تصور کنید دو عامل هوش مصنوعی برای انتقال یک فایل حساس یا مذاکره بر سر یک وظیفه، مجبور باشند تمام پیام‌های خود را از طریق یک دفترخانه مرکزی ارسال کنند. اگر این دفترخانه برای لحظه‌ای از دسترس خارج شود، کل عملیات متوقف می‌شود؛ این دقیقاً همان نقطه‌ضعفی است که معماری‌های متمرکز در دنیای سیستم‌های خودمختار ایجاد می‌کنند. در حالی که MQTT استاندارد صنعتی اینترنت اشیا (IoT) است، اجبار به عبور گفتگوهای نقطه‌به‌نقطه از یک واسطه، شکنندگی شدیدی به سیستم می‌بخشد، به‌ویژه در جاهایی که سیستم‌های خودمختار بیشترین حساسیت را دارند. یک واسطه متمرکز در لحظه‌ای که دو عامل هوش مصنوعی نیاز به مذاکره برای تحویل یک وظیفه یا انتقال یک فایل دارند، به یک نقطه ضعف بحرانی تبدیل می‌شود. MQTT در آنچه برایش طراحی شده — یعنی پخش رویدادها از یک منبع به بسیاری از گیرنده‌ها (Many-to-Many Event Fan-out) — عالی است، اما پیام‌رسانی مبتنی بر واسطه (Broker-based) و لایه‌های همتا‌به‌همتا (P2P Overlay) در واقع دو مسئله کاملاً متفاوت را حل می‌کنند.
این تنش معماری درست زمانی رخ می‌دهد که توسعه‌دهندگان از چت‌بات‌های ساده به سمت دسته‌های پیچیده از عامل‌های هوش مصنوعی (AI Agents) — شبیه به تیمی از متخصصان که هر کدام وظیفه خاصی دارند و باید با هم هماهنگ شوند — حرکت می‌کنند. همان‌طور که در تحلیل قبلی ما درباره‌ی ProtoLink و تغییر توپولوژی‌های ارتباطی اشاره کردیم و دیدیم که چگونه این توپولوژی‌ها بر تصمیمات نهایی هوش مصنوعی اثر می‌گذارند، صنعت اکنون با لایه فیزیکیِ نحوه یافتن و اعتماد متقابل این عامل‌ها دست‌وپنجه نرم می‌کند. برای اکثر توسعه‌دهندگان، انتخاب بین مدل «مرکز و پره» (Hub-and-Spoke) و مدل «مش» (Mesh) است.
نقاط قوت واسطه‌های مرکزی
به نقل از تحلیل فنی منتشر شده در ۱۵ اوت ۲۰۲۶ در وب‌سایت dev.to، پروتکل MQTT در پخش رویدادهای چندبه‌چند تخصص دارد. این یک پروتکل انتشار/اشتراک (Pub/Sub) است که روی TCP اجرا می‌شود و در آن کلاینت‌ها به‌جای اتصال به یکدیگر، به یک واسطه مانند Mosquitto، EMQX، HiveMQ یا AWS IoT Core متصل می‌شوند. در این ساختار، یک ناشر پیام را به یک موضوع (Topic) مانند agents/fleet-1/status می‌فرستد و واسطه آن را برای تمام مشترکین پخش می‌کند.
این مدل چهار مزیت اصلی برای بارهای کاری خاص فراهم می‌کند:
- کارایی پخش (Fan-out): یک عامل رویدادی را منتشر می‌کند و واسطه کپی و توزیع آن را برای صدها مشترک مدیریت می‌کند. این یک قابلیت کلیدی است که سیستم‌های همتا‌به‌همتا نمی‌توانند به همان اندازه تمیز و بهینه پیاده‌سازی کنند. این رویکرد در واقع زیربنای معماری‌های جدید لایه نشر برای حل شکست‌های سیستمی است که اجازه می‌دهد مقیاس‌پذیری در توزیع محتوا بهینه شود.
- جداسازی (Decoupling): ناشران نیازی ندارند بدانند چه کسی گوش می‌دهد. یک عامل می‌تواند بدون اهمیت دادن به اینکه آیا مصرف‌کننده آنلاین است، در همان ابر قرار دارد یا حتی هنوز کدنویسی و ساخته نشده است، پیام خود را در یک موضوع منتشر کند.
- معناشناسی تحویل: سطوح QoS (کیفیت سرویس) ۰، ۱ و ۲ تحویل پیام را به صورت «حداکثر یک‌بار»، «حداقل یک‌بار» یا «دقیقاً یک‌بار» تضمین می‌کنند. علاوه بر این، پیام‌های «مانده» (Retained Messages) به مشترکین جدید اجازه می‌دهند بلافاصله آخرین وضعیت را مشاهده کنند، در حالی که پیام‌های «وصیت» (Last-will) در صورت مرگ یا قطع اتصال یک عامل، کل ناوگان را مطلع می‌کنند.
- سازگاری با NAT: عامل‌های پشت دیواره‌های آتش فقط نیاز به برقراری اتصال خروجی به واسطه دارند و نیازی به IP عمومی یا باز کردن پورت‌های ورودی نیست. تا زمانی که واسطه در دسترس باشد، عامل‌ها نیازی به آدرس‌های عمومی ندارند.
جایی که مدل شکست می‌خورد
مشکلات زمانی آغاز می‌شوند که ارتباطات واقعاً نقطه‌به‌نقطه باشند. انتقال وظایف، فراخوانی ابزارها و مذاکرات، در واقع گفتگوهای یک‌به‌یک هستند که فقط نام یک «موضوع» را پوشش داده‌اند. در این حالت، واسطه تنها یک گام اضافی (Extra Hop) و یک نقطه شکست واحد (Single Point of Failure) است. تمام ترافیک از واسطه عبور می‌کند، حتی اگر دو عامل روی یک ماشین فیزیکی باشند. اگر واسطه سقوط کند، تمام عامل‌ها از کار می‌افتند. اگرچه واسطه‌ها را می‌توان به صورت خوشه‌ای (Clustered) پیاده کرد، اما این کار صرفاً به این معناست که توسعه‌دهنده اکنون باید زیرساخت پیچیده‌ای را مدیریت کند که همچنان یک وابستگی مشترک برای هر عامل باقی می‌ماند.
محدودیت‌های شناسایی و دسترسی
شناسه در MQTT محدود به واسطه است؛ یعنی یک Client ID فقط برای آن واسطه خاص معنا دارد. این وضعیت منجر به گسستگی در شناسایی می‌شود:
- انزوا: دو عامل که روی دو واسطه مختلف هستند، نمی‌توانند بدون پیاده‌سازی پل‌های ارتباطی (Bridges) به‌طور کلی یکدیگر را خطاب قرار دهند.
- شناسه زودگذر: هیچ مفهومی از یک شناسه‌ی جهانی وجود ندارد که با جابجایی عامل بین سرورها یا محیط‌ها او را دنبال کند؛ شناسایی با قطع اتصال به واسطه می‌میرد.
- الزام NAT: در حالی که کلاینت‌ها اتصال خروجی برقرار می‌کنند، آن‌ها فقط می‌توانند به واسطه متصل شوند. اگر عامل‌ها در ابرهای مختلف، شبکه یک شریک تجاری یا یک لپ‌تاپ خانگی پراکنده باشند، واسطه باید برای همه آن‌ها به‌صورت عمومی در دسترس باشد. این یعنی جابجایی پورت‌فوروارینگ هر عامل با یک مؤلفه عمومی عظیم و همیشه روشن.
شکاف اعتماد
اعتماد در این مدل نیز متمرکز و کلی است. در مدل واسطه، واسطه کلاینت‌ها را احراز هویت می‌کند و زنجیره امنیتی در همین‌جا تمام می‌شود. عامل A هرگز عامل B را تأیید نمی‌کند؛ هر دو صرفاً به لیست‌های کنترل دسترسی (ACL) واسطه اعتماد می‌کنند. برای عامل‌های خودمختاری که باید درباره همتایان خود تصمیمات مستقل بگیرند، این مرز امنیتی اشتباه است. این وضعیت سناریویی را ایجاد می‌کند که در آن «عضویت در شبکه» را با «قابل اعتماد بودن» یکی بدانیم؛ خلطی که امنیت عامل‌ها را به خطر می‌اندازد.
جایگزین همتا‌به‌همتا (P2P)
یک جایگزین، لایه همتا‌به‌همتا است که در پروتکل متن‌باز Pilot Protocol پیاده شده است. این پروتکل که با زبان Go، بدون هیچ وابستگی خارجی و تحت لایسنس AGPL-3.0 نوشته شده، به عامل‌ها یک آدرس مجازی دائمی می‌دهد. ارتباطات از طریق تونل‌های UDP رمزنگاری‌شده با استفاده از X25519 و AES-GCM صورت می‌گیرد.
این رویکرد نقاط ضعف واسطه را از طریق مکانیزم‌های زیر حل می‌کند:
- اتصالات مستقیم: عامل A داده‌ها را مستقیماً به آدرس عامل B می‌فرستد. هیچ واسطه‌ای در مسیر نیست و هیچ مؤلفه مشترکی برای مدیریت وجود ندارد، که باعث حذف نقطه شکست واحد برای گفتگو می‌شود.
- شناسه دائمی: آدرس مجازی با ری‌استارت شدن، تغییر IP یا جابجایی بین ابرها باقی می‌ماند. همتای A می‌تواند فردا همتای B را با همان نام پیدا کند، بدون اینکه نیاز به اتصال مجدد به واسطه یا اشتراک مجدد در موضوعات باشد.
- اعتماد متقابل: هر جفت عامل یک دست‌دادن (Handshake) متقابل انجام می‌دهند. عامل A مستقیماً تصمیم می‌گیرد به عامل B اعتماد کند یا خیر، به‌جای اینکه اعتماد را از یک مرجع مرکزی به ارث ببرد. در اینجا عضویت و اعتماد از هم جدا شده‌اند.
- دسترسی بدون زیرساخت: با استفاده از STUN و Hole Punching، عامل‌ها مستقیماً از میان NATها متصل می‌شوند. در مواقعی که NAT مانع از Punching شود، یک Relay جایگزین ترافیک را منتقل می‌کند. این روش نیازی به پورت‌های ورودی و هیچ واسطه عمومی ندارد.
پروتکل Pilot حتی یک فروشگاه اپلیکیشن فراهم کرده تا عامل‌ها قابلیت‌های جدید را با دستور pilotctl appstore install نصب کنند. این سیستم دقیقاً برای حالتی ساخته شده که MQTT در آن ناتوان است: دسترسی مستقیم یک عامل به یک همتا.
انتخاب ابزار مناسب
توسعه‌دهندگان نباید این را یک انتخاب «برنده-بازنده» ببینند. اکثر سامانه‌های چندعاملی ترکیبی هستند. برای انتخاب، نوع ترافیک را بررسی کنید:
- از MQTT (یا NATS و Kafka) استفاده کنید: اگر عامل‌ها عمدتاً رویدادهایی تولید می‌کنند که دیگران مصرف می‌کنند — مانند تله‌متری، فیدهای وضعیت و پخش نتایج. خانواده واسطه‌ها برای پخش (Fan-out) انتخاب درست هستند و بالغ و کم‌حجم‌اند.
- از لایه P2P استفاده کنید: اگر ارتباطات عمدتاً یک‌به‌یک است — مانند انتقال وظایف، انتقال فایل و فراخوانی ابزار بین همتایان خاص. این مدل لینک مستقیم، شناسه‌ی پایدار و اعتماد به‌ازای هر همتا را فراهم می‌کند که مسیریابی واسطه قادر به بیان آن نیست. در واقع، مدیریت داده‌ها در چنین ساختارهای توزیع‌شده‌ای نیازمند استراتژی‌های متفاوتی است، همان‌طور که در بررسی ۵ الگوی معماری برای تحلیل داده‌های عامل‌ها در شبکه‌های توزیع‌شده تحلیل کرده‌ایم.
هدف این است که یک معماری واحد را مجبور نکنیم دو الگوی ترافیکی کاملاً متفاوت را مدیریت کند. برای جریان‌های رویداد از MQTT استفاده کنید، جایی که قابلیت Fan-out ارزش خود را ثابت می‌کند، و گفتگوهای نقطه‌به‌نقطه را در لایه‌ای قرار دهید که جایگاه واقعی آن‌هاست.
این چرخش به سمت ارتباطات لینک-مستقیم نشان می‌دهد که آینده هوش مصنوعی عامل‌محور کمتر به هاب‌های ابری متمرکز و بیشتر به شبکه‌های توزیع‌شده‌ای وابسته خواهد بود که بازتاب‌دهنده استقلال خودِ عامل‌هاست. برای کسانی که می‌خواهند مدل اتصال مستقیم را تست کنند، پروتکل Pilot را می‌توان از طریق دستور curl -fsSL https://pilotprotocol.network/install.sh | sh نصب کرد. سپس دیمون را با pilotctl daemon start اجرا کرده و اولین پیام مستقیم را با دستور pilotctl send-message <peer-address> --data 'hello from agent one' ارسال کنید.
گام بعدی شما
- اگر در حال توسعه سیستم‌های چندعاملی هستید، ترافیک خود را تحلیل کنید تا متوجه شوید کجاها به اتصال مستقیم نیاز دارید.
- پروتکل Pilot را برای تست مدل اتصال مستقیم نصب کنید:
curl -fsSL https://pilotprotocol.network/install.sh | sh. - دیمون را با
pilotctl daemon startاجرا کرده و اولین پیام مستقیم را باpilotctl send-message <peer-address> --data 'hello'ارسال کنید.
این تحول در لایه ارتباطی، زیربنای استقلال واقعی عامل‌هاست. اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو