Øjeblikkets ord i den lille verden af ​​AI-agenter er kontekstteknik.

Det ser ud til, at endnu et mærke er opfundet for at sælge noget, vi allerede har gjort. Til dels er det. Men som det ofte sker, fanger etiketten, fordi den giver navn til en ægte smerte.

Smerten er denne: modeller fejler ikke, bare fordi de "ikke tænker". De fejler ofte, fordi vi sender dem på arbejde med det forkerte rum.

Vi giver dem gamle instruktioner. Vi skjuler vigtige filer for ham. Vi giver dem dokumenter, der er for lange og siger ikke, hvad der betyder noget. Vi viser dem logfiler uden prioritet. Vi giver dem ti værktøjer uden at forklare, hvornår de skal bruges. Så bliver vi overraskede, hvis agenten bevæger sig som en person, der er vågnet i en ukendt lejlighed.

Spørgsmålet er den sætning, du siger til den. Konteksten er den verden, du forbereder omkring den.

Fra prompt engineering til kontekst engineering

Hurtig ingeniørarbejde blev ofte tænkt som at skrive. Vælg de rigtige ord, spørg på den rigtige måde, tilføj eksempler, angiv formatet.

Kontekstteknologi er tættere på arkitektur.

Man spørger ikke bare "hvordan formulerer jeg anmodningen?". Den spørger:

• hvilke oplysninger er der egentlig brug for?
• hvad er støj?
• hvad skal genvindes i farten?
• hvad skal huskes?
• hvilke værktøjer skal eksponeres?
• hvilke instruktioner er stabile og hvilke afhænger af opgaven?
• hvordan får jeg agenten til at forstå, hvad der er autoritativt?

Det er en subtil, men enorm ændring. For når du arbejder med agenter, er kontekst ikke en statisk blok. Det ændrer sig ved hvert trin.

Agenten åbner en fil, lærer noget, kører en test, modtager en fejl, opdaterer planen, kalder et værktøj, opdager en afhængighed. For hver omgang skal han beslutte, hvad han skal tage med, og hvad han skal undlade.

Dette er teknik.

Konteksten er ikke en losseplads

Skabeloner med store kontekstvinduer gav os en fristelse: lad os smide alt ind.

Det er forståeligt. Hvis jeg har en million tokens, hvorfor skulle jeg så vælge?

For selv når du kan sætte alt ind, betyder det ikke, at alt hjælper. Støj har faktisk en omkostning. Det koster tokens, det koster opmærksomhed, det koster latency, det koster kvalitet. En model kan gå tabt i irrelevante detaljer ligesom os, når vi åbner tyve faner og ikke længere husker hvorfor.

God kontekst har et hierarki:

1. systeminstruktioner og -politikker;
2. Specifikt mål;
3. nuværende status;
4. relevante data;
5. begrænsninger;
6. tilgængelige værktøjer;
7. spore de beslutninger, der allerede er truffet.

Der er ingen grund til at behandle alt på samme niveau. En brugerkommando er mere værd end en gammel note. En mislykket test er nu mere værd end en æstetisk præference for tre måneder siden. En sikkerhedspolitik er mere værd end en produktionsgenvej.

Kontekstteknologi betyder også at give vægte, ikke kun data.

Hukommelse: husk mindre, husk bedre

Hukommelse hos agenter er et af de mest glatte emner.

Som bruger ønsker du, at agenten skal kende dig. Du vil have ham til at huske tonen, planen, konventionerne, de ting, der allerede er besluttet. Som ingeniør ved du, at enhver vedvarende hukommelse også er en risiko: den kan være forkert, gammel, for personlig, for generisk, ikke verificerbar.

En nyttig hukommelse bør have mindst tre kvaliteter:

• herkomst: hvor kommer disse oplysninger fra?
• dato: hvornår var det sandt?
• formål: hvilken type opgave skal den bruges til?

Uden disse tre ting bliver hukommelsen til overtro.

Jeg kan godt lide at tænke på agentisk hukommelse som en projektmappe, ikke som et magisk sind. Der er midlertidige noter, bekræftede beslutninger, stilpræferencer, tekniske begrænsninger, links til kilder. Nogle ting udløber. Some need to be rewritten. Nogle skal elimineres, fordi agenten har misforstået dem.

A good system must make this maintenance normal. Ikke heroisk.

Retrieval and tools are not the same thing

Når vi taler om kontekst, ender vi ofte med det samme på RAG. Embedding, vector database, chunking, reranking.

Alt sammen nyttigt. Men genfinding er kun én måde at bringe information til modellen. Han er ikke den eneste.

En agent kan få kontekst ved at læse filer, forespørge på en API, ringe til en MCP-server, åbne en browser, køre test, søge i Slack, se på et dashboard, spørge mennesket.

Den interessante del er at beslutte, hvilken rute der skal bruges og hvornår.

Hvis agenten skal besvare et historisk spørgsmål, er det måske nok at hente. Hvis han skal rette en fejl, skal han læse rigtig kode. Hvis han har brug for at forstå, hvorfor en implementering mislykkes, skal han se på nye logfiler. Hvis du skal skrive til en kunde, skal du hente tone, historik og status på billetten. Hvis han skal handle på produktionen, skal han bede om tilladelse.

Context is not a database. Det er en arbejdsgang.

Den gode agent forstår også at ignorere

Et tegn på modenhed hos agenter vil være evnen til at sige: Jeg har ikke brug for denne information.

It seems trivial, but it is very difficult. Many agentic systems accumulate. Hvert værktøjskald tilføjer tekst. Every error remains in the buffer. Each file read adds to the stack. I sidste ende har modellen en meget lang historie og intet kort.

Kompression er nødvendig. Intermediate synthesis is needed. It needs to be structured.

Not "that's all that happened", but:

• Målet er stadig gyldigt;
• aktuelle hypotese;
• filer allerede kontrolleret;
• trufne beslutninger;
• åbne risici;
• næste handling.

Dette gør agenten mindre teatralsk og mere hjælpsom. Ikke fordi han virker klogere, men fordi han arbejder med et ryddeligt skrivebord.

Kontekstudvikling for teams, ikke for prompte kunstnere

Grunden til, at dette emne interesserer mig, er, at det flytter ansvar fra individet til systemet.

I prompt engineering vinder ofte den, der bedst kan tale med modellen. I kontekstteknik vinder det team, der bedst organiserer sit arbejde: dokumentation, konventioner, problemer, logfiler, test, ejerskab, navngivning, kilder.

Et rent depot bliver en bedre kontekst. Et velskrevet nummer bliver bedre brændstof. En opdateret runbook sparer tokens og angst. En klar changelog reducerer hallucinationer.

Det er en god og lidt ubehagelig nyhed. Smukt, fordi det belønner god praksis. Upraktisk, fordi du ikke kan løse alt med en smart prompt.

Agenterne forstærker hygiejnen i det system, de finder.

Hvordan ville jeg anvende det i morgen

Hvis jeg skulle introducere kontekstteknik i et rigtigt projekt, ville jeg tage udgangspunkt i små ting:

• en kort og vedligeholdt projektinstruktionsfil;
• gode eksempler på forventet output;
• en liste over tilgængelige værktøjer og tilfælde, hvor de skal bruges;
• arkitektoniske beslutninger skrevet på en citerbar måde;
• problem med minimum obligatorisk kontekst;
• let at hente logfiler og tests;
• vedvarende hukommelse, der kan ændres af mennesker.

Så ville jeg måle en simpel ting: Hvor mange gange skal agenten bede om afklaring eller går i den forkerte retning?

Hvis det sker ofte, ville jeg ikke tilføje en større model med det samme. Jeg ville se på sammenhængen.

Min læsning

Context engineering er lidt af et oppustet ord, ja. Men konceptet er sundt.

Det minder os om, at en agents intelligens ikke kun er i modellen. Det ligger i omgivelserne, som vi forbereder ham: hvad han ser, hvad han husker, hvad han kan, hvad han har forbud mod, hvilke kilder han genkender som sande.

Den menneskelige del er dette: at forberede konteksten godt er en form for omsorg. Det fortæller agenten, men også holdet: "Jeg vil ikke have, at du gætter, jeg vil have, at du har det, du har brug for."

Mindre magi. Renere værelse. Agenter har lige så meget brug for det, som vi har.

Kilder

• LangChain Blog: The rise of context engineering
• Simon Willison: Context engineering
• Model Context Protocol: Introduction
• Anthropic: Building effective agents
• OpenAI: Nye værktøjer til byggeagenter