AI 代理上線之後，誰在看著它？可觀測性、評測與控制平面的三層儀表板
台灣企業今年開始把 AI 代理推上生產環境，然後撞上同一個問題：出事了不知道怎麼回溯。這篇拆解 2026 年成形的三層工具——追蹤、評測、執行期治理，並說明什麼規模該裝哪一層。
早上九點，台北一家電商的技術主管打開 Slack，看到客服部門昨晚傳的訊息：有客戶說 AI 客服答應給他退全額運費，但公司政策明明是折抵一半。他想調紀錄，然後發現一件很尷尬的事——他們只存了對話的最後回覆，中間代理呼叫了哪些工具、看到什麼資料、為什麼做出那個判斷，全部沒有留。
這不是一家公司的問題。2026 年上半年，台灣有一批企業把 AI 代理從 POC 推上正式環境，然後集體撞上同一堵牆：代理會做決定了，但沒人看得見它怎麼決定的。
事件背景
過去兩年，AI 應用的形態變了。2024 年大家做的是聊天機器人，輸入一句、輸出一句，錯了就重問一次，成本是使用者多打幾個字。2026 年大家做的是代理：它會呼叫 API、會寫入資料庫、會寄信給客戶、會花錢買服務。
錯誤的代價因此完全不同。聊天機器人答錯是尷尬，代理做錯是損失。
工具市場也跟著分化。Product Hunt 在 2026 年 8 月一週之內就出現三個相關產品——Traccia 做代理控制平面、Lenz 做獨立事實查核 API、bitdrift 做行動端的即時可觀測性。這不是巧合，是同一個需求在不同角落浮出來。
本次重點：三層儀表板
觀察這一批工具，可以整理出三個層次。它們解決的問題不同，該裝的時機也不同。
第一層：追蹤（Tracing）
記錄代理執行的每一步——收到什麼輸入、做了什麼推理、呼叫哪些工具、拿到什麼結果、重試了幾次、最後輸出什麼。
這一層的關鍵字是「完整」。只記最後結果沒有用，因為代理的問題八成出在中間。Traccia 的 SDK 建在 OpenTelemetry 之上，就是為了讓這些資料能接進團隊既有的可觀測性系統，而不是又多一個孤島。
第二層：評測（Evaluation）
有一組固定的測試資料與評分器，每次改動之後跑一遍，得到可比較的分數。
這一層解決的是「我改了 prompt，到底變好還是變壞」。沒有評測的團隊，改 prompt 全憑感覺，改到第五版時已經沒人記得第二版其實比較好。
第三層：執行期治理（Runtime Governance）
在代理動作的當下就攔截：禁止呼叫某些外部服務、超過成本上限中止、輸出必須通過檢查才放行、高風險動作需要人工審批。
這一層跟前兩層的差別是「事前」與「事後」。追蹤與評測都是回頭看，治理是當下擋。碰錢、碰客戶資料的代理，這一層不能省。
市場影響分析
對台灣使用者
一般使用者不會直接接觸這些工具，但會感受到差別。有治理層的 AI 客服，不會隨口答應公司做不到的事；沒有的，你就會看到新聞上那些「AI 客服答應退款結果公司不認帳」的糾紛。
台灣消費者可以留意一個訊號：當企業的 AI 服務出錯時，它多快能給你一個具體的解釋。答得出「我們查到系統在某個步驟判斷錯誤」的，代表後台有留紀錄；只會說「這是系統問題」的，多半什麼都沒存。
對企業應用
台灣企業導入這三層的順序，我認為應該是這樣：
追蹤先行，而且現在就做。 這一層的成本最低——最陽春的做法是把每次代理執行的完整脈絡寫進一張資料表，連工具都不用買。真正貴的是出事那天沒有紀錄。
評測在第三個代理上線前建立。 一兩個代理靠人工抽查還撐得住，三個以上就不可能了。而且評測資料集要從真實失敗案例長出來，這需要時間累積，太晚開始就來不及。
治理在碰錢或碰個資時導入。 如果你的代理只是幫忙整理內部文件，治理層是過度投資；如果它會發訊息給客戶、會操作訂單、會存取個資，那就是必要成本。
成本方面要有心理準備：完整追蹤會產生可觀的資料量，儲存與查詢都要錢。實務上多數團隊會採分層策略——正常執行只留摘要，異常執行留完整脈絡。
還有一件台灣企業特別要注意的：追蹤資料裡通常含有個資。客戶的問題內容、訂單資訊、聯絡方式都會被完整記下來。保留期限、存放區域、去識別化的策略要在導入時就規劃好，不是事後補。
對開發者
工具選型上有兩個判斷點。
第一是「綁不綁廠商」。如果你今天用 OpenAI、明年可能換 Anthropic 或開源模型，選廠商中立的工具比較安全。Traccia 主打的 vendor-neutral 就是這個賣點，代價是它 2026 年才推出，成熟度不及 Langfuse、LangSmith 這些先行者。
第二是「開不開源」。SDK 開源代表你導入前可以先看它到底收了哪些欄位、送到哪裡去。這對資安審查嚴格的產業（金融、醫療）往往是能不能過關的關鍵。
另外一個值得注意的分支是輸出驗證。Lenz 這類獨立事實查核 API 的思路很有意思——它不是讓同一個模型檢查自己，而是用競爭廠商的模型交叉辯論。這解決了自我檢查的根本盲點：模型看不出自己的錯，因為那個錯是它的認知本身。
未來發展趨勢
我認為接下來一年會發生三件事。
追蹤會變成標配，而不是加購。 就像 2015 年之後沒有人會問「要不要裝 APM」一樣，代理框架本身會內建追蹤，工具廠商的競爭會轉到分析與治理層。
評測會從「跑分數」走向「跑真實案例」。 現在很多評測工具的預設題庫是通用的、學術的，實務上沒有意義。真正有用的是你自己那 50 筆客訴案例。工具會往「幫你把失敗案例自動變成測試集」的方向走。
治理會被法規推著走。 歐盟 AI 法的執法權在 2026 年 8 月正式啟動，其他地區的規範也在跟進。當「你必須能解釋 AI 為什麼這樣做」變成法律要求時，控制平面就從加分項變成合規基礎建設。台灣的金管會與個資主管機關遲早會有相應要求，現在做的準備不會白費。
TheAI學院 總結與評語
我對這個題目的態度很直接：追蹤是義務，治理是選擇。
那家電商的技術主管後來怎麼處理？他花了兩天寫一段程式，把每次代理執行的完整脈絡寫進 PostgreSQL，包含使用者輸入、每次工具呼叫的參數與回傳、模型的中間推理、最後輸出。沒有買任何工具，成本是兩天的工時。
一個月後又出了一次類似的爭議，這次他十分鐘就查到根因：代理讀到的政策文件是三個月前的舊版本。問題解決了，而且他知道要修的是文件同步，不是模型。
這就是我想講的重點——你不需要一開始就買最完整的方案，但你必須從第一天就開始存資料。太多團隊在評估工具的三個月裡什麼都沒裝，然後在第四個月出事時發現手上空空如也。
評語：先把 log 存起來，再談要買哪套工具。與其完美地什麼都沒做，不如粗糙地開始留下證據。
給台灣讀者的具體建議：如果你的公司今年有代理要上線，這週就做一件事——確認每次執行的完整脈絡有被存下來，而且你知道去哪裡查。這件事不需要預算、不需要開會，一個下午就能做完。等到需要它的時候再做，就來不及了。
想更完整了解代理的建置流程，可以看 AI Agent 建置指南；關於 LLM 應用的安全面向，LLM 應用安全清單 有更細的檢查項目。想找可以用的工具，工具頁 的開發框架與基建分類都整理好了。
資料來源
依公開資訊整理，產品功能與定價以官方公告為準。
常見問題
小團隊只有一個代理，需要裝這些嗎？
追蹤那一層需要，評測與治理可以等。最低限度是把每次代理執行的輸入、工具呼叫、輸出存下來，用資料庫或雲端日誌都行。這件事不做，出事那天你什麼線索都沒有。評測與控制平面通常在代理數量超過三個、或開始碰客戶資料時才划算。
為什麼不能只靠 LLM 供應商的後台？
供應商後台只看得到「呼叫模型」這一層，看不到你的代理在呼叫模型之前做了什麼決策、之後又觸發了哪些工具。代理的問題八成出在編排邏輯而不是模型回應，只看模型日誌等於只看到冰山一角。
追蹤資料要存多久？
看你的產業。一般 SaaS 產品 30 到 90 天足以應付大部分除錯需求；受監理的金融、醫療則要依主管機關要求，可能是數年。要注意追蹤資料裡常含個資，保留期限與去識別化策略要一起規劃，不能無限期留著。
評測要怎麼開始才不會變成形式？
從一個真實的失敗案例開始。把上週那個代理答錯的實際輸入存下來，加上正確答案，就是你的第一筆測試資料。累積 20 到 50 筆之後，每次改 prompt 或換模型就跑一次。從真實失敗長出來的測試集，比一開始就設計 500 題有用得多。