Hur AI-agenter faktiskt implementerar färdigheter: Komplett jämförelse mellan plattformar

Introduktion

Varje ramverk för AI-agenter står inför samma grundläggande fråga: hur gör man en LLM bra på något specifikt? Modellen i sig har bred allmän kunskap, men när du behöver den för att utföra en kodgranskning, distribuera infrastruktur eller navigera i Minecraft – behöver den specialiserade instruktioner, verktygsåtkomst och domänkontext.

Detta är problemet med färdighetsinjektion. Och varje stort ramverk löser det på olika sätt.

Vissa plattformar dumpar allt i systemprompten direkt. Andra använder lat laddning och avslöjar bara funktioner när agenten behöver dem. Några använder vektordatabaser för att hämta relevanta färdigheter baserat på semantisk likhet. Skillnaderna är inte akademiska – de påverkar direkt tokenkostnader, agenttillförlitlighet och hur många färdigheter en agent realistiskt kan hantera.

Vi analyserade 11 stora AI-agentplattformar för att förstå exakt var färdigheter hamnar i prompten, när de laddas, vad de kostar i tokens och hur de överlever när kontextfönstret fylls upp. Detta är inte en ytlig funktionsjämförelse. Vi grävde i källkod, dokumentation och arkitekturdiagram för att kartlägga de exakta injektionsmekanismerna för varje plattform.

Huvudjämförelsetabell

Här är den kompletta översikten innan vi dyker ner i detaljerna.

Injektionsmekanik: Var, när och hur

Persistens, tokenkostnad och ständigt-på-beteende

Redo att växa ditt företag?

Starta din kostnadsfria provperiod idag och se resultat inom några dagar.

Begär demo Logga in

Vad “färdighetsinjektion” faktiskt betyder

Innan vi dyker ner i jämförelsen, låt oss definiera problemområdet. En AI-agents kontextfönster – den totala texten som LLM:en ser vid varje anrop – har en fast storlek. Varje token av instruktioner, konversationshistorik, verktygsdefinitioner och hämtad data konkurrerar om utrymme i det fönstret.

En “färdighet” i agentsammanhang är vilket strukturerat paket av expertis som helst som förändrar hur agenten beter sig. Detta kan vara:

• Instruktioner som berättar för agenten hur den ska närma sig en specifik domän (riktlinjer för kodgranskning, distributionschecklistor)
• Verktygsdefinitioner som ger agenten anropsbara funktioner (API-integrationer, filoperationer)
• Few-shot-exempel som visar agenten hur bra utdata ser ut
• Hämtad kunskap från vektordatabaser eller externa dokument

Injektionsmekanismen – var och när detta innehåll hamnar i kontexten – bestämmer tre kritiska egenskaper:

1. Tokeneffektivitet: Hur många tokens förbrukar färdigheten, och betalas den kostnaden även när färdigheten inte behövs?
2. Tillförlitlighet: Kommer agenten konsekvent att använda färdigheten när den är relevant, eller kan den missa signalen?
3. Skalbarhet: Hur många färdigheter kan agenten komma åt innan kontextsvällning försämrar prestandan?

Varje ramverk gör olika avvägningar mellan dessa tre dimensioner. Låt oss undersöka var och en.

Injektionsspektrumet: Från ständigt-på till vid-behov

Över alla 11 plattformar faller metoderna för färdighetsinjektion längs ett spektrum från “allt laddat i förväg” till “inget laddat förrän det uttryckligen behövs”.

I ena änden injicerar plattformar som CrewAI, SuperAGI och CAMEL-AI det fullständiga innehållet av varje aktiverad färdighet i varje LLM-anrop. Agenten har alltid sin fullständiga expertis tillgänglig. Enkelt, tillförlitligt, men dyrt i tokens.

I andra änden använder Claude Code, LangChain Deep Agents och OpenAI:s Responses API progressiv avslöjning – agenten ser bara färdighetsnamn och korta beskrivningar vid uppstart, och fullständigt innehåll laddas vid behov. Effektivt, skalbart, men kräver att agenten känner igen när den behöver en färdighet.

I mitten använder AutoGen Teachability och Voyager semantisk hämtning för att bara injicera de mest relevanta färdigheterna per tur, vilket skapar ett dynamiskt, kontextkänsligt injektionsmönster.

Och sedan finns det unika metoder: DSPy kompilerar optimerade few-shot-exempel offline och bakar in dem permanent i modulpromptar. MetaGPT kodar färdigheter som actionmallar som bara aktiveras när en specifik roll övergår till en specifik action.

Låt oss undersöka var och en i detalj.

Gå med i vårt nyhetsbrev

Få de senaste tipsen, trenderna och erbjudandena gratis.

E-postadress

Prenumerera

Claude Code: Trelagersprogressiv avslöjning

Claude Code implementerar en av de mest sofistikerade arkitekturerna för färdighetsinjektion, med ett trelagersystem för progressiv avslöjning som balanserar medvetenhet med tokeneffektivitet.

Lager 1: Alltid i kontexten

Vid sessionsstart injiceras varje tillgänglig färdighets namn och beskrivning i ett system-reminder-meddelande – ett metadatablock som modellen alltid ser. Detta kostar ungefär 250 tecken per färdighet och förbrukar cirka 1 % av kontextfönstrets budget för alla färdighetsbeskrivningar tillsammans (ungefär 8K tecken som reservbudget, överskridbar via miljövariabeln SLASH_COMMAND_TOOL_CHAR_BUDGET).

På liknande sätt visas uppskjutna verktyg – verktyg vars fullständiga JSON-scheman inte har laddats ännu – som en lista med enbart namn i system-reminder-block. Från och med Claude Code v2.1.69 är även inbyggda systemverktyg som Bash, Read, Edit, Write, Glob och Grep uppskjutna bakom ToolSearch, vilket minskar systemverktygskontexten från ungefär 14–16K tokens till ungefär 968 tokens.

Agenten ser tillräckligt för att veta vad som finns tillgängligt utan att betala tokenkostnaden för fullständiga definitioner.

Lager 2: Vid aktivering

När en användare skriver ett snedstreckskommando (t.ex. /commit) eller modellen automatiskt matchar en färdighet baserat på dess beskrivning, laddas den fullständiga SKILL.md-brödtexten som ett konversationsmeddelande via Skill-verktyget. Denna brödtext innehåller de fullständiga instruktionerna – ibland tusentals tokens med detaljerad vägledning.

Viktig detalj: Shell-förbearbetning körs först (alla !command-direktiv i färdighetsfilen exekveras och deras utdata ersätter direktivet), och när brödtexten väl laddats stannar den kvar i konversationen under resten av sessionen.

Lager 3: Vid behov

Ytterligare resurser – referensdokument, skript, tillgångsfiler – läses bara när modellen uttryckligen beslutar att använda Read-verktyget för att komma åt dem. Dessa laddas aldrig automatiskt.

Beteende vid kontextkomprimering

När konversationen närmar sig kontextgränsen och komprimering utlöses, återkopplar Claude Code de senast anropade färdigheterna med en budget på 5K tokens per färdighet och ett kombinerat maximum på 25K. De senast anropade färdigheterna får prioritet. Äldre färdigheter kan tas bort helt.

Denna trelagerarkitektur innebär att en agent med 20+ tillgängliga färdigheter betalar en minimal startkostnad men kan komma åt fullständig expertis om vilken som helst av dem inom en enda tur.

CrewAI: Fullständig injektion i varje uppgiftsprompt

CrewAI tar motsatt tillvägagångssätt jämfört med progressiv avslöjning. När en färdighet är aktiverad för en agent injiceras dess fullständiga innehåll i varje uppgiftsprompt som agenten exekverar.

Hur det fungerar

Färdigheter i CrewAI är fristående kataloger, var och en med en SKILL.md-fil som innehåller YAML-frontmatter (namn, beskrivning, licens, kompatibilitet, tillåtna verktyg) och en markdown-brödtext. Färdighetssystemet skiljer mellan färdigheter och verktyg: färdigheter injicerar instruktioner och kontext som formar hur agenten tänker, medan verktyg tillhandahåller anropsbara funktioner för handlingar.

Under agentinitieringen anropar Agent.set_skills() discover_skills() för att skanna färdighetskataloger på metadatanivå, och sedan activate_skill() för att läsa fullständiga färdighetstexter. Vid uppgiftsexekvering anropar _finalize_task_prompt() format_skill_context() för varje aktiverad färdighet och lägger till allt formaterat färdighetsinnehåll i uppgiftsprompten.

LLM:en tar emot: [systemmeddelande] + [uppgiftsprompt + ALLA färdighetstexter]

Tokenkonsekvenser

CrewAI tillämpar en mjuk varning vid 50 000 tecken per färdighet men ingen hård gräns. Dokumentationen rekommenderar att hålla färdigheter fokuserade och koncisa eftersom stora promptinjektioner späder ut modellens uppmärksamhet – en verklig oro med tanke på forskning om kontextförfall.

Avvägningen är enkel: agenten har alltid fullständig expertis tillgänglig (hög tillförlitlighet), men tokenkostnaden skalas linjärt med antalet färdigheter per uppgift (låg effektivitet). För agenter med 1–2 fokuserade färdigheter fungerar detta bra. För agenter som behöver breda funktionsuppsättningar blir det dyrt snabbt.

Ingen persistens mellan uppgifter

Varje uppgift får en ny injektion. Det finns ingen ackumulering av färdighetsinnehåll mellan uppgifter – vilket faktiskt är en funktion, inte en bugg. Det betyder att varje uppgift startar med en ren kontext och undviker de problem med inaktuellt innehåll som sessionsbaserad persistens kan skapa.

LangChain Deep Agents: Agentstyrd laddning via SkillsMiddleware

LangChain Deep Agents implementerar ett sofistikerat middleware-baserat färdighetssystem där agenten själv bestämmer när fullständigt färdighetsinnehåll ska laddas – en äkta progressiv avslöjningsmodell där agenten styr aktiveringen.

De tre nivåerna

Nivå 1 (Index): SkillsMiddleware analyserar all SKILL.md-frontmatter vid uppstart och injicerar ett lättviktigt index i systemprompten. Detta index innehåller bara namn och beskrivningar och kostar ungefär 278 tokens per färdighet jämfört med 3 302 tokens för fullständigt innehåll.

Nivå 2 (Fullständigt innehåll): När agenten bedömer att en färdighet är relevant anropar den read_file() på färdighetens SKILL.md-sökväg. Detta är ett vanligt verktygsanrop – ramverket injicerar inte brödtexten; agenten fattar ett medvetet beslut att ladda den. Det fullständiga innehållet hamnar i konversationshistoriken som ett verktygsresultat.

Nivå 3 (Djupdykning): Stödmaterial, referensdokument och skript nås bara när agenten uttryckligen läser dem.

Tokeneffektivitet i praktiken

Med 12 färdigheter minskar progressiv avslöjning kontexten från ungefär 30 000 tokens (alla laddade) till ungefär 600 tokens (enbart index), och expanderar till 2 000–5 000 när relevanta färdigheter laddas för en specifik uppgift. Det är en potentiell minskning på 83–98 % av färdighetsrelaterad tokenförbrukning.

Flera färdighetskällor kan läggas i lager, och vid namnkollisioner vinner den senaste källan. Filer över 10 MB hoppas automatiskt över.

Den avgörande skillnaden mot Claude Code

Medan Claude Code använder ett dedikerat Skill-verktyg för att utlösa laddning, återanvänder Deep Agents agentens befintliga read_file-verktyg. Detta innebär att laddningsmekanismen är transparent – agenten läser färdighetsfiler på samma sätt som den läser vilken annan fil som helst. Nackdelen är att det inte finns något speciellt komprimeringsbeteende: färdighetsinnehåll som hamnar i konversationshistoriken omfattas av LangChains standardmeddelande­trimning, utan prioritetsbehandling.

OpenAI Responses API och Agents SDK: Plattformshanterad uppskjuten laddning

OpenAI implementerar färdighetsinjektion genom två distinkta men filosofiskt samstämmiga mekanismer: Responses API:s verktygstyp tool_search och Agents SDK:s ToolSearchTool.

Responses API: tool_search

Verktygstypen tool_search (tillgänglig på GPT-5.4+) gör det möjligt för utvecklare att skjuta upp stora verktygsobjekt till körning. Tre uppskjutningsstrategier finns tillgängliga:

• Individuell funktionsuppskjutning: @function_tool(defer_loading=True) – modellen ser funktionsnamnet och beskrivningen men parameterschemat skjuts upp. Sparar tokens på parameternivå.
• Namnrymdsuppskjutning: tool_namespace(name=..., description=..., tools=[...]) – grupperar funktioner under en enda namnrymd. Modellen ser bara namnrymdens namn och beskrivning, vilket sparar betydligt fler tokens.
• MCP-serveruppskjutning: HostedMCPTool(tool_config={..., "defer_loading": True}) – skjuter upp hela MCP-serverns verktygsobjekt.

När modellen bedömer att den behöver ett specifikt verktyg utfärdar den ett tool_search-anrop. API:et returnerar 3–5 relevanta verktygsdefinitioner, injicerade i slutet av kontextfönstret för att bevara promptcaching.

Agents SDK: ToolSearchTool

Agents SDK tillhandahåller en programmatisk motsvarighet. Verktygsnamnrymder registreras men laddas inte:

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

Vid körning ser agenten bara namnrymdsnamn. Den anropar ToolSearchTool("crm") för att upptäcka och ladda de fullständiga schemana, och kan sedan anropa enskilda verktyg inom den namnrymden.

Ingen persistens mellan anrop

Varje API-anrop är oberoende. Upptäckta verktyg bevaras inte mellan anrop. Detta är den mest tillståndslösa metoden i vår jämförelse – ren, förutsägbar, men kräver nyupptäckt vid varje anrop om verktygen ändras.

AutoGen Teachability: Semantisk hämtning per tur

AutoGen:s Teachability-funktion tar ett fundamentalt annorlunda tillvägagångssätt jämfört med alla andra ramverk i denna jämförelse. Istället för att injicera statiskt färdighetsinnehåll hämtar den dynamiskt relevanta “memon” från en ChromaDB-vektordatabas vid varje enskild tur.

Hämtningsloopen per tur

Teachability registrerar en hook på process_last_received_message som fångar upp varje inkommande användarmeddelande innan agenten bearbetar det:

1. En TextAnalyzerAgent extraherar nyckelbegrepp från det inkommande meddelandet
2. Dessa begrepp används för att fråga ChromaDB (med Sentence Transformer-inbäddningar som standard)
3. De top-K mest relevanta memona hämtas (konfigurerbart via max_num_retrievals, standard 10)
4. Hämtade memon läggs till i meddelandetexten innan agenten ser det

Viktigt att notera: det modifierade meddelandet sprids inte till lagrad konversationshistorik – bara det ursprungliga meddelandet lagras. Detta förhindrar att memoinnehåll ackumuleras över turer.

Inlärningsloop

Efter att LLM:en svarat analyserar en andra hook svaret för nya insikter:

1. TextAnalyzerAgent identifierar ny kunskap i svaret
2. Nya memon extraheras som nyckel-värde-par (indata-text -> utdata-text)
3. Dessa memon lagras i ChromaDB, tillgängliga för framtida turer och sessioner

Detta skapar en genuin inlärningsloop där agenten ackumulerar expertis över tid.

Sessionsoberoende persistens

AutoGen Teachability är en av bara tre plattformar i vår jämförelse (tillsammans med Voyager och DSPy) som bevarar färdigheter mellan sessioner. ChromaDB-databasen ligger på disk, vilket innebär att en agent kan lära sig av interaktioner på måndag och tillämpa den kunskapen på fredag.

Parametern recall_threshold (standard 1.5) styr hur likt ett meddelande måste vara ett lagrat memo för hämtning, och reset_db kan rensa hela minnet vid behov.

Tokeneffektivitet

Eftersom bara relevanta memon injiceras per tur (vanligtvis 3–5) är tokenkostnaden naturligt begränsad oavsett hur stor memodatabasen växer. En agent med 10 000 lagrade memon betalar bara för den handfull som är mest relevanta för den aktuella turen.

Semantic Kernel: Plugin-scheman som ständigt närvarande verktygsdefinitioner

Microsofts Semantic Kernel tar ett rakt tillvägagångssätt: plugins är samlingar av KernelFunction-objekt registrerade med Kernel, och deras scheman exponeras för LLM:en som verktygsdefinitioner för funktionsanrop.

Två injektionsvägar

Funktionsanrop: När ToolCallBehavior.AutoInvokeKernelFunctions är inställt skickas alla registrerade funktioner till LLM:en som tillgängliga verktyg i varje API-anrop. LLM:en bestämmer vilka som ska anropas; Semantic Kernel hanterar anrop och resultatrouting.

Promptmallar: Semantic Kernels mallsyntax ({{plugin.function}}, Handlebars eller Liquid) gör det möjligt att anropa funktioner inline under promptrendering. Resultaten bäddas in direkt i prompttexten innan den når LLM:en – en form av ivrig evaluering snarare än lat verktygsanrop.

Ingen progressiv avslöjning

Varje registrerat plugins schema inkluderas i varje API-anrop. Det finns ingen inbyggd uppskjuten laddning, namnrymdsgruppering eller aktivering vid behov. Dokumentationen rekommenderar uttryckligen att bara importera de plugins som behövs för ett specifikt scenario för att minska tokenförbrukning och felanrop.

Detta gör Semantic Kernel till en av de mest förutsägbara plattformarna – du vet alltid exakt vad agenten har tillgång till – men det begränsar skalbarheten. En agent med 50 registrerade funktioner betalar den fullständiga schemakostnaden vid varje enskilt anrop.

Persistens

Plugin-registrering är per Kernel-instans och i minnet. Det finns ingen inbyggd mekanism för sessionsoberoende färdighetspersistens.

MetaGPT: Actionmallar inom rollbaserade SOP:er

MetaGPT kodar färdigheter inte som fristående paket utan som actionmallar inbäddade i standardoperationsprocedurer (SOP:er) som styr rollbeteende.

Roll- och actionarkitektur

Varje Role i MetaGPT har ett persona-prefix som injiceras i promptar och en uppsättning Action-klasser. Varje Action innehåller en LLM-proxy som anropas via aask(), vilken använder promptmallar i naturligt språk för att strukturera LLM-anropet.

När Role._act() utlöses stöder den tre reaktionslägen:

• "react": LLM:en väljer dynamiskt actions i tänk-agera-loopar
• "by_order": Actions exekveras sekventiellt i en förutbestämd ordning
• "plan_and_act": Agenten planerar först och exekverar sedan actions enligt planen

Smalt injektionsfönster

Bara den aktuella Actionens promptmall är aktiv vid varje givet ögonblick. Agenten ser inte mallar för andra actions – den ser bara sitt rollprefix plus den specifika actionens kontext. Detta är det smalaste injektionsfönstret av alla ramverk vi undersökte.

Kontextanalysfunktioner inom Action-klasser extraherar relevant information från indata, så varje action tar emot en kurerad delmängd av tillgänglig kontext snarare än den fullständiga konversationshistoriken.

Persistens inom enstaka tur

Mallen renderas på nytt för varje actionexekvering. Det finns ingen ackumulering eller sessionsoberoende persistens. Detta håller varje action fokuserad men innebär att agenten inte kan bygga vidare på tidigare laddat färdighetsinnehåll inom ett enstaka arbetsflöde.

Voyager: Inbäddningsbaserad färdighetshämtning för livslångt lärande

Voyager, Minecraft-utforskningsagenten från NVIDIA och Caltech, implementerar en av de mest eleganta arkitekturerna för färdighetsinjektion: ett växande bibliotek av verifierade program som hämtas genom inbäddningslikhet.

Färdighetsbiblioteket

När Voyager skriver kod som klarar självverifiering (den genererade Mineflayer-JavaScripten fungerar faktiskt i spelet) lagras koden och dess dokumentationssträng i en vektordatabas. Dokumentationssträngens inbäddning blir hämtningsnyckeln.

Hämtning per uppgift

Vid varje ny uppgift som föreslås av den automatiska läroplanen:

1. Uppgiftsbeskrivningen och miljöåterkopplingen bäddas in
2. Cosinuslikhetsökning mot alla lagrade färdighetsinbäddningar
3. Topp-5 mest relevanta färdigheter hämtas
4. Hämtad färdighetskod inkluderas i actionagentens prompt som few-shot-exempel

Prompten ser ut så här:

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 genererade koden kan anropa hämtade färdigheter med namn, vilket möjliggör kompositionell färdighetsuppbyggnad – komplexa beteenden konstruerade från enklare, verifierade primitiver.

Livslång persistens

Färdighetsbiblioteket är den centrala mekanismen för “livslångt lärande”. Det växer under agentens hela livstid, och nya färdigheter bygger på gamla. Till skillnad från de flesta ramverk där färdigheter skrivs av människor genereras, verifieras och lagras Voyagers färdigheter av agenten själv.

Tokenkostnaden är naturligt begränsad: oavsett om biblioteket innehåller 50 eller 5 000 färdigheter betalar varje uppgift bara för de 5 mest relevanta hämtningarna.

DSPy: Kompilerade few-shot-exempel som frysta färdigheter

DSPy tar ett radikalt annorlunda tillvägagångssätt jämfört med alla andra ramverk. Istället för att injicera färdigheter vid körning kompilerar DSPy optimala few-shot-demonstrationer offline och bakar in dem permanent i modulpromptar.

Kompileringsprocessen

Två huvudoptimerare hanterar kompileringen:

BootstrapFewShot: Använder en lärarmodul för att generera spår genom programmet. Spår som klarar ett användardefinierat mått behålls som demonstrationer. Varje dspy.Predict-modul inom programmet får sin egen kurerade uppsättning demonstrationer.

MIPROv2 (Multi-prompt Instruction Proposal Optimizer v2): En trefasprocess:

1. Bootstrap: Generera kandidatdemonstrationsuppsättningar
2. Föreslå: Generera kandidatinstruktionstexer som är medvetna om både datadistributionen och demonstrationerna
3. Sök: Bayesiansk optimering över det kombinerade utrymmet av instruktioner x demonstrationer över alla moduler

Parametrar som max_bootstrapped_demos (genererade exempel) och max_labeled_demos (från träningsdata) styr hur många exempel som hamnar i varje moduls prompt.

Fast efter kompilering

När de väl kompilerats lagras demonstrationer i varje Predict-moduls demos-attribut och formateras till prompten vid varje LLM-anrop. De ändras inte vid körning – “färdigheten” är frusen.

Detta innebär att DSPy-färdigheter är de mest förutsägbara i vår jämförelse: tokenkostnaden är känd efter kompilering, det finns ingen variation mellan turer, och agenten ser alltid samma demonstrationer. Nackdelen är oflexibilitet – för att ändra färdigheter måste du kompilera om.

Persistens

Kompilerade program serialiseras till JSON, inklusive alla demonstrationer. De är fullt persistenta och laddningsbara mellan sessioner, vilket gör DSPy till en av de mest hållbara mekanismerna för färdighetslagring.

SuperAGI: Verktygslådebaserad registrering vid uppstart

SuperAGI använder ett traditionellt verktygslådemönster där alla verktyg registreras vid agentinitieringen.

Varje verktygslåda utökar BaseToolkit med:

• Attributen name och description
• Metoden get_tools() som returnerar en lista med BaseTool-instanser
• get_env_keys() för obligatoriska miljövariabler

Verktygslådor installeras från GitHub-repositorier via SuperAGI:s verktygshanterare. Vid agentinitieringen returnerar BaseToolkit.get_tools() alla verktyg, och deras fullständiga scheman exponeras för LLM:en som funktionsanropsdefinitioner.

Det finns ingen uppskjuten laddning, ingen progressiv avslöjning och ingen filtrering per tur. Varje registrerat verktygs schema finns i varje anrop. Detta är den enklaste injektionsmodellen och fungerar bra för agenter med fokuserade, små verktygsuppsättningar men skalas inte till agenter som behöver dussintals funktioner.

CAMEL-AI: ChatAgent-verktygsregistrering

CAMEL-AI följer ett liknande mönster för registrering vid uppstart. Verktyg från olika verktygslådor (t.ex. MathToolkit, SearchToolkit) skickas som en lista till ChatAgent(tools=[...]) vid initieringen.

Ramverket betonar att anpassade funktioner behöver tydliga argumentnamn och omfattande docstrings så att modellen kan förstå användningen – verktygsschemat är det enda “färdighetsinnehåll” modellen ser. Det finns ingen separat mekanism för instruktionsinjektion.

Nyligen tillagda funktioner inkluderar MCP-stöd (Model Context Protocol) via MCPToolkit, som gör det möjligt för ChatAgent att ansluta till MCP-servrar och registrera externa verktyg. Detta utökar den tillgängliga verktygsobjektet men ändrar inte injektionsmodellen – alla upptäckta MCP-verktyg registreras fortfarande vid uppstart.

Jämförelse mellan plattformar

När färdigheter injiceras

Persistensmodeller

Överlevnad vid kontextkomprimering

Mönstret progressiv avslöjning

Den mest betydande arkitektoniska trenden över dessa plattformar är antagandet av progressiv avslöjning – ett koncept lånat från UI-design där information avslöjas stegvis baserat på behov.

Varför progressiv avslöjning är viktigt

En naiv metod för färdighetsinjektion – att ladda allt i förväg – skapar två problem:

1. Tokenslöseri: De flesta färdigheter är inte relevanta för de flesta turer. Att ladda 20 fullständiga färdighetstexter när bara 1–2 behövs per tur slösar 90 %+ av färdighetsrelaterade tokens.
2. Uppmärksamhetsutspädning: Forskning om kontextförfall visar att LLM:er presterar sämre när deras kontext innehåller stora mängder irrelevant information. Fler färdigheter i kontexten kan faktiskt minska kvaliteten på färdighetstillämpningen.

Progressiv avslöjning löser båda problemen genom att upprätthålla ett lättviktigt index av tillgängliga färdigheter medan fullständigt innehåll bara laddas vid behov.

Implementationsvarianter

Claude Code använder ett dedikerat system: färdighetsmetadata i system-reminder-meddelanden, ett Skill-verktyg för aktivering och ToolSearch för uppskjutna verktygsscheman. Ramverket hanterar injektion automatiskt med prioritetsbaserad komprimering.

LangChain Deep Agents använder agentens befintliga filläsningsfunktion: SkillsMiddleware injicerar indexet, och agenten laddar fullständigt innehåll via read_file(). Detta är mer transparent men erbjuder mindre ramverksoptimering.

OpenAI Responses API använder namnrymdsbaserad gruppering med plattformshanterad sökning: verktygsnamnrymder tillhandahåller beskrivningar på hög nivå, och tool_search returnerar relevanta scheman. Plattformen hanterar söklogiken helt.

Tokenbesparingar i praktiken

Siffrorna är övertygande. Med 12 färdigheter:

• Ständigt-på-injektion (CrewAI/SuperAGI-stil): ~30 000 tokens
• Progressiv avslöjning, enbart index: ~600 tokens
• Index + 2 aktiverade färdigheter: ~2 000–5 000 tokens

Det är en minskning på 83–98 % av färdighetsrelaterad tokenförbrukning per tur. Under en lång session med hundratals turer ackumuleras besparingarna dramatiskt.

Arkitektoniska mönster och avvägningar

Genom att titta över alla 11 plattformar framträder fyra distinkta arkitektoniska mönster:

Mönster 1: Ständigt-på-injektion

Används av: CrewAI, SuperAGI, CAMEL-AI, Semantic Kernel

Hur det fungerar: Fullständigt färdighetsinnehåll eller verktygsscheman finns i varje LLM-anrop.

Fördelar:

• Maximal tillförlitlighet – agenten har alltid fullständig expertis tillgänglig
• Enklast implementation – ingen aktiveringslogik behövs
• Förutsägbara tokenkostnader – samma varje tur

Nackdelar:

• Tokenkostnaden skalas linjärt med antalet färdigheter
• Uppmärksamhetsutspädning med många färdigheter
• Skalas inte bortom ~5–10 färdigheter per agent

Bäst för: Fokuserade agenter med 1–3 kärnfärdigheter som alltid är relevanta.

Mönster 2: Progressiv avslöjning

Används av: Claude Code, LangChain Deep Agents, OpenAI Responses API/Agents SDK

Hur det fungerar: Lättviktig metadata alltid närvarande; fullständigt innehåll laddas vid behov.

Fördelar:

• Skalas till dussintals eller hundratals tillgängliga färdigheter
• Minimal tokenkostnad när färdigheter inte behövs
• Bevarar promptcache när fullständiga scheman läggs till i slutet

Nackdelar:

• Agenten kan missa signalen att aktivera en relevant färdighet
• Ytterligare latens från aktiveringssteget
• Mer komplex ramverksimplementation

Bäst för: Allmänna agenter som behöver tillgång till många funktioner men bara använder ett fåtal per uppgift.

Mönster 3: Semantisk hämtning

Används av: AutoGen Teachability, Voyager

Hur det fungerar: Vektordatabasfrågor tar fram relevanta färdigheter/kunskap baserat på semantisk likhet med det aktuella sammanhanget.

Fördelar:

• Naturligt begränsad tokenkostnad oavsett bibliotekets storlek
• Innehållsrelevansen förbättras över tid allteftersom biblioteket växer
• Sessionsoberoende lärande och ackumulering
• Ingen explicit aktivering behövs – relevans beräknas automatiskt

Nackdelar:

• Hämtningskvaliteten beror på inbäddningsmodellens kvalitet
• Risk att hämta föråldrad eller subtilt felaktig information
• Kräver vektordatabasinfrastruktur
• Mindre förutsägbart – olika turer laddar olika innehåll

Bäst för: Agenter som lär sig av erfarenhet och behöver ackumulera domänkunskap över tid.

Mönster 4: Kompilerad/statisk injektion

Används av: DSPy, MetaGPT

Hur det fungerar: Färdigheter kompileras till fast promptinnehåll (DSPy) eller aktiveras genom rigida actionmallar (MetaGPT).

Fördelar:

• Mest förutsägbart beteende – samma innehåll varje gång
• Optimering kan göras offline (DSPy:s kompilering)
• Ingen körtidsoverhead för färdighetsval
• Bevisat effektivt för väldefinierade, repeterbara uppgifter

Nackdelar:

• Oflexibelt – att ändra färdigheter kräver omkompilering (DSPy) eller kodändringar (MetaGPT)
• Kan inte anpassa sig till nya situationer utanför de kompilerade exemplen
• DSPy:s kompileringsprocess kräver i sig många LLM-anrop

Bäst för: Produktionspipelines med väldefinierade uppgifter där tillförlitlighet övertrumfar flexibilitet.

Praktiska konsekvenser för agentbyggare

Att välja rätt mönster

Rätt arkitektur för färdighetsinjektion beror på din agents profil:

Om din agent har en smal, väldefinierad roll (t.ex. en kodgranskningsbot, en kundsupportagent för en produkt), är ständigt-på-injektion (CrewAI/SuperAGI-mönster) enklast och mest tillförlitligt. Tokenkostnaden för 2–3 ständigt närvarande färdigheter är hanterbar, och du undviker komplexiteten i aktiveringslogik.

Om din agent behöver breda funktioner men bara använder ett fåtal per interaktion (t.ex. en utvecklarassistent, en allmän automatiseringsagent), är progressiv avslöjning (Claude Code/Deep Agents-mönster) den klara vinnaren. Tokenbesparingarna på 83–98 % i stor skala är för betydande att ignorera.

Om din agent behöver lära sig och förbättras från interaktioner (t.ex. en personlig assistent, en domänexpert som ackumulerar kunskap), ger semantisk hämtning (AutoGen Teachability-mönster) den inlärningsloop som andra mönster saknar. Se bara till att du har kvalitetskontroller på vad som hamnar i kunskapsbasen.

Om din agent kör väldefinierade pipelines (t.ex. databehandling, rapportgenerering, standardiserade arbetsflöden), ger kompilerad injektion (DSPy-mönster) dig det mest förutsägbara, optimerade beteendet.

Hybridmetoden

För produktionsagentteam där agenter behöver fungera direkt ur lådan rekommenderar vi en hybridmetod:

Kärnfärdigheter (1–2 per agent, som definierar deras primära domänexpertis): alltid injicerade i systemprompten, i CrewAI-stil. Dessa är icke-förhandlingsbara funktioner som agenten behöver vid varje tur.

Utökade färdigheter (ytterligare funktioner som agenten kan behöva): enbart metadata i systemprompten, laddade via en sök-/laddningsmekanism vid behov, i Deep Agents-stil. Dessa utökar agentens funktionsuppsättning utan att betala tokenkostnaden när de inte är relevanta.

Inlärd kunskap (ackumulerad domänexpertis): lagrad i en vektordatabas och hämtad semantiskt per tur, i AutoGen-stil. Detta gör det möjligt för agenten att förbättras över tid utan manuell färdighetsförfattning.

Denna lagerarkitektur mappar naturligt till hur en systemprompt byggs upp: datum -> persona -> systeminstruktioner -> kärnfärdigheter -> färdighetsindex -> roll-/teamkontext. Kärnfärdigheterna och indexet lägger till en förutsägbar, hanterbar tokenkostnad, medan de fullständiga färdighetstexterna bara dyker upp vid behov.

Bästa praxis för tokenbudgetar över ramverk

Oavsett vilket injektionsmönster du använder gäller dessa tokenhanteringsstrategier universellt:

Cachevänlig ordning

Stapla oföränderlig kontext (systeminstruktioner, verktygsscheman) i början av prompten. Hos leverantörer som stöder promptcaching kostar cachade tokens 75 % mindre. Claude Code och OpenAI injicerar båda upptäckta verktygsscheman i slutet av kontexten specifikt för att bevara cacheträffar på det statiska prefixet.

Avlastning

Sammanfatta verktygssvar istället för att behålla fullständiga resultat i kontexten. Lagra den fullständiga datan i externa referenser som agenten kan läsa vid behov. Detta är särskilt viktigt för agenter som gör många verktygsanrop per session.

Reduktion

Komprimera konversationshistorik genom sammanfattning. Extrahera nyckelfakta från långa utbyten till komprimerade representationer. Varje ramverk med sessionsbaserad persistens drar nytta av aggressiv historikhantering.

Hämtning före förladdning

Hämta relevant information dynamiskt vid körning istället för att ladda allt i förväg. Detta gäller färdigheter, kunskapsbaser och till och med konversationshistorik. Studier visar att detta kan minska promptstorlekar med upp till 70 %.

Isolering

Använd underagenter för specifika uppgifter så att varje agents kontext förblir fokuserad. Istället för att ge en agent 20 färdigheter, skapa ett team av 5 agenter med 4 färdigheter vardera. Varje agent upprätthåller ett smalt kontextfönster, och teamet täcker kollektivt hela funktionsuppsättningen.

Slutsats

Sättet som ramverk för AI-agenter injicerar färdigheter i kontext är ett av de mest betydelsefulla arkitektoniska besluten i agentdesign – ändå diskuteras det sällan på denna detaljnivå.

Fältet konvergerar tydligt mot progressiv avslöjning som det föredragna mönstret för allmänna agenter, där Claude Code, LangChain Deep Agents och OpenAI alla oberoende har kommit fram till liknande trelagerarkitekturer. Samtidigt fyller specialiserade mönster som semantisk hämtning (AutoGen, Voyager) och kompilerad injektion (DSPy) viktiga nischer som progressiv avslöjning ensam inte adresserar.

För praktiker som bygger agentsystem idag är den viktigaste insikten att färdighetsinjektion inte är en universallösning. Rätt tillvägagångssätt beror på din agents roll, antalet färdigheter den behöver, om den behöver lära sig över tid, och din tolerans för avvägningar mellan tokenkostnader och tillförlitlighet.

De mest robusta produktionssystemen kommer sannolikt att kombinera flera mönster – ständigt-på för kärnfunktioner, progressiv avslöjning för utökade färdigheter och semantisk hämtning för ackumulerad kunskap – och skapa agenter som är både effektiva och expertkunniga.