OpenRouter Classifiers：AI coding 开始被按工程类型和成本中心记账

很多团队已经能统计「用了多少 token」，却答不出更实际的问题：这些 token 到底花在修 bug、写新功能、代码审查，还是一个长程 Agent 在反复试错？OpenRouter 7 月 24 日把 Classifiers 推出 beta，试图把这层账补上。

它的做法很朴素。用户为请求定义一套 taxonomy，再指定一个分类模型和采样率。分类器在原始请求完成后异步运行，不阻塞推理路径，然后把结构化标签写回日志。官方给出的配置最多支持 8 个维度，内置 6 套模板，包含部门、受众、任务类型、工程工作、Agent 复杂度和可资本化的软件支出等。

对 AI coding 最有用的是 Engineering work 模板。它可以把请求分成 feature development、bug fixing、documentation、refactoring、code review 等类别。Agent complexity 则把任务按难度和任务族标记。这样一来，团队不必只看某个模型的平均价格，而能看到「哪类工程任务用了什么模型」「复杂任务是不是被低价模型反复重试」「哪个部门的 Agent 账单增长最快」。

这件事看起来像日志功能，实际更接近运行治理。过去企业采购模型常用一个粗粒度的总账：输入 token、输出 token、模型单价。Coding Agent 进入生产后，成本会被上下文长度、工具调用次数、重试、缓存、审批和人类返工共同决定。没有任务类型，管理者只看得到账单；有了分类，才有机会把账单和产出、风险、部门预算放在一起看。

OpenRouter 还给了一个现实的使用方式：合规类分类器可以 100% 采样，成本归因类分类器可以只抽样 10%。分类模型本身也可以更换，官方推荐 Gemini 3.5 Flash Lite 作为性价比选项。分类结果被限制在用户定义的维度和值里，便于在日志和 Activity Explorer 里聚合趋势。

但这不是自动长出真相。分类器读的是请求与生成记录，标签质量取决于 taxonomy、分类提示词和模型判断。一个「重构」请求可能同时包含 bug 修复；一个 Agent 任务的复杂度也可能在执行过程中变化。采样能省钱，却会让小样本部门的趋势不稳定。更现实的风险是把模型标签当成财务事实，尤其是「可资本化软件支出」这类判断，最终仍需要企业自己的会计与合规规则。

我更关心的是：它把 AI coding 的竞争从「模型选择器」推向「工作负载账本」。当 Cursor、Claude Code、Codex 或自建 Agent 都能接入多个模型，企业真正需要的是一张可解释的路由表：什么任务交给谁，为什么，花了多少钱，出了问题谁负责。Classifiers 还只是 beta，但它已经把这个问题从财务报表旁边，搬进了 Agent 日志本身。

原文：

• OpenRouter 官方公告：https://openrouter.ai/blog/announcements/classifiers
• 分类器文档：https://openrouter.ai/docs/guides/features/classifiers
• Activity Explorer：https://openrouter.ai/activity/explore