过去几天 Hacker News、GitHub Trending 和 Reddit 讨论里，FrontierHarness Eval 这类话题很值得关注：同样是 coding agent，换一个 harness，成本、通过率和失败形态可能完全不同。相关背景可参考 Hacker News、GitHub Trending、arXiv cs.AI recent、Reddit r/MachineLearning。
这不是一个小工具热闹。它说明 AI 编程的竞争正在从“谁接了最强模型”转向“谁能把模型跑成一个稳定经济体”。模型是发动机，harness 是传动、刹车、仪表盘和维修手册。只看发动机马力，很容易误判整车表现。
为什么模型单价不够解释成本
很多团队估算 AI 成本时，会先看每百万 token 单价，然后乘以预估请求量。这对聊天机器人勉强可用，对 agent 基本不够。Agent 的一次用户任务不是一次模型调用，而是一串动态决策：
理解任务 -> 检索上下文 -> 计划 -> 调工具 -> 观察 -> 修改代码 -> 跑测试 -> 修复 -> 总结每一步都可能追加上下文、触发重试、调用更贵模型或打开更多文件。于是总成本由五个变量共同决定：输入上下文长度、输出长度、调用轮数、工具返回体积、失败重试策略。
同一个模型，如果 harness 每轮都塞全量文件、完整日志和长推理过程，成本会迅速膨胀。如果 harness 先做静态索引、只给相关片段、失败后早停，总成本会低很多。
通过率也不是单点指标
评测常给一个 pass rate，但企业真正关心的是 cost per pass，也就是每个成功任务花多少钱。一个 agent 通过率高 3 个百分点，但每次成功成本贵 5 倍，未必值得。
更麻烦的是失败成本。某些 harness 在失败任务上会反复尝试，跑很多轮测试，最后仍然失败。用户只看到“没修好”，账单却已经花掉。另一些 harness 会在证据不足时早停，把失败控制在较低成本。
因此比较 coding agent，至少要看四个指标：
pass_rate
cost_per_pass
cost_per_fail
median_turns_to_finish只有这四个放在一起，才能看出一个系统是聪明、昂贵、鲁莽，还是稳定、节制、可扩展。
Harness 的六个经济杠杆
第一个杠杆是上下文选择。代码仓库很大，模型窗口再长也不该随便塞。好的 harness 会结合 import graph、测试失败栈、最近修改和符号索引选文件。
第二个杠杆是任务拆解。一次让模型修完整需求，往往会产生大 diff 和高失败率。拆成定位、修改、验证、解释四步，虽然调用次数变多，但每次上下文更短，失败更容易控制。
第三个杠杆是工具顺序。先跑便宜的静态检查，再跑昂贵的集成测试；先查符号，再打开文件；先读错误栈，再问模型。这些顺序会直接影响 token 和时间。
第四个杠杆是缓存。系统提示、工具说明、仓库摘要、依赖图和常见错误解释都可以缓存。没有缓存的 agent 每次都重新“认识世界”。
第五个杠杆是重试。重试不是越多越好。好的 harness 会区分语法错误、测试失败、权限错误和任务不明确。只有可恢复错误才重试。
第六个杠杆是验证门控。模型写完代码后必须被测试和规则检查约束。没有验证，agent 可能用漂亮解释掩盖错误；验证过晚，成本又被浪费。
为什么这会改变团队组织
过去 AI 编程工具像个人效率产品，工程师自己装插件、自己试模型。现在长任务 agent 进入团队工作流后，它更像一套生产系统。你需要有人维护评测集、仓库索引、权限策略、模型路由和成本仪表盘。
这会出现一个新角色：harness engineer。这个角色不一定训练模型，但非常懂代码库、CI、测试、权限、提示词、模型 API 和数据分析。它的工作是让模型在真实工程环境中少走弯路。
大团队会把 harness 做成内部平台。小团队也至少需要一套轻量规则：哪些目录 agent 能改，哪些测试必须跑，单任务最大预算是多少，失败几次后必须交还给人。
评测为什么要贴近真实仓库
公开 benchmark 很重要，但它们无法完全代表你的代码库。真实仓库有历史债务、内部框架、奇怪脚本、不稳定测试、权限限制和业务规则。模型在公开题上表现好，不代表能在你的 monorepo 里稳定改代码。
所以团队应该建立内部评测。做法不用复杂：从过去 3 个月 PR 里抽 50 个小任务，保留 issue、测试、期望 diff 和验收条件。每次更换模型或 harness，都在这组任务上跑一遍，记录成本和结果。
更进一步，可以分三类任务：
第一类是定位修复，例如一个单测失败。
第二类是小功能开发，例如增加一个 API 字段。
第三类是维护任务，例如升级依赖、修 lint、补文档。
不同类型的经济性差异很大。一个 harness 可能很会修测试，却不适合做跨模块功能。
对供应商评估的影响
采购 coding agent 时，不要只问“底层模型是什么”。还要问：
它如何选择上下文？是否有仓库索引？工具调用是否可审计？失败时是否会早停？是否支持预算上限？能否导出 trace？能否复现实验？是否支持私有部署或私有数据边界？是否能和现有 CI 权限模型对齐？
这些问题听起来像平台问题，但它们决定账单和安全。一个没有预算控制的 agent，即使模型单价便宜，也可能因为重试和长上下文变得昂贵。
结论
FrontierHarness 这类热议背后的真正主题，是 agent 经济学。模型能力仍然重要，但它不再单独决定产品价值。运行系统决定模型如何看代码、何时调用工具、何时停止、如何验证、如何花钱。
未来一年，AI 编程工具的差距会越来越多出现在 harness 层。开发者和团队要把注意力从“哪个模型最强”扩展到“这个模型被怎样运行”。只有当 pass rate、cost per pass、失败成本和审计能力同时可见，coding agent 才能从新鲜工具变成可靠工程基础设施。