شکاف هارنس: دلیل اصلی شکست دموهای عامل‌های هوش مصنوعی در مقیاس واقعی

تصور کنید یک برنامه‌نویس هفته‌ها روی دموی یک عامل هوش مصنوعی کار کرده و همه‌چیز در محیط تست عالی است، اما به محض استقرار در دنیای واقعی، سیستم بدون هیچ هشداردهنده‌ای فرو می‌پاشد. این شکست معمولاً به دلیل ضعف در استدلال مدل نیست، بلکه نتیجه‌ی یک نقص ساختاری در «بسته‌بندی» یا همان هارنس (Harness) است. وقتی افراد می‌پرسند چرا یک عامل که در دموی اولیه بسیار جذاب به نظر می‌رسید در محیط عملیاتی از هم می‌پاشد، پاسخ اغلب در یک فرمول خاص نهفته است: «عامل = مدل × هارنس».

طبق تحلیل‌های فنی، اکثر توسعه‌دهندگان فعلاً عامل‌های «حلقه-باز» (Open-loop) می‌سازند. این سیستم‌ها دست به عمل می‌زنند — مثلاً یک فایل می‌نویسند، یک API را فراخوانی می‌کنند یا یک کامیت را ارسال می‌کنند — و سپس بدون بررسی نتیجه، به سراغ قدم بعدی می‌روند. در این ساختار، عامل نسبت به موفقیت یا شکست خود کاملاً بی‌خبر است. شما تنها زمانی متوجه باگ می‌شوید که یک انسان متوجه خرابی شود؛ اتفاقی که اغلب روزها پس از وقوع خطا رخ می‌دهد. این عامل‌ها تا زمانی که به‌طور خاموش کاری اشتباه را برای چندین روز تکرار کنند، بسیار تاثیرگذار و خیره‌کننده به نظر می‌رسند.

برای عبور از این وضعیت، صنعت در حال پذیرش یک معماری جدید است. در حالی که مدل‌هایی مثل Claude یا GPT استدلال خام را فراهم می‌کنند — که بخشی است قابل تعویض و رشدش طبق منحنی پیشرفتی است که توسعه‌دهنده کنترلی روی آن ندارد — این هارنس است که اهداف، حلقه‌ها، ابزارها، زمان‌بندی و منطق تلاش مجدد (Retry Logic) را مدیریت می‌کند. در واقع، نیاز به جایگزینی مهندسی پرامپت با محدودیت‌های اجرایی برای توقف بحران تکرارهای بی‌هدف است که در تحلیل‌های پیشین روی خطرات حلقه‌های تکرار نامحدود مورد بررسی قرار گرفت. همان‌طور که در بحث‌های گذشته‌ی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، هرچه لایه‌ی کنترل سخت‌گیرتر باشد، ریسک توهمات کاهش می‌یابد. در واقع، تمام مهندسیِ کلیدی که واقعاً اهمیت دارد در هارنس اتفاق می‌افتد، نه در مدل.

کالبدشناسی یک هارنس حلقه-بسته

بزرگ‌ترین اشتباه تیم‌های فنی این است که هارنس را صرفاً «لوله‌کشی» (اهداف + حلقه‌ها + ابزارها) می‌بینند و نظارت (Observability) و ارزیابی‌ها (Evals) را به‌عنوان QA بیرونی به آن می‌چسبانند. این موارد اغلب به‌عنوان ابزارهایی تلقی می‌شوند که پس از اجرای عامل و از بیرون به آن اشاره می‌کنند. اما در واقعیت، لایه‌ی ارزیابی و لایه‌ی ردیابی (Trace) باید در درون خودِ هارنس قرار گیرند. این دو لایه، همان نیمی از عامل هستند که یک حلقه-باز را به یک حلقه-بسته تبدیل می‌کنند.

یک هارنس مستحکم طبق این رویکرد به این صورت گسترش می‌یابد: «هارنس = اهداف + حلقه‌ها + ابزارها + لنز + ارزیابی‌ها». بر اساس مستندات فنی، سه مورد اول (اهداف، حلقه‌ها و ابزارها) اجازه عمل به عامل می‌دهند، در حالی که دو مورد آخر (لنز و ارزیابی‌ها) به عامل اجازه می‌دهند بفهمد که آیا آن عمل درست بوده است یا خیر. این تنها مکانیزمی است که یک عامل را از وضعیتی که «صرفاً اجرا می‌شود» به وضعیتی که «بهبود می‌یابد» ارتقا می‌دهد. این ارتقا نیازمند زیرساختی است که در آن مستندات برای ماشین‌ها به عنوان شرط لازم برای بهره‌وری ابزارها تعریف شده باشند.

برای رسیدن به این ساختار، دو لایه‌ی विशिष्ट باید ادغام شوند:

• لنز (Observability): این لایه هر فراخوانی مدل و هر گام ابزار را ثبت می‌کند، از جمله ورودی‌های پردازش شده (Resolved Inputs) و خروجی‌های خام. با ثبت این موارد، یک «اجرا» (Run) هرگز به یک «جعبه سیاه» تبدیل نمی‌شود. لنز دقیقاً به شما می‌گوید که عامل چه کاری انجام داده است.
• ارزیابی‌ها (Evals): در این لایه، خروجی بر اساس یک استاندارد با استفاده از بررسی‌های قطعی (Deterministic)، اعتبارسنجی قراردادها یا منطق «مدل-به‌مثابه-داور» (Model-as-a-Judge) امتیازدهی می‌شود. ارزیابی‌ها به شما می‌گویند که آیا آن عمل «خوب» بوده است یا خیر.

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

درس‌هایی از یک کرش سیستمی

خطرناک‌ترین حالت زمانی است که عامل‌های زمان‌بندی‌شده به‌صورت Workerهای پس‌زمینه روی cron اجرا شوند. هر یک از این‌ها وظیفه‌ای متمرکز را در یک تایمر و در یک Session ایزوله انجام می‌دهند که پردازش اصلی نمی‌تواند به‌صورت زنده آن را زیر نظر بگیرد. در یک سیستم حلقه-باز، اگر یکی از این Workerها در حین اجرا کرش کند، یک فاجعه خاموش رخ می‌دهد: کارگر می‌میرد، هیچ خروجی‌ای تولید نمی‌کند و هیچ ردی از خود به جا نمی‌گذارد. این دقیقاً همان دردی است که باعث می‌شود برخی عامل‌ها یک هفته «غیب» شوند و هیچ‌کس متوجه نشود.

ادغام لایه‌های لنز و ارزیابی، این «سیاه‌چاله» را به یک نقص قابل ردیابی تبدیل می‌کند. این کار از طریق دو مکانیسم صورت می‌گیرد:

• ثبت اول-پایه (Stub-First Recording): لنز از Worker می‌خواهد که بلافاصله پس از شروع و پیش از انجام هرگونه کار واقعی، ترانسکریپت (نسخه ثبت‌شده) خود را بنویسد. این کار یک رکورد با وضعیت Outcome: IN-PROGRESS ایجاد می‌کند. حتی اگر Worker یک ثانیه بعد بمیرد، ردپایی به جا گذاشته است. شکست دیگر نامرئی نیست؛ یک ترانسکریپت منجمد در میانه مسیر وجود دارد که می‌گوید: «من شروع کردم و هرگز تمام نشدم».
• اعتبارسنجی قرارداد نسخه‌دار: لایه‌ی ارزیابی، ترانسکریپت‌های Worker را با یک قرارداد نسخه‌دار (Versioned Contract) بررسی می‌کند. در حالی که یک پیش‌نویس IN-PROGRESS در حالت عادی پذیرفته است، اما در حالت «پایان اجرا» (Finished mode) به عنوان یک خطای سخت (Hard Error) علامت‌گذاری می‌شود.

تفاوت منطقی به این شکل است:

• حالت عادی: agent-eval validate transcripts/ (پیش‌نویس‌های ناتمام پذیرفته‌اند)
• حالت پایان: agent-eval validate transcripts/ --finished (هر IN-PROGRESS باقی‌مانده، خطای سخت است)

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

حل پارادوکس «کارگر مرده»

تشخیص شکست تنها نیمی از راه است (مشاهده + ارزیابی)؛ سیستم باید سپس آن را اصلاح کند. یک راهکار ساده‌لوحانه، اضافه کردن بلوک finally است تا Worker در هنگام کرش، ترانسکریپت خود را نهایی کند. اما این از نظر منطقی غیرممکن است؛ زیرا در یک Session ایزوله، وقتی Worker می‌میرد، همان پردازشی که مسئول اجرای بلوک finally است، نابود شده است. شما نمی‌توانید از یک کارگر مرده بخواهید محیط را تمیز کند.

برای بستن حلقه اصلاح، راهکار باید خارج از Worker و به‌عنوان یک حلقه کوچک مجزا پیاده شود. این مورد به‌عنوان یک «جاروب‌کننده» (Sweeper) پیاده‌سازی می‌شود؛ یک پردازش نظافتی زمان‌بندی‌شده که به‌دنبال ترانسکریپت‌هایی می‌گردد که روی IN-PROGRESS گیر کرده‌اند و زمان اجرایشان به‌طور اثباتی به پایان رسیده است.

مکانیسم جاروب‌کننده

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

• منطق: برای هر ترانسکریپت با علامت IN-PROGRESS اگر عمر گزارش > حداکثر زمان اجرا + حاشیه امنیت باشد، آن اجرا به‌طور اثباتی مرده است.
• اقدام: یک بازنویسی انجام می‌دهد: Outcome -> "fail (auto-finalized: abandoned mid-run)".

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

خود-اصلاحی در برابر خود-بهبودی

بسیار حیاتی است که بین سیستمی که «خط قرمز» را حفظ می‌کند و سیستمی که «خط قرمز» را جابه‌جا می‌کند، تمایز قائل شویم. یک هارنس خود-اصلاح‌گر (Self-correcting) سیستمی است که در آن حلقه بسته شده است: سیستم انحرافات را از استانداردهای تعیین‌شده توسط انسان شناسایی کرده و آن‌ها را بدون دخالت انسانی تعمیر می‌کند. این حداقل‌ترین سطح نیاز (Floor) برای هر ناوگان عامل‌محور است.

در مقابل، سیستم‌های خود-بهبودبخش (Self-improving) خط معیار را به‌تنهایی بالا می‌برند. این امر شامل مواردی است که سیستم متوجه شود یک بررسی دارای مثبت-کاذب (False Positive) است و خودش معیار را سخت‌تر کند، یا متوجه شود یک Worker دچار پس‌رفت (Regression) شده و دستورالعمل‌های آن Worker را تغییر دهد. این رویکرد به‌شدت ریسکی است. اگر موردِ داوری و داور، هر دو در یک سیستم بسته بدون یک لنگر خارجی باشند، عبارت «از ارزیابی‌های خودش عبور کرده» دیگر هیچ معنایی نخواهد داشت.

بنابراین، خود-اصلاحی در چارچوب یک قرارداد انسانی، نسخه سالم است. تغییر خودکارِ قرارداد نیاز به حفاظ‌های سخت (Guardrails) و یک درگاه انسانی دارد. در حال حاضر، حلقه‌ها خودکار اجرا می‌شوند، اما طراحی این حلقه‌ها باید توسط انسان باشد.

ابزارهای پیاده‌سازی

برای توسعه‌کنندگانی که این الگوها را پیاده می‌کنند، لایه‌های لنز و ارزیابی را می‌توان در دو ابزار دید که به‌عنوان یک واحد عمل می‌کنند:

• agent-eval: چارچوب ارزیابی که خروجی‌ها را از طریق اعتبارسنجی قرارداد، تشخیص رانش (Drift)، بررسی توهم و تحلیل تازگی (Staleness) امتیازدهی و درگاه‌گذاری می‌کند. این ابزار می‌گوید «که» چیزی خراب شده است.
• AgentLens: لایه ردیابی که هر گام مدل و ابزار، ورودی‌های پردازش شده و خروجی‌های خام را ثبت می‌کند. این ابزار می‌گوید «چرا» خرابی رخ داده و سیگنال ارزیابی را قابل دیباگ می‌کند.

این دو ابزار با هم عرضه می‌شوند چون دو نیمه از یک حلقه بازخورد هستند. نتیجه نهایی روشن است: اگر ارزیابی‌ها و ردیابی‌های شما گهگاه و از بیرون اجرا می‌شوند، شما یک عامل حلقه-باز با چند اسکریپت QA دارید. ارتقای واقعی، قرار دادن لنز و ارزیابی‌ها درون هارنس است تا روی هر اقدام اجرا شوند. مدل‌ها خودبه‌خود پیشرفت می‌کنند، اما پیشرفت عامل شما کاملاً به این بستگی دارد که آیا حلقه هارنس را بسته‌اید یا خیر.

گام بعدی شما

• بررسی کنید آیا سیستم نظارت شما (Observability) در لحظه اجرا فعال است یا فقط لاگ‌های پس از حادثه را می‌خوانید.
• پیاده‌سازی یک مکانیسم «ثبت اول-پایه» (Stub-First) برای شناسایی Workerهای متوقف‌شده در پس‌زمینه.
• تفکیک دقیق لایه‌ی ارزیابی (که می‌گوید چه چیزی غلط است) از لایه‌ی ردیابی (که می‌گوید چرا غلط است).

این معماری تنها برای پایداری است؛ اما برای افزایش هوش عامل‌ها، باید به سراغ استراتژی‌های زنجیره تفکر پیشرفته‌تر برویم که در تحلیل‌های آتی بررسی خواهیم کرد.