好答案不等于好流程：给 Agent 搭一套可靠性测试台

Agent 的最终回复读起来通顺，不代表它真的做对了事。这本书用一个小型客服与事故分诊 Agent 做例子，教你从权威状态而不是从 Agent 的自述里验证执行路径和业务结果，并用这些证据来决定能不能发布。

演示会骗人：可靠性缺口在哪

• 很多 Agent 系统一开始靠 demo 和 happy path 测试来评估，回复流畅自信，就以为可以上线了。
• 真实失败往往藏在回复背后：跳过必要检查、越权操作、同一效果提交两次、依赖失败却报告成功。
• 只看最终回复会漏掉这些，因为人审的文本和实际执行的路径是两个不同的对象。
• 书里给了一个可运行的教学案例：事故确认调用超时，一个脚本如实说无法确认，另一个照样建工单并声称已确认，测试台判前者通过、后者失败。

为什么 Agent 比普通程序难测

• 传统测试给输入、独立校验输出或状态；Agent 工作流多了两个风险：Agent 可能拿到泄露答案的信息，评估者可能把 Agent 的自述当成成功证据。
• 同一输入多次运行可能走不同路径，越权动作、重复提交、假成功都藏在看似合理的回复后面。
• 所以测试台要同时验证路径和结果，把权限校验放在 Agent 之外，主动注入故障，再检查恢复行为或是否如实失败。
• 多次真实运行才能给出带不确定度的可靠性估计。

测试台要覆盖的几类判定

• 回复质量：最终消息是否切题、格式正确，但这只是最表层的一层。
• 轨迹：工具选择、参数、步骤顺序、是否原地打转或重复执行。
• 工具与业务结果：从权威状态核对副作用，比如工单是否真的建了、账户状态是否被改。
• 行为维度：循环、护栏、状态与记忆、韧性、授权，以及可观测性、性能测量和统计。
• 最后把发布门禁、CI 和生产反馈接起来，让检查变成持续维护的工程控制，而不是一次性验收。

参考实现怎么跑

• 书里跟的是一个小的支持与事故分诊 Agent，核心测试跑在 CI 里。
• Python 参考实现默认离线运行，用确定性的脚本化适配器，结构测试不需要模型 API 或网络。
• 真实模型的回复质量、延迟、成本和采样需要 live adapter，项目提供接口但不附带实现，离线和在线测量要分开看。
• 作者建议从第 5 章和第 9 章入手：跑起参考 Agent，再从状态验证一个业务结果。

边界：它能证明什么，不能证明什么

• 测试台能在声明的可靠性范围内抓住指定的失败类别，为发布提供可复现的证据。
• 它不能证明系统完全安全，也替代不了安全评审、监控、分阶段发布和人的问责。
• 它消除不了幻觉，覆盖不了所有涌现行为；第 19 章专门区分了已实现能力和生产扩展。
• 适合正在把 Agent、copilot 或工具调用工作流推向生产的工程师，需要熟悉 Python、JSON、HTTP API、分布式系统和 LLM 工具调用。