大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



大家后，我是舒一笑不秃头，喜欢写作和分享，更多精彩内容～

这两个月，技术圈里一个词突然开始高频出现：

Harness Engineering（Harness 工程）

很多人第一反应是：

都不是。

这个词之所以突然火起来，是因为 OpenAI 和 Anthropic 这类一线 AI 公司，开始反复强调一件事：

当模型越来越强，真正拉开差距的，已经不是模型本身，而是你怎么把它接进真实工程系统里。 OpenAI 在 2026 年 2 月发布的文章里，直接把这个主题命名为 Harness engineering；Anthropic 在 2025 年末和 2026 年 3 月的工程文章里，也连续强调 harness design 对长时运行 agent 的关键作用。 (OpenAI)

所以今天这篇文章，我就讲清楚三件事：

1. Harness 工程到底是什么
2. 它为什么会在 AI 时代爆火
3. 它和 Prompt Engineering、Agent Engineering、平台工程、DevOps 到底有什么区别

---

你可以先记住这个定义：

Harness 工程，就是把“大模型的能力”驯化成“稳定生产力”的工程。

模型很聪明，不代表它能在真实业务里可靠工作。

一个 AI agent 真正进入工程体系之后，会立刻遇到这些问题：

• 它能看到哪些上下文？
• 它能调用哪些工具？
• 哪些命令可以执行，哪些绝对不能碰？
• 它做完一步之后，如何验证结果对不对？
• 失败了怎么回滚？
• 什么时候必须交给人类审批？
• 它的行为如何审计？

这些问题，都不是模型问题，而是 Harness 工程问题。

所以业内常说一句非常形象的话：

Agent = Model + Harness

Anthropic 也明确指出，前沿 agent coding 的表现，越来越依赖 harness design，而不是只靠更强的模型。 (Anthropic)

---

因为大家都发现了一个残酷现实：

同一个模型，放在不同的工程环境里，表现差距可能大得离谱。

OpenAI 在介绍他们如何在“agent-first”世界里使用 Codex 时，重点讲的并不是“模型多强”，而是：

• 代码仓库怎么组织，才能让 agent 更容易理解
• 为什么要把 repo 作为 record system
• 为什么要写 AGENTS.md
• 为什么上下文是稀缺资源，不能胡乱堆信息
• 为什么要把浏览器调试能力、可观测性工具接进 agent runtime
• 为什么要让 agent 能复现 bug、验证修复、录制结果，再去发起 PR

这些都说明一个事实：

模型能力已经不是唯一瓶颈，系统设计才是。 (OpenAI)

换句话说，以前大家在卷“模型够不够聪明”，现在开始卷的是：

“你有没有办法让这个模型，在真实软件工程流程里持续产出价值。”

这就是 Harness 工程爆火的根本原因。

---

很多人第一次听到这个词，会误以为它只是“高级提示词工程”。

其实差别非常大。

• 提示词怎么写
• 一次对话怎么问得更准
• 单轮输出怎么更好

• agent 如何在长流程里持续工作
• 如何给它上下文、工具、权限和反馈
• 如何让它在真实工程里可验证、可审计、可恢复
• 如何让它做完任务，而不是只回答一个问题

所以：

Prompt Engineering 优化的是“回答质量”
Harness Engineering 优化的是“任务完成率和系统可靠性”

这两者不是一个层级的东西。

---

如果把它拆开看，Harness 工程其实就是在搭一整套 AI 工作底座。

你不能只跟 agent 说一句：

“去把这个 bug 修了。”

你得告诉它：

• 只能改哪些目录
• 不能动哪些模块
• 成功标准是什么
• 必须通过哪些测试
• 哪些操作需要人工确认

比如：

• 只能修改 services/order
• 不允许改数据库 schema
• 必须通过单测和 lint
• 不能直接 merge 到主分支

这就是 Harness。

因为没有边界的 agent，不叫智能体，叫事故制造机。

---

OpenAI 在文章里特别强调：

上下文是一种稀缺资源。
不是你给得越多越好，给错了、给杂了，agent 反而会优化错方向。 (OpenAI)

所以 Harness 工程要解决的不是“怎么塞更多上下文”，而是：

• 哪些文档必须给
• 哪些历史 PR 值得参考
• 哪些规范是最新的
• 哪些信息已经过期
• 如何把上下文组织成 agent 真能消费的结构

这就是为什么很多团队开始重视：

• 更清晰的 repo 结构
• 更明确的模块边界
• 给 agent 写专用说明文件
• 把知识从“散落的聊天记录”变成“结构化可消费文档”

---

这是最容易被误解的一点。

很多团队一上来就想：

“给它接个 shell，给它 kubectl，给它数据库查询权限，不就能干活了吗？”

错。

真正的 Harness 工程不是“给 agent 尽可能多的能力”，而是：

给它刚刚好的能力，并且严格受控。

比如一个运维观测场景里，正确的问题不是：

“Agent 会不会用 kubectl？”

而是：

• 给不给它 kubectl？
• 只允许 get/list/logs，还是连 exec 也放开？
• 能不能查 secrets？
• 能不能跨 namespace？
• 能不能访问生产环境？
• 是否需要短期 token？
• 是否有操作审计？

这时候你做的，已经不是“提示词工程”了，而是 Harness 工程。

---

人类工程师之所以能不断修正，是因为我们每做一步都有反馈：

• 测试挂了
• 页面渲染错了
• 日志里还有异常
• 构建失败了
• 指标没下降
• 回归没通过

Agent 也一样。

OpenAI 提到，他们把浏览器调试能力、DOM snapshot、截图、导航能力，以及 observability tooling 接入 agent runtime，让 agent 不只是“生成代码”，而是能复现问题、验证修复、再提交结果。 (OpenAI)

这件事非常重要。

---

Harness 工程最核心的一层，其实是控制。

要控制什么？

• 不能删资源
• 不能读敏感数据
• 不能直接发版
• 不能越过审批
• 不能跳过测试
• 不能碰生产配置
• 不能在未授权场景执行高危命令

没有这些东西，模型越强，风险越大。

---

这也是很多人忽略的一点。

Harness 工程不是为了追求“100% 全自动”。

恰恰相反，成熟的 Harness 工程会非常明确地规定：

哪些事 agent 可以自己做，哪些事必须让人拍板。

例如：

• 多方案取舍，交给人
• 高风险变更，交给人
• 线上事故定责，交给人
• 涉及权限开通，交给人
• 涉及成本和业务决策，交给人

这才是真正可落地的人机协作。

---

很多人现在对 AI 的期待，是把它当成一个“超级工程师”。

但更准确的理解应该是：

AI 更像一个执行能力很强、速度很快、知识很广，但边界感很差的新同事。

它需要的不是更多鼓励，而是完整的管理体系：

• 岗位说明书
• 权限系统
• 工具系统
• 代码规范
• 评审流程
• 测试体系
• 审计机制
• 升级路径

这个管理体系，就是 Harness。

所以可以再说得更直白一点：

Harness 工程，本质上是 AI 员工的组织管理工程。

---

这是最容易混淆的地方。

Agent Engineering 更偏“怎么做一个 agent 产品”：

• 任务拆解
• memory
• planning
• tool calling
• multi-agent
• interaction

Harness Engineering 更偏“怎么让 agent 在真实系统里稳定工作”：

• 权限
• 上下文供给
• 工具接入
• 验证
• 审计
• 安全边界
• 人机切换

你可以理解为：

Agent Engineering 更偏智能体能力设计
Harness Engineering 更偏智能体运行环境设计

---

平台工程关注的是：

• 开发者平台
• CI/CD
• 可观测性
• 自助服务
• 标准化研发底座

Harness 工程有点像平台工程在 AI 时代的一个新分支。

因为它也是在做平台，但服务对象从“人类工程师”扩展到了“AI agent”。

---

DevOps 强调的是：

• 开发和运维协同
• 自动化交付
• 持续集成与部署
• 更快更稳定的软件交付

Harness 工程则是在此基础上多了一层：

如何让 AI 参与并接管其中一部分流程，而且还能保持可控。

你甚至可以说：

Harness 工程 = DevOps + 平台工程 + AI Agent 运行控制

---

因为接下来真正有壁垒的，不是“谁会调用模型 API”。

而是：

谁能把模型真正接进组织生产系统，并稳定地产出结果。

这件事的难度，远远高于“接个对话框”。

未来团队之间的差距，很可能不是：

• 谁用了更大的模型

而是：

• 谁给模型准备了更好的工作环境
• 谁把上下文组织得更好
• 谁的工具链更可控
• 谁的验证机制更闭环
• 谁的审计、权限、回滚做得更严密

OpenAI 和 Anthropic 最近公开分享的工程经验，本质上都在指向同一个趋势：

Agent 的上限，越来越取决于 Harness。 (OpenAI)

---

很多团队会在这个阶段踩坑：

“我们已经给 agent 接了代码库、日志、监控、Shell、数据库、工单系统，所以我们也在做 Harness 工程了。”

不一定。

因为真正的 Harness 工程，不是“把工具全接上”，而是：

• 工具有没有权限边界？
• 输出有没有校验？
• 操作有没有审计？
• 高危行为有没有熔断？
• 上下文会不会污染？
• 失败后能不能恢复？
• 模型是不是在错误反馈里越跑越偏？

所以 Harness 工程的核心不是连接能力，而是控制能力。

---

如果你非要让我把 Harness 工程浓缩成一句最适合传播的话，那就是：

Prompt Engineering 解决的是“AI 怎么回答更好”，Harness Engineering 解决的是“AI 怎么真正把活干好”。

或者再狠一点：

模型决定 AI 聪不聪明，Harness 决定 AI 能不能上生产。

这就是它最近爆火的原因。

因为从今年开始，越来越多团队已经意识到：

AI 时代真正的工程护城河，不只是模型能力，而是 Harness 能力。

---

接下来真正会拉开团队差距的，可能不是谁先接入 AI，而是谁先把 Harness 工程做好。