FIPA ACL 完整解析：multi-agent 系統的通訊標準、22 個 performatives 與 JADE 實作指南

在 LLM agent 滿天飛的 2026 年，為什麼還要回頭研究一個 1996 年從瑞士日內瓦發起的舊協議？

先說結論：FIPA ACL（Foundation for Intelligent Physical Agents – Agent Communication Language） 是一套定義多個自主軟體 agent 之間怎麼用一致語意對話的標準，1996 年由 FIPA 在瑞士創立、2005 年併入 IEEE。它把哲學家 Austin 和 Searle 提出的 speech act theory 編成可實作的協議，用 22 個 performatives 把「告知」「請求」「同意」「拒絕」這些對話行為形式化，並用 belief、intention、rational effect 這些 mental attitudes 給每個訊息一個精確的數學語意。今天 Anthropic 的 MCP、Google 的 A2A、ANP 這些 LLM 時代的 agent 協定，設計時繞不開的核心問題，FIPA 在三十年前就先解過一次。

這篇要做的事：從訊息結構、22 個 performatives 的完整地圖、形式語意基礎、SL 內容語言、interaction protocols、JADE 的 Java 實作，一路講到 KQML 的繼承關係，最後接到 2026 年的協定演進。文章主軸是技術深度而不是商業判斷——適合正在設計 multi-agent 架構、或想搞清楚 MCP/A2A 來歷的工程師與技術主管。

一個值得先記住的數字——FIPA 在 2002 年正式發佈的 ACL 規範（FIPA00061、FIPA00037）至今仍是 IEEE Standards Committee 認可的標準文件，而根據 2025 年發表的 multi-agent interoperability 協定調查（arXiv 2505.02279），MCP、ACP、A2A、ANP 這四個 2024-2025 才出現的新協定，論文裡都把 FIPA ACL 列為「formal semantic foundation 的先例」。換句話說：研究 FIPA 不是考古，是去看新協定為什麼是現在這個樣子。

為什麼 LLM agent 時代還要懂 FIPA ACL

先講一個常被工程師問的問題：「我用 LangChain、AutoGen、CrewAI 就能跑 multi-agent 了，FIPA 跟我有什麼關係？」 表面上沒關係。實際上，當你的系統開始長大——agent 數量超過個位數、來自不同團隊、要跨組織協作——你會陸續撞到 FIPA 在 1996 年就在處理的同樣問題：

• 兩個 agent 怎麼確定彼此「在講同一件事」？同樣的字串對 A 是「下單」，對 B 可能只是「諮詢」。
• agent 收到一則訊息，怎麼知道對方要的是「告知資訊」「請求行動」還是「邀請報價」？
• 在開放、異質的環境裡，agent 怎麼證明自己理解了訊息、而不是只是收到 bytes？
• 多個 agent 同時搶一個任務時，協商流程要怎麼跑才能保證收斂？

這四個問題對應 FIPA ACL 的四個設計支柱：ontology（共享詞彙）、performative（言語行為類型）、formal semantics（形式語意）、interaction protocol（互動協定）。MCP 用 JSON-RPC schema 解第一個，A2A 用 task lifecycle 解第四個，但兩者對 performative 和 formal semantics 都還在演進階段。讀懂 FIPA 等於拿到一張完整地圖，知道新協定省掉了哪些東西、又把哪些東西重新發明了一次。

這是一個值得抓住的學習槓桿——把基礎打好了，後面接什麼新協定都能快速判斷它的取捨。如果你的團隊正在做企業級 agent 架構設計、需要評估通訊層怎麼選，可以參考恆遠的 AI 顧問服務，我們有幫過數家客戶從零設計 multi-agent backbone 的經驗。

FIPA 標準化簡史：從 1996 日內瓦到 2005 IEEE

FIPA（Foundation for Intelligent Physical Agents）1996 年在瑞士日內瓦以非營利組織形式成立，創立宗旨是替「智慧型實體 agent」訂一套通用標準，讓不同廠商寫出來的 agent 能直接互通。創始會員包括 IBM、NTT、Telecom Italia、British Telecom 等通訊與計算大廠，Wikipedia 的歷史條目 記錄了完整的成員名單與里程碑。

FIPA 的標準文件用 FIPA0000X 編號分系列發佈，主要分幾個層次：

• Agent Management（FIPA00023）：規範平台架構，包含 AMS（Agent Management System）、DF（Directory Facilitator）、MTS（Message Transport Service）三大組件
• Agent Communication（FIPA00061）：訊息結構與編碼
• Communicative Act Library（FIPA00037）：22 個 performatives 的精確語意
• Content Languages（FIPA00008 SL、FIPA00009 CCL、FIPA00010 KIF）：訊息內容的表達語言
• Interaction Protocols（FIPA00026 到 FIPA00036 等）：標準化的對話流程

關鍵轉折發生在 2005 年。3 月，FIPA 會員一致投票同意加入 IEEE Computer Society；6 月 8 日，IEEE FIPA Standards Committee 正式成立。 這個併入動作意義很大——FIPA 從一個產業聯盟升格為國際標準組織背書的標準，後續多代理人技術在電力系統、智慧建築、製造業等領域的應用，多半都引用這套規範。IEEE PES（Power & Energy Society）甚至成立了 Multi-Agent Systems Working Group 專門處理電網場景的 FIPA 標準延伸。

ACL 訊息結構解剖：一個訊息裡的 12 個 slot

一則 FIPA ACL 訊息長什麼樣？官方規範定義了 12 個欄位（slot），每個欄位都有明確語意。先看一個 inform 訊息的完整範例：

(inform
  :sender         (agent-identifier :name alice@platform1)
  :receiver       (set (agent-identifier :name bob@platform2))
  :content        "((price item-42 1500))"
  :language       fipa-sl
  :ontology       e-commerce-2026
  :protocol       fipa-request
  :conversation-id conv-9817
  :reply-with     msg-001
  :in-reply-to    msg-000
  :reply-by       2026-05-12T14:00:00Z
  :encoding       UTF-8)

乍看像 LISP 的 S-expression，實際上它就是 LISP-style 語法。12 個 slot 分成五群：

:performative 是整個訊息的「動詞」，決定了接收方該怎麼解讀內容。同樣一句「明天會下雨」，包在 inform 裡是告知氣象、包在 request 裡是要求對方讓明天下雨——荒謬，但形式上完全合法，這就是為什麼語意必須形式化定義。

:ontology 是常被低估的設計點。沒有共享 ontology，兩個 agent 即使語法都對，講的也是兩件事。FIPA 沒有規定 ontology 內容必須長什麼樣，但要求兩個對話的 agent 必須事先協議或在訊息中明確標註——這個約束直接影響到後來語意網（Semantic Web）與 OWL 的設計方向。

22 個 Performatives：speech act 怎麼變成可執行協議

FIPA Communicative Act Library（FIPA00037）定義了 22 個標準 performatives。每個都有對應的 feasibility precondition（FP，發出此訊息前必須成立的條件）與 rational effect（RE，發出者希望達到的效果）。完整列表見 FIPA 官方規範頁面，但實務上工程師最該熟悉的是按「言語行為類型」分組：

Assertive（陳述類）：傳遞資訊

• inform — 告知一個命題（最常用）
• confirm — 確認某命題為真
• disconfirm — 確認某命題為偽
• inform-if — 詢問某命題真假（這算 directive 也合理，FIPA 歸在資訊互換群）
• inform-ref — 詢問某表達式的指涉值

Directive（指令類）：請求行動

• request — 要求對方執行某動作
• request-when — 當某條件成立時才執行
• request-whenever — 每當條件為真就執行（持續性）
• query-if — 詢問接收者是否相信某命題
• query-ref — 詢問某表達式的值
• cancel — 取消先前的請求
• subscribe — 訂閱某個 reference 的變更通知（持續性）

Commissive（承諾類）：承諾未來行為

• agree — 同意執行對方請求的動作
• refuse — 拒絕執行（並說明原因）
• accept-proposal — 接受先前的提案
• reject-proposal — 拒絕先前的提案
• propose — 提出一個提案（含執行條件）

Notification（通知類）：行為結果回報

• failure — 通知先前的動作執行失敗
• not-understood — 表示沒看懂前一則訊息（最後一道防線）

Meta（後設類）：訊息流控制

• cfp（call for proposals）— 召集提案，啟動招標流程
• propagate — 請接收者把訊息轉發給其他 agent
• proxy — 請接收者把附帶訊息送給指定的 agent

把 22 個 performatives 跟 speech act theory 對齊看，源頭是英國哲學家 J. L. Austin 在《How to Do Things with Words》（1962）提出的觀念：講話本身就是一種行為（performative utterance），後來 John Searle 在 1969 年的《Speech Acts》把這些行為分成五類：assertive、directive、commissive、expressive、declarative。FIPA 把 Searle 的五類精簡為四類（拿掉 expressive 與 declarative，加上 meta），並針對軟體 agent 的需求做了形式化。

形式語意：mental attitudes、Feasibility Precondition 與 Rational Effect

這是 FIPA ACL 最硬的一段，也是最值得花時間搞懂的一段。如果只把 performative 當 enum 用，那 FIPA 就只是個花俏的 RPC。它真正特別的地方在於用 modal logic 形式化定義每個 performative 的「意義」，這套語意又稱 mentalist 或 psychological semantics。

四個 mental attitude operator

FIPA SL 定義了四個基本算子，用來描述 agent 的「心智狀態」：

這四個 operator 加上一階邏輯，就構成 FIPA SL（FIPA00008 SL Content Language Specification）的核心。Intention 被定義為「持續性的 goal」——意思是 agent 不只是「想要」p，還會持續規劃行動直到 p 達成或變得不可能。這個區分對應行為架構（BDI 模型）裡 desire 跟 intention 的差異。

Feasibility Precondition 與 Rational Effect

每個 performative 用兩個東西定義：

• Feasibility Precondition（FP）：發出這則訊息前，發送者的心智狀態必須滿足什麼條件
• Rational Effect（RE）：發送者希望這則訊息在接收者心智裡產生什麼效果

拿最常用的 inform 為例。完整定義是這樣：

<i, inform(j, φ)>
  FP:  B_i φ  ∧  ¬B_i (B_j φ  ∨  U_j φ  ∨  ¬B_j φ)
  RE:  B_j φ

白話翻譯——agent i 要對 agent j 發出 inform(φ) 的條件是：(1) i 自己相信 φ；(2) i 不認為 j 已經對 φ 有確定意見（沒理由再講一次）。發出 inform 的「合理效果」是讓 j 相信 φ。

再看 request：

<i, request(j, α)>
  FP:  B_i (Agent(j))  ∧  ¬I_i Done(α)  ∧  C_i Done(α)
  RE:  Done(α)

意思是：i 相信 j 是個 agent、i 自己沒打算去做 α、i 希望 α 完成。RE 就是希望 α 完成這件事被達成。注意 FP 不要求 i 相信 j 真的「能做」α——這是 FIPA 設計上的取捨：通訊行為的語意不該耦合到對方能力的判斷，能力判斷留給更上層的 reasoning 層處理。

這套語意也有著名的爭議。2006 年 Gaudou 等人在 ECAI 發表的論文（A New Semantics for the FIPA ACL based on Social Attitudes）指出，mentalist semantics 假設我們能驗證另一個 agent 的「真正心智狀態」，這在 black-box 環境裡實際上是做不到的。他們提出改用 social commitment 為基礎的語意——這條學術路線後來深刻影響到 ANP（Agent Network Protocol）跟 ACP 的設計，講的也是「在無法驗證心智狀態時，要怎麼用可觀察的承諾行為當基礎」。

SL 內容語言與標準 Interaction Protocols

performative 決定訊息「是哪種行為」，content 帶的才是「具體在講什麼」。FIPA 規範裡 content 的格式不寫死，由 :language 欄位指定。最常用的是 FIPA SL（FIPA00008），另外還有 KIF（Knowledge Interchange Format，FIPA00010）跟 RDF（FIPA00011）。

SL 又分三個層次（SL0、SL1、SL2），表達能力遞增：

實務上多數實作只支援到 SL0 或 SL1——SL2 的完整 modal logic 解析在工程上代價非常高，而大多數應用場景並不需要 agent 反過來推理另一個 agent 的 belief about belief about ...

Interaction Protocols：對話的劇本

單則訊息只是孤立的對話行為。FIPA 把常見的對話模式抽出來，制定成標準 interaction protocol，每個都用 AUML（Agent UML）sequence diagram 規範訊息流。最重要的幾個：

• FIPA-Request（FIPA00026）：最基本的請求-回應流程
• FIPA-Query（FIPA00027）：詢問資訊
• FIPA-Contract-Net（FIPA00029）：招標式協商
• FIPA-Iterated-Contract-Net（FIPA00030）：多輪招標
• FIPA-Subscribe（FIPA00035）：訂閱-通知模式
• FIPA-Propose（FIPA00036）：單純提案
• FIPA-Brokering / Recruiting（FIPA00033、FIPA00034）：透過中介媒合

以 FIPA-Request 為例，正常流程是：

注意每個分支對應的 performative 都不一樣。如果你想自己設計類似 protocol，這張圖就是 reference design——任何「同步請求-回應」流程其實都長這樣，只是大多數人不會精準區分 refuse 跟 failure 跟 not-understood 的差異。

Contract Net Protocol：分散式招標

FIPA-Contract-Net 是最值得單獨講的 protocol，因為它把「分散式任務分配」變成可重複套用的設計模式。出自 Reid Smith 在 1980 年的論文，FIPA 把它規範化成 FIPA00029。完整流程：

Contract Net 在 2020 年代的 microservice orchestration、Kubernetes scheduler 設計、甚至 LLM agent 的 task delegation 中都看得到變形版本。Google A2A protocol 的 Task lifecycle、AutoGen 的 GroupChat 路由邏輯，骨架都是 Contract Net 的延伸，只是換了傳輸層跟序列化格式。

JADE：把 FIPA 規範變成可執行的 Java 程式碼

FIPA 規範是文件，JADE（Java Agent DEvelopment Framework） 是把規範變成程式碼的事實標準。JADE 由義大利 Telecom Italia 的 TILab 開發、用 LGPL v2 授權釋出，從 2000 年代初就是學界與業界做 FIPA 合規 multi-agent 系統的首選平台。它實作了完整的 ACL、interaction protocols、AMS、DF、MTS，並提供 message queue、behavior scheduler、container 機制。

先看一個最小的 JADE agent — 發送一則 inform 訊息：

import jade.core.Agent;
import jade.core.AID;
import jade.lang.acl.ACLMessage;
import jade.core.behaviours.OneShotBehaviour;

public class AliceAgent extends Agent {
    @Override
    protected void setup() {
        addBehaviour(new OneShotBehaviour() {
            @Override
            public void action() {
                ACLMessage msg = new ACLMessage(ACLMessage.INFORM);
                msg.addReceiver(new AID("bob", AID.ISLOCALNAME));
                msg.setLanguage("fipa-sl");
                msg.setOntology("e-commerce-2026");
                msg.setConversationId("conv-9817");
                msg.setContent("((price item-42 1500))");
                send(msg);
                System.out.println("Alice sent inform to bob");
            }
        });
    }
}

接收方 Bob agent 用 CyclicBehaviour 監聽訊息：

import jade.core.Agent;
import jade.lang.acl.ACLMessage;
import jade.lang.acl.MessageTemplate;
import jade.core.behaviours.CyclicBehaviour;

public class BobAgent extends Agent {
    @Override
    protected void setup() {
        addBehaviour(new CyclicBehaviour(this) {
            @Override
            public void action() {
                MessageTemplate mt = MessageTemplate.MatchPerformative(
                    ACLMessage.INFORM);
                ACLMessage msg = receive(mt);
                if (msg != null) {
                    System.out.println(
                        "Bob got inform from " + msg.getSender().getName()
                        + " content: " + msg.getContent());
                } else {
                    block();
                }
            }
        });
    }
}

幾個值得抓住的設計重點：

• Agent 是繼承 jade.core.Agent 的類別，生命週期由 JADE container 管理
• Behaviour 是 agent 的「行為單位」，OneShotBehaviour 跑一次、CyclicBehaviour 跑無限多次
• ACLMessage 直接對應 FIPA ACL 訊息結構，全部 12 個 slot 都有 setter
• MessageTemplate 用模式比對挑選 inbox 裡的訊息——可以按 performative、conversation-id、ontology 等任意條件組合過濾
• block() 不是 thread block，是把 behaviour 從 scheduler 拿掉等訊息來，比 polling 省資源

用 JADE 跑 Contract Net

JADE 提供 ContractNetInitiator 與 ContractNetResponder 兩個 ready-made behaviour，把整個 cfp → propose → accept-proposal → inform 流程封裝起來。簡化版的 Initiator：

import jade.proto.ContractNetInitiator;
import jade.lang.acl.ACLMessage;
import java.util.Vector;

ACLMessage cfp = new ACLMessage(ACLMessage.CFP);
cfp.addReceiver(new AID("provider1", AID.ISLOCALNAME));
cfp.addReceiver(new AID("provider2", AID.ISLOCALNAME));
cfp.setContent("deliver-package P-001");
cfp.setReplyByDate(new Date(System.currentTimeMillis() + 10000));

addBehaviour(new ContractNetInitiator(this, cfp) {
    @Override
    protected void handleAllResponses(Vector responses, Vector acceptances) {
        // 評估所有 propose，挑最便宜的接受、其餘拒絕
        // 結果寫進 acceptances Vector
    }
    @Override
    protected void handleInform(ACLMessage inform) {
        System.out.println("task done: " + inform.getContent());
    }
});

這段程式碼是 1996 年 FIPA 設計的協議到 2020 年代的工程實踐之間的橋。如果你正在做 LLM agent orchestration 系統，把 LLM 包成一個 JADE agent 完全可行——message queue、scheduling、protocol state machine 這些 plumbing 全部不用自己寫一次。可以參考恆遠的 客製化系統開發 案例，我們處理過數個把舊有 multi-agent 架構接到新 LLM 工作流的整合案。

FIPA ACL vs KQML：兩個 mentalist 學派的取捨

FIPA ACL 不是憑空出現的。它的直接前輩是 KQML（Knowledge Query and Manipulation Language），1990 年由 DARPA 的 Knowledge Sharing Effort 提出，是第一個被廣泛使用的 agent communication language。語法上兩者極像，都是 LISP-style；但設計理念有幾個關鍵分歧。

最大的設計差異是：KQML 允許 agent 透過 insert 把資訊「植入」對方的 virtual knowledge base，這在 90 年代分散式資料庫思維下合理，但在開放系統時代很危險——任何 agent 都可以強迫修改對方狀態，沒有 negotiation。FIPA ACL 把這條路堵死，所有狀態變更必須透過協商（cfp、propose、agree）達成。這個取捨也是後來 ACP、ANP 等新協定一致採用的設計原則。

從學術上看，兩者都屬於 mentalist semantics 學派——把溝通的意義建在「對方心智狀態」上。批評者認為這假設了我們可以驗證 black-box agent 的真實心智狀態，實務上做不到。這個批評催生了 social commitment-based 學派（M. Singh 等人），主張用「可觀察的公開承諾」當基礎。今天 A2A 跟 ANP 在 task lifecycle 設計上，本質就是 commitment-based 路線——你看不到 agent 在想什麼，但你看得到它對哪個 task 做了哪些公開的 state transition。

FIPA 的 2026：MCP、A2A、ANP 怎麼站在它的肩膀上

回到開頭那個問題——LLM agent 時代為什麼要懂 FIPA？2025 年 5 月發表的 arXiv 綜述論文（A Survey of Agent Interoperability Protocols: MCP, ACP, A2A, ANP）直接把四個新協定排在 FIPA 之後的演進譜系上，明白標註「formal semantic foundation 源自 KQML 與 FIPA ACL」。

把四個新協定跟 FIPA 對照比較：

從這張表能看出一個趨勢：新協定都在 FIPA 的某個層次上做「現代化重寫」，但沒有任何一個試圖重做整套 22 個 performatives 加完整 modal logic 語意。 因為 LLM 本身的對話能力已經模糊掉了 performative 邊界——一個 LLM 可以輕鬆從 inform 切到 request 切到 propose，不需要顯式標註。但這也代表新協定在「可驗證、可審計」這件事上比 FIPA 弱很多。當你做的是金融、醫療、電網這類需要強合規的 agent 系統，FIPA 的形式化反而是不能省的。

如果你對「multi-agent 系統怎麼讓多個 LLM 互相辯論逼出更好答案」這個方向有興趣，可以接著看恆遠之前寫過的 多 Agent 辯論架構設計與實作指南——那篇講的是 LLM 時代的應用層架構，跟本篇講的通訊標準底層剛好構成一組完整視角。對 MCP 工具生態好奇的話，Claude MCP Server 完整推薦 從工程實作角度切入。

工程實踐：什麼專案該認真看 FIPA

講了這麼多理論，落地建議三條：

該套 FIPA 規範的場景

• 電力系統 / 電網調度：IEEE PES MAS Working Group 直接把 FIPA 當預設
• 智慧建築 / IoT 多 agent 控制：需要跨廠商互通、合規可追溯
• 供應鏈協商系統：Contract Net 直接套用，多賣家招標流程
• 需要形式驗證的關鍵任務系統（醫療、航空、軍事）：FP/RE 可被 model checker 驗證

該借用 FIPA 思想、但用新協定實作的場景

• LLM agent workflow：MCP 處理工具、A2A 處理協作，但 conversation-id、ontology、protocol 這些概念要自己補
• 企業內部 agent platform：學 FIPA 的 AMS / DF / MTS 三層架構，用現代基礎設施重寫
• 跨組織 AI 系統整合：學 FIPA 的 ontology 強約束，避免雞同鴨講

不要強行套用 FIPA 的場景

• 單一 LLM 加一堆工具的 single-agent 系統：用 function calling 或 MCP 就好
• 純資料管線：用標準 API 或 message queue 即可，不需要 performative
• 原型驗證階段：FIPA 規格學習曲線高，POC 階段先用輕量框架

觀察一個簡單訊號：如果你的系統「agent 之間需要協商、需要互相理解對方意圖、需要審計通訊歷史」——FIPA 的設計值得認真讀；如果不是，知道它存在、看得懂相關 paper 就夠了。

常見問題

不只是讀規範——把 multi-agent 架構做對需要實戰經驗

FIPA ACL 講了三十年，本質上要解決的是「多個自主程式怎麼好好對話」這件事。LLM agent 沒有讓問題消失——它讓問題變得更現實、更普遍、也更難。 任何一個正在規劃企業級 agent 平台的團隊，遲早會撞到 ontology 不一致、conversation state 漏掉、跨組織訊息語意飄移這類老問題。先把 FIPA 看懂，再選擇要不要從 scratch 實作或用 MCP/A2A 起步，會比一開始就盲跳新協定踏實得多。

恆遠數位行銷的技術團隊持續在做企業級客製化 AI 系統開發，從通訊架構設計、LLM agent 整合、到內部知識庫接 MCP server 都有完整經驗。如果你在規劃 multi-agent 系統、需要技術顧問評估架構選型，歡迎透過 AI 顧問服務 或 聯絡頁面 與我們聊聊。我們的立場很直接：站在 AI 巨人肩膀上替你解問題，不堆疊不需要的技術棧。