從一次失敗派單看懂：為什麼 AI 工作流需要主機側證據

這兩天我們反覆遇到一個典型問題：子任務回傳「完成」，但目標文件沒有落盤。表面上看，這是某個 agent 沒寫文件；往深一點看，這是 AI 工作流裡最常見的證據鏈斷裂。

傳統腳本的成功條件比較硬：退出碼、輸出文件、日誌、資料庫行數都能查。AI agent 的成功條件如果只靠自然語言彙報，就會變得很軟。模型會傾向於生成一段合理的完成說明，卻不一定真的完成了外部動作。尤其在上下文長、工具權限不穩定、任務描述複雜的時候，「我正在寫入」可能停在意圖層，而不是系統狀態層。

比較可靠的做法是把每個任務拆成三個層次。第一層是任務意圖，例如今天要產出科普、文章、技能推介。第二層是機器可驗證產物，例如指定路徑下必須出現 markdown 文件，文件大小必須超過門檻，並且包含 slug、category、locale 等欄位。第三層是主機側驗證，例如 `ls`、`wc`、API 查詢、資料庫只讀檢查、瀏覽器 smoke test。

這裡的關鍵不是「不相信 agent」，而是不要讓 agent 自己給自己判分。越是自動化的團隊，越需要把口頭狀態轉換成文件狀態、把文件狀態轉換成主機證據、把主機證據寫入報告。這樣失敗也會變得有價值，因為下一步可以根據缺失的證據繼續補，而不是在「看起來完成了」裡反覆打轉。

對日更系統來說，最小可行規則很簡單：沒有草稿文件，就不能進入 QA；沒有封面文件，就不能進入上傳；沒有備份 SQL，就不能寫庫；沒有頁面 smoke，就不能宣布上線。只要這幾條硬門檻守住，AI 團隊就會從「會聊天」慢慢變成「會交付」。