Harness Engineering 不是噱头，但也不是终局：为什么 OpenAI 和 Anthropic 都在补这层系统

Harness Engineering 不是噱头，但也不是终局：为什么 OpenAI 和 Anthropic 都在补这层系统

摘要（先看结论）

• Harness Engineering不是在发明一种全新的 AI 技术，而是在回答一个更现实的问题：模型已经够强了，为什么还是经常做不成事。
• 如果说Prompt Engineering研究的是“怎么问”，Context Engineering研究的是“给它看什么”，那Harness Engineering研究的就是“让它在什么系统里干活，才能稳定交付”。
• 这个概念之所以最近突然变热，不是因为行业又造了个新词，而是因为大家开始大规模把 Agent 用到真实开发任务里，结果发现真正拖后腿的，往往不是模型上限，而是系统支撑太薄。
• OpenAI 的信号是：当文档、规则、验证、可观测性没搭好时，更强的模型也会走偏、返工、重复犯错。
• Anthropic 的信号是：一旦任务变长、上下文变重，单 Agent 很容易一口气做乱；把规划、生成、评估拆开，稳定性才会明显上升。
• 它不是终局，因为很多“替模型思考”的脚手架，未来确实会被更强模型吃掉；但工具、权限、验证、状态管理、可观测性这些系统基础设施，不会消失。
• 对工程师来说，这意味着工作重点正在从“亲手写每一行代码”转向“设计让 Agent 不容易翻车的运行系统”；对管理者来说，这意味着投入重点不该只是买更强模型，而是补齐兑现能力。

1. 为什么这个词突然火了

过去两年，大家对 AI 工程的关注点其实经历了三次外扩。

• 第一阶段，重点是Prompt Engineering。核心问题是：怎样提问，模型更容易答对。
• 第二阶段，重点是Context Engineering。核心问题是：怎样把历史、知识、工具说明、项目约束组织进上下文。
• 到了现在，焦点开始转向Harness Engineering。核心问题变成了：就算模型看到了资料、也听懂了要求，为什么还是会跑偏、烂尾、做完不验、改了又错。

这个变化背后，不是概念营销，而是使用深度变了。

当大模型只做单轮问答时，提示词和上下文已经够用。可一旦它开始接真实任务，比如改仓库、跑测试、修 UI、写文档、连续做几个小时的开发工作，失败模式就不是“这句话没答好”这么简单了。

更常见的问题会变成：

• 信息太多，模型抓不到重点。
• 文档过时，模型学到的是旧规则。
• 任务太长，做到一半忘了自己原本要做什么。
• 做完了却不验证，直接宣布完成。
• 同一个错误重复发生，因为系统里没有把失败经验变成下一轮约束。

也就是说，模型能力到了一个临界点之后，差异不再只来自模型本身，而开始明显转移到模型外面的系统设计上。

2. 先把三层关系讲清：Prompt、Context、Harness

最容易把人绕晕的地方，是很多人把这三个词当成互相竞争的新名词。其实不是。

更准确的理解是：它们描述的是同一个问题上，控制范围不断外扩的三个层次。

Prompt ⊂ Context ⊂ Harness Prompt：怎么问 Context：给它看什么 Harness：让它在什么系统里干活，并确保干成

如果再翻成更接地气的话：

• Prompt Engineering是在调一句话。
• Context Engineering是在调一份输入包。
• Harness Engineering是在调整套运行环境。

可以再用一个更贴近工程直觉的类比：

模型 = 发动机 Prompt = 你踩油门的方式 Context = 导航、路况、地图 Harness = 方向盘、刹车、仪表盘、限速器、故障报警、维修流程

发动机再强，如果没有方向盘和刹车，你很难把车稳定开到目的地。

所以Harness Engineering的重点从来不是“让模型更聪明”，而是“让模型在真实环境里更可控、更可验、更可恢复”。

3. Harness 到底在管什么

如果把定义说得足够工程化，Harness指的就是 Agent 里除模型之外、但又直接影响交付效果的那一层系统。

它通常至少包括下面几类东西：

• 信息组织：哪些规则常驻，哪些资料按需加载，哪些内容必须从仓库而不是聊天记录里读取。
• 任务规划：复杂需求怎么拆，哪些步骤必须先做，哪些中间状态需要落盘。
• 工具与权限：模型能读什么、改什么、执行什么、哪些操作需要人批准。
• 验证机制：测试、Lint、结构检查、UI 校验、结果回看，哪些是硬门禁。
• 可观测性：日志、截图、指标、回放、错误归因，出了问题怎么追。
• 恢复与演进：失败后如何重试、回滚、收敛，以及如何把一次失败沉淀成下一次的系统约束。

把它压缩成一个最小闭环，大致长这样：

需求/目标 | v 规划与信息装配 | v 执行与工具调用 | v 验证与评估 | v 反馈沉淀为规则/文档/约束 | +----> 下一轮任务

这也是为什么Harness Engineering不能简单理解成“多 Agent 编排”。

多 Agent 只是其中一种实现手段。真正重要的，是你有没有把“信息、执行、验证、反馈”做成闭环。没有这个闭环，就算只有一个 Agent，也会飘；有了这个闭环，就算系统不复杂，稳定性也会明显提升。

4. OpenAI 给出的信号：问题不只在模型，而在系统支撑

很多人第一次看到 OpenAI 的相关实践，最先记住的往往是“几个人、几个月、写了很多代码”。但真正值得记住的不是吞吐量，而是他们在复盘里反复强调的一件事：

早期卡住，不是因为模型完全不会写，而是因为 Harness 没搭好。

这背后至少有三层信号。

4.1 信息不能乱堆，乱堆等于没给

一个常见误区是：只要把所有规则和项目说明都塞进一个超大的说明文件，Agent 就应该更聪明。

现实通常相反。

• 内容过多，重点会被淹没。
• 内容长期不清理，过时信息会和新规则混在一起。
• 信息散落在聊天、文档、老员工脑子里，Agent 根本拿不到完整真相。

更有效的做法不是“塞更多”，而是“让信息可导航、可更新、可追溯”。

一个很有代表性的动作是，把原本越来越臃肿的统一说明文件压到极小，只保留目录和索引，让更细的规则按主题拆开，真正需要时再加载。这个动作看起来像是在“减少上下文”，本质上其实是在提升上下文质量。

换句话说，好的 Harness 不追求一次性喂饱模型，而追求让模型在需要时拿到正确的材料。

再往前走一步，就是把散落在聊天记录、外部文档、口口相传里的项目信息，尽量迁回可版本化、可检索、可更新的工程资产里。因为对 Agent 来说，拿不到的信息，和不存在没有区别。

4.2 交付不能靠自觉，必须靠验证闭环

OpenAI 实践里最重要的一个信号，是他们非常重视让 Agent 自己验证结果。

这件事的意义不在于“多接几个工具”，而在于把“我觉得我做完了”变成“系统确认我做对了”。

例如在 UI 场景里，如果 Agent 能自己看页面、看 DOM、截图回查、模拟用户操作，那么它就不再只是“生成代码的人”，也是“初步验收的人”。

再加上测试、Lint、结构约束这类确定性门禁，系统就会从单纯的生成链条，变成一个自动收敛的闭环：

生成 -> 运行验证 -> 发现问题 -> 返回修改 -> 再次验证

这比单纯追求更强的提示词有用得多，因为它直接在解决长任务里的两个核心问题：

• 模型会误判自己完成了。
• 模型会重复犯同一个错。

OpenAI 这类实践之所以让人警醒，不是因为他们把工具接得很多，而是因为他们把“生成”和“验证”真正连起来了。Agent 不是把代码吐出来就算完，而是必须经过页面、测试、结构约束、运行环境这几层反馈之后，才算完成一次有效交付。

4.3 真正的工程收益，来自把失败变成系统改进

如果每次 Agent 出错都靠人手工纠偏，那系统并没有变强，只是人一直在补洞。

OpenAI 实践里更有价值的一点，是把问题反过来看：

• 为什么这个错误会重复出现？
• 是不是规则不够清晰？
• 是不是验证门槛不够硬？
• 是不是环境隔离不够好？
• 是不是文档源头本身就不可信？

这套思路非常关键。因为它意味着工程师的角色正在变化。

这也是为什么环境隔离、独立日志、任务级指标、后台扫描修复这类看起来“离模型很远”的东西，会变得越来越重要。因为一旦 Agent 开始持续产出代码，技术债也会被持续放大。如果没有专门的回收与修正机制，系统只会越来越脏。

以前很多时间花在“亲自执行”。现在越来越多价值，会体现在“设计一个让 Agent 不容易重复摔倒的系统”上。

5. Anthropic 给出的信号：为什么单 Agent 经常做着做着就烂尾

如果说 OpenAI 让人看到的是“系统支撑的重要性”，那 Anthropic 让人看到的是另一件更具体的事：

为什么单 Agent 一做长任务就容易失控。

最典型的问题是，单 Agent 往往会同时承担四个角色：

• 理解需求
• 规划步骤
• 实现代码
• 评估自己做得好不好

这在简单任务上未必有问题，但在复杂任务上，很容易出现两个后果：

• 一口气做太多，做到中途上下文爆炸。
• 对自己的产出有天然偏见，明明还有 bug，也觉得差不多了。

Anthropic 后来收敛出来的思路，本质上就是把这些角色拆开。

Planner -> Generator -> Evaluator 扩展需求 产出实现 独立评估

这套结构最重要的不是“三个名字”，而是两条工程原则。

5.1 规划要和执行分开

模糊需求如果直接丢给执行者，执行者往往会急着开工，结果越做越乱。

先把需求扩展成更明确的功能点，再逐个实现，本质上是在降低上下文压力，减少中途跑偏的概率。

Anthropic 早期观察到的典型现象是：如果把一个大需求直接丢给单 Agent，它很容易上来就试图“一口吃完”，做到一半上下文撑不住，最后既不知道哪些已经完成，也不知道哪些还没验。看起来像是模型笨，实际上更像是系统没有给出稳定的任务分段方式。

这并不神秘，它和传统软件工程里的“先拆清楚再动手”是一脉相承的，只是现在执行者从人变成了 Agent。

5.2 生成要和评估分开

这是 Anthropic 经验里最值得所有团队记住的一点。

让生成者自己评价自己，天然不可靠。因为生成这件事本身就会让模型形成路径依赖，它更容易解释自己的输出，而不是严格挑错。

把评估者独立出来，系统会立刻获得一个很重要的能力：第三方视角。

这不一定非要做成三 Agent 系统。你完全可以把它落成更轻量的形式：

• 代码生成和测试校验分离
• 页面生成和视觉回归分离
• 修改动作和结构审查分离

本质都一样：不要让“交付者”兼任“验收者”。

Anthropic 的一个很现实的提醒是，这套更完整的 Harness 往往会更慢、更贵。也就是说，full harness的价值从来不是“立刻更便宜”，而是“在更复杂的任务里，把原本根本交付不出来的东西，变成可交付”。这对管理判断很重要，因为它意味着你不能只拿单次调用成本去衡量这套系统，而要看它到底提高了多少真实任务的完成率。

6. 它是不是噱头：争议到底卡在哪

围绕Harness Engineering，争议其实主要集中在两个点上。

6.1 争议一：这不都是老东西吗

这个批评并不完全错。

任务拆解、工具调用、验证闭环、环境隔离、权限控制、可观测性，这些都不是今天才出现的新技术。单拿任何一个出来，都谈不上革命性发明。

但问题在于，工程进步本来就不总是靠发明全新零件完成的。

很多时候，真正的进步来自两件事：

• 把零散能力组织成统一框架。
• 把原本靠经验完成的动作，变成可以持续优化的系统设计。

从这个角度看，Harness Engineering的价值不在“新”，而在“成体系”。

6.2 争议二：模型变强后，这一层会不会消失

这个批评也不是空穴来风。

随着模型越来越强，确实有一些今天看起来必要的脚手架，未来会显得笨重。

例如：

• 为了避免迷路而写得非常死板的步骤约束
• 为了让模型别忘事而加的重复提醒
• 很重的反思链、补丁式规划器、强制顺序执行器

这些东西，本质上都是在替模型补认知短板。模型一旦补上，很多脚手架就会被压缩。

但这不等于 Harness 整体会消失。因为系统基础设施不是认知补丁。

工具、权限、验证、状态、审计、可观测性，这些不是“模型更聪明”就能凭空省掉的。模型再强，也仍然需要运行在一个可控系统里。

7. 哪些 Harness 会被更强模型吃掉，哪些会留下来

这是管理者最该关心的问题，也是工程师最容易误判的问题。

一个简单的判断方法是：看这层东西，到底是在“替模型思考”，还是在“给模型提供系统能力”。

更容易被压缩的部分 - 复杂提示链 - 过度刚性的 Planner - 补丁式反思循环 - 为模型短板写的大量认知型规则 更可能长期留下的部分 - 工具接入 - 权限控制 - 测试与验证 - 状态管理 - 可观测性与审计 - 环境隔离与回滚

这背后有一个很实用的投资判断：

• 如果你的建设重点是在“教模型怎么想”，它的折旧速度通常会更快。
• 如果你的建设重点是在“让模型能安全执行、能被验证、能被回放、能被纠偏”，它更容易沉淀成长期资产。

所以，真正值得投的不是“把 Harness 做厚”，而是“把长期基础设施补齐”。

8. 工程师和管理者分别该怎么理解这件事

8.1 对工程师来说，它意味着职责重心在外移

未来一段时间，工程师当然还是要写代码。但越来越多价值会体现在下面这些事情上：

• 把规则写清楚，而不是让 Agent 靠猜。
• 把任务拆清楚，而不是一把丢给模型。
• 把验证接起来，而不是只看生成结果。
• 把失败留痕，并且把教训沉淀成系统约束。

简单说，工程师正在从“亲自完成每一步”逐步转向“设计一个更稳定的执行系统”。

8.2 对管理者来说，投入重点不该只放在模型采购

很多团队讨论 AI 投入时，最容易把问题简化成：

• 该买哪个模型？
• 要不要上更贵的模型？
• 能不能直接多开几个 Agent？

但如果缺少 Harness，强模型只会把“能做 demo”放大，不一定能把“能稳定交付”放大。

一个更成熟的投入顺序通常是：

1. 先把目标任务定义清楚。
2. 再把信息源、权限和验证门槛补齐。
3. 然后再判断模型和编排层要不要继续加厚。

否则就很容易出现一种假繁荣：

• Demo 很惊艳
• 真实任务里返工很多
• 结果波动很大
• 最终大家把问题归因成“模型还不够强”

其实很多时候，不是模型不够强，而是系统还不够像一个可交付的生产系统。

9. 总结

如果一定要给Harness Engineering下一个最简洁的判断，我会这样概括：

它不是噱头，因为头部公司的实践已经证明，模型能力之外的系统设计，确实决定了 Agent 能不能稳定进入真实生产。

它也不是终局，因为今天很多认知型脚手架，本质上只是过渡时期的补丁，未来会被更强模型逐步吞掉。

但在当下这个阶段，它依然非常重要。因为真实世界的问题不是“模型有没有潜力”，而是“能力能不能兑现”。

对工程师来说，这是一种新的工程重心迁移。

对管理者来说，这是一种更现实的投入判断框架。

别把它理解成又一个需要追逐的新词。更准确的理解是：当 Agent 从演示走向交付时，Harness Engineering正在变成那层不能再被忽略的系统底座。