Eliminera felaktiga svar

Den agentiska loopen avslutas med stop_reason – aldrig genom att söka igenom modellens text efter ord som ”done” eller ”finished”. Alla alternativ som fortsätter loopen så länge en sträng finns i resultatet är distraktorer som bygger på antimönster.

Rätt mekanism är att skicka hela historiken i varje tur, kontrollera stop_reason, köra verktyg vid tool_use och stoppa vid end_turn.

En nära släkting till den föregående fällan. En iterationsgräns ("stoppa efter 10 varv") är ett legitimt säkerhetsnät — men den är aldrig den primära stoppmekanismen. Beslut styrs av modellen; reservera hårdkodade gränser för garantier, inte för styrning av kontrollflödet.

Så när två alternativ båda nämner en loopgräns ska du läsa noggrant: det felaktiga alternativet gör gränsen till det huvudsakliga avslutningsvillkoret. Det rätta stoppar vid end_turn och använder gränsen enbart som skydd mot skenande loopar.

När en fråga gäller pengar, juridik eller säkerhetskonsekvenser (återbetalningsgränser, policyöverträdelser) är ett alternativ som säger "instruera modellen i systemprompten att aldrig återbetala mer än 500 dollar" en distraktion. Prompter är ungefär 90 % probabilistiska. Hooks är 100 % deterministiska.

Det korrekta svaret tillämpar regeln med en PostToolUse- eller utgående anrops-hook eller ett programmatiskt förvillkor — kod som modellen inte kan prata sig runt.

Två distraktioner inom verktygsdesign dyker ständigt upp i frågor om scenario 4 och 8:

• "Förbättra urvalet genom att döpa om verktygen" — fel. Det är verktygens beskrivningar, inte namnen, som är den primära urvalsmekanismen.
• "Ge agenten alla 18 verktyg så att den aldrig saknar ett" — fel. 4–5 verktyg per agent är optimalt; 18 eller fler försämrar urvalets tillförlitlighet.

De korrekta svaren är att skriva utförliga beskrivningar (syfte, returvärden, indataformat med exempel, specialfall och begränsningar) och att avgränsa verktygen strikt efter rollen enligt principen om minsta behörighet.

I scenarier med flera agenter och extrahering ska du se upp för två felaktiga mönster:

• Att returnera "Operation failed" — en generisk status som förhindrar intelligent återställning.
• Att tysta ned ett fel eller avbryta hela arbetsflödet för att en underagent misslyckades.

Det korrekta svaret returnerar strukturerade fel: isError, errorCategory (transient/validation/business/permission), isRetryable, den försökte frågan och partiella resultat. Det skiljer också ett åtkomstfel (kan kanske försöka igen) från ett giltigt tomt resultat (inga träffar — försök inte igen).

I scenarier som gäller kodgranskning och CI/CD (scenario 2 och 5) ska du stryka alla alternativ som granskar i samma session som genererade koden — upphovspersonen behåller sitt eget resonemang och kommer inte att ifrågasätta sig själv. En oberoende granskning i en ny instans är alltid starkare.

Stryk också granskning av flera filer i ett enda pass: det splittrar uppmärksamheten. Den korrekta metoden med flera pass gör först ett lokalt pass per fil och därefter ett separat integrationspass över filer.

Message Batches API är 50 % billigare och har ett tidsfönster på upp till 24 timmar — men det har ingen SLA för svarstid och stöder inte verktygsanrop i flera turer. Därför är alla alternativ som använder Batch för en pre-merge-grind, en synkron användarkontroll eller en agentisk verktygsloop distraktioner.

Batch är rätt endast för jobb som inte blockerar: nattliga granskningar och massrapporter. Om scenariot innehåller ord som "blockerande", "pre-merge", "realtid" eller "användaren väntar" — stryk Batch omedelbart.

Två andra vanliga distraktioner:

• Eskalering som utlöses av sentimentanalys eller ett självskattat konfidensvärde från modellen (1–10). Det här är dåliga utlösare. Bra utlösare är en uttrycklig begäran från en människa, luckor i policyn, uteblivna framsteg efter försök och överträdelser av tröskelvärden.
• Att markera ett fält som kanske saknas med required i ett JSON-schema. Modellen kommer att hitta på det. Kräv ett fält ENDAST om det alltid finns; använd enum-värden med "other" samt en fritextdetalj för utbyggbarhet.

Om ett alternativ eskalerar vid "arg ton" eller kräver "middle_name" — stryk det.

Sammanför detta till en återanvändbar process för varje fråga:

• 1. Läs scenariot för att hitta den verkliga begränsningen — pengar/juridik (kräver en hook), blockerande kontra nattligt (Batch eller inte), en eller flera filer (pass), fält som finns kontra saknas (required eller inte).
• 2. Sök igenom alla 4 alternativ efter varningssignaler för felaktiga mönster och stryk varje träff. Vanligtvis faller 2–3 bort.
• 3. Välj bland de återstående det alternativ som ger en deterministisk garanti där det spelar roll — strukturerat framför generiskt, modellstyrt stopp framför texttolkning, oberoende granskning framför självgranskning.
• 4. Svara alltid. Det finns inget avdrag för att gissa — lämna aldrig ett svar tomt, inte ens när det är helt jämnt.

Att känna igen felaktiga mönster är inte en genväg förbi förståelsen; det är så en erfaren arkitekt läser en fråga snabbt och korrekt.

Viktiga slutsatser för att eliminera felaktiga svar:

• Distraktioner är vanligtvis förklädda felaktiga mönster. Memorera katalogen och behandla varje sådant mönster som en varningssignal.
• Stryk direkt: texttolkning för att stoppa, iterationsgränser som primärt stopp, prompter för kritiska regler, generiska eller undertryckta fel, för många verktyg, verktygsurval baserat på namn, granskning i ett enda pass och i samma session, Batch för blockerande kontroller, eskalering baserad på sentiment eller konfidens och krav på fält som kan saknas.
• Det rätta svaret prioriterar deterministiska garantier när insatserna är höga: hooks och förvillkor, strukturerade fel, modellstyrd avslutning vid end_turn, oberoende granskning och utförliga verktygsbeskrivningar.
• Svara alltid — inget avdrag för att gissa. Stryk två distraktioner så blir en ren gissning ett välgrundat val.

Känn igen fällan, så väljer det korrekta alternativet i praktiken sig självt.