تصور کنید برنامهنویسی هستید که باید تغییراتی را تأیید کند که توسط یک هوش مصنوعی نوشته شده، اما متوجه میشوید تستهای «سبز» مدل، در واقع هیچ چیز را ثابت نمیکنند چون مدل خودش تست را نوشت، خودش آن را اعتبارسنجی کرد و در نهایت خودش را تحسین کرد. این همان وضعیت «امضای کورکورانه» است؛ جایی که توسعهدهندگان تغییراتی را میپذیرند که دیگر ابزارهای معیاری برای درک آنها ندارند. این مشکل زمانی تشدید میشود که تستها بر اساس فیلدهای خصوصی (Private Fields)، ساختارهای اتفاقی یا استفاده از مدلهای شبیهسازی شده (Mocks) از خودِ کدی که تحت تست است نوشته شده باشند.
طبق مستندات این پروژه، سامانه agents-concerto — یک ارکستراتور چندعاملی (Multi-agent Orchestrator) بر بستر Claude Code — با ایجاد تفکیک سختگیرانه بین «رهبر» (Conductor) and «نوازنده» (Player)، تضمین میکند هیچ عاملی که کد را مینویسد، هرگز نتواند خودش آن را تأیید کند. این رویکرد برای حل شکاف اعتماد ایجاد شده است، چراکه در اکثر ابزارهای فعلی، عامل (Agent) — مانند دستیاری که همسردست و هم داور مسابقه است — در یک جلسه واحد (Single Session) عمل میکند و هم پیشنهاد میدهد، هم اعتبارسنج میکند و هم خودش را تحسین میکند. در این حالت، «موکها» اغلب به جای بازتاب واقعی نیازهای سیستم، صرفاً آینهای از کدِ نوشته شده توسط AI هستند. این مدل مدیریت متمرکز، یادآور رویکردی است که در LoopFlow برای جایگزینی مهندسی پرامپت با حلقههای تأیید چندعاملی به کار گرفته شد.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، نبودِ مرزهای عملیاتی منجر به توهمات خطرناک میشود. در agents-concerto، مخزن کد نه به عنوان یک اپلیکیشن، بلکه به مثابه یک مغز ارکستراسیون دیده میشود که از یک فایل CLAUDE.md، چهار عامل تعریفشده در مارکدان و چهار اسکریپت Bash تشکیل شده است. این پیکربندی اجازه میدهد سیستم هر تعداد مخزن هدف را — چه یک مخزن و چه پانزده مخزن — از طریق یک لیست ساده در config.md مدیریت کند.
ارکستراسیون چهار-نفره
این سیستم بهجای یک عامل واحد، از چهار نقش مجزا برای ایجاد یک «مرجع دو-طرفه» استفاده میکند. این بازیکنان بر اساس عملکرد خط لوله سازماندهی شدهاند، نه تکنولوژی؛ مثلاً یک پیادهساز عمومی فارغ از اینکه پروژه بکاند باشد یا فرانتاِند، خدمات میدهد:
- ارکستراتور (Opus): رهبر سیستم است. او وظایف را تجزیه میکند، فایل
plan.mdرا مینویسد، کارها را توزیع کرده و حلقه اصلاح (Fix Loop) را اجرا میکند. نکته حیاتی این است که او هرگز «ساز» نمیزند؛ یعنی هرگز حتی یک خط کد برنامه، حتی یک «اصلاح سریع» (Quick Fix) را نمینویسد. - طبقهبندیکننده (Sonnet): عاملی است که فقط خواندنی است و دقیقاً یک سطح (Tier) را برمیگرداند و هیچ چیز دیگر نمیگوید. او وظایف را به سه دسته «ساده» (Trivial)، «استاندارد» (Standard) یا «پیچیده» (Complex) تقسیم میکند. دستهی پیچیده برای منطقهای دشوار، مسائل همزمانی (Concurrency) یا مسیرهای حساس رزرو شده است. اگر طبقهبندیکننده بین دو سطح مردد باشد، برنامهریزی شده تا سطح بالاتر را انتخاب کند.
- پیادهساز (Implementer): این عامل مدل ثابتی در Frontmatter خود ندارد؛ در عوض، مدل مورد استفاده در هر فراخوانی بر اساس سطحی که طبقهبندیکننده تعیین کرده، انتخاب میشود. او دقیقاً در ورکتری (Worktree) مخصوص به خود کار میکند و دیسیپلین «اول مرتبسازی» (Tidy First) را دنبال میکند: ابتدا یک کامیت ساختاری (بازسازیهایی که تغییری در رفتار ایجاد نمیکنند) و سپس یک کامیت رفتاری. این دو هرگز با هم مخلوط نمیشوند.
- بازبین (Opus): عاملی فقط خواندنی است که مجموعهی ابزارهای او محدود به Read، Grep، Glob و Bash است. او هیچ دسترسی به نوشتن (Write) یا ویرایش (Edit) ندارد و نمیتواند کدی را که بررسی میکند تغییر دهد. او اصلاحات را توصیف میکند اما هرگز آنها را اعمال نمیکند.
تحمیل مرزها و ایزولاسیون
برای جلوگیری از گسترش غیرمجاز محدوده (Scope Creep) و ادغامهای بدون مجوز، agents-concerto مرزهای سختگیرانهای را در سطح ابزار از طریق .claude/settings.json پیاده میکند. این ناپاییها (Invariants) در سطح ابزار منع شدهاند تا مطمئن شویم عاملها نمیتوانند با تغییر مسیر، آنها را دور بزنند. بهطور مشخص، دستورات زیر بهطور کامل مسدود شدهاند:
gh pr merge: عاملها هرگز نمیتوانند کد را ادغام کنند.gh pr review: مسدود شده است زیرا دستور--approveرا به همراه دارد.git merge: ادغام محلی (Local Merging) ممنوع است.git push --force: بازنویسی تاریخچه ارسالشده (Pushed History) منع شده است.
این محدودیتها در واقع نسخهای پیشرفته از پنج حفاظ فنی برای جلوگیری از تخریب مخازن توسط عاملهای خودکار هستند که امنیت کد را در برابر رفتارهای پیشبینینشده مدلها تضمین میکند. اگر عاملی به یک دستور مسدودشده برسد، تلاش برای یافتن راه جایگزین نمیکند، بلکه صرفاً زیر-وظیفه را به عنوان «آماده برای انسان» (Ready-for-human) ارتقا میدهد و اجرا ادامه مییابد. ایزولاسیون را گیت ورکتری (Git Worktrees) تضمین میکند؛ هر عاملی که با کد درگیر است در ورکتری اختصاصی خود اجرا میشود تا محیط محلی توسعهدهنده تا زمان بازبینی نهایی انسان کاملاً دستنخورده بماند.
دروازه تست BDD
این سیستم تعریف وظیفه را از یک «لیست آرزوها» به یک «مشخصات تست فنی» تغییر میدهد. با استفاده از دستور /shape یا دستورالعملهای درونخطی در /run سیستم از تولید اهداف مبهم خودداری میکند. در عوض، معیارهایی با فرمت Given-When-Then تولید میکند: با توجه به <زمینه>، وقتی <اقدام> رخ دهد، آنگاه <نتیجه مشاهدهپذیر> حاصل شود.
این معیارها در یک قرارداد لایهبندی شده قرار میگیرند که در آن بخشهای ## Task و ## Acceptance criteria اجباری هستند، در حالی که ## Scope و ## Non-goals اختیاری بوده و تنها در صورتی اضافه میشوند که ارزش افزودهای داشته باشند. به دلیل اینکه «نتیجه» (Then) باید یک نتیجه مشاهدهپذیر باشد — مانند خروجیها، رابط کاربری رندر شده، وضعیت ذخیره شده در دیتابیس، پاسخهای HTTP یا رویدادهای منتشر شده — برای عامل بسیار دشوار است که معیار را با تکیه بر فیلدهای خصوصی داخلی پاس کند.
این معیار در تمام خط لوله سفر میکند: در مرحله شکلدهی (Shaping) نوشته میشود، در مرحله پیادهسازی به یک تست تبدیل میشود و در مرحله بازبینی، به عنوان یک نگاشت «معیار به تست» تأیید میشود. اگر یک بازسازی ساختاری (Refactor) که قرار بود رفتار را حفظ کند باعث شکست تستی شود، آن تست «غلط» تلقی میشود؛ زیرا ثابت میکند تست به جزئیات داخلی وابسته بوده است، نه به رفتار واقعی سیستم.
گیتهای بازبین
بازبین پیش از آنکه یک PR بتواند جلو برود، مجموعهای از گیتهای سختگیرانه را اعمال میکند. اگر هر یک از موارد زیر رد شود، وضعیت PR به NEEDS_FIXES تغییر میکند:
- صحت (Correctness): آیا معیارهای تعریف شده برآورده شدهاند؟
- تستهای سبز (Green Tests): تمام تستها باید پاس شوند.
- دیسیپلین مرتبسازی (Tidy First): ترکیب کامیتهای ساختاری و رفتاری در یک کامیت ممنوع است.
- گیت BDD: هر معیار باید یک تست پوششی داشته باشد. تستهایی که روی جزئیات داخلی تاکید دارند، مسدود میشوند.
نکته مهم این است که گیت BDD فقط روی تستهایی اعمال میشود که در Diff فعلی اضافه یا تغییر کردهاند. تستهای پیشفرض نادیده گرفته میشوند تا یک تغییر سه خطی منجر به بازنویسی کل مجموعه تستها نشود. حکم نهایی یک کامنت تجمیعی است که به path:line ارجاع میدهد. وضعیت CLEAN به معنای تایید کد نیست — زیرا بازبین نمیتواند رسماً تایید کند — بلکه صرفاً یعنی PR اکنون «آماده برای بازبینی انسانی» است.
خط لوله تولید
جریان کامل یک توالی ساختاریافته است که برای حذف خودمختاری عامل در ادغام نهایی طراحی شده است:
۱. شروع وظیفه: اجرای /run فرآیند را فعال میکند. اگر وظیفه مبهم باشد، گام صفر آن را به صورت درونخطی شکلدهی میکند.
۲. راهاندازی: بارگذاری تنظیمات و باز کردن یک لاگ اجرا با یک RUN_ID منحصربهفرد. خواندن وظیفه از task_source (که میتواند GitHub، GitLab، Linear یا Jira باشد).
۳. تعیین محدوده (Scoping): فیلتر کردن اینکه کدام مخازن تحت تأثیر قرار میگیرند. چنین مدیریت دقیقی از مخازن، ضرورت زیرساختهای مقیاسپذیرتری را میطلبد، مشابه آنچه Entire برای میزبانی انبوه مخازن هوش مصنوعی ارائه داده است.
۴. برنامهریزی: ایجاد plan.md شامل زیر-وظایف و وابستگیهای «مسدود شده توسط» (Blocked by).
۵. موجهای وابستگی: زیر-وظایفی که مسدود نیستند به صورت موازی و هر کدام در ورکتری خود اجرا میشوند. این موج ترتیب زیر را دنبال میکند: طبقهبندی $
ightarrow$ انتخاب مدل $
ightarrow$ اجرای worktree-create.sh $
ightarrow$ پیادهساز (TDD + Tidy First) $
ightarrow$ باز کردن PR $
ightarrow$ بازبین $
ightarrow$ حلقه اصلاح (که توسط max_fix_cycles محدود شده است).
۶. نتیجهگیری: در صورت رسیدن به سقف چرخههای اصلاح، موضوع به بازبینی انسانی ارتقا مییابد. پس از پایان، اسکریپت worktree-cleanup.sh اجرا شده و یک خلاصه اطلاعرسانی میشود.
چون هیچ چیزی به صورت خودکار ادغام (Auto-merge) نمیشود، نیازی به «کارگر رفع تداخل» (Conflict Worker) نیست؛ انسان به سادگی ترتیب ادغام شاخههایی که یک فایل مشترک دارند را انتخاب میکند.
طبق مستندات سیستم، هزینه اجرای یک تیم عاملی به این روش حدود ۴ تا ۶ برابر بیشتر از یک جلسه تکعاملی با Claude Code است. هر خلاصه اجرا شامل این یادآوری در کنار تعداد PRها، چرخهها و ارتقاءهاست. این هزینه، بهای گذار از «امضای کورکورانه» به یک مسیر حسابرسی قابل تأیید است، جایی که باتوم (Baton) در دست انسان باقی میماند.
توسعهدهندگان برای پیادهسازی میتوانند ابزار را از طریق مارکت پلاگینهای کلود با دستور claude plugin install agents-concerto@moruno-plugins نصب کرده و با /agents-concerto:setup مقداردهی اولیه کنند یا وظایف را با /agents-concerto:run <task description> اجرا نمایند.
گام بعدی شما
- اگر از Claude Code استفاده میکنید، پلاگین agents-concerto را برای تست متدولوژی Tidy First نصب کنید.
- ساختار Given-When-Then را برای تعریف وظایف AI جایگزین توصیفات متنی ساده کنید.
- هزینه استنتاج (Inference Cost) — شبیه کرایه آشپزخانه صنعتی که هرچه دستور پخت سنگینتر، هزینه هر وعده بیشتر است — را با تعداد چرخههای اصلاح (Fix Cycles) در هر اجرا مانیتور کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو