دلایل علیه پیش‌فرض گرفتن ازدحام‌ها
یک حالت شکست رایج در مهندسی agent این است که پیش از رسیدن به یک تابع، به سراغ یک ازدحام برویم. یک کار به نقش‌ها تجزیه می‌شود، یک supervisor اضافه می‌شود و سیستم «agentic» اعلام می‌گردد. آنچه واقعاً ساخته شده یک سیستم توزیع‌شده با یک مدل زبانی در حلقه است و هزینه‌هایش همان هزینه‌های آشنای توزیع به‌علاوه هزینه‌های ناآشنای غیرقطعی‌بودن است.
هر agent اضافی یک handoff معرفی می‌کند. در هر handoff، agent تولیدکننده وضعیت خود را به متن سریال‌سازی می‌کند و agent مصرف‌کننده آن را دوباره به context دیسریال‌سازی می‌کند. این رفت‌وبرگشت همراه با اتلاف است. یک نتیجه ساختاریافته با امتیاز اطمینان، ارجاع به منبع و یک نشانگر شکست جزئی، در قالب نثر به جمله‌ای تبدیل می‌شود که هر سه را حذف می‌کند. این اتلاف تصادفی نیست؛ دقیقاً با همان اطلاعاتی همبستگی دارد که agent پایین‌دستی برای تصمیم‌گیری درباره ادامه، تلاش مجدد یا ارجاع به سطح بالاتر نیاز دارد.
سربار هماهنگی نیز سریع‌تر از صرفه‌جویی حاصل از تجزیه رشد می‌کند. اگر یک کار T واحد کار ببرد و به n زیرکار تقسیم شود، صرفه‌جویی ایده‌آل تقریباً T/n است. هزینه هماهنگی T/n نیست؛ مجموع handoffهاست که هر یک به یک prompt، یک فراخوانی مدل، یک parse و یک اعتبارسنجی نیاز دارد. در عمل، افزودن agentها فراتر از نقطه‌ای که زیرکارها واقعاً مستقل‌اند، سیستمی تولید می‌کند که کندتر، پرهزینه‌تر و سخت‌تر برای اشکال‌زدایی از همان فراخوانی واحدی است که جایگزینش شده.
عمیق‌ترین مشکل، آزمون‌پذیری است. کد قطعی را می‌توان unit test کرد. تابعی که ورودی نوع‌دار می‌گیرد و خروجی نوع‌دار برمی‌گرداند، قراردادی دارد که می‌توان علیه آن assert نوشت. prompt یک orchestrator چنین نیست. می‌توانید خروجی‌هایش را روی یک مجموعه‌داده ارزیابی کنید و باید هم بکنید، اما نمی‌توانید تستی بنویسید که وقتی orchestrator بی‌صدا سیاست مسیریابی خود را بین نسخه‌های مدل تغییر می‌دهد، شکست بخورد. prompt یک مشخصه است که در زبانی بدون کامپایلر بیان شده.
این استدلالی علیه سیستم‌های چند-agent نیست. استدلالی است علیه برخورد پیش‌فرض با آن‌ها. الگوی رئیس‌دفتر، همان‌گونه که در این نوشته درباره هماهنگ‌سازی نشست‌های Claude Code توصیف شده، دقیقاً به این دلیل مفید است که شرایطی را نام می‌برد که در آن‌ها یک لایه هماهنگ‌کننده ارزش خود را ثابت می‌کند.
نشانه‌هایی که هماهنگ‌سازی را توجیه می‌کنند
در عمل، سه نشانه کاری را که به orchestrator نیاز دارد از کاری که به اسکریپت نیاز دارد متمایز می‌کند.
مجموعه‌ابزارهای ناهم‌پوشان یا contextهای ناهم‌پوشان
اگر زیرکار A به دسترسی خواندن به یک codebase نیاز دارد و زیرکار B به دسترسی نوشتن به یک هدف استقرار، آن‌ها به مجموعه‌ابزارهای متفاوت نیاز دارند. یک agent واحد که هر دو ابزار را در اختیار دارد باید به هر دو مورد اعتماد شود و context آن باید schemaها، اعتبارنامه‌ها و حالت‌های شکست هر دو را حمل کند. جدا کردنشان یعنی context هر agent کوچک‌تر و اختیاراتش محدودتر است. همین استدلال درباره context windowها هم صادق است: اگر ماده خام یک زیرکار بیشتر پنجره را مصرف کند و ماده خام زیرکار دیگر باقی آن را، یک agent واحد کوتاه‌سازی یا خلاصه‌سازی می‌کند و خلاصه‌سازی همان جایی است که اتلاف اطلاعات رخ می‌دهد.
استقلال واقعی
یک agent دوم زمانی ارزش هزینه‌اش را دارد که واقعاً مستقل باشد، نه وقتی بازگویی agent اول باشد. استقلال یعنی context، فرض‌ها و حالت‌های شکست agent اول را به اشتراک نمی‌گذارد. یک verifier که همان context و همان استدلال را می‌خواند، تمایل دارد با تولیدکننده موافق باشد، چون همان توزیع را روی همان tokenها اجرا می‌کند. یک verifier که فقط artefact را می‌خواند و ابزارهای خودش را برای بررسی آن دارد، می‌تواند مخالفت کند. همان مخالفت ارزش است.
کارهای افق بلند
برخی کارها به‌قدری افق بلند دارند که یک context واحد نمی‌تواند آن‌ها را نگه دارد. مهاجرتی که صدها فایل را لمس می‌کند، کار تحقیقی‌ای که در طول ساعت‌ها منابع جمع می‌کند، پاسخ به حادثه‌ای که چندین سیستم را در بر می‌گیرد: این‌ها از آنچه یک پنجره می‌تواند نگه دارد فراتر می‌روند و حالت شکست، پاسخ غلط نیست بلکه پاسخ فراموش‌شده است. اینجا کار orchestrator استدلال درباره کار نیست، بلکه مدیریت دفتر ثبت آنچه انجام شده و آنچه باقی مانده است.
اگر هیچ‌یک از این سه نشانه وجود ندارد، پاسخ صادقانه مهندسی یک اسکریپت است. اسکریپتی که یک مدل را فراخوانی می‌کند، خروجی را علیه یک schema اعتبارسنجی می‌کند و در صورت شکست دوباره تلاش می‌کند، آزمون‌پذیر، قابل مشاهده و ارزان است. در بیشتر موارد سریع‌تر هم هست.
پیاده‌سازی الگو
وقتی هماهنگ‌سازی توجیه دارد، جزئیات پیاده‌سازی تعیین می‌کند که کار می‌کند یا نه. سه سازوکار بیش از انتخاب framework اهمیت دارند.
یک دفتر ثبت وظیفه مرجع واحد
agentها باید یک دفتر ثبت مشترک را بخوانند و بنویسند، نه اینکه خلاصه‌های نثری به هم پاس بدهند. دفتر ثبت مرجع حقیقت برای آنچه تلاش شده، آنچه موفق شده و آنچه مسدود شده است. هر ورودی یک رکورد است: شناسه وظیفه، وضعیت، ورودی‌ها، خروجی‌ها و هر خطا. agentها وظایف را برمی‌دارند، وضعیت را به‌روزرسانی می‌کنند و نتایج را ضمیمه می‌کنند. هماهنگ‌سازی
این الگوی معمول را وارونه می‌کند. به‌جای اینکه orchestrator وضعیت را در context خود نگه دارد و به کارگران خلاصه‌اش کند، وضعیت بیرون از هر context زندگی می‌کند و بر حسب نیاز خوانده می‌شود. کارگری که باید بداند آیا یک وابستگی موفق شده، دفتر ثبت را می‌خواند نه اینکه به یک خلاصه اعتماد کند. context orchestrator کوچک می‌ماند و همین نکته اصلی است.
قراردادهای handoff به‌صورت payloadهای نوع‌دار
یک handoff باید یک payload نوع‌دار باشد، نه یک خلاصه نثری. schema را یک بار تعریف کنید، در هر دو طرف اعتبارسنجی کنید و در صورت عدم تطابق با صدای بلند شکست بخورید. یک قرارداد حداقلی برای نتیجه یک subagent می‌تواند چنین باشد:
{
"task_id": "string",
"status": "succeeded | failed | blocked",
"artefacts": [{"path": "string", "hash": "string"}],
"claims": [{"text": "string", "evidence": "string"}],
"open_questions": ["string"]
}
schema دو کار می‌کند. agent تولیدکننده را مجبور می‌کند بین آنچه انجام داده و آنچه باور دارد تمایز بگذارد، که دو چیز متفاوت‌اند. و به agent مصرف‌کننده یک رابط پایدار می‌دهد، تا تغییر در استدلال تولیدکننده بی‌صدا ورودی مصرف‌کننده را تغییر ندهد. جایی که فیلدی قابل پر کردن نیست، agent باید بگوید و blocked یک وضعیت معتبر است. خلاصه‌های نثری دقیقاً همین حالت را پنهان می‌کنند.
اندازه‌گیری تأخیر handoff و اتلاف اطلاعات
تأخیر handoff قابل اندازه‌گیری است: زمان از تکمیل تولیدکننده تا شروع مصرف‌کننده، و زمان صرف‌شده در اعتبارسنجی و تلاش‌های مجدد. اتلاف اطلاعات سخت‌تر است اما غیرممکن نیست. آن را با مقایسه آنچه تولیدکننده منتشر کرده و آنچه مصرف‌کننده بر اساس آن عمل کرده اندازه‌گیری کنید. اگر payload تولیدکننده سه پرسش باز داشته و اقدام بعدی مصرف‌کننده به هیچ‌یک نمی‌پردازد، این یک اتلاف است و ارزش ثبت دارد. در طول اجراهای متعدد، توزیع این اتلاف‌ها به شما می‌گوید کجا قراردادها بیش از حد نازک‌اند.
هر دو را به‌عنوان معیارهای درجه‌یک، در کنار نرخ موفقیت وظیفه و هزینه هر وظیفه، در نظر بگیرید. سیستم هماهنگ‌سازی‌ای که درست است اما handoffهایش بیشتر از کاری که هماهنگ می‌کنند طول می‌کشد، سیستمی است که باید دوباره به یک اسکریپت فروکاسته شود.
معامله صادقانه
الگوی رئیس‌دفتر رایگان نیست و همیشه درست هم نیست. هزینه‌هایش واقعی‌اند: قطعات متحرک بیشتر، promptهای بیشتر برای نگهداری، حالت‌های شکست بیشتر برای مشاهده و تجربه اشکال‌زدایی‌ای که چندین context را در بر می‌گیرد نه یکی را. مزایایش هم واقعی‌اند، اما مشروط. زمانی ظاهر می‌شوند که زیرکارها به context متفاوت، ابزارهای متفاوت یا راستی‌آزمایی مستقل نیاز دارند و تا حد زیادی وقتی ندارند، ناپدید می‌شوند.
انضباط عملی این است که با اسکریپت شروع کنید. فراخوانی واحد را بنویسید، خروجی‌اش را اعتبارسنجی کنید، اندازه بگیرید کجا شکست می‌خورد. وقتی شکست می‌خورد چون context بیش از حد بزرگ است، یا ابزارها تعارض دارند، یا راستی‌آزمایی مستقل نیست، orchestrator را اضافه کنید. نه پیش از آن. این الگو پاسخی به مجموعه‌ای مشخص از محدودیت‌هاست و اعمال آن بدون آن محدودیت‌ها، ظاهر پیچیدگی را به قیمت خودِ آن چیز تولید می‌کند.