Bennie Haelen szerint az első nagy összegű ügynökfuttatás gyakran nem irányítási, hanem számlázási problémának tűnik: a csapat kinyitja az első számlát, kigyűjti a futásokat költség szerint, és talál egyet, amely a medián 40-szerese. A szolgáltatói mérő tokeneket és összesített értéket mutat; az alkalmazásnaplók azt jelzik, hogy a külső kérés sikeres volt; a trace-nézegető rendezett kérésről és választ mutat. Egyik forrás sem magyarázza meg azonban, miért tért el ez az egyetlen futás a többiétől.
A használatalapú számlázás nem feltétlenül tette az ügynököket drágábbá — érthetőbbé tette a költségeket. Azonban a láthatóság nem azonos az okok hozzárendelhetőségével: hogy megtudd, miért volt egy futás költséges vagy veszélyes, beláthatóvá kell tenni a tényleges futást, fordulóról fordulóra.
Mire gondolunk, amikor "control plane"-ről és "substrate"-ről beszélünk
A control plane alatt azt a platformréteget értjük, amely fölött az egyes ügynökök állnak: itt központosítják az észlelhetőséget (observability), és itt érvényesítik a szabályokat, hozzáférést, költségkereteket, routingot és végrehajtási korlátokat. Sok szervezetnak megvannak a control plane darabjai, de gyakran hiányzik az alatta fekvő bizonyíték-réteg: egy olyan, loop-orientált naplózás, amely megmutatja, mit csinált az ügynök fordulóról fordulóra.
Az instrumentációs pontoknak futási szűk keresztmetszeteknél kell lennie: model gateway, tool proxy, API gateway, execution sandbox, runtime harness, policy engine — az a réteg, amelyet az ügynök nem tud megkerülni.
A loop a megfigyelés egysége
A hagyományos alkalmazásmonitoring egy kérésre és választra épül. Az ügynök ezzel szemben nem egyszerűen egy kérést kezel, hanem egy cél felé dolgozik: érveléseket folytat, eszközöket hív, eredményeket olvas, döntéseket hoz és ismétel, amíg be nem fejeződik, határba nem ütközik, vagy nem emel szintet. Egy felhasználói szándék sok modellhívássá és tool-hívássá ágazhat szét, a kontextus pedig minden fordulóban változik. Az értékes jel az egyes fordulók közötti kapcsolat, nem csupán bármelyik hívás időzítése.
Három lényeges következmény:
- A kontextus felhalmozott állapot: minden forduló hordozhat korábbi üzeneteket, eszközleírásokat, lekért fájlokat, közbenső eredményeket és döntéseket. A növekedés helye sok költséget és kockázatot rejt.
- Egy tool-hívás elsőrendű döntés: hogy melyik eszközt választotta a modell, milyen paraméterekkel, mekkora volt az eredmény, és hogy egy politika korlátozta-e a hívást — mindez része a governance-nyilvántartásnak.
- Minden futás saját trace-fává nőhet: ugyanaz a prompt más úton mehet egyik napon, mint a másikon, így a fix hívásgráfok és tiszta service map-ek téves biztonságérzetet adhatnak.
Ha a megfigyelés egysége még mindig a kérés, könnyen elsiklik a ritka, de költséges vagy veszélyes loopok fölött.
Mit kell rögzítenie a substrate-nek
Ha elfogadjuk, hogy a loop az egység, akkor a követelmény konkréttá válik: az ügynök alatt rögzített, a teljes flotta felett lekérdezhető jelhalmazra van szükség. Bennie Haelen egy nagy egészségügyi szervezetnél futtatott pilotból azt írja, hogy ezt a réteget OpenTelemetry, Cloud Trace és egy usage-log tábla kombinációjával építették — a konkrét stack kevésbé fontos, mint az adatok alakja.
Minimumként minden felhasználói szándék egy run trace-t kell, hogy eredményezzen. Minden loop-fordulót spanként vagy stabil csoportosító attribútumként kell rögzíteni. A modellhívások, tool-végrehajtások, policy-ellenőrzések, retry-k és utófeldolgozások gyerek-spanként vagy strukturált eseményként szerepeljenek. A hangsúly a loop kauzális struktúrájának megőrzésén van.
A gyakorlati tervezés leginkább a következő problémák kezelése: kardinalitás, retenció, payload capture, sampling policy, sémaváltozás és a joinok kezelése a trace-, usage-, identitás- és policy-adatok között.
A tárolási pontot a csapatok gyakran alábecsülik: ha a jelek csak egy trace-nézőben landolnak, meg lehet nézni egy futást szépen, de nem lehet érvelni egy ezer futásból álló flotta fölött. A governance flottaszintű kérdés, ezért a substrate-nek lekérdezhetőnek kell lennie.
Adatminimalizálás is szükséges: alapértelmezésként metaadatokat, a tartalom rögzítését kivételes esetekre. A payloadok szétválasztása (eszköz neve, modell, token-számok, payload méret, sorok száma, policy döntés, hatáskör kontextus, request ID, redacted vagy hash-elt paraméterek) lehet hasznos szabályozott környezetben. A cél annyi bizonyíték tárolása, hogy vissza lehessen állítani, miért viselkedett egy futás úgy, ahogy, nem pedig minden látható adat archiválása.
Egy kezdeti hasznos verzióhoz nem kell teljes prompt- vagy szemantikai rögzítés. Hasznos mezők lehetnek: run_id, turn_id, parent_span_id, timestamp, principal_id, delegated_scope, model, input_tokens, output_tokens, cached_tokens, tool_name, result_bytes, row_count, policy_id, policy_decision, stop_reason, loop_bound_hit, outcome_status. Ezekkel a drága loopok titkai lekérdezhetővé válnak.
Példa SQL-szerű lekérdezés (konkrét szintaxis adattárházanként változhat):
with runs as ( select run_id, count(distinct turn_id) as turns, sum(input_tokens + output_tokens) as total_tokens, max(result_bytes) as largest_tool_result, bool_or(loop_bound_hit) as hit_loop_bound, count_if(policy_decision = 'rewrite') as rewritten_actions from agent_turn_events where occurred_at >= current_date - interval '7 days' group by run_id ) select * from runs where turns > 10 or largest_tool_result > 10000000 or hit_loop_bound or rewritten_actions > 0;
Ez a különbség aközött, hogy csodálkozunk egy trace-en és aközött, hogy kormányozzuk a flottát.
Egy substrate, három kormányzási probléma
Az azonos substrate egyszerre válaszolja meg az iparág által gyakran külön kezelt három problémát:
- Költségkezelés: token-számlálás fordulónként megmutatja, hogy túl sok forduló, túl nagy továbbvitt kontextus, túlméretezett tool-eredmény, rossz lépéshez választott drága modell vagy korlátlan retry okozta-e a költséget.
- Delegáció és hozzáférés: többügynökös rendszerekben a delegáció biztonsági határ. Végül megkérdezik majd, hogy ki engedélyezte az adott ügynök-műveletet, milyen hatáskörrel futott, és mely adatscope volt érvényben. Erre az audit-nyomvonal ugyanaz a loop-trace, identitás- és hatáskör-információval kiegészítve.
- Runaway akciók: a pusztító törlés vagy a termelési tábla eltávolítására tett kísérlet nemcsak posztmortemként legyen látható. Itt a blokkolt destruktív művelet egy deny-val jelzett guardrail-döntés, a futó scan pedig trace, amely loop boundot vagy payload-limitet ütött.
Mindhárom esetben ugyanaz a bizonyítékforma szükséges: fordulónkénti, függetlenül rögzített események, amelyekre a control plane támaszkodhat.
Az ügynök nem lehet a saját naplója
Csábító lehet, hogy az ügynökön belül gyűjtsük a token- és hatáskör-adatokat, de ez a "róka őrzi a tyúkólat" problémája. Az ügynök hasznos morzsákat bocsáthat ki, de nem lehet a rendszerbeli nyilvántartás saját hatalmáról, költségeiről vagy elutasításairól — az auditorok pont az önbejelentést utasítják el. Az instrumentációnak az ügynök alatt kell lennie, azon a rétegen, amelyet az ügynök nem választhat megkerülni.
Enforcement és observation ugyanannak a rétegnek két oldala: ha az ügynök szerkesztheti az észlelést, akkor sem megfigyelés, sem érvényesítés nincs.
Már vannak tracing eszközök, de ez nem elég
Léteznek kiforrott tracing eszközök és ügynök-observability-szállítók, és sok csapat be tudja kapcsolni a trace nézőt. A vizualizáció ugyan hasznos, de a hiányzó elem a teljesség és az akcióképes bizonyíték: a trace-nek függetlennek kell lennie az ügynöktől, és a jeleknek flottaszinten lekérdezhetőknek kell lenniük.
Egy hasznos teszt: meg tudja-e a control plane mondani az összes olyan futást ezen a héten, ahol a kontextus több mint 5x-re nőtt, egy tool >10 MB-ot adott vissza, egy guardrail átírta a műveletet és mégis eljutott felhasználó-látható válaszig? Ha erre emberi kattintgatás nélkül kell egyes trace-eket végignézni, akkor vizualizációd van, nem governance-öd.
A minta fontosabb, mint a stack
Ez nem egy konkrét tracing szabvány, adattárház vagy vendor melletti érvelés. A technológiai választás másodlagos; a fontos a minta: loop-aware trace-ek; fordulók spanszerű vagy strukturált eseménysorok; token-, tool-, guardrail- és identitásbizonyítékok; flottaszinten lekérdezhető tárolás; az ügynök alatti instrumentáció; és adatminimalizálás.
A csapatok, amelyek az observability-t csak dashboardnak tekintik, továbbra is akkor találnak hibákat, amikor a tünetek felszínre kerülnek: meglepő számla, audit-finding, incidens. Azok a csapatok, amelyek az observability-t a control plane szenzorhálójaként építik ki, ugyanabból az adathalmazból előre láthatják a problémákat és beavatkozhatnak, mielőtt a mérőóra, az auditor vagy az incidens rákényszerítené a választ.
Promptek irányítanak viselkedést. Guardrailek szabályoznak viselkedést. Az observability pedig azt mutatja meg, hogy a governance valódi-e: azt nem lehet kormányozni, amit nem látunk, és azt nem lehet javítani, amit nem tudunk hozzárendelni.
