Harness Engineering 的本质：给智能一套能交付的工程外壳

最近我越来越觉得，讨论 Agent 的时候，不能只盯着模型本身。

模型当然重要。没有足够强的理解、推理和代码能力，后面的工程结构都很难发挥价值。

但只要 Agent 开始碰真实系统，问题就会变得不一样。

它不再只是回答问题，而是会读文件、改代码、跑命令、调 API、写数据库、开浏览器、触发部署，甚至把任务拆给别的 Agent。到这一步，模型已经不是一个“给建议的人”了，它开始参与执行。

这时候真正危险的，往往不是模型不会做。

而是它很敢做。

所以我现在对 Harness Engineering 的理解很简单：

Harness Engineering 的本质，不是让模型变聪明，而是给模型搭一套能干活、能验收、出事能兜住的工程外壳。

Prompt 解决的是“怎么让模型说得更对”。

Harness 解决的是“怎么让模型在真实系统里做事，而且别把事情做飞”。

这中间差得挺远。

真正的问题不是回答，而是行动

如果只是聊天，问题其实没有那么重。

你问模型一个问题，它答错了，你最多重新问一次。它胡说八道，你关掉页面就行。

但 Agent 不是这样。

用户说一句：

帮我修一下这个测试。

一个裸奔的 Agent 可能会直接读代码、猜原因、改文件，然后告诉你：修好了。

听起来挺爽。

但你稍微追问一下就会发现问题一堆：

• 它真的跑测试了吗？
• 跑的是哪个测试？
• 改了哪些文件？
• 有没有顺手改坏别的地方？
• 失败以后是继续修了，还是假装成功了？
• 这个修改能不能回滚？
• 用户到底有没有批准它动这些文件？

这些问题没有一个是“模型聪不聪明”能单独解决的。

模型再强，也需要一套工程结构把它包起来。

这套结构，就是 Harness。

Harness 更像安全带、仪表盘和验收流程

我觉得可以把 Harness 理解成 Agent 的安全带、仪表盘和验收流程。

安全带负责约束它别乱来。

仪表盘负责告诉你它现在在干什么。

验收流程负责判断它到底有没有把事情做完。

一个真正能用的 Agent Harness，至少要回答几个问题。

它能看到什么上下文？

不是所有东西都应该塞给模型。系统提示词、历史消息、RAG、memory、tool result、summary，哪些是稳定前缀，哪些是临时状态，哪些应该被压缩，这些都会影响 Agent 的判断、成本和稳定性。

它能调用哪些工具？

读文件和删文件不是一个风险级别。搜索代码和执行危险命令更不是一回事。工具必须有权限、沙箱、超时、重试、输出截断和审计。

它怎么拆任务？

复杂任务不能只靠模型一口气往下冲。Plan 模式、DAG、workflow、subagent、状态机，本质上都是在给模型一个更稳定的执行轨道。

它怎么证明自己做完了？

说“修好了”不算。测试结果、lint、typecheck、diff、日志、评测报告，这些才算证据。

它失败时是什么样子？

这是我现在越来越看重的一点。显式失败其实比隐式失败仁慈。一个 Agent 最危险的状态，不是报错，而是表面成功。

状态是 ok，流程也跑完了，但真正该交付的结果没到。

这种情况最伤信任。

为什么最近大家开始重视 Harness

因为模型能力已经强到可以“闯祸”了。

以前模型弱的时候，我们主要担心它不会做。

现在模型强了，问题变成：它敢改文件，敢跑命令，敢自己推理用户意图，也敢把半懂不懂的东西包装成结论。

这时候你会发现，真正决定一个 Agent 能不能长期用的，不是某一次 demo 多惊艳，而是它出问题时还剩下多少秩序。

我做 Orca 的 DeepSeek 缓存优化时，就很有这个感受。

表面上是在优化 prefix cache 命中率，实际上一路撞下来，问题根本不只是“缓存策略”。你会碰到 system prompt 里混进动态信息、summary 调用不计入 usage、压缩后继续 miss、compaction storm、wire prompt 和内存结构不一致。

这些都不是模型智商问题。

它们是 Harness 问题。

也就是：你怎么组织上下文，怎么记录状态，怎么统计真实成本，怎么判断是否触发压缩，怎么让每一次 API 调用都能被解释。

再比如做多 Agent 流水线，最难的也不是“让 PM Agent 写 PRD，让 Architect Agent 写架构”。

这种 demo 很容易。

真正难的是：PRD 写完以后谁判断它够不够清楚？架构和任务拆解不一致怎么办？Dev 做完以后 QA 怎么验？部署阶段能不能跳过？每个节点的状态谁说了算？中途失败以后，从哪里恢复？

这些东西加起来，才是 Harness Engineering。

它工程化的不是智能本身

它工程化的不是智能本身，而是智能周围的秩序。

换句话说：

模型负责产生可能性，Harness 负责把可能性变成可交付结果。

这里面最关键的不是某个单点能力，而是几条边界。

模型和工具的边界。

模型可以建议调用工具，但工具执行必须受权限和策略约束。

计划和执行的边界。

想法可以发散，执行必须收敛。

状态和结果的边界。

任务跑过，不代表任务完成。执行成功，不代表交付成功。

自动化和人类接管的边界。

Agent 可以自动做很多事，但关键动作要让人能看懂、能暂停、能回滚。

这些边界一旦糊掉，系统就会进入一种很危险的状态：

每个局部看起来都合理，但组合起来就是不可靠。

这也是为什么我现在看 Agent 项目，已经不太只看“支持多少工具”“能不能多模型”“上下文多长”这些指标。

我更关心：

• 它有没有权限模型？
• 有没有 trace？
• 有没有失败语义？
• 有没有验证闭环？
• 有没有恢复能力？
• 有没有把模型输出和真实执行结果区分开？

这些东西听起来没那么性感，但它们决定一个 Agent 是玩具还是系统。

和 Prompt Engineering、Context Engineering 的区别

如果硬要区分，我会这么看。

Prompt Engineering 是教模型怎么说话。

Context Engineering 是决定模型该看什么。

Harness Engineering 是让模型在真实环境里安全、稳定、可验证地做事。

前两个更多发生在模型调用前后。

Harness 则包住整个执行生命周期。

从用户输入开始，到上下文装配、工具调用、状态记录、权限判断、测试验证、失败恢复、结果交付，全部都算。

所以它不是某个 prompt 技巧，也不是某个框架名。

它更像一套工程方法论。

如果你只是做一个聊天机器人，Harness Engineering 可能显得有点重。

但只要你的 AI 开始碰真实系统，比如代码仓库、数据库、CI、浏览器、服务器、用户账号，那 Harness 就不是可选项了。

因为这时候问题已经不是：

模型能不能做？

而是：

它做的时候，我能不能信？

我现在对 Agent 的判断也越来越简单：

能力决定上限，Harness 决定下限。

上限高，demo 会很好看。

下限稳，系统才敢长期用。

所以 Harness Engineering 的本质，就是把不稳定的智能，放进一套有边界、有证据、有恢复能力的工程系统里。

这件事不酷，但很关键。