你如何驗證 AI 工作流程實際上做了正確的事情？
嗨各位，
當你的 AI 工作流程傳回「成功」且所有 API 都回應正常，但之後你發現它更新了錯誤的記錄、發送了錯誤的金額，或建立了重複項目時，你如何捕捉到這一點？
不是在問提示詞品質。而是關於執行後的間隙。
你依賴：
· 手動檢查？
· 讀回/驗證步驟？
· 稽核日誌？
· 對帳報告？
· 還是只是等待投訴？
我很想聽聽真實的故事：
1. 哪裡出了問題
2. 你如何發現的
3. 你改變了什麼
4. 你的修復方案仍然感覺不完整嗎？
試圖判斷這是否是一個值得建立解決方案的常見痛點。謝謝！
嗨 @Rayner 歡迎！
核心問題在於「成功」只是指呼叫返回了 200，這是傳輸層面，不是正確性層面。n8n 的 Error Trigger 只在真正發生錯誤時觸發，所以寫入到錯誤的記錄或錯誤的金額時，即使成功也不會觸發。這類問題必須透過重新檢查結果來捕捉，而不是透過錯誤處理。
大部分問題都可以透過讀回步驟來解決：在任何寫入操作之後，立即 GET 你剛才修改的記錄，並驗證關鍵欄位是否與你的預期相符（用 IF 比較預期的 id、金額和收款人與回應內容），然後在不匹配時分支到警示或補償性操作。對於重複問題，讓寫入操作成為冪等的：如果 API 支援的話傳送 Idempotency-Key，或透過唯一的業務鑰匙查找記錄，如果已存在則跳過建立，而不是依賴代理不會重複執行。
在「為什麼會發生這種情況」和對帳方面，針對每個有副作用的操作寫入一行稽核記錄（預期參數、解析後的值、回應和驗證標誌）到 Sheet 或資料庫，然後執行排程工作流程，重新查詢記錄系統，並與該日誌進行比較，以事後發現漂移和重複。你也可以在寫入前使用 Guardrails 節點或簡單的 IF 來驗證代理選擇的值（金額在範圍內、id 已解析、收款人相符）。
老實說，既然你問了：讀回加上對帳可以捕捉大多數錯誤記錄和錯誤金額的情況，但這會增加延遲和成本，而且仍然無法捕捉看起來正確但意圖錯誤的操作，所以大多數人會分層實施這些措施並接受一些殘餘風險。
這是一個非常著名的問題。解決這個問題所需的努力取決於錯誤率的重要性。
就我個人而言，對於我最後創建的項目，我使用了兩件事：
1. 在構建時，手動驗證輸出本身幾次。當我看到錯誤率達到我想要的水平時就放手，之後就讓它去吧。
2. 以一種方式循環，讓實際的人工檢查每 x 次運行。
總的來說，這裡的各位也談到了這一點，如果自動化不值得信任，對大多數團隊來說都不會起到作用。
有一件事要補充：通过在每个AI代理操作前标记一个置信度/风险评分，将「是否执行」与「是否正确执行」分开，低风险操作（只读、少量）自动进行，高风险操作（大量、删除、新收件人）则先路由到人工审批步骤，而不是事后进行完整回读。这比验证所有内容更便宜，并且可以捕捉回读方法无法处理的错误意图情况。
我們培訓內部團隊安全地使用 AI，因此對目前的做法有很好的了解。等待問題被發現實際上是很多團隊發現第一個真正錯誤的方式 — 比任何人承認的都更普遍，我在為財務和營運客戶構建的整合中見過不止一次。
真正行之有效的做法是：將讀回驗證作為強制步驟而非可選步驟，所以在發佈記錄後，下一個節點會取回記錄並將關鍵欄位與發送的內容進行比較，若不相符就失敗並發出警報。除此之外，按計劃進行輕量級對帳報告，比較來源計數和總計與目的地計數和總計 — 標記漂移而非追蹤個別記錄。對於涉及金錢或庫存的任何事項，超過閾值的人工審核關卡值得承受這些摩擦，因為 AI 工作流往往在邊界處失敗，而邊界通常是高價值記錄。審計日誌有幫助，但前提是有人真正查看它；每日摘要總結工作流涉及的內容，並標記異常，遠比原始日誌文件更容易被讀取。重複問題特別是幾乎總是通過冪等密鑰解決 — 將來源記錄的雜湊值在第一次建立時寫入目的地，在任何後續運行前檢查它。
關於你最後的問題：是的，大多數修復仍然感覺不完整，因為真正的缺口在於工作流根據工具測量的每項指標都「成功」了，但業務結果是錯誤的。這既是測試和監控問題，也是工作流設計問題。如果你想深入討論細節，很樂意通過私信討論。
好討論 — @Anshul_Namdev 的讀取驗證 + 冪等性，和 @Stanleyy 的風險評分前寫入都很好地涵蓋了兩種真實技術。還有一個沒人提過的漏洞：這裡描述的所有東西（稽核列、「已驗證」標記、協調日誌）仍然存在於工作流程內的普通表格或試算表中。這在沒人有資料庫存取權、發生不當遷移或認證資料洩露的情況下還可以，但當有人悄悄編輯一列時 — 「我們記錄了」實際上無法事後證明任何事，只能事先證明。修正很便宜，只要你知道要加它：將日誌雜湊鏈化，每一列的雜湊包含前一列的雜湊，這樣事後編輯就會破壞鏈條並可被偵測，而不只是被暗示。
另一個會迅速變得昂貴的是在 10-20 個工作流程中一致地做所有這些 — 讀取驗證、冪等性、稽核、風險路由 — 而不是只做一次。我最後建立了一個政策層，它位於工作流程前面，在一個地方處理允許/拒絕/批准決定以及防篡改日誌。如果有用的話，很樂意分享細節 — 這個討論串已經比我見過的大多數關於這個問題的寫作都好了。
我遇到的失敗模式是這個執行緒中沒有人提過的，而且回讀在結構上也無法捕捉到：成功執行但什麼都沒做的工作流程。
我的情況是一個檢索步驟將結果餵給一個大語言模型。下游的一個篩選節點中留著一個來自早期修復的過期條件，它無聲地將8行正確檢索的結果縮減為0。工作流程隨後進入「無結果」分支，這是一個完全合理的分支，並返回了一個禮貌的「我沒有那個資訊，正在轉接人工客服」的回應。
每個節點都顯示綠色。沒有任何東西被拋出，所以錯誤觸發器從未啟動。回讀無法幫助，因為沒有寫入操作可以回讀。冪等性無法幫助。風險評分無法幫助，因為這個操作按設計是低風險的，它只是拒絕了回答。
我是如何發現的：我問了它一個我已經知道源文件能回答的問題，它卻說不知道。然後我直接查詢了源表，確認答案確實在那裡。那個對比是唯一暴露問題的東西。整個執行日誌看起來都很完美，如果我沒有測試一個已知答案的問題，它就會在幾週內無聲地拒絕真實用戶。
我做出的改變：我現在對中間結果的行數進行斷言，而不僅僅對最終輸出進行斷言。如果檢索返回8行，而下一個節點輸出0行，那就不是有效狀態，而是一個信號。一個廉價的IF節點，用來發出警報而不是繼續執行。
不過，我建議採用的做法是超越任何單一節點的：保留一小組測試輸入，其中你已經知道正確答案，並按計劃在生產環境中運行。不是合成數據，而是有已知正確輸出的真實輸入。日誌告訴你機器運行了。已知答案告訴你它是正確的。
關於你最後的問題，修復是否仍然感覺不完整：是的。行數斷言可以捕捉「應該有但為空」的情況。它們無法捕捉「錯誤但看起來合理」的情況。我認為沒有人類定期審閱樣本，那個差距是關不上的。
嗨@Rayner 當你的 AI 工作流程回傳「成功」且所有 API 都回應 OK 時， 要驗證成功的 API 呼叫實際上是否更新了正確的數據：
擷取記錄： 在更新步驟之後立即新增一個 HTTP 請求節點，使用其 ID（或任何其他參數）來擷取記錄。
比較欄位： 檢查返回的值是否與你的目標參數相符，以便在移至下一個工作流程步驟之前捕捉任何差異。
希望這有幫助！祝自動化順利！
以上所有內容都假設執行存在。我們測量到的兩個失敗類別既不產生執行，要麼產生一個包含悄悄錯誤值的乾淨執行。
1. 從未發生的執行。 在自託管 2.31.5 上，我們發現類型為 weeks 的排程觸發器，其 JSON 缺少 weeksInterval 時，在生產環境中從不觸發。不是延遲——而是從未觸發。沒有執行列，所以回讀、協調差異、稽核日誌和列計數斷言都沒有任何東西可檢查，「正常」與「健康」的呈現方式完全相同。兩個特性使其變得討厭：
triggerAtMinute 屬於同一類別，但更溫和：它變成哈希衍生的偽隨機分鐘，而不是你設定的分鐘。我們現在的做法是：發佈一份與文件定義完全相同的副本，不經過 UI 保存，並觀察真實的生產火災。在執行列表中，由排程觸發的運行不帶燒瓶圖標，而手動運行帶有——這是「排程執行此操作，而不是我」的便宜機械判別器。
2. 來自時區的看似合理但錯誤。 工作流程設定 → 時區影響觸發器觸發，但不影響代碼節點內的 new Date()，它在進程的本地時間中解析。排程正確觸發，只有日期數學偏差一天：列計數正確，回讀與你寫入的內容相符，該值就是錯誤的。相關事項：new Date('YYYY-MM-DD') 解析為 UTC 午夜，所以在 UTC 負數區域中，來自工作表的日期字符串落在前一個本地日期，每個日期差異移位一個。這個我們已經發佈——它在 JST 中不再現，所以在開發過程中是不可見的，只有當我們運行邊界情況時才會出現（due−2 不得觸發，due−3 必須觸發）。修復方法是：從 $now 建立「今天」（Luxon、工作流程時區），執行日期部分算術而不是毫秒加法，並對日期差異進行捨入而不是向下取整，以便 DST 轉換不會造成問題。
3. 禁用的節點直接傳遞輸入。 在生產運行中，禁用的節點返回其輸入不變。如果下游有任何回退表達式，你會獲得無聲的性能降低——沒有錯誤、沒有警告，輸出看起來像未處理的輸入。它在回讀中倖存，所以它屬於「在執行任何操作時成功」列表。
警告：以上所有內容均在自託管 2.31.5 上測量；我們沒有自己的雲測量。
在已知答案的測試輸入上——正確的直覺，但它仍然只在運行存在後才捕捉事物。觸發器端的等效項是斷言運行確實發生了：讓工作流程寫入自己的心跳列並在缺少心跳時發出警報。信號缺失是回讀層無法看到的唯一東西。