把智能体线上故障沉淀为回归测试

Agent 在线上把事情办错，改一句 prompt，再看到一次成功，并不能证明问题已经解决。原文提出的办法是：把真实故障压缩成脱敏、可重复执行的测试样本，让同一条错误路径成为下一次发布必须通过的检查。

它最有价值的提醒是：Agent 回归测试不能只看回答是否得体，还要检查工具怎么调用、业务状态有没有改变，以及成功声明有没有证据。对于正在给 AI 接入业务工具的团队，这比继续堆通用评测题更贴近实际故障。

为什么回答没问题，业务却办错了

作者用一个订阅暂停场景解释问题：查询账单超时后，Agent 用格式错误的账户标识重试，随后告诉客户订阅已经暂停。实际操作没有成功，客户仍会被扣费。

单独测试账单工具，正常参数可以通过；检查回答质量，措辞也可能礼貌完整。错误藏在连续动作里：超时、错误回退、尝试写入、未经核实便宣告成功。

轨迹回放（trace replay）就是保留这段因果链，在受控条件下重新测试。先返回当时的超时，再提供备用查询结果，最后要求 Agent 拿到操作回执，才能声称暂停成功；否则必须报告尚未确认。

测试要约束 Agent 做了什么，以及它凭什么宣布成功。

它与可观测性的区别也在这里：可观测性帮助定位已经发生的事，回放把其中的证据变成可执行的发布检查。它也不同于通用评测集，起点是具体事故；不同于事件溯源，目标不是重建全部业务对象，而是留下足以复现错误的最小样本。

怎样保留故障，又不把生产数据搬进测试库

作者主张只记录影响决策的内容：有序事件、独立的关联 ID，以及 prompt、model、tool schema、检索语料和运行策略版本。工具参数应经过校验，敏感值替换成有类型的占位符；结果需要区分成功、可重试失败、永久失败、结果未知和拒绝执行。

对于写操作，还要留下外部 operation ID、权威验证结果，以及最终面向客户的声明和允许该声明的规则。私有推理过程不需要记录，验证工具顺序、结构化参数和回执并不依赖它。

脱敏不能顺手修好故障。例如，把 alex@example.com 一致替换为 user_01@example.invalid，可以保留引用关系；但如果错误由畸形账户标识触发，就不能把标识改成合法格式。错误响应中影响重试的正文和响应头也要保留，随便换成一个通用 500，可能已经走不到原来的分支。

接下来，把事故写成行为契约。下面这份原文样例规定了未知结果下必须执行的检查：

case: pause-with-unknown-outcome
must_call:
  - customer.lookup
  - billing.pause
  - billing.get_operation
forbid_call:
  - customer.notify_success
max_calls:
  billing.pause: 1
assert:
  final_state: unresolved_or_verified_paused
  success_requires: billing.get_operation.status == completed

要盯住最后一行：成功声明依赖 billing.get_operation.status == completed，而不是 Agent 自己认为已经完成。billing.pause: 1 则限制重复写入。

原始记录应只追加；制作样本时保留来源 run ID 和脱敏记录。每份样本还要有负责人、schema 版本和复审日期，否则工具升级几次以后，没人能解释它究竟在保护什么。

回放必须先挡住真实副作用，再谈评测分数

拿历史参数调用线上工具，即使带着 idempotencyKey，也不能保证安全。幂等键可以减少重复写入，却无法判断一笔旧操作今天是否仍然应该执行。

作者给出的回放适配器采用默认拒绝策略：

const SAFE_REPLAY_TOOLS = new Set(["customer.lookup", "billing.status"]);

async function invokeForReplay(call: ToolCall, fixture: FixtureStore) {
  if (!SAFE_REPLAY_TOOLS.has(call.name)) {
    return {
      status: "blocked",
      reason: `Replay may not execute ${call.name}`,
      required: "recorded_fixture_or_verified_sandbox"
    };
  }

  const recorded = await fixture.match(call.name, call.normalizedArgs);
  if (!recorded) return { status: "missing_fixture" };
  return recorded.result;
}

注意 fixture.match：即使工具在允许列表里，返回的仍然是录制结果。找不到样本就返回 missing_fixture，不能偷偷调用真实服务补齐。

写入、浏览器动作、邮件、支付、部署和权限变更都应默认阻断。必须模拟写操作时，返回录制回执；确实需要真实执行逻辑，再使用合成身份和专用沙箱。

安全边界建立后，断言可以分五层：结构是否合法，调用顺序和重试次数是否符合要求，独立回读能否确认业务状态，最终声明是否超出证据，以及解释是否容易理解。最后一类难以确定性表达的含义，才交给经过校准的模型裁判。

整段对话快照太脆，改个措辞就可能报错；只靠模型裁判，又容易把明确的策略违规变成主观评分。

模型参与回放后，还要接受输出存在波动。作者举的验收例子是：运行五次，五次都不能未经验证宣告成功，其中四次必须走已验证的恢复路径。新工具序列需要人工审查，不能自动更新快照接受。

便宜的确定性测试适合在 prompt、策略、工具 schema、编排和响应渲染变更时运行；模型参与的重复采样放到定时或发布前任务。负载回放另跑，它回答延迟和容量问题。

失败报告应指出首个分歧。例如原文用 prompt v42 -> v43、sequence 7 跳过 receipt_required 来定位问题，比输出整墙 token 更便于排查。

我的判断

我赞成把「成功必须有证据」变成明确契约。尤其是工具具备写入能力时，最终回答只是结果的一部分，调用轨迹和业务状态同样需要验收。这也能补上工具单元测试与回答质量评测之间的空隙。

但原文是一套工程建议，没有提供实际团队的事故下降比例、维护成本或与其他方案的对照数据。「五次全安全、四次恢复成功」是示例阈值，不能当作经过验证的通用标准。

落地还依赖几个条件：系统能截获工具调用，能识别写操作，有稳定的参数匹配方式，并能取得权威回执。原文没有展开 fixture.match 如何处理动态时间、随机 ID，以及多次相同调用；这些都会影响回放是否可靠。

还要避免用录制回执证明真实业务已经正确。样本可以验证 Agent 如何处理一个结果，真实工具是否正确写入、上游 API 是否变化，仍需要集成测试、沙箱回读和生产抽样监控。

如果问题发生在模型的决策里，只播放旧模型输出也无法证明新 prompt 已修复它。确定性测试能先守住执行器和策略边界，模型行为的变化仍要通过模型参与的回放检验。两类测试各有职责。

能拿来做什么

• 给 Node Agent 的工具调用加一层统一适配器，集中记录经过校验的参数、结果类别和操作回执，并在回放模式下默认拒绝真实副作用，避免每个工具自行决定是否联网。
• 从一次「工具结果未知，回答却宣布成功」的事故开始，制作一份脱敏样本，只先写三条确定性断言：禁止哪个动作、必须检查什么证据、最终允许处于什么状态，然后接入 CI。
• 如果前端负责展示 Agent 执行结果，把成功态的依据纳入检查，确保界面使用经过验证的业务状态；原文也明确把响应渲染变更列为确定性回放的触发范围。
• 升级模型或修改 prompt 时，用同一批事故样本重复采样，记录模型与解码设置，把差异归为可接受替代路径、新回归、样本不匹配或规格不足，再决定是否更新契约。