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

HelixAgent betaاجازه‌نامه: MIT

GoGinPostgreSQLRedisLLMsVerifierPrometheusGrafanaOpenTelemetryModel Context ProtocolNeo4jClickHouseKafka

منبع

• HelixDevelopment/HelixAgent

// معماری

به جای انتخاب یک مدل، بگذارید با هم بحث کنند و پاسخی را که بر سر آن توافق دارند ارائه دهند.

HelixAgent یک سرویس آماده‌ی تولید مبتنی بر مجموعه‌ای از مدل‌ها (LLM) و با قدرت AI در Go است که پاسخ‌های چندین مدل زبانی را به شکلی هوشمندانه ترکیب می‌کند — از جمله یک سیستم بحث چندمرحله‌ای AI و انتخاب پویای ارائه‌دهندگان بر اساس تأیید — تا خروجی دقیق و قابل‌اعتماد تولید کند.

HelixAgent یک سرویس مجموعه‌ای مبتنی بر Go است که چندین ارائه‌دهنده را در یک پاسخ دقیق ادغام می‌کند. این سرویس بحث‌های چندمرحله‌ای AI را اجرا می‌کند، ارائه‌دهندگان را به صورت پویا از طریق LLMsVerifier امتیازدهی می‌کند، با استراتژی‌های مسیریابی مبتنی بر اطمینان هدایت می‌کند و ویژگی‌های تولیدی را ارائه می‌دهد: کش، نظارت، محافظ‌های امنیتی و APIهای به سبک OpenAI.

HelixAgent یک سرویس آماده‌ی تولید مبتنی بر مجموعه‌ای از مدل‌ها (LLM) با قدرت AI (تحت مجوز MIT) است که پاسخ یک مدل را به عنوان فرضیه در نظر می‌گیرد، نه حکم قطعی. به جای تکیه بر یک ارائه‌دهنده که ممکن است اشتباه کند، سوگیری داشته باشد یا موقتا در دسترس نباشد، پاسخ‌های چندین مدل زبانی را ترکیب می‌کند تا به دقیق‌ترین و قابل‌اعتمادترین خروجی دست یابد — و وقتی سوالی به اندازه‌ی کافی دشوار باشد، مدل‌ها را در یک بحث ساختاریافته و چندمرحله‌ای قرار می‌دهد. فهرست ارائه‌دهندگان گسترده است: فایل README این سرویس، بسیاری از ارائه‌دهندگان LLM را در مسیر internal/llm/providers/ مستند کرده است، از جمله Claude، DeepSeek، Gemini، Mistral، Qwen و xAI/Grok.

نکته‌ی کلیدی این است که انتخاب ارائه‌دهنده نه بر اساس فهرستی ثابت از اولویت‌ها، بلکه به صورت بلادرنگ و بر اساس عملکرد انجام می‌شود. امتیازهای تأیید زنده از یک LLMsVerifier یکپارچه، مسیریابی و جایگزینی هوشمندانه با بهترین ارائه‌دهنده‌ی در حال کار را هدایت می‌کند و در صورت افت کیفیت یکی از ارائه‌دهندگان، گزارش خطای دسته‌بندی‌شده ارائه می‌دهد. هماهنگ‌کننده‌ی بحث AI اختلاف‌نظرها را به سیگنال تبدیل می‌کند: از توپولوژی‌های مختلف (مش، ستاره، زنجیره) پشتیبانی می‌کند و پروتکل مرحله‌ای منظمی دارد — پیشنهاد → نقد → بازبینی → ترکیب — با یادگیری بین‌بحثی تا سیستم در تطبیق مدل‌ها به مرور بهتر شود. استراتژی‌های مسیریابی شامل انتخاب مبتنی بر اطمینان، اجماع رأی اکثریت و تشخیص معنایی قصد کاربر است که همگی با جریان بلادرنگ پاسخ‌ها همراه هستند تا پاسخ‌ها به جای انتظار برای تکمیل کل مجموعه، توکن به توکن ارائه شوند.

این سرویس برای بقا در محیط تولید طراحی شده است، نه فقط نمایش خوب در دموها: PostgreSQL و Redis یک لایه‌ی داده با دسترسی بالا را تشکیل می‌دهند، Prometheus، Grafana و OpenTelemetry معیارها، داشبوردها و ردیابی را فراهم می‌کنند و احراز هویت JWT، محدودیت نرخ، موتور محافظ‌ها و تشخیص PII، مجموعه را در چارچوبی از کنترل‌های لازم برای استقرار واقعی قرار می‌دهند. این سرویس به صورت حدود بیست ماژول جداگانه سازماندهی شده است (EventBus، Observability، Auth، Storage، VectorDB، Embeddings، RAG، Memory، MCP و غیره) که هر یک دغدغه‌ای مجزا را پوشش می‌دهند و یک چارچوب بهینه‌سازی LLM (کش معنایی، خروجی ساختاریافته، جریان پیشرفته) را ارائه می‌دهد که با SGLang، LlamaIndex، LangChain، Guidance و LMQL یکپارچه شده است. از آنجا که نقاط پایانی تکمیل و مجموعه با OpenAI سازگار هستند، یک کلاینت موجود می‌تواند بدون نیاز به بازنویسی، به HelixAgent متصل شود و از استدلال مجموعه‌ای بهره‌مند گردد.

محتوا

هر مدل LLM به‌تنهایی ممکن است نادرست، مغرضانه یا در دسترس نباشد. HelixAgent ساخته شد تا برنامه‌ها بتوانند همزمان به چندین مدل مراجعه کنند، پاسخ‌های آن‌ها را بر اساس قابلیت اطمینان اندازه‌گیری‌شده بسنجند و با ظرافت جایگزین کنند — و بدین ترتیب وابستگی شکننده به یک ارائه‌دهنده واحد را به مجموعه‌ای انعطاف‌پذیر و خودارزیاب تبدیل کنند.

این سامانه اجماع چندمدلی را عملیاتی می‌کند — یعنی «پرسیدن از چندین مدل و تطبیق پاسخ‌ها» را از اسکریپت‌های موقتی به یک سرویس تولیدی منتقل می‌کند. به‌جای کدنویسی سخت برای یک ارائه‌دهنده و امید به بهترین‌ها، تیم‌ها مسیریابی مبتنی بر امتیازهای تأیید زنده دریافت می‌کنند، پروتکل مناظره ساختاریافته برای پرسش‌هایی که یک بار پاسخگویی کافی نیست، و تاب‌آوری در سطح تولید (لایه داده با دسترسی بالا، قابلیت رصد کامل و محافظ‌های امنیتی) — همه پشت یک OpenAI سازگار با API. دستاورد اصلی این است که بدون ایجاد اختلال در روند کار، وابستگی شکننده به یک ارائه‌دهنده به مجموعه‌ای انعطاف‌پذیر و خودارزیاب تبدیل می‌شود و مشتریان موجود تنها با تغییر یک نقطه پایانی (endpoint) به آن مهاجرت می‌کنند، نه تغییر کد.

• مناظره AI چندمرحله‌ای ساختاریافته که اختلاف‌نظر مدل‌ها را به‌عنوان منبعی ارزشمند تلقی می‌کند: توپولوژی‌های قابل انتخاب مش/ستاره/زنجیره‌ای، پروتکل منظم پیشنهاد→نقد→بازبینی→ترکیب، و یادگیری بین‌مناظره‌ای که با گذشت زمان انباشته می‌شود.
• انتخاب پویای ارائه‌دهنده بر اساس امتیازهای زنده LLMsVerifier به‌جای فهرست ترجیحی ثابت — مجموعه به سمتی هدایت می‌شود که در حال حاضر عملکرد بهتری دارد و در صورت افت کیفیت یک ارائه‌دهنده، با ظرافت جایگزین می‌شود.
• چارچوب بهینه‌سازی بومی Go برای LLM (کش معنایی، خروجی ساختاریافته، جریان‌سازی پیشرفته) که به‌تنهایی کارآمد است و بهینه‌سازهای خارجی اختیاری (SGLang، LlamaIndex، LangChain، Guidance، LMQL) را می‌توان در صورت نیاز به آن افزود، نه اینکه اجباری باشند.
• معماری مدولار متشکل از حدود بیست ماژول جداگانه که جداسازی دغدغه‌ها را ممکن می‌سازد و راه را برای ویژگی‌های کلان‌داده مانند حافظه توزیع‌شده و جریان‌سازی گراف دانش باز می‌کند.

• انتخاب از میان ارائه‌دهندگان نابرابر. ارائه‌دهندگان از نظر کیفیت متفاوت‌اند و با گذشت زمان دچار تغییر می‌شوند، بنابراین هر رتبه‌بندی ثابتی فردا نادرست خواهد بود. ما این مشکل را با انتخاب مبتنی بر اندازه‌گیری مستمر حل کردیم: امتیازهای LLMsVerifier به مسیریابی مبتنی بر رأی اکثریت و وزن‌دهی اعتماد تغذیه می‌شوند و در صورت افت کیفیت یک ارائه‌دهنده، به‌جای اعتماد به آن، با ظرافت جایگزین می‌شود.
• دریافت پاسخ قابل اعتماد برای پرسش‌های واقعاً دشوار. یک مدل تنها، در یک بار پرسش، مکانیزمی برای تشخیص خطای خود ندارد. هماهنگ‌کننده مناظره این مکانیزم را فراهم می‌کند — مناظره چندتوپولوژی و مرحله‌ای (پیشنهاد → نقد → بازبینی → ترکیب) که مدل‌ها را وادار می‌کند پیش از ارائه پاسخ نهایی، یکدیگر را به چالش بکشند و اصلاح کنند.
• اجرای مجموعه‌ای از مدل‌ها در محیط تولید، نه فقط در یک نوت‌بوک. ارسال پرسش به چندین ارائه‌دهنده سطح شکست را چندبرابر می‌کند. ما این مشکل را با لایه داده PostgreSQL+Redis با دسترسی بالا، قابلیت رصد Prometheus/Grafana/OpenTelemetry برای تشخیص رفتار نادرست ارائه‌دهنده یا مسیر، و محیط امنیتی شامل احراز هویت JWT، محدودیت نرخ، موتور محافظ‌ها و تشخیص PII مهار کردیم.

محتوا

• Go — انتخاب شده زیرا ارسال یک درخواست به چندین ارائه‌دهنده به‌طور همزمان دقیقاً همان کاری است که گوروتین‌ها برای آن طراحی شده‌اند، و استقرار تک‌باینری باعث می‌شود سرویس با حدود ۲۰ ماژول به‌سادگی قابل ارسال باشد؛ این فناوری زیربنای کل سرویس و هر ماژول داخلی است.
• Gin (وب API) — انتخاب شده برای ارائه یک سطح HTTP سریع و کم‌بار؛ این فناوری نقاط پایانی سازگار با OpenAI برای تکمیل /v1، چت، استریم و تجمیع را ارائه می‌دهد که به کاربران موجود امکان می‌دهد بدون تغییر از تجمیع استفاده کنند.
• PostgreSQL — انتخاب شده به‌عنوان ذخیره‌ساز پایدار برای جلسات، تحلیل‌ها و سوابق مناظره‌ها، تا تصمیمات اجماع و تاریخچه مناظره‌ها قابل حسابرسی باشد؛ این فناوری لایه داده با دسترسی بالا را تثبیت می‌کند.
• Redis — انتخاب شده برای کشینگ کم‌تأخیر و صف‌بندی وظایف؛ این فناوری هم کشینگ پاسخ‌ها و هم لایه کش معنایی را تقویت می‌کند که به درخواست‌های تکراری یا تقریباً تکراری اجازه می‌دهد از استنتاج‌های زائد عبور کنند.
• LLMsVerifier (یکپارچه) — انتخاب شده تا قابلیت اطمینان ارائه‌دهندگان به جای یک فرض، کمیتی قابل اندازه‌گیری باشد؛ امتیازهای آن ارائه‌دهندگان را برای مسیریابی رتبه‌بندی کرده و در صورت افت کیفیت یکی از آن‌ها، جایگزینی را فعال می‌کند.
• Prometheus + Grafana + OpenTelemetry — انتخاب شده تا تجمیعی که چندین ارائه‌دهنده را در بر می‌گیرد، قابل مشاهده باقی بماند؛ این فناوری معیارهای helixagent_*، داشبوردها و ردیابی درخواست‌های سرتاسری در فرآیند پخش را نمایش می‌دهد.
• آداپتورهای Model Context Protocol (MCP) — انتخاب شده برای قابلیت توسعه از طریق یک پروتکل باز؛ فایل README فهرستی از آداپتورهای MCP برای اتصال ابزارها و زمینه‌های خارجی را ارائه می‌دهد.
• Neo4j / ClickHouse / Kafka (کلان‌داده) — انتخاب شده برای عبور از محدودیت تک‌نود: Neo4j و ClickHouse حافظه توزیع‌شده و ویژگی‌های گراف دانش را پشتیبانی می‌کنند، و Kafka این گراف و داده‌های رویداد را در مقیاس بزرگ استریم می‌کند.
• ادغام‌های بهینه‌سازی (SGLang، LlamaIndex، LangChain، Guidance، LMQL) — انتخاب شده برای افزودن کش پیشوندی، بازیابی، تجزیه وظایف و تولید محدود به‌عنوان سرویس‌های اختیاری، تا بهینه‌سازی‌های سنگین‌تر بدون اجبار در دسترس باشند.

• وضعیت: بتا. این سرویس به‌عنوان آماده تولید توصیف شده است، اما ارقام عملکرد و پوشش در فایل README (مانند «بیش از ۱۰۰۰ درخواست در ثانیه»، «کمتر از ۵۰۰ میلی‌ثانیه برای درخواست‌های کش‌شده»، تعداد ارائه‌دهندگان و اسکریپت‌های اعتبارسنجی) ادعاهای خود پروژه هستند و به‌طور مستقل تأیید نشده‌اند و در اینجا عمداً کیفی نگه داشته شده‌اند.
• تعداد ارائه‌دهندگان در خود فایل README متفاوت است؛ این صفحه از چارچوب کیفی «تعداد زیادی ارائه‌دهنده» استفاده می‌کند.

اولویت لایه: Helix-اصلی.