同一模型，Harness 能差 17 倍：Agent 的账单不只由模型决定

FrontierHarness 最近发布的一组评测显示：在使用同一个模型的情况下，9 套不同 Agent Harness 的单次任务通过成本最多相差 17 倍。 这不是模型排行榜上的又一次换榜，而是一个更实际、也更容易被低估的问题：Agent 到底花多少钱完成一件事，很大程度上取决于包在模型外面的那层运行时工程。

这里的 Harness 是控制 Agent 如何观察环境、调用工具、管理上下文、处理失败并决定何时结束任务的软件运行时。它通常包括 system prompt、工具定义、agent loop、上下文压缩、重试策略、权限控制、沙箱、缓存和结果验证等组件。

过去讨论 Agent 性能时，大家习惯把注意力集中在模型名称上：Claude、GPT、Gemini、DeepSeek、Kimi，谁的 coding benchmark 分数更高，谁的推理能力更强。但在真实任务里，模型只是发动机，Harness 更像变速箱、导航和刹车系统。同一台发动机，传动效率、换挡逻辑和驾驶方式不同，最终油耗当然不会一样。

17 倍差距，意味着什么

FrontierHarness 的核心结论是：Agent 的单位经济性不能只看模型单价，还必须看“每次成功完成任务需要消耗多少模型调用”。

如果把一次任务的通过成本定义为：

单次通过成本 = 总推理成本 ÷ 成功完成的任务数

那么，一个看起来更便宜的 Harness，未必真的更省钱；一个调用次数更少的 Harness，也未必能稳定完成任务。真正影响结果的，是调用成本、成功率、重试次数和上下文长度的组合。

举个简单例子：

• Harness A 每次尝试花费 0.10 美元，成功率为 80%，单次通过成本约为 0.125 美元；
• Harness B 每次尝试花费 0.03 美元，但成功率只有 15%，单次通过成本约为 0.20 美元；
• Harness C 每次尝试花费 0.50 美元，成功率达到 95%，单次通过成本约为 0.526 美元。

因此，单看 token 消耗，B 似乎最便宜；单看完成任务的成本，A 才更划算；如果任务失败的代价很高，C 也可能有商业价值。

FrontierHarness 把问题进一步固定下来：使用同一个模型、面对同一组任务，再替换不同 Harness，观察每套方案需要多少 token、多少轮工具调用、多少次重试，以及最终有多少任务通过。这样测出来的差距，至少比“不同产品各自宣传自己的成功率”更接近 Harness 本身的贡献。

Harness 究竟在哪些地方烧钱

Agent 成本通常不是被某一次昂贵调用烧掉的，而是被大量重复、无效和缺少边界的调用慢慢累积起来。

1. 工具面过大，模型每轮都在为无关信息付费

工具定义会进入模型上下文。一个拥有几十个工具的 Agent，即使当前任务只需要读取文件和运行测试，也可能把数据库、浏览器、部署、Git、搜索等工具的描述一并发送给模型。

这会带来两个问题：一是输入 token 增加，二是模型更容易选错工具。工具越多，决策空间越大，错误调用和恢复调用也会增加。优秀的 Harness 不应该把所有能力一次性摊在模型面前，而是根据任务阶段动态暴露工具。

2. 上下文不做管理，长任务会变成重复阅读

上下文管理是 Harness 对历史信息进行筛选、压缩、缓存和恢复的机制。

在代码任务中，Agent 可能连续读取几十个文件、执行多轮测试、查看多次日志。如果每一轮都把完整历史重新传入，模型不仅需要为重复 token 付费，还会被大量旧信息干扰。

常见的优化包括：

• 对已经确认的文件内容建立摘要，而不是重复传全文；
• 将工具输出分为关键结论、原始日志和可丢弃噪声；
• 对失败尝试做结构化记录，避免模型再次走同一条死路；
• 在接近上下文上限时主动压缩，而不是等模型被截断；
• 尽可能利用服务商提供的 prompt cache，减少重复前缀的计费。

这类优化不会让模型在 benchmark 上突然多出几十个百分点，但经常会直接改变账单曲线。

3. 没有停止条件，Agent 会把“再试一次”当成默认策略

停止策略是 Harness 判断任务已经完成、无法完成或需要人工介入的规则。

缺少停止策略的 Agent 往往会出现两种极端：任务明明已经完成，却继续检查、重跑和修改；任务已经陷入死循环，却不断生成新的工具调用。

重试次数、相同错误检测、工具调用超时、预算上限和人工审批，都是停止策略的一部分。它们看起来像工程细节，但对成本影响非常直接。一次失败后的自动重试，可能只增加几美分；当 Agent 在长任务里连续重试十几轮，成本就会迅速超过模型本身的报价差异。

4. 验证机制决定了“成功”是不是只停留在口头上

结果验证是 Harness 用测试、约束或外部检查确认模型输出是否真正完成任务的机制。

没有验证器的 coding Agent，很容易在“代码看起来合理”时提前结束；验证器过于严格，又可能导致无意义的反复修复。好的 Harness 会让模型先完成最小修改，再运行针对性的测试，并根据错误类型决定下一步，而不是每次都把完整项目重新扫描一遍。

这也是为什么成功率和成本必须放在一起看。一个 Harness 如果通过率高，但依靠的是大量全量测试和长链路审查，它可能并不适合高频任务；另一个 Harness 如果单次成本很低，却无法稳定确认结果，也很难用于生产环境。

9 套 Harness 的比较，真正比较的是什么

FrontierHarness 的价值不在于宣布某一套 Harness 永远最好，而在于把 Agent 的“脚手架差异”变成可测量变量。

目前公开信息的重点是 9 套 Harness 在同一模型条件下出现最高 17 倍的单次通过成本差距。由于不同 Harness 的具体实现、任务分布、模型版本和计费口径会影响结果，不能简单把这个数字理解成任何场景下都能复制的结论。但它足以说明，模型报价并不是 Agent 成本的完整答案。

| 比较维度 | 只看模型的评测 | 加入 Harness 的评测 | |---|---|---| | 核心对象 | 模型本身 | 模型加运行时系统 | | 常见指标 | 准确率、基准分数、token 单价 | 任务通过率、调用轮数、失败恢复、单次通过成本 | | 成本计算 | 每百万输入/输出 token | 完成一个有效任务需要花多少钱 | | 容易忽略的因素 | 工具选择、上下文重复、重试 | 权限、沙箱、缓存、停止条件和验证器 | | 适用场景 | 研究模型能力 | 评估真实 Agent 产品和生产系统 |

对于开发者来说，最值得关注的不是“第几名”，而是每套 Harness 的成本结构：它是否依赖长 system prompt，是否重复发送工具结果，是否会在失败后盲目重试，是否能复用历史上下文，是否把复杂任务拆成可验证的小步骤。

和 Maka、Meta-Harness 放在一起看

近期关于 Harness 的讨论，正在从“手工调 prompt”转向“系统性优化 Agent 运行时”。

例如，Maka 的公开经验把成本拆成四个环节：thinking 重放、工具结果重复阅读、提示词与工具面冗余，以及缓存命中率不足。其报告声称，在特定 DeepSeek 任务上，通过上下文预算剪枝、精简工具面、思考过程复用和缓存优化，单题成本可以做到 OpenCode 的约八分之一；另一个公开结果称，缓存命中率达到 97.93%，上下文 token 减少 41.7%。这些数字来自项目自身报告，任务与对照环境和 FrontierHarness 并不相同，不能直接合并比较，但方向是一致的：成本下降主要来自运行机制，而不是简单换一个更便宜的模型。

Meta-Harness 则把问题推进了一步。Meta-Harness 是一种让 Agent 根据历史 rollout 结果，自动分析失败原因并改写 Harness 代码的系统。 它不更新模型权重，而是尝试判断究竟是工具选择、提示词、验证步骤还是任务分解导致失败，再修改外部运行逻辑。

这件事的重要性在于，Harness 不再只是开发者手工维护的一组 prompt 和 if-else 规则，而可能成为可被评测、搜索和优化的对象。模型负责提出行动，Harness 负责规定行动空间；模型越强，Harness 的上限越高，但模型能否把能力兑现成结果，越来越依赖后者。

成本差17倍，是否说明最贵的那套最差

17 倍成本差距不等于 17 倍产品质量差距，也不意味着所有任务都应该选择最省 token 的 Harness。

首先，任务类型会改变最优解。代码补全、仓库级修改、浏览器操作、数学证明和数据分析，对工具调用、验证方式和上下文结构的要求完全不同。一套适合短任务的轻量 Harness，遇到需要持续运行数小时的任务，可能因为缺少恢复能力而频繁失败。

其次，企业更关心“有效完成一次任务”的总成本，而不是模型调用账单。一个拥有审计日志、权限隔离、沙箱和人工审批的 Harness，可能每次多花一些 token，却能降低误删文件、错误部署和敏感数据泄露的风险。

再次，评测结果必须看方差。平均单次通过成本很低，如果少数任务会无限重试，生产环境仍然可能出现账单失控。开发者应该同时记录 P50、P90 和 P99 成本，以及最长运行时间、最大调用轮数和失败后的恢复率。

开发者应该怎么测自己的 Harness

最实用的做法不是直接复制某个排行榜，而是建立一套能反映自身业务的“每次通过成本”评测。

建议至少记录以下指标：

1. 任务通过率：任务是否满足预先定义的验收条件，而不是模型是否返回了看似完整的文本。
2. 单次通过成本：总输入、输出和工具相关推理成本，除以成功任务数。
3. 平均工具调用轮数：区分有效调用、重复调用和失败调用。
4. 重试率与恢复率：发生工具错误、测试失败或上下文压缩后，Agent 是否能继续完成任务。
5. 上下文膨胀速度：每完成一个阶段，历史 token 增长多少。
6. 长尾成本：P90、P95 和 P99 任务的成本，避免平均值掩盖极端账单。
7. 人工介入率：多少任务需要用户确认、手工修复或重新启动。

评测时还应该固定模型版本、温度或推理配置、工具实现、任务输入和计费价格，并至少重复多次。否则一次偶然成功，就可能被误判为 Harness 的能力。

更重要的是，测试集不能只有“能否写出正确代码”这种最终结果，还要包含工具失败、网络超时、权限拒绝、上下文过长、测试 flaky 和用户中途修改需求等真实情况。Agent 在理想环境里跑得快，不代表它能在生产环境里跑得稳。

这件事对模型厂商和 Agent 产品意味着什么

当模型价格逐渐透明化后，Harness 会成为 Agent 产品拉开差异的主要战场之一。

对模型厂商来说，单纯降低 token 单价的边际收益会越来越小。更有价值的竞争可能转向缓存接口、推理状态复用、工具调用协议、结构化输出、长上下文管理和面向 Agent 的计费方式。

对 Agent 产品来说，宣传“我们使用某某顶级模型”已经不够。用户真正需要知道的是：完成一次任务平均要调用几轮、失败后如何恢复、是否会重复读取上下文、是否有预算上限，以及不同任务的成功率和成本如何变化。

对开发者来说，未来选型时应该把 Harness 当成一等公民。模型排行榜回答的是“模型会不会做这道题”，FrontierHarness 这类评测进一步追问的是：“模型在什么运行方式下，能以多低的成本稳定把题做完？”

我们的判断是，17 倍不是一个应该被机械复刻的固定数字，而是一个非常强的警报：如果你的 Agent 账单持续上涨，第一反应不一定是换更便宜的模型，也可能是检查 Harness 是否在重复思考、重复传输、重复调用和无限重试。

模型决定能力上限，Harness 决定能力兑现的效率。接下来，Agent 工程的竞争很可能不再只是“谁的模型更聪明”，而是“谁能用更少的调用、更短的上下文和更可靠的验证，把同一个模型变成真正可用的生产系统”。

参考来源

• FrontierHarness Eval 项目讨论入口：用于追踪 FrontierHarness 评测项目及其公开实现；本文关于“9 套 Harness、单次通过成本最高相差 17 倍”的核心信息来自题述项目资料。
• Meta-Harness 相关 GitHub 检索：用于查找 Meta-Harness 的公开代码、复现实验和后续版本信息。
• Hugging Face：用于了解开源模型、评测数据集及 Agent 相关社区资料，本文未将其社区数据与 FrontierHarness 结果直接混用。