供應商無預警推出破壞性變更。翌日早上，你桌上有甚麼？

GembaOS 是企業 AI Agent 的治理執行平台：以政策判定權限、以綁定參數的單次放行令授權每一個動作、以可追責的簽署鏈記錄人的審批，部署於企業本地機房或私有 VPC。

這篇文章講的是一種常見但代價極高的隱性事故：外部供應商半夜升級了 API，沒有人讀過更新日誌，而你系統裡的某項關鍵防線，從星期二凌晨起就已經靜默失效。

致命的故障，往往偽裝成風平浪靜

星期二凌晨，CRM 供應商悄悄停止在 API 回應中返回 IsEscalated（是否已升級）這個布林值欄位。

此時你的後端代碼通常不會報錯崩潰。在大部分程式語言中，讀不到缺失欄位會自動套用預設值——布林值變成了 false。

結果是：所有被客戶標記為嚴重投訴、本應緊急升級的個案，在系統看來全都變成了「未升級的普通個案」。系統沒有拋出任何 500 錯誤，沒有任何監控報警被觸發，大家睡得安穩，但在業務層面，關鍵的安全閥門已經形同虛設。

這就是最昂貴的故障：系統沒有崩潰，它只是靜靜地在所有判斷中給出錯誤的結論。

不看宣傳文件，直接探測真實 API

等待供應商主動通知往往為時已晚。GembaOS 的解決方案很簡單：每天半夜主動向供應商沙盒「查體」一次。

在 GembaOS 中，每一個外部能力（Capability Pack）都預先宣告了它所依賴的數據形狀：欄位名稱、類型、可取枚舉值、是否允許為 null。

排程檢查每晚使用預設樣本呼叫供應商沙盒，把返回的真實數據與宣告契約逐行比對。如果供應商停用了一個欄位，系統當晚就會捕捉到「API 漂移」（Drift）：

Contract check: crm   2026-09-23T12:13:59+09:00

CHECKED (1): get_case

DRIFT (5)
  FIELD_ABSENT       get_case.IsEscalated    declared boolean, not in the answer
  FIELD_UNDECLARED   get_case.riskScore      the answer carries a field the pack does not
                                             declare (number): a quiet addition

系統能精確識別七種漂移，包括任何文件都寫不清楚的隱形破壞：欄位名稱沒變但類型變了、返回值超出了既定枚舉、宣告不為空的欄位返回了 null。如果供應商在 HTTP 標頭中標註了 Sunset（即將廢棄日期），系統也會即時記入審計記錄。

算清業務影響，而不是發送一條無效告警

發現 API 變了之後，很多監控工具只會發一封「API Changed」的郵件，然後被淹沒在郵箱裡。

GembaOS 不會只報警。它會立即檢索內部所有已定義的業務流程（Playbook）與審批條件，計算出這項變動的業務影響面：

1. 哪些業務的前置校驗引用了這個消失的欄位？
2. 哪些自動化決策會因為它而失去防護？
3. 按嚴重程度自動分類：
   • BREAKING（嚴重破壞）：核心比對欄位消失或類型變更，導致業務規則靜默失效 $\rightarrow$ 由 API 負責人與安全審查雙人簽批；
   • DEGRADED（降級運行）：欄位新增枚舉或出現非預期 null，仍能運行但存在潛在風險 $\rightarrow$ 由 API 負責人與平台主管簽批；
   • COSMETIC（無害變更）：供應商新增了欄位，但內部沒有任何業務依賴它 $\rightarrow$ 由 API 負責人單人簽字確認。

沒有任何變更可以「自動放行」。凡是外部引入的破壞性變更，系統都強制要求人類負責人知情並蓋章。

審批確認風險，工程師接手修復

第二天早上，負責人桌上出現的不是一堆報警日誌，而是一張清晰的業務影響單：

• 供應商改了甚麼？
• 影響了哪幾個具體業務？
• 調查 Agent 整理好的影響摘要與風險建議。

負責人打開的就是這樣一張單（本文最後介紹的示範實際跑出來的畫面）：要點裏每個數字旁都有主機的核對結果，兩個簽名都還未簽。

負責人審批確認後，表示「企業正式受理這項變更，知曉相關風險」。此時，系統自動為研發部門建立修復工單，並指派給具名工程師。

在審查自己的時間線上，開立修復工單是最後一行，排在兩個簽名和重讀之後。在工單那邊，請求文字是主機組出來的，筆在工程師手上。

AI 負責寫補丁，人類負責點擊 Merge

修復代碼的過程充分發揮 AI 的效率，同時守住權限底線：

1. AI 在沙盒中作業：工程師的編碼 Agent 在隔離沙盒中讀取服務倉庫代碼，修改代碼邏輯（例如不再把缺失欄位當成 false，改走新的替代 API），並運行單元測試與 CI。
2. Pull Request 由主機開，不是 AI：Agent 的工作止於提出變更集。CI 通過、代碼負責人簽署之後，主機把已簽署的那份補丁原樣推送到代碼託管平台，開啟 Pull Request，說明中附上工單編號與核對之處。代碼託管平台的憑證不在 Agent 手上，只放在企業自己網絡內運行的 worker 裏。
3. 人類最終合併（Merge）：AI 絕對沒有合併代碼到主分支的權限。必須由真實的工程師在 GitHub/GitLab 審閱代碼，並以自己的帳號點擊 Merge。

示範環境沒有接上代碼託管平台，所以最後一關就是這張審批單。stub Agent 提出的變更集只有兩個檔案：欄位不存在時讀取函數回傳錯誤，再加一個測試說明這一點。這個檔案讀的是供應商的答覆，所以要等代碼負責人簽署，主機才會把它落地到租戶自己的倉庫。

從供應商半夜改 API，到早上生成影響單、雙人審批受理、AI 提出代碼補丁、工程師親手合併，整條鏈路一清二楚：

• AI 負責主動探測、計算影響、起草修復；
• 人類負責確認風險、承擔責任、最終上線。

沒有任何一行代碼是 AI 偷偷改動並上線的，也沒有任何一項外部變更是無人認領的。

---

技術細節與邊界保證（供架構師參考）

• 候選配置隔離（Candidate Pack）：探測到的新 API 形狀在未獲批准前，僅作為候選配置暫存，絕不影響生產運行。
• 執行前二次校驗（Preflight Check）：若在審批期間供應商 API 再次發生變化，已簽署的影響表雜湊將與現狀不符，系統自動退回審批，防止依據陳舊資訊放行。
• Prompt Injection 防護：供應商公開文件與變更說明僅作為非受信數據（DATA）保存，不會直接作為指令注入給 Agent，防止外部文字操縱系統策略。
• 體驗示範：可透過 gemba demo vendor --drift 指令模擬供應商 API 漂移，並觀察從探測到生成影響單的完整治理過程。