اگر امروز یک عامل هوش مصنوعی را برای مدیریت تسک‌های چندمرحله‌ای به کار می‌گیرید، احتمالاً با پدیده «فراموشی نشست» مواجه شده‌اید؛ جایی که مدل در گام سوم، خروجی گام اول را کاملاً فراموش می‌کند. دلیل اصلی این اتفاق، رویکرد «چرخش به سمت بدون‌وضعیت» (Stateless Turn) است که باعث می‌شود عامل‌های هوش مصنوعی معمولاً تاریخچه گفتگو و خروجی‌های قبلی ابزارها را فراموش کنند. پروژه Swarm با یک معماری یکپارچه بر پایه زبان Rust، این نقص ساختاری را با حذف «نوبت‌های بدون وضعیت» برطرف کرده است.
Swarm این مشکل را از طریق یک سیستم واحد مبتنی بر Tokio حل می‌کند که درگاه مدل (Model Gateway) و زمان‌اجرای ارکستراسیون را با هم ادغام می‌کند. با حذف شکاف عملیاتی که معمولاً تیم‌ها را مجبور می‌کند لایه‌های پروکسی و اجرای مجزایی را مستقر کنند، این پروژه از تکرار استخرهای اتصال (Connection Pools)، لایه‌های احراز هویت و پیکربندی‌های ارائه‌دهنده که اغلب استقرار‌های چندعاملی را دچار مشکل می‌کند، جلوگیری می‌کند.
همان‌طور که در تحلیل قبلی ما درباره‌ی یکپارچه‌سازی درگاه‌های مدل از طریق JSON اشاره کردیم، Swarm فراتر از مسیریابی ساده حرکت می‌کند. این پروژه به یک نقص بنیادی در اکثر حلقه‌های عاملی می‌پردازد: تمایل به مقداردهی اولیه هر نوبت اجرا از صفر. در تنظیمات استاندارد، عامل‌ها اغلب نوبت‌های قبلی را دور می‌اندازند و این منجر به «آمنزیا یا فراموشی نشست» می‌شود؛ وضعیتی که در آن سوالات تکمیلی شکست می‌خورند زیرا به محض پایان یک درخواست، زمینه (Context) ناپدید می‌شود. این وضعیت اغلب توسط «لاگ‌گذاری فقط-برای-نوشتن» (Write-only logging) تشدید می‌شود، جایی که ویژگی‌های حافظه تنها گزارشاتی را برای تله‌متری ثبت می‌کنند اما هیچ مکانیسم بازیابی اطلاعاتی به عامل ارائه نمی‌دهند. همچنین پدیده «اتصال سخت پرامپت» (Prompt Coupling) که در آن تاریخچه به صورت دستی در هندلر HTTP الحاق می‌شود، این مشکل را وخیم‌تر می‌کند.
طبق گزارش فنی منتشر شده در ۹ سپتامبر ۲۰۲۶، معماری Swarm در دو حالت مکمل عمل می‌کند که از یک هسته زمان‌اجرای واحد استفاده می‌کنند. حالت اول، ارکستراسیون چندعاملی و پروتکل زمینهٔ مدل (MCP) است (که در مسیر kickstart/multi_agent_orchestration_kickstart/ قرار دارد). در این حالت، یک «عامل برنامه‌ریز» (Planner Agent) برای تولید گراف‌های جهت‌دار بدون دور (DAG) پویا و یک «عامل اجراکننده» (Executor Agent) برای حل وابستگی‌ها و اعزام اجرای گام‌ها به کار گرفته می‌شود. این حالت از پروتکل MCP برای مدیریت ابزارها از طریق I/O استاندارد، رویدادهای ارسالی سرور (SSE) یا ترنسپورت‌های HTTP قابل استریم استفاده می‌کند. همچنین شامل «متخصصان دامنه» (Domain Specialists) و یک سرویس ارزیابی اختیاری است؛ یک مرحله اعتبارسنجی LLM-as-a-Judge که خروجی ابزارها را ارزیابی کرده و در صورت بدشکل بودن نتایج، درخواست اصلاح می‌کند.
حالت دوم، یک درگاه مدل سازگار با OpenAI است (که در مسیر kickstart/gateway_kickstart/ قرار دارد). این سرور سازگاری کاملی (Drop-in compatibility) برای SDKهای موجود، افزونه‌های IDE و خط لوله‌های کلاینت از طریق مسیر /v1/chat/completions فراهم می‌کند و از زنجیره‌سازی وضعیت‌دار از طریق /v1/responses پشتیبانی می‌کند که نوبت‌ها را با استفاده از شناسه‌های پاسخ (Response IDs) صریح مرتبط می‌سازد. این درگاه از طریق پیکربندی TOML، مسیریابی یکپارچه ارائه‌دهندگان را برای APIهای تجاری مانند Groq، Google Gemini و OpenAI و همچنین زمان‌اجراهای محلی شامل Ollama، vLLM و llama.cpp فراهم می‌کند.
از آنجایی که هر دو حالت از یک زمان‌اجرا مشترک استفاده می‌کنند، آن‌ها از استخر اتصال، مدیریت اسرار (Secret Management)، تله‌متری ردیابی و کشینگ بدون قفل (Lock-free caching) با توان عملیاتی بالا بهره می‌برند که در یک استقرار «Full Swarm»، پرش‌های شبکه (Network Hops) را به صفر می‌رساند.
موتور زمینه چهارلایه
برای ریشه‌کن کردن مشکل حافظه، Swarm یک موتور زمینه (Context Engine) قابل تعویض را پیاده کرده است که به چهار لایه عملیاتی متمایز تقسیم می‌شود:
- زمینه کاری گفتگو (Conversational Working Context): مدیریت وضعیت فوری نشست‌های چند-نوبتی و رشته‌های گفتگو.
- حافظه معنایی و بلندمدت (Long-Term & Semantic Memory): ذخیره ترجیحات کاربر و حقایق کلیدی برای بازیابی از طریق یک مخزن اختصاصی به نام
db_facts. - زمینه هویت و امنیت (Sovereign Identity & Security Context): تزریق نقش‌ها، سطوح دسترسی، شناسایی مستاجر (Tenant ID) و مجوزهای فعال در یک بلوک
<identity_context>. - دانش رویه‌ای و مهارت (Procedural & Skill Knowledge): ارائه کتاب‌های راهنمای دامنه (Runbooks) و توالی‌های ایمن ابزارها برای اطمینان از اینکه مدل در چارچوب مرزهای مجوز باقی می‌ماند.
این سیستم از یک انتزاع به نام ContextProvider در لایه مشترکات (Commons) استفاده می‌کند. این Trait شامل یک متد enrich_context برای تغییر پیام‌ها پیش از مرحله تفکر LLM و یک هوک on_turn_complete برای ثبت گفتگو یا استخراج حقایق پایدار پس از پایان نوبت است.
جزئیات اسمبل کردن زمینه
خط لوله اجرا برای ساخت پرامپت نهایی، توالی سخت‌گیرانه‌ای را دنبال می‌کند:
- لایه پایه: با پرامپت سیستمی پایه (Base System Prompt) آغاز می‌شود.
- تزریق هویت: ارائه‌دهنده هویت (Identity Provider) بلوک هویت را تزریق می‌کند.
- تزریق مهارت: ارائه‌دهنده مهارت (Skill Provider) کتاب‌های راهنمای ابزار را اضافه می‌کند.
- بازیابی حقایق: ارائه‌دهنده حافظه حقایق (Fact Memory Provider) حقایق مرتبط را از پایگاه‌داده بازیابی می‌کند.
- بارگذاری تاریخچه: ارائه‌دهنده تاریخچه (History Provider) یک پنجره لغزان از نوبت‌های قبلی را بارگذاری می‌کند.
- ورودی فعلی: نوبت فعلی کاربر در آخرین مرحله الحاق می‌گردد.
پس از اینکه McpAgent چرخه اجرای خود را (تفکر $
ightarrow$ اجرای ابزارها $
ightarrow$ پاسخ دستیار) به پایان رساند، یک عملیات «تخلیه پس از نوبت» (Post-Turn Flush) رخ می‌دهد. این عملیات، نوبت‌های کاربر و دستیار را در MemoryService ذخیره کرده و متد on_turn_complete را در تمام ارائه‌دهندگان زمینه فعال فراخوانی می‌کند.
پیاده‌سازی فنی در Rust
انتخاب زبان Rust برای عملکرد سیستم حیاتی است. توسعه‌دهندگان از رشته‌های Worker در Tokio و جداول حافظه مبتنی بر DashMap استفاده کرده‌اند تا وضعیت‌های مشترک را در نشست‌های همزمان بدون تداخل قفل‌های سراسری (Global Lock Contention) مدیریت کنند. این کار باعث می‌شود مالکیت حافظه پیش‌بینی‌پذیر باشد و از جهش‌های ناگهانی مصرف حافظه (GC Spikes) که در درخواست‌های استریم با توکن‌های بالا رایج است، جلوگیری شود. علاوه بر این، استفاده از Structهای با تایپ سخت‌گیرانه برای مرزهای پیام‌های Agent-to-Agent (A2A) و MCP اجازه می‌دهد تا ناهماهنگی‌های سریال‌سازی و طرح‌واره (Schema) در زمان کامپایل شناسایی شوند، نه در حین اجرای یک جریان کاری خودکار.
برای مدیریت تاریخچه، HistoryContextProvider متد MemoryService::get_conversation(session_id, limit) را برای واکشی $N$ نوبت آخر فراخوانی می‌کند که مقدار $N$ از طریق TOML قابل تنظیم است. برای جلوگیری از عبور از محدودیت‌های پنجره زمینه LLM، نوبت‌های قدیمی‌تر کوتاه یا فشرده می‌شوند. در محیط‌های لبه (Edge)، سیستم به جای استفاده از Embeddingهای برداری سنگین، از تطبیق حقایق کلید-مقدار (بر اساس کلید، تگ و زیررشته‌های پرس‌وجو) استفاده می‌کند تا سربار عملیاتی کاهش یابد.
انعطاف در استقرار
Swarm دو الگوی استقرار اصلی ارائه می‌دهد تا از تجزیه زودهنگام به میکروسرویس‌ها جلوگیری کند:
۱. Full Swarm: اجرای برنامه‌ریز، اجراکننده، متخصصان دامنه با سرورهای ابزار MCP و درگاه در یک فایل باینری واحد. این یک محیط خودمختار سرتاسری می‌سازد که در آن عامل‌ها مستقیماً از طریق درگاه محلی با LLMها ارتباط برقرار می‌کنند.
۲. Gateway-Only Swarm: حذف لایه ارکستراسیون برای تبدیل شدن به یک پروکسی استنتاج با کارایی بالا، دارای قابلیت Failover ارائه‌دهنده، کشینگ و زنجیره‌سازی پاسخ‌های وضعیت‌دار برای برنامه‌های کلاینت خارجی.
این رویکرد به تیم‌ها اجازه می‌دهد ابتدا به صورت یکپارچه شروع کنند و تنها در صورتی درگاه را به یک سرویس مستقل تبدیل کنند که ترافیک ۱۰۰ برابر سریع‌تر از ارکستراسیون رشد کند یا الزامات امنیتی، جداسازی اجرای ابزارها را در شبکه‌های خصوصی ایجاب کند. برای تضمین پایداری، تمام متدها در Trait مربوط به MemoryService پیاده‌سازی‌های پیش‌فرض no-op دارند؛ به این معنی که عامل‌های بدون سرویس حافظه پیکربندی شده، همچنان در حالت بدون وضعیت و بدون هیچ‌گونه افت عملکردی به کار خود ادامه می‌دهند.
موازنه و محدودیت‌ها
فعال‌سازی این قابلیت‌ها به صورت Declarative در پیکربندی انجام می‌شود. برای مثال، کاربر می‌تواند agent_mcp_history_length = 10 را تنظیم کرده و گزینه‌های agent_mcp_enable_memory_recall و agent_mcp_enable_identity_context را در بخش [agent_mcp] فایل TOML روی true قرار دهد.
با این حال، این معماری با موازنه‌های مداومی روبروست. در حالی که پنجره لغزان سریع و قطعی (Deterministic) است، اما در نهایت جزئیات قدیمی‌تر را حذف می‌کند. توسعه‌دهندگان اشاره کرده‌اند که یک فشرده‌ساز بازگشتی (Recursive Compactor) می‌تواند نوبت‌ها را به یک خلاصه روایتی تبدیل کند، اما این کار باعث افزایش تأخیر و هزینه‌های استنتاج می‌شود. به طور مشابه، در حالی که ذخیره‌سازی کلید-مقدار برای محیط‌های لبه مناسب است، اما مجموعه‌های داده بدون ساختار در مقیاس بزرگ همچنان به Embeddingهای برداری نیاز دارند.
این تغییر در معماری، فرض‌های این حوزه را درباره وضعیت عامل تغییر می‌دهد. Swarm با تبدیل زمینه به یک خط لوله چندلایه به جای یک آرایه ساده از پیام‌ها، ثابت کرد که حافظه پایدار عامل را می‌توان بدون قربانی کردن سازگاری با نسخه‌های قدیمی یا معرفی تأخیر قابل توجه پیاده کرد.
برای توسعه‌دهندگان، این بدان معناست که ماهیت «بدون وضعیت» LLMها دیگر یک محدودیت سخت برای جریان‌های کاری عامل‌محور نیست. توانایی تزریق هویت و دانش رویه‌ای به عنوان لایه‌های مجزا، امکان استفاده ایمن‌تر و پیش‌بینی‌پذیرتر از ابزارها را در محیط‌های سازمانی فراهم می‌کند.
توسعه‌دهندگان اکنون می‌توانند پیاده‌سازی Swarm را در گیت‌هاب تحت لایسنس Apache-2.0 بررسی کنند تا قراردادهای زمان‌اجرای MCP را تست نمایند. سوال حیاتی بعدی برای جامعه این است که آیا فشرده‌سازی بازگشتی در نهایت جایگزین رویکرد پنجره لغزان برای حافظه واقعاً بلندمدت عامل‌ها خواهد شد یا خیر.
گام بعدی شما
- مخزن Swarm را در گیت‌هاب بررسی کنید و قراردادهای زمان‌اجرای MCP را تست نمایید.
- اگر از سیستم‌های چندعاملی استفاده می‌کنید، لایه‌های هویت و مهارت را از تاریخچه گفتگو جدا کنید تا دقت مدل افزایش یابد.
- برای محیط‌های Edge، استراتژی تطبیق کلید-مقدار را جایگزین Vector DBهای سنگین کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو