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

واحد رقابتی در دنیای عامل‌های کدنویسی دیگر حلقه‌ی استدلال نیست، بلکه سطح پلتفرمی است که آن را احاطه کرده است. طبق مطالعه‌ای که در ژوئیه ۲۰۲۶ توسط Wavestone AI Lab منتشر شد، صنعت به نقطه‌ای رسیده است که «هارنس» (Harness) — یعنی لایه‌ی ارکستراسیونی که ابزارها، حافظه و ایمنی را مدیریت می‌کند — محصول اصلی است و مدل زبانی بزرگ (LLM) تنها یک کالای مشترک و پیش‌فرض محسوب می‌شود.

این چرخش در حالی رخ می‌دهد که توسعه‌دهندگان از اسکریپت‌های آزمایشی به سمت ابزارهای سطح تولید (Production-grade) حرکت می‌کنند. همان‌طور که در تحلیل قبلی ما درباره‌ی فایل‌های AGENTS.md و جلوگیری از تخریب قوانین پروژه اشاره کردیم، این پژوهش نشان می‌دهد که صنعت در حال هم‌گرایی روی مجموعه‌ای از الگوهای معماری استاندارد برای مدیریت کدهای پیچیده است. این مطالعه با عنوان «مهندسی هارنس: کالبدشناسی، معماری و تکامل عامل‌های کدنویسی» (arXiv:2609.00006) توسط پل بارباست، تریستان داریگول، ژرمن وو و تام ویلتبرگر انجام شده است. این تیم پژوهشی حدود ۴ میلیون خط کد در زبان‌های پایتون، تایپ‌اسکریپت و راست را در ۱۱ سیستم مختلف تحلیل کرده است.

فرآیند پژوهش

این یک مطالعه توصیفی روی سورس‌کد بود، نه یک رقابت عملکردی. نویسندگان سیستم‌ها را بنچ‌مارک یا رتبه‌بندی نکردند، بلکه ۱۱ هارنس منتشر شده تا ژوئیه ۲۰۲۶ را بررسی کردند: Claude Code (آنتروپیک)، Codex CLI (اوپن‌ای‌آی)، Gemini CLI (گوگل)، Mistral Vibe (میسترال)، OpenHands، Aider، Mini-SWE-Agent، Hermes، Pi، OpenCode و OpenClaw. سیستم دوازدهمی به نام Omnigent (دیتابریکس) نیز به عنوان یک «متا-هارنس» تحلیل شد؛ لایه‌ای از ارکستراسیون که ۱۱ هارنس سازنده‌ی دیگر را پشت یک API واحد مدیریت و هدایت می‌کند.

به دلیل بازبینی هشت مورد از این سیستم‌ها نسبت به نسخه‌ی آوریل ۲۰۲۶ از همین مطالعه، پژوهشگران توانستند یک مقایسه‌ی کنترل‌شده‌ی ۹۰ روزه روی تغییرات کد (Source Diff) انجام دهند. این مقایسه از کدهای یکسان در فاصله سه ماه، منجر به شناسایی ۱۳ مشاهده‌ی جامع، ۲۹ الگوی طراحی تکرار شونده و ۱۸ توصیه طراحی شد. دو نکته برای درک زمینه ضروری است: نخست اینکه اکثر اعداد عملکردی توسط خود توسعه‌دهندگان گزارش شده و دوم اینکه مقاله با کمک قابل‌توجه Claude Code نوشته شده است، در حالی که خود این ابزار یکی از سیستم‌های مورد مطالعه بود.

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

پژوهشگران معادله‌ی عامل را این‌گونه تعریف می‌کنند: عامل = مدل + هارنس. هارنس شامل هر چیزی به جز مدل است؛ از حلقه‌ی عامل و مدیریت زمینه تا کنترل‌های ایمنی. بر اساس مستندات این مقاله، هر سیستمی، از مدل ساده‌ی ۱۰۰ خطی Mini-SWE-Agent تا غول پیچیده‌ی Claude Code، باید در مورد هفت زیرسیستم اصلی موضع بگیرد:

• حلقه‌ی عامل و یکپارچگی با LLM: چرخه اصلی اجرا.
• مدیریت حافظه و زمینه: نحوه یادآوری و فراموشی عامل.
• سیستم‌های ابزار و اکشن: قابلیت‌هایی که عامل می‌تواند فعال کند.
• ایمنی و مجوزها: مرزها و حفاظ‌ها (Guardrails).
• قابلیت گسترش: مهارت‌ها، هوک‌ها، پلاگین‌ها و پروتکل زمینه مدل (MCP).
• ارکستراسیون چندعاملی: نحوه هماهنگی بین چندین عامل.
• لایه‌های انتقال و کلاینت/سرور: زیرساخت ارتباطی.

حتی «عدم اتخاذ موضع» نیز یک انتخاب طراحی محسوب می‌شود. برای مثال، مطالعه نشان می‌دهد که Pi فاقد سندباکس (Sandbox) است؛ این یک نقص یا ویژگی فراموش‌شده نیست، بلکه یک اصل طراحی است که در مستندات خودش استدلال شده است. همین موضوع توضیح می‌دهد که چرا ابزارها با وجود استفاده از مدل‌های پیشرو یکسان، حس متفاوتی دارند: مدل مشترک است، اما هویت محصول در هارنس شکل می‌گیرد.

«غیاب‌های دوقلو» در سیستم‌های عملیاتی

یکی از تکان‌دهنده‌ترین یافته‌ها، غیبت کامل فریم‌ورک‌های عمومی عامل‌محور است. به‌رغم محبوبیت کتابخانه‌هایی مثل LangChain، LangGraph، AutoGen، CrewAI، LlamaIndex، Pydantic AI و Semantic Kernel، هیچ‌یک از ۱۱ سیستم عملیاتی تحلیل‌شده از آن‌ها استفاده نمی‌کنند. حتی Gemini CLI گوگل از فریم‌ورک‌های داخلی خودش یعنی Genkit و ADK دوری کرده است. هر حلقه با استفاده از ابزارهای بومی مثل asyncio در پایتون، Tokio در راست یا Promises در تایپ‌اسکریپت دست‌ساز شده است. هر رجیستری ابزار سفارشی است و هر قالب پرامپت، یک متن ساده Markdown یا الحاق رشته‌هاست.

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

• ripgrep برای جست‌وجوی سریع متن.
• tree-sitter برای تجزیه ساختار کد.
• glob برای تطبیق فایل‌ها.
• فایل‌های AGENTS.md برای شناسایی خودکار زمینه.

نویسندگان هفته‌ها به دنبال مثال نقض گشتند و حجم داده‌های مورد بررسی را سه برابر کردند، اما نتیجه تغییر نکرد. در حالی که OpenClaw از بردارها برای یادآوری چت استفاده می‌کند و Aider می‌تواند llama-index را برای اجرای تولید بازیابی‌افزا (RAG) روی مستنداتش نصب کند، هیچ‌کدام از آن‌ها در حلقه‌ی اصلی عامل برای خواندن کد از این روش‌ها استفاده نمی‌کنند. طنز ماجرا اینجاست که اصطلاح «مهندسی هارنس» ابتدا در LangChain تعریف شد، اما کتابخانه‌های آن در کد اجرایی این سیستم‌های عملیاتی جایی ندارند.

پیچیدگی در برابر عملکرد

این پژوهش فاش می‌کند که پیچیدگی معماری، پیش‌بینی‌کننده‌ی عملکرد عامل نیست. Mini-SWE-Agent که از یک حلقه‌ی خطی با حدود ۵۰ خط کد استفاده می‌کند، امتیاز بالای ۷۴٪ در SWE-Bench Verified گزارش کرده است. در مقابل، فضای کاری Codex CLI اوپن‌ای‌آی در یک فصل از ۶۲۱ هزار به ۱.۱۲ میلیون خط کد راست (Rust) رسید و تعداد کریت‌های (Crates) آن از ۸۹ به ۱۲۶ مورد افزایش یافت.

رشد Codex ناشی از خودِ حلقه نبود، بلکه به دلیل زیرساخت‌های پیرامونی بود: سندباکسینگ، خط لوله‌های تایید، مدیریت حافظه و بازار پلاگین‌ها. نتیجه این است که در حالی که یک حلقه‌ی ساده می‌تواند نمرات بالایی بگیرد، برای «آمادگی در سطح تولید» — به‌ویژه در زمینه‌ی ایمنی، قابلیت اطمینان و سطوح گسترش — به کدهای حجیم نیاز است. نویسندگان برای اثبات این موضوع، یک اسکلت پایتونی حدود ۹۰ خطی (Listing 3) ارائه کردند که یک حلقه‌ی خطی، چهار ابزار پایه (bash, read, write, search_replace) و فشرده‌سازی آستانه‌ای را پیاده می‌کند و لایه‌های پیچیده‌ی ارکستراسیون را که سازندگان فعلاً بر سر آن‌ها اختلاف دارند، حذف کرده است.

هم‌گرایی و «نیمه‌عمر» نوآوری

تا ژوئیه ۲۰۲۶، نفوذ سریع ویژگی‌ها بین سازندگان مشاهده شد. در نسخه‌ی آوریل، سیستم‌ها به‌صورت مستقل و از طریق بازکشف ویژگی‌ها به نتایج مشابه می‌رسیدند، اما در ژوئیه، این هم‌گرایی قابل ردیابی بود. Codex واژگان رویدادهای هوک Claude Code را عیناً پذیرفت و ابزاری برای وارد کردن جلسات و تنظیمات آن عرضه کرد. OpenHands نیز فرمت مانیفست پلاگین‌های Claude Code را به کار گرفت. پژوهشگران اشاره می‌کنند که «نیمه‌عمر» یک مزیت رقابتی در این حوزه اکنون با هفته‌ها اندازه‌گیری می‌شود.

دو استاندارد برنده ظاهر شده‌اند:

۱. SKILL.md: مورد استفاده در ۹ سیستم از ۱۱ مورد؛ این لایه مهارت‌ها زنجیره‌ای از رجیستری‌ها، سطوح اعتماد، تایید اصالت و کشف بین-سازنده‌ای ایجاد کرده است (مثلاً OpenCode می‌تواند دایرکتوری مهارت‌های Claude Code را بخواند).
۲. پروتکل کلاینت عامل (ACP): در ۶ سیستم فعال شده و اجازه می‌دهد OpenHands ابزارهایی مثل Claude Code، Codex یا Gemini CLI را به عنوان بک‌اندهای جایگزین اجرا کند.

پیامدهای عملی برای توسعه‌دهندگان

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

• Claude Code: وقتی بافر به زیر ۱۳ هزار توکن برسد، فشرده‌سازی را اجرا و سپس فایل‌ها را بازیابی می‌کند.
• Gemini CLI: در ۵۰٪ ظرفیت فشرده‌سازی می‌کند و ۳۰٪ آخر زمینه را عیناً نگه می‌دارد.
• Pi: در نقطه contextWindow - 16,384 فعال شده و ۲۰ هزار توکن اخیر را حفظ می‌کند.

علاوه بر این، تعداد ابزارها حیاتی است. مقاله پیشنهاد می‌کند که پس از حدود ۱۵ ابزار، حجم پرامپت بیش از حد زیاد (Prompt Bloat) می‌شود. سیستم‌ها سپس به «بارگذاری تاخیری» ابزارها روی می‌آورند؛ گزارش شده است که این قابلیت در Claude Code حجم پرامپت اولیه را حدود ۴۰٪ کاهش می‌دهد.

برای کسانی که عامل می‌سازند، نویسندگان ۱۸ توصیه در بخش ۱۶ ارائه کرده‌اند، از جمله:

• با یک حلقه‌ی خطی و یک ابزار bash شروع کنید؛ ابزارهای بیشتر را فقط در پاسخ به شکست‌های مشاهده‌شده اضافه کنید. این تغییر در رویکرد توسعه، مستقیماً با نیازهای بازار کار و مهارت‌های عملی مورد نیاز در آگهی‌های شغلی AI هم‌سو است که بر تسلط بر ابزارهای کاربردی تأکید دارند.
• فقط زمانی به سراغ خط لوله‌ی میان‌افزار (Middleware) بروید که سه یا بیشتر سیاست مستقل در هر نوبت داشته باشید.
• از ساخت RAG روی کد بپرهیزید؛ کد ساختاری قطعی دارد که شباهت معنایی نمی‌تواند جایگزین آن شود و سریع تغییر می‌کند.
• قوانین ایمنی را به‌جای کد، در قالب فایل‌های داده یا سیاست (Policy) بنویسید.
• تا زمانی که ایزولاسیون زمینه در حالت موازی بر جست‌وجوی متوالی برتری پیدا نکرد، تک‌عاملی بمانید.

بازرسی بازرسان

برای تایید دقت مطالعه، نویسندگان ادعاها را با مستندات محلی Pi مقایسه کردند. نتایج در مورد آستانه‌های فشرده‌سازی (reserveTokens: 16384, keepRecentTokens: 20k) و گام‌های خلاصه‌سازی تکراری که خلاصه‌ی قبلی را به عنوان زمینه می‌فرستد، کاملاً منطبق بود. همچنین وجود هوک session_before_compact که اجازه می‌دهد افزونه‌ها نتیجه‌ی فشرده‌سازی را وتو یا جایگزین کنند، به عنوان یک رویداد مستند تایید شد.

مهم‌تر از همه، مطالعه به‌درستی شناسایی کرد که Pi تنها سیستمی است که فقدان زیرساخت ایمنی را به‌عنوان یک انتخاب آگاهانه مستند کرده است. در فایل docs/security.md آمده است: «مشاهده ترنسکریپت، استفاده از اعتماد پروژه و بررسی تغییرات، یک مرز امنیتی ایجاد نمی‌کند.» این نشان می‌دهد حوزه از «افزودن ویژگی» به «برداشت‌های معماری آگاهانه» رسیده است.

محدودیت‌ها و جمع‌بندی

مقاله نسبت به محدودیت‌های خود محتاط است. این یک گزارش توصیفی است، نه رتبه‌بندی. اکثر اعداد عملکردی خود-گزارشی هستند و Claude Code از طریق یک اسنپ‌شات منتشر شده تحلیل شده است، نه مخزن عمومی. نویسندگان بین «ادعاهای موجودی» (مثل تعداد ابزارها) که در هفته‌ها منقضی می‌شوند و «ادعاهای ساختاری» (مثل تاکسونومی حلقه) که بادوام‌ترند، تفکیک قائل شده‌اند.

بزرگ‌ترین ادعای این مطالعه این است که عامل‌های کدنویسی در نیمه اول ۲۰۲۶ از «ابزار» به «پلتفرم» تبدیل شدند. شواهد در سورس‌کدهاست: هارنس‌هایی که به عنوان SDK عرضه می‌شوند، واردکننده‌های جلسات بین سازنده‌ای و متا-هارنس‌هایی که بک‌اندهای مختلف را جایگزین می‌کنند. همان‌طور که در مشاهده ۱۲ آمده است: «واحد رقابتی این حوزه دیگر حلقه‌ی عامل نیست؛ بلکه سطح اکوسیستم پیرامون آن است.»

گام بعدی شما

• اگر در حال ساخت عامل هستید، به‌جای تکیه بر فریم‌ورک‌های سنگین، با یک حلقه‌ی خطی ساده و ابزارهای قطعی (مثل ripgrep) شروع کنید.
• برای مدیریت پنجره زمینه، استراتژی‌های فشرده‌سازی (Compaction) را به‌جای حذف ساده‌ی توکن‌ها پیاده کنید.
• قوانین ایمنی و دسترسی‌ها را از بدنه کد جدا کرده و در فایل‌های پیکربندی یا Policy قرار دهید.

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