AI Agent 成功过一次，不等于通过上线测试

你的客服 Agent 看起来已经能上线了。现场演示中，它找到订单、核对政策、向用户确认，准确退回了其中一件商品的款项，还给出了一段得体的说明。团队顺手录下了屏幕。第二天，真实用户提出同类请求，Agent 在一次查询失败后退错了商品；第三次，它很流畅地告诉用户“已经处理完成”，数据库里却没有任何变化。

那次成功演示证明了一条可行路径存在，却没有证明用户可以反复依赖这条路径。

本周，微软研究团队发布了 Thinkingbox 与 Thinkingbox-Bench，用 507 个有业务政策约束的有状态工作流，把这种差异量化了出来。论文报告称，受测系统中的最优结果在 pass@1 上达到 65.36%，但论文所报告的 pass^20 只有 25.25%。也就是说，在这个实验环境里，“有时能成功”和“每次都能稳定完成”是两种差别很大的能力。研究还发现，不少失败轨迹会正常结束，也确实调用了能修改状态的工具；因此，一段整洁的回复或最后一次工具调用没有报错，都不能代替对业务结果的验证。

本文面向正在决定 Agent 能否反复执行退款、改签、账户支持、员工入职或权限申请等工作的非技术创始人、AI app builder 和小型产品团队。核心判断是：先根据产品真实的任务频率和失败后果选择重复次数，再要求准备上线的同一候选版本，在整个序列中都留下正确的最终状态、不产生禁止的额外影响，并向用户准确说明结果。

你将得到一套不容易混淆的 pass@k / pass^k 术语、任务频率评估表、完整客服场景、结果验证方法、可复用的可靠性契约、失败测试，以及上线/限量/暂缓决策矩阵。本文不主张 Thinkingbox 能预测你的产品表现，而是帮助团队把一次漂亮演示换成与产品承诺相匹配的证据。

先弄清 Thinkingbox 到底测了什么

Thinkingbox 既是一个开放框架，也是建立在该框架上的 benchmark。框架会启动隔离、兼容 MCP 的工具会话，让模拟用户与 Agent 围绕一个多轮任务交互，记录完整轨迹，提取状态变化，再运行可执行检查。Thinkingbox 开源仓库给出了这套会话生命周期：创建隔离环境、暴露工具 schema、执行调用、提取副作用供评估，最后销毁本次会话。

Thinkingbox-Bench 1.0 包含 507 个工作流，覆盖零售与电商、旅游与酒店、车险、新型银行内部 IT，以及咨询公司的 IT/HR 支持。独立的数据与工具服务仓库发布了可执行任务、有状态工具环境和运行说明。所有任务都会检查最终后台状态与副作用，其中 30 个任务还会对最终回复施加二元要求。

它并不只是检查工具名称和参数是否合法。一个任务可能要求 Agent 找到正确记录、补齐用户没有提供的信息、遵守业务政策、执行允许的修改、避免碰到无关对象，并把结果正确告诉用户。只要最终结果相同，符合要求的不同操作路径也可以通过；流程看起来流畅、结果却错误的轨迹会失败。

作者让每个系统在 507 个任务上各随机运行 20 次，也就是每个系统 10,140 次 trial。论文报告了四个值得区分的信号：

这些数字来自刚发布的研究团队实验，尚不是独立复现结果。对创始人真正有价值的，不是模型排行，而是把找到成功路径与重复稳定执行分开，并要求验证器在 Agent 行动后检查真实世界状态。

分清 pass@1、pass@k 与 pass^k

这三个写法很像，对应的产品决策却可能完全相反。

假设某一个具体工作流的真实单次成功率稳定为 95%，而且各次尝试彼此独立，那么连续 20 次都成功的概率是 0.95^20，约为 35.8%。这只能帮助建立直觉，不能直接拿来预测产品。真实失败往往会被同一次服务中断、模糊政策、过期 schema、共享 prompt 或同一类困难用户关联起来。不同 benchmark 任务的难度也不同，因此绝不能把 Thinkingbox 的整体 pass@1 65.36% 直接做二十次方。论文是逐任务计算可靠性后再取平均，并明确讨论了估计方法的局限。

把符号换成产品语言，你真正要回答的是：

• 在锁定条件下，这个工作流到底能不能完成？
• 是否有安全的验证器，能在后果逸出前拒绝失败候选？
• 一个发布窗口内，用户会让产品执行多少次？
• 这组尝试中，哪些事实必须每次都成立？
• 哪些失败可以接受，哪些需要恢复，哪些绝不能交给模型自行裁决？

k 应由产品暴露量决定，不要跟随 benchmark

不存在统一的 k=20 上线规则。20 是 Thinkingbox 的重复实验设计，你的重复次数应对应接下来准备承担的真实暴露量。

先写出一个明确工作流，不要测试笼统的“这个 Agent”。接着估算：从开放功能到团队能发现问题、暂停功能并发布修复之间，这个工作流会发生多少次。可以把它叫作暴露窗口。如果两天试点期间大约会有 8 次改签，只测 5 次就低估了承诺；如果写作功能会生成数百条必须由用户确认的私密建议，要求每一条都完全相同，反而会把无害差异误当成严重失败。

用下面这张表做第一次讨论：

实际发布策略应跟着后果走，而不是跟着模型名气走：

不要把 pass^k 变成安全口号。一个小样本全通过，不能证明风险为零；它能揭示某个工作流是否已经不稳定到无法支撑承诺，也能让发布决定留下可审计依据。

验证最终状态，也验证没有产生额外副作用

Agent trace 告诉你系统尝试过什么，产品结果才告诉你真正发生了什么。

Thinkingbox 通过最终后台状态、副作用以及必要时的对话属性来落实这一区别。它的高质量测试编写指南给出了一条实用原则：好的检查应判断 Agent 是否完成任务，而不是要求它严格复刻设计者预想的调用顺序。硬性规定必须调用两次工具很脆弱；核验最终结果则能接受不同但同样正确的路径。

其他一手材料也采用了类似做法。AWS-Bench会创建一次性 AWS 账户，对修改类任务直接检查真实云资源状态，再重置测试环境；这明显强于接受终端里“资源已创建”的文字。Anthropic 的 Agent 评测指南也把任务、重复 trial、grader 与完整 trace 分开，并建议针对 Agent 行为的多个维度使用不同 grader。

每个工作流至少定义四层对象：

1. 初始状态 fixture： 尝试开始前的准确记录、权限、政策版本、时间、feature flag、工具版本和已知用户事实。
2. 必须状态： 成功后必须存在的后台记录与用户可观察结果。
3. 禁止状态： 绝不能出现的重复写入、错对象修改、越额操作、未授权访问、缺失审计记录或误导性表述。
4. 恢复状态： 尝试被拒绝或结果不确定时，必须执行的回滚、升级处理和用户通知。

为一个工作流建立重复可靠性契约

重复可靠性契约是一份有版本的产品、运营与工程协议。它明确测什么、什么才叫成功、准备上线的版本需要连续承受多少次真实暴露，以及哪些证据能把测试结果绑定到最终候选版本。

下面的模板可以直接复用：

repeatability_contract:
  workflow_id: refund_single_item_v3
  product_surface: support_assistant
  release_candidate:
    model: pinned-provider-model-version
    prompt_hash: sha256:...
    tool_schema_hash: sha256:...
    policy_version: refund-policy-2026-08-20
    feature_flags: [agent_refund_pilot]
  exposure_window:
    period: 7_days
    expected_consequential_attempts: 20
    pilot_accounts: 5
  task_suite:
    representative_cases: 12
    repeats_per_case: 20
    reset_between_trials: true
    production_shadow_cases: 0
  required_checks:
    - correct_customer_and_order
    - item_is_eligible
    - explicit_confirmation_recorded
    - exact_amount_refunded_once
    - ledger_and_user_receipt_agree
  forbidden_effects:
    - unrelated_record_changed
    - duplicate_refund
    - limit_bypassed
    - success_claim_without_verified_write
  reliability_views: [pass_at_1, pass_at_k, pass_to_k, slice_failures]
  runtime_controls:
    approval: support_lead
    per_attempt_limit_usd: 100
    idempotency_key_required: true
    post_write_verification: true
    automatic_pause_on_uncertain_state: true
  evidence:
    run_ids: []
    state_diff_uris: []
    rejected_trials: []
    reviewer: null
  decision: hold

这些 hash 很重要，因为可靠性并不只属于某个模型名称。system prompt、工具描述、超时、重试策略、用户模拟器、上下文压缩规则或后台 schema 任意一项变化，都可能改变行为。OpenAI 当前的 Agents SDK 测试文档给出了一条有用边界：应用自己控制的编排逻辑可以通过确定性的内存测试覆盖，外部模型、网络、协议和 sandbox 的真实行为则需要真正的 adapter 或集成环境。你的契约应同时标明这两类证据。

这份契约还可以避免一个常见误区：生产环境里重新执行一次“状态不确定”的修改，不等于 benchmark 里的下一次独立 trial。评测时必须完全重置环境；生产重试前则要先依靠幂等键与状态对账，因为第一次调用可能已经成功，只是回复在途中丢失。

用一个完整场景走一遍决策

假设有一家名为 ParcelPilot 的小型 SaaS，为独立网店提供客服工具。它准备增加一个 AI 客服 Agent：当包裹延误、商品符合政策、客户确认金额时，Agent 可以为单件商品办理不超过 100 美元的退款。第一周所有退款都要由客服负责人批准。

团队演示已经成功，但没有立即全面开放，而是根据已经整理好的客服模式建立 12 个有状态案例：

• 多商品订单中只有一件符合条件；
• 同一客户有两笔相似订单；
• 促销品不符合退款资格；
• 已经存在一笔处理中退款；
• 物流状态已经过期；
• 支付方已接受退款，工具随后超时；
• 金额接近上限；
• 用户中途改口要退另一件商品；
• 历史记录使用旧货币代码；
• 用户没有完成确认；
• webhook 被重复投递；
• 下单后退款政策发生过版本变化。

假设总体 pass@1 看起来很强，但拒绝记录显示：旧货币案例 20 次中失败 4 次，超时案例有 2 次进入不确定状态。即使平均分超过团队设定的目标，也应该暂缓。平均值掩盖了共同后果：钱可能已经移动，产品状态和对用户的说法却不一致。

团队不应只在 prompt 里写一句“请更加小心”。更有效的修复是：在 Agent 之前完成货币代码标准化；支付写操作必须携带幂等键；超时后读取支付方真实状态；把 uncertain 设计成一等结果，自动暂停后续动作。完成后，要用新的版本 hash 重新跑完整套件。即使全部通过，第一周试点仍只开放给 5 个账户，保留客服负责人批准、确定性的 100 美元上限、写后立即核验，以及每日回执审查。

这个场景不是客户案例，也没有声称真实收益。它只用来说明：提高 prompt 的通过次数，与重新设计产品边界、阻止随机错误跨过所有控制，是两件不同的事。

运行常规成功路径测不到的失败测试

重复测试还需要覆盖变化。把同一个简单 fixture 跑 20 遍，只能观察该 fixture 上的采样差异，不能代表真实任务分布。因此，要把重复次数与有针对性的扰动、按后果设计的案例结合起来。

1. 相似对象碰撞

在 fixture 中放入相似姓名、相邻订单号或多个未结工单。Agent 只要触碰了用户没有明确识别和授权的对象，就应失败。

2. 缺失信息压力

故意省略政策要求的信息。只有 Agent 正确追问、拒绝或升级处理才通过；不能奖励恰好猜中隐藏 fixture 的“幸运答案”。

3. 已有部分进展后的工具错误

在一次可能已经生效的写操作后，返回查询失败、授权过期、限流、畸形响应或超时。恢复逻辑必须读取真实状态，不能只相信错误文本。Thinkingbox 作者报告称，在该研究的诊断分类中，工具使用和收到工具反馈后未能恢复的问题最常见，平均占受测模型失败 trial 的 77.5%。

4. 调用成功，业务结果错误

让更新接口返回 HTTP success，但实际写入错误记录、超过额度或缺失配套写入。这能抓住“最后一次工具调用成功就代表任务完成”的错误认知。

5. 正常结束，状态仍不完整

让 Agent 在只读查询后，或只完成多个必须修改中的一项后，输出一段漂亮的完成说明。只要最终状态不完整，就必须失败。

6. 状态正确，说明却误导用户

让后台修改正确，但对金额、时间、可逆性、批准状态或下一步的解释出错。能确定性判断的尽量写成代码检查；确实需要判断语义时，再使用独立人工或经过校准的 rubric。

7. 重复请求与重复投递

连续提交同一个意图，或重放 webhook。只有幂等规则阻止重复副作用、并向用户给出准确状态时才通过。

8. 版本与用户分段变化

每次只改变一个会影响结果的维度，例如政策版本、locale、币种、账户等级、工具 schema、移动端输入结构或权限集合。每个 slice 单独报告，不能让漂亮的平均分掩盖真正承担成本的用户群。

先解释失败簇，再决定是否换模型

Thinkingbox 把观察到的失败分成四类：工具使用、没有执行状态修改、没有完整解决用户问题，以及错误更新状态。论文很谨慎地把它们称作可观察的“表现”，而不是唯一根因。分析自己的 trace 时也应保持同样纪律。

更强的模型可能改善结果，但不会替代这些控制。NIST 对有效且可靠 AI的定义强调：系统应在预期条件和给定时间内按要求工作，并使用符合真实用途的测试集和持续监测。这比“最新模型排名第一”更接近产品责任。

所有被拒绝的 trial 都要保留。如果只保存成功轨迹，pass@k 可能看起来在上升，反复出现的失败却从评审中消失。记录每次失败原因、验证器是否判断正确、有什么后果逃逸，以及修复究竟属于模型、prompt、工具、政策、UI 还是确定性控制层。

决定上线、限量还是暂缓

最终决策要同时看重复性、后果和验证器质量：

即使样本内全部通过，也不能只凭这一点批准上线。还要确认任务覆盖预期用法、验证器真的能捕获关心的失败、上线候选与 receipt 完全一致，并且运行时控制可以约束测试无法证明的部分。生产 tripwire 也要提前定义：一旦出现禁止副作用、不确定写入、关键 slice 失败、验证器分歧，或工具/政策 hash 漂移，就应自动暂停能力或转交复核。

一个 48 小时的起步计划可以这样安排：

1. 选择一个会产生后果的工作流，写清必须和禁止的最终状态。
2. 估算首轮试点的暴露窗口，据此选择 k。
3. 建立 5 至 12 个代表性与对抗性 fixture，每次完整重置。
4. 锁定模型、prompt、工具、政策、feature flag、超时和重试行为。
5. 重复运行，同时报告 pass@1、pass@k、pass^k、关键 slice 和全部拒绝轨迹。
6. 优先修复产品边界，而不只是改 prompt；随后重跑完整序列。
7. 只有具备次数限制、状态核验、receipt、恢复、监测和明确停机负责人时，才开放试点。

明确这套方法不适用或不足的边界

Thinkingbox 为一种评测习惯提供了有力证据，但不是通用生产模拟器。作者明确说明，任务是从非公开来源集合中合成重建的，并非企业工作总体的随机或统计代表样本。每个保留任务只有一个黄金终态，因此天然排除了存在多个合理解法的工作流。结果还受到固定模拟用户、结束标记、轮数限制、token 限制和其他 harness 选择影响。论文采用代入估计量（plug-in estimator）报告 pass^k，也解释了它与稀疏成功情况下无偏估计的差别。

你自己设计的重复测试也有类似限制：

• 它只能估计被测候选版本在当前 fixture、环境和采样设置下的行为。
• 模型、prompt、政策、schema、供应商或用户分布变化后，结果不会自动继承。
• 完全隔离重置可能漏掉相关性失败，例如服务中断、共享脏状态、拥塞和级联重试。
• 团队没有定义或观察不到的结果，验证器就无法证明。
• 不应为了方便评分，强迫模糊的人类决策只有一个黄金答案。
• 它不能代替安全审查、隐私控制、法律建议、无障碍测试、领域专家、事故响应，也不能取代高影响工作中的人类权限。

当产品对用户作出可重复承诺、结果也确实可验证时，重复可靠性很有用。价值高度主观或合理结果需要协商时，应使用探索性研究、定性评审、用户研究或人工主导流程。如果一次错误修改都无法容忍，正确答案也不是把 k 无限放大，而是不要让模型独自拥有批准该修改的权力。

把一次成功变成诚实的产品决策

Agent 成功一次当然有价值，它说明这个工作流可能做得到。一组没有通过的重复测试同样有价值：它能在更多用户承担成本之前，提醒团队产品承诺已经跑到了证据前面。

Thinkingbox 对小团队最重要的启发，不是哪个模型排第一，而是一张更严格的“完成凭证”：持久状态正确、没有额外副作用、沟通真实，并且能在产品预计的条件下反复成立。让 k 对应暴露量，把发现能力与可靠性分开，再把结果绑定到真正上线的候选版本。

最后只作出与证据相称的声明。不要笼统地说“我们的 Agent 很可靠”，而要说明：哪个工作流、哪个发布版本、跑过哪组序列、检查了哪些状态、保留什么限制、失败后如何恢复，因此获得了一次有边界的试点资格。这句话没有完美演示那么抓眼球，却更接近一款真正值得用户信任的产品。

参考资料

1. One Success Isn’t Reliability: Thinkingbox, a Sandbox and Benchmark for Agents in Stateful Business Workflows
2. Microsoft Thinkingbox framework
3. Microsoft Thinkingbox data and tool servers
4. Thinkingbox: Writing Effective Test Cases
5. τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains
6. AWS-Bench: evaluation in live AWS state
7. Anthropic: Demystifying evals for AI agents
8. OpenAI Agents SDK: Testing
9. NIST AI RMF: Valid and Reliable
10. NIST AI 600-1: Generative AI Profile