تصور کنید یک برنامه‌نویس ارشد را استخدام کنید که دو شبانه‌روز کامل، بدون یک ثانیه استراحت یا نیاز به راهنمایی شما، کد بزند و در نهایت محصولی سالم تحویل دهد. این دقیقاً همان اتفاقی است که برای Favur رخ داد؛ عاملی که طی ۴۸ ساعت و در ۶ جلسه کاری، ۱۳۱ فایل را بدون نظارت انسانی تولید کرد. این پروژه بر اساس یک «بیانیه محدوده کاری» (SOW) برای ساخت بازی ۲۰۴۸ پیش رفت و نشان داد که استقلال بلندمدت در عامل‌های هوش مصنوعی (AI Agents) — یعنی سیستم‌هایی که می‌توانند اهداف را تجزیه کرده و ابزارها را برای رسیدن به نتیجه به کار بگیرند — بیش از آنکه به کیفیت مدل وابسته باشد، به «هارنس» یا همان چارچوب مدیریتیِ حلقهٔ عملیاتی بستگی دارد.
بیشتر عامل‌ها پس از چند ساعت شکست می‌خورند، چون با خطاهای سیستمی مواجه می‌شوند که حتی پیشرفته‌ترین مدل‌ها هم نمی‌توانند آن‌ها را حل کنند. این شکست‌ها از نوع کرش کردن نیستند، بلکه فروپاشی‌های منطقی‌اند که وقتی مدل برای مدت طولانی در یک حلقه می‌چرخد، رخ می‌دهند. یک مدل بهتر شاید سقف کیفیت خروجی را بالا ببرد، اما هیچ‌کدام از این شکست‌ها را حذف نمی‌کند، زیرا این خطاها ویژگی‌های ذاتی خودِ حلقه هستند، نه مدل.
به گزارش تیم توسعه، برای مقابله با این مشکل، یک سیستم «گیتینگ» (Gating) یا دروازبانی سخت‌گیرانه پیاده شد. در این روش، سیستم به جای تکیه بر نثر و ادعاهای مدل (که مثلاً بگوید «کار با موفقیت تمام شد»)، منتظر دریافت یک اثر فیزیکی و قابل بررسی توسط ماشین می‌ماند. این رویکرد در واقع پاسخی به شکاف میان قصد و عمل است که باعث می‌شود مدل‌ها توهم اجرای ابزار داشته باشند و در اینجا با تایید فیزیکی جایگزین شده است. برای مثال، یک ثبت تغییرات (Commit) تنها زمانی پذیرفته می‌شود که شامل یک هش معتبر (Commit Hash) و لیستی غیرخالی از فایل‌ها باشد. معیارهای پذیرش به جای متن‌های توصیفی، به صورت فیلدهای ساختاریافته بازگردانده می‌شوند. در واقع، هر جا که یک اثر فیزیکی در دسترس باشد، ادعای متنی مدل پذیرفته نمی‌شود؛ چون مدل می‌تواند هر چیزی را ادعا کند، اما نمی‌تواند برای کدی که واقعاً ثبت نکرده، هش تولید کند.
مقابله با توقف کاذب
توقف کاذب (False Completion) زمانی رخ می‌دهد که یک مرحله، بدون انجام واقعی کار، گزارش موفقیت می‌دهد. در یک اجرای نظارت‌شده، این خطا فقط یک دقیقه زمان می‌برد (چون انسان سریعاً متوجه می‌شود). اما در یک اجرای بدون نظارت، مراحل بعدی روی این خطا بنا می‌شوند و شکست اصلی ساعت‌ها بعد ظاهر می‌شود، جایی که دیگر بازگشت به یک نقطه امن و پاک (Clean Rollback Point) ممکن نیست. برای توقف این روند، هارنس از چندین مکانیزم استفاده می‌کند:
- دروازه اثرات (Artifact Gating): تایید موفقیت مرحله را به وجود آثار فیزیکی گره می‌زند، نه گزارش‌های متنی.
- محدودیت ابزار: هر نوع مرحله دقیقاً یک ابزار مشخص دارد که می‌تواند آن را به مرحله بعد پیش ببرد.
- اعتبارسنجی سخت‌گیرانه: اعتبارسنج‌ها پیش از بسته شدن یک مرحله اجرا می‌شوند و هر تاییدیه باید حداقل به دو سند زمینه (Context Documents) استناد کند.
حل مشکل «حلقه تکرار»
یکی از خطرناک‌ترین انواع شکست، عدم همگرایی (Non-convergence) است. شکستی که اجرای طولانی را متوقف می‌کند، کرش کردن نیست (چون کرش قابل شناسایی است)، بلکه حلقه‌ای است که ظاهرش شبیه به عملیات عادی است. در این حالت، پروسه زنده می‌ماند، توکن مصرف می‌کند و خروجی تولید می‌کند، اما عامل بین دو راهکار کاندیدا نوسان می‌کند که هر دوی آن‌ها غلط هستند.
برای متوقف کردن این وضعیت، هارنس از سه لایه حفاظتی استفاده می‌کند:
- بودجه تلاش مجدد (Retry Budgets): هر مرحله یک سقف تلاش دارد؛ وقتی این بودجه تمام شود، مرحله به عنوان «شکست‌خورده» علامت می‌خورد. وضعیت پایانی نمی‌تواند دوباره به وضعیت «در انتظار» بازگردد تا از فعال شدن مجدد مرحله و شروع دوباره چرخه جلوگیری شود. این مدیریت خطا مشابه راهکارهای عملی برای نجات گردش کارهای AI از قطعی‌های طولانی است که بر بازیابی سریع سیستم تاکید دارد.
- سقف ورود مجدد (Re-entry Caps): در مواردی که یک مرحله دوباره به مراحل برنامه‌ریزی قبلی بازمی‌گردد، تعداد این ورودها شمارش می‌شود. رسیدن به این سقف، باعث ارتقاء سطح خطا (Escalation) می‌شود.
- قطع‌کننده‌های مدار (Circuit Breakers): این ابزار شکست‌های تجمعی را در کل مسیر اجرا رصد می‌کند تا بتواند شکست یک مرحله واحد را از خطایی که در مراحل مختلف تکرار می‌شود، تفکیک کند.
مدیریت زمینه و حافظه
اجرا در ۶ جلسه کاری، چالشی برای تداوم وضعیت (State-persistence) ایجاد می‌کند. یک بازنشانی زمینه (Context Reset) معمولاً باعث می‌شود جلسه جدید بدون حافظه‌ای از وضعیت قبلی شروع شود و کارهای نیمه‌تمام باقی بمانند که عامل جدید نمی‌تواند آن‌ها را تفسیر کند.
این سیستم از یک مکانیزم نقطه بازرسی (Checkpointing) استفاده می‌کند که وضعیت را به صورت دوره‌ای و بلافاصله پس از هر موفقیت یا شکست عامل، ذخیره می‌کند. این تداوم حافظه یادآور استفاده از SQLite برای مقاوم‌سازی حافظه عامل‌ها در برابر کرش است تا وضعیت عملیاتی در جلسات مختلف حفظ شود. این وضعیت در مرز بین جلسات باقی می‌ماند و تضمین می‌کند که هر جلسه جدید با مجموعه کاملی از مراحل پاس‌شده و شکست‌خورده از سر گرفته شود. نکته مهم این است که عملیات نقطه بازرسی، روند اجرا را مسدود نمی‌کند.
برای جلوگیری از اتمام ظرفیت زمینه (Context Exhaustion)، هارنس تاریخچه گفتگوها را در لایه‌های مختلف خلاصه یا حذف می‌کند تا به سقف مدل نزدیک شود. اگر ظرفیت کاملاً پر شود، سیستم به جای اجازه دادن به شکست در میانه پیاده‌سازی، درخواست‌ها را به طور سخت‌گیرانه‌ای مسدود (Hard-block) می‌کند.
هزینه و قضاوت بازبین
در این معماری، «کار» از «قضاوت» کاملاً جدا شده است. عاملی که جریان توسعه را مدیریت می‌کند، هیچ کدی نمی‌زند؛ وظیفه او فقط ترتیب دادن زیر-عامل‌ها و اعمال دروازه‌های تایید است. ساخت تست‌ها یک مرحله مجزا و تفویض‌شده است که پیش از پیاده‌سازی انجام می‌شود؛ مرحله پیاده‌سازی تنها با هدف پاس کردن آن تست‌ها وجود دارد. اگر تاییدیه شکست بخورد، مسیر بازگشت به مرحله پیاده‌سازی است، نه حرکت به جلو.
برای جلوگیری از «تایید بی‌قید و شرط» (Rubber-stamping) کدهای بد، بازبین خودکار در صورت اشتباه جریمه می‌شود. بازبین باید پیش از ارائه یافته‌ها، فایل‌ها را بخواند و هر یافته را با یک سطح شدت (Severity) مشخص کند. یک قطع‌کننده مدار برای موارد مثبت کاذب (False-positive) وجود دارد که پس از سه یافته‌ای که مشکل واقعی نباشند، فعال می‌شود. این کار باعث می‌شود «پرچم‌گذاری بیش از حد» هزینه‌بر باشد و دیگر یک راهکار رایگان برای پوشش ریسک نباشد.
شکاف‌های قابلیتی و انحراف از هدف
برای تضمین صداقت سیستم، از «رهاسازی توجیه‌شده با قابلیت» (Capability-justified abandonment) استفاده می‌شود. عاملی که متوقف شده و گزارش دهد که قابلیت لازم برای انجام کاری را ندارد، جریمه نمی‌شود. این کار مانع از آن می‌شود که عامل‌ها کمبودهای خود را پنهان کرده و آن‌ها را با کارهای ساختگی بپوشانند.
یک شکاف بزرگ باقی‌مانده، «انحراف از هدف» (Task Drift) است. هارنس در حال حاضر فاقد یک بررسی معنایی است تا مطمئن شود خروجی همچنان با هدف اصلی مرتبط است و به جای آن به محدودیت‌های ساختاری تکیه می‌کند:
- ابزارهای ثابت: ابزار پیش‌رونده برای هر نوع مرحله ثابت است.
- الزامات تزریقی: الزامات هر مرحله هنگام ورود تزریق می‌شوند، به این معنی که شواهد از پیش شناخته شده‌اند.
- استراتژی پایدار: دانش حاصل از مراحل برنامه‌ریزی تکمیل‌شده باقی می‌ماند و نیاز به استخراج دوباره تصمیمات قطعی را از بین می‌برد.
در این اجرای خاص با استفاده از مدل Meta Muse Spark 1.1، عامل یک نسخه خلاقانه از ۲۰۴۸ ساخت که در آن تم بازی توسط مدل انتخاب شده بود و کاشی‌ها از «خنک» تا «ناپایدار» تغییر می‌کردند. قوی‌ترین سیگنال موفقیت، نه فقط تست‌های نرم‌افزاری، بلکه اجرای واقعی بازی توسط عامل و ثبت حرکات، ادغام‌ها و رویدادهای دستاوردهای بازی بود.
مخزن کد این پروژه به صورت متن‌باز در آدرس https://github.com/awesoftsolutions/idea_meta-muse-2048-game در دسترس است. ضبط کامل اجرا در https://www.youtube.com/watch?v=o0fQ7WQRTjo و بازپخش مرحله‌به‌مرحله در https://favur.dev/go/devto/the2048 قابل مشاهده است.
گام بعدی شما
- اگر در حال توسعه عامل‌های خودکار هستید، به جای تکیه بر ادعای مدل، سیستم‌های «دروازه اثر» (Artifact Gating) را پیاده کنید.
- برای جلوگیری از حلقه‌های بی‌نهایت، بودجه مشخصی برای هر مرحله (Retry Budget) تعریف کنید.
- مخزن کد این پروژه را در گیت‌هاب بررسی کنید تا با ساختار مدیریت وضعیت در جلسات طولانی آشنا شوید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است؛ برای درک اینکه چه زیرساختی چنین استمرار عملیاتی را ممکن می‌کند، به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.
گفتگو