目录

• 前言
• 从 Prompt Engineering 到 Context Engineering
• 什么是 Harness Engineering
• OpenAI 的 Harness Engineering 实践
• Anthropic 的 Harness 架构
• Harness Engineering 是噱头吗
• 总结

---

前言

继 Prompt Engineering、Context Engineering 之后，AI 圈最近又冒出了一个新名词——Harness Engineering。

从 2025 年 2 月份开始，这个词频繁地在 AI 圈里面出现：

• OpenAI 专门发了一篇文章，讲他们怎么用 Harness Engineering 在 5 个月内写了将近 100 万行代码
• Anthropic 也紧接着发文，分享了自己如何使用精心设计的 Harness 架构来驱动 Agent 的开发应用
• 就连技术大牛 Martin Fowler 创立的技术网站 martinfowler.com 也开始公开讨论起了 Harness Engineering

但与此同时，也有不少人认为这不过是个噱头而已，换汤不换药。

那 Harness Engineering 到底是什么？它跟 Prompt Engineering 和 Context Engineering 又有什么关系呢？Harness Engineering 是真正的技术突破，还是说只是 AI 圈又在炒概念？

这篇文章，我们就来把这个事情彻底搞明白。

---

从 Prompt Engineering 到 Context Engineering

在讲 Harness Engineering 之前，我们不妨先来讲讲它的两个"前任"，分别是 Prompt Engineering 和 Context Engineering。

Prompt Engineering：如何把话说清楚

Prompt Engineering 就是一门研究怎么把话说清楚的技术。

这里的 Prompt 你可以简单理解成用户发给大模型的话。举个具体的例子，比如我们向大模型发问：

帮我的猫起个名字

这个问题就是 Prompt。接到 Prompt 之后，大模型会给你一个答案，比如"花花"、"小白"之类的。

不过这些答案可能都无法让你满意，因为你家的猫可能是橘色的，无论是"花花"还是"小白"都与橘色这个颜色相冲突。

为什么大模型会给错误的答案呢？

因为我们没有在 Prompt 里面给大模型充足的信息。解决问题的关键自然也在 Prompt 上面——我们需要学会如何更精准地表达自己的需求。

按照 Prompt Engineering 的理念，我们需要发送的 Prompt 应该是这样的：

帮我的橘色小猫起名，两个字，需要体现出它活泼爱玩的性格

这时大模型就可以给出更满意的名字，比如：

• 橘宝 - 橘色的大活宝
• 橙豆 - 橙色的小豆子，蹦蹦跳跳体现活泼性格

你看，这两个名字就跟你的猫更贴切了。

说白了，Prompt Engineering 就是一门调整大模型提示词的技术。 就是这么简单。

不过如今，Prompt Engineering 已经很少被单独提起了：

• 一方面它的门槛实在太低
• 另一方面模型本身的能力变得更强了，很多时候不需要在 Prompt 上调来调去也能给出不错的回答

Context Engineering：如何给信息

我们继续用小猫来举例。假设你拿到了小猫的名字之后，还继续跟大模型聊天：

那它平时吃什么好呢？

这就是我们的新 Prompt。但重点来了：我们此时要发给大模型的，其实不仅仅有这个 Prompt，还有之前的对话历史。这样大模型才知道这个新问题里面的"它"指代的是什么。

无论是 Prompt 还是对话历史，它们都是大模型所接收到的信息。我们把大模型所接收的所有信息起个名字，就叫做 Context（上下文）。

当然，Context 的内容还不只有这两个，它还包括：

• 工具列表
• Skill 列表
• 其他相关信息

关键是：Context 是有容量上限的。 所以我们不可能无止境地往里面塞东西，需要精心设计 Context 里面的内容，这就叫做 Context Engineering。

Context Engineering 的经典技术

1. 上下文压缩

对话历史会越聊越多，当超过某个阈值时，我们可以使用上下文压缩技术把之前的对话历史做个总结，以防止 Context 里面的内容过多影响回答效果。

2. 动态检索外部资料

根据当前问题动态检索相关的外部资料，只把最相关的内容放入 Context。

3. 渐进式披露

根据对话进展逐步披露信息，而不是一开始就把所有信息都塞进去。

可以看出，Context Engineering 还是挺能"整活"的，搞出了这么多东西。不过这依然不是终点，因为大家发现 Context Engineering 这门技术的效果是有一定上限的。

为了进一步榨干大模型的潜力，AI 圈又整出了新花样——这就引出了我们今天真正的主角：Harness Engineering。

什么是 Harness Engineering

要搞明白 Harness Engineering 这个概念，我们得先从 Harness 这个单词说起。

Harness 的本意：马具

Harness 这个词在日常生活中其实不太常见，很多人可能也是第一次听说。Harness 的本意其实是马具的意思，就是套在马身上用来控制马的那些装备，比如缰绳、头套等。

虽然马非常强大，但我们必须借助马具的力量来限制马的活动，这样我们才能够让马为我们人类所用。

从马具到 AI Harness

现在我们来做一个类比：

• 脱掉马具的马 ↔ AI 领域里的大模型
• 马具（Harness） ↔ 控制大模型的系统

大模型特别强，尤其是像 GPT-4、Claude Opus 这样的顶级模型，能干的事情太多了。但大模型就像马一样，如果我们不对它加以干预，任由大模型自己去运行和发挥，那它就会像脱缰的野马一样发散思维，甚至产生严重的幻觉，最终根本无法稳定地给我们想要的结果。

所以我们必须要把大模型给控制住，就像用马具来控制马一样。而这套用来控制大模型的系统，就被称为了 Harness。

Harness 的公式

从这一点出发，我们就能推导出 Harness 的公式：

Harness = Agent - Model

换句话说，一个完整的 Agent 减去里面的大模型，剩下的所有东西都是 Harness。

⚠️ 需要注意的是，Harness Engineering 是一个非常新的概念，目前业界还没有形成严格的定义。这个公式只是目前大多数人比较认可的一种说法，并非严格的学术定义。

简单来说：只要不是大模型，就是 Harness。

具体例子：Claude Code

我们可以用 Claude Code 来举例。在 Claude Code 里面，所有不属于 Claude 模型的部分都是 Harness，比如：

1. 写在 CLAUDE.md 里面的规则 - 大模型要遵循的规则
2. 可用工具列表 - Claude Code 可以使用的工具
3. 定时调度机制 - 任务的调度和执行机制
4. 权限管控 - 访问权限的控制
5. 工具管理 - 工具的注册、调用和管理

这些都是 Harness 的一部分。

什么是 Harness Engineering

明白了 Harness 的概念，Harness Engineering 的概念也就呼之欲出了：

Harness Engineering 就是一门专门研究如何构建与设计 Harness 的技术。

换句话说，就是除了大模型本身不研究，别的什么都研究。

它不再是紧紧盯着模型输入的那点提示词或者上下文，而是站在更高的系统层面上，研究怎么给大模型设计一套可以稳定运行的系统，让大模型能够踏踏实实地为我们人类做事。

三者的关系：层层递进

从这里可以看出，Prompt Engineering、Context Engineering 和 Harness Engineering 更像是一种层层递进、研究范围不断向外扩展的关系：

技术	研究对象	研究范围
Prompt Engineering	怎么问问题	如何组织 Prompt，把发给大模型的话说得更清楚、更准确
Context Engineering	怎么给信息	怎么在最合适的时机，把最合适的内容放到模型的 Context 里面（包括 Prompt、工具列表、对话历史等）
Harness Engineering	怎么搭建系统	如何围绕着大模型搭建一个完整可靠的 Agent（包括权限管控、工具管理等所有内容）

可以看出，它们关注的问题是越来越大、越来越广：

• Prompt Engineering 研究的是怎么问问题
• Context Engineering 的研究范围更广一些
• Harness Engineering 的研究范围最激进，直接覆盖了除大模型之外的所有内容

OpenAI 的 Harness Engineering 实践

疯狂的实验：5 个月写 100 万行代码

2025 年 8 月，OpenAI 内部启动了一个疯狂的实验：用 AI 从零开始写一个真实的软件产品，全程不允许工程师手写一行代码。

没错，这个产品的所有组成部分都是由 AI 生成的，包括：

• 业务逻辑
• 测试
• CI 配置
• 文档
• 内部工具

靠着 AI，这个项目的代码规模直接干到了将近 100 万行。而且注意了，这可不是一个玩具，它是一个真正在线上跑、有真实用户的生产系统。

成果数据：

• ⏱️ 耗时：5 个月左右
• 👥 团队规模：一开始 3 人主导，后来扩张到 7 人
• 📈 开发效率：差不多是纯人工的 10 倍

一开始并不顺利

有意思的是，这个实验一开始的进展并不顺利。这并不是因为大模型不够聪明，而是因为 Harness 没有搭建好。

工程师们发现：

• Agent 经常走错方向
• 重复犯同一个错误
• 无法稳定产出高质量代码

于是他们意识到，要想让 Agent 可靠地工作，真正的功夫在于把 Harness 设计好。

为此，他们做了大量的优化，并写了一篇文章详细记录了这个过程。下面我们就来重点聊聊 OpenAI 在 Harness Engineering 上面到底做了什么。

Harness Engineering 的三大优化方向

OpenAI 的文章从多个具体的优化点展开，信息密度非常高。这里我将这些优化点大致分为三类：

1. 上下文管理
2. 验证与反馈
3. 技术债清理

1. 上下文管理：让 Agent 获取充足的信息

想象一下，一个新入职的工程师如果对项目一无所知：

• 不清楚模块怎么划分
• 不知道代码规范是什么
• 不了解团队过去做过哪些技术决策

那他根本没办法开始工作。Agent 也是如此。

❌ 最初的尝试：超大的 AGENTS.md 文件

OpenAI 最初的尝试是把所有的项目规范和相关信息塞进一个超大的 AGENTS.md 文件，这个文件会随着用户的问题一起发给大模型。

但这个方案根本无法解决问题，原因有很多，这里说两个最关键的：

问题 1：内容太多，模型效果变差

就像你第一天去新公司报到，HR 直接砸给你一个巨厚的员工手册说"规矩全在这里，你自己看吧"。你肯定一脸懵，完全不知道该从哪里看起，也搞不清楚重点在哪。

AI 也一样，一股脑地把所有信息全部喂给它，它就迷失了，只能抓到一些碎片，真正关键的内容反而被淹没在了废话里。

问题 2：文件会逐步腐化

项目在不断演进，但文件里的内容却没人及时更新。时间一长就变成了一堆过时信息的垃圾堆。更糟糕的是，这个文件乱到连人都懒得整理，Agent 也就没办法判断哪些内容还有效了。

✅ 改进方案：分门别类的文档系统

后来他们改变了策略，把 AGENTS.md 文件压缩到只有 100 行左右，大体结构如下：

# AGENTS.md

## 项目概述
简短描述项目目标和架构

## 文档索引
- [代码规范](./docs/coding-standards.md)
- [架构设计](./docs/architecture.md)
- [技术决策](./docs/decisions.md)
- [常见问题](./docs/faq.md)

相关的文档和目录会跟 AGENTS.md 放在一起，用到哪块再给 Agent 看哪块，效果就好很多。

看来大模型跟人一样，还是要把信息分门别类地放好才行。

✅ 额外优化：仓库即事实来源

OpenAI 还发现，项目里有很多重要的信息其实并不在代码仓库里，它们可能：

• 散落在 Slack 的聊天记录里
• 躺在某个 Google Docs 的文档里
• 只存在于某个老员工的脑子里

对于 Agent 来说，它只能看见仓库里有什么，仓库外面的一切对它来说都跟不存在没区别。

所以 OpenAI 强制要求把所有重要的决策和约定都搬进代码仓库，让仓库成为唯一的事实来源。这样 Agent 就可以了解到这些外部信息了。

2. 验证与反馈：让 Agent 能够自我验证

做好了上下文管理，有了充足的信息之后，Agent 就可以写代码了。后面的重点就是在 Agent 写完代码之后，让它能够验证自己的成果是否正确。

OpenAI 的做法是给 Agent 配上足够完善的工具和 Skill，在这两者的帮助下，Agent 就能够在任务进行中随时验证自己的输出。

示例 1：接入 Chrome DevTools

他们把 Chrome DevTools 接入了 Agent 的运行环境里，这样 Agent 就可以：

• 自己截图
• 自己查看 DOM 结构
• 自己模拟用户操作

从而验证 UI 是否符合用户要求。如果发现有问题，Agent 就可以原地修复，整个过程不需要人介入。

示例 2：完整的可观测性工具栈

OpenAI 还给 Agent 接入了完整的可观测性工具栈，以便让 Agent 可以：

• 读取日志
• 读取指标
• 在必要时追踪运行链路以排查问题

为了确保日志和输出的准确性，Agent 的每个任务都跑在一个完全隔离的环境里，有自己独立的日志和指标，任务结束后也能自动销毁。

这样做了之后，OpenAI 甚至可以让 Agent 对系统做一些可量化的性能调优，比如确保服务启动时间不能超过 800 毫秒。

示例 3：架构规范的自动检测

OpenAI 把他们的系统分成了好几层，并规定了严格的依赖关系：

UI → Runtime → Service → Repo → Config → Types

每一层都只能依赖它下面的层，依赖关系不能反了（比如 Repo 层依赖 UI 层是万万不能发生的）。

OpenAI 使用 linter 和测试来避免类似情况发生：

1. Agent 生成代码后，linter 或测试开始检测代码是否合规
2. 如果不合规，报错信息会发回到 Agent
3. Agent 根据报错信息修改代码
4. 改完后再跑 linter 或测试
5. 重复几次，直到所有规则和测试全部通过

这样就形成了一个完整的自动闭环，不需要人工介入。

3. 技术债清理：垃圾回收机制

Agent 在大规模生成代码的过程中，会不可避免地引入一些糟糕的设计模式，比如：

• 重复的代码
• 偏离架构规范的写法
• 不一致的命名

慢慢积累下去会把整个代码库搞得一团糟。

OpenAI 的解法：技术债的垃圾回收

设置一个后台的 Agent 任务，定期扫描整个代码库：

1. 找出其中偏离规范的地方
2. 自动修改并提交
3. 确保代码质量始终维持在一个比较高的水准

文档也需要垃圾回收

除了代码，他们还对文档做了同样的事情：

1. 设置后台任务定期扫描整个文档库
2. 找出那些过时的、和实际代码对不上的文档
3. 自动提交修复

所以你看，无论是代码还是文档，OpenAI 都有一套对应的维护方案，两边都不会放任自流。

OpenAI 的核心理念

通过这五个月的疯狂实验，OpenAI 不仅跑通了这套 100 万行代码的系统，更重要的是，他们在这个过程中重新定义了人类和 AI 在未来的工作边界。

在文章中，OpenAI 抛出了一个非常关键的断言：

“Humans steer, Agents execute”
翻译：人类负责掌舵，Agent 负责干活

工作边界的转变：

以前	现在
工程师手写业务代码、造轮子	人类定方向、定规范、做顶层决策
自己查报错、手动跑测试	Agent 在完备 Harness 里自主执行开发、自测
文档、规范靠人维护	系统自动化维护代码与文档质量

新的职责定义：

虽然人类不再需要亲自手写代码，但软件工程的工作并没有消失，而是演变成了完全不同的形态。

如今软件工程师的核心职责变了，变成了为 Agent 搭建稳定可靠的系统与支撑框架，以此来尽可能地提高代码产出效率。

这两个观点可以说是 OpenAI 那篇文章的灵魂，它直接告诉我们：

Harness Engineering 不仅仅是如何写好 Prompt 或如何管理上下文这么简单，它是在重塑整个软件工程的开发流程。

Anthropic 的 Harness 架构

Anthropic 发表了两篇与 Harness Engineering 相关的重要文章：

1. 2024 年 11 月：Effective Harnesses for Long-Running Agents - 讲述如何配置环境以便让 Agent 长时间自主运行
2. 2025 年 3 月：Harness Design for Long-Running Application Development - 在第一篇基础上对 Harness 架构做了进一步优化

这两篇文章信息量很大，总结下来最核心的地方就两点：

• 任务规划
• 质量评估

问题 1：任务规划

实验：克隆 claude.ai

在第一篇文章中，Anthropic 做了一个实验：直接让 Agent 执行一个任务——克隆 claude.ai。

claude.ai 就是 Claude 的聊天界面，跟 ChatGPT 是同类型产品。虽然看起来只是一个聊天界面，但背后的功能还是挺多的，一口气做出来几乎不可能。

遇到的问题：

在 Anthropic 的实验里，Agent 接到需求后立马就开干了，干劲非常足，但效果也非常不好。主要是因为这个需求的工作量实在太大了，直接给到 Agent 的话，Agent 就会急于求成，从而引发一系列问题：

1. 上下文溢出：总想一口气把所有功能全部做完，结果干到一半上下文就满了，直接抛下烂摊子
2. 接手混乱：等下一个 Agent 接手时，完全不知道前面发生了什么，只能靠猜
3. 误判完成：虽然有些功能只做了一半，但接手的 Agent 并不知道，粗略扫了一眼还以为已经大功告成，于是直接宣布完工

解决方案 1：引入 Initializer Agent

Anthropic 在第一篇文章里引入了一个叫做 Initializer 的 Agent。从这个名字就可以看出，这个 Agent 就是用来初始化执行环境的。

Initializer 的职责：

• 拆解用户需求
• 编写启动脚本
• 添加进度文件

最核心的是拆解用户需求：把用户的需求拆解为一个详细的功能列表。后续负责干活的 Agent 就可以直接拿着这个功能列表去干活，而且会一个功能点一个功能点地做，做完一个标记一个，这样稳扎稳打，整个流程的可控性就高了很多。

解决方案 2：独立的 Planner Agent

后来在写第二篇文章时，Anthropic 对这个思路做了演进。他们把 Initializer 里面最核心的一件事情——拆解用户需求——单独拿出来，做成了一个新的 Agent 叫做 Planner。

Planner 的职责：

• 把用户模糊的需求扩展成一份完整清晰的功能列表
• 这样后面 Agent 在写代码时就不用对着用户的需求猜了，照着功能点一个个做就行

问题 2：质量评估

一般来说，光是让 Agent 生成代码是不够的，我们还需要对它生成的代码做一些质量评估。如果产出质量不行，我们需要把对应的问题列表发回给 Agent，以便让它做相应的修改。

方案对比

方案	核心做法	优点	缺点
人工评估	人类逐条审核 Agent 产出	质量最靠谱，能发现细微问题	效率极低，成本高，无法规模化
Agent 自评	Agent 自己开发、自己校验	成本低，反馈快	有"自我滤镜"，容易包庇自己的 bug，评估流于形式
独立 Evaluator	第三方 Agent 专职做评估	客观中立，可单独迭代优化，可规模化	需要额外开发，对 Evaluator 本身质量有要求

✅ 方案 3：独立的 Evaluator Agent

Anthropic 搞出了第三个方案：做一个专门的评估 Agent 来评估产出质量。

优势：

1. 客观性：由于这个评估 Agent 是一个独立的第三方，它自然就没有理由去替别的 Agent 产出护短，评估结果也就客观多了
2. 可优化性：把评估 Agent 单独拎出来，我们可以单独去优化、去训练这个评估 Agent，让它的评估效果做到最好

最终方案：

• 把生成代码和质量评估这两件事情拆开
• 分别交给两个不同的 Agent 来做：
  • Generator：负责生成代码
  • Evaluator：负责质量评估

Full Harness 架构：三 Agent 协作

加上之前提到的 Planner，我们现在有三个 Agent 了：

1. Planner - 任务规划
2. Generator - 代码生成
3. Evaluator - 质量评估

工作流程

1. Planner 拆解需求
   ↓
   生成功能列表
   ↓
2. Generator 选择一个功能点
   ↓
   与 Evaluator 讨论交付标准
   ↓
   (多次往返直到标准确定)
   ↓
3. Generator 生成代码实现功能
   ↓
   提交结果给 Evaluator
   ↓
4. Evaluator 评估反馈
   ↓
   (多次往返直到评估通过)
   ↓
5. 重复步骤 2-4，直到所有功能点完成

Anthropic 把这个包含了三个 Agent 的方案叫做 Full Harness 方案。

相比之下，那种只靠一个 Generator 独立完成所有需求的传统单 Agent 模式，被 Anthropic 称为 Solo 方案。

效果对比：Solo vs Full Harness

Anthropic 拿了一个具体的任务来验证这两个方案的差距：做一个游戏制作工具。

Solo 方案的问题

• 布局不合理
• 产品逻辑难以理解
• bug 到处都是
• 基本上没办法用

Full Harness 方案的改善

• 布局合理
• 整体产品逻辑达到了可用水准
• 虽然还存在一些问题，但比 Solo 方案明显要好不少

代价对比

方案	耗时	花费
Solo	20 分钟	$9
Full Harness	6 小时	$200

可以看出，Full Harness 的方案无论是耗时还是花费都要远高于 Solo 方案。虽然如此，但不得不承认，Full Harness 的方案效果确实好了不少。

毕竟精雕细琢是有代价的——这对我们人类来说也是一样，考 60 分可能只需要复习三天，但想考 90 分可能就得复习一个月了。

模型进化：从 Sonnet 3.5 到 Opus 4.6

最后再提一个 Anthropic 后来做的优化点。

在之前的流程中，Generator 每次只会选取一个功能点，做完这个功能点再做下一个，循环往复直到完成所有功能点为止。这个逻辑是 Anthropic 在提示词里面强制 Generator 这么处理的，否则让 Generator 自行发挥，它还是会急于求成，最后留下一堆烂摊子。

但在 Opus 4.6 发布之后，这个约束就不怎么需要了。

Anthropic 后面就把这一部分给去掉了，最后简化成了更自由的流程：

1. Planner 拆解需求 → 生成所有功能点
   ↓
2. Generator 一次拿到所有功能点
   ↓
   自己决定先做哪个、再做哪个
   ↓
   稳步向前推进
   ↓
3. Evaluator 评估最终产出

为什么后面就可以这么做了？

因为基于 Opus 4.6 做的 Generator 变得更强了。它可以一次把所有的功能点全部都拿过来，自己决定先做哪个再做哪个，稳步地向前推进，不需要别人再对它的执行流程指指点点。

在这种情况下，Evaluator 也直接评估最终产出就可以了，不需要再分功能点评估了。

这个变化预示着什么？我们会在下一章节详细讨论。

Harness Engineering 是噱头吗

Harness Engineering 是怎么火起来的

Harness 并不是新词

首先，单就 Harness 这个词来说，其实它并不算是一个彻头彻尾的新词。一般大家用它来指代为了支持某个功能所做的一套框架。

几个具体例子：

1. Test Harness（测试领域）

   • 代表为了支持测试代码运行而做的一套框架
   • 这个框架里可能包含测试运行器、测试环境等

2. lm-evaluation-harness（开源项目）

   • 为了支持模型效果评估而做的一套框架

3. Anthropic 2024 年 11 月的文章

   • Effective Harnesses for Long-Running Agents
   • 这里的 Harness 代表为了支持 Agent 长时间运行而做的一套框架

所以你看，Harness 这个概念一直都在那儿，大家也都在默默地用，谁也没觉得这是个需要大吹特吹的新概念。

可以说，Harness 这个词本身并不是重点，重点是 Harness Engineering。

Harness Engineering 的起点

把 Harness 和 Engineering 这两个词组合在一起，其实是最近才发生的事。

2025 年 2 月 5 日 - Mitchell Hashimoto 发表文章 My AI Adoption Journey

目前比较公认的起点，就是这篇文章。作者 Mitchell Hashimoto 在海外技术圈是响当当的人物，很多大公司的底层工具都是他做的。

在这篇博客里，他写了这么一段话：

“我也不知道业界有没有公认的叫法，我就姑且管它叫 Harness Engineering。它的核心理念就是，只要 Agent 犯了错，你就去改造系统，让它绝不再犯同样的错。要是有更好的词，我随时改口。”

你看，大佬还是很实诚的。所以这个词的起点其实非常朴素，甚至带着点随意，跟后来大家讨论的宏大概念还是有区别的。

从传播情况来看，这篇文章的讨论热度其实并不算很高。

真正的引爆点

2025 年 2 月 11 日 - OpenAI 发表 Harness Engineering 文章

在很多人的认知里，真正引爆这个概念的是 OpenAI 发的那篇文章（就是我们之前讲过的那个 100 万行代码的实验）。

这篇文章信息量极大，迅速就在业界引起了巨大反响。

2025 年 2 月 17 日 - Martin Fowler 网站发文

仅仅 6 天后，软件工程界鼎鼎大名的 Martin Fowler 网站就发了一篇文章：Harness Engineering - First Thoughts

作为顶级技术博客，这篇文章一发出来自然就在圈内引发了广泛的讨论。

但抛开技术观点不谈，她在文章里还点出了一个很耐人寻味的细节：

虽然 OpenAI 这篇文章的标题有 Harness Engineering 这两个词，但如果你仔细去翻 OpenAI 的文章，你会发现这篇文章的正文里其实只提了一次 Harness 这个词。

因此她推测，OpenAI 搞不好就是受了 Mitchell Hashimoto 的启发，事后才临时把 Harness Engineering 这个词放到了标题里面。

虽然只是个猜测，但也给人带来了很大的联想空间。

2025 年 3 月 10 日 - LangChain 发文

LangChain 发了一篇文章叫 The Anatomy of an Agent Harness，这篇文章第一次明确给出了关于 Harness 的公式：

Agent = Model + Harness

这其实就是我们前面聊过的那个公式的变体。公式一出，概念就算定调了。

2025 年 3 月 24 日 - Anthropic 发文

Anthropic 发了那篇 Harness 的文章，拿出了 Planner、Generator 和 Evaluator 的经典架构（我们之前讲过）。

虽然 Anthropic 自己比较克制，通篇依然只用了 Harness 这个名词，并没有生搬硬套 Harness Engineering 这个刚刚炒热的新词，但在当时那个氛围下，整个 AI 圈可以说是心照不宣，直接就把这套三 Agent 架构当成了 Harness Engineering 的教科书级案例。

就这样，一传十，十传百，Harness Engineering 从一个人的私人说法，变成了大家都在用的词。

怀疑论者的声音

但如果你复盘完这段历史，再仔细琢磨一下，就会发现一件非常微妙的事情：

Harness Engineering 里用到的所有技术，竟然没有一个是新的。

我们前面讲的：

• Linter 代码检查
• 任务拆解规划
• 质量评估机制

这些东西其实早就有了，相信看这篇文章的很多读者甚至都在做相关的工作。

Harness Engineering 真正做的，只是把这些技术重新组织了下，统一放到了一个新词下面。

换句话说，它提供的是一套新的系统思维框架，而不是发明了一批颠覆性的新技术。

既然没什么新技术，那难怪有些人会觉得 Harness Engineering 这个概念被高估了，甚至带着点"炒作"的成分。

怀疑论者的两大攻击点

1. 新瓶装旧酒

Harness Engineering 根本没有新东西，全都是"新瓶装旧酒"。在这种情况下，特意造个新词到处宣传，可不就是噱头吗？

2. 终将被模型能力淘汰

这波怀疑论者还提出了一个更扎心的观点：所有的 Harness Engineering 都迟早要被淘汰。

他们认为，随着大模型自身能力的持续进化，今天看起来必不可少的这些 Harness 设计，未来很可能会被模型能力本身逐步吸收，最终变得不再需要。

证据：模型在吞噬 Harness

而这种担忧，其实连 Anthropic 自己的文章里都有迹可循。

我们前面讲过 Anthropic 的 Harness 核心方案，但文章里还有很多细节很值得细细品味。这里我们仔细研究两个问题：

案例 1：上下文焦虑

问题描述：

这是 Sonnet 3.5 的一个问题。具体来说，就是当上下文过长时，模型会急于结束任务，以更少的 token 完成交付，而这往往会影响最终质量。

Harness Engineering 解决方案：

Anthropic 一开始使用了一种叫做上下文重置的 Harness Engineering 技术来解决这个问题。

模型能力提升后：

当模型升级到更强的 Opus 4.5 后，这种现象被大幅缓解。因为 Opus 4.5 没有明显的上下文焦虑问题了，也就不怎么需要这方面的 Harness Engineering 设计。

案例 2：长任务执行效果差

问题描述：

让我们回忆一下 Anthropic 的链路：Planner → Generator → Evaluator

一开始的设计是逐个功能点执行，也就是说，Anthropic 会在提示词里面强制 Generator 每次只选取一个功能点，做完一个再做下一个，以便确保整个产品开发流程稳步向前推进。

Harness Engineering 解决方案：

在提示词里强制分步执行，确保 Agent 不会急于求成。

模型能力提升后：

等用到更强的 Opus 4.6 之后，这种强制分步执行的机制就不需要了。因为 Opus 4.6 的全局统筹能力够强，它可以一次把所有的功能点都拿过来，自己决定先做哪个再做哪个，稳步推进，不需要别人对它的执行流程指指点点。

结论：模型越强，需要的 Harness 就越少

你看，这恰恰印证了一个非常现实的趋势：

模型越强，需要的 Harness 就越少。大模型自身的进化，正在一口一口吃掉 Harness Engineering 的生存空间。

当然，为了严谨起见，我需要补充一句：Anthropic 官方在文章里其实没这么悲观。他们认为，随着模型变强，Harness 的形态也会跟着进化，去解锁更复杂的任务。也就是说，Harness 只会变形，不会消失。

但我们不妨大胆推演一下：

如果未来的模型真的强到离谱呢？

这并不是说未来连读写文件、联网搜索这种基础工具都不需要了，而是说，也许只要给大模型配置上最基础的 Harness，它自己就能把剩下 99% 的问题全搞定。

真到了那一天，Harness Engineering 就不再是一门需要大家专门去钻研的技术了，它会退化成一个单纯的环境接口、一个底层基础设施。

仔细想想，这件事发生的概率，恐怕没有那么低吧。

我的观点

说了这么多，我们还得回归原来的问题：Harness Engineering 到底是不是噱头？

这里我来聊下我个人的看法，可能有误，仅供参考：

Harness Engineering 不是噱头，但应该也不是终局。

为什么说不是噱头

说它不是噱头，是因为它已经实实在在带来了效果。

无论是 OpenAI 还是 Anthropic，都通过 Harness Engineering 把 Agent 的稳定性、自动化程度和生产力往前推了一大步。这些都是可以被验证的工程成果，而不是概念炒作。

当然，也有人会说，它不过是"新瓶装旧酒"，用的都是老技术。

但问题在于，工程领域真正的进步，往往不在于发明了什么新技术，而在于有没有一套统一的框架，把这些零散的能力组织起来，变成可以系统设计、可以持续优化的工程方法。

Harness Engineering 的意义，恰恰就在这里。

为什么说不是终局

但我不得不承认，Harness Engineering 大概率不是终局。

随着模型能力继续增强，今天这些用来约束模型、纠正模型、给模型兜底的系统设计，很可能会被模型自身逐步吸收。

到那个时候，很多 Harness 可能会变得不再必要，这个词也许会慢慢淡出大家的视野。

所以我更愿意把它看成一个过渡期的关键技术：

• 它可能不是未来的终局答案
• 但它是当下最现实的答案

当下的价值

因为让我们回到今天：

• 模型依然会犯错
• 依然会幻觉
• 依然会在复杂任务中偏离轨道

在这种现实下，Harness Engineering 的重要性就不容忽视。

可以说，谁能把 Harness 搭得更稳，谁就能更早把 AI 的能力转化成真正的生产力，从而从中受益。

总结

经过这么长的篇幅，我们从 Prompt Engineering 和 Context Engineering 讲起，深入探讨了 Harness Engineering 的概念、实践和争议。现在让我们来做个总结。

维度	核心结论
技术演进	Prompt → Context → Harness，从话术 → 信息 → 系统架构逐层升级
核心公式	Harness = Agent - LLM，除大模型外所有支撑体系都是 Harness
OpenAI 实践	上下文治理、自动校验闭环、技术债自动化清理；人类掌舵、Agent 执行
Anthropic 架构	Planner+Generator+Evaluator 三角色分工，牺牲时间成本换产出稳定性
行业争议	新瓶装旧酒，但提供工程化框架；长期模型会弱化大部分 Harness
开发者启示	不用追概念，重点学：信息治理、任务拆解、自动化校验、分层架构

最后的思考

Harness Engineering 的出现，标志着我们对 AI Agent 的认知从"如何对话"上升到了"如何构建系统"。

这不仅仅是技术上的进步，更是思维方式的转变：

• 我们不再满足于让 AI 回答单个问题
• 而是要让 AI 能够稳定地完成复杂的、长期的工作

在这个过程中，Harness Engineering 提供了一套系统化的方法论。

虽然随着模型能力的提升，今天的很多 Harness 设计可能会变得不再必要，但工程化思维本身是永恒的。

无论未来模型多么强大，我们始终需要：

• 合理的架构设计
• 可靠的质量保障
• 清晰的流程规范

这些工程化的理念，才是 Harness Engineering 留给我们最宝贵的财富。

---

参考资料：

1. Mitchell Hashimoto - My AI Adoption Journey (2025.02.05)
2. OpenAI - Harness Engineering (2025.02.11)
3. Martin Fowler - Harness Engineering - First Thoughts (2025.02.17)
4. LangChain - The Anatomy of an Agent Harness (2025.03.10)
5. Anthropic - Effective Harnesses for Long-Running Agents (2024.11)
6. Anthropic - Harness Design for Long-Running Application Development (2025.03.24)

---

写在最后：

AI 技术日新月异，新概念层出不穷。在追逐新概念的同时，我们更应该关注其背后的本质和价值。

Harness Engineering 也许只是一个过渡期的名词，但它所代表的系统化思维，将会长期指导我们构建更好的 AI 应用。

希望这篇文章能帮助你理解 Harness Engineering 的来龙去脉，并在实践中有所收获。