什么是 Harness Engineering：当 AI 开始写代码后，工程重点为什么从写代码转向设计约束与反馈回路
Harness Engineering 不是又一个花哨名词，而是当 AI coding agent 真正进入生产开发后，团队如何通过仓库结构、文档、校验、观测和回路，让代理稳定交付的软件工程方法。
需要继续找相关内容？
如果你想继续查工具名、术语、对比页或相关问题，可以直接搜全站，不用回到博客列表页重找。
核心结论
Harness Engineering 的核心不是再写更长的 prompt，而是把约束、知识、校验、观测和清理机制工程化，让 agent 在一个可控环境里稳定工作。
适合谁看
适合已经在用 Claude Code、Codex CLI、Cursor 等 AI 编程工具，并开始觉得问题不再只是模型能力，而是仓库、流程和反馈回路的人。
关键判断
OpenAI 在 2026 年 2 月 11 日公开分享了一套 agent-first 开发经验：人类主要负责 steer，agents 负责执行，重点转向环境、文档、lint、review、验证和清理机制。
下一步建议
如果你想把这个概念落到日常团队实践，下一步就看 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 变成稳定系统
参考与延伸阅读
继续延伸
术语表
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 环境里，把传统工程纪律转移到环境、约束和反馈系统上。
支付宝扫码赞赏
感谢支持