Harness 工程：不是新词，而是 Agent 工程终于被讲明白了

作者：mCell
阅读时长：约 15 分钟阅读
同步站点：https://stack.mcell.top/blog

点击上方 程序员成长指北，关注公众号
回复1，加入高级Node交流群

最近，Agent 圈突然开始密集讨论一个词：Harness。

很多人第一次看到它，会觉得这是个新框架、新范式，甚至像是什么「下一代 Agent 技术名词」。

但我看了一圈后，第一反应其实很简单：

这不就是我之前在做 memo code 时，一直在做的那套东西吗？

更准确一点说：

Harness 不是一个新技术发明。它更像是 Agent 工程里那部分一直存在、但过去没有被完整命名的「软件工程现实」。

前段时间我去高校做 Agent 开发交流时，也一直在讲一个非常朴素的判断：

Agent = Loop(LLM + Context + Tools)

这个 loop 本身并不复杂。

真正难的，还是 软件工程。

现在回头看，所谓 Harness，某种意义上就是把我当时说的「软件工程」这件事，给具象化了、命名了、体系化了。OpenAI 在 2026 年 2 月发布的官方文章里，几乎就是这么描述的：工程师的工作正从「写代码」转向「设计环境、指定意图、建立反馈回路，让 agent 能可靠工作」；他们甚至用小团队在几个月里借助 Codex 产出约百万行代码作为案例。

所以这篇文章，我不想把 Harness 当作一个「热词解读」。

我更想做另一件事：

把 Harness 这件事，从 Agent 工程的角度，完整讲明白。

Harness 到底是什么？

先说我的定义：

Harness 不是模型。不是 Prompt。不是 Tool Call。不是框架。 Harness 是 Agent 运行时的「工程环境总和」。

这个「环境总和」里包含什么？

至少包括这几类东西：

1. 任务如何被表达

2. 上下文如何被组织

3. 工具如何被暴露、治理、拦截

4. 状态如何被保存、恢复、裁剪

5. 反馈如何回流给模型

6. 错误如何被分类、重试、升级

7. 安全边界如何被建立

8. 系统如何验证 agent 真的把事做好了

如果你把 Agent 想成一个「会调用工具的大脑」，那 Harness 就是：

你给这个大脑配的身体、传感器、护栏、操作台、流程制度、回执系统，以及出事后的保险。

所以我更愿意把它翻成：

Harness = 驾驭系统

或者更工程一点：

Harness = 让 Agent 能被稳定驾驭的环境系统

OpenAI 后续关于 Codex App Server 的文章也把这件事说得更具体：所谓 harness，不只是「用户-模型-工具」的核心 loop，还包括线程生命周期与持久化、配置和鉴权、工具执行与扩展、客户端与运行时之间的协议层。也就是说，真正的 harness 不是一个 prompt 文件，而是一个完整运行时。

为什么这个词现在突然火了？

因为行业终于开始承认一件事：

Agent 的问题，越来越不是「模型够不够聪明」，而是「环境够不够好」。

同一个模型，放到不同系统里，表现会差得非常大。

有的 agent：

• 会乱调工具

• 会丢上下文

• 会把安全边界踩穿

• 会在长任务里越来越漂

• 会越来越像「有工具的聊天机器人」

而有的 agent：

• 能持续做事

• 能沿着目标推进

• 能利用反馈修正自己

• 能在复杂任务里保持结构感

• 甚至能让一个不算新的模型，也表现得很像样

这也是我当时做 memo code 时非常在意的一点。

我故意没有把测试重心放在「最新最强模型」上。相反，我很长一段时间都在用一个已经发布将近一年的 DeepSeek 模型来测。原因很简单：

我想验证的不是「模型天赋有多高」，而是「环境设计能把一个普通模型托到什么程度」。

如果一个相对古早的模型，在这套环境里仍然能做成事，那说明这套工程方向是对的。这比「换个新模型突然变强」更有价值。

这也和最近公开的一些工程经验是对齐的。OpenAI 把重点放在 scaffolding、环境约束、反馈回路和可读代码库上；OPENDEV 那篇论文则把重点放在安全控制、上下文压缩、工作负载路由、记忆系统和事件驱动提醒上。两边说法不同，但本质一致：

Agent 的能力，不只是模型能力，而是模型 × 环境。

为什么我一直说：Agent 的核心很简单，难点仍然是软件工程？

因为从原理上讲，Agent 真的不复杂。

我在分享里说过：

Agent = Loop(LLM + Context + Tools)

或者更直白一点：

在一个循环里面，提供一些工具、维护一个上下文，再调用大模型。

这件事的抽象层面，你甚至十几分钟就能给它写个最小版本。你给模型一个 system prompt，给它几个 tools，让它在循环里不断决定「要不要继续做事」，这就已经是 agent 了。

所以真正的问题不在「能不能做出一个 loop」。

真正的问题在于：

一个 loop，为什么会在生产环境里烂掉？

答案通常不是因为模型突然变笨了，而是因为下面这些工程问题开始集中出现：

• 上下文越来越脏

• 工具越来越多，但没有治理

• 状态没有结构化

• 安全边界靠「相信模型懂事」

• 错误没有归类，反馈也不可消费

• 长任务没有阶段性 checkpoint

• 文档和规则堆成一坨，模型根本吃不动

• 人和 agent 的协作边界不清晰

这些问题，全部都不是「模型理论问题」。

它们是彻头彻尾的软件工程问题。

而 Harness，这个词的价值就在这里：

它提醒你，Agent 项目的真正主战场，不是模型层，而是运行环境层。

Harness 和 Context Engineering 的区别是什么？

我看到不少讨论会把 Harness 和 Context Engineering 混在一起。

我觉得可以这样区分：

1）Prompt Engineering

关注的是：怎么说

比如 system prompt 怎么写，few-shot 怎么摆，措辞怎么调。

2）Context Engineering

关注的是：给模型什么信息

比如：

• 放哪些文档

• 怎么裁剪历史

• 怎么组织 AGENTS.md

• 怎么做记忆注入

• 怎么避免 context bloat

3）Harness Engineering

关注的是：模型在什么环境里做事

它比 Context 更大一层。

因为它不只管「喂什么」，还管：

• 什么时候能动手

• 动手时有哪些工具

• 工具是否需要审批

• 输出太长怎么办

• 危险操作怎么拦

• 会话如何恢复

• 中间产物如何持久化

• 任务失败后如何回路修复

• 客户端如何实时展示 agent 的状态

所以我会说：

Context Engineering 是 Harness 的一个组成部分，但 Harness 不等于 Context。

OpenAI 官方中文页里有一句话我很认同：情境是一种稀缺资源，巨大指令文件会挤掉任务、代码和相关文档，导致 agent 开始围绕错误约束优化。这个观察本身说的是 context，但他们整篇文章讲的解决方式，其实已经进入 harness 级别了：代码库结构、AGENTS.md、审阅回路、验证手段、仓库作为记录系统、熵管理。

从 memo 的实践看，Harness 具体长什么样？

如果让我用 memo code 的经验来拆，我会把 Harness 至少拆成五层。

第一层：上下文装配系统

很多人以为系统提示词就是一份大 Markdown。

其实不是。

在 memo 里，我更在意的是：提示词不是静态文档，而是动态拼装系统。

我在那篇《系统提示词架构解析》里把它拆成六层：

1. 基础模板

2. 用户偏好（SOUL.md）

3. 项目上下文（AGENTS.md）

4. Skills

5. 工具描述

6. 工具定义 JSON

这个拆法的关键不是「层多」，而是：

不同来源的信息，有不同优先级、不同新鲜度、不同职责。

它们不能全塞进一个大 prompt 里，然后指望模型自己理解层级关系。你必须先在工程上把层级关系建好，再交给模型。

这就是 Harness。因为你不是在「写提示词」，你是在「设计上下文的注入机制」。

第二层：工具治理系统

一个 agent 只要开始接工具，复杂度会立刻上升。

因为工具不是「多几个 function call」这么简单。工具系统背后至少有四个问题：

1. 模型如何发现工具

2. 参数如何校验

3. 风险如何分级

4. 调用如何被统一拦截

我在 memo 的工具系统设计里，把这件事拆成三层：

• 工具定义层：声明式 DSL

• 风险与审批层：read / write / execute / critical 分级

• 编排层：统一入参校验、审批拦截、结果裁剪、错误归类

这个设计的重点不是「优雅」，而是：

让工具调用成为一个可治理系统，而不是一堆裸奔接口。

很多 Agent 项目为什么一开始能跑，后来越来越不稳？

因为它们的工具系统不是「系统」，只是「工具列表」。

而 Harness 的一个核心任务，就是把工具从「模型可以调用的能力」提升成「可控、可审计、可演化的运行时能力」。

第三层：安全与审批系统

只要 agent 能写文件、跑 shell、改配置，它就不再是一个「聊天模型」。

它已经是一个操作系统参与者了。

这时候安全问题不是「以后再说」，而是第一天就存在。

我在 memo 的安全设计里，最后收敛成了三道防线：

1. 子进程管理：会话池、数量限制、输出截断、超时终止、自动清理

2. 命令守卫：命令解析、危险命令黑名单、system hint 回传

3. 审批系统：风险分级、审批模式、指纹缓存、dangerous 模式兜底

这里最关键的一点是：

安全不能只靠模型自觉。

你不能把「请不要执行危险命令」写在 prompt 里，然后假装问题解决了。真正的安全边界，必须落在运行时。

这也是 Harness 和很多「Demo Agent」的根本区别。

Demo 级别的 agent 靠的是「模型大概会听话」。Harness 级别的 agent 靠的是「即便模型不听话，系统也有边界」。

第四层：反馈与状态系统

Agent 之所以能持续做事，不是因为它会一直「想」。

而是因为它会不断收到反馈。

比如：

• 工具执行结果

• 审批是否通过

• 输出是否被截断

• 查找结果是否过多

• 命令是否被拒绝

• 当前任务计划是否已更新

• 会话是否可恢复

在 memo 的 prompt 架构里，我专门用 XML 的 system_hint 去承载一些异常状态，比如：

• 输出过长

• 查找结果过多

• 危险调用被拦截

很多人会觉得这只是「小技巧」。

但我不这么看。

这其实是 Harness 里非常重要的一件事：

你要把系统内部发生的事，翻译成模型能消费的反馈语言。

如果没有这层翻译，模型只能看到「失败了」。而有了这层翻译，它才能理解：

• 失败是因为权限问题

• 失败是因为输出被裁剪

• 失败是因为查找范围太大

• 失败是因为命令危险而被拒绝

这直接决定了 agent 是否能做出下一步正确行动。

第五层：熵管理系统

这是我觉得很多人会忽略，但其实特别关键的一层。

Agent 一旦持续运行，系统一定会逐渐「变脏」。

表现形式包括：

• prompt 越来越长

• rules 越来越旧

• AGENTS.md 越来越像垃圾场

• 工具定义越来越多但没人维护

• 会话历史越来越重

• memory 里混入大量无效信息

OpenAI 在那篇文章里其实已经非常明确提到了这件事：当一切都重要时，一切都不重要；大而全的说明文件会迅速腐烂。

所以 Harness 不是「搭完就完了」。

Harness 还有一个长期任务：

持续做熵管理。

也就是：

• 让过期规则失效

• 让长上下文压缩

• 让低价值历史退出上下文

• 让项目知识以可维护方式沉淀

• 让系统不断回到「对模型友好」的状态

如果没有这层意识，再强的 agent 也会越跑越歪。

所以，Harness 的本质到底是什么？

如果一定要让我用一句话概括，我会这么说：

Harness 工程，就是把 Agent 从「会调用工具的模型」，变成「能在约束中稳定完成任务的系统」。

这里面最重要的词不是 Agent，也不是模型。

是三个词：

• 约束

• 反馈

• 稳定

因为真实世界里的 agent，不是靠「聪明」活下来的。

是靠：

• 有边界

• 有结构

• 有状态

• 有反馈

• 有兜底

活下来的。

所以我一直觉得，Agent 的重点从来都不在模型。

模型当然重要。但模型更像发动机。

真正决定这台车能不能上路、能不能跑长途、会不会翻车的，是底下那整套工程环境。

也就是 Harness。

一个我更愿意推广的公式

如果以前我会说：

Agent = Loop(LLM + Context + Tools)

那现在我会更进一步，把它升级成：

Agent = Loop(Model + Harness)

为什么我要这么改？

因为 Context 和 Tools 其实都已经属于 Harness 的一部分了。

真正决定 agent 上限的，越来越不是「你有没有这些组件」，而是：

你有没有把这些组件工程化成一个可以长期运转的环境。

同样是：

• 一个模型

• 一个工具列表

• 一个上下文窗口

有人做出来的是玩具。有人做出来的是生产系统。

差别就在 Harness。

如果你要开始做 Harness 工程，先抓什么？

我给一个非常实用的落地顺序。

1. 先别急着追最强模型

先把环境搭起来。

因为环境是可复用资产，换模型能继承；但只靠换模型，通常不能替你补环境债。

2. 先把工具系统做成「系统」

至少做到：

• 可发现

• 可校验

• 可分级

• 可拦截

• 可审计

3. 上下文不要写成一坨

把 prompt 当成装配系统，不要当成单文件。

4. 安全边界必须在运行时

不要把安全寄托在提示词上。

5. 所有失败都尽量可解释

让系统错误能回流成模型能理解的反馈。

6. 给长任务设计状态与恢复机制

没有状态管理，就没有真正的持续执行。

7. 定期做熵管理

规则、记忆、会话、文档，都会腐烂。你不清理，系统就会慢慢失控。

为什么我会说：Harness 不是新东西，但它是一个重要命名

我很少会因为一个新词本身而兴奋。

但这次我觉得 Harness 这个词是有价值的。

因为它终于把很多 Agent 开发者长期在做、但总说不清的事情，命名清楚了：

• 为什么 prompt 调半天没用

• 为什么换模型只能解决一部分问题

• 为什么工程化之后效果会突然稳定

• 为什么长任务能力往往取决于环境，而不是参数量

• 为什么真正的瓶颈常常是软件工程，不是模型 API

它把这些零散经验，收束成了一个更明确的讨论入口。

所以我不认为 Harness 是什么「横空出世的新发明」。

我更愿意说：

Harness 让 Agent 工程这门课，终于有了一个更准确的词。

最后说回 memo，也说回我自己的判断

回头看 memo code，我越来越确认一件事：

我当时真正做的事情，不只是「做一个 coding agent」。

我其实一直在做一套 Harness。

我做的那些看起来很「工程琐事」的东西：

• prompt 分层装配

• AGENTS.md / SOUL.md

• skills 自动发现

• 工具 DSL

• 风险分级

• 审批缓存

• 危险命令拦截

• 子进程管理

• system hint 反馈

• 输出裁剪

• 多 workspace / web 控制台

这些东西单拿出来都不性感。

但正是这些东西，决定了一个 agent 最后到底是：

• 一个 demo

• 一个玩具

• 一个会写几段代码的聊天机器人

• 还是一个真的能在环境里持续做事的系统

所以如果今天再让我用一句最简短的话来讲 Agent，我可能会这么说：

Agent 的核心很简单，真正难的是 Harness。

或者更直白一点：

Agent 的重点不在模型，而在环境。

这句话，我之前是这么想的。现在我只是终于有了一个更流行的词，来把它说得更完整一点。

Node 社群

我组建了一个氛围特别好的 Node.js 社群，里面有很多 Node.js小伙伴，如果你对Node.js学习感兴趣的话（后续有计划也可以），我们可以一起进行Node.js相关的交流、学习、共建。下方加 考拉 好友回复「Node」即可。

   “分享、点赞、在看” 支持一波👍