飞哥数智谈，现居于济南，
AI提效、AI编程实践者，AI·Spring社群发起人，同时，担任TRAE Friends社区济南Fellow，致力于AI提效与AI编程落地，最近长期举办openclaw系列活动《养虾记》。
前几天有点太忙，Harness这个词看了很多次，但一直没有深入去了解。上周末终于抓时间把OpenAI、Anthropic、Adobe的相关文章和实践都看了一遍，写点东西理理思路。
说实话，看完之后我最大的感受是：这东西并不神秘，但它确实把一件我们都在做但又说不清的事，给说明白了。
一、为什么需要Harness？
要理解Harness，先得承认一个事实：AI大模型天生就不是为"工程化使用"设计的。它有三个很致命的"自带缺陷"：
1. 无状态：每次都从零开始
LLM没有记忆。每次新对话，它就像一个完全失忆的人，不知道之前做过什么。你跟它聊了两小时的架构讨论，下次开新对话就全没了。
2. 上下文腐烂：越聊越"健忘"
即使在同一次对话中，上下文窗口也是有限的。随着对话越来越长，早期的重要信息会被"挤压"到中间位置。
而研究表明，LLM对中间位置的信息关注度明显下降------这就是所谓的"Lost in the Middle"效应。
简单说，它读了100页文件，只记得开头和结尾，中间全忘了。
3. 自我感觉良好：做完就觉得做好了
Anthropic的研究发现了一个很有意思的现象：AI智能体倾向于"自信地赞扬自己的工作，即使质量平庸"。它可能写了一半的功能就宣布"完成了"，而不会主动去跑个测试验证一下。
这三个问题叠加在一起，导致了一个很尴尬的现象：没有Harness的AI，处理复杂任务时要么"一口气吃成胖子"，试图一次性全做完，结果半途而废；要么"假装完成"，看到部分进展就宣布大功告成。
所以Harness解决的核心问题就是：如何让AI在一个可控、可持续、可验证的环境中工作。
二、如何实现Harness？
说白了，Harness就是给AI套上"缰绳"。具体怎么做呢？我觉得可以拆成两个维度：引导和验证。
引导：解决"方向"问题
引导的核心是"信息架构"。不是给AI一本1000页的说明书，而是给它一张"地图"。
这背后的理论基础其实很简单：
注意力是稀缺资源。上下文窗口里的每一个token都在竞争AI的注意力，无关信息不只是"占地方"，而是会主动降低模型对关键信息的关注度。
所以Harness的信息设计原则是：常用规则始终加载，详细文档按需查阅。
具体来说，就是在代码仓库中维护一套结构化的知识体系：
- 一个精简的入口文件告诉
AI"项目长什么样、文档在哪里、当前进度如何"； - 详细的架构文档、设计文档、执行计划则放在子目录中，让
AI在需要时自己去挖掘。
这其实和我们设计产品的思路一样：首页要简洁，详情页要可达。只不过现在的"用户"是AI。
验证：解决"质量"问题
如果说引导是"指路"，验证就是"红绿灯"。
验证的理论基础是：不信任自我报告，只信任外部反馈 。AI的自我评估是不可靠的，所以必须把"完成"的判断权从AI手中拿走，交给机制化的流程。
最基础的做法是"测试门禁"：每次AI完成一个功能，自动跑一遍测试，通过才算完成。
更进一步是"独立评估"：用另一个角色来审查生成结果，因为"别人审稿比自己审查更能发现问题"这个道理对AI同样成立。
最高级的形式是"机械化执行"：通过Linter、结构化测试、代码审查钩子等工具，让正确行为"很容易做"，错误行为"很难做"。
三、具体怎么做呢？
好像有些理解了，但又好像还是懵的。
那我们再带大家来看看头部企业具体如何做的。
OpenAI："地图"思维
OpenAI的核心发现是：给AI"一本1000页的说明书"是失败的，正确的做法是给一张"地图"。
他们用约100行的AGENTS.md作为入口，告诉AI项目架构、文档位置和当前进度，详细内容放在docs/目录按需查阅。同时用自定义Linter强制执行架构规范，让AI"想犯错都难"。
结果：3人团队，5个月，约100万行代码，零人工编写，几乎所有审查都变成了"AI审查AI"。
Anthropic："反馈回路"思维
Anthropic更关注如何让AI在长时间工作中不跑偏。
他们的解法是"三智能体架构"：规划器拆任务、生成器写代码、评估器独立审查，让评估器"多怀疑"。
核心洞察是：让独立角色去批评，比让生成者自己检查自己更有效，这一点和"开发测试分离"的原则如出一辙。
Adobe："环境审计"思维
Adobe提出了"失败→信号→应对"框架。
AI改错文件说明缺上下文，引入Bug说明缺自动测试，做重复工作说明缺状态持久化。每个失败都是一个信号，告诉你环境哪里还不够好。不是换模型，而是补环境。
结语
"驾驭工程"这个名字让我想起来之前的两个工程：提示词工程、上下文工程。
| 阶段 | 做什么 | 本质 |
|---|---|---|
| 提示工程 | 优化一句话的表达 | 一段结构化的指令 |
| 上下文工程 | 优化一段信息的组织 | 一段分类的结构化指令 |
| 驾驭工程 | 优化一个系统的设计 | 一段各司其职的结构化指令 |
仔细想想，三者做的事情本质上是一样的：都是在解决"人和AI之间的信息传递"问题，只是粒度在不断细化。
以上就是我关于 Harness Engineering 的一些初步思考，欢迎大家留言交流。