一个顾客的厨房电器比预计日期晚了十五天，物流状态仍显示异常。智能体查了订单、物流和赔付政策，开出工单，最后把工单关成了“已解决”，还回复顾客询问是否需要其他帮助。它一共调用了九次工具，步骤看起来很齐全。

这件事发生在微软与 Hugging Face 发布的 ThinkingBox 模拟任务中。按任务要求，物流异常没有消除，工单应保持等待处理。智能体确实写入了系统，写进去的状态却错了。只读它的结束说明，顾客的事似乎已经办妥；打开记录，问题还在那里。

10 月 3 日公开的 ThinkingBox 把这种差别放进了可运行的业务流程。几天前，MIT、Google Research 等机构的研究者又发表了一项模型报告行为研究。两项研究测的事情不同，一项看模型怎样汇报已有工作，另一项看智能体实际上把系统改成了什么样。把它们接起来，才看得清“完成了”这三个字需要多少证据。

汇报里最容易消失的是坏消息

报告行为研究准备了八类任务记录，每份约一百到四百行。记录里有已经执行的步骤、看似顺利的结果，也藏着足以改变结论的问题。模型拿到记录后负责写总结，研究者检查它有没有把那个问题讲清楚。这些记录是为实验构造的，不能直接当作真实产品的事故统计。

其中一组记录描述机器学习实验。新方法看起来胜过旧方法，换上一条更强的基线，优势却消失了。研究者让 GPT-5.5 根据记录写摘要。在二百份报告中，它只有两次主动指出这条负面结果。研究者随后加入一句要求诚实作答的提示，指出问题的报告增加到一百九十份。论文给出了任务设计和逐项结果。

这说明模型能读到那条结果。给出明确要求以后，报告行为也大幅改变。不过，同一篇论文里还有“工具调用仍在等待”等情境。对 GPT-5.5 而言，诚实提示在那项任务里的披露率仍是零。让模型“说实话”有用，不能替代人去查任务是不是停在半路。

研究者也让模型检查代码错误、虚构数据和意外副作用。有些问题在直接询问时能够被识别，到了替整项工作写汇报时却被淡化或遗漏。用户常常先看到一段简短、连贯的总结，真正会推翻总结的那一行，可能留在长记录里。

工具调用成功以后，还要看留下了什么

ThinkingBox 检查的是另一处。它为零售、旅行、保险、银行内部支持和企业服务准备了五百零七项有状态业务任务。模拟用户会补充信息，智能体通过工具修改后台记录。评测在结束时检查字段、必需的操作和不该发生的额外修改；其中三十项任务还检查最终回复是否符合要求。论文说明了任务与评分方法。

那张被错误关闭的工单很能说明问题。工具接口没有报错，数据库也确实发生了变化。如果验收只看“有没有调用关闭工单的工具”，这次会像一次成功操作。检查顾客所需的终态，才发现“已解决”和“等待处理”差了一个关键字段。

研究团队在一组跨十二款模型的有效运行中发现，许多未通过检查的尝试仍正常结束，使用过修改状态的工具，也没有留下最终工具错误。发布文章给出了失败类型的拆解。工具成功只能证明指令被执行过。它没有证明对象选对了、字段改对了，更没有证明没有顺手改坏别的记录。

一次做对也还不够。ThinkingBox 让每项任务从相同初始状态独立运行二十次。Kimi-K3 至少一次完成了五百零七项中的四百七十六项，但二十次全部成功的任务只有六十八项。换句话说，一个模型可能会做某件事，轮到下一位顾客时仍未必稳。这里的数字属于这套模拟任务，不能直接换算成真实公司的服务成功率。

把“完成”写成能检查的结果

这两项研究并没有给出一条万能提示词。它们给出的办法更朴素。任务交给智能体之前，先写清结束时什么记录应该存在、字段应是什么值、哪些记录不能碰。智能体结束后，拿这些条件查实际状态，再看它的说明有没有漏掉失败、等待中的步骤和意外修改。重复任务还得分开看偶尔成功与稳定成功。

拿那张物流工单来说，验收条件可以很短。异常仍在时，工单保持等待处理；顾客收到与当前处理状态相符的回复；没有无依据的赔付或额外改动。智能体做了九步还是十九步，对这些条件没有加分作用。条件满足，工作才算完成。

人当然不可能逐条翻阅每次运行的全部记录。可检查的终态能先挡住一部分错误，再把异常留给人处理。模型的结束说明仍有用，它负责告诉人发生了什么；系统里的实际记录，负责回答事情到底办成没有。

/ 作者，ZestJT