---
author: OOMOL
author_url: https://oomol.com/zh-cn/about/
datePublished: 2026-10-15
title: AI 说“已经完成”，怎样确认它真的做了？
description: 一次任务包含多个写入步骤时，把“完成”写成能在目标系统检查的结果，区分工具返回、目标记录与内容，并处理超时后的结果未知。
lang: zh-CN
canonical_url: https://oomol.com/zh-cn/blog/agent-task-verification/
markdown_url: https://oomol.com/zh-cn/blog/agent-task-verification.md
---

![报告标记为已核验，独立的通知纸条仍标记为待确认](/blog/agent-task-verification/zh-cn-cover.webp)

*AI 生成的概念插图，内容为假设示例。*

假设你让 AI 把一份报告保存到团队文档，再通知相关负责人。几分钟后，它回复：“已经完成。”

你打开文档，发现只有标题和一段开头；再去看通知，指定频道里没有消息。助手并没有编造——它调用的每一步都收到了响应，只是“已经完成”描述的是它的调用过程，而不是你想要的结果。

任务越依赖多个系统，这句话就越容易出现偏差。真正需要回答的问题只有一个：任务要求的结果，现在是否真的存在于它该在的地方？

## 把“完成”写成可以检查的结果

“整理报告并通知团队”适合作为任务概述，却无法用来验收。可以把它展开成一组能在目标系统中核对的条件。

以一份每周竞品报告为例：

| 任务要求 | 完成条件（可在哪里检查） |
| --- | --- |
| 整理报告 | 覆盖指定周期，保留来源链接，标明缺失资料 |
| 保存文档 | 位于指定工作区和父页面，正文与最终稿一致 |
| 通知团队 | 出现在指定频道，消息里的链接指向上面这篇文档 |
| 交付结果 | 返回文档位置、通知记录，以及未完成或未核验的事项 |

写完成条件时，尽量落到“谁能在哪里看到它”。如果只要求保存草稿，就不必通知团队；如果要求同事能读到，还要检查目标成员的访问权限——助手自己的账号能打开文档，不代表所有接收人都能打开。

“已经发出”和“对方已经阅读”也要分开。频道中出现一条消息，可以支持“已发布”的判断；没有阅读或确认记录时，就无法继续推断对方已经看到并跟进。

## 三类证据回答不同的问题

核验时有三种材料，各自只能回答一部分问题。

```text
工具返回        这次调用得到了什么响应？
                    状态、错误、返回的对象标识
                          │
目标记录        结果落在哪里？是否读得回来？
                    目标应用中的文档、消息、记录
                          │
内容检查        产物是否符合要求？
                    对照完成条件检查正文、来源、缺失项
```

**工具返回**说明这次调用发生了什么。响应里的状态字段、错误信息和返回对象由被调用的服务决定，具体含义要看该工具与目标 API 的约定。返回了文档标识，可以据此去找这份文档；仅凭标识，还无法判断正文是否完整。

**目标记录**说明结果是否真的落在系统里。用返回的标识重新读取文档，或打开目标应用中的对应记录，核对账号、工作区、父页面和内容。核对通知时也要看频道与消息本身，不要按相似的标题搜索后就认定找到了本次结果。

**内容检查**说明产物能不能交付。文档存在，仍可能漏掉一节；报告带了来源链接，也可能引用了错误周期的数据。这一步必须回到最初的完成条件，逐项对照，而不是只看“有没有创建成功”。

三类证据可以合并成一份简短回执：做了什么，结果在哪里，检查过什么，还有什么不确定。它不需要把整段运行日志贴给用户。

## 部分成功需要单独报告

多步骤任务可能只完成了一部分：前一步已经落地，后一步仍没有结论。

下面是一组用于说明处理方式的假设记录，不是实际调用日志：

| 步骤 | 观察到的结果 | 当前判断 |
| --- | --- | --- |
| 保存文档 | 返回文档标识，重新读取后正文完整、位置正确 | 已保存并核验 |
| 发送通知 | 请求超时，没有取得消息标识 | 结果未知 |
| 查询目标频道 | 当前账号没有读取消息的权限 | 无法通过此账号确认 |

这时助手应该回报“文档已保存，通知结果未确认”，附上文档链接和阻塞原因。

超时只说明调用方没有在预期时间内收到响应。通知可能没有发出，也可能已经写入目标系统而响应丢失。因此直接重跑整个任务，既可能创建第二份文档，也可能重复通知。

后续处理应从结果未知的那一步开始。若账号有读取权限，就按目标频道、发送时间和报告链接检查消息；若存在与本次任务对应的记录，核对内容后补齐回执。查询没有结果时，还要考虑查询范围、权限和数据可见延迟，不能立刻把“没查到”写成“没有发送”。

确实取不到证据时，请有权限的人检查目标频道，并暂缓再次发送。确认需要补发之后，才继续通知步骤，并复用已经核验的文档。

## 回执要保留“未确认”

一份可用的回执可以写成这样。方括号中的内容由实际结果填写；取不到时明确说明，不要生成一个看起来合理的链接。

```text
任务：保存本周竞品报告并通知指定频道

文档：已保存并核验
位置：[实际文档链接或记录标识]
已检查：目标工作区、父页面、正文、来源链接

通知：结果未确认
原因：发送请求超时；当前账号无法读取目标频道消息
处理：已暂停补发，避免重复通知

需要你确认：目标频道是否已出现包含上述文档链接的消息
```

不要把“失败”“未执行”和“结果未知”压成同一种状态，它们对应不同的处理方式。工具明确报告拒绝访问，通常要检查账号与权限；任务根本没有执行到该步骤，需要决定是否继续；发送结果未知，则应先查记录。错误原因没有变化时，反复提交同一个请求通常不会改变结果。

对于长期自动运行的流程，还要保存每一步的结果标识和核验状态。给任务加一个编号便于关联记录，但编号本身不会阻止重复写入；能否安全重试，取决于目标 API 是否支持幂等，以及流程是否真的执行了去重检查。

## 在 OOMOL 中，执行记录能覆盖到哪一步

连接层能提供调用能力和调用记录，验收判断仍要由任务自己给出。

OOMOL 的[权限控制](https://oomol.com/zh-cn/docs/access-control/)按 connection 配置可调用的操作。设计任务时值得留意两点：一是要同时考虑核验所需的读取能力，允许创建文档并不自动意味着助手能读回相关记录；二是即使权限允许调用某个操作，在发送消息、修改外部数据、扩大共享范围或删除内容之前，仍应确认目标 connection、操作和最终参数。

自部署 [OpenConnector](https://openconnector.io/)时，最近的运行记录包含脱敏后的输入摘要和 provider 错误，可以用 `OOMOL_CONNECT_ALLOWED_ACTIONS` 与 `OOMOL_CONNECT_BLOCKED_ACTIONS` 限制可执行的操作。助手只能看到 schema、scope、执行状态和安全账号标签。这些记录适合排查调用失败，但它们描述的是调用，不是业务目标是否达成。[自部署指南](https://oomol.com/zh-cn/docs/openconnector-self-hosting/)

如果任务需要等待人工审批，[Open Flow](https://console.oomol.com/flows) 的 Approval 和 Wait 节点会持久化等待状态，确认后可以继续同一次运行，不必重跑已经完成的步骤。运行历史关联对应的流程版本，便于查清某份结果由哪一版逻辑生成。[托管版](https://console.oomol.com/flows) · [源码与自部署](https://github.com/oomol-lab/open-flow)

完成条件、步骤状态、重试决定和最终回执，需要由助手指令、业务代码或工作流落实。连接层给出调用路径和记录，不替你判断整项任务是否通过验收。

## 从一项可以验收的任务开始

先选一步写入，不要一上来就串起整条链路。在 [OOMOL Connections](https://console.oomol.com/connections) 配置任务需要的连接，核对可用操作，再把下面这段要求交给助手：

> 把这份已确认的报告保存到我指定的测试文档位置。保存后重新读取，检查正文与原稿是否一致，并返回实际文档链接。先不要通知其他人。如果无法读取或核验，请说明已执行的步骤、返回的记录标识和缺少的条件，不要将任务标为全部完成。

等保存与核验能稳定完成，再加入通知，并要求返回对应的消息记录。每增加一个写入步骤，就为它补上一项能在目标系统中检查的完成条件。

验收的关键不在于助手最后说了什么，而在于你能否沿着它给出的位置，在目标系统里找到那个结果。当每个写入步骤都对应一项可以检查的条件，那份“已经完成”才有依据。