Harness Engineering
定义或身份
Harness Engineering 是 OpenAI 提出的 Agent 工程化执行思路。它不是单一模型能力，也不是一条普通提示词技巧，而是一种把 Agent 运行“装进可操作环境”的工程方法：
- 以文件系统承载规则、设计文档、架构规范与执行计划；
- 让 Agent 按需读取这些结构化资料，而不是每次都靠人工在对话里重新解释；
- 尽量减少逐步式、环节式的 human-in-the-loop；
- 允许 Agent 长时间连续运行，出错后读取日志、自行修正并再次执行。
在这个意义上，Harness Engineering 强调的重点不是“写出更强的提示词”，而是构建一个可持续执行、可观察、可回溯、可修正的工程化执行环境。
角色职责
Harness Engineering 在 Agent 系统中的核心职责，主要包括以下几类：
1. 把规则从对话记忆转移到外部环境
它要求把原本散落在人工说明、口头习惯或临时提示词里的要求，固化为 Agent 可读取的外部文件，例如总入口规则、设计说明、执行计划、参考模板与约束文档。这样做的目的，是让工作流不再依赖“这次有没有把话说全”。
2. 为 Agent 提供结构化执行依据
Agent 不再只根据当前用户一句话行动，而是可以从环境中找到：
- 总体目标是什么；
- 当前任务应遵守哪些规范；
- 遇到不同场景时应调用哪些能力；
- 执行失败后该检查哪里、如何重试。
这使 Agent 从“即时响应器”更接近“有工作台的执行者”。
3. 降低人工逐步介入频率
OpenAI 在相关表述中强调，随着模型能力提升，人工审查会逐渐成为系统最慢的环节。Harness Engineering 因而主张，不要让人类在每一步都审批、纠错、再推动下一步，而是尽可能把规则前置写清，让 Agent 按规则自行完成更多环节。
4. 支持长时运行与失败后自修复
该思路特别适合单次任务可能运行较久的场景。Agent 可以先执行，再查看运行日志；如果跑崩或偏离预期，再依据日志定位问题、调整后继续执行，而不是每次失败都停下来等待人接手。
关键信息
以文件系统承载规则与计划
原文语境里，OpenAI 的做法不是把所有要求塞进一个超长提示词，而是使用“渐进式披露的文件系统”。其中，一个大约 100 行 的 AGENTS.md 用作目录入口，指向进一步的结构化材料，例如：
- 设计文档；
- 架构规范；
- 执行计划；
- 其他与任务相关的参考文件。
这里的关键不是具体文件名本身，而是“规则外置、结构化引用、按需读取”的工程组织方式。Agent 先看到总入口，再根据任务相关性加载更细的约束和步骤，这与一次性注入全部上下文的做法不同。
减少逐步式 human-in-the-loop
Harness Engineering 明确反对把人工放在每个中间步骤上做串行审批。原文直接指出：
- 每个变更都等人检查，系统会变慢；
- 每次出错都等人修复，成本会很高；
- 当 Agent 产出能力提升后，人工反而可能成为整体吞吐的瓶颈。
因此它主张把人工从“逐步审批者”转成“规则制定者”和“最终决策者”。人类更多负责定义规范、边界、验收标准，而不是在每一轮生成后都手动推动下一步。
支持长时运行与日志修正
Harness Engineering 的一个鲜明特征，是允许 Agent “自己跑”：
- 可以连续执行较长时间；
- 如果运行崩溃，不是立刻转人工，而是先读取日志；
- 根据日志修改方案后再次执行；
- 形成执行—观测—修正—再执行的闭环。
这使它区别于很多只面向单轮问答或短链路自动化的方案。它关注的是任务在真实工程环境中的持续推进能力，而不只是第一次输出是否看起来正确。
突出工程化执行环境
Harness Engineering 的重点是“环境工程”而非“单提示词优化”。它默认 Agent 应该运行在一个具备以下特性的环境里：
- 有明确的规则载体；
- 有稳定的上下文组织方式；
- 有执行状态与日志可供回看；
- 有计划、规范、参考材料之间的关联结构；
- 出错后可以基于环境信息恢复，而不是完全依赖人工重新讲解。
这也是为什么它常被拿来和 Anthropic Skills、渐进式披露式能力组织、自检驱动的AI工作流 一起讨论：它们共同关注的，都是如何通过结构化外部系统提升 Agent 的稳定性与复用性。
细节与边界
它不等于“完全不要人”
Harness Engineering 强调减少逐步式人工介入，但不代表所有人工角色都被取消。更准确地说，它反对的是“每一步都等人看”的流程设计，而不是否定人类在以下环节的作用：
- 制定规则；
- 搭建执行环境；
- 设定边界条件与验收标准；
- 在最终高风险节点做发布或否决决策。
因此，它与HITL Agent双反馈闭环并不天然冲突。区别在于：Harness Engineering 更强调前置规则化与自动执行，HITL Agent双反馈闭环 更强调当人工介入不可避免时，如何把人工判断转化为短期规则优化与长期能力演进。
它不只是“把提示词拆成多个文件”
虽然文件系统是核心载体，但 Harness Engineering 的重点不只是拆文件，而是形成可执行的工程结构。只有在以下条件同时满足时，文件化才真正有意义：
- 文件之间职责清晰；
- Agent 知道何时读取何种文件；
- 执行过程可观测；
- 失败后有日志可供修正；
- 更新局部规则时不会破坏全局流程。
如果只是把一大段提示词复制成多个文档，却没有读取策略、执行机制和修正闭环，那仍然谈不上真正的 Harness Engineering。
它适合高重复、可规则化、需持续运行的任务
从原文语境看，这种方法特别适合以下场景：
- 需要反复执行的固定流程；
- 能够用规则、模板、清单描述质量标准的任务；
- 可能需要多个能力串联完成的任务；
- 单次执行时间较长、可能中途失败的任务。
相反，对于高度一次性、强依赖模糊判断、缺乏可外置规则的任务，Harness Engineering 的收益会相对有限。
与 Skills 思路的关系
在本页参考语境中，Harness Engineering 与 Anthropic Skills 形成互补关系：
- Anthropic Skills 更强调把工作流拆成可复用、可组合的能力单元；
- Harness Engineering 更强调让这些能力单元运行在可持续执行的工程环境里；
- 前者解决“能力如何组织”，后者解决“能力如何在真实系统中稳定跑起来”。
因此，像“能力独立运行与组合运行兼容”“规则写成独立规范文件”“用自检清单替代频繁人工审查”等做法，都可以视为与 Harness Engineering 高度一致的外围实践。