قابلیت اطمینان عامل هوش مصنوعی در تولید: پنج درس از پژوهش‌های این هفته

اکوسیستم سیستم‌های عامل‌محور — هفتهٔ ۱۴ تا ۱۸ سپتامبر ۲۰۲۶

مهم‌ترین پژوهش‌های این هفته دربارهٔ سیستم‌های عامل‌محور به ساختن یک عامل ابرتوانمند یا افزودن مدل بزرگ‌تر ختم نمی‌شوند؛ پیام مشترک آن‌ها دربارهٔ سیستم مهندسی پیرامون مدل است: مدیریت زمینه، راستی‌آزمایی مستقل، مشاهده‌پذیری، یادگیری کنترل‌شده و امکان بازگشت.

در مطالعات جدید دربارهٔ «چارچوب اجرای کدنویسی» (coding harness)، «راستی‌آزمایی تکمیل کار» (completion verification)، پروفایل‌سازی معنایی، به‌روزرسانی مهارت (skill) و رخدادهای «عدم‌هم‌راستایی» (misalignment)، یک الگو تکرار می‌شود. مدل توانمند ممکن است «زمینه» (context) مهم را از دست بدهد، خیلی زود موفقیت را اعلام کند، وارد حلقهٔ «بازیابی» (recovery) پرهزینه شود، از شکست درس اشتباه بگیرد یا دستور ناامن را به زمینهٔ بعدی منتقل کند.

نتیجهٔ عملی این است که قابلیت اطمینان عامل در محیط عملیاتی (production) بیش از آنکه مسئلهٔ «هوش بیشتر» باشد، مسئلهٔ کنترل سیستم است.

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

خلاصهٔ اجرایی

این اعداد فقط به محیط‌های آزمایشی گزارش‌شده مربوط‌اند و تضمین عمومی عملکرد نیستند.

۱. چارچوب اجرای کار، بخشی از توان واقعی مدل است

یک عامل تولیدی فقط یک مدل زبانی بزرگ (LLM) همراه ابزار نیست. چارچوب اجرا (harness) تعیین می‌کند مدل چه زمینه‌ای ببیند، چگونه برنامه‌ریزی کند، چه کنش‌هایی داشته باشد، چه زمانی متوقف شود و شکست چگونه به حلقه برگردد.

مقالهٔ An Empirical Study of Harness Design for Coding Agents حلقهٔ اجرا را ثابت نگه می‌دارد و سه چیز را جداگانه آزمایش می‌کند: برنامه‌ریزی، فهرست کارهایی که عامل اجازه دارد انجام دهد و مدیریت اطلاعاتی که مدل می‌بیند. نویسندگان ۱۷۶ حالت را روی چهار مدل و دو آزمون کدنویسی بررسی کرده‌اند.

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

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

۲. «عامل می‌گوید تمام شد» به‌معنای درست‌بودن نتیجه نیست

یکی از پرهزینه‌ترین خطاها «موفقیت کاذب» است: عامل می‌گوید کار تمام شده، اما فایل یا نتیجهٔ واقعی درست نیست، در مقصد ثبت نشده یا نیاز کسب‌وکار را برآورده نمی‌کند.

مطالعهٔ How Do Agent Harnesses Create Value? اطلاعات برنامه‌ریزی را از راستی‌آزمای جدا می‌کند. در ۲۶۵ سلول همتا، برنامهٔ ثابت، موفقیتِ تأییدشده با مرجع (oracle-verified) را ۷٫۱۷ واحد درصد بهتر کرد. راستی‌آزمای در Retail، ۶۱٪ مواردی را که مرجع نامعتبر دانسته بود رد کرد و ۱۷٪ نتیجهٔ درست را نیز رد کرد؛ هزینهٔ افزوده کمتر از یک سنت برای هر قسمت اجرا بود.

معماری درست سه نقش دارد: اجراکننده کار را انجام می‌دهد، راستی‌آزما نتیجه را بدون تغییر بررسی می‌کند و کنترل‌گر انتشار دربارهٔ تحویل، تلاش دوباره، ارجاع به انسان یا توقف تصمیم می‌گیرد:

ادعای عامل ← فایل یا نتیجهٔ تولیدشده ← بررسی خودکار ← شاهدِ ثبت‌شدن در مقصد ← نتیجهٔ واقعی کار

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

۳. ثبت جزئیات اجرا باید علت هزینه و خطا را نشان دهد

ثبت جزئیات یک اجرا نشان می‌دهد چه اتفاقی افتاده است؛ اما تیم عملیاتی باید بداند کدام بخش کار بیشترین زمان، مصرف متن و خطا را ایجاد می‌کند. AgentPProf فعالیت‌های مختلف را بر اساس مسئولیت واقعی‌شان دسته‌بندی می‌کند؛ مثلاً برنامه‌ریزی، استفاده از ابزار یا جبران خطا.

در ارزیابی گزارش‌شده، روش دسته‌بندی به امتیاز ۰٫۷۶۴ رسید، در برابر ۰٫۶۶۳ برای روش پایه. در ۴۴۰ مسیر اجرای وب، اجراهای شکست‌خورده ۴۴٫۶٪ گام‌ها را صرف جبران خطا کردند، در حالی که این مقدار برای اجراهای موفق ۱۲٫۰٪ بود. در یک اصلاح مبتنی بر همین تحلیل، مصرف متن ۱۹٪ کم شد، بدون اینکه کیفیت کار پایین بیاید.

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

۴. عامل باید از هر شکست، محدود و قابل‌کنترل یاد بگیرد

در SkillAA، کتابخانهٔ مهارت‌ها یک ساختار نسخه‌دار و به‌هم‌پیوسته است، نه انبوهی از دستورها. اگر عامل در بخشی از کار خطا کند، سیستم ابتدا بررسی می‌کند مشکل دقیقاً به کدام مهارت مربوط است؛ سپس فقط همان بخش را پیشنهاد می‌کند، نه اینکه همهٔ رفتار عامل را تغییر دهد.

با GPT-5.6-sol، اعداد گزارش‌شده ۸۱٫۵٪ در SearchQA، ۶۶٫۷٪ در LiveMath و ۹۱٫۲٪ در DocVQA بود. با این حال در ALFWorld، وقتی مشکل از جست‌وجو یا اجرای کار بود، تغییر مهارت کمکی نکرد و حتی می‌توانست عملکرد عامل را بدتر کند.

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

برای مدیریت skillهای قابل‌اعتماد، راهنمای curation برای MCP Agent Skills را ببینید.

۵. خلاصه‌سازی سابقه و خروجی ابزار، مرزهای اعتماد هستند

گزارش‌های Misalignment Notices and Reports نشان می‌دهند خلاصه‌ای که بدون قالب و کنترل ساخته شود، می‌تواند دستور ساختگی، پنهان‌کاری یا ادعای بی‌پشتوانه را به مرحلهٔ بعد منتقل کند. در یک گزارش، ۲۷ خلاصهٔ مشکوک با پایش هدفمند پیدا شد. در گزارشی دیگر، این رفتار در ۲٫۱۵٪ از خلاصه‌های یک آموزش تقویتی و ۰٫۲۷٪ از خلاصه‌های یک اجرای دیگر علامت‌گذاری شد.

چهار کنترل لازم است: خلاصه را «داده» بدانید، نه دستور؛ واقعیت‌های تأییدشده، کارهای انجام‌شده، شواهد، موارد حل‌نشده، خطاها و گام بعدی را جدا نگه دارید؛ دسترسی به حساب‌ها، بارگذاری عمومی، ارسال داده به شبکه و تغییر مخرب را بیرون از متن دستور کنترل کنید؛ و منبع هر ادعا را ثبت کنید.

نقشهٔ راه عملی تولید

۱. «موفقیت» را به شرایط روشن تبدیل کنید و فایل نهایی، نتیجهٔ آزمون، شناسهٔ مقصد و شاهد ثبت‌شدن نتیجه را نگه دارید.

۲. یک راستی‌آزمای فقط‌خواندنی را روی اجراهای قبلی آزمایش کنید و موفقیت‌های اشتباه و ردکردن‌های اشتباه را جداگانه اندازه بگیرید.

۳. زمینه و حافظه را ساختاریافته کنید؛ شواهد مهم را دست‌نخورده نگه دارید، مشاهدات قدیمی را کم‌کم حذف کنید و خلاصه‌ای را که منبع و اعتبار ندارد نپذیرید.

۴. مسیرهای اجرا را بر اساس نوع مسئولیت دسته‌بندی کنید و پیش از بهینه‌سازی، سه بخش پرهزینه و پرخطا را پیدا کنید.

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

چیزی که اول آزمایش می‌کنم

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

جمع‌بندی

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

مدل مهم است، اما در محیط عملیاتی فقط یکی از اجزای سامانه است. نتیجهٔ قابل‌اعتماد زمانی به دست می‌آید که مدل، ابزارها، بررسی نتیجه و قواعد ایمنی درست کنار هم کار کنند.

— تقی مولوی، معمار هوش مصنوعی | استراتژیست SEO و GEO

واژه‌نامهٔ اصطلاحات فنی

برای جلوگیری از ابهام، اصطلاحات انگلیسیِ باقی‌مانده در متن این معنا را دارند:

• عامل (Agent): سامانه‌ای که بر اساس هدف، وضعیت و ابزارها چند گام تصمیم می‌گیرد و اقدام می‌کند؛ صرفاً یک پاسخ متنی نیست.
• چارچوب اجرا (Harness): لایهٔ مهندسی اطراف مدل که زمینه، ابزارها، حلقهٔ اجرا، توقف، خطا و بازگشت را مدیریت می‌کند.
• زمینه (Context): اطلاعاتی که مدل در همان نوبت می‌بیند؛ مانند دستورها، پیام‌ها، فایل‌ها، نتایج ابزار و وضعیت کار.
• فشرده‌سازی زمینه (Compaction): تبدیل تاریخچهٔ طولانی به وضعیت کوتاه‌تر برای آزاد کردن ظرفیت ورودی مدل؛ اگر کنترل نشود ممکن است واقعیت و دستور با هم مخلوط شوند.
• راستی‌آزما (Verifier): بررسی‌کنندهٔ مستقلی که ادعای موفقیت عامل را با آزمون، فایل، نتیجه یا وضعیت مقصد مقایسه می‌کند.
• شاهد (Evidence): دادهٔ قابل بررسی برای اثبات نتیجه؛ مانند شناسهٔ مقصد، خروجی آزمون، تفاوت فایل یا پاسخ ثبت‌شدهٔ سامانهٔ بیرونی.
• قبول‌شدن (Acceptance): تصمیم رسمی برای اینکه نتیجهٔ کار شرایط لازم را برآورده کرده است؛ با سبزشدن اجرای عامل یکی نیست.
• برنامه‌ریزی (Planning): شکستن هدف به گام‌ها و تعیین ترتیب اقدام‌ها، ابزارها و معیار توقف.
• فضای کنش (Action space): مجموعهٔ اقدام‌هایی که عامل مجاز است انجام دهد؛ مانند خواندن فایل، اجرای دستور یا ارسال درخواست.
• ردپا (Trace): ثبت رویدادهای یک اجرای عامل، شامل ورودی، تصمیم، فراخوانی ابزار، زمان، هزینه و نتیجه.
• مسیر اجرا (Trajectory): دنبالهٔ کامل وضعیت‌ها و اقدام‌های عامل از شروع تا پایان یک کار.
• پروفایل‌ساز معنایی (Semantic profiler): ابزاری که هزینه و خطا را به مسئولیت واقعی کار، مانند برنامه‌ریزی یا بازیابی، نسبت می‌دهد.
• یادگیری مهارت (Skill update): افزودن یا اصلاح دستورالعملی که عامل برای کارهای بعدی استفاده می‌کند؛ این تغییر باید نسخه‌دار و آزمایش‌پذیر باشد.
• دروازهٔ رگرسیون (Regression gate): آزمونی که بررسی می‌کند تغییر جدید قابلیت‌های قبلی را خراب نکرده باشد.
• بازگشت نسخه (Rollback): برگرداندن سامانه یا مهارت به آخرین نسخهٔ سالم پس از مشاهدهٔ خطا.
• تلاش دوباره (Retry): اجرای مجدد یک گام پس از شکست؛ افزایش بی‌قاعدهٔ آن می‌تواند حلقهٔ پرهزینه بسازد.
• ارجاع (Escalation): سپردن مورد مشکوک یا پرریسک به انسان یا کنترل‌گر سطح بالاتر.
• مبدأ ادعا (Provenance): اطلاعاتی که نشان می‌دهد هر ادعا از کدام داده، ابزار یا منبع آمده است.
• خروجی شبکه (Network egress): ارسال داده از محیط عامل به بیرون؛ باید با مقصد، نوع داده و مجوز محدود شود.
• عدم‌هم‌راستایی (Misalignment): رفتاری که با هدف، سیاست یا محدودیت ایمنی مورد انتظار سامانه ناسازگار است.
• واحد پردازش توکن: واحدهای کوچک متن که مدل می‌خواند و تولید می‌کند؛ تعداد بیشتر معمولاً هزینه و زمان بیشتری دارد.

پرسش‌های متداول

مهم‌ترین کنترل برای یک عامل عملیاتی چیست؟

پذیرش بر اساس شاهد واقعی. جملهٔ خود عامل دربارهٔ پایان کار نباید مدرک محسوب شود؛ باید فایل نهایی، نتیجهٔ آزمون یا وضعیت مقصد بررسی شود.

آیا هر عامل به برنامه‌ریزی و حافظهٔ بلندمدت نیاز دارد؟

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

عامل چگونه باید از شکست یاد بگیرد؟

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

چرا خلاصه‌سازی سابقه می‌تواند خطرناک باشد؟

چون خلاصهٔ بدون قالب می‌تواند وضعیت واقعی را با دستور ساختگی یا ادعای بی‌پشتوانه مخلوط کند. خلاصه باید ساختاریافته باشد و منبع هر بخش را مشخص کند.

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

موفقیت‌های اشتباه، ردکردن‌های اشتباه راستی‌آزما، هزینهٔ هر نتیجهٔ تأییدشده، تعداد تلاش‌های دوباره، پرشدن ظرفیت اطلاعات، بخش‌های پرهزینه و پرخطا، خراب‌شدن قابلیت‌های قبلی و پذیرش نتیجه در مقصد.

منابع اصلی

۱. Fan, R.-Z. et al. (2026). An Empirical Study of Harness Design for Coding Agents.

۲. Zhang, Y., Xu, K., & Chen, Y. (2026). How Do Agent Harnesses Create Value? Planning Information and Release Control in Stateful LLM Agents.

۳. Zheng, Y. et al. (2026). AgentPProf: Semantic Profiler for Long Horizon AI Agents.

۴. Shang, Z., Ge, L.-Y., & Guo, L.-Z. (2026). SkillAA: Attribution-Guided Skill-Graph Updating with Targeted Validation and Rollback.

۵. OpenAI (2026). Misalignment Notices and Reports، شامل گزارش‌های مربوط به compaction summary، credential غیرمجاز و upload عمومی.