Harness 是什么？通俗理解是模型到人之间那层兜底
harness 常见定义是 agent + model;通俗理解是模型到人之间 gap 的兜底层。
- 常见定义:agent + model,这是工程界共识
- 通俗理解:模型和人之间那整层 gap 的兜底层
- 兜底范围:上下文、工具、权限、记忆、沙箱、UI、调度
- 本质动作:模仿人类工作模式,把模型包成可用产品
- 价值定位:LLM 是发动机,harness 是整辆车
- 关键判别:同模型不同 harness,效果差 50%+ 是常态
- 落地观察:harness 边际收益远高于模型升级
常见定义:agent + model
harness 的常见定义是「agent + model」——LLM 提供续写能力,agent 循环负责调度、工具调用、上下文装配。大部分工程讨论都从这里出发,这是 harness 的内核。
但这只是冰山一角。完整 harness 至少还要兜住下面这些:
- 上下文装配:系统 prompt、用户输入、工具结果压缩、长期记忆检索
- 工具注册与权限:白名单、参数 schema 校验、敏感操作二次确认
- 沙箱与副作用隔离:文件系统、网络、进程,可回滚
- 会话与可观测:日志、trace、回放、计费、调试
- UI / UX:交互节奏、流式输出、错误兜底
- 调度与并发:子 agent、任务队列、长任务后台
这些全是 harness 的活。模型本身只做一件事:把这一坨上下文吐出一个合理的续写。
通俗理解:模型到人之间那层 gap
如果想更通俗地理解 harness,站在「模型到人之间有什么 gap」上倒推会更清晰:
模型的天职是「看到上下文,吐下一个 token」。但人类的工作流不是吐 token——是「记得上一步说过啥、这事该不该打断确认、几个模块并行推进、搞砸了能不能撤回」。这些能力模型都不会原生具备,只能由 harness 在外面一层层包出来。
包得多厚才算合格？看目标用户。普通开发者要的是「开箱能用 + 偶尔能撤回」,平台团队要的是「每一层都能拦截 + 能审计」——前者是成品房,后者是毛坯房带配件市场,本质上都是 harness 层的事。
本质动作:模仿人类工作模式
为什么 harness 越来越厚？因为模型的能力上限还远低于人类,而人类的需求是从人的工作流倒推出来的。
要让模型「替人干活」,harness 必须复刻人类的几个本能:
| 人类本能 | 对应 harness 机制 |
|---|---|
| 记忆 | session、memory、压缩恢复 |
| 判断 | 权限弹窗、敏感操作二次确认 |
| 协作 | sub-agent、orchestration、消息队列 |
| 反馈 | plan mode、checkpoint、用户中断 |
| 兜底 | undo、回滚、沙箱隔离 |
每一个机制背后都是人类某项工作本能的复刻。把这些全加起来,harness 才是「能替人干活」的形态,而不只是「会续写 token 的工具」。
这就是用户视角下 harness 的本质:通过模仿人类工作的整套流程,让模型嵌入现成的轨道,最终把人从重复劳动里解放出来。
价值定位:发动机 vs 整车
一个更直观的类比:LLM 是发动机,harness 是整辆车。
同一个车壳换一台发动机(比如从 Sonnet 4.5 升级到 Opus 5),边际提升也许 20-30%。
但同一个发动机换一辆车壳(比如把 Sonnet 4.5 从裸 API 搬进完整 harness vs Claude Code),能力差异往往是 3-5 倍甚至一个数量级——能不能跑长任务、能不能调用工具、能不能回滚、能不能并行,这些全是车壳给的。
这也是为什么现在头部 Agent 产品的护城河几乎全在 harness 层——模型正在 commodity 化,harness 才是产品。
关键判别:同模型不同 harness 的效果差异
之前我也以为「用什么模型决定一切」。后来发现这个判断太粗。
同模型 + 不同 harness,实际效果差异经常在 50%+:
- 同一个 Sonnet 4.5,裸 API 写代码 vs 放进 Claude Code 里写代码,完成率差很多
- 同一个模型,加 plan mode 和不加 plan mode,长任务稳定性差距巨大
- 同一个模型,harness 带了 RAG / 工具检索 vs 不带,私域知识问答效果差 2-3 倍
- 同一个模型,harness 有 sub-agent vs 没有,并行任务吞吐差一个数量级
评估一个 Agent 产品时,只看「它底层跑什么模型」是信息量最低的判断方式。
设计取舍:厚 vs 薄
Harness 不是越厚越好,也不是越薄越好。两种路线各有适合场景:
| 维度 | 厚 harness（成品房） | 薄 harness（毛坯房） |
|---|---|---|
| 适合用户 | 普通开发者、追求开箱即用 | 平台团队、需要深度定制 |
| 模型自由度 | 低（被 prompt / 工具约束） | 高（模型自己决定） |
| 稳定性 | 高（流程固定） | 低（容易跑偏） |
| 上手成本 | 低（零配置） | 高（需要装配） |
| 可定制上限 | 中（外层扩展功能有限） | 高（几乎可以重定义一切） |
| 典型代表 | Claude Code、Codex CLI | Pi、DeepSeek Harness、OpenCode |
核心权衡:harness 越厚,模型越被驯化但越可控;越薄,模型越能发挥但越需要在 loop 里。Pi 的设计哲学（Pi 的设计哲学：核心极简、行为外置的 4 包架构）就是把这条路线推到极致——核心只做四件事,其他全外移。
落地观察:现阶段 harness 边际收益远高于模型升级
2026 年这个时间点,harness 的边际改进 ROI 远高于模型升级。
- 模型升级:Sonnet 4.5 → Opus 5,某些任务好 20-30%,但价格贵 5-10 倍
- Harness 升级:加 plan mode、加并行子 agent、加沙箱回滚,某些任务好 50-100%,几乎不增加成本
这也是为什么 DeepSeek Harness、Pi、OpenCode 这些头部框架都在「harness 层做文章」——模型已经够强,瓶颈在怎么把它用对。参考 DeepSeek Harness 是什么？为什么说"一切皆插件"？ 就能看到,最激进的尝试是在 harness 层把每一块都做成可替换插件——本质上是在赌「harness 层还有大量可挖的金矿」。
判断 Agent 产品的标准
下次再看到一个 Agent 产品,别只问「它用什么模型」。多问几个问题:
- 它的 harness 兜了哪些 gap？记忆 / 工具 / 权限 / 沙箱 / 回放,是不是每层都有
- 同样的模型,它在 harness 上做了哪些特化？prompt、工具、流程有没有针对性设计
- 它的 harness 是厚是薄？是不是符合目标场景
- 出错时 harness 怎么兜？能不能回滚、能不能定位
harness 不只是「让模型能跑」,而是「让模型跑得像人」。这才是判断 Agent 产品力的核心维度。