تصور کنید ساعت ۳ صبح است و یک خطای بحرانی کل سرویس شما را از دسترس خارج کرده است؛ در این لحظه، آخرین چیزی که نیاز دارید، یک هوش مصنوعی است که با اطمینانی کاذب، تغییری اشتباه در دیتابیس اعمال کند و وضعیت را بدتر کند. Sonjomon دقیقاً برای مقابله با این کابوس طراحی شده است تا ثابت کند در محیط‌های عملیاتی، «خویشتن‌داری» ارزشمندتر از «سرعت» است.
واژه Sonjomon در زبان بنگالی به معنای «خویشتن‌داری» است. این پروژه که در ۳۰ اوت ۲۰۲۶ منتشر شد، توسط یک دانشجوی سال اول علوم کامپیوتر ساخته شده و رویکرد رایج دموهای صنعتی را به چالش می‌کشد؛ دموهایی که در آن‌ها عامل‌های هوش مصنوعی (AI Agents) — شبیه دستیارهای دیجیتالی که می‌توانند به‌جای شما ابزارها را اجرا کنند — هر مشکلی را بدون درنگ و کورکورانه «اصلاح» می‌کنند.
بسیاری از تلاش‌ها برای اتوماسیون پاسخ به حوادث، سعی دارند مهندس را به‌طور کامل جایگزین کنند. اما در واقعیت، خطر اصلی نبودِ اقدام نیست، بلکه تشخیصِ اشتباهی است که با اطمینان بالا در ساعت ۳ صبح، زمانی که هیچ‌کس نظارت نمی‌کند، اجرا شود و یک سرویس را به‌طور کامل از کار بیندازد. Sonjomon با تعریف خودمختاری به‌عنوان تابعی از «میزان اطمینان» و «دامنه اثر»، این ریسک را مدیریت می‌کند.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های عامل‌محور اشاره کردیم، اعطای دسترسی کامل به مدل‌های زبانی بدون لایه‌های حفاظتی، ریسک‌های سیستمی را به‌شدت افزایش می‌دهد. در همین راستا، بررسی لایه‌های حاکمیتی در سطح داده‌ها نشان می‌دهد که چرا مدیریت عامل‌ها نباید صرفاً به لایه‌ی مدل محدود شود.
زمینه و بستر اتوماسیون
در دنیای واقعی، یک حادثه معمولی در ساعت ۳ صبح به این صورت است که مهندسی از خواب بیدار می‌شود تا صدها خط لاگ را بخواند و آن‌ها را با آخرین استقرارها (Deployments) تطبیق دهد و سپس یک رول‌بک انجام دهد. اگرچه این فرآیند مکانیکی است و هدفی بدیهی برای اتوماسیون به نظر می‌رسد، اما استفاده ساده از یک مدل زبانی بزرگ (LLM) تنها جای problem را تغییر می‌دهد. سؤال اصلی این است: یک عامل هوشمند تا چه اندازه اجازه دارد بدون دخالت انسان، تغییراتی در محیط عملیاتی (Production) ایجاد کند؟
اگر به یک عامل قدرت خیلی کمی بدهید، او صرفاً یک چت‌بات است که خلاصه‌هایی می‌نویسد. اما اگر قدرت بیش از حد بدهید، یک خطای متقاعدکننده می‌تواند فاجعه‌بار باشد. Sonjomon طراحی شده است تا این تنش را حل کند و تضمین نماید که هزینه یک اقدام اشتباه، همیشه بسیار بیشتر از هزینه یک اقدام انجام‌نشده باشد.
نردبان خودمختاری
بر اساس گزارش منتشر شده در dev.to، این عامل بر اساس یک «نردبان خودمختاری» عمل می‌کند که در آن سطح اقدام توسط فرمول tier = f(confidence, blast_radius) تعیین می‌شود. این رویکرد یادآور مدل ۵ سطح خودمختاری است که برای کنترل دقیق ریسک در اقدامات هوش مصنوعی پیشنهاد شده است. سیستم اقدامات را به چهار سطح تقسیم می‌کند:
- مشاهده (OBSERVE): ثبت یافته‌ها بدون هرگونه اقدام.
- پیشنهاد (SUGGEST): توصیه راهکار به انسان، بدون اجرا.
- تأیید (APPROVE): آماده‌سازی اقدام و اجرای آن تنها پس از تأیید صریح انسان.
- اجرا (ACT): اجرای فوری و تأیید مستقل نتیجه.
جزئیات ریسک و اجرای سخت‌گیرانه
برای جلوگیری از اینکه مدل با «خودگویی» یا متقاعد کردن خودش، سطح دسترسی را به یک اقدام پرریسک ارتقا دهد، عامل اجازه ندارد دامنه اثر (Blast Radius) خود را تعیین کند. یک رجیستری سخت‌افزاری (Hard-coded) در نرم‌افزار، سطح ریسک هر اقدام را تعیین می‌کند. برای مثال، ری‌استارت کردن یک سرویس «ریسک متوسط» است چون در عرض چند ثانیه قابل بازگشت است، اما رول‌بک (Rollback) «ریسک بالا» محسوب می‌شود زیرا ترافیک عملیاتی را جابه‌جا می‌کند و اگر بی‌دلیل انجام شود، می‌تواند زمان قطعی واقعی را طولانی‌تر کند. حذف داده‌ها در سطح «بحرانی» قرار دارد و هیچ میزان اطمینانی نمی‌تواند این قفل را باز کند.
شش شرط سخت‌گیرانه وجود دارد که فقط می‌تواند عامل را به پله‌های پایین‌تر نردبان ببرد، نه بالاتر:
- سقف تعیین‌شده برای دامنه اثر (Blast-radius ceiling)
- شواهد ناکافی (Thin evidence)
- شکست اقدام مشابه در گذشته
- تلاش سوم برای یک اصلاح واحد
- کهنه شدن حادثه (Stale incident)
- فعال بودن سوئیچ تست کلی (Global dry-run switch)
علاوه بر این، عامل نمی‌تواند تصمیم بگیرد که آیا مجاز به اجرا هست یا خیر. این موضوع توسط کدهای قطعی (Deterministic) و تست‌شده‌ای مدیریت می‌شود که به‌عنوان before_tool_callback در پلتفرم ADK نصب شده‌اند. اگر فراخوانی یک ابزار مسدود شود، سیستم یک دیکشنری به مدل برمی‌گرداند تا عامل یاد بگیرد چرا متوقف شد، به‌جای اینکه به‌طور خاموش تلاش مجدد کند. در نهایت، عامل نمی‌تواند کار خود را نمره دهد؛ تأیید نهایی توسط یک پروب HTTP مستقل انجام و به‌عنوان یک رویداد مجزا ثبت می‌شود.
آزمایش‌ها و نتایج واقعی
در جریان آزمایش روی یک سرویس حساس Cloud Run، این عامل ۱۴ حادثه واقعی را مدیریت کرد. ۴۱ تست مختلف برای حفظ منطق ایمنی در نظر گرفته شده است؛ از جمله تستی که تأیید می‌کند حتی یک عامل با اطمینان ۹۶٪، همچنان نمی‌تواند یک اقدام تخریبی را اجرا کند. برای درک بهتر چالش‌های امنیتی در دسترسی به فایل‌ها، می‌توان روش‌های سنجش نفوذ عامل‌ها در محیط‌های ایزوله را بررسی کرد.
در یکی از موارد، عامل اثر انگشت (Digest) ایمیج‌های کانتینر را در ۵ نسخه مختلف مقایسه کرد و دریافت که نسخه «سالم» هم دقیقاً همان کد معیوب نسخه فعلی را دارد. در نتیجه، به‌درستی تصمیم گرفت که رول‌بک بی‌فایده است و موضوع را به انسان ارجاع داد.
آزمایش دیگری یک پیکربندی اشتباه واقعی را شناسایی کرد که در آن درصد ترافیک تمام نسخه‌ها روی صفر تنظیم شده بود؛ خطایی که توسعه‌دهنده هنگام راه‌اندازی ایجاد کرده بود. در مورد سوم، عامل سعی کرد اقدامی را اجرا کند اما به دلیل نبود دسترسی IAM — به‌طور مشخص artifactregistry.repositories.downloadArtifacts — شکست خورد. این اتفاق به توسعه‌دهنده کمک کرد تا یک شکاف در سیاست «حداقل دسترسی» (Least-privilege) را پیدا کند؛ چرا که عامل دسترسی run.admin روی یک سرویس داشت اما بدون آن مجوز خاص، نمی‌توانست آن را به‌روزرسانی کند.
موانع فنی
در طول مسیر، چالش‌های فنی متعددی ظاهر شد. توسعه‌دهنده متوجه شد که مدل Gemini 3.5 معمولاً سطح اطمینان خود را بین ۰.۸۵ تا ۰.۹۵ گزارش می‌کند، که باعث می‌شود کفِ ۰.۹۰ برای سطح «اجرا» (ACT) تقریباً دست‌نیافتنی باشد. همچنین، به‌دلیل اینکه نقطه انتهایی (Endpoint) سریعاً پاسخ تأیید می‌دهد و بررسی‌ها در یک تسک پس‌زمینه انجام می‌شود، استفاده از پرچم --no-cpu-throttling در Cloud Run ضروری بود؛ زیرا تخصیص پیش‌فرض CPU باعث می‌شد نمونه (Instance) قبل از اتمام کار، منجمد شود.
یک تست تزریق هرج‌ومرج (Chaos Injection) نیز شکست خورد؛ نشت حافظه باعث ری‌استارت OOM (Out of Memory) شد و وضعیت خطا در حافظه پاک شد. عامل به‌درستی گزارش داد که سرویس «گذرا» بوده و حل شده است، چون شواهد قبل از بسته شدن پنجره هشدار ناپدید شده بودند. راه حل این مشکل، محدود کردن نشت حافظه درست زیر حد مجاز کانتینر بود.
نتیجه‌ای ناخوشایند اما ارزشمند
در تمام ۱۴ حادثه، عامل تقریباً هیچ تغییری در محیط عملیاتی ایجاد نکرد. در حالی که این موضوع ممکن است شبیه به شکست در اتوماسیون به نظر برسد، توسعه‌دهنده استدلال می‌کند که ارزش واقعی در «تشخیص» است. در حالی که یک مهندس معمولاً ۲۰ تا ۳۰ دقیقه برای یافتن علت ریشه (Root Cause) زمان می‌گذارد، Sonjomon این کار را در ۸ تا ۳۰ ثانیه انجام داد و دقیقاً فایل، شماره خط، تعداد دفعات وقوع و نسخه معیوب را شناسایی کرد.
این تغییر رویکرد نشان می‌دهد که اصطکاک اصلی در مهندسی قابلیت اطمینان سایت (SRE)، عملِ اصلاح نیست، بلکه «اطمینانی» است که برای اعمال اصلاح لازم است. با اتوماسیون جمع‌آوری شواهد، بار شناختی بررسی‌ها حذف می‌شود.
این پروژه که در ۱۰ روز به‌صورت تک‌نفره با استفاده از Gemini 3.5، Google ADK، Cloud Run، Pub/Sub، Firestore، Cloud Logging، Cloud Monitoring و Secret Manager ساخته شده، ثابت می‌کند هدف هوش مصنوعی در محیط عملیاتی باید «خویشتن‌داری آگاهانه» باشد. عاملی که فقط برای مفید به نظر رسیدن اقدام می‌کند، یک ریسک است، نه یک ابزار.
توسعه‌دهندگان علاقه‌مند می‌توانند پیاده‌سازی این پروژه را در گیت‌هاب بررسی کنند یا دموی پروژه را تماشا کنند تا نردبان خودمختاری را در عمل ببینند.
گام بعدی شما
- اگر از عامل‌های AI برای مدیریت زیرساخت استفاده می‌کنید، یک «رجیستری ریسک» سخت‌افزاری تعریف کنید تا مدل نتواند سطح دسترسی خود را تغییر دهد.
- به‌جای تمرکز بر اتوماسیونِ «اصلاح»، روی اتوماسیونِ «تشخیص و جمع‌آوری شواهد» سرمایه‌گذاری کنید.
- دسترسی‌های IAM مدل‌های خود را با اصل Least-privilege بازبینی کنید تا از دسترسی‌های غیرضروری جلوگیری شود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو