Kuinka tekoälyagentit toteuttavat taitoja käytännössä: Kattava alustavertailu

Johdanto

Jokainen tekoälyagenttikehys kohtaa saman perustavanlaatuisen kysymyksen: kuinka tehdä kielimallista hyvä jossakin tietyssä asiassa? Mallilla itsellään on laaja yleistietämys, mutta kun tarvitset sitä suorittamaan koodikatselmointia, käyttöönottamaan infrastruktuuria tai navigoimaan Minecraftissa — se tarvitsee erikoistuneita ohjeita, työkalupääsyn ja toimialakontekstin.

Tämä on taitojen syöttämisen ongelma. Ja jokainen merkittävä kehys ratkaisee sen eri tavalla.

Jotkut alustat syöttävät kaiken järjestelmäkehotteeseen etukäteen. Toiset käyttävät laiskaa latausta paljastaen ominaisuuksia vasta, kun agentti tarvitsee niitä. Muutamat käyttävät vektoritietokantoja hakeakseen relevantteja taitoja semanttisen samankaltaisuuden perusteella. Erot eivät ole akateemisia — ne vaikuttavat suoraan tokenikustannuksiin, agentin luotettavuuteen ja siihen, kuinka montaa taitoa agentti voi realistisesti hallita.

Analysoimme 11 merkittävää tekoälyagenttialustaa ymmärtääksemme tarkalleen, mihin taidot sijoittuvat kehotteessa, milloin ne latautuvat, paljonko ne maksavat tokeneina ja miten ne selviävät konteksti-ikkunan täyttyessä. Tämä ei ole pintapuolinen ominaisuusvertailu. Tutkimme lähdekoodia, dokumentaatiota ja arkkitehtuurikaavioita kartoittaaksemme kunkin alustan tarkat syöttömekanismit.

Kokonaisvertailutaulukko

Tässä on kokonaiskatsaus ennen yksityiskohtiin syventymistä.

Syöttömekanismit: Mihin, milloin ja miten

Pysyvyys, tokenikustannus ja jatkuva läsnäolo

Valmis kasvattamaan liiketoimintaasi?

Aloita ilmainen kokeilujakso tänään ja näe tulokset muutamassa päivässä.

Pyydä demo Kirjaudu sisään

Mitä “taitojen syöttäminen” todella tarkoittaa

Ennen vertailuun syventymistä määritellään ongelmakenttä. Tekoälyagentin konteksti-ikkuna — kokonaisteksti, jonka kielimalli näkee jokaisella kutsulla — on kiinteän kokoinen. Jokainen ohjeen, keskusteluhistorian, työkalumäärittelyn ja haetun datan tokeni kilpailee paikasta tässä ikkunassa.

“Taito” agenttikontekstissa on mikä tahansa rakenteellinen asiantuntemuspaketti, joka muuttaa agentin käyttäytymistä. Tämä voi olla:

• Ohjeita, jotka kertovat agentille, miten lähestyä tiettyä toimialaa (koodikatselmointiohjeet, käyttöönottotarkistuslistat)
• Työkalumäärittelyjä, jotka antavat agentille kutsuttavia funktioita (API-integraatiot, tiedosto-operaatiot)
• Few-shot-esimerkkejä, jotka näyttävät agentille, miltä hyvä tuotos näyttää
• Haettua tietoa vektoritietokannoista tai ulkoisista dokumenteista

Syöttömekanismi — missä ja milloin tämä sisältö tulee kontekstiin — määrittää kolme kriittistä ominaisuutta:

1. Tokenitehokkuus: Kuinka monta tokenia taito kuluttaa, ja maksetaanko tämä kustannus myös silloin, kun taitoa ei tarvita?
2. Luotettavuus: Käyttääkö agentti taitoa johdonmukaisesti, kun se on relevantti, vai voiko se ohittaa vihjeen?
3. Skaalautuvuus: Kuinka moneen taitoon agentti pääsee käsiksi ennen kuin kontekstin paisuminen heikentää suorituskykyä?

Jokainen kehys tekee erilaisia kompromisseja näiden kolmen ulottuvuuden välillä. Tarkastellaan jokaista.

Syöttökirjo: Aina päällä olevasta tarvittaessa ladattavaan

Kaikilla 11 alustalla taitojen syöttämistavat asettuvat kirjolle “kaikki ladattu etukäteen” ja “mitään ei ladattu ennen kuin nimenomaisesti tarvitaan” välillä.

Toisessa päässä alustat kuten CrewAI, SuperAGI ja CAMEL-AI syöttävät jokaisen aktivoidun taidon täyden sisällön jokaiseen kielimallikutsuun. Agentilla on aina täysi asiantuntemuksensa käytettävissä. Yksinkertaista, luotettavaa, mutta kallista tokeneina.

Toisessa päässä Claude Code, LangChain Deep Agents ja OpenAI:n Responses API käyttävät progressiivista paljastamista — agentti näkee käynnistyksessä vain taitojen nimet ja lyhyet kuvaukset, ja täysi sisältö latautuu tarvittaessa. Tehokasta, skaalautuvaa, mutta vaatii agentin tunnistamaan, milloin se tarvitsee taitoa.

Keskivaiheilla AutoGen Teachability ja Voyager käyttävät semanttista hakua syöttääkseen vain relevantimmat taidot per vuoro, luoden dynaamisen, kontekstiherkän syöttömallin.

Ja sitten on ainutlaatuisia lähestymistapoja: DSPy kääntää optimoituja few-shot-esimerkkejä offline ja upottaa ne pysyvästi moduulikehotteisiin. MetaGPT koodaa taidot toimintopohjiksi, jotka aktivoituvat vain kun tietty rooli siirtyy tiettyyn toimintoon.

Tarkastellaan jokaista yksityiskohtaisesti.

Liity uutiskirjeellemme

Saa uusimmat vinkit, trendit ja tarjoukset ilmaiseksi.

Sähköpostiosoite

Tilaa

Claude Code: Kolmitasoinen progressiivinen paljastaminen

Claude Code toteuttaa yhden kehittyneimmistä taitojen syöttöarkkitehtuureista käyttäen kolmitasoista progressiivista paljastamisjärjestelmää, joka tasapainottaa tietoisuutta ja tokenitehokkuutta.

Taso 1: Aina kontekstissa

Istunnon alussa jokaisen saatavilla olevan taidon nimi ja kuvaus syötetään system-reminder-viestiin — metatietolohkoon, jonka malli näkee aina. Tämä maksaa noin 250 merkkiä per taito kuluttaen noin 1 % konteksti-ikkunabudjetista kaikille taitokuvauksille yhteensä (noin 8K merkkiä varabudjetiksi, ohitettavissa SLASH_COMMAND_TOOL_CHAR_BUDGET-ympäristömuuttujalla).

Vastaavasti viivästetyt työkalut — työkalut, joiden täysiä JSON-skeemoja ei ole vielä ladattu — näkyvät pelkkänä nimilistana system-reminder-lohkoissa. Claude Code v2.1.69:stä lähtien jopa sisäänrakennetut järjestelmätyökalut kuten Bash, Read, Edit, Write, Glob ja Grep on viivästetty ToolSearchin taakse, mikä vähentää järjestelmätyökalujen kontekstin noin 14–16K tokenista noin 968 tokeniin.

Agentti näkee tarpeeksi tietääkseen, mitä on saatavilla, maksamatta täysien määrittelyjen tokenikustannusta.

Taso 2: Aktivoinnissa

Kun käyttäjä kirjoittaa kauttaviiva-komennon (esim. /commit) tai malli tunnistaa taidon automaattisesti sen kuvauksen perusteella, täysi SKILL.md-runko ladataan keskusteluviestinä Skill-työkalun kautta. Tämä runko sisältää täydelliset ohjeet — joskus tuhansia tokeneita yksityiskohtaista ohjausta.

Keskeinen yksityiskohta: Komentotulkin esikäsittely suoritetaan ensin (kaikki !command-direktiivit taitotiedostossa suoritetaan ja niiden tuloste korvaa direktiivin), ja latauksen jälkeen taidon runko pysyy keskustelussa istunnon loppuun asti.

Taso 3: Tarvittaessa

Lisäresurssit — viitedokumentit, skriptit, resurssitiedostot — luetaan vain, kun malli nimenomaisesti päättää käyttää Read-työkalua päästäkseen niihin. Ne eivät koskaan lataudu automaattisesti.

Kontekstin tiivistämiskäyttäytyminen

Kun keskustelu lähestyy kontekstirajaa ja tiivistäminen käynnistyy, Claude Code liittää uudelleen viimeksi käytetyt taidot 5K tokenin budjetilla per taito ja 25K yhdistetyllä enimmäismäärällä. Viimeksi käytetyt taidot saavat etusijan. Vanhemmat taidot voidaan pudottaa kokonaan.

Tämä kolmitasoinen arkkitehtuuri tarkoittaa, että agentti, jolla on yli 20 saatavilla olevaa taitoa, maksaa minimaalisen alkukustannuksen, mutta pääsee käsiksi minkä tahansa niistä täyteen asiantuntemukseen yhdellä vuorolla.

CrewAI: Täysi syöttö jokaiseen tehtäväkehotteeseen

CrewAI ottaa päinvastaisen lähestymistavan progressiiviseen paljastamiseen nähden. Kun taito on aktivoitu agentille, sen täysi sisältö syötetään jokaiseen tehtäväkehotteeseen, jonka agentti suorittaa.

Miten se toimii

Taidot CrewAI:ssa ovat itsenäisiä hakemistoja, joissa jokaisella on SKILL.md-tiedosto YAML-otsikkotiedoilla (nimi, kuvaus, lisenssi, yhteensopivuus, sallitut työkalut) ja markdown-runko. Taitojärjestelmä erottaa taidot ja työkalut toisistaan: taidot syöttävät ohjeita ja kontekstia, jotka muokkaavat agentin ajattelutapaa, kun taas työkalut tarjoavat kutsuttavia funktioita toimintoihin.

Agentin alustuksen aikana Agent.set_skills() kutsuu discover_skills()-metodia skannatakseen taitohakemistoja metatietotasolla, ja sitten activate_skill()-metodia lukeakseen taitojen täydet rungot. Tehtävän suorituksen aikana _finalize_task_prompt() kutsuu format_skill_context()-metodia jokaiselle aktivoidulle taidolle ja liittää kaiken muotoillun taitosisällön tehtäväkehotteeseen.

Kielimalli vastaanottaa: [järjestelmäviesti] + [tehtäväkehote + KAIKKI taitosisällöt]

Tokenivaikutukset

CrewAI asettaa pehmeän varoituksen 50 000 merkkiin per taito, mutta ei kovaa rajaa. Dokumentaatio suosittelee pitämään taidot kohdennettuina ja tiiviinä, koska suuret kehoteinjektiot laimentavat mallin huomiokykyä — todellinen huolenaihe kontekstirapautumista koskevan tutkimuksen valossa.

Kompromissi on suoraviivainen: agentilla on aina täysi asiantuntemus käytettävissä (korkea luotettavuus), mutta tokenikustannus skaalautuu lineaarisesti taitojen määrän mukaan per tehtävä (matala tehokkuus). Agenteille, joilla on 1–2 kohdennettua taitoa, tämä toimii hyvin. Agenteille, jotka tarvitsevat laajoja kyvykkyyksiä, siitä tulee nopeasti kallista.

Ei tehtävien välistä pysyvyyttä

Jokainen tehtävä saa tuoreen syötön. Taitosisältöä ei kerry tehtävien välillä — mikä on itse asiassa ominaisuus, ei bugi. Se tarkoittaa, että jokainen tehtävä alkaa puhtaalla kontekstilla välttäen vanhentumisongelmia, joita istuntopohjainen pysyvyys voi aiheuttaa.

LangChain Deep Agents: Agentin hallitsema lataus SkillsMiddlewaren kautta

LangChain Deep Agents toteuttaa kehittyneen väliohjelmistopohjaisen taitojärjestelmän, jossa agentti itse päättää, milloin ladata täysi taitosisältö — todellinen progressiivisen paljastamisen malli, jossa agentti hallitsee aktivointia.

Kolme tasoa

Taso 1 (Indeksi): SkillsMiddleware jäsentää kaikkien SKILL.md-tiedostojen otsikkotiedot käynnistyksessä ja syöttää kevyen indeksin järjestelmäkehotteeseen. Tämä indeksi sisältää vain nimet ja kuvaukset, ja maksaa noin 278 tokenia per taito verrattuna 3 302 tokeniin täydelle sisällölle.

Taso 2 (Täysi sisältö): Kun agentti toteaa taidon relevantiksi, se kutsuu read_file()-metodia taidon SKILL.md-polkuun. Tämä on tavallinen työkalukutsu — kehys ei syötä runkoa; agentti tekee tietoisen päätöksen ladata se. Täysi sisältö tulee keskusteluhistoriaan työkalutuloksena.

Taso 3 (Syväsukellus): Tukimateriaalit, viitedokumentit ja skriptit avataan vain, kun agentti nimenomaisesti lukee ne.

Tokenitehokkuus käytännössä

12 taidolla progressiivinen paljastaminen vähentää kontekstin noin 30 000 tokenista (kaikki ladattu) noin 600 tokeniin (pelkkä indeksi), laajentuen 2 000–5 000 tokeniin kun relevantit taidot ladataan tiettyä tehtävää varten. Se on potentiaalisesti 83–98 % vähennys taitoon liittyvässä tokeninkulutuksessa.

Useita taitolähteitä voidaan kerrostaa, ja nimien törmätessä viimeisin lähde voittaa. Yli 10 megatavun tiedostot ohitetaan automaattisesti.

Keskeinen ero Claude Codeen

Kun Claude Code käyttää erillistä Skill-työkalua latauksen käynnistämiseen, Deep Agents hyödyntää agentin olemassa olevaa read_file-työkalua. Tämä tarkoittaa, että latausmekanismi on läpinäkyvä — agentti lukee taitotiedostoja samalla tavalla kuin mitä tahansa muuta tiedostoa. Haittapuolena on, ettei ole erityistä tiivistämiskäyttäytymistä: keskusteluhistoriaan tuleva taitosisältö on tavallisen LangChain-viestitrimmauksen alainen ilman erityiskohtelua.

OpenAI Responses API ja Agents SDK: Alustan hallinnoima viivästetty lataus

OpenAI toteuttaa taitojen syöttämisen kahdella erillisellä mutta filosofisesti yhtenäisellä mekanismilla: Responses API:n tool_search-työkalutyypillä ja Agents SDK:n ToolSearchTool-komponentilla.

Responses API: tool_search

tool_search-työkalutyyppi (saatavilla GPT-5.4+:ssa) mahdollistaa kehittäjille suurten työkalupintojen viivästämisen ajoaikaan. Kolme viivästämisstrategiaa on käytettävissä:

• Yksittäisen funktion viivästäminen: @function_tool(defer_loading=True) — malli näkee funktion nimen ja kuvauksen, mutta parametriskeema on viivästetty. Säästää parametritason tokeneita.
• Nimiavaruuden viivästäminen: tool_namespace(name=..., description=..., tools=[...]) — ryhmittää funktiot yhden nimiavaruuden alle. Malli näkee vain nimiavaruuden nimen ja kuvauksen, mikä säästää merkittävästi enemmän tokeneita.
• MCP-palvelimen viivästäminen: HostedMCPTool(tool_config={..., "defer_loading": True}) — viivästää kokonaisia MCP-palvelimen työkalupintoja.

Kun malli toteaa tarvitsevansa tietyn työkalun, se tekee tool_search-kutsun. API palauttaa 3–5 relevanttia työkalumäärittelyä, jotka syötetään konteksti-ikkunan loppuun kehotevälimuistin säilyttämiseksi.

Agents SDK: ToolSearchTool

Agents SDK tarjoaa ohjelmallisen vastineen. Työkalunimiavaruudet rekisteröidään mutta ei ladata:

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

Ajoaikana agentti näkee vain nimiavaruuksien nimet. Se kutsuu ToolSearchTool("crm")-metodia löytääkseen ja ladatakseen täydet skeemat, minkä jälkeen se voi kutsua yksittäisiä työkaluja kyseisessä nimiavaruudessa.

Ei pyyntöjen välistä pysyvyyttä

Jokainen API-pyyntö on itsenäinen. Löydetyt työkalut eivät säily kutsujen välillä. Tämä on vertailumme tilattömin lähestymistapa — siisti, ennustettava, mutta vaatii uudelleenlöytämistä jokaisella pyynnöllä, jos työkalut muuttuvat.

AutoGen Teachability: Vuorokohtainen semanttinen haku

AutoGenin Teachability-ominaisuus ottaa perustavanlaatuisesti erilaisen lähestymistavan kuin mikään muu kehys tässä vertailussa. Sen sijaan, että syötettäisiin staattista taitosisältöä, se hakee dynaamisesti relevantteja “muistioita” ChromaDB-vektoritietokannasta jokaisella vuorolla.

Vuorokohtainen hakusilmukka

Teachability rekisteröi koukun process_last_received_message-tapahtumaan, joka kaappaa jokaisen saapuvan käyttäjäviestin ennen kuin agentti käsittelee sen:

1. TextAnalyzerAgent poimii avainasiat saapuvasta viestistä
2. Näitä käytetään ChromaDB-kyselyihin (oletuksena Sentence Transformer -upotuksilla)
3. Top-K relevantimmat muistiot haetaan (konfiguroitavissa max_num_retrievals-parametrilla, oletus 10)
4. Haetut muistiot liitetään viestitekstin jatkeeksi ennen kuin agentti näkee sen

Kriittisesti: muokattu viesti ei tallennu keskusteluhistoriaan — vain alkuperäinen viesti tallennetaan. Tämä estää muistiosisällön kasaantumisen vuorojen välillä.

Oppimissilmukka

Kielimallin vastauksen jälkeen toinen koukku analysoi vastauksen uusien oivallusten varalta:

1. TextAnalyzerAgent tunnistaa uutta tietoa vastauksesta
2. Uudet muistiot poimitaan avain-arvo-pareina (syöteteksti → tulosteteksti)
3. Nämä muistiot tallennetaan ChromaDB:hen, käytettävissä tuleville vuoroille ja istunnoille

Tämä luo aidon oppimissilmukan, jossa agentti kerryttää asiantuntemusta ajan myötä.

Istuntojen välinen pysyvyys

AutoGen Teachability on yksi vain kolmesta alustasta vertailussamme (Voyagerin ja DSPy:n ohella), joka säilyttää taidot istuntojen välillä. ChromaDB-tietokanta sijaitsee levyllä, mikä tarkoittaa, että agentti voi oppia maanantain vuorovaikutuksista ja soveltaa tietoa perjantaina.

recall_threshold-parametri (oletus 1.5) hallitsee, kuinka samankaltainen viestin täytyy olla tallennetun muistion kanssa hakua varten, ja reset_db voi tyhjentää koko muistin tarvittaessa.

Tokenitehokkuus

Koska vain relevantit muistiot syötetään per vuoro (tyypillisesti 3–5), tokenikustannus on luonnollisesti rajattu riippumatta siitä, kuinka suureksi muistiotietokanta kasvaa. Agentti, jolla on 10 000 tallennettua muistiota, maksaa silti vain niistä kourallisesta, jotka ovat relevantimpia nykyiselle vuorolle.

Semantic Kernel: Liitännäisskeemat jatkuvasti läsnä olevina työkalumäärittelyinä

Microsoftin Semantic Kernel ottaa suoraviivaisen lähestymistavan: liitännäiset ovat KernelFunction-objektien kokoelmia, jotka rekisteröidään Kerneliin, ja niiden skeemat näytetään kielimallille funktiokutsun työkalumäärittelyinä.

Kaksi syöttöpolkua

Funktiokutsuminen: Kun ToolCallBehavior.AutoInvokeKernelFunctions on asetettu, kaikki rekisteröidyt funktiot lähetetään kielimallille käytettävissä olevina työkaluina jokaisessa API-pyynnössä. Kielimalli päättää, mitä kutsua; Semantic Kernel hoitaa kutsumisen ja tulosten reitityksen.

Kehotepohjat: Semantic Kernelin pohjasyntaksi ({{plugin.function}}, Handlebars tai Liquid) mahdollistaa funktioiden kutsumisen inline-muodossa kehotteen renderöinnin aikana. Tulokset upotetaan suoraan kehotetekstiin ennen kuin se saavuttaa kielimallin — eräänlainen ahkera evaluointi laiskan työkalukutsun sijaan.

Ei progressiivista paljastamista

Jokaisen rekisteröidyn liitännäisen skeema sisällytetään jokaiseen API-kutsuun. Ei ole sisäänrakennettua viivästettyä latausta, nimiavaruusryhmittelyä tai tarvittaessa aktivointia. Dokumentaatio suosittelee nimenomaisesti tuomaan vain tiettyyn skenaarioon tarvittavat liitännäiset tokeninkulutuksen ja virheellisten kutsujen vähentämiseksi.

Tämä tekee Semantic Kernelistä yhden ennustettavimmista alustoista — tiedät aina tarkalleen, mihin agentti pääsee käsiksi — mutta se rajoittaa skaalautuvuutta. Agentti, jolla on 50 rekisteröityä funktiota, maksaa täyden skeemakustannuksen jokaisella yksittäisellä kutsulla.

Pysyvyys

Liitännäisten rekisteröinti on Kernel-instanssikohtaista ja muistissa. Ei ole sisäänrakennettua mekanismia istuntojen väliseen taitojen pysyvyyteen.

MetaGPT: Toimintopohjat roolipohjaisten standarditoimintaohjeiden sisällä

MetaGPT koodaa taidot ei erillisinä paketteina vaan toimintopohjina, jotka on upotettu standarditoimintaohjeisiin (SOP), jotka ohjaavat roolien käyttäytymistä.

Rooli- ja toimintoarkkitehtuuri

Jokaisella Role-luokalla MetaGPT:ssä on kehotteisiin syötettävä persoonaetuliite ja joukko Action-luokkia. Jokainen Action sisältää kielimalliproksin, jota kutsutaan aask()-metodilla ja joka käyttää luonnollisen kielen kehotepohjia kielimallikutsun jäsentämiseen.

Kun Role._act() laukeaa, se tukee kolmea reaktiotilaa:

• "react": Kielimalli valitsee toimintoja dynaamisesti ajattele-toimi-silmukoissa
• "by_order": Toiminnot suoritetaan peräkkäin ennalta määrätyssä järjestyksessä
• "plan_and_act": Agentti suunnittelee ensin, sitten suorittaa toiminnot suunnitelman mukaan

Kapea syöttöikkuna

Vain nykyisen Toiminnon kehostepohja on aktiivinen minä tahansa ajankohtana. Agentti ei näe muiden toimintojen pohjia — se näkee vain roolietuliitteensä ja kyseisen toiminnon kontekstin. Tämä on kapein syöttöikkuna kaikista tutkimistamme kehyksistä.

Action-luokkien kontekstin jäsennysfunktiot poimivat relevantin tiedon syötteistä, joten jokainen toiminto saa kuratoidun osajoukon käytettävissä olevasta kontekstista täyden keskusteluhistorian sijaan.

Yksivuoroinen pysyvyys

Pohja renderöidään tuoreena jokaista toiminnon suoritusta varten. Ei ole kertymistä eikä istuntojen välistä pysyvyyttä. Tämä pitää jokaisen toiminnon kohdennettuna, mutta tarkoittaa, ettei agentti voi rakentaa aiemmin ladatun taitosisällön päälle yksittäisen työnkulun sisällä.

Voyager: Upotuspohjainen taitojen haku elinikäiseen oppimiseen

Voyager, NVIDIAn ja Caltechin Minecraft-tutkimusagentti, toteuttaa yhden tyylikkäimmistä taitojen syöttöarkkitehtuureista: kasvavan kirjaston verifioituja ohjelmia, jotka haetaan upotussimilaarisuudella.

Taitokirjasto

Kun Voyager kirjoittaa koodia, joka läpäisee itseveifioinnin (generoitu Mineflayer JavaScript toimii oikeasti pelissä), koodi ja sen dokumentaatiomerkkijono tallennetaan vektoritietokantaan. Dokumentaatiomerkkijonon upotus muodostuu hakuavaimeksi.

Tehtäväkohtainen haku

Kullakin automaattisen opetussuunnitelman ehdottamalla uudella tehtävällä:

1. Tehtäväkuvaus ja ympäristöpalaute upotetaan
2. Kosinisimilaarisuushaku kaikkia tallennettuja taitoupotuksia vastaan
3. Top-5 relevantimmat taidot haetaan
4. Haettu taitokoodi sisällytetään toiminta-agentin kehotteeseen few-shot-esimerkkeinä

Kehote näyttää tältä:

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

Generoitu koodi voi kutsua haettuja taitoja nimellä, mikä mahdollistaa kompositionaalisen taitojen rakentamisen — monimutkaiset käyttäytymiset rakennetaan yksinkertaisemmista, verifioiduista perusosista.

Elinikäinen pysyvyys

Taitokirjasto on keskeinen “elinikäisen oppimisen” mekanismi. Se kasvaa agentin koko elinajan ajan, ja uudet taidot rakentuvat vanhojen päälle. Toisin kuin useimmissa kehyksissä, joissa ihmiset laativat taidot, Voyagerin taidot generoidaan, verifioidaan ja tallennetaan agentin itsensä toimesta.

Tokenikustannus on luonnollisesti rajattu: riippumatta siitä, sisältääkö kirjasto 50 vai 5 000 taitoa, jokainen tehtävä maksaa vain 5 relevantimmasta hausta.

DSPy: Käännetyt few-shot-esimerkit jäädytettyinä taitoina

DSPy ottaa radikaalisti erilaisen lähestymistavan kuin mikään muu kehys. Sen sijaan, että taitoja syötettäisiin ajoaikana, DSPy kääntää optimaaliset few-shot-demonstraatiot offline ja upottaa ne pysyvästi moduulikehotteisiin.

Kääntämisprosessi

Kaksi pääoptimoijaa hoitaa kääntämisen:

BootstrapFewShot: Käyttää opettajamoduulia jälkien generoimiseen ohjelman läpi. Jäljet, jotka läpäisevät käyttäjän määrittelemän metrikan, säilytetään demonstraatioina. Jokainen dspy.Predict-moduuli ohjelman sisällä saa oman kuratoidun demonstraatiokokoelmansa.

MIPROv2 (Multi-prompt Instruction Proposal Optimizer v2): Kolmivaiheinen prosessi:

1. Bootstrap: Generoi ehdokasdemonstratiokokoelmia
2. Ehdota: Generoi ehdokasohjeitatekstejä, jotka ovat tietoisia sekä datajakaumasta että demonstraatioista
3. Haku: Bayesilainen optimointi ohjeiden x demonstraatioiden yhdistetyssä avaruudessa kaikkien moduulien välillä

Parametrit kuten max_bootstrapped_demos (generoidut esimerkit) ja max_labeled_demos (harjoitusdatasta) hallitsevat, kuinka monta esimerkkiä päätyy kunkin moduulin kehotteeseen.

Kiinteä kääntämisen jälkeen

Käännettynä demonstraatiot tallennetaan kunkin Predict-moduulin demos-attribuuttiin ja muotoillaan kehotteeseen jokaisella kielimallikutsulla. Ne eivät muutu ajoaikana — “taito” on jäädytetty.

Tämä tarkoittaa, että DSPy:n taidot ovat vertailumme ennustettavimpia: tokenikustannus tiedetään kääntämisen jälkeen, vuorojen välillä ei ole vaihtelua, ja agentti näkee aina samat demonstraatiot. Haittapuolena on joustamattomuus — taitojen muuttamiseksi on käännettävä uudelleen.

Pysyvyys

Käännetyt ohjelmat sarjallistuvat JSON-muotoon, mukaan lukien kaikki demonstraatiot. Ne ovat täysin pysyviä ja ladattavissa istuntojen välillä, mikä tekee DSPy:stä yhden kestävimmistä taitojen tallennusmekanismeista.

SuperAGI: Työkalupakin perusteella tapahtuva etukäteisrekisteröinti

SuperAGI käyttää perinteistä työkalupakin mallia, jossa kaikki työkalut rekisteröidään agentin alustuksessa.

Jokainen työkalupakki laajentaa BaseToolkit-luokkaa:

• name- ja description-attribuutit
• get_tools()-metodi, joka palauttaa listan BaseTool-instansseja
• get_env_keys() vaadituille ympäristömuuttujille

Työkalupakit asennetaan GitHub-repositorioista SuperAGI:n työkaluhallinnan kautta. Agentin alustuksessa BaseToolkit.get_tools() palauttaa kaikki työkalut, ja niiden täydelliset skeemat näytetään kielimallille funktiokutsumäärittelyinä.

Ei viivästettyä latausta, ei progressiivista paljastamista eikä vuorokohtaista suodatusta. Jokaisen rekisteröidyn työkalun skeema on läsnä jokaisessa kutsussa. Tämä on yksinkertaisin syöttömalli ja toimii hyvin agenteille, joilla on kohdennettuja, pieniä työkalupakkeja, mutta ei skaalaudu agenteille, jotka tarvitsevat kymmeniä ominaisuuksia.

CAMEL-AI: ChatAgent-työkalurekisteröinti

CAMEL-AI noudattaa samankaltaista etukäteisrekisteröintimallia. Eri työkalupakien (esim. MathToolkit, SearchToolkit) työkalut annetaan listana ChatAgent(tools=[...])-kutsussa alustuksen yhteydessä.

Kehys korostaa, että mukautetuilla funktioilla täytyy olla selkeät argumenttien nimet ja kattavat dokumentaatiomerkkijonot, jotta malli ymmärtää käytön — työkaluskeema on ainoa “taitosisältö”, jonka malli näkee. Erillistä ohjeiden syöttömekanismia ei ole.

Viimeaikaisia lisäyksiä ovat MCP (Model Context Protocol) -tuki MCPToolkit-luokan kautta, mikä mahdollistaa ChatAgent-luokan yhdistämisen MCP-palvelimiin ja ulkoisten työkalujen rekisteröinnin. Tämä laajentaa käytettävissä olevaa työkalupintaa, mutta ei muuta syöttömallia — kaikki löydetyt MCP-työkalut rekisteröidään silti etukäteen.

Alustojen välinen vertailu

Milloin taidot syötetään

Pysyvyysmallit

Kontekstin tiivistämisen selviytyminen

Progressiivisen paljastamisen malli

Merkittävin arkkitehtuurinen trendi näillä alustoilla on progressiivisen paljastamisen omaksuminen — käyttöliittymäsuunnittelusta lainattu konsepti, jossa tietoa paljastetaan asteittain tarpeen mukaan.

Miksi progressiivinen paljastaminen on tärkeää

Naiivi lähestymistapa taitojen syöttämiseen — kaiken lataaminen etukäteen — aiheuttaa kaksi ongelmaa:

1. Tokenien tuhlaus: Useimmat taidot eivät ole relevantteja useimmilla vuoroilla. 20 täyden taitosisällön lataaminen, kun vain 1–2 tarvitaan per vuoro, tuhlaa yli 90 % taitoihin liittyvistä tokeneista.
2. Huomion laimentuminen: Kontekstirapautumista koskeva tutkimus osoittaa, että kielimallit suoriutuvat heikommin, kun niiden konteksti sisältää suuria määriä irrelevanttia tietoa. Enemmän taitoja kontekstissa voi itse asiassa heikentää taidon soveltamisen laatua.

Progressiivinen paljastaminen ratkaisee molemmat ongelmat ylläpitämällä kevyen indeksin saatavilla olevista taidoista samalla kun täysi sisältö ladataan vain tarvittaessa.

Toteutusten variaatiot

Claude Code käyttää erillistä järjestelmää: taitojen metatieto system-reminder-viesteissä, Skill-työkalu aktivointiin ja ToolSearch viivästettyjen työkaluskeemojen hakuun. Kehys hallinnoi syöttämistä automaattisesti prioriteettipohjaisella tiivistämisellä.

LangChain Deep Agents käyttää agentin olemassa olevaa tiedostonlukukykyä: SkillsMiddleware syöttää indeksin, ja agentti lataa täyden sisällön read_file()-metodilla. Tämä on läpinäkyvämpää mutta tarjoaa vähemmän kehystason optimointia.

OpenAI Responses API käyttää nimiavaruuspohjaista ryhmittelyä alustan hallinnoimalla haulla: työkalunimiavaruudet tarjoavat korkean tason kuvauksia, ja tool_search palauttaa relevantit skeemat. Alusta hoitaa hakulogiikan kokonaan.

Tokenisäästöt käytännössä

Luvut ovat vakuuttavia. 12 taidolla:

• Aina päällä oleva syöttö (CrewAI/SuperAGI-tyyli): ~30 000 tokenia
• Progressiivisen paljastamisen pelkkä indeksi: ~600 tokenia
• Indeksi + 2 aktivoitua taitoa: ~2 000–5 000 tokenia

Se on 83–98 % vähennys taitoihin liittyvässä tokeninkulutuksessa per vuoro. Pitkän istunnon aikana satojen vuorojen myötä säästöt kertautuvat dramaattisesti.

Arkkitehtuurimallit ja kompromissit

Kaikilla 11 alustalla tarkasteltuna erottuu neljä erillistä arkkitehtuurimallia:

Malli 1: Aina päällä oleva syöttö

Käyttäjät: CrewAI, SuperAGI, CAMEL-AI, Semantic Kernel

Miten se toimii: Täysi taitosisältö tai työkaluskeemat ovat läsnä jokaisessa kielimallikutsussa.

Edut:

• Maksimaalinen luotettavuus — agentilla on aina täysi asiantuntemus käytettävissä
• Yksinkertaisin toteutus — aktivointilogiikkaa ei tarvita
• Ennustettavat tokenikustannukset — samat joka vuorolla

Haitat:

• Tokenikustannus skaalautuu lineaarisesti taitojen määrän mukaan
• Huomion laimentuminen monilla taidoilla
• Ei skaalaudu yli ~5–10 taidon per agentti

Parasta: Kohdennetuille agenteille, joilla on 1–3 ydintaitoa, jotka ovat aina relevantteja.

Malli 2: Progressiivinen paljastaminen

Käyttäjät: Claude Code, LangChain Deep Agents, OpenAI Responses API/Agents SDK

Miten se toimii: Kevyt metatieto aina läsnä; täysi sisältö ladataan tarvittaessa.

Edut:

• Skaalautuu kymmeniin tai satoihin saatavilla oleviin taitoihin
• Minimaalinen tokenikustannus, kun taitoja ei tarvita
• Säilyttää kehotevälimuistin, kun täydet skeemat liitetään loppuun

Haitat:

• Agentti voi ohittaa vihjeen aktivoida relevantti taito
• Lisäviive aktivointivaiheesta
• Monimutkaisempi kehystoteutus

Parasta: Yleiskäyttöisille agenteille, jotka tarvitsevat pääsyn moniin ominaisuuksiin mutta käyttävät vain muutamaa per tehtävä.

Malli 3: Semanttinen haku

Käyttäjät: AutoGen Teachability, Voyager

Miten se toimii: Vektoritietokantakyselyt nostavat esiin relevantit taidot/tiedon semanttisen samankaltaisuuden perusteella nykyiseen kontekstiin.

Edut:

• Luonnollisesti rajattu tokenikustannus kirjaston koosta riippumatta
• Sisällön relevanssi paranee ajan myötä kirjaston kasvaessa
• Istuntojen välinen oppiminen ja kertyminen
• Ei nimenomaista aktivointia tarvita — relevanssi lasketaan automaattisesti

Haitat:

• Haun laatu riippuu upotusmallin laadusta
• Riski vanhentuneen tai hienovaraisesti väärän tiedon hakemisesta
• Vaatii vektoritietokantainfrastruktuurin
• Vähemmän ennustettavaa — eri vuorot lataavat eri sisältöä

Parasta: Agenteille, jotka oppivat kokemuksesta ja tarvitsevat toimialatiedon kerryttämistä ajan myötä.

Malli 4: Käännetty/staattinen syöttö

Käyttäjät: DSPy, MetaGPT

Miten se toimii: Taidot käännetään kiinteäksi kehostesisällöksi (DSPy) tai aktivoidaan jäykkien toimintopohjien kautta (MetaGPT).

Edut:

• Ennustettavin käyttäytyminen — sama sisältö joka kerta
• Optimointi voidaan tehdä offline (DSPy:n kääntäminen)
• Ei ajoaikaista kuormitusta taidon valinnasta
• Todistetusti tehokas hyvin määritellyille, toistettaville tehtäville

Haitat:

• Joustamatonta — taitojen muuttaminen vaatii uudelleenkääntämistä (DSPy) tai koodimuutoksia (MetaGPT)
• Ei voi sopeutua uusiin tilanteisiin käännettyjen esimerkkien ulkopuolella
• DSPy:n kääntämisprosessi itsessään vaatii monia kielimallikutsuja

Parasta: Tuotantoputkille hyvin määritellyillä tehtävillä, joissa luotettavuus on joustavuutta tärkeämpää.

Käytännön vaikutukset agenttirakentajille

Oikean mallin valitseminen

Oikea taitojen syöttöarkkitehtuuri riippuu agenttisi profiilista:

Jos agentillasi on kapea, hyvin määritelty rooli (esim. koodikatselmointibotti, asiakastukiagentti yhdelle tuotteelle), aina päällä oleva syöttö (CrewAI/SuperAGI-malli) on yksinkertaisin ja luotettavin. 2–3 aina läsnä olevan taidon tokenikustannus on hallittavissa, ja vältät aktivointilogiikan monimutkaisuuden.

Jos agenttisi tarvitsee laajoja kyvykkyyksiä mutta käyttää vain muutamaa per vuorovaikutus (esim. kehittäjäavustaja, yleiskäyttöinen automaatioagentti), progressiivinen paljastaminen (Claude Code/Deep Agents -malli) on selkeä voittaja. 83–98 % tokenisäästöt mittakaavassa ovat liian merkittäviä ohitettavaksi.

Jos agenttisi tarvitsee oppia ja kehittyä vuorovaikutuksista (esim. henkilökohtainen avustaja, toimiala-asiantuntija, joka kerryttää tietoa), semanttinen haku (AutoGen Teachability -malli) tarjoaa oppimissilmukan, jota muut mallit eivät tarjoa. Varmista vain, että sinulla on laadunhallinta sille, mitä tietokantaan päätyy.

Jos agenttisi suorittaa hyvin määriteltyjä putkia (esim. datan käsittely, raporttien generointi, standardoidut työnkulut), käännetty syöttö (DSPy-malli) antaa sinulle ennustettavimman, optimoiduimman käyttäytymisen.

Hybridilähestymistapa

Tuotantoagenttitiimeille, joissa agenttien täytyy toimia heti käyttövalmiisti, suosittelemme hybridilähestymistapaa:

Ydintaidot (1–2 per agentti, määrittävät ensisijaisen toimialaosaamisen): syötetään aina järjestelmäkehotteeseen, CrewAI-tyyliin. Nämä ovat ehdottomia kyvykkyyksiä, joita agentti tarvitsee joka vuorolla.

Laajennetut taidot (lisäkyvykkyydet, joita agentti saattaa tarvita): vain metatieto järjestelmäkehotteessa, ladataan haku-/latausmekanismilla tarvittaessa, Deep Agents -tyyliin. Nämä laajentavat agentin kyvykkyysvalikoimaa maksamatta tokenikustannusta, kun ne eivät ole relevantteja.

Opittu tieto (kertynyt toimialaosaaminen): tallennettu vektoritietokantaan ja haettu semanttisesti per vuoro, AutoGen-tyyliin. Tämä mahdollistaa agentin kehittymisen ajan myötä ilman manuaalista taitojen laadintaa.

Tämä kerroksittainen arkkitehtuuri kartoittuu luonnollisesti siihen, miten järjestelmäkehote rakennetaan: päivämäärä → persoona → järjestelmäohjeet → ydintaidot → taitoindeksi → rooli-/tiimikonteksti. Ydintaidot ja indeksi lisäävät ennustettavan, hallittavan tokenikustannuksen, kun taas täydet taitosisällöt ilmestyvät vain tarvittaessa.

Tokenibudjetin parhaat käytännöt eri kehyksissä

Riippumatta siitä, mitä syöttömallia käytät, nämä tokeninhallinnan strategiat pätevät universaalisti:

Välimuistiystävällinen järjestys

Pinoaa muuttumaton konteksti (järjestelmäohjeet, työkaluskeemat) kehotteen alkuun. Kehotevälimuistia tukevilla tarjoajilla välimuistissa olevat tokenit maksavat 75 % vähemmän. Claude Code ja OpenAI molemmat syöttävät löydetyt työkaluskeemat konteksti-ikkunan loppuun nimenomaan säilyttääkseen välimuistiosumat staattiselle etuliitteelle.

Kuorman siirtäminen

Tiivistä työkaluvastauksien sijaan täysien tulosten pitämistä kontekstissa. Tallenna täydelliset tiedot ulkoisiin viitteisiin, joita agentti voi lukea tarvittaessa. Tämä on erityisen tärkeää agenteille, jotka tekevät monia työkalukutsuja per istunto.

Pelkistäminen

Tiivistä keskusteluhistoria yhteenvetojen kautta. Poimi avainasiat pitkistä keskusteluista tiivistettyihin esityksiin. Jokainen istuntopohjaista pysyvyyttä käyttävä kehys hyötyy aggressiivisesta historian hallinnasta.

Haku esilatauksen sijaan

Hae relevantti tieto dynaamisesti ajoaikana kaiken etukäteen lataamisen sijaan. Tämä pätee taitoihin, tietokantoihin ja jopa keskusteluhistoriaan. Tutkimukset osoittavat, että tämä voi vähentää kehotteiden kokoa jopa 70 %.

Eristäminen

Käytä aliagentteja tietyille tehtäville, jotta jokaisen agentin konteksti pysyy kohdennettuna. Sen sijaan, että antaisit yhdelle agentille 20 taitoa, luo 5 agentin tiimi, jossa jokaisella on 4 taitoa. Jokainen agentti ylläpitää kevyttä konteksti-ikkunaa, ja tiimi kattaa yhdessä koko kyvykkyyskokonaisuuden.

Yhteenveto

Tapa, jolla tekoälyagenttikehykset syöttävät taitoja kontekstiin, on yksi merkityksellisimmistä arkkitehtuuripäätöksistä agenttisuunnittelussa — silti sitä harvoin käsitellään näin yksityiskohtaisesti.

Ala konvergoi selkeästi kohti progressiivista paljastamista yleiskäyttöisten agenttien suositeltuna mallina, sillä Claude Code, LangChain Deep Agents ja OpenAI ovat kaikki itsenäisesti päätyneet samankaltaisiin kolmitasoisiin arkkitehtuureihin. Samaan aikaan erikoistuneet mallit kuten semanttinen haku (AutoGen, Voyager) ja käännetty syöttö (DSPy) palvelevat tärkeitä erikoisalueita, joita pelkkä progressiivinen paljastaminen ei kata.

Agentjärjestelmiä rakentaville ammattilaisille keskeinen oivallus on, ettei taitojen syöttäminen ole yksi kaikille sopiva ongelma. Oikea lähestymistapa riippuu agenttisi roolista, tarvittavien taitojen määrästä, siitä, tarvitseeko se oppia ajan myötä, ja sietokyvystäsi tokenikustannusten ja luotettavuuden välisten kompromissien suhteen.

Kestävimmät tuotantojärjestelmät yhdistävät todennäköisesti useita malleja — aina päällä oleva ydinkyvykkyyksille, progressiivinen paljastaminen laajennetuille taidoille ja semanttinen haku kertyneelle tiedolle — luoden agentteja, jotka ovat sekä tehokkaita että asiantuntevia.