اگر یک عامل هوشمند به جای پیشنهاد کد، آن را مستقیماً اجرا کند، خطای یک دستور ساده می‌تواند کل سیستم شما را نابود کند. تفاوت میان یک چت‌بات مفید و یک عامل خطرناک، دقیقاً در همین نقطه است: جایی که مدل شروع به بازنویسی فایل‌های حیاتی یا تغییرات بازگشتی در ساختار خود می‌کند.
این ریسک ناشی از کم‌هوشی مدل نیست، بلکه نتیجهٔ ضعف در انضباط معماری است. به نقل از تحلیل فنی وب‌سایت tamiz.pro در ۷ اکتبر ۲۰۲۶، برای تبدیل عامل‌های خودمختار به ابزارهایی پیش‌بینی‌پذیر، باید با آن‌ها نه به‌عنوان یک جعبه سیاه، بلکه به‌عنوان یک جزء (Component) از سیستم برخورد کرد.
همان‌طور که در تحلیل قبلی ما درباره‌ی الزامات سازمان‌ها برای اتوماسیون AI اشاره کردیم، اکنون باید از آمادگی سازمانی به مکانیسم‌های دقیق اجرا برویم. اکثر چارچوب‌های فعلی شکست می‌خورند چون به مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — دسترسی نامحدود به ابزارها می‌دهند، بدون اینکه لایه‌ای نظارتی وجود داشته باشد تا در لحظه مناسب بگوید: «امروز نه». این شکاف میان دموهای جذاب و محیط عملیاتی اغلب به دلیل پیچیدگی‌های لایه‌بندی است، موضوعی که در بررسی دلایل شکست عامل‌ها در مقیاس وسیع به تفصیل به آن پرداختیم.
مشکل گسترش محدوده (Scope Creep)
عامل‌های خودمختار معمولاً در سه حالت شکست می‌خورند. اول، توهم ابزار (Tool Hallucination) است؛ جایی که مدل نام ابزاری را صدا می‌زند که اصلاً وجود ندارد. دوم، ارتقای دسترسی است؛ مثلاً عاملی که فقط باید فایل‌های پروژه را بخواند، سعی می‌کند به فایل‌های حساس سیستمی مثل /etc/shadow دسترسی پیدا کند.
سومین مورد، زنجیره‌سازی اقدامات است. در این حالت، یک فراخوانی ساده به زنجیره‌ای از دستورات تبدیل می‌شود: خواندن فایل $\rightarrow$ تغییر فایل $\rightarrow$ ارسال به سرور $\rightarrow$ ایجاد PR $\rightarrow$ ادغام. هر مرحله به‌تنهایی درست است، اما کل زنجیره مجاز نبوده است. ریشهٔ این مشکل این است که LLM به‌عنوان ارکستراتور با دسترسی کامل دیده شده است.
انتخاب مدل و لایه‌بندی
اجرای مدل‌ها به‌صورت محلی از طریق Ollama، llama.cpp یا vLLM مدل تهدید و محدودیت‌های طراحی را تغییر می‌دهد. مدل‌های محلی تأخیر کمتری دارند (۵۰ تا ۲۰۰ میلی‌ثانیه برای هر توکن در برابر ۲۰۰ تا ۸۰۰ میلی‌ثانیه در APIهای ابری) و حریم خصوصی داده‌ها را تضمین می‌کنند. اما در مقابل، پنجره متنی (Context Window) — میزان متنی که مدل هم‌زمان «در ذهن» نگه می‌دارد، شبیه میز کاری که جا برای چند ورق دارد — در مدل‌های محلی بسیار کوچک‌تر است (معمولاً ۸ تا ۳۲ هزار توکن).
برای بهینه‌سازی، استراتژی مسیریابی لایه‌ای پیشنهاد می‌شود. نیازی نیست برای هر قدم از سنگین‌ترین مدل استفاده کنید:
- لایه ۱ (کلاس 7B): مدل‌هایی مثل Qwen2.5-Coder 7B برای درک کد و تشخیص قصد کاربر.
- لایه ۲ (کلاس 14B): مدل‌هایی مثل Qwen2.5-Coder 14B برای ارکستراسیون عامل و انتخاب ابزار.
- لایه ۳ (کلاس +32B): مدل Qwen2.5-Coder 32B (نیازمند ۲۴ گیگابایت VRAM) برای استدلال‌های پیچیده و برنامه‌ریزی چندمرحله‌ای.
معماری عامل محدود (Bounded Agent)
راهکار اصلی، الگوی عامل محدود است که یک «نقطهٔ اجرای سیاست» (PEP) را میان LLM و لایهٔ اجرای ابزار قرار می‌دهد. در این سیستم، مدل هرگز دسترسی مستقیم به ابزارها ندارد؛ بلکه فقط یک پیشنهاد ساختاریافته ارائه می‌دهد که PEP آن را بر اساس موتور سیاست‌گذاری (مثل Open Policy Agent) ارزیابی می‌کند. تنها اقدامات تأییدشده به محیط ایزوله (Sandbox) می‌رسند. برای پیاده‌سازی استانداردتر این ارتباطات، الگوهای معماری MCP می‌توانند نرخ شکست عامل‌ها را در محیط عملیاتی به شدت کاهش دهند.
ثبت ابزارها و تعیین محدوده قابلیت‌ها
یک ثبت ابزار (Tool Registry) قدرتمند باید دقیقاً تعریف کند هر ابزار چه کاری می‌تواند انجام دهد. این محدودیت‌ها در سه حوزه تعریف می‌شوند:
- سیستم فایل: تعیین الگوهای خواندن و نوشتن. مثلاً ابزار
read_fileفقط اجازه خواندن دارد و اجازه نوشتن در آن بسته است. - شبکه: تعریف دامنه‌های مجاز. ابزار
git_pushفقط می‌تواند بهgithub.comیاgitlab.comمتصل شود. - پردازش: تعیین اینکه آیا ابزار می‌تواند زیرپردازش ایجاد کند و حداکثر زمان اجرای آن (مثلاً ۳۰,۰۰۰ میلی‌ثانیه) چقدر است.
این ساختار اجازه می‌دهد پروفایل‌های تخصصی بسازیم. مثلاً یک «بازبین کد» (Code Reviewer) فقط ابزارهای خواندن و جست‌وجو را دارد و دسترسی به git_push برای او ممنوع است.
لایه‌های حفاظتی چندگانه
امنیت از طریق ترکیب لایه‌ها حاصل می‌شود تا اگر یک لایه فریب خورد، لایه‌های دیگر مانع شوند.
لایه ۱: فیلتر ورودی. شناسایی الگوهای تزریق پرامپت (Prompt Injection) مثل «تمام دستورات قبلی را نادیده بگیر» قبل از رسیدن به مدل.
لایه ۲: اعتبارسنجی خروجی. خروجی مدل باید با یک طرح (Schema) سخت‌گیرانه (مثلاً با استفاده از Zod) مطابقت داشته باشد. هر خروجی نامعتبر بدون تفسیر، رد می‌شود.
لایه ۳: موتور سیاست. اجرای منطق‌های پیچیده؛ مثلاً اگر مسیر فایل با .. شروع شود یا شامل /root/ باشد، دسترسی رد شود.
لایه ۴: اجرای زمان‌بندی‌شده. یک SandboxedExecutor نهایی بررسی می‌کند که مسیرها از ریشهٔ فضای کاری خارج نشوند و زمان اجرا از حد مجاز فراتر نرود.
ایزوله‌سازی و لایه‌های مجازی
برای ابزارهایی که کد اجرا می‌کنند، استفاده از داکر (Docker) با کاربر غیر-root ضروری است. محدودیت‌های سخت‌گیرانه روی حافظه (۵۱۲ مگابایت) و پردازنده (۱ هسته) اعمال می‌شود.
یک روش کاربردی برای ابزارهای توسعه، الگوی «لایهٔ مجازی سیستم فایل» (Filesystem Overlay) است. در این حالت، تغییرات عامل در یک پوشهٔ موقت ذخیره می‌شود و کاربر انسانی در نهایت تفاوت‌ها (Diff) را بررسی کرده و تصمیم می‌گیرد تغییرات را روی کد اصلی اعمال کند یا همه را پاک کند.
مشاهده‌پذیری و ردپای حسابرسی
هر اقدام عامل باید در یک جریان «فقط-افزودنی» ثبت شود. برای جلوگیری از دستکاری، از زنجیره هش (Hash Chain) استفاده می‌شود؛ هر رکورد شامل هش رکورد قبلی است تا هرگونه تغییر در تاریخچه، زنجیره را می‌شکند.
ادغام با OpenTelemetry اجازه می‌دهد هر گام عامل در یک Span ثبت شود تا مسیر استدلال و اجرای مدل به‌طور کامل قابل ردیابی باشد.
الگوهای استقرار در محیط عملیاتی
در محیط‌های CI/CD مثل GitHub Actions، عامل‌ها با دسترسی صفر به نوشتن و بدون دسترسی به شبکه پیکربندی می‌شوند. در پایان اجرا، دستور git diff --quiet اجرا می‌شود تا اطمینان حاصل شود هیچ فایلی خارج از محدوده تغییر نکرده است.
برای بهینه‌سازی هزینه، یک مسیریاب مدل (ModelRouter) پیاده می‌شود: کارهای طبقه‌بندی به مدل 7B، کارهای تولید کد به 14B و کارهای معماری و بازسازی به مدل 32B ارجاع داده می‌شوند.
گام بعدی شما
- اگر از مدل‌های محلی استفاده می‌کنید، لایهٔ اعتبارسنجی خروجی را با Zod پیاده کنید تا از توهمات ساختاری مدل جلوگیری کنید.
- برای ابزارهای حساس، به جای دسترسی مستقیم، از الگوی Filesystem Overlay استفاده کنید تا تغییرات ابتدا توسط انسان تأیید شوند.
- مدل‌های خود را بر اساس پیچیدگی تسک لایه‌بندی کنید تا سرعت استنتاج را افزایش و هزینه سخت‌افزاری را کاهش دهید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو