2026 年 10 月这一周，OpenAI 的 Decisions API 进入公开测试、微软发布专门做决策打分的模型、日本法律科技公司 LegalOn 公开了按任务复杂度分配模型后日成本下降约 65% 的数据。三件事指向同一个结论：模型能力正在被切分成不同价位档位，成本优化的主战场已经从选型转移到路由。本文把这件事拆成任务分类、路由设计、预算控制、评测验证四层，给出可执行的落地顺序。
很多团队谈 AI 成本时，第一反应是「换一个便宜点的模型」。这个动作通常只能省下 10% 到 20%，而且经常以质量下降为代价。真正有效的做法是另一件事：先对任务做分类，再决定每个任务该用哪一档模型、哪种调用方式、多少次重试。
2026 年 10 月这一周，行业里同时出现了几件事：OpenAI 的 Decisions API 进入公开测试，微软发布专门做决策打分的模型，日本一家法律科技公司公开了按任务复杂度分配模型后的成本数据。这三件事指向同一个结论——模型能力正在被切分成不同价位档位，成本优化的主战场已经从「选型」转移到了「路由」。
本文把这件事拆成可执行的四层：成本结构的变化、失控的四个来源、路由系统的设计方法、预算与评测体系怎么配套。文末给出一个可以照着做的落地顺序。
---
过去所有的请求都扔给同一个对话模型，是因为对话模型既是通用接口又是唯一选项。现在情况变了。
据 2026 年 10 月 10 日的每日 AI 速览记录，OpenAI 的 Decisions API 已进入公开测试阶段，运行在 GPT-6 Luna 上，输出形态不是自然语言，而是概率、选项和评分这类结构化决策结果。官方给出的对比是：比 Responses API 返回 typed answers 快约 10 倍，计费为每百万输入 token 0.10 美元且不收输出费用。
同一天，微软发布了 Microsoft-Decision-1，这个模型基于 Qwen3.5-9B，定位就是快速分类、路由和决策打分。
这两个动作在架构上意味着同一件事：一个成熟系统里，「做判断」和「写内容」已经是两种不同的任务，值得用两种不同的模型。凡是只需要输出一个标签、一个分数、一个分支选择的环节，都不应该再走对话模型。
2026 年 10 月 9 日，日本法律科技公司 LegalOn Technologies 披露了一组数据：在 Codex 开发流程中按任务复杂度分配不同模型后，在保持开发速度的前提下，预估日成本较此前降低约 65%。
它公开的选型规则非常朴素，值得直接借鉴：
| 任务类型 | 使用档位 |
|---|---|
| 需求明确的代码实现 | 最轻量模型（GPT-6 Luna） |
| 标准设计、数据分析、文档准备 | 标准档模型（GPT-6.1 Sol） |
| 架构设计等高级判断 | 最强档模型（GPT-6 Astra） |
配套的三条管理动作同样具体：把 Fast 模式从默认开启改为默认关闭、按需单独申请；在部门、小组、个人三级设置 AI 预算上限；对成熟业务要求提升约 20% 的成本效率，而对启动期的新业务给宽松预算。
这组数字的价值在于它同时动了两个变量：模型分档和开关策略。单独做其中任何一项，降幅都远达不到 65%。
图像与视频侧的降本路径更直观。据阿里通义官方公布的信息，Qwen-Image-2.1-Turbo 把生成和编辑所需的去噪步数从默认的 40 步降到 8 步，在同一 7B 架构上相当于减少了约 5 倍的去噪计算量。这类在推理步数上做优化的收益是直接体现在单位任务成本上的，和模型参数规模无关。
另一个值得注意的方向是激活参数。2026 年 10 月 10 日的消息显示，Mistral 发布了 Mistral Large 4 预览版，这是一款 1T 参数、但只有 49B 激活参数的原生多模态开源权重模型，训练用了 3800 张 NVIDIA Grace Blackwell GPU。对调用方而言，1T 和 49B 是两个完全不同的成本概念——计价和延迟看的是激活量，不是总量。
同日，Anthropic 为 Claude Managed Agents 加入 dynamic workflows，允许一个主 Agent 并行调度最多 1000 个子 Agent。在其公布的测试数据中，单个 Agent 在 70 个隐藏 bug 中最多找到 27 个，而多智能体工作流稳定找到 66 个。
66 比 27 的效果提升是真实的，但代价是调用量结构完全改变：主 Agent 调度 10 个子 Agent，等于一次业务动作产生十几次模型调用。Google 同期推出的办公 Gemini agent 更进一步，允许管理者创建拥有独立 Workspace 邮箱、日历和目录条目的「同事 Agent」，还带有支出控制能力——厂商已经把「Agent 身份 + 预算」做成了产品功能，这本身就说明调用成本已经大到需要被单独管理。
所以在多智能体编排下，成本不再是「请求数 × 单价」，而是「任务树节点数 × 单价 × 平均分支数」。
---
在谈优化之前，需要先定位钱花在哪。下面四个来源，按实际项目中出现的频率排序。
这是最普遍、也最容易修的一种浪费。典型表现是：团队只有一个模型配置入口，所有请求共用；或者架构上把所有逻辑串成一条长链，无论任务是「把这段 JSON 提取出 status 字段」还是「重新设计订单状态机」，都走同一个模型。
判断方法很简单：打开调用日志，看输入输出的长度比和任务类型分布。如果大量请求的输出只有几十个 token，说明这些任务本该走更便宜的档位。
上下文是按 token 计价的，而且很多任务的失败重试会把同样的长上下文反复重发。常见的膨胀来源：
这类问题在 RAG 场景里尤其突出——召回环节省下来的算力，很容易在上下文组装环节被浪费掉。关于检索质量的工程手段，可以参考站内 提升知识库问答准确率的工程手段 一文中的分环节拆解。
失败重试是最容易被忽略的成本项。一个典型的循环是：调用 → 返回格式不符合预期 → 重试 → 仍然不符合 → 再重试。如果在提示词层面不约束输出格式，这三次调用的上下文是几乎一样的。
编排层面的放大更严重。多 Agent 工作流里的失败节点如果触发整棵子树重跑，成本会以几何级数上升。判断编排是否失控，有一个简单指标：单次用户动作的平均模型调用次数。如果这个数字超过 5，值得停下来重新设计流程。
很多团队说不清「上个月 AI 花在哪了」，只能看到一个总账单。这种情况下任何优化都是盲目的——你无法验证换了模型之后到底省了多少，也无法判断某个功能模块是否在持续亏损。
成本可见性的最低要求是：按业务功能、按模型、按调用方三个维度分开记录。LegalOn 把预算下沉到部门、小组、个人三级，逻辑上也是这个——只有能归因，才谈得上控制。
---
正确顺序是：先把系统里的调用按任务性质分类，再为每一类指定档位。分类依据建议用下面这四个维度：
按这四个维度分完，档位映射基本是自然结果：
| 任务类型 | 推荐档位 | 典型做法 |
|---|---|---|
| 分类、打分、路由分支 | 决策类轻量模型 | 输出结构化结果，不做文本生成 |
| 意图识别、参数抽取 | 轻量或标准档 | 约束输出格式，禁止自由文本 |
| 标准代码实现、文档改写 | 标准档 | 加明确的任务说明与验收条件 |
| 架构设计、复杂权衡 | 最强档 | 强制人工确认，不自动进主干 |
这张表的价值在于它可以直接写成代码里的配置，而不需要每次开会讨论。
路由可以放在三个位置，各有适用场景：
放在应用层——由业务代码显式指定用哪个模型。控制力最强，可读性最好，适合任务类型清晰、路由规则稳定的系统。缺点是每加一个功能就要改一次配置。
放在网关层——由模型推理网关根据请求特征自动判定。这适合调用点分散、不希望每个业务模块都关心模型选择的场景。代价是网关需要能识别任务类型，这通常要求请求里带上明确的结构化标记。
放在客户端 SDK——由 SDK 按本地规则路由。响应最快，但规则分散在多个项目里，容易漂移。
实践中的建议是：规则先在应用层跑通，验证有效后再下沉到网关。反过来做——先在网关里堆规则——往往会得到一堆无法解释的路由结果。
路由系统必须考虑两件事：便宜档位质量不够时怎么办，便宜档位不可用时怎么办。
---
技术手段只能解决一半问题。LegalOn 的做法里，模型选型指南、三级预算上限、Fast 模式默认关闭这几条，本质上是把技术选择变成了管理动作。
对研发团队来说，至少要建立这三件事：
成本基线。 在优化之前先记录一段时间的消耗，明确当前每个功能模块的月均成本。没有基线的优化无法验证效果。
预算上限的层级。 参照 LegalOn 的部门、小组、个人三级设计。团队级上限用于控制总量，模块级上限用于快速定位异常，个人级上限用于约束单个高频调用场景。
高成本选项默认关闭。 把 Fast 模式、超长上下文、额外检索轮次这类明显拉高单价的开关改成默认关闭、按需申请。这一条几乎不需要技术改动，却是单项收益最高的措施之一。
---
这是最容易被跳过、但最不该跳过的一步。降本方案如果没有配套评测，就是把风险推迟到线上事故里。
最低可行的验证方式是建一个固定评测集，控制在几十条到一两百条量级即可：
真正要回答的问题是：在什么质量水平上，成本还能继续压缩。这个拐点通常比想象中靠前——大量任务在轻量档位上就已经达到可用质量，只是没人去试过。
评测体系搭起来之后，再回过头看 大模型私有化部署的决策要点 中的成本结构对比，会发现很多判断标准是通用的：单位成本之外，还要看运维成本、容量成本和容量利用率。
---
按这个顺序做，每一步都能独立产生价值，不需要等前面的步骤全部完成：
需要强调的是，这套顺序里最容易被跳过的是第 5 步。没有评测，前四步的收益无法证明，第 6 步的下沉就没有依据。
---
把降本当成降质的同义词。 大量任务的成本浪费来自用错档位，不是模型本身太贵。先做任务分类，往往能在不损失质量的前提下省下可观成本。
只算调用成本，不算失败成本。 一次失败调用同样计费。一个失败重试率 30% 的链路，优化方向应该是降低失败率，而不是换更便宜的模型。
把路由规则写死在业务代码里散落各处。 规则分散后没人能说清当前到底怎么路由，也就无法优化。路由配置应该集中、可读、可版本管理。
用总量指标代替结构指标。 「这个月省了 30%」不如「中等难度任务的单位成本降到了原来的 45%，复杂任务的单位成本上升了 5%，总交付量上升了 12%」有信息量。降本如果伴随交付量下降，那不叫优化。
迷信单一指标。 调用量、token 数、响应延迟、质量通过率这几个指标经常互相冲突，需要一起看。任何一个单独的指标被当成优化目标，都会被绕过。
---
对正在做 人工智能应用开发 或 软件研发 项目的团队来说，上面这套方法的核心是把模型选择变成工程决策而不是采购决策。模型推理网关的搭建、任务分类与路由规则的落地，本身就是 软件研发服务 中的常规工程内容。
如果需要在具体场景中评估实施路径，可以先看 技术能力 中关于大模型应用集成的说明，或者从 行业动态 里找同类场景的落地方案。智能体场景的工程断点分析见 AI Agent 企业落地方案，多智能体编排的成本放大效应在那里有更详细的讨论。
最有效的做法不是换一个更便宜的模型，而是先对系统里的调用做任务分类，再为每一类指定不同的模型档位。2026 年 10 月 9 日，日本法律科技公司 LegalOn Technologies 披露，在 Codex 开发流程中按任务复杂度分配模型后，预估日成本较此前降低约 65%，同时保持开发速度。配套动作包括把 Fast 模式改为默认关闭、在部门与小组与个人三级设置 AI 预算上限，以及对成熟业务要求提升约 20% 的成本效率。单独换模型通常只能省 10% 到 20%，且常伴随质量下降。
建议规则先在应用层跑通，验证有效后再下沉到网关。应用层的优势是控制力最强、代码里可读、便于排查；缺点是每加一个功能要改一次配置。网关层适合调用点分散、不希望每个业务模块都关心模型选择的场景，代价是网关必须能识别任务类型，通常要求请求携带明确的结构化标记。先在网关堆规则往往会得到一堆无法解释的路由结果。
输出形态是标签、分数或分支选择的任务最适合。按四个维度判断：输出是否只需要结构化结果、推理是一步还是多步、错误能否被下游发现、调用频次与时长。高频短请求且容错空间大的场景——比如意图识别、参数抽取、分类与路由——应走轻量档位或决策类模型。涉及合规判断与对客承诺的输出则应标记为不可路由，宁可多花钱也不降级。
会，而且放大效应显著。2026 年 10 月 10 日的消息显示，Anthropic 为 Claude Managed Agents 加入的 dynamic workflows 允许一个主 Agent 并行调度最多 1000 个子 Agent。主 Agent 调度 10 个子 Agent，等于一次业务动作产生十几次模型调用，成本结构从「请求数乘单价」变成「任务树节点数乘单价乘平均分支数」。判断编排是否失控有一个简单指标：单次用户动作的平均模型调用次数，超过 5 就值得重新设计流程。
需要配套一个固定的评测集，控制在几十条到一两百条量级即可。要求是：从真实场景抽样并覆盖各类任务、固定输入与判分标准以保证可比性、每次换模型或改路由都跑一遍并保留历史结果做趋势对比、同时记录成本与正确率画出关系曲线。真正要回答的问题是「在什么质量水平上成本还能继续压缩」，这个拐点通常比想象中靠前。降本如果没有评测，就是把风险推迟到线上事故里。
不够。成本可见性的最低要求是按业务功能、按模型、按调用方三个维度分开记录。只有能归因才谈得上控制，因为不归因就无法验证换模型之后到底省了多少，也无法判断哪个功能模块在持续亏损。团队级上限控制总量，模块级上限用于快速定位异常，个人级上限用于约束单个高频调用场景，这一层级划分与 LegalOn 公开的三级预算设计思路一致。