软件开发里，大家最熟悉的词可能还是 agent。
但最近两年，另一个词开始频繁冒出来：harness。
这个词不好翻。按字面，它是“安全带”或者“束具”。不过放到 AI 工程里，我觉得它更像一层“驯化外壳”——不是替代模型，而是把一个不稳定、不可预测、还经常会撒谎的模型，拴到一个稳定、可验证、可以控的运行环境上。
这篇文章整理自 IBM 的 Tejas Kumar 在一场技术会议上的分享 Harnesses in AI: A Deep Dive。
这场 talk 只有二十分钟，但讲清了一个很重要的判断：真正决定 agent 能不能进生产的，往往不是 prompt，而是 harness。原视频： https://www.youtube.com/watch?v=C_GG5g38vLU
为什么今天谈 harness 比谈 prompt 更重要
Tejas 开场先讲了一件很现实的事：大多数开发者并不拥有模型，他们只是“租用”模型。
我们按月给 Claude、OpenAI、Google 或别的模型公司交钱，换来一个上下文窗口、一些 token 配额，以及一个表面上稳定、实际上内部细节完全不可见的黑盒。
你看到的是 Opus，后台是不是某种降配版本，你未必知道。模型今天表现很好，明天换了一点权重、路由或者限流策略，输出就可能不一样。
如果你的应用只是聊天，这种不稳定还能忍。
但只要模型开始调用工具、执行命令、改文件、登录系统、发请求，问题就变了。你要的已经不是“偶尔答得很聪明”，而是“每次都别出事”。
所以他给出的关键词不是 intelligence，而是 reliability。
harness 的价值，就在这里。它不是帮模型变聪明，而是帮系统变可靠。
harness 到底是什么
Tejas 用了一个很直观的类比。
登山的人会把自己挂在山体上。遛狗的人会给狗套 harness，而不是随便让它乱跑。
共同点只有一个：把一个可能偏航的东西，系到一个稳定物上。
放到 AI agent 里，他给出的定义是：
harness 是模型周围那一整层，让模型能够被现实世界约束、验证和纠偏的东西。
这一定义很关键，因为很多人会把 harness 理解成 agent loop，或者理解成一套 prompt 模板。
但 Tejas 反复强调，不是。agent loop 只是其中一部分。真正的 harness，是 loop 外面那一圈工程设施。
在他的拆解里，一个典型的 agent harness 通常包含下面几类组件。
- tool registry：工具注册表。模型能读文件、写文件、执行 bash、控制浏览器，都要通过这里暴露。
- model：底层模型本身。它可以换，但 harness 还在。
- context management：上下文管理。上下文太长怎么压缩，保留什么，丢弃什么，不该交给模型临场发挥。
- guardrails：护栏。比如最多允许多少步、多少条消息、多少钱、多久。
- agent loop：模型调用工具、观察结果、继续决策的循环。
- verify step：验证步骤。任务做完以后，要不要跑测试，要不要检查状态，要不要确认结果真的发生。
这套结构听起来朴素，但它实际上把“agent 是个会做事的模型”改写成了“agent 是一个被工程系统看管着的执行单元”。
这场分享最有价值的地方：他没有改 prompt
这场 talk 最漂亮的地方，不是定义，而是 demo。
Tejas 做了一个很小的浏览器 agent 任务：去 Hacker News，给第一条帖子点 upvote。
他故意用了一个比较弱的模型，GPT-3.5 Turbo。
原因也很直接：他想证明，很多时候你不需要先换更强的模型，也不需要先大改 prompt。你更应该先补 harness。
初始版本非常简单。
- 一个 prompt：去给帖子点赞。
- 一个浏览器会话：用 Playwright 打开页面。
- 一组工具：点击、导航之类。
- 一个最普通的 agent loop：模型不断决策，直到它说自己完成。
结果第一次运行就翻车了。
agent 打开 Hacker News，点了 upvote，然后跳到了登录页。接着它崩了。更糟的是，它还在日志里宣称自己成功完成了任务。
这其实就是很多 agent 系统最危险的时刻：不是“做不到”，而是“没做到但说自己做到了”。
Tejas 的判断很对。问题不在 prompt 不够狠，也不在 system prompt 里没塞登录说明。
真正的问题是，这个系统没有 verify，没有 guardrail，也没有一个对失败模式做确定性处理的外层。
harness 的第一步，不是让 agent 成功，而是先别撒谎
他加的第一层东西是 guardrails。
这层 guardrails 很简单，甚至可以说有点粗糙。
- 最多执行多少轮 iteration。
- 消息太多时就压缩上下文。
- 超过限制就终止。
这里有个细节很值得注意：他的 context compression 并不复杂，甚至可以说非常 naive。只保留 system prompt、user prompt 和最近两条消息，中间旧上下文全部裁掉。
这说明一个事实：harness 不一定要从复杂框架开始。很多时候，一个很笨但确定性的策略，已经比“什么都交给模型自己处理”强很多。
但真正扭转结果的，是 verify step。
他开始检查 trace，也就是 agent 执行过程中留下的工具调用历史，然后做确定性判断：
- 真的点到了 upvote 吗？
- 点完以后是不是其实跳到了登录页？
- 有没有出现未恢复的 login redirect？
- 有没有某个自动登录工具已经失败？
只要命中这些失败条件，系统就直接判定失败，不接受模型口头上的“我做完了”。
这是 harness 思维的核心：
把成功的定义，从模型的自述，改成系统的可验证事实。
很多团队做 agent 时，最大的问题恰恰是反过来的。他们相信“模型说 done 了”就是 done，结果生产事故全是从这里长出来的。
真正的提升，来自把脆弱环节抽离出 agent
在 demo 的最后一段，他又加了一层 login handler。
它做的事情非常典型，也非常重要：
- 每轮 agent loop 执行时，先检查当前页面 URL。
- 如果不在登录页，什么都不做。
- 如果落到了登录页，就由 harness 代码直接、确定性地注入凭证并提交。
- 登录完成后，再把控制权交还给 agent，并在消息队列里告诉它：“我已经替你登录好了，继续。”
这一步其实是整个 talk 的工程含义所在。
登录，本来是一个高风险、低价值、又高度确定的问题。它涉及 secret，涉及表单结构，涉及失败处理，也涉及安全边界。你完全没必要让模型自己在这里猜。
更一般地说，很多 agent 失败的地方，本来就不应该交给 agent 决策。
比如：
- 身份认证
- 权限判断
- 费用上限
- 敏感操作确认
- 任务完成校验
- 回滚和重试策略
这些部分越“硬”，越应该放进 harness，而不是埋进 prompt。
prompt 是软约束。harness 是硬约束。
前者影响模型倾向，后者决定系统边界。
Claude Code、Codex、Cursor，本质上都不只是 agent，而是 harnessed agent
Tejas 在演讲里提到一个很容易被忽略的点：像 Claude Code 这样的产品，表面看是 coding agent，实际上更准确的说法是 harnessed coding agent。
这个判断很重要，因为它解释了为什么“会写代码的模型”并不自动等于“能交付代码的系统”。
一个真正可用的 coding agent，至少要有这些东西：
- 文件系统读写工具
- shell 执行能力
- 上下文裁剪和压缩策略
- 最大步数或最大成本限制
- lint/test/verify 这样的收尾验证
- 对登录、凭证、环境变量、工作目录等现实约束的处理
这些能力如果没有被打包成一个运行时，模型再强也只是一个会续写文本的接口。
所以很多人问“为什么同一个模型在 API 里没那么神，在 Claude Code 里却像样很多”，答案常常不在模型本身，而在 harness。
同样的脑子，装进不同的身体，表现差别会非常大。
这其实也是成本优化问题
这场 talk 还有一个很实用的含义：harness 不是只为安全，也为成本服务。
如果 harness 足够好，你就能让便宜模型承担更多工作。
Tejas 明说了这一点。模型是非确定性的，但如果外面有一个好的 harness，你可以用更便宜的模型，甚至更小的开源模型，去做原本看上去需要大模型兜底的事情。
理由很简单。
系统是否可靠，不完全取决于模型单次推理质量，而取决于：
- 它能不能在正确的轨道上行动
- 出错时能不能被及时识别
- 关键步骤有没有硬编码的保底机制
- 结果有没有经过程序化验证
这跟传统软件工程其实很像。一个普通组件放进强约束的系统里，整体质量可以很高；一个很强的组件放进没有边界的系统里，也照样会出事。
从这个角度看，2025 年大家狂热谈 agent，下一步很自然就是谈 harness。因为只有进入这一层，AI 应用才开始像工程，而不只是演示。
我对这场分享的三个判断
先说结论。我觉得这场分享最有价值的，不是教你写一个浏览器 demo，而是把一个行业讨论重新拉回了工程常识。
第一，agent 的竞争会逐渐从 prompt 竞争转向 runtime 竞争
前一阶段，大家喜欢比较 prompt、system message、workflow design。
以后这些东西当然还重要，但真正拉开差距的，越来越可能是 runtime。
也就是：
- 工具怎么定义
- 状态怎么保存
- 上下文怎么裁
- 失败怎么识别
- 重试怎么执行
- secrets 怎么隔离
- verify 怎么落地
这些东西看起来没有 prompt 那么“聪明”，但它们更接近生产价值。
第二，很多所谓“模型不行”，其实是 harness 不行
一个任务失败，最常见的直觉是换更强模型。
这当然有时是对的，但并不总是对。很多任务失败，是因为系统没有告诉模型什么能做、做到哪一步必须停、出了什么错算失败、结果该怎么验证。
模型被扔进一个没有扶手的环境里，靠语言去补一切，当然会漂。
所以以后看 agent 产品，我会越来越关注两个问题：
- 失败时它怎么承认失败？
- 成功时它拿什么证明成功？
如果这两件事说不清，那多半只是个会演示的 agent，不是能托付流程的 agent。
第三，动态生成 harness 可能真是下一阶段
演讲最后，Tejas 抛了一个挺有意思的想法：未来也许不是先写死 harness，再让 agent 去做事；而是 agent 接到任务后，先为这个任务动态生成一层 harness，再进入执行。
他说这可能是 2027 年的方向。
这个判断未必会按年份发生，但方向我觉得是合理的。
因为任务的风险结构并不一样。买机票、改代码、查合同、跑财务数据、发生产命令，它们需要的 guardrail、secret handling、verify step 都不同。
最理想的状态，确实不是一套固定 harness 打天下，而是根据任务类型，自动拼装出合适的约束层。
这有点像今天大家说的 plan mode，但再往前一步：不是先出计划，而是先出边界。
这场 talk 也有它的边界
当然，这个分享也不是没有局限。
第一，它用的是一个很小、很受控的 demo。Hacker News 点赞这个任务，状态空间不复杂，成功标准也相对清晰。现实里的企业工作流，往往比这复杂得多。
第二，它把 harness 讲得很清楚，但对 harness 之间怎么复用、怎么抽象、怎么避免越来越重，没有展开。真实系统一旦做大，harness 自己也会变成需要维护的复杂软件。
第三，它强调确定性处理，这是对的，但确定性逻辑越多，开发者需要自己编码和维护的部分也越多。团队是否有足够的软件工程纪律，决定了 harness 最后会变成“可靠外壳”还是“新的脆弱层”。
不过这些边界不影响它的主判断成立：现在这个阶段，讨论 agent，不能只讨论模型能力，必须讨论模型外面的工程结构。
我的补充：harness 其实是在给 agent 补“机构”
如果把 LLM 看成一个会推理、会写字、也会猜的脑子，那 harness 更像是它的机构。
这里的机构，不只是工具接口，而是一整套约束、流程、权限、记忆和验收规则。没有这套机构，agent 再聪明，也更像一个临场发挥的人。它可能偶尔神来之笔，但没法稳定上班。
很多公司现在做 AI 应用，还停留在“把模型接到业务上试试”的阶段。接下来真正难的，不是再多接几个模型，而是把 harness 这层补起来。
谁先把这层补好，谁的 agent 才会从 demo 变成系统。
Tejas 最后说，2025 是 agent 之年，2026 可能是 harness 之年。
我觉得这个判断大概率会应验。不是因为 harness 这个词本身有多新，而是因为行业终于开始承认：真正难的部分，从来不在回答，而在约束、验证和交付。