便宜模型出错、人修一小时更贵：福建企业上 AI 自动路由前的四步
一、先说结论
据 InfoQ 报道（媒体口径），Cloudflare 通过 AI Gateway 推出 Auto Router 公测版：把模型名填成 cloudflare/auto，网关就替每个请求挑模型，业务代码不必自己判断用哪个。真正值钱的不是功能本身，而是官方一并公布的一项基准——自家路由器在「省钱」与「可靠」之间的量化取舍：约 97 个任务、每模型采样三次、做了 1 万次 Bootstrap 重采样，可靠性提高约 10 个百分点、成本约为原来的三分之一（官方披露/媒体口径）。
更该记住那句业内反复引用的提醒：从事智能体工程的 CTO Jacques B 指出，如果结果还要人额外花一小时去修，更便宜的模型并没省下多少成本（媒体口径）。
对福建企业，结论要落到自己身上：把 AI 用起来之后，第一笔该算的不是单次调用的单价，而是「出错—返工—重跑」这条链上的总人力；模型选择这件事，得能看见、能审计、能收回。 本文不谈报价与采购，只给 IT 部门能起步的四步和三个坑。
二、这次到底变了什么
别急着对号入座，先看清楚变的是什么：
| 维度 | 过去常见做法 | Auto Router 公测版（官方披露/媒体口径） |
|---|---|---|
| 选模型 | 业务代码写死一个模型，或按场景手动切 | 网关按请求动态选，模型名填 cloudflare/auto 即可 |
| 路由机制 | 无 | 两阶段：先建候选模型池（过滤请求格式、凭证、计费、访问控制、支出限制），再由边缘 GPU 上的多头分类模型按 14 类任务、四维度（复杂性/歧义性/风险/对前文依赖）做 1～5 级评分 |
| 判定公式 | 无 | 「效用 = 预期质量 − 自适应成本惩罚」；任务越难，价格权重越低 |
| 上下文 | 看全量或写死规则 | 只依据最近几轮分类，文本上限 8KiB |
| 可审计性 | 基本黑盒 | 响应带 cf-aig-routed-model、cf-aig-routing-reason（如 cost_optimal_within_pool、pinned_by_turn），可事后复盘；可用请求头按单请求限定模型池与供应商 |
| 量化结果 | 无 | 97 任务 ×3 采样 + 1 万次 Bootstrap，可靠性 +约 10 个百分点、成本约 1/3 |
| 边界 | — | 公测期免费、正式定价未公布；不支持 WebSocket，仅 Chat Completions / Responses API；路线图另有 cloudflare/auto-best（不考虑成本取舍、只挑预期质量最高的模型） |
一句话：变的不是「哪个模型更强」，而是模型选择从写死在代码里，变成网关里一次可观测、可审计的运行期决策。
补一句口径：那 10 个百分点和 1/3 是 Cloudflare 自家基准成绩（官方披露）；默认模型池「可能随时间变化」，Opus 5.5、GPT-6 Sol 两项基线还在默认池之外、需请求头启用（媒体口径）。当「取舍可见」的信号，别当「效果承诺」。
三、福建企业真正能用在哪
- 已接大模型客服、询价、工单的（厦门跨境电商、泉州鞋服外贸）：把「简单问题走便宜模型、复杂问题走强模型」从拍脑袋变成网关策略，每次选择留痕；客户对答复有争议时，能回溯当时用了哪个模型。
- 多部门各接各的模型、账单对不上的（福州软件园、集团型制造）：用一个网关统一凭证、计费、访问控制和支出上限，先把「谁在调、调了多少」收拢到一处，再谈优化。
- 做单据与文档处理的（财务对账、报关单、质检记录）：这类任务复杂性、风险差别天然很大，正适合按任务分级路由；但风险标签得由应用自己跨轮次维护，不能让一句「继续执行」把风险等级降下来（媒体口径里技术负责人 Igor Pyrin 的提醒）。
- 准备把 demo 变生产的团队：借这次公测把「模型选择日志 + 会话 ID + 提示词缓存」补齐——没有会话 ID，同一对话可能被分给不同模型，缓存复用不了，成本反而上去（官方披露）。
多模型、长会话还有一步前置：先让每个请求都带上稳定的会话 ID 和最小风险标签，再谈自动路由，顺序别反。
四、可照做的四步
一、先把「模型选择」记下来，不急着改路由。 在调用链里加三个字段：请求时间、实际用的模型、任务类型（自定义 3～5 类）。跑一两周就有了真实的分布图，才知道哪些「便宜模型就能过」、哪些一错就要人擦屁股。别一上来就换网关。
二、给任务分级，明确「哪些绝不能省」。 用四维度列张简表：复杂性、歧义性、风险、对前文依赖。把涉及金额、客户数据、对外发文、提交动作的标成「高风险」，写死走强模型或人工复核——路由器只看最近几轮、上限 8KiB，一句短指令可能悄悄降低风险等级（媒体口径）。
三、让每次选择可审计、可收回。 要求网关或中间层返回「选了哪个模型、为什么选」（对应 cf-aig-routed-model、cf-aig-routing-reason 一类字段，官方披露）；保留按单请求限定模型池的能力，出问题能一键把某类任务钉回固定模型，日志按会话 ID 串起来。
四、用「总人力」验收，不用「单次单价」验收。 挑两三个高频任务做 A/B：一组走自动路由、一组走固定强模型，各跑一批，比的不只是调用账单，还有返工次数、人工修正时长、客户投诉。官方基准的价值，正在于把「可靠性 +10 个百分点 / 成本约 1/3」摆上同一张桌、让团队自己站队（官方披露）。人工复核与回滚脚本先就位，自动执行放最后。
五、三个坑
坑一：把「成本约 1/3」当成自家账单会降 1/3。 那是特定任务集、特定模型池下的基准成绩（官方披露）；模型池会漂移、两项基线还在默认池之外，复现前先确认网关实际选了哪些模型（媒体口径）。当立项参考可以，当预算依据会翻车。
坑二：把风险判断全交给「最近几轮」。 长会话里关键约束往往很早就说过，而真正提交操作的那一轮，恰恰看起来最「便宜」（媒体口径）。跨轮次风险标签必须应用自己维护，别指望 8KiB 窗口替你记住。
坑三：只盯路由、不盯会话与缓存。 没有会话 ID，同一对话被分到不同模型，提示词缓存复用不了、还可能重新生成推理 Token 按输出价格计费；另有随上下文增长的模型切换惩罚（官方披露）。省下的单价，很容易赔在重跑上。
六、什么时候上、什么时候别上
可以上： 已稳定调用大模型、任务难度明显分层的；多部门、多供应商各接各的、想统一网关与支出上限的；准备把 AI demo 转生产、需给每次模型选择留痕的；IT 人手少、不想为每个场景写死模型的。这类企业第一步就见效，因为调用本来就在跑，只差把它管起来。
先别上： 还在选模型、跑 PoC、连「哪类任务算复杂」都没定义的——先把第一步日志跑两周；单一固定任务、一个模型就够，加路由只添变量；强合规、强可解释场景且尚无人工复核岗；正处大版本上线或割接窗口。另外，公测期免费、正式定价未公布、暂不支持 WebSocket（官方披露），依赖 WebSocket 的实时应用现在别迁。
模型会一直换，但「选了哪个、为什么、错了谁负责、能不能退回去」这四件事，得由企业自己钉在系统里——路由可以交给网关，责任要留在自己手上。