单个模型对应单个 AI 工作流：为何这是一种错误的抽象

Dev.to ML 2026-07-28T05:14:47.147209

为什么每个AI工作流都用一个模型是错误的设计

大多数AI应用都把模型选择当作一个配置选项来对待：

const response = await client.chat.completions.create({
  model: "openai/gpt-5",
  messages,
});

开发阶段团队选了一个能力够强的模型，上线后，该路径上的每一次请求就都走同一个模型。这可以理解：更强的模型确实能干活。换掉它可能引起细微的质量回退。通用的模型基准测试很少能代表应用真实业务需求，而评估每一个更便宜的替代品又很花时间。

但随着流量增长，这个安全决策就变成了基础设施税。我在构建 MargIQ 时一直围绕一个简单的论点：模型选择应该基于业务工作流的需求——而不是通用基准、token 数，或者开发者最初选的那个模型。

适合一个工作流的模型，用在另一个工作流上可能很浪费。甚至同一个工作流内部，适合常规请求的模型，对下一个请求可能就不安全。

“用更便宜的模型”不是解决方案

考虑四个常见的 AI 工作流：

• 对客户支持请求进行分类
• 从发票中提取结构化字段
• 总结一篇长内部政策文档
• 分析一个可能的安全事件

它们可能都使用同一个 API 和同一个供应商，但需求完全不同。在换模型之前，我们需要搞清楚业务任务：

• 输出必须满足严格的 JSON schema 吗？
• 模型需要用有效参数调用工具吗？
• 错误答案的代价有多大？
• 输出会影响财务、法律、隐私或安全决策吗？
• 语气重要吗？
• 上下文是否异常长？
• 哪些字段或行为必须始终保持正确？
• 什么情况下工作流必须升级给人处理？

一个模型可能在公共基准上表现很好，但对特定工作流却可能出错。反过来也一样：一个小模型可能完全胜任一个范围有限的分类或提取任务。把这类工作交给前沿模型，不一定会改善业务结果——可能只是增加了账单。

所以问题不是：哪个模型最好？

标题：每个 AI 工作流只配一个模型？这个抽象有问题

真正的问题是：在当前可用模型中，哪一个能满足这个工作流的需求，我们有什么证据支撑？工作流才是模型选择的第一个实用单元。一个反复出现的流程，比一个泛泛的提示词分类蕴含更多信息——它的系统指令、工具、响应格式、供应商、请求的模型和消息结构，共同描述了应用试图完成的任务。通过长期观察这个稳定结构，系统可以开始区分：

• 常规分类 vs. 敏感决策支持
• 自由写作 vs. 按模式提取
• 工具选择 vs. 直接回答
• 长上下文总结 vs. 短意图路由
• 低风险操作 vs. 需要更强判断力的请求

这就是 MargIQ 的第一层。它包装一个兼容 OpenAI 的客户端，识别反复出现的工作流，分析其业务和技术需求，并从应用自身的允许列表中评估模型。应用仍然可以请求它原本信任的模型——这个请求的模型仍然是质量锚点和回退选项。MargIQ 可以先以 仅报告模式 运行，在不改变生产执行的情况下，展示哪个低成本模型似乎更合适。只有当某个工作流积累了足够的证据后，路由才会成为可选方案。

但一个工作流仍然不应该只对应一个模型。

基于工作流选择模型，比给整个应用选一个模型好，但这还不够。同一个工作流中的单次请求，其复杂性、风险和后果可能天差地别。以电商客服工作流为例，它包含的工具包括：查询订单、创建退款单、将问题升级给人工。一个请求说：「你能查一下我的订单为什么还没发货吗？」这是边界清晰的操作性工作，模型只需识别订单并调用对应的查询工具。而同一个工作流中另一个请求则报告：损坏的产品导致了人员受伤，要求立即退款，并威胁公开曝光。同一个应用功能，同一条系统指令，同一套工具定义——但如果模型搞错了，后果完全不同。

每个AI工作流只用一个模型是错误抽象

把两个请求都路由到最便宜的模型是不负责任的；都路由到最强的模型虽然安全，但可能造成浪费。工作流定义的是业务任务，而每个单独的请求决定了该次执行需要多少能力和安全性。这正是MargIQ的策略可以在一个工作流内包含多个请求路径的原因。实时的请求上下文可以自动选择一条经过批准的、成本更低的路径，也可以保留请求所用的模型，或者当请求无法匹配已知路径时收集更多证据。

决策流程的关键

重要的行为不是“正常路径”，而是“降级路径”。如果工作流未知、策略尚未就绪、实时请求不匹配任何已批准的路径、或者请求存在风险或歧义，应用程序就使用请求自带的模型。

我在受控基准测试中发现的

目前的MargIQ沙盒定义了15个工作流家族，包括：
- 意图与支持分类
- 发票与CRM提取
- 政策与会议摘要
- 客户支持写作
- 评论审核
- 线索资格认定
- PII处理
- 代码审查分类
- 多轮客户聊天
- 基于工具型的电商支持
- 动态请求形态与安全邻域测试

此外还包含21个显式评估场景，涵盖：
- 改述表达
- 多语言输入
- 噪声OCR
- 长上下文
- 安全邻域
- 凭证泄露
- 授权漏洞

在一个保留的58个请求的受控基准测试快照中，MargIQ检测到了7个重复出现的工作流。两条策略在0.96置信度下被激活。两个事务级路由决策包含了完整的成本节省证据：

同一个电商工作流中，更高风险的退款和安全请求仍保留在GPT-5上。另一个支持分类工作流则被阻止优化，原因是候选输出在决策关键字段上存在分歧，而基准测试中缺乏解决分歧的权威质量定义。这个被阻止的工作流与那些成本节省的例子同样重要。

查看原文