企业 Agent 成本：真正的大头不在模型，在编排层

很多团队在评估企业 Agent 成本时，第一反应往往紧盯模型价格——哪个模型输入划算、哪个输出便宜、哪个性价比最优。比价固然重要，但论文「The Harness Effect: How Orchestration Design Sets the Token Economics of Enterprise Agentic AI」提出了一个穿透性观点：企业级 Agent 决定一项任务最终消耗多少 Token 的，通常是模型外面的编排层。

论文将编排层称为 Harness。它负责将一次用户请求组织成一系列可执行的步骤，例如：如何拼接上下文、Agent 何时调用子 Agent 等。相对应的，本篇论文的核心实验保持 22 个企业 Agent 任务、6 个模型、评估方式和价格表不变，仅通过替换编排层（Harness）来比较传统生产 Agent loop 与 Agent Harness 的差异。

下面，我们来探讨如何将 Agent 成本从“模型单价问题”拆解为“系统设计问题”。

Agent 的成本构成

通常，Agent 很少只通过一次模型调用就完成任务。一个企业级任务往往要经历多轮 Prompt 交互、工具调用、检索返回、工具输出处理、中间状态更新以及历史记录回放。每次执行模型调用，系统都需要重新组织上下文，这就会产生新的输入 Token 和输出 Token 消耗。

论文将一次 Agent 任务的成本拆解为多轮模型调用的总和。每一轮模型调用中，输入 Token 成本主要来自系统提示词、历史记录、工具 schema、检索内容和用户请求等部分。这意味着，Token 成本不仅受模型单价影响，也受 Harness 的上下文组织方式制约：

• 是完整回放历史记录，还是压缩成 checkpoint；
• 工具 schema 是每轮全部注入，还是按任务需求动态收敛；
• 检索内容是写入大段上下文，还是仅保留关键证据和引用；
• 失败重试是持续消耗调用次数，还是设置重试边界与熔断机制；
• 等待外部事件响应时，是反复调用模型确认状态，还是将任务挂起，等事件返回后再恢复。

这些选择最终都会影响每一轮模型调用的上下文长度和 Token 消耗。

图 1：Token 消耗主要来源，红线代表 naive replay，蓝线代表 harness-managed context，中间的阴影区域为那些被重复消耗、但没有有效转化为任务质量的额外 Token。

上图显示，如果 Agent 每一轮模型调用都完整回放历史记录，输入 Token 会随着执行轮次快速膨胀，整体接近平方级增长。如果由 Harness 管理上下文，对历史记录进行压缩、分层或外置，Token 增长就可以被压到近似线性增长。

小提示：在评估 Agent 成本时，不要只盯着模型单价，更要关注编排层如何组织上下文——它才是 Token 消耗的“总阀门”。

核心实验：只换 Harness，模型不变

这篇论文的实验设计并非单纯比较“哪个模型更便宜”，它还做了一个配对替换实验：相同的 22 个任务，相同的 6 个基础模型，相同的评估方式和价格表，每组条件都运行两遍。第一遍使用一套固定版本的传统生产 Agent loop，作为基线；第二遍换成 Writer Agent Harness。这样一来，实验主要观察的变量就集中在编排层。

本次测试模型包括 Claude Sonnet 4.6、Gemini 3.1、Gemini Flash 3.5、Qwen 3.6、GLM 5.1 和 Palmyra X6，覆盖前沿模型、快模型、开源权重候选模型以及 Writer 自家的企业模型。

图 2 和图 3：整体效率结果

上图是原论文的图 3 和表 2 的数据，作者特别指出不能过度解读模型质量从 0.78 到 0.81 的波动。毕竟样本量只有 22 个任务（n = 22），质量分数的变化更适合作为方向性参考。相比之下，成本、Token 消耗和延迟的下降幅度更加明显，重要的是在不同任务和不同模型上都呈现了一致趋势。

注意这件事：Harness 没有换模型，也没有换任务，却把每个任务的 Token 消耗从 14.2k 降到 8.8k。

Harness 如何省 Token

论文进一步拆解了 Writer Agent Harness 降低 Token 消耗的原因。

Prompt 结构

表面上看，它优化的是 Prompt、上下文和工具调用。但从工程实现来看，它是在优化同一件事：让 Agent loop 里的每一轮模型调用更克制、更可控。

图 4：两层 prompt，将 prompt 明确分成 byte-stable prefix 和 volatile tail

其中最典型的一点，是 Writer Agent Harness 对 Prompt 结构做了拆分。它将 Prompt 拆分为固定前缀和动态后缀。固定前缀中存放工具 schema、固定的系统提示词以及可持久保存的任务记录；动态后缀则存放时间、文件状态、计划、提醒、语音设置等每轮都会变化的信息。

通过这样的设计，就能让前面的固定部分保持 byte-stable，从而更容易命中 prompt cache。论文给出了一个测量例子，7,886 个 prompt token 中，有 7,876 个来自 cache reads，缓存命中比例达到 99.9%。

管理历史记录

除了 Prompt 结构，Writer 对 Harness 设计了管理历史记录的机制。普通 Agent loop 容易将完整历史记录一轮轮地塞进上下文，等到窗口快满时再粗暴截断。这样会导致 Token 反复消耗，关键决策和用户约束也会在截断时丢失。

论文中的 Harness 会使用持久化执行记录和检查点摘要来保存旧状态，同时保留最近几轮消息的原文。这样一来，历史记录就不再只是不断塞进上下文的流水账，而是会被整理成可压缩、可恢复、可继续执行的任务状态。

清理中间结果

对于工具输出、网页内容和文件读取结果，Writer Agent Harness 不会全量写入模型上下文，而是将大块内容放到文件系统或外部状态中，仅在上下文里保留摘要、预览、引用或指针。

此外，子 Agent 也承担了隔离“上下文”的作用。它会独立完成搜索、阅读和整理，最后只将受限长度的结果摘要返回给主 Agent，避免主 Agent 为完整的探索过程继续支付昂贵的上下文成本。

等待与重试机制

很多企业流程需要等待审批、外部系统响应或工具返回。如果 Agent 通过反复调用模型来确认状态，就会产生空转成本。论文中 Harness 会将等待设计成可持久化的暂停状态；同时通过重试边界、熔断机制和循环上限，避免 Agent 在无效路径上持续消耗调用次数。

小提示：如果你的 Agent 任务涉及大量等待或重试，一定要检查是否在空转——Harness 可以通过状态挂起和熔断机制节省大量 Token。

优化收益收敛于模型能力

论文有一个很重要的工程结论：通过优化 Harness 带来的成本下降是普遍存在的，但质量收益却依赖于模型能力。

图 5：不同模型下的成本和延迟变化。所有模型的成本都下降，范围在 33% 到 61% 之间。

论文认为，效率收益主要来自编排层，而不是某个模型自身特性。但质量侧就没这么平均。

图 6：Harness 对不同模型能力得分的影响

在 48 个 capability × model 单元中，有 30 个提升、11 个持平和 7 个回退。7 个回退都出现在 Flash 3.5、Qwen 3.6 和 GLM 5.1 这 3 个较小模型上，并集中在 MCP、Playbooks、Presentations 这几类任务中。

论文用 harness leverage 来描述这种现象：不同模型能利用 Harness 的编排能力并不一样。

图 7：harness leverage

上图进一步给出了一个相关性观察。如果模型的基线能力越强，使用 Harness 后的平均质量增益越高。图中 Palmyra X6 的平均增益是 +0.079，Claude Sonnet 4.6 是 +0.073，而 Qwen 3.6 是 -0.031。

不过，论文指出这个相关性是基于 6 个模型点，样本量本身很小，因此更适合作为提示性结果。

子 Agent 的能力门槛

图 8：Sub-agent delegation 得分

论文单独列出了 Sub-agent delegation 的得分。

子 Agent 是 Writer Agent Harness 组引入的新能力，没有对应的基线组。它要求模型能够生成一个或多个有明确范围的子 Agent，并将子任务结果合并回来。

从结果看，Palmyra X6 和 Sonnet 4.6 的可靠性最高，分别为 0.86 和 0.85；Gemini 3.1 为 0.70；Flash 3.5、Qwen 3.6 和 GLM 5.1 的得分则更低。

论文在讨论部分提到，Harness 的能力需要根据模型能力做分层处理。对于能力较弱的模型，可以缩小工具目录、限制委派范围，或者关闭子 Agent 这类复杂的编排能力。这一点与前面的 harness leverage 观察一致：用 Harness 能降低成本，但复杂编排能否转化为质量收益，取决于模型本身的能力。

从单次任务到企业总账

论文还提醒，Agent 上线后评估不能只看质量分数，也要看完整跑一次任务消耗了多少 Token。

论文建议将 CPM（Completions per Million Tokens，每百万 Token 能完成的任务量）纳入发布门禁。实验中，CPM 指标从 54.9 提升到 92.0，说明同样消耗一百万 Token，Harness 版本能完成更多任务。

这也进一步要求企业建立任务级 Token 账本，记录每个任务的总 Token、输入/输出比例、prompt cache 命中率、工具 schema 大小、检索内容长度、历史压缩效果、失败重试消耗，以及子 Agent 的 Token 是否被单独隔离。

由于 Harness 决定了上下文如何组织、工具如何暴露、失败如何重试，因此，论文强调这类 per-task token accounting 应该放在 Harness 层。

图 9：大规模部署下的 Harness 节省效果

论文做了一个测算：如果一个组织每月运行 100 万个 Agent 任务，baseline 按每任务 0.21 美元计算，每月成本约 21 万美元；Harness 按每任务 0.12 美元计算，每月约 12 万美元。这个差额约每月 9 万美元，一年约 108 万美元。

常见问题：
问：为什么模型相同，成本差异却很大？
答：因为编排层（Harness）决定了每轮调用中上下文如何组织。完整的回放、无效的重试、全量工具注入都会大幅增加 Token 消耗，而 Harness 可以通过缓存、压缩、动态收敛等方式大幅降低消耗。
问：Harness 优化会影响任务质量吗？
答：成本下降是普遍且一致的（33%~61%），但质量收益取决于模型本身能力。较强模型（如 Palmyra X6、Claude Sonnet 4.6）利用 Harness 后质量有提升，而较弱模型可能持平甚至小幅回退。因此需要根据模型能力对 Harness 进行分层配置。

小结

这篇论文主要关注编排层如何组织一次任务。

模型价格决定每个 Token 的单价，Harness 决定一次任务会消耗多少 Token。上下文怎么拼、工具怎么暴露、历史怎么压缩、失败怎么重试，都会影响最终成本。

因此，企业 Agent 的优化不只是在模型之间做选择，也要回到 Agent loop 本身，检查哪些 Token 花得必要，哪些 Token 来自重复回放和无效重试。这正是 Harness 工程要解决的问题。