Wie Subagent-Konfigurationsdaten verwendet werden

Jetzt, da Sie wissen, wie man Subagenten erstellt, schauen wir uns die Muster an, die sie tatsächlich effektiv machen. Ein schlecht konfigurierter Subagent wird abschweifen, zu lange laufen oder Output produzieren, den der Hauptagent nicht verwenden kann. Die Lösungen laufen auf vier Dinge hinaus: gute Beschreibungen schreiben, ein Output-Format definieren, Hindernisse melden und Toolzugriff begrenzen.

Wie Subagent-Konfigurationsdaten verwendet werden

Wenn Sie eine Nachricht an den Hauptkontext-Fenster-Agenten senden, werden der Name und die Beschreibung jedes verfügbaren Subagenten in den System-Prompt aufgenommen. So entscheidet der Hauptagent, welcher Subagent gestartet werden soll und wann. Wenn Sie eine bessere Kontrolle darüber haben möchten, wann ein Subagent automatisch ausgelöst wird, sind Name und Beschreibung das, was Sie anpassen sollten.

Die Beschreibung spielt auch eine zweite Rolle. Wenn der Hauptagent einen Subagenten startet, schreibt er einen Input-Prompt, um die Aufgabe zu starten. Er verwendet die Beschreibung als Orientierungshilfe für das Schreiben dieses Prompts. Die Beschreibung kontrolliert also nicht nur, wann ein Subagent läuft -- sie prägt, was dem Subagenten gesagt wird zu tun.

Beschreibungen schreiben, die Input-Prompts prägen

Betrachten Sie einen Code-Review-Subagenten. Mit einer generischen Beschreibung könnte der Hauptagent einen Input-Prompt wie „verwenden Sie get diff, um die aktuellen Änderungen zu finden" schreiben. Das ist vage. Der Subagent muss selbst herausfinden, welche Dateien wichtig sind.

Wenn Sie die Beschreibung aktualisieren, um etwas wie „Sie müssen dem Agenten genau mitteilen, welche Dateien Sie überprüft haben möchten" einzubeziehen, wird der Hauptagent nun einen viel spezifischeren Input-Prompt schreiben, der die tatsächlichen zu überprüfenden Dateien auflistet.

Diese gleiche Technik funktioniert über verschiedene Arten von Subagenten hinweg. Zum Beispiel führt das Hinzufügen von „Quellen zurückgeben, die zitiert werden können" zur Beschreibung eines Web-Such-Subagenten dazu, dass der Hauptagent diese Anweisung beim Delegieren der Aufgabe einbezieht.

Ein Output-Format definieren

Die wichtigste Verbesserung, die Sie an einem Subagenten vornehmen können, ist die Definition eines Output-Formats in seinem System-Prompt. Dies bewirkt zwei Dinge:

Es schafft natürliche Stoppunkte -- 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 Output-Format haben Subagenten Schwierigkeiten zu entscheiden, wann genug Recherche durchgeführt wurde, und neigen dazu, viel länger als nötig zu laufen.

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

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

Hindernisse melden

Wenn ein Subagent während seiner Arbeit eine Umgehungslösung entdeckt -- wie das Lösen eines Abhängigkeitsproblems oder das Feststellen, dass ein bestimmter Befehl besondere Flags benötigt -- müssen diese Details in der Zusammenfassung erscheinen, die er zurückgibt. Wenn sie das nicht tun, muss der Hauptthread die gleichen Lösungen selbst neu entdecken, was Zeit und Token verschwendet.

Die Arten von Dingen, die Sie an die Oberfläche bringen möchten, sind:

Setup-Probleme oder Umgebungsbesonderheiten
Während der Aufgabe entdeckte Umgehungslösungen
Befehle, die spezielle Flags oder Konfiguration benötigten
Abhängigkeiten oder Importe, die Probleme verursachten

Die Möglichkeit, diese Informationen zu erhalten, besteht darin, explizit danach im Output-Format zu fragen. Das Hinzufügen eines Abschnitts „Aufgetretene Hindernisse" zu Ihrer Output-Vorlage bringt diese Informationen zuverlässig an die Oberfläche.

Toolzugriff begrenzen

Nicht jeder Subagent benötigt Zugriff auf jedes Tool. Überlegen Sie, was ein Subagent tatsächlich tun muss, und geben Sie ihm nur die Tools, die für diese Aufgabe erforderlich sind. Dies bewirkt zwei Dinge: Es verhindert unbeabsichtigte Nebenwirkungen und macht die Rolle jedes Subagenten klarer, wenn Sie mehrere haben.

So denken Sie über Toolzugriff für häufige Subagenten-Typen nach:

Recherche- / Nur-Lese-Subagent \-- Benötigt nur Glob, Grep und Read. Kann Dateien nicht versehentlich ändern.
Code-Reviewer \-- Benötigt Bash-Zugriff, um git diff auszuführen und zu sehen, was sich geändert hat, benötigt aber immer noch nicht Edit oder Write.
Styling- / Code-Änderungs-Agent \-- Hier geben Sie Edit und Write-Zugriff, weil die Aufgabe des Subagenten darin besteht, Ihren Code tatsächlich zu ändern.

Alles zusammenbringen

Effektive Subagenten teilen vier Merkmale:

Spezifische Beschreibungen \-- Die Beschreibung kontrolliert, wann der Subagent gestartet wird und welche Anweisungen er erhält. Schreiben Sie sie, um beide zu steuern.
Strukturierter Output \-- Definieren Sie ein Output-Format im System-Prompt, damit der Subagent weiß, wann er fertig ist und Informationen zurückgibt, die der Hauptthread verwenden kann.
Hindernismeldung \-- Beziehen Sie einen Abschnitt im Output-Format für Umgehungslösungen, Besonderheiten und Probleme ein, damit der Hauptthread sie nicht neu entdecken muss.
Begrenzter Toolzugriff \-- Geben Sie einem Subagenten nur die Tools, die er tatsächlich benötigt. Nur-Lese für Recherche, bash für Reviewer, Bearbeitung/Schreiben nur für Agenten, die Code ändern sollten.

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