Harness Engineering：驾驭大模型的工程新范式
继 Prompt Engineering、Context Engineering 之后，AI 圈又冒出了一个新名词------Harness Engineering。从 2025 年 2 月开始，这个词频繁出现在各大技术社区。OpenAI 专门发文讲述他们如何用 Harness Engineering 在五个月内生成了近 100 万行代码；Anthropic 紧接着也分享了精心设计的 Harness 架构如何驱动 Agent 应用开发；就连 Martin Fowler 的技术网站也开始公开讨论这一概念。
但也有不少质疑声：这不过是个噱头，换汤不换药。
那 Harness Engineering 到底是什么？它与 Prompt Engineering、Context Engineering 之间是什么关系？它是真正的技术突破，还是 AI 圈又在炒作概念？这篇文章将彻底厘清这些问题。
1. 两个前传：Prompt Engineering 与 Context Engineering
在讲 Harness Engineering 之前，有必要先回顾它的两位"前辈"。
1.1 Prompt Engineering：怎么把话说清楚
Prompt 就是用户发给大模型的话，而 Prompt Engineering 就是一门研究"怎么把这句话说清楚"的技术。
举个例子：你问大模型"帮我推荐一个周末去处"，它可能回答"去公园散步、逛博物馆"之类的通用建议。但如果你在北京、喜欢户外活动，这些建议就不太贴切了。问题的根源在于 Prompt 没有给够信息。
按照 Prompt Engineering 的理念，你应该这样问：
帮我推荐一个北京周末去处，适合和朋友一起，户外活动，预算人均200以内。
这时候模型给出的"奥森公园骑行""什刹海划船"就更符合预期。
Prompt Engineering 的核心就是调整提示词，让模型更精准地理解你的意图。 但如今这门技术已经很少被单独提起了------一方面门槛太低，另一方面模型本身变强了，很多时候不需要精细调 Prompt 也能给出不错的回答。
1.2 Context Engineering：怎么把信息给对
假设拿到周末去处推荐后，你继续追问"那里需要预约吗？"，这时发给大模型的就不只是这一个问题，还包括之前的对话历史，否则模型根本不知道"那里"指代什么。
大模型接收到的所有信息------Prompt、对话历史、工具列表、Skill 列表等等------统称为 Context 。Context 有容量上限，不可能无限制地往里塞东西，我们需要精心设计 Context 的内容，这就是 Context Engineering。
Context Engineering 的经典技术包括：
- 上下文压缩：当对话历史过长时，对前面的内容做摘要总结，防止 Context 溢出影响回答质量。
- 动态检索：按需从外部知识库拉取相关信息注入 Context。
- 渐进式披露：分阶段、分层次地暴露信息给模型。
Context Engineering 很能整活，但大家逐渐发现它的效果有上限。为了进一步挖掘大模型的潜力，AI 圈又整出了新花样------这就引出了我们真正的主角。
2. 什么是 Harness Engineering？
2.1 Harness 的本意：马具
Harness 这个词在日常生活中不太常见，它的本意是马具------套在马身上用来控制马的装备，比如缰绳、头套。马虽然非常强大，但必须借助马具来引导它，才能为人类所用。
把这个类比映射到 AI 领域：
- 脱掉马具的马 ≈ 大模型：能力极强，但如果任由它自由发挥，就会像脱缰的野马一样发散思维，产生严重幻觉，无法稳定输出可靠结果。
- 马具 ≈ Harness：用来控制和驾驭大模型的系统。
2.2 Harness 的公式
目前业界比较认可的一个公式是：
Harness = Agent − Model
换句话说，一个完整的 Agent 减去里面的大模型，剩下的所有东西都是 Harness。
以 Claude Code 为例：所有不属于 Claude 模型的部分都是 Harness------CLAUDE.md 中的规则、可用工具、定时调度机制、权限管控等等。只要不是模型本身，都可以视为 Harness 的一部分。
2.3 Harness Engineering 的定义
顺理成章地，Harness Engineering 就是一门专门研究如何构建与设计 Harness 的技术。它不再仅仅盯着模型输入的那点提示词或上下文，而是站在更高的系统层面，研究怎么给大模型设计一套可以稳定运行的框架，让大模型踏踏实实地为人类做事。
2.4 三者关系：层层递进
| Prompt Engineering | Context Engineering | Harness Engineering | |
|---|---|---|---|
| 研究什么 | 怎么"问问题" | 怎么"给信息" | 怎么"搭系统" |
| 关注范围 | Prompt 本身 | Prompt + 对话历史 + 工具列表等 | 除了模型之外的所有内容 |
| 核心目标 | 把话说清楚 | 在最合适的时机给最合适的内容 | 围绕大模型搭建完整可靠的 Agent |
三者是层层递进、研究范围不断向外扩展的关系------关注的问题越来越大、越来越系统化。
3. OpenAI 的实践：五个月、100 万行代码
2025 年 8 月，OpenAI 内部启动了一个疯狂的实验：用 AI 从零开始写一个真实的软件产品，全程不允许工程师手写一行代码。所有组成部分------业务逻辑、测试、CI 配置、文档、内部工具------全由 AI 生成。
- 代码规模：近 100 万行
- 耗时：约五个月
- 团队规模：从 3 人扩展到 7 人
- 开发效率：约为纯人工的 10 倍
有意思的是，实验一开始并不顺利------不是因为大模型不够聪明，而是因为 Harness 没搭好 。工程师发现 Agent 经常走错方向，甚至重复犯同一个错误。他们意识到：要想让 Agent 可靠地工作，真正的功夫在于把 Harness 设计好。
OpenAI 的优化可以归纳为三大类：
3.1 上下文管理：让 Agent 获取充足的信息
最初的做法是把所有项目规范塞进一个超大的 AGENTS.md 文件，结果发现有两个致命问题：
- 内容太多，模型效果变差------就像第一天入职 HR 砸给你一本巨厚的员工手册，完全抓不住重点。
- 文件逐渐腐化------项目在演进，但文件没人及时更新，变成一堆过时信息的垃圾堆。
改进方案 ：将 AGENTS.md 压缩到 100 行左右，只保留目录结构，具体文档分门别类存放。用到哪块再给 Agent 看哪块，效果就好很多。
此外，OpenAI 还发现很多重要信息散落在 Slack 聊天记录、Google Docs 里，甚至只存在于老员工的脑子里。他们的解法是：强制把所有重要决策和约定搬进代码仓库，让仓库成为唯一的真相来源（Single Source of Truth）。
3.2 验证与反馈：让 Agent 能检验自己的产出
写完代码之后，Agent 必须能验证自己的成果是否正确。OpenAI 的做法：
- 集成 Chrome DevTools：Agent 可以自己截图、查看 DOM 结构、模拟用户操作，验证 UI 是否符合要求。发现问题原地修复，无需人工介入。
- 接入可观测性工具栈：Agent 能读取日志、指标，追踪链路排查问题。每个任务跑在完全隔离的环境中，有独立的日志和指标，结束后自动销毁。
- 用 Linter 和测试保证架构规范：OpenAI 将系统分成 UI → Runtime → Service → Wrapper → Config → Types 多层，严格规定依赖关系。Agent 生成代码后，Linter/测试自动检测合规性，报错信息发回 Agent 自行修改，形成闭环。
3.3 技术债清理：不让代码腐化
Agent 在大规模生成代码的过程中，会不可避免地引入重复代码、偏离规范的写法、不一致的命名等问题。
OpenAI 设了一个后台 Codex 任务，定期扫描整个代码库，找出偏离规范的地方，自动修改并提交。文档方面同理------定期扫描文档库，找出过时内容，自动修复。
核心洞察：Human Steer, Agents Execute
这五个月的实验让 OpenAI 重新定义了人与 AI 的工作边界：
人类负责掌舵，Agent 负责干活。
软件工程师的核心职责变了：不再是亲自手写代码，而是为 Agent 搭建稳定可靠的系统与支撑框架，以此最大化代码产出效率。
4. Anthropic 的实践：Planner → Generator → Evaluator
Anthropic 先后发表了两篇与 Harness Engineering 相关的文章：
- 2024 年 11 月：Effective Harnesses for Long-Running Agents
- 2025 年 3 月：Harness Design for Long-Running Application Development
两篇文章信息量很大，但最核心的就两点：任务规划 和 质量评估。
4.1 任务规划：引入 Planner
一开始，Anthropic 让 Agent 直接执行"克隆 Claude.ai"任务------需求工作量太大，Agent 急于求成，干到一半上下文满了就撂挑子，下一个接手的 Agent 完全不知道前面发生了什么，要么重复造轮子要么草草收工。
解法 ：引入一个叫 Initializer 的 Agent，核心职责是把用户需求拆解为详细的功能列表，后续干活的 Agent 按功能点一个一个做，做完一个标记一个。
在第二篇文章中，这个思路演进为独立的 Planner Agent：专门负责把用户一句模糊的需求扩展成一份完整清晰的功能列表。后面的 Agent 照着功能点做就行，不用对着需求猜。
4.2 质量评估：引入独立的 Evaluator
质量评估有三种方案：
| 方案 | 问题 |
|---|---|
| 人工评估 | 效率太低 |
| Agent 自评 | 王婆卖瓜，对自己产出天然有滤镜，有 Bug 也视而不见 |
| 独立评估 Agent ✅ | 第三方评估，客观公正，还可单独优化训练 |
Anthropic 最终选择了第三种方案：将生成代码 和质量评估 拆成两个 Agent------Generator 和 Evaluator。
4.3 完整流程：Full Harness 方案
Anthropic 拿"做一个游戏制作工具"的任务做了对比：
| 方案 | 耗时 | 花费 | 效果 |
|---|---|---|---|
| Solo（单 Agent） | 20 分钟 | $9 | 布局不合理、逻辑混乱、Bug 遍布 |
| Full Harness（三 Agent） | 6 小时 | $200 | 布局和逻辑达到可用水准 |
精雕细琢有代价，但效果提升显著------就像考 60 分只需复习三天，考 90 分则需一个月。
4.4 模型变强后的简化
有趣的是，当 Anthropic 升级到 Opus 4.6 后，很多 Harness 约束不再需要了：
- 上下文焦虑消失：Opus 4.5 在上下文过长时会急于结束任务，Opus 4.6 大幅缓解了这一问题，原先用的"上下文重置"技术不再必要。
- 强制分步执行不必要了：Opus 4.6 的全局统筹能力够强，可以一次性拿到所有功能点，自己决定执行顺序，不需要外力干预。
5. Harness Engineering 是不是噱头？
5.1 这个词是怎么火起来的
"Harness"这个词本身并不新------软件测试领域早有"Test Harness"，AI 领域也有开源项目"LM Evaluation Harness"。真正新的是"Harness Engineering"这两个词的组合。
目前公认的起点是 Mitchell Hashimoto 于 2025 年 2 月 5 日发表的博客 My AI Adoption Journey。他写道（大意）：
我也不知道业界有没有公认的叫法，我就姑且叫它 Harness Engineering。核心就是：只要 Agent 犯了错，你就去改造系统，让它绝不再犯。要是有更好的词，我随时改口。
几天后（2 月 11 日），OpenAI 发表那篇信息量极大的 Harness Engineering 文章，引爆了讨论。随后 Martin Fowler 网站、LangChain 等纷纷跟进，LangChain 还明确给出了公式：Agent = Model + Harness。
5.2 质疑的声音
反对者的核心论点有两个：
- 没有新技术：Linter 代码检查、任务拆解规划、质量评估机制这些东西早就有了。Harness Engineering 只是把旧技术重新组织了一下，新瓶装旧酒。
- 迟早被淘汰：随着大模型能力持续增强，今天的 Harness 设计未来会被模型自身吸收，不再需要。Anthropic 从 Opus 4.5 到 4.6 的演进就是例证------模型越强，需要的 Harness 越少。
5.3 我的看法
Harness Engineering 不是噱头，但大概率也不是终局。
说它不是噱头，因为两点： 一是成果，OpenAI 和 Anthropic 都通过它把 Agent 的稳定性和产出效率推到了新高度，这是实打实的成绩；二是框架，它第一次把零散的"调 Prompt""管上下文""写 Linter"整合成一套可系统设计、可持续优化的工程方法论------工程进步的本质就是把经验变成方法。
说它不是终局，理由同样实在： 今天精心设计的 Harness 约束，正在被更强的模型自身吸收。从 Opus 4.5 到 4.6，原本必须的"上下文重置"技术就不再需要了。照这个趋势，纠偏、兜底、任务拆解这些 Harness 的核心职能，大概率会逐步内化到模型自身。
所以我的结论是：这是一个过渡期的关键技术。 它不是未来的终极答案，但它是当下最现实的答案。模型依然会犯错、会幻觉、会在复杂任务中走偏------在这种现实下，谁能把 Harness 搭得更稳，谁就能更早地把 AI 能力转化为真正的生产力。
6. 总结
| 概念 | 核心问题 | 研究范围 | 时代定位 |
|---|---|---|---|
| Prompt Engineering | 怎么把话说清楚 | Prompt | 入门必备，但已基础化 |
| Context Engineering | 怎么把信息给对 | Context（Prompt + 历史 + 工具等） | 仍有价值，但天花板明显 |
| Harness Engineering | 怎么把系统搭稳 | Agent 中除模型外的所有内容 | 当前最优解，但可能非终局 |
Harness Engineering 的本质，是把人对 AI 的控制从"话说得对不对"升级到"系统搭得稳不稳"。它不是炒概念，而是一套能落地、能见效的工程方法论。但与此同时，我们也要认识到它的过渡性质------未来模型更强大后，Harness 的形态还会持续演化。
最后，建议有兴趣深挖的读者直接去读 OpenAI 和 Anthropic 的原文，信息密度极高，一定会大有启发。
Human Steer, Agents Execute. 在 Harness Engineering 的时代，工程师的使命不再是亲自写每一行代码，而是为 AI 搭建一套能稳定运行的体系------你负责舵，它负责帆。