什么是 Harness Engineering：当 AI 开始写代码后，工程重点为什么从写代码转向设计约束与反馈回路
Harness Engineering 关注 AI coding agent 进入生产开发后的工程方法，包括仓库结构、文档、校验、观测和反馈回路。
Find related content
Search the site for tools, terms, comparison pages, or related troubleshooting notes without going back to the blog index.
Main answer
Harness Engineering 的核心不是再写更长的 prompt，而是把约束、知识、校验、观测和清理机制工程化，让 agent 在一个可控环境里稳定工作。
Who should read this
适合已经在用 Claude Code、Codex CLI、Cursor 等 AI 编程工具，并开始觉得问题不再只是模型能力，而是仓库、流程和反馈回路的人。
Key check
OpenAI 在 2026 年 2 月 11 日公开分享了一套 agent-first 开发经验：人类主要负责 steer，agents 负责执行，重点转向环境、文档、lint、review、验证和清理机制。
Next step
如果你想把这个概念落到日常团队实践，下一步就看 Harness Engineering 检查清单和 Harness Open Source 两篇。
你将学到
- + 为什么 Prompt Engineering 不足以支撑长期 AI 编程协作
- + Harness Engineering 和 context engineering、workflow engineering 的关系
- + 为什么仓库文档、lint、观测与 cleanup 机制会比模型本身更影响长期稳定性
- + 哪些团队信号说明你已经进入 harness engineering 阶段
什么是 Harness Engineering：当 AI 开始写代码后，工程重点为什么从写代码转向设计约束与反馈回路
先说结论
如果你已经在用 Claude Code、Codex CLI、Cursor 或别的 coding agent，你很快会发现一个现实：
真正决定稳定性的，越来越不是“模型会不会写代码”，而是：
- 仓库有没有清楚的知识入口
- agent 能不能自己验证结果
- 边界和结构是不是机械可检查
- 坏模式会不会不断复制
- 团队有没有持续清理和回收熵增
这就是 Harness Engineering 开始有意义的地方。
为什么这个词会冒出来
OpenAI 在 2026 年 2 月 11 日发布的工程文章里，把他们的一套 agent-first 开发经验公开了出来：
- 人类主要负责
steer - agent 主要负责
execute - 团队重点从“亲手写每一行代码”转向“设计环境、表达意图、建立反馈回路”
如果你看过那篇文章，会发现里面最重要的不是某个单独技巧，而是一整套系统：
- 用
AGENTS.md做短入口，而不是写一本超长说明书 - 把真正的知识源放进 repo 内的
docs/ - 让 agent 直接访问测试、UI、日志、metrics 和 traces
- 用 lint、结构校验和 taste invariants 机械约束代码
- 持续做 background cleanup，防止 “AI slop” 扩散
这套东西合在一起，才是 harness。
它和 Prompt Engineering 有什么不同
Prompt Engineering 关注的是：
- 这次怎么问
- 这次怎么写更清楚
- 这次怎样减少歧义
Harness Engineering 关注的是：
- 这个仓库有没有稳定的 agent 工作入口
- 规则是不是写在 repo 里而不是写在人脑里
- agent 有没有办法自己验证、复跑、回归
- 坏模式出现后，系统会不会自动纠偏
可以把它理解成：
Prompt Engineering解决单次交互质量Harness Engineering解决长期系统稳定性
什么情况下你已经进入 Harness Engineering 阶段
如果你开始遇到下面这些问题，说明你已经不只是“在用 AI 写代码”，而是在进入 harness engineering：
- agent 能写出功能，但风格越来越散
- 每次都要人工补充同样的背景说明
- 文档、代码和真实行为越来越不一致
- 代理能改代码，但不会自己验证
- 坏 pattern 一旦进仓库，后面会不断复制
- 团队每周都在花固定时间清理 “AI slop”
这些问题的共同点是：
它们已经不是模型能力问题，而是系统问题。
一个好 harness 往往包含什么
1. 短入口，不是长说明书
超长单文件说明通常会很快失效。
更稳的做法是：
- 用短
AGENTS.md做目录 - 真正的知识源分层放在 repo 里
- 让 agent 知道“去哪里找”，而不是一次塞满上下文
2. Repo 内知识才算可见知识
Slack、口头约定、临时文档，对 agent 来说往往等于不存在。
如果规则真的重要，它应该：
- 在 repo 内
- 可版本化
- 可链接
- 可校验
3. 机械边界比口头风格更重要
agent 不是不怕规则，而是更依赖规则。
所以比起“尽量这样写”，更有效的是：
- 明确层级依赖
- 明确 schema 边界
- 明确文件大小和命名限制
- 用 lint 和结构测试强制执行
4. 验证和观测要对 agent 可用
只会写、不会验的 agent，最终一定把 QA 压力推回人类。
更成熟的 harness 会想办法让 agent 直接看到：
- 测试结果
- UI 路径
- 日志
- metrics
- traces
5. 熵增要持续清理
AI 代码库特别容易复制已有模式。
如果库里已经有不整洁的写法，agent 会把它扩散得更快。
所以 cleanup 不是锦上添花，而是基础设施。
它为什么和你现在的 AI Coding 选型也有关
很多人会把 Claude Code、Codex CLI、Cursor、Windsurf 只看成工具对比题。
但当你用深一点以后，真正的差异会开始落到 harness 上：
- 你能不能把项目规范显式化
- 你能不能让 agent 自己验证
- 你有没有稳定的 repo 入口和执行顺序
- 你是不是已经把知识、lint 和回路变成了“环境的一部分”
所以后半段真正拉开差距的，通常不是“谁第一次写得更像人”，而是谁更容易被你放进一个稳定 harness 里。
如果你想先把几个基础词看顺，也可以先看词典里的：
对个人开发者和小团队意味着什么
你不需要一上来就做成一套大平台。
更现实的第一步是：
- 把仓库的知识入口变短、变清楚
- 把关键规则写进 repo
- 把验证动作标准化
- 把常见坏模式沉淀成 lint 或 checklist
- 定期做清理，而不是等库变脏后集中返工
这也是为什么很多团队最后会从“单纯换工具”走向“重构自己的 harness”。
下一步怎么接着看
如果你想继续往下走，推荐按这个顺序：
- Harness Engineering 检查清单
- Open Harness 是什么：其实官方名称是 Harness Open Source
- Harness Open Source 安装与入门指南
- Harness Engineering vs Prompt Engineering
- AI 编程工具更适合 IDE 还是终端
- 如何把 Agent 工作流从 demo 变成稳定系统
参考与延伸阅读
Continue exploring
Use a tool first
If you need to format JSON, XML, YAML, or prompts, start with the online tools.
See implementation projects
If you want to see how these methods enter real builds and experiments, continue with projects.
Get checklists and templates
If you need checklists, resource entries, or SOP starter packs, continue with resources.
Download reusable skills
If you want repeatable judgment, search, and cleanup actions, continue with the skill market.
Glossary
Harness Engineering
围绕 AI coding agent 设计仓库结构、知识入口、约束、校验、观测与反馈回路，让代理在可控范围内稳定交付的工程方法。
Agent Legibility
不是只让人类读得懂，而是让 agent 能在仓库内找到需要的知识、规则和验证方式。
System of Record
团队默认把哪一层信息视作真正可信的来源；在 harness engineering 里，通常更强调 repo 内、可版本化、可校验的知识。
要点总结
- - 当 agent 开始稳定产出代码后，瓶颈通常会从“能不能写”转向“能不能长期维持质量和一致性”
- - Harness Engineering 关心的重点是 repo 结构、知识入口、边界、反馈回路和清理机制
- - 好的 harness 让 humans steer、agents execute；差的 harness 会让团队反复回到人工救火
常见问题
Harness Engineering 是不是只是 Prompt Engineering 的新包装？
不是。Prompt 只是其中一层。Harness Engineering 更关注仓库结构、知识源、验证、观测、review 与长期维护机制。
只有大团队才需要 Harness Engineering 吗？
不是。只要你已经开始让 agent 连续改仓库、跑验证、提 PR，小团队也会很快遇到同样的问题。
Harness Engineering 会不会替代传统软件工程？
不会。它更像是在 agent-first 环境里，把传统工程纪律转移到环境、约束和反馈系统上。
