从 Prompt 到 Harness：AI 帮程序员干活这条路，人类是怎么想通的？
最近一段时间 AI 圈子的 Buzzword 那还得是 Harness Engineering——说白了，就是怎么让 AI 智能体替我们干活，而且干得漂亮。说到底，这也还是人类从 AI 诞生起就有的那个念想：所有活都让机器帮我们干！
不过你要是以为这是个突然冒出来的新词，那说明你可能没太关注这波 AI 浪潮的演进节奏。要理清这个问题，咱们得把时间拨回去，从 Prompt → Context → Harness 这条演变线说起。
Prompt 时代：最早大家玩 AI，说白了就是「写提示词」。调教模型跟训狗差不多——给个指令，给个例子，期待它能给点像样的输出。那时候的核心问题是：怎么写提示能让模型听懂人话？
Context 时代：很快大家发现，光靠提示词不够用。为啥？因为对话一长，模型就开始「失忆」或者「幻觉」。于是大家开始研究怎么管理上下文——系统提示、few-shot、记忆机制……怎么让模型在长对话里保持靠谱，变成了一门新学问。
Harness 时代：而现在，行业终于走到了这一步——光是「对话」已经不能满足大家了，人们想要的是「干活」。让 AI 自己规划、自己执行、自己纠错，最终把一个完整的任务端到端搞定。这，就催生了 Harness Engineering。
OpenAI 和 Anthropic也都发布过各自的 Harness 实践。表面上看，都是在聊「怎么用好 AI 智能体」，但细品执行上还是有所不同。今天我们就通过他们的工程博客一起扒一扒以及我们能从中学到啥。
01. 核心隐喻：掌舵 vs GAN
先说最本质的区别——两家对 Harness 的隐喻就完全不同。
OpenAI 的思路很简单：人类掌舵，智能体执行。
这话听起来有点鸡汤，但翻译成人话就是：工程师别亲自写代码了，去设计环境、明确意图、构建反馈回路。说的更直白点，你的产出不再是代码，而是约束系统——AGENTS.md、规则、linter、文档。
Anthropic 呢？玩的是 GAN 那一套。
就是生成器-判别器那一套经典架构。搞了个三智能体系统：Planner 负责规划，Generator 负责干活，Evaluator 负责挑刺。是不是听起来有点眼熟？对，就是 AI 圈训练图像生成模型的老办法。
但话说回来，这两种思路没有谁对谁错，更多是 「约束驱动」 vs 「架构驱动」 的区别。
02. 架构设计：结构化约束 vs 多智能体架构
OpenAI 的做法
读完原文，我发现之前的理解有偏差。OpenAI 实际上并非「越少越好」，而是走了结构化约束的路子：
- 地图式文档：AGENTS.md 只有约 100 行，作为入口索引，真正的内容在结构化的 docs/ 目录中（设计文档、执行计划、产品规范、参考资料等）
- 强制约束：自定义 linter 强制执行严格的分层架构（Types → Config → Repo → Service → Runtime → UI），依赖方向必须遵守
- 品味不变式：结构化日志、命名约定、文件大小限制等规则直接编码到 linter 中
- 垃圾回收机制：定期运行后台任务扫描代码偏差、更新质量等级，并发起重构 PR
人类在环主要是审核 PR、给反馈。慢慢才过渡到 Agent 对 Agent 的审核。整个路径是：人工 → 规则 → 自动化。
Anthropic 的做法
Anthropic 上来就加了豪华架构。
三智能体各司其职还不够，还搞了个「Sprint 合约」机制——每次迭代之前，Generator 和 Evaluator 先坐下来谈判：啥叫「干完」？标准是什么？谈拢了才开始干活。
然后就是一轮又一轮的迭代。Anthropic 的数据显示，用这种方式跑一个完整的游戏编辑器，8 轮迭代下来花了 6 小时、200 美金。讲真，这成本确实不低。
但效果怎么样呢？单智能体跑只要 20 分钟、9 美金，但做出来的游戏——核心功能是坏的。而完整 harness 跑下来，6 小时、200 美金，虽然成本高了 20 多倍，但结果是可用的。
03. 上下文管理：渐进式披露 vs Context Reset
OpenAI 的方案
渐进式披露
说难听点，就是别给智能体塞太多东西。一开始只给入口，慢慢引导它去更深的地方找答案。文档要结构化，要编入索引，要定期清理烂文档。专门有个「doc-gardening」智能体负责扫描过时的文档并发起修复 PR。（逻辑类似早期Anthropic对于Skills的渐进式披露）
Anthropic 的方案
Context Reset
有一说一，第一次看博客原文的时候看到几个观点确实很有趣，纯用户视角感觉还是不好察觉的（建议自行看看原文）。简单解释一下：模型跑久了，上下文窗口会塞满，逻辑开始飘，严重的还会出现「Context Anxiety」——模型觉得自己快到极限了，开始提前收尾，草草结束任务。
Anthropic 的解法是：直接清空上下文，重置到一个干净的状态。但这就需要一份结构化的「交接文档」，让下一个智能体能接上之前的工作。
这两种方案哪种更好？说实话，没有标准答案。渐进式披露更轻量，但需要很强的文档基建。Context Reset 更暴力，但需要好的交接机制。
04. 评价体系：外部审核 vs 独立 Evaluator
OpenAI 依赖外部
主要靠人类审核 PR，再加上其他 Agent 的审核反馈。审核通过，合并；不通过，打回重改。这就是传说中的「Ralph Wiggum 循环」——智能体自己改、自己审、循环往复，直到没人挑得出毛病。
Anthropic 搞了个独立 Evaluator
这是 Anthropic 最有意思的创新。把「干活的人」和「挑刺的人」分开。Generator 只管写代码，Evaluator 只管找问题。
为什么不能让自己评价自己？因为 AI 有一个迷之自信的毛病——它永远觉得自己写得特别好。（原文使用了相当拟人的描述）
Anthropic 通过大量调试发现：独立 Evaluator 比「自己评价自己」靠谱太多了。而且 Evaluator 是可以调的——给它足够多的例子，让它知道啥叫「好」，它就能逐步学会你挑剔的品味。
05. 模型适配：隐式 vs 显式
这是 Anthropic 特别有意思的一个洞察。
他们发现：随着模型能力变强，很多之前必需的 harness 组件就可以扔掉了。
比如 Opus 4.5 需要 Context Reset 来解决 Context Anxiety，但 Opus 4.6 发布后，模型本身就已经能处理这个问题，不再需要额外的机制来兜底。
再比如，原来需要把任务拆成很多个 Sprint 来跑，后来发现模型自己就能 handle 整块任务，sprint 机制也可以简化。
换句话说：Harness 不是一成不变的，要跟着模型能力动态调整。
OpenAI 那篇虽然没明说这个观点，但字里行间也在暗示——他们也在不断迭代自己的约束系统。
Anthropic 在他们的研究中有段话我特别认同，摘出来分享一下：
随着模型不断改进，我们可以大致预期它们能够运行更长时间，并处理更复杂的任务。在某些情况下，这意味着随着时间的推移，模型周围的框架的重要性会降低，开发人员可以等待下一代模型，并看到某些问题自行解决。另一方面，模型越好，就越有空间开发能够完成模型基线功能之外的复杂任务的框架。
这项研究让我确信，随着模型的改进，有趣的硬件组合空间并不会缩小。相反，它会不断扩展，而人工智能工程师的真正乐趣在于不断寻找下一个新颖的组合。
说白了就是：模型越好，框架既可以变简单，也可以变复杂。 变简单是因为很多脏活累活模型自己干了；变复杂是因为你可以去挑战以前根本不敢想的复杂任务。两条路都是好事，就看你的目标是想省力，还是想搞大事。
06. 共同点：英雄所见略同
文档是基础设施——两家都强调结构化文档的重要性。别想着一股脑把所有信息塞给智能体，得有条理、有层级。
反馈循环不可或缺——没有闭环的 agent 走不远。不管是 OpenAI 的 Ralph Wiggum 循环，还是 Anthropic 的 GAN 迭代，核心都是「改到满意为止」。
模型会进化——Harness 需要随模型能力调整。Anthropic 明确提出了这个观点，OpenAI 也在用脚投票。
成本意识——两者都关注 token 成本与运行时间。毕竟 harness 搭起来是要花钱的，不能无脑堆复杂度。
总结
整体看
OpenAI 倾向于结构化约束：通过 linter、架构规范、品味不变式来强制执行约束，文档是入口索引而非百科全书。
Anthropic 倾向于多智能体架构：通过 Planner-Generator-Evaluator 的分工与迭代来保证质量。
这个矛盾没有绝对答案。取决于：
- 任务复杂度
- 模型能力
- 成本约束
- 质量要求
但正是这种路径差异，让整个行业有了更多探索的可能性。指不定哪天，两种思路就融合了，变成一种更优雅的方案。
毕竟，只要还在折腾，就说明故事还没讲完。
我们也在做类似的尝试——把 Harness Engineering 从理论落到真实项目中，并记录实战项目的完整配置、沉淀的工具框架、模板以及踩坑经验。
https://s3gw.paasst.cmbchina.cn/srd-b256fe7e81ec477f-1255000106/harness01/