Sådan implementerer AI-agenter faktisk færdigheder: Komplet sammenligning på tværs af platforme

Introduktion

Ethvert AI-agent-framework står over for det samme grundlæggende spørgsmål: hvordan gør man en LLM god til noget bestemt? Modellen har i sig selv bred generel viden, men når du har brug for, at den udfører en kodegennemgang, udrulning af infrastruktur eller navigation i Minecraft — har den brug for specialiserede instruktioner, værktøjsadgang og domænekontekst.

Dette er færdighedsinjiceringsproblemet. Og hvert større framework løser det forskelligt.

Nogle platforme dumper alt ind i systemprompten på forhånd. Andre bruger lazy loading og afslører kun funktioner, når agenten har brug for dem. Nogle få bruger vektordatabaser til at hente relevante færdigheder baseret på semantisk lighed. Forskellene er ikke akademiske — de påvirker direkte tokenomkostninger, agentpålidelighed, og hvor mange færdigheder en agent realistisk kan jonglere med.

Vi analyserede 11 store AI-agentplatforme for at forstå præcis, hvor færdigheder placeres i prompten, hvornår de indlæses, hvad de koster i tokens, og hvordan de overlever, når kontekstvinduet fyldes op. Dette er ikke en overfladisk funktionssammenligning. Vi gravede i kildekode, dokumentation og arkitekturdiagrammer for at kortlægge de præcise injektionsmekanikker for hver platform.

Overordnet sammenligningstabel

Her er det komplette overblik, før vi dykker ned i detaljerne.

Injektionsmekanikker: Hvor, hvornår og hvordan

Persistens, tokenomkostning og altid-aktiv-adfærd

Klar til at vokse din virksomhed?

Start din gratis prøveperiode i dag og se resultater inden for få dage.

Anmod om demo Log ind

Hvad “færdighedsinjicering” faktisk betyder

Inden vi dykker ned i sammenligningen, lad os definere problemområdet. En AI-agents kontekstvindue — den samlede tekst, som LLM’en ser ved hvert kald — har en fast størrelse. Hver token af instruktion, samtalehistorik, værktøjsdefinition og hentet data konkurrerer om plads i dette vindue.

En “færdighed” i agentkonteksten er enhver struktureret pakke af ekspertise, der ændrer, hvordan agenten opfører sig. Dette kan være:

• Instruktioner, der fortæller agenten, hvordan den skal tilgå et specifikt domæne (retningslinjer for kodegennemgang, udrulningschecklister)
• Værktøjsdefinitioner, der giver agenten kaldbare funktioner (API-integrationer, filoperationer)
• Few-shot-eksempler, der viser agenten, hvordan godt output ser ud
• Hentet viden fra vektordatabaser eller eksterne dokumenter

Injektionsmekanismen — hvor og hvornår dette indhold træder ind i konteksten — bestemmer tre kritiske egenskaber:

1. Tokeneffektivitet: Hvor mange tokens bruger færdigheden, og betales denne omkostning, selv når færdigheden ikke er nødvendig?
2. Pålidelighed: Vil agenten konsekvent bruge færdigheden, når den er relevant, eller kan den overse signalet?
3. Skalerbarhed: Hvor mange færdigheder kan agenten tilgå, før kontekstoppustning forringer ydeevnen?

Hvert framework laver forskellige kompromiser på tværs af disse tre dimensioner. Lad os undersøge hver enkelt.

Injektionsspektret: Fra altid-aktiv til on-demand

På tværs af alle 11 platforme falder færdighedsinjiceringstilgangene langs et spektrum fra “alt indlæst på forhånd” til “intet indlæst, før det eksplicit er nødvendigt.”

I den ene ende injicerer platforme som CrewAI, SuperAGI og CAMEL-AI det fulde indhold af hver aktiveret færdighed i hvert LLM-kald. Agenten har altid sin komplette ekspertise tilgængelig. Simpelt, pålideligt, men dyrt i tokens.

I den anden ende bruger Claude Code, LangChain Deep Agents og OpenAI’s Responses API progressiv afsløring — agenten ser kun færdighedsnavne og korte beskrivelser ved opstart, og det fulde indhold indlæses on-demand. Effektivt, skalerbart, men kræver, at agenten genkender, hvornår den har brug for en færdighed.

I midten bruger AutoGen Teachability og Voyager semantisk søgning til kun at injicere de mest relevante færdigheder pr. tur, hvilket skaber et dynamisk, kontekstfølsomt injektionsmønster.

Og så er der unikke tilgange: DSPy kompilerer optimerede few-shot-eksempler offline og indlejrer dem permanent i modulprompter. MetaGPT koder færdigheder som handlingsskabeloner, der kun aktiveres, når en bestemt rolle skifter til en bestemt handling.

Lad os undersøge hver enkelt i detaljer.

Tilmeld dig vores nyhedsbrev

Få de seneste tips, trends og tilbud gratis.

E-mailadresse

Tilmeld

Claude Code: Trelagsprogressiv afsløring

Claude Code implementerer en af de mest sofistikerede færdighedsinjiceringsarkitekturer med et trelagssystem til progressiv afsløring, der balancerer bevidsthed med tokeneffektivitet.

Lag 1: Altid i kontekst

Ved sessionsstart injiceres navn og beskrivelse for hver tilgængelig færdighed i en system-reminder-meddelelse — en metadatablok, som modellen altid ser. Dette koster ca. 250 tegn pr. færdighed og forbruger cirka 1% af kontekstvinduets budget for alle færdighedsbeskrivelser tilsammen (ca. 8K tegn som fallback-budget, kan tilsidesættes via miljøvariablen SLASH_COMMAND_TOOL_CHAR_BUDGET).

Tilsvarende vises udskudte værktøjer — værktøjer, hvis fulde JSON-skemaer endnu ikke er indlæst — som en navneliste i system-reminder-blokke. Fra Claude Code v2.1.69 er selv indbyggede systemværktøjer som Bash, Read, Edit, Write, Glob og Grep udskudt bag ToolSearch, hvilket reducerer systemværktøjskonteksten fra ca. 14-16K tokens til ca. 968 tokens.

Agenten ser nok til at vide, hvad der er tilgængeligt, uden at betale tokenomkostningen for fulde definitioner.

Lag 2: Ved aktivering

Når en bruger skriver en slash-kommando (f.eks. /commit), eller modellen automatisk matcher en færdighed baseret på dens beskrivelse, indlæses den fulde SKILL.md-body som en samtalemeddelelse via Skill-værktøjet. Denne body indeholder de komplette instruktioner — sommetider tusindvis af tokens med detaljeret vejledning.

Vigtig detalje: Shell-forbehandling kører først (eventuelle !command-direktiver i færdighedsfilen udføres, og deres output erstatter direktivet), og når den er indlæst, forbliver færdighedsbodyen i samtalen resten af sessionen.

Lag 3: On-demand

Yderligere ressourcer — referencedokumenter, scripts, aktiv-filer — læses kun, når modellen eksplicit beslutter at bruge Read-værktøjet til at tilgå dem. Disse indlæses aldrig automatisk.

Adfærd ved kontekstkomprimering

Når samtalen nærmer sig kontekstgrænsen og komprimering udløses, genindsætter Claude Code de senest brugte færdigheder med et budget på 5K tokens pr. færdighed og et samlet maksimum på 25K. De senest brugte færdigheder får prioritet. Ældre færdigheder kan blive helt droppet.

Denne trelagsarkitektur betyder, at en agent med 20+ tilgængelige færdigheder betaler en minimal forhåndsomkostning, men kan tilgå fuld ekspertise for enhver af dem inden for en enkelt tur.

CrewAI: Fuld injicering i hver opgaveprompt

CrewAI tager den modsatte tilgang til progressiv afsløring. Når en færdighed er aktiveret for en agent, injiceres dens fulde indhold i hver opgaveprompt, som agenten udfører.

Sådan fungerer det

Færdigheder i CrewAI er selvstændige mapper, hver med en SKILL.md-fil indeholdende YAML-frontmatter (navn, beskrivelse, licens, kompatibilitet, tilladte værktøjer) og en markdown-body. Færdighedssystemet skelner mellem færdigheder og værktøjer: færdigheder injicerer instruktioner og kontekst, der former, hvordan agenten tænker, mens værktøjer giver kaldbare funktioner til handlinger.

Under agentinitialisering kalder Agent.set_skills() discover_skills() for at scanne færdighedsmapper på metadataniveau, derefter activate_skill() for at læse fulde færdighedsbodies. Ved opgaveudførelsestidspunktet kalder _finalize_task_prompt() format_skill_context() for hver aktiveret færdighed og tilføjer alt formateret færdighedsindhold til opgaveprompten.

LLM’en modtager: [systemmeddelelse] + [opgaveprompt + ALLE færdighedsbodies]

Tokenimplikationer

CrewAI pålægger en blød advarsel ved 50.000 tegn pr. færdighed, men ingen hård grænse. Dokumentationen anbefaler at holde færdigheder fokuserede og koncise, fordi store promptinjektioner udvander modellens opmærksomhed — en reel bekymring givet forskning i kontekstforringelse.

Kompromisset er ligetil: agenten har altid fuld ekspertise tilgængelig (høj pålidelighed), men tokenomkostningen skalerer lineært med antallet af færdigheder pr. opgave (lav effektivitet). For agenter med 1-2 fokuserede færdigheder fungerer dette godt. For agenter, der har brug for brede funktionssæt, bliver det hurtigt dyrt.

Ingen persistens på tværs af opgaver

Hver opgave får en frisk injicering. Der er ingen ophobning af færdighedsindhold på tværs af opgaver — hvilket faktisk er en funktion, ikke en fejl. Det betyder, at hver opgave starter med en ren kontekst og undgår de problemer med forældelse, som sessionsbaseret persistens kan skabe.

LangChain Deep Agents: Agentstyret indlæsning via SkillsMiddleware

LangChain Deep Agents implementerer et sofistikeret middleware-baseret færdighedssystem, hvor agenten selv bestemmer, hvornår fuldt færdighedsindhold skal indlæses — en ægte progressiv afsløringsmodel, hvor agenten styrer aktiveringen.

De tre niveauer

Niveau 1 (Indeks): SkillsMiddleware parser alle SKILL.md-frontmatter ved opstart og injicerer et let indeks i systemprompten. Dette indeks indeholder kun navne og beskrivelser og koster ca. 278 tokens pr. færdighed mod 3.302 tokens for fuldt indhold.

Niveau 2 (Fuldt indhold): Når agenten vurderer, at en færdighed er relevant, kalder den read_file() på færdighedens SKILL.md-sti. Dette er et almindeligt værktøjskald — frameworket injicerer ikke bodyen; agenten træffer en bevidst beslutning om at indlæse den. Det fulde indhold kommer ind i samtalehistorikken som et værktøjsresultat.

Niveau 3 (Dybdegående): Understøttende materialer, referencedokumenter og scripts tilgås kun, når agenten eksplicit læser dem.

Tokeneffektivitet i praksis

Med 12 færdigheder reducerer progressiv afsløring konteksten fra ca. 30.000 tokens (alle indlæst) til ca. 600 tokens (kun indeks), der udvides til 2.000-5.000, når relevante færdigheder indlæses til en bestemt opgave. Det er en potentiel reduktion på 83-98% i færdighedsrelateret tokenforbrug.

Flere færdighedskilder kan lagdeles, og ved navnekollisioner vinder den sidste kilde. Filer over 10 MB springes automatisk over.

Den vigtigste forskel fra Claude Code

Mens Claude Code bruger et dedikeret Skill-værktøj til at udløse indlæsning, genbruger Deep Agents agentens eksisterende read_file-værktøj. Det betyder, at indlæsningsmekanismen er gennemsigtig — agenten læser færdighedsfiler på samme måde, som den læser andre filer. Ulempen er, at der ikke er nogen speciel komprimeringsadfærd: færdighedsindhold, der kommer ind i samtalehistorikken, er underlagt standard LangChain-beskæring af meddelelser, uden prioritetsbehandling.

OpenAI Responses API og Agents SDK: Platformstyret udskudt indlæsning

OpenAI implementerer færdighedsinjicering gennem to forskellige, men filosofisk beslægtede mekanismer: Responses API’ens tool_search-værktøjstype og Agents SDK’ens ToolSearchTool.

Responses API: tool_search

Værktøjstypen tool_search (tilgængelig på GPT-5.4+) giver udviklere mulighed for at udskyde store værktøjsoverflader til runtime. Tre udskydelsesstrategier er tilgængelige:

• Individuel funktionsudskydelse: @function_tool(defer_loading=True) — modellen ser funktionsnavnet og beskrivelsen, men parameterskemaet udskydes. Sparer tokens på parameterniveau.
• Navnerumsudskydelse: tool_namespace(name=..., description=..., tools=[...]) — grupperer funktioner under ét navnerum. Modellen ser kun navnerummets navn og beskrivelse, hvilket sparer betydeligt flere tokens.
• MCP-serverudskydelse: HostedMCPTool(tool_config={..., "defer_loading": True}) — udskyder hele MCP-serverens værktøjsoverflade.

Når modellen vurderer, at den har brug for et specifikt værktøj, udsender den et tool_search-kald. API’en returnerer 3-5 relevante værktøjsdefinitioner, injiceret i slutningen af kontekstvinduet for at bevare prompt-caching.

Agents SDK: ToolSearchTool

Agents SDK’en giver et programmatisk ækvivalent. Værktøjsnavnerum registreres, men indlæses ikke:

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

Ved runtime ser agenten kun navnerumsnavne. Den kalder ToolSearchTool("crm") for at opdage og indlæse de fulde skemaer, og kan derefter kalde individuelle værktøjer inden for det navnerum.

Ingen persistens på tværs af forespørgsler

Hver API-forespørgsel er uafhængig. Opdagede værktøjer persisterer ikke på tværs af kald. Dette er den mest tilstandsløse tilgang i vores sammenligning — ren, forudsigelig, men kræver genopdagelse ved hver forespørgsel, hvis værktøjerne ændres.

AutoGen Teachability: Semantisk søgning pr. tur

AutoGen’s Teachability-funktionalitet tager en fundamentalt anderledes tilgang end ethvert andet framework i denne sammenligning. I stedet for at injicere statisk færdighedsindhold henter den dynamisk relevante “memoer” fra en ChromaDB-vektordatabase ved hver eneste tur.

Søgeloop pr. tur

Teachability registrerer en hook på process_last_received_message, der opfanger enhver indgående brugermeddelelse, før agenten behandler den:

1. En TextAnalyzerAgent udtrækker nøglebegreber fra den indgående meddelelse
2. Disse begreber bruges til at forespørge ChromaDB (som standard med Sentence Transformer-embeddings)
3. De top-K mest relevante memoer hentes (konfigurerbart via max_num_retrievals, standard 10)
4. Hentede memoer tilføjes til meddelelsesteksten, før agenten ser den

Kritisk: den modificerede meddelelse spredes ikke ind i den gemte samtalehistorik — kun den originale meddelelse gemmes. Dette forhindrer memo-indhold i at akkumulere på tværs af ture.

Læringsloop

Efter at LLM’en har svaret, analyserer en anden hook svaret for ny læring:

1. TextAnalyzerAgent identificerer ny viden i svaret
2. Nye memoer udtrækkes som nøgle-værdi-par (inputtekst → outputtekst)
3. Disse memoer gemmes i ChromaDB, tilgængelige for fremtidige ture og sessioner

Dette skaber en ægte læringsloop, hvor agenten akkumulerer ekspertise over tid.

Persistens på tværs af sessioner

AutoGen Teachability er en af kun tre platforme i vores sammenligning (sammen med Voyager og DSPy), der persisterer færdigheder på tværs af sessioner. ChromaDB-databasen ligger på disk, hvilket betyder, at en agent kan lære af interaktioner om mandagen og anvende denne viden om fredagen.

Parameteren recall_threshold (standard 1,5) styrer, hvor lig en meddelelse skal være med et gemt memo for at udløse hentning, og reset_db kan rydde hele hukommelsen, når det er nødvendigt.

Tokeneffektivitet

Da kun relevante memoer injiceres pr. tur (typisk 3-5), er tokenomkostningen naturligt begrænset uanset, hvor stor memo-databasen vokser. En agent med 10.000 gemte memoer betaler stadig kun for de få, der er mest relevante for den aktuelle tur.

Semantic Kernel: Plugin-skemaer som altid tilstedeværende værktøjsdefinitioner

Microsofts Semantic Kernel tager en ligetil tilgang: plugins er samlinger af KernelFunction-objekter registreret med Kernel, og deres skemaer eksponeres for LLM’en som funktionskaldværktøjsdefinitioner.

To injektionsveje

Funktionskald: Når ToolCallBehavior.AutoInvokeKernelFunctions er sat, sendes alle registrerede funktioner til LLM’en som tilgængelige værktøjer i hver API-forespørgsel. LLM’en beslutter, hvilke der skal kaldes; Semantic Kernel håndterer kald og resultatrouting.

Promptskabeloner: Semantic Kernels skabelonsyntaks ({{plugin.function}}, Handlebars eller Liquid) tillader funktioner at blive kaldt inline under promptrendering. Resultater indlejres direkte i promptteksten, før den når LLM’en — en form for ivrig evaluering i stedet for doven værktøjskald.

Ingen progressiv afsløring

Hvert registreret plugins skema er inkluderet i hvert API-kald. Der er ingen indbygget udskudt indlæsning, navnerumsgruppering eller on-demand-aktivering. Dokumentationen anbefaler eksplicit kun at importere de plugins, der er nødvendige for et specifikt scenarie, for at reducere tokenforbrug og fejlkald.

Dette gør Semantic Kernel til en af de mest forudsigelige platforme — du ved altid præcis, hvad agenten har adgang til — men det begrænser skaleerbarheden. En agent med 50 registrerede funktioner betaler den fulde skemaomkostning ved hvert eneste kald.

Persistens

Plugin-registrering er pr. Kernel-instans og i hukommelsen. Der er ingen indbygget mekanisme for persistens af færdigheder på tværs af sessioner.

MetaGPT: Handlingsskabeloner inden for rollebaserede SOP’er

MetaGPT koder færdigheder ikke som selvstændige pakker, men som handlingsskabeloner indlejret i Standard Operating Procedures (SOP’er), der styrer rolleadfærd.

Rolle- og handlingsarkitektur

Hver Role i MetaGPT har en persona-prefix, der injiceres i prompter, og et sæt Action-klasser. Hver Action indeholder en LLM-proxy, der påkaldes via aask(), som bruger naturligsprogspromptskabeloner til at strukturere LLM-kaldet.

Når Role._act() udløses, understøtter den tre reaktionstilstande:

• "react": LLM’en vælger dynamisk handlinger i tænk-handling-loops
• "by_order": Handlinger udføres sekventielt i en forudbestemt rækkefølge
• "plan_and_act": Agenten planlægger først, derefter udfører handlinger ifølge planen

Snævert injektionsvindue

Kun den aktuelle Actions promptskabelon er aktiv på ethvert givet tidspunkt. Agenten ser ikke skabeloner for andre handlinger — den ser kun sin rollens prefix plus den specifikke handlings kontekst. Dette er det snævreste injektionsvindue af alle frameworks, vi undersøgte.

Kontekstparsingfunktioner inden for Action-klasser udtrækker relevant information fra input, så hver handling modtager en kurateret delmængde af tilgængelig kontekst frem for den fulde samtalehistorik.

Enkelttur-persistens

Skabelonen renderes frisk for hver handlingsudførelse. Der er ingen ophobning eller persistens på tværs af sessioner. Dette holder hver handling fokuseret, men betyder, at agenten ikke kan bygge videre på tidligere indlæst færdighedsindhold inden for en enkelt arbejdsgang.

Voyager: Embedding-baseret færdighedssøgning til livslang læring

Voyager, Minecraft-udforskningsagenten fra NVIDIA og Caltech, implementerer en af de mest elegante færdighedsinjiceringsarkitekturer: et voksende bibliotek af verificerede programmer hentet via embedding-lighed.

Færdighedsbiblioteket

Når Voyager skriver kode, der passerer selvverificering (den genererede Mineflayer JavaScript fungerer faktisk i spillet), gemmes koden og dens dokumentationsstreng i en vektordatabase. Docstring-embedningen bliver søgenøglen.

Søgning pr. opgave

Ved hver ny opgave foreslået af det automatiske curriculum:

1. Opgavebeskrivelsen og miljøfeedbacken embeddes
2. Cosinuslighed søges mod alle gemte færdighedsembeddings
3. Top-5 mest relevante færdigheder hentes
4. Hentet færdighedskode inkluderes i handlingsagentens prompt som few-shot-eksempler

Prompten ser sådan ud:

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 genererede kode kan kalde hentede færdigheder ved navn, hvilket muliggør kompositionel færdighedsopbygning — komplekse adfærdsmønstre konstrueret af enklere, verificerede primitiver.

Livslang persistens

Færdighedsbiblioteket er den centrale “livslang læring”-mekanisme. Det vokser over agentens hele levetid, og nye færdigheder bygger på gamle. I modsætning til de fleste frameworks, hvor færdigheder er forfattet af mennesker, er Voyagers færdigheder genereret, verificeret og gemt af agenten selv.

Tokenomkostningen er naturligt begrænset: uanset om biblioteket indeholder 50 eller 5.000 færdigheder, betaler hver opgave kun for de 5 mest relevante hentninger.

DSPy: Kompilerede few-shot-eksempler som frosne færdigheder

DSPy tager en radikalt anderledes tilgang end ethvert andet framework. I stedet for at injicere færdigheder ved runtime kompilerer DSPy optimale few-shot-demonstrationer offline og indlejrer dem permanent i modulprompter.

Kompileringsprocessen

To hovedoptimizere håndterer kompilering:

BootstrapFewShot: Bruger et lærermodul til at generere spor (traces) gennem programmet. Spor, der passerer en brugerdefineret metrik, beholdes som demonstrationer. Hvert dspy.Predict-modul inden for programmet får sit eget kuraterede sæt demonstrationer.

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

1. Bootstrap: Generer kandidat-demonstrationssæt
2. Foreslå: Generer kandidat-instruktionstekster, der er bevidste om både datadistributionen og demonstrationerne
3. Søg: Bayesiansk optimering over det kombinerede rum af instruktioner x demonstrationer på tværs af alle moduler

Parametre som max_bootstrapped_demos (genererede eksempler) og max_labeled_demos (fra træningsdata) styrer, hvor mange eksempler der ender i hvert moduls prompt.

Fastlåst efter kompilering

Når de er kompileret, gemmes demonstrationer i hvert Predict-moduls demos-attribut og formateres ind i prompten ved hvert LLM-kald. De ændres ikke ved runtime — “færdigheden” er frosset.

Dette betyder, at DSPy-færdigheder er de mest forudsigelige i vores sammenligning: tokenomkostningen er kendt efter kompilering, der er ingen variation mellem ture, og agenten ser altid de samme demonstrationer. Ulempen er ufleksibilitet — for at ændre færdigheder skal du genkompilere.

Persistens

Kompilerede programmer serialiseres til JSON, inklusive alle demonstrationer. De er fuldt persistente og indlæselige på tværs af sessioner, hvilket gør DSPy til en af de mest holdbare mekanismer til færdighedslagring.

SuperAGI: Toolkit-baseret forhåndsregistrering

SuperAGI bruger et traditionelt toolkit-mønster, hvor alle værktøjer registreres ved agentinitialisering.

Hvert toolkit udvider BaseToolkit med:

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

Toolkits installeres fra GitHub-repositories via SuperAGI’s værktøjsmanager. Ved agentinitialisering returnerer BaseToolkit.get_tools() alle værktøjer, og deres komplette skemaer eksponeres for LLM’en som funktionskaldsdefinitioner.

Der er ingen udskudt indlæsning, ingen progressiv afsløring og ingen per-tur-filtrering. Hvert registreret værktøjs skema er til stede i hvert kald. Dette er den simpleste injektionsmodel og fungerer godt for agenter med fokuserede, små værktøjssæt, men skalerer ikke til agenter, der har brug for dusinvis af funktioner.

CAMEL-AI: ChatAgent-værktøjsregistrering

CAMEL-AI følger et lignende mønster med forhåndsregistrering. Værktøjer fra forskellige toolkits (f.eks. MathToolkit, SearchToolkit) sendes som en liste til ChatAgent(tools=[...]) ved initialisering.

Frameworket fremhæver, at brugerdefinerede funktioner har brug for klare argumentnavne og omfattende docstrings, så modellen kan forstå brugen — værktøjsskemaet er det eneste “færdigheds”-indhold, modellen ser. Der er ingen separat instruktionsinjiceringsmekanisme.

Nylige tilføjelser inkluderer MCP (Model Context Protocol)-understøttelse via MCPToolkit, der tillader ChatAgent at oprette forbindelse til MCP-servere og registrere eksterne værktøjer. Dette udvider den tilgængelige værktøjsoverflade, men ændrer ikke injektionsmodellen — alle opdagede MCP-værktøjer registreres stadig på forhånd.

Sammenligning på tværs af platforme

Hvornår færdigheder injiceres

Persistensmodeller

Overlevelse ved kontekstkomprimering

Mønsteret med progressiv afsløring

Den mest markante arkitektoniske tendens på tværs af disse platforme er adoptionen af progressiv afsløring — et koncept lånt fra UI-design, hvor information afsløres trinvist baseret på behov.

Hvorfor progressiv afsløring er vigtig

En naiv tilgang til færdighedsinjicering — at indlæse alt på forhånd — skaber to problemer:

1. Tokenspild: De fleste færdigheder er ikke relevante for de fleste ture. At indlæse 20 fulde færdighedsbodies, når kun 1-2 er nødvendige pr. tur, spilder 90%+ af færdighedsrelaterede tokens.
2. Opmærksomhedsudvanding: Forskning i kontekstforringelse viser, at LLM’er præsterer dårligere, når deres kontekst indeholder store mængder irrelevant information. Flere færdigheder i konteksten kan faktisk reducere kvaliteten af færdighedsanvendelse.

Progressiv afsløring løser begge problemer ved at opretholde et let indeks over tilgængelige færdigheder, mens det fulde indhold kun indlæses, når det er nødvendigt.

Implementeringsvariationer

Claude Code bruger et dedikeret system: færdighedsmetadata i system-reminder-meddelelser, et Skill-værktøj til aktivering og ToolSearch til udskudte værktøjsskemaer. Frameworket håndterer injicering automatisk med prioritetsbaseret komprimering.

LangChain Deep Agents bruger agentens eksisterende fillæsningsfunktion: SkillsMiddleware injicerer indekset, og agenten indlæser fuldt indhold via read_file(). Dette er mere gennemsigtigt, men tilbyder mindre optimering på framework-niveau.

OpenAI Responses API bruger navnerumsbaseret gruppering med platformstyret søgning: værktøjsnavnerum giver højniveaubeskrivelser, og tool_search returnerer relevante skemaer. Platformen håndterer søgelogikken fuldstændigt.

Tokenbesparelser i praksis

Tallene er overbevisende. Med 12 færdigheder:

• Altid-aktiv injicering (CrewAI/SuperAGI-stil): ~30.000 tokens
• Progressivt afsløringsindeks alene: ~600 tokens
• Indeks + 2 aktiverede færdigheder: ~2.000-5.000 tokens

Det er en reduktion på 83-98% i færdighedsrelateret tokenforbrug pr. tur. Over en lang session med hundredvis af ture akkumuleres besparelserne dramatisk.

Arkitektoniske mønstre og kompromiser

Når man ser på tværs af alle 11 platforme, opstår fire tydelige arkitektoniske mønstre:

Mønster 1: Altid-aktiv injicering

Brugt af: CrewAI, SuperAGI, CAMEL-AI, Semantic Kernel

Sådan fungerer det: Fuldt færdighedsindhold eller værktøjsskemaer er til stede i hvert LLM-kald.

Fordele:

• Maksimal pålidelighed — agenten har altid fuld ekspertise tilgængelig
• Simpleste implementering — ingen aktiveringslogik nødvendig
• Forudsigelige tokenomkostninger — ens hver tur

Ulemper:

• Tokenomkostning skalerer lineært med antallet af færdigheder
• Opmærksomhedsudvanding med mange færdigheder
• Skalerer ikke ud over ~5-10 færdigheder pr. agent

Bedst til: Fokuserede agenter med 1-3 kernefærdigheder, der altid er relevante.

Mønster 2: Progressiv afsløring

Brugt af: Claude Code, LangChain Deep Agents, OpenAI Responses API/Agents SDK

Sådan fungerer det: Lette metadata altid til stede; fuldt indhold indlæses on-demand.

Fordele:

• Skalerer til dusinvis eller hundredvis af tilgængelige færdigheder
• Minimal tokenomkostning, når færdigheder ikke er nødvendige
• Bevarer prompt-cache, når fulde skemaer tilføjes til sidst

Ulemper:

• Agenten kan overse signalet til at aktivere en relevant færdighed
• Yderligere latenstid fra aktiveringstrinnet
• Mere kompleks framework-implementering

Bedst til: Generelle agenter, der har brug for adgang til mange funktioner, men kun bruger få pr. opgave.

Mønster 3: Semantisk søgning

Brugt af: AutoGen Teachability, Voyager

Sådan fungerer det: Vektordatabaseforespørgsler fremsøger relevante færdigheder/viden baseret på semantisk lighed med den aktuelle kontekst.

Fordele:

• Naturligt begrænset tokenomkostning uanset biblioteksstørrelse
• Indholdsrelevans forbedres over tid, efterhånden som biblioteket vokser
• Læring og akkumulering på tværs af sessioner
• Ingen eksplicit aktivering nødvendig — relevans beregnes automatisk

Ulemper:

• Søgekvalitet afhænger af embedding-modellens kvalitet
• Risiko for at hente forældet eller subtilt forkert information
• Kræver vektordatabaseinfrastruktur
• Mindre forudsigelig — forskellige ture indlæser forskelligt indhold

Bedst til: Agenter, der lærer af erfaring og har brug for at akkumulere domæneviden over tid.

Mønster 4: Kompileret/statisk injicering

Brugt af: DSPy, MetaGPT

Sådan fungerer det: Færdigheder kompileres til fast promptindhold (DSPy) eller aktiveres gennem rigide handlingsskabeloner (MetaGPT).

Fordele:

• Mest forudsigelig adfærd — samme indhold hver gang
• Optimering kan foretages offline (DSPy’s kompilering)
• Ingen runtime-overhead for færdighedsvalg
• Bevist effektiv til veldefinerede, gentagelige opgaver

Ulemper:

• Ufleksibelt — ændring af færdigheder kræver genkompilering (DSPy) eller kodeændringer (MetaGPT)
• Kan ikke tilpasse sig nye situationer uden for de kompilerede eksempler
• DSPy’s kompileringsproces kræver selv mange LLM-kald

Bedst til: Produktionspipelines med veldefinerede opgaver, hvor pålidelighed trumfer fleksibilitet.

Praktiske implikationer for agentbyggere

Valg af det rigtige mønster

Den rigtige færdighedsinjiceringsarkitektur afhænger af din agents profil:

Hvis din agent har en snæver, veldefineret rolle (f.eks. en kodegennemgangsbot, en kundesupportagent for ét produkt), er altid-aktiv injicering (CrewAI/SuperAGI-mønsteret) enklest og mest pålideligt. Tokenomkostningen for 2-3 altid tilstedeværende færdigheder er overkommelig, og du undgår kompleksiteten af aktiveringslogik.

Hvis din agent har brug for brede funktioner, men kun bruger få pr. interaktion (f.eks. en udviklerassistent, en generel automationsagent), er progressiv afsløring (Claude Code/Deep Agents-mønsteret) den klare vinder. De 83-98% tokenbesparelser i skala er for betydelige til at ignorere.

Hvis din agent har brug for at lære og forbedre sig fra interaktioner (f.eks. en personlig assistent, en domæneekspert, der akkumulerer viden), giver semantisk søgning (AutoGen Teachability-mønsteret) den læringsloop, som andre mønstre mangler. Sørg blot for at have kvalitetskontroller på, hvad der optages i vidensbasen.

Hvis din agent kører veldefinerede pipelines (f.eks. databehandling, rapportgenerering, standardiserede arbejdsgange), giver kompileret injicering (DSPy-mønsteret) dig den mest forudsigelige, optimerede adfærd.

Hybridtilgangen

Til produktions-agentteams, hvor agenter skal fungere ud af boksen, anbefaler vi en hybridtilgang:

Kernefærdigheder (1-2 pr. agent, der definerer deres primære domæneekspertise): altid injiceret i systemprompten, CrewAI-stil. Disse er uundværlige funktioner, som agenten har brug for ved hver tur.

Udvidede færdigheder (yderligere funktioner, agenten kan have brug for): kun metadata i systemprompten, indlæst via en søge-/indlæsningsmekanisme, når det er nødvendigt, Deep Agents-stil. Disse udvider agentens funktionssæt uden at betale tokenomkostningen, når de ikke er relevante.

Lært viden (akkumuleret domæneekspertise): gemt i en vektordatabase og hentet semantisk pr. tur, AutoGen-stil. Dette giver agenten mulighed for at forbedre sig over tid uden manuel færdighedsudvikling.

Denne lagdelte arkitektur mapper naturligt til, hvordan en systemprompt bygges: dato → persona → systeminstruktioner → kernefærdigheder → færdighedsindeks → rolle-/teamkontekst. Kernefærdighederne og indekset tilføjer en forudsigelig, overkommelig tokenomkostning, mens de fulde færdighedsbodies kun vises, når det er nødvendigt.

Bedste praksis for tokenbudget på tværs af frameworks

Uanset hvilket injektionsmønster du bruger, gælder disse tokenhåndteringsstrategier universelt:

Cache-venlig ordning

Stak uforanderlig kontekst (systeminstruktioner, værktøjsskemaer) forrest i prompten. Hos udbydere, der understøtter prompt-caching, koster cachede tokens 75% mindre. Claude Code og OpenAI injicerer begge opdagede værktøjsskemaer i slutningen af konteksten specifikt for at bevare cache-hits på det statiske prefix.

Aflastning

Opsummer værktøjsresponser i stedet for at beholde fulde resultater i konteksten. Gem de komplette data i eksterne referencer, som agenten kan læse on-demand. Dette er især vigtigt for agenter, der laver mange værktøjskald pr. session.

Reduktion

Komprimer samtalehistorik gennem opsummering. Udtræk nøglefakta fra lange udvekslinger til kondenserede repræsentationer. Ethvert framework med sessionsbaseret persistens drager fordel af aggressiv historikhåndtering.

Søgning frem for forhåndsindlæsning

Hent dynamisk relevant information ved runtime i stedet for at indlæse alt på forhånd. Dette gælder for færdigheder, vidensbaser og endda samtalehistorik. Studier viser, at dette kan reducere promptstørrelser med op til 70%.

Isolering

Brug underagenter til specifikke opgaver, så hver agents kontekst forbliver fokuseret. I stedet for at give én agent 20 færdigheder, opret et team af 5 agenter med 4 færdigheder hver. Hver agent opretholder et slankt kontekstvindue, og teamet dækker kollektivt det fulde funktionssæt.

Konklusion

Måden AI-agent-frameworks injicerer færdigheder i kontekst på er en af de mest konsekvensrige arkitekturbeslutninger i agentdesign — og alligevel diskuteres den sjældent på dette detaljeringsniveau.

Feltet konvergerer tydeligt mod progressiv afsløring som det foretrukne mønster for generelle agenter, hvor Claude Code, LangChain Deep Agents og OpenAI alle uafhængigt er nået frem til lignende trelagsarkitekturer. I mellemtiden betjener specialiserede mønstre som semantisk søgning (AutoGen, Voyager) og kompileret injicering (DSPy) vigtige nicher, som progressiv afsløring alene ikke adresserer.

For praktikere, der bygger agentsystemer i dag, er den centrale indsigt, at færdighedsinjicering ikke er et problem med én løsning, der passer til alle. Den rigtige tilgang afhænger af din agents rolle, antallet af færdigheder den har brug for, om den har brug for at lære over tid, og din tolerance for kompromiser mellem tokenomkostninger og pålidelighed.

De mest robuste produktionssystemer vil sandsynligvis kombinere flere mønstre — altid-aktiv for kernefunktioner, progressiv afsløring for udvidede færdigheder og semantisk søgning for akkumuleret viden — og dermed skabe agenter, der er både effektive og eksperter.