把 AI Agent 接入测试变成可复现用例：用 CATT 检查服务端实际结果
AI Agent 的回答看起来正确，不代表它真的按预期使用了你的服务。它可能重复提交预订、绕过审批、把不该暴露的字段带进回复，或者只是在文字里声称任务完成。只检查最终答案，很难区分“说对了”和“做对了”。
Consumer Agent Testing Tool（CATT）尝试把测试重点放到服务端可观察的结果：让脚本或模型驱动的 Agent 与 MCP 服务、MCP App、网站或 HTTP API 交互，再检查服务端状态、证据和 Agent 的回答。它是一个测试宿主/替身，不是对任何商业助手私有实现的复刻，也不提供兼容性认证。这个边界很重要：测试结论应描述你的服务在 CATT 所模拟条件下的行为，而非宣称某个托管 Agent 一定会如此运行。
先从无模型的脚本测试开始
CATT 项目 README 展示了本地 connector fixture：用 uv run consumer-agent-testing-tool connector-run 执行场景，并可指定 scripted driver 与 JSON 调用脚本。脚本模式不需要模型账户，适合先验证工具调用顺序、审批规则和后端结果，避免把模型随机性混进基础回归测试。
uv run consumer-agent-testing-tool connector-run examples/connector/fixture-booking.yaml \ --driver scripted --script examples/connector/fixture-booking.calls.json
这个示例会搜索房间、获取报价、创建预订并生成最终回答。场景中的私有值由宿主填入，README 特别指出模型不会看到其中的访客邮箱；审批卡片则按场景定义的权限规则响应。运行结束后，工具会检查 fixture 的私有 oracle，例如是否恰好有一笔已确认预订、是否没有重复预订。换句话说，断言不止是“模型答得像真的”，还要看系统状态是否真的正确。
开始接入自己的服务时，可以把流程拆成三层：第一层定义可重复的场景输入和允许的权限；第二层运行 Agent 或脚本并收集调用记录；第三层从服务端 oracle 核验实际状态。把“调用了哪个工具”和“调用产生了什么后果”分开断言，能更快定位问题是在 Agent 决策、工具协议还是业务逻辑。
覆盖不止 MCP
项目列出的测试面包括 MCP connector、MCP App、网站和 HTTP API。connector 场景可检查工具使用、账户与审批规则、私有值保护及最终回答；MCP App 的 surface-run 面向 UI 表单、工具调用和资源响应；网站场景可按浏览器策略操作；HTTP API 则需要映射，并要求服务提供 loopback 部署和私有 control adapter。不同测试 lane 的前置条件并不相同，不能把“支持 API 测试”理解成任意线上 API URL 都能直接拿来跑。
另一个实用入口是 readiness check：它读取工具目录、allowlist、schema 或选定投影来检查契约，不一定真的调用服务工具。README 将这类检查定位为文档约束检查，而非平台准入或生产兼容性认证。对 CI 来说，可以先把静态 readiness 和 scripted run 放进每次提交，再把耗时更高、依赖模型的试验安排在独立任务中。
什么时候才需要模型驱动
脚本驱动适合验证确定性规则；但它无法覆盖模型面对自然语言任务时的选择。CATT 也支持由模型驱动的 Agent run，README 示例要求准备模型配置和 API key，并提醒凭据应通过环境变量提供，不应写进场景文件或共享证据。模型 preflight 会发出简短请求，可能产生费用；doctor 默认不发送模型请求，显式使用 --model-preflight 才执行预检。因此，建议先用 doctor 检查本地环境，再在确认成本和密钥范围后运行模型测试。
测试结果也要注意解释边界。CATT 对 Muse、Instinct 等目标提供 surrogate emulation，但 README 明确说明它近似的是宿主行为，不是对方私有实现；部分行为会标注为 documented、unofficial、assumed 或 unknown。对团队而言，保留这些来源标签比把每个通过结果都当成“真实产品一致”更有价值。它让测试报告能够表达证据强弱，而不是只有一个容易被误读的绿色勾号。
一套务实的落地顺序
- 先用本地 fixture 编写 scripted 场景，覆盖成功路径、重复提交和审批拒绝。
- 为关键副作用设置服务端断言，例如唯一记录数、状态字段或审计事件；不要只匹配自然语言回答。
- 对 MCP schema、权限清单和 readiness 规则做静态检查，将问题尽早挡在运行前。
- 再接入模型驱动试验，明确模型配置、密钥来源与可能产生的请求费用。
- 归档可分享的脱敏导出，而不是直接分享含私有值的整个运行目录；项目文档提醒 runs 中的
private/目录包含宿主私有数据。 - 将每次运行的证据与构建版本关联，比较回归时检查服务端结果是否变化。
CATT 最值得借鉴的不是“再加一个 Agent 测试框架”，而是测试对象的转变：从评价 Agent 说得是否像样，转为验证服务实际发生了什么。对带有支付、预订、账户变更或敏感数据访问的 Agent 集成，这个视角尤其关键。先让确定性脚本证明基本契约，再把模型的不确定性作为额外变量引入，能让失败更容易复现，也让通过的含义更诚实。