چهار عامل هوش مصنوعی خودمختار اکنون میتوانند یک نقص نرمافزاری را شناسایی، کد مربوطه را ویرایش و اصلاحیه را تأیید کنند—همه اینها در کمتر از یک دقیقه، به لطف یک گردشکار جدید مبتنی بر مشاهدهپذیری (observability) که برای هکاتون SigNoz ساخته شده است.
این سیستم که AgentOps نامیده میشود، SigNoz را برای شناسایی جهشهای خطا زیر نظر میگیرد، لاگها و تریسهای مرتبط را استخراج میکند، دقیقاً فایل و خط مسئول را مشخص میکند، کد منبع را در یک محیط سندباکس (sandbox) ویرایش میکند و سپس درخواست را مجدداً اجرا میکند تا ثابت کند باگ برطرف شده است. هر چرخه کامل در ۳۰ تا ۶۰ ثانیه به پایان میرسد و کل فرآیند بدون حتی یک دستور (prompt) انسانی اجرا میشود.
چرا مشاهدهپذیری برای عاملهای هوش مصنوعی اهمیت دارد
شیوههای سنتی SRE، لاگها، متریکها و تریسهای توزیعشده را به عنوان «چشمهای» یک سرویس در نظر میگیرند. وقتی یک درخواست با شکست مواجه میشود، یک مهندس تریس را تا رسیدن به مؤلفه مقصر دنبال میکند. همین اصل اکنون قدرتبخش AgentOps است، اما «سرویسی» که مشاهده میشود، خودِ عامل هوش مصنوعی است.
هر ابزاری که عامل فراخوانی میکند—خواه فراخوانی یک مدل زبانی باشد، یا ویرایش سیستم فایل یا اجرای یک تست—یک span در تریس ایجاد میکند. یک span زمان شروع، مدت زمان و وضعیت موفقیت را ثبت میکند، بنابراین عامل میتواند ببیند هر مرحله از استدلال چقدر طول کشیده و آیا موفق بوده است یا خیر. با کنار هم قرار دادن این spanها، عامل تصویری کامل از فرآیند فکری خود میسازد، درست همانطور که یک انسان هنگام عیبیابی دستی انجام میدهد.
تغییر کلیدی از «مشاهدهپذیری به عنوان یک لایه گزارشدهی» به «مشاهدهپذیری به عنوان ادراک» است. AgentOps دادههای تریس را دوباره به عاملها بازمیگرداند و به آنها اجازه میدهد در لحظه درباره اقدامات خود استدلال کنند. نتیجه، حلقهای است که در آن هوش مصنوعی نه تنها یک فرضیه ایجاد میکند، بلکه آن را با همان تلمتری (telemetry) که برای شناسایی مشکل استفاده میکند، اعتبارسنجی میکند.
گردشکار چهار مرحلهای
- مانیتورینگ (Monitor) – یک ناظر سبک، SigNoz را برای خطاهای جدید گزارششده اسکن میکند.
- تشخیص (Diagnose) – عامل، لاگها و تریسهای مرتبط را استخراج کرده، استک (stack) را تحلیل میکند و فایل و شماره خطی که باعث بروز خطا شده را ایزوله میکند.
- اصلاح (Fix) – با استفاده از یک سرور سیستم فایل در محیط سندباکس، عامل یک وصله (patch) را در خط شناساییشده مینویسد. سندباکس مجوزهای سختگیرانهای را اعمال کرده و اگر ویرایش با سیاستها مغایرت داشته باشد، بهطور خودکار بازگشت (rollback) انجام میدهد.
- تأیید (Verify) – عامل درخواست اصلی را دوباره روی کد اصلاحشده اجرا میکند. اگر تریس نشاندهنده اجرای موفق باشد، اصلاحیه اعمال (commit) میشود؛ در غیر این صورت، عامل فرآیند را تکرار میکند.
تمام مراحل توسط همان مجموعه از عاملها هماهنگ میشود که هر کدام به عنوان یک میکروسرویس خودمختار عمل میکنند. کل این زنجیره از طریق spanهای سازگار با OpenTelemetry قابل مشاهده است که SigNoz آنها را دریافت و بصریسازی میکند.
درسهای سختبهدستآمده در مورد قابلیت اطمینان
شفافیت خطا
یک وضعیت کلی مانند "failed" هیچ اطلاعاتی نمیدهد. تیم دلایل شکست جزئینگرانه را اضافه کرد—مثلاً "فرضیه اشتباه" یا "وصله باعث خرابی فرآیند شد"—تا عاملهای پاییندست بتوانند تصمیم بگیرند که آیا دوباره تلاش کنند، به عقب بازگردند یا فرآیند را متوقف کنند. این دقیقاً مشابه روشی است که انسانها در تحلیلهای پس از حادثه (post-mortems)، علتهای ریشهای را برچسبگذاری میکنند.
تأخیر دادهها
تلمتری (telemetry) بلافاصله ظاهر نمیشود. عاملها اکنون شامل یک وقفه کوتاه و یک بررسی صحت (sanity check) هستند تا اطمینان حاصل کنند که لاگهای مورد نیاز قبل از تأیید اصلاحیه، رسیده است. بدون این محافظ، یک عامل میتواند بر اساس دادههای ناقص عمل کرده و یک نتیجه مثبت کاذب تولید کند.
مرزهای امنیتی
اجازه دادن به یک هوش مصنوعی برای نوشتن کد، خطر ارتقای سطح دسترسی (privilege escalation) را به همراه دارد. سندباکس در پشت یک سرور سیستم فایل اختصاصی اجرا میشود که محدوده نوشتن را به مخزن (repository) هدف محدود میکند و اگر تست شکست بخورد، بهطور خودکار حالت قبلی را بازیابی میکند. این مدل مهارکننده، قدرت هوش مصنوعی را تحت کنترل نگه میدارد.
محدودیتهای توکن
مدلهای زبانی بزرگ توکنهای API را مصرف میکنند و سهمیههای روزانه ممکن است در میانه بررسی تمام شوند. AgentOps میزان مصرف توکن را به ازای هر حادثه ردیابی میکند و پس از رسیدن به یک آستانه، فراخوانیهای بیشتر را محدود میکند تا از وقوع زنجیرهای از اصلاحات ناموفق در صورت اتمام سهمیه جلوگیری کند.
آنچه دمو ثابت کرد
تیم یک باگ کاملاً جدید را که هرگز در کدbase وجود نداشته بود، تزریق کرد. AgentOps ناهنجاری را شناسایی کرد، آن را تا خط دقیق ردیابی کرد، یک ویرایش اصلاحی ایجاد کرد، وصله را در سندباکس اعمال کرد و موفقیت درخواست را تأیید کرد—همه اینها بدون هیچ تغییر دستی در کد یا دستور (prompt) جدید. زمان سرتاسری (end-to-end) زیر یک دقیقه باقی ماند که با مدت زمان ۳۰ تا ۶۰ ثانیه گزارششده مطابقت داشت.
نکته مقابل: خودمختاری یک راهکار جادویی نیست
آنچه در آینده باید زیر نظر داشت
- تلهمتری مستقل از مدل – با افزایش تعداد فروشندگانی که Spanهای سازگار با OpenTelemetry را ارائه میدهند، این رویکرد میتواند مستقل از فروشنده شده و پذیرش آن را در پشتههای (stacks) ناهمگون تسهیل کند.
- نردههای حفاظتی مبتنی بر سیاست – گنجاندن سیاستهای قابل تنظیم که تعیین میکنند یک عامل (agent) مجاز به ویرایش کدام فایلها است یا کدام مجموعه تستها باید پیش از یک commit با موفقیت گذرانده شوند، نگرانیهای مربوط به حاکمیت را برطرف خواهد کرد.
- بودجهبندی توکن با توجه به هزینه – تخصیص پویای توکن بر اساس شدت حادثه میتواند از اتمام سهمیه جلوگیری کند و در عین حال، توانایی رسیدگی به باگهای پرخطر را حفظ نماید.
AgentOps نشان میدهد که چرخه رفع باگ میتواند ۳۰ تا ۶۰ ثانیه طول بکشد. این آزمایش یک اثبات مفهوم (proof-of-concept) را ارائه میدهد که نشان میدهد قابلیت مشاهدهپذیری (observability) میتواند توسط دستیارهای نرمافزاری خودمختار مورد استفاده قرار گیرد.