Harness Engineering 完全解读

AI Engineering · 2025

Harness Engineering
完全解读

从 Prompt Engineering 到 Context Engineering，再到 Harness Engineering —— AI 应用开发正在经历一场范式转移。OpenAI、Anthropic 为何争相布局？这是噱头还是真突破？

📄 深度解析 ⚡ 5 个月 · 100 万行代码

三大工程概念 · 递进关系

①

Prompt Engineering

研究 怎么问问题 —— 如何组织提示词，把需求说清楚、说准确，让模型理解你的真实意图。

基础层 · 门槛低

②

Context Engineering

研究 怎么给信息 —— 在最合适的时机，把最合适的内容放入上下文（包括对话历史、工具列表等），并做压缩与检索。

进阶层 · 有上限

③

Harness Engineering

研究 怎么搭系统 —— 围绕大模型构建完整、可靠的 agent 框架，覆盖工具管理、权限管控、验证反馈、技术债清理等一切非模型部分。

系统层 · 当前焦点

Harness = Agent − Model （业界共识公式 · 非模型即 Harness）

关键数据 · OpenAI 实战

100 万

代码行数

全部 AI 生成

5 个月

开发周期

3 → 7 人团队

10 倍

效率提升

vs 纯人工

200 美元

Full Harness 方案

vs Solo 方案 9 美元

⏱ Full Harness 耗时 6 小时 · Solo 方案仅 20 分钟

OpenAI 实践 · 三大优化方向

来源：OpenAI 官方文章（2025.02.11）

❶ 上下文管理

从「大而全」到「结构化」：放弃超大的 agent.md（信息过载、容易过时），改为 100 行左右的目录式文件，按需加载对应文档。

唯一事实来源：强制将所有重要决策、约定都搬进代码仓库，消除 Slack、文档等外部信息黑洞。

❷ 验证与反馈

为 Codex 配备 Chrome DevTools、可观测性工具链，让 agent 自动截图、查看 DOM、模拟用户操作，自我验证 UI 效果。

Linter + 测试自动闭环：代码生成后自动跑规范检查，报错信息发回 agent 修改，循环直至全部通过，无需人工介入。

❸ 技术债清理

设置后台 Codex 任务，定期扫描整个代码库，自动修复重复代码、架构偏离、命名不一致等问题，并自动提交。

文档同步清理：同样用后台任务找出过时文档，与实际代码对齐，保持文档库健康。

"Human steers, agent executes."

人类掌舵，agent 干活

—— OpenAI 文章核心断言

Anthropic 架构 · 三 agent 分工

来源：《Effective Harnesses for Long Running Agents》(2024.11) 及续作 (2025.03)

Planner（规划者）：将模糊的用户需求拆解为完整、清晰的功能列表，让后续 agent 不再靠猜测干活。

Generator（生成者）：对照功能列表，逐个功能点实现代码，稳扎稳打。

Evaluator（评估者）：作为独立的第三方评估产出质量，避免「王婆卖瓜」式自评，确保客观。

Planner → Generator ↔ Evaluator

Generator 与 Evaluator 循环协作 · 每个功能点达标后才进入下一个

方案效果对比

维度	Solo 方案	Full Harness 方案
耗时	20 分钟	6 小时
花费	9 美元	200 美元
产出质量	布局不合理 · 逻辑难懂 · bug 多	达到可用水准
适用场景	快速原型	严肃产品开发

* 精雕细琢有代价，但效果显著

争议 · 噱头还是真突破？

🤔 质疑点 1：没有新技术，全是「新瓶装旧酒」

Linter、任务拆解、质量评估、代码规范…… 这些技术早已存在。Harness Engineering 提供的是一套 系统思维框架，而非颠覆性发明。

🤔 质疑点 2：模型越强，Harness 越少 —— 终将被淘汰？

例 1：Sonnet 4.5 之前需要用「上下文重置」技术缓解上下文焦虑，而 o4.5 已大幅缓解此问题。
例 2：o4.6 之前需要强制 Generator 逐个功能点执行，o4.6 的全局统筹能力已不再需要此约束。
但 Anthropic 认为：Harness 不会消失，而是会进化，去解锁更复杂的任务。

"Harness Engineering 不是噱头，但应该也不是终局。"

它是过渡期的关键技术，是当下最现实的答案

—— 本文作者观点

本质：工程领域的进步往往不在于发明新技术，而在于用统一框架把零散能力组织成可系统设计、可持续优化的工程方法。Harness Engineering 的意义恰在于此。

行动建议 · 当下可以做什么

①

重新定义分工：从「亲自写代码」转向「掌舵」—— 定方向、给上下文、制定规则，把执行交给 agent。

②

搭建验证闭环：为 agent 配备 Linter、测试、可观测工具，形成「生成 → 验证 → 反馈 → 修复」的自动循环。

③

重视上下文设计：告别大而全的提示文件，采用结构化、按需加载的上下文管理策略。

④

引入独立评估角色：代码生成与质量评估分离，用第三方 evaluator 保证客观性。

⑤

建立技术债清理机制：设置后台任务定期扫描代码与文档，保持仓库健康。

Harness Engineering 的真正启示

它或许不是终极答案，但它正在重新定义人类与 AI 的协作边界。
谁能把 Harness 搭得更稳，谁就能更早地将 AI 能力转化为真实生产力。

Prompt 是提问 · Context 是信息 · Harness 是系统

—— 本文内容综合自 OpenAI、Anthropic、Martin Fowler 博客等公开资料

由 CuteNote.app 颜值笔记生成