تیم‌های ۲۶۴ نفرهٔ مجازی؛ چرا تعداد زیاد عامل‌های هوش مصنوعی کیفیت کد را می‌کاهد؟

تصور کنید برای نوشتن یک قطعه کد ساده، ۲۶۴ متخصص مجازی را دور یک میز جمع کنید؛ نتیجه احتمالاً هرج‌ومرج است، نه دقت. داشتن یک تیم عظیم از عامل‌های تخصصی، هرگز تضمین‌کنندهٔ تولید نرم‌افزار بهتر نیست.

در ۹ سپتامبر ۲۰۲۶، بررسی فنی مخزن Agency Agents — که حدود ۱۵۱,۰۰۰ ستاره در گیت‌هاب دارد — فاش کرد که ارزش سامانه‌های چندعاملی در انتخاب دقیق نقش‌هاست، نه تعداد آن‌ها. بسیاری از توسعه‌ده‌دهندگان اکنون در تلهٔ «بیشتر، بهتر است» افتاده‌اند. آن‌ها تصور می‌کنند شبیه‌سازی ساختار سازمانی شرکت‌ها با ده‌ها شخصیت هوش مصنوعی، صحت خروجی را بالا می‌برد. اما در واقعیت، این رویکرد اغلب منجر به پر شدن پنجرهٔ زمینه (Context Window) — شبیه میز کاری که جا برای چند ورق دارد، نه کل کتابخانه — و بروز «اشتباهات پذیرفتنی» (Plausible Mistakes) می‌شود که در طول زنجیره تکثیر شده و در نهایت خروجی را تخریب می‌کنند. این چالش‌ها در حالی رخ می‌دهد که عامل‌های هوش مصنوعی به‌طور کلی تمرکز صنعت را از تولید محتوا به سمت اجرای هدفمند وظایف تغییر داده‌اند.

زمینه و بررسی منبع

این تحلیل بر اساس بررسی کد در کامیت 6d29a9b انجام شده است. بازرسی‌های صورت گرفته شامل فایل‌های مربوط به نقش‌ها، نصب‌کننده (Installer)، مبدل (Converter)، قوانین مشارکت و بررسی‌های جاری گیت‌هاب بوده است. لازم به ذکر است که این بررسی تمام یکپارچه‌سازی‌ها یا اپلیکیشن دسکتاپ را ارزیابی نکرده است.

به نقل از بررسی منتشر شده توسط Software Sausage، پروژه Agency Agents یک کتابخانه توانمند با مجوز MIT است که نقش‌ها را برای ابزارهایی مثل Claude Code، Cursor، Gemini CLI، Codex، OpenCode، Qwen Code و Aider تبدیل می‌کند. با این حال، مستندات خود پروژه هشدار می‌دهد که برخی یکپارچه‌سازی‌ها، مانند OpenCode، تنها حدود ۱۱۹ عامل را ثبت می‌کنند و توصیه می‌شود کاربران تنها زیرمجموعه‌ای از این عامل‌ها را نصب کنند. در همین راستا، ابزارهای جدیدی مانند گوگل ADK امکان ساخت عامل‌های هوش مصنوعی را با بهره‌گیری از Golang فراهم کرده‌اند تا توسعه‌دهندگان کنترل بیشتری بر ساختار عامل‌ها داشته باشند.

معماری عامل‌های مؤثر

برای جلوگیری از نقش‌های «تزئینی»، این بررسی یک قانون طراحی سخت‌گیرانه پیشنهاد می‌کند: هر عامل (Agent) — مثل کارمندی که فقط یک وظیفه مشخص دارد و از دایره کاری‌اش خارج نمی‌شود — باید تخصص محدود، رفتار متمایز و معیارهای موفقیت قابل اندازه‌گیری داشته باشد. راهنمای مشارکت پروژه صراحتاً نسخه‌های تکراری یا تغییر ظاهر (Re-skins) نقش‌های موجود را رد می‌کند. اگر دو نقش خروجی یکسانی تولید کنند یا خروجی یک نقش هرگز توسط بخش دیگری مصرف نشود، آن نقش باید حذف گردد.

تعاریف موثر برای عامل‌ها نباید صرفاً یک خط توصیف یا شخصیت‌پردازی باشند، بلکه باید به طور صریح موارد زیر را نام ببرند:

• خروجی‌های مورد انتظار (Deliverables)
• گردش‌کارهای اجرایی (Workflows)
• محدودیت‌ها (Constraints)
• معیارهای موفقیت (Success Metrics)

برای تغییرات نرم‌افزاری، نویسنده یک کیت سه-عاملیِ بهینه و سبک پیشنهاد می‌دهد:

• مهندس تغییرات حداقلی: یک نتیجه مشخص، استثنائات صریح و فایل‌های مجاز را دریافت می‌کند. او کد می‌نویسد اما اجازه استقرار (Deploy) ندارد.
• بازبین کد: عاملی فقط-خواندنی است که تسک، تفاوت‌ها (Diff) و لاگ‌های بررسی را دریافت می‌کند. این عامل باید مسدودکننده‌ها (Blockers)، پیشنهادات و نکات جزئی (Nits) را از هم تفکیک کند.
• حسابرس امنیتی کد تولید شده توسط AI: شواهد و مرزهای اعتماد را دریافت می‌کند. این عامل از بررسی‌های محلی فقط-خواندنی برای ثبت شواهد هر یافته استفاده می‌کند.

در این گردش‌کار، اجراکننده حداکثر دو فرصت اصلاح دارد و سپس یک انسان باید یافته‌ها را حل کرده و اثبات‌های جدید از زمان اجرا (Runtime Proof) را ثبت کند.

اثبات ارزش ارکستراسیون

برای تعیین اینکه آیا ارکستراسیون چندعاملی واقعاً کمک می‌کند یا خیر، نویسنده توصیه می‌کند یک تست رودررو (Head-to-head) انجام دهید: یک تسک قابل بازنشانی (Resettable) را ثابت کنید و یک عامل توانمند را در برابر گروهی رقیب که حداکثر سه نقش دارد، قرار دهید.

قبل از اجرا، شما باید آستانه‌هایی (Thresholds) برای موارد زیر تعیین کنید:

• صحت و ایمنی
• هزینه و تأخیر (Latency)
• میزان مداخله و حریم خصوصی

نکته کلیدی این است که نقش‌های رقیب باید خلاصه‌ها و وضعیت‌های ساختاریافته (Structured State) را رد و بدل کنند، نه کل تاریخچه گفتگوهای انباشته شده را؛ تا از رشد بی‌رویه پنجره متنی جلوگیری شود. این رویکرد دقیقاً از توصیه‌های معمار سامانه‌های چندعاملی در این مخزن پیروی می‌کند. برنده این رقابت توسط یک تاییدکننده قطعی (Deterministic Verifier) و یک دستورالعمل ارزیابی کور (Blind Rubric) تعیین می‌شود.

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

در نهایت، کارایی پشته هوش مصنوعی شما به انسانی بستگی دارد که در مرز تصمیمات برگشت‌ناپذیر قرار گرفته است. هدف این است که دسترسی‌ها مجزا بمانند و تعداد تلاش‌های مجدد (Retries) محدود شود تا از حلقه‌های بی‌نهایتِ «موافقتِ هوش مصنوعی با یکدیگر» جلوگیری شود.

گام بعدی شما

• نقش‌های تکراری را از گردش‌کارهای عامل‌محور خود حذف کنید و روی تخصص‌های محدود تمرکز کنید.
• برای هر عامل، معیارهای موفقیت (Success Metrics) مکتوب تعریف کنید تا خروجی‌ها قابل اندازه‌گیری باشند.
• شما اکنون می‌توانید این دستورالعمل‌های بهینه را از طریق نقطه اتصال (Endpoint) عمومی Software Sausage MCP تست کنید که دفاتر ثبت کامل اجرا (Run Ledgers) را برای کلاینت‌های عامل سازگار برمی‌گرداند.

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