如何让 AI 智能体变得可靠：从度量到自主工作的分步计划

为什么强大的模型做出的智能体也不可靠

智能体的可靠性是整个系统的属性，而不只是模型的属性。一个长任务由几十个步骤组成，错误会不断累积：每步正确率为 95% 时，连续十步不出错的运行大约只占 60%（0.95^10 ≈ 0.60），连续五十步则不到 10%。你无法直接提高模型的准确率，但可以在错误发生的那一步捕获它，并让它的代价变得很低。这正是 Harness 要做的事：指令、工具、环境、状态和反馈，都围绕模型而搭建。

下面的计划从“凭感觉”出发，逐步走向可度量的可靠性，再走向自主工作。步骤按收益排序，每一步都建立在前一步之上。

第 1 步：停止凭感觉评估

一位工程师确信新的提示词改变了一切，另一位却看不出区别，而没有人记录过任何指标。从失败日志开始：每当智能体卡住、弄坏了什么，或者报告了一个跑不通的功能，就记下一行。

| 日期  | 任务             | 发生了什么                     | 子系统         |
|-------|------------------|--------------------------------|----------------|
| 10.10 | 购物车折扣       | 报告“完成”，但没有运行 e2e     | 反馈           |
| 10.10 | 支付 webhook     | 无法启动数据库                 | 环境           |
| 11.10 | API 重构         | 重复了已被否决的方案           | 状态           |

“子系统”这一列最关键。一周之后，瓶颈在哪里就一目了然，你就只需修复它，而不是什么都改。只用成功运行的次数来衡量可靠性是个错误：正是失败日志能显示智能体在哪里摔倒。

第 2 步：引入两个指标：MTBF 和 MTTR

可靠性可以用两个数字来描述。对智能体而言，MTBF（平均故障间隔）是它连续运行多少步才会卡住；MTTR（平均恢复时间）是出故障之后恢复到可工作状态需要多久。可用性既随前者提高而提高，也随后者缩短而提高。

一味追求一个永远不出错的智能体，是一场没有尽头的竞赛。缩短 MTTR 通常一天之内就能做到，所以应该先从第二个数字入手。

第 3 步：让错误变得便宜

智能体可以自主工作，并不是因为它不再出错，而是因为出错的代价已经降到几乎为零。为此需要三样东西：

• 小而干净的提交——任何修改都能用一条命令回滚。
• 隔离——智能体在独立的分支或工作副本中工作，例如通过 git worktree，并且运行在无法访问生产环境的沙箱里。
• 环境重置脚本——数据库、依赖和服务通过一条命令恢复到初始状态。

git worktree add ../shop-agent -b agent/discount
cd ../shop-agent
make reset   # 重建数据库，应用迁移，加载测试数据

用秒表测量一次完整恢复到可工作状态所需的时间，这就是你的 MTTR。同时限制影响范围：规定单个任务的改动行数上限，并禁止修改任务范围之外的文件。

第 4 步：闭合反馈回路

没有检查时，智能体是唯一的裁判，它会真诚地认为工作已经完成。给它用来自我检查的命令，并让这些命令成为强制项。

• 快速失败（fail-fast）：检查在第一个错误处停止，并给出清晰的信息，而不是输出一百行噪音。
• 每次修改后的快速检查：通过智能体的钩子运行代码检查器和类型检查。
• 冗余：对同一属性做第二次独立检查，例如在单元测试之上加一个端到端场景。通过的单元测试并不能证明功能在用户那里正常工作。

把“完成”的标准写成可验证的条件：“带优惠码的下单端到端场景通过”，而不是“已实现折扣”。

第 5 步：把记忆放进文件

智能体不记得上一次会话。继续工作所需的一切都必须存在于仓库中：目标、已完成的工作及验证方式、带理由的决定、死胡同，以及下一步。好的标志是：新会话只拿到仓库和一句“继续”，就能立即开始有用的工作。

压缩后的长对话历史会给人一种连续性的错觉，但它丢失了最宝贵的东西：被否决方案的理由。有意识地结束会话，并留下完整的书面状态，通常比硬撑更便宜。

第 6 步：一次只做一个任务

利特尔定律指出：任务在系统中的数量等于到达速率乘以每个任务在系统中停留的时间。在处理能力固定的情况下，并行任务并不会加快工作，只会把每个任务拉长。对智能体而言这一点更加明显：三个功能就意味着同一个上下文窗口里放着三套领域模型。

• 保持在制品数量（WIP）为 1：一个功能完成并通过验证后再开始下一个。
• 把任务切小：一个可验证的用户能力，涉及 1 到 3 个文件，验证耗时不超过一分钟。
• 建立 BACKLOG.md 作为“顺带”的出口：智能体注意到相邻的问题时，写一行到待办清单，而不是擅自修改。

第 7 步：分离执行者与检查者

智能体的自我评估是一个很弱的制动器：写代码的同一个会话，往往会认为代码是正确的。应当由单独的子智能体或独立会话来评估结果，它只拿到需求、代码差异和检查结果，看不到执行者的推理过程。检查者的结论应当依据机器检查，而不是“看起来还行”。

第 8 步：放手让智能体进入自主循环

Harness 让单次运行变得可靠，循环则让一连串运行变得自主。在糟糕的 Harness 上运行循环，只会更快地放大错误，所以这一步放在最后。最简单的循环只需三行：

目标：  带优惠码的支付 e2e 场景通过
检查：  make lint && make test && make e2e
停止：  达成目标 或 15 次尝试 或 2 小时 → 请人介入

根据任务选择循环类型。如果工作有明确的终点，就用面向目标的循环：保存进度记忆、独立的检查者和步数预算。如果没有终点（比如每天早上检查 CI、梳理新出现的错误），就用定时循环。常见错误是把一个有终点的任务做成定时任务：每次运行都会从零开始。

安全自主的规则

• 停止条件只能是机器可以验证的，并且要加上尝试次数和预算的上限。
• 提前列出循环无权处理的事项：生产环境的迁移、资金、数据删除。
• 如果任务停滞，检查指标没有实质进展，这就是把任务交还给人的信号，而不是继续空转。
• 认真阅读代码差异。循环的速度不应超过你阅读的速度，否则你就无法理解自己的代码库。

这条路上的常见错误

一上来就改写指令

对智能体失败最常见的反应，是在 AGENTS.md 里再加一条规则。几个月后文件膨胀到数百行，重要的规则反而被淹没。如果失败日志显示智能体没有运行检查，那就应该修复反馈：提供验证命令和钩子，而不是再加一段文字。

一次修所有东西

五个子系统都想同时改进，但这样就无法判断究竟是什么起了作用。给每个子系统打 1 到 5 分，花半小时修复最弱的一个，然后在同样的五个典型任务上前后各跑一遍。失败日志中的差异会告诉你是否有效。

把“测试通过”当成“功能可用”

智能体可能会写一个测试，检验的是它自己的实现而不是需求。这样的测试永远是绿色的。防范办法是：在用户层面做验证（端到端场景），最好在实现之前编写，或者由独立的检查者编写；并规定智能体不得为了让测试通过而修改测试。

为了速度关闭检查

慢检查会诱使人们“这次就跳过”。更好的做法是拆分：快速的代码检查和类型检查在每次修改后运行，完整的测试套件和端到端测试则在声称“完成”之前运行。这样反馈回路保持短促，又不妨碍工作。

把消融实验作为第一步

可以逐个关闭 Harness 的子系统，看质量下降多少。这是有用的检查，但代价高，也不应是第一步。应该先用失败日志找到瓶颈，消融实验只是用来确认假设。关闭某个组件后没有任何下降，并不说明它没用：可能只是所选的任务没有用到它。

成熟度阶梯

总结

要让 AI 智能体变得可靠：先度量，然后通过失败日志找到薄弱的子系统，让错误变得便宜，闭合反馈回路，把记忆放进文件，一次只做一个任务，并把执行者与检查者分开。只有在这之后，带有机器可验证停止条件的自主循环才是安全的。这份计划的每一步，都在 Harness 工程课程中结合一个实际项目做了讲解。