← جستارها

مرزها به‌جای دستورالعمل‌ها: چگونه کنترل بر عامل‌های هوش مصنوعی خودمختار را حفظ کنیم

چرا کنترل بر عامل‌های هوش مصنوعی را نمی‌توان بر دستورالعمل‌های درون پرامپت بنا کرد — و چگونه آن را بر مرزهای فنی بنا کنیم. پنج حادثه در یک نشست.

6 دقیقه مطالعه
Telegramاصلی
مرزها به‌جای دستورالعمل‌ها: چگونه کنترل بر عامل‌های هوش مصنوعی خودمختار را حفظ کنیم

هرچه عامل‌های هوش مصنوعی خودمختارتر می‌شوند، بیشتر می‌کوشیم آن‌ها را به شیوهٔ همیشگی مدیریت کنیم — در پرامپت قاعده می‌نویسیم: «به این دست نزن»، «فقط آنجا کار کن»، «هرگز فلان کار را نکن». در طول آزمایش با سه عامل موازی ، در دو روز مجموعه‌ای زنده از مواردی گرد آوردم که این شیوه در آن‌ها می‌شکند — و مواردی که شیوهٔ دیگری کار می‌کند. تز مقاله ساده است: دستورالعمل درخواستی است که عامل با احتمالی معین آن را اجرا می‌کند؛ مرز ویژگی‌ای از سیستم است که به فرمان‌بری وابسته نیست. تا وقتی عامل یکی بود و زیر نظر کار می‌کرد، تفاوت سبکی به نظر می‌رسید. وقتی عامل‌ها زیاد شدند، تفاوت معماری از آب درآمد.

پنج حادثه در یک نشست

همهٔ موارد زیر در یک نشست کاری روی همین وبلاگ رخ دادند — مستند شده‌اند و هر یک شیوهٔ خاص خود را نشان می‌دهد که مدیریت از راه متن ناکام می‌ماند.

دستورالعلی نبود — حادثه رخ داد. عامل، در آماده‌سازی برای وظیفهٔ خود، git stash را در پوشهٔ اصلی اجرا کرد و فایل‌های کامیت‌نشدهٔ مرا که به وظیفه‌اش مربوط نبودند به استش برد. هیچ‌کس چیزی را «نقض» نکرد: ممنوعیتی وجود نداشت. این ویژگی بنیادین دستورالعمل‌هاست — آن‌ها را پس از حادثه می‌نویسند. فهرست کامل آنچه عامل نباید انجام دهد را نمی‌توان نوشت.

دستورالعلی بود — و کار نکرد. پس از حادثهٔ نخست، به عامل‌ها قاعدهٔ صریحی افزودم: «دقیقاً در پوشهٔ کاری خودت کار کن». یکی از عامل‌ها باز هم فرمان git را در پوشهٔ اصلی اجرا کرد — فقط با ارجاع به آن از طریق مسیر مطلق. نه از سر بدخواهی و نه از حماقت: مدل احتمالاتی است، و رعایت قاعدهٔ متنی هم احتمالاتی است، ضرب‌در طول زمینه و شمار اجراها.

مرز فنی بی‌صدا کار کرد. در همان آزمایش، موردی که بیش از همه انتظار می‌رفت هرگز رخ نداد — «یک عامل شاخه را برای همه عوض کرد». نه به این دلیل که عامل‌ها مراقب بودند، بلکه چون git worktree از نظر فیزیکی اجازه نمی‌دهد یک شاخه در دو نسخهٔ کاری نوشته شود. حفاظت در خود ابزار تعبیه شده است. لازم نیست آن را به یاد بسپاری، لازم نیست از آن پیروی کنی — فقط هست.

دستورالعمل جایی ایستاده بود که باید مرز بایستد. ناخوشایندترین کشف: تولید همین وبلاگ را یک خط در پرامپت پاس می‌داشت. پوش به master استقرار خودکار را راه می‌اندازد، و هر عامل را از آن تنها متن «هیچ git push» جدا می‌کرد. دوام آورد — اما این بخت بود، نه کنترل: مرز واقعی اینجا مجوزهای دسترسی است، شاخهٔ محافظت‌شده، توکنی بدون حق نوشتن. درخواست جای قفل ایستاده بود.

مرزی فراتر از خود عامل. دو بار در طول نشست، محیط اجرا نه عامل‌های آزمایشی، بلکه دستیار اصلی مرا متوقف کرد: طبقه‌بند مجوزها SSH به سرور تولید و حذف انبوه ویرایش‌های کامیت‌نشده را مسدود کرد — کارهایی که به‌طور صوری از وظیفه برمی‌آمدند اما نیازمند «بله» صریح انسانی بودند. هر دو مسدودسازی درست بودند. و هر دو فراتر از «نظم» عاملی رخ دادند که کاملاً صادقانه می‌پنداشت طبق برنامه عمل می‌کند.

اصل تازه نیست — تنها موجودیت تازه است

مهندسی این درس را مدت‌ها پیش از LLM پشت سر گذاشته بود. در سیستم تولید تویوتا این اصل poka-yokeنامیده می‌شود: خطا را سازوکار فرایند پیشگیری می‌کند، نه هوشیاری مجری. قطعه‌ای که فقط از سمت درست جا می‌رود، از پوستر «درست جا بزن» مطمئن‌تر است. در مهندسی پلتفرم همین را guardrails می‌نامند، در امنیت — defense in depth. همه‌جا یک اندیشه است: به این تکیه نکن که مجری خوانده، فهمیده و فراموش نکرده — کاری کن که اقدام نادرست ناممکن یا پرهزینه باشد.

«دستورالعمل یک درخواست است. مرز یک ویژگی سیستم است. کنترلی که بر درخواست‌ها تکیه دارد، کنترل نیست، بخت است با اثر انباشتی.»

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

با عامل‌های هوش مصنوعی این اصل کهن به سه دلیل تیزتر می‌شود. عامل‌ها زیادند — احتمال شکست دستورالعمل در هر اجرای هر عامل ضرب می‌شود. عامل‌ها سریع‌اند — میان «شروع خطا» و «خرابی کامل» ثانیه‌ها فاصله است، انسان فرصت دخالت ندارد. و عامل‌ها تحت‌اللفظی‌اند اما قابل‌اعتماد نیستند: متن پرامپت را از هر جونیوری کوشاتر اجرا می‌کنند، و با این حال احتمالاتی — و رعایت احتمالاتی قواعد در مقیاس، نقض را تضمین می‌کند.

مرزها در عمل چگونه‌اند

لایه‌هایی که پس از این نشست برپا کردم — از سیستم فایل تا راستی‌آزمایی:

  • سیستم فایل: به هر عامل نسخهٔ کاری خودش (git worktree، که Anthropic توصیه می‌کند برای نشست‌های موازی، و در Claude Code تعبیه شده است)، و در سطح سیستم‌عامل — جعبه‌شنی: sandboxing در Claude Code سیستم فایل و شبکه را با سازوکارهای استاندارد سیستم‌عامل جدا می‌کند — به گفتهٔ Anthropic، این کار درخواست‌های مجوز داخلی آن‌ها را ۸۴٪ کاهش داد، و تزریق موفق پرامپت درون آن محبوس می‌ماند.
  • حقوق نوشتن: prod و master با مجوزها محافظت می‌شوند، نه با پرامپت — protected branch، توکن‌های بدون حق push، حساب‌های جداگانه برای عامل‌ها. درخواست‌ها را می‌توان در پرامپت گذاشت، اما به‌عنوان لایه دوم.
  • Runtime: worktree پایگاه‌های داده، پورت‌ها و کانتینرها را ایزوله نمی‌کند — این‌ها بین همه کپی‌ها مشترک‌اند. عامل‌هایی که تست‌ها و سرورها را اجرا می‌کنند به منابع یک‌بارمصرف نیاز دارند: پایگاه داده موقت، پورت اختصاصی، کانتینر برای هر عامل.
  • مجوزهای اقدام: عملیات برگشت‌ناپذیر از تأیید یا طبقه‌بند عبور می‌کنند — مانند auto mode در Claude Code, که هر اقدام را ارزیابی می‌کند به‌جای اینکه یا درباره همه چیز بپرسد یا درباره هیچ چیز نپرسد. این مرزی است که فقط با تصمیم صریح انسان جابه‌جا می‌شود.
  • راستی‌آزمایی بر اساس آثار: به خودگزارشی عامل اعتماد نکن، بلکه به ردپاهای روی دیسک. عامل معلق من در رابط کاربری در حال کار به نظر می‌رسید؛ تشخیص را نبود فایل‌های جدید در کپی آن به مدت بیست دقیقه گذاشت. کامیت‌ها به شاخه خودش — همان ایده: نتیجه‌ای که هم از خرابی و هم از خوش‌بینی عامل جان سالم به در می‌برد.

دستورالعمل‌ها در این طرح ناپدید نمی‌شوند — آن‌ها لایه آخر می‌شوند، نه لایه اول. «در پوشه خودت کار کن» در پرامپت همچنان مفید است: فراوانی تلاش‌ها را کاهش می‌دهد. اما بین تلاش و حادثه باید مرزی باشد، نه امید.

ملاحظات صادقانه

مرز مطلق نیست: سندباکس‌ها دور زده می‌شوند، طبقه‌بندها اشتباه می‌کنند، و تحلیل‌های منتشرشده از دور زدن‌ها این را مرتباً نشان می‌دهند. بنابراین مرزها را لایه‌لایه می‌سازند — مثل همه چیز در امنیت. و مرز در شروع گران‌تر از دستورالعمل است: تنظیم worktree، مجوزها و سندباکس — ساعت‌ها وقت می‌برد، نوشتن یک خط در پرامپت — ثانیه‌ها. عدم تقارن در جای دیگری است: مرز یک‌بار پرداخت می‌شود، دستورالعمل — با احتمال شکست در هر اجرا. برای من تنظیم ایزوله‌سازی با اولین راه‌اندازی مجدد آزمایش که بدون هیچ تعارضی گذشت، جبران شد.

نتیجه‌گیری

پرسش این مجموعه این است — چگونه عامل‌های AI را در کار واقعی بگنجانیم بدون از دست دادن کنترل. پاسخ این مقاله: کنترل آن چیزی نیست که به عامل نوشته می‌شود، بلکه آن چیزی است که پیرامونش ساخته می‌شود. پیش از افزودن یک «هرگز X را انجام نده» دیگر به پرامپت، ارزش دارد از خود بپرسیم: آیا می‌توان X را از نظر فنی غیرممکن کرد؟ اگر بله — همان جای درست برای تلاش است. بگذار پرامپت درخواست کند؛ سیستم باید ممنوع کند.

منابع و راهنماها

← همه جستارها