Harness Engineering：AI 时代真正稀缺的能力
当 AI 已经足够聪明，为什么还是频繁出错？答案不在模型，在它工作的"环境"。
2026年4月 · 科普向 · 约 10 分钟阅读
目录
- 从一个真实失败开始说起
- 三个容易混淆的概念
- Anthropic 的方案：两阶段双 Agent 架构
- OpenAI 的方案：给 AI 搭一套"死规矩"
- 思维方式的根本转变
- Harness Engineering 究竟是什么
01 · 从一个真实失败开始说起
想象这样一个场景：你的团队部署了一个 AI Agent，它在演示时表现完美——能流畅回答复杂问题、按顺序调用工具、给出合理的结论。所有人都很满意，于是把它推向了生产环境。
凌晨三点，这个 Agent 遇到了一个接口偶尔返回错误的第三方 API。没有人在看。它开始重试，一次、十次、一百次，在一个无人知晓的循环里默默燃烧了 400 美元的 API 调用费用，什么有用的事都没做到。
模型没有问题。Prompt 没有问题。问题在于：包裹这个模型的系统，根本不存在。
这不是极端案例，这是 2025、2026 年大量团队正在经历的常态。AI 已经足够聪明，但"足够聪明"和"可以在真实世界里稳定工作"之间，还隔着一整套尚未被认真对待的工程问题。
这套工程问题，现在有了一个名字：Harness Engineering（驾驭工程）。
02 · 三个容易混淆的概念
在理解 Harness Engineering 之前，先要把三个经常被混在一起的概念区分清楚。AI 博主 Louis 用一个汽车类比把它说得非常透彻：
提示词工程（Prompt Engineering）— 你说什么 怎么提问、怎么描述需求，让 AI 更好地理解你的意图。这是和 AI 交流的"语言"。
上下文工程（Context Engineering）— 给什么信息 在对话里塞入什么背景材料、相关文档、历史记录，让 AI 有足够的信息来回答好。这是 AI 的"燃油和仪表盘"。
驾驭工程（Harness Engineering）— 整个系统怎么运作 工具权限、错误处理、重试机制、测试验证、状态管理、日志监控……AI 工作的完整环境。这是汽车的方向盘、刹车和确保车门不会在高速上飞出去的那些东西。
一句话区别：提示词工程决定你问了什么，上下文工程决定 AI 看到了什么，驾驭工程决定这件事从头到尾能不能可靠地完成。更大的上下文窗口，并不能把一个不稳定的 Agent 变成可靠的系统。
📄 参考：Harness Engineering: The Missing Layer Behind AI Agents — Louis Bouchard
03 · Anthropic 的方案：跨越多个会话，如何保持持续推进？
Anthropic 在 2025 年 11 月发布了一篇工程博客，聚焦一个非常具体的问题：如何让 AI 在跨越多个上下文窗口时，仍能持续稳定地完成复杂任务？
他们用了一个绝妙的比喻：想象一个软件项目，由轮班工程师负责。每个新工程师接班时，对昨天发生的一切一无所知。这正是 AI Agent 的真实处境——每次开启新会话，之前所有的工作记忆全部消失。
没有架构会出现的两种典型失败
失败一：One-shot 冲动 AI 试图在单个会话里做完所有事，结果上下文耗尽时，留下一个功能半实现、没有文档的混乱状态。下一个会话接手的是烂摊子，要先猜发生了什么，再重新收拾，浪费大量时间。
失败二：过早宣布完成 项目进行到一半，AI 看到已经有一些功能，就误以为整个任务完成了。提前收工，大量功能根本没做。
解决方案：两阶段双 Agent 架构
第一阶段：Initializer Agent（只在项目第一天出现）
负责三件事：
- 把需求拆分成 200+ 条具体功能点，每条初始标记为"未完成"，使用 JSON 格式（比普通文字更不容易被 AI 意外改乱）
- 建立工作日志文件，记录每次做了什么、遇到什么问题、下一步建议做什么
- 写一份启动手册（init.sh），告诉后续 AI 如何把整个项目跑起来
第二阶段：Coding Agent（每次会话循环执行）
固定流程如下：
- 来了先读工作日志，了解上次进度
- 按启动手册把项目跑起来，做基础测试确认没遗留 bug
- 从功能清单里选一个最重要的未完成功能
- 只做这一个功能，做完后做端到端测试（像真实用户一样操作，而不是自己说"我觉得好了"）
- 把这个功能标记为完成，更新工作日志，提交存档
- 结束——下一次会话重复这个流程
这套方案最核心的洞见：
不要指望 AI "自己记住"，把记忆变成写在墙上的东西。验收清单、工作日志、存档历史——记忆不在 AI 脑子里，在工地的制度里。
📄 参考：Effective harnesses for long-running agents — Anthropic Engineering
04 · OpenAI 的方案：100 万行代码，零行手写，他们是怎么做到的？
2026 年 2 月，OpenAI 发布了一篇震动业界的文章：他们用一个 3 人团队，在 5 个月内让 AI（Codex）写完了一个正式上线的产品，代码量约 100 万行，全程人类零行手写代码，效率比手动提升约 10 倍。
但他们同样坦承：一开始根本没那么顺利。早期进展极慢，不是因为 AI 不行，而是周围的环境没搭好。当 AI 出问题时，解决方案从来不是"让它再试一次"，而是工程师问自己："AI 缺了什么条件？我怎么把这个条件补上？"
他们做了三件核心的事
第一件：给 AI 一张地图，而不是一本说明书
他们早期把所有规则塞进一个超长文件，结果完全没用。原因有四个：
- 文件太长，AI 的注意力被占满，真正要干的活反而挤不进去
- 什么都"重要"等于什么都不重要，AI 不知道该关注哪条
- 文件会过时，没人维护，AI 会按过时规则干活
- 根本没法自动检查哪些规则还有效
新方案：一份约 100 行的简短目录，指向分散存储的具体文档。AI 需要什么信息，去哪找，目录里写清楚。渐进式获取，而不是一开始就被淹没。
第二件：用"死规矩"来保证质量
代码结构、命名规范、日志格式、文件大小限制——全部用自动检查工具强制执行，违反了直接拦截，AI 必须改了才能提交。
而且报错信息也精心设计过——不只说"这里有问题"，还直接写明"你应该怎么改"。AI 看到报错就能自己修，整个过程不需要人工介入。
第三件：让 AI 能"看见"真实运行状态
把浏览器、日志、监控数据全接入 AI 的工作环境，让 AI 可以：
- 自己打开浏览器点击测试，像真实用户一样操作
- 查看日志和监控数据，自己分析问题
- 发现 bug、提出修复方案、验证结果，全程不需要人
他们还建立了一套"垃圾回收"机制：定期让 AI 自动巡逻代码库，扫描不规范、过时的代码，自己发一个修复请求，大多数一分钟内自动合并。用他们的话说：技术债就像高利贷，要每天还一点点，不能让它越滚越大。
📄 参考：Harness engineering: leveraging Codex in an agent-first world — OpenAI
05 · 思维方式的根本转变
技术方案之外，Harness Engineering 还意味着一个更根本的态度转变。
Mitchell Hashimoto 的这段话，被认为是整个领域最重要的思维框架：
每次 AI 犯错，不要只是希望它下次做得更好。改造环境，让它不能再以同样的方式犯同样的错。
这意味着：出了问题不怪 AI，而是问自己"我的系统哪里没设计好，导致这个错误能发生"，然后把修复设计进环境，让同样的错误以后不可能再发生。
从**"这个模型太蠢了"，变成"是我的系统允许了这个失败"**——这个态度上的转变，比任何具体的技术方案都重要。
而程序员的角色，也随之发生了转变。不是消失，是升级：
- 更少时间手打每一行代码
- 更多时间设计让 Agent 能可靠工作的"栖息地"
- 更多机器可读的文档、更多自动化测试、更多权限边界、更多日志追踪
提示词是最容易的部分，可靠性才是真正的工作。
📄 参考：Harness engineering for coding agent users — Martin Fowler
06 · Harness Engineering 究竟是什么？
用一句话概括：
Harness Engineering 是围绕 AI 模型，设计一套让它能稳定、可靠、持续工作的完整系统环境——提前堵死它可能犯的错，而不是事后亡羊补牢。
这套环境系统由以下部分组成：
| 组成部分 | 负责什么 |
|---|---|
| 提示词工程 | 说清楚要做什么 |
| 上下文工程 | 给对的信息、在对的时机给 |
| 代码规则设计 | 强制约束 AI 的产出符合规范 |
| 出错处理与重试 | 失败了怎么恢复、怎么自我纠正 |
| 测试与验证 | AI 自己验证自己的结果，不靠人工 |
| 记忆与状态管理 | 进度文件、Git 存档、功能清单——跨会话的"交接班"机制 |
最后，值得诚实地说一句：Harness 本身也会成为一个有 bug、会漂移的产品。人类的注意力是真正稀缺的资源。如果 AI 产出的速度远超人类能检查的速度，那严谨性就必须嵌入系统本身——你需要可以信任的自动化检查，需要能安全失败的环境，需要能告诉你哪里出了问题的日志。
这就是为什么 Harness Engineering 重要。它不是 Prompt Engineering 的花哨新名字，它是当你认真尝试把 AI 能力落地到真实世界时，必然会遇到、必须认真对待的那一层工程问题。
参考资料
- Effective harnesses for long-running agents — Anthropic Engineering
- Harness engineering: leveraging Codex in an agent-first world — OpenAI
- Harness Engineering: The Missing Layer Behind AI Agents — Louis Bouchard
- Harness engineering for coding agent users — Martin Fowler
基于 Anthropic、OpenAI、Louis Bouchard、Martin Fowler 等公开资料整理 · 2026年4月
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
13
0- 0
已为社区贡献7条内容
所有评论(0)