AI 使用量起來之後，治理問題緊跟著到：誰在用、用在什麼任務、哪筆錢能報帳、哪些輸出會送到監管機關眼前。這些問題的答案本來就藏在每筆 generation 裡，只是缺一個結構化的形式把它說出來。OpenRouter 在 7 月 24 日釋出 beta 版的 Classifiers，把分類這件事搬進平台：每筆 generation 自動貼上你定義的標籤、寫進 logs，成為可過濾、可彙總的 metadata，AI 使用回報從此有結構化資料可用。
本文拆解它的機制、template 選擇、從 logs 到 Activity Explorer 的分析路徑，以及用 sampling rate 控制成本的方法——包括官方沒給數字的定價部分。
機制：四件套配置，非同步執行
一個 classifier 的設定只有四個部分：taxonomy、classification prompt、model、sampling rate。taxonomy 最多八個 dimension，每個 dimension 的值自訂；classification prompt 以 system message 的形式送給 classifier model；model 讀取 prompt 與該筆 generation 後輸出分類；sampling rate 決定多少比例的流量被分類。
執行位置是設計上的關鍵：分類在每個請求完成之後非同步執行，不在推論路徑上，所以不增加 latency。輸出被強制為結構化格式——模型不能自由發揮，只能在 taxonomy 定義的 dimensions 與 values 裡選。這個約束讓下游的一切成為可能：標籤是 schema 裡的值，不是自然語言的猜測。
官方推薦 Gemini 3.5 Flash Lite 作為 classifier model，理由是便宜且 structured output 準確度高（官方說法），而且 model 可以隨時更換。
六種 template：先抄再改
分類法設計不必從零開始，官方提供六種 preset template：Department、Audience、Task type、Engineering work、Agent complexity、Capitalizable software expense，各自對應不同的治理問題：
| Template | 標記什麼 | 治理問題 |
|---|---|---|
| Department | 請求來自哪個部門 | 各單位推論成本分攤 |
| Audience | 輸出對象：internal、client-facing、regulators、public | 合規流程分流 |
| Task type | 用途：coding、agentic work、資料處理 | 模型選擇是否得當 |
| Engineering work | 功能開發、除錯、文件、重構、code review | AI 輔助成效追蹤 |
| Agent complexity | 從 trivial tool calls 到 frontier-expert 的難度層級與 task family | 多層代理的成本結構 |
| Capitalizable software expense | 開發 vs 維護／營運／支援 | 會計上的可資本化判定 |
值得注意兩個 template 的深意。Audience 把「這段輸出會被誰看到」變成一級 metadata——送往 regulators 的輸出與 internal use 的輸出，合規義務完全不同，先標好再出事，比出事後回頭翻 logs 便宜。Capitalizable software expense 則直接對接會計問題：AI 輔助的工程投入哪些算開發（可資本化）、哪些算維護營運（費用化），在 AI 支出膨脹的年度，這是財報上真實存在的問題。
從 logs 到 Activity Explorer：標籤如何變成決策
分類寫入 logs 後，消費路徑有三層。第一層是過濾：每筆被分類的 generation 帶標籤，可以直接篩 department: legal 這類條件。第二層是逐筆檢視：generation detail panel 會列出該筆請求的所有分類 dimension 與 value。第三層才是重點——Activity Explorer 可按任意 classifier dimension 彙總流量，看各 model、各部門的 spend 分佈，而且 classifier filters 會跨 Activity 的各分頁（explore、trends、guardrails）沿用，同一組篩選可以一路追趨勢。
還有一個容易被忽略的驗證功能：可對任意過去的 generation 手動執行 classifier。設計新 taxonomy 時不必猜分類效果，直接拿歷史流量試跑，看標籤分佈是否符合直覺，再正式上線。這把 taxonomy 設計從一次性拍板，變成可以迭代的工程。
成本模型：sampling rate 是乘數
Classifiers 的成本結構，官方只給了形狀、沒給數字：成本等於 classifier model 的費用，乘上實際被分類的流量比例。公告並未列出具體定價，這點要誠實標明；但控制手段是明確的。
官方示範的模式值得直接抄：compliance classifier 對流量 100% 取樣——監管場景不容漏抓；cost-attribution classifier 對同一份流量只抽 10%——歸因分析要的是統計代表性，不是全量。兩個 classifier 可以看同一份流量、用不同 sampling rate，成本與監督強度就此脫鉤。
取捨與限制
先記住 beta：功能與定價都還在演進。其次，分類是非同步的——標籤在請求完成後才出現——所以它適合做事後分析與回報，不是即時的政策執行點（此段為對非同步機制的推論，非官方明文）。第三，分類品質受限於 classifier model 與 prompt 設計：taxonomy 裡的 values 定義得越含糊，標籤就越不可信。好消息是兩個工程細節被照顧到了：input 與 output logging 停用時 classifiers 仍可運作，不想存內容、只要 metadata 的姿態成立；model 隨時可換，先用便宜的、不滿意再升級。
Builder 建議
三步起手：第一，先套 Department 與 Task type 兩個 template 跑一週，用 Activity Explorer 看實際流量的分佈，再決定自訂 taxonomy 的長相；第二，每個新 classifier 都先用文件裡的手動執行功能對歷史 generation 試跑，標籤分佈不合理就改 values 再跑；第三，把 sampling policy 寫成明文規則：合規 100%、歸因 10% 是官方示範的起點，你的正確比例取決於對漏抓的容忍度。
已經在 OpenRouter 上有規模流量的團隊，Classifiers 補上的是 AI 使用回報最缺的那塊結構化資料；還沒有規模的團隊，先記住這個 pattern：分類 metadata 應該由平台產生、隨請求非同步、可抽樣控費——將來不管用哪個平台，這三個特徵都值得要求。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。