摘要： OpenRouter 的 Classifiers 以 taxonomy、classification prompt、model 與 sampling rate 四個元素設定。分類在請求完成後以非同步方式執行，不經過推論路徑，因此 latency 零增加。文章說明六種 preset template 與 Activity Explorer 的分析路徑，同時指出具體定價未公布。
AI 用量一旦放大，治理的提問就追著來：誰在用、拿去做什麼任務、哪些支出可以報帳、哪些輸出總有一天會攤在監管機關面前。這些答案其實一直藏在每筆 generation 裡，差的只是一個能把它們講清楚的結構化格式。7 月 24 日，OpenRouter 把 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 裡的正式值，不是自然語言的猜測。
classifier model 的官方推薦是 Gemini 3.5 Flash Lite，理由是便宜、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 應該由平台產生、跟著請求非同步跑、可抽樣控費——將來無論換到哪個平台，這三個特徵都值得開口要求。