SigNoz హ్యాకథాన్ కోసం రూపొందించిన కొత్త అబ్జర్వబిలిటీ-డ్రివెన్ (observability-driven) వర్క్‌ఫ్లో సహాయంతో, ఇప్పుడు నాలుగు స్వయంప్రతిపత్త AI ఏజెంట్లు సాఫ్ట్‌వేర్ లోపాన్ని గుర్తించి, దానికి కారణమైన కోడ్‌ను ఎడిట్ చేసి, ఆ పరిష్కారాన్ని ధృవీకరించగలవు—అదీ ఒక నిమిషం కంటే తక్కువ సమయంలో.

AgentOps అని పిలువబడే ఈ వ్యవస్థ, SigNoz లో ఎర్రర్ స్పైక్‌ల (error spikes) కోసం నిఘా పెడుతుంది, సంబంధిత లాగ్‌లు మరియు ట్రేస్‌లను సేకరిస్తుంది, దానికి కారణమైన ఖచ్చితమైన ఫైల్ మరియు లైన్‌ను గుర్తిస్తుంది, సాండ్‌బాక్స్‌లో సోర్స్ కోడ్‌ను ఎడిట్ చేస్తుంది, ఆపై బగ్ పోయిందని నిరూపించడానికి రిక్వెస్ట్‌ను మళ్ళీ రన్ చేస్తుంది. ప్రతి పూర్తి సైకిల్ 30-60 సెకన్లలో పూర్తవుతుంది మరియు ఈ మొత్తం ప్రక్రియ మానవ ప్రమేయం లేకుండానే జరుగుతుంది.

AI ఏజెంట్లకు అబ్జర్వబిలిటీ (observability) ఎందుకు ముఖ్యం

సాంప్రదాయ SRE పద్ధతిలో లాగ్‌లు, మెట్రిక్స్ మరియు డిస్ట్రిబ్యూటెడ్ ట్రేస్‌లను ఒక సర్వీస్‌కు కళ్లుగా పరిగణిస్తారు. ఒక రిక్వెస్ట్ విఫలమైనప్పుడు, ఇంజనీర్ ఆ ట్రేస్‌ను అనుసరిస్తూ సమస్య ఉన్న కాంపోనెంట్‌ను కనుగొంటారు. అదే సూత్రం ఇప్పుడు AgentOps కి కూడా పనిచేస్తుంది, కానీ ఇక్కడ పరిశీలించబడే "సర్వీస్" స్వయంగా AI ఏజెంట్.

ఏజెంట్ ఉపయోగించే ప్రతి సాధనం—అది లాంగ్వేజ్ మోడల్ కాల్ అయినా, ఫైల్-సిస్టమ్ ఎడిట్ అయినా లేదా టెస్ట్ రన్నర్ అయినా—ట్రేస్‌లో ఒక స్పాని (span) సృష్టిస్తుంది. ఒక స్పాన్ ప్రారంభ సమయం, వ్యవధి మరియు విజయ స్థితిని రికార్డ్ చేస్తుంది, తద్వారా ఏజెంట్ ప్రతి రీజనింగ్ స్టెప్ ఎంత సమయం తీసుకుంది మరియు అది విజయవంతమైందో లేదో చూడగలదు. మనుషులు మాన్యువల్‌గా డీబగ్ చేసేటప్పుడు ఎలా చేస్తారో, అలాగే ఈ స్పాన్‌లను కలిపి చూడటం ద్వారా ఏజెంట్ తన స్వంత ఆలోచనా ప్రక్రియ యొక్క పూర్తి చిత్రాన్ని నిర్మించుకుంటుంది.

ఇక్కడ ప్రధాన మార్పు "రిపోర్టింగ్ లేయర్‌గా అబ్జర్వబిలిటీ" నుండి "గ్రహణ శక్తిగా (perception) అబ్జర్వబిలిటీ" కి మారింది. AgentOps ట్రేస్ డేటాను తిరిగి ఏజెంట్లకు అందిస్తుంది, తద్వారా అవి రియల్ టైమ్‌లో తమ స్వంత చర్యల గురించి ఆలోచించగలవు. దీని ఫలితంగా, AI కేవలం ఒక ఊహను (hypothesis) మాత్రమే సృష్టించడమే కాకుండా, సమస్యను గుర్తించడానికి ఉపయోగించిన టెలిమెట్రీ (telemetry) ఆధారంగానే దానిని ధృవీకరిస్తుంది.

నాలుగు దశల వర్క్‌ఫ్లో

  1. Monitor – ఒక లైట్‌వెయిట్ వాచర్ (watcher) కొత్తగా రిపోర్ట్ చేయబడిన ఎర్రర్‌ల కోసం SigNoz ని స్కాన్ చేస్తుంది.
  2. Diagnose – ఏజెంట్ సంబంధిత లాగ్‌లు మరియు ట్రేస్‌లను సేకరించి, స్టాక్‌ను సంగ్రహించి, వైఫల్యానికి కారణమైన సోర్స్ ఫైల్ మరియు లైన్ నంబర్‌ను వేరు చేస్తుంది.
  3. Fix – సాండ్‌బాక్స్‌డ్ ఫైల్-సిస్టమ్ సర్వర్‌ను ఉపయోగించి, ఏజెంట్ గుర్తించిన లైన్‌లో ఒక ప్యాచ్‌ను రాస్తుంది. సాండ్‌బాక్స్ కఠినమైన అనుమతులను అమలు చేస్తుంది మరియు ఎడిట్ పాలసీని ఉల్లంఘిస్తే ఆటోమేటిక్‌గా రోల్‌బ్యాక్ చేస్తుంది.
  4. Verify – ఏజెంట్ ప్యాచ్ చేసిన కోడ్‌పై అసలు రిక్వెస్ట్‌ను మళ్ళీ పంపిస్తుంది. ట్రేస్ విజయవంతంగా పూర్తయిందని చూపిస్తే, ఆ పరిష్కారం ఖరారు చేయబడుతుంది; లేకపోతే ఏజెంట్ మళ్ళీ ప్రయత్నిస్తుంది.

ఈ దశలన్నీ ఒకే ఏజెంట్ల సమూహం ద్వారా నిర్వహించబడతాయి, ప్రతి ఏజెంట్ ఒక స్వయంప్రతిపత్త మైక్రో-సర్వీస్‌గా పనిచేస్తుంది. ఈ మొత్తం ప్రక్రియ OpenTelemetry-అనుకూలమైన స్పాన్‌ల ద్వారా గమనించవచ్చు, వీటిని SigNoz స్వీకరించి విజువలైజ్ చేస్తుంది.

విశ్వసనీయతపై కష్టపడి నేర్చుకున్న పాఠాలు

ఎర్రర్ స్పష్టత (Error clarity)

సాధారణ "failed" స్టేటస్ ఏమీ చెప్పదు. తదుపరి ఏజెంట్లు మళ్ళీ ప్రయత్నించాలా, వెనక్కి వెళ్ళాలా లేదా నిలిపివేయాలా అనేది నిర్ణయించుకోవడానికి వీలుగా, బృందం "తప్పు ఊహ" (wrong hypothesis) లేదా "ప్యాచ్ ప్రాసెస్‌ను దెబ్బతీసింది" (patch broke process) వంటి వివరణాత్మక వైఫల్య కారణాలను జోడించింది. ఇది మనుషులు పోస్ట్‌మార్టమ్ (post-mortem) చేసేటప్పుడు మూల కారణాలను గుర్తించే విధానాన్ని పోలి ఉంటుంది.

డేటా లేటెన్సీ (Data latency)

టెలిమెట్రీ వెంటనే కనిపించదు. ఏజెంట్లు ఒక పరిష్కారాన్ని ధృవీకరించే ముందు, అవసరమైన లాగ్‌లు వచ్చాయని నిర్ధారించుకోవడానికి ఇప్పుడు ఒక చిన్న విరామం మరియు శానిటీ చెక్ (sanity check) చేస్తాయి. ఈ జాగ్రత్త లేకపోతే, ఏజెంట్ అసంపూర్ణ డేటా ఆధారంగా పనిచేసి తప్పుడు ఫలితాన్ని (false positive) ఇచ్చే అవకాశం ఉంది.

భద్రతా పరిమితులు (Security boundaries)

AIని కోడ్ రాయడానికి అనుమతించడం అనేది ప్రివిలేజ్ ఎస్కలేషన్ (privilege escalation) ప్రమాదానికి దారితీస్తుంది. సాండ్‌బాక్స్ ఒక ప్రత్యేక ఫైల్‌సిస్టమ్ సర్వర్ వెనుక నడుస్తుంది, ఇది రైట్ స్కోప్‌ను కేవలం టార్గెట్ రిపోజిటరీకి మాత్రమే పరిమితం చేస్తుంది మరియు టెస్ట్ విఫలమైతే ఆటోమేటిక్‌గా మునుపటి స్థితికి మారుస్తుంది. ఈ కంటైన్‌మెంట్ మోడల్ AI యొక్క శక్తిని నియంత్రణలో ఉంచుతుంది.

టోకెన్ పరిమితులు (Token limits)

లార్జ్ లాంగ్వేజ్ మోడల్స్ API టోకెన్లను ఉపయోగిస్తాయి మరియు దైనందిన కోటా విచారణ మధ్యలోనే అయిపోయే అవకాశం ఉంది. AgentOps ప్రతి ఇన్సిడెంట్‌కు టోకెన్ వినియోగాన్ని ట్రాక్ చేస్తుంది మరియు ఒక పరిమితికి చేరుకున్న తర్వాత తదుపరి కాల్స్‌ను నియంత్రిస్తుంది, తద్వారా కోటా అయిపోయినప్పుడు వరుసగా ఫెయిల్ అయ్యే పరిష్కారాలను నివారిస్తుంది.

డెమో ఏమి నిరూపించింది

బృందం కోడ్‌బేస్‌లో ఎప్పుడూ లేని సరికొత్త బగ్‌ను సృష్టించింది. AgentOps ఆ అసాధారణతను గుర్తించి, ఖచ్చితమైన లైన్‌ను ట్రాస్ చేసి, సరిదిద్దే ఎడిట్‌ను రూపొందించింది, సాండ్‌బాక్స్‌లో ప్యాచ్‌ను వర్తింపజేసింది మరియు రిక్వెస్ట్ విజయవంతమైందని ధృవీకరించింది—ఇదంతా ఎటువంటి మాన్యువల్ కోడ్ మార్పులు లేదా కొత్త ప్రాంప్ట్‌లు లేకుండానే జరిగింది. మొత్తం సమయం ఒక నిమిషం కంటే తక్కువగా ఉంది, ఇది నివేదించిన 30-60 సెకన్ల వ్యవధికి సరిపోలుతుంది.

ప్రతిపాదనకు విరుద్ధంగా: స్వయంప్రతిపత్తి అనేది అన్ని సమస్యలకు పరిష్కారం కాదు

తదుపరి ఏమి గమనించాలి

  • Model-agnostic telemetry – మరింత మంది వెండర్లు OpenTelemetry-అనుకూలమైన స్పాన్‌లను (spans) అందుబాటులోకి తెస్తున్న కొద్దీ, ఈ విధానం వెండర్-తటస్థంగా (vendor-neutral) మారి, భిన్నమైన స్టాక్‌లలో (heterogeneous stacks) దీని వినియోగాన్ని సులభతరం చేస్తుంది.
  • Policy-driven guardrails – ఏ ఫైల్‌లను ఏజెంట్ ఎడిట్ చేయవచ్చు లేదా కమిట్‌కు ముందు ఏ టెస్ట్ సూట్‌లు ఉత్తీర్ణత సాధించాలో నిర్ణయించే కాన్ఫిగర్ చేయగల పాలసీలను పొందుపరచడం ద్వారా, గవర్నెన్స్ (governance) ఆందోళనలను పరిష్కరించవచ్చు.
  • Cost-aware token budgeting – ఇన్సిడెంట్ తీవ్రత ఆధారంగా డైనమిక్ టోకెన్ కేటాయింపు చేయడం ద్వారా, కోటా అయిపోకుండా నిరోధించడమే కాకుండా, అధిక ప్రభావం చూపే బగ్‌లను (high-impact bugs) పరిష్కరించే సామర్థ్యాన్ని కూడా కాపాడుకోవచ్చు.

AgentOps ప్రకారం బగ్-ఫిక్స్ సైకిల్ 30-60 సెకన్ల సమయం తీసుకోవచ్చు. స్వయంప్రతిపత్తి కలిగిన సాఫ్ట్‌వేర్ అసిస్టెంట్లు అబ్జర్వబిలిటీని (observability) ఉపయోగించవచ్చని ఈ ప్రయోగం ఒక ప్రూఫ్-ఆఫ్-కాన్సెప్ట్‌ను నిరూపిస్తుంది.