Hvordan AI-agenter faktisk implementerer ferdigheter: Komplett sammenligning på tvers av plattformer

Introduksjon

Hvert AI-agentrammeverk står overfor det samme grunnleggende spørsmålet: hvordan gjør du en LLM god til noe spesifikt? Modellen i seg selv har bred generell kunnskap, men når du trenger den til å gjennomføre en kodegjennomgang, distribuere infrastruktur eller navigere i Minecraft — trenger den spesialiserte instruksjoner, verktøytilgang og domenekontekst.

Dette er ferdighetsinjeksjonsproblemet. Og hvert stort rammeverk løser det på forskjellige måter.

Noen plattformer dumper alt inn i systemprompten på forhånd. Andre bruker lat lasting, og avslører bare funksjonalitet når agenten trenger det. Noen få bruker vektordatabaser for å hente relevante ferdigheter basert på semantisk likhet. Forskjellene er ikke akademiske — de påvirker direkte token-kostnader, agentpålitelighet og hvor mange ferdigheter en agent realistisk kan håndtere.

Vi analyserte 11 store AI-agentplattformer for å forstå nøyaktig hvor ferdigheter plasseres i prompten, når de lastes, hva de koster i tokens, og hvordan de overlever når kontekstvinduet fylles opp. Dette er ikke en overfladisk funksjonssammenligning. Vi gravde i kildekode, dokumentasjon og arkitekturdiagrammer for å kartlegge de nøyaktige injeksjonsmekanismene til hver plattform.

Hovedsammenligningstabell

Her er den komplette oversikten før vi dykker inn i detaljene.

Injeksjonsmekanikk: Hvor, når og hvordan

Persistens, token-kostnad og alltid-på-oppførsel

Klar til å vokse bedriften din?

Start din gratis prøveperiode i dag og se resultater i løpet av få dager.

Be om demo Logg inn

Hva «ferdighetsinjeksjon» faktisk betyr

Før vi dykker inn i sammenligningen, la oss definere problemområdet. En AI-agents kontekstvindu — den totale teksten LLM-en ser ved hvert kall — har en fast størrelse. Hvert token av instruksjon, samtalehistorikk, verktøydefinisjon og hentet data konkurrerer om plass i det vinduet.

En «ferdighet» i agentkonteksten er enhver strukturert pakke med ekspertise som endrer hvordan agenten oppfører seg. Dette kan være:

• Instruksjoner som forteller agenten hvordan den skal tilnærme seg et spesifikt domene (retningslinjer for kodegjennomgang, distribusjonsjekklister)
• Verktøydefinisjoner som gir agenten kallbare funksjoner (API-integrasjoner, filoperasjoner)
• Few-shot-eksempler som viser agenten hva godt resultat ser ut som
• Hentet kunnskap fra vektordatabaser eller eksterne dokumenter

Injeksjonsmekanismen — hvor og når dette innholdet kommer inn i konteksten — bestemmer tre kritiske egenskaper:

1. Token-effektivitet: Hvor mange tokens bruker ferdigheten, og betales den kostnaden selv når ferdigheten ikke trengs?
2. Pålitelighet: Vil agenten konsekvent bruke ferdigheten når den er relevant, eller kan den gå glipp av signalet?
3. Skalerbarhet: Hvor mange ferdigheter kan agenten ha tilgang til før kontekstoppblåsning reduserer ytelsen?

Hvert rammeverk gjør forskjellige avveininger på tvers av disse tre dimensjonene. La oss undersøke hver enkelt.

Injeksjonsspekteret: Fra alltid-på til ved-behov

På tvers av alle 11 plattformer faller tilnærminger til ferdighetsinjeksjon langs et spekter fra «alt lastet på forhånd» til «ingenting lastet før det eksplisitt trengs».

I den ene enden injiserer plattformer som CrewAI, SuperAGI og CAMEL-AI det fullstendige innholdet av hver aktiverte ferdighet i hvert LLM-kall. Agenten har alltid sin komplette ekspertise tilgjengelig. Enkelt, pålitelig, men dyrt i tokens.

I den andre enden bruker Claude Code, LangChain Deep Agents og OpenAIs Responses API progressiv avsløring — agenten ser bare ferdighetsnavn og korte beskrivelser ved oppstart, og fullt innhold lastes ved behov. Effektivt, skalerbart, men krever at agenten gjenkjenner når den trenger en ferdighet.

I midten bruker AutoGen Teachability og Voyager semantisk henting for å injisere bare de mest relevante ferdighetene per tur, noe som skaper et dynamisk, kontekstsensitivt injeksjonsmønster.

Og så finnes det unike tilnærminger: DSPy kompilerer optimaliserte few-shot-eksempler offline og baker dem permanent inn i modulprompter. MetaGPT koder ferdigheter som action-maler som bare aktiveres når en spesifikk rolle går over til en spesifikk handling.

La oss undersøke hver i detalj.

Bli med i vårt nyhetsbrev

Få de siste tipsene, trendene og tilbudene gratis.

E-postadresse

Abonner

Claude Code: Tre-lags progressiv avsløring

Claude Code implementerer en av de mest sofistikerte arkitekturene for ferdighetsinjeksjon, med et tre-lags progressivt avsløringssystem som balanserer bevissthet med token-effektivitet.

Lag 1: Alltid i kontekst

Ved sesjonsstart injiseres navn og beskrivelse for hver tilgjengelige ferdighet i en system-reminder-melding — en metadatablokk som modellen alltid ser. Dette koster omtrent 250 tegn per ferdighet, og bruker omtrent 1 % av kontekstvinduets budsjett for alle ferdighetsbeskrivelser samlet (omtrent 8K tegn som reservebudsjett, overstyrbart via miljøvariabelen SLASH_COMMAND_TOOL_CHAR_BUDGET).

På samme måte vises utsatte verktøy — verktøy der de fulle JSON-skjemaene ikke er lastet ennå — som en navneliste i system-reminder-blokker. Fra og med Claude Code v2.1.69 er selv innebygde systemverktøy som Bash, Read, Edit, Write, Glob og Grep utsatt bak ToolSearch, noe som reduserer systemverktøykonteksten fra omtrent 14-16K tokens til omtrent 968 tokens.

Agenten ser nok til å vite hva som er tilgjengelig uten å betale token-kostnaden for fulle definisjoner.

Lag 2: Ved aktivering

Når en bruker skriver en skråstrekkommando (f.eks. /commit) eller modellen automatisk matcher en ferdighet basert på beskrivelsen, lastes den fullstendige SKILL.md-bodyen som en samtalemelding via Skill-verktøyet. Denne bodyen inneholder de komplette instruksjonene — noen ganger tusenvis av tokens med detaljert veiledning.

Viktig detalj: Shell-forbehandling kjøres først (eventuelle !command-direktiver i ferdighetsfilen kjøres og resultatet erstatter direktivet), og når den er lastet, forblir ferdighetsbodyen i samtalen resten av sesjonen.

Lag 3: Ved behov

Tilleggsressurser — referansedokumenter, skript, ressursfiler — leses bare når modellen eksplisitt bestemmer seg for å bruke Read-verktøyet for å få tilgang til dem. Disse lastes aldri automatisk.

Oppførsel ved kontekstkomprimering

Når samtalen nærmer seg kontekstgrensen og komprimering utløses, gjenvedlegger Claude Code de sist aktiverte ferdighetene med et budsjett på 5K tokens per ferdighet og et maksimum på 25K samlet. De sist aktiverte ferdighetene får prioritet. Eldre ferdigheter kan bli helt fjernet.

Denne tre-lags arkitekturen betyr at en agent med 20+ tilgjengelige ferdigheter betaler en minimal forhåndskostnad, men kan få tilgang til full ekspertise på hvilken som helst av dem innen en enkelt tur.

CrewAI: Full injeksjon i hver oppgaveprompt

CrewAI tar den motsatte tilnærmingen fra progressiv avsløring. Når en ferdighet er aktivert for en agent, injiseres dens fullstendige innhold i hver oppgaveprompt agenten utfører.

Hvordan det fungerer

Ferdigheter i CrewAI er selvstendige kataloger, hver med en SKILL.md-fil som inneholder YAML-frontmatter (navn, beskrivelse, lisens, kompatibilitet, tillatte verktøy) og en markdown-body. Ferdighetssystemet skiller mellom ferdigheter og verktøy: ferdigheter injiserer instruksjoner og kontekst som former hvordan agenten tenker, mens verktøy tilbyr kallbare funksjoner for handlinger.

Under agentinitialisering kaller Agent.set_skills() discover_skills() for å skanne ferdighetskataloger på metadatanivå, deretter activate_skill() for å lese fulle ferdighetsbodyer. Ved oppgavekjøring kaller _finalize_task_prompt() format_skill_context() for hver aktivert ferdighet og legger til alt formatert ferdighetsinnhold i oppgaveprompten.

LLM-en mottar: [systemmelding] + [oppgaveprompt + ALLE ferdighetsbodyer]

Token-implikasjoner

CrewAI har en myk advarsel ved 50 000 tegn per ferdighet, men ingen hard grense. Dokumentasjonen anbefaler å holde ferdigheter fokuserte og konsise fordi store promptinjeksjoner utvanner modellens oppmerksomhet — en reell bekymring gitt forskning på kontekstforråtnelse.

Avveiningen er grei: agenten har alltid full ekspertise tilgjengelig (høy pålitelighet), men token-kostnaden skalerer lineært med antall ferdigheter per oppgave (lav effektivitet). For agenter med 1-2 fokuserte ferdigheter fungerer dette bra. For agenter som trenger brede ferdighetssett, blir det raskt dyrt.

Ingen persistens mellom oppgaver

Hver oppgave får en ny injeksjon. Det er ingen opphopning av ferdighetsinnhold på tvers av oppgaver — noe som faktisk er en fordel, ikke en ulempe. Det betyr at hver oppgave starter med en ren kontekst, og unngår forfallsproblemene som sesjonsbasert persistens kan skape.

LangChain Deep Agents: Agentstyrt lasting via SkillsMiddleware

LangChain Deep Agents implementerer et sofistikert mellomvarebasert ferdighetssystem der agenten selv bestemmer når den skal laste fullt ferdighetsinnhold — en ekte progressiv avsløringmodel der agenten styrer aktiveringen.

De tre nivåene

Nivå 1 (Indeks): SkillsMiddleware analyserer all SKILL.md-frontmatter ved oppstart og injiserer en lettvektsindeks i systemprompten. Denne indeksen inneholder bare navn og beskrivelser, og koster omtrent 278 tokens per ferdighet mot 3 302 tokens for fullt innhold.

Nivå 2 (Fullt innhold): Når agenten fastslår at en ferdighet er relevant, kaller den read_file() på ferdighetens SKILL.md-sti. Dette er et vanlig verktøykall — rammeverket injiserer ikke bodyen; agenten tar en bevisst beslutning om å laste den. Det fullstendige innholdet kommer inn i samtalehistorikken som et verktøyresultat.

Nivå 3 (Dypdykk): Støttematerialer, referansedokumenter og skript åpnes bare når agenten eksplisitt leser dem.

Token-effektivitet i praksis

Med 12 ferdigheter reduserer progressiv avsløring konteksten fra omtrent 30 000 tokens (alt lastet) til omtrent 600 tokens (kun indeks), og utvides til 2 000-5 000 når relevante ferdigheter lastes for en spesifikk oppgave. Det er en potensiell 83-98 % reduksjon i ferdighetsrelatert token-forbruk.

Flere ferdighetskilder kan lagdeles, og når navn kolliderer, vinner den siste kilden. Filer over 10 MB hoppes automatisk over.

Hovedforskjellen fra Claude Code

Mens Claude Code bruker et dedikert Skill-verktøy for å utløse lasting, gjenbruker Deep Agents agentens eksisterende read_file-verktøy. Dette betyr at lastemekanismen er transparent — agenten leser ferdighetsfiler på samme måte som den leser andre filer. Ulempen er at det ikke finnes noen spesiell komprimeringsoppførsel: ferdighetsinnhold som kommer inn i samtalehistorikken er underlagt standard LangChain-meldingstrimming, uten prioritert behandling.

OpenAI Responses API og Agents SDK: Plattformstyrt utsatt lasting

OpenAI implementerer ferdighetsinjeksjon gjennom to distinkte, men filosofisk samstemte mekanismer: Responses APIs tool_search-verktøytype og Agents SDKs ToolSearchTool.

Responses API: tool_search

tool_search-verktøytypen (tilgjengelig på GPT-5.4+) lar utviklere utsette store verktøyoverflater til kjøretid. Tre utsettelsesstrategier er tilgjengelige:

• Individuell funksjonsutsetning: @function_tool(defer_loading=True) — modellen ser funksjonsnavnet og beskrivelsen, men parameterskjemaet er utsatt. Sparer tokens på parameternivå.
• Navneromsutsetning: tool_namespace(name=..., description=..., tools=[...]) — grupperer funksjoner under et enkelt navnerom. Modellen ser bare navneromnavnet og beskrivelsen, noe som sparer betydelig flere tokens.
• MCP-serverutsetning: HostedMCPTool(tool_config={..., "defer_loading": True}) — utsetter hele MCP-serververktøyoverflater.

Når modellen fastslår at den trenger et spesifikt verktøy, sender den et tool_search-kall. API-et returnerer 3-5 relevante verktøydefinisjoner, injisert på slutten av kontekstvinduet for å bevare prompt-caching.

Agents SDK: ToolSearchTool

Agents SDK gir en programmatisk ekvivalent. Verktøynavnerom registreres men lastes ikke:

crm_tools = tool_namespace(
    name="crm",
    description="CRM management tools",
    tools=[...]
)
agent = Agent(tools=[*crm_tools, ToolSearchTool()])

Ved kjøretid ser agenten bare navneromnavn. Den kaller ToolSearchTool("crm") for å oppdage og laste de fulle skjemaene, og kan deretter kalle individuelle verktøy innenfor det navnerommet.

Ingen persistens mellom forespørsler

Hver API-forespørsel er uavhengig. Oppdagede verktøy vedvarer ikke mellom kall. Dette er den mest tilstandsløse tilnærmingen i vår sammenligning — ren, forutsigbar, men krever gjenoppdagelse ved hver forespørsel hvis verktøy endres.

AutoGen Teachability: Semantisk henting per tur

AutoGen sitt Teachability-funksjon tar en fundamentalt annerledes tilnærming fra alle andre rammeverk i denne sammenligningen. I stedet for å injisere statisk ferdighetsinnhold, henter den dynamisk relevante «notater» fra en ChromaDB-vektordatabase ved hver eneste tur.

Hentesløyfen per tur

Teachability registrerer en hook på process_last_received_message som avskjærer hver innkommende brukermelding før agenten behandler den:

1. En TextAnalyzerAgent trekker ut nøkkelkonsepter fra den innkommende meldingen
2. Disse konseptene brukes til å spørre ChromaDB (bruker Sentence Transformer-embeddinger som standard)
3. De topp-K mest relevante notatene hentes (konfigurerbart via max_num_retrievals, standard 10)
4. Hentede notater legges til meldingsteksten før agenten ser den

Viktig: den modifiserte meldingen spres ikke inn i lagret samtalehistorikk — bare den opprinnelige meldingen lagres. Dette forhindrer at notatinnhold akkumuleres på tvers av turer.

Læringssløyfe

Etter at LLM-en svarer, analyserer en sekundær hook responsen for ny kunnskap:

1. TextAnalyzerAgent identifiserer ny kunnskap i responsen
2. Nye notater trekkes ut som nøkkelverdi-par (inndatatekst → utdatatekst)
3. Disse notatene lagres i ChromaDB, tilgjengelige for fremtidige turer og sesjoner

Dette skaper en genuin læringssløyfe der agenten akkumulerer ekspertise over tid.

Persistens mellom sesjoner

AutoGen Teachability er en av bare tre plattformer i vår sammenligning (sammen med Voyager og DSPy) som bevarer ferdigheter mellom sesjoner. ChromaDB-databasen lever på disk, noe som betyr at en agent kan lære fra interaksjoner på mandag og anvende den kunnskapen på fredag.

recall_threshold-parameteren (standard 1.5) styrer hvor lik en melding må være til et lagret notat for henting, og reset_db kan tømme hele minnet ved behov.

Token-effektivitet

Siden bare relevante notater injiseres per tur (typisk 3-5), er token-kostnaden naturlig avgrenset uansett hvor stor notatdatabasen vokser. En agent med 10 000 lagrede notater betaler fortsatt bare for den håndfull som er mest relevant for den aktuelle turen.

Semantic Kernel: Plugin-skjemaer som alltid-tilstedeværende verktøydefinisjoner

Microsofts Semantic Kernel tar en grei tilnærming: plugins er samlinger av KernelFunction-objekter registrert med Kernel, og skjemaene deres eksponeres til LLM-en som funksjonskall-verktøydefinisjoner.

To injeksjonsstier

Funksjonskall: Når ToolCallBehavior.AutoInvokeKernelFunctions er satt, sendes alle registrerte funksjoner til LLM-en som tilgjengelige verktøy i hver API-forespørsel. LLM-en bestemmer hvilke som skal kalles; Semantic Kernel håndterer aktivering og resultatruting.

Promptmaler: Semantic Kernels malsyntaks ({{plugin.function}}, Handlebars eller Liquid) lar funksjoner kalles inline under promptrendering. Resultater bygges direkte inn i promptteksten før den når LLM-en — en form for ivrig evaluering i stedet for lat verktøykalling.

Ingen progressiv avsløring

Hver registrert plugins skjema inkluderes i hvert API-kall. Det finnes ingen innebygd utsatt lasting, navneromgruppering eller aktivering ved behov. Dokumentasjonen anbefaler eksplisitt å bare importere pluginene som trengs for et spesifikt scenario for å redusere token-forbruk og feilkall.

Dette gjør Semantic Kernel til en av de mest forutsigbare plattformene — du vet alltid nøyaktig hva agenten har tilgang til — men det begrenser skalerbarheten. En agent med 50 registrerte funksjoner betaler den fulle skjemakostnaden ved hvert eneste kall.

Persistens

Plugin-registrering er per kjerneinstans og i minnet. Det finnes ingen innebygd mekanisme for ferdighetspers istens mellom sesjoner.

MetaGPT: Action-maler innenfor rollebaserte SOPer

MetaGPT koder ferdigheter ikke som frittstående pakker, men som action-maler innebygd i Standard Operating Procedures (SOPer) som styrer rolleoppførsel.

Rolle- og action-arkitektur

Hver Role i MetaGPT har et personaprefiks som injiseres i prompter og et sett med Action-klasser. Hver Action inneholder en LLM-proxy som aktiveres via aask(), som bruker naturlige språk-promptmaler for å strukturere LLM-kallet.

Når Role._act() utløses, støtter den tre react-moduser:

• "react": LLM-en velger dynamisk handlinger i tenk-handle-sløyfer
• "by_order": Handlinger utføres sekvensielt i en forhåndsbestemt rekkefølge
• "plan_and_act": Agenten planlegger først, deretter utfører handlinger i henhold til planen

Smalt injeksjonsvindu

Bare den gjeldende Actions promptmal er aktiv på et gitt tidspunkt. Agenten ser ikke maler for andre handlinger — den ser bare sitt rolleprefiks pluss den spesifikke handlingens kontekst. Dette er det smaleste injeksjonsvinduet av noe rammeverk vi undersøkte.

Kontekstanalysefunksjoner i Action-klasser trekker ut relevant informasjon fra inndata, slik at hver handling mottar en kuratert delmengde av tilgjengelig kontekst i stedet for den fulle samtalehistorikken.

Persistens for enkelttur

Malen rendres på nytt for hver handlingskjøring. Det er ingen opphopning eller persistens mellom sesjoner. Dette holder hver handling fokusert, men betyr at agenten ikke kan bygge videre på tidligere lastet ferdighetsinnhold innenfor en enkelt arbeidsflyt.

Voyager: Embedding-basert ferdighetshenting for livslang læring

Voyager, Minecraft-utforskningsagenten fra NVIDIA og Caltech, implementerer en av de mest elegante arkitekturene for ferdighetsinjeksjon: et voksende bibliotek av verifiserte programmer hentet ved embedding-likhet.

Ferdighetsbiblioteket

Når Voyager skriver kode som passerer selvverifisering (den genererte Mineflayer-JavaScripten faktisk fungerer i spillet), lagres koden og dokumentasjonsstrengen i en vektordatabase. Embedding-en av dokumentasjonsstrengen blir hentenøkkelen.

Henting per oppgave

Ved hver ny oppgave foreslått av den automatiske læreplanen:

1. Oppgavebeskrivelsen og miljøtilbakemeldingen embeddes
2. Cosine-likhetssøk mot alle lagrede ferdighets-embeddinger
3. De 5 mest relevante ferdighetene hentes
4. Hentet ferdighetskode inkluderes i handlingsagentens prompt som few-shot-eksempler

Prompten ser slik ut:

You are a Minecraft bot. Here are some relevant skills you've learned:

// Skill: mineWoodLog
async function mineWoodLog(bot) { ... }

// Skill: craftPlanks
async function craftPlanks(bot) { ... }

Now write code to: build a wooden pickaxe

Den genererte koden kan kalle hentede ferdigheter ved navn, noe som muliggjør komposisjonell ferdighetsbygging — komplekse oppførsler konstruert fra enklere, verifiserte primitiver.

Livslang persistens

Ferdighetsbiblioteket er kjernen i «livslang læring»-mekanismen. Det vokser gjennom hele agentens levetid, og nye ferdigheter bygger på gamle. I motsetning til de fleste rammeverk der ferdigheter er forfattet av mennesker, genereres, verifiseres og lagres Voyagers ferdigheter av agenten selv.

Token-kostnaden er naturlig avgrenset: uansett om biblioteket inneholder 50 eller 5 000 ferdigheter, betaler hver oppgave bare for de 5 mest relevante hentingene.

DSPy: Kompilerte few-shot-eksempler som frosne ferdigheter

DSPy tar en radikalt annerledes tilnærming fra alle andre rammeverk. I stedet for å injisere ferdigheter ved kjøretid, kompilerer DSPy optimale few-shot-demonstrasjoner offline og baker dem permanent inn i modulprompter.

Kompileringsprosessen

To hovedoptimalizatorer håndterer kompilering:

BootstrapFewShot: Bruker en lærermodul for å generere traces gjennom programmet. Traces som passerer en brukerdefinert metrikk beholdes som demonstrasjoner. Hver dspy.Predict-modul i programmet får sitt eget kuraterte sett med demonstrasjoner.

MIPROv2 (Multi-prompt Instruction Proposal Optimizer v2): En tre-fase prosess:

1. Bootstrap: Generer kandidatdemonstrasjonssett
2. Propose: Generer kandidatinstruksjonstekster som er bevisst på både datadistribusjonen og demonstrasjonene
3. Search: Bayesiansk optimalisering over det kombinerte rommet av instruksjoner x demonstrasjoner på tvers av alle moduler

Parametere som max_bootstrapped_demos (genererte eksempler) og max_labeled_demos (fra treningsdata) styrer hvor mange eksempler som ender opp i hver moduls prompt.

Fast etter kompilering

Når de er kompilert, lagres demonstrasjoner i hver Predict-moduls demos-attributt og formateres inn i prompten ved hvert LLM-kall. De endres ikke ved kjøretid — «ferdigheten» er frosset.

Dette betyr at DSPy-ferdigheter er de mest forutsigbare i vår sammenligning: token-kostnaden er kjent etter kompilering, det er ingen variasjon mellom turer, og agenten ser alltid de samme demonstrasjonene. Ulempen er manglende fleksibilitet — for å endre ferdigheter må du rekompilere.

Persistens

Kompilerte programmer serialiseres til JSON, inkludert alle demonstrasjoner. De er fullt persistente og lastbare mellom sesjoner, noe som gjør DSPy til en av de mest holdbare ferdighetslagringsmekanismene.

SuperAGI: Verktøysettbasert forhåndsregistrering

SuperAGI bruker et tradisjonelt verktøysettmønster der alle verktøy registreres ved agentinitialisering.

Hvert verktøysett utvider BaseToolkit med:

• name- og description-attributter
• get_tools()-metode som returnerer en liste med BaseTool-instanser
• get_env_keys() for nødvendige miljøvariabler

Verktøysett installeres fra GitHub-repositorier via SuperAGIs verktøybehandler. Ved agentinitialisering returnerer BaseToolkit.get_tools() alle verktøy, og deres komplette skjemaer eksponeres til LLM-en som funksjonskall-definisjoner.

Det finnes ingen utsatt lasting, ingen progressiv avsløring og ingen filtrering per tur. Hvert registrert verktøys skjema er til stede i hvert kall. Dette er den enkleste injeksjonsmodellen og fungerer godt for agenter med fokuserte, små verktøysett, men skalerer ikke til agenter som trenger dusinvis av funksjoner.

CAMEL-AI: ChatAgent-verktøyregistrering

CAMEL-AI følger et lignende forhåndsregistreringsmønster. Verktøy fra ulike verktøysett (f.eks. MathToolkit, SearchToolkit) sendes som en liste til ChatAgent(tools=[...]) ved initialisering.

Rammeverket understreker at egendefinerte funksjoner trenger tydelige argumentnavn og omfattende docstrings slik at modellen kan forstå bruken — verktøyskjemaet er det eneste «ferdighetsinnholdet» modellen ser. Det finnes ingen separat instruksjonsinjeksjonsmekanisme.

Nylige tillegg inkluderer MCP-støtte (Model Context Protocol) via MCPToolkit, som lar ChatAgent koble til MCP-servere og registrere eksterne verktøy. Dette utvider den tilgjengelige verktøyoverflaten, men endrer ikke injeksjonsmodellen — alle oppdagede MCP-verktøy registreres fortsatt på forhånd.

Sammenligning på tvers av plattformer

Når ferdigheter injiseres

Persistensmodeller

Overlevelse ved kontekstkomprimering

Mønsteret for progressiv avsløring

Den mest betydningsfulle arkitektoniske trenden på tvers av disse plattformene er adopsjonen av progressiv avsløring — et konsept hentet fra UI-design der informasjon avsløres gradvis basert på behov.

Hvorfor progressiv avsløring er viktig

En naiv tilnærming til ferdighetsinjeksjon — å laste alt på forhånd — skaper to problemer:

1. Token-sløsing: De fleste ferdigheter er ikke relevante for de fleste turer. Å laste 20 fulle ferdighetsbodyer når bare 1-2 trengs per tur sløser bort 90 %+ av ferdighetsrelaterte tokens.
2. Oppmerksomhetsutvanningen: Forskning på kontekstforråtnelse viser at LLM-er presterer dårligere når konteksten inneholder store mengder irrelevant informasjon. Flere ferdigheter i konteksten kan faktisk redusere kvaliteten på ferdighetsanvendelsen.

Progressiv avsløring løser begge problemene ved å opprettholde en lettvektsindeks over tilgjengelige ferdigheter mens fullt innhold bare lastes når det trengs.

Implementasjonsvariasjoner

Claude Code bruker et dedikert system: ferdighetsmetadata i system-reminder-meldinger, et Skill-verktøy for aktivering og ToolSearch for utsatte verktøyskjemaer. Rammeverket styrer injeksjon automatisk med prioritetsbasert komprimering.

LangChain Deep Agents bruker agentens eksisterende fillesefunksjon: SkillsMiddleware injiserer indeksen, og agenten laster fullt innhold via read_file(). Dette er mer transparent, men tilbyr mindre rammeverknivå-optimalisering.

OpenAI Responses API bruker navnerombasert gruppering med plattformstyrt søk: verktøynavnerom gir overordnede beskrivelser, og tool_search returnerer relevante skjemaer. Plattformen håndterer søkelogikken i sin helhet.

Token-besparelser i praksis

Tallene er overbevisende. Med 12 ferdigheter:

• Alltid-på-injeksjon (CrewAI/SuperAGI-stil): ~30 000 tokens
• Progressiv avsløring kun indeks: ~600 tokens
• Indeks + 2 aktiverte ferdigheter: ~2 000-5 000 tokens

Det er en 83-98 % reduksjon i ferdighetsrelatert token-forbruk per tur. Over en lang sesjon med hundrevis av turer akkumuleres besparelsene dramatisk.

Arkitektoniske mønstre og avveininger

Når vi ser på alle 11 plattformer, fremkommer fire distinkte arkitektoniske mønstre:

Mønster 1: Alltid-på-injeksjon

Brukt av: CrewAI, SuperAGI, CAMEL-AI, Semantic Kernel

Hvordan det fungerer: Fullt ferdighetsinnhold eller verktøyskjemaer er til stede i hvert LLM-kall.

Fordeler:

• Maksimal pålitelighet — agenten har alltid full ekspertise tilgjengelig
• Enkleste implementering — ingen aktiveringslogikk nødvendig
• Forutsigbare token-kostnader — det samme hver tur

Ulemper:

• Token-kostnaden skalerer lineært med antall ferdigheter
• Oppmerksomhetsutvanningen med mange ferdigheter
• Skalerer ikke utover ~5-10 ferdigheter per agent

Best for: Fokuserte agenter med 1-3 kjerneferdigheter som alltid er relevante.

Mønster 2: Progressiv avsløring

Brukt av: Claude Code, LangChain Deep Agents, OpenAI Responses API/Agents SDK

Hvordan det fungerer: Lettvekts-metadata alltid til stede; fullt innhold lastet ved behov.

Fordeler:

• Skalerer til dusinvis eller hundrevis av tilgjengelige ferdigheter
• Minimal token-kostnad når ferdigheter ikke trengs
• Bevarer prompt-cache når fulle skjemaer legges til på slutten

Ulemper:

• Agenten kan gå glipp av signalet om å aktivere en relevant ferdighet
• Ekstra latenstid fra aktiveringsstegget
• Mer kompleks rammeverkimplementering

Best for: Generelle agenter som trenger tilgang til mange funksjoner, men bare bruker noen få per oppgave.

Mønster 3: Semantisk henting

Brukt av: AutoGen Teachability, Voyager

Hvordan det fungerer: Vektordatabasespørringer henter relevante ferdigheter/kunnskap basert på semantisk likhet med den aktuelle konteksten.

Fordeler:

• Naturlig avgrenset token-kostnad uansett biblioteksstørrelse
• Innholdsrelevansen forbedres over tid etter hvert som biblioteket vokser
• Læring og akkumulering mellom sesjoner
• Ingen eksplisitt aktivering nødvendig — relevans beregnes automatisk

Ulemper:

• Hentekvaliteten avhenger av kvaliteten på embedding-modellen
• Risiko for å hente utdatert eller subtilt feil informasjon
• Krever vektordatabaseinfrastruktur
• Mindre forutsigbar — forskjellige turer laster forskjellig innhold

Best for: Agenter som lærer av erfaring og trenger å akkumulere domenekunnskap over tid.

Mønster 4: Kompilert/statisk injeksjon

Brukt av: DSPy, MetaGPT

Hvordan det fungerer: Ferdigheter kompileres til fast promptinnhold (DSPy) eller aktiveres gjennom rigide action-maler (MetaGPT).

Fordeler:

• Mest forutsigbar oppførsel — samme innhold hver gang
• Optimalisering kan gjøres offline (DSPys kompilering)
• Ingen kjøretidsoverhead for ferdighetsvalg
• Bevist effektivt for veldefinerte, repeterbare oppgaver

Ulemper:

• Ufleksibelt — å endre ferdigheter krever rekompilering (DSPy) eller kodeendringer (MetaGPT)
• Kan ikke tilpasse seg nye situasjoner utenfor de kompilerte eksemplene
• DSPys kompileringsprosess krever i seg selv mange LLM-kall

Best for: Produksjonspipeliner med veldefinerte oppgaver der pålitelighet trumfer fleksibilitet.

Praktiske implikasjoner for agentbyggere

Å velge riktig mønster

Riktig arkitektur for ferdighetsinjeksjon avhenger av agentens profil:

Hvis agenten din har en smal, veldefinert rolle (f.eks. en kodegjennomgangsbot, en kundestøtteagent for ett produkt), er alltid-på-injeksjon (CrewAI/SuperAGI-mønsteret) enklest og mest pålitelig. Token-kostnaden for 2-3 alltid-tilstedeværende ferdigheter er håndterbar, og du unngår kompleksiteten med aktiveringslogikk.

Hvis agenten din trenger brede funksjoner, men bare bruker noen få per interaksjon (f.eks. en utviklerassistent, en generell automasjonsagent), er progressiv avsløring (Claude Code/Deep Agents-mønsteret) den klare vinneren. Token-besparelsene på 83-98 % i skala er for betydelige til å ignorere.

Hvis agenten din trenger å lære og forbedre seg fra interaksjoner (f.eks. en personlig assistent, en domeneekspert som akkumulerer kunnskap), gir semantisk henting (AutoGen Teachability-mønsteret) læringssløyfen som andre mønstre mangler. Bare sørg for at du har kvalitetskontroller på hva som legges inn i kunnskapsbasen.

Hvis agenten din kjører veldefinerte pipeliner (f.eks. databehandling, rapportgenerering, standardiserte arbeidsflyter), gir kompilert injeksjon (DSPy-mønsteret) deg den mest forutsigbare, optimaliserte oppførselen.

Hybridtilnærmingen

For produksjonsagentteam der agenter trenger å fungere rett ut av boksen, anbefaler vi en hybrid tilnærming:

Kjerneferdigheter (1-2 per agent, som definerer deres primære domeneekspertise): alltid injisert i systemprompten, CrewAI-stil. Dette er ikke-forhandlingsbare funksjoner agenten trenger ved hver tur.

Utvidede ferdigheter (tilleggsfunksjoner agenten kan trenge): kun metadata i systemprompten, lastet via en søk/last-mekanisme ved behov, Deep Agents-stil. Disse utvider agentens funksjonssett uten å betale token-kostnaden når de ikke er relevante.

Lært kunnskap (akkumulert domeneekspertise): lagret i en vektordatabase og hentet semantisk per tur, AutoGen-stil. Dette lar agenten forbedre seg over tid uten manuell ferdighetsforfatting.

Denne lagdelte arkitekturen kartlegger naturlig til hvordan en systemprompt bygges: dato → persona → systeminstruksjoner → kjerneferdigheter → ferdighetsindeks → rolle/teamkontekst. Kjerneferdighetene og indeksen legger til en forutsigbar, håndterbar token-kostnad, mens de fulle ferdighetsene bare dukker opp når de trengs.

Beste praksis for token-budsjett på tvers av rammeverk

Uansett hvilket injeksjonsmønster du bruker, gjelder disse strategiene for token-håndtering universelt:

Cache-vennlig rekkefølge

Plasser uforanderlig kontekst (systeminstruksjoner, verktøyskjemaer) foran i prompten. Hos leverandører som støtter prompt-caching, koster cachede tokens 75 % mindre. Claude Code og OpenAI injiserer begge oppdagede verktøyskjemaer på slutten av konteksten spesielt for å bevare cache-treff på det statiske prefikset.

Avlastning

Oppsummer verktøyresponser i stedet for å beholde fulle resultater i konteksten. Lagre de komplette dataene i eksterne referanser som agenten kan lese ved behov. Dette er spesielt viktig for agenter som gjør mange verktøykall per sesjon.

Reduksjon

Komprimer samtalehistorikk gjennom oppsummering. Trekk ut nøkkelfakta fra lange utvekslinger til komprimerte representasjoner. Hvert rammeverk med sesjonsbasert persistens drar nytte av aggressiv historikkhåndtering.

Henting fremfor forhåndslasting

Hent relevant informasjon dynamisk ved kjøretid i stedet for å laste alt på forhånd. Dette gjelder ferdigheter, kunnskapsbaser og til og med samtalehistorikk. Studier viser at dette kan redusere promptstørrelser med opptil 70 %.

Isolering

Bruk underagenter for spesifikke oppgaver slik at hver agents kontekst forblir fokusert. I stedet for å gi én agent 20 ferdigheter, opprett et team på 5 agenter med 4 ferdigheter hver. Hver agent opprettholder et slankt kontekstvindu, og teamet dekker kollektivt det fulle funksjonsettet.

Konklusjon

Måten AI-agentrammeverk injiserer ferdigheter i konteksten på er en av de mest konsekvensrike arkitekturbeslutningene i agentdesign — likevel diskuteres det sjelden på dette detaljnivået.

Feltet konvergerer tydelig mot progressiv avsløring som det foretrukne mønsteret for generelle agenter, der Claude Code, LangChain Deep Agents og OpenAI alle uavhengig har kommet frem til lignende tre-nivås arkitekturer. I mellomtiden tjener spesialiserte mønstre som semantisk henting (AutoGen, Voyager) og kompilert injeksjon (DSPy) viktige nisjer som progressiv avsløring alene ikke dekker.

For praktikere som bygger agentsystemer i dag, er nøkkelinnsikten at ferdighetsinjeksjon ikke er en enhetsstørrelse-passer-alle-problemstilling. Riktig tilnærming avhenger av agentens rolle, antall ferdigheter den trenger, om den trenger å lære over tid, og din toleranse for avveininger mellom token-kostnader og pålitelighet.

De mest robuste produksjonssystemene vil sannsynligvis kombinere flere mønstre — alltid-på for kjernefunksjoner, progressiv avsløring for utvidede ferdigheter, og semantisk henting for akkumulert kunnskap — og skape agenter som er både effektive og eksperter.