最近 Harness Engineering 这个词很热。

一开始我也以为，这可能只是 Agent 圈里又一个新概念。
但看完 OpenAI 的相关文章，再结合这段时间自己对 Codex、Claude Code 以及一些工程化实践的观察，我越来越觉得，它其实不是一个“新瓶装旧酒”的词，而是在 AI 编程真正进入工程阶段之后，一个很自然的收束。

如果说前两年大家还在讨论“怎么和模型说话”，那现在更现实的问题已经变成了：

怎么给模型一个能工作的环境，并让它稳定地产出结果。

这也是我想写这篇文章的原因。
一方面是给自己做个阶段性整理，另一方面也想在团队里把这个概念讲清楚。因为它不只是一个新名词，而是很可能会影响之后一段时间工程师工作方式的东西。

术语为什么会一路演进？

这几年和 AI 打交道，大家的关注点其实一直在变。

第一阶段：提示工程

大概是 2023 到 2024 年，核心问题是：

怎么跟 AI 说话。

那个阶段大家主要在研究：

• 怎么写提示词
• 怎么组织输入输出格式
• 怎么让模型一次性回答得更准一点

本质上，它还是围绕单轮交互展开的。
你把问题提得越清楚，模型就越容易给出一个“像样的答案”。

第二阶段：上下文工程

到了 2025 年，问题开始变化。

大家逐渐发现，影响模型效果的，不只是“怎么说”，还有：

你到底给它看了什么。

于是话题开始转向：

• 系统提示词怎么组织
• 记忆怎么存
• RAG 检索怎么喂
• 工具调用怎么接
• 长上下文怎么压缩，怎么避免污染

这时候，AI 的工作方式已经不再是简单问答，而开始像一个“带上下文、带工具、能连续执行”的系统。

第三阶段：Harness Engineering

再往后，问题就更具体了。

因为当 Agent 真开始写代码、改文件、跑命令、查日志、调用外部系统时，大家很快会遇到一个现实：

模型再强，如果工作环境不对，结果一样不可靠。

所以 Harness Engineering 关注的就不再只是提示词或者上下文，而是：

我们到底要构建一个什么样的环境，让 AI 可以在里面工作，并且这个工作过程是可控、可验证、可重复的。

什么是 Harness？

我比较认同的一种理解是：

为了保证任务可靠交付，在 Model 之外做的一切，几乎都可以算作 Harness。

模型提供智能，Harness 让这种智能真正变得有用。

如果把话说得更直接一点：

• 模型负责推理
• Harness 负责约束、补全、验证和交付

也就是说，真正决定一个 Agent 能不能落地的，往往不是“底座模型够不够聪明”，而是你有没有给它配上一套足够好的工作台。

Harness 里面通常包含什么？

从现在主流的编码 Agent 实践来看，Harness 大致会包含下面这些部分。

1. 文件系统和工作空间

这是最基础的一层。

Agent 不是在真空里工作的，它需要：

• 一个可操作的工作目录
• 清晰的文件结构
• 对代码仓库的访问能力
• Git 这样的版本控制能力

如果没有这些，所谓“写代码”就只能停留在聊天窗口里。
而一旦进入真实文件系统，Agent 才能改代码、看配置、理解项目结构，甚至和其他 Agent 协作。

2. Bash、工具链和 Sandbox

这部分很关键，因为它决定了 Agent 能不能进入“自我验证循环”。

一个真正可用的编码 Agent，不只是生成代码，而是要能完成这样一个闭环：

写 -> 跑 -> 看 -> 修 -> 再跑

这背后依赖的是：

• 终端命令执行能力
• 安全隔离机制
• 对输出结果的可观察性

没有 Sandbox，权限边界会出问题。
没有命令执行，Agent 就很难验证自己的修改。
没有日志和返回结果，它也无法判断自己到底修好了没有。

3. 记忆与约束注入

这里我觉得 AGENTS.md 是个特别典型的例子。

它不是拿来堆百科全书的，而更像一个入口文件，告诉 Agent：

• 这个仓库是干什么的
• 有哪些规则必须遵守
• 常用命令是什么
• 更深的知识该去哪里找

也就是说，记忆系统的重点不是“塞更多内容”，而是“在正确的时候注入正确的信息”。

4. Web Search 和 MCP

如果 Agent 只能依赖训练时的知识，它的能力上限会很快暴露出来。

所以现实里通常还需要两类补充：

• Web Search：解决知识截止日期问题
• MCP / 外部工具：让它访问训练后、甚至组织内部的实时信息

这一步的意义，不是让 Agent 变得更“博学”，而是让它开始具备真实世界里的操作性。

5. 上下文工程

上下文工程并没有消失，它只是成了 Harness 的一个组成部分。

因为一旦任务变长、链路变深，就一定会遇到这些问题：

• 上下文越来越脏
• 关键信息被淹没
• Token 消耗失控
• Agent 开始在错误前提上连续推理

所以你还是需要：

• 压缩
• 分层
• 渐进式加载
• Skill 化组织

这件事的本质，是对抗上下文腐化。

6. 编排、Hooks 和多 Agent 协作

当任务进一步变复杂，单个 Agent 往往已经不够用了。

这时候就会进入另一层能力建设：

• 子 Agent 调度
• 任务拆分与分发
• 模型路由
• Hooks 注入确定性流程

这一层其实很像传统工程里的 orchestration，只不过现在被编排的对象，开始从“服务”变成“智能体”。

那 Agent 又是什么？

如果只用一句话来概括，我会说：

Agent = Model + Harness

模型负责智能，Harness 负责把这种智能组织成一个能完成任务的系统。

所以 Agent 从来都不只是“大模型套壳”。
它更像一个带推理能力的执行系统，目标可以很简单，也可以很开放。但无论任务复杂度如何，只要你希望它能稳定完成，就绕不开 Harness。

这也是为什么现在越来越多团队开始讨论多智能体。
不是因为“多个 Agent 听起来更酷”，而是因为复杂任务天然需要角色分工、上下文隔离和并行协作。

回到 Coding：工程上该怎么落地？

如果把视角放回编码场景，Codex、Claude Code 这一类产品，其实已经把 Harness Engineering 的很多要素摆在台面上了。

它们让我们看到一个很明确的方向：

工程师的角色，正在从“亲自写完每一行代码”，转向“设计一个让智能体高效工作的系统”。

这里面我觉得有几个点特别重要。

1. 工程师的重点，开始转向系统和杠杆

以后真正有价值的，不只是写代码本身，而是：

• 怎么定义约束
• 怎么设计工作流
• 怎么搭建反馈闭环
• 怎么让 Agent 产出可验证、可复用

也就是说，工程师的杠杆点在上移。
不是减少技术要求，反而是对系统设计能力提出了更高要求。

2. 提高“面向 Agent”的可读性

以前说代码可读性，默认读者是人。

但现在还要多问一句：

这套系统对 Agent 可读吗？

这个“可读”，不只是代码缩进漂亮、命名规整，而是更偏执行层面的可理解性：

• 页面结构是否清楚，便于 Agent 理解 UI
• 日志是否足够清晰，便于定位错误
• 堆栈是否完整，便于复现问题
• 命令输出是否稳定，便于继续推理

换句话说，很多过去只是“工程习惯”的东西，到了 Agent 时代会直接影响产出质量。

3. 把代码仓库当作记录系统

这一点我非常认同。

不要把 AGENTS.md 写成一份无穷无尽的大说明书，而是把它当成 目录。
真正的知识，应该沉淀在代码仓库里结构化的位置。

一个比较理想的形态，大概像这样：

AGENTS.md
ARCHITECTURE.md
docs/
├── design-docs/
│   ├── index.md
│   ├── core-beliefs.md
│   └── ...
├── exec-plans/
│   ├── active/
│   ├── completed/
│   └── tech-debt-tracker.md
├── generated/
│   └── db-schema.md
├── product-specs/
│   ├── index.md
│   ├── new-user-onboarding.md
│   └── ...
├── references/
│   ├── design-system-reference-llms.txt
│   ├── nixpacks-llms.txt
│   ├── uv-llms.txt
│   └── ...
├── DESIGN.md
├── FRONTEND.md
├── PLANS.md
├── PRODUCT_SENSE.md
├── QUALITY_SCORE.md
├── RELIABILITY.md
└── SECURITY.md

这里最关键的，不是目录长什么样，而是一个原则：

让 Agent 能顺着目录，找到真实、最新、结构化的信息源。

因为从 Agent 的视角看，运行时拿不到的信息，就等于不存在。

4. 让仓库本身具备“可推理性”

过去我们说“文档要写给人看”，现在其实还要多一层：

文档、日志、代码结构，都要让 Agent 能推理。

这意味着很多团队之后要补的，可能不是某个模型接入，而是这些更基础的东西：

• 缺失的架构文档
• 失真的 README
• 不可运行的示例
• 混乱的目录结构
• 无法复现问题的日志

这些东西，以前影响的是人协作效率。
现在还会直接影响 Agent 的工作上限。

最后

我现在越来越觉得，Harness Engineering 之所以重要，不是因为它提出了一个多么玄妙的新理论，而是因为它把一件事说透了：

在 Agent 时代，决定结果质量的，已经不只是模型本身，而是模型所处的整个工作环境。

谁能把这个环境搭得更清楚、更稳定、更可验证，谁的 Agent 就更有机会真正进入生产。

从这个角度看，Harness 其实也不只是“给 AI 加一层壳”。
它更像是一套新的工程基础设施。

而对工程师来说，这件事的意义也很直接：

以后我们不只是写系统，也是在给智能体修建工作台。

参考阅读：

• OpenAI: Harnessing the future of software engineering