چار خود مختار AI ایجنٹس اب سافٹ ویئر کی خرابی (glitch) کو پہچان سکتے ہیں، متعلقہ کوڈ کو ایڈٹ کر سکتے ہیں اور درستگی کی تصدیق بھی کر سکتے ہیں—یہ سب ایک منٹ سے بھی کم وقت میں ممکن ہوا ہے، اور اس کی وجہ SigNoz ہیکاتھون کے لیے بنایا گیا ایک نیا observability-driven ورک فلو ہے۔
AgentOps نامی یہ سسٹم SigNoz میں غلطیوں کے اضافے (error spikes) پر نظر رکھتا ہے، متعلقہ logs اور traces حاصل کرتا ہے، ذمہ دار فائل اور لائن کا درست تعین کرتا ہے، ایک sandbox میں سورس کوڈ کو ایڈٹ کرتا ہے، اور پھر یہ ثابت کرنے کے لیے کہ بگ ختم ہو گیا ہے، دوبارہ وہی ریکویسٹ (request) چلا کر دیکھتا ہے۔ ہر مکمل سائیکل 30 سے 60 سیکنڈ میں مکمل ہو جاتا ہے، اور یہ پورا عمل انسانی مداخلت یا کسی پرامپٹ (prompt) کے بغیر چلتا ہے۔
AI ایجنٹس کے لیے observability کیوں اہم ہے
روایتی SRE طریقہ کار میں logs، metrics اور distributed traces کو کسی سروس کی "آنکھوں" کے طور پر دیکھا جاتا ہے۔ جب کوئی ریکویسٹ فیل ہوتی ہے، تو ایک انجینئر اس مسئلے والے حصے (component) تک پہنچنے کے لیے trace کا پیچھا کرتا ہے۔ یہی اصول اب AgentOps کو طاقت فراہم کر رہا ہے، لیکن یہاں جس "سروس" کی نگرانی کی جا رہی ہے وہ خود AI ایجنٹ ہے۔
ایجنٹ جو بھی ٹول استعمال کرتا ہے—خواہ وہ language model call ہو، file-system edit ہو یا test runner—وہ trace میں ایک span تخلیق کرتا ہے۔ ایک span آغاز کا وقت، دورانیہ اور کامیابی کی صورتحال (success status) کو ریکارڈ کرتا ہے، تاکہ ایجنٹ دیکھ سکے کہ ہر منطقی قدم (reasoning step) میں کتنا وقت لگا اور آیا وہ کامیاب رہا یا نہیں۔ ان spans کو آپس میں جوڑ کر، ایجنٹ اپنے سوچنے کے عمل کی ایک مکمل تصویر تیار کرتا ہے، بالکل اسی طرح جیسے ایک انسان دستی طور پر ڈی بگنگ (debugging) کرتے وقت کرتا ہے۔
اصل تبدیلی "reporting layer کے طور پر observability" سے "perception کے طور پر observability" کی طرف ہے۔ AgentOps trace ڈیٹا کو واپس ایجنٹس کو فراہم کرتا ہے، جس سے وہ ریئل ٹائم میں اپنے اپنے اقدامات کے بارے میں منطقی فیصلہ کر سکتے ہیں۔ اس کا نتیجہ ایک ایسے لوپ (loop) کی صورت میں نکلتا ہے جہاں AI نہ صرف ایک مفروضہ (hypothesis) تیار کرتا ہے بلکہ اسی telemetry کے ذریعے اس کی تصدیق بھی کرتا ہے جسے وہ مسئلے کی نشاندہی کے لیے استعمال کرتا ہے۔
چار مرحلہ وار ورک فلو
- Monitor – ایک ہلکا پھلکا watcher SigNoz میں رپورٹ ہونے والی نئی غلطیوں کو اسکین کرتا ہے۔
- Diagnose – ایجنٹ متعلقہ logs اور traces حاصل کرتا ہے، stack کو نکالتا ہے، اور اس فائل اور لائن نمبر کا تعین کرتا ہے جس کی وجہ سے خرابی پیدا ہوئی۔
- Fix – ایک sandboxed file-system server کا استعمال کرتے ہوئے، ایجنٹ شناخت شدہ لائن پر ایک patch لکھتا ہے۔ Sandbox سخت اجازت ناموں (permissions) کو نافذ کرتا ہے اور اگر ایڈٹ پالیسی کی خلاف ورزی کرے تو خود بخود پرانی حالت پر واپس (roll back) چلا جاتا ہے۔
- Verify – ایجنٹ پیچ شدہ (patched) کوڈ کے خلاف اصل ریکویسٹ دوبارہ بھیجتا ہے۔ اگر trace میں کامیابی نظر آئے تو اصلاح (fix) کو مستقل کر دیا جاتا ہے؛ ورنہ ایجنٹ دوبارہ کوشش کرتا ہے۔
تمام مراحل ایجنٹس کے ایک ہی سیٹ کے ذریعے منظم کیے جاتے ہیں، جن میں سے ہر ایک ایک خود مختار micro-service کے طور پر کام کرتا ہے۔ یہ پوری زنجیر OpenTelemetry-compatible spans کے ذریعے قابل مشاہدہ ہے، جنہیں SigNoz حاصل کرتا ہے اور بصری شکل (visualise) میں پیش کرتا ہے۔
بھروسہ مندی (reliability) کے بارے میں حاصل کردہ اہم اسباق
Error clarity
ایک عام سا "failed" اسٹیٹس کچھ نہیں بتاتا۔ ٹیم نے ناکامی کی تفصیلی وجوہات شامل کیں—مثلاً "غلط مفروضہ" یا "patch نے عمل کو خراب کر دیا"—تاکہ بعد کے ایجنٹس فیصلہ کر سکیں کہ آیا دوبارہ کوشش کرنی ہے، پیچھے ہٹنا ہے یا عمل روک دینا ہے۔ یہ بالکل اسی طرح ہے جیسے انسان پوسٹ مارٹم (post-mortems) کے دوران اصل وجوہات (root causes) کی نشاندہی کرتے ہیں۔
Data latency
Telemetry فوری طور پر ظاہر نہیں ہوتی۔ ایجنٹس اب ایک چھوٹا سا وقفہ اور sanity check شامل کرتے ہیں تاکہ یہ یقینی بنایا جا سکے کہ اصلاح کا دعویٰ کرنے سے پہلے مطلوبہ logs پہنچ چکے ہیں۔ اس حفاظتی تدبیر کے بغیر، ایک ایجنٹ نامکمل ڈیٹا پر عمل کر سکتا ہے اور غلط نتیجہ (false positive) دے سکتا ہے۔
Security boundaries
AI کو کوڈ لکھنے کی اجازت دینا سیکیورٹی کے لحاظ سے ایک بڑا خطرہ (privilege escalation risk) ہو سکتا ہے۔ Sandbox ایک مخصوص filesystem server کے پیچھے چلتا ہے جو لکھنے کے دائرہ کار (write scope) کو صرف متعلقہ ریپوزٹری (repository) تک محدود رکھتا ہے اور اگر کوئی ٹیسٹ فیل ہو جائے تو خود بخود پچھلی حالت بحال کر دیتا ہے۔ یہ کنٹینمنٹ ماڈل AI کی طاقت کو قابو میں رکھتا ہے۔
Token limits
Large language models API tokens استعمال کرتے ہیں، اور روزانہ کا کوٹہ تحقیق کے دوران ختم ہو سکتا ہے۔ AgentOps ہر واقعے کے لیے ٹوکن کے استعمال پر نظر رکھتا ہے اور ایک حد (threshold) تک پہنچنے پر مزید کالز کو محدود کر دیتا ہے، تاکہ کوٹہ ختم ہونے پر ناکام اصلاحات کا سلسلہ شروع نہ ہو۔
ڈیمو نے کیا ثابت کیا
ٹیم نے کوڈ بیس میں ایک بالکل نیا بگ (bug) شامل کیا جو پہلے کبھی سامنے نہیں آیا تھا۔ AgentOps نے اس خرابی کو پہچانا، درست لائن تک اس کا سراغ لگایا، اصلاحی ایڈٹ تیار کیا، sandbox میں patch لاگو کیا اور تصدیق کی کہ ریکویسٹ کامیاب رہی—یہ سب بغیر کسی دستی کوڈ کی تبدیلی یا نئے پرامپٹ کے ہوا۔ کل وقت ایک منٹ سے کم رہا، جو کہ رپورٹ کردہ 30 سے 60 سیکنڈ کے دورانیے کے مطابق تھا۔
Counter-point: autonomy isn’t a silver bullet
What to watch next
- ماڈل سے آزاد ٹیلی میٹری (Model-agnostic telemetry) – جیسے جیسے زیادہ وینڈرز OpenTelemetry کے ہم آہنگ spans فراہم کریں گے، یہ طریقہ کار وینڈر سے آزاد ہو سکتا ہے، جس سے مختلف قسم کے (heterogeneous) اسٹیکس میں اس کے استعمال کو آسان بنایا جا سکے گا۔
- پالیسی پر مبنی گارڈ ریلز (Policy-driven guardrails) – ایسی قابلِ ترتیب (configurable) پالیسیاں شامل کرنا جو یہ طے کریں کہ ایجنٹ کن فائلوں میں ترمیم کر سکتا ہے، یا کمٹ (commit) سے پہلے کن ٹیسٹ سویٹس (test suites) کو پاس کرنا ضروری ہے، گورننس کے خدشات کو دور کرے گا۔
- لاگت سے آگاہ ٹوکن بجٹنگ (Cost-aware token budgeting) – واقعے کی شدت کی بنیاد پر متحرک ٹوکن کی تقسیم کوٹہ کے ختم ہونے سے بچا سکتی ہے اور ساتھ ہی زیادہ اثر انداز ہونے والے بگز (high-impact bugs) کو سنبھالنے کی صلاحیت کو بھی برقرار رکھ سکتی ہے۔
AgentOps ظاہر کرتا ہے کہ بگ فکس سائیکل (bug-fix cycle) میں 30-60 سیکنڈ لگ سکتے ہیں۔ یہ تجربہ ایک 'پروف آف کانسیپٹ' (proof-of-concept) کے طور پر یہ ثابت کرتا ہے کہ خود مختار سافٹ ویئر اسسٹنٹس (autonomous software assistants) کے ذریعے observability کا استعمال کیا جا سکتا ہے۔