1. 项目全景与总体思路1.1 为什么一定要做多智能体集群这两年我一直在折腾智能体落地这件事。从最早的单模型套 Prompt到后来教模型用工具、接数据源再到最近半年把 DeepAgents、MCP、A2A、Skills 这四样东西组合成一套完整的多智能体集群架构最大的感受是单个智能体做 Demo 已经不难难的是让一群智能体像一支小队一样协作干活。先说清楚这套东西解决的真实问题。单 Agent 的能力边界非常明显上下文窗口有限、工具调用容易串线、长任务做到一半状态就乱了、改一处逻辑要重新调整个 Prompt。当你面对每周自动产出竞品分析报告这种需要采集、清洗、分析、撰写、质检多个环节的任务时单 Agent 硬扛一定会出现上下文污染——前面抓数据的中间结果把后面的写作空间挤掉模型开始凭空编造结论。多智能体集群的价值就是把一个大任务切成几个小任务每个 Agent 只干自己擅长的事上下文各管各的互不干扰。DeepAgents、MCP、A2A、Skills 这四个词不是四个独立技术的简单叠加它们分别对应智能体体系里的大脑、手脚、语言和记忆。DeepAgents 负责把复杂任务递归拆解、自我反思、反复试错MCP 统一了智能体调用外部工具的接口规范相当于给 Agent 装上了标准化的USB-C 口A2A 解决的是 Agent 与 Agent 之间的通信协议让不同框架、不同厂家的智能体能互相派活Skills 则是把高频场景的能力沉淀成可复用的资产让新 Agent 一上来就拥有特定领域的做事方法。这篇文章适合正在做智能体落地、被多 Agent 协作搞到头大的人。我会从架构设计讲到代码实现再讲到我实际跑流程时踩过的坑最后给出可以直接抄的工程经验。不需要你精通所有框架但最好对 Agent 的基本概念有个底。1.2 方案选型的底层逻辑很多人一上来就问我用 LangChain 还是用自研框架我直接用现成的多 Agent 平台不香吗我的答案是选型首先要看你的瓶颈在哪里。如果你的瓶颈是模型不够聪明换更大的模型比上多 Agent 更划算如果你的瓶颈是任务链路太长、工具太多、需要多人协作式的分工那多智能体集群才有价值。我最终没有选全家桶平台而是用协议 轻量编排的方式自己拼。原因有三第一MCP 生态和 A2A 生态现在都在快速膨胀平台绑定越深将来迁移成本越高第二团队内部有基于 Java 的服务、有 Python 的脚本、有前端工具异构系统需要一个不挑语言的通信标准第三跑业务的人需要的不是一套炫技框架而是能插到现有系统里的可维护方案。MCP 把工具接入标准化A2A 把Agent 互调标准化而我只需要写一个很薄的调度层。这套方案的另一个关键判断是集群里不能只有一种 Agent。我们日常说的 DeepAgents强调的是智能体本身的深度——会拆任务、会反思、会在失败后换一条路。但如果集群里每个 Agent 都有这么重的思考能力成本会爆炸。所以我会把 Agent 分成重脑和轻手两类重脑负责规划、决策、质检轻手负责执行单点任务。具体怎么划分后面架构部分细说。2. 四个核心组件逐个拆解2.1 MCP 协议给智能体装上标准的工具接口MCPModel Context Protocol本质上是把模型怎么连接工具和数据源这件事定成了一套公开规范。在这之前每接一个工具就要写一段专用代码模型厂商一个接口、插件平台一个接口、内部服务又一个接口Agent 的代码里全是 if-else 分支。MCP 出现以后工具提供方只需要实现一个 MCP Server暴露三类能力Tools可调用的函数、Resources可读取的数据、Prompts模板化提示词现在用得少了任何 MCP Client 都能直接对接。我强烈建议你用 FastMCP 写服务端Python 生态里它是我实测最顺手的封装。一个简单的 MCP Server 长这样from fastmcp import FastMCP mcp FastMCP(report-tools) mcp.tool() def fetch_competitor_news(company: str, days: int 7) - list[dict]: 抓取指定竞品最近 N 天的公开动态 # 内部调新闻接口、RSS 或爬虫 return [{title: ...} for _ in range(3)] mcp.resource(db://projects/{project_id}) def get_project_info(project_id: str) - dict: 读取项目基础信息 return {id: project_id, name: 竞品监测项目} if __name__ __main__: mcp.run(transportstdio)选 stdio 还是 HTTP 传输我建议本地工具用 stdio简单可靠要跨机器、跨服务调用就走 HTTP/SSE。MCP 最容易被忽视的价值是它的描述即路由机制——模型会读每个 tool 的名字和 docstring 来决定调用哪个所以给工具起名、写注释千万别偷懒这直接决定模型用工具的准确率。我见过很多团队接 MCP 接得痛苦不是协议难而是对自己的工具域没做梳理。一个稳妥的做法是先把团队内部的系统盘点一遍数据库、项目管理平台、监控系统、文档库、消息机器人然后每个系统单独出一个 MCP Server而不是把所有接口塞进一个大杂烩服务。这样工具列表清晰模型选工具的准确率会高很多。2.2 Skills把高频能力沉淀成可复用资产Skills 解决的是Agent 每次从零开始摸索的问题。模型再聪明如果每次写作、写代码、处理数据都要现场临场发挥质量和效率都不稳定。Skill 本质上是一个带元数据的可执行知识包一个 SKILL.md 描述文件加上若干脚本、模板、示例让 Agent 在遇到对应任务时自动加载特定的方法论和工具链。一个标准的 Skills 目录结构大致是这样skills/ └── weekly-report/ ├── SKILL.md ├── templates/ │ └── report_template.md └── scripts/ └── summarize_progress.pySKILL.md 是入口YAML 头信息里写 name 和 description正文写这个 Skill 的使用场景、工作流程、注意事项。模型读到 description 之后会判断这个任务该不该用这个技能命中之后才会加载完整的说明和脚本。所以 description 要写得具体比如生成团队周报汇总各 Agent 的任务进度、阻塞项和明日计划而不是笼统的周报技能。我踩过的最明显的一个坑一开始把 Skill 的 SKILL.md 写成了长长的操作手册事无巨细全塞进去结果模型加载后上下文被占掉一大截反而没空间装真实任务数据。后来我总结出经验——SKILL.md 里只写什么时候用、关键步骤、禁忌把具体模板和代码放外部文件模型按需读取。这就像给新同事一份岗位说明书就够了不需要把公司全部规章制度都塞给他。2.3 A2A 协议智能体之间怎么对话MCP 解决的是 Agent 与工具之间的连接A2AAgent2Agent解决的是 Agent 与 Agent 之间的连接。你可以把 MCP 理解成人和螺丝刀之间的关系而 A2A 是人和人之间的协作关系。A2A 协议的核心是一份 Agent Card智能体名片每个 Agent 用 JSON 描述自己是谁、能干什么、支持哪些能力其他 Agent 通过 HTTP 发现这张名片之后就能给它派任务。一个典型的 Agent Card 长这样{ name: data-collector, description: 负责从 MCP 服务采集竞品数据并做初步清洗, url: http://localhost:4123/, capabilities: { streaming: true, pushNotifications: false }, skills: [data-collect, format-normalize] }Agent 之间通过 JSON-RPC 2.0 消息互调核心方法包括 tasks/send派发任务、tasks/get查任务状态、message/send发消息、message/stream流式响应。一次最简单的派活请求长这样curl -X POST http://localhost:4123/ \ -H Content-Type: application/json \ -d { jsonrpc: 2.0, id: 1, method: tasks/send, params: { id: task-001, message: { role: user, parts: [{text: 请采集最近 7 天三家竞品的发布动态}] } } }A2A 和 MCP 的分工容易被搞混我自己的记忆法是MCP 是往口袋里装工具A2A 是互相递名片、派活。实际项目中两个协议经常配合使用——主 Agent 通过 A2A 把采集任务派给采集 Agent采集 Agent 内部再用 MCP 去调用具体的数据源工具。协议没有重叠协议之间是互补关系。2.4 DeepAgents集群里的深度思考大脑DeepAgents 这套东西我说的既是 LangChain 开源的 deepagents 库所代表的思路也是我更广义的工程理念。它的核心特征是递归任务分解、工具调用前先想清楚、执行后自我反思。传统的 ReAct 模式是想一步走一步、走一步再看一步DeepAgents 则会在行动之前先拆一个任务树对每个叶子节点做可行性判断执行完一轮再回调反思这次结果符合预期吗哪里失败了有没有更好的路径在实现层面我不会让所有 Agent 都具备同样的深度而是设立一个编排型 Agent专门做深度思考其他 Agent 只做轻量执行。编排 Agent 维护一份任务清单类似公司的项目经理负责拆解需求、记录每步状态、处理异常。执行 Agent 收到任务后就地干活把结果回传。这里面最关键的设计是反思要落到行动上。很多 Agent 反思了半天下一步还是按老路子走。我的做法是让编排 Agent 的反思输出强制带上下一步具体动作和备选路径比如计划 C 失败改用计划 B并且把数据源从新闻接口切换到数据库快照。没有具体动作的反思都是空转。3. 多智能体集群架构设计3.1 分层设计路由、编排、执行、记忆我最终落地的集群架构可以分成四层接入层、编排层、执行层、记忆与工具层。接入层负责接收外部请求比如定时任务触发、Webhook 事件、用户在对话界面的输入编排层是集群的大脑也就是上一节说的 DeepAgents 编排器执行层是真正干活的一群 Agent各自通过 MCP 访问工具、通过 Skills 获得技能记忆与工具层则包含向量数据库、任务状态库、MCP Server 集群和 Skills 仓库。这种分层最直接的好处是可以独立伸缩。业务量上来了执行层的采集 Agent 可以横向多开几个实例编排逻辑变了只需要改编排器不用动执行 Agent甚至某个执行 Agent 完全换掉也不影响对外接口因为层与层之间只有协议没有硬编码依赖。说个具体的取舍经验执行层 Agent 到底要不要也接 A2A我的做法是执行层内部尽量不互相直接调用通信全部走编排层转发。原因很简单Agent 之间直接互调会形成网状依赖出问题的时候排查链路能把你逼疯。星型拓扑虽然多一跳但每个 Agent 只管跟编排器对话任务状态一目了然日志也好追踪。3.2 编排模式中心化调度加策略兜底多智能体编排有三种常见模式完全中心化、完全去中心化、中心化加本地自治。我选的是第三种。完全中心化的问题在于编排器成为单点瓶颈而且所有消息都过它上下文会很重完全去中心化的问题是全局状态不可控没法保证任务不重复执行。折中方案是编排器负责任务分配和结果汇总但执行 Agent 在拿到明确子任务后有权在自己的上下文里自由发挥使用自己的 Skills 和 MCP 工具不需要每一步都请示编排器。这套模式跑下来非常稳。聚合阶段的失败处理我做了三档第一档执行 Agent 返回结果后编排器做一次格式校验不合格直接打回重跑第二档重跑仍失败就换一个执行 Agent比如抓取数据换成分析 Agent 去读数据库快照第三档还不行就降级把任务标记为人工介入生成一份带上下文的交接单。三档兜底下来系统在真实业务中基本不会卡死。3.3 状态管理与上下文治理多智能体集群最容易翻车的地方不是模型不够聪明而是状态管理。每个 Agent 都有自己的上下文多个 Agent 之间怎么共享进度任务做到一半进程重启了怎么办Agent A 的输出格式变了Agent B 解析失败怎么办我现在的做法是引入一个独立的任务状态库用一张任务表记录每个子任务的 id、父任务 id、所属 Agent、状态、输入摘要、输出摘要、重试次数和错误信息。Agent 之间不直接传大数据只传任务 id 和摘要。真正的完整数据放在共享存储里需要的时候通过 MCP 的资源接口按需读取。这样有两个好处一是每个 Agent 的上下文只装载自己当前这一步需要的少量信息不会被上游的海量中间结果撑爆二是任务状态可以随时恢复进程重启后从状态库拉回进度继续跑。上下文治理还有一条铁律一个 Agent 的上下文里不要同时存在历史任务的全部中间结果和当前任务。我见过太多人把上一轮的结果全部塞给下一轮 Agent结果就是模型被旧信息干扰新任务的判断出现偏差。正确的做法是每轮只传摘要 必要的数据引用完整数据让 Agent 自己去读。4. 全流程实操跑通一个竞品分析多智能体流水线4.1 场景定义与 Agent 角色划分这部分我用一个完整的实操案例来演示搭建一条竞品情报周报自动生成的流水线。为什么选这个场景因为它天然需要多 Agent 协作链路长、环节多、中间结果格式多样是检验集群架构的好样本。我把流水线分成五个角色Agent 角色职责依赖的能力planner编排、拆解任务、汇总、反思DeepAgents 深度推理collector采集竞品新闻、舆情、版本发布信息MCP 调用新闻/网页/数据库analyst清洗数据、算环比、提取趋势Skills 数据分析脚本writer撰写周报正文Skills 写作模板reviewer事实核查、格式校验、完整性检查MCP 检索验证 校验规则每个角色都是独立的 Agent 进程通过 A2A 和编排器通信通过 MCP 访问各自需要的工具。collector 用到一个内部的新闻聚合 MCP Serveranalyst 用到一个PostgreSQL 查询 MCP Serverreviewer 用到一个检索验证 MCP Server做到工具职责互相隔离。4.2 环境准备与基础设施搭建依赖清单方面我用 Python 3.11 作为主力语言装 fastmcp 写 MCP ServerA2A 通信用一个小型 HTTP 服务FastAPI 起服务实现 Agent Card 接口和 tasks/send 处理编排器用 deepagents 的思路自己写了一个薄层Skills 仓库就是一个本地 Git 目录按文件夹组织。先把目录结构建好multi-agent-cluster/ ├── orchestrator/ │ ├── planner.py │ └── task_store.py ├── agents/ │ ├── collector/ │ ├── analyst/ │ ├── writer/ │ └── reviewer/ ├── mcp-servers/ │ ├── news-server/ │ ├── db-server/ │ └── verify-server/ ├── skills/ │ ├── analysis-skill/ │ └── writing-skill/ └── shared/ └── artifacts/每个 Agent 目录里我固定放三个文件agent.py主体逻辑、agent_card.jsonA2A 名片、Dockerfile可选用于隔离部署。这套结构跑了一个多月新增角色基本就是复制模板改配置成本很低。4.3 编写第一个 Skill数据分析技能的完整过程以 analyst 的数据分析 Skill 为例我在 skills/analysis-skill 下面建了 SKILL.md 和 scripts/analyze_trend.py。SKILL.md 的写法我反复迭代过最终稳定的版本长这样--- name: analysis-skill description: 用于竞品数据的清洗、去重、环比计算与趋势提取。当输入为多来源采集的原始记录时优先使用本技能。 --- # 分析流程 1. 按来源字段去重保留时间最新且信息最全的一条。 2. 按周汇总竞品动态数量、类型分布、提及关键词。 3. 与上一周期数据做环比异常波动标记。 # 输出格式 返回 JSON包含 summary、trends、anomalies 三个字段。 # 禁忌 - 不要对缺失数据做无依据的填充。 - 不要修改原始采集记录只输出分析结果。scripts/analyze_trend.py 里就是具体的清洗逻辑模型在加载 SKILL.md 后会按需执行脚本。这里有个细节Skill 脚本不应该包含任何模型无法执行的外部依赖安装逻辑如果脚本依赖 pandas要么在镜像里提前装好要么由 Skill 的 setup 脚本处理。我实测中发现让 Agent现场 pip install效率极低且容易失败提前把依赖固化进运行环境才是正解。写作 Skill 类似SKILL.md 里写清周报结构摘要、竞品动态、数据趋势、风险提示、后续动作模板放在 templates/report_template.md模型在写正文时加载模板填充。这套方式比纯 Prompt 稳定得多因为模板锚定了输出结构模型的天马行空被限制在固定的筐里。4.4 通过 MCP 接入数据源与工具这一步把数据源接进来。我用 fastmcp 写了一个内部新闻聚合服务暴露一个 search_news 工具。这里要特别强调工具描述的重要性在 MCP 里模型就是靠工具名和描述来判断调用时机的描述写得模糊模型就会乱点。我一开始写的是搜索新闻结果模型把很多跟竞品无关的请求也发过来。后来改成按公司名检索该公司近 N 天的重要动态返回标题、正文摘要、来源和发布时间准确率立刻上来了。MCP Server 启动之后要让执行 Agent 能连上它。我的做法是在 Agent 的配置里声明它可用的 MCP Server 列表Agent 启动时建立连接并拉取工具清单。collector 的配置片段类似这样MCP_SERVERS [ {name: news-server, transport: stdio, command: python mcp-servers/news-server/server.py}, {name: db-server, transport: http, url: http://localhost:8300/mcp}, ]stdio 服务和 HTTP 服务我都有用。本地脚本型工具走 stdio跨机器共享的数据库查询走 HTTP。有一点容易踩坑HTTP 传输的 MCP Server 要用 SSE 方式推送响应如果你自己封装服务端一定要处理好连接保持否则 Agent 那边会频繁断连。4.5 用 A2A 把五个 Agent 串起来现在到了最关键的一步用 A2A 协议把五个 Agent 串成流水线。每个 Agent 启动时注册自己的 Agent Card编排器启动时拉取所有 Agent Card构建一张能力路由表。planner 根据任务类型决定派给哪个 Agent比如采集派给 collector分析派给 analyst写报告派给 writer核查派给 reviewer。planner 的核心调度逻辑我简化成一个状态机收到初始任务后拆解为子任务每个子任务按依赖顺序入队执行 Agent 完成后回调更新任务状态库所有叶子任务完成后汇总进入反思阶段检查是否符合质量门槛不通过则局部重跑。伪代码如下def run_pipeline(initial_task: str): subtasks planner.decompose(initial_task) for st in topo_sort(subtasks): agent route(st.agent_type) result agent.execute(st) task_store.update(st.id, result) if not planner.validate(st, result): retry_or_fallback(st) final planner.synthesize(subtasks) reviewed reviewer.execute(final) return reviewedA2A 请求的坑主要出在流式响应上。我的 reviewer 需要边读 writer 的产出边做校验所以 writer 开启 streaming 能力用 message/stream 方法一路把增量文本推给 reviewer。如果你用的是同步的 tasks/send那就要等 writer 全部写完才能开始校验长报告的体感会差很多。另外Agent Card 的 url 字段必须指向一个稳定可达的 HTTP 地址我第一次部署时把 url 写成了 localhost结果编排器在另一台机器上怎么都发现不了这个 Agent。跑通之后我给流水线加了两个增强功能一是把周报产出固化成另一个 Skill方便将来复用二是在编排器里记录每次任务的耗时、成功率、失败原因每周审视一遍把频繁失败的工具调用优化掉。这套增强机制带来的收益比我换更强的模型还要明显。5. 常见问题与排查技巧实录5.1 高频问题速查症状可能原因处理办法Agent 找不到 MCP 工具MCP Server 没启动或传输方式不匹配先手动启动服务用 mcp-cli 测试工具列表能否拉取工具调用报参数格式错误模型的参数猜测与工具 schema 不一致在工具描述中给每个参数加示例值A2A 派发任务无响应Agent Card 的 url 不可达或未注册用 curl 访问 Agent Card 地址确认返回 JSON某 Agent 上下文超限上游中间结果全量塞入改成传任务 id 和摘要完整数据走共享存储同一任务重复执行缺任务去重机制在任务状态库加唯一键与幂等标志反思后仍重复失败动作反思输出没有落到下一步具体动作要求反思结果必须含下一步动作字段MCP 工具调用失败是我遇到的最高频问题。一个典型的场景是模型认为某个参数应该传字符串但工具定义要求整数运行时直接 500。解决办法是让工具的输入 schema 更宽松能自动做类型转换或者让错误信息返回给模型时带上明确的修正提示模型看到参数 age 需要 int你传了 str之后通常会自动修正重试。5.2 我踩过的三个印象最深的坑第一个坑是过度依赖让 Agent 自己想办法。一开始我把采集和分析两个 Agent 都设计得很有主见结果它们经常擅自修改任务目标collector 觉得数据不够就自己去猜数据analyst 觉得格式不统一就直接改写上游记录。后来我在每个执行 Agent 的约束里写明只做被分配的任务不得修改任务定义和上游数据并在 task_store 里加了任务定义哈希校验这个问题立刻消失。第二个坑是技能加载失败但系统没有任何报错。某个 Skill 的 YAML 头信息缩进写错了模型读不到 description于是这个技能永远没有被触发而日志里一切正常。排查成本极高。后来我写了一个技能自检脚本定期扫描所有 SKILL.md 的 YAML 合法性并在编排器里统计每个 Skill 的命中次数命中为 0 就告警。第三个坑是 A2A 流式响应的超时配置。reviewer 校验长报告时writer 的流式输出超过默认 60 秒超时中间连接被断开导致校验只做了一半。把 HTTP 客户端的读超时调到 10 分钟并让 writer 每 15 秒发一次心跳包问题解决。这些小参数在生产环境里真的会咬人上线前一定要压一遍长任务。5.3 调试工具与排查方法论我调试这套集群的方法论可以浓缩成一句话先看协议再看上下文最后才怀疑模型。很多时候问题不是模型笨而是 MCP 工具没注册、A2A 地址写错、Skills 描述不匹配之类的基础问题。我先用 curl 直接测 Agent Card 接口再用 mcp-cli 独立测试工具调用这两层过了才轮到模型推理。日志方面我会给每个 Agent 打结构化日志字段包括任务 id、输入摘要、输出摘要、耗时、调用工具列表、Token 消耗。排查问题时先按任务 id 把整条链路的日志拉出来一眼就能看出卡在哪个环节。Token 消耗这个字段特别有用它能在上下文膨胀导致变笨之前就报警。6. 上线运行后的几点体感经验6.1 什么时候别用多智能体我得说句泼冷水的话不是所有场景都适合多智能体集群。我自己总结的判断标准是——如果这个任务能在一次对话、十几步工具调用内完成或者失败后人工重试成本很低那就不要上多 Agent。集群架构的收益在于长链路、多环节、可以并行/分治、且中间产物可以被复用的场景。单 Agent 时代周报任务一次要烧掉几万 Token 还经常产出不完整切到集群之后每个 Agent 上下文都很干净总 Token 反而更低。成本账也要算清楚。多 Agent 不是免费的每个 Agent 都要维护、要有独立的服务生命周期、要处理网络异常最直接的成本是进程和部署复杂度。我的经验是至少要有 3 个以上真正有分工价值的任务环节才值得引入集群架构否则就是给自己找事。6.2 集群后续可扩展的方向跑稳之后我接下来计划做三件事。第一是把 MCP 工具接入范围扩大到项目管理平台和数据库运维让 planner 能直接查询需求状态和线上日志把告警联动起来。第二是给 Skills 建一个内部共享仓库组里谁开发了新技能就提交上去其他集群拉取即用相当于给智能体团队建了一套共享手册。第三是给集群加一层可观测面板把任务链路、Token 消耗、技能命中率都可视化出来这样运营同学不用看日志也能判断集群健康状况。6.3 最后分享一个小技巧最后分享一个我自己觉得最值钱的小技巧给每个 Agent 的约束文件里加一条如果你发现自己陷入了重复失败停下手头动作把当前状态和已知信息整理成一段可读摘要交还给编排器。这一条看似简单实际上解决了多智能体系统里最常见的死循环问题。模型陷入死循环时让它带着总结回来的成本远远低于让它继续蒙头试。所有编排系统都应该设计一条主动认输的路径这不是投降是工程理性。这套从 DeepAgents 到 MCP、A2A、Skills 的完整链路我前后迭代了差不多两个多月推翻过三次架构最终这个版本才稳定下来。每次回看都觉得最大的收获不是某个具体技术而是理解了协议比框架重要边界比能力重要这句话。给智能体划清楚职责边界让它们通过标准协议协作再用 Skills 把经验沉淀下来这套方法论放到任何业务里都适用。