تصور کنید یک متخصص ارشد را استخدام کنید، اما برای پاسخ به یک سوال ساده، او را مجبور کنید ابتدا ۱۰۰ صفحه صورت‌جلسات نامرتبط را بخواند؛ احتمالا تمرکز او را از دست می‌دهد و زمانش تلف می‌شود. در سامانه‌های چندعاملی (Multi-agent System)، اتفاق مشابهی می‌افتد: پنجره متنی (Context Window) — شبیه میز کاری که جا برای چند ورق دارد، نه برای کل کتابخانه — به‌سرعت از چند هزار توکن به ده‌ها هزار توکن می‌رسد. این اتفاق در یک جلسه واحد رخ می‌دهد و باعث می‌شود هزینه‌های توکن دوبرابر شده و تمرکز مدل به‌شدت کاهش یابد.
به نقل از راهنمای فنی منتشر شده در وب‌سایت dev.to در ۲ ژوئیه ۲۰۲۶، راهکار این بحران در تعریف «مرزهای ارکستراتور» (Orchestrator Boundaries) نهفته است. این رویکرد معماری، راهکاری برای جلوگیری از دسترسی زیر-عامل‌ها به تاریخچه کامل گفتگوهای عامل اصلی است.
همان‌طور که در تحلیل قبلی ما درباره‌ی هماهنگی ۶ عامل هوش مصنوعی اشاره کردیم، افزایش قابلیت اطمینان از ۷۴٪ به ۹۲٪ نیازمند نظم است؛ اما این معماری جدید، فراتر از هماهنگی ساده رفته و به «جداسازی کامل زمینه» (Total Context Isolation) می‌رسد. این رویکرد در واقع تکامل‌یافته‌ی مفاهیم مدیریتی است که در بررسی‌های پیشین درباره‌ی زیرساخت‌های ارتباطی در سیستم‌های چند-عاملی به چالش‌های همگام‌سازی اشاره شده بود. در مدل‌های معیوب، تمام تاریخچه گردش کار به زیر-عامل‌ها داده می‌شود. این کار دقیقاً مانند این است که به یک متخصص، ترانسکریپت ۱۰۰ صفحه‌ای از تمام جلسات را بدهید تا فقط یک خط کد را بررسی کند؛ در چنین حالتی، سیگنال‌های مفید در میان نویزهای اطلاعاتی گم می‌شوند.
مأموریت سخت‌گیرانه ارکستراتور
برای حفظ کارایی، ارکستراتور (عامل اصلی) باید تنها به سه عملکرد مشخص محدود شود:
۱. تصمیم‌گیری (Decide): خواندن وضعیت فعلی سیستم و تعیین گام بعدی.
۲. اعزام (Dispatch): ایجاد زیر-عامل‌های مورد نیاز و ارسال پرامپت‌های دقیق وظیفه برای آن‌ها.
۳. جمع‌آوری (Collect): خواندن فایل‌های خروجی زیر-عامل‌ها و به‌روزرسانی وضعیت کلی (Global State).
به باور نویسندگان این راهنما، ارکستراتور هرگز نباید منطق تجاری (Business Logic) را اجرا کند. تحلیل باگ‌ها، نوشتن کد خام یا کوئری زدن به لاگ‌ها صرفاً وظیفه زیر-عامل‌هاست. منطق تجاری، خواندن فایل‌های خام و تغییر داده‌های کسب‌وکار منحصراً به زیر-عامل‌ها تعلق دارد. اگر ارکستراتور یک لاگ ۱۰۰ هزار خطی را مستقیماً در زمینه خود بخواند (مثلاً با دستور log_content = Path("crash.log").read_text())، طراحی سیستم شکست خورده است. به‌جای آن، یک زیر-عامل باید آن لاگ را پردازش کرده و تنها یک نتیجه ساختاریافته در قالب JSON بازگرداند.
مزایای اجرای مرزها
این تفکیک سخت‌گیرانه دو مزیت فنی کلیدی ایجاد می‌کند:
- مدیریت بهینه زمینه: پنجره متنی عامل اصلی سبک (Lean) باقی می‌ماند. این زمینه تنها شامل وضعیت‌ها و نتایج ساختاریافته است و دیگر داده‌های خام در آن جای ندارند.
- تست مستقل: چون زیر-عامل‌ها به تاریخچه نشست عامل اصلی وابسته نیستند، منطق تجاری آن‌ها را می‌توان به‌صورت کاملاً مجزا تست کرد. این امر منجر به شتاب گرفتن چرخه توسعه می‌شود.
اصول طراحی زیر-عامل‌ها
برای موفقیت این سیستم، زیر-عامل‌ها باید سه محدودیت سخت (Hard Constraints) را رعایت کنند:
۱. کامل بودن ورودی (Input Completeness): پرامپت وظیفه باید هر آنچه برای انجام کار لازم است را در خود داشته باشد. استفاده از عباراتی مانند «به نتایج تحلیل‌های قبلی مراجعه کن» ممنوع است، زیرا زیر-عامل در یک نشست ایزوله اجرا می‌شود و به تاریخچه دسترسی ندارد. یک پرامپت کامل باید صراحتاً موارد زیر را تعریف کند: وظیفه (Task)، ورودی‌ها (مانند bug_info.summary ،bug_info.stack_trace و log_dir) و الزامات خروجی.
۲. سخت‌گیری در قرارداد خروجی (Output Contract Strictness): خروجی‌ها باید دقیقاً مطابق طرح‌واره (Schema) تعریف‌شده در پوشه templates/ باشند. منطق مسیریابی ارکستراتور به این طرح‌واره وابسته است؛ هرگونه نقص در فیلدها یا اشتباه در نوع داده‌ها، منطق تصمیم‌گیری را مختل می‌کند. فیلدهای الزامی عبارتند از:
* passed (boolean): برای مسیریابی ارکستراتور حیاتی است.
* confidence (float): عددی بین ۰ تا ۱.
* root_cause (string): علت ریشه‌ای مشکل.
* evidence (list of strings): فهرستی از شواهد.
* error (string | None): این فیلد مخصوصاً در زمان شکست الزامی است.
۳. شکست ساختاریافته (Structured Failure): زیر-عامل نباید به‌سادگی کرش کند یا هیچ خروجی‌ای ندهد. در صورت شکست، باید حتماً فایلی بنویسد که در آن passed: false باشد و یک پیام خطای دقیق ارائه شود (مثلاً: "Log file not found: /workspace/logs/crash_20260601.log"). نبود فایل خروجی توسط عامل اصلی به عنوان «اتمام زمان» (Timeout) تفسیر می‌شود؛ اما خطاهای ساختاریافته به ارکستراتور اجازه می‌دهد تفاوت بین «شکست زیر-عامل» و «Timeout» را تشخیص داده و واکنش مناسب نشان دهد.
کنترل هم‌زمانی و مدل Fan-Out
این چارچوب از طراحی Fan-out استفاده می‌کند که در آن یک محرک (Trigger)، تعداد $N$ زیر-عامل را به‌صورت هم‌زمان ایجاد می‌کند. طبق مستندات، برای اجرای موفق این مدل دو شرط حیاتی است:
شرط اول: مسیرهای خروجی یکتا. برای جلوگیری از تداخل در نوشتن هم‌زمان (Concurrent Write)، هر زیر-عامل باید در مسیر منحصر‌به‌فرد خود بنویسد. برای مثال، اگر سیستم در حال پردازش سه کاندید است، آن‌ها باید به ترتیب در فایل‌های phase4/candidate_a.json ،phase4/candidate_b.json و phase4/candidate_c.json بنویسند، نه اینکه همگی سعی کنند در یک فایل واحد به نام result.json بنویسند.
شرط دوم: انتظار هم‌گام (Synchronized Waiting). پس از عملیات Fan-out، ارکستراتور باید در وضعیت انتظار بماند و تا زمان تکمیل تمام زیر-عامل‌ها پیش نرود. در محیط‌هایی که زمان‌بندی نامتقارن (Async Runtime) ندارند، این کار از طریق Polling مدیریت می‌شود. ارکستراتور وجود هر فایل JSON مورد انتظار را در یک بازه زمانی تعریف‌شده (مثلاً ۳۰۰ ثانیه) بررسی می‌کند و سپس ادامه می‌دهد.
استراتژی‌های ادغام (Fan-in)
هنگام بازگشت نتایج و ادغام آن‌ها (Fan-in)، سیستم بر اساس ماهیت مسئله از دو استراتژی مدیریت خطا استفاده می‌کند:
۱. توقف سریع (Fail-Fast): در این حالت، هرگونه شکست در حتی یکی از شاخه‌ها باعث توقف کل گردش کار می‌شود. این استراتژی برای مسائل «همه یا هیچ» استفاده می‌شود که در آن نتایج تمام شاخه‌ها مورد نیاز است. برای مثال، اگر سه زیر-عامل در حال استخراج داده از سه منبع مختلف هستند، نبود حتی یکی از منابع، تحلیل‌های بعدی را غیرممکن می‌کند. در فایل پیکربندی، این حالت با fan_in_strategy: fail-fast مشخص می‌شود و ممکن است در صورت شکست، یک گیت خاص (مثل trigger_gate_A) را فعال کند. این متدولوژی با مفاهیم مدیریت وضعیت اتمیک در Network-AI هم‌سویی دارد تا از فقدان داده‌ها در لحظه انتقال جلوگیری شود.
۲. جمع‌آوری کلی (Collect-All): سیستم تمام نتایج، از جمله شکست‌ها را جمع‌آوری کرده و بهترین کاندیدای موفق را انتخاب می‌کند. این استراتژی برای مسائل «فضای-راهکار» (Solution-space) ترجیح داده می‌شود؛ مانند حالتی که سه روش مختلف برای رفع یک باگ تولید می‌شود. اگر یکی از کاندیداها تست‌ها را پاس کند، کافی است و بقیه دور ریخته می‌شوند. در این حالت، گیت انسانی تنها زمانی فعال می‌شود که تمام کاندیداها شکست بخورند. این روش نیازمند تعریف معیارهای انتخاب (selection_criteria) مانند select_by: max_test_coverage و تنظیم require_any_passed: true است.
لایه ایزولاسیون
جریان اطلاعات در این مدل کاملاً یک‌طرفه و گیت‌دار است. ارکستراتور فقط پرامپت وظیفه شامل فیلدهای مورد نیاز را می‌فرستد؛ زیر-عامل در یک خلأ (Vacuum) پردازش را انجام داده و خروجی JSON را در مسیر تعیین‌شده می‌نویسد. ارکستراتور سپس فایل را می‌خواند (مثلاً با دستور result = json.loads(Path("phase3/analysis_final.json").read_text())) و هرگز به تاریخچه گفتگو رجوع نمی‌کند.
این جداسازی تضمین می‌کند که تاریخچه‌های نامرتبط باعث کاهش تمرکز زیر-عامل نشود. زیر-عامل از پیشرفت کلی گردش کار یا خروجی‌های سایر زیر-عامل‌ها کاملاً بی‌اطلاع است. اگر زیر-عاملی برای تکمیل وظیفه‌اش به زمینه پس‌زمینه (Background Context) نیاز دارد، ارکستراتور باید آن را صراحتاً در پرامپت تزریق کند؛ نمی‌توان فرض کرد که عامل می‌تواند تاریخچه را «ببیند».
چک‌لیست طراحی برای پیاده‌سازی
برای تضمین یکپارچگی معماری، توسعه‌دهندگان باید موارد زیر را بررسی کنند:
- ارکستراتور: آیا از اجرای منطق تجاری پرهیز می‌کند؟ آیا فقط JSONهای ساختاریافته را می‌خواند؟ آیا مسیریابی به جای تاریخچه، به فایل وضعیت (State File) وابسته است؟
- زیر-عامل‌ها: آیا پرامپت‌های وظیفه کامل هستند؟ آیا طرح‌واره خروجی در
templates/تعریف شده است؟ آیا شکست‌ها منجر به تولید فایل JSON باpassed: falseمی‌شوند؟ - هم‌زمانی: آیا مسیرهای خروجی یکتا هستند؟ آیا استراتژی ادغام (Fail-fast یا Collect-all) صراحتاً مشخص شده است؟
- ایزولاسیون: آیا نشست‌ها ایزوله هستند؟ آیا تمام زمینه‌های لازم به‌طور صریح در پرامپت ارائه شده‌اند؟
این تغییر در معماری عاملی، معیار تعریف «عامل هوشمند» را تغییر می‌دهد. هدف دیگر این نیست که ارکستراتور را intelligentتر کنیم، بلکه هدف این است که آن را disciplinedتر (منضبط‌تر) سازیم. با اجرای این مرزها، توسعه‌دهندگان می‌توانند زیر-عامل‌ها را به‌صورت مستقل تست کنند و چرخه دیباگینگ گردش‌های کاری پیچیده AI را به‌شدت کاهش دهند.
برای پیاده‌سازی این مدل، مهندسان باید با بازرسی پرامپت‌های فعلی خود برای شناسایی وابستگی‌های ضمنی به زمینه (Implicit Context Dependencies) شروع کرده و آن‌ها را با فیلدهای داده‌ای صریح جایگزین کنند.
گام بعدی شما
- پرامپت‌های فعلی خود را بررسی کنید و هرگونه ارجاع ضمنی به «تاریخچه گفتگو» را با فیلدهای داده‌ای صریح جایگزین کنید.
- برای خروجی‌های زیر-عامل‌ها، یک فایل JSON Schema سخت‌گیرانه تعریف کنید تا نرخ خطای مسیریابی ارکستراتور کاهش یابد.
- استراتژی Fail-Fast یا Collect-All را بر اساس ماهیت خروجی‌های خود (تک‌جوابی یا چند-گزینه‌ای) انتخاب و پیاده کنید.
اما بهینه‌سازی این لایه‌های ایزولاسیون تنها نیمی از راه است؛ برای کاهش بیشتر هزینه‌ها، بررسی کنید که چگونه تکنیک‌های Quantization می‌توانند مدل‌های کوچک‌تر را در نقش زیر-عامل جایگزین مدل‌های غول‌پیکر کنند.
گفتگو