一名客户的 745 美元厨房电器卡在纳什维尔的配送中心，已超预计送达日十五天。客服智能体接手后做了九次工具调用：调订单、查物流、查客户档案、两次读退款政策、确认没有工单后新开一张、记录时间线，还正确判断这位客户确实不符合延迟赔付的条件。然后它把工单标成已解决，回了一句“您的问题已处理，还有什么可以帮您”。
两处不对。承运商的异常状态仍开着，这张工单的应然终态是挂起；客户问的那件事，它一个字没回答。真正值得琢磨的是这个错误有多难被抓到：九次工具调用全部合法，最终答复也通顺，一个检查工具调用的评分员会放过它，一个检查措辞的评分员也会。不同意的是数据库——该写 hold 的字段写成了 solved。这个案例在基准仓库里可以自己跑，可执行检查只判一条：那个字段的值不对。
判定一挪到数据库，失败就现形了
ThinkingBox 由微软 Copilot Studio 团队与 Hugging Face 联合推出，10 月 3 日通过 Hugging Face 与 OpenEnv 放出可运行版本，论文 8 月首投、10 月 1 日修订。它和常见评测的分野在于打分对象：多数智能体评测看最终答复，或者看工具调用序列合不合理，这两样都是代理指标。它把 507 条有状态业务流程铺进零售、车险、旅行、数字银行与咨询支持五类场景，每条从一个干净、隔离的后端开始，由模拟用户保管一部分只有被问到才会给出的信息，智能体拿到一份政策和一组工具，等它停下来，再由可执行检查逐字段比对真实记录与要求的终态，看它有没有多建、多改、多发不该动的东西，然后把整件事做十九遍。评测框架是 MIT 许可，基准数据用 CDLA-Permissive-2.0。
重复二十次不是装饰。真实系统里同一条流程要跑几千次，一次演示成功说明不了任何事。
在覆盖 12 个模型的 121,680 次有效试验里，79,853 次没通过可执行检查；其中 67.24% 仍然干净收尾、调用了改状态的工具、也没有报出任何工具错误，看起来就像做完了。这些失败的检查结果里，77.61% 写错了字段值，43.30% 多做了不该做的事，25.36% 漏做了该做的事——三类互相重叠，不能相加。
失败长得不像失败
按诊断归类，失败里 79.9% 是工具使用失误，10.3% 是状态更新写错，7.0% 是没有真正解决用户的问题，2.9% 完全没有动手。多数不是推理不够聪明，而是不会从失败里退回来：预条件不满足、查询返回空、工具报了一个不致命的错，智能体往往继续往下走，把剩下的步骤走完，最后交出一份读起来很顺的总结。
一个断掉的接口调用是吵闹的，一次写错的数据库更新加一段漂亮的总结是安静的。后者才是接进业务之后真正花钱的那种错——它进入了下游流程，被当成既成事实继续往下走，要等到对账、审计或客户投诉时才被发现，那时回滚的成本已经和当初省下的人力不在一个量级。
能解决不等于每次都对
ThinkingBox 报三个数：pass@1 是单次尝试的成功率，pass@20 是二十次里至少成功一次，20/20 是二十次全部通过。前两个回答“它通常做得怎么样”“它到底会不会”，第三个回答“它是不是每次都做得对”——只有第三个数和“能不能交给业务”直接相关。
三个数摆在一起，一个常见的采购直觉就失效了。单次分上，Claude Opus 5.5 是 67.16%，Claude Opus 5 是 66.50%，GPT-5.4 是 65.36%，GPT-6 Astra 是 58.31%，开源模型里 Kimi-K3 最高，57.37%。换成二十次全过，顺序变了：Kimi-K3 能在 507 条里解出 476 条（93.89%），二十次全过的只有 68 条（13.41%）；Claude Opus 5 单次覆盖面小一些（79.09%），全过的却有 241 条（47.53%）。更新的 Claude Opus 5.5 平均分比 Opus 5 高，全过的仍然停在 241 条——多出来的准确率没有换成可靠性。换个口径看同一件事：把单次得分在二十次重复里保住多少，GPT-6 Astra 是 78%，两个 Claude 是 71%，Kimi-K3、GLM-5.1 与 DeepSeek-V4-Pro 都只剩约 8%。
对做选型的团队，这是两条不同的曲线。一条叫覆盖面，决定它能替你处理多少种事；一条叫一致性，决定这些事里有多少可以不再逐条检查。买错的那一种，会在演示环节表现得很体面。
把“完成条件”当成一份资产写下来
基准真正的贡献不是排名，是把“完成”写成了可执行的判定：哪些字段必须等于什么值、哪些副作用不许出现、哪些预条件不满足时应该停下。写下来之后，验收才有对象。
放到施工企业的工程变更付款流程上，这件事的样子很具体。一条变更从提出到付款，中间要过的节点大多已经在系统里有名字：变更申请、业主确认的工程量签证、监理审核意见、合同号与工程量清单的对应关系、计量支付台账里的应付记录、审批链上谁签到了哪一步。现在多数单位让智能体帮忙做的是填表、归类附件、起草说明、把资料从一处搬到另一处，验收方式是“看着差不多”。
改法是把每条流程的完成条件显式写出来，再交给系统判：
这段写下来还有个副作用：它逼着业务方先把话说明白。很多流程今天之所以只能靠老师傅盯着，不是因为规则复杂，而是从没有人把“做完了”的定义写成一句话。基准里那些失败的智能体，很多时候是在替人补这条缺失的定义——它自己猜了一个终态，然后照着猜的那条走完。
Bytemethod.ai 给自家 IT 服务团队做 ServiceNow 数字员工时（10 月 4 日 VentureBeat 署名复盘），得到的经验正好落在这里：先只做一个流程，挑重复、规则清楚、量大、好测量、好撤销的那种；写操作一律人工审批后才执行；身份沿用使用者自己的账号与角色权限；变更走团队熟悉的 update set，部署与回滚都是老流程。他们的目录项生成从几小时到几天压到约 20 秒，自报成本降约 80%，但那两件难事更值得记住——让数字员工稳定读懂组织的需求文档格式，以及真实痛点比路线图设想的更窄、更重复。
完成条件本身也该进评审
完成条件写下来之后，放在哪里就成了新问题。10 月 3 日，开发者 Kevin Liao 在自己的博客上提出一个更激进的替代方案：给编码智能体装记忆插件这条路，从前提上就错了。他批评的共同架构是遍历会话、切成上千条片段、嵌入、每次提问时把最相似的几条塞回提示词，再配一个搜索工具。这条流水线的后果包括：检索靠相似度排序，而相似不等于正确或仍然现行；片段丢掉上下文和动机，两百个 token 装不下当初为什么这么定；历史被当成事实，而代码库每天都在变；整个库不可审计，一万条嵌入向量里哪些过期、哪些从没被取出来过，没人说得清。
他的做法是在项目里建一个 internal/ 目录，让智能体把东西写进去，分四类：指令是这个项目里评审怎么走，规格是和用户谈定了什么，研究是对某个陌生库的可复用结论，索引是东西都在哪。开工前先读索引和相关文档，收工后趁整个任务还在上下文里，把过期的改掉、缺的补上。循环因此从“提问—做—忘”变成“提问—查阅—做—更新”，而且改动会出现在同一个合并请求里，和它所描述的工作一起被审。他把这套东西开源成了 Operator Memory（BSD 3-Clause，支持 Claude Code、Codex、OpenCode V2 等）。
这条线和 ThinkingBox 接得上：完成条件本身就是一份该被写下来、该被提交、该被评审的文档。区别在于，它不该由干活的智能体自己维护——它是验收标准，属于甲方、监理、审计和下一任接手的人，谁写、谁改、什么时候改，本身要有个说法。
反对意见里有一条绕不开：文档记忆依赖智能体每次收工都老实更新，漏几次就和向量库一样过期，而且因为它读起来更像权威，误导性更强。另一条是适用边界——“偏好简短回答”这类关于人的事实来自对话，抽取加去重才是更现实的去处。更稳的分工可能是：项目怎么运转写进文档，关于人的事留在记忆库，两者都不要在每次提示里无差别注入。
条件与边界
ThinkingBox 是一个基准，不是部署方案。507 条合成流程、12 个模型的共同子集、场景集中在零售、车险、旅行、数字银行与咨询支持，都不等同于任何一家单位自己的流程；把它的失败构成照搬来做风险预算，只能算起点。基准数据用 CDLA-Permissive-2.0，框架 MIT，可以自己跑，跑出来的数字是你的环境，不是别人的。
把完成条件写成判定也有成本：写清一条流程的终态、副作用与预条件，通常要业务方、开发和审计一起花掉半天到几天，流程一改还得跟着改。换回来的是可撤销、可对账、可交班。选择在哪几条流程上付这份钱，本身就是管理判断——越靠近钱、越靠近安全、越靠近对外承诺的流程，越值得先做。
再补一个数：如果一条流程每月有两万次智能体操作，1% 的出错率就是两百次需要人回滚。这个数字决定了该配什么模型、在哪一步设人工审批、留多少人工兜底。先算它，再谈选型，比反过来省事。
来源与说明
[1]: The Agent Said It Was Done. The Database Disagreed. —— Hugging Face 博文（微软与 Hugging Face 联合）/ 2026-10-03 (https://huggingface.co/blog/microsoft/thinkingbox) [2]: The agent said done. The database kept a different story —— The Plain Signal / 2026-10-04 (https://theplainsignal.com/article/thinkingbox-agent-database-state-reliability-benchmark) [3]: New Benchmark Catches AI Agents Lying About Finished Work —— DEV Community（首发于 inite.ai）/ 2026-10-04 (https://dev.to/mikefluff/new-benchmark-catches-ai-agents-lying-about-finished-work-43ig) [4]: The AI Reliability Gap: Microsoft’s ThinkingBox Study —— The AI Chronicle / 2026-10-04 (https://theaicronicle.com/en/news/research/thinkingbox-microsoft-ai-agent-reliability) [5]: The Agent Said It Was Done. The Database Knew Better. —— ai2day / 2026-10-04 (https://ai2day.live/story/the-agent-said-it-was-done-the-database-knew-better) [6]: We built an AI agent for ServiceNow. The real pain points were narrower than our roadmap assumed —— VentureBeat / 2026-10-04 (https://venturebeat.com/orchestration/we-built-an-ai-agent-for-servicenow-the-real-pain-points-were-narrower-than-our-roadmap-assumed) [7]: Agents Don’t Need Memory. They Need Documentation. —— liao.gg / 2026-10-03 (https://liao.gg/blog/agents-dont-need-memory) [8]: Agent Memory vs Documentation: RAG or Markdown? —— andrew.ooo / 2026-10-04 (https://andrew.ooo/answers/agent-memory-vs-documentation-markdown-workspace-vs-vector-memory-2026) [9]: aerovato/operator-memory —— GitHub / 2026 年项目页 (https://github.com/aerovato/operator-memory) [10]: Agents Don’t Need Memory, They Need Documentation —— Get AI Book / 2026-10-04 (https://getaibook.com/news/agents-dont-need-memory-they-need-documentation)
说明：745 美元电器案例、九次工具调用、工单终态应为挂起而写成已解决、可执行检查只判该字段，均出自微软与 Hugging Face 的联合博文，案例编号 test_case_ST003_006 与其在基准仓库中的可运行状态以原文为准；507 条流程、121,680 次有效试验、67.24% 与 77.61%／43.30%／25.36% 的失败构成、各模型 pass@1 与 20/20 数据、79.9%／10.3%／7.0%／2.9% 的失败诊断，以及每个可靠成功任务 6.80 与 7.80 美元的成本，同出自该博文，并与两份独立整理相互核对。Bytemethod 的 20 秒、成本降幅与容量释放为项目方自报口径，非独立核验。Operator Memory 的许可与支持范围出自作者原文与随后的整理报道，第三方整理对许可的记法不一，本文按 BSD 3-Clause。关于文档记忆依赖自觉更新、以及关于人的事实仍需检索这两条反驳，出自第三方对照整理，非本文推断。