大家后，我是舒一笑不秃头，喜欢写作和分享，更多精彩内容～
这两个月，技术圈里一个词突然开始高频出现：
Harness Engineering（Harness 工程）
很多人第一反应是：
“这是不是 Harness 那家 DevOps 公司提出来的概念？”
“这是不是 Prompt Engineering 的新说法？”
“这是不是给 Agent 接点工具就行了？”
都不是。
这个词之所以突然火起来，是因为 OpenAI 和 Anthropic 这类一线 AI 公司，开始反复强调一件事：
当模型越来越强，真正拉开差距的，已经不是模型本身，而是你怎么把它接进真实工程系统里。 OpenAI 在 2026 年 2 月发布的文章里，直接把这个主题命名为 Harness engineering；Anthropic 在 2025 年末和 2026 年 3 月的工程文章里，也连续强调 harness design 对长时运行 agent 的关键作用。 (OpenAI)
所以今天这篇文章，我就讲清楚三件事：
- Harness 工程到底是什么
- 它为什么会在 AI 时代爆火
- 它和 Prompt Engineering、Agent Engineering、平台工程、DevOps 到底有什么区别
一句话先讲明白：什么是 Harness 工程？
你可以先记住这个定义：
Harness 工程，就是把“大模型的能力”驯化成“稳定生产力”的工程。
模型很聪明，不代表它能在真实业务里可靠工作。
一个 AI agent 真正进入工程体系之后，会立刻遇到这些问题：
- 它能看到哪些上下文？
- 它能调用哪些工具？
- 哪些命令可以执行，哪些绝对不能碰？
- 它做完一步之后，如何验证结果对不对？
- 失败了怎么回滚？
- 什么时候必须交给人类审批？
- 它的行为如何审计？
这些问题，都不是模型问题，而是 Harness 工程问题。
所以业内常说一句非常形象的话：
Agent = Model + Harness
模型负责“会不会”，
Harness 负责“能不能稳定、安全、可控地干活”。
Anthropic 也明确指出，前沿 agent coding 的表现，越来越依赖 harness design，而不是只靠更强的模型。 (Anthropic)
为什么它突然火了？
因为大家都发现了一个残酷现实：
同一个模型，放在不同的工程环境里，表现差距可能大得离谱。
OpenAI 在介绍他们如何在“agent-first”世界里使用 Codex 时，重点讲的并不是“模型多强”，而是：
- 代码仓库怎么组织，才能让 agent 更容易理解
- 为什么要把 repo 作为 record system
- 为什么要写
AGENTS.md - 为什么上下文是稀缺资源，不能胡乱堆信息
- 为什么要把浏览器调试能力、可观测性工具接进 agent runtime
- 为什么要让 agent 能复现 bug、验证修复、录制结果，再去发起 PR
这些都说明一个事实：
模型能力已经不是唯一瓶颈，系统设计才是。 (OpenAI)
换句话说，以前大家在卷“模型够不够聪明”，现在开始卷的是：
“你有没有办法让这个模型，在真实软件工程流程里持续产出价值。”
这就是 Harness 工程爆火的根本原因。
Harness 工程不是 Prompt Engineering 的升级版
很多人第一次听到这个词，会误以为它只是“高级提示词工程”。
其实差别非常大。
Prompt Engineering 关心的是：
- 提示词怎么写
- 一次对话怎么问得更准
- 单轮输出怎么更好
Harness Engineering 关心的是：
- agent 如何在长流程里持续工作
- 如何给它上下文、工具、权限和反馈
- 如何让它在真实工程里可验证、可审计、可恢复
- 如何让它做完任务，而不是只回答一个问题
所以：
Prompt Engineering 优化的是“回答质量”
Harness Engineering 优化的是“任务完成率和系统可靠性”
这两者不是一个层级的东西。
Harness 工程，本质上在做什么？
如果把它拆开看，Harness 工程其实就是在搭一整套 AI 工作底座。
1. 给 Agent 设定清晰任务边界
你不能只跟 agent 说一句：
“去把这个 bug 修了。”
你得告诉它：
- 只能改哪些目录
- 不能动哪些模块
- 成功标准是什么
- 必须通过哪些测试
- 哪些操作需要人工确认
比如：
- 只能修改
services/order - 不允许改数据库 schema
- 必须通过单测和 lint
- 不能直接 merge 到主分支
这就是 Harness。
因为没有边界的 agent，不叫智能体，叫事故制造机。
2. 给 Agent 喂“正确”的上下文
OpenAI 在文章里特别强调：
上下文是一种稀缺资源。
不是你给得越多越好，给错了、给杂了，agent 反而会优化错方向。 (OpenAI)
所以 Harness 工程要解决的不是“怎么塞更多上下文”，而是：
- 哪些文档必须给
- 哪些历史 PR 值得参考
- 哪些规范是最新的
- 哪些信息已经过期
- 如何把上下文组织成 agent 真能消费的结构
这就是为什么很多团队开始重视：
- 更清晰的 repo 结构
- 更明确的模块边界
- 给 agent 写专用说明文件
- 把知识从“散落的聊天记录”变成“结构化可消费文档”
3. 给 Agent 接工具，但不是无限放权
这是最容易被误解的一点。
很多团队一上来就想：
“给它接个 shell，给它 kubectl，给它数据库查询权限，不就能干活了吗？”
错。
真正的 Harness 工程不是“给 agent 尽可能多的能力”，而是：
给它刚刚好的能力，并且严格受控。
比如一个运维观测场景里，正确的问题不是：
“Agent 会不会用 kubectl？”
而是：
- 给不给它 kubectl？
- 只允许
get/list/logs，还是连exec也放开？ - 能不能查
secrets？ - 能不能跨 namespace？
- 能不能访问生产环境？
- 是否需要短期 token？
- 是否有操作审计？
这时候你做的，已经不是“提示词工程”了，而是 Harness 工程。
4. 给 Agent 建反馈回路
人类工程师之所以能不断修正，是因为我们每做一步都有反馈：
- 测试挂了
- 页面渲染错了
- 日志里还有异常
- 构建失败了
- 指标没下降
- 回归没通过
Agent 也一样。
OpenAI 提到，他们把浏览器调试能力、DOM snapshot、截图、导航能力，以及 observability tooling 接入 agent runtime，让 agent 不只是“生成代码”，而是能复现问题、验证修复、再提交结果。 (OpenAI)
这件事非常重要。
因为没有反馈的 agent，本质上是在盲飞。
它不是在解决问题，它是在连续猜测。
5. 给 Agent 装护栏，而不是给它自由
Harness 工程最核心的一层，其实是控制。
要控制什么？
- 不能删资源
- 不能读敏感数据
- 不能直接发版
- 不能越过审批
- 不能跳过测试
- 不能碰生产配置
- 不能在未授权场景执行高危命令
如果说模型像发动机，
那 Harness 就是方向盘、刹车、限速器、安全气囊。
没有这些东西，模型越强，风险越大。
6. 设计“什么时候必须交还给人”
这也是很多人忽略的一点。
Harness 工程不是为了追求“100% 全自动”。
恰恰相反，成熟的 Harness 工程会非常明确地规定：
哪些事 agent 可以自己做，哪些事必须让人拍板。
例如：
- 多方案取舍，交给人
- 高风险变更，交给人
- 线上事故定责，交给人
- 涉及权限开通，交给人
- 涉及成本和业务决策，交给人
这才是真正可落地的人机协作。
一个特别好懂的类比：AI 不是员工，Harness 才是管理体系
很多人现在对 AI 的期待，是把它当成一个“超级工程师”。
但更准确的理解应该是：
AI 更像一个执行能力很强、速度很快、知识很广，但边界感很差的新同事。
它需要的不是更多鼓励，而是完整的管理体系：
- 岗位说明书
- 权限系统
- 工具系统
- 代码规范
- 评审流程
- 测试体系
- 审计机制
- 升级路径
这个管理体系，就是 Harness。
所以可以再说得更直白一点：
Harness 工程，本质上是 AI 员工的组织管理工程。
它和 Agent Engineering、平台工程、DevOps 有什么区别？
这是最容易混淆的地方。
和 Agent Engineering 的区别
Agent Engineering 更偏“怎么做一个 agent 产品”：
- 任务拆解
- memory
- planning
- tool calling
- multi-agent
- interaction
Harness Engineering 更偏“怎么让 agent 在真实系统里稳定工作”：
- 权限
- 上下文供给
- 工具接入
- 验证
- 审计
- 安全边界
- 人机切换
你可以理解为：
Agent Engineering 更偏智能体能力设计
Harness Engineering 更偏智能体运行环境设计
和平台工程的区别
平台工程关注的是：
- 开发者平台
- CI/CD
- 可观测性
- 自助服务
- 标准化研发底座
Harness 工程有点像平台工程在 AI 时代的一个新分支。
因为它也是在做平台，但服务对象从“人类工程师”扩展到了“AI agent”。
以前平台工程是服务开发者，
现在 Harness 工程是服务开发者 + 智能体。
和 DevOps 的区别
DevOps 强调的是：
- 开发和运维协同
- 自动化交付
- 持续集成与部署
- 更快更稳定的软件交付
Harness 工程则是在此基础上多了一层：
如何让 AI 参与并接管其中一部分流程，而且还能保持可控。
你甚至可以说：
Harness 工程 = DevOps + 平台工程 + AI Agent 运行控制
为什么说它会成为未来 2 年最值钱的工程能力之一？
因为接下来真正有壁垒的，不是“谁会调用模型 API”。
而是：
谁能把模型真正接进组织生产系统，并稳定地产出结果。
这件事的难度，远远高于“接个对话框”。
未来团队之间的差距，很可能不是：
- 谁用了更大的模型
而是：
- 谁给模型准备了更好的工作环境
- 谁把上下文组织得更好
- 谁的工具链更可控
- 谁的验证机制更闭环
- 谁的审计、权限、回滚做得更严密
OpenAI 和 Anthropic 最近公开分享的工程经验，本质上都在指向同一个趋势：
Agent 的上限，越来越取决于 Harness。 (OpenAI)
一个你一定会遇到的误区：把 Harness 工程做成“万能接口拼装”
很多团队会在这个阶段踩坑：
“我们已经给 agent 接了代码库、日志、监控、Shell、数据库、工单系统，所以我们也在做 Harness 工程了。”
不一定。
因为真正的 Harness 工程，不是“把工具全接上”，而是：
- 工具有没有权限边界？
- 输出有没有校验？
- 操作有没有审计？
- 高危行为有没有熔断？
- 上下文会不会污染？
- 失败后能不能恢复？
- 模型是不是在错误反馈里越跑越偏？
所以 Harness 工程的核心不是连接能力，而是控制能力。
最后一句话总结
如果你非要让我把 Harness 工程浓缩成一句最适合传播的话，那就是：
Prompt Engineering 解决的是“AI 怎么回答更好”，Harness Engineering 解决的是“AI 怎么真正把活干好”。
或者再狠一点：
模型决定 AI 聪不聪明，Harness 决定 AI 能不能上生产。
这就是它最近爆火的原因。
因为从今年开始，越来越多团队已经意识到：
AI 时代真正的工程护城河，不只是模型能力，而是 Harness 能力。
接下来真正会拉开团队差距的，可能不是谁先接入 AI，而是谁先把 Harness 工程做好。
你们团队现在更像是：
“把 AI 当聊天工具” ，还是已经开始建设 “AI 的工作底座” 了？
