Google OpenRouter 工作流通过新分类器实现成本归因

OpenRouter 已推出处于测试阶段的 Classifiers，为请求增加最多八个标签维度，且不会延迟原始 AI 响应。对于运行 Google OpenRouter 工作流的团队而言，这项功能有望更清晰地回答一个长期存在的问题：哪些人员和任务正在消耗模型预算？

此次发布可将请求日志转化为潜在的成本地图。独立模型会读取每次已完成的生成结果，分配结构化标签，并将这些标签写回其记录。企业可按部门、任务、受众、复杂度、合规类别、成本中心或自定义分类体系对工作进行分类。

这改变了 OpenRouter 相对于 LangSmith 等可观测性平台的定位。这类产品已经能够追踪链路、元数据和模型支出。OpenRouter 现在则尝试在模型选择和计费本已发生的路由平台内部，自动推断有用的业务元数据。

其吸引力很直接。开发者通常知道哪个模型处理了请求，但财务和合规团队需要的是不同的答案。他们希望知道，是法务审查、编码代理、公开内容还是内部研究导致了这些支出。

更难的问题在于，AI 模型能否足够准确地标记这些活动，从而让这些答案能够指导预算或治理。Classifiers 让归因更容易生成，但并不会自动让归因变得可靠。

Google OpenRouter Classifiers 将提示词转化为成本标签

Classifiers 会新增一次异步模型调用，将每个选定的生成结果转换为结构化业务元数据。

OpenRouter 于 2026 年 7 月 24 日宣布推出该测试版。根据其 classifier announcement，管理员可以从模板创建分类器，或定义自定义分类体系。

每项配置包含四个主要组件：分类体系、面向分类模型的指令、所选模型以及采样率。分类体系最多支持八个维度，每个维度下的取值由管理员定义。

这些维度既可以描述谁发起了请求，也可以说明请求的预期目标。一家公司可能使用 department、task_type、audience 和 compliance_category；另一家公司则可能更倾向于使用 project、cost_center、data_sensitivity 和 agent_complexity。

分类器会在原始生成完成后运行。OpenRouter 表示，初始响应会在分类任务进入队列前返回，因此额外分析不会增加用户侧的推理延迟。

进入队列的模型会接收一份序列化转录内容。这是对系统消息、用户轮次、助手轮次、工具名称、工具调用和工具结果的带标签表示。OpenRouter 的 classifier documentation 表示，其中不包含完整的工具 schema。

每个序列化轮次限制为 5,000 个字符。被截断的内容会附带标记，说明原始文本后面还有更多内容。这一点很重要，因为被省略的部分可能包含有关请求目的或敏感性的最强信号。

分类模型会根据配置好的分类体系评估这份转录内容。结构化输出，即被限制在已声明字段和值范围内的响应，可让结果兼容筛选与分析。

随后，OpenRouter 会将标签附加到生成记录中。用户可以在生成详情面板查看维度和值的拆分情况，也可以筛选法务部门请求或复杂代理任务等组合。

该测试版包含六项预设。Department 用于识别来源业务职能，Audience 则区分内部、面向客户、监管以及公开输出。Task Type 覆盖编码、数据处理、内容创作和代理工作流等活动。

Engineering Work 区分功能开发、漏洞修复、文档、重构和代码审查。Agent Complexity 将难度层级与任务类别结合起来。Capitalizable Software Expense 则试图区分潜在的开发投资与维护、运营和支持。

最后一项预设同时揭示了该功能的吸引力与局限性。推断出的标签可以帮助团队找出需要审查的记录，但在经过人工验证以及结合企业自身资本化政策之前，不应成为最终的会计结论。

OpenRouter 还允许管理员针对历史生成记录测试分类器。这提供了一种基础方法，可在将分类体系应用于新流量之前进行检验。

结果不只是新增了一个日志字段。它创造了一种机制，可将提示词转化为业务团队能够理解的类别。这一机制也带来了新的可计费工作负载，以及新的潜在测量误差来源。

自动归因正在冲击人工标记与外部可观测性

OpenRouter 正在挑战这样一种假设：开发者必须在 AI 请求运行前提供每一个有用的成本和治理标签。

传统的请求归因高度依赖应用埋点。开发者在创建请求时附加用户标识符、项目代码、环境、功能名称或部门字段。可观测性系统会保留这些值，并将其用于筛选。

当应用本身已知答案时，这种方法可以非常精确。采购助手可能拥有固定成本中心，客户支持工作流也可能有稳定的部门和受众。在这些情况下，显式元数据仍是最强信号。

模型网关所面对的现实更为复杂。一个 API key 可能服务于多个代理、部门或内部实验。一个应用也可能在一次会话中切换研究、编码、摘要和文档审查任务。

人工标签通常描述的是应用，而不是单个请求所实际执行的工作。Classifiers 试图通过读取内容并推断请求的实际目的来弥补这一缺口。

这给两类团队带来了压力。内部平台团队必须决定，现有埋点是否依然足够；独立可观测性供应商则必须证明，为何其更广泛的链路追踪和评估能力值得作为单独一层存在。

例如，LangSmith 支持任意标签和键值元数据。其 trace metadata 可以记录环境、用户、内部标识符或其他应用上下文。这些字段随后可支持查询和分组。

LangSmith 还会追踪 token 使用量和模型支出。其 cost tracking 会在链路、项目和仪表板中汇总费用。当开发者提交自定义使用数据时，它还可以纳入非模型组件。

OpenRouter Classifiers 并不能取代这种程度的链路追踪。它们作用于经由 OpenRouter 路由的生成请求，而一条代理链路还可能包含检索、数据库调用、工具、分支逻辑和多个模型请求。

竞争差异更为具体。OpenRouter 将模型访问、请求支出和推断出的任务标签整合到同一工作区中。已经在那里路由模型的团队，无需构建新的标签管道，即可获得业务层面的成本视图。

这对 Google OpenRouter 部署尤其相关。一家公司可能使用 Google 模型完成常规处理，使用另一家供应商处理高难度编码工作，并使用前沿模型进行特定审查。分类器维度可以将这些选择与实际执行的工作关联起来。

Activity Explorer 提供了聚合层。OpenRouter 表示，团队可以按分类器维度对流量进行分组，再比较不同任务类型、部门或复杂度级别下的模型使用量和支出。

这会为模型选择形成反馈闭环。如果简单的文档任务持续使用昂贵模型，管理员可以调查路由或应用默认设置。如果高难度代理任务在迁移至更小模型后出现失败，同样的拆分数据也能揭示这一模式。

这项功能也扩大了能够解读 OpenRouter 日志的人群。财务团队无需识别每个 API key；合规审查人员无需理解每个代理的内部名称；产品负责人可以比较任务类别，而不必阅读原始提示词。

不过，自动分类应补充而非抹去显式元数据。应用知道是谁发起了请求，分类器则推断该请求看起来属于什么类型。成熟的治理体系将保留这两种信号，并调查两者之间的分歧。

正是在这里，这种压力变得具有建设性。OpenRouter 不只是在与一家具名的可观测性供应商竞争，它还在测试推断出的语义标签能否成为模型基础设施的标准组成部分。

该机制以背景支出换取推理延迟的消除

OpenRouter 将分类移出响应路径，但无法消除计算成本或准确性之间的权衡。

异步处理是核心产品决策。用户在收到原始模型输出之前，分类器永远无需完成。超时、模型错误或无效的结构化响应，都不会中断应用的主请求。

OpenRouter 表示，分类失败只会让对应生成记录不带标签。这种故障隔离保护了应用可靠性，但也会在后续报告中造成缺失数据。

因此，基于已分类流量构建的仪表板可能看起来完整，却排除了失败任务。团队在将分组结果视为可靠的总体活动统计前，需要看到明确的覆盖率。

模型选择带来了另一项权衡。OpenRouter 推荐 Gemini 3.5 Flash Lite，称其对大多数分类体系而言，在低成本和结构化输出准确性之间达成了良好平衡。管理员可以选择其他模型，并在之后更换模型。

结构化输出很重要，因为每次分类都必须匹配已声明的维度和允许值。Google 的 structured output guidance 解释了 schema 如何将模型约束为 JSON 对象、必填字段和枚举字符串。

Schema 可以让输出有效，但无法保证判断正确。分类器可能始终返回一个允许的部门，却持续将法务工作与合规工作混淆。格式可靠性和语义准确性是两项不同的衡量指标。

采样率让管理员能够直接控制分类量。合规分类器可以覆盖每一个请求，而覆盖范围更广的成本归因分类器则可以只检查一个样本。

OpenRouter 举例称，合规分类可以实现全量覆盖，而成本归因仅对 10% 的流量采样。其思路是让支出与每项分类决策的后果相匹配。

当流量稳定且规模足够大时，采样效果最佳。当罕见任务的重要性不成比例地高时，采样的可靠性会降低。小样本可能遗漏异常的监管提示词、高成本研究请求或短暂出现的代理故障。

管理员还需要考虑谁来支付这些后台调用。OpenRouter 表示，分类器 token 与其他生成请求一样计费，并计入配置该分类器的管理用户，而不会分配给发起底层请求的 API key。

这种计费设计将监督成本集中起来。这也意味着，分类器自身的支出与被衡量的部门或任务相互独立。财务团队不应将被分类请求的成本与分类开销视为同一类别。

上下文处理带来了更多限制。OpenRouter 会将对话序列化为一条带标签的消息，其中包括工具名称和选定的工具交互内容。它不会发送完整的工具 schema，从而在保留代理行为基本记录的同时减少输入规模。

但每一轮内容都可能被截断。较长的工具结果和文档可能丢失关键证据。根据 OpenRouter 的文档，如果分类器模型的上下文窗口明显短于原始提示词，也可能发生静默失败。

隐私同样值得高度关注。分类需要额外的模型读取提示词的某种表示形式。组织在启用敏感分类体系前，应审查所选提供商、工作区控制措施、保留设置和数据政策。

OpenRouter 表示，在禁用输入和输出日志记录时，Classifiers 仍可工作。这降低了“分类必须依赖常规提示词日志记录”的假设，但并未免除组织了解处理过程中哪些数据会传递给分类模型的必要性。

最合理的部署方式是从狭窄的分类体系开始。部门和任务类型具有较为熟悉的边界。团队可以人工审核样本、衡量分歧、修订指令，然后才加入会带来财务或合规影响的类别。

这与优秀的 AI 工作流一致：先自动化收集，再在判断至关重要的环节保留审核步骤。分类器应减少整理工作的负担，而不是掩盖不确定性。

标签无法证明什么

分类器可以产出整洁的分类体系，却仍可能误述模糊的工作内容、不完整的上下文，或不断变化的组织规则。

这一 beta 版最大的风险是虚假的精确性。Activity Explorer 可以将分类结果转化为精美的支出图表。视觉上的清晰感可能让模型生成的标签看起来比其底层证据所能支持的程度更具权威性。

例如，某位产品经理要求代理为路线图总结客户访谈。该请求可能属于产品、研究、营销或工程。其受众也可能在工作流后续阶段从内部读者转向客户演示。

除非公司预先定义类别，否则没有任何一个单一标签是客观正确的。因此，分类体系设计是一项治理工作，而不仅仅是提示词编写任务。

同样的问题也会影响复杂度评级。长提示词不一定困难，而简短指令可能触发要求很高的代理流程。分类器看到的是序列化内容，但它可能无法观察到每一种外部状态或下游影响。

可资本化的软件费用涉及更高风险。OpenRouter 明确表示，客户仍需对提交给第三方的财务或税务信息的准确性负责。该预设是发现和报告辅助工具，而不是会计政策引擎。

合规类别也需要同样谨慎。分类器可以标记可能涉及内部数据，或面向监管机构的受众。它无法保证提示词不含受保护信息、满足法律义务，或已遵循每一项所需审批。

在这些情况下，漏报尤为重要。合规仪表盘可能因为模型遗漏了敏感请求而显示低发生率。抽样也会加剧这一问题，因为许多请求未被检查。

误报同样有成本。过度分类可能淹没审核队列、阻碍员工使用获批工具，或将支出分配给错误的部门。团队需要纠错流程，而不是假定分类器输出是不可变更的事实。

OpenRouter 的历史测试选项有助于提示词调优，但一次生成无法验证一套分类体系。管理员需要一个具有代表性的测试集，其中包含常规流量、边缘案例、模糊请求、长上下文和罕见的高风险场景。

人工审核人员应独立为该测试集打标签。随后可将分类器结果与每个维度的参考标签进行比较。准确率应按类别报告，因为可接受的总体得分可能掩盖其在罕见类别上的糟糕表现。

组织还应监控漂移。新项目、模型能力、代理工具和内部政策都可能改变某个类别的含义。一个在设置期间有效的分类体系，可能在没有任何明显系统错误的情况下逐渐失效。

模型变更会带来另一种漂移来源。管理员可以随时更换分类模型。这种灵活性有助于控制成本和提升质量，但新模型可能对相同指令作出不同解读。

涵盖此类变更的报告应保留分类器和模型版本信息。否则，部门使用情况的变化可能反映的是新的标注模型，而非员工行为的变化。

缺失标签需要得到明确处理。如果分类失败，原始生成仍会照常继续。汇总报告应将已分类、未被抽样和失败流量作为不同群体展示。

OpenRouter 的公开材料解释了其机制和失败行为，但并未为 Gemini 3.5 Flash Lite 在客户自定义分类体系上的表现提供独立准确率基准。在团队根据自身记录完成验证之前，这项推荐仍属于公司的判断。

这一验证缺口并不意味着 Classifiers 无法使用。它界定了其适当角色。这些标签可以支持探索、异常检测、预算讨论和审核优先级排序。

它们不应独立批准费用、确定监管合规性，或作出雇佣决定。后果越严重，所需证据就必须越充分。

一条好的运营规则很简单：推断标签可以开启调查，而经验证的记录才能结案。保留这一边界的团队，能够获得可见性，同时避免将概率性输出转化为制度事实。

三个信号将决定 Classifiers 是否成为基础设施

下一项检验在于，组织是将 Classifiers 视为有用的分析层，还是将其视为又一个需要持续纠正的仪表盘。

第一个信号是可量化的分类覆盖率和纠正质量。OpenRouter 应披露有多少符合条件的生成被抽样、成功标记、跳过或失败。

覆盖率数据将使管理员能够区分真实的使用趋势和管道缺口。纠正工具也会为员工或审核人员发现错误标签时改进分类体系提供路径。

如果 OpenRouter 增加覆盖率指标、审核队列或系统化评估功能，其治理主张将更有说服力。如果用户必须在无法衡量错误的情况下手动检查生成内容，Classifiers 将仍然最适合用于方向性分析。

第二个信号是 Activity Explorer 如何处理版本控制和归因。管理员需要知道每个标签由哪一套分类体系、提示词和模型生成，尤其是在配置变更之后。

具备版本感知能力的报告将保护历史比较的有效性。它还可以让团队在替换用于定期财务或合规报告的分类方法之前，测试两种分类方案。

如果这些控制措施到位，OpenRouter 将更接近一个受治理的测量系统。如果报告悄然混合不同分类器版本的结果，表面上的趋势仍将难以信任。

第三个信号来自可观测性和网关竞争对手的反应。LangSmith 已将元数据、追踪、评估和支出分析结合起来。其他平台可以为现有追踪添加自动化语义标签，或接收其他地方生成的分类结果。

竞争对手拥有一项重要优势，因为它们通常能看到完整的代理执行过程。OpenRouter 则有不同优势，因为它直接处于模型路由和计费路径之中。

获胜的方法可能会结合两者。OpenRouter 可以在生成层面推断任务和部门标签。可观测性平台则可以将这些生成与工具、检索步骤、评估、用户反馈和应用发布关联起来。

Google OpenRouter 工作流提供了这一分工的早期检验。Gemini 3.5 Flash Lite 可以执行分类，OpenRouter 可以将结果与模型支出关联，而更广泛的追踪系统可以保留运营上下文。

团队应关注用户是否会在不同模型间采用同一套分类体系，还是为不同应用创建独立分类器。共享分类体系将支持全组织范围的成本归因。碎片化的分类体系则会让比较更加困难。

他们还应关注全覆盖与抽样之间的平衡。若在适度抽样率下仍获得较高采用率，将表明方向性的成本分析已能提供足够价值。全覆盖则意味着合规和运营审核正在成为更强的使用场景。

这一 beta 版最终重新定义了 AI 成本管理。Token 总量解释了公司花了多少钱。自动推断的标签则试图解释这些钱为何被花出，以及哪些工作获得了资源。

这是一个更有用的问题，但它要求更严谨的证据。每一个考虑使用 Classifiers 的组织，都应明确标签将支持的一项决策，测试具有代表性的样本，并在图表旁公布覆盖率。

你的团队会将 Google OpenRouter 分类结果作为导航信号，还是让它们成为会计事实？答案应在第一个高管仪表盘出现之前，决定分类体系、抽样政策、验证集和人工审核流程。