为什么 Harness Engineering 最近突然变热了？
最近一段时间，Harness Engineering 这个词在 AI Coding Agent 圈子里越来越热。
如果只看字面，它很容易被理解成一个新的技术名词，或者某种旧概念的重新包装。但我越来越觉得，它的升温并不是因为大家突然喜欢发明新词，而是因为 Agent 开始进入更真实的工程环境之后，很多过去被掩盖的问题都集中暴露了出来。
过去大家聊 Agent，更多在聊这些事情：
- 模型能力够不够强
- Prompt 怎么设计
- Tool Calling 怎么接
- Memory 怎么做
- Planning 怎么设计
- Workflow 怎么编排
但当 Agent 真正开始接触代码仓库、执行命令、修改文件、运行测试、提交 PR 之后，问题的重心就变了。
这时候你会发现，真正让一个 Agent 难以落地的，往往不是它“会不会想”，而是它：
- 运行在哪个环境里
- 拥有什么权限
- 执行过程能不能被观察
- 失败之后能不能恢复
- 改动是否可追踪、可回放、可审计
这些问题，单靠更强的模型并不能解决。它们本质上是执行系统工程的问题，而 Harness Engineering 对应的，正是这层能力。
什么是 Harness Engineering？
如果要给它一个足够工程化的定义，我会这样说：
Harness Engineering，就是为 Agent 提供可控、可观测、可审计、可恢复执行环境的一整套系统工程。
这里的 harness，你可以把它理解成 Agent 和真实世界之间的执行中间层。
它不是模型本身，也不是某一个具体工具。它更像是 Agent 在执行层面的 runtime、control plane 和 safety layer 的组合。
对于 Coding Agent 来说，模型负责的是：
- 理解任务
- 规划步骤
- 生成代码
- 做推理和决策
而 harness 负责的是：
- 决定它在哪儿执行
- 决定它能做什么、不能做什么
- 记录它做了什么
- 在失败时提供恢复路径
- 让人类能够接管、审核和纠错
换句话说，模型决定“想做什么”，harness 决定“能怎么做、做到哪一步、出了事怎么办”。
这个分层很重要。因为在很多 Agent 讨论里，大家习惯把“会调用工具”也归到“Agent 很强”的范畴里，但真正到了生产环境，光会调工具远远不够，关键是你是否有一层稳定的执行底座把这些能力承接起来。
为什么它现在才开始变热？
我觉得原因至少有五个。
1. 模型能力变强之后，瓶颈从 reasoning 转向 execution
前一阶段大家最关心的问题是：模型到底能不能理解复杂任务，能不能在多步推理里保持稳定，能不能生成还像样的代码。
现在这个问题虽然没有完全解决，但已经不再是唯一瓶颈了。很多模型已经足够强，至少能在相当多的软件任务里完成“理解—规划—执行建议”这一套流程。
于是新问题浮出水面：
- 为什么第一次跑得通，第二次就挂了？
- 为什么改动成功了，但仓库也被顺手搞脏了？
- 为什么 Agent 明明知道要做什么，但执行半路卡死？
- 为什么用户总是不放心让它直接动代码？
这些都不是 reasoning 的问题，而是 execution 的问题。
2. 大家开始从 Demo Agent 走向生产 Agent
做一个 Demo Agent 并不难。你可以把模型、工具、少量 prompt glue code 拼起来，再加一个会话 UI，看起来就已经很像一个完整产品了。
但 Demo Agent 和生产 Agent 最大的差别，不在于“能不能跑通一次”，而在于：
- 能不能稳定重复执行
- 能不能控制风险边界
- 能不能让团队排查问题
- 能不能在复杂环境里长时间工作
一旦进入企业环境，原来那些“反正先跑起来”的部分，都会变成必须认真设计的问题。Harness Engineering 的热度，本质上就是 Agent 从 demo 阶段走向系统阶段的表现。
3. Coding Agent 天然是高风险执行系统
和纯聊天型产品不同，Coding Agent 不是只输出文字。
它会：
- 读你的仓库
- 改你的文件
- 运行 shell
- 安装依赖
- 调用浏览器
- 跑测试
- 可能还会推送 commit、发起 PR
这意味着它面对的是一个真实、脆弱、带状态的执行环境。哪怕模型输出再聪明，只要执行环境设计得差，它依然可能：
- 污染工作区
- 覆盖不该改的文件
- 卡在不可恢复的中间状态
- 在权限边界外误执行危险操作
所以对 Coding Agent 来说，harness 不是锦上添花，而是基础设施。
4. 用户对“可控感”的要求显著上升
很多时候，用户对 Agent 的担忧并不是“它不够聪明”，而是“它会不会乱来”。
一个很有意思的现象是：哪怕 Agent 的成功率已经不错，用户也不一定愿意让它全自动执行。因为用户真正需要的是一种可控感：
- 我知道它现在在做什么
- 我知道它为什么这么做
- 我知道它接下来会不会动危险区域
- 我知道哪里需要我确认
- 我知道出问题了怎么停下来
这不是模型参数的问题，而是产品和运行时设计的问题。Harness Engineering 恰好就是提供这种可控感的关键层。
5. 产品竞争开始从“会不会用工具”转向“谁的执行系统更强”
Agent 的第一阶段竞争，大家比的是：
- 模型接得多不多
- Tool Calling 做得灵不灵
- Prompt 调得准不准
- UI 体验顺不顺
但随着基础能力逐渐拉平，真正的差异会越来越落在更深层的系统能力上：
- 谁能提供更稳定的执行环境
- 谁能更好地管理长任务和异步任务
- 谁能让人机协同更顺滑
- 谁能提供更强的可观测性和审计能力
- 谁能把 Agent 真正接入团队日常工作流
这也是我觉得 Harness Engineering 会持续升温的原因。它不是一个阶段性热点，而很可能会成为下一轮 Agent 产品竞争的核心变量之一。
一个好的 Harness，需要解决什么问题？
如果从工程角度拆分，我觉得一个成熟的 harness 至少要覆盖下面五个方面。
1. 隔离性
Agent 需要自己的工作空间和边界。
比如：
- 独立 worktree
- 容器化执行环境
- 临时沙盒目录
- 对文件系统和网络的范围限制
隔离性的意义不只是安全，更是为了可重复性。没有隔离，Agent 的执行会越来越依赖历史状态；有隔离，才能更接近“每次都在一个已知环境里开始”。
2. 可观测性
你必须知道 Agent 做了什么。
这包括但不限于：
- 执行了哪些命令
- 读了哪些文件
- 改了哪些文件
- 调用了哪些工具
- 当前停在哪个步骤
- 最近一次失败发生在哪里
如果这些信息拿不到，Agent 一旦出问题，排查体验会非常痛苦。很多 Agent 产品之所以让人缺乏信任，不是因为失败本身，而是因为它失败得像个黑盒。
3. 可控性
可控性不是“全放开”或者“全禁掉”二选一，而是更细粒度的授权和介入能力。
比如：
- 哪些命令可以自动执行，哪些必须确认
- 哪些目录可写，哪些只能读
- 哪些外部服务允许访问
- 哪一步执行需要人工审批
- 用户能否在中途接管或修改计划
如果没有这层控制，Agent 要么太弱，要么太危险。真正可用的产品，一定要在“自动化效率”和“人类监督”之间找到平衡。
4. 可恢复性
长任务一定会失败，也一定会中断。
可能是因为：
- 网络断了
- CLI 断开了
- shell 卡住了
- 模型超时了
- 用户中途介入了
- 外部工具返回了不一致结果
这时候最糟糕的情况，是整个任务只能从头再来。
成熟的 harness 需要提供：
- 任务状态持久化
- 断点恢复
- 会话恢复
- 中间产物保留
- 人工接手后的继续执行能力
只有这样，Agent 才能处理真正复杂的、持续时间长的工作。
5. 可审计性
当 Agent 开始被团队使用时，“它做了什么”会变成一个管理问题，而不仅是一个调试问题。
可审计性意味着：
- 关键操作有记录
- 代码变更有来源
- 权限升级有痕迹
- 外部访问有轨迹
- 人工确认节点可回看
这对于企业场景尤其重要。不是所有问题都能靠“相信 Agent”解决，很多时候需要的是“可以证明它是怎么做的”。
Harness 不等于 Tool Calling
我觉得这是最容易混淆的一点。
很多人第一次听到 Harness Engineering，会下意识把它理解成“更复杂的工具调用系统”。这并不完全错，但也远远不够。
Tool Calling 关注的是能力接口
Tool Calling 主要解决的是这些问题：
- 模型能调用哪些工具
- 调用参数怎么传
- 工具返回什么结果
- 结果如何反馈进上下文
它本质上是在解决“能力暴露”和“能力消费”的问题。
Harness Engineering 关注的是执行底座
Harness Engineering 解决的是另外一层问题：
- 这些工具运行在什么环境里
- 怎么隔离权限和状态
- 多个工具如何形成稳定流程
- 长任务、中断、恢复怎么处理
- 人类如何观察、确认和接管
- 执行链路如何被记录和审计
所以如果要用一句话概括两者的区别，我会这样说：
Tool Calling 是能力接口，Harness Engineering 是执行底座。
前者回答的是“Agent 能调什么”，后者回答的是“Agent 调完之后，整个系统怎么稳地跑下去”。
这也是为什么很多只靠 Tool Calling 拼起来的 Agent，在 demo 时看起来不错，但一旦进入真实工作流，就会暴露出大量不稳定性问题。
Harness 也在重新定义 Agent UX
还有一个我觉得经常被低估的点：Harness Engineering 不只是 infra 问题，它其实也直接塑造了 Agent UX。
以前我们谈 Agent UX，讨论的大多是这些：
- 对话框体验
- 输出流式展示
- 思考链可视化
- 工具调用的结果展示
但对于 Coding Agent 来说，真正关键的用户体验往往是另一组问题：
- 我能不能清楚看到它现在在做什么？
- 我能不能判断它是否卡住了？
- 我能不能快速知道它改了哪里？
- 我能不能方便地在关键节点接手？
- 我能不能放心让它继续往下跑？
这时候你会发现，用户体验的核心已经不只是“对话顺不顺”，而是“执行过程是否透明、稳定、可接管”。
也就是说，Harness Engineering 既是基础设施问题，也是产品体验问题。
我的一个判断：Harness 会成为下一阶段 Agent 的基础设施层
如果说第一阶段的 Agent 竞争，更接近模型能力竞争；第二阶段，更接近 workflow、tool use 和产品交互竞争；那我觉得下一阶段，很可能会越来越像 runtime / infra / platform 能力竞争。
原因很简单。
真正决定一个 Agent 能不能走进生产的，通常不是它在 benchmark 上多了几点，而是它是否具备这些条件：
- 能进入真实仓库工作
- 能安全执行 shell、browser、MCP、API
- 能在长任务里保持状态
- 能与人工顺滑协作
- 能被团队观察、管理和审计
而这些能力的核心承载层，恰恰就是 harness。
所以我会倾向于把 Harness Engineering 视为 Agent 时代的一层新基础设施，而不是某个边缘优化点。
写在最后
Harness Engineering 最近变热，本质上说明了一件事：
Agent 行业正在从“会不会做 Demo”转向“能不能把执行系统做扎实”。
当模型能力逐渐变成基础能力之后，真正拉开差距的，会越来越是这些看起来不那么性感、但极其关键的工程层问题：
- 运行时设计
- 权限体系
- 可观测性
- 恢复机制
- 审计能力
- 人机协同接口
换句话说，Agent 产品正在从“模型驱动”走向“系统驱动”。
而 Harness Engineering 的升温，正是这个阶段变化最直接的信号之一。
如果说 Prompt、Memory、Tool Calling 解决的是 Agent “能不能想”和“能不能调用能力”，那么 Harness Engineering 解决的，就是它最终能不能被安全、稳定、长期地执行。
我觉得，这不会只是一个短暂热点。它很可能会成为未来几年 AI Coding Agent 产品里最值得认真建设的一层。