Ein Agent mit gutem Kontext schlägt einen Schwarm: Warum Übergaben Multi-Agent-Code zerstören

Sieben Agenten, eine gelöschte Funktion

Ein Orchestrator startete sieben Agenten. Sechs davon schrieben dieselbe Funktion, und der siebte löschte sie. Hier ist der gekürzte Diff, denn sehen ist besser als davon hören:

+ def limit(req):            agents/a2.py
+ def rate_limit(req):       agents/a3.py
+ def check_limit(r):        agents/a4.py
+ def limiter(request):      agents/a5.py
+ def apply_limit(req):      agents/a6.py
+ def limit(req):            agents/a7.py
- def limit(req):            agents/a7.py  (removed a2's copy)

Das sind fünf Versionen einer vierzigzeiligen Funktion, jede für sich völlig vernünftig, keine wusste von den anderen. Dann bemerkte ein siebter Agent einen doppelten Namen, tat das Verantwortungsvolle und entfernte genau die Version, die alles andere importierte. Zuzusehen, wie das vorbeiscrollte, während echtes Geld verbrannte, löste keinen Frust aus, sondern Peinlichkeit: Die teuerste denkbare Maschine hatte gerade einen Ordner gebaut, der nicht kompiliert, nach einem Architekturdiagramm, auf das jemand stolz war.

Wer schon einmal Kästchen mit Planner, Coder, Reviewer und Tester beschriftet und dabei ein kleines Hochgefühl verspürt hat, etwas Ernsthaftes zu entwerfen, ist hier gemeint.

Die Rechnung, die auf Folien fehlt

Nehmen wir einen Agenten, der in 95 Prozent der Fälle richtigliegt, also einen wirklich guten. Verketten Sie fünf davon und sehen Sie zu, was passiert. Die Schleife läuft vier Sekunden:

p = 0.95
for n in range(1, 6):
    print(n, round(p**n, 2))

1 0.95
2 0.9
3 0.86
4 0.81
5 0.77

Aus einer soliden Eins wurde eine Drei, und die Rechnung ist fünfmal so hoch. Vorträge über Agenten-Orchestrierung gibt es reichlich, doch diese kleine Schleife taucht selten auf einer Folie auf.

Bei der Übergabe bricht es

Das zu bemerken dauerte am längsten. Ein Agent, der tief in einem Problem steckt, trägt eine riesige Menge unausgesprochenen Zustand mit sich. Er weiß, dass die Auth-Middleware mit Klebeband zusammengehalten wird, dass die Testsuite die Abdeckung schönt und dass der naheliegende Fix schon probiert wurde und alles in die Luft gejagt hat.

Eine Übergabe transportiert nichts davon. Weitergereicht wird eine Notiz von vielleicht dreihundert Tokens, höchstens tausend, und der Rest verschwindet, wenn der Prozess endet. Der zweite Agent arbeitet also nicht mit dem, was der erste wusste, sondern mit einer Zusammenfassung davon, und trifft auf diesem komprimierten Rest tragende Entscheidungen.

FIVE AGENTS

  [A1] --msg--> [A2] --msg--> [A3] --msg--> [A4]
   |             |             |             |
  full          ~300          ~300          ~300
  context       tokens        tokens        tokens
   |             |             |             |
  knows         guesses       guesses       guesses

ONE AGENT
   retrieval ---+
   memory    ---+---> [ AGENT ] ---> output
   tools     ---+         ^  |
   compaction---+         |  |
                          +--+
                     one head, one state,
                     nothing lost in transit

Das stärkste Argument für Multi-Agent

Die Gegenposition ist stark, deshalb bekommt sie eine faire Anhörung. Erstens funktioniert Spezialisierung: Bei einer bestimmten Aufgabe schlägt ein Agent mit engem Prompt einen Generalisten. Zweitens sind Kontextfenster endlich, und fünf davon bieten fünfmal so viel Platz. Drittens ist ein frischer Kontext der einzige Reviewer, dem man trauen kann. Ein Agent, der sechzigtausend Tokens damit verbracht hat, sich von einem Design zu überzeugen, ist schlecht geeignet, es zu beurteilen. Schließlich schlagen Recherchesysteme, die viele Quellen gleichzeitig durchforsten, tatsächlich einsträngige, und dieser Gewinn wurde gemessen, nicht beworben.

Auffächern ist also nicht tot. Man setzt es nur entlang der falschen Dimension ein.

Lesen lässt sich verteilen, Schreiben nicht

Agenten zu zählen ist nicht der richtige Test. Entscheidend ist, ob die Teilaufgaben Entscheidungen treffen, die zueinander passen müssen. Lesen lässt sich fast kostenlos aufteilen, ob vierzig Quellen, hundert Dateien oder sechs zu prüfende Behauptungen, denn niemand legt sich auf etwas fest, und es gibt keinen gemeinsamen Zustand, der zerbrechen könnte.

Beim Schreiben ist es umgekehrt. Lassen Sie zwei Agenten unabhängig eine API-Form wählen, und Sie bekommen zwei Entwürfe, die jeweils sinnvoll sind und nicht zusammenpassen. Sie abzugleichen dauert länger, als die Arbeit Schritt für Schritt zu erledigen.

hits = par([find(q) for q in qs])   # reads fan out
patch = run(req, ctx + hits)        # writes go through one head

Kurz gesagt: Lesen auffächern, Schreiben durch eine Stelle leiten. Die ganze Regel passt auf eine Serviette.

Der langweilige Teil ist die eigentliche Arbeit

Die Hauptarbeit ist nicht "ein Agent", sondern guter Kontext, und das ist mühsame, unfotogene Arbeit:

• Retrieval, das die richtigen vier Dateien liefert statt der Top 20 nach Kosinus-Ähnlichkeit
• Kompaktierung, die über eine lange Sitzung hält
• Gedächtnis, das festhält, warum ein Ansatz verworfen wurde, statt was getippt wurde
• Tool-Ausgaben, die so geformt sind, dass ein einzelner Aufruf nicht das halbe Fenster verschlingt

Konferenzveranstalter fragen nicht nach Vorträgen über Kompaktierungsstrategien, also bauen die Leute stattdessen Schwärme. Ein Orchestrierungsdiagramm erfasst man auf einen Blick, drei Wochen Arbeit am Inhalt des Prompts dagegen nie. Diese drei Wochen lohnen sich, und zwar immer wieder.

Probieren Sie es morgen aus

Protokollieren Sie jedes Token, das während einer vollständigen Sitzung in das Fenster Ihres Agenten gelangt. Lesen Sie das Protokoll dann durch und schätzen Sie, welcher Anteil für die Entscheidung relevant war, die der Agent tatsächlich treffen musste. In diesem Fall war es weniger als ein Drittel. Ein brillantes Modell wurde mit einem Feuerwehrschlauch voller Rauschen gefüttert und dann für seine Treffsicherheit getadelt.