One Success Isn't Reliability: Thinkingbox, a Sandbox and Benchmark for Agents in Stateful Business Workflows

TL;DR Thinkingbox 提供有状态业务工作流的沙箱与基准，507 个策略约束任务上，最强模型 pass@1 仅 65.36%，pass^20 降至 25.25%，揭示单次成功远非可靠，工具调用与响应信号不能代理端到端状态正确性。

问题

问题背景：当前 agent 评估正从静态问答转向可执行环境，如 代码修复、网页导航、App API 调用、函数调用 等，以检验工具使用与多步交互能力。

现有方法局限：这些基准大多聚焦于单轮或简单多轮的 工具调用正确性 与 响应质量，忽略了真实业务工作流中至关重要的 持久状态转换 和 无副作用 约束。例如，一个 agent 可能产生看似合理的回复和有效的工具调用序列，且以干净终止结束，但后端数据库的最终状态却未达到预期，或产生了额外变更。现有评估信号（如 BLEU、工具调用格式、轨迹长度）无法捕捉这种错误。

为什么这个问题难/重要：有状态业务任务（如零售订单修改、保险理赔身份验证、内部 IT 工单处置）通常具有 部分可观测性、策略条件、多工具依赖 和 长期状态跟踪 要求。一次偶然的成功轨迹并不能代表可靠性：实证显示，最强模型 pass@1 仅为 65.36%，而 pass^20 降至 25.25%，说明多次运行的一致性极差。业界对能处理真实业务后果的 agent 需求强烈，但当前模型在可靠性上远未达到部署门槛，错误的持久状态变更可能导致财务损失或合规风险。

行业类比：类似于 自动驾驶 中的“无事故里程”或 金融对账 中的“最终账本一致性”——单次成功演示远不足以证明系统在生产环境中可被信任。

核心洞察

• Thinkingbox 的核心创新在于将评估重心从“响应正确”或“工具调用有效”转移到“终端后端状态的精确变更”，即验证最终持久状态是否符合业务规则且无副作用。同类 agent 基准（如 web navigation、function calling）大多在轨迹层面判定成功，无法捕捉状态更新错误、缺失或多余副作用。Thinkingbox 提供可执行的状态检查和任务特定的验证器，接受多种有效轨迹但严格拒绝错误状态，揭示了表面干净终止与真实任务失败之间的系统性差距。
• 论文用 pass@1 与 pass^20 的对比量化了“偶尔成功”与“可靠完成”之间的鸿沟，最强模型仅 65.36% pass@1 但 25.25% pass^20，表明单次采样成功不能代表 agent 的可靠性。传统 leaderboard 通常报告 pass@1，但业务部署中 agent 往往需要多次尝试或长期自主运行，一致性至关重要。Thinkingbox-bench 通过多次采样和状态检查暴露了高方差和偶发正确，推动社区重视 agent 在多次执行中的稳定性和确定性，而不仅是峰值能力。

方法

方法概述

Thinkingbox 构建了一个 状态化业务工作流沙箱 与配套 benchmark，从输入到输出形成闭环。

• 输入 / 任务形式：每个任务实例包含 初始后端状态（数据库记录）、领域政策、工具环境 与 交互脚本（含模拟用户）。Agent 需在多轮对话中调用 MCP 兼容工具、与用户澄清需求，并执行状态变更。
• 关键模块：
  1. 沙箱编排：为每次尝试提供隔离的 MCP 工具会话，记录完整执行轨迹，并能在终端只读后端状态。
  2. 以副作用为中心的判定：不同于基于回复文本或单次工具调用正确性的评估，Thinkingbox 通过 任务专属可执行检查器 对比终端状态。这些检查器接受合法的轨迹，同时拒绝错误、缺失或多余的状态副作用；部分任务还校验最终回复的必备属性。
• 任务构建与质量保障：采用三阶段流程——工作流设计 → 可执行任务实例化 → 可执行验证与过滤。经过验证的任务覆盖零售、酒店、车险、银行 IT、咨询 IT/HR 等场景，共 507 条。
• 评估协议：报告 pass@1 与 pass@20，强调单次成功不等于可靠完成；许多失败轨迹有干净的终止和合法工具调用，说明 过程信号不能代替端到端状态结果。

与同类可执行 agent benchmark 的差异点：Thinkingbox 将评估焦点从“生成合理回复 / 工具调用”转移到 持久化后端状态的正确性与完整性，并要求策略条件满足，从而度量状态化业务任务中的可靠性。

实验

实验设计

在 Thinkingbox-bench 的 507 个状态化业务工作流上评估了多款专有与开源模型。每个任务要求 agent 在隔离 MCP 兼容工具会话中完成多轮信息收集、政策遵循与状态变更，评估以终端后端状态的可执行检查为准，可接受有效轨迹并拒绝错误、缺失或额外副作用。

关键发现

• 最强模型 pass@1 为 65.36%，但 pass^20 仅 25.25%，显示单次成功与可靠完成之间存在巨大差距。
• 失败分析表明，工具使用错误占主导，还存在无状态更改操作、未完成用户解决、错误状态更新等模式；许多失败轨迹呈现干净终止和有效工具调用，说明响应或工具调用级别信号不能作为端到端完成度的代理。

与基线对比解读

传统 agent 基准多关注最终答案或单步工具调用正确率，而 Thinkingbox-bench 引入状态持久性与副作用检查，更接近真实业务系统。与仅报告 pass@1 的基准相比，本工作通过 pass^20 揭示可靠性瓶颈：即使最强模型也难以在不同尝试中稳定复现成功，凸显从“偶然成功”迈向“工程级可靠”所需的系统化改进空间。

行业影响

落地场景

Thinkingbox 针对的是有状态业务工作流中 agent 的可靠性问题，直接适用于需要多轮信息收集、策略遵循与持久状态更新的生产场景。典型用例：

• 电商订单服务：agent 处理退货、换货、地址修改等请求，必须验证用户身份、检查库存/优惠策略、调用订单 API，并确保只更新目标字段，不产生副作用。
• 保险理赔协助：agent 引导用户提交事故信息，协调定损工具与保单系统，完成理赔状态流转，且不得违反赔付上限或错改其他保单数据。

商业价值

基准结果显示最强模型 pass@1 仅 65.36%，而 pass^20 仅 25.25%，说明“偶尔成功”不等于“可靠可用”。这带来两个直接价值：

• 降低人工 fallback 成本：通过预筛可靠性低的 agent 版本，减少工单升级和人工复核；可靠完成端到端任务可显著缩短处理时长。
• 合规与风控：通过 side-effect 检测拒绝错误或多余状态更改，避免订单错改、错误赔付等造成的直接经济损失与信任损耗。

与现有产品/工作流的接口

Thinkingbox 沙箱以 MCP 兼容工具会话 封装业务系统，可作为 agent 开发与上线流程中的标准验证环：

• 接入 CI/CD：作为回归测试集，每次模型升级或 prompt 变更自动跑分，检查可靠性是否下降。
• 与 LangGraph、AutoGen、Semantic Kernel 等框架对接：真实工具调用通过沙箱代理，执行轨迹可复现、可审计。
• 用作 RL 训练环境：利用 executable checks 提供细粒度奖励，针对失败模式定向优化。

整体而言，Thinkingbox 填补了“可执行环境评测”到“有状态业务可靠性”的空白，为 agent 从 demo 走向生产提供工程化验证手段。

局限

• **沙盒与评判器依赖**：论文明确承认评价结果依赖于可执行检查与状态模拟器的准确性，若模拟器的状态模型或检查逻辑存在偏差，可能误判有效轨迹。此外，基准任务通过合成数据构建，尽管做了隐私保护，但其分布与真实企业工作流仍有差距，模型在真实环境中的迁移表现尚未验证。
• **领域覆盖与任务规模有限**：当前 507 个任务分布在零售、酒店、汽车保险、新银行内部 IT、咨询 IT/HR 五个领域，且每个任务仅设计了一个用户角色与策略条件，缺乏跨领域泛化测试。与 WebArena 等更广泛的交互式基准相比，任务数量较少，可能不足以支撑对通用代理能力的稳定评估。
• **评估成本与指标可解释性**：`pass^20` 指标需要多次独立运行（20 次）才能估算可靠性，计算开销显著高于单次 `pass@1`，可能限制大规模模型比较。同时，该指标关注“任意成功一次”的概率，未区分成功的分布模式（如连续失败后偶然成功），对实际部署中需要的持续可靠性评价仍有距离。