如果让我独自写一个一百万行的代码项目，我根本做不到。即使借助 AI，这个过程依然痛苦——我需要把一长串需求塞进文件让 AI 理解，还要在编写过程中深度参与、不断纠错，指挥 AI 写代码本身就是一件麻烦事。 最近 OpenAI 发表了一篇文章，详述了他们如何用 AI 编写了一个百万行代码的项目（99% 由 AI 编写）。文中提出了一个概念：Harness Engineer——设定规则，通过约束来规范 AI 行为，使其按预想开展工作。 促使我深入理解这个概念的，是 OpenClaw 执行任务时的随机偏差。受挫之下，我花了好几天来研究它。但说实话，我不太喜欢 "Harness Engineer" 这个名称，因为它容易把问题简单化，仿佛只是一种"约束"。我所理解的 Harness Engineering 远不止约束——更通俗地讲，是通过各种工程方法，对抗 AI 工作过程中的非合理行为。可以预见的是，随着 AI 模型能力提升、非合理行为减少，这个概念本身也会逐渐过时。 在讨论解决方案之前，首先要能描述问题。因此，我先梳理 AI 的几类典型非合理行为，再针对性地介绍工程化的应对方法。
一、知识污染：AI 会随机忽略长串知识中的某部分 随着任务知识增加，AI 容易遗忘其中部分内容。把大量任务和要求一股脑塞给 AI 是不现实的。解决思路是建立渐进式披露的知识库：将知识拆分，按需去寻找。比如有任务 1~100，与其把全部任务塞进一个文件让 AI 一次读完，不如拆成 100 个文件，AI 执行哪个任务就只加载对应文件。整体灌输容易产生知识污染——指望 AI 逐一完成任务并清晰区分边界，是不现实的。拆分是对抗知识污染的有效手段。
二、过度自信：AI 认识到错误后会立即改正 这导致在单个 agent 的视角里，它似乎永远在做正确的事。应对方法是将 agent 拆分：拆成计划者、执行者、验证者，通过分工对抗 AI 的过度自信。具体拆分粒度视工作复杂度而定： - 简单工作：无需拆分 - 中等复杂度：计划者（兼验证者）+ 执行者 - 高复杂度：计划者 + 执行者 + 验证者 （拆分没有固定范式，一切按实际需求来。）
三、能力衰减：上下文过长导致 AI 准确度下降 有研究表明，当上下文长度超过最大长度的 40% 时，AI 准确度会大幅下降。对抗这个问题的办法是定期销毁长期工作的 agent，换上新的 agent，并用文档驱动工作——知识不应只存在于 agent 的上下文中，还要落在文档里。
四、盲区：AI 看不见的东西就不存在 如果 AI 没有察觉错误的发生，就不会主动纠正。因此需要构建充分的反馈机制：环境反馈、结果反馈、操作反馈，让 AI 始终能"看到"自己的行为及其后果。
五、行为失范：AI 无法始终规范自身行为 在代码编写中，尽量用机械机制替代 AI 的记忆：用git追踪修改，用ruff等工具规范代码风格，用权限控制agent可以改动的文件，用硬约束来保证行为的一致性和正确性。
六、熵增：项目迭代中，小偏差在验证者忽视的地方积累 这些不易察觉的偏差日积月累，最终会导致整体偏离目标。对抗熵增的办法是引入独立审查者，定期审视项目全局，修正分散在各处的积累错误。
综上所述，Harness Engineering 不是一套固定的规则，也不是一个标准的范式，而是一组对抗 AI 非合理行为的工程实践的集合。它随模型能力变弱而加强，随模型能力变强而变弱，随场景变化呈现不同形态。与其说它是一个概念，不如说它是一组用工程思维消除不确定性的方法——问题出现了，就去解决它，持续迭代，没有终点。
