为什么 Harness 最近突然火了？
它到底是什么
Harness Engineering 不是多写几句 prompt，也不只是给 AI 配几个工具。它本质上是在设计一整套让 AI 稳定工作的开发流程：给它上下文，接上工具，写清规则，保留状态，观察执行，出错后还能继续恢复。模型只是大脑，Harness 才是让这个大脑真正进入项目、持续干活的工作台、护栏和反馈闭环。没有这套东西，模型再强，也很容易停留在“一次回答很好看，但一进真实流程就不稳定”。
你为什么现在就得学
因为开发已经开始从“人写代码，AI偶尔帮一下”，走向“人搭系统，AI持续参与执行”。如果你还停留在旧思路里，把 AI 当聊天框、问答器、代码补全器，那套方法很快就会落后。接下来真正拉开差距的，不是谁更会问问题，而是谁先学会把 AI 接进文档、代码、测试、日志和协作流程里，让它稳定复现、连续接力。Harness Engineering 火，不是因为概念新，而是因为旧方法已经开始不够用了。
我理解的 Harness，有 5 个关键点
下面我结合 OpenAI 那篇 Harness Engineering，再加上我最近看到的一些项目，聊聊我自己的理解。
1. 可见性
第一点，我觉得就是可见性。
这里至少有两层可见性。
一层是项目本身的可见性。也就是说，AI agent 能看到你当前项目的日志、运行状态、报错信息、任务结果等等。
另一层是业务的可见性。也就是说，AI agent 不只是知道代码怎么写，还要知道这个业务为什么这么做。
为什么要加这个 feature？为什么这个需求这么改？为什么这个边界不能碰？
这些信息很多时候并不只存在于正式文档里，它们也会出现在群聊、会议记录、聊天软件、零散讨论里。
这些内容其实都很重要。如果这些东西没有被记录下来、没有被整理出来，AI 就很难真正理解你的业务。
说白了就是：你不给 AI 看，它就只能靠猜。
2. 上下文管理
第二点，我觉得是上下文管理。
context window 这件事，几乎是所有 agent 系统都会碰到的问题。
最典型的一个例子，就是 agents.md 这种文件怎么组织。
一开始很多人会把所有信息都塞到一个文件里，觉得这样最省事。
但后面会发现，东西一多，AI 反而不知道重点是什么，也不知道该索引什么。你给得越多，它不一定用得越好。
所以更合理的一种方式，其实是：
agents.md只负责做索引- 具体内容拆到
skill、文档库、reference、架构说明、feature 文档、计划文档里 - 需要的时候再按需加载
这样做的本质，是让上下文从“堆料”变成“检索”。
文档也需要垃圾回收
这里还有一个特别重要但容易被忽视的点，就是文档本身也需要持续整理。
因为项目一直在变，代码会膨胀，文档也会膨胀。如果文档长期不维护，它就会慢慢变成 AI 的上下文污染源。
所以我很认同一种做法：定期做索引重建、文档整理、知识淘汰、技术债处理。
这件事其实很像团队里的知识管理。不是你把资料存下来了就算完，而是要持续清理、持续更新、持续提炼。
3. 规则化
第三点，我觉得是规则化。
大型项目如果没有规范，很容易失控。AI 加进来之后，这个问题只会更明显。
所以你需要明确告诉它：
- 这个项目是干什么的
- 这个项目应该怎么写
- CI/CD 流程是什么
- 前端的职责是什么
- 后端的职责是什么
- UI 规范是什么
- 编码规范是什么
比如前后端协作时，前端只应该负责 UI 层，后端才负责接口。这个边界一定要讲清楚。
不然 AI 为了图快，真的可能直接把职责写乱。
Prompt 规则还不够
但只靠 prompt，其实还不够。
因为 prompt 说到底还是“软约束”。
真正可靠的系统，一定还需要“硬约束”。
比如：
- 前端有 lint
- 后端有静态检查
- 有测试
- 有代码质量检测
这些规则不是靠模型自觉遵守，而是靠程序强制执行。
所以真正靠谱的系统，不会是“全靠模型听话”，而是“模型外面还有一层规则网”。
4. 个人 Context 管理的启发
我最近还看了鸭哥一个项目，叫 context-infrastructure。
这个项目给我的启发很大，因为它不是团队级的，而是个人级的。
它会去记录一个人过去很长时间的 context，比如录音、会议记录、对话记录、生活和工作里的各种信息，然后再去做每日索引和提炼。
同时它还会做多级记忆分层，比如：
L1放最核心的入口信息，比如agents.mdL2放技能和按需调用的信息L3放更详细、更深层的文档背景
这个思路特别有意思。
因为它说明了一件事：Harness 不只是团队工程问题，它也可以是个人知识管理问题。
如果一个人能把自己的长期 context 管理好，AI 对他的理解深度会完全不一样。
5. 一个自动执行的案例
我还看到了 Anthropic 的一个案例，叫 autonomous-coding，大概意思是：让 AI 在几个小时里自动持续写代码，把一个产品逐步做出来。
它的做法大致是用两个 agent：
- 一个 agent 负责初始化，先看产品文档、理解特性、生成计划 JSON
- 另一个 agent 负责执行，按 JSON 一个一个 feature 往下做
每做完一个特性，就把状态更新掉，然后开新的 session，继续读同一个状态文件，知道下一个任务是什么。
这个案例特别能说明 Harness 为什么重要。
因为当 AI 不再只是回答一个问题，而是要连续几个小时推进一件复杂工作时，你马上就会发现：
- 没有状态管理，不行
- 没有上下文分层，不行
- 没有执行记录，不行
- 没有明确规则，不行
这时候 Harness 就不是锦上添花，而是前提条件。
最后总结一下
如果要我用一句话总结 Harness Engineering，我会这样说：
它研究的，本质上是怎么给 AI agent 搭一套真正能工作的环境。
这个环境至少包括：
- 可见性
- 上下文管理
- 规则化
- 跨 session 的状态延续
- 执行追踪和反馈回路
所以它最近会火，我觉得非常正常。
因为 AI 现在正在从“会说”走向“会做”，而所有“会做”的系统，最后都绕不开工程化。
如果你接下来想认真把 AI 用进自己的项目、团队和流程里，Harness 这件事，基本是绕不过去的。
