这两年做 AI Agent 开发最明显的一个感受是单 Agent 的 demo 已经没什么可聊的了真正的战场在“一群 Agent 怎么协作”。我最近完整走了一遍 DeepAgents、MCP、A2A、Skills 这条技术路线一句话总结就是——MCP 解决 Agent 怎么用工具A2A 解决 Agent 怎么找同行Skills 解决 Agent 怎么持续涨本事DeepAgents 则是把这些串起来的一套工程范式。这篇文章就把我实际搭建一个可编排、可互通、可扩展的多智能体集群的全过程拆开讲清楚包括协议选型、代码怎么写、踩过的坑以及一些在真实业务里才会暴露的问题。适合已经被单 Agent 折磨过、准备往上走一层的开发者也适合正在选型企业级 Agent 平台的架构师。1. 先把概念理清MCP、A2A、Skills 到底各自解决什么问题很多人一上来就陷入协议细节结果越学越乱。我建议先站在“整个系统缺什么”的角度去看这三样东西一句话就能记住MCP 是 Agent 和工具之间的协议A2A 是 Agent 和 Agent 之间的协议Skills 是给 Agent 补充“怎么做”的说明书。三者不是替代关系而是分层协作。1.1 MCP 的本质把工具调用从“硬编码”变成“插拔式”MCPModel Context Protocol最早是 Anthropic 提出的现在已经是 Agent 工具接入的事实标准。它的核心思路是把“工具”抽象成一种可发现、可调用、可鉴权的服务。过去我们想让 Agent 查数据库得在代码里写死一个函数调用Agent 换个模型或者换个场景这套工具就废了。有了 MCP工具就变成一个独立的 Server 进程Agent 通过 MCP Client 与它通信工具的能力描述、入参出参格式都由 Server 自己声明Agent 侧只需要动态发现。这里要特别注意一个老生常谈的概念混淆MCP 是软件协议不是硬件协议。它定义的是“AI 模型与外部工具/数据源之间如何交换上下文和调用指令”的规范跟 USB、PCIe 这类硬件总线协议不是一个层面的东西。你可以把它理解成“AI 世界的 USB 接口”只要双方都实现这个接口插上就能用不用关心对方内部怎么实现的。实际开发中你会发现MCP 的价值不只是“少写胶水代码”更重要的是它把工具能力变成了可运营的基础设施。比如权限控制、版本管理、监控审计都能在 MCP Server 这一层统一做掉而不是散落在各个 Agent 的 prompt 里。这也是为什么后端框架社区比如 RuoYi-Vue-Pro 这类项目开始有人合并 MCP 功能——本质上是把 MCP Server 的管理能力做成后台的一个菜单让 Agent 的工具接入像配置数据源一样简单。1.2 A2A 的本质Agent 与 Agent 的“外交语言”MCP 解决的是 Agent 和工具的关系但业务稍微复杂一点你就发现 Agent 和 Agent 之间也得对话。A2AAgent-to-Agent协议就是在干这件事比较有代表性的实现是 Google 提出的 A2A 规范以及 Spring 社区里的 Spring A2A 这类封装。A2A 解决的核心问题是“寻址”和“任务委托”。一个写作 Agent 需要数据分析结果它不需要自己会调 SQL只需要向数据分析 Agent 发一个请求对方接单、干活、回传结果。这个过程涉及服务发现、技能描述、任务状态跟踪、结果返回A2A 就是把这套交互标准化。从工程实现上看A2A 的 Agent Card 类似“名片”声明了我叫什么、能做什么、用什么协议通信其他 Agent 看到名片就知道该怎么找我、该不该把活交给我。这里补充一句经验之谈A2A 和编排引擎后面会讲 Harness、编排层不要混为一谈。A2A 是“Agent 之间对话的语法规范”编排是“谁先干、谁后干、并发还是串行、出错了怎么办”的流程控制。没有 A2A编排只能靠硬编码的 API 调用没有编排A2A 只是一堆 Agent 在互相喊话却没人管节奏。两者配合才是完整的集群。1.3 Skills让 Agent 从“看懂”到“会做”Skills 这个概念在 Claude Code、Codex 里已经大量出现社区里也流行叫 Agent Skills 或 superpower skills。它和 MCP 最大的区别在于MCP 提供的是“工具”Skills 提供的是“方法论”。举个例子你让 Agent 写一篇技术博客MCP 可以提供搜索工具、网页抓取工具、Markdown 渲染工具但 Agent 不一定知道“一篇好博客应该怎么组织结构、语气该是什么样、怎么放示例代码”。Skills 就是一段结构化的指导文件通常是 SKILL.md告诉 Agent写博客前要做主题调研开头 100 字要融入关键词正文要有实操步骤和避坑经验代码要标注语言类型。你把这段“经验包”丢给 Agent它的输出质量立刻不一样。我自己的经验是Skills 的价值长期被低估了。很多人专注在写 MCP Server却忽略了给 Agent 沉淀“岗位手册”。其实在企业里复制一个资深 AgentSkills 比工具更值钱——工具可以买、可以开源方法论才是一个团队真正积累下来的东西。2. 架构设计一个可编排、可互通、可扩展的 Agent 集群长什么样概念理清之后关键问题就是怎么把这几个东西组装起来。我按照标题里“可编排、可互通、可扩展”三个目标把集群拆成四层底座、互通、能力、指挥。2.1 四层架构底座层、互通层、能力层、指挥层第一层是底座层也就是跑 Agent 的计算环境。现在常见的选择是 Docker 容器比如有人问过“docker 容器里的 ros2 humble 和 micro-ros agent 怎么配置”原理上是相通的给每个 Agent 一个干净的运行时依赖隔离、环境可复现、资源可限制。我的建议是不要省这一步哪怕一开始只有一个 Agent 也要容器化不然后面加 Agent 的时候环境冲突会让人崩溃。第二层是互通层负责 Agent 与工具、Agent 与 Agent 之间的通信。工具侧走 MCPAgent 之间走 A2A。这一层是所有协议的核心战场后面第 3 章我会详细讲实现细节。第三层是能力层就是 Skills 和各类 Agent 的集合。每个 Agent 带着自己的 Skills 包相当于带了一套 SOP 上岗。能力层要解决的是“可扩展”——新技能就是往目录里扔一个文件夹的事不需要改主程序。第四层是指挥层也就是编排。这就是热词里 Harness 和 Agent 区别的答案Harness 是 Agent 运行时的“马具”负责管理 Agent 的上下文窗口、工具权限、沙盒环境、执行循环而 Agent 本身是“大脑”负责推理和决策。编排引擎再往上做一层管理多个 Harness 的协作流程、任务队列、并发策略和错误恢复。2.2 工具选型MCP 框架怎么选、Agent 底座怎么定MCP 的 SDK 生态目前比较成熟的还是 Python 和 TypeScript 两个阵营。Python 用官方mcp库TypeScript 用modelcontextprotocol/sdk。我的建议是如果你团队的 Agent 主要跑数据处理、API 集成选 Python 生态因为后面接各类库最省事如果你的 Agent 跑在前端/浏览器插件里选 TypeScript比如在 IDEA 插件里做通义灵码接 Oracle 这种场景TS 的集成会顺手很多。Agent 底座的选择上我试过几类Claude Code 这类官方 CLI配合 Codex 或 Claude Agent Skills 一起用、开源的 Hermes Agent 这类桌面版方案、还有 Dify 这类偏向业务配置的平台。他们定位不太一样官方 CLI 开发效率高适合单个 Agent 的重度任务Hermes Agent 适合接 Obsidian 这类个人知识库做知识管理自动化Dify 的强项是给非技术人员拖拽搭流水线但它的 MCP 接入通常需要自己做代理层。至于生产级的多 Agent 集群我更推荐自己搭控制层因为目前还没有一个开箱即用、能同时管好 MCP、A2A、Skills 的编排产品。2.3 为什么“可扩展”要靠 Skills 而不是靠硬编码架构里最容易被忽视的是“可扩展性”的设计。很多团队的 Agent 能力是写在代码分支里的加一个新工具就写一个新函数加一个新场景就改一段 prompt。这不是可扩展这是埋雷。Skills 的模式天然适合扩展。在 Claude Code 的实践里Skills 就是.claude/skills/目录下的一个个子目录每个子目录里一个SKILL.md加若干资源文件。新增能力 新增目录 写一份说明书。Agent 启动的时候自动扫描目录就能感知到新能力。这套机制移植到自己的集群里很简单用一个skills/目录挂载到所有 Agent 的容器里运营同学都能往里加技能不需要写代码。我为什么强调这一点因为在企业里Agent 的真正瓶颈不是模型能力而是“团队怎么持续把自己的领域知识沉淀给 Agent”。Skills 这套模式把沉淀的过程从“找开发改代码”变成了“写一份结构化文档”这个跃迁才是可扩展的根基。3. 实操从零搭建一个能跑的多智能体集群这一章我把关键步骤拆开讲代码和配置都是可以拿回去直接改用的。整体分四步先写一个 MCP Server再给 Agent 写 Skills然后配置 A2A 互通最后用编排层把整个流程串起来。3.1 第一步写一个最小可用的 MCP Server以 Python 为例先初始化项目并安装依赖mkdir mcp-tools cd mcp-tools python -m venv .venv source .venv/bin/activate pip install mcp[cli] httpx然后创建一个最简单的 Server我拿“查天气”举例方便聚焦核心机制from mcp.server import Server from mcp.server.stdio import stdio_server from mcp.types import Tool, TextContent app Server(weather) app.list_tools() async def list_tools(): return [ Tool( nameget_weather, description根据城市名查询当前天气, inputSchema{ type: object, properties: { city: {type: string, description: 城市名如北京} }, required: [city] } ) ] app.call_tool() async def call_tool(name: str, arguments: dict): if name get_weather: city arguments[city] # 这里替换成真实天气 API result f{city}晴25°C return [TextContent(typetext, textresult)] async def main(): async with stdio_server() as (read, write): await app.run(read, write, app.create_initialization_options()) if __name__ __main__: import asyncio asyncio.run(main())这段代码里有三个关键点list_tools声明工具清单和入参 schemacall_tool实现具体逻辑stdio_server负责与客户端通信。你不需要自己定义通信协议SDK 全部封装好了。跑起来之后用 MCP Inspector 就能看到工具描述。我在做企业级接入时通常会在这一层加上日志和鉴权每一个工具调用都记录调用方、入参、耗时敏感操作加一个审批钩子。MCP 的价值之一就在这里——所有工具调用汇聚到 Server 层安全和审计就有统一抓手。3.2 第二步给 Agent 编写第一份 SkillsSkills 目录结构按照 Claude Code 社区流行做法skills/ └── blog-writer/ ├── SKILL.md └── assets/ └── example-post.mdSKILL.md的文件头带 YAML frontmatter内容示例--- name: blog-writer description: 编写高质量技术博客文章的完整方法论适合写作类 Agent 加载 --- # 博客写作指南 ## 适用场景 需要输出结构清晰、实操性强的技术文章时使用。 ## 写作流程 1. 先梳理目标读者和核心关键词 2. 搭建文章骨架开头引入、主体拆解、实操细节、避坑经验 3. 正文每段不少于 150 字避免空泛总结 4. 涉及代码必须标注语言类型 5. 结尾用真实经验或技巧收尾不写套话关键在于这份文件是给模型“读”的而不是给人看的。所以描述必须足够具体、足够操作化。我见过很多人写 SKILL.md 像写产品文档满篇“要高质量”“要注重细节”模型读完等于没读。真正的 Skills 要写出判断标准、操作顺序、禁忌清单最好再给一个正反例对照。写完这份 SKILL.md 之后把它挂载到 Agent 的 skill 目录里。如果你用的是 Codex可以把 Skill 直接放到~/.codex/skills/下面如果是自己写的 Agent 代码启动时扫描skills/目录把每个 SKILL.md 读取到系统提示词里即可。3.3 第三步打通 A2A让 Agent 之间能互相派活A2A 的实现思路是每个 Agent 启动时都会生成一份 Agent Card声明自己的能力和通信端点。我用一个最轻量的 JSON 格式演示{ name: data-analyzer, description: 负责数据清洗、统计分析和图表生成, url: http://agent-data-analyzer:8080/a2a, skills: [pandas-analysis, chart-generation], authentication: { scheme: bearer, credentials: env:A2A_API_TOKEN } }Agent Card 注册到一个服务中心别的 Agent 需要服务时就到这里查“名片”。我建议在生产环境用 Redis 或者直接放 etcd 做服务发现简单场景下用文件轮询也能跑。真正调用别的 Agent 时HTTP 协议大致长这样POST /a2a { jsonrpc: 2.0, method: tasks/send, params: { task_id: task_001, agent_id: data-analyzer, input: { instruction: 分析用户留存数据并生成趋势图, context: 数据源/data/retention.csv } } }这个调用会创建一个任务A2A 客户端轮询任务状态直到对方回传completed并带上结果。Spring A2A 这类封装就是把上述握手、加密、超时重试做成了注解和模板方法省去很多重复工作。这里分享一个实践教训A2A 的任务状态机一定要设计。最低要求是 pending、running、completed、failed 四个状态否则一个 Agent 挂了主流程根本不知道任务卡在哪儿。稍微复杂一点还要支持 cancel 和 timeout不然一个子 Agent 死循环整个集群跟着遭殃。3.4 第四步用编排层把流程串起来编排层是最能体现“DeepAgents”深度的地方。DeepAgents 这个概念你可以理解为不是写一个魔法函数而是深入 Agent 的每一步——规划、记忆、工具选择、自我反思、错误恢复——都显式地编排起来。我用一段伪代码演示编排思路async def run_pipeline(): # 1. 规划阶段 plan planner.decompose(写一篇关于 MCP 的博客并配图) # 2. 指派阶段 blog_task orchestrator.dispatch(blog-writer, plan.article) chart_task orchestrator.dispatch(chart-generator, plan.figure_spec) # 3. 并发执行 article, chart await asyncio.gather( agent_runner.run(blog_task), agent_runner.run(chart_task) ) # 4. 汇合与校验 if not validator.check(article, chart): raise RetryError(质量不达标重新生成) return merge(article, chart)这里的关键点不是代码本身而是三个设计决策第一规划与执行分离。规划 Agent 只负责拆解任务不负责干活。这样方案阶段和耗时阶段互不阻塞也方便后续做方案审计。第二并发策略要可控。AI Agent 是单并发场景下最容易失控的。我用的是自研的任务池 信号量限流核心逻辑就是先把任务拆成 DAG再把没有依赖关系的节点交给一个asyncio.Semaphore(5)的边界内并发执行。热词里“AI Agent 怎么扛并发”的答案就在这里——不是硬扛而是削峰、排队、限制工具调用的 QPS。第三凡是能出错的步骤都要重试。LLM 调用不像传统接口同一个输入可能连续失败三次但第四次就成功了。我的重试策略是模型调用失败指数退避重试 3 次工具调用失败最多重试 1 次并降级编排层兜底改为串行执行防止死锁。3.5 对接真实场景Dify、低代码平台与 IDE 插件的 MCP 接入集群跑通之后你会发现周边系统接入才是工作量最大的部分。实际项目里至少会遇到这三类第一类是 Dify 这类低代码平台接入 MCP。Dify 本身有自己的工具机制但社区对浏览器 MCP 这类能力需求很高。可以实现的思路是写一个 Bridge Server把 Dify 的自定义工具接口转换为 MCP 协议这样 Dify 的流程里就能用上 Playwright MCP 的浏览器自动化能力。注意不要直接在 Dify 里拼 HTTP 请求调用 MCP Server因为 MCP 是长连接协议不是简单的 REST中间要有一层适配。第二类是后台管理系统集成 MCP。RuoYi-Vue-Pro 这类框架合并 MCP 功能通常是把 MCP Server 的注册、启用、鉴权做成前端菜单后端维护一个 Server 实例池通过 SSI 或 WS 转发给 Agent 使用。这样做的好处是企业里不同的部门可以各自维护自己的工具包互不干扰。第三类是 IDE 插件。IDEA 里用通义灵码这类 AI 插件接 MCP 时痛点通常是权限和驱动。插件需要有一个独立的 MCP Client 配置入口并且驱动 Oracle 这类数据库时要把 JDBC 的驱动包放到 MCP Server 的 classpath 里别指望插件自动帮你处理。这里我建议做成两个进程插件进程只做 UI 展示MCP Server 进程管数据库访问避免插件崩溃连带数据库连接全断。4. 常见问题与排查技巧实录这一章是真正从线上踩坑得来的每一条都是拿时间换来的。我整理成速查表下面挑重点展开。现象可能原因快速排查方法Codex 无法找到 MCP配置路径错误或 Server 未启动用mcp list查看注册情况Agent 执行终止execution terminated due to error上下文溢出或工具超时拆分任务并加大超时配置Skills 不生效目录名与 SKILL.md 的 name 不一致检查文件头 frontmatterA2A 任务卡在 pending服务发现失败或鉴权失败查看子 Agent 日志和注册中心状态MCP Server 频繁断开并发过高或心跳超时排查连接池配置4.1 Codex 找不到 MCP 或发送失败Codex 找不到 MCP 是我遇到频率最高的问题。常见原因有三个一是 MCP Server 的进程没起来或端口被占用二是配置里的命令路径不对比如在 Windows 上直接写了python而没有写全路径三是 Codex 的沙盒环境隔离了网络Server 虽然跑着但客户端连不上。排查思路很简单先在终端里手动把 Server 跑起来确认端口通再在 Codex 配置里用绝对路径最后检查沙盒网络配置必要时把 MCP Server 的地址加入沙盒白名单。这类问题 90% 出在环境和配置而不是协议本身。4.2 Agent 沙盒报错与安全边界热词里“显示更新 agent 沙盒”这个报错多半是沙盒环境更新后依赖版本变了。比如你原来在沙盒里装了mcp1.0更新后变成了 2.0接口不兼容Agent 直接罢工。我的做法是沙盒镜像打 tag每次升级前跑一遍全量回归测试同时把 MCP SDK 的版本锁死在 requirements.txt 里不做滚动升级。沙盒的安全边界也要注意。Agent 能跑的代码、能连的内网、能读的文件必须在编排层做白名单。我见过一个团队把生产数据库的只读账号给了 Agent结果一个测试 Agent 的循环任务把数据库连接池打满。这事不怪模型怪权限设计。4.3 Skills 冲突与加载顺序Skills 加载最典型的问题是两个 Skills 同时命中模型不知道该听谁的。比如一个通用写作 Skill 和一个技术博客 Skill都包含“怎么写开头”模型可能混着执行。我的规范是每个 Agent 只挂载与职责相关的 Skills 目录明确优先级——领域专用 Skill 优先于通用 Skill。另外 SKILL.md 里的 name 必须和目录名一致之前吃过亏目录改名后忘了同步 frontmatter模型加载时报错。4.4 MCP 鉴权与授权以 Figma、蓝湖接入为例设计工具类 MCP 的授权机制要单独说。Figma 这类工具通常走 OAuth不能简单地塞一个 token 进去。比如 Codex 接入 Figma MCP首次会弹授权页面你需要把回调地址配置到 MCP Server 的启动参数里让授权流程能完整走通。蓝湖这种国内设计协作平台类似授权以后还要处理 refresh token 过期问题我建议在 Server 层把 token 刷新做成自动任务不要等用户手动重新授权。这类授权链路中有一个易踩的坑OAuth 回调地址如果用了 localhost在容器或远程开发环境里会因为端口映射失效而无法回调。解决办法是把 MCP Server 的监听地址改成可访问的宿主机地址或者用反向代理把回调转到容器内。5. 从开发到生产把集群做得更稳的五个细节单机跑通、联调通过之后距离一个能上生产的集群还差很多。这五个细节是我在实际项目中反复踩、反复改出来的提前布局能省掉后面大量的返工。5.1 日志和追踪Agent 集群的“黑匣子”AI Agent 的执行链路天然不可预测没有日志根本没法排查。我不但给 MCP Server 加日志还给每个 Agent 加了 trace_id从编排层的任务下发开始贯穿到子 Agent 调用、工具调用、模型生成的每一次交互。这样用户报一个问题我能直接从日志里拉出整条链路定位是模型决策错了、工具执行失败了还是编排死循环了。日志里一定要记录prompt 的摘要不用存全文存关键参数、模型输入输出 token 数、工具调用入参和出参、关键节点的耗时。特别是工具调用的入参出参必要的时候要做脱敏但原始数据至少要留存 24 小时用于事故回溯。5.2 状态管理编排层的多活与持久化编排层的调度状态不能放在内存里否则编排层一重启所有进行中的 Agent 任务全丢。我用的方案是编排层把任务状态写入 Redis用任务 ID 做键存储规划结果、依赖关系、当前执行节点、各子 Agent 的返回。编排层本身做多实例部署抢锁用 Redis 分布式锁确保同一个任务不会被两个实例重复执行。状态持久化顺带解决了一个问题Agent 执行到一半挂了编排层重启后能根据 Redis 里的状态决定重试还是回滚而不是从头再来。5.3 限流、熔断与降级防止 Agent 雪崩多 Agent 集群最可怕的不是单个 Agent 慢而是一个上游 Agent 挂了下游一堆 Agent 都在等它连接池和任务队列一起爆掉。我的做法分三级限流指的是每个 Agent 的 MCP 工具调用做 QPS 限制防止模型生成速率过高打爆下游 API熔断指的是上游持续失败时编排层自动摘除该 Agent不让新任务再发给它降级指的是核心链路要有备选方案比如用搜索 MCP 失败时降级成静态库检索宁可结果糙一点不能让整个流程空转。5.4 安全与权限给 Agent 发最小权限的“工牌”Agent 安全的核心是权限最小化这个原则和执行者是谁无关和模型是否自作主张有关。我见过最典型的事故是一个被授予了写权限的 Agent在执行一次数据库订正任务时把一张生产表的上万条记录更新成了错误值。原因很简单模型的判断出现偏差但权限没有拦住偏差。所以我的铁律是默认只读写操作必须走审批钩子每个 Agent 使用单独的服务账号MCP Server 层做操作白名单而不是黑名单。热词里“Agent 安全”被很多人讨论我的看法是与其担心 Agent 泄露 prompt不如先把工具权限管好因为工具能做的破坏远比模型知道的秘密大。5.5 成本控制token 用量和并发时长的监控Agent 集群跑起来之后成本会以非常惊人的速度增长。一个包含三个子 Agent 的流水线一次完整执行可能要消耗十万甚至几十万 token而且失败重试还会加倍。我建议在编排层加成本计数器每次任务完成后记录总 token 消耗、按 Agent 维度拆分的消耗、按工具调用的消耗。数据攒两周之后你就能看到哪些任务性价比低、哪些 Skill 让模型少走了弯路。这不是财务问题这是架构优化问题——成本数据会反过来指导你调整流程。6. 一些我踩过的坑和个人体会最后分享几个偏“软”的经验它们在文档里几乎不会写但会决定你的集群到底好不好用。第一个体会是不要一开始就追求全自动。很多团队做多 Agent 集群恨不得从任务下发到结果生成全自动无人值守结果第一个月全在救火。我现在的习惯是新流程先跑“半自动模式”编排层每个关键节点都停下来等人审核跑顺了再逐步放开。这样做最大的好处是能积累一套“正常流程长什么样”的基准数据后面自动化出问题的时候对比基线就能快速定位。第二个体会是Skills 是要持续运营的资产不是写一次就完了。我每个季度会挑几个线上案例复盘看 Agent 是哪一步没做好然后把改进方法更新到对应 SKILL.md 里。三个月下来同一个业务的 Agent 成功率能明显提升而且这个过程不需要换模型、不需要改代码。这比天天调 prompt 有意义多了因为 Skills 是结构化沉淀prompt 是随缘调参。第三个体会是关于工具选择的。Browser Use MCP 和 Playwright MCP 的区别经常有人问我统一回答如果只是要浏览器自动化脚本选 Playwright MCP稳定且可控如果要的是 Agent 自主探索网页根据内容动态决策点哪里选 Browser Use MCP它的规划能力更强但代价是消耗更多 token、执行更慢。两者没有绝对的谁更好只有适不适合当前任务。这也是我给整个技术栈做选型时的通用思路——协议和框架都是手段真正的目标是让你的业务跑得更稳、更快、更可控。这套 DeepAgents MCP A2A Skills 的组合目前没有现成的全家桶产品需要自己拼装。但拼装本身不是坏事因为每一次选择都逼着你把架构想清楚而想清楚的团队才接得住下一代 Agent 集群的复杂度。