اگر امروز برای حل خطاهای عامل‌های هوش مصنوعی خود فقط به ارتقای مدل به نسخه‌های بزرگ‌تر تکیه می‌کنید، احتمالاً در یک بن‌بست فنی گرفتار شده‌اید. داده‌های جدید نشان می‌دهد که حتی قدرتمندترین مدل‌ها هم نمی‌توانند نقص‌های ساختاری در برنامه‌ریزی را صرفاً با داشتن پارامترهای بیشتر برطرف کنند.
یک آزمون میدانی روی ۱۵۷ هدف مختلف فاش کرد که gpt-4o نمی‌تواند شکست‌های ساختاری در برنامه‌ریزی را حل کند. طبق این نتایج، مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — فارغ از تعداد پارامترها یا کیفیت متن، به‌طور مداوم در درک منطق وابستگی‌ها دچار مشکل می‌شوند.
این یافته‌ها درست زمانی منتشر می‌شود که توسعه‌دهندگان از رابط‌های ساده‌ی چت به سمت گردش‌های کاری عامل‌محور (Agentic) حرکت می‌کنند. همان‌طور که در تحلیل قبلی ما درباره‌ی موتور PlannerCritic اشاره کردیم — سیستمی که در آن یک مدل برنامه‌ریزی می‌کند و مدل دیگر بازبینی می‌کند — این تست جدید بررسی می‌کند که آیا یک مدل «باهوش‌تر» می‌تواند شکاف‌های منطقی تکراری را از بین ببرد یا خیر. برای اکثر توسعه‌دهندگان، غریزه اول این است که هنگام شکست یک عامل، مدل را ارتقا دهند؛ اما این داده‌ها نشان می‌دهد که این مسیر برای استدلال ساختاری به بن‌بست می‌رسد.
مشکل ساختاری: فراتر از اندازه مدل
این تحلیل، سومین بخش از سری گزارش‌های توسعه PlannerCritic است. در حالی که بخش اول به تست میدانی اولیه با ۱۵۷ هدف پرداخت و بخش دوم به رفع یک باگ در شدت بازبینی (Critic Severity) اختصاص داشت، این تحلیل روی یک حقیقت ناگوار تمرکز دارد: برنامه‌ریز دچار یک مشکل ساختاری است که هیچ ارتقای مدلی آن را درمان نمی‌کند. در این راستا، استفاده از حفاظ‌های کدنویسی توانست بخشی از وسواس مدل‌ها در بازبینی را مهار کند، اما مشکل بنیادین استدلال همچنان پابرجاست.
در طول تست، الگو غیرقابل انکار بود. تا هدف دهم، شکست‌ها محسوس شدند. در هدف پنجاهم، خطاها حتی پیش از چاپ گزارش بازبین قابل پیش‌بینی بودند. در هدف صدم، نتایج دیگر غافلگیرکننده نبودند و صرفاً آزاردهنده بودند. برنامه‌ریز به‌صورت تصادفی شکست نمی‌خورد، بلکه به‌طور سیستماتیک خطا می‌کرد.
سه خانواده از نقص‌های برنامه‌ریزی
به نقل از گزارشی که در ۲۲ اوت ۲۰۲۶ در dev.to منتشر شد، برنامه‌ریز در ۶۳ هدف سخت‌گیرانه شکست خورد که منجر به ایجاد ۱۳۲ مانع عینی شد. این شکست‌ها در سه الگوی مشخص جای می‌گیرند:
- وابستگی‌های تأییدنشده (۵۷ مورد): برنامه پیش‌نیازی را اعلام می‌کند که هیچ تسک قبلی آن را ایجاد نکرده است. مدل می‌داند چه چیزی باید درست باشد، اما نمی‌تواند مراحل را طوری بچیند که آن وضعیت ایجاد شود.
- مثال (ai-03-model-serving-migration): برنامه تسکی برای «انتقال ۱۰۰٪ ترافیک از SageMaker به vLLM» تعریف می‌کند، اما فاقد تأییدیه صریح پایداری از مراحل قبلی (انتقال ۱۰٪ و ۵۰٪ ترافیک) پیش از ادامه مسیر است.
- توالی ناایمن (۴۶ مورد): تسک‌ها پیش از پیش‌نیازهای سخت‌شان قرار می‌گیرند. برای مثال، عملیات انتقال ترافیک پیش از تأیید پایداری اجرا می‌شود یا یک بک‌آپ پس از اتمام مهاجرت تکمیل می‌گردد. این نوع شکست‌ها مشابه مواردی است که در آزمون‌های سخت‌افزاری باعث شکست ۱۰ عامل پیشرفته شد و نشان داد که مدل‌ها در مواجهه با محدودیت‌های فیزیکی و سخت‌گیرانه ناتوان‌اند.
- مثال (ai-02-embedding-index-migration): برنامه عملیات «backfill_vectors» را پیش از بررسی کیفیت ایندکس قرار می‌دهد، در حالی که این بررسی باید به عنوان یک دروازه (Gate) عمل کند و تا زمان تأیید کیفیت، عملیات backfill نباید آغاز شود.
- بازگشت ضعیف (۱۸ مورد): مراحلی با ریسک بالا و اثرات گسترده (High-blast-radius)، برنامه‌ی بازیابی معتبری ندارند. مدل برای کارهای روتین بازگشت (Rollback) می‌نویسد، اما در مراحل حساس حذف، جایگزینی یا بازگشت به حالت قبل (Failback)، آن را فراموش می‌کند.
- مثال (db-10-multi-tenant-split): برای تسک «dual_write_setup»، برنامه بازگشت فقط به حالت تک‌نویسی (single-write) برمی‌گردد و به ناهماهنگی‌های احتمالی داده‌ها که در طول انتقال ایجاد شده است، هیچ پاسخی نمی‌دهد.
آزمایش «مدل بزرگ‌تر»
برای بررسی اینکه آیا این یک مشکل ظرفیتی است، نویسنده از gpt-4o استفاده کرد. تست‌ها در دو پیکربندی اجرا شدند: یک برنامه‌ریز gpt-4o در کنار یک بازبین کوچک (Mini Critic)، و حالتی که gpt-4o هر دو نقش برنامه‌ریز و بازبین را ایفا می‌کرد.
نتیجه دقیقاً همان الگوی نقص بود. اگرچه متن تولید شده زیباتر و متقاعدکننده‌تر بود، اما اشتباهات ساختاری باقی ماندند: وابستگی‌های تأییدنشده، توالی‌های ناایمن و بازگشت‌های ضعیف. این ثابت کرد که برنامه‌ریز «کودن» نیست — او مراحل درست را می‌شناسد و متنی متقاعدکننده می‌نویسد — اما نمی‌تواند گراف وابستگی‌ها را ببندد یا ترتیب را تحمیل کند. این یک مشکل ساختار برنامه‌ریزی است، نه اندازه مدل.
شکست حلقه بازبینی
معماری PlannerCritic از حلقه‌ای استفاده می‌کند که در آن بازبین موانع را گزارش می‌دهد و برنامه‌ریز پیش‌نویس را اصلاح می‌کند. این حلقه برای هم‌گرایی طراحی شده، اما در عمل، برنامه‌ریز معمولاً یک مانع را رفع می‌کند و هم‌زمان مانع جدیدی ایجاد می‌کند. او اغلب ترتیب تسک‌ها را جابه‌جا می‌کند بدون اینکه شکاف وابستگی را پر کند، یا بازگشت (Rollback) را به تسک اشتباهی اضافه می‌کند. برای مقابله با این تکرار خطاها، مکانیزم لایه نشانی اصلاحات به عنوان راهکاری برای تثبیت خروجی‌ها پیشنهاد شده است تا از چرخه تکرار اشتباهات جلوگیری شود.
یافته‌های کلیدی درباره این حلقه عبارتند از:
- شکست در هم‌گرایی: پس از میانگین دو بازبینی (در ۳۳ هدف سخت‌گیرانه)، برنامه‌ریز دیگر تغییر معناداری ایجاد نمی‌کند.
- ارتقای موتور: به محض اینکه تشخیص‌دهنده هم‌گرایی (Convergence Detector) فعال شود، موتور خطا را به سطوح بالاتر ارتقا می‌دهد.
- دقت بازبین: بازبین به‌طور قابل‌اعتمادی همان موانع را در بازبینی‌های مختلف پیدا می‌کرد. مشکل در توانایی برنامه‌ریز برای ترمیم ساختاری بود، نه در قضاوت بازبین.
تأییدات آکادمیک
این مشاهدات با پژوهش‌های اخیر هم‌سو است. مقاله «چرا استدلال در برنامه‌ریزی شکست می‌خورد» (arXiv 2601.22311) اشاره می‌کند که عامل‌های LLM اغلب اقدامات را بر اساس ارزیابی‌های محلی انتخاب می‌کنند بدون اینکه پیامدهای آینده را در نظر بگیرند. در پیمایش‌های گراف دانش، سیاست‌های حریصانه تک‌گام (Single-step greedy policies) در بیش از ۵۵٪ مواقع دچار «تله‌های نزدیک‌بینانه» می‌شوند. نویسندگان ثابت می‌کنند که استدلال گام‌به‌گام برای برنامه‌ریزی‌های بلندمدت به‌طور ذاتی ناکافی است.
به همین ترتیب، بررسی PlanGenLLMs (arXiv 2502.11221) برنامه‌ریزی LLMها را بر اساس چهار معیار ارزیابی می‌کند: کامل بودن، قابل اجرا بودن، بهینه بودن و نمایش. این پژوهش تأیید می‌کند که مدل‌های زبانی به‌طور مداوم در تضمین «قابل اجرا بودن» برنامه‌ها، به‌ویژه در مورد پیش‌نیازهای برآورده‌نشده و مراحل خارج از ترتیب، شکست می‌خورند.
مسیر رسیدن به اعتبارسنجی قطعی
راه حل، پارامترهای بیشتر نیست، بلکه رویکردی ترکیبی است که LLMها را با اعتبارسنجی قطعی و تکنیک‌های برنامه‌ریزی کلاسیک ادغام کند. نویسنده یک «بسته‌ساز پیش‌نیاز» (Precondition Closer) پیشنهاد می‌دهد؛ یک ابزار بررسی (Linter) قطعی که پس از تولید پیش‌نویس توسط مدل اجرا شود.
این ابزار بررسی می‌کند که آیا هر پیش‌نیاز واقعاً توسط تسک قبلی ایجاد شده است یا خیر. برای مثال، اگر تسکی به وضعیت replica_verified نیاز دارد، این لینتر تضمین می‌کند که تسکی پیش از آن، این وضعیت را تولید کرده باشد. پیاده‌سازی این مرحله‌ی قطعی می‌تواند ۶۴ مورد از ۱۳۲ مانع (۴۸٪) را بدون نیاز به «باهوش‌تر شدن» مدل حذف کند.
موانع باقی‌مانده مانند توالی ناایمن و بازگشت ضعیف، نیازمند مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن برای گرفتن بهترین جواب — یا اعتبارسنجی‌های قطعی بیشتر و استدلال واقعی‌تر درباره ریسک و ترتیب هستند.
گام بعدی شما برای توسعه عامل‌ها
اگر در حال ساخت عامل‌هایی هستید که برنامه‌ریزی‌های چندمرحله‌ای انجام می‌دهند، این درس‌ها از اجرای ۱۵۷ هدف را در نظر بگیرید:
- تست روی مجموعه‌داده‌های واقعی: از دموهای کوچک (مثلاً ۳ هدف) برای سنجش برنامه‌ریزی استفاده نکنید؛ این‌ها هرگز الگوهای ساختاری را فاش نمی‌کنند.
- اندازه‌گیری خانواده‌های نقص: به‌جای ردیابی ساده‌ی «موفق/ناموفق»، شکست‌ها را دسته‌بندی کنید تا بفهمید آیا شکاف ساختاری خاصی دارید یا خیر.
- پرهیز از تله ارتقای مدل: فرض نکنید مدل بزرگ‌تر مشکلات ساختاری را حل می‌کند؛ شکاف برنامه‌ریزی یک محدودیت در استدلال است، نه یک محدودیت در توانایی زبانی.
- پیاده‌سازی چک‌های قطعی: پیش از اعتماد به اصلاحات خودکار مدل، یک لایه اعتبارسنجی کدنویسی‌شده (Deterministic) اضافه کنید. حلقه بازبینی یک ابزار است، نه جایگزینی برای بررسی‌های ساختاری.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو