去年我把一条原本需要“需求、设计、前端、测试”四个人接力才能跑通的前端交付流水线压成了一组可自动流转的超级多智能体。整套东西由 DeepAgents 做编排、MCP 打通所有外部工具、A2A 协议负责智能体之间的任务交接、Skills 沉淀过程中的最佳实践。折腾完这 21 章实战之后我最深的一个体会是单 Agent 时代那种“换个好 Prompt 就能搞定一切”的想法在多智能体场景里根本不成立。真正决定系统能不能稳定跑下去的不是模型有多聪明而是编排、通信、工具接入和经验沉淀这四个层面能不能各司其职。这篇文章不是课程宣传也不准备面面俱到地复读官方文档。我只想以整套项目的复盘身份把“为什么要用这四件套”“它们各自解决什么病灶”“实际搭建时哪几步最容易翻车”“多智能体上线之后怎么观测和调优”这些真实经验讲清楚。如果你已经跑通了单个 Agent但发现复杂任务经常做着做着就上下文混乱、工具调用不稳定那这篇文章应该能帮你少踩一半的坑。1. 单 Agent 的瓶颈以及“四件套”各自解决的病灶1.1 为什么多智能体不是赶时髦先说个场景我用单 Agent 试着完成“把 Figma 设计稿转成可用 React 组件并做视觉验证”这个任务。第一轮效果还行第二轮开始出问题——让它分析布局它会顺手改代码让它输出组件它会忽然开始写测试让它调用浏览器截图核实还原度它可能在同一个上下文里被前面几十轮对话干扰忘了自己还有浏览器工具可用。这不是模型能力不够而是单 Agent 的结构性缺陷。核心问题有三个上下文污染所有角色职责、工具结果、历史消息都堆在同一个上下文窗口里。模型需要不停区分“哪些历史信息对当前子任务有效”注意力被严重稀释。即使模型支持百万 token长上下文里的指令遵循质量也是逐级衰减的。角色切换笨重一个 Agent 要轮流扮演需求分析、前端开发、测试验收本质上是在同一个推理过程里反复切换状态机一旦切换逻辑不够强硬前后角色就会互相干扰。工具调用没有边界单 Agent 把所有工具的使命都绑在自己身上SaaS 数据、浏览器、文件系统、设计稿平台……全部塞给一个角色它既不知道什么时候该用也不知道工具返回的结果该由谁来消化。所以多智能体的意义不是把任务拆给多个模型聊聊天而是让“职责边界”和“上下文边界”同时存在。每个 Agent 只保留与自己子任务相关的上下文历史消息不需要全量透传工具调用也能按需分配。1.2 四件套的分工编排层、接口层、通信层、经验层这个项目里我把四类技术分开看它们根本不是同一个维度上的东西不能二选一而是各管一段组件所属层面核心解决的问题类比DeepAgents编排与流程层任务怎么拆解、Agent 拓扑怎么定义、按什么顺序执行项目负责人MCP工具接入层Agent 如何统一调用外部工具和数据源万能外设接口A2A通信与协作层Agent 之间如何交接任务、同步状态、返回产物企业对接流程Skills经验与技能层把高质量做事方法沉淀为可复用的技能包标准作业手册先用项目负责人的视角理解 DeepAgents它负责画出“谁在什么时候干什么”的拓扑图比如先让规划 Agent 拆需求再派三个执行 Agent 并行处理最后叫审核 Agent 来验收。这一步没有之后的 MCP、A2A 也能写但一定会写得非常痛苦因为每个分支、每个重试条件都要手写状态管理。MCPModel Context Protocol解决的是“Agent 的手”的问题。没有 MCP 之前接一个工具就要写一套自定义 SDK 适配代码。要接 Figma、蓝湖、浏览器、本地文件至少四套不同的调用逻辑而且换一个 Agent 框架全部重来。MCP 统一了这套接口Agent 侧只需要知道“有哪些工具可用、参数长什么样”底层实现全部由 MCP Server 封装。A2AAgent-to-Agent解决的是“Agent 之间的嘴”的问题。MCP 是 Agent 连工具A2A 是 Agent 连 Agent。每个 Agent 对外发布一张 Agent Card描述自己能做什么调用方通过标准消息结构发起任务并跟踪任务从 submitted 到 completed 的状态变化。这套协议避免了团队自己发明一套 JSON 格式来对接各个 Agent。Skills 解决的是“做事套路”的问题。同一个“设计稿转代码”任务新手 Agent 可能只会把图片切出来丢给模型描述老手会先解析画布结构、再提取设计变量、然后生成组件代码、最后用浏览器截图比对。Skills 就是把后者这套流程固化成结构化文件Agent 读到描述就能自动加载执行相当于给系统装上了可迁移的“肌肉记忆”。1.3 没有统一协议之前到底有多痛我在项目早期曾经用硬编码的方式让 Agent 调用蓝湖 API 拉取单张切图代码写死在一个 Python 脚本里换一个 Agent 框架就得重写。后来接入 Playwright 做浏览器验证又单独写了一套调用封装。不到两周工具适配代码已经占到了整个项目的一半以上而且每换一个模型或框架这些代码就要排查一遍兼容性。这就是我下决心全面转向 MCP 和 A2A 的直接原因——不是盲目追新而是硬编码的维护成本真的到了无法承受的地步。2. 先把地基打牢MCP 协议与工具层配置实践2.1 MCP 的 Host 与 Server 模型MCP 这套协议最核心的关系是 Host 与 Server。Host 是 AI 客户端也就是真正跑模型的入口比如 Claude Code、Codex、OpenCode、Cursor、Trae以及 DeepAgents 这类编排平台Server 是能力提供方把文件系统、浏览器、Figma、蓝湖、数据库等外部能力封装成标准工具。打个比方MCP 之于 Agent有点像 USB-C 之于电脑。USB-C 只定义一个标准接口不需要知道插在上面的是显示器、硬盘还是扩展坞只要都符合协议就能工作。MCP Server 就是那个扩展坞负责把各种私有协议翻译成模型看得懂的标准工具定义。Server 的启动方式有两种本地工具通常通过 stdio 子进程方式启动远程服务通过 HTTP/SSE 暴露。项目里文件系统、Playwright 这类本地能力我用 stdioFigma、蓝湖这类云端能力用远程 HTTP。选型时有一个原则凡是能本地跑的就别走远程一是减少延迟二是避免把敏感文件路径暴露给第三方服务。2.2 配置一个真实 MCP Server以文件系统工具为例在 Claude Code 里可以用命令直接添加claude mcp add filesystem -s local -- npx -y modelcontextprotocol/server-filesystem /path/to/project也可以改配置文件。Claude Code 的全局配置文件位于~/.claude.json里面是类似这样的结构{ mcpServers: { filesystem: { command: npx, args: [ -y, modelcontextprotocol/server-filesystem, /path/to/project ], env: {} } } }不同客户端的配置入口差异很大我整理了一份对照客户端配置入口添加命令/字段备注Claude Code~/.claude.json或项目级.mcp.jsonclaude mcp add name -s local -- command支持 user/project/local 三种作用域Codex~/.codex/config.toml[mcp_servers.设计稿]字段通过子进程启动本地 serverOpenCodeopencode.json的mcp字段手动编辑 JSON支持本地和远程 serverTrae设置面板中的 MCP 入口图形界面添加适合非技术背景用户有一个细节非常容易踩坑npx -y首次运行要现场下载包启动时间可能长达十几秒而不少客户端默认的 server 超时设置只有 5 到 10 秒结果就是第一次调用工具必失败。我的做法是先手动执行一次npx -y modelcontextprotocol/server-filesystem /path/to/project把包缓存好再让客户端去启动之后就稳了。2.3 设计稿类 MCP 的接入以及 Figma 和蓝湖的取舍这个项目里最实用的工具是设计稿相关的 MCP。Figma MCP Server 支持读取文件结构、获取图层信息、导出切图资源但前提是需要配置 Figma 的 Personal Access Token 和 File Key。拿到 File Key 后Agent 可以这样工作先读取画布结构生成组件树再按指定图层名导出2x资源最后结合 Skills 生成组件代码。蓝湖 MCP 则是国内设计协作场景的主流选择。团队里设计师在蓝湖上传设计稿、打标注、切图前端开发要拉取这些东西效率非常低。配置好蓝湖 MCP 之后Agent 能直接拿到设计稿的标注信息和可用的切图资源充分省去了“打开设计稿手动量尺寸”这一步。这类云端 MCP 的一个关键安全习惯是token 放在环境变量里不要写进配置文件提交到 Git。我在项目里曾经把 Figma Token 写进.mcp.json后来因为仓库权限没控制好等于把设计稿访问权限直接暴露了。正确姿势是env字段引用环境变量比如{ mcpServers: { figma: { command: npx, args: [-y, figma-developer-mcp, --stdio], env: { FIGMA_API_KEY: ${FIGMA_API_KEY} } } } }2.4 不同客户端的 MCP 行为差异用了一段时间之后我发现客户端之间对 MCP 的信任策略区别很大。Claude Code 默认对本地 server 启动的进程有较高的信任度工具调用前可能会弹一次确认之后就可以连续使用Codex 在config.toml里配置好之后默认按会话粒度做权限审批每个会话第一次调用敏感工具时会询问OpenCode 则对工具调用比较放得开适合在自动流程里使用但安全性要自己做足。项目里我把 DeepAgents 作为主编排入口让它在底层挂接多个执行环境。执行 Agent 需要频繁调用浏览器和文件系统时就用 OpenCode 这类对工具调用更自由的客户端需要跟 IDE 交互、需要人工逐步确认的环节就用 Claude Code 这类更谨慎的客户端。这不是谁好谁坏的问题而是“自动化程度需要和风险容忍度匹配”的问题。3. Skills 技能包把一次性的聪明沉淀成可复用能力3.1 Skills 与 Prompt、MCP 的本质区别很多朋友第一次接触 Skills 时以为它就是高级 Prompt。这个理解对了一半但不全对。Prompt 是一次性的指令写完就完了Skills 是结构化的技能包包含 YAML 元信息、说明文档、甚至可执行脚本和配套资源。Agent 读到一个技能包时会依据元信息里的 description 判断“当前用户问题是不是这个技能的适用场景”然后才会加载正文指令必要时还会运行脚本。Skills 与 MCP 的区别更值得说清楚MCP 是给 Agent 装手Skills 是给 Agent 装操作手册。MCP 解决“能用什么工具”Skills 解决“这件事具体怎么干更靠谱”。以设计稿转代码为例MCP 提供的是“读取 Figma 文件”“导出图片”这些原子能力Skills 定义的是“先解析画布结构、再提取设计变量、然后生成组件、最后做视觉比对”这套标准作业流程。没有 SkillsAgent 也可以一步一步调用 MCP 工具但每一步之间靠的是模型临场发挥质量很不稳定。3.2 SKILL.md 的标准结构与描述写作技巧一个标准的 Skills 目录结构大致是这样design-to-code/ ├── SKILL.md ├── scripts/ │ └── extract_design_tokens.py └── resources/ └── component_template.jsxSKILL.md是技能包的入口顶部是 YAML frontmatter核心是 name 和 description。我的实践经验是description 是一段决定“路由命中率”的文字写得太泛会让 Agent 在各种不相关场景误触发写得太窄又会让 Agent 该用的时候不用。好的 description 至少要包含三部分适用条件、输入形式、输出物。我后来是这样写的--- name: design-to-code description: Convert Figma/Lanhu design frames into React Tailwind components. Use when user provides a design frame link, image, or asks to implement a UI snippet from a design. Returns component code, extracted design tokens, and a checklist of visual verification steps. ---注意里面放了一些容易被用户自然表达命中的关键词比如“设计稿切图”“实现这个界面”“按这个样式写组件”。这些关键词本质上是在帮模型做意图匹配不是给小白的废话。3.3 实际开发三个技能从切图到审查21 章课程里我带着项目实际开发了三个技能这几个技能到目前仍然在流水线上稳定运行。第一个是design-to-code配合 Figma/蓝湖 MCP 使用。它的正文指令里规定了严格的执行顺序先读画布结构再提取颜色、字体、间距等设计变量然后对照组件模板生成 React 代码最后输出一份“待人工确认项”清单。没有这个技能时Agent 经常跳过提取设计变量直接写死样式有了技能约束之后产出的一致性好很多。第二个是ui-verification配合 Playwright MCP 使用。它的职责是在组件代码生成之后自动打开本地页面、对关键区域截图、和设计图做像素级对比输出差异列表。没有这个技能时Agent “说”验证完成了但你根本不知道它到底看没看页面。第三个是commit-review在代码提交前对变更内容做审查。它会列出潜在的样式覆盖风险、缺少响应式处理、硬编码颜色等常见问题并把结论格式化输出。这个技能的触发条件是“用户要求 review / 检查代码 / 看看这次改动有什么问题”。3.4 技能包的安装路径与社区资源各主流客户端的技能目录位置不同但思路一致都是“把技能包文件夹放到指定目录”。Claude Code 放在~/.claude/skillsCodex 放在~/.codex/skillsOpenCode 放在~/.config/opencode/skills。安装一个技能就是拉取或复制文件夹删除则直接移走不需要额外注册。社区里最有名的技能集合是 superpower skills它把大量通用场景——文档编写、代码审查、任务拆解、反思规划——全部做成了规范技能包。我的建议是不要整包全装因为技能多了之后 Agent 在做路由选择时会出现干扰。最稳的做法是选出 5 到 10 个与当前工作流最相关的技能装完跑几天观察哪些 description 命中的场景和你的想象不一致再逐个微调。技能装完之后一定要做“命中测试”。我的测试方法是准备一组典型输入比如“帮我把这个设计稿转成页面”“看一下这个截图并给实现方案”“审查一下最新的改动”分别观察 Agent 是否正确触发对应技能。如果该触发没触发大概率是 description 里的关键词和用户真实表述对不上如果不该触发却触发了大概率是 description 里包含了太宽泛的业务词。4. A2A 通信机制多智能体协作的消息设计与任务编排4.1 A2A 解决的是 MCP 覆盖不到的那一层A2A 协议解决的根本问题和 MCP 不在一个维度。MCP 是 Agent 往下连工具A2A 是 Agent 横着连另外的 Agent。理解这个区别很重要因为项目里最容易犯的错就是把“多智能体”做成了“多角色 Prompt”而 A2A 要做的是真正的服务化对接。A2A 里有几个核心概念Agent Card一个 Agent 对外发布的能力清单描述自己擅长什么、支持何种输入输出格式、是否有能力结束任务。Task一个可追踪的完整任务单元有 id有状态。Message任务中的一条消息包含 role 和 parts。Artifact任务产生的产物可以是文本、代码、文件引用或结构化数据。维度MCPA2A连接对象Agent 到工具Agent 到 Agent核心概念Tools / Resources / PromptsAgent Card / Task / Message / Artifact解决的核心问题把外部能力暴露给业务 Agent把 Agent 能力服务化给其他 Agent适合场景文件、浏览器、数据源、设计稿任务分包、结果汇总、多角色协作类比USB-C 接口两家公司之间的商务对接流程项目里我特意把 MCP 和 A2A 用在不同位置Agent 内部需要读文件、截图、调设计稿 API 时走 MCPAgent 之间需要派发子任务、回收结果、请求复核时走 A2A。两者并行不冲突。4.2 一套典型的多 Agent 任务状态流转以“前端交付流水线”为例任务从提交到完成的状态流转大概是这样任务提交后进入 submitted编排节点把它派给切图 Agent切图 Agent 状态变为 working切图 Agent 完成切图后通过 A2A 把产物引用回传给主流程主流程接着把任务发给代码生成 Agent如果某个环节需要用户确认任务状态会变成 input-required等人工介入后继续流转全部完成后进入 completed出错则进入 failed 或 canceled。A2A 消息的结构大概长这样{ jsonrpc: 2.0, method: tasks/send, params: { id: task-20240601-001, agentCard: design-to-code, message: { role: user, parts: [ { kind: text, text: 把首页 Hero 区域从 Figma 链接转换成 React 组件 }, { kind: file, file: https://example.com/artifacts/frame-hero.png } ] } } }注意 message 的 parts 数组它支持文本片段和文件引用混合。我的经验是跨 Agent 传递时尽量传 artifact 引用而不是传文件大内容。早期我试过把设计图 base64 直接塞进 A2A 消息结果单条消息几十兆各个 Agent 的上下文瞬间被撑爆。改成传递文件 URL 或本地路径之后需要哪个 Agent 处理哪个文件让它按需拉取整体消耗立刻降了下来。4.3 三种编排模式怎么选21 章的编排部分主要围绕三种模式展开串行流水线一个 Agent 做完把产物交给下一个 Agent。适合步骤强依赖、每个环节输入是上一个环节输出的场景。优点是链路简单问题定位容易缺点是整体耗时等于各环节耗时之和。并行扇出一个主任务拆成多个独立的子任务同时派给多个 Agent全部完成后汇总。适合“同时请求多个外部数据源”“多个模块各自实现”这类场景。项目里实现“多页面同时转换”时就是并行扇出效率提升非常明显。主从仲裁主 Agent 负责拆任务、分发结果、汇总裁决子 Agent 只对主 Agent 汇报。适合最终结果需要统一口径的场景比如多个 Agent 分别实现同一功能的不同方案最后由主 Agent 选定最佳方案。DeepAgents 里定义这些模式的核心思路是把流程画成节点和边的图。每个 Agent 是一个节点节点之间通过 A2A 消息传递驱动。条件分支和循环也是边上的逻辑不需要写死在某个 Agent 的内部实现里。4.4 上下文边界与失败恢复A2A 还有一个容易被忽视的好处它强制划定了上下文边界。每个 Agent 只收到自己需要的任务描述和产物引用不需要看到整条链路的全部历史。这一招直接解决了单 Agent 上下文污染的问题也显著降低了 token 消耗。我在项目里对比过改成 A2A 消息之后单条任务的平均 token 消耗大约下降了 30%。失败恢复方面我给所有 A2A 任务加了超时和重试机制。幂等任务比如读文件、截图自动重试两次非幂等任务比如提交订单、创建 PR超时后进入 input-required等待人工确认。循环调用是最隐蔽的坑两个 Agent 互相认为对方应该先完成前置任务就会产生 A2A 消息死循环。我在编排层加了一个最大跳数限制A2A 消息每经过一跳就递减一次计数归零后强制终止流程。5. 21 章全流程实战项目从零到上线的复盘5.1 项目要解决的真实问题这套项目的起点是一个真实痛点前端页面从设计稿到可运行组件过去依赖设计师标注、前端手动切图、编写组件、再靠人工肉眼比对视觉还原度。单个页面最快也要半小时到一小时。我希望做一条自动流水线让 Agent 替我完成“需求理解→设计稿读取→组件代码生成→浏览器验证→结果审查”的全链路。整个 21 章的演进路线不全是“按难度从低到高”的线性设计而是严格按照“先把单点做扎实再做连通”的思路拆分。回头看这套分阶段的做法最大的好处是每一阶段结束都有可验证的交付物不会出现十几个知识点全讲完才发现基础工具根本没接对的问题。5.2 各阶段章节如何演进我把 21 章划分成了七个阶段核心内容是这样分布的阶段章节范围核心交付物基础环境第 1-3 章DeepAgents 安装、MCP 概念理解、跑通第一个带工具调用的 Agent工具接入第 4-7 章filesystem、Playwright、Figma、蓝湖等 MCP 全部接入并验证技能开发第 8-11 章掌握 SKILL.md 结构开发 design-to-code、ui-verification、commit-review单 Agent 复杂化第 12-14 章单 Agent 内部多工具协同、长任务错误恢复、上下文窗口管理A2A 协议第 15-17 章理解 Agent Card、Task、Message跑通两个 Agent 之间的任务交接多 Agent 编排第 18-20 章串行流水线、并行扇出、主从仲裁三种模式全部落地上线与观测第 21 章Langfuse 链路追踪、多 Agent 调优、成本与延迟优化如果你也打算自己从零起一套多智能体系统我强烈建议按这个顺序走。先不要一上来就规划复杂拓扑而是把“一个 Agent 一组 MCP 工具 若干技能”做成一个能稳定完成单点任务的成品再往上面加协作层。协作层一加调试难度会指数级上升基础不牢的话出问题时根本分不清是工具调用错了还是消息传丢了。5.3 几个代表性案例的实际效果案例一设计稿转组件。设计师在 Figma 或蓝湖上传一张首页 Hero 区域的完整设计稿Agent 读取画布结构、提取设计变量、生成 React Tailwind 组件、再用 Playwright 截图对比。这个流程目前跑一次大约 3 分钟中间会有一次人工介入确认设计变量是否正确。对比之前人工切图写组件再加比对的 30 分钟以上效率提升是实打实的。案例二多页面并行转换。把一个包含登录页、注册页、个人中心页的项目拆成三个并行子任务分别派给三个执行 Agent主 Agent 在完成后统一汇总风格差异并生成一份一致性修改建议。三个页面并行完成后风格统一性明显比串行做出来的更好因为所有页面在最终阶段都由同一个主 Agent 看过全貌。案例三文档自动生成与审查。让一个 Agent 根据代码提交信息生成变更文档再让另一个 Agent 审查文档和实际代码变更是否一致。这里 A2A 的 input-required 状态特别有用审查 Agent 一旦发现描述和实现不一致会主动挂起任务向用户询问而不是自己猜一个说法继续走。这套系统上线后的整体数据我做过一次统计MCP 工具调用成功率达 95% 以上端到端完成率从最初不带 Skills、不带 A2A 时的 60% 左右提升到加入全部机制后的 90% 以上。当然这 90% 里有相当一部分依赖最后的人工确认环节——复杂场景的视觉还原度仍然需要人来看一眼但原来的“全部人工实现”已经被压缩成“人工只做判断”这已经达到了我最初的设计目标。6. 多智能体系统的观测与调优Langfuse 链路追踪6.1 为什么多 Agent 的系统更难 Debug单 Agent 出错时你只需要看一次模型调用记录和工具返回基本就能定位问题。多 Agent 系统则完全不同一次用户请求可能触发十几个模型调用、几十次工具调用、若干个 A2A 消息。任何一个环节出错表象都可能是“最终结果不对”但它和真正的根因之间隔着好几层。我遇到过一个典型问题审核 Agent 总是报告视觉还原度不合格但人工看代码又没发现明显问题。如果只看最终报告永远查不出来后来把链路追踪打开才知道是 Playwright MCP 在无头浏览器模式下截图的默认视口宽度不对导致截图里所有元素都变形了。这种问题写在不同 Agent 的代码里没有贯穿全链路的 trace根本不可能靠猜定位。6.2 埋点设计把 A2A 任务 ID 和 Trace ID 绑在一起Langfuse 是我在这套系统里的主要观测后端它的核心模型是 Trace 和 Span。一个用户任务对应一个 TraceTrace 下面挂若干 Span每个 Span 可以记录一次 Agent 执行、一次工具调用或一段 A2A 消息处理。我对埋点有几个固定动作平台入口生成一个全局 trace_id对应整个任务。每个 Agent 执行过程挂一个 span记录 Agent 角色、输入、输出、token 用量。每次 MCP 工具调用挂一个子 span记录工具名、参数摘要、返回状态。每次 A2A 消息发送和接收也挂一个 span把消息体里携带的 task_id 与当前 trace_id 关联。实践里的关键一步是让 A2A 的 task_id 和 Langfuse 的 trace_id 保持同源。我在编排层生成任务时直接拿 trace_id 当作 A2A 任务 id 的前缀这样在 Langfuse 搜索一个 trace就能看到该任务在所有 Agent 之间的流转记录反过来在 A2A 日志里看到某个 task_id也能立刻跳到对应的完整链路。6.3 调优时重点盯哪几个指标多 Agent 系统上线后我每天固定看这几个指标指标说明经验阈值端到端完成率用户任务成功走完整个流程的比例目标 90% 以上单任务耗时从提交到最终完成的总时间根据任务复杂度定基线token 总消耗全链路所有模型调用之和出现异常上涨优先查上下文透传MCP 工具失败率工具调用失败次数 / 总调用次数超过 5% 要排查 server 稳定性A2A 重试次数同一任务被重复派发的次数持续增长说明消息设计有问题token 消耗是我最敏感的指标。多 Agent 系统的成本和三五个独立 Agent 完全不同它会把同一个任务拆给多个模型跑总 token 很容易失控。我发现一次 token 暴涨追下去是一个 Agent 把上一轮 A2A 收到的超长文本原样塞进了下一轮 A2A 消息导致同一个内容在链路上被反复传递和重复计费。修复方法很简单A2A 消息只传关键摘要和 artifact 引用不传原始长文本。另外A2A 消息里的大文件也要警惕。较早版本里切图 Agent 会把高分辨率图片 base64 编码后直接放在消息里发给代码生成 Agent一张图就占了几万 token。改成传文件路径引用后同一任务的 token 消耗从十几万降到了几万。这个优化做完整个系统的 API 费用直接降了四成。6.4 调优过程中最值得说的一次问题定位整个项目里让我印象最深的排查过程是“代码生成 Agent 偶尔会把组件写得完全偏离设计稿”。从最终表现看问题像是模型理解能力不足但打开 Langfuse trace 之后发现并不是代码生成 Agent 本身出错而是切图 Agent 在蓝湖 MCP 返回数据缺失的情况下擅自用上一轮缓存的旧图层信息生成了产物。代码生成 Agent 接收到的干净输入其实是错的导致它“正确”地实现了一个错误的设计稿。定位到根因后我在切图 Agent 的 Skills 里加了一条强制校验获取图层失败时必须终止任务并报错不允许用缓存数据兜底。一次排查教会我多智能体系统里“结果不对”和“某个 Agent 能力不行”之间经常隔着一条完整的消息链路不看链路只猜模型是永远猜不中的。7. 写在最后这一路踩过的坑以及我对多智能体设计的最终态度项目全部跑完之后我把踩过的坑按层面整理成了一份清单很多都是文档不会写、只有跑起来才会撞见的东西。MCP 配置类的坑npx -y首次启动慢导致 Server 超时。解决方法是提前手动执行一次命令缓存包或者给客户端调大 Server 启动超时时间。远程 MCP Server 的鉴权配置各平台不统一有的支持环境变量模板有的只能写死。写死 token 的配置一定要确认不会被提交到共享仓库。Playwright MCP 在无头模式下截图默认视口偏小视觉验证类任务需要显式设置 viewport。多个客户端共用同一套 MCP Server 时文件系统类 Server 的根目录不要直接指向整个磁盘给每个项目分配独立目录避免 A2A 任务跨项目误读文件。Skills 开发类的坑description 写得太宽Agent 容易在无关场景里强行套用技能写得太窄又会导致该触发时不触发。我的标准是一个技能的 description 必须在读完后能让模型判断出“现在用户的这句请求是否需要这个技能”。技能依赖的脚本和资源必须全部放进技能包目录里。我吃过一个亏技能里的脚本引用了系统绝对路径下的文件换一台机器直接跑挂。多个技能之间不要有重叠描述。早期“design-to-code”和“ui-verification”这两个技能 description 都提到了“检查页面效果”结果模型经常把两个技能同时加载执行顺序变成随机的。后来我把“设计稿转代码”限定为“生成代码”“视觉验证”限定为“打开页面截图比对”两者职责彻底分开。A2A 与编排类的坑两个 Agent 互相等待前置结果形成循环调用。解决方法是给 A2A 消息加最大跳数限制。A2A 消息过大导致接收方上下文窗口被灌满。解决方法是传 artifact 引用不传原始文件内容。角色职责定义重叠导致同一个子任务被两个 Agent 重复执行。我在 DeepAgents 里给每个节点加上了“职责边界描述”用“负责人 交付物”的口吻来定义比如“切图 Agent负责提取设计稿资源交付物是切图文件和设计变量 JSON”而不是泛泛写“负责处理设计稿”。最后说一点个人体会。多智能体系统真正的复杂度不在于“模型会不会用”而在于“边界怎么划、消息怎么传、状态怎么追踪”。在我这个项目里MCP 把外部工具变成标准接口Skills 把做事方法沉淀下来A2A 把 Agent 之间的协作变成可追踪任务流DeepAgents 则把所有节点的拓扑和状态管起来。四样东西缺一不可但也不是越多越好。如果你的任务单 Agent 就能稳定完成那就没有必要上多 Agent如果确实需要记住一个顺序先跑通单个 Agent 和工具链再沉淀技能最后再加 A2A 协作层。每次只引入一层复杂度出问题时你才知道该去哪里找原因。如果你也正在搭自己的多智能体系统我建议先从“一个 Agent 一个 MCP Server 一个 Skills”这样最小的闭环开始跑通后再逐步加节点。这套组合方式让我少走了大量弯路也希望它能帮你把“超级多智能体”从概念变成真正能交付的系统。
