PydanticAI ja LangGraph: viive erosi, tarkkuus ei

PydanticAI sopii lähtökohdaksi, kun rakennat tyypitettyä Python-agenttia ja tavallinen sovelluskoodi ohjaa sen kulkua. LangGraph on luontevampi, kun haarat, jaettu tila sekä keskeytys ja jatkaminen muodostavat itse työnkulun. BenchClawin 160 ajon vertailussa LangGraph 1.2.9 ja Pydantic AI 2.13.0 saivat gpt-4o-mallilla kumpikin 80 ajoa 80:stä oikein; mediaaniviive oli LangGraphilla 3,86 sekuntia ja Pydantic AI:lla 5,53 sekuntia.

Mittauksessa viive erosi synkronisessa toteutuksessa, mutta tulosta ei voi siirtää sellaisenaan muihin käyttötapoihin. Valinta riippuu ensin siitä, onko ratkaistava ongelma agentin tyypitetyssä syötteessä ja tuloksessa vai useita vaiheita yhdistävän prosessin ohjauksessa. Työnkulun rakenne on hyödyllisempi lähtökohta kuin yleinen väite toisen kehyksen paremmuudesta.

Mitä viivetesti todella mittasi?

Vertailun tehtävät olivat rajattuja työkalukutsuja: varaston täydennyspäätös, aiemmasta kutsusta riippuva toimitushinta, vanhentuneen version ohittaminen ja palautuskäytännön soveltaminen. Kukin ajo oli itsenäinen agenttikutsu, jossa kysymys johti työkalujen käyttöön ja rakenteiseen vastaukseen. Oikeellisuus arvioitiin täsmällisellä vastauksen osumalla; pysyvää keskustelutilaa, ihmisen hyväksyntää tai pitkää haarautuvaa prosessia ei käytetty. Täydellinen tulos kertoo juuri näiden rajattujen tehtävien suoriutumisesta.

Mitattu viive oli koko kutsun kulunut seinäkelloaika, johon sisältyivät mallin, työkalujen, sovittimen ja kehyksen osuudet. Julkaistu tulos ei erottele niiden yksittäisiä vaikutuksia. Pydantic AI:n ajo tapahtui synkronisen testikehikon kautta run_sync()-kutsulla, vaikka sen tavallinen agent.run()-rajapinta on asynkroninen. Testi ei siten kerro, säilyykö sama ero sovelluksessa, joka odottaa kutsua suoraan asynkronisesti.

Milloin PydanticAI on kevyempi lähtökohta?

PydanticAI kokoaa mallikutsut, työkalut ja tuloksen tyypitetyn Agent-rakenteen ympärille. Pydanticin vertailudokumentaatio kuvaa tavallisen Python-ohjausvirran ensisijaiseksi tavaksi rakentaa agenttia ja pydantic-graphin vaihtoehdoksi silloin, kun kulku on varsinainen tilakone. Jos sovellus kutsuu agenttia, käsittelee ehdon omassa koodissaan ja ottaa vastaan määrämuotoisen tuloksen, erillinen graafirakenne ei välttämättä selkeytä kokonaisuutta.

Tyypityksen etu näkyy rajassa, jossa agentin tulos siirtyy muuhun ohjelmaan. Odotetun tietorakenteen voi ilmaista Pythonin tyypeillä ja tarkistaa ennen kuin muu koodi käyttää arvoja. Tämä vähentää käsin tehtävää rakenteen tulkintaa, mutta rakenteellisesti kelvollinen vastaus voi silti olla sisällöltään väärä. Tyypitetty tulos ja tehtävän oikea ratkaisu ovat eri laatukriteerejä; julkaistu tarkkuustulos ei yksin arvioi tyypityksen hyötyä ylläpidossa.

Yksittäinen ehtolause tai uusi yritys ei vielä tee työnkulusta graafia vaativaa. Jos tilasiirtymät alkavat kuitenkin hallita sovellusta, pydantic-graph tarjoaa tyypitettyjä solmuja sekä tallennuksen keskeyttämistä ja jatkamista varten. Näin PydanticAI:n valinta ei sulje pois eksplisiittistä graafia. Ratkaisevaa on, pysyykö prosessi ymmärrettävänä tavallisessa Python-koodissa vai tuleeko siirtymien määrittelystä oma suunnittelutehtävänsä.

Milloin LangGraphin graafi selkeyttää työtä?

LangGraph nostaa tilan ja vaiheiden väliset siirtymät toteutuksen keskiöön. LangGraphin virallinen yleiskuvaus esittää sen pitkäkestoisten, tilallisten agenttien orkestrointikehyksenä, jossa ohjelmalliset vaiheet ja mallin ohjaamat vaiheet voivat toimia samassa graafissa. Kehys tarjoaa pysyvyyden ja ihmisen osallistumisen työnkulkuun, mikä tekee siitä luontevan vaihtoehdon silloin, kun prosessi jatkuu useassa erillisessä vaiheessa.

Ajatellaan ehdollista sovellusta, jossa agentti hakee tiedot, ohjaa tapauksen eri tarkistusreiteille, pysähtyy hyväksyntään ja jatkaa päätöksen jälkeen. Tällöin reitti, säilytettävä tila ja jatkumiskohta ovat tuotteen toimintaa, eivät vain agentin sisäisiä yksityiskohtia. Graafin määrittely tuo lisää suunnittelutyötä, mutta voi tehdä vaiheiden väliset riippuvuudet näkyviksi ja muokattaviksi. Suoraviivaisessa kutsu–työkalu–vastaus-ketjussa sama rakenne voi olla tarpeettoman raskas.

LangGraphissa voi myös kuvata tilaa Pythonin tyypeillä, joten ero ei ole yksinkertaisesti tyypitetyn ja tyypittämättömän koodin välillä. Painopiste on siinä, mihin kehittäjä sijoittaa prosessin päälogiikan. PydanticAI aloittaa agentista ja antaa Pythonin ohjata ympäröivää koodia; LangGraph aloittaa mallinnetusta työnkulusta, jonka solmuissa agenttikutsut ovat yksi mahdollinen vaihe.

Keskeytys ja kestävä suoritus ovat eri tarpeita

Hyväksyntää odottava työnkulku tarvitsee tavan säilyttää tila ja jatkaa myöhemmin oikeasta kohdasta. Palvelun kaatumisesta toipuminen lisää toisen vaatimuksen: kesken jääneen ajon aiemmat mallikutsut ja työkalutoimet pitää käsitellä hallitusti uudelleenkäynnistyksessä. Pelkkä mahdollisuus tallentaa tilannekuva ei vielä kerro, miten keskeneräinen työ jatkuu häiriön jälkeen.

PydanticAI:n kestävän suorituksen ohje erottaa ajon tallentamisen ja myöhemmän jatkamisen varsinaisesta häiriönkestävästä suorituksesta. Jälkimmäiseen se tarjoaa ulkoisia moottoreita, kuten Temporalin, DBOS:n ja Prefectin; moottori kirjaa mallipyynnöt ja sen piiriin kuuluvat työkalukutsut, jotta keskeytynyt ajo voidaan palauttaa. Jos tiimillä on jo tällainen moottori, agentin voi sijoittaa sen ohjaamaan prosessiin ilman, että kaikki reititys siirretään agenttikehykseen.

LangGraphissa pysyvyys on osa graafipohjaisen orkestroinnin mallia. Tämä voi selkeyttää kokonaisuutta, jos samojen solmujen välissä pitää tarkastella tilaa, odottaa ihmistä ja jatkaa käsittelyä. Kummassakin vaihtoehdossa on silti määriteltävä, mitä ulkoiselle järjestelmälle jo tehty työ tarkoittaa uudessa ajossa: esimerkiksi lähetys tai maksu ei saa toistua vain siksi, että vaihe käynnistetään uudestaan. Valinta koskee myös sitä, missä vastuu kestävistä sivuvaikutuksista sijaitsee.

Valinta tehtävän mukaan

Rajattu, tyypitetty agentti: PydanticAI on selkeä lähtökohta, kun sovellus tarvitsee työkalukutsun ja määrämuotoisen vastauksen ja pystyy ohjaamaan muutaman ehdon tavallisessa Python-koodissa.
Haarautuva prosessi ja jaettu tila: LangGraph sopii paremmin, kun solmujen väliset reitit ja niissä säilyvä tila kuvaavat sovelluksen päätoimintaa.
Hyväksynnän odotus: tarkenna, onko hyväksyntäpiste osa mallinnettua graafia vai voiko agentti pysähtyä ja jatkua muun sovelluksen ohjauksessa. Molemmille löytyy välineitä, mutta niiden paikka arkkitehtuurissa eroaa.
Palautuminen häiriöstä: vertaa LangGraphin pysyvyyttä PydanticAI:n ja valitun kestävän suorituksen moottorin yhdistelmään. Ratkaisevaa on, kuka kirjaa jo valmistuneet toimet ja miten keskeneräinen työ toistetaan.
Viiveherkkä synkroninen kutsu: julkaistu mittaus antaa LangGraphille etumatkan juuri testatussa asetelmassa. Asynkroninen palvelu, erilaiset työkalut tai pidempi prosessi tarvitsevat oman kokonaisajan mittauksen.

Lue myös: