多智能體架構(gòu)實(shí)戰(zhàn)：DeepAgents編排、MCP工具接入與A2A通信)
1. 從單體到集群為什么我們需要超級(jí)多智能體1.1 一個(gè)真實(shí)的需求場(chǎng)景去年下半年我接手了一個(gè)企業(yè)內(nèi)部知識(shí)助手的項(xiàng)目需求聽起來不復(fù)雜幫員工查制度文檔、走審批流程、生成周報(bào)。一開始我用的是單體 Agent 方案一個(gè)模型加一堆工具函數(shù)跑起來確實(shí)快。但上線兩周后問題就來了——查文檔的 Agent 經(jīng)常被審批流程的上下文污染生成周報(bào)時(shí)又因?yàn)橐{(diào)用太多工具導(dǎo)致響應(yīng)時(shí)間飆到十幾秒。最要命的是我想給文檔檢索單獨(dú)換一個(gè)更便宜的模型結(jié)果發(fā)現(xiàn)整個(gè)系統(tǒng)耦合在一起改一處動(dòng)全身。這個(gè)經(jīng)歷讓我徹底轉(zhuǎn)向了多智能體架構(gòu)。所謂超級(jí)多智能體不是簡(jiǎn)單地把幾個(gè) Agent 拼在一起而是要解決三個(gè)核心問題可編排誰(shuí)先誰(shuí)后、誰(shuí)調(diào)用誰(shuí)、可互通Agent 之間怎么傳消息、怎么共享狀態(tài)、可擴(kuò)展新增一個(gè) Agent 要不要改老代碼。這三個(gè)問題對(duì)應(yīng)到技術(shù)選型上就是 DeepAgents 負(fù)責(zé)編排、MCP 負(fù)責(zé)工具接入、A2A 負(fù)責(zé) Agent 間通信、Skills 負(fù)責(zé)能力封裝。如果你正在做 Agent 項(xiàng)目或者被單體 Agent 的耦合問題折磨過這套組合拳值得花時(shí)間研究。它不依賴某個(gè)特定廠商核心思路可以遷移到任何 Agent 框架上。1.2 四個(gè)關(guān)鍵詞到底在說什么先把概念理清楚不然后面容易繞暈。DeepAgents在這里指的是一種深度編排的 Agent 架構(gòu)模式核心思想是把復(fù)雜任務(wù)拆成有向圖每個(gè)節(jié)點(diǎn)是一個(gè) Agent 或一個(gè)工具調(diào)用邊代表數(shù)據(jù)流和控制流。它和簡(jiǎn)單的鏈?zhǔn)秸{(diào)用Chain最大的區(qū)別在于支持條件分支、循環(huán)、并行和人工介入節(jié)點(diǎn)。MCPModel Context Protocol是一個(gè)開放協(xié)議解決的是Agent 怎么標(biāo)準(zhǔn)化地調(diào)用外部工具和數(shù)據(jù)源的問題。你可以把它理解成 Agent 世界的 USB 接口——不管你是數(shù)據(jù)庫(kù)、文件系統(tǒng)還是第三方 API只要實(shí)現(xiàn) MCP 協(xié)議任何支持 MCP 的 Agent 都能直接接入。熱搜里有人問mcp 是軟件協(xié)議還是硬件協(xié)議答案是軟件協(xié)議它定義的是通信格式和調(diào)用規(guī)范跟硬件層面的協(xié)議比如 USB、I2C完全是兩回事。A2AAgent to Agent解決的是 Agent 之間的通信問題。MCP 管的是 Agent 調(diào)工具A2A 管的是 Agent 調(diào) Agent。它定義了 Agent 之間怎么發(fā)現(xiàn)對(duì)方、怎么發(fā)消息、怎么處理異步響應(yīng)。熱搜里出現(xiàn)的a2a spring說明已經(jīng)有人在 Spring 生態(tài)里做 A2A 的集成了。Skills是能力的封裝單元。一個(gè) Skill 可以是一個(gè)提示詞模板、一段代碼邏輯、一組工具調(diào)用的組合。它的價(jià)值在于復(fù)用——你寫好一個(gè)生成周報(bào)的 Skill可以在多個(gè) Agent 里直接引用不用重復(fù)實(shí)現(xiàn)。熱搜里claude agent skills: a first principles deep dive和codex skills都指向同一個(gè)趨勢(shì)Skills 正在成為 Agent 能力復(fù)用的標(biāo)準(zhǔn)方式。1.3 這套架構(gòu)適合誰(shuí)不是所有項(xiàng)目都需要上多智能體。如果你的需求是單輪問答、簡(jiǎn)單工具調(diào)用單體 Agent 完全夠用硬上多智能體只會(huì)增加復(fù)雜度。但如果你遇到以下情況這套架構(gòu)就值得考慮任務(wù)流程超過 5 個(gè)步驟且步驟之間有依賴關(guān)系需要多個(gè)專業(yè)領(lǐng)域的 Agent 協(xié)作比如一個(gè)查數(shù)據(jù)、一個(gè)做分析、一個(gè)寫報(bào)告工具數(shù)量超過 10 個(gè)單體 Agent 的提示詞已經(jīng)塞不下需要給不同 Agent 配不同模型來控制成本系統(tǒng)需要頻繁新增能力不想每次改核心代碼下面我會(huì)按照實(shí)際搭建的順序從架構(gòu)設(shè)計(jì)到落地實(shí)現(xiàn)把每個(gè)環(huán)節(jié)講透。2. 架構(gòu)設(shè)計(jì)編排層、通信層、能力層怎么分2.1 三層架構(gòu)的職責(zé)邊界我在實(shí)際項(xiàng)目中把系統(tǒng)分成三層每層職責(zé)清晰層與層之間通過標(biāo)準(zhǔn)協(xié)議通信。編排層DeepAgents負(fù)責(zé)決策任務(wù)怎么拆、下一步走哪個(gè)節(jié)點(diǎn)、什么時(shí)候結(jié)束。這一層不關(guān)心具體工具怎么調(diào)只關(guān)心流程控制。我通常用一個(gè)有向無環(huán)圖DAG來描述流程節(jié)點(diǎn)類型包括Agent 節(jié)點(diǎn)、工具節(jié)點(diǎn)、條件判斷節(jié)點(diǎn)、人工審核節(jié)點(diǎn)、并行分支節(jié)點(diǎn)。通信層A2A MCP負(fù)責(zé)傳輸Agent 之間怎么傳消息用 A2AAgent 調(diào)工具用 MCP。這一層的關(guān)鍵是協(xié)議標(biāo)準(zhǔn)化只要協(xié)議統(tǒng)一底層換實(shí)現(xiàn)不影響上層。能力層Skills負(fù)責(zé)執(zhí)行每個(gè) Skill 是一個(gè)獨(dú)立的能力單元包含提示詞、工具綁定、輸入輸出定義。Skill 可以注冊(cè)到多個(gè) Agent 上實(shí)現(xiàn)復(fù)用。這樣分層的最大好處是新增一個(gè) Agent 只需要在編排層加節(jié)點(diǎn)、在能力層加 Skill通信層完全不用動(dòng)。我試過在一個(gè)已有 8 個(gè) Agent 的系統(tǒng)里新增一個(gè)合同審查Agent從寫 Skill 到接入流程只花了半天。2.2 為什么選 DAG 而不是狀態(tài)機(jī)編排層可以用狀態(tài)機(jī)也可以用 DAG。我最終選 DAG 的原因是狀態(tài)機(jī)適合線性流程但多智能體場(chǎng)景下經(jīng)常需要并行和條件分支。比如同時(shí)查三個(gè)數(shù)據(jù)源然后匯總這種需求用狀態(tài)機(jī)寫起來很別扭DAG 天然支持并行節(jié)點(diǎn)。DAG 的另一個(gè)好處是可觀測(cè)。每個(gè)節(jié)點(diǎn)的輸入輸出都能記錄下來出問題時(shí)可以精確定位是哪個(gè)節(jié)點(diǎn)出了錯(cuò)。我在生產(chǎn)環(huán)境里給每個(gè)節(jié)點(diǎn)都加了日志埋點(diǎn)排查問題時(shí)直接看節(jié)點(diǎn)級(jí)別的 trace比看一整條鏈路的日志高效得多。2.3 通信協(xié)議選型MCP 和 A2A 的分工很多人搞不清 MCP 和 A2A 的區(qū)別我用一個(gè)類比說明MCP 像是人用工具A2A 像是人跟人說話。你用手電筒工具不需要跟手電筒商量直接按開關(guān)就行這是 MCP。但你要跟同事協(xié)作就得說話、等回復(fù)、確認(rèn)理解這是 A2A。具體到實(shí)現(xiàn)上MCP 的調(diào)用是同步或異步的請(qǐng)求-響應(yīng)模式Agent 發(fā)一個(gè)調(diào)用請(qǐng)求工具返回結(jié)果。A2A 則更復(fù)雜支持流式響應(yīng)、多輪對(duì)話、任務(wù)委派。我在項(xiàng)目里用 MCP 接入了文件系統(tǒng)、數(shù)據(jù)庫(kù)、搜索引擎三類工具用 A2A 實(shí)現(xiàn)了研究 Agent和寫作 Agent之間的協(xié)作。注意MCP 和 A2A 不是互斥的。一個(gè) Agent 可以同時(shí)是 MCP 的客戶端調(diào)工具和 A2A 的服務(wù)端被其他 Agent 調(diào)用。這種雙重身份在多智能體系統(tǒng)里很常見。2.4 Skills 的粒度怎么把握Skills 的粒度設(shè)計(jì)是個(gè)經(jīng)驗(yàn)活。太粗復(fù)用性差太細(xì)組合起來麻煩。我的原則是一個(gè) Skill 對(duì)應(yīng)一個(gè)完整的業(yè)務(wù)動(dòng)作。比如查詢員工考勤是一個(gè) Skill它內(nèi)部可能調(diào)了三個(gè) MCP 工具查數(shù)據(jù)庫(kù)、格式化數(shù)據(jù)、計(jì)算統(tǒng)計(jì)但對(duì)外只暴露一個(gè)接口。這樣其他 Agent 引用時(shí)不用關(guān)心內(nèi)部實(shí)現(xiàn)。反過來調(diào)用數(shù)據(jù)庫(kù)這種太底層的操作不適合做成 Skill它應(yīng)該是 MCP 工具。Skill 的抽象層級(jí)要高于工具低于完整的 Agent。3. 核心細(xì)節(jié)MCP 工具接入與 A2A 通信實(shí)現(xiàn)3.1 MCP 工具接入的完整流程MCP 的核心是標(biāo)準(zhǔn)化。不管你的工具是 Python 函數(shù)、HTTP API 還是數(shù)據(jù)庫(kù)查詢都要包裝成 MCP 協(xié)議規(guī)定的格式。我以接入一個(gè)文檔檢索工具為例走一遍完整流程。首先定義工具的元數(shù)據(jù)包括名稱、描述、輸入?yún)?shù) schema。這部分用 JSON Schema 描述目的是讓 Agent 知道這個(gè)工具能干什么、需要什么參數(shù)。{ name: search_documents, description: 根據(jù)關(guān)鍵詞檢索企業(yè)制度文檔, inputSchema: { type: object, properties: { query: {type: string, description: 檢索關(guān)鍵詞}, top_k: {type: integer, default: 5, description: 返回結(jié)果數(shù)量} }, required: [query] } }然后實(shí)現(xiàn)工具的執(zhí)行邏輯。這部分可以用任何語(yǔ)言寫只要最終暴露成 MCP 服務(wù)端即可。我用 Python 寫了一個(gè)簡(jiǎn)單的實(shí)現(xiàn)def search_documents(query: str, top_k: int 5): # 實(shí)際檢索邏輯 results vector_store.search(query, top_k) return [{title: r.title, content: r.content} for r in results]最后把工具注冊(cè)到 MCP 服務(wù)端Agent 通過 MCP 客戶端連接后就能自動(dòng)發(fā)現(xiàn)并調(diào)用這個(gè)工具。這里有個(gè)坑要注意工具描述的質(zhì)量直接決定 Agent 會(huì)不會(huì)正確調(diào)用。我一開始寫的描述很簡(jiǎn)略結(jié)果 Agent 經(jīng)常在不需要檢索的時(shí)候也去調(diào)這個(gè)工具。后來我把描述改得更具體加上僅在用戶詢問制度、流程、規(guī)定時(shí)使用這樣的約束誤調(diào)用率明顯下降。3.2 A2A 通信的消息格式設(shè)計(jì)A2A 通信的關(guān)鍵是消息格式要統(tǒng)一。我定義了一個(gè)基礎(chǔ)消息結(jié)構(gòu)包含發(fā)送方、接收方、消息類型、負(fù)載和上下文 ID。{ from: research_agent, to: writing_agent, type: task_delegation, context_id: task_20240115_001, payload: { task: 根據(jù)以下研究結(jié)果撰寫報(bào)告, data: {...}, requirements: 字?jǐn)?shù) 800 字包含數(shù)據(jù)引用 } }context_id很重要它讓多個(gè) Agent 之間的多輪交互能關(guān)聯(lián)起來。比如研究 Agent 發(fā)了任務(wù)后寫作 Agent 可能中途回來問問題這時(shí)候靠 context_id 就能找到原始任務(wù)上下文。A2A 的響應(yīng)支持流式和非流式兩種。流式適合長(zhǎng)任務(wù)寫作 Agent 可以邊寫邊把內(nèi)容推給調(diào)用方非流式適合短任務(wù)一次性返回結(jié)果。我在項(xiàng)目里默認(rèn)用流式因?yàn)橛脩趔w驗(yàn)更好而且能提前發(fā)現(xiàn)生成方向跑偏的問題。3.3 Skills 的注冊(cè)與發(fā)現(xiàn)機(jī)制Skills 要能被復(fù)用就需要一個(gè)注冊(cè)中心。我實(shí)現(xiàn)了一個(gè)簡(jiǎn)單的 Skill Registry每個(gè) Skill 注冊(cè)時(shí)提供名稱、描述、輸入輸出 schema 和執(zhí)行入口。class SkillRegistry: def __init__(self): self.skills {} def register(self, name, description, schema, handler): self.skills[name] { description: description, schema: schema, handler: handler } def get(self, name): return self.skills.get(name) def list_all(self): return list(self.skills.keys())Agent 在初始化時(shí)從 Registry 拉取可用的 Skill 列表根據(jù)任務(wù)需要?jiǎng)討B(tài)綁定。這樣新增 Skill 不用改 Agent 代碼只要注冊(cè)進(jìn)去就行。熱搜里提到的find skills和skills 推薦反映了大家對(duì)這個(gè)機(jī)制的關(guān)注。我的經(jīng)驗(yàn)是Skill 的發(fā)現(xiàn)不能只靠名稱匹配還要有語(yǔ)義檢索。我后來加了一個(gè)基于向量相似度的 Skill 檢索Agent 用自然語(yǔ)言描述需求就能找到合適的 Skill比硬編碼名稱靈活得多。3.4 狀態(tài)管理與上下文傳遞多智能體系統(tǒng)里狀態(tài)管理是最容易出問題的地方。我的做法是全局狀態(tài)用共享存儲(chǔ)局部狀態(tài)用消息傳遞。全局狀態(tài)包括任務(wù) ID、用戶信息、會(huì)話歷史存在 Redis 里所有 Agent 都能讀寫。局部狀態(tài)包括當(dāng)前節(jié)點(diǎn)的中間結(jié)果通過 A2A 消息在 Agent 之間傳遞不落盤。這樣設(shè)計(jì)的好處是避免了狀態(tài)不一致。我踩過的坑是早期把所有狀態(tài)都放在消息里傳結(jié)果一個(gè) Agent 改了狀態(tài)但沒傳給下一個(gè)導(dǎo)致數(shù)據(jù)丟失。后來把關(guān)鍵狀態(tài)抽到共享存儲(chǔ)問題就解決了。提示共享存儲(chǔ)要加版本號(hào)或樂觀鎖防止多個(gè) Agent 并發(fā)寫同一份數(shù)據(jù)時(shí)互相覆蓋。4. 實(shí)操落地從零搭建一個(gè)多智能體系統(tǒng)4.1 環(huán)境準(zhǔn)備與依賴安裝我以 Python 技術(shù)棧為例列出核心依賴。如果你用其他語(yǔ)言思路是一樣的只是庫(kù)不同。pip install fastapi uvicorn redis pydantic pip install mcp-client mcp-server pip install a2a-sdk pip install langgraph # 用于 DAG 編排MCP 和 A2A 的 SDK 目前還在快速迭代建議鎖定版本號(hào)避免升級(jí)導(dǎo)致接口不兼容。我在項(xiàng)目里用 requirements.txt 固定了版本每次升級(jí)前先在測(cè)試環(huán)境驗(yàn)證。Redis 用于共享狀態(tài)存儲(chǔ)FastAPI 用于暴露 HTTP 接口Pydantic 用于數(shù)據(jù)校驗(yàn)。LangGraph 是我常用的 DAG 編排庫(kù)它原生支持條件分支和循環(huán)比手寫狀態(tài)機(jī)省事。4.2 定義第一個(gè) Agent 和 Skill先定義一個(gè)最簡(jiǎn)單的文檔檢索 Agent它綁定一個(gè)檢索文檔的 Skill。from pydantic import BaseModel class SearchInput(BaseModel): query: str top_k: int 5 class SearchOutput(BaseModel): results: list total: int def search_handler(input: SearchInput) - SearchOutput: results vector_store.search(input.query, input.top_k) return SearchOutput(resultsresults, totallen(results)) # 注冊(cè) Skill registry.register( namesearch_documents, description檢索企業(yè)制度文檔適用于查詢規(guī)定、流程、政策, schema{input: SearchInput, output: SearchOutput}, handlersearch_handler )然后定義 Agent它從 Registry 獲取 Skill通過 MCP 調(diào)用工具通過 A2A 接收任務(wù)。class DocumentAgent: def __init__(self, registry, mcp_client, a2a_client): self.registry registry self.mcp mcp_client self.a2a a2a_client self.skill registry.get(search_documents) async def handle(self, message): input_data SearchInput(**message.payload) result self.skill[handler](input_data) return {status: success, data: result.dict()}這個(gè) Agent 的結(jié)構(gòu)很清晰接收消息、解析輸入、執(zhí)行 Skill、返回結(jié)果。新增能力只需要注冊(cè)新 Skill 并綁定到 Agent 上。4.3 編排多個(gè) Agent 的 DAG有了單個(gè) Agent 后用 LangGraph 把它們編排成 DAG。我以一個(gè)員工咨詢場(chǎng)景為例用戶提問后先判斷問題類型如果是制度類問題走文檔 Agent如果是數(shù)據(jù)類問題走數(shù)據(jù) Agent最后統(tǒng)一由匯總 Agent 生成回答。from langgraph.graph import StateGraph, END def route_question(state): if 制度 in state[question] or 流程 in state[question]: return document_agent elif 數(shù)據(jù) in state[question] or 統(tǒng)計(jì) in state[question]: return data_agent else: return general_agent graph StateGraph(AgentState) graph.add_node(router, route_question) graph.add_node(document_agent, document_node) graph.add_node(data_agent, data_node) graph.add_node(general_agent, general_node) graph.add_node(summarizer, summarize_node) graph.set_entry_point(router) graph.add_conditional_edges(router, route_question, { document_agent: document_agent, data_agent: data_agent, general_agent: general_agent }) graph.add_edge(document_agent, summarizer) graph.add_edge(data_agent, summarizer) graph.add_edge(general_agent, summarizer) graph.add_edge(summarizer, END) app graph.compile()這個(gè) DAG 的關(guān)鍵點(diǎn)是路由節(jié)點(diǎn)。路由可以用規(guī)則實(shí)現(xiàn)也可以用一個(gè)小模型做意圖分類。我在項(xiàng)目里用的是規(guī)則加模型兜底常見問題走規(guī)則規(guī)則匹配不到時(shí)調(diào)模型判斷兼顧速度和準(zhǔn)確率。4.4 參數(shù)計(jì)算與性能調(diào)優(yōu)多智能體系統(tǒng)的性能瓶頸通常在兩個(gè)地方Agent 間的通信延遲和模型調(diào)用次數(shù)。我做過一組實(shí)測(cè)數(shù)據(jù)供參考。場(chǎng)景Agent 數(shù)量平均響應(yīng)時(shí)間模型調(diào)用次數(shù)單體 Agent12.1s1-2雙 Agent 串行23.8s2-3三 Agent 并行34.2s3-4五 Agent 混合56.5s5-7從數(shù)據(jù)看Agent 數(shù)量增加會(huì)帶來明顯的延遲增長(zhǎng)。優(yōu)化方向有三個(gè)一是并行化能并行的節(jié)點(diǎn)不要串行二是緩存相同輸入的結(jié)果緩存起來三是模型分級(jí)簡(jiǎn)單任務(wù)用便宜的小模型。我在項(xiàng)目里給每個(gè) Agent 配了不同的模型路由用 7B 小模型文檔檢索用 13B 模型匯總生成用 70B 大模型。這樣整體成本降了約 60%響應(yīng)時(shí)間只增加了 15%。4.5 部署與監(jiān)控部署上我推薦容器化每個(gè) Agent 一個(gè)容器通過消息隊(duì)列或 HTTP 通信。這樣單個(gè) Agent 出問題不影響整體也方便水平擴(kuò)展。監(jiān)控要覆蓋三個(gè)層面節(jié)點(diǎn)級(jí)別的執(zhí)行時(shí)間、Agent 級(jí)別的調(diào)用成功率、系統(tǒng)級(jí)別的吞吐量。我用 Prometheus 采集指標(biāo)Grafana 做可視化。關(guān)鍵指標(biāo)包括每個(gè)節(jié)點(diǎn)的 P99 延遲、A2A 消息的丟失率、MCP 工具調(diào)用的錯(cuò)誤率。注意多智能體系統(tǒng)的調(diào)試比單體復(fù)雜得多。建議在開發(fā)階段開啟全鏈路日志記錄每個(gè)節(jié)點(diǎn)的輸入輸出和 Agent 間的消息。生產(chǎn)環(huán)境可以采樣記錄避免日志量過大。5. 常見問題與排查技巧實(shí)錄5.1 Agent 之間消息丟失或亂序這是 A2A 通信最常見的問題。表現(xiàn)是下游 Agent 收不到消息或者收到的消息順序不對(duì)。排查思路先看消息隊(duì)列的積壓情況如果積壓嚴(yán)重說明消費(fèi)能力不足再看消息的 context_id 是否一致不一致說明發(fā)送方生成邏輯有問題最后看網(wǎng)絡(luò)層是否有丟包。我的解決方案是給消息加序號(hào)和確認(rèn)機(jī)制。發(fā)送方給每條消息編號(hào)接收方收到后回 ACK超時(shí)未收到 ACK 就重發(fā)。這樣能保證消息不丟但要注意去重避免重發(fā)導(dǎo)致重復(fù)處理。5.2 MCP 工具調(diào)用超時(shí)MCP 工具調(diào)用超時(shí)通常有三個(gè)原因工具本身執(zhí)行慢、網(wǎng)絡(luò)延遲、Agent 等待策略不合理。我遇到過一次數(shù)據(jù)庫(kù)查詢工具超時(shí)排查發(fā)現(xiàn)是查詢沒加索引全表掃描導(dǎo)致。加了索引后從 8 秒降到 200 毫秒。所以工具本身的性能要先保證。網(wǎng)絡(luò)延遲方面如果 MCP 服務(wù)端和 Agent 不在同一臺(tái)機(jī)器建議加連接池和重試機(jī)制。Agent 側(cè)的等待策略要設(shè)置合理的超時(shí)時(shí)間我一般設(shè) 30 秒超過就返回降級(jí)結(jié)果。5.3 Skill 沖突與優(yōu)先級(jí)當(dāng)多個(gè) Skill 功能重疊時(shí)Agent 可能選錯(cuò)。比如同時(shí)有查詢文檔和搜索知識(shí)庫(kù)兩個(gè) SkillAgent 不知道該用哪個(gè)。解決辦法是給 Skill 加優(yōu)先級(jí)和適用場(chǎng)景標(biāo)簽。Agent 選擇時(shí)先按場(chǎng)景過濾再按優(yōu)先級(jí)排序。另外Skill 的描述要寫清楚邊界避免功能重疊。我在項(xiàng)目里維護(hù)了一個(gè) Skill 沖突檢查清單新增 Skill 時(shí)先檢查是否與已有 Skill 重疊重疊的要么合并要么明確分工。5.4 常見問題速查表問題現(xiàn)象可能原因排查方法解決方案Agent 不響應(yīng)消息未送達(dá)檢查消息隊(duì)列和 ACK加重試和確認(rèn)機(jī)制工具調(diào)用失敗參數(shù)格式錯(cuò)誤查看 MCP 調(diào)用日志校驗(yàn)輸入 schema響應(yīng)時(shí)間過長(zhǎng)串行節(jié)點(diǎn)過多分析 DAG 執(zhí)行路徑并行化可并行節(jié)點(diǎn)結(jié)果不一致狀態(tài)競(jìng)爭(zhēng)檢查共享存儲(chǔ)讀寫加鎖或版本號(hào)Skill 選錯(cuò)描述不清晰查看 Agent 決策日志優(yōu)化 Skill 描述和優(yōu)先級(jí)模型成本過高大模型調(diào)用過多統(tǒng)計(jì)各 Agent 模型用量分級(jí)用模型加緩存5.5 幾個(gè)踩過的坑第一個(gè)坑是過度設(shè)計(jì)。我一開始給每個(gè) Agent 都配了完整的 MCP 和 A2A 能力結(jié)果系統(tǒng)復(fù)雜度飆升調(diào)試?yán)щy。后來發(fā)現(xiàn)很多 Agent 只需要 MCP 調(diào)工具不需要 A2A砍掉后系統(tǒng)清爽很多。第二個(gè)坑是忽略冪等性。A2A 消息重發(fā)時(shí)如果接收方?jīng)]有冪等處理會(huì)導(dǎo)致重復(fù)執(zhí)行。比如重復(fù)扣款、重復(fù)發(fā)郵件。我的做法是給每個(gè)任務(wù)加唯一 ID接收方處理前先檢查是否已處理過。第三個(gè)坑是日志太多。全鏈路日志在調(diào)試時(shí)很有用但生產(chǎn)環(huán)境日志量太大影響性能。后來改成采樣記錄只對(duì)錯(cuò)誤和慢請(qǐng)求記錄完整日志。第四個(gè)坑是Skill 版本管理。Skill 更新后正在運(yùn)行的 Agent 可能還在用舊版本。我的解決方案是給 Skill 加版本號(hào)Agent 綁定具體版本更新時(shí)灰度切換。5.6 性能優(yōu)化的幾個(gè)實(shí)用技巧緩存是最有效的優(yōu)化手段。我在 MCP 工具層加了結(jié)果緩存相同參數(shù)的調(diào)用直接返回緩存結(jié)果。對(duì)于文檔檢索這類讀多寫少的場(chǎng)景緩存命中率能到 40% 以上。批處理也很重要。如果多個(gè) Agent 需要調(diào)用同一個(gè)工具可以合并成一次批量調(diào)用。比如三個(gè) Agent 都要查用戶信息合并成一次查詢比三次單獨(dú)查詢快得多。異步化是另一個(gè)方向。A2A 通信默認(rèn)是異步的但很多實(shí)現(xiàn)里 Agent 處理消息是同步的。改成異步后Agent 可以在等待下游響應(yīng)時(shí)處理其他任務(wù)吞吐量能提升 2-3 倍。最后是模型分級(jí)。不是所有任務(wù)都需要大模型。路由、分類、簡(jiǎn)單抽取用 7B 模型就夠只有生成和復(fù)雜推理才需要大模型。我在項(xiàng)目里做了模型分級(jí)后成本降了 60%效果幾乎沒影響。這套架構(gòu)我用了大半年從最初的 3 個(gè) Agent 擴(kuò)展到現(xiàn)在的 12 個(gè)新增能力基本不用改核心代碼。如果你也在做類似的項(xiàng)目建議先從兩三個(gè) Agent 的小系統(tǒng)開始跑通了再逐步擴(kuò)展。一上來就搞十幾個(gè) Agent調(diào)試成本會(huì)讓你懷疑人生。 超級(jí)多智能體架構(gòu)實(shí)戰(zhàn)：DeepAgents編排、MCP工具接入與A2A通信
1. 從單體到集群為什么我們需要超級(jí)多智能體1.1 一個(gè)真實(shí)的需求場(chǎng)景去年下半年我接手了一個(gè)企業(yè)內(nèi)部知識(shí)助手的項(xiàng)目需求聽起來不復(fù)雜幫員工查制度文檔、走審批流程、生成周報(bào)。一開始我用的是單體 Agent 方案一個(gè)模型加一堆工具函數(shù)跑起來確實(shí)快。但上線兩周后問題就來了——查文檔的 Agent 經(jīng)常被審批流程的上下文污染生成周報(bào)時(shí)又因?yàn)橐{(diào)用太多工具導(dǎo)致響應(yīng)時(shí)間飆到十幾秒。最要命的是我想給文檔檢索單獨(dú)換一個(gè)更便宜的模型結(jié)果發(fā)現(xiàn)整個(gè)系統(tǒng)耦合在一起改一處動(dòng)全身。這個(gè)經(jīng)歷讓我徹底轉(zhuǎn)向了多智能體架構(gòu)。所謂超級(jí)多智能體不是簡(jiǎn)單地把幾個(gè) Agent 拼在一起而是要解決三個(gè)核心問題可編排誰(shuí)先誰(shuí)后、誰(shuí)調(diào)用誰(shuí)、可互通Agent 之間怎么傳消息、怎么共享狀態(tài)、可擴(kuò)展新增一個(gè) Agent 要不要改老代碼。這三個(gè)問題對(duì)應(yīng)到技術(shù)選型上就是 DeepAgents 負(fù)責(zé)編排、MCP 負(fù)責(zé)工具接入、A2A 負(fù)責(zé) Agent 間通信、Skills 負(fù)責(zé)能力封裝。如果你正在做 Agent 項(xiàng)目或者被單體 Agent 的耦合問題折磨過這套組合拳值得花時(shí)間研究。它不依賴某個(gè)特定廠商核心思路可以遷移到任何 Agent 框架上。1.2 四個(gè)關(guān)鍵詞到底在說什么先把概念理清楚不然后面容易繞暈。DeepAgents在這里指的是一種深度編排的 Agent 架構(gòu)模式核心思想是把復(fù)雜任務(wù)拆成有向圖每個(gè)節(jié)點(diǎn)是一個(gè) Agent 或一個(gè)工具調(diào)用邊代表數(shù)據(jù)流和控制流。它和簡(jiǎn)單的鏈?zhǔn)秸{(diào)用Chain最大的區(qū)別在于支持條件分支、循環(huán)、并行和人工介入節(jié)點(diǎn)。MCPModel Context Protocol是一個(gè)開放協(xié)議解決的是Agent 怎么標(biāo)準(zhǔn)化地調(diào)用外部工具和數(shù)據(jù)源的問題。你可以把它理解成 Agent 世界的 USB 接口——不管你是數(shù)據(jù)庫(kù)、文件系統(tǒng)還是第三方 API只要實(shí)現(xiàn) MCP 協(xié)議任何支持 MCP 的 Agent 都能直接接入。熱搜里有人問mcp 是軟件協(xié)議還是硬件協(xié)議答案是軟件協(xié)議它定義的是通信格式和調(diào)用規(guī)范跟硬件層面的協(xié)議比如 USB、I2C完全是兩回事。A2AAgent to Agent解決的是 Agent 之間的通信問題。MCP 管的是 Agent 調(diào)工具A2A 管的是 Agent 調(diào) Agent。它定義了 Agent 之間怎么發(fā)現(xiàn)對(duì)方、怎么發(fā)消息、怎么處理異步響應(yīng)。熱搜里出現(xiàn)的a2a spring說明已經(jīng)有人在 Spring 生態(tài)里做 A2A 的集成了。Skills是能力的封裝單元。一個(gè) Skill 可以是一個(gè)提示詞模板、一段代碼邏輯、一組工具調(diào)用的組合。它的價(jià)值在于復(fù)用——你寫好一個(gè)生成周報(bào)的 Skill可以在多個(gè) Agent 里直接引用不用重復(fù)實(shí)現(xiàn)。熱搜里claude agent skills: a first principles deep dive和codex skills都指向同一個(gè)趨勢(shì)Skills 正在成為 Agent 能力復(fù)用的標(biāo)準(zhǔn)方式。1.3 這套架構(gòu)適合誰(shuí)不是所有項(xiàng)目都需要上多智能體。如果你的需求是單輪問答、簡(jiǎn)單工具調(diào)用單體 Agent 完全夠用硬上多智能體只會(huì)增加復(fù)雜度。但如果你遇到以下情況這套架構(gòu)就值得考慮任務(wù)流程超過 5 個(gè)步驟且步驟之間有依賴關(guān)系需要多個(gè)專業(yè)領(lǐng)域的 Agent 協(xié)作比如一個(gè)查數(shù)據(jù)、一個(gè)做分析、一個(gè)寫報(bào)告工具數(shù)量超過 10 個(gè)單體 Agent 的提示詞已經(jīng)塞不下需要給不同 Agent 配不同模型來控制成本系統(tǒng)需要頻繁新增能力不想每次改核心代碼下面我會(huì)按照實(shí)際搭建的順序從架構(gòu)設(shè)計(jì)到落地實(shí)現(xiàn)把每個(gè)環(huán)節(jié)講透。2. 架構(gòu)設(shè)計(jì)編排層、通信層、能力層怎么分2.1 三層架構(gòu)的職責(zé)邊界我在實(shí)際項(xiàng)目中把系統(tǒng)分成三層每層職責(zé)清晰層與層之間通過標(biāo)準(zhǔn)協(xié)議通信。編排層DeepAgents負(fù)責(zé)決策任務(wù)怎么拆、下一步走哪個(gè)節(jié)點(diǎn)、什么時(shí)候結(jié)束。這一層不關(guān)心具體工具怎么調(diào)只關(guān)心流程控制。我通常用一個(gè)有向無環(huán)圖DAG來描述流程節(jié)點(diǎn)類型包括Agent 節(jié)點(diǎn)、工具節(jié)點(diǎn)、條件判斷節(jié)點(diǎn)、人工審核節(jié)點(diǎn)、并行分支節(jié)點(diǎn)。通信層A2A MCP負(fù)責(zé)傳輸Agent 之間怎么傳消息用 A2AAgent 調(diào)工具用 MCP。這一層的關(guān)鍵是協(xié)議標(biāo)準(zhǔn)化只要協(xié)議統(tǒng)一底層換實(shí)現(xiàn)不影響上層。能力層Skills負(fù)責(zé)執(zhí)行每個(gè) Skill 是一個(gè)獨(dú)立的能力單元包含提示詞、工具綁定、輸入輸出定義。Skill 可以注冊(cè)到多個(gè) Agent 上實(shí)現(xiàn)復(fù)用。這樣分層的最大好處是新增一個(gè) Agent 只需要在編排層加節(jié)點(diǎn)、在能力層加 Skill通信層完全不用動(dòng)。我試過在一個(gè)已有 8 個(gè) Agent 的系統(tǒng)里新增一個(gè)合同審查Agent從寫 Skill 到接入流程只花了半天。2.2 為什么選 DAG 而不是狀態(tài)機(jī)編排層可以用狀態(tài)機(jī)也可以用 DAG。我最終選 DAG 的原因是狀態(tài)機(jī)適合線性流程但多智能體場(chǎng)景下經(jīng)常需要并行和條件分支。比如同時(shí)查三個(gè)數(shù)據(jù)源然后匯總這種需求用狀態(tài)機(jī)寫起來很別扭DAG 天然支持并行節(jié)點(diǎn)。DAG 的另一個(gè)好處是可觀測(cè)。每個(gè)節(jié)點(diǎn)的輸入輸出都能記錄下來出問題時(shí)可以精確定位是哪個(gè)節(jié)點(diǎn)出了錯(cuò)。我在生產(chǎn)環(huán)境里給每個(gè)節(jié)點(diǎn)都加了日志埋點(diǎn)排查問題時(shí)直接看節(jié)點(diǎn)級(jí)別的 trace比看一整條鏈路的日志高效得多。2.3 通信協(xié)議選型MCP 和 A2A 的分工很多人搞不清 MCP 和 A2A 的區(qū)別我用一個(gè)類比說明MCP 像是人用工具A2A 像是人跟人說話。你用手電筒工具不需要跟手電筒商量直接按開關(guān)就行這是 MCP。但你要跟同事協(xié)作就得說話、等回復(fù)、確認(rèn)理解這是 A2A。具體到實(shí)現(xiàn)上MCP 的調(diào)用是同步或異步的請(qǐng)求-響應(yīng)模式Agent 發(fā)一個(gè)調(diào)用請(qǐng)求工具返回結(jié)果。A2A 則更復(fù)雜支持流式響應(yīng)、多輪對(duì)話、任務(wù)委派。我在項(xiàng)目里用 MCP 接入了文件系統(tǒng)、數(shù)據(jù)庫(kù)、搜索引擎三類工具用 A2A 實(shí)現(xiàn)了研究 Agent和寫作 Agent之間的協(xié)作。注意MCP 和 A2A 不是互斥的。一個(gè) Agent 可以同時(shí)是 MCP 的客戶端調(diào)工具和 A2A 的服務(wù)端被其他 Agent 調(diào)用。這種雙重身份在多智能體系統(tǒng)里很常見。2.4 Skills 的粒度怎么把握Skills 的粒度設(shè)計(jì)是個(gè)經(jīng)驗(yàn)活。太粗復(fù)用性差太細(xì)組合起來麻煩。我的原則是一個(gè) Skill 對(duì)應(yīng)一個(gè)完整的業(yè)務(wù)動(dòng)作。比如查詢員工考勤是一個(gè) Skill它內(nèi)部可能調(diào)了三個(gè) MCP 工具查數(shù)據(jù)庫(kù)、格式化數(shù)據(jù)、計(jì)算統(tǒng)計(jì)但對(duì)外只暴露一個(gè)接口。這樣其他 Agent 引用時(shí)不用關(guān)心內(nèi)部實(shí)現(xiàn)。反過來調(diào)用數(shù)據(jù)庫(kù)這種太底層的操作不適合做成 Skill它應(yīng)該是 MCP 工具。Skill 的抽象層級(jí)要高于工具低于完整的 Agent。3. 核心細(xì)節(jié)MCP 工具接入與 A2A 通信實(shí)現(xiàn)3.1 MCP 工具接入的完整流程MCP 的核心是標(biāo)準(zhǔn)化。不管你的工具是 Python 函數(shù)、HTTP API 還是數(shù)據(jù)庫(kù)查詢都要包裝成 MCP 協(xié)議規(guī)定的格式。我以接入一個(gè)文檔檢索工具為例走一遍完整流程。首先定義工具的元數(shù)據(jù)包括名稱、描述、輸入?yún)?shù) schema。這部分用 JSON Schema 描述目的是讓 Agent 知道這個(gè)工具能干什么、需要什么參數(shù)。{ name: search_documents, description: 根據(jù)關(guān)鍵詞檢索企業(yè)制度文檔, inputSchema: { type: object, properties: { query: {type: string, description: 檢索關(guān)鍵詞}, top_k: {type: integer, default: 5, description: 返回結(jié)果數(shù)量} }, required: [query] } }然后實(shí)現(xiàn)工具的執(zhí)行邏輯。這部分可以用任何語(yǔ)言寫只要最終暴露成 MCP 服務(wù)端即可。我用 Python 寫了一個(gè)簡(jiǎn)單的實(shí)現(xiàn)def search_documents(query: str, top_k: int 5): # 實(shí)際檢索邏輯 results vector_store.search(query, top_k) return [{title: r.title, content: r.content} for r in results]最后把工具注冊(cè)到 MCP 服務(wù)端Agent 通過 MCP 客戶端連接后就能自動(dòng)發(fā)現(xiàn)并調(diào)用這個(gè)工具。這里有個(gè)坑要注意工具描述的質(zhì)量直接決定 Agent 會(huì)不會(huì)正確調(diào)用。我一開始寫的描述很簡(jiǎn)略結(jié)果 Agent 經(jīng)常在不需要檢索的時(shí)候也去調(diào)這個(gè)工具。后來我把描述改得更具體加上僅在用戶詢問制度、流程、規(guī)定時(shí)使用這樣的約束誤調(diào)用率明顯下降。3.2 A2A 通信的消息格式設(shè)計(jì)A2A 通信的關(guān)鍵是消息格式要統(tǒng)一。我定義了一個(gè)基礎(chǔ)消息結(jié)構(gòu)包含發(fā)送方、接收方、消息類型、負(fù)載和上下文 ID。{ from: research_agent, to: writing_agent, type: task_delegation, context_id: task_20240115_001, payload: { task: 根據(jù)以下研究結(jié)果撰寫報(bào)告, data: {...}, requirements: 字?jǐn)?shù) 800 字包含數(shù)據(jù)引用 } }context_id很重要它讓多個(gè) Agent 之間的多輪交互能關(guān)聯(lián)起來。比如研究 Agent 發(fā)了任務(wù)后寫作 Agent 可能中途回來問問題這時(shí)候靠 context_id 就能找到原始任務(wù)上下文。A2A 的響應(yīng)支持流式和非流式兩種。流式適合長(zhǎng)任務(wù)寫作 Agent 可以邊寫邊把內(nèi)容推給調(diào)用方非流式適合短任務(wù)一次性返回結(jié)果。我在項(xiàng)目里默認(rèn)用流式因?yàn)橛脩趔w驗(yàn)更好而且能提前發(fā)現(xiàn)生成方向跑偏的問題。3.3 Skills 的注冊(cè)與發(fā)現(xiàn)機(jī)制Skills 要能被復(fù)用就需要一個(gè)注冊(cè)中心。我實(shí)現(xiàn)了一個(gè)簡(jiǎn)單的 Skill Registry每個(gè) Skill 注冊(cè)時(shí)提供名稱、描述、輸入輸出 schema 和執(zhí)行入口。class SkillRegistry: def __init__(self): self.skills {} def register(self, name, description, schema, handler): self.skills[name] { description: description, schema: schema, handler: handler } def get(self, name): return self.skills.get(name) def list_all(self): return list(self.skills.keys())Agent 在初始化時(shí)從 Registry 拉取可用的 Skill 列表根據(jù)任務(wù)需要?jiǎng)討B(tài)綁定。這樣新增 Skill 不用改 Agent 代碼只要注冊(cè)進(jìn)去就行。熱搜里提到的find skills和skills 推薦反映了大家對(duì)這個(gè)機(jī)制的關(guān)注。我的經(jīng)驗(yàn)是Skill 的發(fā)現(xiàn)不能只靠名稱匹配還要有語(yǔ)義檢索。我后來加了一個(gè)基于向量相似度的 Skill 檢索Agent 用自然語(yǔ)言描述需求就能找到合適的 Skill比硬編碼名稱靈活得多。3.4 狀態(tài)管理與上下文傳遞多智能體系統(tǒng)里狀態(tài)管理是最容易出問題的地方。我的做法是全局狀態(tài)用共享存儲(chǔ)局部狀態(tài)用消息傳遞。全局狀態(tài)包括任務(wù) ID、用戶信息、會(huì)話歷史存在 Redis 里所有 Agent 都能讀寫。局部狀態(tài)包括當(dāng)前節(jié)點(diǎn)的中間結(jié)果通過 A2A 消息在 Agent 之間傳遞不落盤。這樣設(shè)計(jì)的好處是避免了狀態(tài)不一致。我踩過的坑是早期把所有狀態(tài)都放在消息里傳結(jié)果一個(gè) Agent 改了狀態(tài)但沒傳給下一個(gè)導(dǎo)致數(shù)據(jù)丟失。后來把關(guān)鍵狀態(tài)抽到共享存儲(chǔ)問題就解決了。提示共享存儲(chǔ)要加版本號(hào)或樂觀鎖防止多個(gè) Agent 并發(fā)寫同一份數(shù)據(jù)時(shí)互相覆蓋。4. 實(shí)操落地從零搭建一個(gè)多智能體系統(tǒng)4.1 環(huán)境準(zhǔn)備與依賴安裝我以 Python 技術(shù)棧為例列出核心依賴。如果你用其他語(yǔ)言思路是一樣的只是庫(kù)不同。pip install fastapi uvicorn redis pydantic pip install mcp-client mcp-server pip install a2a-sdk pip install langgraph # 用于 DAG 編排MCP 和 A2A 的 SDK 目前還在快速迭代建議鎖定版本號(hào)避免升級(jí)導(dǎo)致接口不兼容。我在項(xiàng)目里用 requirements.txt 固定了版本每次升級(jí)前先在測(cè)試環(huán)境驗(yàn)證。Redis 用于共享狀態(tài)存儲(chǔ)FastAPI 用于暴露 HTTP 接口Pydantic 用于數(shù)據(jù)校驗(yàn)。LangGraph 是我常用的 DAG 編排庫(kù)它原生支持條件分支和循環(huán)比手寫狀態(tài)機(jī)省事。4.2 定義第一個(gè) Agent 和 Skill先定義一個(gè)最簡(jiǎn)單的文檔檢索 Agent它綁定一個(gè)檢索文檔的 Skill。from pydantic import BaseModel class SearchInput(BaseModel): query: str top_k: int 5 class SearchOutput(BaseModel): results: list total: int def search_handler(input: SearchInput) - SearchOutput: results vector_store.search(input.query, input.top_k) return SearchOutput(resultsresults, totallen(results)) # 注冊(cè) Skill registry.register( namesearch_documents, description檢索企業(yè)制度文檔適用于查詢規(guī)定、流程、政策, schema{input: SearchInput, output: SearchOutput}, handlersearch_handler )然后定義 Agent它從 Registry 獲取 Skill通過 MCP 調(diào)用工具通過 A2A 接收任務(wù)。class DocumentAgent: def __init__(self, registry, mcp_client, a2a_client): self.registry registry self.mcp mcp_client self.a2a a2a_client self.skill registry.get(search_documents) async def handle(self, message): input_data SearchInput(**message.payload) result self.skill[handler](input_data) return {status: success, data: result.dict()}這個(gè) Agent 的結(jié)構(gòu)很清晰接收消息、解析輸入、執(zhí)行 Skill、返回結(jié)果。新增能力只需要注冊(cè)新 Skill 并綁定到 Agent 上。4.3 編排多個(gè) Agent 的 DAG有了單個(gè) Agent 后用 LangGraph 把它們編排成 DAG。我以一個(gè)員工咨詢場(chǎng)景為例用戶提問后先判斷問題類型如果是制度類問題走文檔 Agent如果是數(shù)據(jù)類問題走數(shù)據(jù) Agent最后統(tǒng)一由匯總 Agent 生成回答。from langgraph.graph import StateGraph, END def route_question(state): if 制度 in state[question] or 流程 in state[question]: return document_agent elif 數(shù)據(jù) in state[question] or 統(tǒng)計(jì) in state[question]: return data_agent else: return general_agent graph StateGraph(AgentState) graph.add_node(router, route_question) graph.add_node(document_agent, document_node) graph.add_node(data_agent, data_node) graph.add_node(general_agent, general_node) graph.add_node(summarizer, summarize_node) graph.set_entry_point(router) graph.add_conditional_edges(router, route_question, { document_agent: document_agent, data_agent: data_agent, general_agent: general_agent }) graph.add_edge(document_agent, summarizer) graph.add_edge(data_agent, summarizer) graph.add_edge(general_agent, summarizer) graph.add_edge(summarizer, END) app graph.compile()這個(gè) DAG 的關(guān)鍵點(diǎn)是路由節(jié)點(diǎn)。路由可以用規(guī)則實(shí)現(xiàn)也可以用一個(gè)小模型做意圖分類。我在項(xiàng)目里用的是規(guī)則加模型兜底常見問題走規(guī)則規(guī)則匹配不到時(shí)調(diào)模型判斷兼顧速度和準(zhǔn)確率。4.4 參數(shù)計(jì)算與性能調(diào)優(yōu)多智能體系統(tǒng)的性能瓶頸通常在兩個(gè)地方Agent 間的通信延遲和模型調(diào)用次數(shù)。我做過一組實(shí)測(cè)數(shù)據(jù)供參考。場(chǎng)景Agent 數(shù)量平均響應(yīng)時(shí)間模型調(diào)用次數(shù)單體 Agent12.1s1-2雙 Agent 串行23.8s2-3三 Agent 并行34.2s3-4五 Agent 混合56.5s5-7從數(shù)據(jù)看Agent 數(shù)量增加會(huì)帶來明顯的延遲增長(zhǎng)。優(yōu)化方向有三個(gè)一是并行化能并行的節(jié)點(diǎn)不要串行二是緩存相同輸入的結(jié)果緩存起來三是模型分級(jí)簡(jiǎn)單任務(wù)用便宜的小模型。我在項(xiàng)目里給每個(gè) Agent 配了不同的模型路由用 7B 小模型文檔檢索用 13B 模型匯總生成用 70B 大模型。這樣整體成本降了約 60%響應(yīng)時(shí)間只增加了 15%。4.5 部署與監(jiān)控部署上我推薦容器化每個(gè) Agent 一個(gè)容器通過消息隊(duì)列或 HTTP 通信。這樣單個(gè) Agent 出問題不影響整體也方便水平擴(kuò)展。監(jiān)控要覆蓋三個(gè)層面節(jié)點(diǎn)級(jí)別的執(zhí)行時(shí)間、Agent 級(jí)別的調(diào)用成功率、系統(tǒng)級(jí)別的吞吐量。我用 Prometheus 采集指標(biāo)Grafana 做可視化。關(guān)鍵指標(biāo)包括每個(gè)節(jié)點(diǎn)的 P99 延遲、A2A 消息的丟失率、MCP 工具調(diào)用的錯(cuò)誤率。注意多智能體系統(tǒng)的調(diào)試比單體復(fù)雜得多。建議在開發(fā)階段開啟全鏈路日志記錄每個(gè)節(jié)點(diǎn)的輸入輸出和 Agent 間的消息。生產(chǎn)環(huán)境可以采樣記錄避免日志量過大。5. 常見問題與排查技巧實(shí)錄5.1 Agent 之間消息丟失或亂序這是 A2A 通信最常見的問題。表現(xiàn)是下游 Agent 收不到消息或者收到的消息順序不對(duì)。排查思路先看消息隊(duì)列的積壓情況如果積壓嚴(yán)重說明消費(fèi)能力不足再看消息的 context_id 是否一致不一致說明發(fā)送方生成邏輯有問題最后看網(wǎng)絡(luò)層是否有丟包。我的解決方案是給消息加序號(hào)和確認(rèn)機(jī)制。發(fā)送方給每條消息編號(hào)接收方收到后回 ACK超時(shí)未收到 ACK 就重發(fā)。這樣能保證消息不丟但要注意去重避免重發(fā)導(dǎo)致重復(fù)處理。5.2 MCP 工具調(diào)用超時(shí)MCP 工具調(diào)用超時(shí)通常有三個(gè)原因工具本身執(zhí)行慢、網(wǎng)絡(luò)延遲、Agent 等待策略不合理。我遇到過一次數(shù)據(jù)庫(kù)查詢工具超時(shí)排查發(fā)現(xiàn)是查詢沒加索引全表掃描導(dǎo)致。加了索引后從 8 秒降到 200 毫秒。所以工具本身的性能要先保證。網(wǎng)絡(luò)延遲方面如果 MCP 服務(wù)端和 Agent 不在同一臺(tái)機(jī)器建議加連接池和重試機(jī)制。Agent 側(cè)的等待策略要設(shè)置合理的超時(shí)時(shí)間我一般設(shè) 30 秒超過就返回降級(jí)結(jié)果。5.3 Skill 沖突與優(yōu)先級(jí)當(dāng)多個(gè) Skill 功能重疊時(shí)Agent 可能選錯(cuò)。比如同時(shí)有查詢文檔和搜索知識(shí)庫(kù)兩個(gè) SkillAgent 不知道該用哪個(gè)。解決辦法是給 Skill 加優(yōu)先級(jí)和適用場(chǎng)景標(biāo)簽。Agent 選擇時(shí)先按場(chǎng)景過濾再按優(yōu)先級(jí)排序。另外Skill 的描述要寫清楚邊界避免功能重疊。我在項(xiàng)目里維護(hù)了一個(gè) Skill 沖突檢查清單新增 Skill 時(shí)先檢查是否與已有 Skill 重疊重疊的要么合并要么明確分工。5.4 常見問題速查表問題現(xiàn)象可能原因排查方法解決方案Agent 不響應(yīng)消息未送達(dá)檢查消息隊(duì)列和 ACK加重試和確認(rèn)機(jī)制工具調(diào)用失敗參數(shù)格式錯(cuò)誤查看 MCP 調(diào)用日志校驗(yàn)輸入 schema響應(yīng)時(shí)間過長(zhǎng)串行節(jié)點(diǎn)過多分析 DAG 執(zhí)行路徑并行化可并行節(jié)點(diǎn)結(jié)果不一致狀態(tài)競(jìng)爭(zhēng)檢查共享存儲(chǔ)讀寫加鎖或版本號(hào)Skill 選錯(cuò)描述不清晰查看 Agent 決策日志優(yōu)化 Skill 描述和優(yōu)先級(jí)模型成本過高大模型調(diào)用過多統(tǒng)計(jì)各 Agent 模型用量分級(jí)用模型加緩存5.5 幾個(gè)踩過的坑第一個(gè)坑是過度設(shè)計(jì)。我一開始給每個(gè) Agent 都配了完整的 MCP 和 A2A 能力結(jié)果系統(tǒng)復(fù)雜度飆升調(diào)試?yán)щy。后來發(fā)現(xiàn)很多 Agent 只需要 MCP 調(diào)工具不需要 A2A砍掉后系統(tǒng)清爽很多。第二個(gè)坑是忽略冪等性。A2A 消息重發(fā)時(shí)如果接收方?jīng)]有冪等處理會(huì)導(dǎo)致重復(fù)執(zhí)行。比如重復(fù)扣款、重復(fù)發(fā)郵件。我的做法是給每個(gè)任務(wù)加唯一 ID接收方處理前先檢查是否已處理過。第三個(gè)坑是日志太多。全鏈路日志在調(diào)試時(shí)很有用但生產(chǎn)環(huán)境日志量太大影響性能。后來改成采樣記錄只對(duì)錯(cuò)誤和慢請(qǐng)求記錄完整日志。第四個(gè)坑是Skill 版本管理。Skill 更新后正在運(yùn)行的 Agent 可能還在用舊版本。我的解決方案是給 Skill 加版本號(hào)Agent 綁定具體版本更新時(shí)灰度切換。5.6 性能優(yōu)化的幾個(gè)實(shí)用技巧緩存是最有效的優(yōu)化手段。我在 MCP 工具層加了結(jié)果緩存相同參數(shù)的調(diào)用直接返回緩存結(jié)果。對(duì)于文檔檢索這類讀多寫少的場(chǎng)景緩存命中率能到 40% 以上。批處理也很重要。如果多個(gè) Agent 需要調(diào)用同一個(gè)工具可以合并成一次批量調(diào)用。比如三個(gè) Agent 都要查用戶信息合并成一次查詢比三次單獨(dú)查詢快得多。異步化是另一個(gè)方向。A2A 通信默認(rèn)是異步的但很多實(shí)現(xiàn)里 Agent 處理消息是同步的。改成異步后Agent 可以在等待下游響應(yīng)時(shí)處理其他任務(wù)吞吐量能提升 2-3 倍。最后是模型分級(jí)。不是所有任務(wù)都需要大模型。路由、分類、簡(jiǎn)單抽取用 7B 模型就夠只有生成和復(fù)雜推理才需要大模型。我在項(xiàng)目里做了模型分級(jí)后成本降了 60%效果幾乎沒影響。這套架構(gòu)我用了大半年從最初的 3 個(gè) Agent 擴(kuò)展到現(xiàn)在的 12 個(gè)新增能力基本不用改核心代碼。如果你也在做類似的項(xiàng)目建議先從兩三個(gè) Agent 的小系統(tǒng)開始跑通了再逐步擴(kuò)展。一上來就搞十幾個(gè) Agent調(diào)試成本會(huì)讓你懷疑人生。