前一阵我把手头的 AI 项目从一个什么都能干的大 Agent拆成了一群各有分工的小 Agent。折腾完 DeepAgents、MCP、A2A、Skills 这套组合之后最大的感受是以前总觉得 Agent 不够聪明其实问题往往是出在结构上——把太多能力压在一个上下文里模型再多参数也指挥不好。这轮重构之后可编排、可互通、可扩展这六个字终于不再是方案 PPT 上的概念而是真的可以一行行配置、一条条链路跑通的现实。这篇文章不是课程广告是我自己在落地这套超级多智能体集群时对架构的理解、配置的细节和踩过的坑的完整记录适合正在做 Agent 应用、准备把单 Agent 升级成集群的开发者参考。1. 先看懂这套组合拳DeepAgents、MCP、A2A、Skills 各自的位置很多人听到超级多智能体第一反应是是不是又造了个新框架其实这套东西根本不是同一个层面的产物理解错了层后面配置起来就会到处打架。1.1 单 Agent 的天花板我之前做过一个塞满了工具的大 Agent浏览器操作、代码搜索、数据库查询、爬虫、发消息全挂在同一个系统提示词和同一串工具列表里。一开始还挺爽但随着工具加到十几个问题慢慢出来了——模型经常在工具选择上犹豫明明该查数据库的时候去调了爬虫上下文稍微一长前面的指令就被冲淡了更麻烦的是一次任务里不同的子任务没法并行只能串行一步步来。这就像一个人开公司能力全面但精力有限接了大项目就顾不上细节任何一个环节卡住整条流水线都停摆。单 Agent 不是不聪明而是结构上撑不住复杂任务。所以行业里才有了把 Agent 拆成集群的思路。1.2 四个组件不是并列关系而是四个不同侧面我最初也以为 DeepAgents、MCP、A2A、Skills 是四套竞争方案实际拆开才发现它们分别在回答四个完全不同的问题组件回答的问题类比DeepAgents主 Agent 如何拆解任务、管理子 Agent公司的管理层和项目负责人MCPAgent 如何标准化地调用外部工具和数据统一的电源插座和 USB 接口A2AAgent 之间如何发现彼此、传递任务公司之间的合同和对接流程Skills把特定领域的流程和经验打包成可复用能力员工手里的标准作业手册一句话概括DeepAgents 负责纵向编排上下级任务分配MCP 负责 Agent 与工具能力的连接A2A 负责横向互通Agent 与 Agent 对话Skills 负责让经验可以被复用和累积。把这四层理顺了后面每个组件该放在架构图的哪个位置就非常清楚了。2. MCP给 Agent 集群装上统一的插座MCPModel Context Protocol是这套架构里最底层、也是最先要落地的一环。没有它你接任何一个新工具都要写一套专用适配代码。2.1 协议解决的本质问题在没有 MCP 之前接一个工具意味着什么拿数据库来说你可能要自己封装查询接口把结果转成模型能读懂的文本格式接浏览器操作又得实现一套启动、点击、截图的封装每接一个系统就多一份维护成本。更麻烦的是每个工具返回的数据结构都不一样模型需要花额外的脑力去理解格式。MCP 做的事情其实很简单把所有外部能力统一成MCP Server然后用一套标准的协议暴露工具Tools、资源Resources和提示词Prompts。Agent 这边只需要装一个 MCP Client就能像插 U 盘一样接入任何符合协议的 Server。这个思路和 USB-C 统一充电口是同一套逻辑——你不需要关心对方内部是什么芯片只要接口对上了就能通。2.2 从 stdio 到 wss传输方式的选型MCP 的传输方式直接决定了你的集群是单机版还是分布式。最常用的是两种stdio本地启动一个子进程通过标准输入输出通信。适合数据库、文件系统这类跟 Agent 跑在同一台机器上的工具配置简单、延迟低、权限好管。我本地连 MySQL 用的就是这种方式。HTTP / SSE / WebSocketwss远程连接 MCP Server。适合部署在服务器上的共享能力。比如团队内部部署一个统一的知识库 MCP Server所有开发者的 Agent 都能通过https://或wss://地址接入Server 端用 token 做鉴权。我建议的选型原则是能本地就本地必须共享才远程。本地 stdio 不需要处理网络抖动、token 过期、端口占用这些问题远程 wss 虽然灵活但你需要额外建立一套健康检查和鉴权机制。2.3 以 MySQL MCP 为例走一遍配置很多人在 Claude Code 或者 Cursor 里配 MCP 时卡住其实套路完全一样。我以本地 MySQL 为例用 claude code CLI 手动安装一遍# 先找一个现成的 mysql MCP server 安装到本地 npm install -g modelcontextprotocol/server-mysql # 然后在 claude code 里添加到配置 claude mcp add mysql-mcp -- npx modelcontextprotocol/server-mysql \ --host 127.0.0.1 \ --port 3306 \ --user root \ --password yourpassword在 Cursor 这类 IDE 里就是打开 MCP 配置面板选择添加全局 MCP填上启动命令和参数。配置完成后你在对话里提到查询用户表模型就会自动去调用 MySQL MCP Server 暴露出来的query工具而不是自己去瞎猜数据。这里有个关键点MCP Server 暴露的是工具但工具能不能用取决于你现在给了它什么权限。所以生产环境里MCP Server 的账号权限一定要最小化比如数据库账号只给 SELECT浏览器 MCP 只限本地测试页面。热词里那些wss://.../mcp/?token...的远程 Server 本质上就是开放了一个网络端口加鉴权token 泄露等于把内部工具直接暴露给了别人这点怎么强调都不过分。3. Skills把做过的事沉淀成会做的事MCP 解决了能调什么工具但没解决该按什么流程做。同一个前端分析任务新手 Agent 可能上来就截图老手 Agent 会先用性能 API 拿数据、再对比截图、最后给结论。这中间的差距就是 Skills 要填的。3.1 Skills 和 MCP 的边界最容易混淆的就是 MCP 和 Skills。我自己的理解是MCP 提供零件Skills 提供装配说明书。比如 Playwright MCP 提供了打开页面、点击、截图这些原子操作但你要让 Agent 稳定地完成一次冒烟测试得告诉它先做什么后做什么、什么情况算失败、截图存到哪。这部分知识和流程就写在 Skills 里。Skills 内部可以调用 MCP 工具也可以直接执行脚本文件它是把流程经验做成了一份 Agent 在运行时会主动加载的说明文档加配套脚本。3.2 一个标准 Skill 长什么样SKILL.md 拆解我用的 Skill 结构非常简单一个文件夹就是一个技能frontend-audit/ ├── SKILL.md # 技能说明和执行步骤 └── scripts/ ├── analyze_metric.ts └── screenshot_fullpage.tsSKILL.md是最关键的文件它决定了 Agent 什么时候调用这个技能、以及怎么一步步执行--- name: frontend-audit description: 对给定 URL 做前端质量审计包括性能指标、页面截图、关键资源分析。当用户需要分析网页性能、做前端巡检时使用本技能。 --- # 前端审计流程 1. 使用 playwright MCP 打开目标页面 2. 等待网络空闲调用 Performance API 获取核心指标LCP、CLS、FCP 3. 使用 chrome devtools MCP 截取首屏截图 4. 如果页面存在 404 资源单独输出清单 5. 最终输出性能指标表 截图路径 问题清单当用户的请求和description匹配时Agent 就会主动加载这份文件按照里面的步骤去执行。所以description 一定要写清楚什么时候用写得越模糊Agent 越容易误用。3.3 引入第三方 Skills 的正确姿势GitHub 上已经有大量现成的 Skills我平时搜得最多的是这几类前端开发相关的比如 superpowers 系列的 skills、数学建模相关的数据分析技能、还有安全检查类的脱壳和渗透技能。以 Claude Code 为例手动安装一个 GitHub 上的 Skill 其实就是在项目里建一个目录# 把 skills 目录放进项目根目录即可 mkdir -p .claude/skills git clone https://github.com/example/frontend-audit-skill .claude/skills/frontend-audit # 或者官方 registry 拉取 claude skill add frontend-audit这里有个容易踩的坑Skills 是项目级还是全局级决定了它会不会跟着代码一起走。我推荐把和业务强相关的 Skills 放进项目仓库.claude/skills跟着代码走、跟着版本走把个人效率类的比如写周报、整理会议纪要放到用户级目录。这样团队协作时新成员 clone 下来代码就自动拥有了全套技能不需要各自再去配一遍。3.4 自己写 Skills 的三个原则写了几十个 Skills 之后我自己总结出三条硬规则一个 Skill 只做一件事。把前端审计和SEO 检查拆成两个比合成一个大 Skill 强得多。Skill 太大Agent 加载后容易被里面的无关步骤干扰。步骤要可验证。每一步都要有明确的做完的标志比如拿到 LCP 指标后与 2.5 秒阈值对比。含糊的表述会在执行时变成模型的自由发挥。把踩坑记录写进去。比如截图前先等 1 秒否则懒加载图片不出现这种一句经验就能让后来的人少踩一次坑。Skills 本身就是团队经验沉淀的最好载体。4. A2A让 Agent 之间说同一种话MCP 和 Skills 解决了集群内部怎么干活但真正的多智能体意味着会有多个独立部署、可能由不同团队开发的 Agent 需要协作。这时候 A2AAgent2Agent协议就上场了。4.1 A2A 到底是什么A2A 是 2025 年年中被推到台前的一套开放协议它的核心目标很纯粹让一个 Agent 能够发现另一个 Agent 的能力并把任务传过去、拿回结果。它不是用来替代 MCP 的而是解决 MCP 解决不了的问题——MCP 连接的是工具A2A 连接的是另一个有自主能力的 Agent。可以这么记MCP 是 Agent 的手A2A 是 Agent 的外交语言。4.2 Agent Card 与任务流转A2A 的机制其实不复杂核心有三样东西Agent Card每个 Agent 对外发布一份 JSON 格式的能力清单包含名字、能力描述、支持的协议、接入地址和鉴权方式。你可以理解成 Agent 的公开简历。Task客户端把任务通过message发给目标 Agent目标 Agent 接受后返回一个 task ID任务开始执行。Message / Artifact在执行过程中Agent 会通过消息流式返回进度最终返回结构化产物比如报告、JSON、文件。一份 Agent Card 简化后长这样{ name: weekly-report-agent, description: 根据团队周报数据生成周报摘要, skills: [data-analysis, writing], capabilities: { task: true }, endpoints: [https://agent.example.com/a2a] }调用方的流程也很直白读 Agent Card → 确认它能干这事 → 创建 Task 并发消息 → 轮询或等待回调 → 拿结果。这套模式和 HTTP API 很像但多了任务状态管理和流式反馈更适合长时间运行的 Agent 任务。4.3 A2A 与 MCP 的分工别再混了我在一开始也犯过迷糊既然 A2A 也能发消息给别的服务那是不是可以不用 MCP实际跑一遍你就明白了——A2A 的目标 Agent 是有自己判断能力的实体它自己会决定怎么干活而 MCP 的目标 Server 是没有自主性的工具执行者你让它干什么它就干什么。所以集群里的典型链路是主 Agent 通过 A2A 把任务委托给一个数据采集 Agent采集 Agent 再用 MCP 调用浏览器工具和数据库工具去执行采集。A2A 管分配和回收MCP 管具体执行层级清晰不会乱。5. DeepAgents任务拆解才是深如果把 A2A 看成 Agent 与 Agent 之间的横向互联那 DeepAgents 解决的就是纵向深度。这一层是把大任务层层拆细、分配给子 Agent 执行的架构模式。5.1 子代理架构是怎么运行的DeepAgents 的核心思想是不要让一个 Agent 从头到尾处理所有事而是让一个主代理做两层工作——理解总目标、把目标拆成子任务然后创建多个子代理各自带着明确的子任务去执行。子代理可以是同构的同一个模型各自专注也可以是异构的有的擅长代码、有的擅长写作。我用过的比较典型的 LangChain 实现长这样伪代码from langchain.agents import create_deep_agent from langchain.agents.deep_agent import SubAgentSpec sub_agents [ SubAgentSpec( namebrowser_reader, instructions负责打开页面并提取正文内容输出结构化文本, tools[browser_mcp_tool] ), SubAgentSpec( namedata_cruncher, instructions负责对给定数据做统计分析和可视化, tools[python_repl, chart_tool] ), ] supervisor create_deep_agent( instructions你负责拆解用户任务把网页抓取交给 browser_reader把数据分析交给 data_cruncher, main_tools[research_web], sub_agentssub_agents )运行起来的效果是用户提一个含糊的问题比如分析竞争对手首页的加载性能并给出优化建议主代理会先拆成抓取页面信息和分析指标两个子任务分别派给两个子代理子代理各自干活、各自返回结果最后由主代理合成一份完整建议。5.2 LangChain DeepAgents 与 Claude 的差距在哪里很多人纠结于LangChain 的 DeepAgents 和 Claude 的 subagents 到底该选哪个。我的实测感受是核心思路已经趋同差距在默认行为上。Claude 的体系Claude Code / Skills / Subagents开箱即用靠着它自己的模型对工具调用的高度契合很少出现不知道该调用哪个子代理的情况LangChain 的 DeepAgents 则更透明、更工程化——你能明确看到任务怎么被分配、子代理用什么工具也更容易做权限控制和日志审计。如果项目是私人助手、追求开箱即用我建议直接走 Claude 的体系如果是做产品化的多智能体服务、需要对每一次任务分发都留痕LangChain 的 DeepAgents 更合适。不存在绝对优劣只有适配问题。5.3 编排模式的三种形态做 DeepAgents 编排时最常见的路由模式有三种单一主管模式Supervisor一个主代理管所有子代理适合任务边界清晰的场景部署最简单。接力模式Pipeline任务像流水线一样在多个 Agent 间流转前一个的输出是后一个的输入适合有固定工序的任务比如采集 → 清洗 → 建模 → 出报告。层级嵌套模式Hierarchical子代理下面还能再建子代理适合超大任务。代价是上层 Agent 的上下文容易变成瓶颈我一般控制在三层以内。这三条用熟了之后绝大多数业务场景都能套进去。6. 组合实战一个能跑的 Agent 集群长什么样前面四块拆开讲完很多人还是觉得虚。我直接把我当时用来验证这套架构的一个小集群端出来配置结构、任务流转、扩展方式都摆出来大家可以直接照着抄。6.1 我选的验证场景前端页面分析与自动化冒烟选这个场景的原因很简单它同时需要浏览器操作、代码分析、数据整理和报告生成非常适合展示多 Agent 协调。需求是给一批 URL自动打开页面、采集性能指标、截屏、检查控制台报错最后生成一份 Markdown 报告。6.2 集群的分层与连接关系整个集群我分成了三层编排层一个 DeepAgents 主代理负责接收用户输入、拆解任务、汇总结果。执行层两个子代理。一个是browser-audit-agent专门负责调 Playwright MCP 做页面操作和截图另一个是>