Effektive Subagenten gestalten

Wie Subagenten-Konfigurationsdaten verwendet werden

Wenn du eine Nachricht an den Hauptagenten im Kontextfenster sendest, werden der Name und die Beschreibung jedes verfügbaren Subagenten in den System-Prompt aufgenommen. So entscheidet der Hauptagent, welchen Subagenten er wann startet. Wenn du mehr Kontrolle darüber haben möchtest, wann ein Subagent automatisch ausgelöst wird, solltest du den Namen und die Beschreibung anpassen.

Die Beschreibung spielt auch eine zweite Rolle. Wenn der Hauptagent einen Subagenten startet, schreibt er einen Eingabe-Prompt, um die Aufgabe anzustoßen. Dabei nutzt er die Beschreibung als Orientierung für das Verfassen dieses Prompts. Die Beschreibung steuert also nicht nur, wann ein Subagent läuft -- sie bestimmt auch, was dem Subagenten aufgetragen wird.



Beschreibungen schreiben, die Eingabe-Prompts prägen

Stell dir einen Subagenten für Code-Reviews vor. Mit einer generischen Beschreibung könnte der Hauptagent einen Eingabe-Prompt wie „verwende git diff, um die aktuellen Änderungen zu finden" schreiben. Das ist vage. Der Subagent muss selbst herausfinden, welche Dateien relevant sind.

Wenn du die Beschreibung so aktualisierst, dass sie etwas wie „Du musst dem Agenten genau mitteilen, welche Dateien er überprüfen soll" enthält, schreibt der Hauptagent nun einen viel spezifischeren Eingabe-Prompt, der die tatsächlich zu überprüfenden Dateien auflistet.

Diese gleiche Technik funktioniert bei verschiedenen Arten von Subagenten. Wenn du zum Beispiel „gib zitierfähige Quellen zurück" zur Beschreibung eines Websuche-Subagenten hinzufügst, sorgt das dafür, dass der Hauptagent diese Anweisung beim Delegieren der Aufgabe einbezieht.



Ein Ausgabeformat definieren

Die wichtigste Verbesserung, die du an einem Subagenten vornehmen kannst, ist die Definition eines Ausgabeformats in seinem System-Prompt. Das bewirkt zwei Dinge:

• Es schafft natürliche Haltepunkte -- der Subagent weiß, dass er fertig ist, wenn er jeden Abschnitt des Formats ausgefüllt hat.
• Es verhindert, dass der Subagent zu lange läuft. Ohne ein definiertes Ausgabeformat fällt es Subagenten schwer zu entscheiden, wann genug recherchiert wurde, und sie neigen dazu, deutlich länger zu laufen als nötig.

Hier ist ein Beispiel für ein strukturiertes Ausgabeformat für einen Code-Review-Subagenten:

Dieses Format gibt dem Subagenten eine klare Checkliste zum Abarbeiten. Sobald jeder Abschnitt ausgefüllt ist, weiß der Subagent, dass er aufhören kann.

Hindernisse melden

Wenn ein Subagent während seiner Arbeit einen Workaround entdeckt -- etwa das Lösen eines Abhängigkeitsproblems oder die Erkenntnis, dass ein bestimmter Befehl spezielle Flags benötigt --, müssen diese Details in der Zusammenfassung erscheinen, die er zurückgibt. Tun sie das nicht, muss der Hauptthread dieselben Lösungen selbst erneut entdecken, was Zeit und Tokens verschwendet.

Zu den Dingen, die sichtbar gemacht werden sollten, gehören:

• Einrichtungsprobleme oder Eigenheiten der Umgebung
• Während der Aufgabe entdeckte Workarounds
• Befehle, die spezielle Flags oder Konfigurationen benötigten
• Abhängigkeiten oder Imports, die Probleme verursacht haben

Der Weg, diese Informationen zu erhalten, besteht darin, explizit im Ausgabeformat danach zu fragen. Das Hinzufügen eines Abschnitts „Aufgetretene Hindernisse" zu deiner Ausgabevorlage macht diese Informationen zuverlässig sichtbar.



Tool-Zugriff einschränken

Nicht jeder Subagent benötigt Zugriff auf jedes Tool. Überlege dir, was ein Subagent tatsächlich tun muss, und gib ihm nur die für diese Aufgabe erforderlichen Tools. Das bewirkt zwei Dinge: Es verhindert unbeabsichtigte Nebeneffekte, und es macht die Rolle jedes Subagenten klarer, wenn du mehrere davon hast.

So kannst du über den Tool-Zugriff für gängige Subagenten-Typen nachdenken:

• Recherche-/Nur-Lese-Subagent -- Benötigt nur Glob, Grep und Read. Kann Dateien nicht versehentlich verändern.
• Code-Reviewer -- Benötigt Bash-Zugriff, um git diff auszuführen und zu sehen, was sich geändert hat, braucht aber trotzdem kein Edit oder Write.
• Styling-/Code-Änderungs-Agent -- Hier gibst du Edit- und Write-Zugriff, weil die Aufgabe des Subagenten darin besteht, deinen Code tatsächlich zu ändern.

Alles zusammenfügen

Effektive Subagenten teilen vier Merkmale:

1. Spezifische Beschreibungen -- Die Beschreibung steuert, wann der Subagent gestartet wird und welche Anweisungen er erhält. Schreibe sie so, dass sie beides lenkt.
2. Strukturierte Ausgabe -- Definiere ein Ausgabeformat im System-Prompt, damit der Subagent weiß, wann er fertig ist, und Informationen zurückgibt, die der Hauptthread verwenden kann.
3. Hindernisberichterstattung -- Füge einen Abschnitt im Ausgabeformat für Workarounds, Eigenheiten und Probleme hinzu, damit der Hauptthread sie nicht erneut entdecken muss.
4. Eingeschränkter Tool-Zugriff -- Gib einem Subagenten nur die Tools, die er tatsächlich benötigt. Nur-Lese für Recherche, Bash für Reviewer, Edit/Write nur für Agenten, die Code ändern sollen.

Jedes dieser Muster ist für sich genommen einfach, aber zusammen verwandeln sie einen Subagenten von etwas, das vage zu helfen versucht, in einen fokussierten, vorhersehbaren Arbeiter, der pünktlich fertig wird und klar zurückmeldet.