af AgentPulse (LX AI)
Detektering af agent-løkker og drift i produktion
En agent-løkke er en kørsel, der gentager samme trin eller en næsten variation af det, uden at gøre fremskridt. Drift er en adfærd, der ændrer sig over tid uden en kode- eller prompt-ændring, der kan forklare det. Begge er billige at detektere, hvis du optager beslutninger, og usynlige, hvis du kun optager latency.
Hvorfor varsel kun baseret på forsinkelse fejler for agenter
Klassisk tjenestemonitoring voksede op omkring en anmodning, der starter, slutter og returnerer en statuskode. En selvstændig agentkørsel overholder ikke den kontrakt. Den kan ringe til værktøjer i et træ, gentage det samme værktøj med lidt forskellige argumenter, opgive en plan midtvejs eller fortsætte længe efter, at et menneske ville have stoppet. En grøn p99-forsinkelsesdiagram kan sidde ved siden af en løbsk planlægger, der brænder tokens, mens den ikke gør fremskridt.
OpenTelemetrys GenAI-konventioner behandler stadig mere agentarbejde som førsteklasses-telemetri: invoke_agent-stil spans, værktøjskørselsbørn og valgfri indholdsfangst, når privatlivspolitikken tillader det. Den rørledning hjælper, men konventioner alene fortæller dig ikke, hvilke signaler der fortjener en side. Du har stadig brug for produktregler for løkker og drift, der matcher, hvordan dine agenter faktisk opfører sig.
AgentPulse sidder i den produktlag. Indsæt en prøvekørsel eller adfærdslog, vælg en overvågningsfokus og få en rapport, der fremhæver sandsynlige løkker, driftskandidater og afvigelser. Det er ikke en fuld OTLP-backend, og det er ikke en formel sikkerhedsrevision.
En firetrins mønster til overvågning
- Indsamlinger af begivenheder. Fanget beslutninger, værktøjopkald, resultater, gentagne forsøg og årsager til opgivelse pr. kørsel. Foretræk strukturerede felter frem for kun fri tekst-logfiler, så du kan tælle gentagelser uden NLP-heroics. - Definer normalt for den pågældende agent. Typisk planlægningslængde, værktøjsblanding, gentagne forsøgsantal og varighedsbånd - pr. agentidentitet, ikke en global flådegennemsnit, der kombinerer chatbots med planlæggere. - Detekter afvigelser. Gentagne næsten-identiske trin; kørsellængde langt over båndet; et hidtil uset værktøj i produktion; eskalerende gentagne forsøg efterfulgt af opgivelse; outputlængde eller afvisningsrate, der fjerner sig fra baseline. - Rapportér med bevis. En overvågningspost skal linke til en afspilbar spor. Hvis en vagtende ingeniør ikke kan åbne kørslen og se beslutningerne i rækkefølge, vil alarmen blive ignoreret inden for en uge.
Signaler der er værd at page på
- Gentaget antal for samme værktøj med samme eller næsten identiske argumenter. - Antal skridt eller varighed over det normale interval for denne agent efter eksklusion af kendte lange opgaver. - Et værktøj, der aldrig er blevet kaldt for denne agent, der viser sig i produktions-trafik. - Øgende antal forsøg efterfulgt af opgivelse uden et bruger synligt svar. - Pludselige skift i værktøjsblanding efter en model eller prompt-udrulning — ofte drift eller en dårlig udgivelse, ikke "brugerne blev sværere".
Pågå ikke på hver lang løb. Lange løb, der stadig fratræder, er ikke løkker. Alert træthed er, hvordan overvågningsprodukter dør. Foretræk hastighed af forandring mod en agent-specifik baseline, derefter kræv en spor, så hver alert kan lukkes med bevis.
Baselines går i stykker - optegn årsagen
En ændring i modellen, en ændring i prompten, et nyt værktøj eller en ændring i trafikblandingen vil ændre dine tal. Hvis du ikke optegner disse begivenheder, vil hver udgivelse se ud som mystisk drift. Hold en simpel ændringslog ved siden af målinger: hvilken model, hvilken prompt-hash, hvilke værktøjer var aktiveret og hvornår trafikkompositionen skiftede. Forbrugere af producer-emitteede scores (tillid, drift, scan) i fremvoksende OTel-forslag advares allerede om, at metode-tokene har betydning - når scoringsmetoden ændres, genankrer korrelationen i stedet for at behandle springet som agent-fejl.
Hvad overvågning ikke er
Overvågning fortæller dig, at noget er sket. En runtime-trinbegrænsning eller sikkerhedsforanstaltning stopper det. At forveksle de to fører til overdrivelse. AgentPulse garanterer ikke, at advarsler altid udløses i tide til at forhindre brugerindvirkning. Vi hævder ikke 100% registrering. Vi hævder ikke, at du aldrig vil misse en loop. Disse ærlighedslinjer findes, fordi FTC-stil markedsføringsregler straffer fabrikeret sikkerhed, og fordi operatører fortjener værktøjer, der angiver deres begrænsninger.
Privatliv og opbevaring
Sporene indeholder ofte brugerindhold. Gem dem længe nok til at undersøge, kort nok til at overholde, hvad du har fortalt brugerne i privatlivspolitikken. Standard kort opbevaring, eksport på anmodning og adgangskontrol, der er sammenhængende med GDPR artikel 32 ramme, er grundlaget - ikke en certificeringsmærke, du kan stæmpe på en salgsdækning.
Hvordan AgentPulse passer ind i en værktøjskæde
Brug din eksisterende APM til tjenesterne omkring agenten. Brug OpenTelemetry (eller tilsvarende) til span plumbing, hvis du allerede investerer der. Brug AgentPulse, når du har brug for en fokuseret watch-rapport om løkker, drift og usædvanlig værktøjsbrug med en genspilbar fortælling - især tidligt, når oprettelse af en fuld agent kontrolplane er overkill. Enterprise kan tilføje BYOK og DPA-papirer, Free og Demo forbliver mærket, så intet prætender at være live AI, når nøglen mangler. Desuden kan AgentPulse bruges sammen med andre værktøjer som til at give en komplet oversigt over agentens adfærd og ydeevne.
ArbejdsEksempel (syntetisk, ikke en kunde historie)
Forestil dig en planlægningsagent, der normalt udfører 6-10 værktøjsaktioner. Om natten bliver den udvidet til 40+ skridt, og det samme søgeværktøj bliver kaldt med næsten identiske forespørgsler. Latensen er stadig "fin", fordi hver værktøjskald returnerer hurtigt. En loop-detektor, der overvåger gentagne kald og planlægningslængde, ville rejse en advarsel; en latency-kun dashboard ville forblive stille. At åbne sporningen ville vise den gentagne søgeblok. Det er forskellen på agent-overvågning og klassisk APM.
Ændr prompten, så den tillader et nyt forskningsværktøj. Værktøjsblandingen skifter. Uden en ændringslog, ser det ud som drift. Med en ændringslog, er det en forventet baseline-tilbagestilling. God overvågningssoftware gør denne forskel kedelig og eksplicit.
Operationscheckliste
- Send per-kørselsbeslutningshændelser (værktøj, args-hash, resultatklassen, gentagningsantal). - Gem en afspilbar rækkefølge for hver pagineret incident. - Baseline per agentidentitet; nulstil ved model-/prompt-/værktøjændringer. - Adskil detektion (overvågning) fra gennemtvingelse (sikkerhedsforanstaltninger / trinbegrænsninger). - Markedsfør aldrig 100% detektion eller aldrig-miss-sikkerhed.
Instrumenteringstips der reducerer falske positiver
Hash værktøjsargumenter før sammenligning. Præcis strenglighed på fri-form JSON skaber støj, når tidsstempel eller anmodnings-id'er forskellige. En stabil fingeraftryk af semantiske felter (forespørgselsTekst, ressource-id, handlingens navn) holder løkke-detektion ærlig uden at gemme fulde payload-nyttesløsigt for evigt.
Separat brugerinitierede forsøg fra agentinitierede forsøg. Et menneske, der klikker på "prøv igen", er ikke det samme fejltilfælde som en agent, der genindtræder i samme planlægningsnode. Tag initiativtagere på hver forsøgsbegivenhed, så dine overvågningsregler kan behandle dem forskelligt.
Udeluk kendte lange arbejdsgange fra standardvarighedssiden. Batchforskningsagenter kan legitimt køre i minutter. Sæt disse agent-id'er på en tilladelsesliste med en højere bånd, i stedet for at lukke hele flåden.
Versionér dine overvågningsregler på samme måde, som du versionerer prompts. Når en regel ændres, annotér dashboardet, så en spids ikke mislæses som agentdrift. Fremvoksende producentemittede scorekonventioner anbefaler allerede metoden tokens til dette formål — anvend samme disciplin til dine egne detektorer.
Skits over on-call playbook
- Åbn watch-indgangen og bekræft, at sporet viser en reel løkke eller driftmønster. - Tjek ændringsloggen for model, prompt eller værktøjsaktivering i de sidste 24 timer. - Hvis bekræftet løkke, aktiver eller stram runtime-trinbegrænsningen for den pågældende agentidentitet. - Hvis bekræftet drift efter en udgivelse, rul tilbage eller genbasér med en ekspllicit note. - Hvis sporet er ufuldstændigt, fikser instrumentationen før flere sider hæves — advarsler uden bevis spilder tillid.
Dokumenter lukkeårsagen på hver side. Mønstre som "falsk positiv på grund af trafikblandning" lærer den næste vagt, hvad der skal ignoreres. Mønstre som "prompt regression" lærer ingeniøren, hvad der skal testes før udskibning.
Hvad AgentPulse ikke vil opfinde
Vi vil ikke opfinde kunde-logoer, op-tid-procent eller påstande om "reducerede incidenter med X%". Sociale bevissektioner forbliver markeret som PENDING, indtil ægte citater findes. ROI-numre i indholdsmodulet er skabeloner. Det er en bevidst FTC-orienteret tilbageholdenhed, ikke ufuldendt marketing.
Ofte stillede spørgsmål
Hvad er forskellen på en løkke og en lang kørsel?
En lang kørsel gør fremskridt. En løkke gentager et trin eller en næsten identisk variant uden at komme nærmere målet.
Hvordan undgår vi alert træthed?
Alert på ændringshastighed i forhold til agentens egen baseline, og kræv en replaybar spor, så hver alert kan lukkes hurtigt.
Hvad bryder en baseline?
En modelændring, en ændring af prompt, et nyt værktøj eller en ændring i trafikblandingen. Optegn disse, så du ikke læser dem som uforklaret drift.
Skal en løkke stoppe agenten?
Det er en runtime guardrail-beslutning, ikke en overvågningsbeslutning. Overvågning fortæller dig, at det skete, en trinbegrænsning stopper det.
Hvor længe skal spor gemmes?
Længe nok til at undersøge, kort nok til at respektere, hvad du lovede brugerne om opbevaring. Spor indeholder normalt brugerindhold.
Er drift altid dårligt?
Nej. Trafikændringer kan forklare det. Drift er en prompt til at se, ikke en dom.
Erstatrer AgentPulse OpenTelemetry?
Nej. OTel er plumbing. AgentPulse er et fokuseret watch-report-produkt, der kan sidde ved siden af OTel-baserede pipelines.
Referencer
- OpenTelemetry — GenAI overvågning (2026) - OTel GenAI agent spans - NIST — AI Risikostyringsramme
Prøv produktet: AgentPulse
2026-09-26 · kun primærkilder · ingen fabrikerede trafikmålinger · beslutningsstøtte kun · RULESET_VERSION 2026-09-26
Relaterede artikler
- Agent overvågning vs klassisk APM - Udforsk det fulde AI mikro-SaaS emne matrix →
Hvorfor fejler latency-kun-alarm for agenter?
Klassisk serviceovervågning voksede op omkring en anmodning, der starter, slutter og returnerer en statuskode. En autonom agent-kørsel overholder ikke den kontrakt. Den kan kalde værktøjer i et træ, gentage det samme værktøj med lidt forskellige argumenter, opgive en plan midtvejs eller fortsætte længe efter, at et menneske ville have stoppet. En grøn p99-latency-kort kan sidde ved siden af en løbsk planlægger, der brænder tokens, mens den ikke gør fremskridt.
Hvad er en fire-trins overvågningsmønster?
Ikke page på hver langsom kørsel. Lange kørsler, der stadig fremskridter, er ikke løkker. Alert-træthed er, hvordan overvågningsprodukter dør. Foretræk rate-of-change mod en agent-specifik baseline, og kræv derefter en sti, så hver alarm kan lukkes med bevis.
Hvad er signaler værd at page på?
Ikke page på hver langsom kørsel. Lange kørsler, der stadig fremskridter, er ikke løkker. Alert-træthed er, hvordan overvågningsprodukter dør. Foretræk rate-of-change mod en agent-specifik baseline, og kræv derefter en sti, så hver alarm kan lukkes med bevis.
Hvad er Baselines bryder - optag hvorfor?
En modelændring, en prompt-ændring, et nyt værktøj eller en ændring i trafikmix vil flytte dine numre. Hvis du ikke optager disse begivenheder, ser hver udgivelse ud som mystisk drift. Hold en simpel ændringslog ved siden af metric: hvilken model, hvilken prompt-hash, hvilke værktøjer var aktiveret, og hvornår trafikkompositionen skiftede. Forbrugere af producer-emitterede scores (tillid, drift, scan) i fremvoksende OTel-forslag er allerede advaret om, at metode-token matter - når scoringsmetoden ændrer, gen-anker korrelation i stedet for at behandle springet som agent-misbehaviour.
Hvad er overvågning ikke?
Overvågning fortæller dig, at noget skete. En runtime-trin-grænse eller guardrail stopper det. At forveksle de to fører til over-krav. AgentPulse garanterer ikke, at alarmer altid vil udløse i tide til at forhindre bruger-impact. Vi hævder ikke 100% detektion. Vi hævder ikke, at du aldrig vil misse en løkke. Disse ærlighedslinjer findes, fordi FTC-stil-markedsføringsregler straffer fabrikeret sikkerhed, og fordi operatører fortjener værktøjer, der angiver deres begrænsninger.
Beslutningsstøtte kun. Ikke en uptime-SLA, sikkerhedsaudit eller garanti for, at agenter aldrig fejler.