Pydantic AI vai LangGraph: tipi uzvar vienkāršībā, grafi — ilgā darbplūsmā

Strukturētam Python aģentam, kura galvenais uzdevums ir izmantot rīkus un atdot validētu rezultātu, parasti pietiek ar Pydantic AI. Tā tipizētais Agent ļauj vadīt izpildi ar parastu Python kodu; Pydantic AI salīdzinājums apraksta arī iespēju pievienot atsevišķu grafu, kad plūsma kļūst par stāvokļu mašīnu. Vienkāršības ieguvums ir konkrēts: komandai nav jādefinē mezgli un pārejas īsam procesam, kuru jau skaidri izsaka funkcijas un nosacījumi.

Ja aģenta darbam jāturpinās pēc pārtraukuma, jāgaida cilvēka lēmums vai jāatgriežas pie agrāka posma, LangGraph piedāvā šiem uzdevumiem tiešu grafa modeli. Tā stāvokļa saglabāšanas dokumentācija nošķir kontrolpunktus vienas izpildes pavedienam no krātuves datiem, kas pieejami pāri pavedieniem. Izvēli nosaka tas, vai lietotnei jāpārbauda galarezultāta forma vai arī jāvada visa procesa starpstāvokļi.

Ko dod tipizēta izvade

Pydantic AI stiprā puse ir skaidrs līgums starp aģentu un pārējo lietotni. Komanda var aprakstīt sagaidāmo izvadi, rīku argumentus un atkarības ar Python tipiem. Ja modeļa atbilde neatbilst noteiktajai struktūrai, neatbilstība tiek apstrādāta pie aģenta robežas, pirms rezultātu izmanto nākamā lietotnes funkcija. Tas ir īpaši noderīgi, ja atbildē vajadzīgi noteikti lauki un paredzami datu tipi.

Nosacīts piemērs: aģents nolasa klienta ierakstu ar rīku un atdod objektu, kurā ir identifikators, statuss un īss pamatojums. Ja process sastāv no šādas rīka izsaukšanas un rezultāta pārbaudes, Python funkcijas dod pārskatāmu izpildes ceļu. Mazāks koda apjoms šeit samazina maršrutēšanas loģiku, kas jāuztur. Tas pats par sevi nepadara modeļa spriedumu pareizu: validācija pārbauda datu formu un tai definētos ierobežojumus, nevis katra apgalvojuma patiesumu.

Tipu līgums arī neatbild uz jautājumu, kas notiek pēc procesa pārtraukuma. Pareizi noformēts rezultāts nepasaka, kurš rīks jau ir izsaukts, vai ārējā sistēma ir pieņēmusi pieprasījumu un kurā vietā darbu drīkst turpināt. Šie jautājumi kļūst svarīgi, tiklīdz aģents pāriet no vienas atbildes sagatavošanas uz ilgstošu darbplūsmu.

Kad grafa struktūra atmaksājas

LangGraph modelē procesu ar kopīgu stāvokli, mezgliem un pārejām. Tas palīdz, ja nākamais solis ir atkarīgs no iepriekš iegūta rezultāta, kāds posms jāatkārto vai dažādi lēmumi ved uz atšķirīgiem izpildes ceļiem. Komanda var atsevišķi definēt, ko dara mezgls un kurš nosacījums izvēlas nākamo mezglu. Šāda struktūra ir vērtīga, ja starpstāvokļi ir daļa no lietotnes darbības, nevis tikai īslaicīgi mainīgie funkcijā.

Par šo kontroli jāmaksā ar projektēšanas darbu. Jānosaka stāvokļa saturs, mezglu atbildība un pāreju noteikumi; izmaiņas vienā posmā var ietekmēt nākamo. Īsā, lineārā rīku secībā tas var būt lieks slānis. Savukārt procesā ar atkārtotu izvēli un saglabājamu progresu tieši šī papildu struktūra ļauj skaidri pateikt, kur izpilde atrodas un kas tai jādara tālāk.

Ko nozīmē pauze un atsākšana

Cilvēka apstiprinājums ilgstošā procesā nozīmē vairāk par apstiprināšanas pogu. Izpildei jāapstājas pirms konkrētās darbības, jāsaglabā tās konteksts un pēc atbildes jāatsāk pareizais pavediens. LangGraph pārtraukumu dokumentācija šim nolūkam apraksta interrupt(), kontrolpunktu un pavediena identifikatoru. Tajā norādīta arī būtiska robeža: pēc atsākšanas mezgls sāk darbu no sākuma, tādēļ kods pirms pārtraukuma var izpildīties vēlreiz.

Šī uzvedība ietekmē ārējās darbības. Nosacītā plūsmā, kur mezgls pirms pauzes nosūta pieprasījumu citai sistēmai, atkārtota izpilde var nosūtīt to vēlreiz. Apstiprināšanas vietu tāpēc ir saprātīgi novietot pirms šādas darbības vai paredzēt veidu, kā atpazīt jau izpildītu pieprasījumu. Kontrolpunkts saglabā grafa stāvokli; tas pats par sevi neatsauc izmaiņas ārējā sistēmā.

Ilgstoša izpilde ir iespējama arī ar Pydantic AI. Tā ilgstošas izpildes dokumentācija apraksta integrācijas ar darbplūsmu dzinējiem, kas saglabā progresu kļūmju un restartu gadījumā un var atbalstīt cilvēka iesaisti. Tādēļ izvēle nav starp atjaunojamu un neatjaunojamu aģentu. LangGraph piedāvā kontrolpunktus un pārtraukumus savā grafa izpildes modelī; Pydantic AI gadījumā komandai jāizvēlas un jāievieš piemērots izpildes dzinējs.

Ko var secināt no vairāku rīku etalona

Agentic Pulse publicētajā 2026. gada 3. oktobra pārbaudē bija 40 vairāku rīku uzdevumi. Tajā Pydantic AI v0.0.24 konfigurācija ar pirmo mēģinājumu izpildīja 36 no 40 uzdevumiem jeb 90 %, bet LangGraph v0.2.34 konfigurācija — 33 no 40 jeb 82,5 %. Ziņotais P95 izpildes laiks bija attiecīgi 6,9 un 11,2 sekundes. Tie ir minēto konfigurāciju rezultāti šajā uzdevumu kopā, nevis vispārējs ietvaru precizitātes vai ātruma mērījums.

Pārbaude aptvēra datu analīzi, shēmu izmaiņas, failu un čaulas automatizāciju, kā arī vairāku aģentu sadarbību. Tās kopējais izpildes laiks ietver modeļu izsaukumus, rīku darbu un gaidīšanu tīklā. No šī rādītāja vien nevar izdalīt, cik laika patērēja pats ietvars. Tāpat īsu uzdevumu pabeigšanas rezultāts neatbild uz arhitektūras jautājumu, cik droši sistēma pēc ilgākas pauzes atsāk darbu vai apstrādā cilvēka lēmumu.

Izvēles koks Python komandai

Vispirms jānosauc prasība, kuras neizpilde padarītu aģentu nederīgu. Ja tā ir pārbaudāma atbildes struktūra un procesa gaita paliek īsa un saprotama Python kodā, Pydantic AI ir vienkāršāks sākuma punkts. Ja lietotnes līgumā ietilpst arī saglabājami starpstāvokļi, atkārtoti lēmumi un skaidras pārejas, grafa modelis iegūst praktisku pamatojumu.

• Ja vajadzīga galvenokārt strukturēta ievade un izvade, izvēlieties tipizētu aģentu un turiet vadības plūsmu Python kodā.
• Ja ir vairāki nosacīti ceļi vai cikli un katram posmam vajadzīgs noteikts stāvoklis, apsveriet grafa modeli.
• Ja procesam jāgaida apstiprinājums vai jāpārdzīvo restarti, salīdziniet LangGraph kontrolpunktus ar Pydantic AI un ilgstošas izpildes dzinēja kombināciju. Izvēlē iekļaujiet arī ārējo darbību atkārtošanas noteikumus.

Šie kritēriji var novest pie atšķirīgas atbildes pat vienā komandā: īsam datu iegūšanas aģentam svarīgāka var būt tipizēta atbilde, bet procesam ar lēmumu gaidīšanu — atjaunojams izpildes stāvoklis. Ietvara pieskaitāmās izmaksas ir pamatotas tad, kad tā struktūra risina prasību, kuru lietotne patiešām uzturēs.

Lasiet arī:

• LangGraph vai CrewAI: vienkāršāka komanda maksā ar mazāku kontroli
• SEPA zibmaksājums vai parasts pārskaitījums: ātrākais nedrīkst maksāt vairāk
• Basecamp vai Asana: liela komanda var apgriezt cenas salīdzinājumu