★ FEATURED ARTICLE 如果你只是把一个能写文案的 Agent、一个能查资料的 Agent、一个能操作浏览器的 Agent 丢进同一个系统让它们共享一个聊天窗口那你还只是在摆地摊不是在搭集群。最近我把《DeepAgentsMCPA2ASkills 超级多智能体》这门慕课完整过了一遍课程里最值钱的一点是它没有把“超级多智能体”讲成玄学而是给了四个能落地的组装件DeepAgents 负责编排、MCP 负责接工具、A2A 负责接通不同 Agent、Skills 负责沉淀可复用能力。这篇文章就是把课程里那套“可编排、可互通、可扩展”的目标翻译成实操笔记每个组件解决什么问题、项目里怎么串、哪些地方最容易翻车。1. 先撕掉包装这四件套在 Agent 集群里各管哪一段第一次看到课程标题的时候我也有个困惑DeepAgents、MCP、A2A、Skills 这四个东西听起来都能“装 Agent”为什么还要拼在一起后来把整个项目跑通才想明白它们根本不在同一个抽象层级上。把层级关系搞清楚后面所有代码和配置才有意义。1.1 四个组件不在同一个抽象层级我把这四件套放到下面这张表里你一眼就能看出区别组件管的层级生活化类比DeepAgentsAgent 内部的“组织架构”主控拆任务、Subagent 执行、上下文隔离、结果验收项目经理 外包团队MCPAgent 与外部工具之间的“统一调用协议”墙上的插线板A2AAgent 与 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( nameweb_researcher, description负责基于给定主题检索公开信息输出带来源的结构化笔记。, tools[web_search_tool], max_iterations6, ) doc_subagent create_agent( namedoc_reader, description负责读取本地文档并输出摘要。, tools[document_loader_tool], max_iterations4, ) main_agent create_deep_agent( tools[report_tool], subagents[research_subagent, doc_subagent], max_subagent_depth2, )写 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/mcplatest] }, 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 来描述一整件工作而不是单次函数调用。我用一张表总结两者差异维度MCPA2A交互单位工具调用任务Task两侧角色Agent ↔ 工具服务Agent ↔ Agent双方都可发起典型方法tools/calltasks/send是否支持异步通常偏同步原生支持异步、流式、推送解决的核心问题手不够长协作不通4.2 Agent Card、Task、Message 是 A2A 的三根柱子A2A 规范里每个 Agent 先提供一个公开的 Agent Card相当于服务发现页。卡片里写清我是谁、能干什么、怎么联系、支持什么能力。接着是 Task代表一次完整的活儿再往下一层是 MessageTask 的输入输出都通过 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 Serverplaywright、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 集群建议先从最小闭环跑通再用这四个组件一点点把边界撑开。
阅读完成 · 觉得有帮助？
