Task-værktøjet og allowedTools

Funktioner tildeles eksplicit. Koordinatorens liste over allowedTools (eller allowed_tools) skal indeholde "Task", for at delegering kan fungere. Det er en bevidst, kontrollerbar tildeling, ikke en automatisk standardindstilling.

Bemærk, at koordinatoren her kun får det, den har brug for til at koordinere: Task til at oprette arbejdere og Read til at undersøge input. Den får ikke Bash eller Write, fordi den ikke skal røre systemet direkte.

Hver underagent beskrives af en AgentDefinition med fire dele:

• name — en kort identifikator, som koordinatoren delegerer til
• description — hvornår denne agent skal bruges (sådan vælger koordinatoren den)
• system_prompt — rollen og instruktionerne
• allowed_tools — de værktøjer, denne arbejder må bruge

description er vigtigst: ligesom værktøjsbeskrivelser er den det primære signal ved udvælgelsen. En vag beskrivelse får koordinatoren til at delegere til den forkerte arbejder.

Hver underagents allowed_tools bør følge princippet om mindste privilegium: giv kun de værktøjer, rollen faktisk har brug for, og begræns dem til den rolle.

En arbejder, der laver research, får WebSearch og Read — aldrig Bash eller process_refund. En arbejder, der skriver filer, får Write og Edit. Smalle værktøjssæt forbedrer også pålideligheden af udvælgelsen: 4-5 værktøjer pr. agent er optimalt, mens 18 eller flere værktøjer gør det mindre pålideligt, om agenten vælger det rigtige.

Vigtigt: De fleste underagenter bør ikke selv få Task. Delegeringsmyndigheden hører til i hubben; hvis den gives bredt ud, opstår der ukontrolleret oprettelse af nye agenter.

Dette er den mest afprøvede kendsgerning om underagenter: underagenter arver IKKE koordinatorens samtalehistorik.

Hver underagent starter med en ren kontekst. Den ser kun det, du skriver i dens prompt. Denne isolation er en fordel — den forhindrer, at én oppustet historik forurener alle arbejdere — men det betyder, at koordinatoren har ansvaret for, at al den kontekst, underagenten har brug for, sendes eksplicit i dens opgaveprompt.

Hvis en underagent har brug for en filsti, et kunde-id, en deadline eller tidligere resultater, skal koordinatoren inkludere dem i den delegerede instruktion. Det er den klassiske fejl at antage, at underagenten allerede ved det.

Da intet arves, skal du skrive opgaveprompter, der kan stå alene. Saml alle de oplysninger, arbejderen har brug for, i den promptstreng, koordinatoren sender.

Sammenlign en dårlig delegering ("undersøg emnet") med en god, der angiver emnet, omfanget, det krævede outputformat og begrænsningerne. Underagenten har ingen anden kilde til sandheden.

Når koordinatoren udsender flere Task-kald i ét svar, kører underagenterne parallelt. Sådan spreder et researchsystem sig over flere emner på én gang i stedet for at undersøge dem ét efter ét.

Brug parallelle Tasks, når underopgaverne er uafhængige — for eksempel research af tre separate emner eller gennemgang af tre filer uden indbyrdes sammenhæng. Hvis opgave B har brug for outputtet fra opgave A, kan de ikke køres parallelt; koordinatoren skal vente på A og derefter delegere B i en senere tur.

Når parallelle arbejdere vender tilbage, sammenlægger koordinatoren resultaterne. Virkelige systemer skal kunne tåle, at én arbejder fejler, uden at hele jobbet afbrydes.

Hvis to af tre researchere lykkes, mens én rammes af en adgangsfejl, bør koordinatoren beholde de to gode resultater, markere manglen og rapportere delvise resultater — ikke kassere hele kørslen. Skeln mellem en reel adgangsfejl (som måske kan forsøges igen) og et gyldigt tomt resultat (ingen match fundet). Håndter midlertidige fejl inde i underagenten, og eskalér kun dem, der ikke kan genoprettes, mens de delvise resultater føres videre.

Det er begge dele dårlige mønstre: at fjerne en fejlet arbejder uden at sige noget eller at afbryde alt på grund af én fejl.

Delegering foregår inde i den agentiske løkke. Koordinatoren sender en forespørgsel, undersøger stop_reason, kører eventuelle Task-værktøjskald, føjer deres resultater til beskedhistorikken og gentager, indtil stop_reason er end_turn.

Du afslutter på baggrund af stopårsagen, aldrig ved at lede i modellens tekst efter ord som 'færdig' eller 'afsluttet'. Beslutninger om, hvilken underagent der skal oprettes som den næste, er modelstyrede. En grænse for antal iterationer er et sikkerhedsnet mod ukontrolleret oprettelse af agenter — ikke den primære måde at stoppe på.

En korrekt opsætning med flere agenter har en genkendelig struktur:

• Koordinatorens allowed_tools indeholder "Task" (samt minimale værktøjer til inspektion).
• Hver underagent har en præcis description, en fokuseret system_prompt og et allowed_tools med mindste privilegium på cirka 4-5 værktøjer.
• Hver delegeret prompt kan stå alene, fordi ingen historik arves.
• Uafhængige opgaver sendes ud som parallelle Task-kald; afhængige opgaver sættes i rækkefølge.
• Koordinatoren sammenlægger resultater, tåler delvise fejl og stopper på end_turn.

Få tildelingen af Task og reglen om eksplicit kontekst på plads, så falder resten af orkestreringen på plads.

Vigtige pointer til eksamen:

• Værktøjet Task opretter underagenter; koordinatorens allowed_tools skal indeholde "Task", for at den kan delegere.
• Arkitekturen er en hub og eger: koordinatoren opdeler, delegerer, sammenlægger, videresender og håndterer fejl.
• Underagenter arver ingen samtalehistorik — send al nødvendig kontekst eksplicit i hver opgaveprompt.
• En AgentDefinition = name, description, system_prompt, allowed_tools; description styrer udvælgelsen.
• Anvend mindste privilegium pr. underagent; sigt efter cirka 4-5 værktøjer, og behold Task i hubben.
• Flere Task-kald i ét svar kører parallelt; sæt dem kun i rækkefølge, når de er afhængige.
• Tål delvise resultater; stop på end_turn, aldrig ved at fortolke tekst, og brug kun en grænse for iterationer som sikkerhedsnet.