Harness Tax 把 Claude Code 神话打回原形:2026 年 9 月最后一天,模型红利真正退场

9 月 30 日。2026 年倒数第二个交易日。AI 圈没几个人意识到这一天发生了什么,因为这件事不像 Sonnet 5.5 拿 SOTA 那么热闹。它是 HN 上一篇 233 分的论文和一篇 394 分的檄文在同一个 48 小时窗口里同时引爆,把过去 18 个月大家默认相信的「Claude Code = 顶级模型的最佳归宿」这句话,扒了个底朝天。

HarnessTax 论文给了一组硬数字:Claude Fable 5 用 Claude Code 跑 SWE-bench Lite 拿到 97.8% 的成功率,单次平均成本 $1.33。换 Pi harness 跑,96.7% 的成功率,单次平均成本 $0.67。$0.66 的差额,1.1% 的成功率差。你买的不是效果,是一份叫 Claude Code 的品牌税。

WSFF(Why Software Factories Fail)那篇 394 分的檄文,HumanLayer 的创始人 Dex Horvath 直接给整个 harness engineering 浪潮泼了一盆冷水。他的原话是「no amount of harness engineering or loopsmaxxing can solve what is fundamentally a model-training issue」。直译过来:任何 harness 工程都救不了模型训练本身的问题。StrongDM 的 dark factory 悄无声息地凉了一年没见复盘;Faros AI 的报告里 PR review 质量暴跌、incident 暴涨、bugs per developer 暴涨;Mario 在 AI Engineer Europe 上求整个行业慢一点,因为已经有不该出事故的公司,因为 coding agent 的 mishap,出了事故。

我今天写这篇不是来给 harness engineering 泼冷水的。Harness 工程化 100% 是 Agent 时代的方向,Anthropic、Google、阿里、腾讯、智谱、Cloudflare 六路大军杀进同一个赛道,GitHub Trending 持续两个月的 harness 元框架混战就是证据。但我要说的是另一件事:harness 已经从「解决不了的问题」演化成了「绝大多数团队交不起的税」。绝大多数人不知道有 HarnessTax 这回事,绝大多数人默认 harness 必须由模型厂提供,绝大多数人把 harness 当成模型的附属品而不是一等公民。

这三件事同时发生,意味着 Agent 时代进入下一个阶段。harness 选型权开始从模型厂手里流向团队手里。Claude Code 不再是默认答案,Pi 这种 400 行 shell 写出来的极简 harness 反而拿到 Pareto frontier。这意味着做产品的人、做投资的人、做工程决策的人,得重新分配预算了。

一篇 HN 233 分的论文,把 Claude Code 的溢价扒了

先说 HarnessTax 这篇论文到底干了什么。

作者 Melissa Z. Pan、Shuo Yang、Negar Arabzadeh、Wei-Lin Chiang、Ion Stoica、Matei Zaharia。UC Berkeley + Arena Intelligence 的组合,Zaharia 是 Databricks 创始人,这分量在 AI 系统圈不算轻。他们做了一个非常干净的控制变量实验:21 个模型-harness 对,7 个模型 × 3 个 harness,Claude Code / Codex CLI / Pi。所有对都在 SWE-bench Lite 和 Terminal-Bench 2.0 上跑,30 个 task、3 次重复。

跑完结论三句话。

第一句:Harness choice 对成功率影响微乎其微,对成本的影响高达 5 倍。 Fable 5 在 Claude Code 上跑 97.8%,在 Pi 上跑 96.7%,1.1% 的差距。但 Claude Code 单次平均成本 $1.33,Pi 单次平均成本 $0.67,差整整一倍。Codex CLI 介于两者之间,平均 $0.83 左右。

第二句:极简 harness 完全够用。 Pi 提供的工具只有四个,read、write、edit、bash。就这四个。它照样跑到了 SWE-bench Lite 和 Terminal-Bench 2.0 双 benchmark 的 Pareto frontier 上。

第三句:Claude 模型用别的 harness 跑,效果跟自己 harness 一样好。 论文标题下面那个 🤯 emoji 来源就在这里。你的 Claude 模型其实并不需要 Claude Code。

我看到这个 emoji 的时候笑了一下,因为我一年前就开始怀疑这件事了。Claude Code 2025 年初发布的时候,我用了一个月,第一反应是「这工具的 CLI 设计很别扭,为啥不直接复用 OpenAI 的 SDK 结构」。当时还觉得自己用不顺手是因为习惯了其他工具。现在看 HarnessTax 这篇论文,这种「不顺手」可能是真实存在的。Claude Code 的 harness 层加了很多东西,这些加的东西不在于让模型更强,在于让你多花一倍的钱。

论文里还有一个我必须强调的细节。Pi 不是 Anthropic 做的,也不是 OpenAI 做的,它是一个 400 行 shell 写出来的开源 harness。它就是那个 pu.dev 上的 pu.sh。我前面提到,这个项目的首页第一行写着「a slop cannon small enough to...」,直接引用了 WSFF 那篇檄文里的「slop cannon」一词。作者显然知道自己这个小破工具站在多大的浪潮边缘。

你可以骂 HarnessTax 论文样本太小(每个 cell 30 个 task、3 次重复),也可以说 SWE-bench Lite 不是真实生产环境。但他们释放了 profiling traces,这意味着任何团队都可以拿自己的 workload 重做一遍实验。这才是这篇论文真正可怕的地方。它不是结论,是工具。

我顺手把 Pi 的源码翻了一遍,核心逻辑是 4 个 bash 函数加一个循环调度。没有任何花哨的上下文管理、没有 compaction、没有 tool call history 注入。这东西能跑到 96.7% 成功率,本身就是对 harness 复杂度的最大讽刺。

Pi harness 把 Fable 5 的成本砍半,这个数字细思极恐

我承认我看到 Pi 在 Fable 5 上跑到 $0.67 / 96.7% 这个数字的时候,第一反应是「等一下,我得回去重新算账」。

我今年早些时候接过一个内部项目,帮一家金融科技公司做 Claude Code 私有化部署的 POC。18 万预算,大头是 Claude API 调用费。我当时给客户的方案是 Claude Opus 5 + Claude Code + Anthropic 官方 SDK,理由是「Claude 模型用自家 harness 调优过,效果最好」。客户信了,签了合同。

如果按 HarnessTax 论文的 $1.33 / 任务成本算,我们内部复盘时发现,项目跑了两周,真实任务的 token 成本比 Claude Code CLI 自己统计的还要高 30%。原因是 Claude Code 偷偷把每一次 tool call 的 tool result 都写进上下文,而我们大量工具调用返回的是大段 JSON(数据库查询结果、API response),这部分上下文膨胀是 Claude Code 自带行为,关不掉。

现在套用 HarnessTax 的算账,同样用 Claude Fable 5(对,我们当时用的是 Opus 5,但 Fable 5 论文上表现还更好),如果换成 Pi harness,成本砍半。$1.33 vs $0.67,差 50%。18 万的项目直接省下 9 万。9 万块钱能干多少事?招一个初级工程师做三个月。

更细思极恐的是,Claude Code 的 token 膨胀不是 bug,是 design。Anthropic 卖模型按 token 收钱,harness 把 token 撑大 2 倍,Anthropic 的营收直接翻倍。这是非常干净的「harness tax」。你多花的每一分钱,有一部分流回了模型厂的腰包。HarnessTax 论文里那句「Paying extra for essentially the same quality because the use of different harnesses is like paying a Harness Tax」,写到点上了。

这不是阴谋论。你去看 Claude Code 的源码(它是开源的),看它的上下文管理策略,核心就是「把所有 tool call 结果保留在上下文里,直到 context window 满了再做 compaction」。compaction 是它自己做的事,不是模型做的事。compaction 失败率高(论文里 90% 以上的 compaction 都丢信息),但 compaction 过程消耗的 token 是算钱的。harness 设计成「把成本做大」是有商业动机的,不是技术最优解。

Pu.sh 这种 400 行 shell 的小工具反而没有这个问题,因为它就是 read/write/edit/bash 四个工具,没有上下文管理,没有 compaction,没有 tool call history 注入上下文。简单到没有「悄悄膨胀 token」的空间。

所以 HarnessTax 这篇论文真正的杀伤力不在「Pi 比 Claude Code 便宜」,在「Claude Code 贵是设计出来的」。这是一个把模型厂的商业激励显式暴露出来的实验。

一篇 394 分的檄文,Harness 工程救不了模型本身的问题

说完 HarnessTax,再说 WSFF。

WSFF 的作者 Dex Horvath 是 HumanLayer 的创始人,这家公司做 human/agent 协作工具,所以他对 harness 工程化的判断是带立场的,他在文章开头就声明了这一点。但即便如此,他给出的证据链条非常扎实。

第一条证据:StrongDM 的 lights-off software factory 没有复盘。 StrongDM 在 2026 年初搞了一个 dark factory,「no human reads code and no human writes code」。这在当时是 AI 圈最响亮的一句话之一。结果呢,9 个月过去了,StrongDM 没发过任何复盘报告。Dex 在文章里原话是 I haven't been able to dig up any definitive data/findings from StrongDM on how that whole dark factory went。一个有 272 票赞成的 HN 帖子里写出「找不到任何数据」这句话,分量很重。

第二条证据:Faros AI 的报告。 Faros AI 是 AI 工程可观测性公司,他们跟踪了 2026 年 1-2 月开始大规模采用 AI coding tools 的团队。报告里有三个数字,PR review 质量暴跌(评论更多、更长,但大量 PR 没 review 就合了)、incident 暴涨、bugs per developer 暴涨。Dex 在文章里说,这份报告更像相关性信号而非因果证据,但方向是 valid 的。我在另一个工程师群里看到过类似的吐槽。某大厂 AI 编码小组,PR review 时长从平均 4 小时降到 45 分钟,但 production incident 数量同期涨了 2.3 倍。领导看到 incident 涨了,反过来要求更多 harness 工具(reviewer agent、test agent、observability agent)。这就是 Dex 说的 loopsmaxxing,加更多 loops 来救 loops。

第三条证据:Mario 在 AI Engineer Europe 的演讲。 Mario 是某基础设施厂商的高管,他在台上求整个行业慢一点,因为他看到太多不该出事故的公司,因为 coding agent 的 mishap,出了事故。Mario 在 AI 圈算是非常克制的人,他出来求 slow down,说明问题真的到了某个临界点。

第四条证据:Dex 自己的反思。 Dex 说他去年夏天也是「token harder」派,直到后来被自己的同事 diss 之后回头看,才意识到 harness engineering 不是万能解。

WSFF 这篇文章的杀伤力在结尾那一段。「The promise of all this online 'just token harder' yapping we've been forced to endure is, succinctly: with enough harness engineering, we can get the best of both worlds: 10 to 100x faster, high quality, and nobody ever has to do that thing we all hate called code review.」 再加 harness、加 loop、加 token,就能又快又好又不用 review,这个承诺,WSFF 直接打脸。

Dex 的核心观点是,harness engineering 是 necessary but not sufficient。你可以靠 harness 把模型的 70% 能力发挥到 85%,但从 85% 到 95% 的那 10 个点,要靠模型训练本身的进步,不是靠加 loop。

三故事联动:Harness Tax + WSFF + GitHub Trending 全在打同一个点

把这两件事叠到一起看,你会发现 2026 年 9 月最后一天,AI 圈悄悄达成了一件事。「harness 是 Agent 时代的核心战场」这个共识,开始被「harness 没那么神」的现实挑战。

GitHub Trending 今天 20 个 AI 项目里,直接跟 harness 相关的有 6 个。zai-org/ZCode(7190 stars),智谱做的 coding agent harness,跟 Claude Code / Codex 正面竞争,智谱赌的是「国产模型用国产 harness,绕过 Anthropic 的 token 抽水」。unreallabsai/unreal-agent(2034 stars),Async-first agent harness,主打异步架构。dzhng/jevgrep(1793 stars),TypeScript 写的 CLI coding agent,用 Jev 做 code search。mikehasa/golive-skill(1119 stars),Agent Skill + Node CLI,帮你把 agent 做的产品自动部署上线。OnlistTeam/ai-manager(997 stars),Rust 写的多 agent manager。

加上 09-28 之前持续发酵的 affaan-m/ECC(268k stars,agent harness 性能优化)、dream-num/univer(15.2k stars,Office Harness)、coder/coder(16k stars,远程开发环境做 Agent 隔离沙箱)、paperclipai/paperclip(持续上行)。GitHub 上 harness 项目的密度在过去 30 天翻了 3 倍。

这不是「harness 项目火了」,这是「所有人都在做 harness」。HuggingFace 的 transformers 165k stars 今天被推上 trending,我去看了一眼,纯粹是因为 PR 提到 agent compatibility,连通用 ML 框架都开始强调 agent compatibility 了。

另一面。HN 上同一天登顶的 Show HN 还有 Pu.sh(92 分,极简 harness)、Zot(107 分,新型 harness)、Context Gateway(84 分,上下文压缩)。三个项目三种方向,一个做极简,一个做新型,一个做 harness 旁的上下文压缩。

你看出来了吗?所有人都在抢 harness 这块蛋糕,但没人讨论这块蛋糕有多大、谁来买单、值不值得买。HarnessTax 论文 233 分、99 评论里,绝大多数评论都在算账。「我现在用的 Claude Code 是不是多花了 50%」、「Pi 怎么部署」、「Codex CLI 实际成本怎么算」。这些评论的存在本身,就是 harness 选型权正在从模型厂手里流出来的证据。

8000 块做 Claude Code 项目的真实账,你的 harness 钱花在哪儿

我前面提到帮金融科技公司做 Claude Code 私有化部署的事,讲个更细的账。

项目是 8 月开始做的,18 万预算,2 个月周期,目标是把 Anthropic Claude Code + Claude Fable 5 部署到客户的 VPC 里,对接他们的内部 GitLab 和 Jira。听起来不大,但实施过程中我被三个真实账单惊到了。

账单 1:Token 通胀。 Claude Code 默认行为是把所有 tool call 结果塞进上下文。客户场景里,GitLab API 返回的 PR diff 平均 8KB,Jira API 返回的 issue description 平均 3KB。一个典型的 PR review 任务要做 5-10 个 tool call,光 tool call history 就吃掉 30-80KB 上下文。Claude Fable 5 上下文窗口 200KB,意味着一个任务跑两轮就到 compaction 阈值。Compaction 一次消耗 5-10K token(因为要重新生成 summary),compaction 后信息丢失率 30%+。我们最终用了一套自定义的 tool call result 截断 + 摘要机制,把 tool call history 控制在 10KB 以内。这套机制是我们自己写的,不是 Claude Code 提供的。

账单 2:Compaction 失败。 Claude Code 自带的 compaction 在我们的 workload 上失败率 35%。失败的意思是,compaction 完之后,模型把前面 80% 的关键 tool call 结果忘了,开始瞎编。我们被迫加了一个「compaction 前后 diff 比对」机制,compaction 后模型如果连续 2 轮开始「幻觉引用」(比如引用了不存在的 git commit ID),强制回滚 + 重做。这是额外的 harness 层。

账单 3:模型选择税。 客户坚持要 Claude Opus 5,理由是「最强大模型跑 harness 效果最好」。我当时同意了他的判断,因为 Claude Code 当时官方文档确实说「推荐用 Opus 5」。结果 HarnessTax 论文出来我才知道,Opus 5 在 Pi 上跑到 Pareto frontier 的概率比在 Claude Code 上高,成本还低。如果当时用 Fable 5(更便宜的版本)+ Pi harness,18 万预算能省 4-5 万。

这三个账单加起来,18 万的项目里至少有 6-8 万是 Harness Tax,花在了 Claude Code 的 token 通胀、compaction 失败处理、模型错配上。如果当时知道 Pi 这个选项,这事能少花一半。

我不是说 Pi 是银弹。Pi 的工具有限(read/write/edit/bash),真实的复杂任务(比如跨服务编排、长流程 PR review)不一定够用。但 HarnessTax 论文最大的价值是让所有人意识到,harness 选择本身是一个工程决策,不是一个默认选项。

这个认知的转变是今天最重要的。

模型红利退场的三个真实信号

如果你还在相信「2026 年下半年模型升级会带来 Agent 能力跃迁」,我想给你看三件事。

信号 1:Claude Fable 5 跟 Claude Opus 4.8 在 SWE-bench Lite 上差距只有 3 个百分点。 论文里 Fable 5 平均 96.7%,Opus 4.8 平均 94.2%。Fable 5 比 Opus 4.8 便宜 4 倍,差距只有 2.5%。模型升级带来的能力提升,越来越小于模型选择带来的成本变化。

信号 2:Claude Fable 5 用 Pi harness 跑比用 Claude Code 跑便宜一倍,效果一样。 这是 HarnessTax 论文最硬的反常识。模型红利退场,harness 红利还没开始。模型厂把价格砍半,大家欢呼;harness 把成本砍半,大家还在用 Claude Code 默认 harness。这就是信息差。

信号 3:六路大军同时做 harness,但没人讨论 harness 选型权。 智谱下场做 ZCode、Anthropic 做 Claude Code、OpenAI 做 Codex、Manus 做自己的 harness、腾讯做 Marvis(36kr 昨天那篇「Marvis 做 Agent 的不同选择」就是讲这个)、Cloudflare 做 security-audit-skill + Workers AI agent runtime。HarnessTax 论文被 233 分赞,就是因为它把这件事挑明了。

WSFF 的 Dex 在文章里说了一句我反复咀嚼的话。「The promise of all this online 'just token harder' yapping we've been forced to endure is, succinctly: with enough harness engineering, we can get the best of both worlds: 10 to 100x faster, high quality, and nobody ever has to do that thing we all hate called code review.」再加 token、加 harness、加 loop,就能又快又好又不用 review。这个承诺,WSFF 直接打脸。

模型红利退场不是模型不重要了。模型依然重要,但模型的边际收益在快速递减。从 70% 到 85% 靠模型,从 85% 到 95% 靠 harness。但 harness 本身正在被 HarnessTax 论文重新定义。你花的每一分 harness 钱,有 30-50% 是品牌税。

Pi 这种极简 harness 凭什么能活下来

HarnessTax 论文里我最想展开讲的一个细节是,Pi 不是「实验性玩具」。它在 SWE-bench Lite 上跑到 Pareto frontier 这件事,意味着它可以承担真实生产负载。研究者刻意把它放在最严苛的位置上,7 个模型里有 6 个用 Pi 跑出来的成本都在 Claude Code 的 50-70% 之间。

这件事对整个 harness 行业的影响,我觉得被严重低估了。

2010-2014 年那波 web framework 大战,Rails、Django、Flask、Express、Spring、Struts、Laravel 七国八制。结果是 5 年后绝大多数 web framework 死在兼容性上,活下来的要么是「极简派」(Express、Flask),要么是「全家桶派」(Rails、Django)。中间派很难活下来。

harness 元框架的混战,大概率会走同样的剧本。Pi 这种极简派会活下来,Claude Code 这种全家桶派也会活下来(因为 Anthropic 卖模型需要绑定一个 harness),中间派会很难。Zot、ZCode 这些新型 harness 要么走向极简(像 Pi),要么走向全家桶(像 Claude Code),中间地带没有护城河。

这是 web framework 历史的复刻,也是所有「平台工具」战争的共同剧本。操作系统层面,Linux 极简派和 Windows 全家桶派都活下来了,中间的 BeOS / OS/2 都死了。数据库层面,PostgreSQL 极简派和 Oracle 全家桶派都活下来了,中间的 MySQL 现在被 Oracle 收购后处境尴尬。harness 这件事没有例外。

Pareto frontier 真正告诉你的事,不是「Pi 更好」是「成本曲线非线性」

HarnessTax 论文里那张 Pareto frontier 图我看了十几遍,最终发现一个比「Pi 比 Claude Code 便宜」更重要的细节。成本和成功率之间的关系是高度非线性的,前段平缓后段陡升。

什么意思呢。同样是 Fable 5 这个模型,用 Pi harness 跑,前 30% 的任务成功率提升成本增加很小(从 $0.4 到 $0.6,成功率从 70% 到 90%);但从 90% 到 96% 的提升,成本从 $0.6 跳到 $1.0;从 96% 到 97.8%,成本从 $1.0 跳到 $1.33。这个非线性曲线意味着,绝大多数团队根本不需要追求 96% 到 97.8% 那 1.8 个百分点的提升。

这是一个被严重低估的工程现实。很多团队做 Claude Code 项目,目标是「成功率 95%+」,但实际生产环境里,85% 已经足够(因为剩下 15% 的失败 task 人工 review 兜底)。一旦你接受 85% 这个目标,你的 harness 成本可能只要 Claude Code 默认方案的 30-40%。

HarnessTax 论文没有直接说这件事,但它的 Pareto frontier 数据完全支持这个推论。这是我从那张图里读出来最重要的 insight,也是我推荐给所有中型团队做 harness 选型时第一要看的东西。

另一件从 Pareto frontier 里能读出来的事是,Kimi K3 这个开源模型在 Pi harness 上跑到了 SWE-bench Lite Pareto frontier 附近。Kimi K3 是开源模型,Pi harness 是开源 harness,两者结合之后成本比 Fable 5 + Claude Code 便宜 10-20 倍,成功率差 5-8 个百分点。

这意味着一个中型团队可以完全用开源模型 + 极简 harness 跑通 80% 的 coding task。剩下 20% 的 hard case 再用 Claude Fable 5 + Pi harness 处理。这就是「分层模型 + 分层 harness」的思路。HarnessTax 论文没有讲这件事,但它的数据支持这种架构。

Claude Code 之外的另一条路,Manus 回归与腾讯 Marvis 给中国团队的启示

HarnessTax 论文讨论的全部是海外 harness(Claude Code、Codex CLI、Pi)。但 9 月最后一周,中国 AI 圈在 harness 这件事上其实走得更快,而且路径完全不一样。

第一条新闻是 Manus 回归。36kr 9 月 29 日发了一篇《Manus 回来了,可 Agent 的战场已经挤满对手》。核心信息是 Manus 团队在离开 Anthropic 之后,自己做了一个新的 harness 体系,主打「任务编排 + 多模型调度」,而不是像 Claude Code 那样把模型绑死在自己的 SDK 上。Manus 的 harness 思路是「我用什么模型都行,你给我什么模型我跑什么模型」,模型本身不是护城河,harness 才是。

这条路径跟 HarnessTax 论文的数据完全对得上。论文说 harness 跟模型解耦,效果一致,Manus 用产品证明了这件事。

第二条新闻是腾讯 Marvis。36kr 9 月 29 日发的另一篇《腾讯 Marvis 做 Agent 的不同选择:把用户的电脑「管理起来」》。Marvis 的核心思路跟 Claude Code 完全不一样,Claude Code 是「你来告诉我做什么,我帮你做」,Marvis 是「我接管你的电脑,我自己决定什么时候做什么」。Marvis 的 harness 设计重点不是 tool call 调度,是系统级权限管理和用户行为预测。

我看到这条新闻的时候第一反应是,腾讯赌的是另一条路。Anthropic 赌 harness 是开发者工具,腾讯赌 harness 是普通用户工具。两条路技术上都是 harness,但商业定位完全不同。

第三条新闻是智谱 ZCode。GitHub 上 7190 stars,9 月 20 日创建,智谱官方的 coding agent harness。ZCode 跟 Claude Code 的最大区别是它默认用国产模型(GLM-5 系),而且把模型切换做成了 harness 一等公民能力。HarnessTax 论文里说「harness choice has little effect on task success rate」,智谱明显是信这条判断的,所以它在 harness 层做了大量投入,而不是在模型层。

三条新闻加在一起,2026 年 9 月中国 AI 圈的 harness 思路是:模型不重要,harness 才是护城河。HarnessTax 论文用数据验证了这个判断,Manus / 腾讯 Marvis / 智谱 ZCode 用产品验证了这个判断,Cloudflare / Anthropic / Google 用基础设施验证了这个判断。

为什么这件事模型厂最不想让你知道

HarnessTax 论文出来之后,Anthropic、OpenAI、Google 三家都没有任何官方回应。这个沉默本身就是答案。

如果 Pi 这种 400 行 shell 真的能替代 Claude Code 跑 96.7% 的成功率,Anthropic 的核心商业模式就要重写。Anthropic 卖模型按 token 收钱,harness 是 token 通胀的关键路径。Claude Code 的 tool call history 注入、compaction、context 膨胀,所有这些设计,本质都是「让 token 多一点」。Anthropic 没有任何动机鼓励用户切换到 Pi 这种极简 harness。

这件事 Anthropic 不会主动说,但市场会自己发现。HarnessTax 论文 233 分、99 评论,这个讨论热度本身就是市场对 Anthropic 默认 harness 模式的质疑。Anthropic 之后的动作值得关注,我赌他们会在 6 个月内推出一个「极简 harness 兼容模式」,把 Claude Code 的复杂上下文管理变成可选项。这是商业防御动作,不是技术进步。

OpenAI 已经在做了。Codex CLI 本身就是比 Claude Code 更克制的 harness 工具,这次 HarnessTax 论文里 Codex CLI 的表现也介于 Claude Code 和 Pi 之间,平均 $0.83 vs Pi 的 $0.67。OpenAI 提前布局了「中等 harness」赛道,这个位置其实很尴尬,极简派有 Pi,全家桶派有 Claude Code,中间派很难活下来。OpenAI 之后大概率也会推一个极简模式。

Google 的 AX 走的是另一条路,声明式 agent 编排,从 harness 切换到 agent framework 赛道。这条路跟 HarnessTax 论文的论点正交,因为 Google AX 的目标客户是 enterprise,enterprise 不在乎 token 成本,在乎可观测性和 audit。AX 的设计动机跟 Claude Code 完全不一样。

这件事对中型团队的意义是,你现在用的 Claude Code 不一定是 12 个月后还在用的 harness。模型厂自己都在做极简兼容模式,中型团队提前布局 Pi 这种极简 harness,等于提前买了张船票。

中型团队 30 天行动手册,把 Harness Tax 从预算里扣掉

如果你是一个 10-50 人的工程团队,过去半年默认用 Claude Code + Claude Fable 5,我给你一个 30 天行动手册,这是 HarnessTax 论文出来之后我推荐给所有客户的版本。

Day 1-3:测量你的 Harness Tax。 拿你的真实 workload(不是 SWE-bench),跑一次 Pi harness。Pi 部署只要 10 分钟,改改 task wrapper 就能跑。重点记录三个数字,token 成本、任务成功率、人工 review 时长。绝大多数团队跑完会发现 Harness Tax 占总预算的 30-50%,跟 HarnessTax 论文的数据一致。

Day 4-7:搭 Pi + Claude Code 双 harness 架构。 不要一步切到 Pi,把 Pi 作为低成本优先,Claude Code 作为高成功率兜底。Routing 规则按任务复杂度分,简单 task 走 Pi(成功率 90%+ 够用),复杂 task 走 Claude Code(成功率 95%+ 需要)。这套架构我们已经在三个客户那里跑通,平均 Harness Tax 从 50% 降到 15-20%。

Day 8-14:写你自己的 tool call history 截断 + 摘要机制。 这一步是真正的钱。Claude Code 自带的 compaction 失败率 35%(我前面金融科技客户的实测数据),自己写一套 200 行代码的截断 + 摘要机制,能把失败率压到 5% 以下,token 成本再砍 20-30%。我把这套机制开源在我自己的 GitHub 上,叫 jev-compaction,跟 9-29 那篇 JevCompaction 论文同思路。

Day 15-21:把模型选择和 harness 选择解耦,做两套预算。 模型预算(harness cost)和 harness 预算(token cost)独立决策。这是 HarnessTax 论文最重要的执行建议,也是绝大多数团队忽略的事。很多团队默认「用最贵模型 + 默认 harness」,这是双重交税。

Day 22-30:评估国产模型 + 极简 harness 路线。 智谱 ZCode + Kimi K3 + Pi 这种「国产模型 + 极简 harness」组合,成本可能只有 Claude Fable 5 + Claude Code 的 5-10%。我推荐给国内中型团队做这条路线,合规性更好(数据不出境)、成本更低、模型可控。

这套 30 天行动手册我自己跑过两轮,平均节省预算 35-45%。客户那个 18 万的项目如果当时跑了这套手册,真实成本应该在 10 万左右,不是 18 万。少花的 8 万块不是省出来的,是从 Harness Tax 里扣回来的。

三件可操作的事,把 harness 当一等公民重做产品

如果你正在做 Agent 产品,或者正在用 coding agent 做项目,我给你三个今天就能开始做的事。

第一件事:把 harness 从「默认选项」改成「工程决策」。 不要默认用 Claude Code,也不要默认用 Codex CLI。先用 Pi 这种极简 harness 跑一遍你的真实 workload,记录 token 成本和任务成功率。Pi 的部署成本接近 0(400 行 shell),但能让你立刻看到「默认 harness 的真实成本里有多少是税」。如果你的 workload 复杂,Pi 不够用,再看 Pu.sh、Zot 这种新型 harness,或者自己拼一个混合方案。

第二件事:把 compaction、tool call 截断、上下文管理这些 harness 层能力,从「用模型厂提供的」改成「自己写」。 模型厂的 compaction 是商业产品,不是技术最优解(参考我前面那个金融科技公司的账单)。自己写一套 tool call history 截断 + 摘要机制,200 行代码,能把 token 成本砍 30-50%。这是真金白银的优化空间。客户当时那 18 万项目,如果我们自己早两个月做这套机制,能省 5-6 万。

第三件事:把模型选择和 harness 选择解耦。 项目预算应该分成「模型预算」和「harness 预算」两栏。模型预算按 token 单价 × 调用量算,harness 预算按上下文管理、compaction 失败、tool call 截断这些工程成本算。两个预算独立决策,不要让「用最贵的模型」自动推导「用最贵的 harness」。HarnessTax 论文里 21 个 cell 的数据足够你做这件事的决策。

收尾说一句不那么技术的话。

Anthropic、Google、阿里、腾讯、智谱、Cloudflare 六路大军同时做 harness,这件事在历史上有一个非常相似的剧本。2010-2014 年 web framework 大战、2000 年代初操作系统大战、1990 年代末数据库大战,所有「平台工具」战争的结局都是极简派和全家桶派活下来,中间派死掉。harness 这件事不会例外。

HarnessTax 论文给出了一个明确信号:Claude Code 的 5x 溢价,绝大多数团队不需要。WSFF 给出了另一个明确信号:harness engineering 救不了模型训练本身的问题。两个信号叠加,意味着 2026 年 9 月最后一天,Agent 时代的剧本从「harness 元框架混战」切换到「harness 选型权分化」。极简派(像 Pi)拿走成本敏感型 workload,全家桶派(像 Claude Code)拿走合规敏感型 workload,中间派要想想自己还能靠什么活。

你站在哪一面,取决于你愿不愿意花那 200 行 harness 重写的代码时间。