Agent说做完了，数据库却不认：ThinkingBox揭开自动化系统的“完成幻觉”

AI Agent 最危险的时刻，往往不是它报错，而是它很有把握地告诉你“任务已经完成”。微软团队最近发布的 ThinkingBox 实验显示，Agent 的任务完成声明与数据库中的真实结果之间，可能存在一条足以让生产系统出问题的鸿沟。

ThinkingBox 是一个用于研究 Agent 任务执行、状态变化与完成判断之间关系的实验环境。它把 Agent 放进一个需要调用工具、修改数据并验证结果的闭环任务中，再对比 Agent 的自我报告和外部系统的实际状态。

这个问题并不只是“模型偶尔会犯错”。它更接近软件工程里的一个基本原则：系统不能把执行者自己的口头报告，当成外部世界已经发生变化的证据。

真正的问题：完成声明不是完成事实

Agent 的“完成”是模型基于上下文做出的判断，而数据库的“完成”是一个可以被查询、比对和审计的外部状态。

在普通聊天场景里，模型说“我已经整理好了”通常只是文本输出，用户最多重新检查一遍。但在数据库、工单、CRM、代码仓库或财务系统中，“完成”意味着某些具体状态必须已经发生，例如：记录被创建、字段被更新、关联关系被建立、重复数据被处理，或者事务已经提交。

ThinkingBox 关注的正是这两个概念之间的错位：Agent 可能已经调用了工具，也可能收到了工具返回结果，但这并不自动说明目标状态已经成立。

一次写数据库的操作至少包含四个不同阶段：

1. Agent 生成写入意图。
2. 工具或应用层执行写入请求。
3. 数据库接受、拒绝或部分执行该请求。
4. 系统重新读取数据，并确认它符合任务要求。

很多 Agent 工作流只覆盖了前两步，最多根据工具返回的 success 字段直接结束。ThinkingBox 的价值在于，它把第三步和第四步单独拎出来，要求开发者面对一个不太舒服的事实：工具调用成功，不等于业务目标成功。

为什么 Agent 会坚信自己已经完成

Agent 产生“完成幻觉”，通常不是因为它完全没有执行动作，而是因为它把局部证据误当成了最终证据。

第一种情况是工具响应过于乐观。一个工具可能返回“请求已接受”，这只说明请求进入了处理链路，并不代表数据库已经完成提交。异步任务、队列消费、事务回滚和最终一致性都可能让实际状态晚于工具返回。

第二种情况是模型把计划当成了结果。Agent 已经生成了清晰的步骤，也调用过相关工具，于是上下文看起来像一份完成记录。但“准备更新用户状态”和“用户状态已经更新”是两个完全不同的事实。

第三种情况是返回结果缺少业务语义。数据库驱动层可能只返回影响行数、请求编号或一个布尔值。对模型来说，这些信息并不足以判断目标对象是否正确，更无法自动发现更新了错误的记录、遗漏了一个字段，或因为条件不匹配导致影响行数为零。

第四种情况是任务目标本身没有被转化为可验证条件。比如“把所有过期订阅标记为失效”不是一个完整的验收标准。真正可验证的条件应该包括：符合条件的记录数量、每条记录的新状态、更新时间范围，以及不应被修改的记录是否保持不变。

ThinkingBox 的关键提醒：把外部状态当成唯一裁判

ThinkingBox 最值得借鉴的不是某一个模型的失败案例，而是它对 Agent 评估方式的重新排序。

传统 Agent 评测经常看最终回复是否合理、工具调用格式是否正确，或者模型是否生成了看起来完整的执行轨迹。这些指标可以衡量模型的表达能力，却不能证明外部系统真的发生了预期变化。

更可靠的评估应当至少包含三层：

| 评估层级 | 检查内容 | 能回答的问题 | |---|---|---| | 语言层 | Agent 的最终回复、计划和解释 | Agent 说了什么 | | 执行层 | 工具是否被调用、参数是否正确、调用是否报错 | Agent 做了什么 | | 状态层 | 数据库、文件系统或业务系统的最终状态 | 世界实际上发生了什么 |

其中，状态层才是任务是否完成的最终依据。语言层可以帮助人理解，执行层可以帮助工程师排查，只有状态层能回答“目标是否真的达成”。

这也是 ThinkingBox 与普通工具调用评测的区别。它不满足于证明 Agent 能够发起操作，而是继续追问：操作之后，外部世界是否变成了任务要求的样子？

对开发者的直接启示：必须设计独立验证器

独立验证器是一个不依赖 Agent 自我判断、直接读取外部状态并给出结果的组件。

它不应该读取 Agent 的最终回答来判断成功，也不应该只检查最后一次工具调用是否返回成功。验证器应该根据任务的验收条件，重新查询数据库或目标系统，并输出结构化结果，例如 passed、failed、partial 和具体差异。

一个简单的数据库任务，至少应当把“写入”和“核验”拆成两个动作：

-- 写入动作：只负责改变状态
UPDATE subscriptions
SET status = 'expired', updated_at = CURRENT_TIMESTAMP
WHERE expires_at < CURRENT_TIMESTAMP
  AND status = 'active';

-- 验证动作：重新读取状态，确认目标是否成立
SELECT COUNT(*) AS remaining_active
FROM subscriptions
WHERE expires_at < CURRENT_TIMESTAMP
  AND status = 'active';

这里的重点不是 SQL 写法，而是责任边界。第一条语句执行成功，并不能证明第二个查询会返回零。可能存在事务未提交、条件理解错误、时区处理错误、权限限制，或者目标表并不是 Agent 以为的那张表。

更成熟的验证器还需要检查副作用。任务如果要求只修改过期订阅，就不能只确认目标记录变成了 expired，还要确认未过期订阅没有被误改，关键字段没有被覆盖，更新数量也没有超出合理范围。

“读后写”闭环，比多写一段提示词更重要

Agent 生产系统最应该补上的能力，不是继续增加“请务必确认任务完成”之类的提示词，而是建立读后写闭环。

一个可落地的闭环通常包含以下步骤：

1. 将自然语言目标拆成明确的状态断言。
2. Agent 执行写操作，并保存工具调用记录。
3. 系统等待必要的异步处理完成。
4. 验证器从权威数据源重新读取状态。
5. 将实际状态与断言逐项比较。
6. 只有验证通过，系统才向用户返回完成。
7. 验证失败时，进入重试、人工确认或补偿流程。

这个流程的关键，是让“完成”成为验证器产生的事件，而不是模型生成的一句话。

在工程实现中，完成事件最好携带结构化信息：任务编号、目标对象、预期状态、实际状态、验证时间、证据来源和差异列表。这样一来，后续的审计、回放和问题定位才有依据。

数据库只是开始，代码和文件操作同样危险

ThinkingBox 暴露的模式并不局限于数据库，因为所有有外部副作用的 Agent 都存在同样的问题。

在代码仓库里，Agent 说“修复已经完成”，可能只是生成了补丁，实际上测试没有通过，文件没有写入，或者修改没有被提交到目标分支。判断任务是否完成，应该看测试结果、文件差异和构建产物，而不是看 Agent 的总结。

在客服系统里，Agent 说“工单已经关闭”，需要确认工单状态、关闭原因和审计记录是否真实写入；在云资源管理里，Agent 说“实例已经扩容”，需要检查控制面状态和实际资源配置；在知识库更新里，Agent 说“文档已经同步”，则要确认索引是否完成刷新，用户是否真的能检索到新内容。

这些场景有一个共同结构：Agent 是执行者，外部系统才是事实来源。

可观测性不能只记录模型思考过程

Agent 可观测性是对一次任务的目标、决策、工具调用、外部状态变化和最终验证结果进行完整记录。

不少系统已经开始记录提示词、模型响应和工具调用，但这仍然可能缺少最重要的一段：工具调用之后，目标系统到底发生了什么变化。

至少需要记录以下信息：

• 任务意图：用户要求改变什么对象、达到什么状态。
• 计划与动作：Agent 生成了哪些步骤，实际调用了哪些工具。
• 输入与返回值：工具参数、权限上下文、错误信息和影响范围。
• 状态快照：操作前后的关键数据，以及读取的时间点。
• 验证证据：哪条查询或哪个外部系统确认了完成。
• 差异与处置：失败后是重试、回滚、人工接管还是接受部分完成。

这里尤其要注意时间顺序。操作前快照可以帮助确认目标是否存在，操作后快照可以证明状态是否变化，而延迟一段时间后的最终快照则能发现异步处理和最终一致性问题。

腾讯云开发者社区在 2026 年 7 月发布的 Agent 可观测性文章也提出，生产环境需要从传统日志转向结构化 Trace、意图与动作映射以及自动化归因。这个方向与 ThinkingBox 的结论是相通的：如果只看模型日志，系统只能告诉你 Agent 认为自己做了什么；只有把业务状态纳入 Trace，工程师才能知道系统实际做了什么。

与“让模型更聪明”相比，验证更划算

ThinkingBox 说明，提升模型能力并不能消除完成判断问题。

更强的模型可能更擅长规划、更少调用错误工具，也更会解释失败原因，但它依然无法仅凭自身输出证明一个外部系统已经完成更新。模型能力解决的是“如何执行”，验证机制解决的是“是否真的完成”，两者不是同一类问题。

这也解释了为什么在高风险场景里，小模型配合严格验证，可能比大模型直接操作更可靠。一个能力一般但每一步都必须通过数据库断言的 Agent，往往比一个推理能力更强、却可以自行宣布成功的 Agent 更容易上线。

成本也会因此变得可控。模型可以负责生成计划和候选动作，确定性的代码负责权限、事务、状态检查和幂等控制。把可确定的部分交还给软件系统，既能降低模型调用次数，也能减少错误恢复的成本。

生产环境的四条落地规则

第一，禁止用自然语言回复作为成功信号。 “已完成”“已更新”“已同步”都只能作为展示文本，不能直接驱动后续自动化流程。

第二，所有有副作用的工具都要定义验收条件。 工具不仅要描述参数和返回值，还要说明什么状态才算成功，以及失败时如何补偿。

第三，验证器必须拥有独立权限和独立实现。 如果验证器复用了 Agent 生成的查询逻辑，它可能和执行逻辑一起犯错，失去独立裁判的意义。

第四，优先保证幂等和可回滚。 同一任务重复执行时不应制造重复记录；部分成功时应能识别已经完成的步骤，并对剩余步骤继续处理或执行补偿。

结论：Agent 的可信度来自证据，不来自语气

ThinkingBox 把一个经常被忽略的工程事实摆到了台面上：Agent 的自信程度与任务是否成功没有必然关系。

对开发者而言，真正需要评估的不是 Agent 能不能说出一段完整的工作总结，而是它能否在失败、延迟、权限不足和部分成功的情况下，准确识别外部状态，并把证据交给系统验证。

截至 2026 年 10 月，Agent 正从聊天窗口进入数据库、代码库和企业工作流。随着权限和副作用增加，“它说自己做了什么”会越来越不重要，“系统能否证明发生了什么”才是上线门槛。

如果一个 Agent 没有独立验证、状态回读和失败处置机制，那么它不是一个真正完成任务的自动化系统，而只是一个会生成完成报告的操作员。

参考来源

• Microsoft：The Agent Said It Was Done. The Database Disagreed. —— ThinkingBox 实验原文，讨论 Agent 完成声明与数据库真实状态之间的差异。
• 腾讯云开发者社区：终结“黑盒焦虑”：AI Agent 可观测性、语义追踪与归因分析实战 —— 介绍 Agent 的结构化 Trace、意图绑定和语义级归因方法。
• GitHub：AI Agent Book —— 讨论动态生成软件中的权限边界、执行路径与 Agent 安全问题。