Lägga till kontextprovidrar

Föregående sida visade hur mellanprogram omsluter agentens körningspipeline med övergripande problem – loggning, skyddsräcken, felhantering – utan att röra agentens kärnlogik. Men mellanprogram handlar om hur agenten körs, inte vad agenten vet. Hittills kommer agentens kunskaper från två platser: dess träningsdata och vad användaren än säger i den aktuella turordningen.

Det är ett problem. En användbar agent behöver mer än så. Den måste komma ihåg vad användaren sa för tre varv sedan, känna till användarens inställningar eller hämta relevanta fakta från en kunskapsbas – allt innan det börjar generera ett svar. Verktyg kan hämta information, men de är reaktiva: modellen måste bestämma sig för att anropa dem. Om modellen inte inser att den behöver kontext kommer den inte att be om det.

Kontextprovidrar löser detta. Det är komponenter som körs före och efter varje agentanrop, som proaktivt matar in relevant information i kontextfönstret och eventuellt extraherar tillstånd från svaret som ska lagras för framtida användning. De ger din agent minne, anpassning och åtkomst till extern kunskap – utan att ändra agentens instruktioner eller kod.

När du ska använda detta

Lägg till kontextprovidrar till din agent när:

  • Agenten behöver konversationshistorik – den bör komma ihåg vad som sades i tidigare svängar, inte bara det aktuella meddelandet.
  • Du vill mata in användarspecifika data – profiler, inställningar, kontoinformation eller sessionstillstånd – så att agenten kan anpassa sina svar.
  • Du behöver hämtningsförhöjd generering (RAG) – hämtar automatiskt relevanta dokument eller fakta från en kunskapsbas före varje svar.
  • Agenten kräver dynamiska instruktioner – kontext som ändras mellan anrop baserat på tid på dagen, användarens plats eller andra körningsvillkor.
  • Du vill frikoppla datakällor från agentlogik – agenten behöver inte veta var kontexten kommer ifrån, bara att den är tillgänglig.

Varför inte bara använda verktyg?

Både verktyg och kontextleverantörer ger agenter åtkomst till extern information, men de fungerar på fundamentalt olika sätt:

Aspekt Arbetsredskap Kontextleverantörer
Trigger Reaktiv – modellen bestämmer när ett verktyg ska anropas Proaktiv – körs automatiskt före varje anrop
Kontroll Modelldriven: modellen väljer vilket verktyg, när och med vilka argument Utvecklardriven: du bestämmer vilken kontext som alltid är tillgänglig
Synlighet Modellen måste känna till att ett verktyg finns och bedöma att det är relevant Kontexten matas in transparent – modellen ser den som en del av uppmaningen
Användningsfall Åtgärder och sökningar på begäran: "sök på webben", "fråga databasen" Alltid närvarande kontext: konversationshistorik, användarprofiler, förinlästa kunskaper
Tokenkostnad Token används endast när verktyget anropas Token som spenderas på varje anrop (kontexten finns alltid i prompten)

Ingen av dem är strikt bättre. Många agenter använder båda: kontextprovidrar för information som alltid ska finnas (historik, användarprofil, grundläggande kunskap) och verktyg för information som agenten ska hämta på begäran (live-sökresultat, databasfrågor, API-anrop).

Tips/Råd

En bra tumregel: Om agenten ska ha den här informationen varje gång den körs använder du en kontextprovider. Om agenten bara ska hämta den när det är relevant använder du ett verktyg.

Så här fungerar kontextprovidrar

Kontextprovidrar deltar i en livscykel i två faser runt varje agentanrop:

┌──────────────────────────────────────────────────────────────┐
│  Caller: agent.run("What's the return policy?")              │
└──────────────┬───────────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────────┐
│  BEFORE RUN — each context provider injects context          │
│                                                              │
│  • History provider loads past conversation messages         │
│  • Memory provider retrieves relevant facts/preferences      │
│  • RAG provider searches knowledge base and adds results     │
│  • Custom provider injects user profile, time, location      │
└──────────────┬───────────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────────┐
│  Agent core — model sees original input + all injected       │
│  context and generates a response                            │
└──────────────┬───────────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────────┐
│  AFTER RUN — each context provider processes the response    │
│                                                              │
│  • History provider saves the new messages                   │
│  • Memory provider extracts facts to remember for later      │
│  • Custom provider updates session state                     │
└──────────────────────────────────────────────────────────────┘

Viktiga punkter:

  1. Kontextprovidrar körs automatiskt. Du registrerar dem en gång när du skapar agenten. Därefter deltar de i varje anrop utan extra kod från din sida.
  2. Flera leverantörer kombineras tillsammans. Du kan registrera flera kontextprovidrar – en historikprovider, en RAG-provider och en anpassad provider – och de bidrar alla till samma kontextfönster. Deras bidrag slås samman i registreringsordning.
  3. Leverantörer har två hakpunkter. Innan kroken matar in kontext (meddelanden, instruktioner, verktyg) i prompten. Efter-hook bearbetar svaret – lagrar meddelanden, extraherar minnen eller uppdaterar tillståndet.
  4. Leverantörer är sessionsmedvetna. Kontextprovidrar tar emot den aktuella sessionen så att de kan läsa in och lagra data som är begränsade till en specifik konversation. Se Sessioner för hur sessionshantering fungerar.

Tips/Råd

En detaljerad vy över var kontextprovidrar finns i den fullständiga agentkörningspipelinen – tillsammans med mellanprogram och chattklienten – finns i Arkitektur för agentpipeline.

Hantera kontextfönstret

Varje kontext som du matar in förbrukar token från modellens kontextfönster. Historiken växer med varje tur. RAG-resultat lägger till dokumentsegment. Användarprofiler lägger till metadata. Om summan överskrider modellens gräns trunkeras den äldsta eller minst relevanta informationen , vilket kan leda till att viktig kontext förloras.

Hantering av kontextfönster är en viktig faktor när du använder kontextprovidrar: Komprimeringsstrategier sammanfattar eller trimmar äldre historik för att hålla sig inom tokengränser samtidigt som viktig information bevaras. Se Komprimering.

Tips/Råd

Praktisk erfarenhet av minnes- och kontextprovidrar finns i Steg 4: Minne i självstudien Komma igång.

Viktigt!

Vi rekommenderar inte att du underhåller ett mycket långt kontextfönster eftersom modellens prestanda kan försämras när kontextfönstret växer. Om agenten börjar få sämre prestanda bör du överväga att använda komprimeringsstrategier för att minska kontextstorleken.

Överväganden

Att tänka på Detaljer
Tokenbudget Varje inmatad kontext förbrukar token. Övervaka den totala kontextstorleken noggrant – särskilt när du kombinerar flera leverantörer. Om kontexten växer obehindrat trunkeras viktig information utan varning.
Svarstid för hämtning Kontextprovidrar som frågar efter externa tjänster (databaser, sökindex, API:er) lägger till svarstid för varje anrop. Använd cachelagring, anslutningspooler och asynkrona åtgärder för att hålla hämtningen snabb.
Relevance Att mata in irrelevant kontext slösar inte bara token – det kan aktivt försämra modellens svar genom att späda ut signalen. Se till att dina leverantörer matar in fokuserad, relevant information.
Staleness Cachelagrad eller förladdad data kan bli inaktuell. Utforma leverantörer för att uppdatera data med lämpliga intervall och fundera på om något inaktuell kontext är acceptabel för ditt användningsfall.
Komposbarhet När flera leverantörer bidrar till samma kontextfönster kan deras bidrag interagera på oväntade sätt. Testa leverantörer tillsammans, inte bara individuellt, för att säkerställa att den samlade kontexten är logisk.

Nästa steg

Nu när din agent har verktyg, kunskaper, mellanprogram och kontextproviders är nästa steg agenter som verktyg – att skapa agenter genom att använda en agent som ett verktyg för en annan, vilket möjliggör specialisering och delegering.

Agenter som verktyg

Gå djupare:

  • Last updated on