OpenRouter Classifiers 能给 AI 支出贴标签，但先证明标签可信

OpenRouter 在 2026 年 7 月 24 日发布了 beta 版 Classifiers。团队可以为 workspace 定义一套分类体系，选择一个模型，让它给每次 generation——或者其中一部分样本——打上部门、任务类型、受众、Agent 复杂度、潜在可资本化软件支出等标签。之后，这些标签会出现在请求记录旁，也可以汇总到 Activity 报表里。

这项能力很实用，也很容易被用过头。

一个标签能稳定写入结构化字段，不代表它已经成为会计事实。分类器看到的是经过序列化、而且可能被截断的对话。它可能漏掉任务真正的目的，把含义模糊的请求硬塞进错误类别，也可能静默失败。团队一旦抽样，样本还可能不再代表全部流量。假如报表显示“市场团队消耗了 38% 的 AI 预算”，这个数字其实把两种性质完全不同的信息揉在了一起：平台计量的费用，以及模型对“这份工作属于什么”的判断。

小团队真正要决定的，并不是语义成本归因是否方便，而是这些标签是否足以支撑后续动作。观察一个大致的产品使用趋势，和调整部门预算、开客户账单、提交合规报告、决定研发支出是否资本化，需要的证据强度完全不同。

本文提供的是一套待执行的校准实验，不是已经完成的 OpenRouter benchmark。Y Build 没有用私有 workspace 流量实测 Classifiers，下文也没有把任何数值写成观察结果。可复用的产物包括：分类体系契约、120 条记录的裁决台账、覆盖率与错误门禁、抽样检查、影子运行协议和准入凭证。目标不是否定语义标签，而是防止它们悄悄变成第二套更难审计的计费系统。

OpenRouter 发布了什么，又没有证明什么

OpenRouter 的发布公告把一个 classifier 配置拆成四部分：最多包含八个维度的分类体系、分类提示词、执行分类的模型，以及抽样比例。产品提供六套预设，覆盖部门、受众、任务类型、工程工作、Agent 复杂度和潜在可资本化软件支出。分类发生在主 generation 完成之后，因此不会增加用户等待首轮推理结果的时间。

更详细的 Classifiers 文档说明了真正影响上线判断的边界：

• 系统会把 prompt 序列化成带角色标记的 transcript，其中可能包含 system 文本、工具名称、用户与助手对话、工具调用和工具结果；
• 完整的工具 schema 不会被送入分类器；
• 每一轮内容最多保留 5,000 个字符；
• 如果分类模型的上下文窗口明显短于原始 prompt，分类可能静默失败；
• timeout、模型错误或无效输出不会阻断原 generation，但也不会写入标签；
• classifier 调用和普通 generation 一样消耗 workspace credits；
• 这笔分类费用记在配置 classifier 的管理员用户下，而不是原始 API key 下。

OpenRouter 还说明，structured output 会把结果限制在团队声明的维度和值之内。这能证明输出格式可控，却不能证明选中的值正确，也不能证明缺失标签是随机发生的，更不能证明被抽中的流量代表整体流量。即使标签本身合理，也不代表它适合直接进入财务报表。

Classifiers 目前仍是 beta。这个发布足以让团队启动一个有边界的评测，但不足以证明某套预设符合一家具体公司的工作结构，也不足以证明推荐的低成本模型能满足所有团队的错误预算。

把计量费用与语义推断分开

一份 AI 使用台账至少包含两类不同字段。

计量字段描述平台实际记录了什么：generation ID、模型、输入 token、输出 token、cache 使用和费用。OpenRouter 的用量计量文档说明，这些信息会随响应返回，也可以通过 generation ID 再次查询。它们仍受平台计费口径约束，但不是对工作含义的语义猜测。

推断字段解释请求是什么：部门、任务类型、受众、项目、难度或会计处理方式。模型根据它收到的 transcript 给出这些判断，因此必须配套分类体系、证据和不确定性处理规则。

在存储和表达上都要把几层信息拆开：

这样做能阻止一个常见跳跃：直接把 classifier_label 等同于 accounting_owner。销售同事可能请 Agent 写代码，工程师可能生成发布页面，一个共享 Agent 也可能在同一流程里服务多个部门。即使任务标签完全正确，它也未必回答“谁应该承担预算”。

因此，语义分类更适合作为成本台账的一项 join 条件，而不是最终台账本身。成本归因应当把平台计量用量、明确声明的所有权、必要时经人工复核的任务含义，以及一套可追踪的分摊策略组合起来。

评测模型前，先写分类体系契约

分类体系本身的问题，经常会被误判为模型问题。如果“运营”和“客户支持”有重叠，“修复 bug”和“事故响应”没有边界，那么在分类器参与之前，两个认真负责的复核人员就可能给出不同答案。

每一个维度都要写成契约：

示例应来自团队自己的工作，但必须移除客户数据和密钥。不要只写最容易的典型案例，还要写边界案例。“起草一封定价邮件”很容易归入 Marketing；“分析流失、编写 SQL，再起草续费沟通”则会暴露分类体系究竟描述请求发起部门、实际执行的工作、最终产物，还是工作受益方。

如果产品允许，应加入 unknown、mixed，或者明确的升级处理规则。封闭 schema 没有不确定性出口，不会让歧义消失，只会把歧义包装成确定答案。

“潜在可资本化软件支出”这套预设尤其需要谨慎。OpenRouter 自己也在文档中强调，客户仍要为最终财务或税务数据的准确性负责。Classifier 可以帮助筛出可能值得复核的记录，但不应独立决定资本化政策、使用寿命或审计处理。

建一份 120 条记录的裁决台账

第一轮有效实验不需要给整个 workspace 分类。先从经过授权、去除敏感信息的历史模式或等价合成案例中，建立一份拟议的 120 条记录测试集。

可以有意识地分层：

• 40 条常见、单一目的的请求；
• 20 条目的会在多轮对话中改变的请求；
• 15 条大量调用工具的 Agent 运行；
• 15 条能触发截断边界的长对话；
• 10 条跨部门或跨项目任务；
• 10 条理应进入 unknown 的请求；
• 10 条与财务、合规、客户计费或敏感数据有关的高后果记录。

这些数量只是初始 fixture，不是统计保证。类别越稀少、后续动作后果越高，需要的样本就越多。

两名复核者应先依据分类体系契约，对其中一部分记录独立打标签。复核者一致并不等于真相，但分歧能暴露定义含混的问题。发表于 Computational Linguistics 的一项 meta-analysis 指出，标注目的、人员训练、类别设计等流程选择都会显著影响一致性结果；对小团队最实用的启示，是记录完整标注制度，而不是生搬一个通用的一致性阈值（Bayerl 与 Paul）。

出现分歧时要通过裁决解决，并保留原因，不能直接覆盖第一次标签。台账至少保留：

record_id
source_pattern
risk_tier
taxonomy_version
reviewer_a_label
reviewer_b_label
agreement
adjudicated_label
adjudication_reason
evidence_available_to_classifier
truncation_expected
classifier_model
classifier_prompt_version
classifier_label
classifier_status
metered_classifier_cost

不能让 classifier 生成自己的黄金标签，也不要在独立标注前向复核者展示模型输出。否则实验测到的只是人是否同意模型给出的暗示，而不是独立有效性。

先检查覆盖率，再计算准确性

分类失败不会影响原请求，这对保障主推理链路可用性是合理设计，但也意味着覆盖率必须成为一级指标。

定义：

eligible_records =
  按策略本应进入分类的 generation

tagged_records =
  已写入完整且有效标签的 eligible record

coverage =
  tagged_records / eligible_records

如果平台提供足够证据，再按原因拆分缺失记录：timeout、无效输出、上下文不足、管理员配置、模型不可用，或者未知。如果平台没有暴露原因，就诚实记录为 unknown，不要自行编造诊断。

覆盖率还必须按关键 cohort 切片：

• 长对话与短对话；
• 工具密集型与纯文本任务；
• 语言；
• 部门或 API key；
• 分类模型；
• 分类体系版本；
• 普通记录与高后果记录。

整体覆盖率 96%，可能掩盖“长合规对话只有 60% 被打上标签”。如果缺失概率与任务成本或复杂度相关，缺失标签就绝不是无害噪声。

Google 的生产级 ML 指南强调，离线指标之外还必须有测试与持续监控；它的 ML Test Score把这一原则变成了具体的生产就绪检查。映射到 Classifiers，第一道发布问题应当是：“本应分类的记录，是否产生了可审计输出？”之后才轮到“输出是否正确”。

用混淆矩阵找错配，再给错误定价

对裁决测试集中每一条成功打标的记录，把 classifier 标签与人工裁决标签进行比较。多分类混淆矩阵会直接显示哪些类别最容易相互吞并。

当类别分布不均衡时，只看 accuracy 很危险。Google 的分类指标指南解释了一个常见陷阱：系统只要不断预测最大类别，就可能看起来“很准”，同时完全漏掉稀有但重要的记录。因此至少要报告逐标签 precision 和 recall：

• Precision： classifier 标为 Legal 的记录，有多少经裁决后确实属于 Legal？
• Recall： 所有经裁决属于 Legal 的记录中，有多少被 classifier 找到？
• Unknown precision： classifier 选择不判断时，有多少确实是证据不足？
• Unknown recall： 所有含义模糊的记录中，有多少没有被强行塞入确定类别？

接下来要给错误附上后果。把 Documentation 误分为 Feature Development，可能只会让内部趋势图略微失真；把客户工作误分为内部工作，则可能影响账单；把 maintenance 标成潜在可资本化 development，如果没人复核，可能污染财务流程。

使用一张错误表：

在真实实验产生证据前，数量栏必须保持空白。错误权重是团队策略，不是 classifier 的客观属性。再多低风险正确标签，也不能抵消一次 critical error。

外推总量前，先审计抽样

抽样可以控制分类成本，但抽样设计决定了团队能得出什么结论。请求数量的 10%，不一定代表支出的 10%。大型 Agent 任务可能数量少但费用高，交互式 chat 则可能数量多但单次便宜。

OpenRouter 的公开 State of AI 报告提供了一个很好的边界示例：报告明确称其数据是 observational，并说明内部分类来自大约 0.25% prompt 的随机样本。这份报告不能证明某个客户 workspace 的 Custom Classifiers 会如何抽样。它展示的是一份抽样分析至少应该披露什么：抽中了什么、标签如何生成，以及结果描述的是哪个总体。

针对 workspace 实验：

1. 条件允许时，用有记录、可复现的规则做稳定随机选择。
2. 利用不依赖语义标签的字段，比较样本与未抽中流量：API key、模型、token 量、费用、延迟、时间段和工具使用。
3. 对少见但高后果的 cohort 过度抽样，并保留每条记录的入样概率。
4. 把样本内观察结果与加权估计分开报告。
5. 原始计量总费用应独立于语义 classifier 保存；只有分摊比例来自推断。

如果系统只允许配置一个百分比，却不提供可复现 seed 或可导出的入样记录，精细外推就会受限。标签仍可用于观察大方向，但除非团队能解释记录如何入样、缺失分类如何处理，否则不要给出看似精确的部门金额。

标签动钱之前，先做影子运行

第一个生产阶段只写标签，不改变预算、模型路由、客户账单、权限或财务记录。

拟议的影子阶段应持续七天，或者覆盖一个完整业务周期，取两者中能代表实际波动的那个。必须保留分类体系版本、分类模型、分类提示词版本、抽样比例和启用时间。每天完成：

• 对账 eligible、sampled、tagged、failed 和 unclassified 数量；
• 复核全部高后果标签；
• 随机复核一部分普通标签；
• 查看分歧集中在哪些类别，而不是只看整体 accuracy；
• 计算分类成本占被分析推理成本的比例；
• 把分类体系调整记录为新版本，不能静默改 prompt。

OpenRouter 的 Activity export会报告费用、token 和请求数，并可按模型、API key 或创建者分组。把这些计量维度作为对账锚点。语义分类后的总额，应能重新加总回同一个观察窗口内“已成功打标”的费用。任何差额都必须有明确 bucket：未抽样、分类失败、unknown、延迟写入，或者按策略排除。

NIST AI RMF 的 Measure function 要求记录测试、性能评估、不确定性、生产监控和独立复核（AI RMF Core）。这里最重要的原则是：批准会过期。分类体系、提示词、模型、上下文处理、产品工作流或流量结构一旦变化，就要重新跑一组 sentinel records。

一个具体场景：一个 Agent，三个成本中心

设想一家 12 人的软件公司，用同一个 Agent 处理支持、用户 onboarding 和产品运营。每周有一条流程会：

1. 读取支持工单；
2. 查询产品使用数据；
3. 起草帮助文章；
4. 提议一封 onboarding 邮件；
5. 创建一个工程 issue。

这笔费用属于哪个部门？答案取决于公司的分摊策略。请求可能由 Support 发起，最多 token 也许花在 Product 分析上，最终产物则同时服务 Marketing 和 Engineering。部门 classifier 的语义判断可能完全合理，却仍然回答不了预算问题。

更稳妥的做法，是拆成三个维度：

• requesting_owner：由 workspace 或 API key metadata 明确声明；
• work_type：根据 transcript 推断；
• allocation_policy：复核后应用，可允许 shared 或按比例分摊。

Classifier 最适合判断 work_type。requesting_owner 应由一手 metadata 声明，allocation_policy 则放在由具体负责人维护、带版本号的规则里。

测试集必须包含中途改变目的的多轮流程，因为序列化 transcript 里可能同时出现多种工作。团队要明确：标签描述最后一次请求、占比最大的工作、最终产物，还是整个 generation。如果这条规则说不清，图表最后回答的只会是一个无人提出的问题。

通过实验后，也可以只批准产品趋势 dashboard 使用标签；客户计费继续人工复核；资本化相关标签则保持 discovery-only——classifier 负责找候选，财务人员负责作决定。同一个 classifier 不需要获得一刀切的信任级别。

检查隐私与证据边界

语义分类处理的是内容，而不仅是 token 数。分类 transcript 可能包含 system instructions、用户文本、助手文本、工具名称、工具调用和工具结果。团队因此必须审查敏感信息会进入哪个分类模型和 provider。

OpenRouter 的数据收集文档把 prompt 存储、产品改进 opt-in、匿名分类与 metadata 收集分开说明。Classifiers 文档还写明，即使 input/output logging 关闭，自定义分类仍然可以工作。不能据此推断分类等同于“不发送内容”；分类任务依旧会序列化内容。

启用之前，要记录：

• 哪个模型和 provider 执行分类；
• 适用的 provider logging 与 retention policy；
• private、regional 或 zero-data-retention 要求是否同样覆盖分类请求；
• 哪些 transcript 字段可能包含客户数据或密钥；
• 分类前是否做 redaction；
• 谁能创建或修改 classifier；
• 谁能查看语义标签和关联 generation 详情；
• 删除和事故响应如何覆盖 classifier 产物。

本文不能替某个具体账号确认 OpenRouter 的合同或地域处理行为。团队需要在 workspace 配置和当前条款中再次核实。如果无法确认数据路径合规，就应优先使用一手 metadata 和本地分类，而不是把“需要可观测性”当作扩大数据访问的默认许可。

准入前先认识这些失败模式

最可能出现的并不是夸张的模型幻觉，而是一批安静的报表错误：

封闭分类体系压力。 没有诚实的不确定性出口时，模型只能选择最接近的允许值。

截断盲区。 真正改变类别的证据出现在每轮字符上限之后。

末轮混淆。 多轮流程从调研变成实施，但标签定义没有说明哪个阶段优先。

覆盖偏差。 长请求或困难请求更容易分类失败，于是已打标子集看起来更便宜、更简单。

样本偏差。 请求数量有代表性，不等于费用、风险、语言或时间分布也有代表性。

分类体系漂移。 新团队、新产品或新流程改变了旧类别的含义，dashboard 却仍把它们画成同一条连续曲线。

模型漂移。 被选中的分类模型行为或可用性发生变化。

策略洗白。 一个概率性的任务标签没有经过独立决策规则，就进入会计、合规或客户计费流程。

分类成本漏算。 团队用 classifier 分析 AI 花费，却没有把 classifier 自己的费用计入总成本。

Google 关于机器学习数据验证的研究指出，系统可能在遇到异常 pattern 或训练/服务偏移后仍继续运行。语义成本系统也需要对应的防线：持续验证输入、输出覆盖和 cohort 结构，而不是只在一套冻结测试集上测一次模型。

用准入凭证，而不是一张全绿 dashboard

最终决策产物必须让缺失证据保持可见。一份拟议凭证如下：

classifier_promotion:
  workspace: null
  decision_date: null
  owner: null
  allowed_use:
    exploratory_trends: false
    budget_planning: false
    client_billing: false
    finance_screening: false

  configuration:
    taxonomy_version: null
    classifier_prompt_version: null
    classifier_model: null
    sample_rate: null
    activation_window: null

  evidence:
    eligible_records: null
    tagged_records: null
    coverage: null
    high_consequence_coverage: null
    adjudicated_set_size: null
    per_label_precision_recall: null
    critical_error_count: null
    unknown_rate: null
    classifier_cost_share: null
    sampled_vs_population_check: null

  boundaries:
    metered_fields_separate: false
    unknown_bucket_enabled: false
    privacy_path_reviewed: false
    taxonomy_change_log: null
    human_review_required_for: []

  rollback:
    disable_owner: null
    disable_tested_at: null
    dashboard_annotation_plan: null
    next_review_date: null

  decision: hold

每次只批准一种用途。exploratory_trends: true 不代表 client_billing: true。如果覆盖率无法对账、仍有 critical error、抽样不支持所声称的总体金额，或者隐私路由尚未确认，凭证就应继续保持 hold。

回滚也不只是关闭 classifier。要在 dashboard 上标明不同时间段使用的分类体系版本，保留旧定义，撤回无效窗口内发生的自动分摊，并通知所有使用过这些标签的下游报表负责人。

这套协议适用于哪里，又不适用于哪里

这套协议面向准备在 AI 用量上增加语义标签的小团队。它不是 OpenRouter、推荐分类模型或六套预设的独立 benchmark。120 条记录足以暴露本地定义歧义和明显失败簇，却不能高置信度估计稀有错误，也不能证明所有语言和工作流上的表现。

人工裁决可能不一致，也可能带有偏见；历史模式会漏掉新工作；合成记录通常比生产流量更干净；抽样工具未必暴露加权估计所需的所有细节；beta 产品还可能持续变化。一套分类体系上得到的 precision 与 recall，也不能自动迁移到另一套体系。

不能用这个方法自动完成税务、法律、用工或受监管决策。Classifier 可以筛选候选记录或提示异常，但合格负责人必须保留最终决定权。不要把生产密钥放进实验，也不要从通用文档中推断 provider retention、地域处理或合同保证。

如果声明式 metadata 已经足够回答问题，这套协议甚至可能没有必要。假如每个 API key 都明确属于一个成本中心，共享工作又很少，那么一手所有权数据加计量费用，通常会比语义分类更准确、更便宜、更容易审计。

一份 48 小时 Build Lab 计划

第一天，先选一个低后果问题，例如“哪些工作类型推动了 AI 用量”，不要从客户计费开始。定义四到六个类别和一个 unknown，写清 inclusion 与 exclusion rules，把分类体系冻结为 v1。从常见、混合、长对话、工具密集、unknown 和高后果 cohort 中组装 120 条去敏或合成记录。让两名复核者独立标注一组边界案例，裁决分歧，并在查看模型输出前修改契约。

然后配置一个分类模型和提示词，记录抽样规则与预算。在产品允许的情况下，对固定台账做按需运行。先算 coverage，再算逐标签 precision、recall、critical error、unknown 处理和 classifier 成本。重点查看实际混淆的是哪些类别。

第二天，开始影子运行。把 eligible、sampled、tagged、failed 和 unknown 记录与 generation 计量总额对账。利用模型、费用、token、工具、语言和时间字段，比较样本与总体。复核隐私路由和管理员访问权限。此时只为 exploratory trends 填写准入凭证。

最后只能做四种决定之一：修改分类体系、调整 classifier 配置、继续影子运行，或者只批准一种范围很窄的报表用途。如果团队无法解释分母、缺失标签、错误成本和回滚方式，就不要让标签进入预算事实。

OpenRouter Classifiers 让 AI 使用的“含义”变得可查询，这可以成为很有价值的可观测层。Build Lab 的规则，是始终保留计量费用与模型解释之间的差别：校准解释、给错误定价，并且只让证据支持的用途通过准入。

参考资料

1. OpenRouter — Classifiers: Track What Your Agents Do and What It Costs
2. OpenRouter — Custom Classifiers 文档
3. OpenRouter — Usage Accounting
4. OpenRouter — Activity Export
5. OpenRouter — Data Collection
6. OpenRouter — State of AI report
7. Google for Developers — Classification metrics
8. Google Research — The ML Test Score
9. Google Research — Data Validation for Machine Learning
10. NIST — AI RMF Core, Measure
11. Bayerl and Paul — What Determines Inter-Coder Agreement in Manual Annotations?