2025-10-05 · Bijgewerkt 2026-07-15

[!NOTE] Automatische vertaling Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.

Context Engineering voor AI Agents: Context Windows, Geheugen, Hulpmiddelen en Guardrails

Context engineering is de pipeline die bepaalt wat een model voor elke beslissing ziet: instructies, voorbeelden, kennis, geheugen, definities van hulpmiddelen, observaties en guardrails. Een agent reageert niet op alles wat het systeem kent, maar alleen op het werkgeheugen dat is samengesteld voor de volgende model oproep.

Het is bij die selectie dat veel fouten ontstaan. Een verouderde voorkeur wordt als actueel beschouwd. De opgehaalde tekst bevat een instructie. Een lange tool result verbergt de niet-nagekomen voorwaarde. Een samenvatting onthoudt de genomen beslissing, maar vergeet welk bestand is gewijzigd.

De praktische taak bestaat erin voor elke beslissing het kleinste, maar nog steeds functionele werkset samen te stellen, waarbij rekening wordt gehouden met het bereik, de oorsprong en de toegangsrechten. In dit artikel worden de patronen die ik gebruik besproken, evenals de beperkingen die ervoor zorgen dat deze patronen betrouwbaar blijven.

TL;DR. Beschouw de context als een getypt artefact met duidelijke herkomstinformatie, namelijk runtime. Selecteer dit artefact stap voor stap, stel zowel het tenant- als het toestemmingsschema vast vóór retrieval, scheidt betrouwbare instructies van onbetrouwbare gegevens, bepaal de benodigde resources op basis van de nuttigheid, valideer acties buiten het kader van model, en evalueer de resultaten van de taak in plaats van alleen de lengte van de context.

Context is een invoer voor besluitvorming, geen geheugen

De context window omvat de huidige invoer van de model gecombineerd met de gegenereerde tokens. Hierin kunnen gesprekswisselingen voorkomen, maar het vormt geen duurzaam geheugensysteem. Long-term memory, documentindexen, databases en opslagplaatsen voor artefacten bevinden zich buiten dit tijdsvenster; een context pipeline bepaalt wat er wordt overgenomen.

De venstergrootte is een capaciteitsbeperking, geen kwaliteitsgarantie. Onderzoek naar lange contexten zoals Verloren in het midden en Ruler Dit laat zien dat de succesratio van retrieval en reasoning kan verschillen afhankelijk van de positie, de taak, model en de lengte van de sequentie. De belangrijkste conclusie is niet dat middelste tokens altijd worden genegeerd, maar dat het toevoegen van op het eerste gezicht relevante tokens toch tot een verslechtering van de prestaties van de taak kan leiden.

Gebruik een contextmanifest voor elke oproep van model:

from datetime import datetime
from typing import Literal

from pydantic import BaseModel


class ContextItem(BaseModel):
    item_id: str
    kind: Literal["instruction", "task_state", "evidence", "memory", "tool"]
    source: str
    trust: Literal["trusted", "untrusted"]
    retrieved_at: datetime | None = None
    version: str | None = None
    token_count: int


class ContextManifest(BaseModel):
    request_id: str
    tenant_id: str
    items: list[ContextItem]
    total_input_tokens: int

Het manifest zorgt ervoor dat een fout reproduceerbaar is. De uitspraak “De model hallucineerde” wordt omgezet in een te testen vraag: welke bewijzen, versie, toegangsrechten en tool schema heeft het daadwerkelijk ontvangen?

Het levenscyclus van de assembleercode

Een betrouwbare pipeline voert deze operaties in de volgende volgorde uit:

1. Verwerk de context van het betrouwbare verzoek. Authenticeer de actor, tenant, taalgebied, tijdstip en de huidige status van de taak buiten model.
2. Kies de volgende beslissing. Een planning-stap, het opzoeken van bewijsmateriaal, de selectie van hulpmiddelen en het uiteindelijke antwoord vereisen een andere context.
3. Haal gegevens binnen het bereik. Pas autorisatie- en tenantfilters toe vóór de semantische rangschikking, en niet nadat documenten in de kandidatenset terechtkomen.
4. Rangschik en beperk het budget. Selecteer elementen op basis van nuttigheid, actualiteit, betrouwbaarheid en diversiteit binnen een vastgesteld budget.
5. Bouw samen met vertrouwensgrenzen. Houd de beleidsregels in de instructiekanalen en citeer de gehaalde inhoud als gegevens. De gehaalde instructies worden geen onderdeel van het systeembeleid.
6. Genereer een gestructureerd voorstel. Beperkte uitvoer kan de ondersteunde syntaxis en vorm voorschrijven; deze kan de waarden echter niet corrigeren.
7. Valideer en voer uit. De applicatiecode controleert autorisatie, bedrijfsregels, argumenten van hulpmiddelen en postcondities.
8. Leg de oorsprong en het resultaat vast. Sla het manifest, de geselecteerde bron-ID’s, tool result-referenties, het validatieresultaat en het eindresultaat van de taak op.

Het levenscyclusmodel is afhankelijk van elke afzonderlijke beslissing. Het hergebruiken van één groot contextbestand voor een hele agent-run genereert verouderde gegevens en zorgt er vervolgens voor dat elke stap toegang heeft tot informatie die hij niet nodig heeft.

Geef elke contextbron één taak

Instructies bepalen duurzaam gedrag

De instructies specificeren de rol, het beleid, het outputcontract en het gedrag bij escalatie. Houd de stabiele inhoud ongewijzigd om prefix caching te verbeteren, maar bevries geen waarden die zich bij runtime veranderen. Een restitutietoetsingsgrens moet worden opgeslagen in een beleidsservice of in een geversioneerd dataverklaar, en mag niet oneindig lang worden gekopieerd naar een prompt.

De instructiehiërarchie vormt een controlegrens, en geen beveiligingsmaatregel sandbox. Een model kan nog steeds na kwaadaardige tekst in een opgehaald document voorkomen. Demarkeer onbetrouwbare inhoud, geef aan dat het om bewijsmateriaal gaat in plaats van om instructies, beperk de beschikbare hulpmiddelen apart en testeer prompt-injectiecases.

Taaktoestandsrecords vastleggen van verplichtingen

Conversatieproza vormt een onbetrouwbare bron van waarheid voor meerstappige werkprocessen. Houd expliciet bij welke fase van het proces actueel is, welke acties al zijn uitgevoerd, welke goedkeuringen nog nodig zijn, naar welke artefacten verwezen wordt en wat de status van de tests is. De model kan deze staat samenvatten ten behoeve van narratief; de applicatiecode bevat echter de definitieve versie.

Voorbeelden tonen beslissingen op randgevallen

Few-shot voorbeelden zijn nuttig wanneer ze een moeilijk te bepalen grens verduidelijken, in plaats van enkel het schema te herhalen. Kies voorbeelden die overeenkomen met de huidige beslissing en inclusief relevante randgevallen. Beoordeel voorbeelden retrieval op dezelfde manier als documenten retrieval: een oppervlakkig vergelijkbaar maar beleidsmatig onverenigbaar voorbeeld kan zelfs erger zijn dan geen voorbeeld.

Kennis levert bewijsmateriaal

Retrieval is geschikt voor verse, privé of citeerbare feiten. Er is geen universeel beste optie. top_k, chunk-grootte, hybride weight, of reranker-cutoffwaarde. Stel de hele configuratie af op basis van vragen waarvoor bewijsmateriaal beschikbaar is.

Een bruikbaar bewijsstuk omvat:

• Identificator van de bron- en stabiele documentatie
• Versie of geldigheidsdatum
• Reikwijdte van de toestemming
• Geciteerde span en locatie
• retrieval en reranking scores voor debuggen

Vraag de model niet om een URL te citeren die hij nooit heeft ontvangen. Log geen volledige privédocumenten alleen maar om problemen bij het selecteren op te lossen.

Geheugenvoorzieningen zorgen voor scopegebonden continuïteit

Geheugen omvat opgehaalde gegevens die te maken hebben met extra risico’s met betrekking tot hun levenscyclus. Elke record vereist, indien van toepassing, een onderwerp, herkomst, doel, toestemming of wettelijke grondslag, een tijdstip van creatie, een vervaldatum of beleid voor herziening, evenals een procedure voor verwijdering.

Vaste regels zoals “voorkeuren blijven 365 dagen geldig” vormen geen portable beleid. De bewaring van gegevens wordt bepaald door de behoeften van het product, de verwachtingen van de gebruiker en de wetgeving. Voordat u geheugenlaadt, controleer eerst:

1. Is het bedoeld voor dit geverifieerde subject en tenant?
2. Is het doel relevant voor deze beslissing?
3. Is het voldoende actueel om te gebruiken?
4. Is de bron autoritair, of is het slechts model-afgeleid?

Behandel de afgeleide herinneringen als hypothesen. Zorg ervoor dat een model-antwoord niet stilletjes wordt omgezet in een permanente feitelijkheid voor de gebruiker.

Toolcontracten onthullen de beschikbare functionaliteiten

In de beschrijvingen van tools moeten de voorwaarden, gevolgen, toestemmingssfeer, invoerschema, uitvoerschema, idempotentie en zinvolle fouten worden uitgelegd. Zelfs een oproep die voldoet aan het schema, kan nog steeds onbevoegd of onveilig zijn.

Na uitvoering moet de uitgebreide, ruwe uitvoer worden vervangen door een getypte observatie die het voor de beslissing relevante resultaat behoudt en een verwijzing naar het volledige artefact bevat:

{
    "tool": "check_api_key_status",
    "status": "revoked",
    "checked_at": "2026-07-15T09:30:00Z",
    "account_id": "A-123",
    "artifact_ref": "toolrun://req-42/step-3"
}

MCP standaardiseert de manier waarop clients tools, bronnen en prompts kunnen ontdekken; het geeft echter geen toestemming voor het gebruik daarvan en garandeert ook niet dat de teruggeleverde inhoud betrouwbaar is. Houd controles op gateways, credentials en beleidsregels buiten de beschrijving van model en het protocol.

Hoe de context verslechtert

Een gebrekkige context leidt niet alleen op één manier tot problemen. De oorspronkelijke versie van deze handleiding scheidde verschillende patronen die nog steeds nuttig zijn tijdens het debuggen:

• Position loss: er is voldoende bewijs aanwezig, maar de model maakt onconsistent gebruik daarvan vanwege zijn positie en de omringende sequentie. Evaluaties op lange contexten tonen aan dat dit varieert afhankelijk van model en de taak; er bestaat geen universele ‘slechte middenpositie’.
• Poisoning: een onjuiste geheugenscore, verouderd document, kwaadaardige instructie of onbetrouwbare toolobservatie komt terecht in het werkgeheugen en beïnvloedt latere beslissingen.
• Distraction: relevante bewijzen concurreren met materiaal dat recent is of semantisch vergelijkbaar is, maar niet nodig is voor de huidige stap.
• Confusion: overlappende instructies, voorbeelden of toolbeschrijvingen zorgen ervoor dat de model meerdere plausibele interpretaties van de taak heeft.
• Clash: twee ogenschijnlijk autoritaire elementen zijn het oneens over een waarde, beleid of volgende actie, en de assembler geeft geen informatie over hun versies of prioriteit.

Deze fouten vereisen andere oplossingen. Een betere rangschikking kan de afleiding verminderen, maar het kan een verouderde bron niet herstellen. Scheiders kunnen helpen om gegevens van instructies te scheiden, maar ze kunnen een tool geen toestemming geven. Een groter context window kan meer conflicterend materiaal bewaren zonder het conflict op te lossen.

Wanneer een uitvoering mislukt, controleer dan het manifest om te bepalen welk patroon is opgetreden, voordat je prompt wijzigt of een nieuwe retrieval fase toevoegt.

Budget per dienst, niet per componentenquotum

Een contextbudget reservert ruimte voor de uitvoer en verdeelt vervolgens de invoer over de huidige beslissing. Begin met het ondersteunde venster van de model, trek daar het maximale uitvoervolume en de protocollencosts van af, en stop de beschikbare opties in wat er overblijft.

Beoordeel kandidaten op basis van kenmerken die uw evaluaties in twijfel kunnen trekken:

utility = relevance × authority × freshness × scope_match
          − redundancy_penalty − injection_risk

De formule is een ontwerp prompt, geen universele wiskunde. In een antwoord gebaseerd op beleid kan autoriteit de semantische gelijkenis bepalen. Tijdens het oplossen van fouten kan een recente foutlog boven algemene documentatie worden geplaatst.

Volgorde is eveneens belangrijk. Houd stabiele, betrouwbare instructies op de eerste plaats wanneer de cache-semantiek van de provider profiteert van een gedeelde prefix. Plaats de huidige taak en beslissing dicht bij het bewijsmateriaal waarnaar deze verwijzen. Vermijd tijdstempels of verzoek-ID’s in stabiele prefixen wanneer deze daar niet nodig zijn.

Comprimeren zonder staat te verliezen

Compressie is verliesgericht, tenzij het originele bestand nog steeds toegankelijk blijft. Optimaliseer tokens per succesvolle taak, en niet tokens per verzoek: een agressieve samenvatting die een her-retrieval vereist of tot een onjuiste tool call leidt, is niet goedkoper.

Gebruik aparte mechanismen voor afzonderlijk materiaal:

• Conversatie: vat beslissingen, onopgeloste vragen en verplichtingen samen.
• Observaties over tools: behoud de getypte bevindingen en referenties naar artefacten; verwijder standaardteksten en herhaalde gegevenspakketten.
• Geraadpleegd bewijsmateriaal: bewaar de bron-ID’s, de ondersteunende spans-gegevens en de geldigheidsdata zodat het systeem deze opnieuw kan ophalen.
• Status van taak: sla de status op op een gestandaardiseerde manier, los van de samenvatting.
• Traject van bestanden of artefacten: houd een expliciete index bij van leesacties, schrijfacties, hashes en testresultaten.

Activeer de compressie op basis van gemeten degradatie of van een budgetdrempel die is vastgesteld voor de model en de taak. Publiceer geen algemene regel als “compresseer bij 70%”, alsof alle models op hetzelfde moment failliet gaan.

Evalueer de compressie met probes die een continuatie vereisen, in plaats van lexicaal overlappen:

• Wat is het huidige doel en de volgende actie?
• Welke bestanden of records zijn veranderd?
• Welke beslissing is afgewezen en waarom?
• Welke bron ondersteunt de huidige claim?
• Welke goedkeuring is nog niet verleend?

Voer dezelfde taak uit met en zonder compressie. Vergelijk de resultaten op succes, onjuiste acties, herhaalde oproepen, latency, en het totale aantal tokens.

Optimaliseer de contextpad

Bij optimalisatie moet het beslissingscontract behouden blijven. Vier technieken uit de oorspronkelijke handleiding zijn nog steeds bruikbaar wanneer ze worden toegepast op een gemeten bottleneck:

Compacte voltooide geschiedenis

Vervang oude gespreksvolgorden door een gestructureerde overdracht waarin beslissingen, onopgeloste vragen, gewijzigde artefacten en de teststatus worden vastgelegd. Zorg ervoor dat het oorspronkelijke transcript of de artefacten nog steeds toegankelijk zijn wanneer deze nodig zijn voor herziening of herstel.

Om uitgebreide observaties te maskeren

Een tool kan pagina’s met loggegevens teruggeven wanneer de volgende stap een status, foutcode en referentie van het artefact nodig heeft. Zorg ervoor dat het ruwe resultaat na validatie wordt omgezet in een getypeerde observatie, en houd de volledige payload buiten prompt. Laat model niet de enige bewijzen van een fout wegvagen.

Bewaar cachebare prefixen

Providers en runtimes kunnen werk hergebruiken wanneer het begin van een verzoek stabiel blijft. Zorg ervoor dat de duurzame instructies en tool schemas in een consistente volgorde worden opgeslagen, en plaatst u tijdstempels, verzoekidentificaties, opgehaalde bewijsmateriaal en de huidige staat in het dynamische suffix. Bevestig eerst de cache-semantiek van de provider voordat u erop bent afgestemd in uw ontwerp.

Partitie op basis van beslissing

Een planner, retriever, toolcaller en stap voor het genereren van het eindantwoord hebben niet per se dezelfde ingangen nodig. Geef elke stap de minimale, betrouwbare instructies, statusinformatie, bewijsmateriaal en benodigde hulpmiddelen. Hierdoor wordt zowel het gebruik van token als de blootstelling van functionaliteiten verminderd, maar alleen evaluaties op taakniveau kunnen aangeven of de indeling noodzakelijke informatie heeft weggenomen.

Beveilig de context-leveringsketen

Contextpoisoning kan optreden via documenten, geheugeninformatie, tool results, vaardigheden of eerdere berichten van de assistent. Het markeren van tekst als “onbetrouwbaar” helpt de model, maar de implementatie moet op architectonisch niveau plaatsvinden.

Gebruik deze grenzen:

1. Geef toestemming voordat retrieval en de uitvoering van het hulpmiddel starten.
2. Scheid de gegevens van de instructiekanalen en markeer externe tekst duidelijk af.
3. Voeg hulpmiddelen per stap en acteur toe aan een allowlist; gebruik standaard geen mogelijkheid voor bijwerkingen.
4. Valideer de resourceidentificatoren in plaats van het model toe te staan om tenantkeys of bestandspaden te genereren.
5. Eis bevestiging voor operationen met grote impact op basis van beleid, en niet op basis van de model-confidentie.
6. Scannen en controleren van uitvoerbare skills of connectors voordat deze worden geïnstalleerd.
7. Voorkom dat geheime informatie en ruwe, gevoelige contextinformatie terechtkomen in logs en long-term memory.

Automatische “reparatie” is alleen geschikt voor wijzigingen die de oorspronkelijke betekenis behouden, zoals het parsen van een bekend datumformaat. Het invullen van ontbrekende argumenten van een hulpprogramma met “redelijke standaardwaarden” kan de werking veranderen. Vraag om verduidelijking of wees het af wanneer de betekenis onzeker is.

Voorbeeld: een ondersteuningsverzoek voor een API-sleutel

Voor de vraag “Waarom werkt mijn API-sleutel niet?”, is de volgende stap het verzamelen van diagnostische bewijsmateriaal – in plaats van het genereren van een definitief antwoord. De assembler kan onder andere bevatten:

• Beleid voor betrouwbare ondersteuning en contract voor reactietijden
• Geauthenticeerde account-ID en abonnementsplan uit de toepassingsstatus
• Huidig doel van het ticket en reeds uitgevoerde acties
• Twee huidige runbooks spans geselecteerd binnen het product-/versiensscope
• Een gespecificeerd geheugen waarin is vastgelegd dat de sleutel drie dagen geleden is aangemaakt, inclusief herkomstinformatie check_api_key_status en search_incidentsmaar niet de hulpmiddelen voor het verwijderen of omschakelen van sleutels.

De model stelt een alleen-lezen statuscontrole voor. De applicatiecode geeft toestemming voor het account, roept het hulpprogramma aan en slaat een getypte observatie op. Een tweede oproep van model ontvangt het relevante runbook spans samen met die observatie. In het eindantwoord wordt verwezen naar de versie van het runbook, wordt de sleutel nooit weergegeven, en wordt rotatie uitsluitend aangeboden als een apart geautoriseerde actie.

Let op wat er buiten blijft: ongerelateerde ticketgeschiedenis, elk ondersteuningsvoorbeeld, ruwe accountdumpbestanden, mutatiehulpmiddelen en gegevens van andere huurders.

Anti-patronen die expliciet getest moeten worden

• Het venster vullen: alle opgehaalde documenten, historie, geheugeninformatie en hulpmiddelen laden, zolang er nog capaciteit beschikbaar is.
• RAG overal: semantische retrieval gebruiken voor waarden die thuishoren in een database, beleidsdienst of geverifieerde applicatiestaat.
• Onbegrenscht geheugen: afgeleide feiten bewaren zonder beperkingen met betrekking tot houdbaarheid, correctie of verwijdering.
• Eén oproep per fase: één prompt vragen om te halen, te redeneren, te autoriseren, te wijzigen en uit te leggen, zonder zichtbare grenzen.
• Schema betekent correctheid: geldige JSON beschouwen als bewijs dat waarden, toestemmingen of bedrijfsbeslissingen geldig zijn.
• Geen evaluatie van componenten: alleen de eindtekst beoordelen, evenals ontbrekende retrieval, contextkeuze of fouten bij hulpmiddelen.

Zet elk anti-patroon om in een tegenvoorbeeld in het evaluatieset. Een richtlijn die nooit door een taak of trace wordt nageleefd, kan gemakkelijk onopgemerkt worden overtreden.

Beoordeel de assembler, niet alleen het antwoord

Maak een vaste taakset aan met bewijslabels, toestemmingsgrenzen, vereiste tool calls, en verboden acties. Voor elke wijziging in de contextbeleid, meet:

Gebruik ablaties om de causale waarde te bepalen: verwijder één voor één het geheugen, reranking, voorbeelden of compressie. Een component die tokens toevoegt zonder de relevante subset te verbeteren, moet standaard niet worden geladen.

Conclusie

Een goed context engineering is selectief en verantwoordelijk. Het vult geen groot bereik op, aangezien er voldoende capaciteit beschikbaar is. Het construeert een stappen-specifiek werkset op basis van betrouwbare instructies, een canonieke taaktoestand, geframeerd bewijsmateriaal, geverifieerde geheugengegevens en toegestane hulpmiddelen.

De duurzame cyclus is eenvoudig: assembleren, manifesteren, voorstellen, valideren, uitvoeren en evalueren. Wanneer een beslissing mislukt, geeft deze cyclus aan of het ontbrekende element betrekking had op bewijs, actualiteit, autoriteit, toestand of beleid—and levert hij een test op voor de volgende aanpassing.

Referenties

• Verloren in het midden — positieafhankelijke gebruik van een lange context Ruler — meertakenbeoordeling van de effectieve contextlengte
• Model Specificatie van het contextprotocol — Protocolconcepten en huidige specificaties Het evalueren van Context Compression voor AI Agents — tokens-per-taak framing en evaluatie op basis van probes Prompt injection-aanvallen en verdedigingen in LLM-geïntegreerde toepassingen — Taxonomie van bedreigingen en verdedigingsmaatregelen