تصور کنید می‌خواهید دو هوش مصنوعی را که روی دو لپ‌تاپ مختلف در دو شهر متفاوت نصب شده‌اند، با هم هم‌کاری دهید، اما هیچ‌کدام دسترسی به آی‌پی عمومی ندارند. OpenAmer با یک ترفند هوشمندانه، این بن‌بست شبکه را می‌شکند و مخازن گیت‌هاب را به یک مرکز تبادل پیام تبدیل می‌کند.
بسیاری از سامانه‌های عامل‌محور (Agentic) برای ارتباط با یکدیگر به یک سرور مرکزی یا داشتن یک آدرس وب عمومی نیاز دارند. برای کاربرانی که عامل‌های خود را روی لپ‌تاپ‌های خانگی و پشت دیواره‌های NAT (ترجمه شبکه: سیستمی که چندین دستگاه را پشت یک آی‌پی مشترک پنهان می‌کند) اجرا می‌کنند، این یک مانع بزرگ است. در چنین شرایطی، باز کردن پورت‌های محلی به روی وب برای برقراری ارتباط، ریسک‌های امنیتی شدیدی دارد. OpenAmer که یک عامل دسکتاپ متن‌باز با مجوز Apache-2.0 است، این مشکل را با استفاده از یک مخزن گیت‌هاب به‌عنوان رله ارتباطی حل کرده است و در واقع یک مخزن گیت را به عنوان یک گذرگاه پیام با سازگاری نهایی (Eventually Consistent Message Bus) در نظر می‌گیرد.
این سازوکار شبیه به یک صندوق پستی فیزیکی است؛ به‌جای اینکه یک عامل مستقیماً با دیگری تماس بگیرد، یک نامه امضا شده را در یک پوشه مشترک در گیت‌هاب می‌اندازد. عامل گیرنده به‌صورت دوره‌ای این پوشه را چک می‌کند و پیام را برمی‌دارد. به این ترتیب، گره‌ای که مثلاً ۶ ساعت خاموش بوده، پس از روشن شدن می‌تواند تمام درخواست‌های صف خود را پردازش کند بدون اینکه چیزی را از دست داده باشد.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، حذف نقاط مرکزی شکست (Single Point of Failure) یکی از اولویت‌های اصلی در معماری‌های توزیع‌شده است.
محدودیت NAT و راهکار OpenAmer
در یک ساختار استاندارد ارتباط بین عامل‌ها (A2A)، اگر هر دو گره پشت NAT باشند، نمی‌توانند اتصالات ورودی (Inbound) را بپذیرند. این وضعیت معمولاً کاربر را مجبور می‌کند بین دو گزینه یکی را انتخاب کند: یا یک سرور رله مرکزی را اجرا کند، یا نقطه‌ای برای ملاقات (Rendezvous Point) پیدا کند که هر دو گره بتوانند بدون میزبانی هیچ سرویسی، در آن بخوانند و بنویسند.
OpenAmer دومی را انتخاب کرده است. در اینجا مخزن گیت‌هاب نقش رله را ایفا می‌کند. یک گره، یک پاکت حاوی پیام امضا شده و سانسور شده را در قالب یک فایل JSON در دایرکتوری خاص رله (directory/a2a/relay/) قرار می‌دهد که خطاب به مسیر صندوق پستی مقصد است. سپس گره مقصد آن را Pull می‌کند. این فرآیند تضمین می‌کند که هیچ داده‌ای هرگز مستقیماً با لوکال‌هوست در تماس نیست و نیازی به URL عمومی وجود ندارد.
معماری فنی و مکانیزم‌های امنیتی
بر اساس بررسی مستندات فنی این سیستم، چهار مکانیزم کلیدی برای حفظ امنیت و حریم خصوصی تعریف شده است:
- هویت بر پایه Ed25519: هر نمونه یک جفت‌کلید اختصاصی Ed25519 تولید می‌کند و یک اثر انگشت (Fingerprint) از آن استخراج می‌کند. در این سیستم هیچ نام کاربری، ایمیل یا ثبت‌نام مرکزی وجود ندارد؛ هویت شما همان کلیدی است که در اختیار دارید. کاربران این موارد را از طریق دستورات CLI مدیریت می‌کنند؛ مثلاً دستور
openamer a2a initبرای ایجاد هویت وopenamer a2a fingerprintبرای چاپ اثر انگشت به کار می‌رود. - پاکت‌های امضا شده: هر پیام در واقع یک پاکت است که شامل محتوا (Payload)، اثر انگشت فرستنده و یک امضای دیجیتال Ed25519 است. گیرنده پیش از هر پردازشی، امضا را با کلید عمومی فرستنده تایید می‌کند تا پیام‌های دست‌کاری شده در همان لبه شبکه رد شوند و هرگز به دست پردازشگر (Handler) نرسند.
- پاک‌سازی خودکار داده‌ها: برای جلوگیری از نشت اطلاعات در مخازنی که احتمالاً عمومی هستند، تابع
privacy.redact()پیش از ذخیره هر داده، شماره تلفن‌ها، رمزها، ایمیل‌ها و رشته‌های شبیه به شماره کارت بانکی را حذف می‌کند. حریم خصوصی در لحظه ارسال (Emission) اعمال می‌شود و به نظم یا دقت فرستنده واگذار نمی‌شود. - فهرست اعتماد صریح: داشتن یک امضای معتبر به معنای اعتماد نیست. گره‌ها فقط دستوراتی را اجرا می‌کنند که فرستنده آن‌ها صراحتاً در «فهرست اعتماد» (Trust Store) اضافه شده باشد. این مجوزها به‌صورت تاپل‌های (peer, capability, scope, budget) تعریف می‌شوند. برای مثال، به یک گره ممکن است اجازه
network.fetchفقط برای یک دامنه خاص، یا اجازهmodel.reasonبا یک بودجه مشخص از گام‌های استدلالی داده شود. اگر مجوزی تعریف نشده باشد، قابلیت مربوطه اصلاً اجرا نمی‌شود.
جریان واگذاری وظایف (Task Delegation)
وقتی یک گره وظیفه‌ای را به گره دیگر واگذار می‌کند، یک چرخه پنج مرحله‌ای طی می‌شود:
۱. امضای یک یادداشت وظیفه (Task-note) خطاب به صندوق پستی گره مقصد.
۲. آپلود آن در دایرکتوری رله از طریق GitHub Contents API.
۳. فعال کردن Worker مقصد از طریق مکانیزم repository_dispatch.
۴. نظارت (Poll) روی مخزن تا زمانی که یک پاسخ امضا شده و تازه برای صندوق پستی فرستنده ظاهر شود.
۵. تایید امضا و تازگی (Freshness) پاسخ پیش از خواندن محتوا.
این فرآیند تضمین می‌کند که دو ماشین هرگز نیازی به دسترسی مستقیم به یکدیگر ندارند. مخزن گیت‌هاب به عنوان گذرگاه مشترک عمل می‌کند و رمزنگاری، این گذرگاه را برای اشتراک‌گذاری امن می‌سازد.
الگوی نگهبان (Guardian Pattern)
برای مدیریت حاکمیت و یکپارچه‌سازی، OpenAmer از «الگوی نگهبان» استفاده می‌کند. در شبکه‌ای که گره‌های زیادی می‌توانند پیشنهاد بهبود ارائه دهند، تنها گره «نگهبان» است که توکن دسترسی برای نوشتن (Write Token) را در اختیار دارد.
سایر گره‌ها پیشنهادهای امضا شده خود را از طریق کانال A2A ارسال می‌کنند. نگهبان امضای فرستنده را با دایرکتوری اعتماد تطبیق داده، پیشنهاد را روی یک شاخه موقت (Scratch Branch) اعمال کرده و تست‌ها را در محیط ایزوله اجرا می‌کند. تنها در صورتی که تمام تست‌ها سبز باشند، پیشنهاد در شاخه اصلی (Main) ادغام می‌شود. این عدم تقارن عمدی از پخش شدن توکن‌های دسترسی در ماشین‌های مختلف جلوگیری کرده و تضمین می‌کند هیچ کدی بدون بررسی از روی شبکه اجرا نشود.
تحلیل هزینه‌ها و سبک‌سنگین کردن معماری
این معماری بار امنیتی را از لایه شبکه به لایه رمزنگاری منتقل می‌کند. شما دیگر به اتصال (Connection) اعتماد نمی‌کنید، بلکه به امضا (Signature) اعتماد می‌کنید. با این حال، این رویکرد هزینه‌های مشخصی دارد:
- تأخیر (Latency): این سیستم بلادرنگ (Real-time) نیست. پیام‌ها بر اساس کامیت‌ها و پولینگ جابه‌جا می‌شوند و تأخیر در حد ثانیه‌ها یا دقیقه‌ها است. این ساختار برای هماهنگی (Coordination) عالی است اما برای حلقه‌های کنترلی سریع مناسب نیست.
- اعتماد دستی: هیچ مرجع مرکزی وجود ندارد. امنیت کاملاً به گراف اعتماد صریح و امضاهای پاکت‌ها وابسته است. اگر قابلیت گسترده‌ای به گره‌ای داده شود، مسئولیت ریسک آن بر عهده اپراتور است.
- آرتیفکت‌های مشترک: چون رله یک فضای مشترک است، سانسور داده‌ها در لحظه ارسال برای جلوگیری از نشت اطلاعات حیاتی است.
با وجود این هزینه‌ها، نتیجه نهایی یک شبکه بدون نقطه شکست مرکزی است. یک وظیفه استدلالی سنگین را می‌توان به هر گرهی در شبکه که ظرفیت خالی دارد واگذار کرد، فارغ از اینکه آن گره در کجای جهان قرار دارد. این سیستم مجموعه‌ای از لپ‌تاپ‌های ایزوله را به یک خوشه محاسباتی توزیع‌شده تبدیل می‌کند بدون اینکه به حتی یک سرور نیاز باشد.
شروع به کار و تعامل
کاربران می‌توانند از طریق CLI و با دستوراتی نظیر openamer a2a status برای بررسی وضعیت، openamer a2a announce برای اعلام حضور، openamer a2a directory برای لیست کردن گره‌ها و openamer a2a ask <peer> "<question>" برای ارسال پرسش با سیستم تعامل داشته باشند.
اگر در حال توسعه سامانه‌های چندعاملی هستید، ماژول openamer_cli/a2a/ را در گیت‌هاب بررسی کنید تا با منطق لایه انتقال داده (Transport)، ذخیره اعتماد (Trust Store) و منطق رله آشنا شوید.
گام بعدی شما
- اگر در حال توسعه سامانه‌های چندعاملی هستید، ماژول
openamer_cli/a2a/را در گیت‌هاب بررسی کنید تا با منطق لایه انتقال داده آشنا شوید. - برای تست، یک مخزن خصوصی در گیت‌هاب بسازید و سعی کنید دو نمونه OpenAmer را روی دو ماشین مختلف متصل کنید.
- بررسی کنید که آیا محدودیت‌های نرخ (Rate Limit) API گیت‌هاب در مقیاس‌های بزرگتر به گلوگاه تبدیل می‌شود یا خیر.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو