// سطح: helix-primary · سفارش 12

LLMOrchestrator betaاجازه‌نامه: Apache-2.0

Go (1.25)Go stdlib (+ testify, yaml.v3)Pipe transport (JSON-lines over stdio)File transport (inbox/outbox/shared)sync.Mutex / sync.CondCircuit breaker + HealthMonitorpkg/i18n TranslatorChallenge harness

منبع

• HelixDevelopment/LLMOrchestrator
• HelixDevelopment/HelixConstitution

// معماری

یک صف کنترل برای هر عامل کدنویسی بدون رابط کاربری CLI

LLMOrchestrator یک ماژول مستقل و قابل استفاده مجدد Go برای ایجاد، مدیریت و ارتباط با عوامل بدون رابط کاربری CLI (OpenCode، Claude Code، Gemini، Junie، Qwen Code) از طریق پروتکل ترکیبی لوله+فایل است که شامل قطع‌کننده‌های مدار برای هر عامل، انتخاب چندارائه‌دهنده قابل اتصال، انتزاع i18n جداشده و تضمین‌های تست ضد بلوف می‌شود.

یک ماژول قابل استفاده مجدد Go که یک رابط یکپارچه برای ایجاد و هدایت چندین عامل CLI مبتنی بر LLM از طریق پروتکل ترکیبی لوله+فایل فراهم می‌کند. استخرسازی امن عوامل با قطع‌کننده‌های مدار و راهبردهای مسیریابی قابل انتخاب، عمداً مستقل از مصرف‌کننده، با مترجم i18n قابل اتصال.

LLMOrchestrator زیرساخت اشتراکی برای هماهنگ‌سازی عوامل کدنویسی بدون رابط کاربری CLI است — همان لوله‌کشی که هر سیستم چندعاملی به آن نیاز دارد و معمولاً به شکلی ناقص بازطراحی می‌شود. به جای آنکه هر پروژه مجبور باشد ایجاد فرایند، قالب‌بندی پیام و تجزیه نتایج را برای ابزارهایی مانند OpenCode، Claude Code، Gemini CLI، Junie و Qwen Code از نو پیاده‌سازی کند، این ماژول یک رابط یکپارچه Agent، یک استخر امن نخ AgentPool و یک MultiProviderPool ارائه می‌دهد که عوامل را از چندین ارائه‌دهنده پشت یک نمای واحد گردآوری می‌کند. مسیریابی از طریق یک AgentSelector قابل اتصال است — نوبت‌دهی دایره‌ای که ارائه‌دهندگان ناتوان در برآورده کردن الزامات را نادیده می‌گیرد، یا اولویت‌بندی با جایگزین — به طوری که نحوه توزیع کار یک سیاست انتخابی شماست، نه یک فرض کدگذاری‌شده. هر عامل مشخص یک آداپتور نازک بر روی یک BaseAdapter مشترک است که مالک چرخه کامل فرایند است: شروع با راه‌اندازی لوله، توقف آرام با SIGTERM و سپس SIGKILL، راه‌اندازی مجدد و زنده‌بودن — همان بخش پیچیده و مستعد خطا که یک بار برای همیشه حل شده است.

ارتباط عمداً ترکیبی است و انتقال را با وظیفه منطبق می‌کند. انتقال لوله‌ای حامل پیام‌های JSON با جداکننده خط‌نو، با مهلت خواندن برای هر درخواست و سقف طول پاسخ برای پیام‌رسانی تعاملی سریع است، در حالی که انتقال فایلی از دایرکتوری‌های ورودی/خروجی/مشترک برای هر جلسه برای مصنوعات بزرگ یا ماندگار که نباید در لوله قرار گیرند استفاده می‌کند. تاب‌آوری یک فکر بعدی نیست — بلکه ساختاری است: قطع‌کننده مدار برای هر عامل پس از سه شکست متوالی به مدت ۶۰ ثانیه باز می‌شود و سپس یک پروب نیمه‌باز انجام می‌دهد، و یک مانیتور سلامت پس‌زمینه عوامل را پینگ می‌کند تا عاملی که از کار افتاده بتواند بدون انتظار برای ترافیک ورودی بهبود یابد. دریافت استخر روی یک متغیر شرطی بلاک می‌شود به جای آنکه CPU را در انتظار مشغول نگه دارد، و تجزیه‌کننده پاسخ بدون حالت و امن برای فراخوانی همزمان است. این ماژول کاملاً جداشده است — هیچ جزئیات مصرف‌کننده‌ای اجازه ورود ندارد — و هر رشته قابل مشاهده توسط کاربر از طریق یک مترجم i18n قابل اتصال Translator عبور می‌کند، با یک NoopTranslator که شناسه‌های پیام را به صورت تحت‌اللفظی برمی‌گرداند تا ترجمه گم‌شده به وضوح نمایان شود نه پنهان.

هر سیستم چندعاملی نیاز دارد عوامل CLI را به شکلی قابل اعتماد راه‌اندازی و با آنها ارتباط برقرار کند. حل مجدد مسائل ایجاد فرایند، قالب‌بندی، تجزیه و مدیریت شکست برای هر پروژه اتلاف وقت و مستعد خطاست. LLMOrchestrator این موارد را در یک ماژول جداشده و قابل استفاده مجدد متمرکز می‌کند که مسئولیت تخصصی آن، قابلیت استفاده مجدد را تضمین می‌کند — و این قابلیت استفاده مجدد به محض ورود هر جزئیات مصرف‌کننده‌ای از بین می‌رود.

محتوا

این ابزار، تبدیل کردن «اجرای گروهی از عامل‌های ناهمگن CLI» از یک کار مهندسی سفارشی و طاقت‌فرسا برای هر پروژه به یک ایمپورت سادهٔ کتابخانه‌ای را ممکن می‌سازد — مدیریت تجمیع، شکست مدار، چرخهٔ حیات و مسیریابی قابل‌تعویض، همگی از پیش حل‌شده و مقاوم‌سازی‌شده‌اند. و چون تست‌های ضد-فریب آن، سیستم واقعی را سرتاسر آزمایش می‌کنند و به «کامپایل می‌شود» بسنده نمی‌کنند، به انتزاعی دست می‌یابید که واقعاً می‌توانید در شرایط همزمانی و شکست به آن اعتماد کنید، نه چیزی که فقط در نمودار خوب به نظر برسد.

• پروتکل ترکیبی لوله+فایل — سرعت تعاملی (خطوط JSON روی stdin/stdout، مهلت‌های خواندن، محدودیت پاسخ) *و* تبادل پایدار مبتنی بر فایل (صندوق ورودی/خروجی/مشترک) برای مصنوعات بزرگ، به‌طوری که هرگز مجبور نیستید تأخیر را به پای دوام قربانی کنید یا برعکس.
• تجمیع چندارائه‌دهندهٔ قابل‌تعویض با انتخابگرهای قابل‌تعریف — یک نمای واحد روی چندین ارائه‌دهندهٔ CLI، با مسیریابی نوبتی یا اولویت‌محور که به‌عنوان سیاست انتخاب می‌شود نه به‌صورت ثابت.
• مدارشکن انفرادی برای هر عامل + پایشگر سلامت پس‌زمینه‌ای — کاهش خودکار کارایی *و* بازیابی (۳ شکست → ۶۰ ثانیه قطع → کاوش نیمه‌باز)، به‌طوری که یک عامل ناپایدار ایزوله و سپس بدون دخالت دستی به‌آرامی بازگردانده می‌شود.
• تجمیع بدون انتظار فعال — Acquire روی sync.Cond بلاک می‌شود تا زمانی که یک عامل سالم و منطبق آزاد شود یا زمینهٔ درخواست لغو گردد، بنابراین انتظار هیچ بار پردازشی ندارد.
• جداسازی دقیق + ضد-فریب بین‌المللی‌سازی — NoopTranslator شناسه‌های پیام را به‌صورت خام برمی‌گرداند تا نبود ترجمه هرگز نادیده گرفته نشود، نه اینکه به‌صورت خاموش خالی بماند.
• امنیت به‌صورت پیش‌فرض — فهرست سفید مسیرهای باینری به این معنی است که هیچ‌گونه درون‌یابی شل و در نتیجه هیچ سطحی برای تزریق فرمان وجود ندارد، همراه با محافظت در برابر پیمایش مسیر، محدودیت پاسخ ۱ مگابایتی برای جلوگیری از خروجی‌های کنترل‌نشده، و ماسک‌کردن کلیدهای API در لاگ‌ها.
• چارچوب تست ضد-فریب Challenge — دورهای رفت‌وبرگشت واقعی دیسک/JSON/پارسر در پنج زبان، با یک دروازهٔ جهش همزمان که باید در صورت خرابی ویژگی، با کد خروج غیرصفر پایان یابد — تستی که ثابت می‌کند واقعاً می‌تواند شکست بخورد.

• ورودی/خروجی قابل‌اعتماد فرایند عامل. ارتباط با یک فرایند CLI ایجادشده به‌طرز فریبنده‌ای دشوار است؛ با یک حمل‌ونقل ترکیبی لوله+فایل، قرارداد پیام/پارسر تعریف‌شده تا هر دو طرف بر قالب سیم توافق داشته باشند، و یک BaseAdapter که کل چرخهٔ حیات فرایند از جمله مهلت منظم SIGTERM با بازگشت به SIGKILL را متمرکز می‌کند، حل شد.
• همزمانی بدون انتظار فعال. با یک AgentPool متشکل از متغیر شرطی و قفل که در آن Acquire تا زمانی که یک عامل منطبق و سالم واقعاً آزاد شود یا زمینهٔ درخواست لغو گردد، به خواب می‌رود، همراه با یک پارسر بدون حالت و عاری از اثر جانبی که ایمن است از چندین گوروتین به‌طور همزمان فراخوانی شود، حل شد.
• ایزوله‌سازی شکست ارائه‌دهنده. به‌گونه‌ای حل شد که یک ارائه‌دهندهٔ معیوب نتواند بقیه را با خود پایین بکشد: مدارشکن‌های انفرادی برای هر عامل شعاع انفجار را محدود می‌کنند، و یک گوروتین پایشگر سلامت، بازیابی را حتی زمانی که هیچ درخواستی برای تحریک آن نمی‌رسد، هدایت می‌کند.
• اثبات درستی، نه فقط کامپایل. با یک اجرا‌کنندهٔ Challenge حل شد: ده‌ها ثابت در en/sr/ja/es/de که سیستم واقعی را آزمایش می‌کنند، به‌علاوه یک دروازهٔ جهش همزمان (LLMORCH_MUTATE_RUNNER=1 باید شکست بخورد → خروجی بسته‌بندی با کد ۹۹) که عمداً ویژگی را خراب می‌کند تا ثابت کند خود دروازه فریب نیست.
• بومی‌سازی بدون شکست خاموش. با درز NoopTranslator با شناسه‌های خام و تزریق مترجم به ازای هر مصرف‌کننده حل شد، به‌طوری که نبود ترجمه همیشه قابل‌مشاهده باشد و نه اینکه پنهان شود.

محتوا

• Go (نسخهٔ ۱٫۲۵) — به‌خاطر پشتیبانی درجه‌یک از همزمانی و کنترل دقیق پردازش‌ها انتخاب شده است؛ دقیقاً همان چیزی که هماهنگی فرایندهای زنده‌ی عامل‌ها نیاز دارد. این ابزار ماژول، آداپتورهای عامل، ترنسپورت‌ها و پارسر را پیاده‌سازی می‌کند.
• کتابخانهٔ استاندارد Go (به‌علاوهٔ testify و yaml.v3) — انتخابی آگاهانه برای کمینه نگه‌داشتن سطح وابستگی‌ها و عدم استفاده از هیچ‌یک از SDKهای LLM، تا ماژول سبک‌وزن باقی بماند و بتواند بدون کشیدن بار اضافی فروشنده، در هر مصرف‌کننده‌ای جاسازی شود.
• ترنسپورت پایپ (JSON-lines روی stdio) — برای پیام‌رسانی تعاملی سریع انتخاب شده است که با تعیین مهلت‌های خواندن و محدودیت‌های طول پاسخ تقویت شده تا یک عامل معلق یا سرکش نتواند فراخواننده را مسدود کند.
• ترنسپورت فایل (صندوق ورودی/خروجی/مشترک) — برای تبادل مصنوعات بزرگ و پایدار در هر جلسه انتخاب شده است، جایی که پایپ ابزار مناسبی نیست.
• sync.Mutex/sync.Cond — برای پیاده‌سازی دریافت عادلانه و مسدودکنندهٔ استخر عامل‌ها بدون انتظار فعال انتخاب شده‌اند.
• مدار قطع‌کننده + HealthMonitor — به‌طور مشترک برای ایجاد تاب‌آوری در سطح عامل و بازیابی فعال انتخاب شده‌اند، نه فقط تشخیص شکست.
• مترجم pkg/i18n — به‌عنوان درز محلی‌سازی جداشده انتخاب شده است تا رشته‌های خاص مصرف‌کننده از هسته جدا بمانند.
• چارچوب چالش (challenges/runner) + Makefile (test -race، fuzz، cover) — برای تأیید مبتنی بر شواهد و ضدحقه انتخاب شده‌اند، از جمله تشخیص شرایط رقابتی و فازی‌کردن پارسر تا درستی تحت شرایط خصمانه اثبات شود، نه اینکه صرفاً فرض شود.

• وضعیت: بتا. یک ماژول قابل‌استفادهٔ مجدد و جداشده که به‌عنوان زیرماژول در چندین پروژه از Helix/vasic مصرف می‌شود. مجوز: Apache-2.0؛ مخزن GitHub عمومی است.
• ابرداده‌های مدل از طریق HelixQA از LLMsVerifier پل زده می‌شود؛ این ماژول به‌طور مستقیم LLMsVerifier/VisionEngine/DocProcessor را وارد نمی‌کند. پشته‌های ذکرشده در CLAUDE.md اپلیکیشن والد (Gin/PostgreSQL و غیره) به helix_code اشاره دارند، نه این ماژول.

سطح اولویت: Helix-اصلی (خوشهٔ زیرساخت LLM — ماژول قابل‌استفادهٔ مجدد و جداشده). پس از HelixTrack قرار دارد.