微软与 Hugging Face 推出的 ThinkingBox 通过对 507 个有状态企业工作流的可执行检查，将评测重点从工具调用和对话轨迹转向最终数据库和业务状态，揭示了“一次成功”与可复现可靠性之间的鸿沟，强调企业部署需以后端状态为准的评估方式。
微软与 Hugging Face 发布的 ThinkingBox，把企业智能体的评测重点从“说了什么、调用了哪些工具”，转向一个更难回避的问题：它是否真的把业务系统带到了正确的最终状态。
这套沙箱与基准测试覆盖 507 个有状态的企业工作流。研究人员让多个模型在相同任务上重复运行 20 次，再检查数据库记录、工单状态和其他副作用，而不是只根据最终回答或工具调用轨迹打分。结果显示，智能体偶尔完成任务的能力，与企业能够持续依赖它的能力之间，仍存在明显差距。
微软官方对 ThinkingBox 的介绍见《How we built ThinkingBox to measure whether agents finish the job》。研究论文《One Success Isn’t Reliability: Thinkingbox, a Sandbox and Benchmark for Agents in Stateful Business Workflows》已发表于 arXiv，配套的 ThinkingBox-Bench 数据集也已在 Hugging Face 开放浏览。
一次正确的工具调用，为什么仍然可能是一次失败
ThinkingBox 文章给出的例子来自客户服务场景。一名客户购买了一台 745 美元的厨房电器，但包裹在纳什维尔配送中心陷入“异常”状态，预计送达日期已经过去 15 天。智能体先后查询订单、物流、客户资料和退款政策，确认没有现存工单，又新建工单并记录处理过程。
从对话记录看，它完成了九次看似合理的工具调用，也正确判断客户不符合延迟配送补偿政策。但随后，智能体把工单关闭为“已解决”，并回复客户：“既然您的查询已经解决，还有什么我可以协助的吗？”
问题在于，物流异常仍未解决，按照任务要求，工单应当保持暂停或等待状态，而不是被标记为已解决；更重要的是，客户真正询问的是包裹为何延迟以及接下来怎么办，而不是是否符合补偿政策。只检查工具调用的评测器，可能会把这次运行判为成功；检查最终数据库状态的评测器，则会发现它留下了错误结果。
这正是 ThinkingBox 试图捕捉的差异：工具调用是过程信号，最终状态才是业务结果。智能体可以调用正确的接口，却填写错误参数；可以完成大部分步骤，却遗漏一个决定性更新；也可以输出听起来完整的答复，却没有真正改变后端记录。
507 个任务，20 次重复运行
ThinkingBox-Bench v1.0 包含 507 个任务，覆盖零售与电商、旅游与酒店、汽车保险、数字银行内部 IT 支持，以及咨询公司的 IT 和人力资源支持等五类场景。每项任务都有初始数据库状态、用户请求、可用工具、业务政策，以及对最终状态的可执行检查。
任务并不要求智能体必须沿着某一条固定路径操作。只要最终记录符合要求，合理的不同工具顺序都可以被接受。评测器会比较智能体运行后留下的数据库状态与黄金状态，同时检查是否出现多余、缺失或错误的副作用。部分任务还会对最终回复进行窄范围的语义判断，例如是否说明某项服务受库存或政策限制。
每次尝试都在独立环境中运行。ThinkingBox 的 MCP Session Proxy 会为任务启动隔离的工具服务器，加载相同的初始数据，运行智能体与模拟用户的多轮对话，再收集后端效果并销毁会话。这样可以避免前一次运行留下的记录影响下一次结果，也让研究者能够在并行重复测试时保持可比性。
研究论文的整体实验使用 20 次重复尝试，比较“至少有一次成功”与“20 次全部成功”等不同指标。论文显示，Claude Opus 5 的单次通过率为 66.50%，但 20 次全部通过的比例降至 47.53%；Kimi K3 的对应数字则从 57.37%降至 17.60%。这意味着模型可能具备找到正确路径的能力，却无法稳定地重复这条路径。
论文将这种差异称为“发现—可靠性鸿沟”：多次尝试可以发现一条成功轨迹，但不能因此证明智能体能够在生产环境中持续复现成功。
失败时，智能体往往仍然表现得像“完成了”
ThinkingBox 的另一个重要发现，是很多失败运行并不会以明显的错误结束。它们可能完成了若干有效的状态修改，随后正常结束对话，甚至给出一个语气肯定的最终答复。
在原始新闻所对应的共同任务集消融分析中，研究团队统计了 12 个模型的 121,680 次有效试验，其中 79,853 次没有通过可执行检查。失败试验中，有 67.24%仍然以看似干净的方式结束。论文更广泛的实验则报告称，失败试验中约 80.88%属于干净终止。两组数字来自不同的样本范围，不能直接混为一个总体比例，但它们共同指向同一个问题：正常结束不等于完成任务。
这对现有的智能体监控方式提出挑战。许多系统会把“没有报错”“完成了工具调用”或“模型输出了最终答复”当作流程完成的信号。但在涉及退款、工单、预订、保险理赔和内部权限的业务中，错误可能已经写入数据库，只有后续人工核对或客户投诉时才会暴露。
微软官方文章因此建议，智能体循环需要理解每一次工具返回的信息，在动作失败后重新规划，并在报告成功前主动核验状态。验证不能只发生在流程末尾的文本层，也应当直接读取任务所关心的记录。
从工具轨迹转向终态评测
ThinkingBox 的设计并不是完全放弃工具调用和对话轨迹。工具调用仍然有助于解释智能体为何失败，也能用于检查某些必须发生或不能发生的动作。但它们不再被当作成功本身。
例如，一个酒店预订任务可能要求智能体为客户加入“远离电梯和制冰机的安静房间”偏好，同时解决一张支持工单。评测器不要求智能体必须先查预订、再查客户资料、最后更新工单；它只检查预订记录中是否确实出现了偏好，工单是否被正确关闭，并确认回复中是否说明该偏好仍需视酒店供应情况而定。
这种方法让基准测试更接近企业工作流的实际要求。业务系统并不关心模型是否走过一条漂亮的思考路径，而关心退款有没有发生、工单是否处于正确状态、权限是否被准确修改，以及有没有额外改变不应改变的记录。
这也使 ThinkingBox 与近期关于智能体一致性的研究形成互补。AIFlux此前报道的 IBM 研究指出，智能体不能只看一次成功，关注的是同一任务重复运行时的结果翻转；ThinkingBox 则进一步把“完成”定义为可检查的数据库状态和副作用。前者回答智能体能否稳定复现决策，后者回答它最终是否真的完成了业务动作。
开放数据集与 OpenEnv 运行路径
微软将 ThinkingBox 的运行框架与基准数据分开发布。 microsoft/thinkingbox 仓库包含命令行工具、智能体与模拟用户循环、MCP 会话代理和评测框架；microsoft/thinkingbox-data 则提供工具服务器、合成业务记录和测试任务。
Hugging Face 上的 ThinkingBox-Bench 数据集主要用于浏览和分析，并不直接等同于完整的可执行运行环境。数据卡说明，黄金数据库状态需要由场景的 MCP 服务器根据初始状态和预期工具交互重新生成，因此复现实验应当按照 thinkingbox-bench-v1.0 的发布说明安装运行时，而不能只下载表格文件。
项目还提供通过 OpenEnv 运行环境执行评测的路径。对开发者来说，这意味着同一套可隔离、可重置的业务环境不仅可以用于模型比较，也可能被用于强化学习或后训练。不过，研究团队同时强调，基准任务内容和黄金状态是为了评测而发布，不应直接用于提示词优化、微调或奖励模型训练，除非遵守项目规定的使用范围。
与此相近，AIFlux此前报道的 ServiceNow AutoSynthData试图从企业智能体的失败轨迹中生成下一轮训练数据。两者体现了同一趋势：企业智能体的评估与训练正在从静态问答，转向带有真实状态、工具约束和可执行验证器的工作环境。
企业部署真正需要的指标
ThinkingBox 并没有证明某个模型已经适合直接操作企业生产系统。它更像是在提醒开发者，单次演示成功、工具调用正确和最终回复流畅，都是不充分的指标。
对于企业部署，至少还需要回答几个问题：同一请求重复执行时，通过率是否稳定；失败时是否会留下额外或不可逆的状态变化；智能体能否识别工具返回的矛盾信息；它是否会在没有完成后端动作时声称任务已经完成；以及系统能否在不接触真实敏感数据的情况下持续重放和验证这些场景。
这些问题会增加评测成本，因为每次运行都需要隔离环境、可重置数据和可执行检查。但对涉及客户账户、付款、理赔、企业权限和合规记录的工作流来说，这种成本可能正是判断系统能否进入生产环境的必要成本。
ThinkingBox 所提出的核心标准很简单：智能体说了什么，可以帮助人理解过程；它调用了什么，可以解释行为；但只有它最终留下的记录，才能证明工作是否真正完成。
来源： 微软 Command Line：How we built ThinkingBox to measure whether agents finish the job；arXiv 论文；Hugging Face ThinkingBox-Bench 数据集；ThinkingBox 运行框架；ThinkingBox 数据与工具服务器。