OpenRouter 发布客服机器人便宜优先路由教程，用便宜模型先答常见问题

廉价优先的模型路由将常规支持问题发送给小型、廉价的模型，并将选定的困难或不确定的请求升级到更强大的模型。只要较廉价的路径能满足你的支持要求，它就可以降低为每条消息使用强大模型所产生的成本。三种应用侧模式是：静态规则、基于分类器的分诊，以及带置信度阈值的答案检查。

本指南对比这三种模式，说明流程中哪些部分由 OpenRouter 处理，通过一个可复制的请求逐步演示支持流程，并列出在添加升级机制之前需要衡量的内容。

Tl;dr

• 对范围狭窄、易于识别的常见问题使用静态规则，对以多样措辞表达的稳定类别使用基于分类器的分诊，当希望由廉价模型先尝试作答时使用答案检查。
• 将支持策略验收检查保留在你的应用中。我们的模型回退机制负责处理请求错误。而成功但错误的答案则需要在你的代码中单独做出升级决定。
• 在答案验收、总成本（包括被丢弃的尝试）、升级率和完整回合延迟方面，将廉价优先方案与仅用廉价模型、仅用强力模型进行对比。
• 仅在你的评估显示升级能修复失败的地方才添加升级。如果升级只是替换一个原本已可接受的廉价答案，只会增加成本和延迟，而不会改善回复。

更廉价的模型何时适合常规常见问题

只用一个强大模型可以让初始集成保持简单。如果常规常见问题在更廉价的模型上也能满足你的质量要求，这部分流量就成为降低模型支出的候选。使用我们模型目录中的候选模型和最新定价，针对同一份已批准的文档测试这两个模型。

分类器调用和二次尝试同样会消耗时间和预算。应根据你在生成前能识别什么、生成后能检查什么来选择模式。

三种路由模式

Anthropic 的构建高效智能体指南将路由描述为对输入进行分类并将其导向专门的后继任务，简单问题发送给较小的模型，困难问题发送给更强大的模型。下方的构建和维护估算是我们针对小型支持应用做出的规划判断。

这些模式可以并存。规则或分类决定请求从哪里开始，答案检查则决定其输出是否可接受。在你针对自己的问题将模型自报的置信度与正确性核对过之前，它并不等于正确的概率，因此在获得这些数据之前，请将其视为一种排序信号。

你的应用负责什么、OpenRouter 处理什么

拥有基于质量的路由意味着要维护规则或分类器、验收检查、升级决策和监控。这些都可以放在你的支持应用内部，无需单独的路由服务。

如果您希望我们选择初始模型，我们的 Auto Router（通过 "model": "openrouter/auto" 选中）会按任务类型对每个提示词进行分类，并从 OpenRouter 用户在该任务类型上消费使用的模型中挑选一个。有序的 模型回退 列表以 models 数组发送，当出现速率限制、服务商停机或内容审核拒绝等错误时，会在下一个模型上重试请求。支持策略的接受度检查仍由您自己负责。

如果您希望我们选择初始模型，请选择 Auto Router。如果您清楚自己偏好的模型并且需要错误恢复，请选择有序回退列表。对于廉价优先的质量升级，由您的应用检查候选答案，并在检查未通过时请求另一个答案。

以下流程展示了这种职责划分。

OpenRouter 上的一个支持流程示例

第 1 步：在选择模型之前定义预期结果

HarborDesk 是一个带有固定 FAQ 的虚构 SaaS 产品。它的机器人可以解释政策并推荐支持途径，但无法查看账户或进行更改。一个可接受的回合会回答问题、请求澄清，或推荐人工支持。

对于您能可靠识别且答案固定的意图，请使用已批准的模板。单独测试意图选择，以便正确的措辞对应正确的问题。需要解读的请求将进入下方的生成答案路径。

第 2 步：在升级之前检查生成的答案

对于需要生成的请求，廉价模型提供第一个候选答案和分诊信号。接受与否的决定由您的应用负责。

设想一位客户询问如何取消订阅并申请退款。按照 HarborDesk 的政策，账户所有者在 Settings > Billing 下取消订阅，退款请求由账务人员审核。

• 接受一个解释了这两个步骤且未承诺退款的廉价答案。
• 对于把所有请求都转给账务而遗漏了所有者取消步骤的答案，应予以拒绝。如果有覆盖该请求的已批准模板，就使用该模板；如果您的评估显示更强的模型能修正这一遗漏，则请求更强的模型再试一次。
• 如果客户要求机器人批准退款，则推荐账务支持。更强的模型也无法提供这种权限。

检查政策内容和预期操作。仅凭有效的 JSON 并不能证明正确性。保留对话上下文，对更强的模型的答案运行相同的检查，并在一次升级后停止。

第 3 步：配置错误回退并记录请求成本

此代码片段发送一个带有有序回退列表的请求。运行之前，请安装 requests 并设置 OPENROUTER_API_KEY。这个简短的虚构 FAQ 为示例提供上下文。

import os
import requests

messages = [
    {
        "role": "system",
        "content": (
            "Answer only from this fictional HarborDesk FAQ. "
            "Owners can cancel under Settings > Billing. "
            "Billing support reviews refund requests. "
            "You cannot inspect accounts, cancel plans, or approve refunds. "
            "Ask for clarification when necessary."
        ),
    },
    {"role": "user", "content": "How do I cancel my subscription and request a refund?"},
]

response = requests.post(
    "https://openrouter.ai/api/v1/chat/completions",
    headers={"Authorization": "Bearer " + os.environ["OPENROUTER_API_KEY"]},
    json={
        "models": ["openai/gpt-4.1-mini", "openai/gpt-4.1"],
        "messages": messages,
        "max_tokens": 512,
        "stream": False,
    },
    timeout=60,
)
response.raise_for_status()
data = response.json()
if "error" in data:
    raise RuntimeError(f"Completion failed: {data['error']}")
choices = data.get("choices", [])
if not choices:
    raise RuntimeError("Completion returned no choices")
choice = choices[0]
if choice.get("error") is not None or choice.get("finish_reason") == "error":
    raise RuntimeError(f"Completion failed: {choice.get('error', 'unknown error')}")
print({
    "id": data["id"],
    "model": data["model"],
    "answer": choice["message"]["content"],
    "cost": data.get("usage", {}).get("cost"),
})

models 数组会在出现符合条件的错误（例如速率限制或服务商停机）后尝试下一个模型。成功但不正确的答案不会触发它。质量升级需要应用检查和一次单独的更强模型请求。

之所以存在这两种错误检查，是因为当模型开始处理请求却在生成输出时失败，我们可能返回 HTTP 200。error 对象出现在响应体的顶层，或者当存在部分内容时，出现在 choices[0] 内部且 finish_reason 设置为 error。错误与调试 参考文档描述了这两种结构。请将两者都视为失败，而不是将部分输出当作答案打印出来。

该片段会打印一个未经验证的候选答案以供检查。usage.cost 字段是我们为该请求收取的信用额度费用，model 是生成响应的模型，当回退机制被触发时这一点很重要。请为每个请求记录这两项。当你的应用发生升级时，请将两次调用的费用相加，包括被丢弃的廉价草稿。如果响应到达时没有 cost 值，请在与你的 活动 页面核对之前，将成本记录为未知而非零。用量核算 指南描述了 usage 对象。

衡量升级率与每张已解决工单的成本

对于始终先尝试廉价模型的流水线，请使用以下公式计算每个请求的预期模型成本。

expected_cost = cost_cheap + cost_check_1
              + escalation_fraction * (cost_strong + cost_check_2)

在检查项中计入任何评估器或分类器调用的成本，并在升级的请求上使用更强模型的成本。在相同的质量目标和延迟限制下，将结果与仅用廉价模型和仅用更强模型的方案（包括各自的检查）进行比较。

针对每种路由策略跟踪这些指标。

• 升级率。进行了更强模型尝试的请求占比。
• 被接受的错误答案。通过了你的检查但未通过人工审核的廉价答案。
• 被升级的正确答案。本已满足你的标准却仍被升级的廉价答案。每一次都会增加更强模型的费用和第二次调用的延迟，却不会改善响应。
• 移交适当性。当请求需要机器人不具备的权限时，机器人是否建议了人工支持。
• 整轮延迟。从客户消息到返回答案的时间，升级请求包含两个模型阶段。

升级率高时需要检查被路由的问题。但这本身并不能证明阈值设置有误。

对于每张已解决工单的成本，将一个工单群组的全部模型支出（包括未解决的工单）除以在规定重新打开时间窗口内满足既定解决定义的工单数量。测试集上的答案接受度衡量的是响应质量，而非客户问题的解决情况，因此请将这两个指标分开。

在生产环境启用升级之前，先在留出的客服问题上运行此比较。纳入简单直接的常见问题（FAQ）、模糊的请求、故障排除以及需要人工移交的请求，并根据预定义的内容标准和预期操作对每个答案评分。只有当升级能以你可接受的成本和延迟把不通过的答案变成通过的答案时，它才值得采用。

结论

对于窄范围的 FAQ，先从已批准的模板和廉价模型基线开始。根据你的工作负载选择规则、分类或答案检查，然后仅在相同的质量目标和延迟限制下与更强模型比较。只有在升级能修复足够多的失败、足以证明其成本和延迟合理时才添加升级。当客服政策变化时，重新审视你的检查。

常见问题

我可以避免构建自定义路由服务吗？

你可以把路由保留在你的客服应用内部。如果你希望由我们来挑选初始模型，可以使用 Auto Router；并使用 models 回退数组，以便在请求出错后由我们重试另一个模型。客服场景专属的验收检查（例如答案是否符合你的取消政策）仍然应该放在你的应用中。将模型 ID 保存在配置中，并让你的提示词和评估数据保持可移植，以便日后更换模型。

廉价模型能在生成过程中咨询更强的模型吗？

通过本指南中的流程是无法做到的。廉价模型先完成一个候选答案，然后你的应用再决定是否请求更强模型的答案。要想在一轮对话中咨询另一个模型，需要在你的代码中有明确的工具或编排步骤，由该步骤调用更强的模型并将其输出返回给正在进行的工作流。models 回退数组并不会创建这种机制，它只是在出错后改用另一个模型重试请求。

我应该选择哪个 FAQ 分诊模型？

从在留出的支持问题（包括模糊请求和策略例外情况）上能满足你的质量目标的最便宜候选模型开始。测量完整轮次的延迟而非单次调用的延迟，因为即使模型调用本身最快，如果经常需要第二次尝试，最终的支持响应仍可能更慢。先从一小组反复出现的问题入手，随着你的评估显示哪些路由有效，再逐步扩展。

参考资料

• Auto Router
• 模型回退
• 用量核算
• 错误与调试
• 构建高效智能体，Anthropic