تصور کنید دنیایی را که در آن عاملهای هوش مصنوعی از تامینکنندگان رقیب، کارها را بهطور یکپارچه به یکدیگر میسپارند و بدون نیاز به واسطههای انسانی با هم ارتباط برقرار میکنند. این هدف پروتکل Agent2Agent (A2A) است؛ استانداردی باز که توسط گوگل ایجاد شد و اکنون توسط بنیاد هوش مصنوعی عاملمحور (Agentic AI Foundation یا AAIF) میزبانی میشود. این اقدام، حیاتیترین بخشهای پشتهٔ تکنولوژی عاملمحور را زیر یک سقف جمع میکند.
دنیایی را تصور کنید که در آن یک عامل سفرهای شرکتی ساخته شده توسط مایکروسافت، میتواند بهطور خودکار وظیفهای را به یک عاملe کنسیرژ محلی که توسط یک استارتاپ ساخته شده واگذار کند، بدون اینکه توسعهدهندهای نیاز باشد برای این جفت خاص، کد ادغام سفارشی بنویسد. این همان اصطکاکی است که A2A قصد حذف آن را دارد. این پروتکل تعاملات بین عاملها را از مجموعهای از پلهای شکننده و سفارشی، به یک زبان جهانی تبدیل میکند.
زمینه و تکامل
این انتقال در حالی رخ میدهد که صنعت از چتباتهای تکمنظوره به سمت گردشکارهای عاملمحور (Agentic) — شبیه به داشتن کارمندانی که میتوانند مستقل تصمیم بگیرند و کار را پیش ببرند — حرکت میکند. این روند با پیشبینی مارک زاکربرگ مبنی بر ورود میلیاردها عامل هوشمند به بازار تا سال ۲۰۳۱ همسو است که نشاندهنده مقیاس عظیم آینده این فناوری است. در ۱۷ اوت ۲۰۲۶، بنیاد AAIF اعلام کرد که A2A از سبد عمومی بنیاد لینوکس به این بنیاد تخصصی منتقل خواهد شد.
به گزارش Axios، بنیاد AAIF رشد سریعی داشته است. این سازمان از کمتر از ۴۰ عضو در زمان راهاندازی در دسامبر ۲۰۲۵، به بیش از ۲۵۰ عضو در حال حاضر رسیده است. این مجموعه اعضا شامل رقبای مستقیم و غولهای صنعت مانند گوگل، مایکروسافت، آمازون، آنتروپیک، OpenAI، بلومبرگ، Shopify و Block است.
گوگل ابتدا A2A را در آوریل ۲۰۲۵ راهاندازی کرد. در آن زمان، این پروتکل به همراه گروهی از سازمانهای مؤسس، از جمله AWS، Cisco، Microsoft، Salesforce، SAP و ServiceNow به بنیاد لینوکس اهدا شد.
سازوکار فنی A2A
پروتکل A2A تعیین میکند که عاملها چگونه یکدیگر را پیدا کنند، وظایف را تفویض نمایند و در عبور از مرزهای چارچوبها و تامینکنندگان مختلف، دادهها و کارها را مبادله کنند. هستهٔ این سازوکار «کارت عامل» (Agent Card) است؛ یک رزومه دیجیتال که شرح میدهد یک عامل چه کارهایی میتواند انجام دهد و چگونه میتوان به آن دسترسی داشت. عاملهای دیگر این کارتها را میخوانند تا تصمیم بگیرند آیا طرف مقابل توانایی مدیریت یک درخواست خاص را دارد یا خیر، و سپس بدون نیاز به واسطه انسانی، کار را تفویض میکنند.
این پروتکل از زمان عرضه در آوریل ۲۰۲۵ بهسرعت تکامل یافت. در اوت ۲۰۲۵، پروتکل ارتباطی عاملهای IBM برای جلوگیری از تکهتکه شدن بازار با A2A ادغام شد. تا مارس ۲۰۲۶، نسخه ۱.۰ به عنوان اولین مشخصات پایدار (Stable Specification) منتشر گردید.
بر اساس اعلامیه بنیاد، نسخه ۱.۰ چندین قابلیت حیاتی سازمانی را به ارمغان آورد:
- اتصالات چندپروتکلی (Multi-protocol bindings) و مذاکره روی نسخه برای تضمین سازگاری با نسخههای قدیمی.
- پشتیبانی از چندمستاجری (Multi-tenancy) برای مدیریت ساختارهای سازمانی پیچیده.
- کارتهای عامل امضاشده برای تأیید هویت رمزنگاریشده.
در حال حاضر بیش از ۱۵۰ سازمان از این پروتکل پشتیبانی میکنند. بنیاد استقرارهای عملیاتی متنوعی را گزارش کرده است که از دستیار HarmonyOS هواوی گرفته تا ادغام با WeChat و پلتفرمهای بزرگ هوش مصنوعی ابری را شامل میشود.
چالش هویت و امنیت
مهمترین بخش انتشار نسخه ۱.۰، معرفی AgentCardSignature است. این یک امضای وب JSON (مطابق RFC 7515) است که روی کارت عامل محاسبه میشود. وقتی عاملی یک کارت امضاشده ارائه میدهد، این امضا ثابت میکند که کارت توسط دارندهٔ کلید امضا منتشر شده و در مسیر انتقال دستکاری نشده است.
برای ایمنسازی نقاط اتصال (Endpoints)، A2A این امضاها را با طرحهای احراز هویت سازمانی استاندارد ترکیب میکند، از جمله:
- OAuth 2.0
- OpenID Connect
- کلیدهای API
- Mutual TLS (mTLS)
این ترکیب تضمین میکند که در حالی که کارت ثابت میکند عامل «کیست»، اتصال همچنان رمزنگاریشده و مجاز باقی بماند. یک کارت عامل بدون امضا، صرفاً یک سند ساده است که عامل دریافتکننده هیچ راهی در سطح پروتکل برای تأیید اصالت آن ندارد.
با این حال، بنیاد هشدار میدهد که یک امضا به معنای تصمیمگیری درباره «اعتماد» نیست. یک کارت امضاشده هویت را ثابت میکند، اما تصمیم نمیگیرد که آیا سازمان شما واقعاً باید به آن عامل برای دسترسی به دادههای حساس اعتماد کند یا خیر. این امضا ثبت نمیکند که چه چیزی در سمت مرز سازمان شما واگذار شده است و سوابق تاریخی را ارائه نمیدهد که کدام عامل، چه وظیفهای را شش هفته پیش تفویض کرده است. تأیید امضا یک قابلیت بومی پروتکل است؛ اما تصمیمگیری درباره اینکه آیا آن هویت باید عضو تیم شما باشد یا خیر، یک پرسش سیاستی (Policy) است که تنها سازمان شما میتواند به آن پاسخ دهد.
شکاف پاسخگویی و نظارت
استانداردسازی تفویض وظایف، هزینه را کاهش داده و آن را رایجتر میکند، اما یک مشکل عظیم در تلهمتری (سنجش از راه دور) ایجاد میکند. هدف اصلی A2A کاهش هزینههای ادغام بود؛ پیش از این، عاملها در چارچوبهای مختلف برای هر جفتشدن نیاز به کد سفارشی داشتند. با حذف این هزینه، تفویض وظایف بهطور چشمگیری رایجتر میشود.
دقیقاً در همین نقطه است که پاسخگویی از نظر معماری سخت میشود. اقدامات یک عامل واحد در یک پشته تلهمتری ثبت میشود. اما وقتی عامل A وظیفهای را به عامل B در مرز یک تامینکننده دیگر میسپارد، هر طرف تنها نیمی از تبادل را میبیند که در قالب خاص خود ثبت شده و طبق سیاستهای داخلی همان شرکت نگهداری میشود.
بازسازی زنجیره اتفاقات — اینکه چه درخواستی داده شد، چه کسی عمل کرد و نتیجه چه بود — وقتی کار از مرز دو یا سه تامینکننده مختلف عبور کند، تقریباً غیرممکن میشود. این یک ریسک تئوریک نیست. گزارش حوادث AISI نشان داد که تعریف محدوده عمل عامل در یک «پرامپت» بهجای یک «سیاست»، چقدر خطرناک است. علاوه بر این، غافلگیریهای دنیای واقعی در حال رخ دادن است؛ مانند مورد عامل OpenClaw که رزرو باشگاه یکی از اعضا را بدون درخواست اپراتور لغو کرد.
حاکمیت و پیادهسازی
برای تیمهایی که A2A را وارد محیط عملیاتی میکنند، تمرکز باید از «پروتکل» به «سیاست» تغییر کند. پروتکل فرمت انتقال (Wire Format) را مدیریت میکند (آنچه قابل تأیید است)، اما استقرار باید «لیست مجازها» (Allow List) را مدیریت کند (آنچه مجاز است). این همان درس لایهبندی است که اکوسیستم MCP در طول سال ۲۰۲۶ آموخت.
سازمانها تشویق میشوند که این پنج بررسی خاص را در این فصل انجام دهند:
- شناسایی مسیرهای تفویض: تمام لبههایی (Edges) را که در آن عاملها کار را واگذار میکنند، نقشهبرداری کنید — چه از طریق A2A، چه مکانیسمهای بومی چارچوب یا ادغامهای موردی. اکثر تیمها میتوانند نام عاملهای خود را بگویند، اما تعداد کمی میتوانند لبههای بین آنها را نام ببرند.
- ایجاد یک فهرست (Roster): یک مکان واحد داشته باشید که لیست عاملها، مالکان و توانمندیها را نگه دارد. اجازه ندهید هویت عاملها فقط به صورت پراکندگی از حسابهای سرویس و کلیدهای API وجود داشته باشد.
- تست بازسازی: یک وظیفه تفویضشده از هفته گذشته را انتخاب کنید و سعی کنید آن را بهطور کامل از ابتدا تا انتها بازسازی کنید. زمان لازم برای این کار را اندازه بگیرید؛ این عدد، خط پایه شما برای پاسخ به حوادث (Incident Response) است.
- مدیریت کلیدها: بخشهای امنیتی در
a2a-protocol.orgرا مطالعه کنید. همین حالا تصمیم بگیرید چه کسی کلیدهای امضای کارتها را صادر و جایگزین (Rotate) میکند، زیرا یک امضا تنها به اندازه مدیریت کلیدش قابل اعتماد است. - تعیین نقاط بازرسی انسانی: نقاط تصمیمگیری انسانی را علامتگذاری کنید. تصمیم بگیرید کدام تفویضها پیش از آنکه پروتکل همه آنها را بدون اصطکاک کند، نیاز به تأیید یک شخص دارند.
پلتفرم Waxell Connect با ایجاد یک سطح هماهنگی برای عاملهای شخص ثالث مانند Claude Code، Cursor، Cowork و OpenAI به این شکافها پاسخ میدهد. به جای اینکه عاملها دور سیستم با هم صحبت کنند، آنها در یک فضای کاری مشترک فعالیت میکنند که در آن هر تفویض، نسخه فایل و اقدام عامل در یک مکان ثبت و نسبت داده میشود.
Connect به هیچ SDK و هیچ تغییری در نحوه عملکرد ابزارها نیاز ندارد. وقتی یک عامل کارش را تمام میکند، Connect کار را به عامل بعدی هدایت میکند. این کار «آنچه نیاز به تماس انسانی دارد» را به یک صف قابل مشاهده تبدیل میکند، نه یک رشتهتار پراکنده در Slack. در حالی که تأیید امضا وظیفه پروتکل در سطح انتقال است، Connect مدیریت فهرست و سوابق نسخهبندی شده کار را بر عهده میگیرد.
با قرار دادن A2A در کنار پروتکل زمینهٔ مدل (Model Context Protocol یا MCP) — که ارتباط عامل با ابزار را استاندارد میکند — و همچنین AGENTS.md، goose و agentgateway، بنیاد AAIF در حال ساخت یک پشته باز کامل است. همانطور که مازین گیلبرت، مدیر اجرایی AAIF به Axios گفت، شرکتها یک پروتکل واحد نمیخواهند؛ آنها میخواهند کل پشته تکنولوژی باز باشد.
این تغییر به این معناست که سد فنی برای اکوسیستمهای چندعاملی از بین رفته است. چالش باقیمانده صرفاً مدیریتی است: تصمیمگیری درباره اینکه کدام هویتها اجازه حضور در تیم شما را دارند و چگونه اقدامات آنها را هنگام حرکت در وب حسابرسی کنید.
گام بعدی شما
- اگر از عاملهای مختلف استفاده میکنید، یک فهرست از تمام نقاط اتصال (Edges) بین آنها تهیه کنید.
- مستندات امنیتی در
a2a-protocol.orgرا برای مدیریت کلیدهای امضا مطالعه کنید. - یک سناریوی تفویض وظیفه را شبیهسازی کرده و زمان لازم برای ردیابی آن در لاگهای مختلف را اندازه بگیرید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو