A mikroszolgáltatások bevezették a szoftverfejlesztés egy fontos változását: a nagy alkalmazásokat kisebb, önállóan deploy-olható szolgáltatásokra bontották. Ez egyszerre hozott könnyebbséget a fejlesztésbe és skálázásba, és egy újfajta problémát: a rendszer viselkedésének áttekinthetősége romlott. Ugyanezt a pályát követik most az AI-ügynökök. Egy korábban egyetlen alkalmazáson belül zajló munkafolyamatot több ügynökre bontanak szét; minden ügynök egy feladért felelős. Az egyes darabok helyesek lehetnek, miközben az egész folyamat minősége lassan romlik. A különbség: az ügynökök sokkal gyorsabban és olcsóbban hozhatók létre, így ugyanazt az architekturális hibát könnyebb és nagyobb méretekben ismételni.
Saját eset: három hétnyi kutatás
Ezt fájdalmas módon tanultam meg. A nevem szerepelt a tervezési dokumentumban. Ésszerű döntésnek tűnt a munkafolyamat három ügynökre bontása, és a legtöbb érvet ma is védeném. Aznap délután viszont ha megkérdeztek volna, hogyan fogjuk megtalálni, ha a rendszer csendben leáll, nem tudtam volna válaszolni. Hónapokkal később egy minőségellenőrzésen egy felülvizsgáló azt érezte, hogy valami nem stimmel, még mielőtt a mérőszámaink jeleztek volna bármit. A késleltetés és hibaarányok rendben voltak, minden szolgáltatás a várt választ adta vissza — mégis lassú minőségromlást tapasztaltunk, és a nyomozás három hétig tartott. A folyamatban az első ügynök dokumentumkészletet adott a másodiknak összegzésre. A foglaló ügynök kivette egy mezőt, mert alacsony jelnek ítélte. Egy későbbi ügynök enélkül a mező nélkül magabiztos ajánlást tett. Minden ügynök pontosan azt tette, amire tervezték, de az eredmény hibás volt. Ezt előre kellett volna látnom — láttam ugyanezt a mintát a mikroszolgáltatások idején.
A számla, amit már kifizettünk
A monolitok szétdarabolása jó döntés volt a legtöbb csapat számára, de egy dolgot elfelejtettünk: a bonyolult részek nem tűntek el, csak átköltöztek a szolgáltatások közötti réseket kitöltő területre, ahol a termékért felelősök már nem látták őket. A számla körülbelül 2019-re érkezett be: a szállítási ütemterv csúszott, nem az incidens-csatorna. Csapatok száz-száz szolgáltatást futtattak korlátozott trace-elhetőséggel és szerződésverziózás nélkül; a tünet lassabb szállítás volt.
Az ügynökök ugyanezt a görbét gyorsabban futják le, mert egy ügynök felállítása egy délutánt és egy promptot igényel a repo és deploy-pipeline helyett. Amikor egy ügynök létrehozása olcsó, a termékcsapatok engedély nélkül hoznak létre ügynököket, és senki sem tartja nyilván, mi az és mit csinál.
Mi romlik el, és mennyibe kerül
Ez nem csak az én tapasztalatom. Cemri és a szerzőtársai több mint 1 600 végrehajtási trace-et annotáltak hét népszerű multi-ügynök keretrendszerben, és 14 visszatérő hibamód taxonómiáját állították fel (MAST, NeurIPS 2025). A hibák nagy része a rendszer specifikációjára és az ügynökök koordinációjára vezethető vissza, nem magukra a modellekre.
Leltár látszólag triviális, de nem az. A szolgáltatásburjánzás legalább előjött a Kubernetes manifestekben; az ügynökök azonban termékfelületekben, munkafolyamat-eszközökben és valaki hétvégi automatizmusában jönnek létre. Csak akkor derül ki, mi van, amikor egy megfelelőségi vizsgáló rákérdez: melyik automatizált rendszer érintett egy adott döntésben — és akkor már késő.
A láthatósági rés három hétbe került nekünk. Ha egy ügynök meghív egy ügynököt, ami meghív egy retrieval réteget, ami megint egy ügynököt hív, és minden hop-ban van egy modell, ami dönt arról, mit továbbítson, szükség van olyan trace-kontinuitásra, ami végig megmarad. A legtöbb stack csak promptokat és completation-öket naplóz hívásonként, és megáll ott: megkapod az egyes hopokat, de nem a láncot — pedig a lánc az, ami elromlott.
Ami engem leginkább aggaszt: a magabiztosság felhalmozódása. Az elosztott rendszerek hangosan hibáznak, ami áldásnak bizonyult: egy szolgáltatás dohog egy 500-szal, és a hívó tudja, hogy le kell állnia. Az ügynökök viszont csendben és folyékonyan hibáznak: ha egy upstream összegzés hihető és mégis helytelen, a downstream ügynök nem kap jelet, és magabiztosan épít rá. Mire a felhasználóhoz eljut a végeredmény, az olyan bizonyosságot sugall, amit a kiinduló bizonyíték nem támaszt alá.
Az API-szerződések akkor sodródtak el, amikor valaki verziózás nélkül változtatta meg a válaszformátumot; erre építettünk build-időben elkapó mechanizmusokat. Az ügynök-szerződések akkor sodródnak el, amikor valaki szerkeszti a rendszerpromptot — ebben nincs sémakülönbség és nincs típusellenőrzés. Semmi sem törik meg addig, amíg egy downstream ügynök más outputot nem kap és alkalmazkodik hozzá csendben.
Mit vihetünk át a mikroszolgáltatások tapasztalatából
A regiszter a legolcsóbb dolog, amit érdemes megépíteni, és az első, amit mindenki kihagy. A mikroszolgáltatásoknál szolgáltatáskatalógust vezettünk tulajdonossal és hatókörrel; az ügynökök esetében ugyanilyen rekordra van szükség, plusz egy explicit listára arról, hogy melyik ügynök milyen más komponenseket hívhat.
A trace-elés szinte változatlanul átvihető: a korrelációs azonosítók erre a problémára születtek. Az OpenTelemetry GenAI semantic conventions megadják a szókészletet, és egy ügynök-futás trace-ként (span-fával) jelenik meg a széttagolt logok halmaza helyett. Ha kiadtuk volna ezeket a span-okat, a summarizer és a recommender span egymás mellett ültek volna egy trace-ben, és a hiányzó mező diffként jelent volna meg, nem három hétnyi nyomozásként. Mivel ezek a konvenciók még mozgásban vannak, érdemes a saját mapping réteget tartani az attribútumnevek mögött.
A hiányzó mező megtalálása egy trace-ben lerövidítette volna a vizsgálatot. Emellett szükség lett volna egy tesztre, amely elkapja a kimaradást még azelőtt, hogy egy promptváltozás eléri a prodot. Ezt a mikroszolgáltatásokból ismert szerződés-alapú tesztelési fegyelemmel lehet alkalmazni: definiáld, min múlik a downstream ügynök, majd ellenőrizd, hogy egy upstream változás megtartja-e azt. A summarizer esetében az értékelésnek meg kell vizsgálnia, hogy a kimenet megtartja-e azt az információt, amire a recommendernek szüksége van. Verzióznám a promptokat, és megkövetelném, hogy a változtatások átmenjenek ezeken az értékeléseken kiadás előtt.
Van korai bizonyíték, hogy ez megtérül: a SEMAP, egy protokolszintű módszer a viselkedésalapú szerződésmodellezésre és életciklus-ellenőrzésre Google A2A infrastruktúráján, jelentett legfeljebb hozzávetőlegesen 70 százalékkal kevesebb hibát függvényszintű kódolási feladatoknál, amikor MAST-tal mérték.
A bizalmi határ az, amiről tervezési felülvizsgálaton vitatkoznék. 2019-ben megtanultuk, hogy egy szolgáltatást nem szabad automatikusan megbízni csak azért, mert a peremzeten belül fut — a service mesh-ek nagy része ezt kezelte. Az ügynökverzió az, hogy egy ügynököt nem szabad széleskörű eszközhozzáféréssel felruházni csak azért, mert mi építettük. Amit egy ügynök megtehet, annak egy policy-rétegben van a helye, amin a modell nem férhet át a saját nyelvével; nem elég egy udvarias rendszerprompt.
A költség az a pont, ahol a hasonlat megbukik. Egy mikroszolgáltatás, amely retry-loopban ragad, CPU-t és egy 3 órakor csörögő alertet eredményez. Egy ügynök újrainduló loopja viszont minden iterációnál valódi pénzbe kerül, és nem telítődve produkál magát oly módon, hogy az feltűnjön. Ez a termékfelelősre hárul, mert egységköltési problémaként jelenik meg, nem kiesésként — a PM-nek kell majd védenie a számot a számla végén.
Mit kérek, mielőtt splitet jóváhagyok
Semmi nem szól a multi-ügynök rendszerek ellen; ugyanúgy megkeresik a létjogosultságukat, mint a szolgáltatások. Az érvelésem az, hogy az üzemeltetési gyakorlatoknak együtt kell fejlődniük az architektúrával, és nem ismételhetjük meg az előző átmenet ötéves késését. A termékért felelős személy általában a legalkalmasabb arra, hogy ezt biztosítsa.
Négy dolgot szoktam kikényszeríteni. Követni tudjuk-e egy kérést teljes hosszában, és újraépíteni, hogy melyik ügynök mit döntött és miért? Ha nem, akkor olyat építünk, amit nem lehet hibakeresni. Mi történik, amikor egy upstream ügynök téved — és nem az, hogy képes-e tévedni? Ha a válasz az, hogy a következő ügynök ugyanúgy folytatja, akkor nem tervezünk hibamódot: egy hibát terveztünk és hagyjuk futni.
Ki birtokolja az ügynököt, és hol van érvényesítve a tool-hozzáférése? Egy rendszerprompt nem ellenőrzés. Mennyi ez tízszeres költés mellett, és mi kapcsolja ki, ha a szám elromlik? Ezt korán felteszem, mert senki nem vállalja fel önként.
A mikroszolgáltatások lebontását sikeresen irányító csapatok beépítették a trace-elést és a szerződésalapú tesztelést a fejlesztés kezdetétől fogva. Ezek a gyakorlatok segítettek megérteni, hogyan lépnek kölcsönhatásba a komponensek, és ellenőrizni, hogy a változtatások megőrzik-e a várt viselkedést. Ma ez egy-két sprint munka; sokkal nagyobb feladat lesz, ha 40 ügynököt futtatsz, és valaki rákérdez, melyikük érintette egy ügyfél adatait.
