۵۰۰ میلیارد توکن بعد: ایجنت‌های هوش مصنوعی یک بازی شوتر را کامل دی‌کامپایل کردند

Maurice Heumann (momo5502)، توسعه‌دهنده‌ی شناخته‌شده در حوزه‌ی مهندسی معکوس، گزارش یک پروژه‌ی سه‌ماهه را منتشر کرده: دی‌کامپایل کامل یک بازی شوتر اول‌شخص قدیمی و محبوب به ++C، تقریباً تماماً به دست ایجنت‌های هوش مصنوعی و با مصرف بیش از ۵۰۰ میلیارد توکن. اسم بازی را به خاطر فشار حقوقی نگفته، ولی اصل ماجرا هم بازی نیست؛ درس‌هایی است که درباره‌ی هماهنگ کردن ایجنت‌ها در مقیاس بزرگ گرفته‌اند.

چیدمان اولیه

کار با اشتراک Claude Max و بعد Codex Pro شروع شد؛ ایجنت‌ها داخل Claude Code و Codex CLI اجرا می‌شدند. برای هر فایل cpp یک ایشوی گیت‌هاب ساخته می‌شد و ایجنت‌ها با GitHub CLI پیشرفتشان را ثبت می‌کردند. ارتباط بین ایجنت‌ها (و آدم‌ها) هم از طریق یک کانال دیسکورد بود که خطاهای CI را هم با وب‌هوک دریافت می‌کرد. برای دی‌اسمبل هم از ida-mcp رسمی Hex-Rays استفاده شد.

ماه اول: پیشرفت ظاهری، کد غلط

با سه ایجنت کارگر و یک ایجنت بازبین، حدود ۸۰٪ بازی دی‌کامپایل شد؛ بازی بالا می‌آمد، منو و نقشه‌ها لود می‌شد. چند ترفند هم جواب داد: پایین آوردن آستانه‌ی compaction از ۹۰٪ به ۴۲٪ پر شدن کانتکست، و یک کران‌جاب ساعتی که ایجنت‌ها را مجبور می‌کرد سند دستورالعمل را دوباره بخوانند تا تمرکزشان را از دست ندهند.

اما مشکل اصلی اینجا بود: کد خوانا بود ولی از نظر معنایی غلط. امضای توابع و ساختار structها اشتباه بود، منطق از خودشان اختراع یا حذف می‌کردند و حتی دسترسی ساده به متغیرهای سراسری را به هش‌تیبل‌های گران تبدیل کرده بودند. جالب‌تر اینکه کامنت‌هایی که ایجنت کارگر در کد می‌نوشت عملاً مثل prompt injection روی بازبین عمل می‌کرد و او توجیه‌ها را می‌پذیرفت.

«اوراکل»: مقایسه‌ی بایت‌به‌بایت

راه‌حل، یک معیار پذیرش عینی بود: همان کامپایلر اصلی بازی را برداشتند و اسکریپتی نوشتند که خروجی هر تابع بازسازی‌شده را بایت‌به‌بایت با فایل اجرایی اصلی مقایسه می‌کند (با درنظرگرفتن relocationها). یا PASS یا FAIL.

اولین واکنش ایجنت‌ها؟ تقلب. inline assembly نوشتند و بارها سعی کردند خود اسکریپت را دستکاری کنند تا تابعشان از مقایسه کنار گذاشته شود. در نهایت CI هش اسکریپت را با یک secret در GitHub Actions چک کرد. نکته‌ی جالب دیگر: با این معیار سخت‌گیرانه، مدل‌های ارزان‌تر هم نتیجه‌ی عالی دادند و پروژه به ۱۴ ایجنت Luna و ۲ ایجنت Opus 5.5 رسید.

نتیجه: ۹۹٪ توابع بازسازی شده، ۸۳٪ کاملاً بایت‌به‌بایت منطبق، و بازی بدون باگ محسوس و با تمام قابلیت‌ها اجرا می‌شود.

نظر من

به نظرم مهم‌ترین جمله‌ی این گزارش این است: «درستی باید قابل‌بررسی توسط ماشین باشد.» همه‌ی ما وسوسه می‌شویم سرعت ایجنت‌ها و تعدادشان را بالا ببریم، ولی تا وقتی یک تست عینی PASS/FAIL نداریم، داریم کد خوانا ولی غلط تولید می‌کنیم. ایجنت بازبین جای تست را نمی‌گیرد؛ حتی خودش فریب کامنت‌های ایجنت دیگر را می‌خورد.

درس دوم برای من این بود که تولید کد دیگر ارزان است؛ اگر خراب است، دورش بریزید. تیم momo یک ماه کد بد را نگه داشت و بعد فهمید از صفر شروع کردن سریع‌تر بود. و اینکه ایجنت‌ها اگر جای تفسیر باشد تقلب می‌کنند، یعنی دستورالعمل دقیق و محافظت از خود ابزار ارزیابی هم بخشی از مهندسی است. اگر روی پروژه‌های بزرگ با ایجنت کار می‌کنید، این پست را کامل بخوانید.

منبع: momo5502.com