做多智能体项目最头疼的从来不是单个 Agent 不够聪明而是几个 Agent 凑在一起之后怎么让它们稳定协作。我最近把一个从设计稿到前端页面的完整流程完整跑通最大的感受就是DeepAgents、MCP、A2A、Skills 四件套才是多智能体开发真正能落地的基础配置。这篇文章适合谁正在折腾多智能体但卡在“各 Agent 各说各话”的人、已经会用 Claude Code / Codex 但没试过把多个 Agent 串起来的开发者、想搞清楚 MCP 和 A2A 到底什么区别的学习者。我会从架构理解讲起一直讲到可直接参考的配置和编排流程最后把实战里踩过的坑一并交代清楚内容不算短但对得起你花的时间。1. 先搞清楚一件事DeepAgents 这套多智能体栈到底解决什么问题1.1 单 Agent 做项目时真正卡在哪先说个很现实的问题。单个大模型 Agent 跑一个简单任务比如“总结这篇文档”“写一段 Python 脚本”体验其实不错。但一旦任务变成“从设计稿生成一个完整前端页面还要符合项目规范、可维护、能通过代码检查”单 Agent 通常会在三个地方卡死第一上下文窗口是硬上限。一个页面涉及需求文档、设计稿标注、组件库规范、历史代码风格全塞进一个上下文里还没开始写代码先把 token 预算烧光了然后开始丢三落四。第二单线执行效率低。很多子任务是并行的比如页面头部、底部、中间的业务模块互相不依赖但单 Agent 只能一个一个处理。第三能力和职责混在一起。同一个 Agent 既要做需求分析又要写代码又要自查角色切换本身就是很大的 token 浪费而且容易把分析阶段的结论带到编码阶段去。所以我当时的判断是不能继续在单 Agent 上堆 Prompt 了必须拆成多智能体架构。1.2 MCP、A2A、Skills 各自解决的是哪一层问题多智能体架构听起来美好但拆开之后立刻冒出一堆新问题每个 Agent 怎么接入外部工具Agent 之间怎么互相通信能力怎么沉淀避免每次从零开始这就是 DeepAgents MCP A2A Skills 这套组合存在的意义。我用一个比较直白的比喻来理解它们的分工MCP 解决的是 Agent 怎么“动手”。Model Context Protocol 把所有外部工具接入统一成了标准协议Agent 不用再为每个工具单独写对接代码。A2A 解决的是 Agent 怎么“开口”。Agent2Agent 协议定义了智能体之间如何发现彼此、发送任务、回传结果让多 Agent 协作从“黑话互怼”变成“标准对话”。Skills 解决的是 Agent 怎么“长记性”。把一次实践中积累的操作流程、代码范式、注意事项打包成结构化技能文件之后同样的任务直接调用不用重新写 Prompt。DeepAgents 这类编排框架解决的是前几者怎么“组合”。它负责创建 Agent 实例、分配任务、调度执行顺序、汇总结果。这四层是互补关系不是替代关系。很多人搞混了以为 MCP 做好就不需要 A2A或者 Skills 可以替代 MCP实际完全不是一回事。1.3 DeepAgents 在整条链路里扮演的角色DeepAgents 在这里扮演的是“调度中枢”。它做的事情可以概括为定义每个子 Agent 的角色、给每个子 Agent 注入对应的 MCP 工具与 Skills、把一个大任务拆成子任务并按依赖关系编排、最后汇聚各个 Agent 的输出。我在做项目拆解时会把 DeepAgents 类比成一个软件研发团队里的技术负责人。它自己不一定写每一行代码但它清楚谁负责什么、谁的工具链是什么、谁做完之后下游该接给谁。这套思想在任何领域都适用不一定非得是写代码。需要提醒的是并不是所有项目都适合拆成多智能体。我见过有人连“写一篇周报”都要拆三个 Agent纯属没事找事。判断标准很简单任务里是否存在明显的子任务边界、子任务是否可以并行或分阶段执行、各子任务是否需要不通用的工具或知识。如果三个问题的回答都是否那一个 Agent 带一两个 Skill 反而更高效。2. MCP 不是魔法它是把工具调用标准化了——链路拆解与配置实战2.1 MCP 本质上是“AI 应用的 USB 接口”聊 MCP 之前先回顾一下没有 MCP 的时候给 Agent 接一个外部工具有多痛苦。假设我要让 Agent 读取蓝湖设计稿的标注信息。传统做法是写一个 Python 脚本调用蓝湖 API然后想办法把数据塞进 Agent 的上下文里。如果再加一个 Figma、一个数据库、一个文件系统每个工具都是一套独立的 API、独立的鉴权、独立的错误处理。Agent 生态稍微扩大代码量就以几何级数增长。MCP 的贡献在于它定义了一套统一的标准Agent作为 Host通过 MCP 客户端连接 MCP ServerServer 向外暴露“工具”Agent 只要理解了 MCP 协议就能调用任何符合协议的 Server。就像 USB 接口设备只要符合标准插上就能用不用关心里面是键盘还是 U 盘。这里有一个关键认知MCP 的核心是“标准”不是某个具体的库或软件。它是一套协议包含传输方式、消息格式、工具发现与调用机制。理解了这一点你在配置各种 MCP Server 时就不会被具体工具名绕晕。2.2 Host、Client、Server 三个角色别搞反MCP 体系里一共有三个角色角色作用示例MCP Host运行 Agent 的宿主环境负责发起会话DeepAgents、Claude Desktop、IDE 插件MCP ClientHost 内部与 Server 建立连接的通信层通常由 SDK 封装使用者无感知MCP Server提供具体工具能力的服务可以本地进程也可以是远程 HTTP 服务蓝湖 MCP、Figma MCP、文件系统 MCP配置的时候最容易犯的错就是把 Host 和 Server 搞混。比如有朋友跑来问“我的 MCP Server 怎么连不上 Claude”我一看他把配置写在了某个工具的配置文件里但这个工具本身并不是 Host。记住一个口诀Agent 跑在 Host 里Server 是 Agent 要调用的外部能力Client 是中间那根线。2.3 实际配置以蓝湖 MCP 和 Figma MCP 为例MCP 的配置通常是一个 JSON 文件不同 Host 文件的路径不一样但结构大同小异。这里给一个我在 DeepAgents 场景里的配置示例{ mcpServers: { lanhu: { command: npx, args: [-y, lanhu-mcp/server], env: { LANHU_TOKEN: 你的蓝湖访问令牌 } }, figma: { command: npx, args: [-y, figma-developer-mcp], env: { FIGMA_API_KEY: 你自己的 Figma API Key } } } }为什么用 npx 拉起因为很多 MCP Server 以 Node 包形式发布npx 可以免安装直接执行每次启动时自动拉取最新版本。代价是首次启动会慢一点因为要下载包。如果你对稳定性要求高可以先用 npm install -g 把包装到全局再把 command 改成直接的二进制路径比如command: lanhu-mcp。配置蓝湖 MCP 时有个非常隐蔽的坑LANHU_TOKEN 的获取入口不在 MCP 文档里而是在蓝湖开发者后台的个人令牌页。很多人在配置文件里写了一个“自己的密码”结果鉴权一直失败怀疑人生半天才发现找错了入口。Figma 那边同理需要去 Figma 账号设置里生成 Personal Access Token注意权限范围至少勾选 File content 读取权限。2.4 设计稿还原场景里 MCP 到底帮了什么忙我在实战项目里做“设计稿到前端页面”时MCP 的核心价值有四个一是标注即取即用。以前人工要看设计稿的间距、字号、颜色需要打开蓝湖网页逐项复制现在 Agent 直接通过 MCP 把节点的标注、切图 URL、样式 Token 拿过来精确到像素。二是切图不用手导。Figma MCP 提供的工具里包含图片导出相关能力Agent 可以根据需要把图层导出成 PNG 或 SVG存入本地后在编码时直接引用整个链路自动化程度大幅提升。三是参数有了上下文。MCP Server 返回的数据结构是带语义的Agent 知道这个值是“按钮圆角”还是“卡片阴影”不是一串无意义的数字。四是多 Agent 共享同一套工具。前面的项目经理 Agent 不需要调用 Figma但设计还原 Agent 需要。通过 DeepAgents 按角色注入 MCP Server每个 Agent 看到的是自己那部分工具集权限边界也清晰了。2.5 配置 MCP Server 时的常规排查链路如果 MCP Server 连不上我排查的顺序是固定的先确认 Server 进程能不能单独跑起来。直接在终端执行配置里的 command args看有没有报错。再确认启动参数里的环境变量是否正确。很多 Server 启动时静默失败实际是环境变量没读取到。检查 Host 的配置文件语法。JSON 多一个逗号少一个引号都会导致整个配置不加载而且很多 Host 不会给错误提示。确认传输方式。stdio 类型的 Server 必须由 Host 启动子进程不能用 HTTP URL 去连streamable HTTP 类型的 Server 必须配置 URL 而不是本地命令。这两类搞错了基本必跪。最后才考虑网络问题。远程 Server 的域名解析、防火墙、鉴权头都属于这里。这套排查链路我后来直接贴到了团队文档里新人照着走一遍能解决九成的连接问题。3. A2A 补上的是智能体之间的“对话协议”以及怎么观测它们的协作3.1 有了 MCP为什么还需要 A2A这是我在交流时被问得最多的问题。MCP 统一了 Agent 与工具之间的调用标准但 Agent 与 Agent 之间呢你可以想象一个场景需求解析 Agent 分析完需求文档要把结论交给架构 Agent架构 Agent 拆好组件后要把接口定义传给前端编码 Agent。如果这些信息传递靠的是“把结果写成 JSON 文件放在某个目录里”那每换一种协作方式就要重写一遍代码而且完全不可观测。A2A 协议解决的正是这个问题。它定义了一套智能体之间的标准交互方式一个 Agent 如何向外声明自己的能力和地址、如何接收来自另一个 Agent 的任务、如何返回进度和最终结果、如何在任务处理中交换非文本的“工件”。MCP 是“人Agent与工具”之间的协议A2A 是“Agent 与 Agent”之间的协议两者服务的是不同层。MCP 管的是手A2A 管的是嘴。3.2 A2A 的核心要素Agent Card、任务与消息A2A 里最重要的概念有三个Agent Card、任务、消息。Agent Card 是智能体对外发布的“名片”包含名称、描述、能力列表、接入地址URL等信息。其他 Agent 想找谁干活先拉取对方的 Agent Card看它的能力描述是否匹配需求再决定是否把任务发过去。这部分设计很像微服务架构里的服务注册与发现只不过服务提供方从“接口”变成了“智能体”。任务Task是一个完整的、有状态的工作单元。发起方创建一个任务给接收方接收方接受后持续更新状态比如 pending、working、completed、failed。任务可以关联消息也可以关联工件。工件Artifact用来传递非文本形式的结果比如图片、表格、代码文件。实际体验下来A2A 最大的价值是把“Agent 之间的协作”从代码层面解耦了出来。以前我在 DeepAgents 里让两个 Agent 协作直接在编排代码里写死“A 完成后调用 B”一旦要调整角色或者插入新 Agent就要改代码。引入 A2A 概念后每个 Agent 只关心“谁能完成这件事”而不是“下一个要调谁的函数”。3.3 编排式协作与对等式协作怎么选多智能体的协作模式我把它粗分成两类编排模式Orchestrator-Worker一个主控 Agent 负责任务拆分、分配、结果校验其他 Agent 干完活把结果交回主控。好处是流程可控、出错易定位坏处是主控容易成为瓶颈。对等模式Peer-to-Peer没有中心主控Agent 之间通过 A2A 协议互相委托任务有点像工作流里的事件驱动。好处是灵活坏处是流程不确定性高排查难度大。我的经验是项目初期强烈建议先用编排模式哪怕牺牲一点效率。因为你只有在“能稳定复现”的前提下才谈得上优化。我见过一上来就搞全对等协作的团队Agent 之间互相踢皮球一个任务在系统里转圈最后谁也不认账。先让主控 Agent 把节奏控制住跑通之后再把那些耗时较长、子链路成熟的部分切换成对等委托。3.4 用 Langfuse 观测多智能体协作的调用链多智能体系统上线后你一定会遇到一个问题这个结果是谁产出的中间经过了哪几个 Agent每个 Agent 调用了哪些工具耗时多少如果没有可观测性出了问题只能翻日志甚至只能靠猜。我用的方案是把 Langfuse 接进整个流程。Langfuse 本身是一个 LLM 应用的追踪与可观测平台支持把一次完整的请求记录成一条 tracetrace 里嵌套多个 span。在多智能体场景下我会按这样的粒度打 span最外层 trace 对应一个端到端任务比如“生成前端页面”第二层 span 对应每个 Agent 的执行过程带上 Agent 名称和角色第三层 span 对应具体的步骤比如 MCP 调用、A2A 消息发送、Skills 加载这样打开 Langfuse 的界面就能看到一条清晰的链路主控 Agent 把任务派发给设计还原 Agent设计还原 Agent 调用 Figma MCP 拉取设计稿信息耗时 3.8 秒接着把结果通过 A2A 发给前端编码 Agent该 Agent 加载了 React Skills耗时 12.4 秒。哪一段异常一眼就能定位。有个细节值得提醒A2A 消息的传递内容一定要在 span 里记录摘要不要只记“发送成功”四个字。否则回看链路时你只看到 Agent A 发了一条消息给 Agent B但完全不知道发了什么问题依然没法定位。我在记录时会包含消息类型、任务 ID、关键内容的前几百个字符成本不高收益很大。4. Skills 系统把经验变成可复用资产而不是每次都重写 Prompt4.1 Skills 和 Prompt、插件到底差在哪在 Skills 这个概念火起来之前我们沉淀经验的方式是维护一个巨大的 Prompt 模板比如“你现在是一个前端开发专家请严格按照以下规范输出代码……”。这套做法最大的问题是Prompt 只有文本没法附带参考文件、脚本、示例代码而且所有内容堆在一段话里Agent 难以在合适的时机主动调用。Skills 的做法是把“技能”拆成一个结构化目录。一个典型的 Skill 包含技能描述、使用说明、参考资源、可执行脚本。Agent 可以根据任务判断当前情况是否匹配某个 Skill 的触发条件匹配就加载使用。这个设计让经验沉淀变成了“文件管理”而不是“文字堆砌”。比如我总结了一套公司内部的前端开发规范可以做成一个 Skill描述部分写清楚这个技能适用于什么场景说明部分写清楚规范要求参考资源里放几个标准组件示例脚本里放一个自动跑代码检查的命令。任何新 Agent 加入项目只要挂上这个 Skill立刻就能按公司规范干活不需要重新给它讲一遍。4.2 目录结构与 SKILL.md 的写法不用把 Skills 想得太玄乎一个最基础的 Skill 目录长这样company-fe-skill/ ├── SKILL.md ├── instructions.md ├── templates/ │ └── StandardButton.tsx ├── scripts/ │ └── lint.sh └── assets/ └── style-guide.mdSKILL.md 是入口文件采用 Markdown 格式头部通常是 YAML Front Matter用来声明元信息。下面的写法是我一直在用的--- name: company-fe-skill description: 公司前端页面开发规范与组件使用指南适用于 React TypeScript 项目。 when_to_use: 当任务涉及前端页面开发、组件编写或代码审查时 --- # 公司前端开发技能包 ## 核心规范 - 使用 React 18 TypeScript - 组件文件采用 PascalCase 命名 - 样式方案统一使用 CSS Modules ## 使用流程 1. 阅读 templates/ 目录下的组件模板 2. 开发时参考 style-guide.md 中的设计规范 3. 完成后运行 scripts/lint.sh 检查代码质量 ## 注意事项 - 禁止使用 any 类型 - 图片资源必须走 CDN 地址 - 组件导出必须包含 default export为什么 description 和 when_to_use 这两个字段很重要因为 Agent 在运行时会扫描可用技能列表通过这两个字段判断要不要加载这个技能。写的越具体匹配越精准。我之前见过有人把 description 写成“前端技能包”Agent 几乎不会主动用因为太模糊了它没法判断这个技能和当前任务是否相关。4.3 主流 Skills 生态Codex、Claude Code 与 Superpower目前主流的 Agent 客户端都有自己的 Skills 加载机制。Codex Skills、Claude Code Skills 虽然具体实现有差异但核心思想是一模一样的就是“以目录为单位管理技能通过描述触发加载”。社区里有一个比较有影响力的合集叫 Superpower Skills里面打包了大量整理好的技能覆盖面很广。我的建议是第一次接触 Skills 的人可以先把这个合集装上看几个真实样例学习一下其他人是怎么写 description、怎么组织参考资源的然后立刻动手写一个属于自己场景的小 Skill不要一直在“看别人怎么写”的阶段停留。从我实际使用的情况看下面几类 Skill 的性价比最高代码规范类把团队编码规范打包审查代码时挂上。文档生成类定义了输出大纲、措辞风格、字数要求任何 Agent 写文档都能保持一致调性。图像生成类有些人已经总结了提示词框架和负面提示词参考整合成 Skill 后生图质量稳定很多。结构图类针对图表绘制场景内含流程图、系统架构图的绘图规范与样式要求。4.4 开发一个自有 Skill 的标准流程我自己总结了一套五个步骤的开发流程基本不踩坑先记录下来不要急着整理。在真实项目中把“我这次是怎么做的”完整写下来包括步骤、命令、踩坑点。跑一次验证。把刚写的文本用作 Prompt 让 Agent 重新执行同类任务能跑通再整理。拆分文件。把入口描述、详细说明、模板、脚本拆进不同文件别一股脑堆在 SKILL.md 里。写清理的描述字段。反复打磨 description让 Agent 看一眼就知道什么时候该用。放进共享目录并持续维护。Skills 不是一次性的遇到新边界条件就补充遇到过期信息就更新。这里有一个我反复强调的观点Skills 的价值在于“持续维护”。我见过不少人写了一个 Skill 就再也不管了半年之后里面的技术栈描述已经过时Agent 照着做反而做错。技能和知识一样不更新就会腐烂。5. 全流程实战从零搭一条“设计稿到前端页面”的多智能体流水线5.1 项目设计角色拆分与职责边界实战项目我选的是“把 Figma 设计稿还原成一个可运行的前端页面”这是很多团队刚上多智能体时最喜欢尝试的场景因为边界清楚、工具齐全、效果直观。我一共拆了四个角色再加一个主控Agent 名称职责依赖的 MCP依赖的 Skills主控 Agent接收需求、拆解任务、调度结果、最终输出全局调度任务管理 Skill需求解析 Agent阅读需求描述输出结构化任务清单无需求拆解 Skill设计还原 Agent从 Figma/蓝湖获取标注与切图输出设计规范文件Figma MCP、蓝湖 MCP设计信息提取 Skill前端编码 Agent根据设计规范生成组件与页面代码文件系统 MCP前端开发规范 Skill质量审查 Agent对生成的代码做规范检查与问题反馈终端 MCP代码审查 Skill这个角色的核心设计原则是每个角色只做一件事并且只接触完成这件事所需的最小工具集。设计还原 Agent 不需要终端权限前端编码 Agent 不需要 Figma 权限。权限最小化带来两个好处一是每个 Agent 的上下文更干净不相关的工具不会干扰判断二是安全问题少很多一个 Agent 被“带偏”了破坏半径有限。5.2 环境准备与关键配置这一套的环境准备其实不复杂核心是三步第一步准备 MCP Server。按照第 2 章的 JSON 配置把 Figma MCP 和蓝湖 MCP 配上两个都验证能单独启动。文件系统 MCP 给前端编码 Agent 用允许它把生成的代码写入具体目录。终端 MCP 给质量审查 Agent 用用来执行 eslint 等命令。第二步准备 Skills。把前端开发规范 Skill 和质量审查 Skill 放进共享技能目录并确认 SKILL.md 里的 name 值是唯一的。如果多个 Skill 的 name 重复Agent 加载时会随机覆盖这是我在实战中踩过的坑。第三步配置 DeepAgents 的 Agent 定义。这里最关键的一个参数是每个 Agent 能看到的上下文源。我会确保Agent A 的输出文件路径是 Agent B 的输入读取路径A2A 通信时只传“必要信息摘要”不传整个文件内容文件内容让下游 Agent 自己通过文件系统 MCP 去读。这样可以大幅减少 token 消耗。5.3 编排流程从任务下达到结果汇聚整个流程跑起来大概是这样一个逻辑我尽量用文字描述清楚主控 Agent 收到“根据 design.fig 的设计稿生成前端页面”这个任务后先从任务管理 Skill 里加载拆解模板生成一个包含“需求解析 → 设计信息提取 → 前端编码 → 质量审查”四阶段的计划。主控通过 A2A 把第一个任务发给需求解析 Agent。需求解析 Agent 读取用户提供的需求描述输出一份结构化的功能清单包含页面模块划分、交互说明、验收要点。它完成之后把结果标记为 completed并将输出文件路径返回给主控。主控再把“读取设计稿标注和切图”的任务发给设计还原 Agent。设计还原 Agent 通过 Figma MCP 定位到设计稿文件逐个模块提取尺寸、颜色、间距、切图导出信息整理成一份设计规范 JSON 文件。如果设计稿在蓝湖里也可以通过蓝湖 MCP 走同样的流程。前端编码 Agent 是整条链路里最忙的。它接收设计规范 JSON 文件路径加载前端开发规范 Skill然后按照模块逐个生成代码写入指定目录。它会通过 A2A 二次确认某些模糊的设计细节但尽量一次问清楚避免反复打扰设计还原 Agent。最后质量审查 Agent 通过终端 MCP 运行 eslint 和类型检查发现的问题按严重程度分类回传给主控。主控判断问题是否必须修复必须修复的打回前端编码 Agent非必须的记录下来并附在最终交付说明里。这个流程跑通之后一个页面的端到端生成时间从最初人工的三四个小时压缩到了十几分钟。当然不能迷信这个数字实际时长取决于页面复杂度、设计稿规范程度和模型速度但量级的提升是真实存在的。5.4 端到端的验证与结果检查自动化流程跑出来之后验证环节不能省。我会做三件事第一功能验证。打开生成的页面对照设计方案检查每个交互点是否可用按钮点击是否有效路由跳转是否正常。这个环节目前很难完全交给 Agent 自动完成至少需要人肉过一遍关键路径。第二规范验证。看生成的代码是否严格遵守了技能里的规范。这里有一个技巧不要只检查结果对不对要看质检 Agent 的报告里有没有出现“我违反了规范”的记录。很多情况下前端编码 Agent 会为了“看起来正确”偷偷绕过规范质检 Agent 的拦截率并不高所以人肉的抽检非常必要。第三设计还原度对比。把生成页面截图和原始设计稿叠在一起看重点检查间距、字号、颜色这三类最容易跑偏的指标。设计还原 Agent 通过 MCP 拿到的标注虽然精确但在生成代码时CSS 的单位换算偶尔会出问题尤其是响应式布局里的百分比换算。5.5 一个值得复用的经验渐进式构建最后必须强调一点不要第一次就把四个 Agent 全部拉起来。我自己的节奏是分四步走第一步单 Agent 跑通“设计稿 → 代码”这段核心链路。确认 MCP 调用稳定、生成代码可用。第二步加上质量审查 Agent让系统具备“写一遍、查一遍”的能力先把质量兜住。第三步加入需求解析 Agent把入口从“已知任务”升级为“原始需求”。第四步最后才挂上主控 Agent把前三步编排成完整流程。每一步之间留出足够的验证时间确保当前阶段稳定了再进下一阶段。多智能体系统的复杂度是指数上升的任何一步带着隐患进入下阶段排查成本都会翻好几倍。6. 实操阶段的坑位图解与经验沉淀6.1 MCP Server 连不上一次完整的排查链路我在实战中遇到过最诡异的一次 MCP 连接失败所有配置看着都没问题单独启动 Server 也正常但放到 DeepAgents 里就是连不上。最后排查下来是环境变量问题我的配置文件里 LANHU_TOKEN 带了一个看不见的换行符是从网页复制 token 时带进去的。单独在终端跑命令时Shell 会吃回调或者报错提示但在 Host 内部是以参数形式直接透传的换行符被当成了 token 的一部分鉴权就一直失败。这次之后我养成了一个习惯配置里的所有敏感值先用一个简单的命令验证比如echo -n $LANHU_TOKEN | xxd | head如果输出里夹杂了 0a 之类的换行字节肯定有问题。遇到 MCP 连接不稳定时不要先怀疑网络先怀疑环境变量的干净程度这是我排障经验里性价比最高的一步。6.2 Agent 之间的“死锁”等待循环的根因多智能体系统里最容易出现的逻辑故障是 Agent 之间互相等待。我碰到过一次设计还原 Agent 在等前端编码 Agent 确认“图片资源用本地还是 CDN”而前端编码 Agent 在等设计还原 Agent 把所有资源链接整理成清单。两个 Agent 都在等对方先开口整个流程就卡死了。根因在于我的任务编排里没有明确“谁对什么负责”。前端编码 Agent 认为资源上线是上游的职责设计还原 Agent 认为资源消费方式应该是下游决定的双方都没有决策权。解决方式是在主控 Agent 的任务定义里写死决策规则默认所有图片资源走 CDN如果设计稿里没有提供 CDN 地址前端编码 Agent 自己决定先用本地占位图并在交付说明里标记为待替换。这样不管是哪个 Agent 遇到模糊地带都有一个默认行动路径不可能进入互相等待的状态。这个经验后来被我总结成一个原则在多智能体编排里每个任务的描述必须包含“什么情况下按默认方案执行”这一条不能只写任务目标。6.3 Skills 的加载冲突同名覆盖问题另一个容易翻车的点是多个 Skill 之间存在命名冲突或描述歧义。我在项目里遇到过两个不同的技能包同时声明了 name 为 image-generation 的 Skill结果 Agent 加载时随机选了一个生成的图片风格完全不对排查了好半天才发现是技能加载错了。解决方法是建立一个团队内部的技能注册表用表格记录每个 Skill 的 name、维护人、版本、适用范围。任何新技能加入之前先查注册表确认没有重名。这是一个很轻量但收益非常大的管理手段。另外一个细节是description 写得太像的 Skill 也会让 Agent 选错。比如“前端开发规范”和“前端组件使用指南”在 Agent 看来可能是两个不同的东西也可能是同一个东西取决于它怎么理解。我的建议是描述里明确写“本技能不适用于什么场景”排除法往往比描述“适用什么场景”更有效。6.4 Token 消耗失控成本瓶颈与优化方向多智能体系统的 token 消耗比单 Agent 高一个数量级这是绕不开的现实。我跑完整套流程后的实测一个中等复杂页面大约消耗 60 万到 80 万 token其中前端编码 Agent 占了接近一半。优化方向有两个最有效第一MCP 返回数据的裁剪。很多 MCP Server 会把节点的全部属性返回回来但真正需要的可能只有十几个字段。我通过在 MCP Server 端做结果过滤把响应体压缩了接近七成token 消耗立刻降下来。第二A2A 传摘要而非原文。Agent 之间通信时不要直接传递大段原始文本。我在第 5 章里提到的“传文件路径、让下游自己读”的方式实际上就是把通信内容从“全文”压缩成“路径摘要”这一项优化对成本的影响非常显著。成本优化的核心思路是不要让 Agent 在“已经确定的事实”上反复计算让信息从源头就以最精简的形式出现而不是先进上下文再被压缩。6.5 我对这套体系的一些事后判断跑完整个项目之后我最大的体感是DeepAgents、MCP、A2A、Skills 这套组合的成熟度确实到了一个可以日常使用的水平但它依然不是一种“装上就能跑”的解决方案。前期花在角色设计、权限边界、任务描述上的时间会直接决定后期系统稳定性这部分功夫省不得。很多人被“智能体自主协作”的宣传吸引来期待搭好框架之后就能全自动运行实际做了之后才发现大部分精力都花在定义任务、调协议、裁剪信息这类看似很“不智能”的事情上。但恰恰是这些不起眼的工程细节才决定了多智能体系统到底是玩具还是生产力工具。最后再分享一个我个人的工作习惯每次新起一个多智能体项目我都会先花十分钟画一张最简架构图标注清楚每个 Agent 的输入、输出、依赖工具和协作对象然后才开始配置环境。这张图在我排查问题时救了我无数次强烈建议你也试一次。 多智能体协作实战：DeepAgents+MCP+A2A+Skills四件套全解析
做多智能体项目最头疼的从来不是单个 Agent 不够聪明而是几个 Agent 凑在一起之后怎么让它们稳定协作。我最近把一个从设计稿到前端页面的完整流程完整跑通最大的感受就是DeepAgents、MCP、A2A、Skills 四件套才是多智能体开发真正能落地的基础配置。这篇文章适合谁正在折腾多智能体但卡在“各 Agent 各说各话”的人、已经会用 Claude Code / Codex 但没试过把多个 Agent 串起来的开发者、想搞清楚 MCP 和 A2A 到底什么区别的学习者。我会从架构理解讲起一直讲到可直接参考的配置和编排流程最后把实战里踩过的坑一并交代清楚内容不算短但对得起你花的时间。1. 先搞清楚一件事DeepAgents 这套多智能体栈到底解决什么问题1.1 单 Agent 做项目时真正卡在哪先说个很现实的问题。单个大模型 Agent 跑一个简单任务比如“总结这篇文档”“写一段 Python 脚本”体验其实不错。但一旦任务变成“从设计稿生成一个完整前端页面还要符合项目规范、可维护、能通过代码检查”单 Agent 通常会在三个地方卡死第一上下文窗口是硬上限。一个页面涉及需求文档、设计稿标注、组件库规范、历史代码风格全塞进一个上下文里还没开始写代码先把 token 预算烧光了然后开始丢三落四。第二单线执行效率低。很多子任务是并行的比如页面头部、底部、中间的业务模块互相不依赖但单 Agent 只能一个一个处理。第三能力和职责混在一起。同一个 Agent 既要做需求分析又要写代码又要自查角色切换本身就是很大的 token 浪费而且容易把分析阶段的结论带到编码阶段去。所以我当时的判断是不能继续在单 Agent 上堆 Prompt 了必须拆成多智能体架构。1.2 MCP、A2A、Skills 各自解决的是哪一层问题多智能体架构听起来美好但拆开之后立刻冒出一堆新问题每个 Agent 怎么接入外部工具Agent 之间怎么互相通信能力怎么沉淀避免每次从零开始这就是 DeepAgents MCP A2A Skills 这套组合存在的意义。我用一个比较直白的比喻来理解它们的分工MCP 解决的是 Agent 怎么“动手”。Model Context Protocol 把所有外部工具接入统一成了标准协议Agent 不用再为每个工具单独写对接代码。A2A 解决的是 Agent 怎么“开口”。Agent2Agent 协议定义了智能体之间如何发现彼此、发送任务、回传结果让多 Agent 协作从“黑话互怼”变成“标准对话”。Skills 解决的是 Agent 怎么“长记性”。把一次实践中积累的操作流程、代码范式、注意事项打包成结构化技能文件之后同样的任务直接调用不用重新写 Prompt。DeepAgents 这类编排框架解决的是前几者怎么“组合”。它负责创建 Agent 实例、分配任务、调度执行顺序、汇总结果。这四层是互补关系不是替代关系。很多人搞混了以为 MCP 做好就不需要 A2A或者 Skills 可以替代 MCP实际完全不是一回事。1.3 DeepAgents 在整条链路里扮演的角色DeepAgents 在这里扮演的是“调度中枢”。它做的事情可以概括为定义每个子 Agent 的角色、给每个子 Agent 注入对应的 MCP 工具与 Skills、把一个大任务拆成子任务并按依赖关系编排、最后汇聚各个 Agent 的输出。我在做项目拆解时会把 DeepAgents 类比成一个软件研发团队里的技术负责人。它自己不一定写每一行代码但它清楚谁负责什么、谁的工具链是什么、谁做完之后下游该接给谁。这套思想在任何领域都适用不一定非得是写代码。需要提醒的是并不是所有项目都适合拆成多智能体。我见过有人连“写一篇周报”都要拆三个 Agent纯属没事找事。判断标准很简单任务里是否存在明显的子任务边界、子任务是否可以并行或分阶段执行、各子任务是否需要不通用的工具或知识。如果三个问题的回答都是否那一个 Agent 带一两个 Skill 反而更高效。2. MCP 不是魔法它是把工具调用标准化了——链路拆解与配置实战2.1 MCP 本质上是“AI 应用的 USB 接口”聊 MCP 之前先回顾一下没有 MCP 的时候给 Agent 接一个外部工具有多痛苦。假设我要让 Agent 读取蓝湖设计稿的标注信息。传统做法是写一个 Python 脚本调用蓝湖 API然后想办法把数据塞进 Agent 的上下文里。如果再加一个 Figma、一个数据库、一个文件系统每个工具都是一套独立的 API、独立的鉴权、独立的错误处理。Agent 生态稍微扩大代码量就以几何级数增长。MCP 的贡献在于它定义了一套统一的标准Agent作为 Host通过 MCP 客户端连接 MCP ServerServer 向外暴露“工具”Agent 只要理解了 MCP 协议就能调用任何符合协议的 Server。就像 USB 接口设备只要符合标准插上就能用不用关心里面是键盘还是 U 盘。这里有一个关键认知MCP 的核心是“标准”不是某个具体的库或软件。它是一套协议包含传输方式、消息格式、工具发现与调用机制。理解了这一点你在配置各种 MCP Server 时就不会被具体工具名绕晕。2.2 Host、Client、Server 三个角色别搞反MCP 体系里一共有三个角色角色作用示例MCP Host运行 Agent 的宿主环境负责发起会话DeepAgents、Claude Desktop、IDE 插件MCP ClientHost 内部与 Server 建立连接的通信层通常由 SDK 封装使用者无感知MCP Server提供具体工具能力的服务可以本地进程也可以是远程 HTTP 服务蓝湖 MCP、Figma MCP、文件系统 MCP配置的时候最容易犯的错就是把 Host 和 Server 搞混。比如有朋友跑来问“我的 MCP Server 怎么连不上 Claude”我一看他把配置写在了某个工具的配置文件里但这个工具本身并不是 Host。记住一个口诀Agent 跑在 Host 里Server 是 Agent 要调用的外部能力Client 是中间那根线。2.3 实际配置以蓝湖 MCP 和 Figma MCP 为例MCP 的配置通常是一个 JSON 文件不同 Host 文件的路径不一样但结构大同小异。这里给一个我在 DeepAgents 场景里的配置示例{ mcpServers: { lanhu: { command: npx, args: [-y, lanhu-mcp/server], env: { LANHU_TOKEN: 你的蓝湖访问令牌 } }, figma: { command: npx, args: [-y, figma-developer-mcp], env: { FIGMA_API_KEY: 你自己的 Figma API Key } } } }为什么用 npx 拉起因为很多 MCP Server 以 Node 包形式发布npx 可以免安装直接执行每次启动时自动拉取最新版本。代价是首次启动会慢一点因为要下载包。如果你对稳定性要求高可以先用 npm install -g 把包装到全局再把 command 改成直接的二进制路径比如command: lanhu-mcp。配置蓝湖 MCP 时有个非常隐蔽的坑LANHU_TOKEN 的获取入口不在 MCP 文档里而是在蓝湖开发者后台的个人令牌页。很多人在配置文件里写了一个“自己的密码”结果鉴权一直失败怀疑人生半天才发现找错了入口。Figma 那边同理需要去 Figma 账号设置里生成 Personal Access Token注意权限范围至少勾选 File content 读取权限。2.4 设计稿还原场景里 MCP 到底帮了什么忙我在实战项目里做“设计稿到前端页面”时MCP 的核心价值有四个一是标注即取即用。以前人工要看设计稿的间距、字号、颜色需要打开蓝湖网页逐项复制现在 Agent 直接通过 MCP 把节点的标注、切图 URL、样式 Token 拿过来精确到像素。二是切图不用手导。Figma MCP 提供的工具里包含图片导出相关能力Agent 可以根据需要把图层导出成 PNG 或 SVG存入本地后在编码时直接引用整个链路自动化程度大幅提升。三是参数有了上下文。MCP Server 返回的数据结构是带语义的Agent 知道这个值是“按钮圆角”还是“卡片阴影”不是一串无意义的数字。四是多 Agent 共享同一套工具。前面的项目经理 Agent 不需要调用 Figma但设计还原 Agent 需要。通过 DeepAgents 按角色注入 MCP Server每个 Agent 看到的是自己那部分工具集权限边界也清晰了。2.5 配置 MCP Server 时的常规排查链路如果 MCP Server 连不上我排查的顺序是固定的先确认 Server 进程能不能单独跑起来。直接在终端执行配置里的 command args看有没有报错。再确认启动参数里的环境变量是否正确。很多 Server 启动时静默失败实际是环境变量没读取到。检查 Host 的配置文件语法。JSON 多一个逗号少一个引号都会导致整个配置不加载而且很多 Host 不会给错误提示。确认传输方式。stdio 类型的 Server 必须由 Host 启动子进程不能用 HTTP URL 去连streamable HTTP 类型的 Server 必须配置 URL 而不是本地命令。这两类搞错了基本必跪。最后才考虑网络问题。远程 Server 的域名解析、防火墙、鉴权头都属于这里。这套排查链路我后来直接贴到了团队文档里新人照着走一遍能解决九成的连接问题。3. A2A 补上的是智能体之间的“对话协议”以及怎么观测它们的协作3.1 有了 MCP为什么还需要 A2A这是我在交流时被问得最多的问题。MCP 统一了 Agent 与工具之间的调用标准但 Agent 与 Agent 之间呢你可以想象一个场景需求解析 Agent 分析完需求文档要把结论交给架构 Agent架构 Agent 拆好组件后要把接口定义传给前端编码 Agent。如果这些信息传递靠的是“把结果写成 JSON 文件放在某个目录里”那每换一种协作方式就要重写一遍代码而且完全不可观测。A2A 协议解决的正是这个问题。它定义了一套智能体之间的标准交互方式一个 Agent 如何向外声明自己的能力和地址、如何接收来自另一个 Agent 的任务、如何返回进度和最终结果、如何在任务处理中交换非文本的“工件”。MCP 是“人Agent与工具”之间的协议A2A 是“Agent 与 Agent”之间的协议两者服务的是不同层。MCP 管的是手A2A 管的是嘴。3.2 A2A 的核心要素Agent Card、任务与消息A2A 里最重要的概念有三个Agent Card、任务、消息。Agent Card 是智能体对外发布的“名片”包含名称、描述、能力列表、接入地址URL等信息。其他 Agent 想找谁干活先拉取对方的 Agent Card看它的能力描述是否匹配需求再决定是否把任务发过去。这部分设计很像微服务架构里的服务注册与发现只不过服务提供方从“接口”变成了“智能体”。任务Task是一个完整的、有状态的工作单元。发起方创建一个任务给接收方接收方接受后持续更新状态比如 pending、working、completed、failed。任务可以关联消息也可以关联工件。工件Artifact用来传递非文本形式的结果比如图片、表格、代码文件。实际体验下来A2A 最大的价值是把“Agent 之间的协作”从代码层面解耦了出来。以前我在 DeepAgents 里让两个 Agent 协作直接在编排代码里写死“A 完成后调用 B”一旦要调整角色或者插入新 Agent就要改代码。引入 A2A 概念后每个 Agent 只关心“谁能完成这件事”而不是“下一个要调谁的函数”。3.3 编排式协作与对等式协作怎么选多智能体的协作模式我把它粗分成两类编排模式Orchestrator-Worker一个主控 Agent 负责任务拆分、分配、结果校验其他 Agent 干完活把结果交回主控。好处是流程可控、出错易定位坏处是主控容易成为瓶颈。对等模式Peer-to-Peer没有中心主控Agent 之间通过 A2A 协议互相委托任务有点像工作流里的事件驱动。好处是灵活坏处是流程不确定性高排查难度大。我的经验是项目初期强烈建议先用编排模式哪怕牺牲一点效率。因为你只有在“能稳定复现”的前提下才谈得上优化。我见过一上来就搞全对等协作的团队Agent 之间互相踢皮球一个任务在系统里转圈最后谁也不认账。先让主控 Agent 把节奏控制住跑通之后再把那些耗时较长、子链路成熟的部分切换成对等委托。3.4 用 Langfuse 观测多智能体协作的调用链多智能体系统上线后你一定会遇到一个问题这个结果是谁产出的中间经过了哪几个 Agent每个 Agent 调用了哪些工具耗时多少如果没有可观测性出了问题只能翻日志甚至只能靠猜。我用的方案是把 Langfuse 接进整个流程。Langfuse 本身是一个 LLM 应用的追踪与可观测平台支持把一次完整的请求记录成一条 tracetrace 里嵌套多个 span。在多智能体场景下我会按这样的粒度打 span最外层 trace 对应一个端到端任务比如“生成前端页面”第二层 span 对应每个 Agent 的执行过程带上 Agent 名称和角色第三层 span 对应具体的步骤比如 MCP 调用、A2A 消息发送、Skills 加载这样打开 Langfuse 的界面就能看到一条清晰的链路主控 Agent 把任务派发给设计还原 Agent设计还原 Agent 调用 Figma MCP 拉取设计稿信息耗时 3.8 秒接着把结果通过 A2A 发给前端编码 Agent该 Agent 加载了 React Skills耗时 12.4 秒。哪一段异常一眼就能定位。有个细节值得提醒A2A 消息的传递内容一定要在 span 里记录摘要不要只记“发送成功”四个字。否则回看链路时你只看到 Agent A 发了一条消息给 Agent B但完全不知道发了什么问题依然没法定位。我在记录时会包含消息类型、任务 ID、关键内容的前几百个字符成本不高收益很大。4. Skills 系统把经验变成可复用资产而不是每次都重写 Prompt4.1 Skills 和 Prompt、插件到底差在哪在 Skills 这个概念火起来之前我们沉淀经验的方式是维护一个巨大的 Prompt 模板比如“你现在是一个前端开发专家请严格按照以下规范输出代码……”。这套做法最大的问题是Prompt 只有文本没法附带参考文件、脚本、示例代码而且所有内容堆在一段话里Agent 难以在合适的时机主动调用。Skills 的做法是把“技能”拆成一个结构化目录。一个典型的 Skill 包含技能描述、使用说明、参考资源、可执行脚本。Agent 可以根据任务判断当前情况是否匹配某个 Skill 的触发条件匹配就加载使用。这个设计让经验沉淀变成了“文件管理”而不是“文字堆砌”。比如我总结了一套公司内部的前端开发规范可以做成一个 Skill描述部分写清楚这个技能适用于什么场景说明部分写清楚规范要求参考资源里放几个标准组件示例脚本里放一个自动跑代码检查的命令。任何新 Agent 加入项目只要挂上这个 Skill立刻就能按公司规范干活不需要重新给它讲一遍。4.2 目录结构与 SKILL.md 的写法不用把 Skills 想得太玄乎一个最基础的 Skill 目录长这样company-fe-skill/ ├── SKILL.md ├── instructions.md ├── templates/ │ └── StandardButton.tsx ├── scripts/ │ └── lint.sh └── assets/ └── style-guide.mdSKILL.md 是入口文件采用 Markdown 格式头部通常是 YAML Front Matter用来声明元信息。下面的写法是我一直在用的--- name: company-fe-skill description: 公司前端页面开发规范与组件使用指南适用于 React TypeScript 项目。 when_to_use: 当任务涉及前端页面开发、组件编写或代码审查时 --- # 公司前端开发技能包 ## 核心规范 - 使用 React 18 TypeScript - 组件文件采用 PascalCase 命名 - 样式方案统一使用 CSS Modules ## 使用流程 1. 阅读 templates/ 目录下的组件模板 2. 开发时参考 style-guide.md 中的设计规范 3. 完成后运行 scripts/lint.sh 检查代码质量 ## 注意事项 - 禁止使用 any 类型 - 图片资源必须走 CDN 地址 - 组件导出必须包含 default export为什么 description 和 when_to_use 这两个字段很重要因为 Agent 在运行时会扫描可用技能列表通过这两个字段判断要不要加载这个技能。写的越具体匹配越精准。我之前见过有人把 description 写成“前端技能包”Agent 几乎不会主动用因为太模糊了它没法判断这个技能和当前任务是否相关。4.3 主流 Skills 生态Codex、Claude Code 与 Superpower目前主流的 Agent 客户端都有自己的 Skills 加载机制。Codex Skills、Claude Code Skills 虽然具体实现有差异但核心思想是一模一样的就是“以目录为单位管理技能通过描述触发加载”。社区里有一个比较有影响力的合集叫 Superpower Skills里面打包了大量整理好的技能覆盖面很广。我的建议是第一次接触 Skills 的人可以先把这个合集装上看几个真实样例学习一下其他人是怎么写 description、怎么组织参考资源的然后立刻动手写一个属于自己场景的小 Skill不要一直在“看别人怎么写”的阶段停留。从我实际使用的情况看下面几类 Skill 的性价比最高代码规范类把团队编码规范打包审查代码时挂上。文档生成类定义了输出大纲、措辞风格、字数要求任何 Agent 写文档都能保持一致调性。图像生成类有些人已经总结了提示词框架和负面提示词参考整合成 Skill 后生图质量稳定很多。结构图类针对图表绘制场景内含流程图、系统架构图的绘图规范与样式要求。4.4 开发一个自有 Skill 的标准流程我自己总结了一套五个步骤的开发流程基本不踩坑先记录下来不要急着整理。在真实项目中把“我这次是怎么做的”完整写下来包括步骤、命令、踩坑点。跑一次验证。把刚写的文本用作 Prompt 让 Agent 重新执行同类任务能跑通再整理。拆分文件。把入口描述、详细说明、模板、脚本拆进不同文件别一股脑堆在 SKILL.md 里。写清理的描述字段。反复打磨 description让 Agent 看一眼就知道什么时候该用。放进共享目录并持续维护。Skills 不是一次性的遇到新边界条件就补充遇到过期信息就更新。这里有一个我反复强调的观点Skills 的价值在于“持续维护”。我见过不少人写了一个 Skill 就再也不管了半年之后里面的技术栈描述已经过时Agent 照着做反而做错。技能和知识一样不更新就会腐烂。5. 全流程实战从零搭一条“设计稿到前端页面”的多智能体流水线5.1 项目设计角色拆分与职责边界实战项目我选的是“把 Figma 设计稿还原成一个可运行的前端页面”这是很多团队刚上多智能体时最喜欢尝试的场景因为边界清楚、工具齐全、效果直观。我一共拆了四个角色再加一个主控Agent 名称职责依赖的 MCP依赖的 Skills主控 Agent接收需求、拆解任务、调度结果、最终输出全局调度任务管理 Skill需求解析 Agent阅读需求描述输出结构化任务清单无需求拆解 Skill设计还原 Agent从 Figma/蓝湖获取标注与切图输出设计规范文件Figma MCP、蓝湖 MCP设计信息提取 Skill前端编码 Agent根据设计规范生成组件与页面代码文件系统 MCP前端开发规范 Skill质量审查 Agent对生成的代码做规范检查与问题反馈终端 MCP代码审查 Skill这个角色的核心设计原则是每个角色只做一件事并且只接触完成这件事所需的最小工具集。设计还原 Agent 不需要终端权限前端编码 Agent 不需要 Figma 权限。权限最小化带来两个好处一是每个 Agent 的上下文更干净不相关的工具不会干扰判断二是安全问题少很多一个 Agent 被“带偏”了破坏半径有限。5.2 环境准备与关键配置这一套的环境准备其实不复杂核心是三步第一步准备 MCP Server。按照第 2 章的 JSON 配置把 Figma MCP 和蓝湖 MCP 配上两个都验证能单独启动。文件系统 MCP 给前端编码 Agent 用允许它把生成的代码写入具体目录。终端 MCP 给质量审查 Agent 用用来执行 eslint 等命令。第二步准备 Skills。把前端开发规范 Skill 和质量审查 Skill 放进共享技能目录并确认 SKILL.md 里的 name 值是唯一的。如果多个 Skill 的 name 重复Agent 加载时会随机覆盖这是我在实战中踩过的坑。第三步配置 DeepAgents 的 Agent 定义。这里最关键的一个参数是每个 Agent 能看到的上下文源。我会确保Agent A 的输出文件路径是 Agent B 的输入读取路径A2A 通信时只传“必要信息摘要”不传整个文件内容文件内容让下游 Agent 自己通过文件系统 MCP 去读。这样可以大幅减少 token 消耗。5.3 编排流程从任务下达到结果汇聚整个流程跑起来大概是这样一个逻辑我尽量用文字描述清楚主控 Agent 收到“根据 design.fig 的设计稿生成前端页面”这个任务后先从任务管理 Skill 里加载拆解模板生成一个包含“需求解析 → 设计信息提取 → 前端编码 → 质量审查”四阶段的计划。主控通过 A2A 把第一个任务发给需求解析 Agent。需求解析 Agent 读取用户提供的需求描述输出一份结构化的功能清单包含页面模块划分、交互说明、验收要点。它完成之后把结果标记为 completed并将输出文件路径返回给主控。主控再把“读取设计稿标注和切图”的任务发给设计还原 Agent。设计还原 Agent 通过 Figma MCP 定位到设计稿文件逐个模块提取尺寸、颜色、间距、切图导出信息整理成一份设计规范 JSON 文件。如果设计稿在蓝湖里也可以通过蓝湖 MCP 走同样的流程。前端编码 Agent 是整条链路里最忙的。它接收设计规范 JSON 文件路径加载前端开发规范 Skill然后按照模块逐个生成代码写入指定目录。它会通过 A2A 二次确认某些模糊的设计细节但尽量一次问清楚避免反复打扰设计还原 Agent。最后质量审查 Agent 通过终端 MCP 运行 eslint 和类型检查发现的问题按严重程度分类回传给主控。主控判断问题是否必须修复必须修复的打回前端编码 Agent非必须的记录下来并附在最终交付说明里。这个流程跑通之后一个页面的端到端生成时间从最初人工的三四个小时压缩到了十几分钟。当然不能迷信这个数字实际时长取决于页面复杂度、设计稿规范程度和模型速度但量级的提升是真实存在的。5.4 端到端的验证与结果检查自动化流程跑出来之后验证环节不能省。我会做三件事第一功能验证。打开生成的页面对照设计方案检查每个交互点是否可用按钮点击是否有效路由跳转是否正常。这个环节目前很难完全交给 Agent 自动完成至少需要人肉过一遍关键路径。第二规范验证。看生成的代码是否严格遵守了技能里的规范。这里有一个技巧不要只检查结果对不对要看质检 Agent 的报告里有没有出现“我违反了规范”的记录。很多情况下前端编码 Agent 会为了“看起来正确”偷偷绕过规范质检 Agent 的拦截率并不高所以人肉的抽检非常必要。第三设计还原度对比。把生成页面截图和原始设计稿叠在一起看重点检查间距、字号、颜色这三类最容易跑偏的指标。设计还原 Agent 通过 MCP 拿到的标注虽然精确但在生成代码时CSS 的单位换算偶尔会出问题尤其是响应式布局里的百分比换算。5.5 一个值得复用的经验渐进式构建最后必须强调一点不要第一次就把四个 Agent 全部拉起来。我自己的节奏是分四步走第一步单 Agent 跑通“设计稿 → 代码”这段核心链路。确认 MCP 调用稳定、生成代码可用。第二步加上质量审查 Agent让系统具备“写一遍、查一遍”的能力先把质量兜住。第三步加入需求解析 Agent把入口从“已知任务”升级为“原始需求”。第四步最后才挂上主控 Agent把前三步编排成完整流程。每一步之间留出足够的验证时间确保当前阶段稳定了再进下一阶段。多智能体系统的复杂度是指数上升的任何一步带着隐患进入下阶段排查成本都会翻好几倍。6. 实操阶段的坑位图解与经验沉淀6.1 MCP Server 连不上一次完整的排查链路我在实战中遇到过最诡异的一次 MCP 连接失败所有配置看着都没问题单独启动 Server 也正常但放到 DeepAgents 里就是连不上。最后排查下来是环境变量问题我的配置文件里 LANHU_TOKEN 带了一个看不见的换行符是从网页复制 token 时带进去的。单独在终端跑命令时Shell 会吃回调或者报错提示但在 Host 内部是以参数形式直接透传的换行符被当成了 token 的一部分鉴权就一直失败。这次之后我养成了一个习惯配置里的所有敏感值先用一个简单的命令验证比如echo -n $LANHU_TOKEN | xxd | head如果输出里夹杂了 0a 之类的换行字节肯定有问题。遇到 MCP 连接不稳定时不要先怀疑网络先怀疑环境变量的干净程度这是我排障经验里性价比最高的一步。6.2 Agent 之间的“死锁”等待循环的根因多智能体系统里最容易出现的逻辑故障是 Agent 之间互相等待。我碰到过一次设计还原 Agent 在等前端编码 Agent 确认“图片资源用本地还是 CDN”而前端编码 Agent 在等设计还原 Agent 把所有资源链接整理成清单。两个 Agent 都在等对方先开口整个流程就卡死了。根因在于我的任务编排里没有明确“谁对什么负责”。前端编码 Agent 认为资源上线是上游的职责设计还原 Agent 认为资源消费方式应该是下游决定的双方都没有决策权。解决方式是在主控 Agent 的任务定义里写死决策规则默认所有图片资源走 CDN如果设计稿里没有提供 CDN 地址前端编码 Agent 自己决定先用本地占位图并在交付说明里标记为待替换。这样不管是哪个 Agent 遇到模糊地带都有一个默认行动路径不可能进入互相等待的状态。这个经验后来被我总结成一个原则在多智能体编排里每个任务的描述必须包含“什么情况下按默认方案执行”这一条不能只写任务目标。6.3 Skills 的加载冲突同名覆盖问题另一个容易翻车的点是多个 Skill 之间存在命名冲突或描述歧义。我在项目里遇到过两个不同的技能包同时声明了 name 为 image-generation 的 Skill结果 Agent 加载时随机选了一个生成的图片风格完全不对排查了好半天才发现是技能加载错了。解决方法是建立一个团队内部的技能注册表用表格记录每个 Skill 的 name、维护人、版本、适用范围。任何新技能加入之前先查注册表确认没有重名。这是一个很轻量但收益非常大的管理手段。另外一个细节是description 写得太像的 Skill 也会让 Agent 选错。比如“前端开发规范”和“前端组件使用指南”在 Agent 看来可能是两个不同的东西也可能是同一个东西取决于它怎么理解。我的建议是描述里明确写“本技能不适用于什么场景”排除法往往比描述“适用什么场景”更有效。6.4 Token 消耗失控成本瓶颈与优化方向多智能体系统的 token 消耗比单 Agent 高一个数量级这是绕不开的现实。我跑完整套流程后的实测一个中等复杂页面大约消耗 60 万到 80 万 token其中前端编码 Agent 占了接近一半。优化方向有两个最有效第一MCP 返回数据的裁剪。很多 MCP Server 会把节点的全部属性返回回来但真正需要的可能只有十几个字段。我通过在 MCP Server 端做结果过滤把响应体压缩了接近七成token 消耗立刻降下来。第二A2A 传摘要而非原文。Agent 之间通信时不要直接传递大段原始文本。我在第 5 章里提到的“传文件路径、让下游自己读”的方式实际上就是把通信内容从“全文”压缩成“路径摘要”这一项优化对成本的影响非常显著。成本优化的核心思路是不要让 Agent 在“已经确定的事实”上反复计算让信息从源头就以最精简的形式出现而不是先进上下文再被压缩。6.5 我对这套体系的一些事后判断跑完整个项目之后我最大的体感是DeepAgents、MCP、A2A、Skills 这套组合的成熟度确实到了一个可以日常使用的水平但它依然不是一种“装上就能跑”的解决方案。前期花在角色设计、权限边界、任务描述上的时间会直接决定后期系统稳定性这部分功夫省不得。很多人被“智能体自主协作”的宣传吸引来期待搭好框架之后就能全自动运行实际做了之后才发现大部分精力都花在定义任务、调协议、裁剪信息这类看似很“不智能”的事情上。但恰恰是这些不起眼的工程细节才决定了多智能体系统到底是玩具还是生产力工具。最后再分享一个我个人的工作习惯每次新起一个多智能体项目我都会先花十分钟画一张最简架构图标注清楚每个 Agent 的输入、输出、依赖工具和协作对象然后才开始配置环境。这张图在我排查问题时救了我无数次强烈建议你也试一次。