工作流虚拟模型：不止是 LLM 路由

大多数模型网关提供的是一种简单抽象：客户端请求一个模型名，网关选择供应商或者把请求转发出去。这个抽象很有价值，但它通常不会改变模型本身的行为。

工作流虚拟模型更进一步。模型名背后对应的是一个可执行工作流，它可以调用多个模型、使用工具、执行分支、验证中间结果，最后综合成一个回答。对客户端来说，它仍然只是一个普通模型端点。

Agent 客户端
  -> 虚拟模型端点
  -> 工作流
     -> 主规划模型
     -> 视觉或搜索工具
     -> 并行评审模型
     -> 综合模型
  -> 带完整轨迹的最终回答

路由选择模型，工作流组合行为

模型路由主要回答“哪个供应商可用”或者“这次请求用哪个模型成本更低”。工作流处理的是另一类问题：

• 文本模型是否应该调用视觉模型检查截图？
• 是否需要三个模型并行评审同一份实现？
• 当输出不符合 Schema 时，验证节点是否应该拒绝结果？
• 哪一个节点制造了延迟或 Token 峰值？

这些决策共同构成了客户端最终看到的“模型行为”。工作流发布成模型后，所有兼容客户端都能复用相同行为，不必各自重复实现编排。

为什么协议兼容很重要

本地 Agent 工具已经理解主流模型 API。Claude Code、Codex、OpenCode、Cline、Continue 和应用 SDK 不应该为每一种工作流再开发专用集成。

通过 OpenAI Responses、Chat Completions 或 Claude Messages API 发布工作流，可以把客户端需要知道的内容继续保持在很小的范围：

Base URL + API Key + 模型名

工作流可以在这个契约背后持续演化。单模型链路可以升级成视觉增强工作流或者多模型评审面板，而不用修改每一个客户端。

可观测性必须跟随工作流图

当一个回答包含多次模型调用和工具回调时，请求级日志已经不够。开发者需要把最终答案关联到：

1. 实际执行过的每个工作流节点。
2. 每次模型调用的准确输入与输出。
3. 工具参数、返回结果、耗时与错误。
4. 每个分支的 Token 消耗和延迟。
5. 生成最终回答的综合步骤。

这种图结构证据能把“感觉答案不对”变成一个可以调试的系统。薄弱的评审模型、昂贵的分支或者失败的视觉工具都能被直接定位。

什么时候适合使用虚拟模型

当同一种增强行为需要被多个客户端复用、编排已经超过简单供应商选择，或者需要完整执行证据时，工作流虚拟模型是合适的抽象。

如果一次供应商调用已经足够，就继续使用直接模型端点。目标不是给每个请求都增加一张图，而是让真正有价值的组合能力可以复用、发布和观测。

1flowbase 为这种模式提供可视化运行时、协议发布和执行轨迹。可以先阅读 Fusion 工作流教程，或者直接查看项目源码。