這些數字並非我杜撰，而是來自社群中一位專門處理這類問題的顧問。他提到最令人頭痛的是：診斷時間無法計費，只能自行承擔。本月已有三個類似案例：工作流程連續失敗 28 次，運行三天後才被發現；另一個工作流程連續六週將所有潛在客戶評分為零；還有一個案例是代理程式在兩次查詢都返回 403 錯誤後，卻告訴客戶「我看到您已被收費」，而且執行狀態顯示為「已完成」。
這些失敗都沒有顯示紅色錯誤，這正是問題所在。您的錯誤處理流程只會在例外情況下觸發，但這些「無聲的失敗」卻不會拋出任何錯誤。
您目前實際付出的代價包括：發現問題的時間，從 48 小時到三週不等，通常是客戶告知您。診斷時間則需 6 到 15 小時，用於深入檢查執行紀錄，且這部分時間無法計費。
每次事件本身的成本約為 2,500 到 8,000 美元。若一年發生四次，總計將損失 10,000 到 32,000 美元，外加 60 小時無法向客戶收費的工作時間。
我開發的 Matrix 工具會根據工作流程聲稱的結果，例如「已寄送電子郵件」或「已更新紀錄」，然後讀取權威系統來驗證這些操作是否確實發生。它不會只依賴工作流程自行寫入的執行日誌，而是檢查實際的信箱或資料庫。
Matrix 會給出三種判斷結果：矛盾、確認或不確定，並附上相關證據。其中兩種檢查無需任何額外存取權限：如果聲稱已執行某操作，但實際上從未呼叫任何工具，那麼「未呼叫」本身就是證據；如果查詢返回 403 錯誤，但工作流程卻聲稱該查詢會顯示某結果，或者呼叫已完成但結果是被拒絕，大多數包裝器會忽略這些。
第三種情況則需要連接信箱：工具已被呼叫並返回 200 成功代碼，但實際紀錄卻不存在。
「不確定」的判斷結果之所以重要，是因為如果 Matrix 無法證明追蹤是完整的，或者遇到它無法識別的工具名稱，它會選擇不作判斷，而不是錯誤地指責您正常運作的工作流程。
一個在不確定情況下仍樂觀地做出判斷的監控工具，在關鍵時刻將毫無價值。
Matrix 的限制在於，Gmail 是目前唯一支援的外部轉接器。它無法捕捉到參數正確但內容錯誤的呼叫，例如收件人格式正確但收件人錯誤，Gmail 仍會認為郵件已成功寄出。
此外，如果文字中包含一個從未發送的錯誤聲明，Matrix 也沒有實際結果可以回溯比對。
設定 Matrix 非常簡單，只需將一行程式碼貼到 Cursor 或 Claude Code 中即可自動配置。或者，您也可以手動透過 TypeScript 或 Python 進行四次呼叫來設定。
MatrixVerify.dev 提供免費服務，已有超過 20 位使用者，我寧願它被測試到出錯也不願被忽視。我很樂意針對您的某次執行進行測試，並告訴您它發現了什麼，即使什麼都沒發現也一樣。
