Ich startete eine Fünf-Subagenten-Orchestrierung, um ein Auth-Modul zu refaktorisieren. Es kostete mich $11, dauerte zwölf Minuten und lieferte ein schlechteres Ergebnis als wenn ich es einfach in einem Thread gemacht hätte. Subagenten sind für Solo-Builder überschätzt, und die Twitter-Demos, die schöne Agent-Schwärme zeigen, erzählen dir nicht den Teil, wo es teuer und seltsam wird.
Missversteht mich nicht. Subagenten sind ein echtes Feature mit echten Anwendungsfällen. Aber der Standard-Rat — "brich alles in spezialisierte Agenten auf" — ist falsch für die Person, die alleine ein Produkt baut. Meistens willst du einen flachen, Single-Thread-Agenten, der die Arbeit einfach erledigt. Lass mich erklären warum.
Was ein Subagent wirklich kostet
Wenn du einen Subagenten startest, delegierst du nicht nur eine Aufgabe. Du spinnst einen frischen Kontext, der nichts über deinen Hauptthread weiß. Also musst du ihn briefen. Jeder Subagent braucht die relevanten Dateien, die Konventionen, das Ziel — von Null neu erklärt. Das Briefing sind Tokens. Die Arbeit des Subagenten sind Tokens. Dann berichtet er zurück, und sein Bericht in den Hauptthread zu synthetisieren sind noch mehr Tokens.
Für eine parallele Aufgabe mit sauberen Grenzen ist dieser Overhead es wert. Für eine Aufgabe, bei der die Teile verflochten sind — was die meiste echte Coding-Arbeit beschreibt — zahlst du die Briefing-Steuer immer wieder, und die Subagenten treten sich ständig gegenseitig auf die Füße, weil keiner von ihnen das gesamte Bild sehen kann.
Die Single-Thread-Version hat den Kontext einfach... bereits. Sie hat die Dateien einmal gelesen. Sie erinnert sich, was sie vor drei Schritten getan hat. Kein Briefing, keine Synthese, kein Koordinations-Overhead. Oft ist es sowohl günstiger als auch besser.
Das Kontext-Fragmentierungsproblem
Hier ist das Subtile. Der ganze Grund, warum Agenten gut im Coding sind, ist der gemeinsame Kontext — das Modell hält das Problem, die Dateien und seine eigenen vorherigen Entscheidungen an einem Ort und denkt über alles gemeinsam nach. Subagenten zersplittern das. Jeder sieht nur einen Ausschnitt.
Also behebt Subagent A die Fehlerbehandlung auf seine Weise. Subagent B, separat gebrieft, behebt die Validierung auf eine andere Weise. Keiner weiß, was der andere getan hat. Du, im Hauptthread, musst jetzt zwei lokal vernünftige Änderungen in Einklang bringen, die nicht zusammenpassen. Ich habe mehr Zeit damit verbracht, Subagenten-Output in Einklang zu bringen, als die Subagenten eingespart haben. Das ist die Falle.
Für einen Solo-Builder ist dein Vorteil, dass du das gesamte Bild in deinem Kopf hältst und der Agent es im Kontext hält. Das zu fragmentieren, um wie ein Team auszusehen, ist so, als würdest du eine Organisation cosplayen, die du nicht hast.
Wann Subagenten wirklich zahlen
Ich sage nicht niemals. Hier greife ich tatsächlich nach ihnen:
- Wirklich parallele, unabhängige Arbeit. "Führe die Testsuite aus, während du auch die Codebase lintest." Kein gemeinsamer Zustand, keine Abstimmung. Sauberes Fan-out.
- Bewusste Kontext-Isolation. Wenn eine Teilaufgabe meinen Hauptkontext mit Mist überfluten würde, den ich nicht im Hauptthread haben will — wie 40 Dateien zu lesen, um eine Frage zu beantworten. Der Subagent liest die 40, gibt die eine Antwort zurück, mein Hauptkontext bleibt sauber. Das ist eine tolle Verwendung.
- Begrenztes Research. "Geh herausfinden, wie die Auth dieser Bibliothek funktioniert, und berichte zurück." Die Erkundung ist unordentlich; ich will nur das Fazit.
Das Muster beachten: Subagenten verdienen ihren Platz, wenn die Teilaufgabe unabhängig und zusammenfassbar ist. Wenn der Wert darin liegt, Chaos aus dem Hauptthread herauszuhalten, nicht darin, ein Team vorzutäuschen.
Die Orchestrierungs-Fantasie
Es gibt ein Genre von Inhalten, das den Multi-Agenten-Traum verkauft — ein Planer-Agent, ein Coder-Agent, ein Reviewer-Agent, ein Tester-Agent, alle koordinieren wie ein kleines Unternehmen. In einem Diagramm sieht das unglaublich aus. Für einen Solo-Builder ist es meistens eine Möglichkeit, eine $0,50-Aufgabe in eine $6-Aufgabe zu verwandeln.
Der Planer erklärt dem Coder die Aufgabe neu. Der Coder produziert Arbeit. Der Reviewer, mit seinem eigenen frischen Kontext, liest alles neu durch, um es zu reviewen. Der Tester liest es wieder durch. Jede Übergabe verarbeitet denselben Code erneut. Du hast die Ineffizienz eines großen Teams neu erschaffen — den gesamten Kommunikations-Overhead — ohne den Nutzen, denn es bist immer noch nur du und das Modell.
Ein einzelner fähiger Agent in einem Thread plant, codiert und überprüft sich selbst, während er alles im Kontext hält. Du liest das Diff am Ende. Das ist dein Reviewer. Du bist das Organigramm.
Meine Regel
Standard ist flach. Ein Thread, ein Agent, vollständiger Kontext. Ich greife nur dann zu einem Subagenten, wenn ich mit Ja antworten kann auf: Ist diese Teilaufgabe unabhängig, und will ich nur die Zusammenfassung zurück?
# Die Frage, die ich stelle, bevor ich einen starte:
# - Unabhängig von der Hauptarbeit? (kein gemeinsamer Zustand zur Abstimmung)
# - Zusammenfassbar? (ich will ein Fazit, keinen rohen Output)
# Beide ja -> Subagent. Sonst -> flach bleiben.
Alles andere bleibt im Hauptthread, wo der Kontext vollständig ist und die Rechnung klein ist.
Der Agenten-Schwarm sieht wie die Zukunft aus. Für eine Person, die ein Produkt ausliefert, ist es meistens ein Kostüm. Zieh es aus und mach die Arbeit in einem Thread. Dein Token-Budget wird es dir danken, und der Code auch.