Anthropic、OpenAI、微软、Google，四家巨头在 AI Agent 架构上难得意见一致：先从单 Agent 开始，只在必要时增加复杂度。

这条建议对吗？对。能执行吗？几乎不能。

“必要时"是个很微妙的词。什么叫必要？系统提示超过 3000 token 算必要吗？工具列表超过 10 个算必要吗？用户投诉增多算必要吗？四大厂商谁都没说。

这篇文章不讨论"多 Agent 好不好”，这个问题太大了，答案永远是"看场景"。我想回答一个更具体的问题：你的单 Agent 什么时候撑不住了？

我在实际的 AI 应用编排中经历过这个纠结。一开始单 Agent 够用，后来工具越加越多、提示词越写越长。直到有一天，调试一个 bug 花了三个小时还没定位到问题出在哪一层，我开始认真考虑拆分。但拆完之后发现，新的问题来了。协调成本、错误传播、token 翻倍，拆了的代价比想象中大得多。

下面是我总结的五个失控信号，准确地说是三个诊断信号、一个成本框架、一个升维视角。如果你的系统命中了三个以上诊断信号，大概率是时候认真评估拆分了。但在评估之前，你需要先理解一件事：拆分也有税。

一、提示词膨胀：你的 Agent 背了太多"规则手册"

这是最容易被忽视的信号，也是最早出现的。

想象一个 AI 客服 Agent。V1 版本有 5 个工具：查订单、查物流、改地址、退货、转人工。系统提示大约 1200 token，其中工具描述 750 token，角色定义 200 token，行为约束 200 token。清清爽爽，各司其职。Agent 表现不错，用户满意度很高。

三个月后，产品经理加了退款处理、投诉升级、优惠推荐、会员积分、情感分析。工具从 5 个变成 10 个。系统提示膨胀到约 3000 token。

工具描述也变详细了，从平均 150 token 涨到 180 token，因为你需要更精确地告诉模型什么场景用什么工具。你还新增了 400 token 的工具间优先级规则：“用户提到退款时，先走退款流程，不要推荐优惠。”

半年后，又加了知识库检索、工单创建、多轮记忆管理、满意度调研、权限验证。15 个工具。系统提示膨胀到 6000 token。

你以为问题只是提示词变长了？不是。

真正的杀手是工具之间的冲突处理规则。5 个工具之间几乎不打架。但 15 个工具之间有 C(15,2)=105 种两两组合。当然不是每对都会冲突，但你也无法预判哪些会，所以你面对的是一个不可穷举的冲突空间。“用户说想退货但又问了优惠，先退货还是先推荐优惠？““用户情绪很差，是先做情感安抚还是直接走投诉升级？““知识库返回的信息和工单系统冲突了，听谁的？”

你写不完所有冲突规则。写不完，Agent 就自己"猜”。猜错的概率随工具数量非线性增长，因为冲突组合是二次方级别的。

这里有一个参考阈值。在我经手的几个项目中，系统提示超过 4000 token、且工具描述加冲突规则占系统提示的 60% 以上时，继续"优化提示词"解决不了根本问题。你需要的不是更精巧的提示词，而是更少的职责。

二、工具打架与上下文挤爆

先说工具打架。

你有一个"查订单"工具和一个"查物流"工具。用户说"我的快递到哪了”。查订单能查到物流号，查物流能查到位置，用哪个？工具描述写得再仔细，当两个工具的适用场景存在较大重叠时，模型就会犹豫。

犹豫的结果不是"随机选一个"那么简单。它可能先选了一个、发现不对、再换另一个，白白消耗了一轮调用。

更常见的情况是：两个工具做了一半相同的事。“查订单"返回了物流号但没返回位置，“查物流"需要物流号作为输入。模型需要自己串联两步，先查订单拿到物流号，再查物流拿到位置。问题是，你的系统提示里有没有告诉它这个串联逻辑？大概率没有。

再说上下文挤爆。

每次调用 Agent，上下文窗口需要装下四样东西：系统提示、工具的接口描述、对话历史、当前任务。前两项是固定开销。如果你的系统提示已经很长，再加上十几个工具的接口描述，还没开始干活，窗口就用掉了一大块。

你可能觉得 128K 窗口足够大。但问题不在总窗口大小，在于有效注意力的分配。模型需要在一堆工具描述和冲突规则中找到跟当前任务相关的那一小块信息，这和"大海捞针"测试面临类似的挑战。窗口越满，捞针越难。

当上下文窗口被"规则"和"工具说明"这类固定开销大量占据时，你的 Agent 够聪明，但它没有足够的空间来思考当前的问题。

三、调试地狱与角色分裂

调试地狱是五个信号里最让人崩溃的。

举个场景。你有三个 Agent 串联：分析 Agent 读取用户请求判断意图，执行 Agent 根据意图调用工具，审核 Agent 检查执行结果。用户反馈：“我让它查上周的销售数据，它给我返回了这周的。”

这个 bug 背后你面临三重困境。

第一重：谁错了？ 分析 Agent 把"上周"理解成"最近一周”？执行 Agent 收到了正确的时间范围但查询 API 时参数填错了？还是审核 Agent 看到了错误的数据但放行了？三个嫌疑人，你没有直接证据。

第二重：日志说不清楚。 单 Agent 系统调试，一份日志从头到尾追就行。三 Agent 系统？三份独立日志，外加 Agent 之间的消息传递日志。分析 Agent 输出了一个 JSON，执行 Agent 解析这个 JSON 时有没有丢信息？这种"接力"环节的问题，你只能看输入和输出，中间的推理过程是黑盒。

第三重：复现成本爆炸。 单 Agent 复现 bug，把同样的输入再跑一遍就行。多 Agent 系统，你需要同时固定三个 Agent 的提示词版本、模型版本、temperature 和上下文状态。LLM 的输出本身有随机性，就算所有参数都一样，三个 Agent 的行为组合可能每次都不同。你复现了十次，可能只有两次能重现这个 bug。

判断阈值：出错后无法在 5 分钟内定位问题出在哪个环节，调试地狱信号亮灯。如果你发现团队在多 Agent 系统上花的调试时间已经超过了开发时间，这本身就是一个强信号。

再说角色分裂。

你让同一个 Agent 做两件事：根据用户需求生成一份方案，然后检查这份方案是否合理。听起来很正常对吧？

但这里有一个认知偏差的 LLM 版本。人类有"确认偏误”，自己写的方案，自己检查时倾向于觉得没问题。LLM 也类似：在同一个上下文中，模型刚生成了方案 A，接着让它"评审方案 A”，它已经"知道"自己为什么这么写。评审视角被生成逻辑锚定了。

就像让球员当裁判。他可能很公正，但视角本身有盲区。

拆成两个独立 Agent 后，情况不一样了。生成 Agent 有完整的用户上下文和工具调用能力。审核 Agent 只拿到生成结果，不知道生成过程，这个"不知道"反而是优势。它问的是"这个方案合理吗"而不是"我写的这个方案合理吗”。问题的措辞不同，模型的行为就不同。

当同一个 Agent 需要同时扮演对立角色，生成和审核、推荐和风控、翻译和校对，角色分裂信号出现。这是五个信号中最清晰的拆分正面信号。

四、协调税：拆了不一定更好

到这里，你可能已经在想"看来我该拆了"。

慢着。拆分有成本，而且这个成本经常被严重低估。我管它叫协调税。

先看一个数学推演。以下仅针对串联架构，且假设各环节错误独立，这已经是最乐观的情况。假设每个 Agent 单独执行时准确率 90%，两个 Agent 串联，总准确率是 0.9 × 0.9 = 81%。三个串联，0.9³ = 72.9%。

三个 90 分的 Agent 串起来，总分 73。从"优秀"直接掉到"勉强及格"。

这还是最乐观的估算。概率乘法假设 Agent 之间的错误是独立的。现实中，Agent A 输出了一个有偏差的中间结果，Agent B 基于这个偏差做决策，偏差被放大。到 Agent C 那里，可能已经面目全非。

开源社区有一组基准测试数据（来自 Swarms 项目的评测，方法论细节有限，仅作参考）也指向类似趋势：在顺序推理类任务中，多 Agent 架构的性能可能下降三到七成，token 消耗翻倍甚至更多，每个协调步骤还会额外增加延迟。更贵，更慢，还更不准。

这组数据还揭示了一个有意思的拐点：在顺序推理类任务中，当单 Agent 准确率超过大约 45% 时，加多 Agent 的收益开始递减。

为什么？低于这个水平时，单 Agent 太弱，多 Agent 的冗余机制（投票、交叉验证、对抗辩论）能显著补偿。高于这个水平后，单 Agent 已经"够用"了，协调开销开始吃掉冗余带来的收益。你花了两倍的 token 和三倍的时间，结果没比一个 Agent 好多少。

对大多数用了 GPT-4o 或 Claude 的 AI 应用来说，单 Agent 在合理任务范围内的准确率远高于这条线。这意味着：你的单 Agent 可能早就过了这个拐点。继续加 Agent 不会让系统更好，只会更贵更慢。

反过来说，如果你的单 Agent 准确率还很低，先别想拆分的事。你的提示词和工具设计大概率有根本性的问题。先把一个 Agent 调好，别急着加人。

说完了成本，反过来看：什么时候拆确实是对的？

并行化任务是最明确的甜蜜区。把一个大任务拆成互不依赖的子任务分别执行，这是分治不是串联，衰减模型不适用。分治的关键是子任务之间真的不需要互相等待。在可并行的场景中，多 Agent 架构往往能带来大幅提升。

安全边界。一个 Agent 不应该同时拥有读数据和写数据的权限。这跟性能无关，是架构问题。

组织边界。不同团队维护不同的 Agent，各自迭代互不阻塞。

五、从代码问题到组织问题

到这里我们聊的都是技术信号和工程成本。但真正让我改变想法的，是另一件事。

如果你认真对照了前面的信号，会发现：真正驱动拆分决策的，往往不是技术因素。

Single-agent or Multi-agent Systems? Why Not Both? 这篇论文系统性地对比了不同能力水平的 LLM 在单 Agent 和多 Agent 架构下的表现差异。结论很值得琢磨：随着 LLM 能力持续提升，多 Agent 系统相对于单 Agent 的优势在缩小。模型变强了，很多原来需要多个 Agent 配合才能完成的任务，现在一个 Agent 就能搞定。

但这不意味着"等模型升级就行了"。

有些拆分需求不靠模型能力解决。你的客服 Agent 不应该有权限删除用户数据，无论它多聪明，这是安全边界。支付团队和推荐团队需要独立迭代，各管各的 Agent，这是组织边界。金融场景需要每一步决策可追溯，单 Agent 的"端到端黑盒"反而更难审计，这是合规需求。

这很像微服务刚火那几年的故事。大家拼命把单体拆成微服务，后来发现一大批团队拆完之后的系统比单体更难维护。为什么？因为拆分的理由是"业界在拆"“架构图好看”，不是"有明确的领域边界和独立的变更节奏"。

Agent 架构正在走同一条路。“多 Agent"听起来很先进，但拆分的判断标准不是"你有几个工具"或"你的提示词有多长”，而是你的问题边界在哪里。一个简单的自检：你的拆分需求能否在不重启整个系统的情况下独立验证？能，就值得拆。不能，大概率是伪需求。

五个信号是体检表，帮你判断"单 Agent 是不是在勉强撑着"。但"该拆成几个、怎么拆、谁负责哪块"，这不是纯技术问题，也不是一篇文章能给你的答案。

我能给的建议很简单：先把一个 Agent 做到极致。如果它真的撑不住了，五个信号会告诉你的。