技術分享
MCP 規格大改版：企業該怎麼盤點衝擊與排出遷移時程
MCP 官方 2026-07-28 規格版把協定核心改為無狀態，並棄用 Roots、Sampling、Logging 與 HTTP+SSE 傳輸，十二個月過渡期已經開始。本文說明這次改版對企業既有系統的實際衝擊、可省下的基礎設施成本，以及一份三十天內能做完的盤點與遷移排程清單。
AI 上線後最缺的，是一套「出事怎麼辦」的劇本
AI 事故正在變多。AI Incident Database 記錄的事故從 2024 年的 233 件成長到 2025 年的 362 件，一年增加逾五成，其中約 58% 與生成式 AI 有關。同一時間，Gartner 預估超過四成的 Agentic AI 專案會在 2027 年底前被取消，主因之一正是「風險控管不足」。多數團隊把力氣花在把模型推上線，卻沒準備好幻覺、API 逾時、成本暴衝或資料外洩時的應變流程。而停機的代價並不抽象：2026 年 Splunk／Cisco 的調查估算，大型企業平均每分鐘停機成本約一萬五千美元；Uptime Institute 的年度分析也指出，逾半數營運者最近一次重大中斷的損失超過十萬美元，約五分之一更超過一百萬美元。沒有 Runbook，事故一發生就只能靠當下最資深的人臨場判斷，結果是復原慢、責任亂、同樣的錯還會再犯。
這篇提供一套可直接落地的 AI 事故應變 Runbook：先把事故分級，再定義應變流程與角色分工，最後用復盤把每一次事故轉化為系統性的改進。
第一步：把 AI 事故分級（SEV）
分級的目的，是讓「該叫醒誰、多快回應」有客觀依據。建議比照 SRE 慣例分四級，並在每一級掛上真實 AI 事故當錨點：
| 等級 | 定義 | AI 情境與真實案例 | 回應時間 | 誰介入 |
|---|---|---|---|---|
| SEV1 | 業務中斷或資料外洩 | 零點擊資料外洩：M365 Copilot 的 EchoLeak 漏洞（CVE-2025-32711，CVSS 9.3）可在使用者無操作下把內部文件送出 | 立即（15 分內） | 事故指揮官＋on-call＋主管 |
| SEV2 | 重大功能異常或法律風險 | 幻覺造成錯誤承諾：加拿大航空客服機器人亂答喪親票規則，遭卑詩省民事調解仲裁庭判賠並須負責 | 1 小時內 | on-call 工程師 |
| SEV3 | 局部或可容忍 | 成本異常爬升、非關鍵路徑逾時、部分回覆品質下降 | 當日處理 | 值班人員 |
| SEV4 | 輕微或僅需觀察 | 偶發格式錯誤、單次工具呼叫失敗 | 排入待辦 | 一般排程 |
分級最大的好處，是把判斷從個人英雄主義抽離：新進工程師照著表就能判斷該不該叫主管，不必苦等最資深的人到場。分級也直接決定要不要復盤——SEV1／SEV2 一律寫 Postmortem，SEV3 以下視情況。這套標準務必事前寫進 Runbook 並取得全隊共識，避免在壓力最大的當下還在爭論「這到底算第幾級」。
別漏掉 AI 特有的事故來源
傳統 Runbook 多半只涵蓋「服務掛了」，但 AI 系統的事故來源正在擴大，這些新型態風險都該納入情境清單：
- 幻覺與錯誤承諾：模型自信地給出錯誤資訊。加航案（Moffatt v. Air Canada）確立企業要為聊天機器人的說法負法律責任。
- 提示注入與資料外洩：EchoLeak 是第一個在生產級企業 AI 上被證實可行的零點擊資料外洩漏洞，攻擊藏在一封普通郵件裡，繞過了微軟自家的注入偵測；微軟已於 2025 年 6 月完成修補，未發現實際被利用的案例。
- 工具鏈供應鏈風險：2026 年 OX Security 揭露 MCP 生態的系統性漏洞，估計影響約 20 萬個實例；被污染的工具描述不必被呼叫就能污染整個 context。
- 成本暴衝：Uber 的 AI 編碼工具年度預算四個月就燒光；也有工程師同時運行上百個 AI 代理，30 天內燒掉約 130 萬美元 API 費用，其中「快速模式」設定就占了約七成。成本失控往往源於預設值，不是模型本身。
應變流程與角色分工
事故現場最怕一群人同時動手卻沒人統籌。建議建立單一「事故指揮官（Incident Commander）」制度：指揮官不一定親自動手修，而是負責決策、分派任務與對外溝通，讓責任在流程上就清楚。標準流程如下：
- 偵測與告警：以監控指標（錯誤率、延遲、Token 成本、幻覺偵測分數）自動觸發，而不是等客戶投訴。
- 定級與召集：依 SEV 表判定等級，透過 on-call 排班叫人，SEV1／SEV2 立即開設戰情室。
- 止血優先：先切到安全模式（改人工審核、退回舊版、暫停自動執行、設 Token 上限）控制影響，再從容追根因。
- 溝通同步：以固定頻率向受影響方更新，內外訊息一律由指揮官統一發布。
- 復原與確認：服務恢復後持續觀察，指標回穩才正式宣告結案。
用復盤（Postmortem）讓事故不再重演
復原只是止血，真正的價值在復盤。Google SRE 團隊的長年經驗指出，避免事故重演最有效的工具，就是公開、無咎化的 Postmortem。採「無咎化（blameless）」原則，聚焦流程與系統缺口而非究責個人，工程師才願意誠實還原真相。一份有用的 Postmortem 至少要包含：
- 事故時間軸：從偵測、定級、止血到復原的關鍵節點與決策。
- 影響範圍：受影響使用者數、持續時長、資料與成本損失。
- 根因分析：拆成技術面（模型、資料、工具鏈整合）與流程面（監控盲點、告警缺失）。
- 行動項：每一條都有負責人與期限，並追蹤到關閉，避免淪為紙上檢討。
值得注意的是，AI 事故的根因常橫跨技術與流程兩端：模型面的幻覺或注入，往往是被監控盲點與缺失的告警規則放大成災。復盤的產出因此不該只是一份報告，而是要轉化為新的監控指標、告警門檻與情境劇本，餵回下一版 Runbook。
把 Runbook 練成團隊的肌肉記憶
Runbook 寫完卻不演練，等於沒有。建議每季安排一次 game day，模擬 SEV1／SEV2 情境，驗證告警是否會響、on-call 是否找得到人、止血步驟是否真的有效。演練後把卡關的環節補回 Runbook，讓文件跟著系統一起演進。也建議把常見事故的處置步驟寫成可直接執行的檢查清單，並在告警訊息裡附上對應 Runbook 連結，讓值班人員不必半夜翻文件、憑記憶救火。當事故應變從「臨場救火」變成「照表操課」，團隊的復原速度就不再繫於某個人是否在線上，AI 系統也才算真正具備上線後的維運韌性。
恩梯科技如何協助你建立 AI 事故應變能力
恩梯科技（Nerdtechnic）長期協助台灣企業導入與維運 AI 系統。我們不只把 AI Agent 送上線，更會一起把監控告警、SEV 分級、on-call 排班與復盤機制建立起來，讓 AI 服務具備可稽核、可復原的維運韌性。無論你正在評估 AI 導入、需要客製化系統開發，或想以 OpenClaw 打造自動化流程，我們都能提供從落地到維運的完整顧問服務，協助你把「出事怎麼辦」變成團隊的標準作業，而不是每次都從零開始。
參考資料
- Stanford HAI，《AI Index Report 2026 — Responsible AI》，2026。來源連結
- Gartner，《Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027》，2025。來源連結
- Cisco／Splunk，《The $600 Billion Wake-up Call: New Splunk Research Reveals Downtime is a Systemic Business Crisis》，2026。來源連結
- Uptime Institute，《Annual Outage Analysis 2026》，2026。來源連結
- Aim Labs 研究團隊，《EchoLeak: The First Real-World Zero-Click Prompt Injection Exploit in a Production LLM System》（arXiv:2509.10540），2025。來源連結
- McCarthy Tétrault，《Moffatt v. Air Canada: A Misrepresentation by an AI Chatbot》，2024。來源連結
- OX Security，《The Mother of All AI Supply Chains: Critical, Systemic Vulnerability at the Core of the MCP》，2026。來源連結
- TechCrunch，《Uber caps employee AI spending after blowing through budget in four months》，2026。來源連結
- The Next Web，《Peter Steinberger's 100 AI agents racked up $1.3 million in OpenAI tokens in 30 days building OpenClaw》，2026。來源連結
- Google SRE，《Site Reliability Engineering — Ch. 15: Postmortem Culture: Learning from Failure》，2016。來源連結
