HarnessMM 拆解：80% 的 token 省在输入里，不在输出里

HarnessMM 拆解：80% 的 token 省在输入里，不在输出里

它真正的对手不是 Codex，是“每走一步都要把全部历史重读一遍”这个默认设置。

2026 年 10 月 26 日，Yuhua Jiang、Chang Xu、Feifei Gao、Li Zhao 的论文 HarnessMM: Recursive Self-Improvement for Harness Token Efficiency 上线 arXiv（编号 2610.32813），同一天代码仓 YuhuaJiang2002/HarnessMM 建立。三周后它有 172 星、15 fork、529 个文件、Apache-2.0 协议，最后一次推送停在 11 月 10 日。

README 上最抓眼的是一行对比：MBPP-sanitized 的 257 个测试任务上，同一个 DeepSeek Harness、同一个 Qwen3.5-4B actor，每任务 token 从 53.98k 降到 10.61k，省 80.35%，成功率同时从 90.27% 升到 91.83%。

成功率升、成本降八成，这种两全的数字在 agent 领域很少见，所以它值得拆。但拆之前先说清楚最容易被读错的地方：这 80% 的分母是“什么优化都没做的原生 harness”。仓库自己还留了另一个对照臂，叫 cot-only，那一条的账是每任务 15.04k token、93.39% 成功率。换成它当分母，HarnessMM 的节省是 29.46%，成功率还低 1.56 个百分点。

两个口径差了一个量级，而仓库里两个数字都在。这篇文章要做的，就是把这两个数各自的分量算清楚。

我读了 README、docs/VISUAL_COMPARISON.md、REPRODUCE.md，把 reproduction/mbpp_sanitized/aggregate.json 里 3 个臂 × 257 个任务的整数 token 逐项拆开重算，还把这个仓库的两个本地示例真跑了一遍。下面凡是能被这些材料证实的会标明来源，凡是我自己算出来的标“我算的”，凡是我复现不了的部分会写清楚为什么。

本文提纲

  1. 先看数字：三张表，三个口径
  2. 名字里的 MM 是减减
  3. 把聚合文件拆开：省的全在输入侧
  4. 对照组：cot-only 那一行的分量
  5. RSI 在这里是个窄定义
  6. 我把它跑了一遍：示例能跑，benchmark 跑不动
  7. 对比表是怎么选的：四个对手与十方法全表
  8. 该怀疑的地方
  9. 如果要接入，先改哪一处

先看数字：三张表，三个口径

README 给了三组结果，三组用的是不同的模型和宿主，混着看不合适，得分开读。

第一组是 HumanEval 的 98 个任务，actor 都是 Qwen3.5-4B。Codex Harness 那条：成功率 90.82% 不变，每任务 token 从 66.72k 降到 47.02k，省 29.54%。DeepSeek Harness 那条：成功率从 71.43% 升到 85.71%，每任务 token 从 96.28k 降到 11.62k，省 87.93%。后者换算成题数是 70 题到 84 题，同一批 98 题里多对了 14 题，这是我按 98 任务反算的。

第二组是 MBPP-sanitized 的 257 个任务，DeepSeek Harness 加 Qwen3.5-4B：成功率 90.27% 到 91.83%，token 53.98k 到 10.61k，省 80.35%。这一组是全仓库唯一能本地重算的，REPRODUCE.md 自己写明：MBPP 那行可以在本地用聚合文件复算，HumanEval 两行需要外部评测与计量证据。

第三组是 MiniWoB++ 的 96 个任务，Qwen3.5-9B，就是它的视觉扩展 HarnessMM-V：

方法 成功率 Tokens/task (k) 相对 HarnessMM-V 的 token 节省
HarnessMM-V 62.50 5.07 —
HarnessPro 61.46 10.03 49.42%
SoL-Pi 60.42 41.99 87.92%
Codex Harness 59.38 44.77 88.67%
DeepSeek Harness 61.46 20.03 74.69%

三组数字的记账口径是一致的：统计的是“完整测试执行”的输入加输出 token，包含 authorship、control、fallback、上下文压缩，也包含失败执行；离线学习、训练与验证的成本单独列出，不并入这张表。这句话很重要，它说明 80% 是执行期的账，不是总账。项目自己也在 README 里写，执行节省不能自动推导出全口径的自改进节省。

还有一个容易被忽略的规律：省的百分比不是常数，取决于原宿主有多啰嗦。Codex 宿主本来就是 66.72k 一档，省 29.54%；DeepSeek 宿主是 96.28k 一档，省 87.93%。同一个方法、同一批题，节省率差三倍，差别全在原始 harness 的走路姿势上。所以“HarnessMM 能省 80%”这句话，只有配上“从哪个 harness 出发”才成立。

名字里的 MM 是减减

HarnessMM 的 README 第一句就把命名解释清楚了：Harness Minus Minus，像 C++ 里的递减运算符。名字本身就是设计声明：它不是给 harness 加能力，是从 harness 里减东西。

减的是三次往返里最贵的那次。一个典型的 agent 循环是：模型看一眼观测，决定一个动作，工具执行，把结果塞回上下文，模型再看一眼，再决定一个动作。真正的问题在于，每次工具调用之后都要重新把整段历史、工具说明、系统提示塞进去，再让模型重新推理一遍“下一步该干什么”。历史越长，这一步越贵，而且每一步的推理质量还会因为上下文里噪音变多而下降。

HarnessMM 的做法是把决策和执行拆开。慢模型（actor）先写一份可执行决策图（EDG，Executable Decision Graph），把未来若干步的工具调用写成精确动作。之后每次工具结果回来，收据守卫（GDR，Guarded Decision Reuse）检查这个观测是否支持图里存好的动作：支持就放行，不支持就回退。放行的动作由认证回调替换（CCS，Certified Callback Substitution）通过原生工具接口执行，同时记下它替掉了哪一次推理回调。图走完或者观测对不上，控制权还给慢模型。

这里有两个设计点值得单独拎出来。

第一个是“收据”而非“计划”。存下来的动作不是无条件执行的，它必须被当前的观测支持。这让决策复用有了一个安全阀：环境变了，复用自动失效，退化成原来的慢路径，而不是错着往下跑。

第二个是“证书”。每次替换都留下一条记录，包含原生工具的真实回执和被绕过的回调标识。我在本地跑示例时拿到的输出就是这样：三条 substitution 证书，加上一次图耗尽后回落到慢模型。对 harness 作者来说，这意味着省下来的 token 是可审计的，不是一笔糊涂账。

顺带说一句仓库的兼容处理：包名从 phiagent 迁到 harnessmm，但 CHISEL、SAR、Jev、<CHISEL_PLAN> 这些内部实现名保留原样，老 import 通过桥接层继续可用。这是一个研究仓库从个人工作区抽出来时的典型妥协：对外改名，对内不改，因为改内部协议名会牵动几百个实验脚本。

把聚合文件拆开：省的全在输入侧

README 只给每任务均值，聚合文件里有整数。三个臂 × 257 个任务，我把它们列成一张表：

臂 输入 token 输出 token 合计 成功率 provider 调用次数
native 12,953,280 920,816 13,874,096 90.27%（232/257） 1,633
cot-only 2,879,732 985,996 3,865,728 93.39%（240/257） 1,690
HarnessMM（chisel） 1,757,389 969,349 2,726,738 91.83%（236/257） 1,088

先看加总是否自洽：三个臂的输入加输出都精确等于合计，三组成功率反算回整数题数也全对（232/257、240/257、236/257）。这部分是能验的。

再看结构，结论很直接：省的全在输入侧，而且是压倒性的。native 的输入占自身 token 的 93.4%，chisel 的输入只占 64.4%。绝对量的对比更刺眼：输入侧从 1295.3 万降到 175.7 万，砍掉 1119.6 万；输出侧从 92.1 万涨到 96.9 万，多花了 4.85 万。合计省的 1114.7 万，几乎全部来自输入。

折算到单任务：输入从 50.4k 降到 6.8k，降 86.4%；输出从 3.58k 涨到 3.77k，涨 5.3%。

这条曲线说明了一件事：模型并没有少写代码，它甚至多写了一点。它少的是“把仓库、历史、工具说明反复塞进上下文”这件事。这和很多“压缩提示词”的思路方向相反：压缩是让同样的上下文变短，决策复用是让上下文根本不需要再送一遍。

还有一组我算出来的数字，比 token 更能说明机制：provider 调用次数从每任务 6.35 次降到 4.23 次。也就是说，省下来的不只是每次调用更短的输入，还有三分之一的往返本身消失了。往返少了，错误累积的机会也少，这大概能解释为什么它的成功率比 native 高，而不是用“省成本必然掉质量”的老框架去看。

输出为什么反而多了 5.3%？我猜有一部分是决策图的作者成本：把未来几步动作提前写清楚，需要额外输出。这部分是一次性付费，换后续每步不用再推理。这是我的推断，聚合文件里没有按调用类型拆开的明细，作者也没把 authorship 与执行分开给数。

另外两个细节藏在字段里：chisel 臂有 472 次认证替换，摊到 257 个任务约 1.84 次；同时有 5 次 SDK 失败 episode、3 次原生验证器超时回执，而 native 臂这两项都是 0。这说明快路径不是没有代价，它有自己的失败模式，只是被记进了账里没被拿来讲。

对照组：cot-only 那一行的分量

cot-only 这个臂值得单独一节，因为它是全篇最关键的读表技巧。

它的定义从字段就能读出来：认证替换数为 0，调用次数比 native 还多，token 却只有 native 的 28%。它代表的是“不做决策复用，只做思维链与上下文处理”的那条线，也就是最朴素的一档优化。

三个臂摆在一起，净收益就清楚了：相对 native，HarnessMM 省 80.35%、成功率 +1.56 点；相对 cot-only，省 29.46%、成功率 −1.56 点。也就是说，那个漂亮的“又省又准”，是相对“完全不优化”说的；一旦对手也做了基础优化，剩下的优势是省三成，代价是四个题的准确率。

聚合文件里有一组布尔字段，把这件事写得很明白：

  • native_30pct_admission_passed: true
  • native_40pct_gate_passed: true
  • quality_gate_passed: true
  • cot_40pct_gate_passed: false
  • quality_vs_exact_cot_passed: false
  • benefit_claim_eligible: false
  • mechanism_gate_passed: false

读法是这样的：相对原生 harness 省 40% 的那道门过了，质量门也过了；但相对 cot-only 省 40% 的门没过（实际 29.46%），相对 cot-only 的质量门没过，“收益主张可引用”这一项因此为 false，机制门也为 false。

这个仓库把两层验收都写进了 JSON，而 README 传播的是第一层。我不认为这是刻意隐瞒，因为字段就摆在 reproduction/mbpp_sanitized/aggregate.json 里，任何人下载就能看到；更合理的解释是，验收逻辑本来分两层，README 面向读者只挑了最直观的一层。

但要给一句公道话：257 个任务里 4 个题的差距（236 对 240），按二项分布算不上显著，把它记成“没通过”是保守的做法。保守记录、公开字段，这个态度比数字本身更值得抄。

RSI 在这里是个窄定义

标题里的 Recursive Self-Improvement 容易被读成“模型自己训练自己”。这里的 RSI 要窄得多：它改的是 companion prompts、上下文设置和 adapter 规则，用训练反馈去搜，验证集在冻结的候选里做选择，选完在测试前冻结，权重从头到尾不动。

分区的严格程度是这个项目少见的优点：MiniWoB++ 的 32 训练 / 32 验证 / 96 测试按任务族切开，文档写明“测试结果不引导设计”，聚合文件里也有 test_feedback_to_method: false。这意味着你看到的测试分数不是调出来的。

为什么这样设计？因为搜索空间是文本与规则，不是参数。好处是成本低、可复现、每次改动都是配置 diff，能 review 也能回滚；坏处是天花板低，它提升的是外挂的利用率，不是模型的能力。论文里那句“模型权重保持固定”是这个定义的边界，也是它敢把配置冻结后一次性跑测试的原因。

我的判断：把它叫 RSI 有点占语义便宜，因为“自改进”的对象是脚手架而不是智能体本身。但作为工程约束，这个窄定义反而更容易在团队里落地，你不会因为一次自动调参把线上行为改坏，最坏情况是配置回滚。

我把它跑了一遍：示例能跑，benchmark 跑不动

我没有克隆整个仓库，只拉了 7 个文件：README、examples/guarded_reuse.mjs、examples/partition.py、integrations/deepseek_harness/ 下的 sar_v2.mjs 和 cot_jev.mjs、harnessmm/harness/benchmark_partition.py，以及 reproduction/mbpp_sanitized/ 的三份 JSON。

node examples/guarded_reuse.mjs 直接跑通，输出三条替换证书（callback-0、callback-1、callback-2），加上 slow_calls_after_graph_exhaustion: 1。它的 scope 字段自己写着：合成控制器演示，不含 benchmark 分数，也不含实测的 token 节省。

python examples/partition.py 第一次直接失败，报 No module named 'harnessmm'。原因很朴素：跑脚本时进入 sys.path 的是脚本所在目录，不是仓库根目录，所以仓库根的包找不到。加上 PYTHONPATH=. 或者按 Quick start 做一次可编辑安装就正常了，输出训练/验证/测试的划分结果。这是文档里没写清的一处小摩擦，一分钟能解决，但会绊住第一次跑的人。

这两步能验证到三件事：机制确实能跑通、分区逻辑是确定性的、聚合文件的整数是自洽的。验证不到的一件事也很明确：这些数字是不是真跑出来的。benchmark 需要上游 runtime、数据集、模型端点、付费调用记录，README 自己写了参考配置不是可直接启动的任务，数据集与权重另外管理。所以对数字的态度只能是“内部自洽的声称”，不是“我复现过”。

对比表是怎么选的：四个对手与十方法全表

README 的视觉对比挑了四个对手：HarnessPro、SoL-Pi、Codex Harness、DeepSeek Harness，而且这四个都在两轴上输给它，成功率更高、token 更低。这个选取没有错，但完整表在 docs/VISUAL_COMPARISON.md 里，十方法一起列，画风就变了：

方法 成功 / 96 成功率 Tokens/task (k)
SkillOpt 62 64.58 7.97
HarnessMM-V 60 62.50 5.07
HarnessPro 59 61.46 10.03
DeepSeek Harness 59 61.46 20.03
baseline harness 58 60.42 7.36
SoL-Pi 58 60.42 41.99
AutoSaddler 58 60.42 7.87
Prompt Compaction 57 59.38 7.39
Codex Harness 57 59.38 44.77
RHO 56 58.33 9.10

SkillOpt 的 token 是 7.97k，比我按 96 任务折算的 RHO（873,351 / 96 = 9.10k）高一点，但成功率是全表最高的 64.58%。也就是说，在“每任务 7 到 8k”这个更接近的档位里，HarnessMM-V 不是准确率的赢家；它的王牌是 5.07k，十方法里唯一的 5k 档。

96 个任务里一个任务等于 1.04 个百分点，62.50 与 64.58 之间只差两个题。这个量级撑不起“更高成功率”的强结论，能撑起的是“同样的准确率区间的更便宜的一端”。

还有一层条件差异要说明：HarnessPro 那一列不是原厂最佳配置，文档写的是“按 Medium 档配置出来的视觉复现”，跑了八轮优化；SoL-Pi 用官方 Pi v0.85.1 runtime；Codex 保留官方 CLI v0.142.5 加自建视觉适配器。所以这不是四个产品同台竞技，是四个配置在同一条协议下同台，协议本身是公平的（同 96 题、同截图、同工具、15 步上限、180 秒），但“对手是不是它的最强形态”这件事没人能保证。

我的判断是：它真正赢的不是“更会推理”，而是“每次决策的复用率”。四个重 harness 贵的共同原因是每一步都要重新做决策，它便宜的原因是一步能顶好几步。这也是为什么轻方法（SkillOpt、Prompt Compaction、AutoSaddler）跟它咬得这么近：它们也在压上下文，只是压法不同。

该怀疑的地方

第一，80% 的分母。这一点前面讲透了：换成 cot-only 当分母是 29.46%，并且准确率是负的。看到“省 80%”先问一句“跟谁比”，能省掉大半误读。

第二，模型与规模都太窄。MBPP 与 HumanEval 是 Qwen3.5-4B，MiniWoB 是 9B，仓库里看不到 32B、70B 或商用大模型的结果。输入 token 便宜、输出 token 贵，这个替换在不同价位上未必同比例划算，省 token 的绝对金额也会随定价变化。

第三，HumanEval 两行复现不了。仓库自己说得很清楚：只有 MBPP 那一行能用聚合文件在本地重算，另外两行需要外部计量证据。我尊重这个声明，但也意味着 87.93% 这个最漂亮的数字，目前只有作者的记录支撑。

第四，样本量。98、257、96，三个都不大。MiniWoB 那一组的置信区间按 96 题算相当宽，任何以“1 到 2 个题”为单位的优势都别当结论。

第五，对手是配置复现。HarnessPro 是自建的 Medium 档复现，不是官方调好的最佳形态；Codex 与 DeepSeek 也是自适配的视觉接口。这不是不公平，所有方法都受同一条协议约束，但它让“胜出”的解释变成了“在这套协议下胜出”。

第六，成本只算执行期。离线学习的搜索成本按声明是单列的，但仓库没有给出那笔账的具体数字。README 引论文原话说，执行节省不能自动推导出全口径自改进节省。翻译一下：省的是跑测试时的钱，为了省这笔钱先花了多少，表里没有。

第七，对环境的确定性有依赖。收据对不上就回退，这个机制在 UI 频繁变化、网页结构抖动的场景里会频繁回退，收益会比表格里低。这是我的推断，仓库没有给这类场景的数字，因为它的实验环境都是固定版本、固定容器的 benchmark。

如果要接入，先改哪一处

如果你是 harness 作者，这仓库有三件事值得直接抄走。

第一，把“决策”和“执行”分成两段。让慢模型一次写多步，快路径直接派发。哪怕不做完整 EDG，先做“一次决策覆盖两三步”也能省下可观的往返。

第二，每次替换都要有回执和证书。存下来的动作必须有观测支撑，替换必须能追到被绕过的回调。这决定了这套机制能不能上线，因为省钱的路径如果没有审计，出问题时你连哪一步错了都定位不到。

第三，记账粒度到 complete task，包含失败执行。仓库把 sdk 失败、验证器超时都记进臂里，这个习惯会让你的对比表难看一点，但可信度高很多。

有三件事别抄。别把 80% 当承诺，你的基线可能已经在 cot-only 档位；别在没有对照的情况下直接上 RSI 搜索，你会得到一个说不清来源的提升；别在非确定性环境里指望高复用率，回退率会把收益吃掉。

说到底，这篇工作最值钱的不是那 80%，是它把没通过的那道门也一起公开了。一个项目愿意在 JSON 里写 benefit_claim_eligible: false，比在 README 里写十行“state of the art”更让人信得过。

MERMAID_BLOCK_0

参考文档与链接

你算过自己 agent 的 token 账吗？大头在输出还是输入？评论区贴个数字，我们一起看看谁家的上下文最浪费。觉得有用就点个赞。

作者: itech001
来源: 公众号：AI人工智能时代(the-ai-era)
网站: https://www.theaiera.top/
关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top

本文首发于 AI人工智能时代，转载请注明出处。

posted @ 2026-11-13 09:51  iTech  阅读(12)  评论(0)    收藏  举报