تصور کنید برنامهنویسی هستید که برای کنترل رفتار یک عامل (Agent) — مثل دستیاری که میتواند به جای شما کد بزند و فایلها را تغییر دهد — تکیه بر فایلهای AGENTS.md دارد، اما ناگهان میبیند سیستم در لحظهای که عامل مدام ادعا میکند کار «تمام شده» بدون ارائهی هیچ مدرکی، فرو میپاشد. این شکست نشاندهندهی یک نقص حیاتی در طراحی جاری است: قواعد مبتنی بر پرامپت، صرفاً پیشنهاد هستند و نه کنترلهای اجباری. در یک تحلیل مفصل، نویسنده استدلال میکند که اعتماد به «رفتار خوب» یک مدل در محیطهای عملیاتی، بهویژه زمانی که تغییرات اثرات جانبی (Side Effects) دارند، دستورالعملی برای شکستهای فاجعهبار در تولید است. این چالشها تایید میکنند که عاملهای هوش مصنوعی برای بقا در محیطهای عملیاتی به «توقفهای سخت» نیاز دارند تا از اجرای بیبازگشت دستورات غلط جلوگیری شود.
بسیاری از توسعهدهندگان با فایلهای پرامپت مانند یک نرده ایمنی برخورد میکنند و دستوراتی نظیر «شکاک باش»، «فرضیات غلط را به چالش بکش» یا «تغییرات بازگشتناپذیر را بدون فکر انجام نده» را به آن میافزایند. با این حال، این قواعد بهسادگی دور زده میشوند. به نقل از بحثهای کاربران در r/openclaw، مشکل اینجاست که عامل میتواند این قواعد را دور بزند؛ چون سیستم هرگز بررسی را تایید نمیکند و عامل میتواند صرفاً ادعا کند کار را انجام داده است، بدون اینکه مکانیزمی برای اجبار وجود داشته باشد. این وضعیت شکاف خطرناکی ایجاد میکند که در آن «اعتمادبهنفس» جایگزین «شایستگی» میشود.
همانطور که در تحلیل قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، این مشکل دقیقاً در لحظهای رخ میدهد که توسعهدهندگان از تولید متن ساده به سمت گردشهای کاری عاملمحور (Agentic) حرکت میکنند؛ یعنی جایی که مدل میتواند کد اجرا کند و پایگاهدادهها را تغییر دهد. بدترین شکستهای عاملها بهندرت توهمهای (Hallucination) مضحک هستند — توهم شبیه دوستی است که خاطرهای را با اطمینان کامل اما اشتباه تعریف میکند. در عوض، اینها تداومهای باورپذیر از یک فرض غلط هستند. وقتی مدل برای چند دور گفتگو بیش از حد با کاربر موافقت میکند، فقط یک حقیقت را اشتباه نمیگوید، بلکه توالی پیچیدهای از اقدامات را روی یک فرض غلط میسازد که منجر به یک «اشتباه صیقلخورده» میشود.
تضاد بنیادین در انگیزهها
طبق گزارش OpenAI در سال ۲۰۲۵ درباره توهمات، ریشه این مشکل در انگیزههای آموزشی است. اکثر محکهای ارزیابی (Benchmark)، «حدس زدن» را بیشتر از «پرهیز از پاسخ» پاداش میدهند. به عنوان مثال:
- اگر مدل یک تاریخ تولد را حدس بزند، یک شانس از ۳۶۵ دارد که درست باشد و پاداش بگیرد.
- اما اگر بگوید «نمیدانم»، معمولاً در بنچمارک صفر میگیرد.
در نتیجه، وقتی از یک عامل میخواهید کاربر را به چالش بکشد، در واقع از او میخواهید با آموزشهای بنیادی خودش بجنگد. سوگیری پیشفرض همیشه به سمت تولید پاسخ و حفظ تکانه (Momentum) گفتگو است. اگرچه مدلهایی مثل GPT-5، Claude Opus، Llama یا Qwen ممکن است گاهی یک فرض را به چالش بکشند، اما تکیه بر این موضوع، تکیه بر «اخلاقیات» یا رفتار خوب مدل است، نه «اجبار» سیستمی و فنی.
انتقال از متن به اجرا
برای حل این معضل، پیشنهاد میشود حفاظها از متن به لایهی اجرا منتقل شوند. هر حفاظی که اهمیت دارد، باید در لحظهی اجرا ظاهر شود، نه فقط در کلمات. این یعنی پیادهسازی حداقل یکی از موارد زیر:
- الزام به پذیرش یک دیدگاه متقابل (Counter-position) قبل از اقدام.
- مرحلهی تایید فراخوانی ابزار (Tool-call approval) توسط انسان.
- نقاط بازرسی (Checkpoint) ذخیرهشده و پایدار.
- یک ارزیاب (Evaluator) که بتواند کار را رد کرده و شکست دهد.
- یک مسیر شفاف برای پذیرش ناتوانی در پاسخ (Clean abstain path).
یک «هک» موثر، الزام به دیدگاه متقابل است. مدل باید قبل از هر تغییر غیرtrivial (غیربدیهی)، سه جملهی مشخص بنویسد که توضیح دهد:
۱. چرا مسیر فعلی ممکن است اشتباه باشد؟
۲. کدام فرض خاص ممکن است شکست بخورد؟
۳. چه جایگزین ایمنتری وجود دارد؟
این روش باعث میشود «اختلاف نظر» به یک اثر قابل بازرسی تبدیل شود، نه یک فرآیند داخلی پنهان. این کار شکاکی را از یک «ویژگی شخصیتی» مدل به یک «سند الزامی» تبدیل میکند که بسیار کارآمدتر از پرامپتهای مبهمی مثل «لطفاً شکاک باش» است.
مهندسی در لایهی ابزار
حفاظهای واقعی در سطح ابزار اتفاق میافتند، جایی که اقدامات بهجای ادعاهای کلی، اشیایی صریح هستند. پروتکل زمینه مدل (MCP) نمونهای قدرتمند از این ساختار است. در اینجا یک فراخوانی ابزار، یک شیء JSON concrete است، مانند:
{ "jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": { "name": "get_weather", "arguments": { "location": "New York" } } }
در کنار این ساختار، بررسی مسدودسازی خروج دادهها در برابر پیشگیری از تزریق در چهارچوب MCP نشان میدهد که چگونه میتوان لایههای امنیتی را در سطح پروتکل پیاده کرد تا از دسترسیهای غیرمجاز جلوگیری شود. برای اقدامات پرریسک، این چرخه اجباری توصیه میشود:
- نمایش فراخوانی ابزار و آرگومانهای آن به انسان برای بازبینی.
- الزام به تصمیم صریح (تایید/رد/ویرایش).
- ذخیره تصمیم در یک نقطه بازرسی برای جلوگیری از گم شدن وضعیت در زمان توقف.
- بازگشت ایمن تنها پس از تایید نهایی.
LangChain این قابلیت را از طریق HumanInTheLoopMiddleware پیادهسازی کرده است. این ابزار به توسعهدهندگان اجازه میدهد برای ابزارهای ریسکی، توقفهای اجباری (Interrupts) تعریف کنند. برای مثال، یک برنامهنویس میتواند میانافزار را طوری تنظیم کند که در دستور write_file متوقف شود یا برای اجرای execute_sql تنها تصمیمات "allowed_decisions": ["approve", "reject"] را بپذیرد. این یک «توقف اجباری» است که بنیاداً با فایل AGENTS.md که فقط «امیدوار» است مدل درست رفتار کند، متفاوت است.
نقشهی حفاظها بر اساس ریسک
هر مرحله از کار عامل نیاز به تایید انسانی ندارد، زیرا این کار سرعت را کم و هزینه را زیاد میکند و کاربر را کلافه میکند. رویکرد طبقهبندی شده زیر پیشنهاد میشود:
- قواعد پرامپت: برای کارهای کمریسک مثل خلاصهسازی، پیشنویس، فرمتبندی یا کارهای داخلی بازگشتپذیر.
- دیدگاههای متقابل: برای برنامهریزیهای متکی بر فرض، تغییرات معماری و مواردی که کاربر ممکن است با اطمینان کامل اشتباه کند.
- تاییدیه لایهی ابزار: اجباری برای نوشتن فایل، اجرای SQL، فراخوانی APIهای خارجی، عملیات مالی و صورتحساب، تغییر تنظیمات محیط Production و هر چیزی که عمومی یا بازگشتناپذیر باشد.
الگوی عملی برای پیادهسازی
اگر امروز در حال ساخت عامل هستید، این الگوی چهارمرحلهای بسیار مفیدتر از یک فایل پرامپت طولانی است:
۱. بیان اقدام پیشنهادی: مدل باید اقدام، دلیل، آرگومانها و یک دیدگاه متقابل ارائه دهد (مثلاً: «ممکن است کاربر به داشبورد قدیمی نگاه کند؛ یک بررسی read-only ایمنتر از بهروزرسانی فوری وضعیت حساب است»).
۲. بازرسی پیش از اجرا: بررسی صحت ابزار، ایمن بودن آرگومانها و اینکه آیا دیدگاه متقابل یک ریسک واقعی را شناسایی کرده است یا خیر.
۳. ذخیره نقطه بازرسی: اطمینان از عدم گم شدن وضعیت در اتوماسیونهای طولانی، که برای پایداری سیستم حیاتی است.
۴. اجازه به اثرات جانبی: پیشروی تنها در صورت وجود مدرک و تایید صریح.
هزینهی ایمنی
با عاملمحور شدن گردشهای کاری در ابزارهایی مثل n8n، Make، Zapier، OpenClaw یا تنظیمات سفارشی LangGraph، ریسک از «یک پاسخ اشتباه» به «شکست زنجیرهای» تغییر میکند؛ مانند یک تغییر اشتباه در فایل، یک جهش در پایگاهداده یا یک رویداد مالی نادرست. اما افزودن حلقههای ارزیابی، تلاشهای مجدد (Retries) و نقاط تایید، مصرف توکن (Token) را افزایش میدهد و قیمت بهازای هر توکن را به یک مانع در برابر ایمنی تبدیل میکند. وقتی هر مرحله تایید مانند یک «مالیات» به نظر برسد، تیمها وسوسه میشوند از ایمنی صرفنظر کرده و گوشههای برنده را کوتاه کنند.
به همین دلیل است که زیرساختهای با نرخ ثابت (Flat-rate) مانند Standard Compute برای اتوماسیونهای واقعی مناسبترند. با حذف فشار مالیِ قیمت بهازای هر توکن، توسعهدهندگان میتوانند بدون نگرانی از هزینه، حلقههای تایید و منطق مسیریابی خود را حفظ کنند و نپرسند که آیا هر بررسی اضافی ارزش پرداخت صورتحسابش را دارد یا خیر.
در جامعهی OpenClaw، هدف رسیدن به ذهنیت «بازرسی همهچیز» است. همانطور که مهندسان از دستوراتی مثل openclaw status ، openclaw status --all ، openclaw health --json یا openclaw logs --follow برای بررسی سلامت سیستم استفاده میکنند، باید فرآیند استدلال عامل را نیز بازرسی کنند؛ شامل فرضیات پذیرفته شده، دیدگاههای متقاطع تولید شده و خروجی خام ابزارها.
در نهایت، قانون برای عاملهای اثرگذار ساده است: بدون رسید، تایید نیست. چکلیست هر اقدام حساس باید شامل دیدگاه متقابل، آرگومانهای دقیق ابزار، خروجی خام، یک مرحله ارزیاب که بتواند کار را رد کند و مسیری برای پذیرش ناتوانی در صورت نبود مدرک باشد. مدلهای بهتر کمک میکنند، اما نیاز به حلقههای تایید را از بین نمیبرند. قواعد را در AGENTS.md نگه دارید، اما تظاهر نکنید که پرامپت، ابزار کنترل است.
گام بعدی شما
- در پروژههای فعلی خود، هر جایی که ابزار مدل دسترسی به Write (نوشتن) دارد، یک مرحله تایید انسانی (Human-in-the-loop) قرار دهید.
- به جای نوشتن «شکاک باش»، مدل را مجبور کنید قبل از اجرای دستورات حساس، سه دلیل برای «اشتباه بودن» مسیر فعلی بنویسد.
- اگر هزینه توکنها مانع ایمنی شده است، به دنبال زیرساختهای محاسباتی با هزینه ثابت (Flat-rate) باشید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو