«لیست‌های بسته‌بندی»؛ راهکاری برای اعتبارسنجی محلی در عامل‌های هوش مصنوعی

هر بار فراخوانی مدل برای اجرای مجدد یک عامل شکست‌خورده، صرفاً یک هزینه است و نه یک تشخیص؛ مگر آنکه فایل ردپای اول دارای یک ساختار بسته و کامل باشد. در ۱۰ اکتبر ۲۰۲۶، یک پیشنهاد فنی در dev.to سازوکاری به نام «گیت شکل ردپا» (Trace-Shape Gate) را معرفی کرد که با تحمیل قراردادهای ساختاری سخت‌گیرانه بر مصنوعات عامل، جلوی شکست‌های خاموش در حلقه‌های عیب‌یابی را می‌گیرد.

بیشتر شکست‌های عامل (Agent) — شبیه به کارمندی که دستورات را اجرا می‌کند اما گزارش کارش ناقص است — در سکوت رخ می‌دهند. طبق گزارش این منبع، ممکن است مدل یک پاراگراف برگرداند در حالی که لاگ ابزار یک دستور را نشان دهد، و درخت کاری (Working Tree) تغییر کند، اما اگر این مصنوعات یک شناسه منحصربه‌فرد مشترک نداشته باشند، هیچ‌کدام از این سه مورد به عنوان یک «بازه» (Span) شناخته نمی‌شوند. بدون بررسی ساختاری، فراخوانی بعدی مدل عملاً یک داستان کاملاً جدید را شروع می‌کند. در چنین شرایطی، شما نمی‌توانید تشخیص دهید که آیا عامل همان ابزار را دوباره امتحان کرده، از آن عبور کرده یا مسیری سوم را اختراع کرده است. ممکن است خط خلاصه یک اجرا بگوید که عملیات به پایان رسیده است، اما این جمله ثابت نمی‌کند که یک بازه ریشه (Root Span) وجود دارد، یا هر فراخوانی ابزار دارای یک فرزند است، و یا اینکه یک خطا دارای نوعی است که بتوان آن را بعداً گروه‌بندی کرد. این ابهام در وضعیت نهایی، یادآور چالش‌های استفاده از برچسب‌های واحد برای پایان عملیات است که منجر به گم‌شدن جزئیات اجرایی در گردش‌کارهای پیچیده می‌شود.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی پایداری سیستم‌های عامل‌محور اشاره کردیم، نبودِ متاداده‌های دقیق، بزرگ‌ترین مانع در مسیر اتوماسیون است. تصور کنید یک متصدی ارسال، جعبه‌ای را بررسی می‌کند؛ او نیازی به باز کردن تک‌تک اقلام ندارد تا بفهمد محموله معتبر است یا خیر، بلکه فقط برچسب، وزن و مهر را چک می‌کند. در این چارچوب، «مهر» شامل شناسه ردپا (Trace ID)، شناسه‌های منحصربه‌فرد بازه (Span IDs)، لینک‌های والد، مدت‌زمان غیرمنفی، نام ابزار و هش ورودی است. این موضوع که آیا هش با فایلی که قصد ویرایش آن را داشتید مطابقت دارد یا خیر، سؤالی است که در مراحل بعدی بررسی می‌شود. ترکیب این دو مرحله (بررسی ساختار و بررسی محتوا) همان جایی است که تیم‌ها بودجه مدل خود را صرف فیلدهای گم‌شده می‌کنند.

مکانیسم گیت شکل

ابزار پیشنهادی با نام trace_shape.py به عنوان یک گیت محلی عمل می‌کند که به‌جای پروتوباف‌های OTLP، خروجی‌های ساده‌شده JSON را می‌خواند. بر اساس مستندات این ابزار، اگر یک ردیاب (Tracer) از قبل JSON تولید کند، کاربر می‌تواند با یک آداپتور (Adapter) — لایه‌ای سازگارساز که دو سیستم متفاوت را به هم وصل می‌کند — فیلدهای spanId ،parentSpanId و startTimeUnixNano را مپ کند تا خودِ گیت ساده و بدون پیچیدگی باقی بماند. این گیت تصمیم نمی‌گیرد که آیا یک وصله کد (Patch) درست است یا خیر، بلکه فقط بررسی می‌کند که آیا اجرای فعلی با اجراهای دیگر قابل مقایسه است یا نه. گیت یک قرارداد کوچک و سخت‌گیرانه را تحمیل می‌کند تا اطمینان حاصل شود که شکست دقیقاً به یک دلیل رخ می‌دهد: نامعتبر بودن ساختار. این رویکرد سخت‌گیرانه در اعتبارسنجی، مشابه استفاده از گیت‌های الزام‌آور برای جلوگیری از تایید خودکار و نادرست در مراحل کدنویسی است تا از خروجی‌های توهمی جلوگیری شود.

الزامات ساختاری کلیدی عبارت‌اند از:

• ریشه واحد: دقیقاً یک بازه ریشه که والد آن خالی است. ریشه همچنین باید ویژگی run.id را داشته باشد.
• یکپارچگی والد: هر بازه دیگر باید به والدی اشاره کند که در همان فایل وجود دارد.
• شناسه‌های منحصربه‌فرد: شناسه‌های بازه (Span IDs) نباید تکراری باشند.
• اعتبارسنجی ساعت: زمان پایان (end_ns) باید حداقل برابر با زمان شروع (start_ns) باشد. این مورد مقادیر ساعتِ خودِ بازه را بررسی می‌کند، نه ترتیب زمانی بین ماشین‌های مختلف را.
• هویت ردپا: سند باید شامل یک trace_id معتبر باشد.

اعتبارسنجی ابزار و خطا

برای بازه‌هایی که با tool. شروع می‌شوند، گیت هر دو مورد tool.name و هش input.sha256 را الزامی می‌کند. این هش به عنوان یک کلید پیوند (Join Key) برای مقایسه‌های رفتاری (Behavioral Diffs) بعدی عمل می‌کند. آرگومان خام ابزار باید خارج از بازه و با کلید همان هش ذخیره شود، در صورتی که بدنه برای بازپخش محلی (Local Replay) مورد نیاز باشد. گیت فقط بررسی می‌کند که فیلد هش وجود داشته باشد و آن را دوباره محاسبه نمی‌کند، زیرا بدنه در فایل نیست.

اگر وضعیت یک بازه به عنوان «خطا» (error) علامت‌گذاری شود، باید حتماً یک رویداد استثنا (Exception Event) یا ویژگی error.type (مثلاً مقدار timeout) را همراه داشته باشد.

اگر هر یک از این فیلدها گم شده باشند، اسکریپت کد خروجی ۲ را صادر می‌کند. این طراحی برای توقف فوری شل (Shell) است، درست مانند تست‌های شکست‌خورده که استقرار را متوقف می‌کنند. یک هشدار ساده اجازه می‌دهد مرحله بعدی — یعنی فراخوانی گران‌قیمت مدل — اجرا شود و هدف گیت را باطل می‌کند. کد خروجی ۰ به این معناست که فایل می‌تواند به تلاش‌های بعدی متصل شود، نه اینکه لزوماً عامل باگ را رفع کرده است یا اینکه یک جمع‌کننده راه دور (Remote Collector) دقیقاً همان بایت‌ها را دریافت کرده است.

پیاده‌سازی و آزمایش

نویسنده برای اطمینان از اینکه گیت صرفاً «تزئینی» نیست، پیشنهاد می‌کند یک فایل نمونه (Fixture) در کنار اسکریپت قرار گیرد. یک نمونه معتبر — که می‌تواند با دو بازه برای اثبات قوانین ریشه و ابزار، زیر سی خط باشد — باید عبارت shape_ok را چاپ کرده و با خروجی ۰ خارج شود.

آزمایش گیت شامل دو مرحله است:
۱. اجرای دستور python3 trace_shape.py fixture.json برای تایید موفقیت.
۲. حذف input.sha256 در یک کپی از فایل و انتظار دریافت کد خروجی ۲. اگر نسخه خراب همچنان خروجی ۰ بدهد، گیت تزئینی است و نباید پیش از هیچ فراخوانی مدلی قرار گیرد.

این سیستم تعمداً بررسی شکل را از بررسی محتوا جدا می‌کند. گیت فقط وجود فیلد هش را تایید می‌کند و آن را دوباره محاسبه نمی‌کند. محاسبه مجدد هش باید در یک اسکریپت جداگانه باشد تا تغییرات مربوط به سانسور یا پاک‌سازی داده‌ها (Redaction) با تغییر رفتار عامل اشتباه گرفته نشود.

پس از موفقیت، اسکریپت یک id_hash چاپ می‌کند که اثر انگشتی از شناسه‌های بازه به ترتیب قرارگیری در فایل است. این مقدار در لاگ‌های CI بسیار کاربردی است، هرچند اگر بازه‌ها به ترتیب متفاوتی مرتب شوند، تغییر می‌کند. مقایسه رفتاری (Behavioral Diff) مرحله دوم است که منتظر می‌ماند تا دو فایل هر دو از گیت عبور کنند؛ در این نقطه، نام‌ها، کدهای وضعیت و مقادیر input.sha256 مقایسه می‌شوند. نامی که فقط در فایل دوم وجود دارد، یک فراخوانی ابزار جدید است و هشی که تحت یک نام ابزار یکسان تغییر کرده، به معنای آرگومان جدید است.

چه زمانی گیت را نادیده بگیریم؟

این رویکرد جهانی نیست. نویسنده به چندین سناریو اشاره می‌کند که در آن‌ها این گیت محلی غیرضروری است:

• جمع‌کننده‌های موجود: اگر یک Collector راه دور از قبل همین طرح (Schema) را تحمیل می‌کند و عامل نمی‌تواند فایل محلی تولید کند، زیرا یک گیت دوم ضعیف‌تر، از گیت اول فاصله می‌گیرد (Drift می‌کند).
• ترافیک نمونه‌برداری شده: در محیط تولید، نمونه‌بردارانی (Samplers) که فرزندان ابزارها را حذف می‌کنند، باعث می‌شوند گیت اجراهایی را که عمداً کاهش حجم یافته‌اند، رد کند و ابزار ردیابی را مقصر تصمیم نمونه‌برداری بداند.
• اثبات تاییدیه: اگر کد خروجی ۰ به عنوان دلیلی بر درست بودن درخت کاری استفاده شود (یک ردپای خوش‌شکل همچنان می‌تواند یک ویرایش غلط را توصیف کند).
• فقدان هش‌ها: اگر سیستم قادر به نگهداری حتی یک هش از آرگومان‌های ابزار نباشد، زیرا آن هش یک کلید پیوند است که نیاز به مالک و قانون نگهداری دارد.

زمینه و افشا

این مقاله به عنوان بخشی از فعالیت‌های ترویجی محصول MonkeyCode تهیه شده است. در این زمینه، دسترسی رایگان به مدل‌ها تنها به عنوان بودجه‌ای دیده می‌شود که یک تلاش مجددِ بدون شکل (Shapeless Retry) آن را تلف می‌کند. گزینه سرور رایگان، هدف نهایی برای خروجی است، اما تنها پس از آنکه trace_shape.py روی یک فایل محلی تایید شده باشد؛ این کار تضمین می‌کند که تنظیمات جمع‌کننده و رفتار عامل در یک ساعت واحد عیب‌یابی نشوند.

هیچ نام مدل خاص، سهمیه (Quota)، اندازه سخت‌افزار یا دوره نگهداری داده‌ای ذکر نشده است، زیرا این موارد برای پیش‌نویس تایید نشده بودند. اگر یک سرور راه دور در دسترس نباشد، JSON محلی منبع اصلی رکورد باقی می‌ماند. این حلقه تعمداً کوتاه نگه داشته شده است: یک فایل JSON تولید شود، اسکریپت شکل اجرا شود و ابزار ردیابی تا زمانی که فایل خراب خروجی ۲ و فایل واقعی خروجی ۰ بدهد، اصلاح شود. سپس، و تنها در این صورت، هزینه یک فراخوانی مدل دیگر پرداخت شود.

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

گام بعدی شما

• بررسی کنید آیا در لاگ‌های فعلی عامل‌هایتان، شناسه‌های والد (Parent IDs) برای تمام مراحل ثبت می‌شوند یا خیر.
• یک اسکریپت ساده برای اعتبارسنجی ساختاری JSONهای خروجی قبل از ارسال به API مدل پیاده کنید تا از حلقه‌های تکرار بی‌هدف جلوگیری شود.
• از هش کردن ورودی‌های ابزارها برای شناسایی سریع تغییرات رفتاری مدل در نسخه‌های مختلف استفاده کنید.

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