استانداردِ عملیاتیِ توسعهٔ ایجنتی

قواعدی که هرکدام به شواهدِ منتشرشده متکی‌اند — قاعده‌ای بدون خطِ شاهد، نظر است نه قاعده

نسخه 2026-09-01 · ساخت: 2026-10-25 13:30 UTC

دامنه

خودمختاری تابعِ اثبات‌پذیری است، نه تابعِ هوشِ مدل. هر قاعدهٔ زیر یک کارِ ثابت می‌کند: ارزان‌ترکردنِ اثباتِ اینکه ایجنت خرابی نساخته.

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

هر قاعده سه بخش دارد: حکم، شاهد (با عدد و منبع)، و سنجه — یعنی چیزی که همین امروز می‌توانی اندازه بگیری تا بفهمی رعایتش می‌کنی یا نه.

قواعد

1اجرا در کد، نه در پرامپت

الزامی

حکم: هر محدودیتی که نقضش برایت هزینه دارد باید به‌شکلِ یک ولیدیتورِ کدی اجرا شود که خروجی را رد می‌کند — نه به‌شکلِ جمله‌ای در پرامپت. پرامپت جهت می‌دهد؛ کد تضمین می‌دهد.

شاهد: «From Prompts to Contracts» پنج قراردادِ صریح را در لایهٔ کد اجرا کرد: source-grounding، entity-routing، trace، output-hygiene و recommendation-language. با هارنس، ۱۲۰ از ۱۲۰ موردِ مفید سالم عبور کرد در برابر ۸۸ از ۱۲۰ برای گاردریلِ بیرونی؛ و ۲۷۰ اجرای مرزِ ترکیب روی سه مدلِ مختلف همگی پاس شدند — یعنی تضمین به مدل وابسته نبود. با پرامپت‌تنها، نقض‌ها تا خودِ خواننده می‌رسیدند.

arXiv:2607.08028

سنجه: چند درصد از قواعدت تستِ خودکارِ متناظر دارد؟ قاعدهٔ بی‌تست، قاعده نیست.

2فایلِ کانتکست = قرارداد اجرایی، نه توصیف‌نامه

الزامی

حکم: در AGENTS.md یا معادلش فقط چیزی بنویس که به یک دستورِ قابل‌اجرا یا یک شرطِ پذیرشِ قابل‌سنجش نگاشت می‌شود. متنِ توصیفیِ «معماریِ ما این‌طور است» را حذف کن.

شاهد: ارزیابیِ کنترل‌شدهٔ ETH Zürich روی SWE-bench و AGENTBENCH (۱۳۸ تسکِ واقعیِ پایتون): فایل‌های کانتکستِ سطحِ ریپو نرخِ موفقیت را به‌طور کلی بالا نبردند ولی به‌طور میانگین بیش از ۲۰٪ هزینهٔ inference اضافه کردند — هم برای فایلِ تولیدشده با LLM، هم فایلِ نوشتهٔ خودِ توسعه‌دهنده. تحلیلِ trace نشان داد ایجنت دستورها را دنبال می‌کند (بیشتر تست می‌زند، بیشتر فایل می‌خواند) ولی نتیجه عوض نمی‌شود.

arXiv:2602.11988

سنجه: هر خط از فایل کانتکست را به یک دستور یا یک تست نگاشت کن. هرچه نشد، پاک کن.

3برگشت‌پذیری را قبل از پذیرش تست کن، نه بعد از خرابی

الزامی

حکم: هیچ تغییری — حتی تغییری که معیارها را بهتر می‌کند — پذیرفته نشود مگر اینکه برگشت‌پذیری‌اش در حالتی غیر از حالتی که در آن ساخته شده تأیید شود.

شاهد: EvoUndo روی ۶۰۰ تسکِ خودتکاملیِ دیده‌نشده: ۱۹۷ جهشِ «بهبوددهنده» در تستِ برگشت‌پذیری رد شدند. راهبردهای معمولِ ترمیم صفر از ۱۹۷ را نتوانستند برگردانند. فقط با زبانِ بازیابیِ گسترده و تشخیصِ مبتنی بر آدرس‌دهیِ دقیقِ حالت، بازیابی به ۱۴۲ از ۱۴۳ (۹۹٫۳٪) در موارد پیچیده رسید. درسِ مقاله: امنیتِ خودتکاملی نیازمندِ هم‌طراحیِ راستی‌آزمایی، بازنماییِ حالت و مکانیزمِ بازیابی است — با prompting تکراری به دست نمی‌آید.

arXiv:2608.28363

سنجه: روی آخرین ده تغییر، بدترین حالت در چند ثانیه برمی‌گردد؟ و آیا در حالتِ دیگری هم تستش کردی؟

4هر ویرایشِ هارنس یک پیش‌بینیِ ابطال‌پذیر همراه داشته باشد

الزامی

حکم: پیش از هر تغییر در ابزار/پرامپت/حافظه، بنویس که انتظار داری چه متریکی چقدر عوض شود. دورِ بعد آن پیش‌بینی را با نتیجهٔ واقعی مقایسه کن. بدون این، انتساب ممکن نیست و داری کورکورانه تیون می‌کنی.

شاهد: AHE این را «decision observability» می‌نامد و هر ویرایش را به یک قراردادِ ابطال‌پذیر تبدیل می‌کند. نتیجه: ده تکرار، pass@1 روی Terminal-Bench 2 از ۶۹٫۷٪ به ۷۷٫۰٪ — بالاتر از هارنسِ انسان‌ساختهٔ Codex-CLI (۷۱٫۹٪) و بالاتر از ACE و TF-GRPO. روی SWE-bench-Verified بهترین نتیجهٔ تجمیعی با ۱۲٪ توکنِ کمتر. انتقال بین خانواده‌های مدل: ‎+۵٫۱ تا ‎+۱۰٫۱ واحدِ درصد.

arXiv:2604.25850

سنجه: می‌توانی بگویی کدام تغییرِ هارنس باعثِ کدام بهبود شد؟ اگر نه، هیچ‌کدام را نگه ندار.

5ابزارِ تأیید را با مُدِ شکست تطبیق بده، نه با تعداد

الزامی

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

شاهد: مطالعهٔ کنترل‌شده روی ۱٬۱۱۶ اپلیکیشنِ وب، شش مدل و هشت پیکربندیِ ابزار، با ارزیابِ انسانیِ ناآگاه از شرط: بدونِ ابزار، حدود یک از هر هفت اپ اصلاً بالا نمی‌آمد. یک پروبِ سادهٔ boot تقریباً همهٔ این شکست‌ها را حذف کرد با ۳۵٪ هزینهٔ یک shellِ کامل. shellِ کامل هزینهٔ توکن را ۲٫۳۵ برابر می‌کرد. اسکرین‌شات برای مسائلِ غیربصری (مثلاً اسکرولِ روان روی لیستِ ۱۰۰٬۰۰۰ ردیفی) هیچ ارزشی نداشت، و بهبودِ بصری‌اش هم بعد از تصحیحِ مقایسهٔ چندگانه از بین رفت.

arXiv:2608.28795

سنجه: برای هر ابزارِ تأیید بگو کدام مُدِ شکستِ واقعی را می‌گیرد. اگر نتوانستی، حذفش کن.

6وسطِ کار به عدم‌قطعیت اعتماد نکن؛ در پایان تصمیم بگیر

الزامی

حکم: دروازهٔ تصمیم را در پایانِ اجرا بگذار: یا بپذیر یا از نو اجرا کن. مداخلهٔ وسطِ مسیر بر پایهٔ confidence نساز.

شاهد: «Last Step Matters»: اعتمادِ کلامی در پایانِ تسک میانگین AUROC ‏۰٫۸۵ دارد ولی در نقطهٔ ۵۰٪ پیشرفت به زیرِ ۰٫۶۰ سقوط می‌کند. علتش path switching است — ایجنت مسیر را وسطِ کار عوض می‌کند و پیوندِ عدم‌قطعیتِ میانی با نتیجهٔ نهایی می‌شکند. در آزمایش، «از اعتمادِ گامِ آخر برای تصمیمِ ری‌استارت استفاده کن» از همهٔ مداخله‌های میانِ اجرا بهتر عمل کرد.

arXiv:2608.29685

سنجه: آیا منطقِ توقفِ زودهنگام داری؟ اگر بله، ثابت کن که از restartِ ساده بهتر است.

7ورودیِ ریپو را غیرقابل‌اعتماد فرض کن — نحوهٔ فراخوانی خودش سطحِ حمله است

الزامی

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

شاهد: بنچمارک CIPR با ۱٬۹۲۰ نمونه روی ۲۰ ریپوی مسموم: نوعِ تسک تا ۴٫۵ برابر تفاوت در نرخِ موفقیتِ حمله ایجاد می‌کند. تسکِ «اجرای تست» بدترین است — نرخِ موفقیتِ حملهٔ بالا با نرخِ هشدارِ پایین، یعنی سطحِ حملهٔ خاموش. پرامپتِ کم‌جزئیات ریسک را کم می‌کند (چون عمقِ اجرا را محدود می‌کند) و پرامپتِ شلوغ می‌تواند هشدارها را خفه کند. نتیجهٔ مقاله: آسیب‌پذیری خاصیتِ ثابتِ ایجنت نیست، برایندِ پیکربندیِ روزمرهٔ کاربر است.

arXiv:2608.30686

سنجه: آیا «اجرای تستِ کدِ ناشناخته» در سندباکسِ جدا و بدونِ اعتبارنامه انجام می‌شود؟

8تیونینگ را روی ابزار، middleware و حافظه بگذار — نه پرامپتِ سیستمی

توصیه

حکم: وقتی می‌خواهی کیفیت را بالا ببری، اول سراغِ تعریف و پیاده‌سازیِ ابزار، لایهٔ میانی و حافظهٔ بلندمدت برو. بازنویسیِ پرامپتِ سیستمی کم‌بازده‌ترین اهرم است.

شاهد: در ablationِ AHE، تمامِ بهبود روی اجزای tools، middleware و memory متمرکز بود، نه روی system prompt.

arXiv:2604.25850

سنجه: در ده تغییرِ اخیرت، چند تا پرامپت بود و چند تا ابزار؟ نسبت را برعکس کن.

9کانتکست را انتخاب کن، نه انباشت

توصیه

حکم: دادنِ «همهٔ لاگ‌ها» به ایجنت ضدِ هدف است. کانتکست باید انتخاب و لایه‌بندی شود: خلاصهٔ قابلِ drill-down، نه پیکرهٔ خام.

شاهد: Dex Horthy از تحلیلِ ۱۰۰٬۰۰۰ سشن مفهومِ «dumb zone» را استخراج کرد: میانهٔ ۴۰–۶۰٪ پنجرهٔ کانتکست که در آن recall افت می‌کند. «Measure Before You Manage» روی ۵۵ trajectory نشان داد بودجهٔ توکنِ برابر به معنای کانتکستِ تحویل‌شدهٔ برابر یا هزینهٔ مدیریتِ برابر نیست، و کالیبراسیون لزوماً به تسکِ دیده‌نشده منتقل نمی‌شود؛ ارزیابی باید در چهار سطح انجام شود: حالتِ ذخیره‌شده، کانتکستِ تحویل‌شده، کارِ مدیریت، و نتیجهٔ تسک. ACE هم دو آسیب را نام‌گذاری کرد: brevity bias و context collapse، با راه‌حلِ به‌روزرسانیِ delta موضعی به‌جای بازنویسیِ کامل.

arXiv:2608.31057arXiv:2510.0461812-Factor Agents

سنجه: کانتکستِ تحویل‌شده را بشمار، نه بودجهٔ توکن را.

10مرزِ خودمختاری را با نرخِ واقعیِ همان نوعِ تسک تعیین کن

الزامی

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

شاهد: DEPBENCH با ۲۰۳ تسکِ واقعیِ ارتقای وابستگی در پنج اکوسیستم: بهترین پیکربندی فقط ۱۰۴ از ۲۰۳ (۵۱٫۲٪) را حل کرد — یعنی برای نگهداریِ وابستگی، خودمختاریِ کامل هنوز زود است. در سطحِ صنعت هم شکافِ ادعا و واقعیت هست: Devin نرخِ merge را ۶۷٪ گزارش می‌کند (از ۳۴٪ در ۲۰۲۵) ولی تستِ مستقلِ Answer.AI روی ۲۰ تسکِ واقعی ۱۵٪ دید. تا میانهٔ ۲۰۲۶ همهٔ ایجنت‌های اصلی خروجی را از تأییدِ انسانی رد می‌کنند.

arXiv:2608.30300گزارش‌های مقایسه‌ای ۲۰۲۶

سنجه: برای هر نوعِ تسک، نرخِ موفقیتِ خودت را داری؟ اگر نه، خودمختاری نده.

11دستورالعمل و اسکریپتش را با هم نگه دار

توصیه

حکم: فایلِ زبانِ طبیعیِ یک skill و پیاده‌سازیِ اسکریپتی‌اش یک واحدِ نگهداری‌اند و باید با هم تغییر کنند و با هم ریویو شوند.

شاهد: مطالعهٔ تجربی روی ۱٬۹۲۶ ریپوی مارکت‌پلیسِ پلاگینِ Claude Code، ۸٬۳۵۱ پلاگین و ۷۷٬۷۷۳ کامیت: درونِ پوشهٔ skills، فایلِ دستورالعملِ زبانِ طبیعی و اسکریپتِ پیاده‌سازی با نرخی بالاتر از تصادف هم‌تغییر می‌کنند و ۷۸٪ این هم‌تغییرها از نظر عملکردی به هم وابسته‌اند — وابستگیِ نگهداری‌ای که در نرم‌افزارِ سنتی سابقه ندارد. ضمناً نرخِ کامیتِ feature بیش از دو برابرِ نرم‌افزارِ بازمتنِ متعارف است (۳۹٫۶٪ در برابر ۱۷٫۲٪) و Claude در ۳۴٫۹٪ کامیت‌ها هم‌نویسنده است.

arXiv:2608.28497

سنجه: آیا تغییرِ متنِ یک skill بدونِ بازبینیِ اسکریپتش merge می‌شود؟

12کارِ انسان را جلو ببر، نه عقب

توصیه

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

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

arXiv:2608.30701

سنجه: زمانِ انسانیِ صرف‌شده روی spec در برابر زمانِ صرف‌شده روی اصلاحِ کدِ ایجنت — نسبت باید بالای یک باشد.

13لاگِ اجرای ایجنت را دارایی حساب کن

توصیه

حکم: trajectory کاملِ ایجنت — پرامپت، استدلالِ میانی، فراخوانیِ ابزار، مصرفِ توکن — باید نگه داشته شود. این تنها پایهٔ ممکن برای eval، انتساب و تحلیلِ شکست است.

شاهد: AgentLogs از ایجنتِ ابریِ GitHub: ۳۰۷٬۴۱۶ تسک، ۵۴۹٬۲۳۹ سشن در ۳۵٬۸۱۰ ریپو، و ۶۴٬۲۵۵٬۱۷۴ رکوردِ لاگ — ساخته شده تا تحلیل از «ایجنت چه تحویل داد» به «ایجنت چطور کار کرد» منتقل شود. بدونِ این سطح از ثبت، مُدِ شکست قابلِ کشف نیست.

arXiv:2608.29204

سنجه: برای آخرین شکستِ ایجنت، می‌توانی trajectory کامل را بازخوانی کنی؟

ابزارهای معتبر به تفکیکِ کار

قرارداد و مشخصات (قبل از کد)

GitHub Spec Kitconstitution.md + requirements/design/tasks. سریع‌ترین رشدِ حوزه (~۱۱۵ هزار ستاره در ~۴ ماه). MIT.
AWS KiroSpecs با نُتاسیونِ EARS و سندِ طراحیِ خودتولید. وقتی می‌خواهی شرطِ پذیرش صوری باشد.
AGENTS.mdاستانداردِ باز و مشترکِ ابزارها — ولی طبق قاعدهٔ ۲ فقط محتوای اجرایی در آن بگذار.

اتصالِ ابزار و داده به ایجنت

MCPپروتکلِ استانداردِ اتصال. لایهٔ «دسترسی» — ولی طراحیِ مقاومِ خودِ ابزار کارِ توست.
Sentry MCP + Seerتله‌متریِ واقعیِ تولید را به ایجنتِ محلی وصل می‌کند؛ چرخهٔ investigate → fix → verify.

مالکیت — «هر فیچر یک مسئول»

GitHub Copilot coding agentissue را مستقیم به ایجنت اساین می‌کنی و PR می‌گیری. عملیاتی‌ترین شکلِ موجود.
الگوی Agent Registryهویتِ ایجنت، مالکیتِ سرویس، سقفِ توکن، و متریکِ cost-per-completed-task.

سنجش و مشاهده‌پذیری

OpenTelemetry — GenAI conventionsقراردادِ نام‌گذاریِ متریک و trace. اگر ایجنتت OTel نمی‌دهد، کور پرواز می‌کنی.
CloudWatch Coding Agent Insightsاز ۲۰ ژوئیهٔ ۲۰۲۶. داشبوردِ آمادهٔ OTel برای Claude Code / Codex / Copilot: مصرف، هزینه، latency، tool call، approval.
AgentLogs (دیتاست)۶۴ میلیون رکوردِ لاگ از ایجنتِ ابریِ GitHub — مرجعِ مقایسه‌ای برای اینکه بفهمی رفتارِ ایجنتت عادی است یا نه.

تکاملِ خودکارِ هارنس

AHEکدِ رسمیِ مقالهٔ ۲۶۰۴٫۲۵۸۵۰. حلقهٔ بستهٔ مشاهده‌پذیری‌محور با پیش‌بینیِ ابطال‌پذیر.
ACEGenerator/Reflector/Curator با به‌روزرسانیِ delta. ICLR 2026، بازمتن.

ارزیابی و بنچمارک

SWE-bench Verifiedمرجعِ عمومیِ رایج — ولی برای تصمیمِ خودمختاری کافی نیست.
DEPBENCH۲۰۳ تسکِ ارتقای وابستگی با شکستِ پنهان. بهترین نتیجه ۵۱٫۲٪.
AGENTBENCH (Gloaguen)۱۳۸ تسکِ واقعی از ریپوهای کمترشناخته‌شده — کمتر آلوده به دادهٔ آموزش.
CIPR۱٬۹۲۰ نمونه روی ۲۰ ریپوی مسموم — برای سنجشِ مقاومت در برابر مسمومیتِ ریپو.
RealSWEارزیابیِ ترکیبی زیرِ درخواست‌های واقعیِ کاربر، نه issueهای تمیزشده.

آنچه عمداً اینجا نیست

حذفِ آگاهانه، خودش بخشی از استاندارد است.