← Arbeitsjournal 2026

Arbeitsjournal

2026-01-24

Heute habe ich bis 11 Uhr durchgeschlafen, fühlte mich total entspannt – so ausgiebig geschlafen habe ich schon lange nicht mehr.

  1. Was ich heute gemacht habe:

    1. Neue Version von node-unit deployed. Der Hauptgrund, warum ich relativ beruhigt deployen konnte, ist, dass ich umfassende End-to-End-Tests habe. Im Detail: Ich habe einen TimescaleDB (PostgreSQL 17) per Docker gestartet, dann zwei Instanzen von node-unit hochgefahren und 21 Einträge von @yuants/portal in die Datenbank eingefügt, um zu testen, dass die Verteilung am Ende auf 50/50 konvergiert.

      Dieser Test deckt im Wesentlichen ab, was passiert, wenn viele herrenlose Deployments auftauchen. Sobald zwei node-unit-Instanzen laufen, kann man beobachten, wie sie sich abwechselnd die Deployments schnappen. Was noch fehlt, ist einerseits die tatsächliche CPU-/Memory-Last durch Workloads und andererseits das Szenario, dass eine node-unit aus irgendeinem Grund offline geht.

    2. Mit der neuen Multi-Agent-Version von Legionmind in Yuan das Problem des Output-Streams des Earn-Kontos von vendor-gate gelöst. Ich habe den Agenten angewiesen, zunächst mit Legion Dokumentation zu erstellen. Insgesamt kamen folgende Dokumente dabei heraus:

      .legion/tasks/vendor-gate
├── context.md
├── docs
│   ├── api-doc.md
│   ├── pr-body.md
│   ├── report-walkthrough.md
│   ├── rfc.md
│   ├── spec-bench.md
│   ├── spec-dev.md
│   ├── spec-obs.md
│   └── spec-test.md
├── plan.md
└── tasks.md

      Das fühlt sich nach einem vernünftigen Workflow an. Allerdings gibt es Konflikte zwischen meinem neuen Multi-Agent-System und der existierenden Dokumentationserstellung von Legionmind. Ich sollte die Grenzen der einzelnen Aufgaben sorgfältig überdenken. Die Spezifikationen für die Erstellung der einzelnen Dokumenttypen sollten in separate Skills ausgelagert werden, während Legionmind eher eine Workflow-Beschreibung sein sollte. Jeder Agent sollte einige kleinere Skills laden können, um seine Arbeit zu unterstützen.

      Ein weiteres Problem: Bei der ersten Ausführung hat der Agent einen Fehler gemacht und den Account-Output-Stream in account-actions-with-credential.ts ausgegeben. Der Grund: Ich hatte ihn angewiesen, sich an vendor-okx zu orientieren, um das Earn-Konto anzubinden – weil bisher nur das Earn-Konto von OKX als Account integriert ist. Allerdings hat die KI auch einige veraltete Praktiken übernommen. Der aktuelle Standard für Exchange-Integrationen ist, alle Konten über provideExchangeServices zu veröffentlichen, nicht über provideAccountActionsWithCredential.

      Dieses Wissen besitzt ein brandneuer KI-Agent nicht. Wie kann man dieses Wissen modellieren? Wie kann man dem KI-Agenten diesen Projektkontext als externes Gehirn bereitstellen? Das ist eine tiefgründige Frage, über die ich morgen nachdenken muss.

    3. Nachmittags habe ich gekocht, um die Freunde von SY zu bewirten – das hat mich ganz schön geschlaucht. Morgen geht es also mit der Arbeit weiter.

  2. Gedanken:

    • Wie oben erwähnt, muss ich genau überlegen, wie ich dem KI-Agenten kompakt ein externes Gehirn designen kann. Der einfachste Ansatz wäre, mit einer Reihe von AGENT.md-Dateien zu beginnen. Das habe ich bereits versucht, aber der Overhead für die Pflege dieser Dokumente ist recht hoch. Es ist schwierig, zwischen nutzlosem Wissen und wirklich bewahrenswerten Erfahrungen zu unterscheiden. Derzeit scheint das Gedächtnis wie ein weiterer Prompt zu sein, nur dass der Agent zusätzlich eine Rückkopplungsschleife hat, um das Gedächtnis selbst zu aktualisieren. Am wichtigsten ist jedoch, wie man die Arbeitsergebnisse des KI-Agenten bewertet.

    • Zu diesem Punkt: Ich habe einen interessanten Artikel gelesen, den ich jetzt in meinen eigenen Worten zusammenfasse: Zunächst zur Bewertung der Einzelschritte eines Agenten. Diese Bewertung kann in verschiedene Kategorien unterteilt werden:

      1. Statische Tool-Evals: Compiler, Linter, Unit-Tests, E2E-Tests
      2. Model-Evals: Bewertung durch ein anderes LLM anhand selbstdefinierter Prompts
      3. Manuelle Evals: Bewertung durch mich persönlich

      Für eine systemische Bewertung eines Agenten gibt es zwei Arten:

      1. Fähigkeitsbezogen: Beantwortet die Frage „Was kann der Agent?“. Die Erfolgsquote kann niedrig sein – z.B. wenn ich Legion nutze, um schrittweise größere, schwierigere Aufgaben zu bearbeiten. Das fühlt sich an wie die Erkundung einer neuen Grenze.
      2. Regressionsbezogen: Kann der Agent noch die Fähigkeiten behalten, die er zuvor hatte? Z.B. wiederholtes Testen bestimmter Aufgaben, um sicherzustellen, dass sie stabil erledigt werden.

      Sobald eine neue Fähigkeit eingeführt wird, sollte man von der fähigkeitsbezogenen zur regressionsbezogenen Bewertung übergehen.

      Der Artikel erwähnt auch zwei wichtige Metriken: pass@K und pass^K

      • pass@k: Mindestens ein Erfolg in k Versuchen. Je mehr Versuche, desto höher die Wahrscheinlichkeit mindestens eines Erfolgs. Anwendbar, wenn man nur daran interessiert ist, „mindestens eine brauchbare Lösung zu finden“.
      • pass^k: Alle k Versuche müssen erfolgreich sein. Je mehr Versuche, desto schwieriger wird die Konsistenz. Anwendbar, wenn der Benutzer einen zuverlässigen Produktionsagenten erwartet.

      FYI: Siehe diesen Artikel

    • Meine Energie ist immer noch etwas schwach. Nachmittags ein bisschen gearbeitet, abends gekocht – fühlte mich schon etwas müde. Wann werde ich so wie CZ gar keinen Schlaf mehr brauchen?

  3. Was ich morgen vorhabe:

    1. Über das Modell des Bewertungs-Agenten nachdenken und das Multi-Agent-System weiter iterieren.
    2. Clustersicherheit – das muss unbedingt angegangen werden.
    3. legion-github-bridge