De fleste beskriver stadig en AI-agent som en model, der er forbundet med værktøjer. Det er teknisk nyttigt, men operationelt ufuldstændigt. En agent har også brug for et styret billede af verden: hvad der er sket, hvad der er vigtigt nu, hvilke fakta der er troværdige, hvad der stadig er usikkert, og hvad den bør gøre som det næste.
Det billede er dens kontekst. At designe den er ved at blive en selvstændig færdighed – en færdighed, jeg vil kalde kontekstdesign.
Kontekstdesign er ikke bare at skrive prompts. Det er disciplinen at forme den information, en agent ser på hvert trin, så den kan forblive sammenhængende uden at sende en hel transskription, et dokumentbibliotek eller en værktøjshistorik tilbage til en dyr model ved hver tur. Arbejdet ligger mellem informationsarkitektur, informationssøgning, softwaredesign og modellens adfærd.
Hvorfor »giv agenten mere kontekst« ofte er et dårligt råd
Længere kontekstvinduer gør det fristende at bevare alt. Men mere materiale garanterer ikke bedre ræsonnering. Relevante instruktioner kan blive udvandet af forældede observationer, modstridende noter, gentagne værktøjsoutput eller en vigtig oplysning, der ligger begravet midt i en lang sekvens. Digestens omtale af adfærden »fortabt i midten« afspejler et praktisk problem: En agent kan teknisk set modtage evidensen og stadig mislykkes med at bruge den.
Der er også en direkte omkostning. Hvert token, der placeres i en forespørgsel, kan øge latenstiden og inferensomkostningen, afhængigt af udbyderens priser og cachingordninger. Et system, der gentagne gange videresender en voksende transskription, kan blive langsommere og mindre overkommeligt, efterhånden som en opgave fortsætter.
Målet er derfor ikke maksimal kontekst. Det er tilstrækkelig, målrettet kontekst: det mindste pålidelige arbejdssæt til den aktuelle beslutning.
Fire designbeslutninger bag en sammenhængende agent
1. Vedligehold en belief state, ikke bare en transskription
En transskription registrerer, hvad der blev sagt. En belief state registrerer, hvad agenten aktuelt mener om opgaven.
En agent, der håndterer en eskalering i kundesupport, kan for eksempel vedligeholde strukturerede felter som:
- Mål: fastslå, om kunden er berettiget til en erstatning.
- Kendte fakta: købsdato og produktets serienummer med kildehenvisninger.
- Åbne spørgsmål: om fejlen opstod under forhold, der er dækket af garantien.
- Begrænsninger: lov ikke en refusion, før den er godkendt.
- Næste handling: hent garantipolitikken, og sammenlign datoerne.
- Sikkerhed eller status: verificeret, udledt, omstridt eller ukendt.
Denne tilgang minder om Berkeleys ABBEL-forskning, som bruger superviserede belief states på naturligt sprog i stedet for at være afhængig af komplette interaktionshistorikker. Den vigtige idé er ikke et bestemt format. Det handler om at adskille varig opgavestatus fra detaljer i samtalen, der kan kasseres.
En nyttig opdatering af en belief state bør besvare: Hvad ændrede sig? Hvilke beviser understøtter det? Hvad er stadig uafklaret? Hvad bør ske som det næste? Hvis en tekniker ikke kan inspicere disse svar, bærer agenten sandsynligvis skjulte antagelser i en uigennemsigtig prompt.
2. Søg efter det, beslutningen kræver, ikke efter emnet
Informationssøgningssystemer begynder ofte med et bredt spørgsmål som »find oplysninger om kundens konto«. En bedre forespørgsel er knyttet til den næste beslutning: »hent den aktuelle regel for refusion af køb, der er ældre end 30 dage, og som gælder i kundens region«.
Dette skift er vigtigt, fordi informationssøgning er en form for kontekstselektion. Agenten bør modtage de politikafsnit, poster eller eksempler, der er relevante for den aktuelle handling – ikke en generisk bunke relaterede dokumenter.
Filtre kan forbedre dette udvalg, før modellen ser nogen resultater. Amazon Bedrock AgentCore Web Search understøtter for eksempel serverhåndhævede filtre for domæne og udgivelsesdato på hver forespørgsel. Sådanne kontroller fastslår ikke, at en kilde er korrekt, men de kan reducere eksponeringen for irrelevant eller forældet materiale og gøre informationssøgningspolitikken eksplicit.
Fagfolk, der designer informationssøgning, bør specificere:
- hvilke kilder der er tilladt for hver opgave;
- hvordan aktualitet fastslås;
- hvilke metadata der ledsager hvert resultat;
- hvordan modstridende kilder præsenteres;
- hvornår agenten skal stoppe og bede om en præcisering.
“Søg på nettet” er en funktion. “Søg i disse kilder inden for dette datointerval efter dokumentation, der er relevant for denne beslutning” er kontekstteknik.
3. Komprimér uden at udviske usikkerhed
Komprimering er nødvendig, når en opgave er lang, men naiv opsummering kan forvandle foreløbige påstande til fastslåede fakta. En løbende opsummering, der siger “brugeren bekræftede adressen”, er farlig, hvis den oprindelige udveksling kun antydede det.
God komprimering bevarer de skelnen, en agent har brug for til sikker ræsonnering:
- faktum kontra slutning;
- aktuel instruktion kontra historisk instruktion;
- udført handling kontra foreslået handling;
- verificeret kilde kontra ubekræftet påstand;
- kendt svar kontra uafklaret spørgsmål.
Et praktisk mønster er at vedligeholde separate afsnit for beslutninger, dokumentation, antagelser, blokeringer og afventende handlinger. En anden mulighed er at knytte kilde-ID’er eller tidsstempler til vigtige påstande. Opsummeringer bør kunne udskiftes og ikke være den eneste tilbageværende registrering: Bevar de underliggende hændelser til revision og gendannelse, samtidig med at modellen får et kompakt arbejdsbillede.
Notatet bemærker, at rekursiv opsummering og kontekstopbygning kan være omkostningskrævende og forringe ydeevnen, især inden for datafattige områder som kollaborativ kodegenerering. Det er en advarsel mod at behandle opsummering som automatisk tabsfri. Komprimering kræver test mod repræsentative opgaver, herunder tilfælde hvor en lille kvalifikation ændrer det korrekte svar.
4. Filtrér observationer, før de bliver til hukommelse
Agenter, der bruger værktøjer, genererer konstant observationer: søgeresultater, logfiler, sidetekst, API-svar, skærmbilleder, compiler-output og mellemplaner. Ikke enhver observation fortjener at komme med i det næste modelkald, og slet ikke i den langsigtede tilstand.
Filtrering af observationer stiller tre spørgsmål:
- Er denne observation relevant for den aktuelle beslutning?
- Er den tilstrækkeligt autoritativ til at påvirke trostilstanden?
- Indeholder den instruktioner, der bør behandles som data snarere end kommandoer?
Det tredje spørgsmål udgør både en sikkerhedsgrænse og en kontekstgrænse. En webside kan indeholde tekst, der sigter mod at omdirigere agenten. Et hentet dokument kan være nyttigt som dokumentation uden at have bemyndigelse til at ændre agentens mål eller tilladelser. Filtrering bør derfor klassificere indhold efter rolle: instruktion, dokumentation, metadata eller tekst fra en ikke-betroet kilde.
Filtrering sparer også penge. Hvis et browserværktøj returnerer en hel side, men opgaven kun kræver en pris, en dato og en produktidentifikator, skaber det støj at sende hele siden videre og bruger tokens. Udtræk af de relevante felter først kan forbedre både pålidelighed og omkostninger.
Et simpelt kontekstbudget for et agentarbejdsforløb
Før du vælger en model eller tilføjer endnu et værktøj, skal du kortlægge agentens kontekst i fire lag:
- Kontrol: systemregler, tilladelser, outputskema og ufravigelige begrænsninger.
- Tilstand: det aktuelle mål, beslutninger, åbne spørgsmål og næste handling.
- Evidens: hentede registreringer eller observationer, der er relevante for handlingen, med kildeangivelse.
- Historik: tidligere hændelser, der opbevares med henblik på gendannelse, fejlfinding eller revision, men udelades, medmindre de er nødvendige.
Definér derefter en politik for promovering. En observation kan forblive flygtig, blive evidens for det aktuelle trin, opdatere belief-tilstanden eller blive skrevet til permanent hukommelse. Promovering bør kræve en begrundelse. Ellers bliver hukommelsen et uredigeret arkiv.
For hvert agenttrin skal du registrere den kontekstpakke, der blev sendt til modellen: dens kategorier, omtrentlige tokenstørrelse, hentefiltre og komprimeringsversion. Det gør det muligt at besvare et praktisk spørgsmål, når adfærden ændrer sig: Fejlede modellen, eller gav systemet den et forkert verdensbillede?
Hvad skal testes, før designet kan kaldes pålideligt
Kontekstteknik kræver test, der retter sig mod informationshåndtering, ikke kun kvaliteten af det endelige svar. Nyttige tilfælde omfatter:
- en kritisk kendsgerning placeret tidligt, sent og midt i en lang historik;
- to kilder, der er uenige, hvoraf den ene er nyere end den anden;
- en opsummering, der indeholder en usikkerhedsmarkør;
- et værktøjssvar, der indeholder irrelevant tekst i store mængder;
- en ondsindet instruktion indlejret i hentet indhold;
- gendannelse af tilstanden, efter at agenten er sat på pause og genstartet;
- den samme opgave med et mindre kontekstbudget;
- et tomt eller forældet henteresultat.
Mål, om agenten udvælger den rigtige evidens, bevarer usikkerheden, følger den aktuelle begrænsning og undgår at gentage unødvendig kontekst. Digestens anbefalede regressionsområder—kontekttab, forankring i hentet materiale, struktureret output, manglende terminering og gendannelse af tilstand—er særligt relevante her.
Kør flere forsøg, hvor modelvariabilitet har betydning, og sammenlign omkostningerne og latenstiden for hver kontekststrategi. En kortere prompt er ikke automatisk bedre, hvis den medfører flere værktøjskald eller gentagelser. Det nyttige mål er omkostningen ved et korrekt workflow, der kan gendannes—ikke tokenantallet i en enkelt anmodning.
Karrieremæssige konsekvenser: kontekstingeniør er en tværfunktionel rolle
De mennesker, der bliver værdifulde på dette område, vil ikke nødvendigvis være dem, der skriver de længste prompts. De vil kunne omsætte en forretningsproces til tilstand, evidens, autoritet og beslutningsregler.
Det kræver flere konkrete evner:
- at designe skemaer for opgavetilstand og kildeangivelse;
- at skrive hentepolitikker og metadatafiltre;
- at bygge rutiner til komprimering og udvælgelse af observationer;
- at adskille betroede instruktioner fra indhold, der ikke er betroet;
- profilering af tokenforbrug, latenstid, gentagelser og værktøjskald;
- test af tab af tilstand og gendannelse;
- forklaring til ikke-specialister af, hvorfor en agent så – eller ikke så – en bestemt kendsgerning.
Et stærkt porteføljeprojekt kunne demonstrere den samme agent under tre kontekstpolitikker: fuld transskription, løbende opsummering og struktureret tilstand af antagelser med målrettet hentning. Vis tilfælde, hvor opgaven lykkes, tilfælde, hvor den mislykkes, den kontekst, der sendes ved hvert trin, samt afvejningerne mellem omkostninger og latenstid. Det er mere overbevisende end en chatbotdemo, fordi det synliggør de designbeslutninger, der gør en agent pålidelig.
Den strategiske læring er enkel: Agenter bliver ikke sammenhængende, blot fordi modellerne bliver mere kapable. De bliver sammenhængende, når deres omkringliggende systemer vedligeholder en disciplineret, aktuel og passende afgrænset redegørelse for arbejdet. Kontekstteknik er kunsten at opbygge denne redegørelse – og at vide, hvad der skal udelades.
Priya Raman er den ansvarlige menneskelige redaktør af AI Career Brief.
