Harness Engineering vs Prompt Engineering：团队开始让 agent 连续改仓库后，重点为什么会变
Prompt Engineering 解决的是单次交互质量，Harness Engineering 解决的是 agent-first 团队的长期稳定性。把这两层分开，很多工程判断会一下子清楚。
Find related content
Search the site for tools, terms, comparison pages, or related troubleshooting notes without going back to the blog index.
Main answer
Prompt Engineering 更关心这次怎么问得更好，Harness Engineering 更关心 agent 在仓库和团队流程里能不能长期稳定工作。
Who should read this
适合已经在用 Claude Code、Codex CLI、Cursor 或其他 coding agent，并开始发现问题不再只在 prompt 上的团队。
Key check
OpenAI 在 2026-02-11 的 Harness Engineering 文章里强调的重点，已经明显超出 prompt 本身，转向 repo 入口、知识源、验证、观测和 cleanup 机制。
Next step
如果你已经确认团队问题不只是 prompt，下一步就看检查清单；如果你想看平台层落地，可以接着看 Harness Open Source 组文。
Harness Engineering vs Prompt Engineering：团队开始让 agent 连续改仓库后，重点为什么会变
先说结论
这两个词容易被混在一起，但它们解决的不是同一层问题。
Prompt Engineering主要解决单次交互质量Harness Engineering主要解决长期工程稳定性
如果你只是让模型回答一个问题、写一段文案、补一小段代码，Prompt 往往已经很重要。
但如果你开始让 agent：
- 连续读仓库
- 修改多文件
- 跑验证
- 提 PR
- 反复进入团队开发链路
那重点通常会从“这次提示词怎么写”转向“环境和回路怎么设计”。
Prompt Engineering 更关心什么
Prompt Engineering 关心的通常是：
- 角色怎么设定
- 任务怎么表达更清楚
- 约束怎么写得更具体
- 输出格式怎么固定
- 歧义怎么减少
它非常适合解决：
- 一次性问答
- 单轮生成
- 可控格式输出
- 局部代码修改
这层当然重要，而且很多场景下依然是第一层。
Harness Engineering 更关心什么
Harness Engineering 的问题会更偏工程系统：
- agent 先看哪里
- 真正可信的知识源放在哪里
- 哪些规则只是说明，哪些规则能被机器校验
- 改完之后默认跑哪些验证
- 出错后怎么回退
- 坏模式怎么被持续清理
也就是说，它问的不是：
“这次怎么提示更好？”
而是：
“这个团队怎样让 agent 在仓库里长期不跑偏？”
为什么团队一进 agent-first 阶段，主矛盾就会变
很多团队一开始以为问题都在 prompt 上。
但当 agent 使用频率上来后，真正反复出现的往往是这些：
- 同样的背景每次都要重新解释
- 文档、代码和真实行为不一致
- agent 能改，但不会自证改对
- review 压力越来越重
- 坏风格和坏结构被不断复制
这类问题很难靠“再多写两句 prompt”彻底解决。
因为它们已经不只是交互质量问题，而是：
- repo legibility
- system of record
- validation path
- feedback loop
- cleanup mechanism
这些才是 Harness Engineering 真正在处理的层。
如果你想先把几个词的边界看得更紧一点，可以直接跳词典：
两者最好的关系不是替代，而是分层
更实用的理解方式是：
- Prompt Engineering 负责把单次任务说清楚
- Harness Engineering 负责把长期工作环境搭起来
前者像“这一次怎么表达”
后者像“以后都按什么机制运转”
所以在成熟团队里，常见的状态不是二选一，而是：
- 用 prompt 处理局部任务表达
- 用 harness 处理规则、入口、验证和回路
什么时候说明你该少纠结 prompt，多补 harness
如果你开始出现下面这些信号，通常就该把注意力往 harness 移：
- agent 不只是在回答，而是在持续改仓库
- 你已经给过很多 prompt，但结果稳定性还是差
- 问题经常出在验证、结构、环境而不是输出文字本身
- 团队成员之间开始需要统一 agent 工作方式
- 你发现 review 和 cleanup 成本在上升
这时最有效的动作往往不是继续拉长提示词，而是：
- 建短入口
- 把关键知识移进 repo
- 把高频规则变成 lint / schema / CI
- 给 agent 打开验证和观测入口
- 设计回退与人工接管点
我的简化判断法
- 如果你在优化单次回答或单次输出：优先想
Prompt Engineering - 如果你在优化 agent 的长期协作与仓库行为：优先想
Harness Engineering - 如果你两边都遇到了：说明你已经进入“prompt 还要做，但主瓶颈开始转向 harness”的阶段
下一步建议看什么
- 什么是 Harness Engineering
- Harness Engineering 检查清单
- Open Harness 是什么：其实官方名称是 Harness Open Source
- Harness Open Source vs GitHub Actions
参考与延伸阅读
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.
要点总结
- - Prompt Engineering 解决单轮输出质量，Harness Engineering 解决连续协作稳定性。
- - 当 agent 开始持续改仓库、跑验证和提 PR，仓库结构和反馈回路通常比多写几句 prompt 更重要。
- - 两者不是互斥关系，而是不同层级。
常见问题
Harness Engineering 会不会取代 Prompt Engineering？
不会。Prompt 仍然重要，但在 agent-first 团队里，它不再是唯一主轴。
个人开发者有必要看 Harness Engineering 吗？
有必要，只是规模可以更轻。只要你已经让 agent 持续动仓库和验证链，就会很快遇到同类问题。
