---
{
  "series": "Harness工程研究：让AI Agent好用的工程实践",
  "article_index": 6,
  "topic": "多Agent不是银弹：什么时候值得花15倍成本",
  "created": "2026-04-25",
  "deai_score": 92.0,
  "pipeline": "series"
}
---

在面对复杂任务时，增加节点数量通常是直觉上的首选方案。Multi-Agent Orchestration 被理所当然地当成了通向高级智能的必然阶梯。

本系列从 Harness 的基本价值、Context 治理、约束机制、验证体系一路讨论到人机协作模式。这些构成了 Agent 工程的基础设施层。最后一个需要拆解的问题是架构层面的：什么时候该用多个 Agent？

这种设计逻辑在直觉上模拟了人类的组织架构。开发者默认了一个假设：Agent 之间的协作溢价优于单体推理的持续调优。但在实际观察中，这些精巧的架构外壳内部，往往是资源冗余的粗放式消耗。

### 15 倍溢价背后的真相

Anthropic 的研究为这种热潮提供了量化坐标。数据表明，在特定复杂任务中，多 Agent 系统相比单体模式，Token 消耗量通常会激增至 15 倍左右。更深入的观察揭示了一个事实：Token 使用量本身解释了性能方差中 80% 的部分。

所谓的架构带来的智能飞跃，核心源于强制模型进行了多次采样和循环计算。多 Agent 协作在很多场景下是 Multi-shot Sampling 的一种昂贵变体。我们目前的做法只是换了一种方式让计算投入变得极其低效，并没有发明更聪明的协作协议。

由于 LLM 在长序列传递中存在计算上的物理损耗，Agent 间的每次对话都在导致原始意图衰减。当简洁的逻辑流被拆解成碎片化的对话流，系统的信息损耗速度远超智能带来的收益。

在一些引入多 Agent 讨论代码实现的案例中，模型耗费了大量 Token 在无关痛痒的死循环纠缠上。核心业务逻辑因为上下文稀释而变得模糊。相比之下，打磨单体 Prompt 配合扎实的外部验证框架（如《验证比生成更重要》中讨论的 Harness）来捕获错误，反而更有性价比。

### 复杂度溢出

多 Agent 架构的适用边界极其窄。只有任务能被清晰分解为互不依赖、可并行探索的子项时，这种物理并行才具备真正的工程价值。

在处理高依赖、强耦合的任务时，多 Agent 协作往往适得其反。模型此时最需要的是精准的 Context Window 分配和边界清晰的指令约束（参见《Context是稀缺资源》和《约束让Agent更好用》中的讨论）。过多的决策参与者只会制造噪音。

软件工程中有一个经典原则：如果两个模块的改动需要频繁开会协同，说明系统解耦失败。当你觉得必须靠一群 Agent 频繁开会才能解决问题，通常意味着任务拆解本身存在设计缺陷。目前的很多多 Agent 框架掩盖了需求定义的模糊。

随着 Reasoning Models 等原生推理能力的提升，那些为了弥补模型早期逻辑短板而设计的复杂工作流，正在迅速沦为多余的代码。系统复杂度应当与模型能力成反比。模型推理能力越强，包裹在模型外层的工程基座就应该越薄。

现在的多 Agent 热潮中存在一种偷懒倾向。相比于深入优化 Context 质量、建立精细化验证流程这些繁琐的工程活，写一段 Python 脚本让两个 Agent 互相对话要容易得多。但这实际上是把解决问题的责任推给了概率。

### 基于投入产出的决策框架

决策路径应从以下几个维度展开：

衡量任务的可分解性。如果一个任务无法在不损失关键信息的前提下被拆分为独立的子任务，那就停下增加 Agent 数量的手。此时应当把精力集中在增强单体 Agent 的工具链上，通过函数调用（Function Calling）来增强逻辑稳定性。

评估验证的硬性门槛。如果系统产出依然需要人工进行高强度的逐行审查，前端的协作设计就是无效的。正如《人机协作是光谱》中讨论的，验证逻辑应该由确定性的代码或 Harness 承担，概率性的 Agent 检查另一个 Agent 的结果通常不可信。

监控 Token 的边际收益曲线。如果系统的成功率提升微乎其微，但成本翻了数倍，那么这条链路就应该被精简。

系统每增加一个 Agent 节点，其逻辑冲突和幻觉干扰的风险呈指数级上升。当你觉得必须引入多个 Agent 时，先停下来问：当前的失败是因为模型大脑不够用，还是作业现场太混乱？完善一份技术文档，或者增加一个针对 API schema 的检查，其效果往往胜过堆砌五个 Agent 进行无意义的讨论。

### 一个真实的反面案例

我观察过一个用于自动化代码修补（Code Patching）的系统。该团队设计了四个 Agent：分别负责读取需求、写代码、写测试用例和评审。在他们的设想中，这是一个完整的端到端流程。

然而在实际运行中，写测试用例的 Agent 经常理解偏差，给出与代码逻辑相反的断言。随后评审 Agent 开始试图在错误的代码和错误的测试之间寻找中间地带，最终导致生成的 Patch 充满逻辑冗余，甚至引入了内存泄露。

在这个案例中，直接构建一个真实的 CI 环境，通过确定性的报错信息反馈给生成代码的 Agent，效果好得多。验证的价值在于它改变了行为模式，这种改变必须基于硬性的、客观的物理反馈。人类之所以需要评审委员会，是因为人类无法像计算机那样低成本地执行沙盒验证。把这种限制原封不动地搬到 AI 架构设计里，是在用先进的算力模拟落后的流程。

### 两个悬念

虽然我目前对多 Agent 协作持保留态度，但行业内仍有两个问题值得持续关注。

当 LLM 的单位 Token 价格再下降 50 倍甚至 100 倍后，那种具备 15 倍溢价的架构，是否会演变为某种可接受的方案？如果计算资源变得极其廉价，通过暴力采样来换取稳定性提升，在商业上可能成立。但在那一天到来之前，这种投入产出比需要被严格审视。

另一个问题关乎协作的本质。当前的系统仅仅是通过增加采样次数稀释了错误率，并没有在语义层面达成真正的共识。如果我们在底层通信协议上没有突破，这种协作就始终只是概率的叠加。

回到本系列的核心判断：模型能力越强，工程设计就应该越简单。在决定增加节点之前，先把单体 Agent 的 Harness 做扎实。写好项目规范，配好测试沙箱，建好验证闭环。如果这些做完之后问题依然存在，再考虑那种昂贵的多 Agent 协作。大多数情况下，你会发现问题在前面几步就已经解决了。