Agent-to-Agent Protocol (A2A)

A2A یک پروتکل باز است که به ایجنت‌های هوش مصنوعیِ مستقل از یکدیگر — حتی وقتی روی فریم‌ورک‌ها و توسط شرکت‌های مختلف ساخته شده باشند — اجازه می‌دهد یکدیگر را کشف کنند و مستقیماً برای انجام یک وظیفه با هم همکاری کنند.

A2A دقیقاً چیست؟

تصور کنید ایجنت خرید شما (که مثلاً روی زیرساخت یک شرکت اجرا می‌شود) باید برای تکمیل یک سفارش، با ایجنت لجستیک یک شرکت حمل‌ونقل دیگر هماهنگ شود. این دو ایجنت نه فقط روی فریم‌ورک‌های متفاوت ساخته شده‌اند، بلکه اصلاً هیچ‌کدام دسترسی مستقیم به کد یا دیتابیس دیگری ندارند. A2A دقیقاً برای همین سناریو طراحی شده: یک زبان مشترک برای اینکه ایجنت‌های مستقل، کارهای خودشان (Task) را به هم واگذار کنند، بدون اینکه نیازی به دانستن جزئیات پیاده‌سازی داخلی طرف مقابل باشد.

چرا وقتی MCP داریم، به A2A هم نیاز داریم؟

این دو پروتکل دو رابطه‌ی کاملاً متفاوت را استاندارد می‌کنند. MCP رابطه‌ی «ایجنت به ابزار/داده» را حل می‌کند (یک ایجنت به یک پایگاه‌داده یا API متصل می‌شود). A2A رابطه‌ی «ایجنت به ایجنت دیگر» را حل می‌کند — یعنی طرف مقابل خودش یک تصمیم‌گیرنده‌ی مستقل با منطق و اهداف خودش است، نه یک ابزار منفعل.

Agent Card

هر ایجنتی که از A2A پشتیبانی می‌کند، یک سند JSON عمومی به نام Agent Card منتشر می‌کند — چیزی شبیه کارت‌ویزیت ماشین‌خوان. این کارت شامل نام ایجنت، توضیح قابلیت‌هایش (Skills)، آدرس اندپوینت، و نیازمندی‌های احراز هویت است. مفهوماً دقیقاً همان نقشی را دارد که فایل ucp.json برای یک فروشگاه دارد؛ فقط این‌بار «فروشگاه» یک ایجنت دیگر است.

کشف ایجنت (Discovery)

پیش از هر تعامل، ایجنت مبدا باید بفهمد ایجنت مقصد اصلاً چه کارهایی بلد است. طبق مشخصات A2A، هر ایجنت Agent Card خودش را روی یک آدرس استاندارد و شناخته‌شده منتشر می‌کند: /.well-known/agent.json. این یعنی کشف کردن قابلیت‌های یک ایجنت ناشناس، فقط با داشتن دامنه‌ی آن ممکن است — بدون نیاز به مستندسازی دستی یا هماهنگی از قبل بین دو تیم توسعه.

چرخه عمر Task

واحد اصلی کار در A2A یک Task است که مراحل مشخصی را طی می‌کند:

1. submitted — ایجنت مبدا وظیفه را ارسال می‌کند
2. working — ایجنت مقصد در حال پردازش است (ممکن است پیام‌های میانی/وضعیت بفرستد)
3. input-required — اگر اطلاعات بیشتری لازم باشد، از ایجنت مبدا سوال می‌پرسد
4. completed / failed — وظیفه با یک نتیجه‌ی نهایی (Artifact) یا خطا به پایان می‌رسد

پیام‌ها و Artifact

ایجنت‌ها در طول یک Task با رد و بدل کردن Messageها ارتباط برقرار می‌کنند (متن، فایل یا داده‌ی ساخت‌یافته)، و نتیجه‌ی نهایی به‌شکل یک یا چند Artifact (مثلاً یک سند، تصویر یا رکورد JSON) تحویل داده می‌شود.

به‌روزرسانی جریانی و Push Notification

بسیاری از Taskها فوری تمام نمی‌شوند — مثلاً «رزرو حمل‌ونقل» ممکن است چند دقیقه یا حتی چند ساعت طول بکشد. A2A برای این حالت دو مکانیزم دارد:

• استریم با SSE (Server-Sent Events) — وقتی هر دو ایجنت آنلاین و متصل می‌مانند، ایجنت مقصد می‌تواند وضعیت‌های میانی Task را به‌محض تولید، در یک اتصال باز به‌صورت جریانی ارسال کند.
• Push Notification (Webhook) — برای Taskهای طولانی‌مدت که اتصال زنده نگه‌داشتن آن‌ها منطقی نیست، ایجنت مبدا یک آدرس Webhook می‌دهد و ایجنت مقصد هر وقت وضعیت Task تغییر کرد (مثلاً از working به completed)، یک درخواست HTTP به آن آدرس می‌زند.

انتخاب بین این دو، به این بستگی دارد که آیا دو ایجنت می‌توانند یک اتصال باز را در طول کل اجرای Task حفظ کنند یا نه.

A2A در برابر MCP

نمونه: یک Agent Card ساده

{
  "name": "LogisticsAgent",
  "description": "پیگیری و رزرو مرسوله برای فروشگاه‌های آنلاین",
  "url": "https://logistics.example.com/a2a",
  "skills": [
    { "id": "create_shipment", "description": "ثبت یک مرسوله جدید" },
    { "id": "track_shipment", "description": "پیگیری وضعیت مرسوله" }
  ],
  "authentication": { "schemes": ["bearer"] }
}

سوالات متداول