مدل‌های زبانی بزرگ (LLMها) فناوری‌هایی فوق‌العاده قدرتمند هستند که از مدل‌های استدلال ریاضی برای ایجاد عامل‌های هوشمندی استفاده می‌کنند که قادرند از نوشتن مقالات تا توسعه‌ی پایگاه‌های کد پیچیده را انجام دهند. با قدرتمندتر شدن LLMها، بسیاری از کارشناسان به این فکر می‌کنند که آینده‌ای با خدمات «عامل‌محور» چگونه خواهد بود و این عامل‌ها چگونه با یکدیگر تعامل خواهند داشت.
یکی از راه‌حل‌های پیشنهادی برای این موضوع، Agent Mesh است. در ظاهر، مفهوم آن ساده به نظر می‌رسد شبکه‌ای از عامل‌ها که می‌توانند با یکدیگر همکاری کرده و یکدیگر را کشف کنند. اما همانند بسیاری از حوزه‌های دیگر در دنیای هوش مصنوعی، این مفهوم هنوز در مرحله‌ی آزمایشی قرار دارد.
در ادامه، به بررسی Agent Mesh می‌پردازیم تا بفهمیم چیست، چگونه کار می‌کند و آیا واقعاً به آن نیاز داریم یا خیر.
Agent Mesh چیست؟
مفهوم Agent Mesh ساده است، اما پیاده‌سازی آن بسیار پیچیده است. به‌صورت مفهومی، Agent Mesh یک لایه‌ی اجرایی یا زیرساختی است که به عامل‌ها اجازه می‌دهد یکدیگر را پیدا کنند، با هم ارتباط برقرار کنند و بر اساس یک سیاست یا مشخصات خاص، وظایف را به‌صورت هماهنگ به یکدیگر واگذار نمایند.
اگر این موضوع شبیه Service Mesh برای عامل‌های هوش مصنوعی به نظر می‌رسد، تصادفی نیست چراکه همان‌طور که پیاده‌سازی‌های عامل‌محور شبیه سیستم‌های API شده‌اند، ارتباطات میان آن‌ها نیز در حال شبیه شدن به همین الگوست.
ایده‌ی اصلی از این واقعیت نشأت می‌گیرد که عامل‌های مبتنی بر LLM برای اجرای جریان‌های کاری چندمرحله‌ای و پیچیده مورد استفاده قرار می‌گیرند — هماهنگی در انتقال داده، همکاری در پیاده‌سازی‌ها، و حتی فراخوانی عامل‌های LLM دیگر. این لایه‌ی ارکستراسیون در واقع یک سیستم توافقی است که اجازه می‌دهد این عامل‌ها بدون دخالت انسان با یکدیگر همکاری کنند.
ایجاد سیستم‌هایی با چندین عامل هوش مصنوعی چالش‌هایی در زمینه‌ی هماهنگی و امنیت ایجاد می‌کند. مفهوم Agent Mesh تلاش می‌کند برخی از مشکلات کلیدی را حل کند، از جمله:
-
اعتماد و مجوز میان عامل‌ها: همه‌ی عامل‌ها نباید بتوانند با همه‌ی عامل‌های دیگر تعامل یا تأثیرگذاری داشته باشند.
-
کشف سرویس: عامل‌ها باید بتوانند ابزار یا عامل مناسب برای یک وظیفه را پیدا کنند.
-
مدیریت وضعیت (State Management): حافظه‌ی مشترک لازم است تا عامل‌ها کار تکراری انجام ندهند یا تصمیمات ناسازگار نگیرند.
-
مقیاس‌پذیری: توسعه‌دهندگان باید راهی برای مقیاس‌دادن تعاملات چندعاملی در جریان‌های کاری داشته باشند بدون اینکه منطق ارکستراسیون شکننده شود.
معماری AgentMesh در Lyzr
راه‌حل Lyzr ایجاد یک اکوسیستم مبتنی بر بازارچه (Marketplace) است. در این روش، بازارچه به‌عنوان منبع مرکزی تمام عامل‌ها و جریان‌های کاری آن‌ها عمل می‌کند. به بیان دیگر، هر عامل می‌تواند از طریق این بازارچه، عامل‌های دیگر را جست‌وجو و انتخاب کرده و وظایف را به آن‌ها واگذار کند.
مشکل این رویکرد، وابستگی شدید به فروشنده است. این پیاده‌سازی خاصِ Lyzr باعث قفل شدن در پلتفرم می‌شود و تعامل عامل‌ها را محدود به بازارچه‌ی داخلی می‌کند. در نتیجه، استفاده از منابع متن‌باز یا سیستم‌های عمومی بدون بازارچه‌ی مشابه بسیار دشوار خواهد شد.
Solo.io
شرکت Solo.io که در حوزه‌ی Service Mesh شناخته شده است، الگوی Agent Mesh خود را معرفی کرده است. در این روش، از کنترل پلین‌ها (Control Planes) و سرورهای MCP برای ترکیب LLMها، درگاه‌های API و موتورهای سیاست‌گذاری از طریق یک درگاه عامل (Agent Gateway) استفاده می‌شود.
در واقع، این روش نسخه‌ای «عامل‌محور» از همان الگوی Service Mesh است.
نکته‌ی منفی این روش، پیچیدگی بیش از حد آن است. برای کاربرانی که فقط یک یا دو عامل را به هم متصل می‌کنند، پیاده‌سازی چنین زیرساخت عظیمی با کنترل‌پلین‌ها و لایه‌های سنگین منطقی به‌نظر نمی‌رسد. حتی در کاربردهای سازمانی بزرگ، این سطح از انتزاع ممکن است استقلال و انعطاف‌پذیری عامل‌ها را کاهش دهد.
Solace
Solace که در زمینه‌ی PubSub و Event Mesh تخصص دارد، راه‌حلی مبتنی بر معماری رویدادمحور (Event-Driven Architecture) برای اتصال عامل‌ها پیشنهاد کرده است. در این مدل، هر درخواست عامل در قالب یک «رویداد» در نظر گرفته می‌شود و سیستم از این رویدادها برای مسیردهی درخواست‌ها بین عامل‌ها استفاده می‌کند.
این روش از نظر مفهومی منطقی است، اما برای عامل‌های LLM همیشه مناسب نیست. بسیاری از عامل‌ها به‌صورت همزمان (Synchronous) و در قالب پاسخ به درخواست عمل می‌کنند، در حالی که معماری رویدادمحور بیشتر برای فرآیندهای ناهمزمان مناسب است.
علاوه بر این، عدم وجود حافظه‌ی اشتراکی حالت‌دار (Stateful Semantic Memory) در این رویکرد باعث می‌شود عامل‌ها نتوانند جریان‌های کاری چندمرحله‌ای با حافظه‌ی مشترک را حفظ کنند.
وضعیت کنونی Agent Meshها
هدف از نقدهای بالا رد کامل این راه‌حل‌ها نیست — بلکه نشان دادن این است که تمام این رویکردها در مراحل ابتدایی توسعه قرار دارند.
در حال حاضر، تعداد کمی از سازمان‌ها از سیستم‌های چندعاملی در مقیاس بالا استفاده می‌کنند. اغلب کاربران فقط یک یا دو عامل اصلی در زنجیره‌ی کاری خود دارند.
اما این وضعیت به‌زودی تغییر خواهد کرد. با رشد سیستم‌های Copilot سازمانی که چندین عامل LLM را برای حوزه‌هایی مانند فروش، منابع انسانی و پشتیبانی IT به کار می‌گیرند، نیاز به هماهنگی ساختارمند میان عامل‌ها افزایش می‌یابد.
آینده‌ی Agent Mesh
در حال حاضر، عبارت «Agent Mesh» ممکن است بیشتر شبیه به یک اصطلاح بازاریابی به نظر برسد، اما همین موضوع در گذشته برای «Service Mesh» نیز صادق بود. این مفهوم در واقع نشان‌دهنده‌ی یک نیاز معماری واقعی است — لایه‌ای اجرایی برای هماهنگی عامل‌های خودمختار در مقیاس بزرگ.
در آینده، تمرکز زیادی روی امنیت عامل‌محور (Agentic Security) خواهد بود. مسائل امنیتی مانند مدیریت هویت، وضعیت، اعتبارسنجی بار کاری، تزریق زمینه و اجرای سیاست‌ها از چالش‌های اصلی این فضا هستند.
به همین دلیل، Agent Mesh باید از ابتدا با در نظر گرفتن امنیت طراحی شود تا هم ارتباط بین عامل‌ها برقرار باشد و هم اعتماد میان آن‌ها حفظ گردد.
در نهایت، چه اصطلاح Agent Mesh باقی بماند یا تغییر کند، نیازهای اصلی آن — کشف عامل‌ها، ارتباط میان آن‌ها، و حاکمیت (Governance) — پابرجا خواهند ماند. با گسترش استفاده از عامل‌های هوش مصنوعی، انتظار می‌رود Agent Mesh به یکی از ارکان اساسی زیرساخت‌های هوش مصنوعی تبدیل شود.
