1. 单体Agent的墙我是一头撞上去的先说个背景。过去一年我带着团队做了好几个基于大模型的应用最开始所有智能体都按“单体巨石”的方式搭一个Agent塞进去系统提示词、工具列表、记忆模块、业务流程状态机产出一个最终答案或执行动作。早期这种架构确实见效快因为业务面窄、工具数量少一个Agent里挂上三四把工具、写清楚系统提示词效果就已经不错了。但业务一扩、场景一多问题就逐步暴露了。最典型的几个场景业务需要同时跨内部系统、外部API和知识库去完成任务单体Agent的工具列表不断膨胀系统提示词越写越长大模型在“调用哪个工具”这件事上开始出现选择困难——明明应该调A工具去拿交易数据它偏偏去调了B工具查用户画像明明只需要一步操作为了“显得严谨”Agent自己多绕了两道工具调用反而把数据搞脏了。真正让我下定决心放弃单体架构的是一次线上事故一个Agent在处理退款任务时同时调用了“查询订单”和“查询用户余额”两个工具由于系统设计时没有隔离模块间的上下文它把余额数据当成了订单金额往下游走最后给用户多退了钱。虽然事后通过补偿机制挽回但这给了我一个很清楚的信号单体Agent在工具数量少、协作链路短的时候是效率最高的形态但一旦横向长出多个业务域、纵向拉出多层协作它就是一个不可控的定时炸弹。行业内对这件事的解法也在过去一年里逐渐收敛成几条清晰的技术路线DeepAgents负责把“单个任务”拆解为“多个Agent角色的分工”MCP解决“Agent怎么安全地调用外部工具和数据”A2A解决“多个Agent之间怎么互相通信、互相发现、互相协作”Skills解决“怎么让Agent高效复用一套沉淀下来的能力和经验”。这四个东西各管一段搭配在一起才真正把“单体Agent”的墙推倒搭起一个“多智能体组织”。这篇文章就是把我过去大半年落地这套组合方案时的工程思路、踩坑记录和设计取舍完整铺开。2. DeepAgents的“组织化”思想先分角色再谈协作在谈MCP、A2A之前必须先把DeepAgents这个“组织者”的角色说清楚。DeepAgents本质上是在单Agent之上再加了一个“编排层”它本身不直接处理具体业务而是根据用户的目标输入在后台规划出几个具有不同职责的Agent实例然后把任务分发给它们、汇总结果、做质量校验。简单类比单体Agent像一个“个体户”什么活儿都自己干DeepAgents像一家“公司”有CEO、有部门、有执行层所有员工各管一摊CEO只负责拆解目标和验收结果。我在实际落地时遵循的编排原则有三条角色最小化能拆成三个Agent就不拆五个角色边界越清晰系统提示词越短模型的工具选择越稳定。我们最常见的拆分模式是Planner规划器 Researcher信息收集/检索 Executor执行器。Planner负责将复杂目标分解为靠后的子任务Researcher负责通过MCP协议拉取外部数据Executor负责执行明确的动作写数据库、发消息、调外部API。显式路由而非让模型自由发挥我们不依赖模型自己判断“这个任务该给谁”而是在DeepAgents的编排逻辑里写清楚任务优先级和路由规则。比如任务包含“查询余额”关键词就直接路由到Researcher包含“扣款”“修改订单”就路由到Executor并进入人工确认分支。这个设计极大降低了模型误判的概率。上下文隔离在任务分发时每个Agent只看到与自己相关的上下文窗口。这一步在工程上看起来很简单无非就是拼接prompt时做过滤但实际价值极高——我们观察到的工具误调用率至少下降了四成原因就是Agent不再被无关信息干扰。这套设计带来的另一个额外好处是可观测性。单体Agent内部在做什么基本是黑盒出了问题你只能翻日志猜。拆分角色后每一个Agent的输入输出天然形成了一条可追踪的任务链路用户意图 - Planner规划 - Researcher检索 - Executor执行。后期做效果评估、性能分析、问题回溯都变得非常直接。但要注意DeepAgents不是万能钥匙。它解决的是“组织形态”问题不解决“Agent怎么和外部世界交互”的问题。你拆了十个角色如果每个角色都裸调HTTP接口、手写JSON解析、自己管理鉴权那么工程成本会极其高昂错误率也会成倍增长。这时候就轮到MCP上场了。3. MCP把“能调用的东西”变成标准接口而不是让每个Agent各写一套MCPModel Context Protocol模型上下文协议是目前在Agent工具调用领域最值得提前投入的一项标准化工作。它的核心思路是把Agent需要的外部能力工具、数据源、工作流统一包装成标准化的“资源”让Agent通过一套通用的客户端协议去调用而不是针对每一个外部系统单独写一段集成代码。在我动手改造之前团队内部Agent接一个第三方系统流程大概是拿到对方API文档 - 写SDK封装 - 处理鉴权 - 写工具函数 - 手动配置到Agent的tools列表里 - 调参验证。每接一个系统平均消耗两三个工作日而且每个系统的返回格式、错误码、鉴权方式都不一样Agent对接层越堆越乱。引入MCP之后流程变成了写一个MCP Server把目标系统的API包装成标准化的tool/resource - 在Agent侧配置MCP客户端连接 - 完成。一次封装处处复用。不仅仅内部系统可以这样做社区里也已经有很多现成的MCP Server生态从数据库、git仓库、浏览器自动化到各领域的垂直API基本都能找到可用实现自己只需要做少量定制。从工程角度看我认为MCP最值得理解的是三个基础概念概念作用我常用的场景Tool可被Agent主动调用的动作类似函数调用有输入输出约束写数据库、发消息、调外部业务APIResource供Agent读取的静态数据源内容可能动态刷新知识库文档、数据库Schema描述、业务配置Prompt Template可复用的提示词模板支持参数化常用分析框架、报告生成模板这里有个很多人容易忽略的点Tool和Resource的使用方式完全不同。Tool是Agent“决定调才调”的动作Resource是Agent在上下文窗口里直接“加载”的数据。如果你的Agent经常需要看一份政策文件、一份产品说明那应该走Resource而不是设计成一个tool让Agent反复调用。Resource走的是上下文加载通道效率更高还能配合向量检索做增量注入tool走的是执行通道适合有副作用、有参数校验、有返回结果处理的需求。我自己在项目里踩过的一个真实坑是一开始把所有外部能力都封装成了tool结果Agent在回答前要先“调用”好几个tool去读文档又慢又费token还经常因为返回太长导致上下文溢出。后来把只读类的能力全部改成Resource并配合检索过滤整体响应速度明显上来了也开始暴露了另一个问题——MCP把“Agent到工具”的路径标准化了但多个Agent之间依旧不知道怎么互相发现、互相协作。举一个我们项目中的直观对比改之前Agent内部直接用硬编码的fetch去请求内部接口。一旦接口改动必须重新改代码、重新发布而且每次新接入一个Agent都要为它单独配置API密钥、单独处理限流。改之后接口统一做成MCP Server所有Agent共用一个MCP客户端配置。接口逻辑改动只改Server端Agent侧零改动鉴权收敛到Server一侧安全策略可以统一管控。同时MCP在开发调试上也有讲究。我们内部对MCP Server的调试流程是先用一个简单的命令行客户端做冒烟测试确认工具能返回预期结果再接入Agent做端到端验证最后才放到生产环境。社区里也有人犯了“连工具本身都没通就丢给Agent去调”的毛病最后排查了半天发现是Server返回格式字段和Agent解析逻辑不一致——这类低级失误完全可以在接入前规避掉。4. A2A让Agent互相“看得见、找得到、传得懂”如果说MCP解决的是Agent和工具之间的握手那A2AAgent-to-Agent解决的就是Agent和Agent之间的握手。A2A是一种应用层协议它主要包含几个核心要素AgentCardAgent的能力描述文件用于服务发现、任务管理协议任务的创建、更新、完成状态同步、消息路由规则不同Agent之间如何传递任务上下文和结果。在引入A2A之前我们的多Agent协作是“硬编码式”的——Planner写死了调用Researcher的类方法、写死了调用Executor的接口。这种硬编码最大的问题是没有可发现性。比如我想新增一个财务分析Agent想让现有Planner在某些条件下路由给它就必须改Planner的代码哪天想调整Agent的职责又得同步改路由逻辑改动成本极高。而且Agent之间的通信完全依赖内存里的对象调用一旦进程重启、会话恢复整个协作链路就断了。A2A给的做法是每一个Agent启动时都把自己的AgentCard注册到中心服务上或者被中心服务轮询发现AgentCard里描述了Agent的能力名称、输入输出格式、调用入口、认证方式等元信息。这样一来编排层的路由判断就不是基于“代码写死的对象引用”而是基于“能力匹配和当前Agent的可用性状态”。用大白话说MCP让工具变成了可以被插拔的服务A2A让Agent本身也变成了可以被发现、被路由的服务节点。我在项目中具体做了一个轻量的A2A实现每个Agent启动时向中心Registry上报自己的AgentCardJSON格式包含agent_id、agent_name、capabilities列表、输入/输出Schema。编排层在分发子任务前先查Registry找到能力匹配的Agent列表如果有多个候选再根据负载、业务优先级做一次排序选择。两个Agent之间传递任务时统一走A2A的task协议请求里带task_id、payload、期望输出格式响应里带statuspending / completed / failed、artifact引用或直出数据。所有协作状态都会落库会话可以被恢复任务进度可以随时查询。这套机制落地后原先“新增一个Agent要改一遍主流程代码”的问题彻底解决了。现在新增Agent只需要写一份AgentCard注册上去编排逻辑自动认识它遇到符合它能力的任务会自动尝试路由。而且由于A2A协议天然带上任务状态管理我们还能顺手做一个可视化的任务链路看板管理成本直线下降。但A2A也不是没有陷阱。一个很容易踩的坑是“过度设计Agent之间的对话”。有人把A2A理解成“让两个Agent自由对话”于是让Planner和Executor之间互相发类似于自然语言的消息来回拉扯好几轮才完成一个简单动作。这在Demo里看起来很酷但实际生产里token消耗大、延迟高、结果不稳定。我的建议是Agent之间的通信尽量走结构化协议每个任务只做必要的一次或两次交互不要开放无节奏的“聊天模式”。自然语言只用于面向用户的最终输出内部协作越结构化越好。此外还有安全问题A2A让Agent暴露在网络上之后访问控制必须提前设计好。我们内部的方案是让所有Agent跑在内网环境对外只有一个入口Agent其余Agent不接受未经Registry认证的请求。同时每个Agent的AgentCard里都会标注它可接受的输入Schema非匹配的payload一律拒收相当于对外部输入做了一层最基础的校验。5. 协同链路怎么串一次“自动排查退款异常”的完整流程讲了这么多概念和组件还是用一个我们实际上线运行的场景把整个链路串一遍——智能售后助手自动排查退款异常。用户发起一条求助消息“我上周申请的退款还没到账帮我查一下怎么回事。”以前的单体Agent处理方式Agent接收消息自行决定要调用订单查询工具、退款状态查询工具、流水查询工具——三个工具它可能一次性全调了也可能漏调一个还可能调错顺序。结果经常是要么回答“订单还在处理中请耐心等待”打发了用户而实际是因为银行回调失败导致退款卡住要么把Multiple数据源里的信息混在一起回了一大堆用户根本不需要看的内容核心原因反而没讲清楚。现在基于DeepAgents MCP A2A的协同处理流程是这样入口AgentPlanner收到用户消息先做意图理解和任务分拆。它判断这是一个需要跨系统查询的退款异常case于是把任务拆成三个子任务查订单状态、查退款申请流水、查支付渠道回调记录。Planner通过A2A协议把三个子任务分别路由给不同的Agent订单Agent负责订单状态退款Agent负责退款流水支付Agent负责渠道回调。这三个Agent各自通过MCP Server去访问对应的业务系统订单Agent调订单查询MCP退款Agent调用退款记录MCP支付Agent调用支付回调MCP。三个Agent各自完成查询后通过A2A协议把结构化结果返回给Planner而不是让三个Agent直接把结果拼起来丢给用户。Planner汇总后做一次“原因诊断”如果订单状态正常但退款记录里存在“渠道回调失败”的标记就定位到这次退款卡住的根因同时生成用户可以理解的回复并附带一个“下一步可自动重发回调”的按钮。用户点击确认后Planner再次把“重发回调”这个动作路由给退款Agent退款Agent通过MCP调用对应外部系统接口执行重发。这条链路里每一步的职责都很清晰没有任何Agent看到了与它无关的数据也没有任何一个Agent需要理解用户所有可能的上下文。这种清晰是单体Agent无法做到的——单体Agent既要理解用户完整意图又要自己掌握所有工具调用方式和数据源格式一旦业务复杂度上来出错率指数级上升。实际线上表现方面我们当时做了AB对比同一个测试集200条退款类用户问题单体Agent的准确率达到79%仅指给出正确根因判断的比例还没算操作成功率而DeepAgents协同方案的第一轮准确率是93%第二轮的完成率是88%。虽然不是多惊艳的数字但明显已经不是一个量级。6. 工程落地里的隐藏雷区兼容性问题、上下文隔离、MCP资源与流式输出上面讲的是理想链路实际工程里还有一堆不亲自动手就发现不了的问题我把踩过的几个典型坑列出来。6.1 MCP服务端的兼容性版本差异比想象的更“埋雷”MCP Server生态现在看起来很热闹但兼容性坑很多。我们内部同时接了十来个MCP Server有的基于官方SDK实现有的是社区用不同语言手写的结果在调用时偶尔出现返回的result结构不统一、字段名风格不一致有的返回snake_case有的返回camelCase、错误信息有的带error.code有的只有error.message。这些问题到了Agent侧就会变成一堆解析报错且日志很难一眼定位。我的经验是不要假定所有MCP Server都能完美互操作。在接入之前两件事必须做——先写一个最简单的本地客户端逐个冒烟测试把每个Server的返回结构记录下来建一张兼容性矩阵其次在Agent的MCP客户端封装层做一层“归一化”处理把不同Server的返回数据统一转换成内部标准结构之后再丢给大模型。没有这层归一化模型在理解工具返回时会频繁出现幻觉。6.2 DeepAgents的上下文隔离不能只靠提示词“请忽略无关信息”刚才说角色拆分时我提到上下文隔离很重要它的具体实现不是靠提示词去约束而是在任务分发时直接做字段过滤。比如Planner收到用户完整消息后只把“退款单号”“订单号”这两个字段传给退款Agent传参时自动丢弃其他无关自然语言内容。这样做的好处有两个一是减少大模型输入中的噪声工具选择准确率明显上升二是节省token在多Agent并发场景下这个成本节约非常可观。坏处是需要花一些工程量去设计每个Agent的输入Schema并且要保证Schema和AgentCard中描述的能力是对齐的。我们在一次迭代里尝试过“让Agent自己决定要看哪些字段”的做法用户全量消息原样转发给所有Agent结果工具误选率上涨了差不多50%。从那之后我们定了个原则Agent的输入就是结构化、最小集信息由编排层统一过滤绝不把选择权下放给模型。6.3 MCP Resource的上下文注入用对地方效率翻倍前面提到MCP有Resource概念我再补充一个实战场景。我们的知识库Agent过去走的是“把相关文档全文塞进prompt”的方式token消耗极大一篇文章动不动三四千token而且文档一长就会干扰模型对用户问题的理解。后来改造为先通过向量检索把命中段落截断为小块再放到MCP Resource里Agent只读取段落级别的资源子集。同样一个问答场景输入token消耗下降了大概65%回答质量反而提升。这个经验对做知识库型Agent的朋友有直接参考价值。另外关于流式输出如果你是做Agent类产品一定会遇到类似需求“MCP Server返回结果很大Agent想边接收边处理不要等全部返回再加载进上下文”。我们在实现过程中发现MCP客户端对超大响应体比如一次性返回几十万token的检索结果的性能表现并不理想而且大模型在处理这种超长输入时本身就容易“迷失重点”。我们的做法是在MCP Server端增加切片和摘要能力让Server在返回数据时先做一轮内置的“重点提取”只返回最相关的小块数据而不是全量返回。如果确实需要全文则通过两步走先返回文档索引和定位信息由Agent决定是否进一步获取。这个二级拉取模式在实际体验上比一股脑返回全文好得多。6.4 Skills的价值与局限可以复用不能“神化”标题里还有Skills它解决的是另一层问题Agent除了会调工具还得会运用一套“行为模式”或“工作流经验”。比如写代码的Agent应当遵循“先写测试再写实现-再跑测试-最后重构”的开发流程做数据分析的Agent应当遵循“先清洗数据-再做描述性统计-再建模-最后画图”的分析流程。这些高一层的方法论如果用系统提示词硬写一长就不稳定如果让模型自由发挥往往会出现“能力不够就拿模板硬凑”的情况。Skills本质上是把这套方法论做成了可复用、可版本化、可分享的配置包。你可以把某个优秀Agent的工作流沉淀成一个Skill包团队里其他Agent只要引用了这个Skill就自动获得该领域的任务执行模板、经验约束和质量检查点。我做了大概几十个Skill包的实验后得出一个比较务实的判断Skill在单一领域的任务稳定性提升是很明显的尤其是开发、数据清洗、文档结构化这些有明确规范的场景但Skill不适合用于跨领域通用推理的加持它更像医生的“临床指南”而不是“医学原理教材”。你不可能靠挂一个“营销专家Skill”就真的拥有营销专家的推理能力但如果只是规范你的产出格式与检查流程它确实非常有用。另外Skills还有一个工程层面的价值它让“Agent能力沉淀不依赖于模型版本”。哪怕底层更换了更强的模型只要Skill包不变Agent行为模式依然保持稳定这为我们做系统升级提供了很好的降风险缓冲。7. 我们最终采用的架构全景与分工原则到这里把全部组件都串起来一个我认为在目前阶段值得推荐的架构全景就自然浮现了。拆开看它大概是四层层级组件职责组织与编排层DeepAgents意图拆解、任务规划、子任务路由、结果汇总统筹智能体间协作层A2AAgent发现、任务状态同步、结构化消息传递、跨Agent协作工具与数据接入层MCP统一封装外部工具/数据源标准化能力接入能力与经验层Skills沉淀特定领域的方法论、流程模板和质量约束这个架构在实际运行中的分工原则很简洁“谁擅长什么谁干谁需要什么数据谁拿谁完成什么任务谁负责”——一切协作用接口完成一切外部能力用协议对接一切经验沉淀成配置。但我想特别强调一下这个架构并不适合所有项目。如果你的业务只有两三个简单Agent、涉及的工具也只有一两个API引入这套体系绝对是过度设计——DeepAgents的编排开销、A2A的注册发现机制、MCP Server的维护成本每一项都需要人力投入。我自己判断适合上这套架构的最低门槛是有3个以上需要相互协作的Agent角色涉及的工具/数据源超过5个或需要频繁新增工具业务对链路可观测性有要求需要能够追踪每一次Agent协作的过程需要支持多个Agent角色独立迭代、独立发布。如果你的项目满足其中两三条那“从单体到组织”的改造就非常有必要如果都不满足老老实实维护一个单体Agent反而效率更高。8. 兼容与演进新Agent怎么加入、旧Agent怎么改、运行效果怎么量化这个架构上线之后我们总结出几个后续持续运行中要反复处理的问题新增Agent、旧Agent迁移改造、效果量化评估。这三件事处理不好再好的架构也会随着业务变化而腐化。新增Agent的标准流程我们已经模板化定义AgentCapability范围写清楚它负责什么、不负责什么- 编写AgentCard能力描述 - 实现Agent的内部逻辑 - 注册到Registry - 进行A2A连通测试。整个流程如果顺利基本半天之内就能让一个新的Agent接进协作网络。这个效率在单体架构时代是不可想象的。旧Agent迁移改造时最容易翻车的是“责任边界模糊”。比如原本一个处理“售前咨询”的Agent其实是既查商品信息、又管下单推荐、又挑优惠券策略的顺带活——迁移的时候如果不彻底拆开后面新增一个专门的“优惠券Agent”时就会发生两套逻辑抢活。我们的处理方式是改造过程中强制按能力域拆分先拆功能边界再拆代码实现不要为了迁移而迁移。至于效果量化我建议不要只盯着单次任务成功率应该建一套多维度指标至少包含任务成功率、平均协作轮次衡量链路精简度、工具误用率衡量模型路由质量、单次任务Token成本衡量上下文注入效率以及Agent间消息延迟衡量A2A链路健康度。我们上线这套架构后表现最直观的变化就是工具误用率和单次任务Token成本同时显著下降而任务成功率稳步上升这本身就是架构价值的客观证据。当然这套架构的好处不只是性能指标上的提升。它带来的组织性变化更让我感慨以前每次改功能都要动一个巨大的、越来越脆的主Agent现在团队内部分工明确到“谁负责哪个Agent、谁维护哪条MCP链路、谁沉淀哪类Skill”可维护性完全不可同日而语。9. 最后回到工程判断不是组件堆得越多就越高级我个人实际操作下来的体会是很多人在听到DeepAgents、MCP、A2A、Skills这些名词之后会急着在一夜之间全上恨不得把Demo里的所有组件都塞进生产。但实际上这套组合能不能发挥价值取决于你对业务边界的拆解能力、对协议的理解深度、以及最关键的——知道在什么位置该“保持简单”。我不会建议任何人一上来就全量落地。如果只挑一件性价比最高的事我会先把MCP做了——它带来的标准化收益最直观风险也最低然后等Agent数量真正多起来、协作问题成为矛盾核心时再把A2A的注册与路由机制加进来。DeepAgents则取决于你现有任务的复杂度和拆分需求随时可以分层Skills则是在Agent行为“不稳定、不可控”的痛点足够明显时再做沉淀与固化。多智能体系统建设跟盖楼很像打地基的MCP、垒墙体的A2A、做设计图纸的DeepAgents、用来内部装修规范的Skills每个工序有自己的节点和周期超前和滞后都会破坏整个工程的节奏。工程上没有银弹只有理解每一层协议背后的取舍在正确的问题域里用正确的工具少踩几个已知的坑多沉淀一些可复用的经验。这套从单体走向组织的路每一步都走得踏实最终交付的才是一个真正能跑在复杂业务里的多智能体体系。