测试全绿，bug 还在：AI 编程代理最贵的一种失败
Claude Code、Codex 这类代理能跑通测试、生成漂亮的完成报告，却可能没碰到原始问题。kvro 提出的 Agent Reliability Engineering，把完成定义从模型自述改成可验证证据、预算和恢复边界。
这段 27 秒视频是素材里的演示。
你给 Claude Code 一个修 checkout 的任务，让它跑一夜。早上终端绿了，42 个单测通过，类型检查通过，构建通过，完成报告写得很整齐。然后用户用某个支付方式提交订单，checkout 还是失败。
kvro 在 X 上把这套缺失层称为 Agent Reliability Engineering，代理可靠性工程。他的判断是：代理能生成 2000 行代码、跑 40 个测试、产出完美总结，原始 bug 还在。更贵的是，它可能再花 20 美元修一个从没被准确定义的问题。
这类失败和模型强弱、提示词好坏关系不大。核心是“产出一个看起来正确的工件”与“证明预期结果发生”之间的差距。
绿测试的幻觉
测试通过只说明测试通过。原文把它叫 Green-Test Illusion。代理改动组件、更新单测、跑通测试，但没有复现原始失败。测试验证的是它们被写来检查的行为。用户问题是否解决，需要代理自身最终回答之外的完成定义。
用成果契约替代提示词
提示词说“尝试什么”。成果契约说“系统允许报告完成之前，哪些条件必须为真”。原文给的例子包括：复现原始失败、checkout e2e 通过、无支付回归、应用构建；约束包括最多 3 次尝试、最多 2 美元、保护 infra/production 和 .env；完成条件要求证据、改动文件摘要、部署需人工批准。任务从“说服你完成”变成“产出满足契约的证据”。checkout 测试没跑，不能标记 verified。测试失败，任务保持打开。预算耗尽，停止并升级。
证据引擎与五个组件
常见错误是让第二个大模型评价第一个大模型。主观评审可以，执行证据不能替代。编码任务最强的检查往往确定性很强：命令真的跑了吗？退出码对吗？修复前失败测试失败了吗？修复后通过了吗？浏览器走完用户路径了吗？保护文件被改了吗？原文给了一个最小 Python 验证层，用 subprocess 执行命令并记录 passed、exit_code、stdout、stderr。重点在于成功变成被记录的观察。模型生成的一句话不再算数。模型提议，环境测量，控制器决定。
架构不必是 30 个代理互相聊天。五个组件就够：Planner 把任务转成有界执行计划；Worker 做代码或配置改动；Verifier 跑测试、浏览器检查和验收条件；Recovery Controller 决定是否值得再试；Evidence Ledger 记录发生了什么、什么通过、什么失败、什么仍未知。Planner 和 Worker 可以用同一个模型。Verifier 尽量用独立检查。控制器用代码执行预算，不能只靠提示词要求模型“尊重预算”。Ledger 要能跨上下文重置存活。
恢复循环要知道何时停
无界代理循环危险，因为活动看起来像进展。代理可能反复改同一个文件、重跑同一个失败测试、消耗 token，没有发现新东西。原文给三条规则：每次重试必须有理由；每次尝试必须产生新证据，否则停止；预算限制在模型外执行。一个简化控制器会记录失败指纹，即退出码和错误。指纹重复就返回 STALLED。最好的自主代理不按运行时长排名。它知道下一次尝试没有可测量价值时停下。
按验证结果算成本
AI 代理经济常被说成每百万 token 成本，这只占一部分。更有用的指标是 Cost per verified outcome，每个已验证结果的成本。原文用假设数据：Agent A 总成本 30 美元，55 个验证结果，每个 0.55 美元；Agent B 总成本 42 美元，84 个验证结果，每个 0.50 美元。B 每次尝试更贵，但每个验证结果更便宜。只优化 token 成本会误导。便宜模型反复制造未验证改动，可能比在良好验证系统里的更强模型更贵。AI 工程的经济单位是 accepted result，被接受的结果。
风险分级与持久记忆
不是所有任务都该同一套审批。改文档和删生产记录不一样。低风险自动验证；中风险测试加评审；高风险如支付逻辑要独立验证加批准。关键是用权限和执行边界落实策略。系统提示写“小心”不构成授权机制。不需要生产凭证的任务就不该拿到凭证。部署门禁不能取决于模型自称有信心。自主性应随证据和可逆性增加，不随信心增加。
代理还会丢信息。会话结束或上下文压缩，重要信息可能没了。持久任务记录解决另一个问题：下次运行从实际观察继续，人也能看懂代理为什么停。记录任务、状态、尝试次数、已验证与否、各检查结果、下一步、阻塞原因。记忆保存决策、证据、未解决问题，不保存模型生成过的每个 token。
看板该看什么
多数 AI 看板显示 token 用量、完成任务数、活跃代理数、模型延迟。这些不够。可靠工程看板还应跟踪：已验证完成率、虚假完成率、每个验证结果成本、恢复效率、人工介入率、到验证解决的时间。一个系统 500 个完成任务只有 200 个验证结果，不一定比 300 个完成、280 个验证更高效。指标让不同代理架构可比较，不靠演示效果。
一个可落地的开始
从一个仓库、一类重复任务开始。建三个文件：AGENTS.md 描述仓库、测试命令、架构规则、必须的验证行为；tasks/checkout.yaml 定义验收条件、限制、保护资源；evidence/checkout.json 存观察结果。给代理的指令要它先检查代码、复现失败、记录失败验证命令；修改后跑原始复现测试和相关回归测试，记录命令结果与改动文件，标出未验证的验收条件。未通过全部所需检查并记录证据，不要报告 VERIFIED。同一失败重复且无新证据，停止并报告 STALLED。需要授权就请求批准，不绕过保护边界。提示词建立工作流，外部控制器仍要执行权限、预算、完成规则。提示词是指令，护栏是已实现的边界。
有网友在讨论里说，代理通过了他写的所有检查，仍然发布了他测试没想到的 bug。他现在先不信任测试套件，再谈不信任模型。另一个网友提到 PDF 提取，把 JSON 换成 CSV 后解析错误消失，行仍然缺失。解析器高兴了，提取没完成。还有人说，让代理写测试来评判自己，等于自己批自己的作业。至少需要一个它改不了的检查。
原文最后一句值得放在这里：停止测量 AI 写了多少代码，开始测量它能证明自己解决了多少问题。更好模型重要，更好提示词也重要。工程优势会累积在模型周围那套系统里。
素材与延伸阅读：
发布时间: 2026-11-12 02:27