過去兩週，你的組織已經完全不一樣了。AI Agent 已經無處不在——有個 Agent 在自動彙整工作全貌（Day 26）、有個 Agent 在進行變更審查（Day 27），還有一個 Agent 在不知疲倦地回答新人的技術問題，把以前鎖在 Brent 大腦裡的隱性知識，變成了全團隊可即時檢索的寶貴資產（Day 25）。

DevOps Lead 在週會上興奮地報告：「我們現在有 7 個 Agent 在 Production 生產環境跑。」

Data Lead 接口：「我們那邊也還有 3 個在實驗中。」

AI Lead 補充：「加上 Knowledge Base 那個，我們現在應該有 10 個以上的 Agent 在線上運作了吧？」

你突然驚覺：此時此刻，組織裡活躍的 Agent 數量，已經悄悄超過了你直屬的團隊人數。

然而就在昨天，線上出事了。

那個負責自動審查變更的 AI Reviewer，在審查一個正常的安全性修復 PR 時，意外將其標記為「高風險」並自動退回。工程師申訴無門，在 Slack 上找不到任何人能「覆議」這個 AI 的決定，最後無奈之下選擇繞過流程強行 Merge——結果那個 PR 的 Migration 腳本真的與生產環境有衝突，直接導致線上服務降級了半小時。

在隨後召開的事故檢討會上，所有人都在追問同一個靈魂問題：

「這件事情，到底是誰的錯？」

是工程師違反規定繞過流程的錯？還是 AI 誤判後系統缺乏中斷機制的錯？亦或是最初設計這套自動化工作流的人的錯？

當 AI Agent 開始替團隊做實質決定時，誰該為它的最終結果負責？

場景：那些「Agent 做的決定」無人監管的災難

你打開過去一個月的問題清單，發現與 Agent 相關的事故已經累積了長長一串：

🚨 過去單月 AI Agent 相關事故診斷報告

1. AI Reviewer 誤判阻礙正常變更：
   • 過程：安全修復被誤標為「高風險」，且無申訴覆議機制。
   • 結果：工程師被迫繞過安全流程強行 Merge，最終導致線上服務降級半小時。
2. Knowledge Agent 輸出過時文檔：
   • 過程：提供已失效的舊部署指南。
   • 結果：新進同仁照著操作，導致整個 Staging 測試環境崩潰。
3. Work Tracking Agent 錯誤分類 Ticket：
   • 過程：將生產環境 P0 緊急 Bug 誤判為「低優先級」。
   • 結果：導致問題在 Backlog 裡滯留 3 天無人看管。
4. Auto-approval Agent 越權核准：
   • 過程：核准了一個超出安全合規（Policy）限制的敏感存取權限。
   • 結果：在例行性稽核中被亮紅燈，面臨「誰核准此變更」的究責。
5. Agent 品質在暗中退化：
   • 過程：因底層模型更新或漂移（Drift），某個 Agent 線上答對率暴跌，但無任何主動監控通報。

這五起事故都有一個共同點：當問題爆發時，沒有人知道 Agent 當時到底為什麼做出這個決定、誰又該出面為結果承擔責任。

Agent 既不是單純的工具，也不是有契約關係的員工——它正處於一個「沒有監管的灰色地帶」中替你做決策。

你把三個團隊的 Lead 找來開會。

「我們不能再這樣放任下去了，」你嚴肅地說。「Agent 已經在做實質工作，但我們對它的治理和監控幾乎是零。」

DevOps Lead 點頭同意：「沒錯，我們甚至連『這個 Agent 上週到底做了哪些線上決定』都沒有統一的紀錄可以查詢。」

AI Lead 坦承：「更糟的是，現在有些 Agent 是不同工程師私下各自部署的，根本沒有統一的標準。有的有 Log，有的沒有；有的有設安全邊界，有的完全是放飛自我。」

Platform Lead 補了一刀：「而且我們目前根本無從得知每個 Agent 『表現究竟好不好』——它的決策正確率是多少？是否存在偏差？完全是一個黑箱。」

你突然懂了……

既然你絕不會允許一個沒有監督、沒有 KPI 考評、沒有人為審核的新人去隨意觸碰 Production 系統，那你憑什麼對 Agent 放任不管？

你現在需要的，不是建置更多的 Agent，而是一套「管理 AI Agent 的營運學問（AgentOps）」。

兩難：視為免費工具？還是納入正規管理的團隊成員？

你在會議室白板上寫下了兩條截然不同的治理路徑：

如果是你，此時此刻會做出什麼樣的抉擇？

翻牌：AgentOps——將三步工作法應用於 AI 本身

正確答案是 選項 B。

這聽起來有些不可思議，對吧？給 AI 設定 KPI？把 AI 「當成員工來管理」？

但請深思——如果一個 Agent 做出的決定，會實質影響你的線上系統、你的客戶體驗、乃至於你的財務合規性，你憑什麼不將它納入嚴格的工程治理中？

這就是 AgentOps 的核心：管理 AI Agent 的營運科學。

它絕不是擬人化的文字遊戲，而是把《鳳凰專案》的三步工作法（Three Ways），精準落實到「AI 作為團隊一員」的新時代前沿：

• 🔗 第一航道（Flow，流動）：
  • 將 Agent 的運作流納入整體的端到端價值流（Value Stream）。明確它處於哪個價值交付階段？它的輸出來自哪裡？產出又將流向何方？
• 🩹 第二航道（Feedback，回饋）：
  • Agent 做出的所有關鍵決策必須具備高可觀測性與可追溯性。系統出錯時必須能隨時回滾，並內建人為干預（Human-in-the-Loop）審查機制。
• 🧠 第三航道（Continuous Learning，持續學習）：
  • Agent 的線上表現與品質必須是可量化、可衡量的。每天分析其決策準確率與誤報率，確保 Agent 本身能不斷更新、自我迭代。

AgentOps 的五大治理支柱：

1. 可觀測性（Observability）── 它做了什麼決定？為什麼？

每個 Agent 的線上決策過程必須被完整記錄，包含：

• 輸入上下文：用戶問題、當時的系統環境狀態。
• 推理過程：它調用了哪些知識庫文件、呼叫了哪些外部工具、推理鏈（Chain of Thought）為何。
• 信心分數（Confidence Score）：它對此決策的自我評估把握度。

2. 安全護欄（Guardrails）── 它絕對不能做什麼？

明確限制 Agent 的寫入權限與執行邊界：

• 嚴禁直接變更生產資料庫、嚴禁越過 CI/CD 直接部署。
• 當 Agent 的決策信心分數低於閾值時，必須自動降級並升級呈報給真人。

3. 效能評估（Evaluation）── 它的工作品質如何衡量？

設計專屬的量化 KPI：

• 決策準確率：Knowledge Agent 回答的正確率。
• 誤報率 / 漏報率：AI Reviewer 標錯安全風險的比例。
• 人工採納率：人為審核時，同意並採用 Agent 提案的比例。

4. 人為審核（Human-in-the-Loop）── 關鍵決策必須由人把關

在高風險或模糊邊界，建立人機協作機制：

• 權限申請、生產部署等高風險動作，Agent 僅能「生成提案」，必須由真人進行最終確認。
• 內建一鍵申訴機制，供工程師對 AI 的判斷提出申訴，自動指派資深工程師覆審。

5. 版本控制與安全回滾（Versioning & Rollback）

• 每套 Agent 及其引用的知識庫（RAG）都必須標註語意版本。
• 當發現新版 Agent 出現幻覺或準確率下降時，能像代碼一樣在 5 秒內一鍵回滾到上一個穩定版本。

如果有完整的 AgentOps：從「不敢用」到「放心上線」

我們來看看同一個 AI Reviewer Agent，在導入 AgentOps 治理框架後的健康工作流：

graph TD
    A[工程師提交 PR] --> B{AI Reviewer 審查}
    B --> C[記錄決策:<br/>檢查了哪些 policy,<br/>信心分數 87%]
    B --> D{風險等級?}
    D -->|低風險<br/>信心 > 90%| E[自動批准<br/>+ 記錄到 audit log]
    D -->|中風險<br/>信心 70-90%| F[標註疑慮<br/>+ 人工複審]
    D -->|高風險<br/>或信心 < 70%| G[退回/必須人工審查<br/>+ 附 Agent 分析報告]
    G --> H[人工決定:<br/>批准/退回/修改]
    H --> I[記錄人工複審結果]
    E --> J[每週評估:<br/>自動批准的 PR 中,<br/>事後發現問題的比例]
    J --> K{準確率 < 95%?}
    K -->|是| L[調整 policy<br/>/ 降低自動批准門檻]
    K -->|否| M[維持現狀或放寬]

這就是 AgentOps 帶來的實戰改變：

• 可觀測：每個決策都有跡可循，事後稽核能輕易追查「AI 為什麼在週五做此判定」。
• 設護欄：高風險事件強制升級給真人把關，不會放任 AI 自主妄為。
• 可回滾：若模型更新後表現退化，能在第一時間退回上一版本。

現場推演：被納入 AgentOps 治理的知識庫 Agent

我們來看一個業界真實發生的團隊轉型場景：

想像一個 25 人的工程團隊，建置了一套技術問答 Knowledge Agent，串接了團隊內部的 Wiki 說明、代碼庫與歷史 Jira Ticket。上線初期大家覺得很新鮮，但很快便因為 Agent 偶爾會給出過時甚至錯誤的指令，導致團隊對其失去信任。

團隊決定為這套 RAG 系統全面引入 AgentOps 框架：

• 步驟 1：可觀測性
  • 每個回答都自動附帶「引用了哪幾篇 Wiki」與「信心指數」，並提供 👍 / 👎 反饋按鈕。
• 步驟 2：安全護欄
  • 偵測到「刪除資料庫」、「重置權限」等高危敏感詞時，Agent 強制拒絕直接提供步驟，而是拋出安全警語並轉接真人窗口。
• 步驟 3：效能評估
  • 每週自動統計「用戶反饋 useful 比例」與「人工隨機抽樣準確率」，設定 KPI 必須維持在 85% 以上。
• 步驟 4：人為審核
  • 使用者點擊 👎 的回答會自動進入「優化 Queue」，每週由 Tech Lead 集中審查，修復過時的 Wiki 文件。
• 步驟 5：版本與回滾
  • 知識庫的索引每天進行版控。一旦發現新匯入的文檔導致回答準確率大幅下降，立刻回退至昨天的索引版本。

兩個月後，團隊迎來了改變：

• Agent 回答的客觀準確率提升至可量化的 89%。
• 用戶對 Agent 的信任滿意度由 62 分提升至 84 分。
• 再未發生過因為「聽信 AI 給出的過時指令」而導致環境崩潰的事故。

這就是 AgentOps 的底層價值：它成功地將 AI 從一個「隨時會失控的玩具」，轉化為了「敢放心交託任務的可靠隊友」。

今日金句

「你既然絕不會允許一個沒有監督、沒有績效考核的員工碰 Production 系統，那對 AI Agent 也應該一視同仁。」

留給你的問題

在你們團隊目前使用的 AI 工具或 Agent 中，有人能說得清楚它昨天在線上替你們做了哪些具體決策嗎？

如果答案是「完全沒有人知道」，那你們現在其實是將系統的命運，蒙眼交託給了一個隨時可能暴走的黑箱。

明天，我們要面對這 30 天挑戰中，最核心也最需要勇氣的終極難題：技術工具更新了、流程自動化了、Agent 也納入管理了——但如果組織架構本身是錯置的，系統最終還是會長回那個混亂的模樣。

你敢不敢重串整個組織的邊界，而不僅僅是修補代碼系統？

Day 29 見。