AI 代理“做完了”并不等于真的完成：ThinkingBox 如何检查数据库

导语

AI 代理能够正确调用工具、生成流畅回复，并不意味着它真的完成了业务任务。微软与 Hugging Face 发布的 ThinkingBox，试图把评估重点从“代理说了什么”转向“系统最终留下了什么”。它在隔离的 MCP 工具会话中运行代理，随后直接检查数据库的终态和实际副作用。

一个看似成功的案例

素材给出的零售场景中，客户的高价厨房电器在配送中心出现异常，且已经延迟 15 天。代理完成了订单查询、物流核验、客户资料读取、退款政策检索和工单创建等九次工具调用，判断客户不符合延迟赔偿条件。问题在于，承运商异常仍未解决，工单本应保持“暂挂”，代理却将其关闭为“已解决”；同时，最终回复也没有真正回答客户的问题。

如果只检查工具调用轨迹，这次执行很容易被判定为合格。可执行检查则会发现，数据库中的工单状态不符合要求。这正是 ThinkingBox 要捕捉的差距：工具调用是过程证据，后端状态才是结果证据。

核心要点

• 检查真实状态。 评测关注字段是否写对、应有的副作用是否发生，以及是否产生额外变更，而不只看最终文本或工具是否返回错误。
• 一次通过不代表可靠。 ThinkingBox 覆盖 507 个有状态业务任务，每项任务从干净后端开始独立运行 20 次，并区分 pass@1、pass@20 与实际 20/20 全部通过的任务数。
• 失败经常“看起来正常”。 在包含 121,680 次有效试验的共同集合消融中，79,853 次未通过可执行检查；其中 67.24% 仍正常结束、调用了状态变更工具且没有报告最终工具错误。
• 能力广度与稳定性分离。 Kimi-K3 至少成功完成过 507 项任务中的 476 项，但只有 68 项做到 20 次全通过；Claude Opus 5 至少成功完成的任务较少，却有 241 项实现了全程稳定通过。

意义与影响

这项工作提醒企业重新理解代理评测。高 pass@1 说明模型有能力完成任务，却无法说明它在下一次是否仍会写入正确字段。尤其在客服、保险、银行和旅行等会修改真实记录的场景，错误关闭工单、遗漏必要更新或制造额外副作用，都可能比一句不够准确的回答造成更大损失。

因此，代理评测应把可执行的后端断言纳入标准流程，并报告不同维度的结果：模型能覆盖多少任务、通常能否成功，以及能否连续稳定完成。ThinkingBox 的价值不在于给出一个新的排行榜，而在于推动评测从“轨迹像不像正确答案”转向“系统状态是否真的正确”。

来源：Hugging Face Blog