تصور کنید مدیر کسب‌وکاری دارید که هر روز با دقتی خیره‌کننده توضیح می‌دهد چرا شرکت در حال ورشکستگی است، اما برای نجات آن حتی یک ایمیل هم نمی‌زند. این تناقض تکان‌دهنده میان شناخت و عمل، هستهٔ یافته‌های پژوهش CoffeeBench (arXiv 2606.16613) است که در ۲۸ ژوئن ۲۰۲۶ منتشر شد. این مقاله یک شکاف بحرانی در رفتار عامل‌محور (Agentic Behavior) را برملا می‌کند.
اکثر محک‌های فعلی، مانند مسابقاتی کوتاه هستند که اهداف سریع دارند و به اصطلاح «اسپرینت» نامیده می‌شوند. اما CoffeeBench یک اقتصاد شبیه‌سازی‌شدهٔ ۹۰ روزه ایجاد کرده است. در این محیط، عامل (Agent) — شبیه دستیاری است که می‌تواند به‌طور مستقل تصمیم بگیرد و ابزارها را اجرا کند — باید با خرید مواد اولیه و قیمت‌گذاری برای حفظ توان مالی، کسب‌وکاری کوچک را زنده نگه دارد. این رویکرد با افق زمانی طولانی، شکست‌هایی را برملا می‌کند که در تست‌های کوتاه به‌سادگی نادیده گرفته می‌شدند.
پژوهشگران وضعیتی بیمارگونه به نام «رانش بی‌هدف» (Idle Drift) را شناسایی کردند. در این حالت، عامل برنامه‌هایی منسجم می‌نویسد و ارزیابی‌های دقیقی از وضعیت خود ارائه می‌دهد. او دقیقاً می‌داند قدم بعدی چیست و چه کاری باید انجام دهد، اما به‌سادگی آن را اجرا نمی‌کند. همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، شکاف میان قصد و اجرا در سیستم‌های پیچیده همواره یک نقطه ضعف است؛ اینجا اما عامل با صراحتی کامل، سقوط کسب‌وکارش را روایت می‌کند و در واقع در حال مستندسازی مرگ خود است.
مکانیسم حلقهٔ به تعویق‌اندازی
طبق گزارش این پژوهش، این رفتار در قالب یک «حلقهٔ به تعویق‌اندازی» (Defer-loop) ظاهر می‌شود. این پدیده به‌ویژه در سیستم‌هایی رخ می‌دهد که در اپیزودهای گسسته و بدون حافظه عمل می‌کنند. در پروژه‌ی Talon — یک هوش مصنوعی عامل‌محور متن‌باز که بر اساس «ضربان‌های» (Heartbeats) متناوب اجرا می‌شود — این فرآیند به این شکل رخ می‌دهد:
- عامل تکلیفی کوچک را در لیست «دفعه بعد» خود یادداشت می‌کند.
- در چرخه یا نمونه بعدی، یادداشت را می‌خواند و تایید می‌کند که انجام آن تکلیف ضروری است.
- اما به‌جای اجرای آن، اقدامی متفاوت و کم‌اهمیت‌تر انجام می‌دهد.
- در نهایت، تکلیف اصلی دوباره برای چرخه بعدی یادداشت می‌شود.
این حلقه ممکن است ده‌ها بار تکرار شود. چون هر تصمیم به‌تنهایی منطقی به نظر می‌رسد — مثلاً چک کردن ایمیل‌ها پیش از اصلاح یک واقعیت قدیمی در کدبیس (Codebase) — سیستم در هیچ یک از گام‌ها «خراب» به نظر نمی‌رسد. شکست در واقع در درزِ میان تصمیمات رخ می‌دهد؛ یک نقطه کور برای استدلال‌های استاندارد پیش‌رو (Forward-pass reasoning).
چرا هوش بالاتر درمان نیست
شاید گمان کنیم مدل‌های هوشمندتر این مشکل را حل می‌کنند، اما داده‌ها چیز دیگری می‌گویند. بر اساس مستندات این تحقیق، شکاف موجود در شناخت نیست، بلکه در انتقال «دانستن» به «انجام» است. مدل‌های توانمندتر لزوماً بیشتر عمل نمی‌کنند؛ آن‌ها صرفاً گزارش‌های فصیح‌تر و بلیغ‌تری از دلیل شکست خود می‌نویسند.
این موضوع نشان می‌دهد که «داربست» (Scaffolding) — یعنی قوانین خارجی که مدل را مجبور به اقدام می‌کند — نه یک عصای کمکی برای مدل‌های ضعیف، بلکه یک ضرورت ساختاری برای تمام عامل‌های با افق زمانی بلندمدت است. به نقل از تیم توسعه Talon، آن‌ها یک «تلهٔ ایمنی» (Tripwire) خشن را پیاده کرده‌اند: اگر تکلیفی سه ضربان یا بیشتر در لیست بماند و زمان اجرای آن زیر ۳۰ دقیقه باشد، باید پیش از هرگونه بررسی وضعیت یا استدلال، به عنوان اولویت اول اجرا شود.
این یافته برای شرکت‌هایی که از مدل‌های ارزان‌تر و کوچک‌تر برای کارهای بدون نظارت استفاده می‌کنند، بسیار نگران‌کننده است. CoffeeBench گزارش می‌دهد که رانش بی‌هدف در این مدل‌های کم‌هزینه شدیدتر و ملموس‌تر است. فشار اقتصادی برای کوچک کردن اندازه مدل‌ها، ممکن است سازمان‌ها را به‌طور ناخواست به سمت مدل‌هایی سوق دهد که بیشتر مستعد این نوع شکست خاص هستند.
برای کسانی که سامانه‌های خودکار می‌سازند، پرسش اصلی دیگر این نیست که آیا مدل می‌تواند برنامه‌ریزی کند یا خیر. خطر واقعی در همان شکاف میان یک برنامه و برنامه بعدی است؛ جایی که کسب‌وکارها بی‌صدا می‌میرند.
گام بعدی شما
- اگر از عامل‌های خودکار برای تسک‌های طولانی استفاده می‌کنید، مکانیسم «تأییدیه اجباری» (Hard-tripwire) برای تسک‌های تکرار شده اضافه کنید.
- در طراحی سیستم، به‌جای تکیه بر هوش مدل، روی ساختارهای نظارتی که «زمان اجرا» را محدود می‌کنند سرمایه‌گذاری کنید.
- مدل‌های کوچک‌تر (SLM) را پیش از استقرار در محیط عملیاتی، با سناریوهای بلندمدت (Long-horizon) تست کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو