今年上半年我一直在做同一件事：把手头的单点 Agent 工作流，改造成真正的多智能体集群。过程比预想中痛苦，但回头看不光把链路跑通了，还形成了一个比较固定的套路。核心是四样东西：DeepAgents、MCP、A2A和Skills。很多人把这些概念分开看，可真要把多智能体集群落地的时候，它们其实是同一个问题的四个面——MCP 负责给每个智能体装上“手脚”，A2A 负责让智能体之间“说上话”，Skills 负责让每个成员“各怀绝技”，而 DeepAgents 负责让整个系统“想得深、走得远”。这篇文章我会从概念怎么串起来讲起，再到环境搭建、架构选型、完整实战，最后把踩过的坑整理成速查表。适合正在搭多智能体架构、或者准备从单 Agent 升级到集群协同的开发者，内容可以直接抄作业。
1. 先把四个概念的关系理清楚：手、嘴、脑子和技能包
1.1 MCP：给大模型装一个 USB-C 口
MCP 全称 Model Context Protocol，解决的是“模型怎么安全、标准化地调用外部工具和数据”。你可以把它理解成 AI 世界的 USB-C 接口：没有统一标准之前，每个工具都要单独给模型写适配层，接一个换一套；有了 MCP 之后，工具方只需要实现一个 MCP Server，所有支持 MCP 的客户端（Claude、Codex、Cline、Cherry Studio 等）都能直接使用。
MCP 协议本身基于 JSON-RPC 2.0，核心能力有三类：tools（工具）、resources（资源）、prompts（提示词模板）。tools 是“动作”，比如执行一条 SQL、创建一个禅道任务；resources 是“数据”，比如读取某个文件、某张表结构；prompts 是预置的“套路模板”，比如一段固定的代码审查指令。智能体在规划任务时，会通过tools/list发现可用工具，再通过tools/call去调用，整个生命周期是可枚举、可审计的。
最近这段时间，MCP 生态铺开的速度相当惊人。光我视野里就出现了：x64dbg / x32dbg 的调试器 MCP 插件、Unreal Engine 5.8 的 MCP 接入、同花顺 MCP、禅道 MCP、汇川 Inoproshop PLC 的 MCP、蓝湖 MCP、Figma MCP……甚至看到有人把 MCP 功能直接合并进了 ruoyi-vue-pro 这类低代码平台。这说明 MCP 已经不单是“接个数据库跑个查询”的玩具级协议，而是在往逆向工程、游戏引擎、工业控制这些垂直专业领域渗透。做多智能体集群的时候，MCP 是每个成员 Agent 的“外部器官”——没有它，Agent 只能纸上谈兵。
1.2 A2A：让智能体之间学会“打电话”
MCP 解决的是“智能体→工具”的纵向连接，但集群里还缺一根横向的线：智能体→智能体。这就是 A2A（Agent2Agent）协议的位置。A2A 是 2025 年 4 月由 Google 提出并开源、后来移交到 Linux 基金会托管的智能体通信协议，本质是基于 HTTP + JSON-RPC 的一套消息规范。
A2A 的核心设计可以拆成四块：
- AgentCard：每个 Agent 对外发布的一张“名片”，用 JSON 描述自己能干什么、服务地址在哪里、支持哪些能力（流式传输、任务管理、跨语言协作等）。其他 Agent 拿到 AgentCard 就知道该怎么和它打交道。
- Task（任务）：Agent 之间的交互一律建模为任务，任务有明确的生命周期状态机：
submitted → working → input-required → completed / cancelled / failed。 - Message（消息）：任务过程通过不断交换消息来推进，消息带 role（用户/智能体）和内容片段。
- Artifact（工件）：Agent 执行任务的产出物，可以是文档、代码片段、结构化 JSON，甚至是文件下载地址。
A2A 最大的价值在于“互通”。它不规定 Agent 内部用什么框架、什么模型，只要对外暴露一个符合协议的端点，就能被其他 Agent 发现和调用。热词里能看到 Spring A2A 的实现、C++ A2A 的实现，还有人专门问“如何把 Agent 暴露成 A2A AgentCard”——这正好说明这个协议不绑定语言和技术栈，任何一个正常的 HTTP 服务都能接入。
1.3 Skills：把零散能力打包成可交付的“技能包”
如果说 MCP 是接口，那么 Skills 更像是“岗位说明书 + 操作手册”。一个 Skill 本质上是一个带元数据的能力包：目录里放一个SKILL.md（包含技能名称、描述、使用说明、示例），再附上若干脚本、模板、参考文档。Agent 载入这个包之后，看到SKILL.md就知道这个技能是干什么的、在什么场景下用、按什么步骤执行。
我最早接触 Skills 是从 Claude Agent Skills 开始的，后来发现 Codex 那边也有了成体系的 skills 机制。热词里能看到大家在找“前端开发 skills”“分镜 skills”“论文写作 skills”，还有人专门做 Skills 下载平台、Skills 测试工具。这说明 Skills 正在形成一套和 App Store 类似的生态：能力被人为打包、分发、复用。
Skills 和 MCP 的区别值得多说一句。MCP 更偏“连接现成的外部系统”，比如连数据库、连设计工具、连项目管理平台；Skills 更偏“教会 Agent 做一件特定的事”，比如生成符合公司规范的 SVG 图标、用指定的目录结构写接口文档、按某种编码规范审查代码。在实践中两者经常配合使用：Skill 定义“怎么做”，MCP 提供“用什么工具做”。
1.4 DeepAgents：集群里的每个节点都要“想得深、干得远”
DeepAgents 不是一个具体的协议，而是一种设计取向。“深度”体现在两个层面：第一，单个 Agent 具备多步规划、自我反思、拆解执行的能力，而不是只做一次对话式推理；第二，整个系统通过多个深度智能体分工协作，把一个大任务拆成若干可独立完成的子任务，再汇总成最终成果。
为什么一定要集群化？我的体会有三点：
- 上下文隔离：单个 Agent 的上下文窗口再大，塞进“需求分析 + 建表 + 写接口 + 写前端 + 测试”全套任务之后，信息密度和准确率都会明显下降。拆成多个 Agent，每个只关心自己的子任务，上下文干净得多。
- 能力专精：让一个 Agent 既精通 SQL 又精通 React 还精通测试设计，配置成本极高。拆开后，每个 Agent 挂不同的 MCP 工具和 Skills，各干各擅长的。
- 并行与容错：多个 Agent 并行处理，整体链路更短，单个成员失败不影响全局，编排层可以重试或换人。
一句话总结四者关系：DeepAgents 是大脑的设计哲学，MCP 是伸向外部世界的“手”，A2A 是成员之间沟通的“嘴”，Skills 是每个人身上的“技能包”。集群要跑起来，这四样缺一不可。
2. 环境搭建：先搭一个可以直接抄作业的最小底座
2.1 本地 MCP Server 的搭建与注册
多智能体集群里，每个成员 Agent 都要挂载自己的 MCP 工具。实际开发中 95% 的场景用本地 stdio 模式就够了：客户端启动子进程，通过标准输入输出与 MCP Server 通信。远程场景（多机部署、云端 Agent）才需要 HTTP 或 SSE 模式。
以两个最常用的服务器为例，配置文件长这样（Claude Desktop 的claude_desktop_config.json或 Codex 的配置区通用结构）：
{ "mcpServers": { "postgres": { "command": "npx", "args": ["-y", "@henkey/postgres-mcp-server"], "env": { "DATABASE_URL": "postgresql://postgres:devpass@localhost:5432/myapp" } }, "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/var/workdir"] } } }这里有三个非常实际的坑，新手几乎都会踩：
第一，npx 首次运行会弹 “Ok to proceed?”。交互式确认在你手动敲命令时没问题，但放在 MCP 配置里由客户端拉起时，进程会卡住。解决办法是命令里带-y，也就是上面示例的做法。
第二，环境变量不要硬编码密码。env字段支持从系统环境读取，建议把敏感信息放到.env里，配置时用${DATABASE_URL}这类引用，避免把账号密码写进 JSON 后不小心提交到仓库。
第三，多 server 之间注意工具名冲突。比如 postgres 和 filesystem 可能都暴露了list、read这类通用名。我在实际集群里遇到过 Agent 拿错工具的情况，排查了半天。解决方案是启用客户端工具名前缀机制，或者给每个 server 只开放最小工具集。
装好之后可以手动验证一下。以 filesystem server 为例，直接跑：
npx -y @modelcontextprotocol/server-filesystem /var/workdir看到 JSON-RPC 启动日志就说明资源加载成功。客户端里通常可以在“MCP 服务器管理”页面点刷新，然后发一句话让它列一下tools/list，确认工具真正被 Agent 感知到了。
2.2 Skills 的目录结构、安装与调试
Skills 的目录结构非常轻，核心就是一个文件夹 + 一个SKILL.md：
svg-gen/ ├── SKILL.md └── scripts/ ├── svg_generator.py └── templates/ └── chart.tplSKILL.md的开头是 YAML 元数据，这是 Agent 判断“该不该用这个技能”的依据：
--- name: svg-gen description: 根据文字描述生成 SVG 矢量图，支持常见图表、插画、图标。 --- ## 使用场景 当你需要根据自然语言生成矢量图时使用。 ## 调用方式 1. 运行 `python scripts/svg_generator.py --desc "描述文本"` 2. 输出文件保存到当前工作目录的 `output/` 下 ## 示例 输入："生成一个展示季度销售额的柱状图" 输出：`output/sales_q3.svg`安装方式取决于客户端。Claude 的官方市场可以直接浏览安装，也支持把 GitHub 仓库或本地目录拖进 Skills 目录（全局目录是~/.claude/skills，项目级目录是<项目>/.claude/skills）；Codex 那边类似，热词里也能看到大家在找“codex好用的skills”和“codex写论文的skills”。安装之后同样需要重启会话，Agent 才会重新扫描技能列表。
调试 Skills 我有一个固定套路：先看有没有被加载，再看能不能跑通。加载检查可以直接问 Agent：“你有哪些可用技能？”，如果列表里有 svg-gen 就说明元数据解析成功了；如果列表里没有，按顺序排查：目录名是不是小写连字符格式（大写字母会导致不识别）、SKILL.md是否放在一级目录、YAML 里的name是否和目录名一致。跑通检查就用一个最小示例，比如让它按模板生成一个 200×100 的红色方块 SVG，能用再上复杂场景。
2.3 把 Agent 暴露成 A2A 服务端
热词里有一条“如何把 agent 暴露出 a2a agentcard”，这是我被问过最多的问题。其实流程很标准：写一个 HTTP 服务 → 暴露 AgentCard → 实现 message/send 等 JSON-RPC 方法 → 处理任务生命周期。
最小可用的 AgentCard 大概是这样的：
{ "protocolVersion": "0.2.1", "name": "code-reviewer", "description": "代码审查智能体，负责检查 MR 中的潜在问题", "url": "http://localhost:9300", "capabilities": { "streaming": true, "taskManagement": true }, "skills": [ { "id": "code-reader", "name": "代码阅读" } ] }按照 A2A 的约定，AgentCard 要放在服务根路径/.well-known/agent-card.json或者/a2a路径下，让其他 Agent 能通过 HTTP 直接拉取。后端实现可以用 Python FastAPI，也可以用 Node 的 Express，甚至用热词里提到的 Spring A2A 或 C++ 实现。
一个message/send的请求长这样：
{ "jsonrpc": "2.0", "id": "task-001", "method": "message/send", "params": { "message": { "role": "user", "parts": [ { "text": "请审查 MR #42 的代码" } ] } } }Agent 收到后要做两件事：一是立即返回任务已受理的状态（submitted），二是异步或同步地执行任务并更新状态。如果任务是同步完成的，可以直接在响应里返回completed和工件列表；如果任务会跑很久，客户端会通过task/get轮询，或者靠流式消息推送进度。我第一次实现时踩了一个坑：Agent 在任务没有完成时就响应了最终结果，导致调用方拿到的 task 状态是working却有工件，两端状态对不上。后来统一成“先提交任务 ID，完成后再回填状态”。
3. 集群架构设计：分工、通信与状态一致性
3.1 三种协作模式，我实测下来哪种最稳
多智能体集群的协作模式，大体可以分成三类：
编排者-执行者模式（Orchestrator-Workers）：中央编排者负责拆任务、派活、收结果，执行者只埋头干活。优点是流程可控、追踪方便、某个成员挂掉可以快速重试；缺点是编排者本身可能成为瓶颈，而且单点故障会影响全局。实测下来，这是业务开发场景最稳的模式——需求拆解、开发、测试这种任务边界清晰的场景，中央编排不会出错。
管道式模式（Pipeline）：需求→设计→开发→测试，像流水线一样一环扣一环。适合输入输出非常稳定、基本不做回溯的任务流。缺点是一旦前一环质量不达标，后面所有环节跟着返工，而且没有全局视角难以调整。
自治式模式（Mesh）：Agent 之间完全去中心化，谁需要谁就直接通过 A2A 调用谁。这种模式最灵活，但状态管理和责任追踪会非常痛苦。我目前只在探索型任务（比如让几个 Agent 自由头脑风暴方案）里用，生产型开发任务不敢这么搞。
说到底，选型逻辑不是“哪个更先进”，而是“你能为多大的失控风险买单”。我个人的推荐是：第一版先无脑用编排者-执行者模式跑通，后面有需要再局部引入流水线。
3.2 任务编排与上下文传递
集群里的任务编排，核心就一件事：管理好任务之间的依赖关系。一个开发任务的 DAG（依赖图）很简单：建表 → 写接口 → 写页面 → 测试，后面的任务依赖前面的输出。编排层要为每个子任务生成唯一的task_id，记录它依赖哪些前置任务、由哪个 Agent 执行、状态是什么。
上下文传递我有三种办法，配合起来用：
- 消息内引用：A2A 消息里直接携带结构化结论文本，适合小体积、必须即时读取的信息，比如“接口契约摘要：POST /api/orders/status，入参 orderId，出参 status/trackList”。
- 共享工作区：挂一个公共目录或 Git 仓库，前置 Agent 把产物写进文件，后置 Agent 通过 filesystem MCP 去读。适合大体积内容，比如完整代码文件、设计稿。
- 结构化工件：Agent 把产出物登记为 artifact，挂在任务状态上，编排层汇总时统一拉取。
用得最多的是“A2A 传摘要 + MCP 共享工作区”组合：Agent 之间不直接丢大文件，只告诉对方“文件写在了/repo/src/api/order.js”，需要的人自己用 filesystem MCP 去读。这样上下文体积小、链路清晰，排查问题也方便。
3.3 状态一致性：别让每个 Agent 各记各的账
多智能体最容易炸的地方不是“能力不够”，而是状态不一致。A 说任务做完了，B 说还没收到；编排层以为能交付了，测试 Agent 拿到的还是旧代码。我的解决思路很朴素：搞一张统一的任务状态表，所有 Agent 和编排层都往这张表上写真值。
具体做法是启动一个轻量的 SQLite（或者直接用 MCP 连 PostgreSQL），建一张tasks表：
CREATE TABLE tasks ( task_id TEXT PRIMARY KEY, agent_name TEXT, parent_id TEXT, status TEXT, input_summary TEXT, output_artifact TEXT, error_message TEXT, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );A2A 任务状态机的每一次跳变（submitted、working、completed、failed）都同步更新到这张表。编排层轮询时只信任这张表，不信 Agent 嘴上的“我完成了”。这样做的好处是幂等：同一个任务重复提交、重复更新，只要以task_id为键，不会有脏数据。
4. 完整实战：订单状态查询功能的全流程协同
4.1 任务设定与角色分配
理论铺垫了这么多，来一个实际能跑的场景。假设产品经理丢过来一个需求：给现有的电商后台增加一个订单状态查询页面，用户输入订单号，能看到订单当前状态、物流节点、最近更新时间。
我把它拆成四个角色：
- orchestrator（编排者）：负责接收需求文本，拆解子任务，派发给下面三个 Agent，汇总产物。
- backend-agent（后端 Agent）：挂 PostgreSQL MCP、接口规范 Skills，负责建表和实现查询接口。
- frontend-agent（前端 Agent）：挂 Figma/蓝湖 MCP、前端开发 Skills，负责按设计稿实现页面。
- qa-agent（测试 Agent）：挂测试用例库 MCP、测试设计 Skills，负责生成用例并执行冒烟测试。
每个 Agent 通过 A2A AgentCard 暴露服务地址，编排者维护一张 agent 路由表。启动集群前，我先确认每个 Agent 的 MCP 工具列表能正常返回，Skills 也都能在“可用技能”里看到。这一步省不得，等集群跑起来再排查就费劲了。
4.2 从需求拆解到前端交付的完整链路
编排者收到需求文本后，用一段固定的拆解提示词生成了四个子任务：
- task-ddl（backend-agent）：“根据订单状态查询需求，设计订单状态与物流节点数据表，通过 PostgreSQL MCP 执行 DDL。”
- task-api（backend-agent，依赖 task-ddl）：“基于已建好的表，开发一个查询接口，返回订单状态、物流节点、最近更新时间。开发完成后把接口契约写到
/repo/docs/api.md。” - task-page（frontend-agent，依赖 task-api）：“读取
/repo/docs/api.md，参考蓝湖 MCP 里的订单详情设计稿，实现订单状态查询页面，页面文件写到/repo/src/pages/OrderQuery.jsx。” - task-test（qa-agent，依赖 task-page）：“根据接口契约和页面实现，生成 5 条核心测试用例，用测试用例库 MCP 登记，并执行一次冒烟测试。”
实际执行时，backend-agent 调用 PostgreSQL MCP 执行建表语句：
CREATE TABLE t_order_status ( order_id VARCHAR(32) PRIMARY KEY, status VARCHAR(20), logistics JSONB, updated_at TIMESTAMP );表建好后继续写接口，然后通过 MCP filesystem 把接口契约写入/repo/docs/api.md。编排者看到 task-ddl 和 task-api 都变成completed，就允许 task-page 启动。
frontend-agent 拿到 A2A 消息里的任务摘要后，先用 filesystem MCP 读取 api.md，再从蓝湖 MCP 拉取设计稿标注。这里热词里曾经有人问“codex 接入 figma mcp 怎么授权”，实际就是 OAuth 授权流程，第一次调用会引导输入访问令牌，之后 token 存在本地配置里。拿到设计信息后，前端 Agent 使用前端 Skills 里预置的项目脚手架模板，生成页面代码并写入共享区。
最后 qa-agent 启动，读取接口契约和页面代码，用测试设计 Skills 生成用例，再通过 MCP 调测试平台登记。整个流程走完，编排者汇总所有任务的 artifact，把最终交付报告写到/repo/DELIVERY.md。
4.3 编排层核心代码骨架
下面是一个简化但可运行的编排层核心思路，值得注意的地方我都加了注释：
import json import time import requests from pathlib import Path AGENTS = { "backend": "http://localhost:9100/a2a", "frontend": "http://localhost:9200/a2a", "qa": "http://localhost:9300/a2a", } TASKS = [ {"id": "task-ddl", "agent": "backend", "depends_on": []}, {"id": "task-api", "agent": "backend", "depends_on": ["task-ddl"]}, {"id": "task-page", "agent": "frontend", "depends_on": ["task-api"]}, {"id": "task-test", "agent": "qa", "depends_on": ["task-page"]}, ] def send_a2a_message(agent_url: str, task_id: str, prompt: str) -> dict: body = { "jsonrpc": "2.0", "id": task_id, "method": "message/send", "params": { "message": { "role": "user", "parts": [{"text": prompt}], } } } resp = requests.post(f"{agent_url}/a2a", json=body, timeout=30) return resp.json() def task_inputs(task_id: str, results: dict) -> str: # 把前置任务的结果摘要拼进提示词 return "\n".join( f"[{dep} 的产出]\n{results[dep].get('artifact_summary', '')}" for dep in next(t["depends_on"] for t in TASKS if t["id"] == task_id) ) def main(): results = {} while not all(t["id"] in results for t in TASKS): for t in TASKS: if t["id"] in results: continue if not all(dep in results for dep in t["depends_on"]): continue prompt = build_prompt(t["id"], task_inputs(t["id"], results)) result = send_a2a_message(AGENTS[t["agent"]], t["id"], prompt) results[t["id"]] = {"status": "submitted", "payload": result} time.sleep(5) # 汇总 artifacts delivery = {tid: r["payload"] for tid, r in results.items()} Path("DELIVERY.md").write_text(json.dumps(delivery, ensure_ascii=False, indent=2)) if __name__ == "__main__": main()真实生产环境里，这段代码至少还要补三件事：轮询任务状态而不是提交完就不管了（task/get 或流式接收进度）、失败重试与熔断（某个 Agent 连续失败就换人）、trace_id 贯穿日志（方便在大模型输出里回溯是哪一步出了问题）。但骨架本身已经覆盖了“拆任务、派任务、管依赖、汇总产物”这几个编排层的核心职责。
5. 常见问题与排查技巧实录
5.1 高频问题速查表
这些是我和身边同事在实际集群使用中碰到过的高频问题，整理成了一张速查表：
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| MCP server 启动后马上退出 | Node 版本过低、npx 首次确认卡住 | 先手动跑一遍命令看报错，配置里加-y |
| Agent 找不到已配置的 MCP 工具 | 配置作用域不对或客户端未重启 | 检查mcpServers配置位置，重启会话后重新扫描 |
| Skills 列表里没有刚装的技能 | 目录名用了大写字母、SKILL.md位置不对 | 目录名改小写连字符，SKILL.md放一级目录 |
| A2A AgentCard 拉取失败 | URL 不可达、/.well-known路径配置错误 | 直接 curl 对应地址，检查返回头是不是application/json |
任务状态永远是working | Agent 忘记更新任务状态 | 要求 Agent 在每个关键节点调用task/update，并设置超时兜底 |
| Agent 之间上下文污染 | 子任务消息携带了过多无关大文本 | 改成共享工作区 + 摘要引用 |
| 两个 Agent 各记各的状态 | 没有统一任务表 | 引入 SQLite / PostgreSQL 任务表，以task_id为唯一键 |
5.2 我踩过几次坑之后固化的四条心得
第一，每个 Agent 的 MCP 工具要少而精，不要全挂载。一开始我给 backend-agent 同时挂了 PostgreSQL、filesystem、禅道、同花顺，结果 Agent 在选择工具时经常出现“开着数据库去查行情”的离谱行为。后来每个 Agent 最多挂 2-3 个和职能强相关的工具，工具选择的准确率直线上升。这和“上下文隔离”是同一个道理——不是能力越多越好，而是干扰越少越好。
第二，消息里一定要带 trace_id。多智能体链路的排查难度指数级高于单 Agent。没有 trace_id，你根本不知道一个失败的接口调用是哪个 Agent 发起的、对应哪条 A2A 消息。我在编排层的每次 A2A 请求里都带上trace_id，统一写进日志，排查时间能省下一大半。
第三，别让 Agent 无限重试。DeepAgents 的“深度”体现在规划能力，但大模型的错误输出是会自我强化的。一个任务失败后让它反复重试，往往越试越偏。我现在的做法是：最多重试两次，第三次直接换一个 Agent 或者切到人工兜底。省 token，也省时间。
第四，先跑两个 Agent 的最小闭环，再上完整集群。我第一次搭集群直接上了四个 Agent，结果整整花了三天排查通信问题。后来学乖了：先让编排者和一个后端 Agent 跑通“建表→写接口”两条消息，确认 A2A、MCP、状态表都没问题，再逐步把前端、测试 Agent 加进来。多智能体系统的复杂度是组合爆炸的，每一层都要在最小可验证单元里先确认稳定。
最后再分享一个小技巧：如果你也在用 A2A 做集群，给每个 Agent 的 AgentCard 里都写清楚“擅长什么、不擅长什么”，并且用skills字段把能力边界暴露出去。这样编排者在拆任务的时候，能直接根据卡片信息做路由，而不是把任务随手丢给一个不匹配的 Agent——这一步做得好，集群的交付质量能提一个档次。
