1. 先把这个项目全景图说清楚四套技术各管哪一段1.1 一个真实的需求从设计稿到可运行代码我接手过一个内部工具项目设计师在蓝湖和Figma里面把页面改完前端开发照着视觉稿手动切图、翻译样式、写组件一个中等复杂度的页面往往要一两天。产品经理问我能不能让AI直接看懂设计稿再把代码骨架搭出来中间最好还能自动调用设计系统里的规范、自动检查落地的还原度。放在一年前这是个很棘手的问题。单靠一个大模型去读设计稿得到的只是描述不是可执行的工作流。现在这个问题有了相对完整的技术答案就是我标题里写的那套组合DeepAgents做编排MCP去接外部工具和数据Skills充当可复用的经验包A2A解决模型和智能体之间的通信。这四样东西各管一段拼起来就是一整套可落地的多智能体全流程。这篇文章不是官方文档的翻译是我把这两年在多智能体项目里的踩坑、调通、跑崩、又调通的过程连同对协议和框架的理解一次性整理成21章完整版之外的另一种完整版——不讲目录讲为什么这么做、实际跑起来是什么感受。1.2 MCP、A2A、Skills、DeepAgents各自的定位很多朋友一上来就被四个名词劝退了其实它们解决的完全是不同层面的问题。先说MCPModel Context Protocol。它是模型和外部工具之间的插座协议。没有MCP的时候你想让AI调用一个内部API要么自己写胶水代码要么把API封装成prompt暴力塞进去。有了MCP工具按标准协议暴露能力模型客户端按标准方式调用插上就能用。我把它理解成AI世界的USB-C接口。再看Skills。如果你把模型当成一个聪明但没经验的新人MCP给他的是工具箱Skills给他的就是老师傅的操作手册。一个Skill通常是一组带说明文件、步骤定义、参考案例的指令包告诉模型遇到这类任务时按这套方法论执行。它不像MCP那样直接调用函数而是提供一种可复用的做事方式。然后是A2AAgent-to-Agent。这是让不同智能体互相通信的协议。MCP解决的是AI调用工具A2A解决的是AI调用AI。当一个任务需要规划、编码、测试、UI还原多个角色协作时它们之间怎么打招呼、怎么派活、怎么回报结果就是A2A负责的事。最后是DeepAgents。它是一个具体的开发框架帮你把前面三样东西组装成一个可运行的多智能体应用。你可以把它理解成整条流水线的中控台负责调度任务、管理上下文、把Skills挂到合适的节点、把MCP工具暴露给子智能体、甚至通过A2A去和其他Agent服务对话。1.3 整条链路是怎么串起来的用我实际做的设计稿到代码流程来串一遍就清楚了。需求进来后DeepAgents里的规划节点先分析任务拆成读取设计稿规范、提取页面结构、生成前端代码骨架、检查还原度四个子任务。第一个子任务通过Figma MCP把设计稿的图层、颜色、标注读出来第二个子任务把数据交给一个挂了前端编码Skills的编码智能体第三个子任务再调MCP把生成代码推给本地脚手架工具如果这个过程涉及另一个独立的Agent服务比如一个专门做视觉校验的微服务那双方就通过A2A协议来通信主智能体下发校验请求视觉校验Agent回传差异报告。所以说白了Skills给智能体内功MCP给智能体手脚A2A让智能体之间有共同语言DeepAgents把这一切编排成一条跑得通的生产线。这篇文章后面会按这条逻辑线展开我会尽量讲清楚每个环节的为什么而不只是堆API。2. MCP先把手能伸到的地方铺开2.1 MCP到底在解决什么问题聊MCP之前我先说一个很多团队反复踩的坑在项目初期把工具调用直接写死在大模型的system prompt里。前端调用后端接口人肉维护一份长长的手册模型用的时候从里面猜参数。结果手册和实际接口一旦不同步模型要么瞎编工具名要么参数格式不对调试起来非常痛苦。MCP的核心价值就是把工具发现和工具调用标准化。一个MCP Server会通过标准接口暴露三样东西Tools工具、Resources资源、Prompts提示模板。客户端连上这个Server之后可以自动拿到工具清单、按标准格式发起调用、读取资源内容根本不用预先知道对方内部是怎么实现的。数据格式基于JSON-RPC 2.0传输层支持stdio本机进程间通信和HTTPSSE远程服务通信等模式。我举个例子你就明白它多省事。我们的设计稿存在Figma上Figma官方出了MCP Server。以前想让AI读设计稿得先导出PNG、再写图像识别脚本、再把识别结果转成AI能理解的文本。现在直接让DeepAgents连接Figma MCPAI自己就能发出get_figma_file_stylesget_figma_file_layout这类调用拿到的还是结构化数据比如颜色变量、字体、坐标、组件实例。需要注意的是MCP并非只能对接云端SaaS。我见过有人给本地股票软件做MCP Server把本地K线数据和选股结果暴露成工具还有人给CATIA、NXOpen这类工业设计软件包了一层MCP模型可以直接调用CAD软件的建模接口。这说明MCP的价值不止在互联网工具它同样适合企业内部系统、专业软件和本地数据源。2.2 手写一个MCP Server示例本地项目仓库分析理论讲再多不如写一个能跑通的Server。下面这个示例用Python实现目标是暴露一个本地项目仓库结构分析工具。它背后的能力很普通——就是把目录结构和文件行数统计出来——但关键是它用MCP协议把自己变成了AI可调用的标准化工具。import os from mcp.server import Server from mcp.server.stdio import run_server from mcp.types import Tool, TextContent app Server(repo-analyzer) app.list_tools() async def list_tools(): return [ Tool( namerepo_summary, description分析本地代码仓库返回目录树、总文件数和总行数, inputSchema{ type: object, properties: { root_path: {type: string, description: 仓库绝对路径} }, required: [root_path] } ) ] app.call_tool() async def call_tool(name: str, arguments: dict): if name repo_summary: root_path arguments[root_path] total_files 0 total_lines 0 tree_lines [] for dirpath, dirnames, filenames in os.walk(root_path): depth dirpath.replace(root_path, ).count(os.sep) indent * depth tree_lines.append(f{indent}{os.path.basename(dirpath)}/) for f in filenames: total_files 1 fp os.path.join(dirpath, f) try: with open(fp, r, encodingutf-8, errorsignore) as fh: total_lines len(fh.readlines()) except Exception: pass result \n.join(tree_lines[:200]) return [TextContent(typetext, text( f目录树前200行\n{result}\n f总文件数{total_files}总行数{total_lines} ))] if __name__ __main__: run_server(app)这个Server跑起来之后支持MCP的客户端比如DeepAgents、Claude Desktop、Cursor可以直接发现它。我刚开始写MCP Server时也犯过一个错误以为Tools越多越好把几十个接口全暴露出去。实际上MCP工具描述如果不够精确模型会选错工具反而降低成功率。工具少而精描述里写清楚什么时候用、参数是什么单位、返回什么结构才是真正的工程经验。2.3 主流MCP生态盘点从Figma到蓝湖再到安全测试工具给团队选型时MCP生态是否成熟是我最看重的指标。现在的情况是热门工具基本都有了官方或社区维护的MCP Server。设计协作类Figma官方MCP支持读取设计稿、图层、样式国内的设计协作平台蓝湖也推出了对应的MCP可用于获取设计标注、设计提案。前端拿设计稿生成代码是当前最典型的场景。开发工具类Cursor内置了MCP支持可以接入本地文件操作、代码搜索、Git操作等服务Codex的MCP可以用来执行命令行任务还有像Context7这类文档MCP把第三方库的官方文档结构化AI能在编码时动态查询最新API。安全与测试类Burp Suite和Yakit都有配套的MCP Server可以让AI直接操作流量、发送测试请求、分析告警。做AI辅助安全测试的团队现在省掉了大量脚本开发直接让模型通过MCP来编排测试工具。专业软件类CAD领域有CATIA、NXOpen的MCP方案虽然还比较早期但方向很明确——AI本身不擅长计算几何但通过MCP调用专业建模内核的参数化接口就能完成复杂的模型生成任务。金融数据类有人给通达信这类股票软件做了本地数据MCP这样模型可以直接读本地行情数据而不是靠大模型的记忆去编造数字。我的建议是新项目接入某个外部能力前先去MCP生态里搜一遍能直接用现成的Server就不自己写。但凡是核心链路依赖的工具一定要自己审计Server代码或自己写因为第三方Server的稳定性、权限边界、返回质量参差不齐。我给你一个排查口诀先看Server的返回是不是严格的JSON-RPC格式再看工具描述是否精准最后看有没有对网络和文件系统的访问限制。3. Skills给智能体装上传经编过的经验3.1 Skills和MCP的边界什么时候用Skill什么时候用MCP这可能是新手最容易混淆的一对概念。网上有张很火的对比图MCP是给AI一双手Skills是给AI一套肌肉记忆。这个类比不算精确但方向是对的。我自己的判断标准很简单如果一项能力需要通过调用外部函数才能完成选MCP如果一项能力是模型应该怎么做、按什么思考路径、参考什么规范选Skills。举个例子。我在项目里给前端编码智能体挂了一个前端开发Skills里面包含的不只是写代码这个动作还有拿到设计稿后先分析风格变量再搭组件树再写样式每一步都有检查清单。这套东西不是外部工具不需要调用函数但它能让模型的输出更稳定。相比之下获取设计稿标注这件事就必须用Figma MCP因为那是外部数据源。如果一个能力介于两者之间怎么选我给的补充判断是看是否需要模型利用外部实时状态。需要就MCP纯教模型怎么做就Skill。比如说从Git提交记录里生成今日工作总结需要读Git状态应该做成MCP工具而写commit message时遵循Conventional Commits规范属于做事方式做成Skill更合适。有一类数学建模Skills数模Skills在国内社区很火本质上就是把建模大赛这类任务的方法论沉淀成Skill赛题分析、指标选择、模型选型、论文排版每个环节都有对应的提示词模板和检查项。这也是Skills的正确用法——它承载的是经验和流程不是接口。3.2 一个Skill到底长什么样我以自己常用的结构图Skills为例拆解一下。这个Skill的作用是让AI在画架构图之前先做信息架构梳理然后产出Mermaid或PlantUML代码。它的目录结构基本上长这样structure-diagram-skill/ SKILL.md examples/ ecommerce.md event-driven.md references/ mermaid-cheatsheet.mdSKILL.md是核心里面有一段YAML格式的前置元信息然后再用自然语言描述任务目标、可用的工具、执行步骤和质量标准。简化后大概是这样--- name: structure-diagram-skill description: 根据需求描述生成架构图或结构图时使用防止AI直接乱画 --- # 结构图生成流程 1. 先从需求中提取实体清单和关系清单 2. 确认关系类型依赖、聚合、组合、单向/双向 3. 将实体与关系映射到图表语法 4. 检查是否有孤立节点、循环依赖 5. 最后输出图表代码和简短说明 ## 注意事项 - 如果没有明确说明优先使用 Mermaid 语法 - 实体名使用 PascalCase关系名使用小写短语 - 不生成超出需求范围的假设性模块 ## 参考示例 - 见 examples/ecommerce.md电商订单流 - 见 examples/event-driven.md事件驱动架构你可能会问这个Skill和直接把注意事项写在system prompt里有什么区别区别在于Skills是结构化、可积累、可复用的。你可以把几十个这样的Skill放到Skills目录里智能体启动时按任务类型动态加载而不是在一个巨大的prompt里全部塞满。Prompt会越写越乱Skill却可以像乐高一样灵活组合。3.3 Skills Harness和Superpowers带来的启发社区里关于Skills Harness的讨论不少我研究之后的理解是Harness指的是技能运行环境它决定了技能怎么被发现、怎么加载、怎么和模型交互。有的实现是文件夹扫描有的是在模型启动时按任务描述在向量库里搜出最相关的几个Skill再动态注入上下文。好的Harness设计会做三件事技能路由按任务选技能、技能隔离不同技能间的上下文不污染、技能链一个技能触发另一个技能。Superpowers这个项目给了我不少启发。它的思路是把技能做得非常细不只一个大而全的写代码技能而是按场景拆成调试技能重构技能写测试技能解释遗留代码技能。一个模型在编码任务里可能同时加载两三个技能任务不同技能组合完全不同。这不是形式上的花活而是工程上真实提升了成功率——因为每个技能里的提示词上下文更聚焦模型不容易精神污染。我在实际项目里测试过同样是用DeepAgents做任务分解挂不挂Skills对复杂任务的输出稳定性影响非常明显。不挂Skills时子智能体经常自由发挥步骤混乱挂了Skills之后子智能体会按Skill里定义的步骤顺序走即使模型版本换了输出质量也能保持稳定。这也是我把Skills视为多智能体系统的宪法的原因——宪法管住的是流程而不是具体某句话怎么写。4. A2A让智能体之间说同一种语言4.1 A2A与MCP的分工如果团队里只有一个AgentMCP加Skills基本就够用了。但多智能体场景下最头疼的问题不是单个Agent笨而是它们之间讲不通。你有你的工具我有我的状态你交付的东西我不知道怎么读取怎么办A2AAgent-to-Agent就是为了解决这个讲不通而生的。它把每个Agent视为一个服务Agent之间通过标准消息互相发现、通信、传递任务。你可以把它理解成HTTP之于Web那样不需要知道对方用什么语言写的、部署在哪台机器上只要双方遵守同样的请求响应格式就能对话。MCP和A2A经常被放在一起对比很多初学者会以为它们是对手方案。其实分工很清楚MCP是Agent的手A2A是Agent的嘴。MCP管的是Agent如何调用工具和系统A2A管的是Agent如何与其他Agent打交道。一个Agent完全可以既通过MCP调用外部工具又通过A2A把任务委托给另一个Agent。我常打的比方是MCP像是厨房里的厨具——统一的炊具接口什么锅都能放上灶台A2A像是餐厅和后厨之间的传菜窗口——传的是什么菜、怎么报单、怎么确认出餐这些规则大家都得认。4.2 Agent Card从0.3到1.0协议演进中最关键的变化A2A协议从0.3版本演进到1.0版本的过程中最值得关注的是Agent Card从格式化名片变成了协议级的能力声明。0.3版本里Agent Card已经定义了Agent的名字、描述、URL、版本号还定义了一组skills数组——每个skill描述这个Agent能做哪个具体任务。当时的问题是卡片信息太薄缺乏对交互模式的约束两个Agent即使都实现了协议仍容易在任务类型是否匹配卡片宣告的技能与运行时能力是否一致上出偏差。1.0版本做了几个关键收紧我挑最重要的三点说第一Agent Card里的skills字段被进一步结构化。每个skill从简单的名称描述升级为包含操作参数说明、输入输出结构和处理能力的声明。这非常像把JSON Schema内嵌到了卡片里。一个Agent拿到另一方的卡片后不只是知道哦他能处理前端重构还能知道他需要我传design_tokens和page_structure这两种结构输出的是React组件代码。第二任务对象Task的生命周期被明确。A2A中Agent之间的对话以Task为单位每个Task有id、status、artifact产出的成果物、message消息记录。1.0版本强调Task的最终状态必须是completedcanceledfailed这类明确终态避免两边因为我以为你还在算导致死等。第三能力协商机制更完善。1.0版本的AgentCard可以让Agent声明自己支持的能力配置比如是否支持长时任务回调、是否支持流式消息、是否支持客户端发起的重试。这让处于不同部署环境内网/公网、离线/在线的Agent可以彼此协商出一个双方都接受的通信方式。一个完整的1.0版本Agent Card示例大概长这样{ identifier: ui-review-agent, displayName: UI还原度审查Agent, description: 接收设计稿数据和前端代码返回视觉还原差异报告, url: https://agent.example.com/a2a, version: 1.0.0, capabilities: { streaming: false, pushNotifications: true }, skills: [ { id: visual-diff, name: 视觉差异检测, description: 用于比较设计稿和实现稿在颜色、间距、字体上的差异, inputModes: [application/json], outputModes: [application/json] } ], security: { authentication: { schemes: [bearer], credentials: required } } }从0.3到1.0最核心的变化是卡片从给人看的宣传页变成了机器能解析、能决策的契约。4.3 一个可落地的A2A交互流程纸上谈兵没意思我拿一个实际用过的场景演示A2A的交互流程。假设主Agent是项目规划Agent我们叫它Planner子Agent是前端编码Agent叫它Coder它们分布运行在两个不同的服务进程里。第一步Planner通过A2A协议向Coder发送一个TaskTask的payload里明确写了输入和期望输出{ jsonrpc: 2.0, method: tasks/send, params: { id: task-001, message: { role: user, parts: [ { text: 请根据design-payload.json生成前端页面骨架 } ] } } }第二步Coder收到Task后先不回完成而是返回一个pending状态然后异步处理。处理过程中它会调用自己的MCP工具拉取设计稿数据、查组件库再按前端Skills里的规范写代码。完成后通过tasks/complete方法回传结果{ jsonrpc: 2.0, method: tasks/state, params: { id: task-001, status: completed, artifacts: [ { name: generated-code.zip, metadata: { files: 23, language: tsx, framework: react } } ] } }第三步Planner解析artifacts如果发现还有后续任务比如把代码交给视觉审查Agent就再走一遍同样的流程。整个过程里每个消息都必须是标准化的不能有双方私下约定的暗号。这就是A2A最大的价值它把Agent网络从一个单体应用变成了可扩展的开放生态。我在实际落地时的体会是协议本身不复杂但Agent给的承诺要能兑现很重要。1.0版本之所以加强Agent Card就是希望大家在真正通信前先把能力边界说清楚。如果你把不存在的能力写进Agent Card另一方按契约来请求你返回不了预期结构整个信任体系就崩了。5. DeepAgents把上面的东西编排成真正的项目5.1 DeepAgents的工程化形态和核心设计DeepAgents给我的第一印象是它不像传统调用大模型API的脚本那么单薄而是一个真正以Agent为第一公民的开发框架。它对多模态输入、交互式运行的支持让人觉得它更像一个Agent IDE而不只是一个SDK。我使用之后把它的核心设计归纳成三点第一以任务中心化的方式组织Agent生命周期。框架会维护一套历史记录系统记录每个错误修复动作、交互失败模式、子步骤的完整过程。任务从创建到完成有明确的状态流转这跟A2A协议的Task模型是天然对齐的。你可以查看每个子Agent干了什么、产出是什么、失败了之后试过哪条新路径。第二支持多模态交互。它不只处理文本还能直接处理图像、文档截图等输入。我在设计稿还原场景里直接把Figma导出的视觉稿截图喂进去让规划Agent先看图说话把页面结构提取成文本描述再把描述交给编码Agent。这条链路没有DeepAgents的多模态支持时完全走不通。第三Skills和MCP合并接入。DeepAgents支持在任务规划阶段就把Skills和MCP工具纳入考虑。你可以直接告诉框架给编码Agent挂上前端开发Skills同时把Figma MCP提供的工具暴露给它框架会把这些配置应用到运行时的智能体上下文里。5.2 用DeepAgents写一个多智能体协作流程示例下面是一段简化版的伪配置和代码展示我如何在DeepAgents里定义Agent角色、挂载Skill、连接MCPfrom deepagents import DeepAgent, Skill, MCPToolRegistry repo_analyzer MCPToolRegistry.connect(repo-analyzer) figma_tools MCPToolRegistry.connect(figma-server) planner DeepAgent( nameplanner, role项目规划, instructions分析需求并拆解为可执行任务, ) coder DeepAgent( namecoder, role前端编码, instructions按前端工程规范实现页面代码, skills[Skill.load(frontend-development)], tools[repo_analyzer.tool(read_project_config)] ) design_specialist DeepAgent( namedesign-specialist, role视觉还原, instructions读取设计稿提取样式变量和布局结构, tools[figma_tools.tool(get_figma_styles)], ) # 多智能体协作planner 拆解任务后派发给其他 Agent result planner.delegate( task把Figma页面转为React/Tailwind代码, assigns{ design-analysis: design_specialist, code-generation: coder, } )注意几个细节MCPToolRegistry.connect会把MCP Server暴露的工具做一层鉴权超时包装避免子Agent乱调工具Skill.load会在Agent启动时把选中的Skill加载进上下文而不是等到运行时再临时注入。这里有一个容易被忽略的工程决策为什么要让design-specialist负责提取样式而不是让coder直接连Figma MCP原因是我希望读设计稿和写代码两件事有清晰的上下文边界。设计稿数据很杂如果直接全部塞给coder它既要处理视觉信息又要写代码容易分心先由design-specialist提取出精简的样式token和布局树再传给coder后者只需专注代码生成成功率明显更高。5.3 编排层要重点设计的状态管理多智能体系统里状态管理是最容易失控的部分。我见过很多项目Agent之间靠来回传递超大JSON报文维持状态跑几轮之后上下文爆掉、关键信息丢失、子Agent开始互相覆盖对方的产出。我的经验是在编排层必须明确三条状态规则第一子Agent之间不共享非必要上下文。每个子Agent只拿到完成本任务必需的输入输出也只保留关键产物。比如design-specialist输出的是样式变量布局树而不是一份5000行的Figma原始JSON。在DeepAgents这类框架里你要显式设计每个Agent的输入契约和产出契约。第二任务状态必须持久化。不能只把状态放在内存里因为任何一个Agent超时挂掉整个任务链都会断。我一般会把Task状态同步到Redis或者数据库记录哪个Agent负责、当前阶段、已完成产物地址。第三要有全局回滚点。多智能体协作难免出错出错后如果只能从零开始成本太高。我会在每个关键节点生成一个阶段快照比如设计稿解析完成代码骨架生成完成出错时从最近的成功快照继续。这个思路和数据库的checkpoint机制很像。6. 端到端实战复盘从设计稿到代码骨架的完整流水线6.1 项目结构和任务拆解前面讲了不少原理现在完整复盘一遍我实际搭过的流水线。任务很明确输入一个Figma/蓝湖设计稿输出一份可运行的ReactTailwind页面骨架。我把整条流水线拆成五个阶段阶段负责Agent主要工具产出物需求解析PlannerDeepAgents规划上下文任务清单、页面清单设计稿分析Design SpecialistFigma MCP / 蓝湖 MCP样式token、布局树、组件标注代码生成Coder前端开发Skills、仓库工具React组件、Tailwind样式静态检查Reviewer项目配置MCP、Lint工具差异报告、错误修正建议人工确认全局唯一不需要最终合并请求为什么把静态检查单独作为一个Agent而不是让Coder自己检查自己因为让写代码的Agent检查自己写的代码等于让考生自己判卷除非有非常严格的checklist否则基本都是我检查过了没问题。独立Reviewer角色的存在价值一方面是隔离上下文另一方面是审视者的立场会让它更容易发现问题。6.2 核心串联代码在这个流水线里最重要的串联逻辑是产出物如何在Agent之间传递。我用的核心代码逻辑如下from deepagents import DeepAgent, Skill, MCPToolRegistry # 1. 连接外部工具 figma MCPToolRegistry.connect(figma-server) project_loader MCPToolRegistry.connect(project-loader) # 2. 定义三个核心Agent design_specialist DeepAgent( namedesign-specialist, role视觉解析, tools[figma.tool(get_figma_file)], instructions分析设计稿返回样式变量、布局树和组件列表, ) coder DeepAgent( namecoder, role前端编码, skills[Skill.load(frontend-development), Skill.load(tailwind-patterns)], tools[project_loader.tool(create_component)], instructions严格按照输入的结构化设计信息生成React组件, ) reviewer DeepAgent( namereviewer, role代码审查, tools[project_loader.tool(lint_project)], instructions调用lint工具检查代码问题列出所有差异点不要直接修改代码, ) # 3. 编排主流程 planner DeepAgent( nameplanner, role编排调度, instructions把设计稿转代码任务串联起来发现问题及时回滚, ) # 实际执行解析设计稿 - 生成代码 - 审查修正 design_report design_specialist.run(读取design payload并输出结构化的JSON) code_deliverable coder.run( f基于以下设计报告生成代码: {design_report} ) review_report reviewer.run(f检查以下代码并返回报告: {code_deliverable}) # 4. 如果Reviewer发现问题循环回去让Coder修改 if not review_report.is_clean(): for issue in review_report.issues: coder.run(f修复如下问题不要引入新问题: {issue.description})这段代码看着简单实际运行中花了我最多时间调试的不是Agent本身而是Reviewer提的问题Coder改不动的死循环。后来我用两个手段解决一是Reviewer的报告必须结构化问题必须带着文件路径行号建议修改不能只给一句代码质量不佳二是每个Agent的修改有次数上限超过上限就交给人工处理避免无限死循环。6.3 运行实测和经验总结用一套真实页面跑完整条流水线之后我记录了几个关键数字设计稿标注的样式提取成功率在95%以上偶尔失败是因为Figma里用了非标准的文本样式生成代码的初次通过率大概在70%左右剩下30%需要Reviewer指出后一轮修改就能解决真正的死循环占比不到5%基本都是视觉差异主观性太强导致的。这组数据背后藏着一个经验设计稿转代码这件事还原度的评判标准先得定义清楚。我在项目里给Reviewer明确列了检查优先级第一是样式token与设计稿一致颜色、字号、间距不能错第二是布局层级正确父子组件嵌套关系不能乱第三才是视觉细节阴影、圆角、渐变这类主观项。这个优先级排序让Reviewer的输出稳定了很多。再分享一个看起来小但对成功率影响极大的细节给Figma MCP的token配置必须处理超时问题。Figma大文件动辄几百MBMCP调用一次可能两三分钟。如果不做超时控制和任务分段Client那边早就断开了任务直接失败。我的做法是先调用Figma的文件树接口拿到页面结构再按页面一个一个拉取图层数据最后统一汇总而不是一口气读全量文件。另一个心得是生成代码这一步的Skills质量直接决定项目的天花板。我给Coder挂的前端开发Skills里不仅有通用规则还有团队自己的编码规范、组件库使用文档、甚至是几个反面案例。这些内容让模型在生成代码时就不是会写JS的人而是熟悉我们团队规范的前端。7. 踩坑记录和可复用的优化建议7.1 MCP调用超时与并发控制多智能体系统里最典型的故障就是MCP调用超时。我总结下来超时原因通常不是网络慢而是模型不知道这个工具会慢。MCP工具列表在模型眼里是一视同仁的函数模型以为调用两个工具的时间差不多结果连续串行调用了好几个Figma大文件接口整个任务链卡死。我的优化方案有三条按性价比排序第一给MCP Server端做任务超时上限进度回调让客户端知道当前任务在跑没挂第二在工具描述里显式写明本工具耗时可能超过60秒请在使用时……让模型提前有预期第三在编排层做并发控制不要同时给子Agent暴露太多MCP工具否则模型会乱。7.2 技能命中率低的问题从塞规则到写意图有段时间我一直在往Skills里堆规则觉得规则越多模型越不会犯错。结果事与愿违SKILL.md越来越长模型反而看不到重点了输出质量下降。后来我把一堆规则改成了意图决策树的结构。每个Skill的description里写清楚什么情况下用这个Skill而不是这个Skill包含……。比如我把frontend-development的description从包含React编码规范、组件设计模式、Tailwind最佳实践改成当你需要根据设计稿生成React页面代码时使用尤其是从Figma/蓝湖输出转代码。这一改模型按需加载Skill的准确率提高了不少。这个经验契合了Skills Harness的设计原则技能路由靠的是意图匹配而不是关键词匹配。你写Skills的description时要从这个技能能做什么切换到在什么任务场景下应该用我。7.3 关于预测多智能体交互的世界模型这类进阶话题最近社区里开始讨论能预测多智能体交互的世界模型这类方向我也关注了一段时间。它的思路是用一个大模型去模拟如果Agent A采取动作XAgent B会如何反应从而预判多智能体交互的结果减少试错成本。虽然现在还比较早期但它指向一个趋势多智能体系统不能只靠现场调度最好能在行动前做一些推演。我个人的看法是实战项目里可以先从规则加轻量预测做起不必等一个完美世界模型。比如我在流水线里预设了一些已知坏模式Coder生成的组件名和现有项目冲突、Reviewer和Coder对某个视觉规范理解不一致、MCP工具在某个特殊目录下报错。这些坏模式被沉淀成规则后Planner在派发任务前会先检查输入是否命中坏模式命中就预先调整避免执行期才发现问题。这些规则用久了其实就是一个轻量世界模型的雏形。最后再分享一个工具选型的建议不要被框架名迷惑也不要一上来就想改造框架。先用DeepAgents套现成的MCP生态和Skills体系把一条端到端流程跑通再去考虑自研编排器或者引入更复杂的A2A网络。分布式系统里先让流程跑起来比架构好要重要得多架构是在跑的过程中长出来的不是一开始设计出来的。希望这篇文章能帮你少走几步弯路。
