चार स्वायत्त AI एजंट्स आता सॉफ्टवेअरमधील त्रुटी (glitch) शोधू शकतात, संबंधित कोडमध्ये बदल करू शकतात आणि तो बदल बरोबर आहे की नाही याची खात्री करू शकतात—तेही एका मिनिटाच्या आत. हे SigNoz हॅकाथॉनसाठी तयार केलेल्या नवीन observability-driven workflow मुळे शक्य झाले आहे.
AgentOps नावाचे हे सिस्टम SigNoz मध्ये एरर स्पाइक्स (error spikes) शोधते, संबंधित लॉग्स (logs) आणि ट्रेसेस (traces) गोळा करते, त्रुटीसाठी जबाबदार असलेली नेमकी फाईल आणि ओळ (line) शोधून काढते, सँडबॉक्समध्ये (sandbox) मूळ कोडमध्ये बदल करते आणि त्यानंतर तो बग दूर झाला आहे हे सिद्ध करण्यासाठी पुन्हा रिक्वेस्ट पाठवते. प्रत्येक पूर्ण चक्र ३०-६० सेकंदात पूर्ण होते आणि ही संपूर्ण प्रक्रिया मानवी हस्तक्षेपाशिवाय (without a single human prompt) चालते.
AI एजंट्ससाठी observability का महत्त्वाची आहे
पारंपारिक SRE पद्धतीमध्ये लॉग्स, मेट्रिक्स आणि डिस्ट्रिब्युटेड ट्रेसेसना (distributed traces) एखाद्या सर्व्हिसचे 'डोळे' मानले जाते. जेव्हा एखादी रिक्वेस्ट फेल होते, तेव्हा इंजिनिअर त्या ट्रेसचा वापर करून त्रुटी असलेल्या घटकापर्यंत पोहोचतो. हेच तत्त्व आता AgentOps ला चालवते, परंतु येथे ज्या 'सर्व्हिस'चे निरीक्षण केले जात आहे, ती स्वतः AI एजंट आहे.
एजंट वापरत असलेले प्रत्येक टूल—मग ते लँग्वेज मॉडेल कॉल असो, फाईल-सिस्टममधील बदल असो किंवा टेस्ट रनर असो—ट्रेसमध्ये एक 'span' तयार करते. एक 'span' ही सुरुवात होण्याची वेळ, कालावधी आणि यशाची स्थिती नोंदवते, ज्यामुळे एजंटला प्रत्येक विचार प्रक्रियेचा (reasoning step) किती वेळ लागला आणि ती यशस्वी झाली की नाही, हे पाहता येते. या स्पॅन्सना एकत्र जोडून, एजंट स्वतःच्या विचार प्रक्रियेचे संपूर्ण चित्र तयार करतो, अगदी एखाद्या माणसाने मॅन्युअली डीबगिंग करताना करत असल्याप्रमाणे.
मुख्य बदल म्हणजे "observability ही केवळ रिपोर्टिंग लेयर नसून ती एक 'perception' (जाणीव/दृष्टी) आहे." AgentOps ट्रेस डेटा पुन्हा एजंट्सना पुरवते, ज्यामुळे त्यांना त्यांच्या स्वतःच्या कृतींबद्दल रिअल-टाइममध्ये विचार करता येतो. याचा परिणाम असा होतो की, AI केवळ एक गृहितक (hypothesis) मांडत नाही, तर समस्या शोधण्यासाठी ज्या टेलिमेट्रीचा (telemetry) वापर केला होता, त्याच टेलिमेट्रीच्या आधारे त्याचे प्रमाणीकरण (validate) देखील करते.
चार-टप्प्यांची कार्यप्रणाली (workflow)
- Monitor – एक हलका (lightweight) वॉचर SigNoz मध्ये नवीन रिपोर्ट झालेल्या त्रुटी शोधतो.
- Diagnose – एजंट संबंधित लॉग्स आणि ट्रेसेस गोळा करतो, स्टॅक एक्सट्रॅक्ट करतो आणि त्रुटी निर्माण करणारी मूळ फाईल आणि ओळ (line number) वेगळी करतो.
- Fix – सँडबॉक्स फाईल-सिस्टम सर्व्हरचा वापर करून, एजंट शोधलेल्या ओळीवर पॅच (patch) लिहितो. सँडबॉक्स कडक परवानग्या लागू करतो आणि जर बदल धोरणांचे (policy) उल्लंघन करत असतील, तर तो आपोआप पूर्वस्थितीत (rollback) येतो.
- Verify – एजंट सुधारित कोडवर मूळ रिक्वेस्ट पुन्हा पाठवतो. जर ट्रेसमध्ये सर्व काही व्यवस्थित दिसले, तर दुरुस्ती कायम (commit) केली जाते; अन्यथा एजंट पुन्हा प्रयत्न करतो.
हे सर्व टप्पे एजंट्सच्या एकाच संचाद्वारे नियंत्रित केले जातात, ज्यातील प्रत्येक एजंट एका स्वायत्त मायक्रो-सर्व्हिसप्रमाणे (autonomous micro-service) काम करतो. ही संपूर्ण साखळी OpenTelemetry-सुसंगत स्पॅन्सद्वारे (spans) पाहता येते, जे SigNoz द्वारे ग्रहण आणि व्हिज्युअलाइज केले जातात.
विश्वासार्हतेबद्दलचे महत्त्वाचे धडे
Error clarity (त्रुटींची स्पष्टता)
केवळ "failed" असे सामान्य स्टेटस काहीच सांगत नाही. टीमने त्रुटींची सविस्तर कारणे जोडली आहेत—उदा. "चुकीचे गृहितक" किंवा "पॅचमुळे प्रक्रिया बिघडली"—जेणेकरून पुढील एजंट्सना पुन्हा प्रयत्न करायचा, मागे हटायचे की प्रक्रिया थांबवायची, याचा निर्णय घेता येईल. हे मानवी post-mortems मध्ये मूळ कारणे (root causes) दर्शवण्याच्या पद्धतीसारखेच आहे.
Data latency (डेटा लॅटन्सी)
टेलिमेट्री त्वरित उपलब्ध होत नाही. एजंट्स आता दुरुस्तीची खात्री करण्यापूर्वी आवश्यक लॉग्स पोहोचले आहेत की नाही, हे तपासण्यासाठी थोडा वेळ थांबतात आणि 'sanity check' करतात. या संरक्षणाशिवाय, एजंट अपूर्ण डेटावर कृती करू शकतो आणि चुकीचा निष्कर्ष (false positive) काढू शकतो.
Security boundaries (सुरक्षा मर्यादा)
AI ला कोड लिहिण्याची परवानगी देणे हे 'privilege escalation' जोखमीचे असू शकते. सँडबॉक्स एका समर्पित फाईलसिस्टम सर्व्हरच्या मागे चालतो, जो लेखनाची व्याप्ती (write scope) केवळ लक्ष्यित रिपॉझिटरीपुरती मर्यादित ठेवतो आणि जर टेस्ट फेल झाली तर आपोआप पूर्वस्थिती पुन्हा आणतो. हे containment model AI च्या शक्तीवर नियंत्रण ठेवते.
Token limits (टोकन मर्यादा)
लार्ज लँग्वेज मॉडेल्स API टोकन्स वापरतात आणि तपासणी दरम्यान दैनंदिन कोटा संपू शकतो. AgentOps प्रत्येक घटनेसाठी टोकन वापराचा मागोवा घेतो आणि एकदा ठराविक मर्यादा गाठली की पुढील कॉल्स मर्यादित (throttle) करतो, ज्यामुळे कोटा संपल्यावर दुरुस्तीच्या अयशस्वी प्रयत्नांची साखळी तयार होण्यापासून रोखता येते.
डेमोने काय सिद्ध केले
टीमने कोडबेसमध्ये कधीही न आलेल्या एका नवीन बगचा समावेश केला. AgentOps ने ही विसंगती (anomaly) शोधली, ती नेमक्या ओळीपर्यंत शोधली, दुरुस्तीसाठी बदल तयार केला, सँडबॉक्समध्ये पॅच लागू केला आणि रिक्वेस्ट यशस्वी झाली की नाही याची पडताळणी केली—हे सर्व कोणत्याही मॅन्युअल कोड बदलाशिवाय किंवा नवीन प्रॉम्प्ट्सशिवाय झाले. संपूर्ण प्रक्रियेचा वेळ एक मिनिटाच्या आत राहिला, जो रिपोर्ट केलेल्या ३०-६० सेकंदांच्या कालावधीशी सुसंगत आहे.
प्रतिवाद: स्वायत्तता म्हणजे सर्व समस्यांचे रामबाण उपाय नाही (autonomy isn’t a silver bullet)
पुढे काय पाहावे
- मॉडेल-स्वतंत्र टेलिमेट्री – जसजसे अधिक विक्रेते OpenTelemetry-सुसंगत स्पॅन्स उपलब्ध करून देतील, तसा हा दृष्टिकोन विक्रेता-तटस्थ होऊ शकतो, ज्यामुळे विविध प्रकारच्या स्टॅक्समध्ये त्याचा अवलंब करणे सोपे होईल.
- धोरण-आधारित गार्डरेल्स – एजंट कोणत्या फाईल्स संपादित करू शकतो किंवा कमिट करण्यापूर्वी कोणते टेस्ट सूट्स पास होणे आवश्यक आहे हे ठरवणारी कॉन्फिगर करण्यायोग्य धोरणे समाविष्ट केल्यामुळे गव्हर्नन्सशी संबंधित चिंता दूर होतील.
- खर्च-जाणीव असलेले टोकन बजेटिंग – घटनेच्या तीव्रतेनुसार डायनॅमिक टोकन वाटप केल्यामुळे कोटा संपण्यापासून रोखता येईल आणि त्याच वेळी उच्च-प्रभाव असलेल्या बग्सना हाताळण्याची क्षमता देखील टिकवून ठेवता येईल.
AgentOps दर्शवते की बग-फिक्स सायकलला ३०-६० सेकंद लागू शकतात. हा प्रयोग एक 'प्रूफ-ऑफ-कॉन्सेप्ट' सिद्ध करतो की ऑब्झर्व्हेबिलिटीचा वापर स्वायत्त सॉफ्टवेअर असिस्टंट्सद्वारे केला जाऊ शकतो.