تست ۴۰۴: بودجهٔ حلقه‌ها معیار اصلی سنجش توسعه‌دهندگان عامل‌ها

تصور کنید یک پروژهٔ استخدامی را در ساعت ۹:۴۱ شب باز می‌کنید و با README-ای مواجه می‌شوید که ادعای موفقیت می‌کند، اما به محض اجرای دستور make test فن لپ‌تاپ شما برای ۱۲ دقیقه با حداکثر سرعت می‌چرخد چون یک عامل هوش مصنوعی در حال تلاش بی‌دلیل برای دسترسی به آدرسی است که هرگز وجود نداشته است. این صحنه اکنون در دنیایی که هر روز ادعاهای جدیدی دربارهٔ توانایی مدل‌ها در نوشتن کل یک Pull Request می‌شنویم و فیدهای خبری پر از عامل‌ها و ابزارهای اتصال (Tool Glue) شده است، به اتفاقی رایج تبدیل شده است.

بیشتر مصاحبه‌های فعلی بر روی خروجی نهایی یا هوشمندی پاسخ مدل تمرکز دارند. طبق گزارش این چارچوب جدید، این رویکرد یک ریسک عملیاتی حیاتی را نادیده می‌گیرد: «تکرار خارج از کنترل» (Runaway Retry). در عصر دسترسی رایگان به مدل‌ها و لایه‌های رایگان (Free Tiers)، آن ترس مالی از پر شدن صورت‌حساب کارت اعتباری که زمانی مانع حلقه‌های بی‌نهایت می‌شد، از بین رفته است. این موضوع سد هزینه را حذف کرده اما مشکل گرم شدن سخت‌افزار، اسپم شدن لاگ‌ها و فشار روی مصاحبه‌کننده‌ای که باید جلسه را روز دوشنبه بازبینی کند، باقی مانده است. اگر به کاندیدا دسترسی رایگان به مدل و سرور بدهید، شما دیگر نحو (Syntax) را ارزیابی نمی‌کنید؛ بلکه می‌سنجید که آیا او می‌تواند برای فرآیندی که می‌خواهد تا ابد اجرا شود، بودجه تعیین کند یا خیر.

برای حل این مشکل، این راهنما یک تست «عامل محدودشده» (Bounded Agent) را پیشنهاد می‌دهد. به جای یک پروژه پیچیده، به کاندیدا یک سرویس HTTP بسیار کوچک داده می‌شود. این سرویس عمداً کوچک نگه داشته شده تا هر فراخوانی اضافی ابزار، بیشتر شبیه به «پانیک» مدل به نظر برسد تا یک معماری هوشمندانه. این سرویس دارای سه مسیر فعال و یک مسیر «۴۰۴ چسبناک» است؛ یک نقطه اتصال (Endpoint) به نام /secret که همیشه با خطا مواجه می‌شود. هدف این نیست که عامل رمز را پیدا کند، بلکه باید ثابت کند که می‌تواند یک بن‌بست را تشخیص دهد و متوقف شود.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت و پایداری مدل‌های عامل‌محور اشاره کردیم، مدیریت منابع در لایه اجرا به اندازه کیفیت پاسخ مدل اهمیت دارد. در این راستا، تثبیت سخت‌افزاری در برابر تاریخچهٔ چت ابزاری کلیدی برای دستیابی به تکرارپذیری در ارزیابی این عامل‌هاست.

بستهٔ عامل محدودشده

بر اساس مستندات این متد، اگر تیم استخدام هنوز تست را اجرا نکرده باشد، پرامپت باید به عنوان یک «بسته پیشنهادی» برچسب بخورد. کاندیدا چهار ساعت زمان، یک فایل README و یک دستور دارد که حتماً باید به پایان برسد. سرویس HTTP مورد استفاده شامل مسیرهای زیر است:

• GET /health -> بازگشت ۲۰۰ {"ok": true}
• GET /items -> بازگشت ۲۰۰ {"items": []}
• POST /items -> بازگشت ۲۰۱ برای JSON معتبر
• GET /secret -> همیشه بازگشت ۴۰۴ (به کاندیدا صراحتاً گفته می‌شود که نباید مسیری اختراع کند)

کاندیداها می‌توانند از مدل‌های کدنویسی و سرورهای آزمایشی استفاده کنند، اما اکیداً از اتصال به اعتبارنامه‌های تولیدی (Production)، داده‌های مشتری یا کلیدهای خصوصی تستِ پروژه منع شده‌اند.

یک تحویل کامل برای معتبر شناخته شدن باید شامل چهار مورد باشد:

• agent_run.py: درایوری که مدل یا ابزارها را فراخوانی می‌کند اما باید حتماً متوقف شود.
• ledger.jsonl: یک لاگ دقیق که هر خط آن یک فراخوانی مدل یا ابزار است و مواردی مثل برچسب زمانی (ts)، نوع (kind)، نام (name)، بایت‌های ورودی (bytes_in)، بایت‌های خروجی (bytes_out)، خطا (error) و ردیف تکراری (duplicate_of) را ثبت می‌کند.
• STOP.md: توضیحی به زبان ساده درباره قانون توقف و اقدام مشخصی که در برابر یک خطای تکراری صورت گرفته است.
• replay.sh: اسکریپتی که به مصاحبه‌کننده اجازه می‌دهد جلسه را روی یک ماشین خام بدون تاریخچه چت اجرا کند. این اسکریپت باید در کمتر از ۶۰ ثانیه با خروجی ۰ یا ۱ به پایان برسد.

محدودیت‌های سخت بودجه

این چارچوب ارزیابی بر اساس «حس و حال» (Vibes) را با محدودیت‌های سخت جایگزین می‌کند که در کد درایور تعبیه شده‌اند، نه فقط به صورت یک قول در فایل README. یک عامل پذیرفته‌شده باید این سقف‌ها را رعایت کند:

• حداکثر ۱۲ فراخوانی مدل.
• حداکثر ۲۰ فراخوانی ابزار.
• توقف کامل پس از ۳ خطای مشابه متوالی.
• زمان اجرای کل اسکریپت replay.sh حداکثر ۴۵ ثانیه.
• قانون سخت‌گیرانه برای ثبت خطای ۴۰۴ یک‌بار و عدم تکرار آن.

پیاده‌سازی فنی: LoopBudget

برای اینکه بودجه قابل تست و وارد کردن باشد، این راهنما کلاس LoopBudget را پیشنهاد می‌کند. این کلاس رویدادها را با استفاده از dataclass و یک deque برای خطاها ردیابی می‌کند. حیاتی‌ترین مکانیزم، منطق duplicate_of است. در حالی که یک مدل رایگان ممکن است خطای ۴۰۴ را با لحنی گرم‌تر دوباره توضیح دهد، لاگ نباید این را به عنوان اطلاعات جدید تلقی کند. وقتی /secret یک‌بار شکست می‌خورد، شکست بعدی یک «رویداد بودجه» است، نه یک چرخش داستانی.

در نمونه کد loop_budget.py ارائه شده، متد record قبل از افزودن به لاگ، ساعت و تعداد فراخوانی‌ها را چک می‌کند. اگر صف خطاها به حد max_identical برسد و تمام ورودی‌ها یکسان باشند، استثنای BudgetBlown صادر می‌شود. این یعنی با عامل مثل مهمانی رفتار می‌شود که کارت غذای محدود دارد، نه هم‌خانه‌ای که دسترسی نامحدود به یخچال دارد.

پیاده‌سازی sticky_404.py تضمین می‌کند که کاندیدا نتواند برای دور زدن قانون توقف، «سرور را تعمیر کند». این کد از BaseHTTPRequestHandler برای ارائه مسیرهای ثابت روی 127.0.0.1:8077 استفاده می‌کند. متد do_POST به‌طور خاص JSON را اعتبارسنجی کرده و برای ورودی‌های نامعتبر خطای ۴۰۰ و برای ورودی‌های درست ۲۰۱ برمی‌گرداند.

اسکریپت replay.sh به‌گونه‌ای طراحی شده که برای مصاحبه‌کنندگان خسته، «کسل‌کننده» باشد (که این یک ویژگی است). این اسکریپت سرور را در پس‌زمینه اجرا می‌کند، عامل را می‌راند و سپس با یک قطعه کد پایتون، فایل ledger.jsonl را برای تکرار ۴۰۴ها یا طول بیش از حد لاگ بررسی می‌کند. این اسکریپت به‌طور خاص چک می‌کند که اگر len(secrets) > 1 یا len(rows) > 32 باشد، خروجی غیرصفر صادر شود.

شناسایی حالت‌های شکست

این راهنما چهار «بسته شکست» رایج را شناسایی کرده که مصاحبه‌کنندگان باید آن‌ها را تا روز چهارشنبه رد کنند:

• بیانیه خبری: در فایل STOP.md نوشته شده «ما در صورت خطا متوقف می‌شویم»، اما در کد agent_run.py تمام استثناها (Exceptions) گرفته شده و برنامه ادامه می‌یابد. لاگ هم فقط یک خط است که می‌گوید «با موفقیت اجرا شد». این مورد به دلیل نبود شواهد رد می‌شود، نه به دلیل نبود شعر و ادبیات.
• حلقه قطعیت: عامل مسیر /secret را تکرار می‌کند چون مدل «می‌خواست مطمئن شود». قطعیت، بودجه نیست. ستون duplicate_of در لاگ اینجا مثل یک هشدار دود عمل می‌کند. اگر تکرارها ثبت نشده باشند، به دلیل جعل لاگ رد می‌شود.
• مقاله در لباس مبدل: عامل تمام بودجه را صرف برنامه‌ریزی می‌کند. ۱۲ فراخوانی مدل انجام می‌دهد اما صفر فراخوانی ابزار؛ و در نهایت یک مقاله زیبا درباره REST می‌نویسد. دسترسی رایگان به مدل باعث می‌شود این مقاله رایگان به نظر برسد، اما برای مصاحبه‌کننده‌ای که باید آن را بخواند، رایگان نیست. اگر replay.sh نشان دهد که لاگ هرگز به GET /items نرسیده، این یک شکست است.
• فرآیند یتیم: عامل یک پردازش کمکی طولانی‌مدت را روی سرور اجرا می‌کند و کار را به پس‌زمینه می‌برد تا replay.sh در دو ثانیه تمام شود. برای شناسایی این مورد، در STOP.md باید شرط باشد که بعد از خروج، دستور pgrep -f agent اجرا شود و هیچ پردازشی را پیدا نکند. سرورهای رایگان هنوز PID دارند و PIDها اگر به آن‌ها نگاه نکنید، دروغ می‌گویند.

اجرای دستورالعمل ارزیابی

برای حذف ذهنیت شخصی، دستورالعمل ارزیابی باید در یک فایل تست (مثل test_loop_budget.py) باشد، نه در یک فایل اکسل با نام «احساسات». این کار مانع از بحث مصاحبه‌کنندگان درباره «ابتکار عمل» کاندیدا می‌شود. با استفاده از pytest می‌توان سه تست مشخص را اجرا کرد:

۱. test_repeated_404_trips_the_stop: تایید می‌کند که ۳ خطای یکسان (مثلاً "GET /secret -> 404") باعث صدور BudgetBlown می‌شود.
۲. test_model_cap: تضمین می‌کند درایور پس از حداکثر تعداد فراخوانی مدل (مثلاً ۲ مورد) متوقف شود.
۳. test_clock: با استفاده از monkeypatch زمان را شبیه‌سازی کرده (تنظیم time.monotonic روی b.deadline + 1) و توقف بر اساس ساعت دیواره را بررسی می‌کند.

اگر کاندیدا این سه تست را پاس کند، شایستگی یک گفتگو را دارد. در غیر این صورت، چرخه مصاحبه بدون بحث درباره فرمت کدها به پایان می‌رسد.

محدوده و محدودیت‌ها

این متد برای هر سناریویی نیست. برای غربالگری کارآموزانی که باید نقشه‌های هش (Hash Maps) را بلد باشند کاربرد ندارد، چون آن‌ها را برای بلد نبودنِ «نقش بازی کردن در قالب یک عامل» جریمه می‌کند. همچنین اگر تیم حقوقی اجازه ارسال متن‌ها به مدل‌های شخص ثالث را نداده باشد، نباید استفاده شود، زیرا توافق‌نامه عدم افشای (NDA) کاندیدا توهمی نیست که بتوان با تکرار آن را برطرف کرد.

علاوه بر این، اگر محصول را بیش از حد پیچیده کنید، این متد شکست می‌خورد. به محض اینکه کوبرنتیز، صف پیام یا داشبورد را وارد کنید، کاندیدا می‌تواند حلقه تکرار را پشت مفهوم «سازگاری نهایی» (Eventual Consistency) پنهان کند. سرویس را خسته‌کننده نگه دارید تا بودجه صدای بلندی داشته باشد.

محدودیت‌های فنی کد نمونه نیز وجود دارد. LoopBudget تعداد فراخوانی‌ها و رشته‌های خطای یکسان را می‌شمارد اما از توکن‌ها، GPU یا هدرهای Rate-limit اطلاعی ندارد. دو بدنه خطای ۴۰۴ متفاوت ممکن است به عنوان پیشرفت تلقی شوند. برای تطبیق دقیق‌تر، پیشنهاد می‌شود به جای عذرخواهی مدل، هشِ مسیر به‌علاوه کد وضعیت (Status Code) محاسبه شود. همچنین، ساعت دیواره از time.monotonic() استفاده می‌کند که نمی‌تواند کارهای اجرا شده روی یک ماشین راه دور را که فقط رسید ارسال می‌کند، تشخیص دهد.

برای کسانی که به محیطی برای تست این چارچوب نیاز دارند، نویسنده به MonkeyCode اشاره می‌کند؛ ابزاری که دسترسی رایگان به مدل و سرور را فراهم می‌کند تا تیم استخدام بتواند بدون تبدیل جلسه به یک جلسه خرید تجهیزات، متد را تمرین کند. این ابزار با اعطای حجم گسترده‌ای از توکن‌های رایگان توانسته است موانع مالی بازبینی خودکار کد را حذف کند. این کار اجازه می‌دهد تیم استخدام ارزیاب را همان‌طور که روز دوشنبه اجرا می‌کنند، تست کنند، نه آن‌طور که در یک ویدیو دمو نمایش داده می‌شود.

این تغییر در ارزیابی، تمرکز را از «هماهنگی چندعاملی» به «پایداری پایه فرآیند» منتقل می‌کند. برای توسعه‌دهنده، این یعنی «دکمه توقف» ویژگی اصلی است. اگر عاملی نتواند یک خطای ۴۰۴ مستند را بدون پانیک مدیریت کند، فارغ از اینکه کد نهایی‌اش چقدر صیقل‌خورده باشد، در محیط تولید یک ریسک است.

گام بعدی شما

• اگر مصاحبه‌کننده هستید، به جای بررسی خروجی نهایی، یک مسیر «بن‌بست» (Dead-end) به پروژه اضافه کنید و ببینید عامل کاندیدا چه زمانی تسلیم می‌شود.
• در پیاده‌سازی‌های خود، کلاسی شبیه به LoopBudget را برای ردیابی تکرارهای بی‌هوده مدل‌ها اضافه کنید تا از اتلاف توکن‌ها جلوگیری کنید.
• از ابزارهایی مثل MonkeyCode برای شبیه‌سازی محیط‌های ایزوله جهت تست استقرار عامل‌ها استفاده کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.