Smart LLM Routing for AI Agents CN
大多数 AI Agent 客户端一开始都会配置一个模型。这样接入最简单，但很快会遇到问题：
简单任务不需要最贵的模型。
复杂代码和推理任务可能需要更强的模型。
图片、文件、浏览器、工具调用任务可能需要另一条模型链路。
供应商不可用时需要 fallback。
你的客户不应该自己配置每个供应商、API key、模型和路由规则。
1flowbase 的智能路由不是让用户手动切模型，而是把路由做成一个可发布、可观测的工作流虚拟模型接口。
路由的价值不只是“选一个更便宜的模型”。真正有用的是：你能看到为什么选择这条 route，哪个分支花了 tokens，fallback 发生在哪里，以及最终答案有没有因为这次路由变好。
外部客户端仍然只调用一个模型名。1flowbase 内部可以让主模型调用一个挂载工具，切换到对应分支 LLM，让分支 LLM 使用开放的外部工具完成任务，然后把结果以 tool result 的形式返回给主节点。
Claude Code / Codex / Cursor / SDK
-> 一个 1flowbase 虚拟模型接口
-> 主 LLM
-> 智能路由工具
-> 可使用外部工具的分支 LLM
-> Tool Result
-> 主 LLM 输出最终答案
这和隐藏式 LLM router 不一样。你可以在运行日志里看到路由、工具调用、分支模型执行、Token、延迟、失败状态和最终结果。
之前的多模态模式是把视觉模型挂成工具。分支 LLM 主要读取上传图片块，把视觉上下文返回给主模型。
智能路由更进一步：
- 分支 LLM 可以接管被路由的任务。
- 分支 LLM 可以调用你开放给它的外部工具。
- 分支结果会以结构化 tool result 返回给主节点。
- 客户端仍然只看到一个普通模型接口。
可以简单理解为：
多模态挂载：分支模型负责读取媒体。
智能路由：分支模型可以带着工具完成工作，并把结果返回。
当被路由的任务不只是“换个模型回答”，而是需要工具权限、文件读取、浏览器或应用工具时，就适合使用智能路由。
适合：
- 把截图、文件检查、代码定位交给能调用
Read、Glob、浏览器、OCR 或内部工具的模型。 - 把分类、格式化、抽取这类简单任务交给便宜模型或本地模型。
- 把复杂代码、规划、审查交给更强模型。
- 把隐私数据路由到本地或国内供应商。
- 当主供应商失败时，路由到 fallback 模型。
- 给产品用户暴露一个模型接口，把供应商复杂度留在 1flowbase 内部。
不适合：
- 普通单模型回答已经足够。
- 你不希望分支模型使用工具。
- 无法接受额外延迟。
- 还没有审查分支模型的工具权限边界。
这个演示里，外部客户端是 Claude Code。用户只发了一个普通请求：
uploads\test-01.png
看看这张图代码在哪里？
Claude Code 不需要知道应该由哪个模型看图、哪个模型读文件、哪个模型定位代码。它只需要调用 1flowbase 发布出来的虚拟模型接口。
在 1flowbase 内部，主 LLM 判断这类图片和文件定位任务应该交给挂载的智能路由工具。这个工具会切换到配置好的分支 LLM，让分支 LLM 使用外部工具，然后把结果返回给主 LLM。
最小结构如下：
Start
-> 主 LLM：面向用户推理并输出最终答案
-> 挂载工具：image_llm
-> 分支 LLM：适合该任务的模型
-> 外部工具：Read / Glob / browser / app tools
-> Tool Result：结构化子任务结果
-> 主 LLM：最终回复
主模型不必自己完成所有步骤。它可以把一个子任务交给智能路由工具，然后根据返回结果回答用户。
打开主 LLM 节点设置，开启 Mount LLM，然后添加一个工具注册。
演示里使用：
Tool name: image_llm
Tool identifier: tool_1
工具描述要告诉主模型什么时候走这个路由。例如：
当用户要求检查图片、文件路径、截图、代码位置、UI 截图或上传媒体时，调用这个工具。被路由的模型可以使用已开放的外部工具读取文件、检查上下文，并返回结构化结果。
工具名不是重点。重点是描述要给主模型一个清晰的路由策略。
在工具注册里：
- 开启 Allow branch LLM。
- 将 Tool mode 设置为
Smart routing。 - 开启 open external tools。
这几个开关会改变执行方式：
- Allow branch LLM 允许挂载工具调用下游 LLM 节点。
- Smart routing 表示这是一次任务交接，而不是简单文本转换。
- open external tools 允许分支 LLM 使用你开放给它的外部工具。
只给确实需要工具的路由开启外部工具。分支模型能力更强以后，边界也要更清楚。
根据任务选择分支 LLM。
例子：
image_llm -> 视觉或 UI 检查模型
code_llm -> 更强的代码模型
cheap_llm -> 简单任务用便宜或本地模型
private_llm -> 隐私数据用本地或国内供应商
fallback_llm -> 主供应商失败时的备用模型
在截图演示里，分支模型可以检查上传路径，调用 Read 或 Glob 等工具，返回相关文件位置和实现细节。
建议让分支结果足够具体：
- 检查过哪些文件
- 可能的代码位置
- 相关组件或路由
- 找到的证据
- 下一步操作或需要用户补充的问题
这样主 LLM 的最终回答会基于分支实际做过的工作，而不是凭空猜测。
把 Claude Code、Codex、Cursor、OpenCode、Cline、Continue、LibreChat 或其他客户端配置到 1flowbase 发布的 endpoint。
概念上只需要：
Base URL: 你的 1flowbase endpoint base URL
API key: 你的 1flowbase app key
Model: 发布出来的虚拟模型名
Protocol: Claude-compatible Messages API 或 OpenAI-compatible API
然后像平常一样发送用户请求。
客户端不需要配置 DeepSeek、GLM、Claude、Gemini、OpenRouter、fallback、分支工具和模型路由规则。它只调用一个模型接口。
打开 Log，选择本次运行，再打开 Conversation log 和 Track 标签。
演示日志里可以看到：
- 普通工具尝试，例如
Glob和Read image_llm Smart routing Interceptedimage_llm Smart routing Executed successfully- 工具输入里出现
type: "visible_internal_llm_tool" - 媒体引用，例如
uploads/test-01.png - 右侧 Run details 里返回最终答案
这就是 1flowbase 的核心价值：路由不是黑盒。你能看到用了哪个路由、被路由模型收到了什么、开放了哪些工具，以及什么结果回到了主节点。
生产使用时，建议让路由决策显式化。路由节点或分支节点可以输出类似结构：
{
"task_type": "image_code_location",
"risk_level": "medium",
"reasoning_depth": "medium",
"context_need": "workspace_files",
"tool_access_required": true,
"selected_route": "image_llm",
"confidence": 0.82,
"reason": "用户提供了上传图片路径，并询问对应代码位置。"
}这样后续才能审计：
- 路由是否选对了分支？
- 它是因为任务困难、需要看图、涉及隐私，还是需要工具才路由？
- 分支模型有没有使用正确工具？
- 这次路由真的节省了成本，还是只是增加了延迟？
智能路由不等于“永远先用便宜模型”。
在 Agent 工作流里，便宜模型可能带来更多重试、更多工具循环和更多人工修正。最终结果可能更慢，也可能更贵。
建议用运行日志比较：
选择的模型
路由原因
输入 Token
输出 Token
延迟
工具调用
fallback 事件
最终答案质量
真正应该优化的不是单价，而是整个任务的质量、成本和稳定性。
主模型从不调用智能路由工具。
加强工具描述。明确触发条件：图片路径、截图、文件检查、代码定位、隐私数据、fallback 或复杂任务。
分支模型不能使用工具。
检查是否开启了 open external tools，以及外部工具是否真的暴露给该分支。
选错了分支模型。
把路由规则写得更具体。不要只靠 token 长度，应该区分任务类型、风险、上下文需求、隐私需求和工具需求。
路由执行成功，但回答很空。
要求分支返回结构化结果：检查过的文件、证据、推理过程和最终子任务结论。
工作流太慢。
只在必要任务里触发智能路由。普通聊天、简单格式化和低风险摘要继续走主模型。
工作流难以信任。
增加路由决策输出，并在修改路由 prompt 或分支模型后，用一小组真实任务做 replay。
如果你在搜索下面这些问题，这篇教程就是对应场景：
智能路由
大模型智能路由
LLM router
model router
dynamic model routing
AI agent model routing
每条消息选择模型
每个任务选择模型
OpenAI-compatible endpoint
OpenAI-compatible proxy
Claude Code 模型路由
Codex 模型路由
Cursor 模型路由
工作流虚拟模型接口
多模型 Agent 工作流
模型路由可观测性
LLM 路由成本归因
路由决策日志
一个接口多个模型
你的客户只配置一个模型接口。
1flowbase 在背后运行模型路由工作流。
被路由模型可以使用工具、返回 tool result，并且全程可观测。
如果你在做 AI Agent、Coding Agent 或模型驱动产品，智能路由可以让客户端保持简单，把供应商选择、工具权限、fallback 和成本可见性放进你可控的工作流里。