如果你只是把一个能写文案的 Agent、一个能查资料的 Agent、一个能操作浏览器的 Agent 丢进同一个系统，让它们共享一个聊天窗口，那你还只是在摆地摊，不是在搭集群。最近我把《DeepAgents+MCP+A2A+Skills 超级多智能体》这门慕课完整过了一遍，课程里最值钱的一点，是它没有把“超级多智能体”讲成玄学，而是给了四个能落地的组装件：DeepAgents 负责编排、MCP 负责接工具、A2A 负责接通不同 Agent、Skills 负责沉淀可复用能力。这篇文章就是把课程里那套“可编排、可互通、可扩展”的目标翻译成实操笔记：每个组件解决什么问题、项目里怎么串、哪些地方最容易翻车。
1. 先撕掉包装：这四件套在 Agent 集群里各管哪一段
第一次看到课程标题的时候，我也有个困惑：DeepAgents、MCP、A2A、Skills 这四个东西听起来都能“装 Agent”，为什么还要拼在一起？后来把整个项目跑通才想明白，它们根本不在同一个抽象层级上。把层级关系搞清楚，后面所有代码和配置才有意义。
1.1 四个组件不在同一个抽象层级
我把这四件套放到下面这张表里，你一眼就能看出区别：
| 组件 | 管的层级 | 生活化类比 |
|---|---|---|
| DeepAgents | Agent 内部的“组织架构”：主控拆任务、Subagent 执行、上下文隔离、结果验收 | 项目经理 + 外包团队 |
| MCP | Agent 与外部工具之间的“统一调用协议” | 墙上的插线板 |
| A2A | Agent 与 Agent 之间的“服务协议” | 两家公司之间的合同与对接接口 |
| Skills | 把操作经验打包成 Agent 可读的“操作手册” | 新人入职培训手册 |
MCP 解决的是 Agent 的手够不够长，A2A 解决的是 Agent 之间能不能互相派活，Skills 解决的是经验能不能沉淀复用，DeepAgents 解决的是这些能力怎么被组织成一条可控制的流程。课程里反复强调一句话：集群不是把多个 Agent 摆在一起，而是让每个 Agent 可以独立失败、独立重启、独立升级。做到这一点的前提，就是先把上面的层级切开。
1.2 单体 Agent 与 Agent 集群的分界线在哪
单体 Agent 的特点是：所有工具、提示词、历史记录都塞在同一个上下文窗口里。任务短的时候没问题，任务一长，上下文被思考过程、工具返回值、中间产物填满，模型就会越来越“糊涂”。集群的思路正好反过来：每个节点职责单一，节点之间只交换最终结论，不交换各自的完整思考过程。
举个例子。单体方案做一个“行业研究报告”，需要模型既会搜索、又会读 PDF、又会写 Markdown。它每执行一步，动作历史都留在上下文里。等到写报告时，前面几十次搜索返回值早就把窗口挤占了。集群方案则把任务拆给三个 Subagent：搜索 Agent 只负责检索并输出结构化笔记，PDF 阅读 Agent 只负责提取摘要，写作 Agent 只接收前两位的精华结果。每个 Subagent 的执行过程都在自己的上下文里完成，父 Agent 只看到一份干净的移交单。这就是课程项目里“可编排”三个字的实际含义，不是功能上的堆叠，而是流程上的切分。
2. 编排层：DeepAgents 的 Subagent 机制为什么是集群的地基
DeepAgents 最核心的概念就是 Subagent。课程里讲了一个让我印象深刻的对比：传统 ReAct 是一条单线程上的“思考-行动-观察”循环，每一步都吃掉同一个上下文窗口；DeepAgents 则是一棵任务树，主 Agent 评估要不要继续深入，子 Agent 在自己的上下文里执行完一个完整子任务后，只把结论摘要交回主 Agent。
2.1 Subagent 是“换上下文”，不是“多个大脑并行”
很多人误以为 Subagent 就是同时跑多个模型，让它们“一起想”。实际上，至少在当前主流框架里，Subagent 的收益不来自并行计算，而来自上下文隔离。同一个模型 API 被调用多次，在语义上是多个上下文实例，不是多个大脑。Subagent 的价值在于：父任务不会被子任务的中间产物污染，子任务也不会被父任务的无关历史干扰。
我第一次跑通 DeepAgents 项目时，最大的感受就是“原来思考可以这样交接”。父 Agent 给 Subagent 一份任务说明书，说明目标、输入材料、输出格式和验收标准；Subagent 跑完，交回一个摘要；父 Agent 检查摘要，不合格就打回重做，合格就继续下一层。主控 Agent 的上下文永远只保留“决策摘要 + 当前进度”，而不是每次工具调用的完整日志。任务越深，这套机制的优势越明显。
2.2 DeepAgents 和 Claude 这类底层模型比，到底在比什么
网上经常有人问“LangChain 的 DeepAgents 现在能力咋样，和 Claude 比差距在哪”。我的看法是，这个问题问错了层。DeepAgents 是编排框架，Claude 是底层模型/产品形态，两者不是同一个维度的东西。你完全可以用 Claude 作为 DeepAgents 底下的执行模型，也可以用其他模型来跑 Subagent。
真正该比较的，是编排能力：能否控制 Subagent 的深度上限、能否根据描述准确路由子任务、能否在子任务失败后自动降级重试、能否把 Subagent 的返回结果压缩后交回主控。这些能力跟底层模型的选择有关系，但不完全是一回事。课程里其实也默认了“模型可以换”这件事：把模型接在 DeepAgents 上，就像给发动机换缸体，编排层不需要重写。
2.3 用任务树组织任务，而不是把所有逻辑塞进提示词
课程里的代码版本一直在变，但结构是稳定的。以我用过的 LangChain DeepAgents 接口形态为例，下面是去掉无关细节后的示意代码，具体函数名要以你实际安装的版本为准：
# 示意代码：不同版本的字段名会变，但组织逻辑一致 from deepagents import create_deep_agent from agents import create_agent research_subagent = create_agent( name="web_researcher", description="负责基于给定主题检索公开信息，输出带来源的结构化笔记。", tools=[web_search_tool], max_iterations=6, ) doc_subagent = create_agent( name="doc_reader", description="负责读取本地文档并输出摘要。", tools=[document_loader_tool], max_iterations=4, ) main_agent = create_deep_agent( tools=[report_tool], subagents=[research_subagent, doc_subagent], max_subagent_depth=2, )写 Subagent 时，description 才是命门。描述里写清楚“负责什么、在什么条件下被调用、输出什么格式”，路由命中率会高很多。我见过太多失败案例，description 写得像营销文案，比如“强大的检索专家”“智能文档助手”，模型根本不知道什么时候该调它。要写就写：当用户要求查资料时使用，输入是一个主题，输出是带来源的笔记列表。这种描述才能在任务树上起到路标作用。
3. 工具互通层：MCP 把“手”变成即插即用
编排层解决的是“谁来做”，工具层解决的是“用什么做”。课程里花了不少篇幅讲 MCP，我一开始觉得它只是个 API 封装，真去接入才发现，它的价值在于把工具接入方式标准化了。
3.1 MCP 是软件协议，不是硬件协议
MCP 全称 Model Context Protocol，它管的是程序之间如何交换能力和数据。有人问 MCP 是软件协议还是硬件协议——答案很清楚，它是软件协议。它不定义物理接口，而是定义“我是服务端，我提供这些工具；你是客户端，你可以调用我”这套 JSON-RPC 会话。和 USB-C 的类比只停留在“统一接口”这个思路上，协议本身跑在 stdio 或 HTTP 之上。
课程的类比很实用：MCP 像插线板。你把一个 MCP Server 插上去，客户端自动发现它提供的工具、资源和提示词。不需要为每个工具手写适配器，也不需要改主控 Agent 的代码。这个特性对集群特别重要，因为集群里有很多 Agent，如果每个 Agent 都要为同一套工具写不同的调用代码，那就不叫集群，叫集成地狱。
3.2 一次 MCP Server 接入的最小配置
现在主流客户端和 IDE 基本都支持通过配置文件接入 MCP。最常见形态是 mcpServers 配置，下面是一份我本地调通的示例：
{ "mcpServers": { "playwright": { "command": "npx", "args": ["-y", "@playwright/mcp@latest"] }, "web-search": { "url": "http://127.0.0.1:8080/mcp", "transport": "streamable-http" } } }stdio 类型适合本地进程型工具，启动快、日志直观；streamable-http 适合服务端工具，可以被多个 Agent 共享。课程里给的经验是：本地调试优先 stdio，因为你能直接看到工具进程的输出；生产环境优先 HTTP，因为工具可以被集群里的所有节点复用。配置完成后，客户端会自动发 tools/list 请求，把服务端的能力注册进模型的工具表，全程不用手写胶水代码。这一点比传统 API 封装强太多。
3.3 MCP 工具不是越多越好
MCP 的开放性是优点，但工具表太长也会让模型选择困难。课程里的做法是给每个 MCP Server 按域拆分：浏览器归浏览器、数据库归数据库、搜索归搜索，而不是把一个 Server 塞 50 个工具。工具命名也很有讲究，名字里直接带副作用，比如“打开网页并提取正文”就比“run”好一百倍。
我自己的经验是，MCP Server 更像是服务边界，而不是功能垃圾桶。如果一个 Server 里什么都有，模型每次调用前都要在大工具表里做筛选，不仅慢，还容易选错。保持每个 Server 的工具数量在 10 个以内，会让整个集群的稳定性和速度都明显提升。
4. 智能体互通层：A2A 让 Agent 之间能互相派活
MCP 解决 Agent 到工具，A2A 解决 Agent 到 Agent。课程里把这两者的边界讲得很清楚，我做完项目后体会更深：集群中经常有一个完整的 Agent 提供另一块能力，比如专职校对、专职翻译、专职排版。你可以把它们各自包成 MCP Server，但 A2A 是更自然的对接方式。
4.1 为什么有了 MCP 还不够
MCP 的交互单位是“工具调用”，适合一次请求拿一个结果。但 Agent 之间的协作往往是“任务级”的：我给你派一个活儿，你干完通知我，中间可能需要几分钟，也可能需要你中途问我补充信息。A2A 的设计就是为这种场景准备的，它用 Task 来描述一整件工作，而不是单次函数调用。
我用一张表总结两者差异：
| 维度 | MCP | A2A |
|---|---|---|
| 交互单位 | 工具调用 | 任务（Task） |
| 两侧角色 | Agent ↔ 工具服务 | Agent ↔ Agent，双方都可发起 |
| 典型方法 | tools/call | tasks/send |
| 是否支持异步 | 通常偏同步 | 原生支持异步、流式、推送 |
| 解决的核心问题 | 手不够长 | 协作不通 |
4.2 Agent Card、Task、Message 是 A2A 的三根柱子
A2A 规范里，每个 Agent 先提供一个公开的 Agent Card，相当于服务发现页。卡片里写清我是谁、能干什么、怎么联系、支持什么能力。接着是 Task，代表一次完整的活儿；再往下一层是 Message，Task 的输入输出都通过 Message 来表达。下面是一份简化过的 Agent Card 示意：
{ "name": "proofreader-agent", "description": "对中文内容做错别字与句式校对，返回修订对比。", "url": "http://localhost:9000/a2a", "capabilities": { "streaming": true, "pushNotifications": true }, "skills": ["proofreading", "markdown"] }发起任务时，主控 Agent 向这个 URL 发送 tasks/send 请求：
{ "jsonrpc": "2.0", "method": "tasks/send", "params": { "id": "task-2025-001", "message": { "role": "user", "parts": [ { "kind": "text", "text": "请校对这份报告草稿" } ] } } }返回的通常是一个 Task 对象，初始状态是 working。如果对方 Agent 支持推送，稍后会通过你注册的回调地址告知 completed；如果不支持，你就需要轮询状态。这套机制很像真实世界里的甲方乙方：你发一个需求单，对方开工，做完交付，而不是像调用函数一样要求立刻返回。
4.3 长任务与回调：A2A 最容易被忽略的部分
A2A 不是简单的请求-响应，很多任务会持续几十秒甚至几分钟，所以回调地址是课程项目里调试最久的问题之一。最常见的坑是容器网络：主控 Agent 跑在容器里，回调地址写了 localhost，这个地址是容器自己，外部 A2A 服务根本访问不到。要让服务端能触达主控，必须写宿主机或局域网内可达的地址。
我在本地固定用 host.docker.internal 这类内部域名解析宿主机，部署到服务器后就改用服务发现里的内部域名。另外一个教训是，Agent Card 里的 url 要和实际部署一致。开发时经常改了端口却忘了更新卡片，主控拿着旧地址去调，永远超时。建议把 Agent Card 当作配置项托管，而不是写着写着就忘了。
5. 扩展层：Skills 决定集群能长多大
如果集群只能靠改代码来加能力，那它就不是“可扩展”的。课程里给出的解法是 Skills：把经验打包成文件，让 Agent 按需加载。这一块看起来最简单，实际做起来最考验工程习惯。
5.1 Skill 到底长什么样：SKILL.md 的组织方式
Skills 最常见的形态是一个目录加一个 SKILL.md，里面用 frontmatter 写名称和描述，正文写操作步骤，必要时放脚本和参考文件。你可以把它想象成给 Agent 的一份新人培训手册。
my-skills/ report-standard/ SKILL.md template.md generate_report.pySKILL.md 的内容大致这样：
--- name: standard-weekly-report description: 按企业周报模板生成 Markdown 周报。当用户要求写周报、日报或项目进展时使用。 --- # 执行步骤 1. 收集本周完成项、风险项、下一步计划。 2. 按 template.md 填充分区。 3. 用 generate_report.py 生成最终 Markdown。 # 注意 - 不要编造数据，缺失项写“待补充”。这套格式的好处是：模型只有在确定该技能适用时，才会读取正文；不适用时，它只看 description 就能决定跳过。技能库越攒越多，集群的复用能力就越强。常用的代码审查、数据处理、报告生成这类技能，复用率尤其高，值得优先沉淀。
5.2 决定 Skill 好不好用的是描述，不是正文
课程里专门花了一节讲 skill 描述，这可能是最容易被忽略的细节。模型选择 Skill 时先读 description，正文是选定后才被加载。很多人把精力全花在正文，描述随便写一句“生成周报”，结果模型永远不知道什么时候该调它。
我踩过几次坑之后总结出一套写法：触发场景放在最前面，输入输出写清楚，最后加一句反面条件。比如“当用户要求写周报、日报或项目进展时使用；输入是工作要点列表；输出是 Markdown 周报；不要用于未提供数据的情况”。这样的描述，在 Agent 的“技能选择”环节里才是有效的路由信息。
5.3 技能库和 MCP 工具的边界配比
刚开始搭集群时，我分不清什么该做成 MCP 工具，什么该做成 Skill。课程里的判断标准很清晰：确定性的、模型不该自由发挥的操作，做成 MCP 工具；多步骤、带判断和编排的方法论，做成 Skill；要暴露给其他 Agent 的完整能力，走 A2A。
比如“打开网页”用 MCP，“按某公司风格写一篇产品发布稿”用 Skill，“把文稿翻译成多语言并回传”用 A2A。这个边界关系理清后，集群的代码量能少很多。你不需要把所有业务逻辑都写进提示词，也不是所有功能都值得写成工具，很多经验类的东西放技能库反而更灵活。
6. 一个能照抄的最小集群结构：把四件套串起来
有了前面的基础，就可以看整体结构了。我照着课程里的实战项目重新搭了一个最小可运行版本，目标是“根据一句主题生成一份带来源的周报”。这个项目不大，但四个组件全部用上了。
6.1 课程实战项目复刻成的最小闭环：研究型周报集群
整体架构可以简化成下面这个结构，每个节点职责都很单一：
[用户请求] ↓ [DeepAgents 主控] # 编排、验收、汇总 ├── [研究 Subagent] → MCP: web-search / playwright ├── [数据 Subagent] → MCP: database-server └── [写作 Subagent] → Skills: report-standard ↓ A2A [校对 Agent] # 外部 A2A 服务研究 Subagent 负责检索资料，数据 Subagent 负责查内部数据，写作 Subagent 负责按周报 Skill 写初稿，最后通过 A2A 把草稿发给校对 Agent。任何一个子任务失败，主控都能单独重派；工具升级不用改主流程；新 Agent 只要提供 Agent Card 就能接入。这就是“可编排、可互通、可扩展”在一个具体项目里的样子。
6.2 启动顺序与请求链路
启动顺序很重要。我的经验是：先启动 MCP Server（playwright、web-search、db），再启动 A2A 校对服务，最后启动 DeepAgents 主控。因为主控启动时会去拉 Agent Card、扫描 MCP 工具表。如果先启主控，工具表是空的，不得不重启。
一次正常请求的链路大致是：用户输入 → 主控创建任务 → 研究 Subagent 调 MCP 搜索并打开网页 → 返回结构化笔记 → 数据 Subagent 查数据库 → 写作 Subagent 加载 report-standard 技能 → 生成草稿 → A2A 发给校对 Agent → 校审结果回传主控 → 汇总给用户。每个节点只和上下家通信，不越级、不共享上下文，链路虽然长，但每个环节都可观测。
6.3 让三个协议能一起调试的关键：请求 ID
课程里最实用的一招，是给整条链路定义 request_id，从 DeepAgents 的任务 ID 一路透传到 MCP 工具调用和 A2A 的 task ID。这样出问题时，你可以定位是哪个工具超时、哪个 Subagent 报错，而不是对着一句“Agent execution terminated due to error”的提示发呆。我在本地调试时就吃过这个亏，最后把所有日志都按 request_id 归集，问题一下子好查了很多。
7. 我在实操中踩过的坑与调试思路
课程是一回事，亲手把集群跑起来又是另一回事。下面这几个问题，是我在复刻课程项目过程中真实撞上的，应该能帮你省下不少时间。
7.1 “Agent execution terminated due to error” 不一定是框架的锅
这个错误在 deepagents 项目里太常见了，但它往往不是编排逻辑的错。我的排查顺序是：先看是哪个 Subagent 终止，再看是工具调用失败还是模型输出不合法，最后看对应 MCP Server 的日志。遇到过的案例里，十次有七八次是 MCP 工具没装好或服务端启动失败。比如 npx 命令在客户端环境里找不到包，进程起不来，模型自然会报执行终止。先把 command 在命令行里手动跑一遍，确认进程能起来，再接客户端。
7.2 MCP 返回内容太长导致上下文爆炸
MCP 工具可以返回很大的数据，比如整页 HTML 或整张数据库表。如果不加节制地丢给模型，很快就把上下文长度吃完了。课程给出的方案是“工具侧先粗加工，再回传摘要”：MCP Server 内部做好正文提取、导航删除、超长字段截断，甚至直接生成摘要，只把精华返回给主 Agent。这个思路比在提示词里反复写“请忽略无关内容”可靠得多。我当时把网页抓取工具改造成自动输出摘要后，主控上下文占用下降了将近一半。
7.3 A2A 回调地址的本地开发陷阱
前面提过的容器 localhost 问题，在 A2A 调试里尤其严重。另一个坑是本地起了多个 Agent 服务，端口冲突导致回调地址指向错误服务。课程项目里不同 Agent 用的端口特别接近，稍不注意就串了。建议本地开发时把所有端口号集中写在一个配置文件里，启动时检查端口占用，A2A 回调地址从同一个配置源动态生成，而不是散落在代码里。
7.4 Skills 太多会导致“选择困难”：给主 Agent 做减法
技能库建到 20 个以上后，模型开始混乱，经常在无关场景选错 Skill。解决办法不是删技能，而是分层：高频基础 Skills 常驻轻量描述，低频专项 Skills 放进二级目录，由上一层 Skill 或 Subagent 决定是否加载。真正的主控 Agent 只看到少数几个入口，而不是面对一个巨大的技能菜单。课程里把它叫作“让 Agent 聚焦”，我自己的体会是，这和给人设计工作台类似，桌面上只放常用的，剩下的收进抽屉。
最后说一个我在整个项目里最认同的观点：集群不是把能力堆给一个 Agent，而是把复杂度拆到协议里。DeepAgents 管流程，MCP 管工具，A2A 管互通，Skills 管沉淀，各层只要守住自己的边界，集群就能一直做加法而不乱。这套架构我后面还会继续在生产环境里迭代，尤其想在 Skills 的版本管理上再补一套校验流程。如果你也在搭 Agent 集群，建议先从最小闭环跑通，再用这四个组件一点点把边界撑开。
