تیپ #۲۳

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

وقتی دو ایجنت را با کپی‌کردن خروجی یکی داخل پرامپت دیگری به هم وصل می‌کنید، اولین تغییر در هر طرف کل زنجیره را می‌شکند. پروتکل A2A جایش یک کارت ایجنت (Agent Card) می‌گذارد 🪪: فایل JSON در مسیر well-known/agent-card.json که مهارت‌ها، آدرس سرویس و روش احراز هویت را اعلام می‌کند، تا ایجنت کلاینت پیش از فرستادن حتی یک توکن بداند طرف مقابل چه کاری از دستش برمی‌آید. بعد از آن، کارها به‌صورت واحدهای ساخت‌یافته و حالت‌دار (submitted، working، input-required، completed) روی JSON-RPC رد و بدل می‌شوند و برای کارهای طولانی، استریم SSE و اعلان push در دسترس است. این را خواهر افقی MCP بدانید: یکی ایجنت را به ابزار وصل می‌کند و دیگری ایجنت را به ایجنت.

توضیح کامل‌تر

در سیستم‌های چندعاملی، ساده‌ترین راه این است که یک ایجنت مرکزی همه‌ی زمینه را در دست بگیرد و بقیه را با پرامپت صدا بزند؛ اما این الگو خیلی زود شکننده می‌شود، چون قرارداد مشخصی برای کشف توانایی‌ها، نسخه‌بندی و مدیریت خطا وجود ندارد. پروتکل A2A دقیقاً برای همین نقطه ساخته شده است: ایجنت‌ها مستقل و کدر (opaque) می‌مانند، یعنی حافظه، پرامپت سیستمی و ابزارهای داخلی‌شان با طرف مقابل به اشتراک گذاشته نمی‌شود. مکانیزم کار این‌طور است که هر ایجنت یک کارت ایجنت را در مسیر استاندارد well-known منتشر می‌کند و در آن مهارت‌ها، آدرس endpoint و طرح احراز هویت را اعلام می‌کند؛ ایجنت کلاینت اول کشف می‌کند و بعد یک Task ساخت‌یافته می‌فرستد. ارتباط روی JSON-RPC 2.0 و HTTPS انجام می‌شود، برای پاسخ‌های تدریجی از SSE استفاده می‌شود و برای کارهای طولانی، ایجنت می‌تواند نتیجه را با webhook به سمت کلاینت push کند. چرخه‌ی عمر Task حالت‌های مشخصی دارد (submitted، working، input-required، completed، failed) و حالت input-required همان جایی است که می‌توانید انسان را در حلقه نگه دارید. یک مثال ملموس: ایجنت سفر شما بدون اینکه بداند ایجنت پرواز از چه مدلی استفاده می‌کند، کارت آن را می‌خواند و یک Task رزرو بلیت می‌فرستد، همزمان به ایجنت هتل هم Task دیگری می‌دهد و هر دو را موازی پیش می‌برد. نکته‌ی مهم این است که A2A جایگزین MCP نیست؛ MCP اتصال عمودی ایجنت به ابزار و داده است و A2A اتصال افقی ایجنت به ایجنت.