如果最近一年你在做Agent相关的开发应该有个很明显的感受单Agent的Demo已经不难跑了难的是让多个智能体在一个真实业务场景里稳定协作。我去年接手过一个内部采购助手的项目最初就是三个Agent串行调用每个Agent各自接了两三个工具跑POC的时候效果不错一上真实数据就各种乱。后来才意识到问题不在于模型不够强而在于整个系统缺少三样东西统一的工具接入标准、智能体之间的通信协议、以及可复用的能力沉淀方式。这正好对应了今天要聊的MCP、A2A和Skills而DeepAgents这类编排框架则负责把这四样东西串成一条完整的生产链路。这篇内容适合三种人正在从单Agent转向多智能体架构、但又不知道从哪下手的开发者已经在用LangChain或自研框架、想引入标准协议来降低维护成本的团队以及做AI产品但总被工具接不过来、Agent之间没法对话卡住的产品技术负责人。我会把DeepAgents、MCP、A2A、Skills这四者的分工讲清楚再带你把一个真实的多智能体全流程从骨架搭到联调中间穿插我实际踩过的坑。1. 这套组合到底在解决什么从调函数的Agent到协议化的智能体网络1.1 单Agent的天花板在哪单个Agent的核心问题不是模型能力而是一个大脑管太多事之后必然出现的上下文稀释和工具混乱。你做客服机器人还好一旦让它既查订单、又调设计稿、还要写代码、还要做质检Prompt稍微长一点模型就开始顾此失彼。更现实的问题是你辛辛苦苦写好的工具接入逻辑换个项目全部重写没有任何可复用性。这也是多智能体架构火起来的原因——把一个复杂任务拆给多个专职Agent每个Agent只处理自己领域的事上下文更干净工具更聚焦。但多Agent同时带来了新的麻烦Agent之间怎么分工谁来调度怎么把任务结果传回去如果每个Agent都用不同的工具调用方式整个系统就是一座巴别塔。1.2 四个名词各管哪一段我习惯用一句话概括这四个东西的分工DeepAgents是编排大脑负责拆任务、调度子Agent、做计划、把人放进决策环MCP是手负责让Agent以统一方式调用外部工具和数据源A2A是嘴负责让不同框架、不同厂商的Agent之间能互相说话、派活Skills是肌肉记忆把某个领域的操作流程、代码规范、决策规则打包成可加载的知识包。换句话说MCP解决的是Agent怎么用工具A2A解决的是Agent怎么找同类协作Skills解决的是Agent怎么记住干活的套路DeepAgents解决的是谁说了算、活怎么派。1.3 这套组合适合谁如果你只是写个脚本让LLM调一两个API这套东西确实杀鸡用牛刀。但一旦你的业务有这些特征就值得投入任务可以明确拆成多个专业步骤需要对接多个异构系统数据库、设计工具、内部REST接口、浏览器自动化你希望Agent的能力可以被持续积累而不散落在Prompt里以及最重要的——你不想被某一个云厂商或框架绑死。这四件套凑齐之后换掉任何一个组件都不需要重写整个系统这就是协议化的价值。2. 概念辨析Skills、MCP、A2A不是同类东西别放到一个篮子里比很多人一上来就问MCP和A2A哪个好、或者Skills是不是就是MCP的升级版这种问题本身就问错了。三者解决的问题维度完全不同先把这个底层逻辑搞清楚后面才不会在架构设计上跑偏。2.1 MCP接管手的标准协议MCPModel Context Protocol最早由Anthropic在2024年底提出核心思路是把Agent要用的工具、数据、提示词模板从业务代码里抽出来做成独立的Server通过一套统一协议暴露给任何MCP客户端。这样你的Agent不用针对每个系统分别写接入代码只需要连上对应的MCP Server就能用它的工具。MCP有三个基础原语Tools可执行动作比如查订单截图、Resources可读取的数据比如配置文件的完整内容、Prompts场景化提示词模板。实际开发中Tools用得多Resources次之Prompts偶尔用来规范子Agent的交互模板。MCP的传输方式也值得注意本地工具多用stdio进程间管道远程服务多用Streamable HTTP基于HTTP的流式传输。选哪种取决于你的Server跑在哪——本机跑Python脚本用stdio最省事部署成微服务供多个Agent共享就必须走HTTP。2.2 Skills沉淀肌肉记忆的可执行知识包Skill的本质是一组关于怎么做事的文件和脚本通常包含一个带元信息的说明文档比如SKILL.md加若干辅助脚本、参考模板。它跟MCP最大的区别在于MCP给你的是能调用什么Skill给你的是应该按什么步骤、什么规范来做。举个例子。你的Agent已经通过MCP接上了Figma工具能读到设计稿的图层信息但它不知道拿到设计稿之后要先抽色板、再核对间距token、组件命名要符合什么规范——这些流程性知识就是Skill的活。DeepAgents这类框架有专门的Skills Harness来加载和调度这些知识包让Agent在进入某个任务前先把对应的操作手册读进上下文。2.3 A2A智能体之间的普通话A2AAgent2Agent是Google在2025年推动的智能体间通信协议解决的是两个Agent怎么发现对方、怎么派单、怎么返回结果的问题。它基于JSON-RPC 2.0通过一个叫Agent Card的JSON描述文件对外暴露Agent的能力、endpoint、协议版本等信息其他Agent拿到这个Card就可以发起调用。A2A的几个核心概念Agent服务提供方、Task一次任务实例、Message多轮会话中的一条消息、Artifact任务产出的文件/结构化数据、Part消息内容的组成部分可以是文本、文件或结构化数据。理解这几个概念后面看代码就很顺了。2.4 一张表理清三者的边界维度MCPSkillsA2A解决的核心问题Agent连接外部工具和数据Agent知道怎么做一件具体的事Agent之间跨框架通信与派活交互对象Agent ↔ 工具/数据源Agent内部知识加载Agent ↔ Agent表现形式独立Server暴露Tools/Resources文件目录SKILL.md脚本Agent Card JSON-RPC接口类比手和工具体系肌肉记忆和SOP手册人与人之间的语言和协作规则典型场景连Figma、连数据库、连内部API前端开发流程、数模分析套路跨团队Agent互相走查、派活2.5 Skills和MCP最容易混淆的场景我见到的真实混淆场景通常是这样的团队想让Agent会前端开发于是有人提议我们写一个前端开发MCP Server吧结果越写越别扭——因为这个Server里全是流程规则和代码模板根本不是工具接口。正确做法是把能抓取页面截图、能执行Shell命令这些动作用MCP实现把页面还原应该分几步、组件命名规则是什么、用什么技术栈写成一个前端开发Skill。两者配合Agent既有了手又有了脑子里的SOP。3. DeepAgents骨架搭建先把协调者跑起来3.1 安装与最小示例DeepAgents是LangChain在2025年发布的框架定位很明确做生产级的多智能体编排而不是又一个Demo框架。我第一次跑通它的时候最直接的感受是——它把规划、子Agent调度、人工交接、技能加载这些原本要自己写半天的东西做成了框架能力。安装非常简单pip install langchain-deepagents langchain-openai然后是最小骨架from langchain_deepagents import Agent from langchain_openai import ChatOpenAI model ChatOpenAI(modelgpt-4o, temperature0) orchestrator Agent( nameorchestrator, modelmodel, sub_agents[ Agent( namefrontend_dev, modelmodel, description负责前端页面编码与样式调整只处理React/TypeScript相关问题, ), Agent( namedesign_reviewer, modelmodel, description负责对照设计稿走查视觉还原度输出问题清单, ), ], ) result orchestrator.invoke( 把Figma里的原型实现成React页面交给design_reviewer走查一遍 ) print(result.output)这个例子看着简单但背后已经启动了完整的调度逻辑主Agent先按计划拆解任务判断该把哪个子任务交给frontend_dev等它产出代码后再决定是否转给design_reviewer。注意每个子Agent的description要写得具体这是主Agent路由时判断该派给谁的关键依据写得太笼统路由准确率会明显下降。3.2 理解子Agent与HandoffDeepAgents的核心机制之一是Handoff——子Agent完成自己的部分后可以主动把控制权交还给主Agent或者根据主Agent的指令转交给另一个子Agent。这跟我们人类团队里A工程师干完活把成果交接给B工程师review的流程如出一辙。实现上你不需要在子Agent里写什么特殊的交接代码框架会在合适的时机自动触发。但有一点要靠你自己设计交接时传什么。如果子Agent只是把一句我完成了交回去主Agent根本不知道它完成了什么。我通常会在每个子Agent的Prompt末尾加一句要求结束时必须在回复里包含产出文件的路径、关键决策和遗留问题这样交接内容才有信息量。3.3 DeepPlanning机制DeepAgents默认带了一个DeepPlanning机制主Agent不会一上来就把整个任务交给子Agent而是先做规划、再逐步执行。规划的频率可以通过planning_interval控制代表每执行多少步动作后重新做一次计划。默认值不一定要改但如果你的任务链条特别长比如超过20步建议把间隔调小一些让模型有更多机会根据中间结果修正计划。这里给一个实际调参经验planning_interval3适合中等复杂度任务任务如果高度可控比如纯数据处理可以调大到5任务不确定性强比如涉及多轮网页探索就调到2。频繁规划会多烧token但换来的是任务成功率明显提升这个权衡在真实项目中相当划算。4. 接上MCP从Figma到自定义工具4.1 MCP的三个基础原语在实际接入前先把MCP的三个原语和它们的调用方式理清楚Tools请求-响应式调用Agent决定调用哪个工具、传什么参数Server执行后返回结果。这是最常用的原语对应Agent的行动能力。Resources类似只读资源客户端订阅或读取用途是给Agent提供上下文数据。比如把一份设计规范文档注册为ResourceAgent需要时直接读不用每次Prompt里都塞。Prompts服务端定义好的提示词模板客户端按模板生成结构化Prompt。多Agent场景下可以用来统一某个子Agent的角色设定。写MCP Server时这三个原语用FastMCP这个Python库可以几行搞定。注意FastMCP在较新版本里推荐用mcp.run(transportstreamable-http)字符串形式的transport参数已经比早期写法稳定很多。4.2 在DeepAgents中挂载MCP ServerDeepAgents对MCP的支持比较完整你可以直接通过mcp_servers参数把工具挂进来。这里要注意新版本的写法是把已连接的MCP工具列表传给Agent而不是传Server配置本身。from langchain_mcp_adapters.client import MultiServerMCPClient async with MultiServerMCPClient( { figma: { transport: streamable-http, url: http://localhost:4000/mcp, }, sqlite: { transport: stdio, command: uvx, args: [mcp-server-sqlite, --db-path, ./app.db], }, } ) as mcp_client: agent Agent( namedata_helper, modelmodel, mcp_serversmcp_client.get_tools(), )这段代码里同时展示了两种传输方式Figma MCP走HTTP适合远程服务sqlite MCP走stdio本机起一个子进程跑。我建议你开发阶段尽量用stdio配置简单日志好追踪部署到生产环境再换成HTTP因为生产环境的MCP Server往往要供多个Agent实例共享。4.3 一个自定义MCP Server的完整示例假设你们的采购系统有个内部订单接口原先是REST API现在想让Agent直接查订单。最省事的做法不是让Agent去调REST还得给它写OpenAPI文档转工具描述而是包一层MCPfrom mcp.server.fastmcp import FastMCP mcp FastMCP(order-service) mcp.tool() def query_order(order_id: str) - str: 根据订单号查询订单状态与物流信息 # 内部调用采购系统的REST接口 return f订单 {order_id} 状态已发货预计3天内到达 mcp.resource(config://system/features) def get_features() - str: 获取系统功能开关配置 return new_checkouttrue;recommendationtrue if __name__ __main__: mcp.run(transportstreamable-http)写完之后Agent通过工具名叫query_order就能调用模型会从函数签名和docstring里自动理解参数和返回含义。这里我想强调一个细节docstring一定要写清楚。MCP Server的工具描述就是模型理解工具用途的唯一信息来源你写根据订单号查询订单状态与物流信息模型就明白什么时候该调用它你要是只写query_order模型大概率在边缘场景就漏掉这个工具了。4.4 前端/设计场景的常用MCP如果你的业务涉及设计稿转页面这几个MCP是社区里验证过的Figma MCP读取Figma文件结构、图层、样式变量适合让Agent理解设计稿结构。蓝湖MCP国内团队常用的设计协作平台能直接拉取标注和切图信息和Figma MCP解决的是同类问题但更贴合国内工作流。Blender MCP把Blender的操作暴露给Agent适合做3D素材生成和场景调整。Playwright MCP浏览器自动化拿来验证页面渲染效果非常实用我在联调环节几乎必挂它。这些Server大多走streamable-http部署时注意给每个Server配好独立的地址和端口。同机部署多个Server时端口写错是我见过最高频的启动失败原因排查时先看端口占用再看路径是否带上了/mcp后缀。5. A2A协议实战跨框架智能体协作5.1 A2A核心模型Task、Message、ArtifactA2A的调用模型有点像异步任务系统你给一个Agent发一条MessageAgent创建一个Task来承载这次对话多轮交互都挂在同一个Task下面最终Task会产出Artifact文件或结构化结果。理解这个模型你就知道A2A不是简单的请求-响应它是支持长任务、多轮、异步轮询的。调用方通常用message/send发起任务如果任务需要较长时间A2A 1.0支持轮询task/get获取最新状态不用一直占着HTTP连接。这在真实场景里非常重要——一个跨框架的走查Agent可能跑好几分钟你不可能让HTTP请求一直挂着。5.2 Agent Card设计Agent Card是A2A的门面它决定了别的Agent能不能正确发现你、调用你。按规范Agent Card默认放在/.well-known/agent-card路径也可以部署在根路径。一个最简Agent Card长这样{ name: DesignReviewer, description: 依据设计规范对UI实现进行走查输出问题清单, url: http://agent.internal.example.com/a2a, version: 1.0.0, protocolVersion: 1.0, capabilities: { skills: [visual_regression, design_spec_check], maxTokens: 16384, streaming: true } }我踩过一个很具体的坑description写得太泛结果其他Agent不管什么任务都往这个走查Agent上派。后来我把description改成仅处理UI视觉走查不处理后端逻辑路由准确率才上来。所以写Agent Card的description原则是明确边界不是写广告语。5.3 1.0和0.3的差异社区里现在还有人在用0.3但如果你是新项目直接上1.0。两者的差别主要在几个方面维度A2A 0.3A2A 1.0Agent Card字段结构较松散版本表达模糊明确protocolVersion支持扩展字段任务状态管理依赖SSE流式推送事件支持task/get轮询状态机更清晰结构化输出通过可选字段实现各家不一致标准化为structuredOutput能力声明消息流模式主要走流式推送明确支持Push和Pull两种模式认证预留但未细化明确OAuth 2.0授权流程你从0.3迁移到1.0时最需要改的是Agent Card里protocolVersion字段和任务状态轮询逻辑。我见过不少Agent挂着0.3的Card去调1.0的客户端握手就失败日志里报的都是奇怪的解析错误一查全是版本不匹配。5.4 在DeepAgents中作为A2A客户端调用外部AgentDeepAgents生态里可以用langchain-a2a工具包把一个DeepAgents Agent发布成A2A服务也可以作为客户端去调别人家的Agent。这是实现跨框架协作的关键一步——比如你的DeepAgents跑在Python端而设计团队的走查Agent是Node.js框架写的两边通过A2A对话完全不用关心对方内部实现。from langchain_a2a import create_a2a_client, create_a2a_server # 把DeepAgents Agent发布成A2A服务 a2a_server create_a2a_server( agentfrontend_agent, host0.0.0.0, port8001, agent_card{ name: FrontendDev, description: 前端页面实现与还原接收设计走查任务, }, ) # 作为客户端访问别的Agent client create_a2a_client(http://agent.internal.example.com/a2a) result await client.send_task( 请检查 http://localhost:5173 的按钮颜色是否符合设计规范 )调通的标志是客户端能拉到对方的Agent Card能建Task能在多轮Message里来回对话。初期联调我建议先用一个简单的echo Server验证握手再逐步把真实逻辑接进来否则排查问题时根本分不清是协议问题还是业务问题。6. Skills开发把经验打包成可复用资产6.1 Skill的目录结构与SKILL.mdLangChain生态和DeepAgents对Skill结构有一套约定核心是一个SKILL.md文件加若干辅助脚本和参考资料skills/ frontend_dev/ SKILL.md scripts/ analyze_layout.py generate_component.py references/ design_system.mdSKILL.md是这个Skill的入口带YAML frontmatter的Markdown--- name: frontend_dev description: 使用React Tailwind实现页面还原遵循公司设计系统 version: 1.2.0 tags: [frontend, react, tailwind, design-system] --- # Frontend Development Skill ## 适用场景 - 根据设计稿或需求描述实现前端页面 - 页面视觉还原与响应式适配 - 组件拆解与代码规范检查 ## 执行步骤 1. 如果提供了Figma链接先用figma MCP读取图层结构。 2. 运行 analyze_layout.py 输出页面区块划分。 3. 按 references/design_system.md 中的颜色Token和间距Token组织样式。 4. 生成组件组件命名遵循 design_system.md 里的规则。 5. 用 Playwright MCP 打开本地页面截图和设计稿对比。 ## 注意事项 - 所有颜色值必须引用design token禁止硬编码色值。 - 有疑问时生成 TODO 注释不要自行猜测交互逻辑。关键在name和description两个字段——DeepAgents的Skills Harness靠这两个字段决定什么场景下把哪个Skill加载给Agent。description写清楚触发条件和适用范围比洋洋洒洒写一堆正文更管用。6.2 一个前端开发Skill的实例上面的frontend_dev就是我实际用到的一个Skill骨架。它解决的核心问题是Agent写前端时经常自己发挥颜色乱写、组件命名随缘。有了这个SkillAgent在开工前会先把SKILL.md里的执行步骤读一遍配合design_system.md里沉淀的设计规范产出的代码风格稳定很多。你还可以给不同场景定制Skill数学建模的Agent可以挂一个建模分析Skill里面写清楚建模流程、常用模型选型规则、论文排版要求做自媒体文案的Agent可以挂网文创作Skill包含故事结构模板和分级节奏控制规则。社区里常见的Codex Skills、Superpowers Skills也是这个思路本质上就是前人把一套成熟工作流固化成了可加载文件。6.3 Skills Harness运行机制Skills Harness这个名词看着唬人实际就是Agent在合适的时机自动把Skill加载进上下文的调度器。DeepAgents会基于当前任务描述和Skill的description做匹配命中后把SKILL.md的内容注入Agent的上下文窗口。这里有一个设计取舍Skill内容太多会挤占上下文窗口太少又不够指导Agent执行。我的经验是SKILL.md正文控制在300到600字之间把详细步骤、代码模板放到references或scripts里让Agent按需读取。就像你带新人不可能第一天就让他读完整个团队wiki给一张先看这几页的清单就够了。6.4 怎样判断该写Skill还是写MCP判断标准其实很朴素如果这个能力需要连一个外部系统用MCP如果这个能力是告诉Agent按什么流程干活用Skill。要查订单、读数据库、操控Figma都是MCP要知道前端页面还原分几步、数学建模选什么模型、文案结构怎么组织都是Skill。两者也可以组合使用。Skill的执行步骤里完全可以引用MCP工具先用figma MCP读取图层就是在Skill里调用MCP的例子。Skill定流程MCP供工具这是目前我看到的最自洽的一套组织方式。7. 全流程联调从设计稿到上线走查的多智能体流水线7.1 任务设定前面做了这么多铺垫最终要落到一个能跑的完整流程上。我以一个实际验证过的场景为例用户提交一个Figma原型地址要求实现成React页面并让设计走查Agent检查视觉还原度。这条链路覆盖了DeepAgents编排、MCP工具接入、A2A外部协作、Skills知识加载四个环节是超级多智能体全流程的一个缩影。整个系统的组件清单如下主编排Agentorchestrator负责拆任务、路由、汇总结果frontend_dev子Agent挂载前端开发Skill接Figma MCP和Playwright MCPdesign_reviewer外部Agent独立服务通过A2A接入负责视觉走查文件系统MCP和sqlite MCP负责读写临时文件和记录任务状态。7.2 流程编排与Agent分工实际运行时的任务流转是这样的用户在主Agent里提交Figma链接。主Agent启动DeepPlanning把任务拆成读取设计稿 → 生成页面 → 本地渲染验证 → 走查四个阶段。主Agent把读取设计稿并生成页面交给frontend_dev。frontend_dev先通过Figma MCP获取图层结构再把前端开发Skill加载进上下文按SKILL.md的执行步骤输出React组件代码写入临时目录。frontend_dev调用Playwright MCP启动本地服务并截图把截图路径和代码路径作为交接信息返回给主Agent。主Agent发现需要外部走查于是通过A2A客户端调用design_reviewer把页面地址和设计规范链接传过去。design_reviewer跑完后返回问题清单。主Agent判断问题清单里有没有阻断性问题如果有把问题附带回传给frontend_dev要求修复如果没有输出最终总结给用户。这段流程的关键在于第2步和第4步的交接信息。我强烈建议在每个子Agent的结束回复里强制包含结构化摘要产出了什么、验证了什么、遗留问题是什么。这样主Agent才能准确判断下一步该干嘛而不是靠猜。7.3 实际联调中出现的问题与修正这套流程我第一次跑通花了大半天中间踩了几个坑记录下来给你省时间Figma MCP返回的图层顺序和视觉层级不一致。Figma的图层列表是按z序从底层到顶层的Agent直接按数组顺序读经常把背景层当成最上层。解决办法是在Skill里加一条规则读取Figma图层后先按zOrder字段排序再分析。Playwright MCP启动浏览器后端口冲突。多个Agent同时在本地起服务端口用默认值容易撞。我给Playwright MCP配了独立端口并在启动前用一条简单的socket检测保证端口可用。A2A走查Agent返回的JSON格式不统一。design_reviewer用的是0.3版本的接口返回的Artifact结构跟1.0不一样解析直接报错。最后统一把design_reviewer升到1.0问题才消失——所以跨团队协作时第一件事就是对齐协议版本。这些坑看起来零碎但每一个都会让流程从能跑变成跑不通。多智能体系统的调试难度是随组件数量指数上升的所以联调阶段一定要把日志打全每个Agent的输入输出、每次MCP调用的耗时、每个A2A Task的状态变化都留痕否则出了问题根本无从下手。8. 跑通之后稳定性和可观测性才是真正的分水岭8.1 MCP Server生命周期问题MCP Server不是启动一次就万事大吉。stdio类型的Server由客户端进程拉起如果你的Agent运行在长期运行的Web服务里Server进程可能会随客户端重启被多次拉起产生僵尸进程。我遇到的典型情况是Agent跑了几小时后机器上挂了十几个sqlite MCP的孤儿进程把端口和内存都吃掉了。解决办法是生产环境尽量用streamable-http模式部署MCP Server由进程管理器systemd或supervisor统一管理生命周期开发阶段用stdio方便调试但记得在Agent退出时清理子进程。另外给每个MCP Server加健康检查接口编排Agent在启动时先探活探不到就直接报错而不是等调用时才超时。8.2 A2A调用超时与任务状态管理A2A的Agent往往跑在别的服务上一次走查可能要几分钟。我们的HTTP客户端默认超时是30秒第一次联调时A2A任务才跑了一半就超时了客户端直接报错。后来改成提交任务后立即返回Task ID再轮询task/get拿状态的模式超时和长任务问题才真正解决。轮询间隔我建议10到20秒一次太频繁会给对方Server造成无谓压力太稀疏会拖慢整个流水线。另外一定要给任务设置总超时上限比如15分钟超过就标记失败并通知主Agent走人工交接不要无限等下去。8.3 上下文窗口管理多智能体系统最隐蔽的坑是上下文膨胀。每个子Agent都带着自己的历史交互记录主Agent还要汇总所有子Agent的结果跑几轮下来上下文窗口很容易爆。DeepAgents虽然会做上下文压缩但依赖模型的能力压过头就丢信息。我的经验是给子Agent设置明确的汇报精简指令交接信息只保留关键路径、决策和问题中间的过程日志写进文件而不是塞进回复。主Agent层面定期用摘要压缩子Agent的历史消息只保留当前任务相关的信息。这套文件化中间产物、摘要化交接信息的做法比单纯加长上下文窗口可靠得多。8.4 可观测性与测试策略多智能体系统的调试难点在于同样一个任务每次跑的内部路径都可能不同。我的做法是三管齐下结构化日志每个Agent、每次MCP调用、每次A2A任务都输出JSON格式日志包含任务ID、耗时、token消耗、结果摘要。事后可以按任务ID把所有环节串起来回放。回放测试把线上采集到的任务输入存下来作为回归测试集。每次改完Prompt或Skill先跑一遍这批用例对比成功率。多智能体系统的回归测试比单Agent更重要因为一个小改动可能影响路由决策。评估集要贴近真实不要用太理想的输入做测试真实用户的任务描述往往是模糊的、带噪声的。我测试集里专门放了一批用户只丢一个Figma链接啥都不说的用例逼着系统学会自己补全需求。把这套可观测性搭好之后系统才算真正迈过了实验室能跑的门槛。多智能体开发的乐趣就在这你搭的不是一个Agent而是一套有分工、有协作、能进化的数字团队而且这个团队的每一个成员、每一段经验都可以被替换、被升级、被复用。它现在还远谈不上完美但方向已经很清楚了——协议化、技能化、可复用的Agent生态就是接下来一两年最值得押注的技术主线。