1. 单体Agent撞到天花板为什么要把一个超级个体拆成一个组织当单个Agent处理的任务从帮我写一段Python脚本升级为帮我从需求分析到部署上线跑完整个业务流程时问题就出现了。上下文窗口迟早会被塞满工具调用列表越来越长模型每次推理光是在选哪个工具这件事上就要消耗大量token。我见过最多的场景是一个RAG Agent同时挂了十几个工具用户问一句今天天气怎么样Agent还要在一堆工具里翻半天才能找到合适的那一个。这个领域的发展速度远超多数人的预期。DeepAgents这类框架的兴起MCP协议逐渐成为工具接入的事实标准A2A协议开始解决Agent之间的通信问题Skills机制让经验可以被显式沉淀和复用——这几个技术方向凑在一起本质上是在回答同一个问题当Agent从玩具走向生产力工具时系统架构应该长什么样。这篇文章就是想把这套从单体到组织的工程逻辑拆开讲清楚适合正在做Agent应用落地、或者准备把原型升级成生产系统的团队参考。1.1 上下文窗口和工具调用的双重瓶颈这里有个反直觉的现象模型能力越强单体Agent越容易失控。因为大模型的参数规模上去了它能并行处理的信息更多了但单体Agent把思考状态和工具会话状态全部堆在一个上下文里任何一次错误调用都可能污染后续所有判断。上下文窗口从128K扩展到1M听起来变大了可实际生产中塞进去的内容增长得更快——系统提示词、历史消息、工具返回结果、中间推理……很快就把窗口撑满。工具调用层面更麻烦。工具多了之后工具间的依赖关系、参数歧义、调用顺序约束全部要由同一个Agent的决策能力兜底。一个工具返回的结果格式稍微变了Agent可能就需要额外的纠正提示才能恢复状态。这种情况下单体Agent的可靠性完全取决于模型的临场发挥而不是系统设计。我见过一个团队把三十个工具塞进一个Agent结果模型在工具选择上的错误率直接让整个流程没法用。1.2 单体复杂度增长带来的维护噩梦更实际的痛点是维护。单体Agent的Prompt和工具配置越写越长任何一行工具描述改动都可能引起行为偏移。测试一个单体Agent很难写边际用例新增一个工具你无法确定它会不会影响既有工具的命中率。我实际改过一条工具描述里的标点符号结果一套流程的准确率掉了3%这种不可解释的全局耦合让迭代成本随功能数量指数上升。而真实业务天然是多领域的。一个电商客服Agent的任务列表里有订单查询、退换货、物流追踪、优惠券计算还有售后安抚话术——这些任务的知识领域完全不同把它们压进一个Agent里要么某个领域表现很差要么为了平衡所有领域把系统Prompt撑爆。这就是我常说的超级个体悖论看起来什么都能干实际上什么都差点意思。1.3 组织的核心价值不仅是拆分更是专业化把单体拆成组织不是简单地把一个Agent换成多个Agent。组织逻辑讲究的是每个Agent有自己的专长、自己的上下文边界、自己的工具集相互之间通过标准协议协作。就像一家公司不会让会计去写代码也不会让程序员去做账——专业分工带来的是每个环节都能做深、做稳。当然组织化的代价也很现实通信成本变高、调度变复杂、出错链路变长。所以后面四件套的引入本质上就是用工程手段把这些代价控制在一个可接受的范围内。如果只是盲目拆分不做工程配套多Agent系统会比单体Agent更难维护这点后面会展开说。2. 四件套的分工逻辑DeepAgents、MCP、A2A、Skills各管哪一段2.1 一张组织结构图看懂四者的关系拿公司做类比可能最好理解。DeepAgents更像公司治理结构——它定义了组织里有哪些岗位Agent角色、谁向谁汇报层级关系、任务怎么派发调度策略。MCP是员工的手脚让Agent可以实际去操作数据库、调用API、读写文件。A2A是员工之间的沟通协议定义了怎么说话、怎么交接、怎么确认任务完成。Skills则是岗位经验手册——把某个角色做过的成功流程沉淀下来下次遇到同类任务直接套用。我把这四个东西理解成垂直的四层而不是平行的四个工具治理层DeepAgents负责Agent的编排、调度、状态管理、任务分解执行层MCP负责让Agent连接真实世界的工具和数据通信层A2A负责Agent之间的发现、请求、响应、任务交接知识层Skills负责把可复用的经验固化成标准化资产真正跑起来的时候用户请求先到DeepAgents的编排层编排层拆出子任务分发给下游Agent下游Agent通过A2A收到任务后用自己注册的MCP工具执行期间可能调用Skills里的经验模板完成后通过A2A回传结果编排层汇总并交付。这个链路听上去复杂但每一层的职责都很清晰出了问题也好定位。2.2 为什么四件套缺一不可我见过只接MCP不搞A2A的方案。结果就是每个Agent确实有手有脚了但多个Agent之间各干各的没有标准化的通信机制最后只能靠编排层硬编码协作关系代码写死人。反过来只搞A2A不接MCPAgent之间能说话了但手上没工具聊得再热闹也干不了活等于空谈。Skills是容易被忽视的一块——如果每次Agent执行任务都要从零推理一遍流程效率低不说质量还不稳定Skills把成功率固化下来才让组织真正越跑越稳。所以这个组合的意义在于DeepAgents给了骨架MCP给了手脚A2A给了神经系统Skills给了经验库。缺一个组织都不完整。我甚至觉得这四者的组合本身就是一种元架构——它不是针对某个具体业务设计的而是给所有多Agent系统提供了一套通用的组织模板。2.3 这套架构解决了单体时代哪些具体问题多Agent架构不是秀肌肉每个组件的引入都应该对应一个具体的痛点。DeepAgents解决的是任务复杂度和上下文容量矛盾MCP解决的是工具接入标准化和复用性A2A解决的是多个Agent之间的协作没有通用契约Skills解决的是经验无法沉淀、每次都要重新推理。我在技术选型时有个习惯每个架构组件都必须能回答它替代了什么、解决了什么、不引入会怎样三个问题。四件套在这三个问题上都给得出明确答案这才值得引入。3. MCP实操让Agent真正长出手脚的工具接入层3.1 MCP的Client-Server模型和一次完整调用MCP全称Model Context Protocol它的设计思路是非常工程化的。MCP把工具、数据源、能力封装成ServerAgent侧通过MCP Client去连接这些Server。连接过程不是走传统的HTTP REST接口而是有一套标准化的协议握手、能力探测、工具发现流程。一次完整的调用大致是这样Agent启动时通过MCP Client发送initialize请求和MCP Server建立会话Server返回自己的能力列表包括暴露了哪些tools、resources、promptsAgent在推理时决定需要调用某个工具构造tools/call请求Server执行真实操作查库、调API、读写文件返回结构化结果Agent把结果合并到上下文继续推理这个流程的好处是工具层和推理层彻底解耦了。Agent不需要关心每个工具内部怎么实现的只要知道这个工具有什么能力、输入输出什么格式。对于平台方来说接入一个新工具就是开发一个MCP Server注册后所有Agent都能用。我打过一个比方MCP之于Agent相当于USB-C之于外设——接口统一了插上就能用不用为每个设备定制专属连接线。3.2 我在接入MCP时踩过的坑先说一个最常见的坑MCP Server的鉴权和凭据管理。很多新手把API Key直接写进MCP Server的配置文件里结果Agent在处理并发的请求时凭据混乱导致限流。我自己后来是把MCP Server做成一个独立服务放在内网通过环境变量注入凭据再用e2e的测试框架做联调才稳定下来。凭据管理听起来不性感但在多Agent场景下每个Agent可能连着好几个MCP Server凭据隔离做不好迟早出事。第二个坑是工具返回数据的体积控制。MCP Server返回一个20MB的JSON给AgentAgent直接就把上下文撑爆了。后来我们在Server侧加了结果裁剪逻辑大文件只返回摘要和分页指针Agent需要细节时再二次请求。这个优化让长任务的稳定性和速度都提升明显。核心思路是MCP Server应该尽量做瘦响应而不是把家底全端给Agent。第三个坑是MCP的工具描述质量。同样一个数据库查询工具描述写得模糊和写得精确Agent选择的准确度差很远。我自己的经验是每个工具描述除了做什么还要写清楚适用场景、输入要求的边界、输出格式的约定、可能失败的情况。这相当于给工具写文档文档写得越细模型调用越准。很多团队重功能实现、轻文档撰写结果Agent在工具选择上频繁出错这其实是描述质量的问题不是模型能力的问题。3.3 MCP Server的设计模式与组织规范当MCP Server数量超过十个以后就需要注意设计规范了。我建议按三个一来管理一个工具一个Server一个Server一个职责域一个职责域一套命名规范。不要把相关工具都塞进一个Server里那样会让Server变成一个大杂烩Agent调用时反而困惑。另外MCP Server的上线流程要标准化必须有沙箱环境测试、必须有超时和重试机制、必须有可用性监控。Agent调用工具失败时Server能返回什么样的错误信息这直接影响Agent的恢复策略。我见过太多MCP Server只返回error两个字Agent根本不知道是参数错了还是服务不可用更谈不上自愈了。4. A2A探秘Agent之间如何说话和协作4.1 A2A的核心机制Agent Card与Task生命周期A2AAgent-to-Agent本质上是一套开放的Agent通信协议。它的核心抽象有两个Agent Card和Task。Agent Card相当于每个Agent对外发布的名片里面写清楚了这个Agent的能力、支持的技能、接受的输入类型、输出类型、通信端点。其他Agent想找人干活先去Registry里搜Agent Card看谁的技能匹配然后通过Card里的endpoint发起请求。这个机制有点像微服务架构里的服务注册与发现——只不过服务的消费者和执行者都是Agent。Task是A2A里的工作单元它的生命周期设计得很细submitted、working、input-required、completed、failed等等。为什么要定义这么细因为Agent之间的协作不是一次同步调用而是一个异步过程Agent A给Agent B派了个任务B要跑很久中间还可能需要A补充信息。如果没有Task状态机的管理双方根本没法对齐现在任务到底在哪个阶段。我见过没做状态管理的多Agent协作最后全靠日志在那里人工拼故事效率极其低下。4.2 一个跨Agent协作的请求旅程我用一个实际场景来走一遍用户让项目经理Agent做一个技术方案评审。项目经理Agent收到用户请求后先把任务拆成两件事让架构Agent出方案让测试Agent查兼容性风险。它通过A2A协议查询架构Agent的Agent Card确认能满足需求发起Task请求。架构Agent开始工作它会通过自己的MCP工具去翻代码仓库和设计文档中途发现方案涉及到一个自己不熟悉的前端框架于是通过A2A的input-required状态向项目经理Agent请求支援。项目经理Agent收到通知后把任务转派给前端专家Agent前端专家Agent完成后把结果写回到Task上下文中。最终项目经理Agent汇总所有结果生成评审报告交付用户。这个过程里最关键的工程点在于每个Agent在Task上下文里追加信息而不是产生一条条孤立的对话消息。Task上下文相当于一个共享的工作台所有参与者Agent都能读写这让任务级协作和闲聊式聊天形成了本质区别。如果只是消息飞来飞去没有工作台的概念多Agent协作很快就会变成一场混乱的群聊。4.3 A2A落地时的协议选型细节落地A2A时我建议不要一上来就追求完整实现。先跑通最核心的Discovery和Task两个机制再去考虑流式传输、加密鉴权、断点续传这些增强能力。从实现角度看基于JSON-RPC风格的消息格式是最稳妥的起点因为它天然支持请求-响应模型而且调试工具生态成熟。真正上生产还有一个必须处理的点统一身份认证。Agent之间通过网络互访如果没有任何访问控制就好比公司大门敞开谁都能进——这在企业环境里是不可接受的。我建议在Agent网关层统一接入认证每个Agent拥有独立身份凭证A2A消息必须携带可验证的身份信息接收方校验通过才处理。不然后期Agent数量涨起来随便一个Agent被攻破整个组织就裸奔了。4.4 A2A与MCP的边界感很多人容易混A2A和MCP。一句话区分MCP是Agent向下接工具A2A是Agent横向接同行。MCP让Agent有手脚A2A让Agent有同事。一个Agent工作时既可以通过MCP调用本地工具也可以通过A2A把子任务外包给其他Agent。在设计系统时我们要有意识地判断这个能力应该做成MCP工具还是做成一个新的Agent服务我的基本判断标准是——如果这个能力需要独立的知识体系或独立的上下文管理就值得做成Agent如果只是单纯读写数据或调用API就做成MCP工具。5. Skills把踩过的坑变成可重复调用的肌肉记忆5.1 从Prompt到Skill的演进逻辑最早做Agent的时候我们的做法是把所有经验写进一大段System Prompt遇到什么情况怎么处理、有什么注意事项、用什么格式输出。问题是Prompt是线性文本没法高效检索和复用。后来我们开始把经验拆成一个个Skills——每个Skill封装一个特定的能力包含触发条件、执行步骤、输入输出规范、典型注意事项。Skills和普通Prompt的区别在于它有明确的能力边界和触发机制。一个Skill不是一段建议而是一份可执行的行动手册。Agent在任务规划阶段会去匹配当前场景适合哪个Skill命中后按Skill的步骤执行。这就像新员工入职后经验丰富的师傅给了套路新人先别自己琢磨这套流程是验证过的照着做大概率能成。个词在2025年特别火GitHub上Skills相关项目也很多但真正理解它价值的人其实不多。Skills不是简单的Prompt模板它是可执行经验的最小单元。5.2 Skill的落地形态与生命周期管理实际工程里Skill往往被组织成一个结构化的目录metadata名称、描述、适用场景、版本instructions分步执行指南可能附带few-shot示例tools该Skill运行所需的工具和参数模板constraints边界条件和禁止事项生命周期管理上有个关键点Skill不能只增不改。新Skill进来旧Skill必须定期做回归测试看它在新的模型版本下是否还有效。模型能力在进化过去需要手把手教的步骤新模型可能一句话就能完成反之某些过去有效的约束条件新模型可能不再遵循。Skill失效有三类常见表现命中率下降、执行步骤被跳过、输出格式漂移。我们建立了每周一次的Skill体检机制用一组固定的测试用例跑一遍指标下降就标记review。5.3 如何让Skill成为组织的记忆Skills最有价值的一面是它把隐性的经验显性化了。单人开发时经验在脑子里多人协作时如果经验只存在于某个人的脑子里组织就永远是脆弱的。当Agent组织里有一个新Agent加入它不需要从零开始摸索直接从Skills库里加载相关的经验包就能在第一个任务上达到老Agent八成以上的能力水平。这才是从单体到组织真正想要的沉淀效应。另外我建议每个Skill都记录一个owner即负责维护这条Skill经验的开发者或团队。这样当Skill出问题时能快速找到责任人去更新而不是所有人都可以改、最后没人负责。Skill库和代码库一样需要有人维护它不是一次写好就永远不用管的。5.4 Skills与MCP工具的关系前脚踩油门后脚踩刹车有读者可能会问Skill和MCP工具是不是重复了我的理解是MCP工具是手段Skill是套路。MCP只提供能力Skill定义使用这些能力做成一件事的标准流程。比如MCP Server提供了搜索文档和查代码语义两个工具而一个Code Review Skill则定义了如何组合这两个工具来完成一次高效审查——先查什么、再搜什么、按什么顺序比对、什么情况下要告警。Skill是更高层的组织者MCP是技能树上的叶子节点。两者配合Agent才能既知道怎么做也知道做成什么样才算好。6. 从单体到组织的落地路径拆解、替换、联调三步走6.1 第一步盘点单体能力边界确定拆解粒度落地多智能体不是推翻重来而是一个渐进演进的过程。第一步是把单体Agent的能力盘一遍画出能力地图它现在能处理哪些任务每个任务依赖哪些工具哪些任务之间有数据依赖拆解粒度是这里面最难的决策。拆得太细通信成本压垮效率拆得太粗专业化优势又发挥不出来。我一般遵循两条原则一是领域知识高度重合的任务放一起二是数据依赖强、调用频繁的放一起。比如电商场景里订单查询和物流追踪都依赖订单系统可以合并成一个订单Agent而退换货政策、库存扣减、售后话术则跨了三个领域适合拆成三个Agent。还有一个容易被忽略的点拆解之前先梳理共享数据层。多个Agent要协作必然需要共享某些数据用户上下文、任务状态、业务数据如果数据模型没定好Agent之间的数据语义不一样A2A通信再顺畅也白搭。我建议先画一张数据流图明确哪些数据是全局共享的、哪些是Agent私有的这会影响后续的A2A消息格式和MCP工具设计。6.2 第二步按领域模型配置四件套任务拆解完进入四件套的落地配置。先用DeepAgents定义Agent角色清单、协作关系和调度策略接着为每个Agent开发或接入对应的MCP Server确保它有执行任务的手脚然后按A2A标准为每个Agent生成Agent Card把Task路由和通信端点配好最后把单体时期积累的经验和Prompt整理成第一批Skills入库。这里有个先后顺序的经验先让每个Agent独立跑通自己领域内的任务链路再接入跨Agent协作。如果一开始就全链路联调出了问题根本定位不到是哪个Agent的上下文污染了还是通信协议出了问题。先跑通局部再打通全局调试效率高得多。这跟搭积木一样得先确认每块积木本身结实再考虑怎么拼接。6.3 第三步灰度切换与回滚策略最后一步是灰度切换。多智能体架构最怕的是什么是看起来一切正常实际结果悄悄变了。单体Agent时代错误通常是显式的工具调用失败了、上下文溢出了。多智能体时代错误往往是隐式的A Agent结果正常B Agent结果正常但A到B的信息交接过程中丢了某个关键字段最终结果就偏了。所以灰度方案里必须设计输入重放结果对照机制把单体Agent时期的真实请求录下来在测试环境里重放到新架构中对比新旧输出差异。差异阈值以内放量超过阈值自动回滚。回滚策略同样重要——多智能体架构因为链路深一旦出问题影响面广必须保留快速切回单体Agent的能力我建议灰度期间双架构并行运行至少两周再切流量。god过双架构并行的成本不低但在生产环境里这是最稳妥的做法。别嫌麻烦等出了故障再后悔就晚了。6.4 从单体到组织团队角色也要跟着变最后提醒一个容易被忽视的点工程师团队的技能栈也需要同步演进。单体Agent时代核心岗位是Prompt工程师或Agent调参师关注的是上下文工程和推理策略。多Agent时代新增了网络工程师和协议开发者的角色——要懂MCP Server开发、懂A2A消息路由、懂分布式系统中的可观测性。组织架构变了人的能力结构也要变。我在推进这类项目时会刻意安排团队全员轮训等四件套上线时至少有三个人能独立排查全链路问题而不是只有一个核心工程师看得懂全貌。7. 我的真实体会与工程建议7.1 不要在组织规模上一步到位我吃过一个亏一开始就把Agent拆到十几个觉得组织越大越厉害。结果是调度复杂度爆炸A2A消息满天飞一个任务链路上串了七八个Agent任何一个Agent偶发失败整个任务就卡住。后来我把Agent收敛到五个以内每个Agent的责任范围扩大一点整体稳定性和交付效率反而都上去了。工程上一定要记得先小组织、后大组织先把链路跑稳再慢慢加成员。7.2 可观测性建设要提前投入多智能体系统里最消耗时间的不是开发是排查问题。单体Agent你打一条日志就能追完整条链路多智能体里一个任务的执行轨迹分散在多个Agent、多个MCP调用、多次A2A消息里没有统一的traceId贯穿全程出了问题就只能对着日志唉声叹气。我建议在四件套落地之前先把分布式追踪体系和统一结构化日志建好。每个Agent接收任务时生成traceId往后所有日志都带上这个ID才能保证一条链子从头摸到尾。观察过不少团队他们宁愿花时间调Prompt也不愿意写traceId理由是浪费时间。但等到线上故障时长达到数小时才后悔那才是真正的浪费。7.3 Role的定义是全局最重要的决策最后说说最核心的一件事Agent的Role定义。Role决定了这个Agent的上下文边界、工具集、Skills库和协作权限可以说整个组织的性格都是由Role定义塑造的。Role写得太大Agent会退回全能但平庸的模式Role写得太窄Agent能力发挥不出来还容易频繁请求协作。我现在的习惯是用一两句话描述这个Agent的使命和专长再用结构化字段定义它的输入输出边界、可用工具、不可触碰的领域。定义完后让这个Agent先跑一周纯自己领域内的任务再根据实际表现微调Role——这也是一种组织运营。从单体到组织技术上的门槛并不高真正难的是转换思维方式从一个Agent尽力做所有事变成一套系统让不同Agent各司其职。四件套解决的是工程问题而你到底想要一个什么样的组织那才是需要反复打磨的事情。我自己在这个转变过程中最大的感受是多Agent系统不是搭好就完事的它更像是在经营一支团队——需要设定目标、分配角色、沉淀经验、处理故障还要定期复盘优化。每一步都是工程也都比单纯调一个Agent难得多但一旦跑通它的产出上限和系统稳定性是单体架构很难比的。本内容为AI生成请注意甄别。