Agent harness 怎么影响 token 成本？9 种 harness 同题实测差 17 倍，差在四个开关

harness 影响 token 成本的方式是乘法，不是加法。它决定每一轮模型要读多少字（系统提示与工具 定义的体积）、其中多少按 cache 价计（历史怎么重读）、想多深（默认 effort）、几轮才做完一件事 （并行工具调用有没有退化成串行）。四个数相乘，就是同一个模型在不同 harness 里的账单差。

这个差有多大，本周有了公开数字。Runta 发布的 FrontierHarness Eval （2026-09-01）让同一个 Kimi K3 跑 9 种 harness、12 个配置、同一批 30 个任务：通过率挤在 50.0% 到 66.7% 之间，每次通过的成本却从 $1.05 到 $18.34，差 17.5 倍。这个「每次通过的成本」 把失败尝试也算了进去，口径下一节写清。

harness 是什么、Agent 循环的三个上限、token 随步数二次增长，本刊前面三篇写过 （DeepSeek Harness 刷屏那周、 三种失控各需一个独立上限、 常時稼働の請求書はステップ数の二乗で伸びる）。 这篇只算一件事：每一步，harness 让你多付多少。

17 倍是怎么算出来的：9 种 harness、30 个任务、一个模型、失败也计费

按 Runta 的 Introducing FrontierHarness Eval， 评测的骨架是：30 个任务（21 个 Terminal-Bench、9 个 DeepSWE，全是软件工程与终端任务）， 12 个配置 × 30 = 360 格，每格只跑一次，不重试、不 best-of-N，由 verifier 判 pass/fail； 全场 209 格通过、151 格失败。模型全部是 Kimi K3，推理由 Fireworks 提供，9 个 harness 经 同一个网关接入，网关同时讲 OpenAI Responses 与 Anthropic Messages。每格从同一个 golden checkpoint 恢复，正式任务在评测前从未跑过，因为「a debug run leaves the prefix cache warm for hours」。成本方面只有一句「first-turn cache reads are repriced consistently across harnesses」，怎么重算的没写。

12 个配置按每次通过的成本排（数字取自仓库的 results/eval-data.json）：

DSH 是 DeepSeek Harness，跑了 standard / minimal / creator / PTC 四档。

「每次通过的成本」是哪一列，得说清。 站点 JS 里这一列绑定字段 effective_cost_per_pass； 站点标它「Median cost per task」，README 与博客表格标「Median cost per pass」，博客首图横轴写 「Median cost per pass (failures included)」，三个标签同一列。站点「Beyond the numbers」第一条 替它做了注解：「Count failed attempts and the number becomes $3.24 per task」——$3.24 正是 OpenCode 在这一列的值。所以这一列 = 该配置在 30 格上的花费 （含失败格）摊到它通过的格数上。 $18.3368 ÷ $1.0452 = 17.54，README 写 17.5x，HN 帖题写 17x。 站点另一列「Median cost per successful task」（字段 median_cost_per_success_normalized） 只差 4.7 倍，但「normalized」按什么归一未公开，本篇不引。

表里还有一件能直接读出来的事：Codex 平均每题 62 轮，全场最多，每次通过 $3.47； Claude Code 平均 49 轮，$18.34。轮次差不到三成，cache 差了四倍。 轮次乘以每轮单价，等于账单——这张表是这个乘法的现场。

作者划的边界得带上：v1.0 只覆盖软件工程与终端任务；每个 harness 按出厂配置跑，不为 K3 的 隐式缓存做适配；成本差「may reflect the interaction between the harness, model, and gateway rather than the harness alone」，现有数据拆不出三者各自的贡献。 Show HN: FrontierHarness Eval（采集时 38 分、 16 条评论）里的批评也在点上：vidarh 说 Kimi 系模型有工具调用死循环之类的怪癖，围绕 Anthropic 模型设计的 harness 不用处理它们，「无主场优势」站不住；kaishin 说仓库只放结果与任务定义，无法复跑。

所以这组数据能证明的是：同一个模型换 harness，成本差一个数量级，这件事真实存在。 它证明不了哪个 harness 好。下面拆这个数量级从哪四层来。

harness 的四层成本乘数，每一层都在 usage 字段里留了指纹

掘金本周那篇《一文弄懂 Agent Harness 与 Agent Runtime 的区别》 （采集时 216 分）给 harness 列了七项职责——执行循环、提示拼装与上下文管理、工具接口、 消息与状态跟踪、输出解析、错误处理、子代理管理——是从分工角度写的，没有算钱。 下面这一步是我们加的：把七项按「每一轮要付多少」重排，剩下四层。

第一层：系统提示与工具定义，每一轮都重读一遍

FrontierHarness 的博客存档了一段 Claude Code 会话的逐轮读数，多数轮次的 cache read 停在 18.4K token 上下，作者注明这正是系统提示的大小。不管这一轮干什么，这 18.4K 先读一遍。

三个市场本周都在往这一层加东西，加得都有道理。掘金《企业级 AI Coding 的 Harness 工程实战》 （采集时 180 分）给八个 skill 定了三条共同设计：每个 skill「先读 CLAUDE.md，不可跳过」； 末尾挂一张「常见坑速查表」，「这只表是活的——每交付一个需求，review 发现新坑就补进去」； 关键依赖「强制先读 Context7 官方文档再回答」。掘金《我装了 30 多个 Skill，给 AI 安排了 8 个岗位》 （采集时 333 分）讲 30 多个 skill 怎么分岗。Zenn 榜上 kawarimidoll 的 《202608 個人的 claude code 設定》 （采集时 555 likes）里，沙箱工具 cage 的限制说明用 --append-system-prompt 追加进系统提示； ponytail 插件自带一条要求写特定注释的指令，作者又在 CLAUDE.md 里写一条把它打消。

三位作者都没谈 token，下面这句是我们加的：坑表会长，CLAUDE.md 会长，30 个 skill 的名称与 description 在 Claude Code 这类 harness 里会作为可用技能清单进入上下文，两条互相抵消的指令 占两份体积——这些都对，也都按轮计费。这一层的特点是你加什么，它每轮就读什么； 好在它也最容易量：第一次调用的输入 token 数减去你那句话，就是它。kawarimidoll 那篇最后一节 叫「たまに設定を棚卸しする」，理由是「使わない設定が残り続けているとコンテキストを圧迫する」—— 不用的设定留着会压上下文。这是这一层唯一的减法，作者的频率是半年或一个季度一次。

第二层：历史怎么重读——命中与 miss 之间是 40 到 50 倍的单价差

每一轮都要把历史重发一遍，躲不掉；能选的是历史按哪个价计。Anthropic 的 Claude Fable 5.1 价目： base input $10 / MTok，5 分钟 cache write $12.50，1 小时 cache write $20，cache read $0.25， output $50。我方算术：命中与不命中之间 40 倍，命中与写入之间 50 倍。5.1 把 cache read 从上一代的 0.1× base 降到 0.025×，杠杆拉长了四倍。这次降价在账单里占多大份额，本刊同日另一篇 cache read 降价的账单份额算过，不重复。

规则在 What’s new in Claude Fable 5.1 里：最小可缓存长度 512 token；「treat the conversation as append-only」——改动早先轮次里的 任何东西（系统提示、工具数组、注入再删掉的提醒），缓存前缀就断了，5.1 上还会让后面的 thinking block 失效。

FrontierHarness 给了这一层的失效现场。Claude Code 的 cache 命中率按中位格算 67.8%， 按 token 加权 25.0%；其余 11 个配置加权都在 91.6% 到 99.1%。作者对这个 25.0% 自己加了保留： 它主要由最贵那一格（24.6M 输入 token、命中 15.7%）拉低，「doesn’t represent typical Claude Code behavior」——两个口径都得摆出来才读得对。作者贴出的逐轮读数：

call   fresh   cacheRead   total_in   hit%
   1    1174       18432      19606   94.0
   4   19381       18432      37813   48.7
   5       0       38345      38345  100.0   <-- same conversation, full prefix hit
   8   23092       18688      41780   44.7
  13       0       45277      45277  100.0
  25   35474       18944      54418   34.8
  26       0       55514      55514  100.0

多数调用只命中系统提示那 18.4K，增长中的对话按全价计；约五分之一的调用整个前缀 100% 命中。 作者的归因照录：Claude Code 围绕 Anthropic 模型的显式 cache_control 语义设计，K3 暴露的是 行为不同的隐式前缀缓存，「the same caching strategy may not transfer cleanly. This is a property of the complete harness-model configuration, not necessarily a defect in Claude Code」。 本篇对这层意思不加不减。

账单上长这样：最难的一题 python-statemachine-state-data-scoping，Pi 90 轮、命中 98.2%、 $2.50；Claude Code 381 轮、命中 15.7%、24.6M 输入 token、$64.36。26 倍，同一个 verifier 判的同一个 pass。

这一层还有另一个方向的开关。Zenn 上 a_kadowaki 的 Google提唱の「SKILL.state」について （采集时 76 likes）转述了 Google 与 Purdue 的论文 SKILL.state： 不送会话历史，只送一份带类型的结构化 State。200 步的仓储任务，摘要型基线累计 617 万 token， SKILL.state 12 万。数字是 Zenn 作者对论文的转述，本篇没读原文；适用范围作者也写了——定型业务。 把两件事放在一起：让重读变便宜（命中）和减少要重读的东西（状态化、压缩）是两个独立的开关； 两个都关着的 harness，账单随步数的平方走——那条曲线 本刊 8 月 30 日那篇推过。

第三层：默认 effort——Low 能过的任务按 High 计费 4 倍

Fable 5.1 的默认 effort 是 high，迁移清单第三条直接写「Re-tune effort from the default (high)」； Prompting Claude Fable 5.1 说「At medium, results roughly match Claude Fable 5 at lower cost」。默认值是 harness 替你填的—— techsy 写明 Claude Code 里默认 High，claude.ai 与 Cowork 里默认 Medium。

techsy 的 Claude Fable 5.1 Review（2026-09-02） 用三个带单元测试的函数题跑了 Low 与 High：

三题在 Low 下全部通过。前两题两档几乎一样；第三题 High 多想了 1,150 个 reasoning token， 输出变成 4.25 倍，22 秒对 7 秒，账单 4.0 倍——为一组已经过了的测试。effort 税不是常数， 是任务相关的，这才是它难审计的地方：平均看不出，单题才看得见。同一篇转引 r/ClaudeCode 说 High 默认落地后 5 小时窗口 20 分钟烧完，二手信息，只当情绪读数。

5.1 上这一层多了一个开关：per-message effort（beta），同一会话里升降 effort 不破缓存。 代价是你得知道哪一步是硬的——harness 目前不替你判断。

第四层：并行工具调用退化成串行，多出来的每一轮都按全额付

what’s new 里「Changed from Claude Fable 5」第一条，照录：

Parallel tool calling is more variable. Claude Fable 5.1 may issue one tool call per turn where Claude Fable 5 batched several. This shows up in long agent loops where the next independent reads are only implied: custom coding agents, bash-and-editor harnesses, computer use. The extra turns cost tokens, round trips, and wall-clock time but don’t reduce answer quality.

三个独立的文件读取，上一代一轮发完，这一代可能分三轮。为什么这是乘数而不是加法， 这一步是我们加的：多出来的每一轮，第一层要重读、第二层要重发——它把前两层的账单再乘一遍。 答案质量不变，账单变了。

Anthropic 的解法在提示指南里，节名「Batch independent tool calls in agent loops」， 一行加进系统提示的批处理指令。这个开关的位置在 harness 的系统提示里，harness 没加， 你的账单替它加。同一份 what’s new 还列了「Whole-file rewrites for small changes」：改一行也可能 整文件重写，「the rewrite costs more output tokens and time」，按 $50 / MTok 计。 回到最难那道题：Pi 90 轮，Claude Code 381 轮，轮次这一列本身就是第四层的读数。

开关在你手里的证据：同一个 harness 四个预设差 1.4 倍

DSH 四个预设用同一个 harness、同一个模型、同一个运行时，通过率差 6.6 个百分点、成本差 1.4 倍， 作者说这「about the spread between many of the harnesses themselves」。最难那道题上， Creator 超时失败花 $3.88，Minimal 通过花 $10.49，PTC 超时失败花 $12.95——预设改的只是提示与 工具配置。

Exo Harness 最便宜，作者写明「partly because it stops early」：它有 51 步上限，最难题撞上限 失败，$1.46，别人还在花钱；「a harness that fails cheaply is the one you would want to retry」。 代价写在旁边：它的通过率 53.3%，倒数第三。步数上限是开关，两头都有价。

社区已经在往 harness 里装表。掘金《整理了一份 DeepSeek Harness 必备插件清单》 （采集时 441 分）列的十个插件里，dsh-web-ui 带「Token 实时统计」，dsh-cost-meter「实时统计 会话花费和当日预算」并在峰谷切换前提醒，作者一句话：「现在跑 Harness，不看费用等于裸奔」。 kawarimidoll 的 statusline 用电池 emoji 显示上下文占比，是同一件事。预设是开关，不是出厂设置。

审计你的 harness：五个从 usage 字段读出来的读数

每次响应都带 usage。下面用 Anthropic Messages 的字段名；OpenAI 兼容接口对应 prompt_tokens_details.cached_tokens 与 completion_tokens_details.reasoning_tokens。

参照列是谁的数要先说清：前三行来自 Kimi K3 评测，第四行来自 techsy 的 Fable 5.1 实测， 两组不可互换、也不能给你的 harness 排名——K3 暴露隐式前缀缓存，Claude Code 围绕 Anthropic 显式 cache_control 设计（上一节的作者归因），换到 Fable 5.1 命中率可能反过来。参照列只用来 认数量级。

两条注脚。第二行按轮数平均会把 25% 看成 68%——Claude Code 中位格 67.8% 与加权 25.0% 之间那个 2.7 倍就是这么来的。前三项记应用层日志就够，后两项不够：推理占比要同一任务两个 effort 档各跑 一遍，每轮工具调用数要看到响应体的 block 结构。有的 harness 流式输出不带 usage（Kimi Code 就是， 作者从 wire log 的 usage.record 恢复）——读不到 usage 本身就是第六个读数。

多个 harness 共用一批 key 时，按 key 汇总这几项是网关侧的设计方向，pirouter 的现状见 pirouter.ai/docs——设计方向，不是上线承诺。

不比 harness 好坏，先把乘数读出来

17 倍不是某个 harness 的罪名，是这一层的量程——它告诉你开关的行程有多长。作者说三者交互 拆不开，HN 说要 harness × model 矩阵，都对；矩阵出来之前，你自己的 usage 日志就是你那一格。

成本为零的动作：把五个读数打进日志跑一天，挑读数最差的那一层动一个开关。每个开关的代价上面 都写了——盘点设定要判断力，append-only 要纪律，effort 要知道哪一步硬，批处理只要一行。

模型的价目表每家都印在官网上。harness 的价目表没人印，它在你自己的 usage 里，一行一行，等你去读。