在 Elasticsearch 中使用 A2A 協議和 MCP 創建一個 LLM agent 新聞室

作者：來自ElasticJustin Castilla

Agent Builder 現已作為技術預覽版提供。開始使用 Elastic Cloud 試用版，並在此處查看 Agent Builder 的文檔。

簡介

當前基於 LLM 的系統正在迅速發展，超越單一模型應用，形成複雜網絡，其中專業 agent 協作完成現代計算以前無法想象的任務。隨着這些系統複雜性的增加，使 agent 通信和工具訪問成為開發的主要關注點。為滿足這些需求，出現了兩種互補的方法：用於多 agent 協作的 Agent2Agent（ A2A ）協議，以及用於標準化工具和資源訪問的 Model Context Protocol（ MCP ）。

理解在何時如何協調使用或不使用這兩者，會顯著影響應用的可擴展性、可維護性和有效性。本文探討了 A2A 的概念及其在數字新聞室的實際示例中的實現，其中專業 LLM agent 協作進行新聞文章的研究、撰寫、編輯和發佈。

相關代碼倉庫可在此找到，本文在第 5 節接近結尾處會展示 A2A 的實際應用示例。

前提條件

該倉庫包含基於 Python 的 A2A agent 實現。提供了一個基於 Flask 的 API 服務器，以及一個名為 Event Hub 的自定義 Python 消息服務，用於路由消息以進行日誌記錄和 UI 更新。最後，提供了一個 React UI，用於獨立使用新聞室功能。所有內容都包含在 Docker 鏡像中，以便更容易實現。如果你希望在本機直接運行服務，需要確保安裝以下技術：

語言和運行時

Python 13.12 - 核心後端語言
Node.js 18+ - 可選 React UI

核心框架和 SDK

A2A SDK 0.3.8 - agent 協作和通信
Anthropic SDK - Claude 集成，用於 AI 生成
Uvicorn - 運行 agent 的 ASGI 服務器
FastMCP 2.12.5+ - MCP 服務器實現
React 18.2 - 前端 UI 框架

數據與搜索

Elasticsearch 9.1.1+ - 文章索引和搜索

Docker 部署（可選，但推薦）

Docker 28.5.1+

第 1 節：什麼是 Agent2Agent（A2A）？

定義和核心概念

Agent2Agent（ A2A ）是獨立 LLM agent 之間交互的標準化協議。A2A 不依賴單一整體系統處理所有任務，而是讓多個專業 agent 能夠溝通、協調和協作，以完成複雜工作流，這些工作流對於單個 agent 來説可能難以、高耗時或根本無法高效完成。

官方規範：https://a2a-protocol.org/latest/specification/

起源與發展

Agent2Agent 通信或多 agent 系統的概念源自分佈式系統、微服務以及多 agent 研究，可追溯數十年。早期分佈式人工智能工作為能夠協商、協調和協作的 agent 奠定了基礎。這些早期系統主要用於大規模社會模擬、學術研究和電網管理。

隨着 LLM 可用性提升和運行成本降低，多 agent 系統進入了 “生產者消費者” 市場，並得到 Google 及更廣泛 AI 研究社區的支持。如今被稱為 Agent2Agent 系統，A2A 協議的加入已發展為現代標準，專為多 LLM 協作完成任務而設計。

A2A 協議通過在 LLM 連接和通信的交互點應用一致標準和原則，確保 agent 之間的無縫通信和協調。這種標準化使來自不同開發者、使用不同底層模型的 agent 能夠有效協作。

通信協議並非新事物，它們在幾乎所有互聯網數字交易中都有廣泛應用。如果你在瀏覽器中輸入https://www.elastic.co/search-labs來訪問本文，很可能 TCP/IP、HTTP 傳輸和 DNS 查詢協議都已執行，確保我們有一致的瀏覽體驗。

關鍵特徵

A2A 系統基於幾個基本原則構建，以確保順暢通信。基於這些原則，不同的 agent（基於不同 LLM、框架和編程語言）都能無縫互動。

四個主要原則如下：

消息傳遞：agent 通過具有明確定義屬性和格式的結構化消息進行通信
協調：agent 通過相互分配任務並管理依賴關係來組織複雜工作流，同時不阻塞其他 agent
專業化：每個 agent 專注於特定領域或能力，成為該領域專家，並基於技能完成任務
分佈式狀態：狀態和知識分佈在各 agent 之間，而非集中管理，agent 能夠通過任務狀態和部分結果（artifact）相互更新進度

新聞室示例

想象一個由 AI agent 驅動的數字新聞室，每個 agent 專注於新聞學的不同方面：

新聞主管（協調者/客户端）：分配新聞並監督工作流
記者 agent：根據研究和採訪撰寫文章
研究員 agent：收集事實、統計數據和背景信息
檔案 agent：使用 Elasticsearch 搜索歷史文章並識別趨勢
編輯 agent：審查文章質量、風格和 SEO 優化
發佈 agent：通過 CI/CD 將審核通過的文章發佈到博客平台

這些 agent 並非獨立工作；當新聞主管分配一篇關於可再生能源採用的報道時，記者需要研究員收集統計數據，編輯審查草稿，發佈 agent 發佈最終文章。這種協調通過 A2A 協議實現。

第 2 節：理解 A2A 架構

客户端 agent 與遠程 agent 角色

在 A2A 架構中，agent 承擔兩種主要角色。客户端 agent 負責制定任務並與系統中的其他 agent 進行通信。它識別遠程 agent 及其能力，並利用這些信息對任務分配做出明智決策。客户端 agent 協調整體工作流，確保任務得到適當分配，系統向目標推進。

相比之下，遠程 agent 執行客户端委派的任務。它根據請求提供信息或採取特定行動，但不會獨立發起操作。遠程 agent 還可以根據需要與其他遠程 agent 通信，以完成分配的職責，從而形成一個具有專業能力的協作網絡。

在我們的新聞室示例中，新聞主管充當客户端 agent，而記者、研究員、編輯和發佈者則是響應請求並相互協調的遠程 agent。

核心 A2A 能力

A2A 協議定義了若干能力，使多 agent 協作成為可能：

1）發現

A2A 服務器必須公佈其能力，以便客户端知道何時以及如何將其用於特定任務。這通過 Agent Card 實現 —— JSON 文檔描述了 agent 的能力、輸入和輸出。Agent Card 可在一致的、已知的端點提供（例如推薦的 /.well-known/agent-card.json 端點），允許客户端在開始協作前發現並查詢 agent 的能力。

下面是 Elastic 自定義檔案 agent “Archie Archivist”的示例 Agent Card。請注意，像 Elastic 這樣的軟件提供商託管其 A2A agent，並提供訪問的 URL：

{
  "name": "Archie Archivist",
  "description": "Helps find historical news documents in the Elasticsearch Index of archived news articles and content.",
  "url": "https://xxxxxxxxxxxxx-abc123.kb.us-central1.gcp.elastic.cloud/api/agent_builder/a2a/archive-agent",
  "provider": {
    "organization": "Elastic",
    "url": "https://elastic.co"
  },
  "version": "0.1.0",
  "protocolVersion": "0.3.0",
  "preferred_transport": "JSONRPC",
  "documentationURL": "https://www.elastic.co/docs/solutions/search/agent-builder/a2a-server"
  "capabilities": {
    "streaming": false,
    "pushNotifications": false,
    "stateTransitionHistory": false
  },
  "skills": [
    {
      "id": "platform.core.search",
      "name": "platform.core.search",
      "description": "A powerful tool for searching and analyzing data within your Elasticsearch cluster.",
      "inputModes": ["text/plain", "application/json"],
      "outputModes": ["text/plain", "application/json"]
    },
    {
      "id": "platform.core.index_explorer",
      "name": "platform.core.index_explorer",
      "description": "List relevant indices, aliases and datastreams based on a natural language query.",
      "inputModes": ["text/plain", "application/json"],
      "outputModes": ["text/plain", "application/json"]
    }
  ],
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain"]
}

該 Agent Card 揭示了 Elastic 檔案 agent 的幾個重要方面。該 agent 自我標識為 “Archie Archivist”，並清楚説明其用途：幫助在 Elasticsearch 索引中查找歷史新聞文檔。Card 指定了提供商（Elastic）和協議版本（0.3.0），確保與其他符合 A2A 標準的 agent 兼容。最重要的是，skills 數組列出了該 agent 提供的具體能力，包括強大的搜索功能和智能索引探索。每項技能定義了其支持的輸入和輸出模式，使客户端能夠準確瞭解如何與該 agent 通信。此 agent 來源於 Elastic 的 Agent Builder 服務，該服務提供一套原生 LLM 支持的工具和 API 端點，使你能夠與數據存儲進行對話，而不僅僅是檢索數據。Elasticsearch 中 A2A agent 的訪問可在此找到。

2）協商

客户端和 agent 需要就通信方式達成一致 —— 無論是通過文本、表單、 iframes，甚至音頻/視頻 —— 以確保正確的用户交互和數據交換。這種協商發生在 agent 協作開始時，並建立整個工作流中管理交互的協議。例如，基於語音的客服 agent 可能協商通過音頻流通信，而數據分析 agent 可能更喜歡結構化 JSON。協商過程確保雙方能夠以適合其能力和任務要求的格式有效交換信息。

上面 JSON 片段中列出的能力都具有輸入和輸出模式；這些模式設定了其他 agent 如何與該 agent 交互的預期。

3）任務與狀態管理

客户端和 agent 需要機制在任務執行過程中傳遞任務狀態、變化和依賴關係。這包括管理任務從創建、分配到進度更新和狀態變化的整個生命週期。典型狀態包括待處理、進行中、已完成或失敗。系統還必須跟蹤任務間的依賴關係，以確保先決工作完成後再開始依賴任務。錯誤處理和重試邏輯也是關鍵組成部分，使系統能夠在失敗後優雅恢復，並繼續向主要目標推進。

任務消息示例：

{
  "message_id": "msg_789xyz",
  "message_type": "task_request",
  "sender": "news_chief",
  "receiver": "researcher_agent",
  "timestamp": "2025-09-30T10:15:00Z",
  "payload": {
    "task_id": "task_456abc",
    "capability": "fact_gathering",
    "parameters": {
      "query": "renewable energy adoption rates in Europe 2024",
      "sources": ["eurostat", "iea", "ember"],
      "depth": "comprehensive"
    },
    "context": {
      "story_id": "story_123",
      "deadline": "2025-09-30T18:00:00Z",
      "priority": "high"
    }
  }
}

該任務消息示例展示了 A2A 通信的幾個關鍵方面。

消息結構包括元數據，例如唯一消息標識符、發送的消息類型、發送方和接收方標識，以及用於跟蹤和調試的時間戳。
有效負載包含實際的任務信息，指定在遠程 agent 上調用的能力，並提供執行該能力所需的參數。
上下文部分提供額外信息，幫助接收 agent 理解更廣泛的工作流，包括截止日期和優先級，這些信息指導 agent 如何分配資源和安排工作。

4）協作

客户端和 agent 必須支持動態且結構化的交互，使 agent 能夠向客户端、其他 agent 或用户請求澄清、信息或子操作。這創造了一個協作環境，使 agent 在初始指令模糊時可以提出後續問題，請求額外上下文以做出更好決策，將子任務委派給具有更合適專業知識的其他 agent，並在執行完整任務前提供中間結果以供反饋。這種多向通信確保 agent 不孤立工作，而是參與持續對話，從而產生更好的結果。

分佈式點對點通信

A2A 支持分佈式通信，agent 可能由不同組織託管，其中一些 agent 在內部維護，而其他 agent 由第三方服務提供。這些 agent 可以運行在不同基礎設施上 —— 可能跨多個雲提供商或本地數據中心。它們可能使用不同的底層 LLM，有的 agent 由 GPT 模型提供支持，有的由 Claude 提供，還有的由開源替代方案提供支持。agent 甚至可能跨不同地理區域運行，以滿足數據主權要求或降低延遲。儘管存在這種多樣性，所有 agent 都遵循共同的通信協議交換信息，確保無論實現細節如何都能互操作。這種分佈式架構為系統的構建和部署提供了靈活性，使組織能夠根據自身需求組合最優的 agent 和基礎設施。

這是新聞室應用的最終架構：

第 3 節：Model Context Protocol（MCP）

定義與目的

Model Context Protocol（MCP）是由 Anthropic 開發的標準化協議，用於增強和賦能單個 LLM，使其能夠使用用户定義的工具、資源和 prompts，以及其他補充代碼庫內容。MCP 為語言模型與完成任務所需的外部資源之間提供了通用接口。本文概述了 MCP 的現狀，包括使用案例示例、新興趨勢以及 Elastic 的實現方式。

核心 MCP 概念

MCP 基於客户端-服務器架構，包含三個主要組件：

客户端（Clients）：連接到 MCP 服務器以訪問其能力的應用程序（如 Claude Desktop 或自定義 AI 應用）
服務器（Servers）：向語言模型提供資源、工具和 prompts 的應用程序。每個服務器專注於提供對特定能力或數據源的訪問
- 工具（Tools）：用户定義的函數，模型可以調用以執行操作，例如搜索數據庫、調用外部 API 或對數據執行轉換
- 資源（Resources）：模型可以讀取的數據源，提供動態或靜態數據，通過 URI 模式訪問（類似 REST 路由）
- Prompts：帶變量的可複用 prompt 模板，引導模型完成特定任務

請求-響應模式

MCP 遵循類似 REST API 的請求-響應交互模式。客户端（LLM）請求資源或調用工具，然後 MCP 服務器處理請求並返回結果，LLM 利用該結果繼續任務。與點對點 agent 通信相比，這種以中心化模型與外圍服務器的方式提供了更簡單的集成模式。

新聞室中的 MCP

在我們的新聞室示例中，各個 agent 使用 MCP 服務器訪問所需的工具和數據：

研究員 agent 使用：
- News API MCP 服務器（訪問新聞數據庫）
- Fact-Checking MCP 服務器（根據可信來源驗證信息）
- Academic Database MCP 服務器（學術文章和研究資料）
記者 agent使用：
- Style Guide MCP 服務器（新聞室寫作標準）
- Template MCP 服務器（文章模板和格式）
- Image Library MCP 服務器（庫存圖片和圖形）
編輯 agent使用：
- Grammar Checker MCP 服務器（語言質量工具）
- Plagiarism Detection MCP 服務器（原創性驗證）
- SEO Analysis MCP 服務器（標題和關鍵詞優化）
發佈 agent 使用：
- CMS MCP 服務器（內容管理系統 API）
- CI/CD MCP 服務器（部署管道）
- Analytics MCP 服務器（跟蹤與監控）

第 4 節：架構比較

何時使用 A2A

A2A 架構在需要真正多 agent 協作的場景中表現出色。多步驟工作流需要協調時，A2A 特別有利，尤其是任務涉及多個順序或並行步驟、需要迭代和優化的工作流，以及包含檢查點和驗證需求的流程。在我們的新聞室示例中，新聞工作流要求記者撰寫文章，但如果某些事實的可靠性不足，可能需要返回給研究員進行核實，然後繼續交給編輯，最終由發佈者發佈。

跨多個領域的專業化也是 A2A 的強力用例。當完成更大任務需要多個領域的專家，每個 agent 提供深厚的領域知識和針對不同方面的專業推理能力時，A2A 提供了實現這些連接所需的協調框架。新聞室示例完美説明了這一點：研究員專注於信息收集，記者專注於寫作，編輯專注於質量控制 —— 每個角色都有獨特的專業能力。

自主 agent 行為的需求使 A2A 尤為有價值。能夠獨立決策、根據變化條件主動行動並動態適應工作流需求的 agent 在 A2A 架構中表現出色。專業功能的水平擴展也是一個關鍵優勢 —— 與其依賴單個全能 agent，不如讓多個專業 agent 協作，同一 agent 的多個實例可以異步處理子任務。例如，在新聞突發事件中，多名記者 agent 可能同時處理同一故事的不同角度。

最後，需要真正多 agent 協作的任務非常適合 A2A，包括LLM 作為陪審機制、共識構建和投票系統，以及需要多方視角來達成最佳結果的協作問題解決。

何時使用 MCP

Model Context Protocol 適合擴展單個 AI 模型的能力。當單個 AI 模型需要訪問多個工具和數據源時，MCP 提供了完美解決方案，將集中推理與分佈式工具以及簡單的工具集成結合。在我們的新聞室示例中，研究員 agent（單個模型）需要訪問多個數據源，包括 News API、事實核查服務和學術數據庫 —— 這些都通過標準化 MCP 服務器訪問。

當工具集成的廣泛共享和可複用性很重要時，標準化工具集成變得優先。MCP 在這方面表現突出，其預構建 MCP 服務器生態系統顯著減少了常用集成的開發時間。在需要簡化和可維護性的情況下，MCP 的請求-響應模式對開發者熟悉，比分佈式系統更容易理解和調試，並且運營複雜性較低。

最後，MCP 通常由軟件提供商提供，以簡化與其系統的遠程通信。這些提供商的 MCP 服務器顯著減少了入門和開發時間，同時提供了標準化接口，使集成比自定義 API 開發更簡單。

何時同時使用（A2A ❤️ MCP）

許多複雜系統受益於 A2A 與 MCP 的結合，如 A2A 文檔中關於 MCP 集成所述。需要協調與標準化的系統是混合方法的理想候選。A2A 負責 agent 協調和工作流編排，而 MCP 為單個 agent 提供工具訪問。在我們的新聞室示例中，agent 通過 A2A 協調工作流，從記者到研究員，再到編輯和發佈者。然而，每個 agent 使用 MCP 服務器訪問其專業工具，實現了清晰的架構分離。

多個使用 MCP 訪問工具的專業 agent 是常見模式：agent 協調層由 A2A 管理，工具訪問層由 MCP 管理。這種明確的職責分離使系統更易理解和維護。

結合兩種方法的好處顯著。你可以獲得多 agent 系統的組織優勢，包括專業化、自主性和平行處理，同時享受 MCP 的標準化和生態系統優勢，如工具集成和資源訪問。agent 協調（A2A）與資源訪問（MCP）清晰分離，且對於僅需 API 訪問的小任務，不需要 A2A —— MCP 可高效處理，無需多 agent 編排的額外開銷。

常見問題：A2A 與 MCP 的使用場景

特徵	代理2代理（A2A）	模型上下文協議（MCP）	混合動力（A2A + MCP）
主要目標	多代理協調：使專業代理團隊能夠在複雜的多步驟工作流程中協同工作。	單代理增強功能：使用外部工具、資源和數據擴展單個 LLM/代理的功能。	綜合實力：A2A 處理團隊的工作流程，而 MCP 為每個團隊成員提供工具。
新聞編輯室團隊示例	工作流程鏈：新聞首席→記者→研究員→編輯→出版商。這是協調層。	單個代理的工具：訪問風格指南服務器和模板服務器（通過 MCP）的 Reporter 代理。這是工具訪問層。	完整系統：記者與編輯（A2A）協調，記者使用圖像庫 MCP 服務器查找故事的圖形。
何時使用哪個	當您需要真正的協作、迭代和改進，或需要多個代理分配專業知識時。	當一個代理需要訪問多個工具和數據源或需要與專有系統進行標準化集成時。	當您需要多代理系統的組織優勢以及 MCP 的標準化和生態系統優勢時。
核心優勢	自主性和擴展性：代理可以做出獨立決策，系統允許專業功能的水平擴展。	簡單性和標準化：由於中心化推理，更易於調試和維護，併為資源提供了通用接口。	關注點的明確分離：使系統更易於理解：A2A = 團隊合作，MCP = 工具訪問。

結論

這是兩部分內容中的第一部分，介紹了基於 A2A 的 agent 實現，並輔以 MCP 服務器以提供數據和工具的支持與外部訪問。下一部分將展示實際代碼，演示它們如何協作以模擬在線新聞室中的工作活動。雖然這兩個框架各自都非常強大且靈活，但你將看到它們在協同工作時是多麼互補。

原文：https://www.elastic.co/search-labs/blog/a2a-protocol-mcp-llm-agent-newsroom-elasticsearch

簡介

前提條件