شاید کمتر تکنولوژیای در طول تاریخ به سرعت هوشمصنوعی مولد فراگیر شده باشه. فقط ChatGPT، از ۳۰ نوامبر ۲۰۲۲ که عَرضه عمومی شد تا روزی که رکورد صدمیلیون کاربر رو برای خودش ثبت کرد، فقط ۶۰ روز نیاز داشت و امروز بعد ۳ سال و نیم، حدود یک میلیارد کاربر داره. این میزان رشد و فراگیر شدن، محدود به تعداد کاربرها نبود؛ بلکه مشابه همین گستره رو امروز، در قالب یک اکوسیستم عظیم از کاربردها، سرویسها و پروتکلها هم حول و حوشش میشه دید.
حدود ۲ سال بعد از معرفی اولین نمونه chatbotهای مبتنی بر LLM برای عموم مردم، استاندارد MCP توسط Anthropic معرفی شد، چون دیگه چتکردن و ساختن خروجیهای ساختاریافته به شیوههای دلخواه، پاسخگوی طیف وسیع نیازها نبود. MCP یک چارچوب استاندارد برای ادغام سیستمهای هوش مصنوعی با منابع (مثل فایلها و دیتابیسها)، ابزارها (مثل نرمافزاری که API رو صدا میزنه یا کوئری رو اجرا میکنه یا روی فایلها کاری میکنه) و پرامپتها است. انواع MCP سرورها ارائه شدن و باز هم چتباتها کاراتر شدن.
در بازهی زمانی مذکور، از چتبات ساده به Prompt Engineering، بعدتر به Tool Calling، بعدش همMCP رسیدیم؛ و خیلی زود ایجنتها وارد این حوزه شدن و به سرعت هم فراگیر شدن. به بیا ساده، MCP و ایجنتها، فناوریهای مکمل همدگیه هستن. یعنی ایجنتها امکان فعالیت و تصمیمگیری مستقل دارن، در حالی که MCP لایه زیرساخت استانداردیه که ایجنتها رو به طور ایمن به ابزارها و دادههای خارجی متصل میکنه. ایجنت رو به عنوان «مغز» و MCP رو به عنوان «پُل» میشه در نظر گرفت. با مطرح شدن ایجنتها و رشد سریعشون، لزوم ارتباطگیری بین ایجنتی مطرح شد.
مثال:
فرض کنید شما توی تیم توسعه، میخواهید رویکرد AI-Native داشته باشید و از ایجنتها برای توسعه استفاده کنید. توی شرکتتون از جیرا برای مدیریت تیکتها و از کانفلوئنس برای مدیریت مستندات، و از گیتهاب هم برای نگهداری کدها و CI/CD استفاده میکنید. حالا برای اینکه LLM بتونه با جیرا حرف بزنه، شما نیاز به MCP دارید که API جیرا رو برای جستجو، خوندن، ایجاد کردن، ویرایش تیکتها بفهمه، و MCP دیگهای برای اینکه مستندات رو توی کانفلوئنس جستجو کنه بخونه، یا ویرایش کنه نیاز دارید؛ و همچنین MCP دیگهای هم برای معرفی API گیتهاب برای اینکه خوندن کدها، کامیتها، برنچها و پیآرها به LLM رو محیا کنن. چون MCP پروتوکول استاندارده، دیگه فرقی نداره مدل شما OpenAI ای است یا آنتروپیکی یا گوگلی یا…
با داشتن MCP شما فقط پل ارتباطی با جیرا و کانفلوئنس و گیتهاب دارید؛ برای اینکه قبل از توسعه، «بررسی» دقیق انجام بدیم؛ یه ایجنت میسازیم که وقتی تیکت جدیدی برای توسعه بهمون میرسه؛ وظیفهاش برنامهریزی بر اساس تیکتهای مشابه، مستندات قبلی، و پیآرهای قبلی و اینکه پیادهسازیهای مشابه قبلی چطوری انجام شده باشه. این ایجنت از هر ۳ تا MCP قبلی استفاده میکنه و «هدفِ» برنامهریزی رو تا رسیدن به پاسخش دنبال میکنه.
حالا همین مثال رو بسط بدیم به شرایطی که انواع این ایجنتها قراره تا با هم حرف بزنن، اونی که برنامهریزی میکنه، خروجی رو جمعبندی کنه بده به اونی که توسعه میده، بعد از توسعه، بده به اونی که قراره مرور کنه ببینه چیزی از قلم نیوفتاده، بعد بده به ایجنتی که استانداردهای کدنویسی و امنیت رو چک میکنه و تا مرحله دپلوی در محیط stage و خوندن لاگها و… دنبال کنن تا برسه به محیط عملیاتی و after care محصول.
جایی که قراره ایجنتها با هم حرف بزنن، مفاهیمی مثل A2A و ACP وارد داستان میشون. شاید پرسش براتون پیش بیاد که چرا یک اَبَرایجنت نداشته باشیم که همهفنحریف باشه؟ چرا باید ایجنتها با هم حرف بزنن و تعامل داشته باشن؟
پاسخ: یه دلیلش مفهوم کانتکست توی LLMهاست که خیلی مهمه، یعنی داریم در مورد چی فکر میکنیم و حرف میزنیم، این شامل ورودی ما به LLM و خروجیای که بهمون برمی گردونه میشه. ساختار LLMها طوریه که اگر کانتکست شلوغ و گسترده بشه، دقت و کیفیت خروجیشون پایین میاد. پس بهتره to-the-point صحبت کنیم باهاش. ایجنتی که صد جور کار کنه، هم منابع پردازشی بیشتری نیاز داره (افزایش هزینه و البته ردپای کربن!) و هم کیفیت پاسخهاش پایین میاد. پس بهتره ایجنتهای ما متخصص باشن تا آچار فرانسه.
دلیل دوم هم اینه که توی شرکتهای متوسط و بزرگ، ایجنتها توسط تیمهای مختلف یا شرکتهای دیگه توسعه داده میشن. پس باید بلد باشن یا یه استاندارد جهانشمول با هم حرف بزنن.
به همین دلایل که گفتم، خیلی سریع بعد از پیدایش MCP، ایجنتها معرفی، و خیلی سریع پروتکل ارتباطی بینشون ایجاد شد. یعنی اکثر سیستمهای هوش مصنوعی که مثل جزیرههای مجزا بودند، و هر ایجنت میتونست به ابزارهای خودش دسترسی داشته باشه، تسکهای خودش رو انجام بده و جواب برگردونه؛ ولی اگه میخواست با یک ایجنت دیگر کار کنه، عاجز میموند. مثل اینکه که دو نفر متخصص حرفهای از دو شرکت متفاوت بخوان با هم همکاری کنن، اما زبون مشترکی نداشته باشن. (مثلا ایجنت CRM شما از شرکت A بخواد با ایجنت ERP شما از شرکت B حرف بزنه). بدون یک پروتکل مشترک، مجبوریم برای هر اتصال، integration اختصاصی بنویسیم. یعنی همون کابوسی که سالها در enterprise integration بود دوباره تکرار میشد، فقط این بار با ایجنتها. Agent2Agent (A2A) و Agent Communication Protocol (ACP) تلاش کردن جلوی همین آشفتگی رو بگیرن.
⚠️ توجه: این ACP با ACP ای که چند خط بعد خواهم گفت فرق داره؛ این Agent Communication Protocol (ACP) در ماه مارچ ۲۰۲۵ توسط IBM Research و در بستر BeeAI مطرح شد. BeeAI خودش پروژهای بود برای ساخت، اجرا، تست و اشتراک agentها. ACP نقش لایه ارتباطی رو در این فضا داشت. ولی Agent2Agent (A2A) یک ماه بعد توسط گوگل در اپریل ۲۰۲۵ معرفی شد؛ و بعدتر با نزدیک شدن جهتگیری این دو پروژه، تیم ACP اعلام کرد که ACP در A2A ادغام میشه و توسعه فعال ACP به شکل مستقل متوقف خواهد شد. به بیان سادهتر، به جای اینکه دو تا استاندارد موازی برای agent communication داشته باشیم، مسیر به سمت یکی شدن با A2A رفت.ولی نهایتا در سپتامبر ۲۰۲۵ هر دو یعنی ACP با A2A تحت چتر بنیاد لینوکس ادغام شدند.
ولی اگر از سال ۲۰۲۶ عبارت ACP شنیدید؛ احتمالا Agent Client Protocol (ACP) خواهد بود، که چون Client و Communication هر دو با C شروع میشن؛ مخففش همون ACP میشه. این ACP جدیدهم یک استاندارد متنبازه که JetBrains و Zed ایجاد کردن و به دستیار کدنویسی و ایجنتها اجازه میده تا به صورت یکپارچه با ویرایشگرهای کد و IDEها ارتباط برقرار کنن. این پروتکل، عاملها را از ویرایشگرهای خاص جدا میکند و تضمین میکنه که میتونید از هر عامل هوش مصنوعی سازگار با ویرایشگر کد دلخواهتون استفاده کنید.
چون A2A و ACP ادغام شدند و تحت عنوان A2A ادامه داره، من با A2A ادامه میدم. A2A هدفش اینه که ایجنتها بتونن مستقل از اینکه با چه framework، زبان، vendor یا زیرساختی ساخته شدن، با هم ارتباط برقرار کنن.
نکته مهمش اینه که قرار نیست A2A ایجنت رو تبدیل به یک tool ساده کنه، چون وقتی شما یک API یا tool رو صدا میزنید، معمولا ورودی میدید و خروجی میگیرید. اما ایجنت معمولا رفتار پیچیدهتری داره. ممکنه task رو بفهمه، یا اینکه نیاز پیدا کنه سوال تکمیلی بپرسه، یا چند مرحلهای فکر کنه، وضعیت کارش رو گزارش بده، artifact تولید کنه، یا حتی درگیر یک کار طولانی چند ساعته بشه. اینا همه شرایطی هستن که باید پروتکل پشتیبانی کنه. برای همین هم ما در A2A چند مفهوم کلیدی داریم:
Agent Card (Agent Discovery)
هر ایجنت باید بتونه خودش رو معرفی کنه. یعنی بگه من چه کاری بلدم، چه modalityهایی رو پشتیبانی میکنم، چطور باید با من صحبت کرد، برای احراز هویت چه authentication schemeهایی دارم و چه endpointهایی ارائه میدم. این شبیه یک کارت شناسایی برای agent است. مثلا یک ایجنت میتونه بگه:
- من متخصص تولید گزارش مالی هستم.
- ورودی من text و structured data است.
- خروجی من PDF، جدول و summary است.
- برای استفاده از من باید OAuth token داشته باشید.
- کارهای long-running رو هم پشتیبانی میکنم.
حالا یه ایجنت دیگه میتونه قبل از اینکه کاری رو واگذار(delegate) کنه، بفهمه که آیا این ایجنت مناسب اون کار هست یا نه.
Task
در A2A ارتباط فقط چت ساده نیست. محور اصلی ارتباط، task است. یعنی یک ایجنت میتونه از یه ایجنت دیگه بخواد کاری رو انجام بده، وضعیت task رو پیگیری کنه و خروجی نهایی رو دریافت کنه.
این برای enterprise خیلیخیلی مهمه. چون توی سازمان واقعی، خیلی از کارها instant (دفعتی و در لحظه) نیستن. مثلا بررسی قرارداد، ساخت گزارش، تحلیل incident، آمادهسازی onboarding، بررسی compliance یا تولید مستندات release ممکنه چند دقیقه، چند ساعت یا حتی چند روز طول بکشه. A2A این رو میفهمه و از long-running task پشتیبانی میکنه.
Artifact
خروجی task فقط یک متن ساده نیست. ممکنه یک فایل، گزارش، فرم، نمودار، structured data یا هر artifact دیگهای باشه. A2A این مفهوم رو رسمی میکنه تا ایجنتها بتونن خروجیها رو به شکل قابل استفاده و قابل ردگیری مبادله کنن.
Modality Negotiation
یکی از ایدههای خوب A2A اینه که ایجنتها میتونن درباره نوع تعامل و خروجی مذاکره کنن. مثلا یک ایجنت ممکنه بتونه تصویر، فرم، ویدیو، فایل یا متن تولید کنه، اما ایجنت مصرفکننده یا UI نهایی فقط بعضی از اونها رو پشتیبانی کنه. پس به جای اینکه همه چیز رو به text تقلیل بدیم، پروتکل کمک میکنه تا دو طرف بفهمن چه فرمتی برای این تعامل مناسبتره.
چرا اینها مهماند؟
چون اگر agentها جدی شن (که دارن روز به روز جدیتر میشن)، معماری نرمافزار هم تغییر میکنه.
ما سالها درباره microservice حرف زدیم. بعد درباره event-driven architecture، API gateway، service mesh، workflow engine، orchestration و choreography حرف زدیم. حالا agentها دارند وارد همون بازی میشن. اما agent با microservice فرق داره. microservice معمولا contract مشخص داره. endpoint داره. schema داره. behavior ش تا حد زیادی deterministic است. اما agent ممکنه reasoning کنه، سوال بپرسه، task رو refine کنه، خروجی مرحلهای بده، و حتی بسته به context، مسیر متفاوتی رو انتخاب کنه. برای همین هم agentها به قرارداد ارتباطی متفاوتی نیاز دارن. نه صرفا OpenAPI کافی است، نه صرفا message queue، نه صرفا prompt. اینجا A2A تلاش میکنه برای این جنس همکاری، یه زبان مشترک ارائه بده.
مثال: پشتیبانی مشتری
فرض کنید یک شرکت SaaS دارید.
یک customer support agent پیام مشتری رو میگیره.
یک billing agent وضعیت invoice و subscription رو چک میکنه.
یک technical diagnostic agent لاگها و traces رو بررسی میکنه.
یک knowledge base agent مستندات مرتبط رو پیدا میکنه.
یک escalation agent تصمیم میگیره آیا ticket باید به انسان منتقل بشه یا نه. اینجا ایجنتها باید با هم حرف بزنن. مهمتر از اون، باید بدونن هر کدوم چه کاری بلدن، وضعیت task چیه، چه دادهای رد و بدل شده و خروجی نهایی چیه.
اگر این ارتباط استاندارد نباشه، خیلی زود سیستم تبدیل میشه به یک spaghetti از API callها، promptها و glue codeها و بدون خروجی مشخص.
مثال Enterprise HR
حالا بریم سراغ یک مثال توی محیط enterprise. فرض کنید یک سازمان بزرگ میخواد فرآیند onboarding رو agentic کنه.
یک agent از سیستم recruitment اطلاعات candidate رو میگیره.
یک agent قرارداد رو بر اساس country و role آماده میکنه.
یک agent تجهیزات لازم برای شروعبهکار کارمند رو سفارش میده.
یک agent دسترسیهای IT رو provision میکنه.
یک agent training plan رو برای آموزشهای اولیه کارمند تنظیم میکنه.
یک agent calendar جلسات onboarding رو میسازه.
یک agent compliance بررسی میکنه که همه چیز طبق policy انجام شده باشه.
در چنین سناریویی، سیستمها معمولا از vendorهای مختلف هستن: Workday، ServiceNow، SAP، Microsoft 365، ابزارهای داخلی، دیتابیسهای قدیمی و سرویسهای custom. اینجا A2A ارزشش رو نشون میده. چون هدفش دقیقا اینه که ایجنتها بتونن روی platformها و vendorهای مختلف با هم همکاری کنن، بدون اینکه هر ایجنت مجبور باشه پیادهسازی داخلی ایجنت دیگه رو بشناسه.
کجا به A2A نیاز داریم و کجا نداریم؟
این سؤال خیلی مهمه. چون هر تکنولوژی جدیدی که میاد، خطر overengineering و جوگیری هم با خودش میاره. (که اِلا و بِلا باید همه جا بچپونیمش!)
اگر شما فقط یک chatbot ساده دارید که به یک دیتابیس وصل میشه، A2A لازم ندارید. احتمالا MCP یا حتی یک tool calling ساده کافیه.
اگر یک ایجنت دارید که فقط چند API داخلی رو صدا میزنه، باز هم شاید A2A لازم نباشه. اگه همه چیز داخل یک کدبیس کوچیکه و ایجنتها واقعا مستقل نیستن، A2A ممکنه بیشتر پیچیدگی بیاره تا «ارزش».
اما اگر چند ایجنت مستقل دارید، چند تیم روی اونها کار میکنن، frameworkها متفاوتاند، vendorها متفاوتاند، taskها long-running هستن، خروجیها multimodal هستن، یا لازمه که ایجنتها capability discovery و collaboration داشته باشن، اونوقت A2A جدی میشه.
به بیان ساده:
برای tool access، اول به MCP فکر کنید.
برای agent collaboration، به A2A فکر کنید.
برای workflow داخلی ساده، شاید orchestration معمولی کافی باشه.
برای کارهای deterministic و حساس، شاید اصلا agent انتخاب درستی نباشه و همون سرویس کلاسیک بهتر باشه.
چالشها و ریسکها
حالا نباید فکر کنیم با A2A همه مشکلات حل میشه. اتفاقا وقتی ایجنتها با هم حرف میزنن، چند مسئله سختتر میشه.
اول، security. اگر ایجنتها بتونن task به هم واگذار کنن، باید دقیق بدنیم چه کسی مجازه چه کاری انجام بده. احراز هویت و حق دسترسی جدیتر میشه.
دوم، observability. رهگیری، در سیستمهای توزیعشده معمولی هم سخت بود. حالا تصور کنین چندین ایجنت با reasoning غیرقطعی با هم تعامل دارن. باید بتونیم بفهمیم کدوم ایجنت چه تصمیمی گرفته، چه ورودیای داشته، چه خروجیای داده و چرا task fail شده.
سوم، governance. توی محیط enterprise نمیشه اجازه داد هر ایجنتی هر کاری دلش خواست بکنه. policy، approval، audit log و human-in-the-loop همچنان مهم هستن؛ مثلا توی یک محیط انترپرایز چند ملیتی، کافیه بخشی از دیتا یا آدمهای درگیر باهاش توی اروپا باشن، اونوقت کلی ضابطه و قانون محلی به رفتارها و دیتا و فرایند اعمال میشه .
چهارم، cost. وقتی چند ایجنت با هم کار میکنن، مصرف توکن، latency و هزینه زیرساخت میتونه یهو بالا بره.
پنجم، reliability. ایجنتها همیشه deterministic نیستن و میتونن با ورودی ثابت، خروجی متفاوتی بدن. پس باید retry، timeout، fallback، validation و guardrail داشته باشیم.
ششم، UX. وقتی نحوه تعامل کاربر و اونچه که پشت سیستم داریم، اینقدر متفاوت از گذشته میشه؛ دیگه UX و UI با نگاه گذشته کار نخواهد کرد! نیاز به بازتعریف و طراحی پایهای داره. و این تخصص کمیابیه حداقل الان. نمیشه با رویکرد و نگاه گذشته UXی تعریف کنیم که مناسب برای فرمها و منوهای سنتی است. این بخش، بسیار پرهزینه است و شوخی نگیریمش!
مثال مشابه این، در خودروها داریم؛ وقتی کارهایی که انسانبه صورت سنتی از گذشته تا امروز انجام میداد، مثل رانندگی، رو سپردیم به هوشمصنوعی، دکمهها کم شد؛ و برای برخی انواع جدید خودروها، فرمون و پدال و راهنما و… رو هم حذف کردن؛ و UX کاملا جدیدی رو طراحی کردن.
همه این چالشها یعنی A2A زبان مشترک میده؛ اما معماری خوب همچنان لازمه!
یک الگوی ساده معماری
اگر بخوام یک معماری ساده و قابل فهم پیشنهاد بدم، اینه:
در لایه اول، ایجنتهای تخصصی دارید. مثلا HR Agent، Legal Agent، Finance Agent، Support Agent.
در لایه دوم، هر agent برای دسترسی به ابزارها و سیستمهای خودش از MCP یا tool integrations استفاده میکنه.
در لایه سوم، agentها برای همکاری با هم از A2A استفاده میکنن.
در لایه چهارم، یک orchestration یا supervisor وجود داره که taskهای بزرگ رو مدیریت میکنه، اما قرار نیست همه جزئیات رو hard-code کنه.
در لایه پنجم، observability، policy، audit، security و cost control قرار میگیره.
این نگاه کمک میکنه ایجنتها رو با معماری نرمافزار اشتباه نگیریم. ایجنت فقط یک قطعه هوشمنده، نه جایگزین discipline معماری.
جمعبندی
A2A از یک نیاز واقعی اومده: اکوسیستم ایجنتها اگر قرار باشه جدی بشه، نمیتونه با integrationهای دستی و promptهای پراکنده جلو بره.
A2A تلاش میکنه یک استاندارد باز برای ارتباط بین ایجنتها بسازه تا ایجنتها بتوانن قابلیتهای همدیگه رو کشف کنن، task تعریف کنن، وضعیت کار رو پیگیری کنن، خروجی تولید کنن و بدون افشای پیادهسازیشون با هم همکاری کنن.
برای تیمهای کوچیک، این مفاهیم شاید اوایل پیچیده بیان، اما اگه چند ایجنت مستقل داشته باشن، ارزششون معلوم میشه. برای enterpriseها، اهمیتش حتی بیشتره. چون ایجنتها قراره روی سیستمهای مختلف، vendorهای مختلف و فرآیندهای واقعی سازمانی کار کنن.
در نهایت، نکته اصلی اینه:
آینده فقط این نیست که هر نرمافزار یک ایجنت داشته باشه. آینده احتمالا اینه که مجموعهای از ایجنتهای تخصصی، تحت governance درست، با هم همکاری کنن. A2A یکی از تلاشهای جدی برای ساختن زبان مشترک این همکاریه.
اما مثل همیشه، ابزار جای معماری رو نمیگیره. اگر مسئله ساده است، ساده نگهش دارید. اگر مسئله واقعا چند-ایجنتی است، چندتیمی، چندسیستمی و long-running است، اون وقت A2A دیگه یک buzzword نیست، یک نیاز معماریه. این رو هم فراموش نکنید، زیرساخت پایدار و قابل اتکا برای AI چیز ارزونی نیست اصلا. PoC با دنیای واقعی فرق داره. و سازمان و محصول رو فدای ماجراجویی و تجربهی چیزهای جالب و نو نکنیم. به بیان ساده، پیش از کندن چاه، به فکر سرقت مناره نباشیم…