多Agent还是单Agent：拆分的3个信号与协作评测
几乎每个做AI应用的创业者都会走到一个岔路口：一个总Agent把事做完，还是拆成“规划、执行、检索、审稿、路由”多个Agent协作？很多团队会下意识觉得，多Agent更高级，架构图更像“系统”，也更像能讲给投资人和客户听的未来。但OXYZ内部讨论时的观点恰恰相反：先把简单方案做深，优先把单Agent、工具调用和显式workflow榨干，只有在这些方案明显不够用时，才引入多步或多Agent系统；甚至如果任务本来就能写成函数或固定流程，先别急着上Agent。
OXYZ资本认为，很多创业团队不是拆得太晚，而是拆得太早。原本一个能闭环的助手，被硬拆成一个“要开会的组织”；角色变多了，系统并没有更聪明，只是更慢、更贵，也更难debug。多Agent只是若干协作模式中的一种，和顺序流水线、并行fan-out/gather、分层任务拆解、generator-critic、manager orchestration、decentralized handoff并列存在。它是工程选择，也是经济选择，但绝不是先进性的勋章。
当然，关键的问题是：什么时候必须拆，什么时候不该拆，以及拆了以后怎么证明这套协作比单Agent更值。
一、先把一个误区说透：多Agent不是默认答案
如果把今天很多Agent产品的失败复盘一下，会发现一个共同问题：团队把“复杂度”误当成“能力”。成功不在于把系统做得最复杂，而在于做对需求匹配的系统；要保持简单、增强透明度，并且只有在简单方案失效时，再增加多步agentic结构。OpenAI的实操指南也给出了几乎一样的建议：先最大化单Agent的能力，因为更多Agent会引入额外复杂度和开销。
OXYZ资本内部讨论相关项目时，常会先问一个很朴素的问题：“这一步到底需要自治，还是只需要编排？” 这是创业团队最容易跳过的一步。Microsoft在最新的Agent Framework概览里给的判断很务实：开放式、对话式、需要自主规划和工具使用的任务，更适合Agent；步骤明确、执行顺序确定、多个函数或子任务需要协调的场景，更适合workflow；如果你本来就能写成函数，那就先别上Agent。很多所谓“多Agent架构问题”，其实在这一步就已经有答案了。
所以，创业者先别急着问“要不要多Agent”，而要先画清楚三层东西：哪些步骤是确定性的，哪些步骤需要模型判断，哪些步骤之间真的存在协作价值。顺序型任务可以做成Sequential，天然并行的任务可以做成Parallel fan-out/gather，复杂目标可以做Hierarchical Decomposition，需要专门质检时可以上Generator-Critic。换句话说，不是所有拆分都要拆成“多个会思考的同事”，很多时候只是把一个模糊的大任务，拆成更清楚的软件结构。
二、什么时候该拆？看这3个信号
信号一：提示词已经从“指令”变成“制度大全”
第一个该拆的信号，不是模型答错，而是你的system prompt已经开始不可维护。当提示词里出现越来越多的条件分支、if-then-else规则，prompt template已经很难继续扩展，而且Agent经常不能稳定遵守复杂指令时，就该考虑把不同逻辑段拆给不同Agent。
创业者对此通常有很强的体感。最早你只是让一个客服Agent回答问题；后来加了退款规则、会员政策、支付异常、工单创建、升级人工、敏感词约束；再后来，不同国家地区、不同客群、不同产品线又各自多了一套例外。到这一步，单Agent表面上还在工作，实际上已经进入“每加一条规则，就打掉另一条规则”的阶段。你看到的不是模型不够强，而是职责边界已经糊掉了。OXYZ资本在看一些相关项目时，最常见的红旗之一，就是团队维护着一份越来越长、越来越像企业制度手册的prompt，却仍然希望一个Agent兼任前台、运营、法务和执行。
这类场景下，拆分的目标不是“让多个Agent一起思考”，而是先把职责切清楚：谁负责意图识别，谁负责查规则，谁负责执行动作，谁负责输出给用户。如果你仍然希望用户只面对一个统一助手，那就用manager pattern，让总Agent保持对用户的单一界面，把专门能力封装成子Agent工具；如果步骤本身很明确，比如“校验—处理—报告”，那更适合用显式workflow，而不是多个自由发挥的对话Agent。
信号二：工具歧义已经超过了模型的路由能力
第二个该拆的信号，不是工具太多，而是工具太像。问题不只在工具数量，而在相似度和重叠度：有的系统能稳定处理15个以上边界清晰的工具，但也有系统在不到10个高度重叠的工具前就开始混乱。更重要的是，建议先做工具清晰化——更直白的名称、更明确的参数、更详细的描述——如果这样仍然不能显著提升表现，再考虑拆成多个Agent。
工具设计和选择极其关键。一个工具说明写得差，Agent就会整条路走歪；而随着MCP和外部工具接入变多，这种问题只会被放大。对于创业团队来说，这一点特别现实——很多产品并不是需要更多“智能”，而是需要更少的路由歧义。比如一个销售支持Agent同时挂着知识库搜索、报价生成、CRM查询、订单追踪、发票核对、合同模板、客户画像七八类工具，只要其中两三个工具目标接近、参数定义不统一，单Agent就会频繁误选、漏选或重复调用。
这时拆分的正确方式，通常不是按“角色感”去拆，而是按工具族、权限边界和任务目标去拆。比如对外仍然保持一个客户成功总Agent，但把订单类、售后类、知识类、财务类动作切成子Agent；或者在无需中央综合的场景下，允许Agent之间做handoff，把用户直接交给对应的订单、维修、销售Agent。OpenAI在官方指南中把这两种模式分得很清楚：前者适合你要统一控制、统一口径、统一综合结果的场景；后者适合不需要一个中央协调者持续主持全局的场景。OXYZ资本观点是，真正健康的拆分，不是让更多Agent“存在”，而是让错误路由和模糊权限减少。
信号三：任务天然可并行，或者已经碰到上下文与容量天花板
第三个信号，才是很多人直觉里最像“多Agent”的那个场景：任务天然可以并行，或者单Agent已经被上下文和容量拖住了。多Agent最擅长的是breadth-first的问题，也就是需要沿多个相对独立方向同时探索的任务。它之所以有效，不只是“分工”这两个字，而是因为不同子Agent拥有各自的上下文窗口，可以并行探索不同线索，再把压缩后的关键结果交给主Agent综合。这类结构特别适合三种事情：高并行度任务、超出单上下文窗口的信息规模、以及需要接很多复杂工具的任务。
这对创业者非常重要。因为你做的如果是企业研究、尽调、采购比价、跨系统排障、多源信息核验、复杂报表生成，这些任务很可能就天然适合拆成并行搜索、并行分析、最后汇总的结构；Google ADK里的Parallel fan-out/gather和Hierarchical Decomposition，本质上就是在服务这类场景。反过来，如果你的任务强依赖同一份上下文、步骤之间耦合极高、每一步都需要上一环节的细节，那么多Agent未必更强。在当前阶段，很多编码类任务并不适合多Agent，因为真正可并行的部分没有想象中多，而且Agent之间实时协作和委托还不够可靠。
更关键的是，创业者必须把这件事看成一张P&L，而不是一张架构图。多Agent的token消耗会明显上升：普通agent交互本身就比chat贵，而多Agent又会比chat高出更多；这类结构只有在任务价值足够高时，才具有经济合理性。面对长上下文和多轮状态变化时，应该更多利用memory、artifact和轻量handoff，尽量避免把所有信息都重新通过总协调者“传话”一遍。OXYZ资本内部认为，多Agent一旦成立，增加的不只是能力边界，更是成本边界、延迟边界和可观测性边界。不能把这三张账同时算清楚，拆分就只是炫技。
三、真正难的不是“拆”，而是“证明拆了更好”
绝大多数团队做到这里会犯一个致命错误：他们只看最终答案。单Agent和多Agent谁回复得更像样，谁主观上“更聪明”，就选谁。多Agent和传统流程不同，它不会每次都走同一条路径，即便起点相同，不同Agent也可能通过不同工具、不同搜索深度、不同协作方式到达同一个正确结果。所以你不能只拿固定脚本去检查它是否走了“唯一正确步骤”，而应该同时评估结果是否对，以及过程是否合理。Google ADK也把Agent评测拆成两部分：一部分是最终响应，另一部分是trajectory，也就是工具使用、策略选择和执行路径。OpenAI则进一步把trace grading做成了官方能力，专门用来在workflow级别识别错误、看清Agent到底是在哪一步做对或做错。
创业团队真正该建立的，不是一个“感觉更聪明”的主观印象，而是一套最小可用的协作评测。至少要有四层。
第一层，是结果评测。
用户任务是否完成，最终环境状态是否正确，输出是否覆盖完整、事实是否可靠、引用或依据是否匹配，这一层看的是“最后有没有把事办成”。对于会改写状态的Agent，比如提交工单、创建订单、改数据库、发消息，不要只看它嘴上说了什么，更要看最终状态有没有真的发生。对长链路、会改变环境的Agent，很多时候应该优先做end-state evaluation，而不是一回合一回合盯过程。
第二层，是路径评测。
这层看“它是怎么办成的”：路由是否正确，是否调用了该调用的工具，handoff次数是否失控，有没有重复搜索、重复总结、无意义往返。OpenAI对trace grading的定义很有代表性：trace就是端到端的决策、工具调用和推理日志；它的价值，不是为了看一张漂亮日志，而是为了知道哪一步是收益，哪一步是浪费。OXYZ资本在看一些相关项目时，最怕创始人给出一张完成率曲线，却打不开任何一条真实trace——这通常意味着团队自己也不知道性能提升是来自架构，还是只是来自更贵的token。
第三层，是协作效率评测。
多Agent不是只比准确率，更要比“协作后是否值得”。这里至少要看四个数：单任务总时延、单任务token成本、平均工具调用次数、以及重复劳动率。Anthropic在Research系统中发现，性能提升与token使用、工具调用数量和模型选择密切相关；他们也通过并行化把复杂研究任务的耗时明显压缩了。这说明一个现实：多Agent真正有价值的，不是“多了几个角色”，而是并行与容量换来了可量化的结果提升。若完成率只提升一点点，却把成本、时延和调试复杂度都翻倍，那它就不是更好的产品，只是更贵的demo。
第四层，是校准与生产监控。
没有任何一种评测层会覆盖所有问题，最有效的做法是把自动化评测、生产监控和定期人工review结合起来；要读transcripts，因为只有读真实轨迹，才知道是Agent真的错了，还是你的grader把一个有效解误判了。对创业公司来说，这几乎是组织能力分水岭：有些团队把评测当成上线前一次性动作，有些团队把评测当成持续运营系统。前者靠感觉迭代，后者靠证据迭代。OXYZ资本认为，到了Agent时代，评测不是QA部门的附属品，而是产品策略本身。
四、给创业者一个够用的决策框架
如果你现在正站在“单Agent还是多Agent”的路口，我建议只问自己三句：
第一，这件事能不能先写成函数或workflow？如果能，就别先用Agent去替代确定性。
第二，如果还是需要Agent，单Agent通过更清晰的prompt、工具命名、参数设计和guardrails，能不能先解决80%的问题？
第三，只有当你能在同一套真实任务评测集上证明：拆分后任务完成率更高，或SLA更优，且成本和时延仍然可接受时，再正式引入多Agent。
单Agent不是落后，多Agent也不是先进。真正成熟的团队，不会因为“像组织”就迷恋拆分，也不会因为“省事”就固守单体。OXYZ资本观点是，今天最稀缺的，不是那个能画出最复杂协作图的创始人，而是那个敢于把复杂度往回收、把结果往前推的人。能一个Agent把事稳稳办成，就别先让四个Agent开会；必须开会时，也别只画组织架构图，先把分工边界、协作日志、绩效评测和成本账一起建出来。那才不是Demo，那才是产品。