飞哥数智谈，现居于济南，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 之间的信息传递"问题，只是粒度在不断细化。

以上就是我的一些思考，欢迎大家留言交流。