قانون اساسی عامل‌ها؛ چارچوبی برای جلوگیری از شکست عملیاتی AI

تصور کنید یک عامل هوش مصنوعی را با نقش «کارشناس فروش» استخدام کرده‌اید، اما او بدون هیچ محدودیتی شروع به تغییر مفاد قراردادها با مشتریان می‌کند. بدون یک قانون اساسی عملیاتی عامل (Agent Operating Constitution)، نامیدن نقش‌ها برای AI تنها نسخه‌ای برای شکست است.

به نقل از گزارش منتشر شده در dev.to در ۱۲ سپتامبر ۲۰۲۶، نقش‌های شغلی برای AI تا زمانی که با مجوزهای صریح، گیت‌های تأیید و شرایط توقف همراه نباشند، هیچ معنای عملیاتی ندارند. اکثر سازمان‌ها با عامل‌ها مانند شخصیت‌های دیجیتال برخورد می‌کنند، اما این نگاه ریسک‌های اقدامات خودگردان را نادیده می‌گیرد. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، نبود مرزهای سخت در سیستم‌های خودکار می‌تواند یک دارایی را به سرعت به یک بدهی تبدیل کند.

برای حل این مشکل، این چارچوب یک ماتریس عملیاتی سه‌سطحی برای دسته‌بندی ریسک معرفی می‌کند:

• سبز: وظایفی با ریسک پایین که می‌توانند به‌طور خودکار اجرا شوند.
• زرد: وظایف مشروط که نیازمند ارائه مدرک یا تأیید انسانی هستند.
• قرمز: اقدامات پرریسک که یا کاملاً ممنوع هستند یا داشتن یک «گیت انسانی» (Human Gate) برای آن‌ها اجباری است.

طبق این مستندات، محرک‌های گیت انسانی شامل تراکنش‌های مالی، تأیید هویت، تغییر قراردادها، دسترسی به داده‌های حساس یا تغییرات بازگشت‌ناپذیر در سیستم است. در حالی که پژوهش‌های کم‌ریسک را می‌توان کاملاً خودکار کرد، این حوزه‌های حساس باید تحت کنترل انسان باقی بمانند.

تأیید نهایی از طریق «قراردادهای مدرک» (Evidence Contracts) انجام می‌شود. در این روش، سیستم به‌جای اعتماد به پیام «انجام شد» از سوی AI، مدرک قابل راستی‌آزمایی می‌خواهد. برای مثال، یک تسک نویسندگی تا زمانی که یک URL عمومی ارائه نشود، «تمام‌شده» نیست؛ یا یک تغییر در کد تا زمانی که تست‌های محیط هدف را پاس نکند، «تأییدشده» محسوب نمی‌شود. این رویکرد دقیق برای جلوگیری از خطاهای سیستمی ضروری است، چرا که افزایش سرعت تولید کد توسط AI لزوماً به معنای بهبود بهره‌وری یا سودآوری سازمان‌ها نیست و کیفیت خروجی باید با مکانیزم‌های سخت‌گیرانه کنترل شود.

در صورت بروز خطا، این چارچوب به‌جای پیام‌های خطای ساده، یک پروتکل «تصاعد» (Escalation) را جایگزین می‌کند. عامل باید هدف، وضعیت فعلی، مانع، مدرک و اقدام پیشنهادی برای انسان را گزارش کند تا کاربر بتواند گیت را باز کرده و AI را از یک نقطه مشخص بازگرداند.

در این دیدگاه، شکست یک خطا برای پاک کردن نیست، بلکه ردی برای یادگیری است. این چرخه شامل مراحل «تشخیص $\rightarrow$ توقف $\rightarrow$ حفظ $\rightarrow$ طبقه‌بندی $\rightarrow$ بازگشت $\rightarrow$ یادگیری $\rightarrow$ استراژیک» است. این ردپاهای خطا سپس به تست‌های رگرسیون تبدیل می‌شوند تا اطمینان حاصل شود که یک شکست هرگز تکرار نمی‌شود.

این تغییر به معنای برخورد با عامل‌های AI مانند کارمندان است؛ نه با دادن شخصیت به آن‌ها، بلکه با تعریف محدوده اختیارات و معیارهای خروجی. افزودن عامل‌های جدید تنها زمانی باید رخ دهد که ثابت شود نقش‌های موجود نمی‌توانند شکاف خاصی را پر کنند تا از «تورم عامل‌ها» (Agent Bloat) جلوگیری شود.

گام بعدی شما

• لیست تمام تسک‌های فعلی AI خود را استخراج کنید.
• این تسک‌ها را در ماتریس سبز/زرد/قرمز جای‌گذاری کنید تا نقاط ریسک بالا شناسایی شوند.
• برای هر تسک قرمز، یک گیت تأیید انسانی (Human-in-the-loop) تعریف کنید.

اما مدیریت این گیت‌ها در مقیاس هزاران عامل، چالش جدیدی را ایجاد می‌کند — به بررسی ما درباره‌ی پروتکل‌های MCP برای مدیریت زمینه مدل‌ها مراجعه کنید.