Agent 回報「完成」之前，先確認訊息到底有沒有送到

ai代理工作流程排程任務通知系統可靠性設計

ryanvale 2026-10-29 18:53:01 ‧ 34 瀏覽

分享至

假設團隊讓 agent 每週整理一次錯誤紀錄，再把報告送到固定的審查群組。某天排程正常啟動，報告也寫好了，傳送通知時卻等到逾時。儀表板上的任務顯示成功，群組那邊沒人能確定有沒有收到。

這時按「重跑」很直覺，也最容易出事。整份報告可能重新產生，群組最後看到兩則內容相同的通知；反過來，若把逾時當成已送達，審查者可能根本沒看見報告。系統把幾個不同的「完成」塞進同一格，出問題時便說不清楚是哪一步卡住。

排程成功，只證明它開始跑了

Microsoft Foundry 的更新將 Routines 列為已正式推出，也示範了啟動工作後，另外處理報告與固定目的地通知的流程。範例裡送到 Teams 需要額外的 adapter；手動 dispatch 的示範，不能直接算成週期排程與通知交付都已驗證。OpenAI 的 Agents API 則讓工具呼叫、computer use 與長流程的上下文管理成為可用的建置材料。這些能力可以讓 agent 做更多事，跨系統的送達確認仍得由應用程式自己設計。

我會先讓「完成」有明確的主詞。排程接受工作、報告完成、審查群組收到訊息，是三件事。前兩件事發生在自己能保存紀錄的系統裡，最後一件事發生在另一個系統。不能拿 agent 回覆的「已發送」替接收端簽收。

三種完成，各留一份證據

這裡的欄位是團隊可以自行實作的契約，不是 Foundry、Teams 或 OpenAI 的官方 schema。一次週報先固定 job_id、觸發時間、收件目的地與來源範圍。報告存檔時再記 report_version，之後的通知永遠指向這個版本，不讓重試順便改寫報告。

狀態	足以進入這個狀態的證據
`accepted`	任務識別與必要輸入已持久化；只是受理，尚未產生報告
`result_ready`	報告版本已保存，來源與必要檢查已記錄；尚未證明通知送達
`delivery_confirmed`	目的地與報告版本都對得上的接收端紀錄或可查證回執；單有傳送端訊息 ID 還不夠
`delivery_unknown`	傳送要求逾時或回執遺失，接收結果無法判定；等待對帳或人工接手

這張表的好處不是狀態名稱多漂亮，而是值班的人能從 job_id 查到同一份報告和同一次傳送嘗試。通知前先持久化待送記錄，附上固定收件對象與報告版本；收到可核對的回執後才記 delivery_confirmed。傳送要求失敗也要留下嘗試紀錄，不要直接把整個產報告流程從頭跑一遍。

逾時之後，先對帳再決定要不要重送

傳送端沒等到回應，不代表接收端沒收到。假如通知系統提供可查詢的訊息 ID，就拿它與目的地的紀錄對帳；查到吻合的訊息，再補齊本地回執。若團隊掌控接收端，也能以 job_id 加 report_version 做去重鍵，讓同一版本的重複要求只處理一次。外部群組服務若沒有這種能力，就不能指望去重鍵替你擋掉重複通知。

更棘手的是請求逾時時連訊息 ID 都沒拿到。此時自動重送可能造成雙份通知；永遠不送又可能漏掉。我的預設是把狀態留在 delivery_unknown，交給值班者核對群組及報告版本，再決定是否補送。人工確認前，不把它改寫成成功，也不讓 agent 自己猜。跨兩個系統很難憑一句「重試即可」保證恰好一次送達。

如果任務能在手機或其他裝置接手，更需要讓接手者看得見目前卡在哪一步：哪個報告版本待審、上次傳送何時逾時、誰有權決定補送。通知不是一句提醒而已，它會改變人下一步做什麼。