觀塘一家物流集團有一個 AI Agent 負責發票核對，已經運行了四個月。上星期二，它批准了一筆 18 萬港元的重複付款。
營運總監提出最直接的問題：是哪一步出錯？沒有人答得出。推理過程消失了，剩下的只有一行日誌，寫著任務已成功完成。
這個缺口有一個名稱，叫做可觀測性（Observability）。在 2026 年，它是企業 AI 在試點階段運作良好、卻在正式上線後停滯的主要原因之一。
什麼是 AI Agent 可觀測性？
AI Agent 可觀測性是指在 Agent 的推理與執行路徑上，逐步擷取結構化遙測資料：由它接收的指令開始，經過每一次檢索、模型調用與工具操作，直至最終輸出。它讓你能夠重建 Agent 做了什麼、為什麼這樣做，以及付出了多少成本。
對決策者而言，關鍵區別在於日誌與追蹤紀錄之間。日誌記錄「發生了某件事」，追蹤紀錄則記錄「產生這件事的整棵決策樹」。
一次 Agent 運行並非一問一答。它是一連串分支：模型決定搜尋文件庫、閱讀三筆結果、調用內部 API、重新考慮、再調用第二個 API，然後寫出答案。每一步都是獨立環節，各自有輸入、輸出、延遲與成本。
可觀測性的意思是，上述每一步都被擷取成可以事後重播的關聯紀錄。
為什麼可觀測性在 2026 年變得關鍵？
因為 Agent 的部署速度已經超越了監督能力。企業把 Agent 推入實際營運的速度，遠快於建立檢視能力的速度。現有證據顯示，阻擋正式上線的並非模型質素，而是監督缺口。而香港監管機構在過去一年，正朝同一方向收緊要求。
根據麥肯錫《State of AI Trust in 2026》報告，62% 企業至少已在試用 Agent，23% 已進入規模化階段，但只有 30% 在 Agentic AI 治理上達到第三級或以上的成熟度。
同一份報告指出，接近三分之二受訪者把保安與風險列為擴展 Agentic AI 的首要障礙，排名甚至高於監管不確定性。
上線數據更為嚴峻。2026 年 7 月引述的 IDC 研究顯示，88% 的 AI Agent 概念驗證從未進入廣泛生產：每啟動 33 個試點，大約只有 4 個真正投入實際營運。
Gartner 2026 年 CIO 及科技主管調查則顯示，只有 17% 企業已全面部署 AI Agent，而超過 60% 預期兩年內做到。這代表一個相當龐大的群體，即將發現自己是否有能力審核已部署的系統。
可觀測性與 AI 評估、傳統監控有何分別？
三者在不同時間點回答不同問題。評估問的是「上線前這個 Agent 夠好嗎」；監控問的是「系統有沒有運作」；可觀測性問的是「這一次運行實際做了什麼」。企業可以同時擁有三者，卻依然處於盲區，因為每一項只覆蓋一個窗口。
傳統應用效能監控是為確定性的請求與回應路徑而設計，量度延遲、錯誤率與吞吐量。這些指標依然有用，但對診斷「答錯」幾乎沒有幫助，因為一個錯誤答案通常在正常時間內回傳 HTTP 200。
評估屬於上線前及定期進行的紀律。若需要相關框架，UD 已另文處理：什麼是 AI Eval？
可觀測性屬於運行期的一層。它讓六星期後客戶、審計師或監管機構提問時，事件仍然可以被重建。
--- 監控回答：服務是否健康？
--- 評估回答：Agent 的準確度是否足以部署？
--- 可觀測性回答：這一次運行究竟發生了什麼，哪一步出錯？
一份 Agent 追蹤紀錄應該包含什麼？
可用的追蹤紀錄會擷取單次運行的完整環節樹，將每一次模型調用、檢索與工具操作記錄為獨立節點。缺乏逐步擷取，你就無法回答最基本的鑑證問題：哪一步產生了錯誤輸出。這正是評估任何供應商說法時應套用的實際測試。
認真的平台在紀錄元素上相當一致：
--- 輸入：使用者指令、系統指示，以及運行時注入的任何上下文
--- 每次檢索：搜尋了什麼、回傳了哪些文件、相關度分數為何
--- 每次模型調用：模型版本、參數、輸入輸出 Token 數量及成本
--- 每次工具調用：接觸了哪個系統、傳入什麼參數、回傳什麼結果
--- 決策節點：Agent 在何處選擇了某一分支而非另一分支
--- 身分：由哪個使用者、服務帳戶或 Agent 憑證授權此次運行
最後一項是企業買家最常在需求清單上遺漏的，卻是審計師最先追問的。
香港監管機構期望你能夠展示什麼？
香港並無單一 AI 法規，相關期望嵌入現有制度之中，而這些期望在 2026 年上半年明顯收緊。對受監管機構而言，實際要求是一條經得起審查的可解釋、可審計決策軌跡，而不是一份聲稱已有軌跡的政策文件。
香港金融管理局要求認可機構維持可解釋、可審計的 AI 決策軌跡，即系統須能展示每項決定背後所依據的數據，並以監管人員可以審視的形式呈現。
個人資料私隱專員公署則另外針對 Agentic AI 表態，指出 Agent 可能接觸本機裝置、檔案、電郵、憑證、瀏覽器內容及外部服務，並可能在無即時人為參與下執行多步任務。其建議包括最小存取權限、不授予管理員權限、隔離運行環境，以及對具重大個人影響的決定保留人為覆核。
兩者合起來的訊息相當清楚：若你的 Agent 接觸個人資料，而你無法重建它的行為，你並沒有合規立場，你只有一個假設。
UD 對控制面的另文處理見：如何治理 AI Agent。
如何在 90 天內建立可觀測性能力？
從一個 Agent 開始，而不是從採購平台開始。在香港中型企業行之有效的次序是：先為單一生產環境 Agent 做端到端埋點，證明能重播一次真實事故，然後才把同一模式向外擴展。在能夠重播一份追蹤紀錄之前就購買平台，通常只會產生一個無人信任的儀表板。
第 1 至 30 天：為一個 Agent 埋點
挑選財務或客戶風險最高的 Agent。為每一次運行擷取完整環節樹，包括逐步成本。追蹤紀錄保留期至少須覆蓋最長的審計週期。
第 31 至 60 天：驗證重播能力
取過去一個月的一次真實失敗個案，完全依靠追蹤紀錄重建它。若做不到，說明埋點不完整，而你以極低代價學到了這一點。
第 61 至 90 天：連結問責
為每個 Agent 指定負責人。界定哪些失敗類別觸發人為覆核。每月發佈一份報告，顯示運行量、按類別劃分的失敗率、每個成功結果的成本，以及未結事故。這份報告正是把遙測資料轉化為管理工具的關鍵。
企業省略可觀測性時會出什麼問題？
五種失效模式反覆出現，而五者都在 Agent 已被託付實際工作之後才浮現。每一種在埋點階段防範的成本都很低，一旦事故已進入覆核程序，修補代價就變得高昂。
--- 無聲的質素衰退。模型版本改變、檢索質素轉移，準確度連續數星期下滑而無人察覺，因為系統可用率仍然是 100%。
--- 無法重建的事故。企業知道 Agent 造成了損失，卻無法說明過程，於是技術問題升級為法律風險。
--- 成本漂移。沒有人把支出歸因到具體步驟，於是一個每次運行都默默重試五次的 Agent，看起來像整體預算超支，而不是一個可修正的錯誤。
--- 問責分散。IT 團隊說流程屬於業務部門，業務部門說系統屬於 IT，結果沒有人為輸出負責。
--- 治理表演。政策寫明 Agent 受到監督，卻沒有任何追蹤紀錄可以證明。這份政策會在第一次審計時失效。
下一步應該做什麼？
在下一次技術檢討會議上提出一個問題：指定上月某一次 Agent 運行，要求團隊向你展示它的追蹤紀錄。這個答案比任何成熟度評分更能說明你的上線準備程度。若紀錄存在，你屬於麥肯錫所描述的那 30%；若不存在，你已經知道第一個項目是什麼。
可觀測性是不起眼的工作。它不會帶來新功能，也無法在董事會投影片上展示成果。但它正是「一個你能夠辯護的 AI 計劃」與「一個你只能夠描述的 AI 計劃」之間的分野。
二十八年香港企業科技經驗告訴我們，能夠存活下來的系統，是那些操作者說得清楚的系統。懂AI的冷，更懂你的難。UD 同行28年，讓科技成為有溫度的陪伴。
由 UD 企業 AI 團隊審閱。
準備好部署真正可審計的 AI Agent？
知道追蹤紀錄應該包含什麼是一件事；把 Agent 部署在一個每項操作都被擷取、授權與可覆核的環境之中，是另一件事。UD 團隊手把手帶你完成每一步，由準備度評估、安全沙盒部署，到監控、成本歸因，以至董事會會追問的每月報告。28 年服務香港企業，全程陪你走。
