一套模型干不完客服的活——我按问题分层后，响应快了三倍，账单少了一半

业务痛点

一个朋友的电商店铺，日均咨询量在三千条左右，主要集中在四类问题：订单查询、退换货政策咨询、商品参数询问、以及少量投诉情绪处理。他最初的做法是所有人都会做的事：接一个大模型 API,写一个长 Prompt,把店铺政策、商品资料全部塞进去，一个模型包打天下。

上线两周后问题暴露得很具体：

• 慢。每次请求都要把几万字的商品资料放进上下文，平均响应 11 秒以上，高峰期更久，用户等不及就流失了；
• 贵。所有问题无差别地走大上下文大模型，月账单接近八千元，其中近七成 token 花在了「我的订单到哪了」这种本不需要大模型的问题上；
• 答非所问。用户带着情绪投诉时，模型还在机械地背诵退货政策，升级人工的时机判断全靠关键词硬匹配，漏判率肉眼可见。

这不是模型不够强，而是架构错了：用一种模型能力应对四种完全不同复杂度的问题。简单问题在为复杂问题买单，复杂问题又被简单问题的处理方式拖累。

架构设计：按问题分层，多模型各司其职

重构后的核心思路是把客服请求分成四层，每层匹配不同的处理策略：

用户消息
   │
   ▼
┌─────────────────────────────┐
│ 第1层：意图路由（小模型）      │  成本极低的分类模型
│ 识别:查订单/政策/商品/投诉    │  响应 <300ms
└─────────────────────────────┘
   │
   ├── 查订单 → 结构化工具调用（不经过LLM生成,直接查API返回模板）
   ├── 政策咨询 → 小模型 + 精简RAG（只检索政策文档,上下文<2k token）
   ├── 商品参数 → 小模型 + 商品向量检索
   └── 投诉/复杂 → 大模型 + 完整上下文 + 情绪识别标记
                      │
                      ├── 情绪高风险 → 自动升级人工 + 生成工单摘要
                      └── 情绪正常 → 大模型多轮对话

关键决策有三个：

1. 约 55% 的订单查询不经过大模型生成，直接走订单 API + 回复模板，响应时间从 11 秒降到 1 秒以内；
2. 政策与商品咨询用小模型，只带检索回来的相关片段，单次成本是大模型方案的 1/8 左右；
3. 只有投诉和复杂多轮才动用大模型，并且前置一个情绪判断，高风险直接转人工并让大模型先写好工单摘要，客服接手时不用从头看聊天记录。

关键实现步骤

# 伪代码:分层路由核心逻辑
async def handle_message(user_msg, session):
    # 第1层:轻量分类模型,只输出标签
    intent = await gateway.chat(
        model="lite-classifier",
        messages=[{"role": "user", "content": ROUTER_PROMPT + user_msg}],
        max_tokens=10          # 只要一个标签,几乎不花钱
    )

    if intent == "order_query":
        order = query_order_api(extract_order_id(user_msg))
        return render_template("order_status", order)   # 无LLM生成

    if intent in ("policy", "product"):
        docs = vector_search(user_msg, top_k=3)
        return await gateway.chat(
            model="small-chat",               # 小模型够用
            messages=build_rag_prompt(user_msg, docs)
        )

    if intent == "complaint":
        emotion = detect_emotion(user_msg)
        if emotion.risk > 0.7:
            ticket = await gateway.chat(
                model="large-chat",           # 大模型写工单摘要
                messages=summarize(session.history)
            )
            return escalate_to_human(ticket)
        return await gateway.chat(
            model="large-chat",
            messages=session.history + [user_msg]
        )

落地顺序建议：先做意图分类和订单查询直连(收益最大、改动最小)，再接 RAG 替换全量上下文，最后补情绪识别和人工升级链路。朋友的团队两个人花了大约两周跑完全流程。

为什么统一 AI API 网关能降低维护成本

这个架构要调用至少三种不同模型，如果分别对接三家的原生 SDK,会带来三份认证逻辑、三套错误码、三种限流策略，以及每次模型调价或接口变更时的三处排查。独立开发者最缺的就是维护这类「胶水代码」的时间。

统一网关的价值在于：

• 一处接入，任意切换。所有调用走同一个协议，换模型只改一个模型名字符串。测试某款新出的便宜小模型时，改动量是一行代码，而不是一个下午；
• 统一监控与账单。不同层级模型的调用量、延迟、成本在一个面板里看，哪一层超预算一目了然——这正是分层架构持续优化的数据基础；
• 统一的降级与重试。大模型层超时自动回退到小模型兜底回复，不用在业务代码里为每家服务商各写一套容错；
• 密钥集中管理。避免 API key 散落在多处服务和日志里，安全审计只做一次。

效率账：前后对比

更重要的隐性收益：因为订单查询不再占用大模型吞吐，高峰期的稳定性问题随之消失；而工单摘要让客服接手时间从平均三四分钟了解背景，缩短到十几秒读完摘要。

写在最后

多模型协作听起来复杂，但对小团队来说，本质上是「把贵的能力留给值得的问题」。分层之后，每一层的优化目标都清晰了——快的问题追求更快，难的问题追求更准，账单自然就降下来了。

如果你也想快速搭建这样一套多模型架构，不妨从一个统一的 AI API 网关开始，注册即用，几行代码就能接入多种模型，先跑通分层路由，再逐步精细化：https://api.thistoken.ai/register

---

想直接跑通示例？访问 https://api.thistoken.ai/register 注册 ThisToken.AI，获取 API Key 后即可开始。