تبدیل لاگ‌های گران‌قیمت عامل‌های هوش مصنوعی به تست‌های رایگان

اگر هر بار برای پیدا کردن یک باگ در عامل هوش مصنوعی خود، هزینه‌ی هزاران توکن را می‌پردازید، باید بدانید که روش سنتی عیب‌یابی در حال تغییر است. تصور کنید به جای اجرای مجدد یک چرخه نامطمئن، بتوانید دقیقاً همان لحظه‌ای را که مدل اشتباه کرد، بدون پرداخت یک سنت تکرار کنید.

عیب‌یابی عامل (Agent) — شبیه به کارآگاهان است که باید از روی ردپای دیجیتال بفهمند کجا اشتباه رخ داده — معمولاً صبر و بودجه‌ی توسعه‌دهنده را می‌بلعد. اکثر حلقه‌های عیب‌یابی عامل‌ها به بدترین شکل ممکن گران هستند. شما برای توکن‌های مدل، فراخوانی ابزارها و یک لایه جدید از عدم قطعیت هزینه می‌پردازید، فقط برای اینکه یک باگ را برای بار دوم ببینید. این هزینه‌های پیش‌بینی‌نشده یادآور تجربه‌ی تلخ برخی تیم‌هاست که در یک حلقه بی‌نهایت، هزاران توکن بودجه تولید خود را سوزاندند. طبق گزارشی که در ۱۴ سپتامبر ۲۰۲۶ در dev.to منتشر شد، اکثر برنامه‌نویسان برای دیدن یک باگ، کل چرخه را دوباره اجرا می‌کنند و امیدوارند ماهیت غیرقطعی مدل، باگ را در دور دوم پنهان نکند. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، پیش‌بینی رفتار مدل‌های زبانی بزرگ همواره با چالش عدم قطعیت همراه است.

در حالی که یک ردپای ضبط‌شده (Recorded Trace) به شما می‌گوید یک بار چه اتفاقی افتاده است، اما به‌ندرت می‌گوید که پس از اعمال اصلاحات شما چه اتفاقی خواهد افتاد. این شکاف همان جایی است که انتشار نسخه‌های جدید متوقف می‌شود. بسیاری از تیم‌ها سعی می‌کنند با سخت‌گیرانه‌تر کردن سیستم‌های ردیابی (Tracing) — با استفاده از محدودیت‌های تعداد اسپان‌ها (Span Cardinality Limits)، ترتیب علّی (Causal Ordering) و گیت‌های اسپان بسته (Closed-span Gates) — این مشکل را حل کنند؛ اما همچنان نمی‌توانند به این پرسش حیاتی پاسخ دهند: آیا تغییر کد من رفتار عامل را عوض کرد یا محیط اجرای برنامه تغییر کرده است؟

در اینجا مفهوم «هارنس بازپخش» (Replay Harness) وارد می‌شود. اگر اجرای عامل را به یک فیلم تشبیه کنیم، لاگ‌های معمولی شبیه به خلاصه‌ی مکتوب داستان هستند؛ شما می‌دانید چه اتفاقی افتاده اما نمی‌توانید با آن تعامل کنید. در مقابل، هارنس بازپخش شبیه به یک ضبط دیجیتال است که به شما اجازه می‌دهد فیلم را متوقف کنید، یک خط کد را تغییر دهید و ببینید فیلم دقیقاً از کجا از فیلم‌نامه اصلی منحرف می‌شود. در لحظه‌ای که یک ردپا می‌تواند به‌صورت آفلاین بازپخش شود، دیگر یک لاگ ساده نیست، بلکه به یک تست تبدیل می‌شود. این امر یک ردپا را از یک رکورد تاریخی به یک مورد آزمون (Test Case) کاربردی تبدیل می‌کند. این رویکرد در واقع تکامل یافته‌ی سیستم‌های ثبت «رسید» تصمیمات است که پیش‌تر توانستند خطاهای منطقی پیچیده در خط لوله را افشا کنند.

سه مرز تعیین‌کننده رفتار

به نقل از گزارش dev.to، تقریباً هر باگی در عامل‌ها از سه مرز مشخص نشأت می‌گیرد و هر چیز دیگری در سیستم — از درخت اسپان‌ها و خطوط لاگ گرفته تا شمارنده‌های توکن — صرفاً تفسیری بر این تصمیمات است:

• درخواست‌های مدل: پرامپت، طرح‌های ابزار (Tool Schemas) و پارامترهای رمزگشایی که به مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — ارسال می‌شود.
• فراخوانی ابزارها: نام تابع و آرگومان‌های خاصی که عامل برای اجرا انتخاب می‌کند.
• خوانش‌های محیطی: کلیدهای پیکربندی یا مقادیر داده‌ای که از سیستم خوانده می‌شوند.

مکانیزم «کاست» (Cassette)

برای ثبت این مرزها، نویسنده مفهوم «کاست» را معرفی می‌کند؛ نقشه‌ای که هش (Hash) یک ورودی استاندارد را به خروجی مشاهده‌شده متصل می‌کند. سیستم با هش کردن لیست پیام‌ها، طرح ابزارها، پارامترهای رمزگشایی و شاخص گام (Step Index)، یک کلید منحصربه‌فرد برای هر تصمیم می‌سازد.

این استراتژی کلیدگذاری باعث می‌شود سیستم به‌شدت سخت‌گیر باشد. اگر عامل با یک پرامپت متفاوت، یا در جایگاهی متفاوت از چرخه به همان فراخوانی برسد، کلید تغییر می‌کند. این اتفاق باعث ایجاد یک استثنای ReplayMiss می‌شود. این استثنا اصلی‌ترین سیگنال عیب‌یابی است و به توسعه‌دهنده می‌گوید دقیقاً کدام ورودی تغییر کرده و اجرا از کجا منحرف شده است. از آنجا که سیستم بر اساس شاخص گام کلیدگذاری می‌کند، هر بازسازی کد (Refactor) که تصمیمات یکسانی بگیرد اما ترتیب آن‌ها متفاوت باشد، بازپخش را با شکست مواجه می‌کند. اگرچه این موضوع در میانه بازسازی کد ممکن است باعث ایجاد نویز شود، اما دقیقاً همان چیزی است که پیش از انتشار نهایی مورد نیاز است.

پیاده‌سازی و گردش کار

پیاده‌سازی مرجع پیشنهادی با نام tape.py در دو حالت عمل می‌کند: ضبط و بازپخش. در حالت ضبط، هارنس فراخوانی واقعی مدل را اجرا کرده و نتیجه را در یک فایل .jsonl ذخیره می‌کند. در حالت بازپخش، فراخوانی را رهگیری کرده و نتیجه ذخیره‌شده را بدون ارسال درخواست به شبکه برمی‌گرداند.

این سیستم از کلاس Tape و تابع _key استفاده می‌کند که با hashlib.sha256 اثرانگشت‌های ۱۶ کاراکتری (Hex Digests) از داده‌ها می‌سازد. حلقه عامل، فراخوانی‌های گران‌قیمت خود را از طریق این نوار (Tape) هدایت می‌کند. برای مثال، اجرای یک عامل با بودجه max_steps برابر با ۱۲ گام می‌تواند ضبط شود.

ضبط یک اجرای شکست‌خورده (مانند موردی که توسط tasks/issue-412.txt تحریک شده است) ممکن است منجر به فایلی با ۱۷ خط شود که نشان‌دهنده ۱۷ تصمیم است. این کل اجرای شکست‌خورده اکنون در سیستم کنترل نسخه (Version Control) در کنار تسک معیوب قرار می‌گیرد. تست‌های بعدی برای اصلاح باگ، با هزینه صفر توکن و بدون ترافیک شبکه روی این کاست اجرا می‌شوند. اگر ویرایش یک پرامپت باعث جابجایی یک فراخوانی ابزار شود، بازپخش در گام ۲ شکست می‌خورد. اگر طرح یک ابزار تغییر کند، کلید llm در گام ۱ تغییر می‌کند. برای کشف هیچ‌کدام از این موارد، نیازی به فراخوانی مدل نیست.

ثبت مرزها و حالت‌های شکست

ضبط همه‌چیز آسان است اما بی‌فایده. این راهنما طراحی خاصی را برای آنچه باید در کاست قرار گیرد پیشنهاد می‌کند تا از شکست در ثبت جلوگیری شود:

• درخواست‌های مدل: لیست پیام‌ها، طرح ابزار مرتب‌شده، پارامترهای رمزگشایی و شاخص گام را ثبت کنید تا تغییرات پرامپت یا طرح (Schema Drift) شناسایی شوند.
• فراخوانی ابزارها: نام، آرگومان‌ها، کلیدهای Idempotency و میلی‌ثانیه‌های ساعت دیواری (Wall-clock) را ثبت کنید تا آرگومان‌های تغییر یافته یا تلاش‌های مجدد خاموش (Silent Retries) پیدا شوند.
• محیط: کلیدها و مقادیر مجاز (Allowlisted) را ثبت کنید تا تغییرات پیکربندی بین ماشین‌های مختلف شناسایی شود.
• هارنس: کد SHA گیتِ حلقه عامل را ثبت کنید تا تشخیص دهید آیا کاست تحت یک مسیر کد متفاوت ضبط شده است یا خیر.

مدیریت اثرات جانبی و حریم خصوصی

بر اساس مستندات این راهنما، ضبط همه‌چیز می‌تواند فاجعه‌بار باشد. اثرات جانبی برگشت‌ناپذیر — مانند پردازش یک پرداخت، استقرار (Deploy) یک سرویس یا ارسال یک پیام — باید در لایه ابزار شبیه‌سازی (Stub) شوند. اگر ابزاری قابل شبیه‌سازی نیست، نباید از مسیر نوار ضبط عبور کند؛ توسعه‌دهندگان باید مسیر خواندن (Read Path) را پوشش دهند و مسیر نوشتن (Write Path) را رها کنند.

حریم خصوصی داده‌ها تنش ثانویه‌ای ایجاد می‌کند. پاک کردن اسرار (Secrets) از یک کاست باعث تغییر هش می‌شود و در نتیجه بازپخش می‌شکند. راهکار پیشنهادی این است که ورودی تصمیم‌گیرنده برای استفاده ماشین به صورت یک فیلد هش دست‌نخورده باقی بماند، در حالی که یک نسخه سانسورشده در کنار آن برای مطالعه توسعه‌دهندگان انسان ذخیره شود.

محدودیت‌های بازپخش

باید توجه داشت که هارنس بازپخش، منطق کد را اثبات می‌کند، نه رفتار مدل را. از آنجا که ارائه‌دهندگان مدل حتی با بذر (Seed) ثابت ممکن است متن متفاوتی برگردانند، بازپخش بیانی از مسیر کد است، نه تکرارپذیری استنتاج (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند، شبیه به خودِ آشپزی و نه دوره‌ی آموزش آشپز. اگر باگی در رفتار نمونه‌برداری (Sampling) مدل وجود داشته باشد، این روش آن را پیدا نمی‌کند و هیچ مقدار ردیابی (Tracing) نمی‌تواند آن را بیابد.

علاوه بر این، کاست‌ها «پیر» می‌شوند. هر تغییری در قالب پرامپت، طرح ابزار یا بازسازی ساختار حلقه، ضبط قبلی را باطل می‌کند. با این حال، نویسنده استدلال می‌کند که ضبط مجدد، بهای لازم برای داشتن یک تست تکرارپذیر است. این رویکرد را باید در صورتی که اجراها کوتاه و ارزان هستند، شکست‌ها صرفاً محیطی‌اند، یا هدف عامل رصد انحرافات بلندمدت (Long-horizon Drift) است (جایی که تثبیت یک تصمیم واحد گمراه‌کننده است)، نادیده گرفت.

اقتصاد دسترسی رایگان

این گردش کار ریاضیات توسعه عامل را تغییر می‌دهد؛ زیرا ضبط گران است اما بازپخش رایگان. یک بار پرداخت هزینه مدل برای ضبط، اجازه می‌دهد هزاران بار روی منطق مسیریابی و پرامپت‌ها بدون صرف توکن آزمایش کنید.

در این راستا، پلتفرم MonkeyCode با ارائه دسترسی رایگان به مدل و سرور، هزینه ضبط اولیه و ضبط مجدد کاست‌های پیر شده را کاهش می‌دهد. این پلتفرم با فراهم کردن زیرساخت‌های ردیابی رایگان، امکان تست‌های رگرسیون در سطح ردپا را برای توسعه‌دهندگان تسهیل کرده است. گزینه سرور رایگان به‌ویژه مفید است زیرا کاست‌ها باید روی ماشینی نوشته شوند که ابزارها واقعاً در آن اجرا می‌شوند تا اعتبارنامه‌ها، مسیرهای شبکه و شکل داده‌های صحیح ثبت شوند. MonkeyCode در حال حاضر سهمیه ۱۰ میلیون توکن رایگان را اعلام کرده است، هرچند کاربران باید کوتاهای فعلی را بررسی کنند زیرا ممکن است تغییر کنند.

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

گام بعدی شما

• تکرار شایع‌ترین شکست عامل خود را شناسایی کرده و برای آن یک کاست ضبط کنید.
• به جای خواندن لاگ‌های متنی، نتایج بازپخش را با ضبط اصلی مقایسه (Diff) کنید.
• ابزارهای حساس (مانند پرداخت یا ارسال ایمیل) را در لایه ابزار شبیه‌سازی کنید تا از اجرای ناخواسته در زمان تست جلوگیری شود.

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