Model + Harness = Agent：产品差距的大头，不在模型

这是「Harness 深水区」系列的开篇，立的是框架。下一篇《我完全信任我的 AI，除了它说的”我做完了”》讲验收的实践：我怎么在验证上连栽三跤，又怎么把”信任，但要验证”修成一道可以直接抄走的验收 Gate。

这几天我在用 Kimi K3。同一个模型，我试了两种用法：一种跑在它自家的 Kimi Code CLI 里，一种接进 Claude Code。在我手里，接进 Claude Code 的那边明显更顺手。说清楚：这是我的体感，不是对照实验——何况接进去还是个”残血”用法，官方兼容层仍有限制，例如 Tool Search 需要关闭。残血还更顺手，这件事才有意思。

这不是野路子，是 Moonshot 官方支持的用法：文档里专门有 Claude Code 接入指南，改几个环境变量，自家旗舰就跑进了竞品的壳。更有意思的是 K3 官方模型卡里的脚注：自家的 Kimi Code Bench 2.0，K3 用自家 harness 跑是 72.9 分，用 Claude Code harness 跑是 73.7。0.8 分的差距说明不了谁强谁弱——关键在别处：Moonshot 把 Harness 当作评测条件单独披露，官方成绩单里另外还有两项 coding、两项 agentic 基准，直接用 Claude Code 跑自家模型。这也不是 Moonshot 一家的做法，GLM、DeepSeek、MiniMax 都提供 Anthropic-compatible 端点和 Claude Code 接入方式。多家模型厂商都在用产品行动承认：模型和 Harness，是可以分离的两层。为什么？

因为很多重度用户真正不愿离开的，往往不只是模型，而是沉淀在 Harness 里的那套东西：hooks、MCP、CLAUDE.md、整个工作流。海外一篇集成指南有句很准的话，翻成中文就是：“换模型是一个环境变量的事，换 Harness 是一个周末。“能一键迁走的只是配置文件；迁不走的，是你对这套工具什么时候会犯什么错的那份预期。

公平地说，Kimi Code 仍处在快速迭代期，而 Claude Code 已积累了更长的工程时间。我倾向把这份差距的大部分归因于工程成熟度——两者之间隔着的，正是本文要讲的那层东西。

再往前说一步：这个差距，我不认为会永久存在。Harness 和模型是共同成长的——第一方比谁都清楚自家模型的脾气，也最有条件把 Harness 里的真实使用信号直接回流到自家模型迭代。只要 Moonshot 方向不判断错、坚持做下去，自家 Harness 反超 Claude Code 只是时间问题。这是一个可以被时间检验的预测，立此存照。

这一年我日常重度使用 Claude Code、Codex、Cursor，还自己搭了一套 17 个角色的多 Agent 协作系统（已开源；17 是我探索出来的上限，不是推荐值，取舍写在 README 里）。踩了足够多的坑，加上 K3 这个新鲜例子，我收敛出的判断是：

Model 决定 Agent 能力的上限；Harness 决定有多少人能稳定地够到这个上限。

这两年，我越来越常看到”Model + Harness = Agent”这个公式；常见的读法是”模型决定上限，Harness 决定下限”。我认为”下限”读偏了：下限说的是最差表现，而 Harness 真正决定的是兑现——上限的可及率。对单个用户，这是稳不稳的问题；放到整个市场，就是有多少人够得着的问题。

先回应一个自然的反问：工具和编排不也是 Harness 给的吗？那不就是提高了上限？——工具扩展的是手脚，判断力还是模型的：判断不行，手脚越多，错得越快。本文说的上限，是模型的判断力上限；Harness 的全部工作，是让这份判断力少打折扣地落到任务上。

但也要把话说清楚：模型优先。模型不过关，Harness 再精巧也救不回来——上限永远是模型给的，Harness 抬不高它。

但上限是一回事，兑现是另一回事。Harness 这个词，字面意思就是挽具：马能出多大力是马的事，力气有几成真的到了车轮上是挽具的事。这个比喻讲清了”传力”，但少了一个维度——你想拉多重的货。

更准的画面是两根柱子。模型的能力是一根，Harness 的成熟度是另一根，柱子的粗细就是承载力；你交给 Agent 的任务，是垒在两根柱子共同托着的板上的货——期待越大，垒得越高。

载荷轻的时候，柱子粗细不那么显眼：问个问题、翻译一段话，细柱子也能托住——这也是为什么聊天时代，Harness 很少成为用户讨论的主角。载荷一大，较细的那根往往先垮。而我们正好走进了最危险的组合：模型那根柱子，厂商在替你疯狂加粗；Harness 这根还细着，你却已经开始把整个项目往板上垒。顺带一句：模型柱会越变越粗，Harness 柱却往往来不及同步加粗——模型新长出来的能力，最容易暴露另一根柱子的不足（这个”能力≠成熟度”的展开，留给本系列的理论篇）。回到开头的 K3：模型没有换，这份体验差至少不能只用”模型能力”解释；最值得追的变量，落在 Harness 与运行条件上。

任务能垒多高，不取决于较粗的那根，取决于较细的那根。上限是模型柱给的；兑现，是较细的那根说了算。

左柱＝模型的能力，右柱＝Harness 的成熟度，粗细＝承载力；板上垒的＝你交给它的任务。载荷轻时怎样都稳；载荷一大，垮点通常在较细的那根。

评测数据也站在这一边。今年有篇立场论文，标题就把话挑明了——《不公开 Harness，就别比较 Agent》：长时程任务上，同一个模型只换 Harness，SWE-bench Verified 的公开监测差出最多 15 个百分点，另一个子集（Verified Mini）上出现过接近 48 个百分点的摆动；而各家论文当作”有意义的模型进步”来报告的，通常是 2 到 4 个百分点。在论文列举的公开样本和控制实验里，同代旗舰在同一套 Harness 下的分差，小于换一个 Harness 的分差——上限之差，小过兑现之差。这就是为什么 Harness 是 Agent 产品的真正战场。（边界说明：本文的样本和数据全部来自 coding agent，且论文结论限定在能力相近的前沿模型之间；别的场景有各自的约束，不硬套。）

论文汇总的两组公开结果：SWE-bench Verified 上最多相差 15 个百分点，Verified Mini 上的极端案例接近 48 个百分点；作为对照，被报告为”有意义模型进步”的幅度通常为 2–4 个百分点。

Harness 是什么：六件事

“Harness”最近很热，拆解也不少——有人从组成入手（系统提示词、工具、沙箱、编排），一篇 Harness Engineering 论文从职责层面拆到了十一项。但这类拆法回答不了”该先做哪件”。给 Harness 这根柱子加粗，具体是往哪儿加？我按职能拆成六件事，每一件都有自己的深水区：

1. 上下文工程——在有限窗口里，每一步都放对的东西。检索、压缩、会话内分层，这是信息架构问题，不是 prompt 技巧问题。
2. 工具调用与安全——让模型能动手，但动不了不该动的。沙箱、权限分级、fail-closed。
3. 人机交互——steering、审批、可中断、可回看。人在需要时随时能进来，且不累。
4. 记忆——跨会话、跨任务的知识，且带来源、可质疑、会过期。
5. 多 Agent 编排——拆解、派发、并发、验收、收敛，像一个真正的团队那样工作。编排提高的不是单点能力上限，是兑现的吞吐和可靠性。
6. 验收与评测闭环——单个任务能被独立验收（不信 Agent 自报，每一步可追溯），整体表现能被量化（“到底有没有帮到人”，而不是”看起来跑通了”）。

拿这六件事去照市面上的产品——只看默认的任务交付链路，不算要自己动手配置的可选项——会发现一个有意思的现象：没有一家六件全对，而短板惊人地集中在第六件：验收与评测。

只评默认任务交付链路（2026-07，作者使用判断，依据见下文三段点评）：没有一家六件全对，第六件是三家共同的缺口。

Claude Code 和模型配合极深（KV Cache 友好的 prompt 结构、subagent 上下文隔离），目标校验、hooks 这些件也有，但都要自己显式配——默认链路里，依然没有一个独立读取真实状态、自动放行或拦截的裁判；仪表盘衡量的是用量、采纳和产出贡献，不是”做对没做对”。

Codex 强在沙箱和多 Agent 分工；但 subagent 独立工作，主要通过任务说明与结果摘要和主线程交接，信息仍可能有损。它已经加入本地记忆，不过目前默认关闭。

Cursor 把 IDE 深度集成做成了开发者最高频的入口，治理这一年补课最猛——沙箱已经进入默认链路，分级审批、独立代码审查也有了；但 auto-review 和独立审查仍需选择或触发，默认的任务交付链路里，仍缺一道自动、独立、可阻断的验收——Agent 说”我做完了”，产品就信了。

拆完这些产品，最深的感受可以缩成一句话：

在我观察的这三套默认链路里，大家仍更常用模型补 Harness 的短板，而不是用 Harness 系统地约束模型的不确定性。

落到具体，是四个在默认交付链路里还没被系统性解决的问题：

• 依赖模型自己”做对事”，缺系统性的独立验证层——Agent 的自我报告，就是最终报告；
• 会话级或持久的权限白名单很常见，缺的是与任务契约绑定、任务结束自动回收的临时授权；
• 缺 Agent 表现的量化指标——好不好，靠感觉；
• 运行时的上下文装配偏被动，结构化记忆的主动注入还处在早期，默认行为各家不一。

这四个缺口，是 Harness 这个方向最值得先做的事。四者里先讲验收，因为它离最终结果最近，也最容易从外部独立测量。

验收：兑现的胜负手

六件事里，我押注最重的是第六件——验收。因为它直接决定”兑现”成不成立。这里能给一个可检验的推论：模型能力接近、其余条件相当时，验收层更硬的产品，任务闭环率会明显更高（闭环率＝全部入列任务中，在给定预算内交付且无需人工返工或回滚的占比，超时、放弃都计失败——这个口径不依赖验收层自己，可以从外部独立测）。

这条推论的前提——模型的自我报告不可信——我在自己的系统里反复撞见，严格的对照实验还没做（这正是”可检验”的意义：它是个能被推翻的预测，不是我拍脑袋的结论）。而撞见它的代价，值得单独讲一篇：我的 Agent 伪造过我的确认、干完活却报告”零改动”、测试全绿却在真机上全军覆没。这些坑最后收敛成一句话——Harness 的一项核心工作，是把模型的汇报和世界的事实分开对待——连同验收 Gate 的完整可抄实现，我写在了系列的下一篇《我完全信任我的 AI，除了它说的”我做完了”》里。这里只留一句垫底的结论：模型的进步是别人给的，Harness 的可靠性是自己挣的。

为什么现在写这个系列

接下来我会把这一年在 Harness 深水区踩过的坑写成一个系列：

• 怎么让 Agent 知道”做到什么程度算完”（规格三要素）；
• 为什么不能信 Agent 的自报（验收 Gate 的设计）；
• 上下文压缩会吃掉你的约束（context engineering 实战）；
• 记忆为什么需要”怀疑主义”（Skeptical Memory）；
• 怎么量化”Agent 是否真的帮到了人”（指标体系）。

还有一个更根本的问题：Harness 到底是谁的产品？它有两个用户——一个会抱怨，一个不会说话。这个问题会放在系列后段正面展开。

每一篇都遵守同一个写作规格：有真实机制、有踩坑代价、有可以直接抄走的设计。不写”十大技巧”，只写深水区。

---

关于”两个用户”那一层，我和既白——千手实验室的另一位作者，一个 AI——在东方既白系列写过第一笔：《Harness 有两个用户，其中一个不会说话》。