رسیدهای اجرایی؛ راهکاری برای پایان جعبه‌سیاه بودن عامل‌های هوش مصنوعی

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

این رویکرد در واقع پاسخی به چالش‌های گذار مدل‌های زبانی به سوی اتوماسیون پیچیده است که در آن مدل‌ها از تولید متن ساده به سمت اجرای عملیات واقعی حرکت کرده‌اند.

طبق این گزارش، اکثر تیم‌ها شکست‌های عامل را در یک دسته‌بندی کلی یعنی «اشتباه مدل» قرار می‌دهند، در حالی که واقعیت بسیار تکه‌تکه‌تر است. شکست‌ها می‌توانند ناشی از خطای موقت یک ابزار، آرگومان‌های ناقص مدل، یا نقض قوانین کسب‌وکار باشند، حتی اگر خروجی در ظاهر درست به نظر برسد. موارد دیگر شامل پنجره‌های متنی (Context Window) — مثل میز کاری که جا برای چند ورق دارد، نه برای کل کتابخانه — قدیمی یا بیش از حد بزرگ است. همچنین ممکن است فرآیندی به دلیل سیاست تلاش مجدد، دو بار خاتمه یابد. بدون داده‌های ساختاریافته، تمام این دلایل در یک لاگ استاندارد یکسان به نظر می‌رسند و اپراتور نمی‌داند باید پرامپت را اصلاح کند، آداپتور ابزار را تغییر دهد یا سیاست تلاش مجدد (Retry Policy) را بازنگری کند.

همان‌طور که در تحلیل قبلی ما درباره‌ی بهینه‌سازی سرعت استنتاج در Jevlike اشاره کردیم، اکنون تمرکز از «سرعت اجرا» به «مشاهده‌پذیری منطق» تغییر یافته است. تصور کنید یک تراکنش بانکی انجام می‌دهید؛ شما فقط نمی‌خواهید پول برسد، بلکه رسیدی می‌خواهید که ثابت کند تراکنش رخ داده و کارمزدهای آن را لیست کند. اعمال این منطق روی مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — به معنای تبدیل هر اجرا به یک تراکنش کوچک و قابل ردیابی است. این رویکرد همچنین در مورد ثبت تلاش‌ها بدون از دست دادن زمینه (Context) و تست جریان‌های ایمیلی بر اساس محیط اجرا کاربرد دارد؛ جایی که یک تسک زمانی ارزشمندتر است که سیگنال‌های قابل تفسیر از خود به جای بگذارد. این متدولوژی دقیقاً همان چیزی است که در معماری جدید ثبت لاگ برای جایگزینی داده‌های مبهم مورد بحث قرار گرفت تا شکاف عیب‌یابی در فراخوانی ابزارها پر شود.

کالبدشناسی یک رسید اجرا

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

برای پیاده‌سازی این سیستم، مدل ساختاریافته‌ای به نام RunReceipt پیشنهاد شده است:

• runId: یک شناسه ثابت که از اولین رویداد اختصاص می‌یابد.
• workflow: جریان اتوماسیون خاصی که در حال اجراست.
• instructionVersion: ردیابی اینکه کدام نسخه از پرامپت فعال بوده است.
• startedAt: برچسب زمانی شروع اجرا.
• steps: آرایه‌ای شامل نام ابزار، هش ورودی (برای حفظ محرمانگی)، وضعیت (موفق/تلاش مجدد/شکست)، مدت زمان به میلی‌ثانیه، یک ارجاع اختیاری به خروجی (output reference) و کد خطا.
• finalStatus: دسته‌بندی شده به عنوان تکمیل‌شده، مسدودشده یا شکست‌خورده.

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

قراردادهای ابزار و توکار بودن (Idempotency)

مشاهده‌پذیری مؤثر نیازمند مرزی سخت بین تصمیم عامل و اثر واقعی است. معماری پیشنهادی از چهار لایه تشکیل شده است: عامل تصمیم می‌گیرد، ارکستراتور اعتبارسنجی می‌کند، آداپتور (Adapter) — لایه‌ای که مدل را به ابزار خارجی وصل می‌کند — اجرا می‌کند و رسید ثبت می‌نماید. اگر آداپتور مستقیماً در یک لاگ عمومی بنویسد، مرز بین تصمیم و اثر از بین می‌رود. اگر ارکستراتور بعد از نوشتن در لاگ اعتبارسنجی کند، تلاش‌های مجدد می‌توانند باعث ایجاد داده‌های تکراری شوند.

هر ابزار باید پیش از اجرا، قراردادی را اعلام کند که شامل سه مورد باشد:

• پیش‌شرط‌ها: الزاماتی مثل شناسه مشتری برای ابزار ایجاد تسک.
• فرم موفقیت: خروجی مورد انتظار، مانند یک ID ایجاد شده.
• خطاهای قابل تلاش: شکست‌های خاصی مثل Timeout که تکرار تلاش را توجیه می‌کند.

خطاهای اعتبارسنجی نباید وارد مدار تلاش مجدد (Retry Circuit) شوند. برای جلوگیری از داده‌های تکراری، سیستم از یک کلید Idempotency استفاده می‌کند که از ترکیب runId و نام عملیات ساخته شده است. آداپتور این کلید را به سرویس ارسال می‌کند و باعث می‌شود تلاش مجدد، یک تداوم کنترل‌شده باشد، نه یک سفارش جدید و کورکورانه.

بودجه‌بندی و نگهداری

برای جلوگیری از حلقه‌های بی‌نهایت و هزینه‌های سرسام‌آور، سیستم باید یک بودجه صریح را اعمال کند. این بودجه شامل محدودیت در تعداد تلاش‌ها، زمان کل اجرا، تعداد فراخوانی هر ابزار و هزینه تخمینی توکن (Token) — تکه‌های کوچکی از متن که مدل تکه‌تکه می‌خورد — است. وقتی بودجه تمام شود، رسید باید دلیل دقیقی ذکر کند (مثلاً: «دو مورد Timeout در send_email و اتمام بودجه») به جای یک پیام خطای کلی.

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

در نهایت، سیاست نگهداری (Retention Policy) حیاتی است. نگهداری ابدی تمام رسیدها ریسک امنیتی و هزینه ذخیره‌سازی را بالا می‌برد، در حالی که حذف زودهنگام، بررسی حوادث را غیرممکن می‌کند. توسعه‌دهندگان باید بازه‌ای را بر اساس اثر جریان کاری انتخاب کرده و محتوای حساس را حذف کنند در حالی که معیارهای کلی (Aggregate Metrics) را حفظ نمایند.

گام بعدی شما

برای تبدیل یک جعبه‌سیاه به یک سیستم قابل نگهداری، این چک‌لیست توصیه می‌شود:

• برای هر رویداد از ابتدا یک runId ثابت اختصاص دهید.
• تمام دستورالعمل‌ها و طرح‌واره‌های (Schemas) ابزارها را نسخه‌بندی کنید.
• برای ورودی‌های حاوی داده‌های خصوصی از هش (Hash) استفاده کنید.
• تفاوت بین خطاهای «قابل تلاش مجدد» و «قطعی» را در سیستم تعریف کنید.
• برای تمام ابزارهایی که اثر خارجی دارند، قابلیت Idempotency را پیاده کنید.
• مدت زمان، وضعیت و ارجاعات خروجی را برای هر گام ثبت کنید.
• محدودیت‌های صریح برای زمان، تعداد فراخوانی‌ها و هزینه تعریف کنید.
• یک تست ایجاد کنید که عمداً باعث Timeout شود تا صحت ثبت رسید را بررسی کنید.

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