Harness Engineering:当代码不再稀缺,什么才是工程的核心?

1306 字
4 分钟
0

过去十几年,软件工程一直在解决一个问题:

如何把代码写得更快、更好。

但随着大模型的出现,这个问题正在失效。

现在的现实是:

  • AI 可以写代码
  • 可以写很多代码
  • 甚至可以写百万行级别的系统

但真正的问题变成了:

如何让它持续写对?

这就是 Harness Engineering(驾驭工程)出现的背景。

一、从“写代码”到“设计环境”

一个很关键的认知转变是:

你不再直接写代码,而是设计一个让 AI 写代码的系统

这和传统开发完全不同。

过去:

  • 工程师 = 执行者
  • 写逻辑、修 bug

现在:

  • 工程师 = 系统设计者
  • 设计规则、约束、反馈机制

也就是说:

软件工程,正在从“生产代码”,变成“生产系统”。

二、AI 工程的三层演进

如果你回看过去两年,其实已经经历了三次明显的范式升级:

1. Prompt Engineering(提示工程)

最早大家在做的事情:

  • 怎么问问题更好?
  • 怎么写 prompt 更准?

本质:优化“表达方式”

但问题是:不稳定、不可复现、无法规模化。

2. Context Engineering(上下文工程)

然后大家意识到:

不是你说得不好,是 AI 知道得不够

于是开始:RAG、注入代码上下文、提供文档。

本质:优化“信息输入”

但问题仍然存在:AI 还是会犯错、会偏离目标、无法长期运行。

3. Harness Engineering(驾驭工程)

于是出现第三阶段:

不是改 prompt,也不是喂更多数据,而是设计整个运行系统

它关注的是:

  • AI 在什么规则下运行
  • 出错之后怎么办
  • 怎么防止系统变坏

三、为什么必须要 Harness?

因为 AI 有一些非常“工程不友好”的特性。结合实际经验(包括 Anthropic 等团队总结),有三种典型失败模式:

❌ 1. 一次性做完(One-shot)

AI 很喜欢一次性写完整功能,不拆步骤。

结果:上下文爆炸、逻辑混乱、无法维护。

❌ 2. 过早宣布完成

当系统稍微有点进展时,AI 很容易“觉得差不多了”,即使还有功能没实现、还有 bug。

❌ 3. 写完就当对了

AI 经常写完代码就认为是对的,但实际上没有端到端验证,测试不完整。

还有一个更隐蔽的问题:

AI 会复制代码库中的一切模式——包括错误的模式

这意味着:如果没有约束,它会指数级放大技术债。

四、Harness Engineering 在做什么?

可以用一句话概括:

不是让 AI 更聪明,而是让系统更可靠

它的核心是四个“护栏”:

1. 上下文工程(Context)

不是给 AI 更多信息,而是给“刚刚好”的信息。

关键实践:

  • AGENTS.md(入口说明)
  • 按需加载上下文
  • 动态检索

否则:上下文越多,反而越差(会挤掉任务空间)。

2. 架构约束(Constraints)

最核心的一点:

规则必须可以被机器执行

例如:

  • 分层依赖(不能乱调用)
  • Linter 自动检查
  • CI 强制阻断

重点不是“写规则”,而是把规则变成系统的一部分。

3. 反馈循环(Feedback Loop)

AI 最大的问题是:不知道自己错了。

所以必须构建:自动测试、自动验证、自动修复,形成闭环:

生成 → 检测 → 修复 → 再检测

甚至发展成:Agent Review Agent(智能体审智能体)。

4. 熵管理(Entropy Management)

这是很多人忽略但极其关键的一点。系统会自然变乱:代码腐化、文档过时、架构漂移。如果不处理,AI 会把这些问题放大。

所以需要:定期重构、自动清理、文档同步(Doc Agent)。

可以理解为:给系统做“垃圾回收”。

五、一个反直觉结论

很多人以为:AI 变强 → 系统就更好。

但实际情况是:

系统设计比模型能力更重要

甚至出现这种情况:不换模型,只优化 Harness,效果提升一个量级。

这也是为什么多个团队得出一致结论:

瓶颈不在模型,而在基础设施

六、工程师角色正在重写

这是最值得关注的变化。

未来的工程师不再是写最多代码的人,而是设计最强系统的人。

他们做的事情是:

  • 设计约束
  • 设计反馈
  • 设计流程
  • 设计演化机制

一句话总结:

从“写程序的人”,变成“设计程序如何被写出来的人”

七、一个非常形象的比喻

可以这样理解三层工程:

  • Prompt Engineering → 对马说话
  • Context Engineering → 给马地图
  • Harness Engineering → 修路 + 建护栏 + 设交通规则

关键在于:

不是让马更聪明,而是让它“不会跑偏”

八、最终总结

Harness Engineering 的核心思想可以压缩成三句话:

Prompt 决定你怎么说 Context 决定 AI 看什么 Harness 决定 AI 能不能长期做对

更深一层是:

AI 的能力是“潜力”,Harness 才是“现实生产力”。

📎 文章参考

版权声明

本文采用 CC BY-NC-SA 4.0 协议进行许可。转载请保留原文链接及作者。