ThinkingBox：用数据库终态检查 Agent 到底做成了什么

事实与来源

微软与 Hugging Face 在 10 月 3 日介绍 ThinkingBox：让 Agent 在隔离的业务环境中操作，再检查它留下的数据库状态与副作用。公开基准包含 507 个合成工作流，每个任务重复运行 20 次。它关心的完成标准，包括记录是否改对，以及有没有产生多余变更。

作者报告，在覆盖 12 个模型的 121,680 次有效试验中，79,853 次未通过可执行检查；这些失败里，67.24% 仍正常结束、调用过修改状态的工具，且最终工具响应没有明确报错。这是该研究的结果，不是所有生产 Agent 的通用失败率，本文也没有复跑基准。

技术机制

每个任务固定初始数据、用户目标、业务政策、可用 MCP 工具和验收条件。一次尝试使用独立会话，从干净状态开始；结束后，评测器提取实际变化，再和预期结果比较。Agent 可以采用不同的查询顺序或从错误中恢复，评分不要求复制一条指定操作轨迹。

预期状态和检查逻辑留在评测侧，不能让 Agent 直接看到答案。正确结果之外，检查还要覆盖缺失和额外副作用。对于无法对应数据库字段的沟通要求，部分任务另加回答检查。公开仓库还支持对保存的测试上下文重新运行断言，不需要再次调用模型，方便区分执行结果与检查逻辑。

例子与用途

假设内部维修流程要求：设备暂时无法修好时，把已有工单交给维修组、保持待处理，并保留原设备关联。Agent 可能成功调用更新接口，随后宣称事情已经办好，但误把状态设成已解决。只检查接口返回成功或最后一句话，会漏掉这项错误。

这个假设可以拆成几个验收点：目标工单的负责组正确，状态仍待处理，设备关联未变，没有重复创建第二张工单，也没有修改其他记录。为每项保留前后状态差异，失败时就能定位问题。例子是本文的工程推演，不是 ThinkingBox 已发表任务的逐项复现；真实验收条件仍要由业务政策决定。

限制与不确定性

重复指标也要读准。单次成功率描述全部尝试中的成功比例；二十次至少成功一次衡量能否偶尔解决；观测到的二十次全对，则强调这批记录中的一致性。它们不能混为一个分数，二十次全对也不保证今后永远正确。本文没有采用价格估算或排行榜来替读者选模型。

论文说明，477 个任务只检查后端状态，只有另外 30 个附加回答要求。因此，记录改对却向用户说错结果，仍可能被计为成功。此外，任务是合成重建，每题只有一个预定终态；模拟用户保持合作。多个合理结局、用户改主意和含糊需求，不能由这些结果充分代表。

开发者启示

对会写入业务系统的 Agent，可以先选一个边界清楚的流程，把“必须改变”和“必须保持不变”的字段分别写成断言。再保存初始快照、完整工具结果、结束状态和失败原因，避免只留下聊天记录。需要复测时重置环境，让上一次运行的记录和缓存不影响下一次。

还要单独检查对用户的说明：哪些已完成、哪些仍等待，以及是否正确披露限制。先用离线沙箱找到常见错误，再小范围验证只读回查与人工复核流程；不能把研究里的事后评分直接当成生产事务保护。这个思路的价值，是让“已完成”有可检查的证据，同时保留对沟通质量和真实业务差异的警惕。