Hoe Subagent Config Data Wordt Gebruikt

Nu je weet hoe je subagents moet maken, gaan we kijken naar de patronen die ze echt effectief maken. Een slecht geconfigureerde subagent zal afdwalen, te lang draaien, of output produceren die de hoofdagent niet kan gebruiken. De oplossingen komen neer op vier dingen: goede beschrijvingen schrijven, een output format definiëren, obstakels rapporteren, en tool-toegang beperken.

Wanneer je een bericht naar de hoofdagent in het context window stuurt, worden de naam en beschrijving van elke beschikbare subagent opgenomen in de system prompt. Dit is hoe de hoofdagent besluit welke subagent hij moet starten en wanneer. Als je beter controle wilt over wanneer een subagent automatisch wordt geactiveerd, zijn de naam en beschrijving wat je moet aanpassen.

De beschrijving speelt ook een tweede rol. Wanneer de hoofdagent een subagent start, schrijft hij een input prompt om de taak op gang te brengen. Hij gebruikt de beschrijving als richtlijn voor het schrijven van die prompt. De beschrijving bepaalt dus niet alleen wanneer een subagent draait -- het bepaalt ook wat de subagent wordt verteld om te doen.

Beschrijvingen Schrijven Die Input Prompts Vormgeven

Beschouw een code review subagent. Met een generieke beschrijving zou de hoofdagent een input prompt kunnen schrijven als "gebruik get diff om de huidige wijzigingen te vinden. " Dat is vaag. De subagent moet zelf uitzoeken welke bestanden belangrijk zijn.

Als je de beschrijving aanpast met iets als "Je moet de agent precies vertellen welke bestanden je wilt laten beoordelen," zal de hoofdagent nu een veel specifiekere input prompt schrijven met de werkelijke bestanden die moeten worden beoordeeld.

Deze zelfde techniek werkt voor verschillende soorten subagents. Als je bijvoorbeeld "retourneer bronnen die kunnen worden geciteerd" toevoegt aan de beschrijving van een web search subagent, zal de hoofdagent deze instructie opnemen wanneer hij de taak delegeert.

Een Output Format Definiëren

De belangrijkste verbetering die je aan een subagent kunt aanbrengen is het definiëren van een output format in zijn system prompt. Dit doet twee dingen:

Het creëert natuurlijke stoppunten -- de subagent weet dat hij klaar is wanneer hij elk onderdeel van het format heeft ingevuld.
Het voorkomt dat de subagent te lang draait. Zonder een gedefinieerd output format worstelen subagents om te bepalen wanneer genoeg onderzoek is gedaan en draaien ze meestal veel langer dan nodig.

Hier is een voorbeeld van een gestructureerd output format voor een code review subagent:

Geef je beoordeling in een gestructureerd format:

Samenvatting: Kort overzicht van wat je hebt beoordeeld en algemene beoordeling
Kritieke Problemen: Beveiligingskwetsbaarheden, gegevensintegriteitsrisico's,

of logicafouten die onmiddellijk moeten worden opgelost

Grote Problemen: Kwaliteitsproblemen, architectuurmisalignment, of

aanzienlijke prestatieproblemen

Kleine Problemen: Stijlinconsistenties, documentatiegaten, of

kleine optimalisaties

Aanbevelingen: Suggesties voor verbetering, refactoring-

mogelijkheden, of best practices om toe te passen

Goedkeuringsstatus: Duidelijke verklaring of de code klaar is

om samen te voegen/in te zetten of wijzigingen vereist

Dit format geeft de subagent een duidelijke checklist om door te werken. Zodra elk onderdeel is ingevuld, weet de subagent dat hij kan stoppen.

Obstakels Rapporteren

Wanneer een subagent tijdens zijn werk een workaround ontdekt -- zoals het oplossen van een afhankelijkheidsprobleem of het vinden dat een bepaalde opdracht bepaalde vlaggen nodig heeft -- moeten die details verschijnen in de samenvatting die hij retourneert. Als ze dat niet doen, moet de hoofdthread dezelfde oplossingen zelf herontdekken, wat tijd en tokens verspilt.

De soorten dingen die je naar voren wilt brengen zijn:

Setup-problemen of omgevingskenmerken
Workarounds die tijdens de taak zijn ontdekt
Opdrachten die speciale vlaggen of configuratie nodig hadden
Afhankelijkheden of imports die problemen veroorzaakten

De manier om deze informatie te krijgen is er expliciet om te vragen in het output format. Het toevoegen van een "Obstakels Ondervonden" sectie aan je output template brengt deze informatie betrouwbaar naar voren.

Obstakels Ondervonden: Rapporteer alle obstakels die tijdens het

beoordelingsproces zijn ondervonden. Dit kan zijn: setup-problemen, ontdekte workarounds of omgevingskenmerken. Rapporteer opdrachten die een speciale vlag of configuratie nodig hadden. Rapporteer afhankelijkheden of imports die problemen veroorzaakten.

Tool-Toegang Beperken

Niet elke subagent heeft toegang tot elk tool nodig. Denk na over wat een subagent werkelijk moet doen, en geef het alleen de tools die nodig zijn voor die taak. Dit doet twee dingen: het voorkomt onbedoelde bijeffecten, en het maakt de rol van elke subagent duidelijker wanneer je er meerdere hebt.

Hier is hoe je over tool-toegang moet denken voor veelvoorkomende subagent-typen:

Onderzoeks- / alleen-lezen subagent \-- Heeft alleen Glob, Grep, en Read nodig. Kan bestanden niet per ongeluk wijzigen.
Code reviewer \-- Heeft Bash toegang nodig om git diff uit te voeren en te zien wat is veranderd, maar heeft nog steeds geen Edit of Write nodig.
Styling / code wijzigingsagent \-- Dit is waar je Edit en Write toegang geeft, omdat de taak van de subagent is om je code werkelijk te veranderen.

Het Allemaal Samenvoegen

Effectieve subagents hebben vier kenmerken:

Specifieke beschrijvingen \-- De beschrijving bepaalt wanneer de subagent wordt gestart en welke instructies hij ontvangt. Schrijf het om beide te sturen.
Gestructureerde output \-- Definieer een output format in de system prompt zodat de subagent weet wanneer hij klaar is en informatie retourneert die de hoofdthread kan gebruiken.
Obstakelrapportage \-- Voeg een sectie in het output format toe voor workarounds, kenmerken en problemen zodat de hoofdthread ze niet opnieuw hoeft te ontdekken.
Beperkte tool-toegang \-- Geef een subagent alleen de tools die hij werkelijk nodig heeft. Alleen-lezen voor onderzoek, bash voor reviewers, bewerk/schrijf alleen voor agents die code moeten wijzigen.

Elk van deze patronen is op zichzelf eenvoudig, maar samen veranderen ze een subagent van iets dat vaag probeert te helpen in een gerichte, voorspelbare werker die op tijd klaar is en duidelijk terugrapporteert.