OpenAI 既是 Harness Engineering驾驭工程这一概念的定义者和领跑者也是其最核心的践行者。在 OpenAI 内部最经典的案例就是其应用大模型如早期基于 GPT-3/4 演进出的 Codex以及近年最新的 o1/o3-mini 等推理模型进行软件自主开发Agent-First World的实践。OpenAI 的工程师发现当任务长达数小时、涉及数百步决策时一味优化 Prompt 是没有用的必须通过构建严密的外围 Harness代码工程、沙盒、验证循环来约束和引导大模型。以下是 OpenAI 官方及工程团队应用 Harness Engineering 的五大核心策略与实操方法一、 “模型提议Harness 执行” 的彻底分离 (Model Proposes — Harness Executes)OpenAI 在工程规范中强调绝对不允许大模型直接拥有系统的高级执行权限必须通过 Harness 层进行中转、校验和拦截。痛点如果让大模型直接通过 Bash 工具执行任意代码可能会遭遇恶意的提示词注入Prompt Injection导致大模型失控甚至删库、死循环泄露代币Token。OpenAI 的解法模型只能输出标准的结构化数据如 JSON 格式的工具调用指令{tool: modify_file, path: main.py, line: 12}。Harness 的职责解析与校验拦截这个 JSON通过确定性的代码如 Pydantic 或 Zod验证参数格式。安全沙盒将行动放入彻底隔离的 Docker 容器如 E2B 沙盒或受限环境中执行。确定性反馈无论执行成功、超时还是报错Harness 都必须捕获并转化为标准的结构化 Observation观察结果再喂回给模型杜绝悬挂进程Dangling Promises。二、 极限瘦身系统的上下文Context Compaction Progressive DisclosureOpenAI 在利用 Codex 自主编写代码时最初犯过一个错误把所有的编码规范、历史讨论、长篇的规则一股脑全塞进 System Prompt 里比如大名鼎鼎的AGENTS.md文件。结果模型因为信息过载要么忽略关键约束要么开始糊弄。OpenAI 的解法 —— “渐进式揭示” (Progressive Disclosure)将宏大的AGENTS.md精简到 100 行以内。它不再是一本硬性规则书而是一张“地图”。地图只告诉大模型如果你要处理架构问题请去读docs/architecture/如果你要了解某个特定 API请去调用read_skill工具。Harness 动态注入只有当大模型表达出“我需要去修改用户模块”的意图时Harness 才会即时Just-in-Time把用户模块相关的背景上下文和最新演进文档加载到大模型的上下文窗口中并在任务结束后像操作系统的“垃圾回收Garbage Collection”一样将其清理防止上下文爆炸。三、 强制执行硬性的“架构约束” (Enforcing Architectural Invariants)没有约束的 AI 会像脱缰的野马不仅会写出 Bug还会污染整个项目的代码架构由于大模型喜欢复制 repo 里的旧模式甚至包括坏模式。OpenAI 的解法规定极其严苛的单向依赖架构例如Types → Config → Repo → Service → UI绝对不允许逆向调用。Harness 的落地OpenAI 团队让大模型自己编写了定制化的Static Linters静态检查器和结构测试工具。大模型写完代码后Harness 会自动在后台运行 Linter。如果发现 AI 破坏了依赖规则Harness 会直接无情拒绝并将具体的报错和修复建议内联Inline反馈给大模型“你违反了 Service 不能直接调用 UI 的规则请在 Service 层重构。”四、 建立自动化的“Steering Loop转向纠错循环”当 AI Agent 在深夜自主运行 6 个小时去修复一个复杂 Bug 时人类工程师都在睡觉谁来充当它的教练这就是 Harness 里的传感器Sensors反馈机制。OpenAI 接入全套开发工具链他们将 Chrome DevTools Protocol、LogQL日志查询、PromQL指标监控全部封装成工具塞进大模型的 Harness 中。设定硬性指标阈值OpenAI 在 Harness 中设定了一个硬性指标——“服务启动时间必须在 800 毫秒以内且全套单元测试必须 Pass”。闭环纠错模型写完代码 → Harness 自动部署 → Harness 自动运行测试、监控启动延迟。如果延迟是 950 毫秒Harness 会对大模型说“未通过当前延迟 950ms超过 800ms 限制请继续优化性能。” 这种计算型Computational的硬反馈比人类肉眼看代码去纠错高效、精准得多。五、 设置“多级风险拦截”与三阶段预算Budgets完全的自主权意味着不可控。OpenAI 在 Harness 层面为 Agent 划分了严密的风险等级与资源熔断机制1. 风险分级操作模式Read-only只读模式AI 纯自主运行随便翻阅、检索代码和文档。Draft草稿模式AI 可以在本地沙盒里修改代码、运行模拟、创建 Git 分支并跑通测试但这些修改不影响外部世界。External Write外部写入当 AI 准备执行“合并 Pull Request”、“发送邮件给客户”或“在线上执行迁移”等高危动作时Harness 会强行挂起Suspend触发人类确认机制Human-in-the-Loop必须由人类工程师点击ApprovedHarness 才会放行。2. 四维资源熔断Guardrails为了防止大模型陷入死循环导致账单爆炸Token 泄漏OpenAI 的 Harness 严格计算每一次任务的Step Budget最大执行步数限制如最多思考 50 步Time Budget墙上时钟时间限制Token Budget单次及累计 Token 上限Cost Budget单次任务硬性美元限制 任何一个指标触顶Harness 会瞬间强行切断大模型的执行流保存当前现场Checkpoint并向人类报警。 总结OpenAI 留给我们的 Harness 开发金句OpenAI 的团队在分享他们基于大模型进行自主开发的经验时提到了一个核心哲学“当 Agent 运行失败时修复手段几乎永远不是‘让大模型再试一次Try harder’或者去改动 System Prompt而是去迭代你的 Harness。每当一个 Bug 重复出现你就应该在 Harness 里增加一个确定性的检查器或验证工具从物理上剥夺大模型犯错的机会。”
Open AI怎么应用 Harness Engineering
OpenAI 既是 Harness Engineering驾驭工程这一概念的定义者和领跑者也是其最核心的践行者。在 OpenAI 内部最经典的案例就是其应用大模型如早期基于 GPT-3/4 演进出的 Codex以及近年最新的 o1/o3-mini 等推理模型进行软件自主开发Agent-First World的实践。OpenAI 的工程师发现当任务长达数小时、涉及数百步决策时一味优化 Prompt 是没有用的必须通过构建严密的外围 Harness代码工程、沙盒、验证循环来约束和引导大模型。以下是 OpenAI 官方及工程团队应用 Harness Engineering 的五大核心策略与实操方法一、 “模型提议Harness 执行” 的彻底分离 (Model Proposes — Harness Executes)OpenAI 在工程规范中强调绝对不允许大模型直接拥有系统的高级执行权限必须通过 Harness 层进行中转、校验和拦截。痛点如果让大模型直接通过 Bash 工具执行任意代码可能会遭遇恶意的提示词注入Prompt Injection导致大模型失控甚至删库、死循环泄露代币Token。OpenAI 的解法模型只能输出标准的结构化数据如 JSON 格式的工具调用指令{tool: modify_file, path: main.py, line: 12}。Harness 的职责解析与校验拦截这个 JSON通过确定性的代码如 Pydantic 或 Zod验证参数格式。安全沙盒将行动放入彻底隔离的 Docker 容器如 E2B 沙盒或受限环境中执行。确定性反馈无论执行成功、超时还是报错Harness 都必须捕获并转化为标准的结构化 Observation观察结果再喂回给模型杜绝悬挂进程Dangling Promises。二、 极限瘦身系统的上下文Context Compaction Progressive DisclosureOpenAI 在利用 Codex 自主编写代码时最初犯过一个错误把所有的编码规范、历史讨论、长篇的规则一股脑全塞进 System Prompt 里比如大名鼎鼎的AGENTS.md文件。结果模型因为信息过载要么忽略关键约束要么开始糊弄。OpenAI 的解法 —— “渐进式揭示” (Progressive Disclosure)将宏大的AGENTS.md精简到 100 行以内。它不再是一本硬性规则书而是一张“地图”。地图只告诉大模型如果你要处理架构问题请去读docs/architecture/如果你要了解某个特定 API请去调用read_skill工具。Harness 动态注入只有当大模型表达出“我需要去修改用户模块”的意图时Harness 才会即时Just-in-Time把用户模块相关的背景上下文和最新演进文档加载到大模型的上下文窗口中并在任务结束后像操作系统的“垃圾回收Garbage Collection”一样将其清理防止上下文爆炸。三、 强制执行硬性的“架构约束” (Enforcing Architectural Invariants)没有约束的 AI 会像脱缰的野马不仅会写出 Bug还会污染整个项目的代码架构由于大模型喜欢复制 repo 里的旧模式甚至包括坏模式。OpenAI 的解法规定极其严苛的单向依赖架构例如Types → Config → Repo → Service → UI绝对不允许逆向调用。Harness 的落地OpenAI 团队让大模型自己编写了定制化的Static Linters静态检查器和结构测试工具。大模型写完代码后Harness 会自动在后台运行 Linter。如果发现 AI 破坏了依赖规则Harness 会直接无情拒绝并将具体的报错和修复建议内联Inline反馈给大模型“你违反了 Service 不能直接调用 UI 的规则请在 Service 层重构。”四、 建立自动化的“Steering Loop转向纠错循环”当 AI Agent 在深夜自主运行 6 个小时去修复一个复杂 Bug 时人类工程师都在睡觉谁来充当它的教练这就是 Harness 里的传感器Sensors反馈机制。OpenAI 接入全套开发工具链他们将 Chrome DevTools Protocol、LogQL日志查询、PromQL指标监控全部封装成工具塞进大模型的 Harness 中。设定硬性指标阈值OpenAI 在 Harness 中设定了一个硬性指标——“服务启动时间必须在 800 毫秒以内且全套单元测试必须 Pass”。闭环纠错模型写完代码 → Harness 自动部署 → Harness 自动运行测试、监控启动延迟。如果延迟是 950 毫秒Harness 会对大模型说“未通过当前延迟 950ms超过 800ms 限制请继续优化性能。” 这种计算型Computational的硬反馈比人类肉眼看代码去纠错高效、精准得多。五、 设置“多级风险拦截”与三阶段预算Budgets完全的自主权意味着不可控。OpenAI 在 Harness 层面为 Agent 划分了严密的风险等级与资源熔断机制1. 风险分级操作模式Read-only只读模式AI 纯自主运行随便翻阅、检索代码和文档。Draft草稿模式AI 可以在本地沙盒里修改代码、运行模拟、创建 Git 分支并跑通测试但这些修改不影响外部世界。External Write外部写入当 AI 准备执行“合并 Pull Request”、“发送邮件给客户”或“在线上执行迁移”等高危动作时Harness 会强行挂起Suspend触发人类确认机制Human-in-the-Loop必须由人类工程师点击ApprovedHarness 才会放行。2. 四维资源熔断Guardrails为了防止大模型陷入死循环导致账单爆炸Token 泄漏OpenAI 的 Harness 严格计算每一次任务的Step Budget最大执行步数限制如最多思考 50 步Time Budget墙上时钟时间限制Token Budget单次及累计 Token 上限Cost Budget单次任务硬性美元限制 任何一个指标触顶Harness 会瞬间强行切断大模型的执行流保存当前现场Checkpoint并向人类报警。 总结OpenAI 留给我们的 Harness 开发金句OpenAI 的团队在分享他们基于大模型进行自主开发的经验时提到了一个核心哲学“当 Agent 运行失败时修复手段几乎永远不是‘让大模型再试一次Try harder’或者去改动 System Prompt而是去迭代你的 Harness。每当一个 Bug 重复出现你就应该在 Harness 里增加一个确定性的检查器或验证工具从物理上剥夺大模型犯错的机会。”
