Harness 工程：如何构建可靠的 AI 智能体
文章：8
Harness 工程（harness engineering）是一门学科，研究如何在语言模型周围搭建环境，让 AI 智能体能够可靠地完成真实工作。核心公式：智能体 = 模型 + Harness。同一个模型在一个项目中像经验丰富的开发者，在另一个项目中却会丢失上下文，并报告一个跑不通的功能“已完成”。两者的差别几乎总是在 Harness，而不在模型。
本指南是主题地图，汇集了核心概念以及学习它们的推荐顺序。每个主题都在单独的文章中有详细讲解。
Harness 的五个子系统
- 指令——CLAUDE.md 和 AGENTS.md 文件、专题文档和 skills：智能体对项目的了解。
- 工具——shell、文件编辑、浏览器、MCP 服务器：智能体如何采取行动。
- 环境——沙箱、容器、隔离的工作副本：智能体在哪里运行命令。
- 状态——计划和进度文件、git 历史：跨会话的记忆。
- 反馈——测试、代码检查、钩子、独立检查者：智能体如何得知自己出错。
这些子系统构成一个闭环。去掉任何一个，闭环就会断开：没有检查，智能体看不到错误；没有状态，每次会话都从零开始。
从哪里开始
如果这是一个新主题，先阅读关于什么是 harness engineering、它与提示词和上下文工程有何不同的文章。关于智能体 Harness 的简短定义和示例，可以在 Harness 定义的文章中找到。
接下来转向实践。每个人遇到的第一个文件，都是项目指令：CLAUDE.md 和 AGENTS.md 应该写什么，不应该写什么，以及为什么智能体会忽略文件中明确写着的规则。
当智能体已经在项目中工作时，可靠性就成了问题。分步计划从失败日志和 MTBF、MTTR 指标出发，经过低成本回滚、反馈回路和基于文件的记忆，最终到达可以连续工作数小时的自主循环。
核心原则
- 智能体没有坏，坏的是环境。先寻找 Harness 中的漏洞，而不是更换模型。
- 从反馈开始：一条验证命令比一页说明文字更有价值。
- 指令是地图，而不是教科书：入口文件要短，细节按需加载。
- 重要的东西存放在文件中，而不是上下文窗口里。
- 用数据衡量：用失败日志代替感觉。
Harness 的各个子系统以及它的完整搭建，都在 Harness 工程课程中结合实践做了讲解。