Tuotantovalmis tekoälyagentti: ulkoiset taidot ja liitännäiset käytännössä
Yksittäinen kehote ei riitä, kun agentti käsittelee monivaiheista liiketoimintalogiikkaa. Suomalainen pk-yritys, joka haluaa sovittaa yhteen laskut kirjanpitojärjestelmästä ja sähköpostit, törmää nopeasti LLM:n konteksti-ikkunan rajoihin. Ratkaisu ei ole parempi kehote, vaan selkeä agenttinen työnkulku, jossa tehtävät reititetään erikoistuneille työkaluille. Monimutkaisuus siirtyy kehotteesta testattavaan koodiin.
Arkkitehtuuri: funktiokutsut eivät yksin riitä
Funktiokutsut ratkaisevat intention ongelman: malli tietää, että sillä on käytettävissä inventaariotyökalu. Ne eivät ratkaise toteutuksen ongelmaa: miten yhdistetään turvallisesti paikalliseen ERP-päätepisteeseen, käsitellään OAuth ja jäsennetään vastaava JSON.
Tarvitaan abstraktiokerros. Se tulkitsee mallin pyynnön, valitsee oikean työkalun, suorittaa koodin ja syöttää tuloksen takaisin LLM:lle synteesiä varten. Tämä on agenttisen järjestelmän ydin. Kriittinen kohta on virheenkäsittely: kun API aikakatkeaa tai dataformaatti on odottamaton, agentin on raportoitava täsmällinen virhe suunnittelusilmukkaan, ei hallusinoitava onnistunutta tulosta. Suurin osaamiskuilu uusilla rakentajilla on juuri tässä: mallin funktiokutsut ja kestävä, tilallinen suorituskehys ovat eri asioita.
Taidot tuotantokoodissa
Taito ei ole pelkkä funktio, vaan itsenäinen, testattu liiketoimintakapasiteetin yksikkö. Suomalaisen palkkahallinnan SaaS-palvelun taitoja voisivat olla esimerkiksi calculate_vat_liability(amount, region) tai fetch_employee_details(employee_id).
Suunnittelussa oleellista on schema-määrittely: malli näkee vain odotetut syötteet ja taatun tulostusrakenteen. Tämä pakottaa kuriin. Tyypillinen ongelma on se, että tiimi kirjoittaa taidon, joka toimii Jupyter notebookissa mutta kaatuu tuotantoympäristössä ympäristömuuttujien tai puuttuvien tunnisteiden takia.
Ratkaisu on selkeä vastuunjako. Orkestrointikerros hallitsee tunnisteet ja tilan säilymisen kutsujen välillä, taito-moduuli hoitaa puhtaan liiketoimintalogiikan. LangGraph soveltuu hyvin näiden tilasiirtymien mallintamiseen, koska sillä voi määritellä selkeät polut onnistumiselle, epäonnistumiselle ja uudelleenyrityksiille. Monimutkaisissa prosesseissa agenttitiimi, jossa yksi koordinointiagentti ohjaa erikoistuneita työkaluagentteja, on usein siistimpi ratkaisu kuin yksi massiivinen agentti.
Tilanhallinta ja luotettavuus
Tuotantoagentin yleisin vikaantumiskohta on tilanhallinta. Agentin "muisti" ei ole LLM:n konteksti-ikkuna, vaan se pysyvä tilavarasto, jota rakentaja hallinnoi.
Jos agentti käy läpi viisi asiakastiliä, sen on tallennettava neljän ensimmäisen tarkastuksen tulokset ja syötettävä rakenteiset tiedot viidenteen tarkastukseen ilman, että konteksti katoaa tai alkuaskeleita toistetaan. Käytännössä tämä tarkoittaa ulkoista tietokantaa. Yleinen ratkaisu on PostgreSQL rakenteiselle datalle ja Redis lyhytaikaiselle istuntotilalle.
Tilahistorian tarkasteltavuus on auditointijäljelle välttämätöntä niin debuggauksessa kuin vaatimustenmukaisuudessa. Tilavarasto on totuuden lähde, ei LLM:n ulostulo.
Paikallinen vai pilvi suorittaa taidon?
Suorituspaikan valinta on konkreettinen arkkitehtuuripäätös. Jos taito käsittelee arkaluonteista dataa, kuten sisäisiä HR-tietoja, logiikan ajaminen paikallisesti on välttämätöntä. Datarajat pysyvät kiinni. Paikalliset kielimallit muuttavat tätä päätöstä merkittävästi, vaikka paikallinen inferenssi lisää viivettä ja monimutkaisuutta käyttöönottoon.
Jos taito on puhtaasti matemaattinen tai käyttää hyvin dokumentoitua julkista APIa, pilvipalvelu sen omalla SDK:lla on yksinkertaisempi ja nopeampi. Vaihtoehtoina ovat aina viive vastaan tietosuvereniteetti. Eurooppalaiselle pk-yritykselle GDPR kallistaa vaakaa johdonmukaisesti paikallisen suorituksen puolelle, vaikka viive-ero olisi pieni.
Usein kysytyt kysymykset
K: Kuinka monta työkalua tarvitaan toimivan perusagentin rakentamiseen?
V: Vähintään yksi työkalu, joka käsittelee ulkoista tilaa tai dataa. Yksinkertainen laskintyökalu riittää todistamaan silmukan toimivuuden, mutta käytännön arvoa syntyy vasta, kun työkalu osuu johonkin ei-triviaaliseen päätepisteeseen, kuten tiettyyn sisäisen tietokannan tauluun.
K: Miten toteutetaan monivaiheinen päättely, joka vaatii ulkoista dataa?
V: Tarvitaan rakenteinen funktiokutsumalli. LLM ei tiedä dataa, vaan tuottaa rakenteisen JSON-pyynnön, joka kertoo orkestroijalle, mitä työkalua ajaa ja millä argumenteilla. Koodi ajaa työkalun, hakee tuloksen ja syöttää sen takaisin LLM:lle vastausta varten.
K: Mikä ero on vektoritietokannalla ja perinteisellä API-kutsulla?
V: Perinteinen API-kutsu sopii rakenteisiin, tunnettuihin päätepisteisiin, kuten asiakkaan hakemiseen tunnuksella. RAG ja vektoritietokanta sopivat strukturoimattoman tiedon hakuun: ne löytävät semanttisesti relevanteimmat dokumentit suuresta aineistosta ja syöttävät ne LLM:n kontekstiin.