Cloudflare Auto Router 上线：AI 产品创始人的模型路由验收关

9 月 30 日，Cloudflare 将 Auto Router 推出为公开测试功能。应用通过 AI Gateway 请求 cloudflare/auto，网关便可为每次请求挑选符合条件的模型。Cloudflare 公布了令人关注的内部成本数据，但这些数字还不能证明你的 AI 产品既省钱，又保持客户看重的结果。对非技术创始人和小团队来说，眼前要做的是上线决策：哪些任务允许自动路由？质量底线是什么？数据可以交给哪些供应商？选错或故障时谁来收拾？

本文给出一套可以交给工程师、也可以配合 AI app builder 使用的验收方法：一个客服场景、一张评估表、分阶段灰度方案和停止条件。案例与阈值都是建议测试，不是 YBuild 的实测结果。核心判断是：只有整件客户任务在时效、隐私和质量要求内完成，单次模型调用变便宜才有价值。

发布了什么，哪些仍是厂商主张

Cloudflare 的发布说明描述了两步选择。AI Gateway 先按输入格式、凭证、计费设置、访问策略、费用上限和供应商健康状态筛出候选模型；随后根据近期对话判断任务类型与难度，再综合预期质量和成本排序。产品文档说明，首选模型无法处理请求时，网关可以尝试下一个合格模型；应用也能用请求头限定候选模型和供应商。这些是厂商描述的产品行为，值得在自己的流程里直接验证。

Cloudflare 称，在内部 OpenCode 工作中，相比只使用前沿模型，Auto Router 最多节省了 30% 成本。它公开的一项通用办公任务评估包含 97 个任务、每题重复三次：路由器在 291 次试验中成功 252 次，Claude Opus 5.5 成功 281 次，GPT-6 Sol 成功 245 次。数字来自 Cloudflare 自建的模拟工作区评估，不是独立机构测出的客服表现，也没有覆盖你的错误严重度、重试策略或供应商合同价。发布时该功能仍处于公开测试阶段。这张表足以支持开展小规模试验，不能直接写进利润预测。

文档还说明默认候选模型池可能变化，并提供限制供应商与模型的请求头。这一点关系到产品承诺：同样的 cloudflare/auto 配置，日后可能让客户请求落到不同模型。除非你固定或记录候选池，否则难以解释结果变化。Cloudflare 把按零数据留存要求筛选候选模型列为后续计划；它不是目前所有自动路由请求已经享有的保证。决策表应把“已经可用”和“路线图”分成两列。

先定义价值单位，再比较账单

模型调用是一次请求及回复。客户任务是用户来到产品里要完成的结果，例如一份可发送的准确回复、一个可依赖的分类，或一个真正解决的工单。路由决策是网关为某次请求选中合格模型。回退是在首选模型无法服务时，尝试另一合格模型。影子运行是离线评估候选回复，不展示给客户。这几个词能防止一张成本图表冒充产品结果。

设想客服助手为退款申请起草回复。便宜模型漏掉商家政策里的例外条款，人工不得不重写，单次调用虽然便宜，“每份获批准回复的成本”却可能上升。反过来，小模型可能足以写好常规物流回复，让昂贵模型专门处理争议。单看 token 单价，推不出哪种情况会发生。Cloudflare 的成本文档也说明，网关费用是基于 token 数据的估算，部分端点可能不提供所需数据；准确账单应以供应商后台为准。

把每件被接受任务的总成本设为主要经济指标：同一组任务的模型调用、重试、回退、人工审核及补救成本总和，除以通过产品验收的任务数。同时记录从开始到被接受的耗时。不要让便宜的均价掩盖质量下降。如果用户弃用、重开工单，或者把错误回复发出去了，这些都是任务结果的一部分，即使第一眼看文字很流畅。

先划出允许路由的任务边界

自动路由适合难度差异较大、结果又容易判断的任务。常规摘要、供人审核的草稿、低影响分类可以先试。需要特定模型能力、合同指定供应商、敏感数据位置保证或高后果判断的任务，则应先固定模型，直到替代方案经过验证。Auto Router 文档说，包含图片的输入会将候选池缩小到能处理图片的模型；这不等于各模型的功能可以无条件互换。目前文档描述支持 Chat Completions 和 Responses API 格式，但不支持 WebSockets。

打开开关之前，先写一页任务清单。逐项列出用户目标、来源数据、用户可见输出、可能触发的外部动作及失败后果。分成“可以进入影子测试”“通过保护性试点后才能路由”“继续固定模型”三类。有人审核的客服草稿，可以早于自动退款决定进入试点。客户直接看到的回答，则至少要能发现无依据断言并提供纠错路径。功能若会调用工具，还要检查换模型是否改变参数格式、停止条件或写入行为。“都能输出文字”不是写入客户记录的验收标准。

候选池是产品政策，不只是节省费用的旋钮。Cloudflare 的模型与供应商限制请求头可以替换默认模型集合或限制供应商。每组客户应使用已经测试过的最窄候选池，并记录列表和版本。默认池变化后，不能假设新选择与旧选择等价。如果只剩一个合格模型，响应中的 forced_by_candidate_pool 会解释原因；这条信息有用，但也意味着这次试点并没有真正测试模型选择能力。

用客户验收标准做评估表

下面这张表可以直接复用。字段是建议模板；具体阈值应按现有产品基线和风险承受能力确定。每一行记录一件完整任务，不是一段模型回复。基线组与候选组应使用相同输入和资料快照，避免政策刚好更新、新消息刚好到达，结果却被误算成路由器的功劳或过错。

字段	每件任务要记录什么	为什么需要
任务与用户分组	功能、语言、客户层级、风险等级	总平均值可能掩盖某个薄弱群体
输入快照	脱敏样本编号、资料版本、政策版本	便于重放，也能复核争议
路由政策	允许的模型/供应商、网关配置版本	候选池可能变化
决策轨迹	实际模型、路由原因、决策 ID、请求 ID	知道到底是谁服务了用户
任务结果	通过、需修改、拒绝或未解决；附审核理由	衡量可用成果，不只衡量语言流畅度
错误严重度	风格瑕疵、事实错误、隐私泄露、错误动作	严重回归不能被平均分淹没
总投入	调用、重试、回退、审核分钟数、总耗时	看见隐性成本
用户证据	批准、编辑、重开、投诉或放弃	将测试分数连到真实体验

Cloudflare 列出的响应头包括 cf-aig-routed-model、cf-aig-routing-reason、cf-aig-routing-decision-id 和 cf-aig-request-id。把它们同应用自己的任务记录关联起来，再补上结果标签。fallback_router_timeout 说明路由器超时，不能证明最终回答合格；cost_optimal_within_pool 是路由器给出的选择原因，不是外部质量评分。

试点开始前，还要确定谁有资格标记“通过”。客服草稿不能只让 Agent 给自己打分，应由熟悉政策的人审核，或者使用明确的用户接受信号。政策本身含糊时，把审核分歧和模型错误分别记录。不要因一份模糊政策责怪便宜模型，也别把坏政策解释成模型偶然失误。分清问题，产品和工程团队才知道该改哪里。

用具体场景揭示真实取舍

设想 CedarDesk，一家虚构的两人创业公司，为小型网店提供客服助手。产品根据商家最新的配送及退款政策起草回复，要处理简单的物流问题、破损商品例外和跨语言请求。有的商家接受所有已批准供应商，有的合同只允许指定名单。CedarDesk 尚未测过 Auto Router，准备验证：自动选模型是否能降低“被接受草稿”的成本，同时守住对客户的承诺。

团队收集获得适当许可、并经过脱敏的近期任务样本，包括普通物流咨询、超过退货期限但可能符合例外的申请、缺少订单号的请求、顾客邮件中夹带恶意指令、要求中文回复的消息，以及会话中途政策变更的情况。每个样本都配一份对应时点的政策快照和验收规则：引用正确条款、不虚构退款、缺信息时追问、保持语言与语气，缺少授权时升级给人。审核者在不知道模型身份的前提下比较固定模型与路由版本。

最难的样本未必最长。顾客说：“包裹破损，已经第 32 天了。”普通退货期限为 30 天，但破损条款允许例外，并要求提供证据。只回答“超过期限”会失败；真诚道歉却直接承诺退款，也会失败。合格回复应指出例外，索取所需照片与订单号，并在商家审核前避免承诺最终退款。这是产品自己的验收规则，不是在猜 Cloudflare 会挑哪个模型。

再加入供应商故障。路由文档说网关可以排除不健康的供应商，并选用另一合格模型。CedarDesk 要确认替代模型仍在该商家的许可名单内，且输出通过同一套规则。回退后 HTTP 成功，只表示传输完成。若替代模型违反合同或改变工具行为，功能应暂停或转人工，不能悄悄把任务标成完成。

测跨轮会话，不能只测单条提示

真实任务有上下文。Cloudflare 文档说明，传入 cf-aig-session-id 可建立会话亲和性：同一轮的相关调用可留在一个模型上，利用提示缓存。不带会话 ID，则每次请求可能独立选模型；文档也允许用 cf-aig-turn-id 明确标记一轮，并解释新一轮开始时何时值得切换。若 AI app builder 把请求头藏起来，要问清它如何保持会话及工具调用身份。只测一句话，看不到这些问题。

至少重放三轮：用户先问普通政策，随后透露商品破损，最后上传照片或请求外部动作。检查任务升级后模型是否仍合适；切换后旧指令和政策版本是否还在；工具参数是否符合格式；答案变化能否向用户解释。Cloudflare 发布文提到，切换模型可能丢失前一模型的推理 token，并未保证隐藏推理可以无缝移交。产品应依赖明确、可审计的任务状态，而不是不可见的推理连续性。

提示缓存也会改变经济性。Cloudflare 表示路由时考虑缓存读取和重写费用。短小、独立的测试样本，可能和长期真实会话选出不同模型；两种都要测。记录整段会话的成本：第一轮、后续上下文读取、重写以及回退。单次调用看似便宜、真实客服会话却更贵时，按请求看的报表回答错了问题。

也要测工具失败和资料缺失。耐心重试的模型可能显得积极，实际上产生更多费用和过期写入。订单系统不可用时，验收规则应要求明确说“无法核实”。路由器只优化模型选择，不能授予修改订单的权限，不能变出缺失文档，也不能证明外部动作已成功。这些仍是应用自身的边界。

把隐私和供应商承诺放在优化之外

自动选择可能让客户内容流向另一家供应商。发送请求之前，应按租户和功能限制候选池。Auto Router 文档提供模型及供应商允许名单，但只有应用根据可信的服务端政策设置请求头，名单才真正代表客户约定。不能让用户输入的一段自由文本决定供应商。结果表保存已应用的政策即可，不要默认复制敏感正文。若严格租户隔离无法靠共享凭证和控制实现，就要考虑独立网关或账号架构。

Cloudflare 的网关认证文档提醒：AI Gateway Run token 作用于整个账号，可调用该账号下每个网关，包括保存了供应商密钥的网关。小团队若以为“每个租户发一枚 token”就等于租户隔离，会出现危险误判。token 应留在后端，不能打包进客户端。严格隔离需要按文档评估独立 Cloudflare 账号或 Worker 绑定。即使路由效果再好，凭证设计破坏客户数据边界也不能上线。

日志要单独决策。Cloudflare 的日志文档写明默认启用日志，记录可能包括提示、回复、供应商、费用和耗时；也提供关闭收集，或只保留元数据、不存正文的控制。处理真实客户资料之前先核查设置。如果启用网关 DLP，其文档说明流式回复在扫描时会被缓冲，且政策改变后，缓存里的旧回复不会自动重新扫描。要在真实政策下测试延迟和缓存行为。不要以为自动路由本身兑现了零留存承诺：Cloudflare 仍把 Auto Router 按零留存要求筛选列为后续工作，而 Unified Billing 的 ZDR适用范围更窄，也不控制网关日志。

上线前比较总成本与严重错误

Cloudflare 的分析页面提供请求数、token、错误、缓存命中及估算成本，这些都是有用的运营输入。但它不知道商家是否批准草稿、顾客是否重开工单。把网关请求 ID 接到自己的任务记录，再按风险等级和用户群比较固定路由与自动路由。认真看被拒绝的案例。如果普通物流回复进步，少见但关键的破损例外却退步，总平均值会误导团队。

CedarDesk 可以拟定这样的决策规则：只有自动路由组在预先确定的容差内保持原有验收率；试点中没有新增严重政策或隐私错误；时延达标；把审核和重试算进去后，每份通过草稿的总成本确实下降，才扩大使用。这是需要按业务改写的规则，不是通用数值标准。若例外样本太少，无法估计严重错误发生率，就让该类任务继续用固定模型，继续积累证据。“小样本里没出事”不等于安全已获证明。

先做成对评估，再做小规模真实灰度。成对评估让每份样本在相同政策快照下分别交给固定模型和路由器，由盲审人员打分。进入真实灰度后，把可比任务分配到基线组和候选组，保持商家供应商政策不变，并复核所有关键例外。不要看到答案后才决定哪些任务算候选组；那会扭曲比较。跟踪到最终批准或重开工单，而不只看首条回复。如果加上重试和人工审核后已无实质节省，该功能就继续关闭自动路由。

费用限制与质量控制是两件事。Cloudflare 的费用上限文档说，可以按模型、供应商或元数据设限，超限可能返回 429；文档还提醒限制采用最终一致的统计，并发突发时可能短暂超出。要测试预算被挡住时用户看到什么：安全的替代方案、排队，还是明确的稍后重试提示？无声切换到合同未许可的模型，往往比明确暂停更糟。

制定停止与回滚规则，再逐步放量

先在隐私许可和资料快照允许的范围内跑影子流量：客户仍看到当前模型的结果，候选回复只离线评估。之后给低影响草稿安排小规模自愿试用或受控分组。只有某个分组的验收和总成本都通过预先设定的标准，才扩大到该分组。Cloudflare 的Dynamic Routing 文档描述了有版本的路由流程、流量比例与回滚；若团队用它分流，要把这项功能的配置与 Auto Router 的模型选择分别核验。也可以直接在应用里控制分组开关。

试点必须有负责人和紧急停止开关。发生隐私越界、未经许可的供应商、严重错误动作、重复的政策幻觉，或无法解释的验收率下降，就回滚。费用问题则看持续的任务级趋势，而不是一次尖峰。保留固定模型的基线路径，让回滚成为配置变更，而非紧急重新构建。记录路由版本、许可候选池与回滚时间，日后才能诚实解释受影响的客户请求。

放量前做一次故障演练：模拟供应商不可用、路由器超时、费用上限拒绝以及会话 ID 缺失。路由原因清单明确列有供应商回退、路由错误、超时和输入不支持等情况。确认应用能区分“回退模型成功响应”和“客户任务完成”。确认写入动作中断后，系统会先核查外部效果，再决定是否重试。模型路由器负责可用性选择，客户状态与恢复仍由你的应用负责。

什么时候固定模型更合适

任务有明确的特定能力需求、供应商合同、难以观测的错误，或流量太少不足以验证路由时，固定模型很合理。某个模型独有的能力甚至可能是你对客户的承诺。创始人不应为了显得架构先进，把承诺藏进 auto。如果所有请求都差不多，现有模型已以可预测的成本达标，多出一层路由判断和运维复杂度可能不划算。

当工作负载同时包含简单和复杂任务，团队能写出明确的结果评分规则，合同允许供应商灵活选择，而且流量足以比较时，自动路由才更有吸引力。即便如此，敏感群体也应维持固定路线，直到该群体自己的证据充分。公开测试版不会替你提供商家的政策真相、审核员或客户沟通方案；它提供的是一种从合格模型中选择的机制。只有产品能识别“选得好”与“错得便宜”，优势才会落地。

创始人今天可以先做三份文档：说明哪些请求可路由的任务清单、针对完整客户结果的验收规则，以及包含供应商政策和决策 ID 的路由记录。启动一个最小、可撤回、能够推翻节省假设的试点。通过了，就按用户群逐步扩大；没通过，也能看出问题究竟出在模型质量、路由选择、资料来源、供应商政策，还是工作流程。这比又一个排行榜名次更能指导下一次产品决策。

参考资料

发布了什么，哪些仍是厂商主张

先定义价值单位，再比较账单

先划出允许路由的任务边界

用客户验收标准做评估表

字段	每件任务要记录什么	为什么需要
任务与用户分组	功能、语言、客户层级、风险等级	总平均值可能掩盖某个薄弱群体
输入快照	脱敏样本编号、资料版本、政策版本	便于重放，也能复核争议
路由政策	允许的模型/供应商、网关配置版本	候选池可能变化
决策轨迹	实际模型、路由原因、决策 ID、请求 ID	知道到底是谁服务了用户
任务结果	通过、需修改、拒绝或未解决；附审核理由	衡量可用成果，不只衡量语言流畅度
错误严重度	风格瑕疵、事实错误、隐私泄露、错误动作	严重回归不能被平均分淹没
总投入	调用、重试、回退、审核分钟数、总耗时	看见隐性成本
用户证据	批准、编辑、重开、投诉或放弃	将测试分数连到真实体验