Harness Engineering

Harness Engineering（ハーネス工程 / 智能体驯化工程），可以理解为：

不是让 AI Agent 更聪明，而是给 AI Agent 设计一套可控、可验证、可持续改进的工作环境。

它关注的是 AI 模型外面的那一整套东西：上下文、工具、规则、测试、CI、权限、反馈循环、代码库文档、自动校验、回滚机制、可观测性。

一句话说就是：

Model 负责生成，Harness 负责约束、引导、验证和纠错。

OpenAI 在 2026 年 2 月发布的文章里提到，他们做了一个实验：5 个月内构建并发布了一个内部 beta 产品，代码不是人工手写，而是由 Codex 编写；人类的主要工作从“写代码”转向“设计环境、表达意图、构建反馈循环”。(OpenAI)

1. 它解决的核心问题

以前大家用 AI 写代码，主要问题不是“AI 不会写”，而是：

AI 能写，但不稳定。

常见问题包括：

Harness Engineering 的出现，就是为了解决AI Agent 从“能演示”到“能生产落地”之间的可靠性鸿沟。

2. 它和 Prompt Engineering 的区别

Prompt Engineering更像是：

“我怎么把一句话写好，让 AI 这次回答更好？”

Harness Engineering更像是：

“我怎么设计一套系统，让 AI 每次都更靠地完成任务？”

区别可以这样看：

所以 Harness Engineering 不是“更高级的提示词”，而是AI Agent 时代的软件工程方法论。

3. Harness 具体包括什么

一个典型的 coding agent harness 可以包括这些部分：

1）上下文工程

让 AI 能看懂项目，而不是每次靠你口头解释。

例如：

AGENTS.md ARCHITECTURE.md docs/ product-specs/ design-docs/ exec-plans/ SECURITY.md RELIABILITY.md

OpenAI 的实践里，他们没有把所有规则塞进一个巨大的AGENTS.md，而是让AGENTS.md作为目录入口，把真正的知识沉淀到结构化的docs/里，并通过 lint 和 CI 检查文档是否过期。(OpenAI)

2）工具约束

给 AI 能用的工具，但不能无限制乱用。

比如：

只能通过测试命令验证 只能改指定目录 必须通过类型检查 必须先读架构文档 提交前必须跑 lint 不能直接改生产配置

3）反馈传感器

AI 写完之后，必须有东西告诉它：

“你做得对不对？”

这些东西可以是：

单元测试 集成测试 类型检查 ESLint / Checkstyle 静态代码扫描 安全扫描 覆盖率报告 日志 错误堆栈 浏览器截图 CI 结果

Martin Fowler 站点上的文章把 harness 分成两类控制：Guides / 前馈控制，用于提前引导 AI；Sensors / 反馈控制，用于观察结果并让 AI 自我纠正。(martinfowler.com)

4）自动纠错循环

不是 AI 写完就结束，而是形成：

理解任务 → 制定计划 → 修改代码 → 运行测试 → 读取错误 → 修复 → 再验证

LangChain 的实践里，加入自验证、自检查、trace 分析、middleware 后，在不更换模型的情况下，coding agent 在 Terminal Bench 2.0 上从 52.8 提升到 66.5。(LangChain)

5）知识沉淀机制

每次 AI 犯错，不只是这次改掉，而是要把规则沉淀下来：

AI 忘记跑测试 → 增加 pre-commit hook AI 总是改错目录 → 增加目录边界规则 AI 不理解业务口径 → 增加业务规格文档 AI 重复写坏 SQL → 增加 SQL lint 或示例模板

核心思想是：

不要只是纠正一次错误，而是改造环境，让错误以后更难发生。

4. Harness Engineering 的优势

第一，提升 AI 编程的稳定性

没有 harness 时，AI 像一个很聪明但没有项目经验的新人。

有 harness 后，AI 会被项目规则、测试、文档和工具持续约束。

结果是：

AI 不只是“会写代码”，而是更接近“能按项目标准交付代码”。

第二，减少人工 review 成本

如果每次 AI 写完都需要你从头检查，那效率提升有限。

Harness 的目标是把大量低级检查自动化：

格式问题 → formatter 类型问题 → type checker 重复代码 → static analysis 接口破坏 → contract test 业务流程错误 → acceptance test 安全问题 → scanner

人类 review 的重点就可以从“检查低级错误”转为“判断产品方向、架构设计、业务正确性”。

第三，让 AI Agent 可以执行更长任务

普通 AI 对话适合短任务。

但真实开发经常是：

读需求 → 拆任务 → 改前端 → 改后端 → 改数据库 → 写测试 → 提交 PR → 根据 CI 修复

Harness Engineering 通过上下文、计划文档、任务状态、测试反馈，让 AI 能够完成更长链路的任务。

LangChain 也明确提到，harness 的目标是围绕模型构建系统，优化任务表现、token 效率和延迟等指标，而不仅仅是改 prompt。(LangChain)

第四，让团队经验变成系统能力

以前团队规范可能散落在：

微信群 飞书聊天 Confluence 老员工脑子里 历史代码习惯

AI 是看不到这些的。

Harness Engineering 要做的是把这些知识变成 AI 可读、可执行、可验证的资产：

架构文档 业务规则文档 代码模板 PR 模板 测试模板 lint 规则 CI pipeline 自动化脚本

OpenAI 文章里也强调，从 Agent 视角看，无法进入上下文的 Google Docs、聊天记录、隐性知识，实际上就等于不存在。(OpenAI)

5. 它为什么现在重要

因为 AI 编程正在从Copilot 辅助补全进入Agent 自动执行任务阶段。

过去是：

人写代码，AI 辅助补全

现在逐渐变成：

人定义目标，AI Agent 执行，系统负责验证

这时工程师的核心能力会发生变化：

所以 Harness Engineering 的本质是：

把工程师从“代码劳动力”升级为“AI 工作系统设计者”。