大多数 AI Agent 在所有环节都使用单一模型。规划步骤、工具调用、总结、错误恢复。这在演示中可行，但在生产环境中，这是一种浪费。
需要深度推理的规划步骤并不需要与 JSON 提取步骤使用相同的模型。代码生成任务的要求与分类任务的要求也截然不同。使用 Claude Opus 4.6（每 1M output tokens 25 美元）来格式化日期字符串，就像聘请资深架构师来刷墙一样。
以下是如何构建能够将每个步骤路由到最佳模型的 Agent。
如果你正在处理 API 层而非 Agent 层，请在阅读本文的同时参考 Agent-First API 设计 和 为什么团队从直接使用模型 API 转向统一 AI API。当底层 API 接口足够稳定，可以在不重写编排代码的情况下更换模型时，多模型 Agent 的效果最佳。
多模型 Agent 架构
用户请求
│
▼
┌─────────────┐
│ 路由器 │ ← 对任务复杂度进行分类
│ (快速模型) │
└──────┬──────┘
│
┌───┴───┐
▼ ▼
┌──────┐ ┌──────┐
│简单模型│ │复杂模型│
└──┬───┘ └──┬───┘
│ │
▼ ▼
┌─────────────┐
│ 聚合器 │ ← 合并结果
│ (快速模型) │
└─────────────┘
三个组件：
- 一个根据复杂度对传入任务进行分类的路由器
- 一个匹配不同任务类型的模型池
- 一个在需要时合并结果的聚合器
在实践中，生产环境的 Agent 通常还需要另外两个部分：
- 当首选模型失败或变慢时的备选策略 (fallback policy)
- 一个记录每个步骤的模型选择、延迟和成本的遥测层 (telemetry layer)
如果没有这两部分，多模型 Agent 很快就会变成一个行为不可预测的黑盒。
使用 OpenAI SDK 实现
通过聚合器使用单一 API key，无需管理多个 SDK 即可访问所有模型：
from openai import OpenAI
client = OpenAI(
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
# 具有成本/能力层级的模型池
MODELS = {
"router": "gpt-4.1-mini", # $0.40/1M in - 快速分类
"simple": "gpt-4.1-mini", # $0.40/1M in - 提取、格式化
"reasoning": "claude-sonnet-4-6", # $3.00/1M in - 规划、分析
"complex": "gpt-4.1", # $2.00/1M in - 代码生成、多步执行
"budget": "deepseek-chat", # $0.28/1M in - 批量处理
}
def route_task(task: str) -> str:
"""使用廉价模型对任务复杂度进行分类。"""
response = client.chat.completions.create(
model=MODELS["router"],
messages=[
{"role": "system", "content": """将此任务分为以下一类：
- simple: 数据提取、格式化、翻译
- reasoning: 分析、规划、比较
- complex: 代码生成、多步问题解决
- budget: 批量处理、非关键任务
仅回复类别名称。"""},
{"role": "user", "content": task}
],
max_tokens=10
)
category = response.choices[0].message.content.strip().lower()
return MODELS.get(category, MODELS["simple"])
def execute_task(task: str, context: str = "") -> str:
"""将任务路由到合适的模型并执行。"""
model = route_task(task)
messages = []
if context:
messages.append({"role": "system", "content": context})
messages.append({"role": "user", "content": task})
response = client.chat.completions.create(
model=model,
messages=messages
)
return response.choices[0].message.content
实战 Agent：代码审查流水线
这是一个审查 Pull Request (PR) 的实用多模型 Agent：
def review_pr(diff: str) -> dict:
"""多模型 PR 审查流水线。"""
# 步骤 1：对更改进行分类（廉价模型）
classification = client.chat.completions.create(
model="gpt-4.1-mini",
messages=[{
"role": "user",
"content": f"分类这些代码更改：{diff[:2000]}\n"
"类别：bugfix, feature, refactor, docs, test"
}],
max_tokens=20
).choices[0].message.content
# 步骤 2：安全扫描（推理模型）
security = client.chat.completions.create(
model="claude-sonnet-4-6",
messages=[{
"role": "system",
"content": "你是一名安全审查员。检查： "
"SQL 注入、XSS、身份验证绕过、代码中的密钥、"
"不安全的反序列化。请指明具体的行号。"
}, {
"role": "user",
"content": f"审查此 diff 的安全问题：\n{diff}"
}]
).choices[0].message.content
# 步骤 3：代码质量（通用模型）
quality = client.chat.completions.create(
model="gpt-4.1",
messages=[{
"role": "user",
"content": f"审查代码质量：命名、结构、"
f"错误处理、测试覆盖率。\n{diff}"
}]
).choices[0].message.content
# 步骤 4：总结（廉价模型）
summary = client.chat.completions.create(
model="gpt-4.1-mini",
messages=[{
"role": "user",
"content": f"用 3 个要点总结此 PR 审查：\n"
f"类型：{classification}\n"
f"安全：{security[:500]}\n"
f"质量：{quality[:500]}"
}]
).choices[0].message.content
return {
"classification": classification,
"security": security,
"quality": quality,
"summary": summary
}
典型 PR 审查（2K token diff）的成本明细：
| 步骤 | 模型 | 输入 Token | 成本 |
|---|---|---|---|
| 分类 | GPT-4.1-mini | ~2,100 | $0.0008 |
| 安全 | Claude Sonnet 4.6 | ~2,500 | $0.0075 |
| 质量 | GPT-4.1 | ~2,500 | $0.0050 |
| 总结 | GPT-4.1-mini | ~1,200 | $0.0005 |
| 总计 | ~$0.014 |
如果所有四个步骤都使用 Claude Sonnet 4.6，成本约为 0.028 美元。多模型方法将成本降低了 50%，同时在最关键的环节（安全审查）使用了最强大的模型。
按能力路由，而非仅按价格
许多团队开始进行多模型路由时遵循一个简单的规则：昂贵的任务交给昂贵的模型，廉价的任务交给廉价的模型。
这是一个很好的初步尝试，但还不够。
更强大的路由策略会考虑四个维度：
- 推理深度 (reasoning depth)
- 上下文长度 (context length)
- 工具调用可靠性 (tool-use reliability)
- 延迟敏感度 (latency sensitivity)
这会产生更好的规则：
- 规划和任务分解交给推理能力强的模型
- 提取和格式化交给廉价、快速的模型
- 代码审查交给具有最佳 Bug 发现行为的模型
- 全库分析交给具有最大上下文窗口的模型
这也是为什么 编程模型对比 和 价格对比 应该直接指导你的路由器，而不是仅仅躺在研究文件夹里。
LangChain 集成
from langchain_openai import ChatOpenAI
# 创建具有不同配置的模型实例
fast = ChatOpenAI(
model="gpt-4.1-mini",
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
reasoning = ChatOpenAI(
model="claude-sonnet-4-6",
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
# 在 LangChain 链中使用
from langchain_core.prompts import ChatPromptTemplate
classify_chain = ChatPromptTemplate.from_template(
"Classify: {input}"
) | fast
analyze_chain = ChatPromptTemplate.from_template(
"Analyze in depth: {input}"
) | reasoning
何时使用多模型 Agent
多模型路由增加了复杂性。在以下情况下是值得的：
- 你的 Agent 处理多种任务类型（不仅仅是聊天）
- 每月 API 成本超过 100 美元（节省变得有意义）
- 你需要特定的模型优势（Claude 用于代码，Gemini 用于长上下文，GPT 用于速度）
- 某些步骤对延迟敏感，而其他步骤则不然
对于简单的聊天机器人或单一用途的 Agent，单一模型就足够了。当每个请求都需要相同的能力时，路由的开销并不合理。
临界点通常是以下情况之一：
- 你在为低价值任务支付高端推理费用
- 某个供应商的停机现在已成为真正的业务风险
- 整个工作流中的上下文需求差异巨大
- 你在一个昂贵的核心阶段周围需要更便宜的审查/提取/总结阶段
如果以上都不符合，单一模型仍然是正确答案。
常见失败模式
多模型系统会以可预测的方式失败：
1. 路由器过于“聪明”
如果路由器的 prompt 变成了一个巨大的分类练习，你在决定做什么上花费了太多。保持路由器廉价且粗放。
2. 输出契约漂移
一个模型返回干净的 JSON，另一个返回带有 JSON 块的散文，导致你的下游解析器崩溃。在每次交接时使用显式的 schema 和验证。
3. 备选方案悄无声息地改变了质量
在供应商压力期间路由到更便宜的模型，如果用户看到完全不同的质量表现，可能会让 Agent 显得不稳定。这就是为什么 限流策略 属于设计内部，而不是事后才考虑的事情。
4. 缺少成本报告
如果你不记录每个步骤的模型选择、成本和延迟，你就无法判断多模型设计是否真的节省了资金。
极简评估循环
你不需要一个巨大的评估平台来负责任地运行多模型 Agent。
从每次运行一个表格或一个数据库表开始记录：
- 用户任务类别
- 路由器决策
- 每步使用的最终模型
- 每步的延迟
- 总 token 成本
- 是否触发了备选方案
- 用户是否接受了答案
这为你提供了足够的信号来回答关键问题：
- 路由器是否足够频繁地选择了正确的昂贵模型？
- 哪一步消耗了大部分预算？
- 备选方案是在挽救运行还是仅仅在掩盖不稳定性？
- 廉价路径对于重复性任务是否足够好？
这也是统一网关有所帮助的原因。当模型使用分散在许多供应商中时，很难组建一个可对比的运行账本。当一切都通过一个 API 层时，监控负担就会降低。
保持架构“枯燥”
最好的多模型 Agent 不会让人觉得新奇。它们在操作上让人觉得“枯燥”（稳定且可预测）。
这意味着：
- 编排层有一个稳定的请求形状
- 有一个定义路由规则的统一位置
- 有一个检查成本和延迟的统一位置
- 每个任务系列有一个备选策略
- 模型白名单有一个单一事实来源
如果你的 Agent 图看起来很聪明，但你的操作员无法解释为什么一个请求去了这个模型而不是另一个，那么设计还没有完成。
何时不要使用多模型 Agent
在某些情况下，简单的设计显然胜出。
不要仅仅因为模型目录很大就添加路由。
在以下情况下坚持使用单一模型：
- 产品重复执行一项狭窄的任务
- 模型之间的质量差异对用户来说无关紧要
- 你的流量太低，成本优化无关紧要
- 你的运维层面已经缺乏监控
- 你还没有足够强大的评估手段来判断路由是起到了帮助还是副作用
一个经过精心选择、具有良好重试机制、prompt 规范和可观测性的单一模型，往往优于一个没人信任的华丽多模型图。
正确的问题不是“我们可以路由吗？”，而是“路由是否为此工作流带来了更好的质量、更低的成本或更安全的失败行为？”
如果答案模糊不清，请保持架构简单，直到工作流本身变得更加多样化。
核心要点
- 使用能处理好每个步骤的最廉价模型
- 将昂贵的模型留给真正需要它们的任务
- 分类/路由步骤应始终使用最廉价的可用模型
- 衡量每个 Agent 运行的实际成本，而不仅仅是每 token 价格
- 使用单一 key 的 API 聚合器可以显著简化多模型访问
多模型 Agent 本身并不更好。只有当工作流确实包含不同类型的工作时，它们才更好。
通过一个 API 访问所有模型：LemonData 通过单一 API key 提供 300 多个模型。无需管理多个供应商账户，也无需为每对供应商重新开发路由，即可构建多模型 Agent。