میراث FIPA-ACL و نظریه کنش گفتار در پروتکل‌های ایجنت

با گسترش سیستم‌های چندایجنت و ظهور پروتکل‌های جدیدی مانند MCP و A2A، بسیاری تصور می‌کنند مفاهیم ارتباط میان ایجنت‌ها تازه متولد شده‌اند. واقعیت این است که زیرساخت تئوریک و معماری این ارتباطات بیش از دو دهه پیش در استاندارد FIPA-ACL و نظریه کنش گفتار فرمول‌بندی شده بود. شناخت این پیشینه به شما کمک می‌کند مرز میان نوآوری واقعی و بازاختراع چرخ را به درستی تشخیص دهید.

در سیستم‌های توزیع‌شده امروزی، حذف ساختارهای رسمی گذشته مانند هستی‌شناسی‌ها به نفع سینتکس‌های انعطاف‌پذیر JSON و مدل‌های زبانی، سادگی توسعه را به همراه داشته است؛ اما هم‌زمان خطاهایی مثل انحراف معنایی میان ایجنت‌ها پدید آورده است. یادگیری الگوهای تعاملی کلاسیک نظیر Contract Net مسیر طراحی معماری‌های پایدارتر و دقیق‌تر را هموار می‌کند.

کدها و پیاده‌سازی این درس کاملاً متکی بر کتابخانه‌های استاندارد پایتون هستند و بدون نیاز به سخت‌افزار خاص، کارت گرافیک یا اتصال به سرویس‌های ابری مسدودشده، روی سیستم شخصی شما اجرا می‌شوند.

پیش از MCP و قبل از A2A، پروتکل FIPA-ACL وجود داشت. در سال 2000، «بنیاد ایجنت‌های فیزیکی هوشمند» (FIPA که در سال 2005 به یکی از کمیته‌های استاندارد IEEE Computer Society تبدیل شد) یک زبان ارتباطی ایجنت را با بیست کلام‌کنش (Performative)، دو زبان محتوا و مجموعه‌ای از پروتکل‌های تعامل تصویب کرد؛ پروتکل‌هایی مثل Contract Net، Subscribe/Notify و Request-When. این استاندارد به مرور از صنعت کنار رفت؛ چون بار پردازشی و پیچیدگی هستی‌شناسی (Ontology) برای وب بسیار سنگین بود. با این حال، موج احیای سیستم‌های چندایجنت با مدل‌های زبانی بزرگ (LLM)، بی‌سروصدا در حال پیاده‌سازی دوباره‌ی همان ایده‌ها است، منتها بدون معناشناسی صوری (Formal Semantics): قراردادهای JSON جایگزین کلام‌کنش‌ها شده‌اند و زبان طبیعی جای هستی‌شناسی‌ها را گرفته است. در این درس، FIPA-ACL را دقیق و موشکافانه بررسی می‌کنیم تا ببینید کدام تصمیم‌های پروتکلی در سال 2026 اختراع دوباره‌ی چرخ‌اند، کدام واقعاً نوآوری محسوب می‌شوند و این موج فعلی در چه نقطه‌ای قرار است به همان مشکلاتی برسد که در دهه‌ی 2000 حل شده بودند.

صورت‌مسئله

فضای پروتکل‌های ایجنت در سال 2026 بسیار شلوغ است: MCP برای ابزارها، A2A برای ایجنت‌ها، ACP برای ممیزی سازمانی، ANP برای اعتماد نامتمرکز، NLIP برای محتوای زبان طبیعی، به اضافه‌ی CA-MCP و ده‌ها پروپوزال پژوهشی دیگر. هر مشخصه‌ای خودش را زیربنایی و بنیادین معرفی می‌کند.

واقعیت این است که بیشتر آن‌ها صرفاً در حال کشف دوباره‌ی یک درخت تصمیم (Decision tree) بیست‌ساله هستند. نظریه‌ی کنش گفتار (Speech-act theory) از آستین (1962) و سرل (1969) به ما نشان داد که «گفته‌ها همان عمل‌ها هستند». زبان KQML در سال 1993 این ایده را به یک پروتکل انتقال روی سیم تبدیل کرد. سپس FIPA-ACL (تصویب‌شده در سال 2000) استانداردسازی مرجع را رقم زد: بیست کلام‌کنش، زبان‌های محتوای SL0 و SL1، و پروتکل‌های تعاملی برای Contract Net و Subscribe/Notify. فریم‌ورک‌های JADE و JACK پلتفرم‌های مرجع جاوا بودند. این تلاش‌ها در حدود سال 2010 کم‌رنگ شدند؛ چرا که بار سنگین هستی‌شناسی برای وب بیش از حد دست‌وپاگیر بود و معماری وب در حال فتح همه‌چیز بود.

وقتی به tools/call در MCP، چرخه‌ی حیات تسک (Task Lifecycle) در A2A یا مخزن بافتار مشترک (Shared context store) در CA-MCP نگاه می‌کنید، در واقع نسخه‌ای ساده‌تر، منعطف‌تر و مبتنی بر JSON از همان تصمیم‌های FIPA را می‌بینید. شناخت این پیشینه دو نکته را روشن می‌کند: کدام «نوآوری‌های» جدید در واقع بازاختراع گذشته‌اند، و مشخصه‌های جدید با کدام حالت‌های شکست (Failure modes) قدیمی دوباره روبه‌رو خواهند شد.

مفهوم

کنش‌های گفتار در یک پاراگراف

آستین متوجه شد برخی جملات جهان را توصیف نمی‌کنند، بلکه آن را تغییر می‌دهند: «قول می‌دهم»، «درخواست می‌کنم»، «اعلام می‌کنم». او این جملات را گفته‌های کلام‌کنشی یا اجرایی نامید. سرل آن‌ها را در پنج دسته فرمول‌بندی کرد: حُکمی (Assertive)، هدایتی (Directive)، تعهدی (Commissive)، بیانی (Expressive) و اعلامی (Declarative). زبان KQML (فینین و همکاران، 1993) این مفهوم را برای ایجنت‌های نرم‌افزاری عملیاتی کرد: یک پیام شامل یک کلام‌کنش (عمل) به اضافه‌ی محتوا (موضوع عمل) است. استاندارد FIPA-ACL کاستی‌های KQML را برطرف کرد و حول بیست کلام‌کنش استاندارد شد.

بیست کلام‌کنش FIPA (فهرست منتخب)

فهرست کامل در سند fipa00037.pdf (با عنوان FIPA ACL Message Structure) آمده است. نیازی به حفظ کردن آن نیست؛ نکته اینجاست که تک‌تک این موارد معادل همان مفاهیم اولیه‌ای هستند که پروتکل‌های مدرن LLM در نهایت دوباره اضافه می‌کنند.

ساختار پیام استاندارد در FIPA-ACL

(inform
  :sender       agent1@platform
  :receiver     agent2@platform
  :content      "((price IBM 83))"
  :language     SL0
  :ontology     finance
  :protocol     fipa-request
  :conversation-id   conv-42
  :reply-with   msg-17
)

هفت فیلد بسته‌ی پوشش پروتکل را تشکیل می‌دهند؛ یک فیلد (content) بار داده (Payload) را حمل می‌کند. بقیه‌ی فیلدها دقیقاً همان چیزهایی هستند که هر بار هنگام اضافه کردن تلاش مجدد (Retry)، مدیریت رشته‌ها (Threading) و هستی‌شناسی به یک پروتکل JSON، از نو اختراع می‌کنید.

دو پلتفرم قدیمی

JADE (مخفف Java Agent DEvelopment framework، از 1999 تا دهه‌ی 2020) پرکاربردترین محیط اجرای (Runtime) سازگار با FIPA بود. ایجنت‌ها کلاسی پایه را بسط می‌دادند، پیام‌های ACL ردوبدل می‌کردند، داخل کانتینرها اجرا می‌شدند و با استفاده از رفتارهای تعریف‌شده («Behaviors») هماهنگ می‌شدند. کتابخانه‌ی پروتکل تعاملی آن به طور پیش‌فرض دارای الگوهای Contract Net، Subscribe/Notify، Request-When و Propose-Accept بود.

JACK (محصول Agent Oriented Software، تجاری) بر استدلال BDI (مخفف باور-میل-نیت: Belief-Desire-Intention) روی پیام‌های FIPA تمرکز داشت؛ سیستمی صوری‌تر با پذیرش کمتر در بازار.

هر دو پلتفرم زمانی که بستر وب سناریوهای چندایجنت را بلعید، افول کردند. پروتکل‌های MCP و A2A در واقع همان «کانتینرهای» محیط اجرای سال 2026 هستند.

دلایل افول FIPA

• بار سنگین هستی‌شناسی: FIPA برای پردازش فیلد content به یک هستی‌شناسی مشترک نیاز داشت. رسیدن به توافق روی هستی‌شناسی‌ها فرایند استانداردسازی چندساله‌ای بود، در حالی که دنیای وب خیلی ساده از ترکیب HTTP + JSON استفاده کرد.
• معناشناسی صوری که کسی استفاده نکرد: زبان SL (مخفف Semantic Language) شرایط صدق دقیقی فراهم می‌کرد، اما بیشتر سیستم‌های محیط عملیاتی (پروداکشن) از محتوای آزاد استفاده می‌کردند و ساختار صوری را نادیده می‌گرفتند.
• وابستگی انحصاری به ابزار (Tooling Lock-in): پلتفرم JADE فقط مخصوص جاوا بود و JACK نیز تجاری بود؛ در نتیجه تیم‌هایی با فناوری‌های چندزبانه، هر دو را دور زدند.
• پیروزی اینترنت در بستر انتقال: ابتدا REST، سپس JSON-RPC و بعد gRPC جای بستر انتقال (Transport) در ACL را گرفتند.

احیای مفاهیم در عصر LLM: بازگشت به نسخه‌ی سبک FIPA

یک request در FIPA را با tools/call در MCP مقایسه کنید:

(request                                {
  :sender  agent1                         "jsonrpc": "2.0",
  :receiver tool-server                   "method":  "tools/call",
  :content "(lookup stock IBM)"           "params":  {"name":"lookup_stock",
  :ontology finance                                   "arguments":{"symbol":"IBM"}},
  :conversation-id c42                    "id": 42
)                                        }

پوشش یکسان است، فقط سینتکس تفاوت دارد. هر دو شامل این اطلاعات هستند: فرستنده، گیرنده، نیت، بار داده و شناسه‌ی تطبیق (Correlation ID). هیچ‌کدام انقلابی نسبت به دیگری محسوب نمی‌شوند؛ هر دو صرفاً مصالحه‌های متفاوتی از یک طرح واحد هستند.

مقاله‌ی مروری سال 2025 توسط لیو و همکاران («بررسی پروتکل‌های تعامل‌پذیری ایجنت: MCP، ACP، A2A و ANP»، arXiv:2505.02279) این پیشینه‌ی مشترک را به صراحت نشان می‌دهد: پروتکل MCP متناظر با کنش‌های گفتار استفاده از ابزار است، A2A با کنش‌های گفتار بین ایجنت‌ها، ACP با کنش‌های گفتار ردگیری ممیزی، و ANP با توسعه‌های هویت نامتمرکز. مشخصه‌های جدید در اصل نوادگان ACL هستند، منتها با سینتکس JSON و بار معنایی ساده‌تر.

موازنه‌ها و تصمیم‌ها در یک نگاه

آنچه FIPA در اختیارتان می‌گذاشت و مشخصه‌های مدرن آن را حذف کرده‌اند:

• معناشناسی صوری — می‌توانید اثبات کنید که inform نشان می‌دهد فرستنده به درستیِ محتوا باور دارد.
• مجموعه‌ای استاندارد و کامل از کلام‌کنش‌ها — لازم نیست دوباره بحث کنید که «آیا به عمل cancel نیاز داریم یا نه؟».
• دهه‌ها الگوی آزموده‌شده‌ی تعاملی — الگوهایی مثل Contract Net، Subscribe/Notify و Propose-Accept که ویژگی‌های درستیِ عملکرد آن‌ها اثبات شده است.

آنچه مشخصه‌های مدرن ارائه می‌دهند و FIPA فاقد آن بود:

• بارهای داده بر پایه‌ی JSON و سازگار با تمام ابزارهای امروزی.
• محتوای متنی به زبان طبیعی که مدل‌های زبانی می‌توانند بدون نیاز به هستی‌شناسی دستی آن را تفسیر کنند.
• بسترهای انتقال وب‌محور (HTTP، SSE، WebSocket).
• کشف قابلیت‌ها به‌صورت زنده از طریق server/discover در MCP و کارت‌های ایجنت (Agent Cards) در A2A.

دادن آزادی بیشتر به بار معنایی در ازای سادگی پیاده‌سازی؛ کل ماجرا دقیقاً همین مبادله است.

پروتکل‌های تعاملی باارزش برای انتقال به سیستم‌های امروزی

استاندارد FIPA نزدیک به 15 پروتکل تعاملی داشت. حفظ و انتقال سه مورد از آن‌ها به سیستم‌های چندایجنت مدرن مبتنی بر LLM ارزش بالایی دارد:

1. پروتکل Contract Net (یا CNP): مدیر سیستم یک cfp (فراخوان پیشنهاد) منتشر می‌کند؛ شرکت‌کنندگان با propose پاسخ می‌دهند؛ مدیر این پیشنهادها را می‌پذیرد یا رد می‌کند. این همان الگوی مرجع بازارهای وظیفه است (فاز 16 · 16 مذاکره).
2. الگوی Subscribe/Notify: مشترک پیام subscribe را ارسال می‌کند؛ ناشر هر زمان که موضوع تغییر کند یک پیام inform می‌فرستد. تمام Event Busهای سال 2026 بر همین اساس کار می‌کنند.
3. الگوی Request-When: «وقتی شرط Y برقرار شد، کار X را انجام بده». اجرای عمل با تأخیر بر اساس پیش‌شرط‌ها. معادل آن در سال 2026 وظایف معوق در موتورهای جریان کاری (Workflow) پایدار است (فاز 16 · 22 مقیاس‌پذیری در پروداکشن).

هر یک از این الگوها به‌سادگی روی صف‌های پیام مدرن، سازوکار HTTP + Polling، یا استریمینگ (Streaming) مبتنی بر SSE پیاده‌سازی می‌شوند.

پیامدهای حذف هستی‌شناسی چیست؟

وقتی دایره‌ی واژگان مشترک (Shared Vocabulary یا همان هستی‌شناسی) وجود نداشته باشد، ایجنت‌ها معنا را از محتوای زبان طبیعی برداشت می‌کنند. حالت شکست ثبت‌شده در سال 2026، انحراف معنایی (Semantic Drift) است: دو ایجنت از یک کلمه‌ی یکسان (مثلاً "customer") برای دو مفهوم کمی متفاوت استفاده می‌کنند، ایجنت دریافت‌کننده بر اساس برداشتی اشتباه دست به عمل می‌زند، و هیچ اعتبارسنجی اسکیمایی هم متوجه این خطا نمی‌شود. اگر از FIPA استفاده می‌شد، شرط هستی‌شناسی مانع از پذیرش پیام در همان مرحله‌ی پردازش و پارس اولیه می‌شد.

راهکارهای کاهش خطا بدون نیاز به پیاده‌سازی کامل هستی‌شناسی:

• اسکیمای JSON روی content — خطاهای ساختاری را در همان لایه‌ی انتقال رد می‌کند.
• دست‌سازه‌های نوع‌دار (Typed Artifacts در A2A) — ارائه‌ی داده با شیوه‌ی نادرست را رد می‌کند.
• کلام‌کنش صریح در پوشش پیام — باعث می‌شود نیت پیام کاملاً شفاف بماند، حتی اگر محتوا به زبان طبیعی باشد.

تطبیق مشخصه‌های سال 2026 با ریشه‌های کنش گفتار

اگر جدول را از بالا به پایین مرور کنید، الگوی کلی مشخص است: ساختار پایه را حفظ کن، فرمالیسم را کنار بگذار و بگذار مدل‌های زبانی روی ابهامات سرپوش بگذارند.

پیاده‌سازی

فایل code/main.py یک مترجم FIPA-ACL را تنها با استفاده از کتابخانه‌ی استاندارد پایتون پیاده‌سازی می‌کند. این کد پوشش استاندارد ACL را رمزگذاری و رمزگشایی (Decode) می‌کند و نشان می‌دهد که چطور هر فرم پیام در MCP یا A2A در نهایت به همان هفت فیلد تبدیل می‌شود. این دمو:

• پنج پیام به سبک MCP و A2A را در قالب FIPA-ACL رمزگذاری می‌کند.
• پیام‌های FIPA-ACL را به فرمت‌های مدرن معادلشان رمزگشایی می‌کند.
• یک مذاکره‌ی ساده بر اساس پروتکل Contract Net بین یک مدیر و سه شرکت‌کننده با استفاده از cfp، propose، accept-proposal و reject-proposal اجرا می‌کند.

اجرا:

python3 code/main.py

خروجی این اسکریپت، یک ردگیری محاسبات (Trace) مقایسه‌ای است که هر پیام مدرن را در هر دو قالب JSON سال 2026 و فرمت FIPA-ACL در کنار هم نشان می‌دهد و سپس رفت‌وبرگشت یک پیشنهاد در الگوی Contract Net را اجرا می‌کند. مفاهیم پایه‌ای پروتکل در این تبدیل رفت‌وبرگشتی دست‌نخورده باقی می‌مانند؛ تنها تفاوت، در سینتکس است.

نحوه‌ی استفاده

فایل outputs/skill-fipa-mapper.md مهارتی است که متن هر مشخصه‌ی پروتکل ایجنت را می‌خواند و نگاشت معادل آن در FIPA-ACL را استخراج می‌کند. پیش از انتخاب و پیاده‌سازی هر پروتکل جدید، از این فایل کمک بگیرید تا مشخص شود: «آیا این پروتکل ایده‌ای واقعاً جدید دارد، یا همان inform قدیمی با سینتکس JSON است؟»

استقرار در پروداکشن

قرار نیست FIPA-ACL را دوباره زنده کنید، بلکه باید چک‌لیست کاربردی آن را همراه داشته باشید:

• مؤلفه‌ی پایه‌ی نیت (کلام‌کنش) در هر پیام چیست؟
• آیا شناسه‌ی تطبیق برای اتصال درخواست-پاسخ و عملیات لغو (Cancellation) وجود دارد؟
• آیا زبان محتوا صریح مشخص شده است (مانند JSON-RPC، متن ساده یا دست‌سازه‌ی نوع‌دار ساخت‌یافته)؟
• آیا پروتکل‌های تعامل به‌صورت مفاهیمی درجه‌یک تعریف شده‌اند، یا مجبورید Contract Net را از ابتدا خودتان پیاده کنید؟
• اگر دو ایجنت بر سر معنای محتوا دچار اختلاف شوند (انحراف معنایی)، چه اتفاقی می‌افتد؟

پیش از ورود هر پروتکل جدید به محیط عملیاتی (پروداکشن)، پاسخ این پنج پرسش را مستند کنید.

تمرین‌ها

1. اسکریپت code/main.py را اجرا کنید. روند رمزگذاری رفت‌وبرگشتی را ببینید. بررسی کنید کدام کلام‌کنش در FIPA معادل tools/call، resources/read و ایجاد تسک در A2A است.
2. دموی Contract Net را طوری توسعه دهید که شامل کلام‌کنش cancel باشد تا مدیر بتواند تسک را در میانه‌ی پیشنهادها پس بگیرد. کلام‌کنش cancel چه نوع حالت شکستی را حل می‌کند که مکانیزم‌های Retry به‌تنهایی قادر به حل آن نیستند؟
3. بخش‌های 4.1 تا 4.3 از مستند FIPA ACL Message Structure (در آدرس http://www.fipa.org/specs/fipa00037/) را بخوانید. یکی از کلام‌کنش‌هایی را که در این درس بررسی نشد انتخاب کنید و معادل مدرن آن را در قالب JSON-RPC شرح دهید.
4. مقاله‌ی Liu et al. (به آدرس arXiv:2505.02279) را مطالعه کنید. برای هر یک از پروتکل‌های MCP، A2A، ACP و ANP بنویسید که کدام دسته‌های کلام‌کنش FIPA را حفظ کرده و کدام موارد را کنار گذاشته‌اند.
5. یک اسکیمای JSON حداقلی برای فیلد content در کلام‌کنش request متناسب با سیستم خود طراحی کنید. این اسکیما چه امکاناتی به شما می‌دهد که زبان طبیعیِ صِرف نمی‌دهد، و چه هزینه‌ای به سیستم تحمیل خواهد کرد؟

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

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

• Liu et al. — A Survey of Agent Interoperability Protocols: MCP, ACP, A2A, ANP — مقاله‌ی مرجع سال 2025 که مشخصه‌های مدرن را به پیشینه‌ی FIPA پیوند می‌دهد.
• FIPA ACL Message Structure Specification (fipa00037) — سند رسمی مصوب سال 2000 درباره‌ی فرمت پوشش پیام‌ها.
• FIPA Communicative Act Library Specification (fipa00037) — کاتالوگ و مرجع کامل تمام کلام‌کنش‌ها.
• MCP specification 2026-07-28 — مشخصه‌ی استفاده از ابزارِ بی‌وضعیت فعلی به عنوان معادل request و query-ref.
• A2A specification — معادل امروزی پروتکل‌های ارتباط همتا-به-همتا برای Contract Net و Subscribe/Notify.