Harness Engineering 是什么？新范式，还是噱头？
Harness Engineering 是什么？新范式，还是噱头？
蔡坨坨转载请注明出处❤️
作者：测试蔡坨坨
原文链接：caituotuo.top/2f655917.html
你好，我是测试蔡坨坨。
AI 圈造词的速度，比模型迭代的速度还快。
从最初人人挂在嘴边的 Prompt Engineering（提示工程），到后来强调信息组织的 Context Engineering（上下文工程），如今，一个更新的概念正在硅谷技术圈走红——Harness Engineering。
从今年 2 月份开始，这个词开始频繁出现在 OpenAI、Anthropic 等顶尖 AI 实验室的官方技术博客里。OpenAI 甚至专门发文，分享了他们如何通过 Harness Engineering，在 5 个月内让 AI 编写了将近 100 万行代码。
原文：Harness engineering: leveraging Codex in an agent-first world
Anthropic 也紧接着发文，分享自己如何使用精心设计的 Harness 架构来驱动 Agent 开发应用。
原文：
不仅如此，就连技术大牛 Martin Fowler 创建的技术网站 martinfowler.com 也开始公开讨论起 Harness Engineering。
原文：
但与此同时，也有不少人认为这不过是个噱头而已，换汤不换药。
那 Harness Engineering 到底是什么？它是真技术突破，还是又一个包装精美的炒作概念？
什么是 Harness Engineering？
先把这三个概念的演进理清楚。
Prompt Engineering 解决的是”怎么跟模型说话”的问题，研究的是提示词的措辞、结构、格式。
举一个具体点的例子，比如你对模型说*”帮我推荐一部电影。”*，这其实就是一个 Prompt。
但问题是，这句话的信息太少了，模型根本不知道你喜欢什么类型、想一个人看还是和朋友看、喜欢轻松搞笑还是烧脑、新片还是老片，于是它只能随机给你推荐一些“大众觉得不错”的电影，但这些推荐，很可能不符合你的口味，因此 AI 并不知道你真正想要什么。
这个时候 Prompt Engineering 的作用就来了，如果你把 Prompt 改成*”推荐一部适合周末晚上一个人看的电影，不要恐怖片，节奏不要太慢，希望是轻松搞笑的，最好近几年的高分作品。”*，你就会发现，AI 给出的结果立刻就不一样了。
不过，如今 Prompt Engineering 已经很少被单独提起了，一方面是因为它的门槛实在是太低了，另一方面模型本身的能力也变得更强了，很多时候不需要在 Prompt 上面调来调去，也能得到很不错的回答。
Context Engineering 往前走了一步，关注的是”给模型看什么”，不仅是在 Prompt 上下功夫，还包括历史对话管理、上下文压缩、RAG、动态检索外部资料、渐进式披露等技术，本质是在做信息的组织和筛选。
我们在之前的文章中也有讨论过，可参考：「什么是Context Engineering？一文读懂AI黑话之“上下文工程”」
总结来说，因为 Context Window 是有容量上限的，所以我们不可能无止境的往里塞东西，所以我们需要精心设计上下文窗口里面的内容，而这门研究就被叫做 Context Engineering。
可以看出 Context Engineering 其实已经是挺能整活的了，不过这依然不是终点，因为大家发现 Context Engineering是有一定的上限的，为了进一步榨干模型的潜力，AI 圈又整出了新花样——Harness。
Harness 这个词，本意是”马具”——缰绳、头套、驭马用的一整套装置。一匹烈马再强壮，没有马具就没法受人控制，也就是脱缰的野马，更别提为人所用。
这个比喻放到大模型上非常贴切。大模型（比如 GPT 5.5 或者 Claude Opus 4.7）的能力已经很强了，但它天然会产生幻觉、会跑偏、会在细节上犯低级错误。Harness Engineering 研究的，就是怎么为模型设计一套控制系统，让它踏实地把事办成。
业内目前有一个非官方公式：Harness = Agent - Model。一个完整的 AI Agent 去掉大模型本身，剩下的所有控制逻辑、工具调用、验证机制、调度流程，都属于 Harness 的范畴。
换句话说，它不只盯着几句提示词或者上下文，而是站在系统工程的高度来考虑问题：如何让模型在一个稳定的框架里持续、可靠地输出结果。
以 Claude Code 举例，除去 Claude 模型本身，剩下的 CLAUDE.md、可用工具列表、定时调度机制、Skills、Hooks 等这些都属于 Harness。
OpenAI 的实验：5 个月，100 万行代码
相信看到这里的同学已经了解了 Harness Engineering 是什么了，但是 Harness Engineering 具体要做哪些事情？说实话，这个概念实在是太新了，目前业界也没有一个公认的体系。
我的做法是直接看看大厂是怎么做的。
2025年8月 OpenAI 启动一个”疯狂”的实验：全程不允许工程师手写一行代码，完全由 AI 生成业务逻辑、测试、配置、文档和内部工具。
结果是 3 ~ 7 个人，5 个月，开发出将近 100 万行代码的 beta 产品，开发效率提升约 10 倍。
但这项实验一开始并不顺利，不是因为大模型不够聪明，而是因为 Harness 没有搭建好，工程师发现 Agent 经常走错方向，犯相同的错误。
其中的优化过程原文中有详细记录，信息量非常大，篇幅关系，我会放在单独的文章中再做进一步讨论。
简单来说，OpenAI 的工程师搭了一套精密的 Harness 让 Agent 可靠地完成工作。核心做了三件事：
上下文管理
他们放弃了把所有规则塞进一个大文件的做法。agent.md 被压缩到约 100 行，变成一个”目录”，Agent 需要哪块信息就去读对应的文档。同时，所有决策都强制同步进代码仓库，仓库成为 Agent 唯一的”事实来源”。
这个思路值得记住：上下文不是越多越好，是越精准越好。
验证与反馈闭环
他们给 AI 接入了 Chrome DevTools 等工具，让它能自己截图、自查 UI 效果，同时接入可观测性工具读取日志和指标。这样 AI 就能自己发现问题、原地修复，形成一个完整的自动化闭环，而不是每次都等人来发现错误。
持续清理技术债
设置后台任务定期扫描代码库和文档，自动修复重复代码、命名不一致或过时的文档。代码质量不靠人工 Review 维持，靠系统自动兜底。
这个实验重新定义了人机分工的边界：人类掌舵（Steer），Agent 干活（Execute）。工程师的工作，从写代码变成了为 Agent 搭建稳定可靠的系统支撑框架。
Anthropic 的方案：三角色分工协作
相比 OpenAI 的全能型路径，Anthropic 的 Harness 设计更倾向于多 Agent 协作。
为了让 Agent 稳定运行并完成复杂任务，他们提出了 F-Harness 架构，里面有三个核心角色：
- Planner（规划者）：把用户模糊的需求拆解成清晰的功能列表
- Generator（生成者）：根据列表逐个实现功能点
- Evaluator（评估者）：作为独立第三方，对生成的代码做质量评估，把 Bug 反馈给 Generator 修改
有点像研发流程里的需求拆解 + 开发 + 测试，只是三个角色全都是 AI。
实验数据显示，Solo 模式一次任务花费约 9 美元，F-Harness 模式要 200 美元左右，贵了 20 多倍，耗时也更长。但产出的产品逻辑和布局质量，远超单 Agent 模式。
这让我想到一个测试里的道理：质量不是测出来的，是设计进去的。 给 AI 系统加上独立的”评估者”角色，本质上是把质量门槛设计进了流程里，而不是事后补救。
争议：是新范式，还是”新瓶装旧酒”？
Harness Engineering 并非没有质疑声。
有人觉得，代码检查（Lint）、任务拆解、单元测试这些技术早就有了，HE 不过是把老技术重新起了个洋气的名字。这个批评不是完全没道理——如果只是换了个马甲，那确实没必要大张旗鼓。
还有一个更深的担忧：**”模型会吃掉 Harness”**。
模型能力一直在涨。Anthropic 就发现，从较低版本升级到 Opus 4.6 后，原本需要强制拆解才能处理的任务，模型现在可以自主统筹并稳步推进，不再需要那么多外部约束。换句话说，Harness 里很多复杂的控制逻辑，将来可能会被模型本身内化掉。
这种担忧是真实的。但我觉得，它解决的是”现在”的问题，而不是”未来”的问题。
当下最务实的选择
争议归争议，现实是：模型现在依然会幻觉、会跑偏、会在长任务里失控。
在这个前提下，Harness Engineering 不是噱头，而是目前提升 Agent 稳定性、实现大规模自动化的最可行路径。它可能不是终局答案，但它是当下能拿出来用的答案。
也许等到哪天模型强到”不需要马具”，Harness 会退化成一个简单的环境接口。但在那一天到来之前，谁把 Harness 搭得更稳，谁就能更早地把 AI 能力转化为真实的生产力。
这也是为什么 OpenAI 和 Anthropic 愿意把这些实验细节公开出来——工程能力，才是 AI 落地的真正门槛。
如果你现在正在做 AI 相关的开发，不妨想想：你给 Agent 搭的那套”马具”，够稳吗？
