很多团队评估企业 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 工程要解决的问题。