生产 Agent 的决胜因素：系统架构而非模型选择

2026年6月，Peter Steinberger 报告说他的系统在30天内花费了 $1,305,088.81，在大约100个 Codex 实例上处理了超过603亿个 token，由三人团队运行。这不是基准测试，不是周末实验。这是真实的生产工作负载，足够大到能暴露出任何 agent 可能具有的每一个弱点。

大多数反应直接指向一个明显的问题：什么模型驱动它？从这里开始是合理的。更好的模型能写出更干净的代码，更可靠地遵循指令，在任务出问题时恢复得更好。如果你正在构建编码 agent，选择最强大的可用模型似乎是最重要的决定。

但在130万美元跨越100个 Codex 实例的规模下，有个更有趣的问题。

那就是 harness 是什么？

几乎没人问过这个问题，尽管这个问题解释了系统如何在模型周围保持长期运行的工作顺利进行。这也是什么支撑数百个并行 agent 同时运行、什么持续在数千次工具调用和决策后产生有用结果的原因。这些都不是模型单独的属性。这是生产 harness 的工作，围绕它良好构建的规程现在有了一个名字：agent harness 工程。

前沿模型不断推进自主问题解决中什么是可能的，这种进步是真实的。但生产系统失败的原因往往超出基准测试所能捕捉的范围。一旦 agent 在长期地平线上运行、调用工具、与其他 agent 协调，模型选择就不再是全部决策。它成为更大系统的一部分，从这里开始，一切都假设你在构建生产级别的 agentic 系统，而不是运行一次性的 agent 任务。从这里开始，一切都假设你在构建生产级别的 agentic 系统，而不是运行一次性的 agent 任务。

模型选择不是决定 AI agent 能否交付的因素。围绕它的 harness 才是。

模型选择不是决定 AI agent 能否交付的因素。围绕它的 harness 才是。

今年发表的两项研究衡量的是不同的约束，而不是相互竞争的主张，它们共同表明 harness 质量能够在独立于模型之外移动输出。

今年发表的两项研究衡量的是不同的约束，而不是相互竞争的主张，它们共同表明 harness 质量能够在独立于模型之外移动输出。

在生产中可靠交付的团队趋向于同一个模式：状态存在于模型之外，验证独立于生成进行，上下文在第一个 prompt 之前加载。

在生产中可靠交付的团队趋向于同一个模式：状态存在于模型之外，验证独立于生成进行，上下文在第一个 prompt 之前加载。

真正的问题不是使用哪个模型。而是围绕它的 harness 是否在做足够多的工作。

真正的问题不是使用哪个模型。而是围绕它的 harness 是否在做足够多的工作。

AI agent harness 能做什么是模型做不到的

模型负责推理，但生产 AI agent harness 的工作不同。它是围绕模型的运行时环境，协调将模型的推理转化为可靠执行所需的工作。根据系统，这包括组装指令和上下文、管理工具访问和执行、维护持久状态以及集成诸如模型路由、验证和可观测性等能力。这些职责存在于模型之外，因为它们是系统工程关切，而不是推理任务。

从这个角度看，就能解释为什么系统围绕模型不断增长。团队很少因为框架推荐就添加更好的上下文管理、沙箱、更丰富的可观测性或更强的保障措施。这些能力通常在相同的生产问题反复出现之后才会出现，修复变成永久的而不是工程师要记得手动做的事情。

每个 harness 组件都存在，因为某件事先失败过

这些都不是一次性构建出来的。它的工作方式与将生产系统分层处理应用代码的方式相同：每个组件拥有一项工作，所以某个地方的失败不会影响下游的所有东西。系统 prompt 失败不会破坏沙箱。沙箱突破不会清除你的可观测性日志。这种分离就是全部要点，这就是为什么 harness 设计者无论使用哪个模型或框架，都会不断趋向相似的架构。

以这种方式思考会将对话从特性转移到 harness 级别的失败模式。与其问一个组件做什么，不如问当它不存在时什么会崩溃。这通常是审计 agent 系统的最快方法，因为每个缺失的层都会留下可识别的模式。

一旦你开始寻找它，模式就不那么微妙了。上下文衰变不是 prompt 工程问题；它是上下文管理问题。长期地平线执行失败不会因为模型突然在推理方面变差。它们发生是因为围绕它的 agent 上下文没有被构建来维持长期的自主工作。当 agent 重复调用错误的工具、丧失中间工作或在某些东西崩溃后变得无法调试时，同样的逻辑也适用。这些都是带有 harness 解决方案的 harness 问题。

一旦你通过这个镜头看待 agent，问题就改变了。与其问一个不同的模型是否表现更好，不如开始问系统的哪一部分让失败首先发生。这是更有用的问题，因为每个缺失的组件都会留下特定的、有据可查的失败模式。

模型优先阵营必须解释的证据

如果你假设更好的模型是 agent 表现更好的原因，那么改进模型应该解释你在生产中看到的大部分收益。这是合理的假设。但很难与今年发表的两篇最有趣的文章相符。

METR 衡量上限

先从 Model Evaluation and Threat Research（METR）对编码 agent 的评估开始。Claude Code 在50.7％的时间内优于简单的 Reason-Act（ReAct）循环。这个结果值得你关注，因为它不是在隔离状态下比较原始模型；它评估的是执行相同软件工程任务的完整 agent 系统。同一研究还发现 Codex 表现不如 Triframe，这是 METR 使用的另一个通用框架，只赢得14.5％的时间。如果你构建一个专用的 harness，它却输给一个通用的，那不是模型问题。这是 harness 设计问题，也是你会找到的一些最清晰的证据，表明围绕模型包装的系统可以像帮助一样容易地造成伤害。

METR 的研究也识别了一个约束你最终会遇到的：随着任务变得更长、需要更多持久推理，今天的编码 agent 变得不那么可靠。它们失去了连贯性，从错误中恢复的效果不太好，最终在需要延长执行时间的工作中苦苦挣扎。你构建的每个 agent 最终都会达到实际的时间范围，其中随着任务时长增加，可靠性开始下降。

Anthropic 衡量上限内的质量

Anthropic 的工程事后分析调查了一个不同的变量，值得从上面的上限中分离出来。它询问当生产 harness 改变而底层模型保持不变时会发生什么。

调查始于用户报告 Claude Code 的代码质量明显下降。Anthropic 将回归追溯到模型本身之外的三个改变：降低默认推理努力以减少延迟、一个上下文管理缓存 bug 在空闲会话后重复丢弃先前的推理，以及一个旨在减少冗长的系统 prompt 改变意外地减少了代码质量。在整个调查中，底层模型从未改变。

两个约束，一个生产系统

乍一看，两项研究似乎指向不同的方向。如果你假设改进生产 harness 会导致更好的结果，你可能想知道为什么更长的任务仍然会导致 agent 失败。如果你接受今天的模型有实际的时间范围上限，你可能想知道如何改变 harness 而不改变模型就能明显改进或降低性能。

答案是这些研究在测量不同的东西。METR 查看的是编码 agent 在任务变得更长、更复杂时完成任务的可靠性。Anthropic 查看的是 harness 改变对输出质量的影响，而模型保持不变。它们在回答不同的问题，这就是为什么这些发现是互补的而不是相互矛盾的。

并排比较使得区别更容易看出。

一起阅读，这些发现描述了正交约束。如果你试图找到生产瓶颈实际上在哪里，这就是为什么这很重要：一个衡量长期地平线执行的限制，另一个衡量这些限制内执行的质量。

Anthropic 的事后分析加强了论证，因为在整个调查中底层模型保持不变。所以当你的生产 harness 改变而模型保持不变时，很难争论你的生产性能是由模型能力单独决定的。

要点不是模型对你已经停止重要。更好的模型可以扩展你的 agent 能够尝试的东西。更好的生产 harness 决定这些能力如何可靠地成为你的生产成果。今天的模型仍然遭受上下文丧失、执行漂移和长期运行协调失败，只有你周围的系统能解决这些问题。

在生产中交付的团队实际构建的东西

这些发现指向相同的结论：如果可靠性在模型外崩溃，harness 必须拥有修复。一旦你在生产中交付 agent，你就不能通过单独切换模型来解决可靠性。你将关键职责从模型转移到 harness 中。模型擅长生成下一个行动，但生产团队不依赖它来在长期运行的工作中保持状态、验证自己的输出或在开始进行更改之前重建不熟悉的代码库。这些职责转移到周围的系统中。

状态存在于模型之外

不要问模型来记住一切。独立存储任务状态、中间结果、执行历史和工件。这样，当 agent 停止、重试或移交给另一个 agent 时，工作可以继续。这也使协作变得实用：与其在 agent 之间传递不断增长的上下文窗口，每个都读取当前状态、贡献其工作并将结果写回。

反馈循环独立于生成

将评估完全保持在生成循环之外。生成代码和验证代码是不同的工作。模型生成答案。Harness 检查它是否编译、通过测试、满足项目规则或在决定执行继续、重试还是停止之前引入回归。

上下文管理在第一个 prompt 之前开始

如果你在原型设计，你可能会让 agent 从任务开始，随着进行发现其余的。生产 harness 相反：它在工作开始前组装 agent 需要的上下文。这可能包括项目规则、库结构、依赖信息或先前的任务状态，取决于系统。从正确的上下文开始减少不必要的重新发现，限制上下文衰变，并在长期运行的任务中保持 agent 连贯。在多 agent 系统中，harness 也会自动传播依赖变化，所以每个 agent 都从相同的理解开始。

这最后一点的重要性比听起来要大，AgentField 自己的事后分析向你恰好展示了为什么它不是可选的。由30多个并行 agent 构建的拉取请求通过了给予它的每一项测试，但它仍然在生产中崩溃，因为下游 agent 模拟了上游 agent 从未实际导出的依赖。每个 agent 都做了它的工作。Harness 中没有什么给了他们看到其他 agent 在做什么的可见性。这不是模型失败，更好的推理也不会抓到它。这是 harness 失败，随着你添加更多并行 agent，不实施让他们看到彼此的层，成本会增加而不是减少。

前向部署工程直接解决了这个问题，因为将交付所有权放在靠近工作的地方往往会在交付前而不是交付后表面出这类问题。一个团队对那个模式的方法展示了 harness 所有权在实践中看起来是什么样子，它连接到一个关于过原型速度扩展 AI 开发的更宽泛的点：非正式迭代工作到某个点，然后耐久性需要你能够移交的结构。

第一个 agent 行动之前会发生什么

这个启动序列不是框架特性。这是架构决策。通过在工作开始前初始化状态、规则、上下文和验证，harness 移除了模型否则必须在执行中解决的问题。

通用模式不是更好的模型。这是一个在模型开始前为工作做准备的 harness，你仍然可以关心模型质量而不期望它解决属于 harness 的问题。

读者接下来做什么

开始根据八个生产组件审计你的 harness。缺失或最弱的那个几乎总是你的瓶颈。然后使用带有 Done、In Progress 和 Next 部分的单一状态文件将 agent 状态移到执行循环之外，agent 在会话开始时读取并在结束前更新。在扩展并行 agent 前，通过实现上下文压缩和将大型工具输出转移到文件系统而不是将其留在上下文窗口中来解决上下文衰变。最后，预加载项目规则、库上下文和依赖关系，所以每个会话都从工作知识开始而不是从头重新发现代码库。

如果你在为生产构建 AI agent，更好的问题是围绕模型的 harness 是否在做足够多的工作。