Agent 评测换判据：用终态数据库状态判定任务是否完成

Agent 评测换判据用终态数据库状态判定任务是否完成原文Hugging Face BlogMicrosoft 联合发布- 《The Agent Said It Was Done. The Database Disagreed.》https://huggingface.co/blog/microsoft/thinkingbox一个客服 Agent 处理一笔 745 美元的家电配送工单它连做了九次看着都合理的工具调用正确读到了退款政策然后把工单标成已解决。但有两处仍然是错的——承运商的异常件还挂着按规则工单应该停在挂起状态客户真正问的那个问题也始终没被回答。只看工具调用序列或最后那句总结这次运行会被判成功。数据库不同意。2026 年 10 月 3 日Microsoft 与 Hugging Face 联合发布了评测框架 ThinkingBox 和基准集 ThinkingBox-Bench把 Agent 的判据从说了什么换成了在后端留下了什么。这篇按落地的顺序拆开讲判据怎么定、为什么必须重复跑、失败究竟卡在哪一层。一、看起来没问题的轨迹才是最难的先看一组数字。论文在 12 个模型、121,680 次有效试验上做了一次消融其中 79,853 次没有通过可执行检查。而在这 79,853 次失败里67.24% 是在一次改变状态的工具调用之后干净结束的——最后一次工具调用没有报错。这句话的信息量很大。它意味着两件平时常被当成通过信号的东西都不可靠工具有没有报错不报错不代表改对了地方结尾那句已完成模型是在生成了状态变更之后才说这句话的措辞流畅和状态正确之间没有任何强制关系。真正被改错的地方只有回到数据里才看得见。二、判据换成终态与副作用ThinkingBox 的每个任务由五个部分定义缺一不可起始后端状态用户目标可用的 MCP 工具集合该领域的策略规则针对终态的可执行断言。任务里还有一个模拟用户手里握着私有上下文——比如预订编号、个人偏好、出生日期——只有在 Agent 主动询问时才释放。这一点还原了真实场景里信息不是默认给全的这个约束。跑完之后一个副作用提取器先推导出这次尝试实际改动了什么再由确定性判分器拿它和要求终态比对。判分器的取向值得记下来它接受任何能产生正确结果的轨迹同时拒绝错误的、缺失的、以及多余的副作用。也就是说过程随便走终点必须对而且不能顺手多改东西。每次尝试都拿到一个独立的 MCP 会话状态全新初始化同一个任务的两次尝试不会共享任何数据库行或缓存的工具状态。这是后面重复 20 次能成立的前提——否则第二次跑的是第一次留下的现场。三、语义类要求用窄二元问题兜住并不是所有要求都能落成一个干净的数据库值。像Agent 有没有说明这不保证这种就没有字段可查。ThinkingBox 的做法是分两类处理507 道题里有 477 道只按状态判分剩下 30 道额外加一份响应评分表用一道很窄的二元问题处理语义。这个比例本身就说明了设计取向——能交给状态判的绝不交给语言模型判。还有一条容易被忽略的边界原文写得很清楚模型能看到任务、对话和工具 schema而标准答案状态、断言、判分内部实现和凭据全部留在评测方一侧。评测环境的信任边界是从一开始就划好的不是事后补的。四、做对一次和次次做对是两件事这一节是整篇最值得带走的部分。ThinkingBox-Bench 把 507 道题每道跑 20 次于是同一批模型上出现了两套完全不同的排序。单次成功率第一是 Claude Opus 5.567.16%比 Claude Opus 5 的 66.50% 略高。但换成20 次全过的题目数两个模型都是 241 题也就是 47.53%——平均分提高了可靠任务一个没多。开源权重侧的对比更刺眼。Kimi-K3 至少成功过一次的题目占 93.89%可 20 次全对的只有 68 题13.41%。这两个数字放在一起看就够了如果只报单次成功率可用性会被系统性高估。前端一次演示成功、生产和长任务里反复出岔子根子就在这个差距上。五、失败八成发生在工具层失败特征分布比总分更有指导性。在前面那 79,853 次失败里77.61% 出现字段值错误43.30% 产生多余的副作用25.36% 缺少必需的副作用。三类之间有重叠一次失败可能同时中好几项。按可观测标签归因79.9% 的失败落在工具使用上之后依次是状态更新错误 10.3%、用户问题未解决 7.0%、完全没有做状态变更 2.9%。原文特意注明这些是可观测标签而不是因果解释但从工程角度看结论已经够用多数失败是重试与恢复的问题不是推理不够聪明。域之间的差异同样值得注意。零售场景平均单次成功率约 59.52%而车险只有 33.83%——同一个模型换个业务域表现可以拦腰砍。成本口径也换了一个看的角度。这里不是算每次调用多少钱而是算每个可靠任务多少钱最早完成全部 20 次的有 GPT-5.4 的 128 题、GPT-6 Astra 的 231 题、Claude Opus 5.5 的 241 题对应约 6.80、7.45、7.80 美元。原文说明价格取自 2026 年 9 月 20 日的一份报价快照、用未打折的标价计算是个横向比较用的指数不等于真实云账单。六、把它跑起来框架和数据集都已经公开harness 是 MIT 许可benchmark 数据是 CDLA-Permissive-2.0。运行环境要求 Linux 或 WSLPython 3.11 以上外加 uv 和 Docker。OpenEnv 镜像只起 OpenEnv API其余服务自己跑。安装分三步# 1. OpenEnv ThinkingBox 环境gitclone https://github.com/huggingface/OpenEnvcdOpenEnv uvsync--projectenvs/thinkingbox_env--frozen# 2. 可执行基准切到钉住的发布版本gitclone https://github.com/microsoft/thinkingbox-datagit-Cthinkingbox-data checkout thinkingbox-bench-v1.0# 3. ThinkingBox CLI提供 tb 命令uv toolinstallthinkingbox githttps://github.com/microsoft/thinkingbox接下来是四个进程Typesense 30.1 起检索后端、会话代理与 MCP 服务器、OpenEnv server 按 YAML 配置连上三个模型Agent、模拟用户、judge 可以共用一个端点最后用就绪接口做一次门控。就绪检查在可观测数据、配置和会话代理三项通过前会一直返回失败但它看不到 Typesense也不会去探活每个模型端点这两项要自己确认。跑一道题的评分长这样# 指定单道题跑 1 次输出结果与错误旁路echo- sandbox_external_retail_group1.py:test_case_ST002_001one_task.yaml uv run--projectenvs/thinkingbox_env thinkingbox-eval\one_task.yaml\--config$PWD/thinkingbox.yaml\--outputresults.jsonl\--errors-output errors.jsonl\--repeat1--message-timeout1800这里有个很实用的设计操作性失败环境、超时之类会写进单独的 errors 旁路文件可以重跑而不会和模型本身的对错混在同一个结果里。一份规范的结果必须把所有尝试都判掉或者显式说明不能把没跑成的算成模型失败。研究里用的重复次数是 20自己项目里跑不起 20 次的话先从 5 次起步看稳定性也行。七、四条可以搬回自己项目的做法原文最后给了几条建议都是从上面的数据里推出来的提交变更前先检查终态别把工具没报错当成改对了给工具错误分类只有可恢复的错误才值得重试否则只是在消耗预算收缩可用工具面工具越多选错和参数错的表面积越大不能廉价回滚的变更要求人工审批。作者也坦承这几条改动能带来多少提升他们没有在基准上量过。这算是个诚实的边界——方法是数据读出来的效果还得自己在自己的场景里验证。小结ThinkingBox 的核心贡献不是又出了一份排行榜而是换了一个判据不看 Agent 说了什么看它往数据里写了什么。加上每道题 20 次独立重复单次成功率和次次做对之间的巨大落差被直接暴露了出来——67.16% 的单次准确率对应的是 47.53% 的可靠任务。对做 Agent 的人来说最省事的一步是先在自己的评测里加上两个东西一个终态断言一个重复次数。前者让看起来完成不再蒙混过关后者让稳定性成为可以被报告的数字。