这套组合最近在智能体开发圈子里讨论得确实很凶。我手上的项目正好是在解决一个大脑不够用、工具链越来越杂、多个智能体各干各的这类典型问题从单代理硬撑到拆成多智能体集群把 DeepAgents、MCP、A2A、Skills 四个东西全部串在一起跑通了。这篇东西不打算做成概念科普而是把我从环境搭建、集群设计、协议联调、技能封装到最终跑完全流程的完整过程拆给你看尤其是那些文档里不会写、只有真上手才会撞到的坑。1. 为什么我最后选了 DeepAgentsMCPA2ASkills 这套组合先说结论这四个东西不是同层替代关系它们各自解决的是任务组织、工具接入、代理互通、能力沉淀四个完全不同的问题。很多人把 MCP 和 A2A 混在一起聊这其实是个大误区。1.1 它们之间的职责边界我习惯用一个比方来解释这套组合DeepAgents 是项目经理MCP 是员工手里的各种办公软件和接口A2A 是公司与公司之间的合同和对接流程Skills 则是项目组沉淀下来的标准作业手册。DeepAgents 负责把一个大任务拆成子任务调度多个子代理并行或串行执行最后把结果汇总。MCP 负责让每个代理能真正碰到外部世界——浏览器、数据库、文件系统、第三方 API统一用一套协议接入不再为每个工具写一套私有适配。A2A 负责跨代理、跨平台甚至跨厂商的通信解决的是我这个代理怎么调用你那个代理的问题。Skills 负责把高频操作和领域经验固化下来让代理碰到同类任务时不用从零推理直接按技能包走。1.2 为什么不是单一框架大包大揽我前期也试过只用某一个全家桶方案效果都不理想。单框架方案最大的问题是它把所有智能体都限制在同一个运行时里你需要什么能力都得在这个框架内找插件。但现实是很多好用的 MCP Server 是独立生态比如 Playwright MCP 做浏览器自动化、Chrome DevTools MCP 做前端调试、文件系统 MCP 做本地文件操作这些工具各有各的维护社区不会因为你选了一个框架就自动适配。DeepAgents 好就好在它对 MCP 工具的原生支持比较完整不需要我自己封装工具适配层。A2A 则是补上了外部代理这一块——当你的集群里需要接入一个不是你用 DeepAgents 写的、甚至跑在别人服务器上的代理时A2A 是当下比较现实的互通协议。Skills 则是把团队里的经验从对话里的临时指令升级成版本化、可复用、可共享的能力包。1.3 这套组合适合什么样的场景如果你的项目只是单轮问答、简单工具调用用这套组合属于杀鸡用牛刀。但如果你面临这些情况就可以考虑上了任务本身需要多步骤、多领域协作比如调研竞品 → 整理数据 → 生成前端页面 → 走查调试一条龙。你有超过 5 个工具需要接入且工具之间没有天然联动逻辑。你手上已经有一套代理服务不想推翻重来需要和新建的集群互通。团队里积累了大量可复用的操作经验希望让代理直接继承而不是每次重新训练或重新描述。我这次的项目就是典型需要同时调度浏览器自动化、本地文件操作、前端代码生成、外部数据查询等能力并且任务之间有强依赖顺序。这种情况下单一代理的上下文窗口和工具切换效率完全扛不住。2. 先搭地基MCP 服务接入的正确姿势别一上来就写 DeepAgents 的集群代码。MCP 是这套体系的地基地基没打牢后面全白搭。我第一天就在 MCP 连接上耗了大半天所以这块值得单独讲透。2.1 MCP 的传输方式怎么选MCPModel Context Protocol本质上是一个基于 JSON-RPC 的协议规定智能体怎么发现自己能用什么工具、怎么调用工具、工具结果怎么返回。传输层大概有几种方式传输方式适用场景我踩过的坑stdio标准输入输出本地进程随代理启动而启动Windows 下路径带空格经常崩SSE服务端推送事件远程服务支持事件推送连接复用差断线重连要自己处理Streamable HTTP远程服务更现代的替代方案部分老版本客户端兼容性有问题WebSocket双向实时通信低延迟鉴权信息要放在连接头里容易被忽略我本地开发主力用 stdio因为简单可靠代理进程拉起子进程就能通信。生产环境建议走 Streamable HTTP 或 WebSocket方便横向扩展和远程访问。2.2 一份能跑的 MCP 配置长什么样DeepAgents 读取 MCP 配置的方式是标准化的我用一个 JSON 文件管理所有 server{ mcpServers: { playwright: { command: npx, args: [-y, playwright/mcplatest], env: { BROWSER_HEADLESS: true } }, fetch: { command: uvx, args: [mcp-server-fetch] }, filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, /workspace/data] }, chrome-devtools: { command: npx, args: [-y, chrome-devtools-mcplatest] } } }这里有个关键点每个 MCP Server 只给它最小权限。比如 filesystem 我只开放了/workspace/data这个目录而不是整个磁盘。浏览器自动化默认 headless避免弹出真实窗口干扰。2.3 连接调试的几个必经步骤配置写完之后第一件事不是直接让代理去调用而是先用 MCP 的调试工具验证 server 本身能不能起来、工具清单能不能正常拉取。建议按这个顺序排查手动在终端执行 command 部分确认进程能起来依赖已安装。npx 首次执行要下载包慢是很正常的。用 MCP Inspector 加载配置检查工具的 name、description、inputSchema 是否正常返回。这一步能发现大部分 JSON 格式和路径问题。逐个调用一次最简单的工具确认返回结果结构符合预期。确认 DeepAgents 的配置里 MCP server 名称与 JSON 中完全一致大小写一个都不能错。我在第一步就栽过当时配置里填的command写成了绝对路径带空格Windows 直接把参数截断了。后来改成用npx -y 包名这种形式让系统自己去 path 里找问题才解决。2.4 MCP 工具调用失败的常见原因实测中 MCP 工具调用失败大概有三类原因遇到过的人肯定有共鸣超时MCP 默认超时时间比较短遇到浏览器打开大页面、文件读取慢的场景代理那边已经报错Server 这边还在执行。处理办法是在配置里调大超时或者在代码中给工具调用设置更长的等待时间。工具描述不准确MCP Server 返回的 description 写得太模糊代理无法判断该不该用这个工具。后来我养成了一个习惯自己写的 MCP Server 会在 description 里写清楚什么场景用、输入是什么、输出是什么别指望代理能猜。并发冲突两个子代理同时调用同一个无状态 MCP Server 没问题但如果同一个 Server 内部是有状态的比如同一个浏览器实例就会互相踩。这个在后面集群部分会详细说。3. DeepAgents 集群搭建从单代理到可调度的子代理体系MCP 通了之后真正的重头戏才开始。DeepAgents 的核心价值在于它把一个代理什么都干变成了一个主管代理 一群专业子代理的层级结构而且每个子代理可以有自己的工具集、系统提示词和上下文窗口。3.1 集群的拓扑形态先想清楚我这次设计的是三级结构顶层一个 Coordinator协调者中间按领域拆了三个执行代理——Browser Agent浏览器自动化、Dev Agent代码生成与调试、Data Agent数据查询与分析底层是所有 MCP 工具资源。这种设计的好处有三个上下文隔离。每个子代理只关心自己的领域系统提示词可以写得很具体不会被其他领域的指令干扰。工具权限收敛。Browser Agent 只有 playwright 和 chrome-devtoolsDev Agent 只有 filesystem 和 fetch不会出现一个代理手里握着十几个工具导致选择困难。故障影响面小。某个子代理崩了主管可以重新拉起它不会拖垮整个集群。3.2 DeepAgents 创建子代理的代码骨架用 DeepAgents 创建子代理比较简单关键是给每个子代理配好名字、描述、系统提示词和工具集合from langchain_deepagents import create_agent from langchain_deepagents.types import AgentRole browser_agent create_agent( namebrowser_agent, roleAgentRole( name浏览器自动化工程师, description负责网页访问、表单填写、页面截图、DOM 操作等浏览器相关任务, system_prompt( 你是一个浏览器自动化专家。你只能处理与网页交互相关的任务。 遇到与代码调试无关的请求明确拒绝并返回给主管代理。 不要使用文件系统工具不要尝试读取本地文件。 ), ), mcp_servers[playwright, chrome-devtools], ) dev_agent create_agent( namedev_agent, roleAgentRole( name前端开发工程师, description负责根据需求生成前端代码、修改文件、执行代码质量检查, system_prompt( 你是一个资深前端开发。你负责项目目录下的代码编写与重构。 只允许读取 /workspace/project 目录禁止访问其他路径。 写代码前先给出你的实现方案等待确认后再动手。 ), ), mcp_servers[filesystem, fetch], ) data_agent create_agent( namedata_agent, roleAgentRole( name数据分析师, description负责数据检索、清洗、统计分析和报告整理, system_prompt( 你是一个数据分析师。你负责从远程数据源获取数据进行结构化整理。 所有数据结论必须附带来源和统计方法。 ), ), mcp_servers[fetch], )注意 role 里面的 description 是主管代理用来做任务路由的写得越具体越准确路由命中率越高。我见过很多人 description 写得很笼统结果主管把所有任务都丢给第一个代理整个集群形同虚设。3.3 主管代理如何聚合子代理主管代理同样用 create_agent 创建但不需要绑定具体 MCP 工具而是把三个子代理作为可调度的工具注册进去from langchain_deepagents import create_agent_team team create_agent_team( coordinator_system_prompt( 你是任务协调者。收到用户需求后 1. 拆解任务步骤 2. 识别每个步骤需要的专业能力 3. 将步骤分配给对应的子代理按顺序执行 4. 汇总各代理结果检查是否符合用户要求 5. 若某一步失败重新调度最多重试 2 次。 ), agents[browser_agent, dev_agent, data_agent], )这里我用的是 create_agent_team它会自动把三个子代理包装成主管可见的工具型调用接口。每个子代理的 response 会作为下一次调度的依据所以子代理返回结果的结构化程度很重要。我让每个子代理统一返回 JSON 格式的{status: success, result: ..., metadata: {...}}主管解析起来很顺畅。3.4 集群状态管理与任务编排集群跑起来之后最大的问题不是单个代理能力而是任务编排的可靠性和状态一致性。我的经验是把任务编排分成四个阶段需求解析阶段主管把用户原始需求拆成结构化步骤每步标注依赖关系和负责代理。资源准备阶段检查所需 MCP Server 是否在线子代理是否可用文件目录是否存在。执行阶段按拓扑顺序调度有依赖的步骤串行无依赖的并行。结果校验阶段主管调用一个校验代理或者自己直接检查确认输出符合原始需求不符合则打回重做。状态管理这块我强烈建议不要依赖内存里的变量来传递中间结果。两个子代理之间要共享的数据明确落到工作目录的 JSON 文件里或者通过 A2A 消息传递而不是让主管代理把一大段上下文塞给下一个代理。塞多了必爆上下文窗口而且 token 成本会高得离谱。4. A2A 打通跨框架协同的实践路线DeepAgents 解决的是你自己集群内部的协同。但真实项目里你经常会遇到别人的代理更好用或者老系统里的代理不想推倒重来的情况。这个时候 A2AAgent-to-Agent就派上用场了。4.1 A2A 和 MCP 到底什么关系一句话说清楚MCP 是智能体和工具之间的协议A2A 是智能体和智能体之间的协议。它们不冲突而是配合使用——我的代理通过 MCP 调用浏览器通过 A2A 调用你的代理你的代理内部再用它自己的 MCP 工具链完成任务。A2A 的核心能力有三个Agent Card每个代理对外发布一个描述文件说明自己叫什么、能干什么、输入输出格式是什么。Task 生命周期管理通过tasks/send、tasks/get、tasks/cancel这些方法管理一次任务的发起、查询和取消。消息与部件任务消息由多个部件组成支持文本、文件引用、结构化数据等多种形式。4.2 让 DeepAgents 集群接入 A2A 网络我的做法是在 DeepAgents 集群外面套一个 A2A 网关。这个网关负责把外部 A2A 请求转成 DeepAgents 的内部任务再把 DeepAgents 的结果转成 A2A 响应格式。这样集群内部逻辑完全不用改对外暴露的只是一套标准 A2A 接口。网关收到一个 A2A 请求后处理流程大致是解析 Agent Card确认调用方代理的身份和权限范围。校验请求中的任务描述做一次轻量级的内容安全检查。把任务描述转成一条伪用户消息发给 DeepAgents 主管代理。主管代理走正常的拆解、调度、执行流程。结果汇总后网关把最终输出转成 A2A 的 Task 状态和消息部件返回给调用方。4.3 一个最小可用的 A2A 请求长什么样A2A 的协议层基于 JSON-RPC 2.0。一个典型的任务发起请求长这样{ jsonrpc: 2.0, id: req-001, method: tasks/send, params: { id: task-0042, message: { role: user, parts: [ { type: text, text: 抓取目标页面并生成一份前端展示页面 } ] } } }对应返回{ jsonrpc: 2.0, id: req-001, result: { id: task-0042, status: { state: completed, message: { role: agent, parts: [ { type: text, text: 已完成页面路径为 /workspace/project/index.html }, { type: file, file: { name: index.html, mimeType: text/html, path: /workspace/project/index.html } } ] } } } }4.4 跨框架联调最容易出问题的环节我实际联调时踩过几个坑值得单独说Agent Card 里写的 description 太简陋调用方代理根本不理解你的代理能干什么导致它宁可自己做也不愿意调用。这个跟 MCP 工具描述一个道理描述是给另一个 AI 看的不是给文档评审看的。任务状态同步不及时。A2A 协议支持同步返回和异步轮询两种模式长任务必须用异步。但很多实现里代理执行完了忘了更新任务状态导致调用方一直轮询到超时。超时和重试机制要适配具体场景。不同代理执行速度差异巨大有的毫秒级有的可能要好几分钟。统一用一个超时时间完全不现实需要按任务类型配置不同的超时策略。消息部件里的文件引用路径在跨 Agent 时经常失效。本地路径只有你自己能访问跨网络必须转成可下载的 URL 或者直接内联内容。5. Skills 技能库把经验沉淀成可复用的智能体能力MCP 管的是能访问什么Skills 管的是知道怎么做得更好。一个团队如果只是不断给 AI 发指令那每次都等于重新开始有了 Skills类似任务可以直接加载既有打法。5.1 Skills 到底是个什么东西Skills 本质上是一套带结构化描述的指令包。它包含一个 SKILL.md 主文件描述技能用途、触发条件、使用步骤以及可能附带的脚本、模板、参考文档。智能体在收到任务时会根据任务描述去匹配可用的技能匹配上了就按技能里的流程执行。和 MCP 工具的差异在于MCP 工具是外部能力的接入点Skills 是知识和工作流的固化。同一个 MCP 工具可以被很多技能使用同一个技能也可以调用多个 MCP 工具。5.2 一个 Skills 包的目录结构我整理的技能库长这样skills/ ├── web-research/ │ ├── SKILL.md │ ├── research_flow.py │ └── templates/ │ └── report_template.md ├── frontend-gen/ │ ├── SKILL.md │ ├── generate_page.py │ └── prompts/ │ └── page_spec.md └──>--- name: web-research description: 多来源信息检索与结构化整理技能。适用场景竞品调研、资料搜集、舆情整理。使用前需要 fetch 和 playwright 两个 MCP 工具处于可用状态。 ---然后是正文明确写出技能目标适合与不适合使用的边界条件执行步骤步骤越具体越好每一步说明输入和期望输出需要调用的工具与数据源常见失败情况和兜底策略5.3 如何让智能体正确加载和触发技能触发机制是我调试最久的部分。技能描述写得不好代理要么不触发要么乱触发。我总结出三条经验description 里必须包含触发关键词、适用场景和输入要求。比如竞品调研资料搜集这种高频触发词必须出现在描述里。技能描述里不要写泛泛的用于提高效率这种空话要把什么情况能解决什么问题说清楚。技能的 bodies 里的内容要足够完整让代理可以直接照着执行而不是看完了还得自己发挥。加载技能的方式我现在用的有两种一是把技能库挂载到全局让主管代理在做任务规划的时候自动匹配合适技能二是在具体子代理的 system prompt 里显式指明你优先使用这些技能收窄选择范围。实测下来第二种的准确率高很多代价是需要人工维护技能和代理的对应关系。5.4 有哪些值得先沉淀的技能类型根据我这次项目的实践下面几类技能性价比最高浏览器自动化类页面元素定位、表单填写、截图、内容提取。这类操作每次都要重新描述细节太浪费沉淀成技能后一条指令就触发。前端代码生成类根据设计规范生成组件代码、根据截图还原页面。团队内部的设计规范可以写进 skill 里保证每次生成的代码风格一致。数据处理类CSV 清洗、格式转换、基本统计分析。这类技能稳定且高频。报告生成类把零散结果整理成结构化报告定义好输出模板。调试排查类比如遇到某类报错时的标准排查路径。这类技能把团队踩过的坑固化成流程新代理上来就能复用老经验。网上也有一些公开技能库可以直接借鉴比如 Superpowers 技能包这类社区项目里面的技能组织方式值得学习。我的态度是可以参考别全套照搬因为技能这玩意儿越贴合你自己的工具链和业务场景越好用。6. 全流程实战从我要一个竞品分析页面到跑通的完整链路理论讲多了容易飘直接走一个完整例子。这个任务是我实际跑过的简化版用户给一句话需求对竞品官网做一次信息架构分析生成一份竞品分析报告页面。6.1 需求如何被拆解用户这句话最终被主管代理拆成了五步用 Browser Agent 打开竞品官网收集页面结构、导航菜单、核心文案。用 Data Agent 从公开渠道搜集竞品相关的背景信息并结构化。用 Dev Agent 根据前两步产出创建前端页面。用 Browser Agent 对生成的页面做自动化走查确认关键信息都在。给用户呈现最终结果和阅读指引。每一步之间是有依赖的没有页面结构数据就做不了分析没有分析结论就生成不了报告页面。所以主管把执行方式定为串行创建了一个任务状态文件不断更新。6.2 每个环节的关键动作和现象Browser Agent 跑起来的时候它通过 Playwright MCP 打开了目标站点提取站点地图和关键页面锚文本。这一步我观察到一个有意思的现象代理并没有一次性把所有内容都抓下来而是先抓了首页框架然后根据首页上的导航链接决定下一步点进哪些子页面——它自己会做信息优先级判断这是我写技能之前没想到的。Data Agent 那边用的是 fetch MCP 抓取公开资料做了简单的来源去重输出了一张 Markdown 表格。表格里除了信息本身还有来源 URL 和抓取时间方便后面报告引用。Dev Agent 拿到上面两个结果之后按照我们预置的前端生成技能先输出了一段页面结构方案让管理员确认。这里我们的集群被设置成写代码前先给方案的模式防止它乱来。确认后它直接生成 HTMLCSS 文件到工作目录。Browser Agent 最后一步又用 Playwright 打开了生成的 HTML 文件检查标题、关键区块、图片是否正常渲染。这个走查很快60 秒左右就完成了没有任何安全风险操作全程只是静态页面检查。6.3 最终结果和一次失败重试整个流程跑完大概 6 分钟。中间遇到一次失败Dev Agent 第一次生成的页面里有一个数据表格的列宽设置异常被 Browser Agent 的走查脚本识别为疑似样式错误。主管代理没有把错误直接抛给用户而是把走查报告传回给 Dev Agent让它修复后再走一遍走查流程第二次通过了。这个自动重试闭环给我印象很深如果没有集群架构单代理处理这种写代码 → 验证 → 发现问题 → 修复 → 再验证的循环要么得靠人一次次手动干预要么上下文早就满了。6.4 这个流程里的 Skills 和 MCP 起了什么作用回过头来看这个任务里 Skills 和 MCP 的配合是这样的MCP 提供了浏览器操作、文件读写、网络请求的能力Skills 定义了两套核心工作流——一套是竞品研究的标准步骤一套是前端页面生成的规范。代理在大部分时刻不是在思考该怎么做而是在按技能执行遇到异常再判断。这保证了整个过程的稳定性和可复现性。这也是我对这套组合目前最大的体会多智能体的价值不在于看起来有很多 AI 在干活而在于它可以精确控制每一步的执行质量、隔离故障、沉淀流程。集群架构把复杂度收纳起来了用户面对的还是那一句话的需求入口但背后已经是一个小型团队在协同。7. 落地后的踩坑清单与调优建议最后这部分是纯实战经验汇总按坑的类型分类都来自真实运行中的问题排序按我踩到的频率从高到低。7.1 MCP 层面的高频坑与对策MCP 的坑多数集中在连接和权限两侧。连接侧最常见的是 stdio 模式下 npx 首次下载依赖过慢导致超时解决方法是提前手动执行一次 npx 命令把包缓存好或者直接改用 Streamable HTTP 模式把 Server 常驻后台。权限侧最常出问题是配置给得太宽filesystem 直接开了根目录代理一旦被恶意提示词诱导后果很严重。我现在的原则是每个 Server 的权限都收紧到最小目录、最小域名集。7.2 集群编排的常见设计误区第一个误区是子代理数量贪多。子代理不是越多越好每多一个代理就多一份调度损耗和上下文传递开销。我后面把三个执行代理压到了两个场景专用合并掉了一些边界模糊的角色反而更丝滑。第二个误区是所有代理共享同一组 MCP 工具。这让代理之间互相踩脚而且主管在路由时也分不清该给谁。工具的收敛是集群设计的关键动作每个代理只留自己领域内的工具。第三个误区是中间结果全塞给主管代理转述。主管上下文很容易爆炸。我的做法是让子代理把中间产物落盘为文件主管只见文件的路径和摘要需要时再由对应代理读取。这样主管的上下文保持精简能更好地把注意力放在任务编排上。7.3 Skills 的维护和迭代节奏技能库不是建完就完它会像代码库一样腐化。我现在的维护节奏是每个任务跑完后检查有没有明明做了但没形成规范的操作有就补进对应技能每条技能如果连续三次没有被触发复盘原因要么合并到其他技能要么删除。描述模糊导致不触发是最常见的删除理由。技能版本化也建议做我是直接用 Git 管理的每个技能包的变更走 PR 评审避免有人在技能里埋入激进指令改动全局行为。7.4 成本与效率的调优方向多智能体集群最大的隐形开销是 token。每一个子代理都在独立消耗上下文每一次主管汇总又叠加一层。我试过最烧钱的配置是全部分支并行 详细结果全量回传单次任务的 token 消耗是串行模式的 3 倍多。调优的方向是子代理结果只回传摘要完整数据落盘。并行度控制不是每个环节都能并行强依赖的步骤老老实实串行。给主管代理设置明确的最小汇总要求避免它把每个代理的日志都复述一遍。用表格总结一下我最后的推荐参数调优项推荐做法踩过的教训子代理数量3-5 个足够超过 8 个调度开销显著上升工具权限每个代理 2-3 个 MCP 工具全量共享导致路由混乱上下文传递中间结果落盘传路径摘要全量回传致上下文爆炸技能触发按子代理显式指定技能集全局技能库触发准确率低任务重试最多 2 次失败即上报无限重试浪费 token超时设置按工具类型差异化统一超时导致误判失败8. 这套组合后续还能怎么玩写到这里不打算做那种核心思想总结的收尾。最后分享一个我最近在试的方向把 A2A 网关做得更薄让外部代理可以直接通过自然语言描述任务而不是每次都构造结构化任务消息。另一条线是把 Skills 的仓库做成团队内共享服务用 Git 作为底层存储配合 Webhook 实现技能更新推送这样集群在运行中就能提前加载最新技能。最后一个念头是把这套组合接进 IDE 开发环境里利用 Chrome DevTools MCP 让智能体直接参与前端调试闭环。这几个方向我目前都在跑原型等有稳定结果后再单独写一篇记录。如果你也在搭类似的多智能体集群建议先从最小可用闭环开始——一个主管、两个子代理、三个 MCP 工具、两个技能跑通之后再逐步扩展。这套组合最忌讳一上来就铺开一个大而全的架构因为它本身分层就多分层多意味着每个环节都有出问题的可能小步快跑才是稳妥路线。