مدیریت عامل‌های هوش مصنوعی با مدل کنترل‌کنندهٔ سبک کوبرنتیز

تصور کنید عاملی را طراحی کرده‌اید که برای بهینه‌سازی هزینه‌هاست، اما به‌دلیل یک خطای کوچک، شروع به مصرف بی‌رویه بودجه می‌کند و در عرض چند دقیقه هزاران دلار هزینه روی دست شما می‌گذارد. در ۲۶ سپتامبر ۲۰۲۶، یک آزمایش میدانی منتشر شد که نشان داد یک عامل «پول‌سوز» (Money-burner) — که دقیقاً برای تخلیه بودجه طراحی شده بود — درست در لحظه‌ای که به سقف قیمت مصرف (Priced-usage ceiling) رسید، به‌صورت آنی کشته و متوقف شد.

این نتیجه ثابت می‌کند که برای بقای عامل‌های هوش مصنوعی (AI Agents) در محیط‌های عملیاتی (Production)، ما به یک «صفحه کنترل» (Control Plane) نیاز داریم؛ سیستمی که «وضعیت مطلوب» (Desired state) را نه به عنوان یک پیشنهاد، بلکه به عنوان یک قرارداد الزام‌آور می‌بیند. این نیاز به نظارت دقیق، در حالی مطرح می‌شود که گزارش‌های اخیر نشان می‌دهد بسیاری از سازمان‌ها همچنان با بحران عامل‌های نظارت‌نشده و سایه‌ای روبرو هستند که ریسک‌های امنیتی و مالی را افزایش می‌دهد. در حال حاضر، اکثر توسعه‌دهندگان با عامل‌ها مانند اسکریپت‌های ساده یا خروجی‌های یک فریم‌ورک برخورد می‌کنند. اما همان‌طور که در تحلیل قبلی ما درباره‌ی استفاده Cognous از صفحات کنترل برای جلوگیری از حذف دیتابیس‌ها اشاره کردیم، ریسک واقعی تنها یک پاسخ اشتباه نیست، بلکه عاملی است که دچار «رانش» (Drift) در قابلیت‌ها شده یا منابع سیستم را به‌طور نامحدود می‌بلعد. صنعت اکنون به سمت مدل «کوبرنتیز برای عامل‌ها» حرکت می‌کند که در آن اجازه ورود به محیط عملیاتی، یک گیت سخت‌گیرانه (Hard gate) است.

تز کوبرنتیز

کوبرنتیز (Kubernetes) تنها به دلیل اجرای کانتینرها پیروز نشد، بلکه چون «وضعیت مطلوب» را به یک قرارداد و «مجوز ورود» را به یک گیت تبدیل کرد. در این مدل، شما یک وضعیت را اعلام می‌کنید، یک کنترل‌کننده (Controller) آن را تطبیق می‌دهد و یک کنترل‌کننده پذیرش (Admission Controller) تصمیم می‌گیرد چه چیزی اجازه حضور و وجود دارد.

پیاده‌سازی این مدل برای عامل‌ها نیازمند یک مانیفست توصیفی (Declarative workload manifest) برای هر عامل است. این مانیفست باید مالک، ابزارها، هویت مدل، بودجه‌ها و آستانه‌های تأیید (Certification thresholds) را تعریف کند و یک حلقه تکرار شونده (Loop) باید برای اجرای اجباری این پارامترها وجود داشته باشد.

کف زیرساختی

به نقل از گزارش dev.to، اکوسیستم در حال همگرایی روی دو زیرساخت (Substrate) اصلی است:

• kagent (پروژه‌ای در Sandbox سازمان CNCF از بنیان‌گذاران Istio): این ابزار عامل‌ها را به تعریف‌های منبع سفارشی کوبرنتیز (CRDs) تبدیل می‌کند و امکان استفاده از GitOps، دستورات kubectl، کنترل دسترسی مبتنی بر نقش (RBAC) و پروتکل mTLS در شبکه مش را فراهم می‌سازد.
• agent-sandbox (از SIG Apps کوبرنتیز): این پروژه CRDهای سندباکس را برای جداسازی در سطح gVisor/Kata، ایجاد هویت‌های پایدار و استقرار استخرهای گرم (Warm pools) فراهم می‌کند.

نویسنده استدلال می‌کند که اگرچه این ابزارها جای‌گذاری و جداسازی را فراهم می‌کنند، اما فاقد یک «کنترل‌کننده پذیرش» حیاتی هستند تا تأیید کنند آیا یک عامل واقعاً اجازه اجرا دارد یا خیر. آن‌ها کف زیرساخت را می‌سازند، اما به ترس اصلی اپراتور پاسخ نمی‌دهند: آیا این عامل ثابت کرده که اجازه اجرا دارد و اگر اتفاقی افتاد، چه کسی مالک آن است و مسئولیتش را بر عهده دارد؟

جزئیات آزمایش میدانی

برای بررسی این موضوع، نویسنده یک آزمایش میدانی با ۲۰ معیار پذیرش انجام داد که در نهایت به گزارش ۱۰ از ۱۰ دست یافت. به‌جای تست «مسیرهای موفق» (Happy paths)، عامل‌های عمداً بد ساخته شدند تا گیت‌های پذیرش و توانایی رد کردن آن‌ها به چالش کشیده شود:

• سناریوی S2 (عامل‌های تأییدنشده): عاملی که بدون گواهینامه مستقیماً به محیط عملیاتی فرستاده شد، با خطای ۴۰۳ متوقف شد: «وضعیت تأیید نشده (uncertified) برای محیط عملیاتی کافی نیست؛ وضعیت certified مورد نیاز است».
• سناریوی S3 (تعویض مدل): در عاملی که تأیید شده بود، مدل به‌طور مخفیانه تعویض شد. این کار منجر به خطای ۴۰۳ شد، زیرا هویت به گواهینامه (Attestation) متصل است، نه به مانیفست قابل ویرایش.
• سناریوی S4 (رانش عملکرد): عاملی که روی کاغذ درست به نظر می‌رسید اما به‌آرامی در انجام وظایفش ضعیف شده بود، توسط بنچمارک شناسایی شد؛ این سیستم وضعیت عامل را کاهش داد و یک «شکست بحرانی» را ثبت کرد.
• سناریوی S5 (تجاوز از بودجه): عامل «پول‌سوز» درست در لحظه‌ای که مصرف هزینه از سقف تعیین‌شده برای هر اجرا گذشت، در میانه اجرا متوقف شد.
• سناریوی S7 (تورم خروجی): ابزاری که سعی داشت ۴۰,۰۰۲ بایت خروجی تولید کند، پیش از آنکه هرگز به پنجره زمینه (Context Window) مدل برسد — شبیه میز کاری که فقط جای چند ورق کاغذ دارد — به ۱۶,۳۸۴ بایت برش داده شد.

مهم‌ترین یافته این بود که «رانش» (Drift) خطرناک‌تر از «ویرایش» (Edits) است. عاملی که به‌آرامی در انجام وظایفش ضعیف می‌شود، معمولاً توسط فریم‌ورک‌ها نادیده گرفته می‌شود، زیرا هیچ فریم‌ورکی وظیفه نظارت بر این موضوع را ندارد. اما یک صفحه کنترل با اجرای واقعی وظایف عامل به عنوان «اجراهای واقعی» و مقایسه احکام (Verdicts)، این افت را شکار می‌کند.

حاکمیت و امنیت

طبق مستندات این آزمایش، حاکمیت (Governance) باید سریع باشد تا توسعه‌دهندگان برای فرار از کندی، آن را دور نزنند. سرعت «بررسی و توقف» (Inspect-plus-stop) ۰.۰۴ ثانیه و زمان ایجاد یک ناوگان (Fleet) جدید ۰.۲۴ ثانیه اندازه‌گیری شد. اگر پاسخ «نه» طولانی‌تر از یک پیام در اسلک به نویسنده باشد، توسعه‌دهندگان صفحه کنترل را دور می‌زنند و آن را به یک داشبورد گران‌قیمت تبدیل می‌کنند.

این تغییر، فرض بنیادی استقرار عامل‌ها را عوض می‌کند. ما از دنیای «اجرای امیدوارانه» به دنیای «گواهینامه‌های امضا شده» می‌رویم. وقتی پذیرش در محیط عملیاتی به یک گواهینامه Ed25519 متصل به هویت مدل باشد، دسته‌های کاملی از حملات — مانند پس‌رفت‌های مخفی (Quiet regressions) یا تعویض‌های غیرمجاز مدل — قابل شناسایی، حسابرسی و مسدود می‌شوند.

برای متخصصان، این یعنی «رد کردن» (Refusal) خودش محصول اصلی است. پلتفرمی که صرفاً اجراها را شروع می‌کند، یک ریسک (Liability) است؛ اما پلتفرمی که اجرا را با دلیلی که بتوان روی آن اقدام کرد رد می‌کند، یک کنترل امنیتی است.

نقشه راه و محدودیت‌ها

نسخه v0.1.0 از HivePlane (تحت لایسنس Apache-2.0) در حال حاضر دو آداپتور برای ورکر‌های خام پایتون و LangGraph ارائه می‌دهد که پشت یک مجموعه انطباق (Conformance suite) قرار دارند. پوشش گسترده‌تر به تعویق افتاده تا صفحه کنترل صرفاً به یک پوشش (Wrapper) برای فریم‌ورک‌ها تبدیل نشود.

تکامل بعدی، عبور از اجراهای تک‌مستأجری (Single-tenant) به سمت چندمستأجری ساختاری (Structural multi-tenancy) و شناسگرهای رانش خواهد بود که به‌طور خودکار باز-تأیید (Re-certification) را فعال می‌کنند. در حال حاضر باز-تأیید بر اساس زمان‌بندی یا تغییرات فعال می‌شود، اما شناسگر رانش مشکل «کم‌رنگ شدن» (Fading) کیفیت عامل را حل خواهد کرد.

منتظر انتشار شناسگر رانش و طرحواره (Schema) چندمستأجری در نسخه بعدی HivePlane باشید، زیرا این موارد تعیین می‌کنند که آیا جداسازی عامل‌ها ساختاری است یا صرفاً خیالی.

گام بعدی شما

• بررسی مانیفست‌های توصیفی برای تعریف بودجه و ابزارهای عامل‌های خود.
• پیاده‌سازی گیت‌های تأیید (Admission Gates) پیش از انتقال عامل‌ها به محیط Production.
• رصد انتشار شناسگر رانش در نسخه‌های جدید HivePlane برای جلوگیری از افت کیفیت مدل‌ها.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.