پروتکل A2A: ارتباط استاندارد ایجنت با ایجنت

وقتی چند ایجنت هوش مصنوعی در سازمان‌های مختلف یا روی فریم‌ورک‌های متفاوتی مثل LangGraph و CrewAI پیاده می‌شوند، اتصال آن‌ها به یکدیگر معمولاً به ساخت APIهای سفارشی و پرهزینه تبدیل می‌شود. هر تغییر جزئی در اسکیمای داده، ارتباط میان ایجنت‌ها را مختل می‌کند و امکان همکاری خودکار بین‌سامانه‌ای را از بین می‌برد.

پروتکل A2A (یا Agent-to-Agent) با معرفی یک استاندارد متن‌باز و همتابه‌همتا، این مشکل را حل می‌کند. این استاندارد شامل Agent Card برای شناسایی خودکار، سازوکار رهگیری چرخه‌ی حیات وظایف و پشتیبانی از انواع رسانه‌ها (دست‌سازه‌ها) است که امکان تبادل پیام امن میان ایجنت‌ها را بدون وابستگی به فریم‌ورکی خاص فراهم می‌سازد.

گوگل پروتکل A2A را در آوریل 2025 معرفی کرد؛ تا آوریل 2026 مشخصات فنی آن در آدرس https://a2a-protocol.org/latest/specification/ در دسترس قرار گرفت و بیش از 150 سازمان از آن پشتیبانی می‌کنند. A2A مکمل افقی پروتکل MCP (درس 13) است: جایی که MCP ساختاری عمودی دارد (ایجنت ↔ ابزارها)، A2A همتا‌به‌همتا (ایجنت ↔ ایجنت) عمل می‌کند. این پروتکل کارت‌های ایجنت (Agent Cards برای شناسایی)، وظایف دارای دست‌سازه (متن، داده‌های ساختاریافته، ویدیو)، چرخه‌های حیات مبهم وظیفه و سازوکارهای احراز هویت را تعریف می‌کند. سیستم‌های محیط عملیاتی (پروداکشن) روزبه‌روز بیشتر MCP را در کنار A2A به کار می‌گیرند. گوگل کلاد در طول سال‌های 2025 تا 2026 پشتیبانی از A2A را به سرویس Vertex AI Agent Builder اضافه کرد.

صورت مسئله

ایجنت شما باید ایجنت دیگری را روی سیستمی دیگر فراخوانی کند. چطور؟ می‌توانید یک اندپوینت HTTP راه بیندازید، یک اسکیمای JSON سفارشی تعریف کنید و امیدوار باشید طرف مقابل هم به همان زبان صحبت کند. در این حالت، اتصال هر جفت ایجنت به یکپارچه‌سازی اختصاصی و مجزا تبدیل می‌شود.

پروتکل A2A استاندارد ارتباطی فراگیر (سیمی) برای همین فراخوانی‌ها است؛ با روش شناسایی استاندارد، مدل وظیفه‌ی استاندارد، بستر انتقال استاندارد و دست‌سازه‌های استاندارد. درست مانند HTTP+REST، اما برای ایجنت‌ها به عنوان شهروندان درجه‌یک.

مفهوم

چهار عنصر اصلی

کارت ایجنت (Agent Card). سندی با فرمت JSON در مسیر /.well-known/agent-card.json که ایجنت را توصیف می‌کند: نام، مهارت‌ها، supportedInterfaces (آدرس URL اندپوینت، اتصال پروتکل، نسخه‌ی پروتکل)، انواع پیش‌فرض رسانه‌ی ورودی و خروجی، و الزامات احراز هویت (securitySchemes به همراه securityRequirements). شناسایی ایجنت صرفاً با خواندن همین کارت انجام می‌شود.

GET /.well-known/agent-card.json HTTP/1.1
Host: agent.example.com

{
  "name": "code-review-agent",
  "description": "Reviews Python and TypeScript code.",
  "version": "1.0.0",
  "supportedInterfaces": [
    {
      "url": "https://agent.example.com",
      "protocolBinding": "HTTP+JSON",
      "protocolVersion": "1.0"
    }
  ],
  "capabilities": {"streaming": false, "pushNotifications": false},
  "securitySchemes": {
    "bearer": {"httpAuthSecurityScheme": {"scheme": "Bearer"}}
  },
  "securityRequirements": [{"schemes": {"bearer": {"list": []}}}],
  "defaultInputModes": ["text/plain", "application/json"],
  "defaultOutputModes": ["application/json"],
  "skills": [
    {
      "id": "review-python",
      "name": "Review Python",
      "description": "Reviews Python code.",
      "tags": ["code-review", "python"]
    },
    {
      "id": "review-typescript",
      "name": "Review TypeScript",
      "description": "Reviews TypeScript code.",
      "tags": ["code-review", "typescript"]
    }
  ]
}

وظیفه (Task). واحد کار است؛ شیئی ناهمگام و دارای وضعیت با این چرخه‌ی حیات: TASK_STATE_SUBMITTED ← TASK_STATE_WORKING ← TASK_STATE_COMPLETED / TASK_STATE_FAILED / TASK_STATE_CANCELED. کلاینت پیامی می‌فرستد، سرور وظیفه را می‌سازد و سپس کلاینت برای دریافت به‌روزرسانی‌ها به روش Polling عمل می‌کند یا مشترک می‌شود (Subscribe).

دست‌سازه (Artifact). نوع نتیجه‌ی حاصل از وظیفه است؛ می‌تواند متن، JSON ساختاریافته، تصویر، ویدیو یا صوت باشد. دست‌سازه‌ها نوع‌دار هستند: هر بخش یکی از فیلدهای text، raw، url یا data را حمل می‌کند و می‌تواند mediaType خود را مشخص کند؛ بنابراین انواع مختلف رسانه جایگاه درجه‌یک دارند.

چرخه‌ی حیات مبهم (Opaque lifecycle). پروتکل A2A تعیین نمی‌کند که ایجنت راه دور چگونه وظیفه را حل کند. کلاینت فقط تغییرات وضعیت و دست‌سازه‌ها را می‌بیند؛ پیاده‌سازی سرور در استفاده از هر فریم‌ورکی کاملاً آزاد است.

تفکیک MCP و A2A

• پروتکل MCP (درس 13): رابطه ایجنت ↔ ابزار. ایجنت از طریق JSON-RPC روی یک سرورِ ابزار عملیات خواندن/نوشتن انجام می‌دهد. به طور پیش‌فرض بی‌وضعیت (Stateless) است.
• پروتکل A2A: رابطه ایجنت ↔ ایجنت. پروتکلی همتا است که در آن هر دو طرف، ایجنت‌هایی با قدرت استدلال مستقل خودشان هستند.

سیستم‌های چندایجنت در محیط عملیاتی از هر دو استفاده می‌کنند. یک طرف ارتباط در A2A ابزارهای MCP را در سمت خودش فراخوانی می‌کند. این تفکیک باعث می‌شود مرز دو مسئولیت کاملاً شفاف بماند.

فرایند شناسایی

این‌ها مسیرهای اتصال پروتکل HTTP+JSON هستند و هر درخواست هدر A2A-Version: 1.0 را به همراه دارد. به طور پیش‌فرض SendMessage تا زمانی که وظیفه به وضعیت نهایی یا وقفه (Interrupt) نرسد بلاک می‌ماند؛ بنابراین کلاینتی که قصد Polling دارد، فیلد configuration.returnImmediately را تنظیم می‌کند تا وظیفه را بلافاصله تحویل بگیرد.

در صورت استفاده از استریمینگ: ارسال درخواست به POST /message:stream رویدادهای Server-Sent Events را برمی‌گرداند (ابتدا یک رویداد task و سپس رویدادهای statusUpdate و artifactUpdate). با مسیر /tasks/{id}:subscribe هم می‌توان اتصال مجدد به نشست یک وظیفه‌ی در حال اجرا برقرار کرد. استریم به محض رسیدن وظیفه به وضعیت نهایی بسته می‌شود؛ هیچ فلگ final وجود ندارد.

احراز هویت

پروتکل A2A از سه الگوی رایج پشتیبانی می‌کند:

• توکن حامل (Bearer token): بر پایه‌ی OAuth2 یا رشته‌های مات (httpAuthSecurityScheme یا oauth2SecurityScheme).
• پروتکل mTLS: ارتباط TLS دوطرفه که در آن سازمان‌ها هویت خود را به یکدیگر اثبات می‌کنند (mtlsSecurityScheme).
• کلید API: کلیدی در هدر، پارامتر کوئری یا کوکی (apiKeySecurityScheme).

احراز هویت داخل کارت ایجنت تعریف می‌شود: securitySchemes هر طرح را نام می‌برد و securityRequirements مشخص می‌کند کلاینت باید کدام موارد را برآورده سازد. کلاینت‌ها این موارد را شناسایی می‌کنند و با آن هماهنگ می‌شوند.

بیش از 150 سازمان تا آوریل 2026

استقبال شرکت‌های بزرگ مقیاس A2A را بالا برد. تیتر اصلی این بود: A2A به روش سازمانی عبور سیستم‌های ایجنتی از مرزهای اعتماد تبدیل شد. گوگل کلاد پشتیبانی از A2A را در Vertex AI Agent Builder عرضه کرد؛ مایکروسافت از آن در Agent Framework پشتیبانی می‌کند؛ و اکثر فریم‌ورک‌های مطرح (LangGraph، CrewAI، AutoGen) تطبیق‌دهنده‌های (Adapter) اختصاصی A2A را ارائه کرده‌اند.

نقاط قوت A2A

• فراخوانی‌های بین‌سازمانی: ایجنت شرکت A ایجنت شرکت B را فراخوانی می‌کند. بدون A2A، اتصال هر دو ایجنت به یک قرارداد سفارشی نیاز دارد.
• فریم‌ورک‌های ناهمگن: ایجنت LangGraph ایجنت CrewAI را فراخوانی می‌کند و آن هم ایجنتی اختصاصی با پایتون را صدا می‌زند. A2A این ارتباطات را یکپارچه می‌کند.
• دست‌سازه‌های نوع‌دار: خروجی ویدیویی، JSON ساختاریافته، صوت؛ همگی درجه‌یک هستند.
• وظایف طولانی‌مدت: چرخه‌ی حیات مبهم در کنار Polling، اجرای وظایفی را که ساعت‌ها طول می‌کشند ساده می‌کند.

چالش‌های A2A

• ریزفراخوانی‌های حساس به تاخیر: چرخه‌ی حیات A2A ناهمگام است. ارتباطات زیر میلی‌ثانیه‌ای ایجنت‌به‌ایجنت در این الگو نمی‌گنجد؛ برای چنین مواردی از RPC مستقیم استفاده کنید.
• ایجنت‌های به‌هم‌پیوسته درون یک فرایند: اگر هر دو ایجنت داخل یک فرایند پایتون اجرا می‌شوند، رفت‌وبرگشت HTTP در A2A کار اضافه‌ای است.
• تیم‌های کوچک: بارِ پیاده‌سازی این استاندارد قابل توجه است؛ ایجنت‌های کاملاً داخلی شاید به چنین ساختار رسمی و دقیقی نیاز نداشته باشند.

مقایسه‌ی A2A با ACP، ANP و NLIP

در فاصله‌ی سال‌های 2024 تا 2026 چند استاندارد مرتبط دیگر هم معرفی شدند:

• پروتکل ACP (بنیاد لینوکس/IBM) — پیش‌درآمد A2A با دامنه‌ی محدودتر.
• پروتکل ANP (پروتکل شبکه‌ی ایجنت‌ها) — تمرکز شدید روی شناسایی همتاها و اولویت تمرکززدایی.
• پروتکل NLIP (پروتکل تعامل زبان طبیعی Ecma، استانداردشده در دسامبر 2025) — تمرکز بر نوع محتوای زبان طبیعی.

پروتکل A2A تا آوریل 2026 بیشترین میزان پذیرش را میان پروتکل‌های همتا دارد. برای مقایسه‌ی دقیق‌تر، مقاله‌ی Liu و همکاران با عنوان «A Survey of Agent Interoperability Protocols» را در arXiv:2505.02279 ببینید.

پیاده‌سازی عملی

فایل code/main.py یک سرور و کلاینت مینیمال A2A را با استفاده از http.server و JSON، بر اساس اتصال پروتکل HTTP+JSON نسخه‌ی 1.0 پیاده‌سازی می‌کند. سرور کارهای زیر را انجام می‌دهد:

• ارائه‌ی کارت در مسیر /.well-known/agent-card.json،
• پذیرش درخواست‌های POST /message:send،
• مدیریت وضعیت وظیفه،
• بازگرداندن دست‌سازه‌ها در پاسخ به GET /tasks/{id}.

کلاینت کارهای زیر را انجام می‌دهد:

• دریافت کارت ایجنت،
• ارسال پیام با تنظیم returnImmediately،
• اجرای Polling تا زمان اتمام کار،
• خواندن دست‌سازه.

اجرا:

python3 code/main.py

این اسکریپت سرور را در یک ترد پس‌زمینه راه‌اندازی می‌کند و سپس کلاینت را در برابر آن اجرا می‌نماید. شما کل فرایند را می‌بینید: شناسایی، ثبت وظیفه، Polling و دریافت دست‌سازه.

کاربرد در عمل

فایل outputs/skill-a2a-integrator.md معماری یک یکپارچه‌سازی با A2A را طراحی می‌کند: محتویات کارت ایجنت، اسکیمای وظایف، انتخاب روش احراز هویت، و مقایسه‌ی استریمینگ در برابر Polling.

به‌کارگیری در پروداکشن

چک‌لیست:

• نسخه‌ی مشخصات فنی را قفل کنید. A2A هنوز در حال تغییر است؛ هر ورودی در supportedInterfaces باید protocolVersion خود را اعلام کند و کلاینت‌ها نیز هدر A2A-Version: 1.0 بفرستند.
• ساخت وظایف را بی‌اثر در تکرار (Idempotent) کنید. ارسال درخواست‌های تکراری (مثلاً بر اثر تلاش مجدد شبکه) باید فقط یک وظیفه ایجاد کند. با تکیه بر messageId ارسالی کلاینت، موارد تکراری را حذف کنید.
• اسکیمای دست‌سازه‌ها. ساختار خروجی‌هایی را که ایجنت بازمی‌گرداند مشخص کنید؛ مصرف‌کننده‌ها باید این داده‌ها را اعتبارسنجی کنند.
• محدودیت نرخ درخواست و احراز هویت. پروتکل A2A رو به اینترنت است؛ الزامات استاندارد امنیت وب را رعایت کنید.
• صف نامه‌های مرده (Dead-letter) برای وظایف ناموفق. الگوهای خطا را در طول زمان بررسی کنید تا ریشه‌ی شکست‌های تکراری مشخص شود.

تمرین‌ها

1. اسکریپت code/main.py را اجرا کنید. بررسی کنید که آیا کلاینت سرور را شناسایی کرده و دست‌سازه‌ی درست را تحویل می‌گیرد یا خیر.
2. مهارت دومی به سرور اضافه کنید (مثلاً «خلاصه‌سازی»). کارت ایجنت را به‌روزرسانی کنید. کلاینتی بنویسید که مهارت مورد نظر را بر اساس نوع وظیفه انتخاب کند. درخواست در نسخه‌ی 1.0 فیلدی برای مهارت ندارد، بنابراین سرور باید بر اساس بخش‌های پیام مسیردهی را انجام دهد.
3. اندپوینت POST /message:stream را پیاده‌سازی کنید: با Server-Sent Events پاسخ دهید (ابتدا یک رویداد task و بعد رویدادهای statusUpdate) و استریم را در وضعیت نهایی ببندید. کلاینت برای هماهنگی با این ساختار چه تغییراتی باید بکند؟
4. مشخصات فنی A2A را در آدرس https://a2a-protocol.org/latest/specification/ بخوانید. سه مورد اجباری در این مشخصات را پیدا کنید که در دموی ما پیاده‌سازی نشده‌اند.
5. پروتکل A2A (شناسایی با کارت ایجنت) را با MCP (فهرست‌کردن قابلیت‌ها در سمت سرور از طریق listTools) مقایسه کنید. تعادل و بده‌بستان بین ایجنت‌های خودتوصیف‌گر و کاوش قابلیت‌ها در چیست؟

اصطلاحات کلیدی

برای مطالعه‌ی بیشتر

• مشخصات فنی A2A — سند مرجع و اصلی
• انتشار نسخه‌ی v1.0.1 پروتکل A2A: فایل‌های تگ‌خورده‌ی docs/specification.md و specification/a2a.proto که این درس بر پایه‌ی آن‌ها تهیه شده است
• وبلاگ توسعه‌دهندگان گوگل — معرفی A2A — پست زمان رونمایی در آوریل 2025
• مخزن گیت‌هاب A2A — پیاده‌سازی‌های مرجع و SDKها
• مقایسه‌ی پروتکل‌های تعامل‌پذیری ایجنت‌ها (Liu et al.) — مقایسه‌ی جامع MCP، ACP، A2A و ANP