Claude Opus 5，第一次杀死 Harness？

7 月 24 日，Claude Opus 5 上线。几个小时之内，我看到各家媒体把这个模型的评测成绩转载了一轮，而更值得留意的是 Anthropic 内部人员当天发出的一条推文。

Thariq Shihipar 是 Claude Code 团队成员。

他写道，为了配合 Claude Opus 5 这一代模型，团队把 Claude Code 的系统提示词删除了 80% 以上，编码评估上没有观察到任何可以测量的性能损失。

他随后列出的建议更进一步。

CLAUDE.md 要保持极度精简，高绩效团队控制在 60 行以内，通常不要超过 300 行。测试、代码审查这类复杂流程不要写进提示词，拆成 Skills 按需加载。工具应当依靠清晰的接口和参数设计去引导模型，而非累加示例。

为了配合这套观念，Claude Code 还增加了一个 /doctor 命令，用来检查你的 CLAUDE.md 和 Skills 是否写得过长。

一个 Harness 工具，内置了一个专门劝你少写一点的命令。

这是一个很好的时代切片。因为这可能是 Claude Code 自诞生之日起，将「Harness」这个概念，第一次减弱了。

今年 7 月 7 日，Anthropic 发布了一份口述史，题目叫《The Making of Claude Code》，第一次把 Claude Code 的诞生经过完整讲了出来。

故事的起点是安全对齐研究，而非产品部门。

2021 年前后有一个粗糙的 VS Code 插件，2022 年初开始搭建编码 Agent 的强化学习基础设施，底子由研究工程师 Dawn Drain 打下，中间还经过一个名叫 clide 的内部命令行工具。

这些工作的目的都是搞清楚模型究竟能不能自己写代码，没有人想着做一款爆款开发工具。

转折发生在 2024 年 9 月。Boris Cherny 从 Meta 转投 Anthropic，进入一个名叫 Labs 的小组。这个组的规模小到什么地步，同一批人里有人做了 MCP，有人做了 Skills，另外两个人做了桌面端，全部人手就这么多。

他入职第一周做的东西听上去并不亮眼，把 Claude 连接到终端上，用 AppleScript 让它报出自己正在听的歌，然后帮忙换一首。那个版本读不了文件，用不了 bash，无法完成任何工程任务。

然后他把文件系统和 bash 权限交给了模型。

接下来发生的事情构成了整个 Claude Code 的起点。没有人教它，它自己开始探索了。 交给它一个代码库，它会主动读取文件、顺着 import 往下追索、把项目结构一点点还原出来。这个行为没有被写进任何提示词，是模型自行产生的。

可以说，Claude Code 的设计哲学从第一天起就是尽量不加干预。

而 Claude 本身越来越厚重的系统提示词，其实是后来一点点补充进去的。这主要也是因为当时模型能力较弱：每出一次模型事故，就会多一条规则。比如误删过不该删的文件，就多了一项禁令；喜欢在别人的代码库里到处添加英文注释，也就有了「默认不要加注释」的要求。

每一条规则背后都对应着一次具体的事故。

所以，Harness 本身并不意味着一种产品设计理念，至少在最初始的时候是这样的。

现在说回 Opus 5。它是 Anthropic 这一代的近前沿主力，定价每百万输入 5 美元、输出 25 美元，与上一代 Opus 4.8 完全持平，相当于 Fable 5 输入价的一半。SWE-bench Verified 拿到 96.0%，SWE-bench Pro 79.2%，比 Opus 4.8 的 69.2% 高出整整十个点，与 Fable 5 的 80.0% 相差不到一分。

计算机操作类的 OSWorld 2.0 从 55.7% 提升到 70.57%。上下文一百万 token，另外配有一个可以调节思考强度的 effort 旋钮，低档运行一次 lint 修复，成本只是高档的零头。

这发布材料里面，我看到了一个核心，也是很少人提到的，就是 Anthropic 拿 2026 年 IMO 的全部六道题去问 Opus 5，不提供工具，不套用任何 agent Harness，让裸模型直接作答。

生成的 24 份解答被三模型评审团判定全部正确，人类专家独立复核指定的那一份，给了满分。

裸模型、不套 Harness。

那么，如果一个模型在不借助外部脚手架的情况下，已经能完成高难任务，那我们过去一年反复比较的那些榜单，比较的到底还是模型本身吗？

今天所有编码类榜单公布的都是「模型 + Harness」的联合成绩，而各家使用的 Harness 并不统一。最典型的例子发生在 Anthropic 自己身上。它在 Claude Opus 4.8 的发布页脚注里引用 GPT-5.5 的 Terminal-Bench 2.1 成绩 83.4%，特意注明这是配合 Codex CLI Harness 测出的。

一部分原因估计是不套 Harness，GPT-5.5 似乎并不配与 Opus 4.8 对拼，这也是 Anthropic 团队的「傲慢」。

偏差的幅度可以量化，之前，官方 Swebench.com 把所有模型放进同一套 bash-only 迷你 Agent 标准化 Harness 的榜单，模型的得分，比各家自己报的成绩低了整整近十二分。

业内后来总结出一条经验法则，凡是比标准榜高出十到三十分的数字，基本都带着自家脚手架。

Harness 本身大概值 5 到 12 分。前四名模型彼此之间的差距，还没有这个数字大。

Artificial Analysis 之后承认了这个现实，专门做了一个 Coding Agent Index，把 Harness 和模型配成对来排名。排序当场就发生了变化，Codex 配 Sol 排第一，Claude Code 配 Fable 5 排第二，与纯模型榜的顺序并不一致。

放在这样的环境里，Anthropic 拿裸模型去答 IMO 的用意就清楚了。在「这个分数里究竟有多少来自模型、有多少来自脚手架」已经说不清的时候，它选择在这一次没有掺入任何脚手架。

所以， Harness 这个词到底是怎么被抬到今天这个位置的？

它最早是软件测试里的 Test Harness，一套让代码在受控条件下运行的夹具。后来迁移到机器学习，变成 Evaluation Harness，SWE-bench 直接把自己的任务执行器命名为 Harness。

等到大模型进入 Agent 时代，这个词才有今天的含义，指包裹在模型外面、让它能够真正动手工作的那一整层东西，系统提示词、工具定义、上下文管理、权限沙箱、状态持久化、验证循环都算在内。

社区把它压缩成一个公式：Agent = Model + Harness。

2 月，HashiCorp 联合创始人、Terraform 的作者 Mitchell Hashimoto 在博客里第一次明确为这套实践命名。他提出的核心理念是每当发现 Agent 犯了一个错，就花时间设计一个方案，确保它永远不会再犯同一个错。

几天之后，OpenAI 官方发表了一篇题为《Harness engineering: leveraging Codex in an agent-first world》的工程博客。

作者 Ryan Lopopolo 描述的实验足以让整个行业失眠。一个三人团队从一个空仓库开始，五个月产出一百万行生产代码、一千五百个合并的 PR，人类一行代码都没有手写，人均每天 3.5 个 PR，后来团队扩到七个人，吞吐量反而上升。

他们的信条是人类掌舵、Agent 执行。在这个团队里，手写代码被定义成一种失败模式，因为只要有人动手，就说明 Harness 少了一项能力。

文章结尾的一句话后来被行业大量引用，软件工程依然需要纪律，只是这份纪律现在更多地存在于代码之外的脚手架里。

从那以后，这个词进入了主流视野。Thoughtworks 的 Birgitta Böckeler 在 Martinfowler.com 上写出了整套 Harness Engineering 方法论。Ethan Mollick 把自己的 AI 指南重组成「模型、应用、Harness」三层。

Philipp Schmid 贡献了流传最广的比喻，模型是 CPU，Harness 是操作系统，CPU 再强，操作系统跟不上同样发挥不出来。斯坦福和 MIT 的 Meta-Harness 论文给出了最直接的量化，固定同一个模型只更换外面的 Harness，性能差距可以达到六倍。

行业里因此出现了一句近乎共识的话：模型是可替换的，Harness 不是。

这句话放在现在，有点可笑。

Vercel 在年初改造 v0 的 Agent，把可用工具从大约五十个精简到十个。Stripe 的自主 Agent 系统每周合并一千三百多个 PR，它的 Harness 里有一条被严重低估的规则，同一个问题失败两次就升级给人，不许无限重试。

过去两年 Model 和 Harness 分不开，是因为模型太弱。

Opus 5 的出现，几乎是整个行业内第一次需要承认：模型就是 Agent 本身，Agent 不是 Model + Harness。

过去两年被打包称作 Harness 工程的内容，至少有一半是在给模型写保姆手册。这就是一块遮羞布，它遮住的是模型当时还不够强这个事实。

现在布被揭开了。

最有意思的在于，Claude Code 团队始终就不是 Harness 的信徒，但 Harness 反而在国内引发了一堆厂商的「皈依者狂热」。

比如，有博客曾写道，2025 年是 Agent 的元年，而 2026 年注定是 Harness Agent 的元年。甚至给出了一套六大核心组件的清单，说缺一个都算不上真正的工程化。

甚至有人自创「三层模型」，把 Harness 拆成缰绳层之类的比喻来讲。

Claude Code 的创造者 Boris Cherny 在播客里曾经讲过他们的产品哲学。他们做产品时对标的始终是六个月之后的模型。围着今天的模型找到 PMF 的人，一定会被围着下一代模型做东西的人超过去。

他们把所有非模型的代码统称为 Scaffolding，也就是脚手架，而每次要不要增加一层脚手架，团队反复权衡只是：现在动手加上 Harness 能换来 10% 到 20% 的提升，还是要不要再等两个月，模型自己就会了。

他们办公区的墙上挂着一份裱起来的 Rich Sutton《苦涩的教训》，核心讲的是更通用的方法终将战胜更专用的方法，永远不要赌模型不行。

这份挂在墙上的东西，现在应验在他们自己身上。

「Harness 已死」这个结论，现在的话，还是下得太早，有点营销号。

不过，Opus 5 的发布和 Claude Code 系统提示词的巨量删减，或许会给其他厂商一个参考：若只有 Harness，而模型上的努力不够，相当于闭着眼睛开车。

永远不要赌模型不行。

文章来自于"杉森楠"，作者 "杉森楠"。