Kontekst, ikke kontrol
Hver regel i din agents prompt startede som en fejl.
Nogen så uhensigtsmæssig adfærd, skrev en regel og gik videre. En anden gjorde det samme. En tredje tilføjede et "aldrig gør X", fordi modellen gjorde noget mærkeligt én gang en tirsdag. Ingen slettede noget.
Seks måneder senere bruger agenten mere af sit kontekstvindue på at navigere i sit regelsæt end på at tænke over den egentlige opgave.
Det er kontrol-tankegang. Og jeg mener, det er en af de største designfejl, teams begår, når de bygger AI-agenter.
Et lille eksempel, der afslører et større mønster
Vi stødte på et problem, hvor en agent udløst af en planlagt opgave blev ved med at oprette nye planlagte opgaver inde i kørslen. Uendelig rekursion, men med reelle konsekvenser i den virkelige verden.
To måder at reagere på.
Kontrolstil: Forbyd det. Skriv kode, der blokerer for, at planlagte opgaver kan oprette flere planlagte opgaver. Tilføj en promptregel: "aldrig opret en planlagt opgave inde i en anden planlagt opgave." Udrul det.
Kontekststil: Fortæl agenten, hvad der faktisk sker.
Du blev udløst af en planlagt opgave kl. 3:00 AM Pacific tid. Schedule ID: sched_29x8f. En planlagt kørsel er en isoleret udførelse med et defineret omfang, som brugeren oprindeligt har godkendt. At oprette en ny planlagt opgave ville udvide dette omfang ud over den oprindelige godkendelse.
Den første tilgang lapper én adfærd. Den anden giver agenten en model af situationen.
Nu kan den også ræsonnere over nærliggende spørgsmål: Skal jeg sende en notifikation kl. 3 AM? Skal jeg oprette et opfølgningsforløb, som brugeren ikke eksplicit har bedt om? Skal jeg ændre noget, der rækker ud over den oprindelige kørsels omfang?
Ingen regel nødvendig. Agenten fandt selv ud af det.
Mange teams vælger kontrol, når de i virkeligheden har brug for kontekst.
Den samme forskel findes i prompts
Det handler ikke kun om systemniveau-håndhævelse. Skellet mellem kontekst og kontrol findes også inde i prompts.
Kontekstbaseret prompting: mest fakta, minimal holdning:
Du kører på grund af en planlagt opgave. Udløst kl. 3:00 AM Beijing tid. Schedule ID: sched_29x8f. Brugeren har godkendt denne kørsel til et specifikt omfang.
Kontrolbaseret prompting: holdningspræget, foreskrivende:
Undgå at oprette planlagte opgaver. Du bør underrette brugeren med værktøj X. Gør aldrig Y medmindre Z.
Nogle gange er foreskrivende instruktioner nyttige. Men ofte kompenserer de for manglende fakta. Og når du først begynder at kompensere på den måde, bliver det hurtigt en vane.
Hvordan prompts bliver til bureaukrati
Dette er den dybere fejlkilde.
Et team ser et problem og tilføjer en regel. Så en til. Og en til. Hver enkelt lapper et lokalt problem, men tilsammen skaber de et system fyldt med stedfortrædere.
Bezos beskrev dette mønster i sit 2016-aktionærbrev: gode processer tjener dig, så du kan tjene kunderne. Men hvis du ikke er opmærksom, bliver processen selve målet.
Det er præcis, hvad der sker i agentsystemer.
Reglen er ikke målet. Reglen er en stedfortræder for det ønskede resultat. Og stedfortrædere hober sig op. Én skaber særtilfælde, der kræver flere. Snart ræsonnerer agenten gennem lag af ophobede instruktioner, hver tilføjet af en historisk grund, som ingen helt husker.
I menneskelige organisationer bliver dette til bureaukrati. I agentsystemer bliver det til en kæmpe prompt fuld af arvæv.
Fakta ældes. Holdninger rådner.
Et faktum som "denne kørsel blev udløst af en planlagt opgave kl. 3 AM" er stabilt. Det forbliver sandt, uanset hvilken model der læser det: Claude, GPT, Gemini, eller hvad der ellers udkommer næste kvartal.
En udtalelse som "du bør undgå at oprette underopgaver" er skrøbelig. Den afhænger af fortolkning. Den kan hjælpe i én situation og fejle lydløst i en anden.
Når du skifter model, er enhver holdning i din prompt en potentiel landmine. Den nye model har andre ræsonnementstendenser, og din nøje afstemte "undgå" kan betyde noget helt andet for den.
Men faktabaseret viden om miljø, tilladelser, omfang og begrænsninger har tendens til at generalisere på tværs af modeller og særtilfælde. Derfor er fakta det bedste byggemateriale.
Model-quirk-fælden
Dette er måske den mest snigende version af kontrolproblemet: teams gør midlertidige modeldefekter til permanent systemstruktur.
En model opfører sig dårligt i et snævert tilfælde. Teamet tilføjer et værn: en prompt-lap, et kodecheck, en særgren, der kun eksisterer for at forhindre én bestemt fejlsituation.
Den lap er et væddemål om, at særheden vil bestå. Det gør den næsten aldrig.
Tre måneder senere ændrer modellen sig. Den oprindelige adfærd forsvinder. Men lappen bliver. Ingen vil fjerne den, for måske var den der af en grund.
Sådan bliver systemprompter til legacy-kode.
Vi kan let genkende faren, når den beskrives abstrakt. Men i praksis er det samme mønster at lappe på Sonnets aktuelle ræsonnementstendenser i prompt efter prompt.
At dokumentere stabil systemadfærd er værdifuldt. At lappe på en models ræsonnement er et hamsterhjul. Modellen ændrer sig hurtigere, end du kan vedligeholde dine lapper.
En god test: Adgang nægtet
Du kan tydeligt se forskellen i værktøjsdiagnostik. Når en agent rammer en tilladelsesfejl:
Kontrolstil:
TOKEN mangler. Kør "zero permissions request gmail.send" for at løse det.
Direkte, men agenten lærer intet. Næste gang den rammer en anden tilladelsesfejl, sidder den fast.
Kontekststil:
process.env.GMAIL_TOKEN → findes zero connectors inspect gmail → tilsluttet zero permissions inspect gmail.send → nægtet
Muligheder:
- Anmod om brugerens godkendelse til gmail.send
- Brug en allerede godkendt sti, hvis en findes
Agenten ved nu, at token eksisterer, connectoren virker, og den specifikke tilladelse er nægtet. Den forstår systemets tilstand og kan ræsonnere om nye situationer, som regelforfatteren aldrig havde forudset.
Heuristikken
Her er det, jeg altid vender tilbage til:
Hver gang du er ved at skrive "ikke", "undgå" eller "aldrig" i en prompt. Stop. Spørg: hvilket faktum kompenserer denne regel for?
Ofte mangler der et faktum. Agenten forstår ikke, hvilket miljø den er i, hvad brugeren har godkendt, hvilke handlinger der er irreversible, eller hvorfor denne kørsel adskiller sig fra en normal chat.
Skriv det faktum ned. Slet reglen.
Nogle gange vil du stadig have begrænsningen, især ved destruktive handlinger, pengeoverførsler eller sikkerhedsgrænser. Hårde kontroller er stadig vigtige.
Men mange promptregler er ikke reelle grænser. De kompenserer for manglende forståelse. Og det er netop dem, der hober sig op og rådner.
Målet
Målet er ikke en agent, der husker en tjekliste.
Målet er en agent, der forstår sin situation godt nok til at træffe gode beslutninger inden for klare rammer.
Den ene filosofi styrer adfærd ved at stable regler. Den anden forbedrer adfærd ved at gøre verden forståelig.
Den første fører mod bureaukrati. Den anden mod forståelse.
Skab kontekst. Fjern arvævet. Udrul agenter, der kan tænke.
