Harness 效应：编排设计如何影响企业级 Agent 的 Token 成本

很多团队评估企业 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 增长就可以被压到近似线性增长。

核心实验：只换 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 在无效路径上持续消耗调用次数。

优化收益收敛于模型能力

论文有一个很重要的工程结论，通过优化 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 万美元。

小结

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

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

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