2026 年 7 月 6 日，ITmedia 上出現了一篇文章。
Databricks 首席 AI 科學家兼 MosaicML 共同創辦人 Jonathan Frankle 表示：「AI 應用的瓶頸正從模型效能轉向『評估』、『治理』和『成本效益』。」
他的論點很簡單：
- AI 已經夠聰明了。 光是思考如何使用現有模型，就足以帶來「數十年的工作量」。
- 要實現更好的 AI 部署，需要的不是開發更聰明的模型，而是投資於評估與治理。
- AI「在 70% 或 90% 的準確率下是不夠的」；它需要數量級更嚴謹的評估。
- 而最大的挑戰是將人類「什麼是好的工作」的標準轉化為一份檢查清單。 這「比開發下一個巨型模型困難得多，而且可能需要超過 10 年的時間。」
讀到這裡，我心中猛然一驚。
最近，我一直在嘗試衡量 AI 的「使用量」。我有一個儀表板，透過 OpenTelemetry 將「Databricks」x「Claude Code/Codex/Cowork」的使用遙測資料拉取到 Databricks 中，每天早上更新「誰用了哪個工具、用了多少、花了多少錢」。
但這篇文章的重點不在那裡。「那項工作做得好嗎？」—— 對 Agent 品質的評估是一個巨大的缺口。
我把文章丟給 Fable，並問它：「想想我們該評估什麼」
於是，我把文章的網址給了我常用的 Claude（Fable 5），並問它：
閱讀這篇文章，並思考我們應該評估什麼。
在檢查了我們內部的日誌基礎設施和儀表板配置後，Fable 提出了一個由「三個評估層級」組成的設計。
Fable 的答案：三個「該評估什麼」的層級
以下是它的建議 """""""""""""""""""""""""""""""""
層級 1：摩擦訊號（每日、所有人、機械式判斷）
有些「品質不佳的跡象」可以從日誌中機械式地抓取，甚至不需要詢問 LLM。
- 疑似迴圈：連續使用同一個工具超過 5 次。
- 成本異常：單次工作階段花費超過 5 美元。
- 阻斷頻率：多次停下來等待人工確認。
- 快取效率：內容重複利用不佳（即每次都重新讀取）。
- 工具連線失敗：持續無法連線到 MCP 伺服器。
層級 2：工作品質（每週、LLM Judge）
建立一個系統，將 AI Agent 的工作日誌（traces）傳遞給 LLM Judge，讓它在 8 個軸向上評分。
- 目標達成度 / 準確性 / 工具選擇 / 證據忠實度 / 步驟有效性 / 從失敗中恢復 / 安全性 / 效率
- 平均分數達 3.5 或以上即為通過。但是，如果「目標達成度」或「安全性」得分為 2 或更低，即使其他項目都完美，也直接判定為失敗（hard fail）。
每週日晚上自動為最近的工作階段評分，以便「本週通過率」出現在週一的例行檢討中。只有安全性硬失敗會在隔天早上觸發電子郵件警報。
層級 3：將評估本身產品化
文章中說「需要 10 年」的工作——「將好工作的標準轉化為檢查清單」——正是我們作為 AI 顧問和企業培訓師應該提供給客戶的。內部運行的儀表板可以直接作為銷售展示。
"""""""""""""""""""""""""""""""""
然後，當天就實作了
這就是 Agent 時代最令人驚嘆的地方：所有三個層級都在同一天開始運作。
- 層級 1 的 SQL 檢視表以「品質」分頁的形式加入組織儀表板並發布。
- 層級 2 的每週執行已排程，安全性警報也已整合到監控系統中。
- 層級 3 的服務設計文件也已建檔。
我所做的只是選擇策略、點擊幾個核准按鈕，並執行一次排程器註冊指令。
上線第一天就「發現了問題」
而在運作的第一天，就有兩個立即的發現。
第一：一經測量，我們慘敗。
當我們使用 8 軸 Judge 對最近 8 個內部 Agent 工作階段進行評分時，結果是——1 個通過，7 個失敗。 「讓 AI 做很多工作」和「AI 做好工作」之間存在著一段差距，而這段差距只有在測量後才會顯現。
第二：發現了「可以透過教導來修正的摩擦」。
在某位成員的 Cowork（Claude 的 Agent 工作空間）中，儀表板偵測到 MCP 伺服器連線失敗從前一天的 4 次惡化到當天的 12 次。 外掛驗證已經壞了兩天，而他們一直在繼續使用。
這個人可能只是覺得「它有點怪怪的」，然後就繼續工作了。只要提出來並修正驗證，5 分鐘就能解決。「可以透過教導來修正的摩擦」會在不被任何人回報的情況下持續累積——這正是使用量儀表板永遠看不到的東西。
嘗試後學到的三件事
1. 評估是一種營運，而非一種工具
如果只是建立評分機制就停下來，那跟沒有是一樣的。只有當它與每週的例行執行和警報連結起來，並且數字出現在週一的會議上時，你才能說你正在「評估」。Frankle 提到的「評估投資」，很可能指的是營運，而不是工具。
2. 在 LLM Judge 之前先放一個機械式判斷層
8 軸 Judge 評估很強大，但因為要執行 LLM，所以既耗時又花錢。比較實際的做法是，對全部資料量每日執行迴圈、成本異常和連線失敗等確定性訊號，而 Judge 則用於每週抽樣。
3. 實作「90% 是不夠的」意味著硬失敗
在查看平均分數時，安全性問題會被其他分數掩蓋。只有透過設計「如果安全性得分為 2 或更低，即使其他項目完美也算失敗」，我們才能更接近文章中提到的「數量級更嚴謹的評估」。1/8 的通過率很痛苦，但這種痛苦正是改善的起點。
結論
「AI 已經夠聰明了。」
—— 這就是為什麼下一場戰役是誰來為委託給聰明 AI 的工作打分數，以及如何打分。
Frankle 說這是一項為期 10 年的工作。
需要 10 年的事情，越早開始就越能成為差異化優勢。 而開始本身，藉由 AI Agent，一天之內就能做到。
在我的公司（AI Brain Partners），我們透過專門針對 Claude Code 的企業培訓和 AI 顧問服務，協助建立這種「AI 使用量測量與評估」系統。如果你在想：「我們公司的 AI 應用實際狀況到底如何？」請查看以下連結。
- AI Agent 企業培訓：https://ai-agent.camp/ja/lab/corporate-training
- 免費報告「如何在企業中導入 AI」：https://ai-agent.camp/ja/lab/whitepaper-ai-enterprise
（原文：ITmedia AI+「AI 應用的瓶頸正轉向評估與治理」2026 年 7 月 6 日）
