一句话答案
Harness 是 AI 模型之外的一切——而 harness engineering 是设计这套环境的学科，让 Agent 第一次就做对，并在人类看到结果前完成自我修正。
这正是 2026 年区分「谁能交付可靠 AI」的关键转变。随着模型越来越强，瓶颈不再是「模型够不够聪明」，而是「我们为它搭建的系统够不够好」。
问题：聪明的模型不等于可用的 Agent
一个 LLM 本身是无状态的。开新对话，它什么都不会记得。给它一个多步骤任务，它没有任何内建机制去调用工具、检查自己的工作、保存进度，或在出错时恢复。
这个缺口，恰恰由 harness 来填补。
这个说法来自 Agent 圈里现在常用的一句 shorthand：Agent = Model + Harness（LangChain 团队用这个框架，OpenAI、Anthropic 与 Martin Fowler 的团队后来也都写过）。「Harness」就是把原始文本生成器变成能做事的 Agent 的那层运行外壳。
Harness 具体是什么？
把模型想成引擎，harness 想成包住引擎的车：底盘、方向盘、刹车、仪表板、油箱。没有车，引擎只是原地空转。
实践中，harness 负责模型做不到的事：
- 工具执行——调用你的 API、跑一段脚本、查询数据库，并把结果送回下一步。
- 记忆与状态——跨轮次、跨会话保存上下文，让 Agent 从上次中断处继续。
- 上下文管理——决定每一步喂给模型什么（检索到的文档、上一步结果、约束），又不撑爆上下文窗口。
- 反馈回路——检查工作的传感器：测试、linter、类型检查、浏览器检查、日志。
- 审批策略——关于 Agent 能自动做什么、哪些要等人确认的规则。
- 错误恢复——某一步失败时重试、回滚或上报。
Microsoft 的 Agent Framework 文档说得很直白：harness 是「把语言模型变成能做事的 Agent 的运行骨架」。它驱动模型与工具调用、管理对话状态与上下文、套用审批策略，并让 Agent 在多步骤任务中持续推进。
为什么 harness engineering 成了独立学科
2026 年 2 月，OpenAI 发布了一篇后来被广泛引用的工程文章：一个小团队用 零行手写代码 做出一个产品，累计交付约一百万行由 Codex Agent 生成的代码。他们的结论不是「模型变强了」，而是最难的难题不再是写代码，而是设计环境、反馈回路与控制系统。
那就是 harness engineering。人的工作从「写函数」转变为：
- 把意图说清楚。
- 搭建 Agent 需要的工具与环境。
- 加入能在出错前抓到偏移的反馈回路。
- 只在系统无法自我修正时才介入。
Martin Fowler 的网站用控制论（cybernetics）来框架化它：一个好的 harness 像一个调节器（governor），把前馈引导（规则、参考、how-to）与反馈传感器（review agent、静态分析、运行时日志）结合起来，把代码库导向期望的状态。目标有两个：提高 Agent 第一次就做对的概率，并尽可能在结果到达人眼前自我修正。
好 harness 的组成部分
你不需要庞大的平台就能开始。一个有用的 harness 通常有这几层：
1. 前馈引导（计算型 + 推断型）
- 计算型：语言服务器、CLI、脚本、codemod、类型检查。
- 推断型：写下来的规则、架构约束、参考文档、how-to。
它们预判错误，让正确的路成为好走的路。
2. 反馈传感器
- 静态分析、单元与集成测试、linter。
- 运行时信号：日志、浏览器检查、可观测性仪表板。
- 在人工 review 之前先 critique diff 的 review agent。
3. 状态与记忆
- 一个地方保存发生过什么、决定了什么、下一步做什么。
- 跨会话记忆，让 Agent 不用每次都被重新教一遍你的项目。
4. 护栏与审批
- 最小权限的工具访问（先只读；写操作留待确认）。
- 在「Agent 可以行动」与「必须等人批准」之间划清界线。
Harness Engineering vs Context Engineering
两者相关但不相同。
- Context engineering 关注每一步放在模型面前的是什么：提示词、检索到的知识、压缩过的历史、约束。
- Harness engineering 是更宽的系统：包含 context，也包含让 Agent 随时间朝目标前进的回路、传感器、状态与护栏。
你可以有极好的 context 却依然失败，如果缺了反馈回路。Harness engineering 是伞，context 是它的一个输入。
什么时候需要（什么时候不需要）
| 情况 | 需要 harness 吗？ | | --- | --- | | 一次性「帮我总结这个」 | 不需要——直接调用即可 | | 多步骤编码任务 | 需要——要状态、工具与验证 | | 长时间运行的 Agent（数小时/数天） | 需要——要持久化与恢复 | | 会动你系统的 Agent | 需要——要审批与护栏 | | 可复用的内部助手 | 需要——要跨会话记忆 |
经验法则：只要工作跨越一个步骤，或会碰任何真实的东西，harness 就是让它安全、可复用的关键。
一个简单的起步心智模型
你不用建 OpenAI 那种规模的基础设施。从一个薄但真实的 harness 开始：
- 给 Agent 一个清楚的工作与明确的产出。
- 让它调用一两个狭窄、只读的工具。
- 每步之后跑一个便宜的检查（测试、lint、schema 校验）。
- 记录发生过什么，让下一次运行能学习。
- 之后才放宽它被允许做的事。
那个循环——行动、感知、修正——就是全部的游戏。模型提供推理，harness 提供纪律。
重点整理
- Harness 是模型之外的一切：工具、记忆、状态、反馈、护栏。
- Harness engineering 成为独立学科，因为模型很少是瓶颈——它周围的环境才是。
- 对可靠的、多步骤 Agent 来说，反馈回路与护栏比提示词技巧更重要。
- 从小开始：狭窄工具、便宜检查、持久日志，再扩大范围。
想看它套用在具体工具上，可读这两篇：用 ChatGPT 做 harness engineering 与 用 Hermes 做 harness engineering。
