---
author: OOMOL
author_url: https://oomol.com/zh-tw/about/
datePublished: 2026-10-15
title: AI 說「已經完成」，怎樣確認它真的做了？
description: 一次任務包含多個寫入步驟時，把「完成」寫成能在目標系統檢查的結果，區分工具回傳、目標記錄與內容，並處理逾時後的結果未知。
lang: zh-TW
canonical_url: https://oomol.com/zh-tw/blog/agent-task-verification/
markdown_url: https://oomol.com/zh-tw/blog/agent-task-verification.md
---

![報告標記為已核驗，獨立的通知紙條仍標記為待確認](/blog/agent-task-verification/zh-tw-cover.webp)

*AI 生成的概念插圖，內容為假設範例。*

假設你讓 AI 把一份報告儲存到團隊文件，再通知相關負責人。幾分鐘後，它回覆：「已經完成。」

你開啟文件，發現只有標題和一段開頭；再去看通知，指定頻道裡沒有訊息。助手並沒有編造——它呼叫的每一步都收到了回應，只是「已經完成」描述的是它的呼叫過程，而不是你想要的結果。

任務越依賴多個系統，這句話就越容易出現偏差。真正需要回答的問題只有一個：任務要求的結果，現在是否真的存在於它該在的地方？

## 把「完成」寫成可以檢查的結果

「整理報告並通知團隊」適合作為任務概述，卻無法用來驗收。可以把它展開成一組能在目標系統中核對的條件。

以一份每週競品報告為例：

| 任務要求 | 完成條件（可在哪裡檢查） |
| --- | --- |
| 整理報告 | 涵蓋指定週期，保留來源連結，標明缺失資料 |
| 儲存文件 | 位於指定工作區和父頁面，正文與最終稿一致 |
| 通知團隊 | 出現在指定頻道，訊息裡的連結指向上面這篇文件 |
| 交付結果 | 回傳文件位置、通知記錄，以及未完成或未核驗的事項 |

寫完成條件時，盡量落到「誰能在哪裡看到它」。如果只要求儲存草稿，就不必通知團隊；如果要求同事能讀到，還要檢查目標成員的存取權限——助手自己的帳號能開啟文件，不代表所有接收人都能開啟。

「已經發出」和「對方已經閱讀」也要分開。頻道中出現一則訊息，可以支持「已發布」的判斷；沒有閱讀或確認記錄時，就無法繼續推斷對方已經看到並跟進。

## 三類證據回答不同的問題

核驗時有三種材料，各自只能回答一部分問題。

```text
工具回傳        這次呼叫得到了什麼回應？
                    狀態、錯誤、回傳的物件識別碼
                          │
目標記錄        結果落在哪裡？是否讀得回來？
                    目標應用中的文件、訊息、記錄
                          │
內容檢查        產物是否符合要求？
                    對照完成條件檢查正文、來源、缺失項
```

**工具回傳**說明這次呼叫發生了什麼。回應裡的狀態欄位、錯誤訊息和回傳物件由被呼叫的服務決定，具體含義要看該工具與目標 API 的約定。回傳了文件識別碼，可以據此去找這份文件；僅憑識別碼，還無法判斷正文是否完整。

**目標記錄**說明結果是否真的落在系統裡。用回傳的識別碼重新讀取文件，或開啟目標應用中的對應記錄，核對帳號、工作區、父頁面和內容。核對通知時也要看頻道與訊息本身，不要按相似的標題搜尋後就認定找到了本次結果。

**內容檢查**說明產物能不能交付。文件存在，仍可能漏掉一節；報告帶了來源連結，也可能引用了錯誤週期的資料。這一步必須回到最初的完成條件，逐項對照，而不是只看「有沒有建立成功」。

三類證據可以合併成一份簡短回執：做了什麼，結果在哪裡，檢查過什麼，還有什麼不確定。它不需要把整段執行日誌貼給使用者。

## 部分成功需要單獨報告

多步驟任務可能只完成了一部分：前一步已經落地，後一步仍沒有結論。

下面是一組用於說明處理方式的假設記錄，不是實際呼叫日誌：

| 步驟 | 觀察到的結果 | 目前判斷 |
| --- | --- | --- |
| 儲存文件 | 回傳文件識別碼，重新讀取後正文完整、位置正確 | 已儲存並核驗 |
| 發送通知 | 請求逾時，沒有取得訊息識別碼 | 結果未知 |
| 查詢目標頻道 | 目前帳號沒有讀取訊息的權限 | 無法透過此帳號確認 |

這時助手應該回報「文件已儲存，通知結果未確認」，附上文件連結和阻塞原因。

逾時只說明呼叫方沒有在預期時間內收到回應。通知可能沒有發出，也可能已經寫入目標系統而回應遺失。因此直接重跑整個任務，既可能建立第二份文件，也可能重複通知。

後續處理應從結果未知的那一步開始。若帳號有讀取權限，就按目標頻道、發送時間和報告連結檢查訊息；若存在與本次任務對應的記錄，核對內容後補齊回執。查詢沒有結果時，還要考慮查詢範圍、權限和資料可見延遲，不能立刻把「沒查到」寫成「沒有發送」。

確實取不到證據時，請有權限的人檢查目標頻道，並暫緩再次發送。確認需要補發之後，才繼續通知步驟，並重用已經核驗的文件。

## 回執要保留「未確認」

一份可用的回執可以寫成這樣。方括號中的內容由實際結果填寫；取不到時明確說明，不要生成一個看起來合理的連結。

```text
任務：儲存本週競品報告並通知指定頻道

文件：已儲存並核驗
位置：[實際文件連結或記錄識別碼]
已檢查：目標工作區、父頁面、正文、來源連結

通知：結果未確認
原因：發送請求逾時；目前帳號無法讀取目標頻道訊息
處理：已暫停補發，避免重複通知

需要你確認：目標頻道是否已出現包含上述文件連結的訊息
```

不要把「失敗」「未執行」和「結果未知」壓成同一種狀態，它們對應不同的處理方式。工具明確報告拒絕存取，通常要檢查帳號與權限；任務根本沒有執行到該步驟，需要決定是否繼續；發送結果未知，則應先查記錄。錯誤原因沒有變化時，反覆提交同一個請求通常不會改變結果。

對於長期自動執行的流程，還要儲存每一步的結果識別碼和核驗狀態。給任務加一個編號便於關聯記錄，但編號本身不會阻止重複寫入；能否安全重試，取決於目標 API 是否支援冪等，以及流程是否真的執行了去重檢查。

## 在 OOMOL 中，執行記錄能涵蓋到哪一步

連接層能提供呼叫能力和呼叫記錄，驗收判斷仍要由任務自己給出。

OOMOL 的[權限控制](https://oomol.com/zh-tw/docs/access-control/)按 connection 配置可呼叫的操作。設計任務時值得留意兩點：一是要同時考慮核驗所需的讀取能力，允許建立文件並不自動意味著助手能讀回相關記錄；二是即使權限允許呼叫某個操作，在發送訊息、修改外部資料、擴大共享範圍或刪除內容之前，仍應確認目標 connection、操作和最終參數。

自部署 [OpenConnector](https://openconnector.io/)時，最近的執行記錄包含已遮蔽敏感資訊的輸入摘要和 provider 錯誤，可以用 `OOMOL_CONNECT_ALLOWED_ACTIONS` 與 `OOMOL_CONNECT_BLOCKED_ACTIONS` 限制可執行的操作。助手只能看到 schema、scope、執行狀態和安全帳號標籤。這些記錄適合排查呼叫失敗，但它們描述的是呼叫，不是業務目標是否達成。[自部署指南](https://oomol.com/zh-tw/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) 配置任務需要的連接，核對可用操作，再把下面這段要求交給助手：

> 把這份已確認的報告儲存到我指定的測試文件位置。儲存後重新讀取，檢查正文與原稿是否一致，並回傳實際文件連結。先不要通知其他人。如果無法讀取或核驗，請說明已執行的步驟、回傳的記錄識別碼和缺少的條件，不要將任務標為全部完成。

等儲存與核驗能穩定完成，再加入通知，並要求回傳對應的訊息記錄。每增加一個寫入步驟，就為它補上一項能在目標系統中檢查的完成條件。

驗收的關鍵不在於助手最後說了什麼，而在於你能否沿著它給出的位置，在目標系統裡找到那個結果。當每個寫入步驟都對應一項可以檢查的條件，那份「已經完成」才有依據。