前几天终于抽出时间，把OpenAI、Anthropic、Adobe几家关于Harness的相关文章和实践都仔细梳理了一遍。说实话，看完之后最大的感受是：这一概念并不神秘，但它确实把一件我们都在做、却又难以清晰表述的事情，给讲明白了。

一、为什么需要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之间的信息传递”问题，只是粒度不断细化。