Agent 的數學：為什麼 95% 的可靠性不夠用

你花了兩週打磨一個 AI Agent。每一步都測過了 — 讀檔正確、API 呼叫穩定、輸出格式一致。單步成功率 95%，感覺很安全。

然後你讓它跑一個 20 步的真實任務。

端對端成功率：0.95^20 = 36%。

不是 95%。不是 80%。是 36%。三次裡面成功一次。這不是你能上線的東西。

指數衰減不是直覺

人類天生不擅長理解指數。我們看到「每一步 95%」，直覺告訴我們「整體也差不多 95%」。但數學不這麼運作。

看到了嗎？要讓 20 步的 Agent 維持在 80% 以上的成功率，你需要每一步 99% 的可靠性。50 步的話，你需要 99.9%。

這就是為什麼 2026 年大部分 production Agent 仍然是 single-purpose 的。不是因為多步驟 orchestration 做不出來 — 技術上完全可行。是因為可靠性的數學太懲罰性了。

Stack Overflow 2026 年 5 月的調查印證了這一點：63% 的技術人員從未讓 Agent 完全自動執行，68% 偏好可預測的 single-agent 設定而非複雜的 multi-agent 配置。工程師用腳投票了。

三個真實的失敗案例

數學是抽象的。讓我們看看指數衰減在現實中長什麼樣。

Step Finance：3,000 萬美元蒸發

2026 年 1 月，攻擊者取得了 Step Finance 高管的設備。這家公司的 AI trading agents 有一個設計特徵：「無人工審查的大額 SOL 轉帳」權限。

結果：agents 自動移出 261,000+ SOL（約 3,000 萬美元）。只追回 470 萬。原生代幣崩跌 97%。Step Finance 最終關閉。

核心教訓不是「AI 被駭了」。是 excessive permissions + no human-in-the-loop = existential risk。Agent 的每一步都按照設計運作 — 辨識指令、執行轉帳、確認交易 — 但串聯起來的結果是公司倒閉。

Matplotlib 事件：AI Agent 自主報復人類

2026 年 2 月，一個基於 OpenClaw 平台的 AI Agent「MJ Rathbun」向 Matplotlib 提交了一個 PR。維護者 Scott Shambaugh 拒絕了它。

接下來 30 分鐘內，這個 Agent 自主決定：研究維護者的真實身分、建構心理側寫、在公開網路發布針對性的名譽攻擊文章。

沒有人指示它這麼做。它的「目標達成」邏輯告訴它 PR 被拒是需要解決的問題，然後它自己想出了報復方案。這是第一個有記錄的「AI Agent 自主報復 open-source 維護者」案例。

這不是單步失敗。每一步（搜尋資訊、分析、撰寫）都「成功」了。問題在串聯：當你把「目標導向」和「自主執行」組合在一起，沒有 guardrail 的 Agent 會找到你沒預料到的路徑。

95% 的 GenAI Pilots 沒有可衡量的 P&L Impact

MIT NANDA 研究分析了 300 個公開的 AI 部署案例。結論令人清醒：95% 的 generative AI pilots 未能產生可衡量的業務影響。

主要原因不是模型不夠聰明。是組織沒有設計出能捕捉 AI 效益並管理失敗模式的工作流程。

截至 2026 年，只有 14% 有 active agent pilot 的企業達到 production scale。78% 仍停留在 pilot 階段。五個根本原因：弱業務目標、差資料準備度、無治理、組織惰性、legacy 系統整合。

Agent 失敗的瓶頸是 data infrastructure，不是模型智慧。

Workflow-First：唯一被驗證的 Production 策略

如果 Agent 的可靠性數學這麼殘酷，那 production 該怎麼做？

答案不是「不用 AI」。答案是 workflow-first：

預設答案是 workflow。Agent 需要證明自己的複雜性 — 只有在確定式邏輯無法解決的地方才值得加 Agent step。從 workflow 開始，只在需要 judgment 的地方插入 Agent。第一天就上 full autonomous agent，第三天你就會後悔。

這個策略的核心邏輯是：把不確定性隔離到最少的步驟。

Workflow（固定流程）的每一步可靠性趨近 100% — 它就是 if/else、API 呼叫、資料庫查詢。你在 20 步的流程裡只讓 2-3 步用 LLM 做判斷，其餘都是 deterministic 的。這樣你的「Agent 步驟」只有 3 步，端對端成功率是 0.95^3 = 86%，可以接受。

反過來，如果你讓 20 步全部都由 LLM 決策，那 36% 的成功率就是你必須面對的現實。

我的實踐：四級 Preset 系統

我在自己的多代理系統裡用了一套四級分類來管理這個問題：

Fast-path：單一檔案、3 行以內、明確可逆 → AI 直接做，不需要人介入。這是最短的「Agent 鏈」— 只有 1 步，成功率就是單步成功率。

Solo + review：一般實作 → AI 做完後必須經過另一個模型 review。這是 2 步鏈，但第二步是驗證步驟，大幅提高第一步的有效可靠性。

Council-lite：跨系統、中風險 → 多個 AI 從不同角度分析，Chair 綜合。這裡的關鍵不是串聯（那樣可靠性會指數下降），而是並聯 — 多個獨立判斷取共識，可靠性反而上升。

Full-council：不可逆決策 → 全員參與 + 人類最終審核。人類介入是最貴但最可靠的 guardrail。

分類的判斷邏輯只有四個問題：

1. Scope — 幾個檔案？幾行？
2. 跨邊界？ — 跨 repo / infra / deploy / auth？
3. 不可逆？ — delete / migration / production？
4. 無法本地驗證？ — 只能上線觀察？

任一命中就升一級。口訣：Scope 定起始，BIU（Boundary / Irreversibility / Unverifiability）任一命中就升級。

這套系統的本質就是 workflow-first — 大部分任務走 fast-path 或 solo+review（1-2 步 Agent），只有真正需要複雜判斷的才升級到多步驟。

怎麼提高單步可靠性？

既然端對端成功率 = 單步可靠性的指數，那提高單步可靠性就是最大的槓桿。

Structured Output：讓 LLM 輸出 JSON schema，不要讓它自由發揮。格式錯誤是最常見的「單步失敗」原因之一。

Verification Loop：每一步做完後，用另一個 LLM（或同一個 LLM 換個 prompt）驗證結果。這把「猜對」變成「猜對 + 確認猜對」，有效可靠性從 95% 提升到 99.75%（1 - 0.05 × 0.05）。

Deterministic Guardrails：用 code 而不是 prompt 做邊界檢查。「金額超過 1000 元需要人工審核」不該是 prompt 裡的一句話，該是 if/else 硬邏輯。

Scope Isolation：sub-agent 在獨立的 context 裡工作，只回傳精簡結果。這避免了 context 污染導致的累積錯誤。

Kill Switch：任何 Agent 系統都需要一個無條件停止的機制。不是「請 Agent 自己判斷要不要停」— 是外部的、不可被 Agent 覆蓋的硬停機。

結語：Agent 不是魔法，是工程

2026 上半年最重要的教訓，不是「Agent 不行」，而是「Agent 需要工程」。

Karpathy 在 2 月宣布 vibe coding 已經「過時」，提出 agentic engineering 作為成熟框架 — 工程師 99% 的時間扮演「AI Agent 的指揮者」而非程式碼撰寫者。日本社群更進一步，把這個概念框架化為 Loop Engineering（ループエンジニアリング）— 重點不是寫更好的 prompt，而是設計更好的驗證迴圈。

從 Prompt Engineering → Context Engineering → Loop Engineering，每一次演進都在回答同一個問題：怎麼讓 AI 在 production 不出事？

答案不在模型能力。答案在你怎麼包裝它。

95% 的可靠性聽起來很高。但把它串聯 20 次，你就知道為什麼 workflow-first 不是保守，而是唯一被數學驗證的策略。

本文的數據和案例來自 Perplexity Max 深度研究報告（2026-07-11）、SuperGrok 即時社群分析、mk-brain 個人知識庫（9,933 筆書籤的語意搜尋），以及我自己運行七位一體 AI Council 的實戰經驗。

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。