多智能体集群落地指南：DeepAgents、MCP、A2A与Skills架构实践

前一阵我把手头的 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 负责纵向编排（上下级任务分配），MCP 负责 Agent 与工具能力的连接，A2A 负责横向互通（Agent 与 Agent 对话），Skills 负责让经验可以被复用和累积。把这四层理顺了，后面每个组件该放在架构图的哪个位置，就非常清楚了。

2. MCP：给 Agent 集群装上统一的"插座"

MCP（Model 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 / WebSocket（wss）：远程连接 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.ts

SKILL.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 需要协作。这时候 A2A（Agent2Agent）协议就上场了。

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( name="browser_reader", instructions="负责打开页面并提取正文内容，输出结构化文本", tools=[browser_mcp_tool] ), SubAgentSpec( name="data_cruncher", instructions="负责对给定数据做统计分析和可视化", tools=[python_repl, chart_tool] ), ] supervisor = create_deep_agent( instructions="你负责拆解用户任务，把网页抓取交给 browser_reader，把数据分析交给 data_cruncher", main_tools=[research_web], sub_agents=sub_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 做页面操作和截图；另一个是>