企业官网建设流程全解析

先讲一个我真实经历过的情况。某智能客服项目一开始只接了一个高配大模型，所有提问、总结、信息抽取全部走同一个接口。结果月底对账的时候，负责人差点以为计费系统出了问题：光模型调用费一项，就比服务器成本高了将近五倍。更尴尬的是，简单问题回答得又慢又啰嗦，复杂问题反而经常漏关键信息。后来我把这套系统改成“按请求分流”——也就是给不同任务分配不同规格的模型——费用立刻降了一大截，整体回复质量反而更稳定了。这个分流机制，在圈里通常被称为智能体路由（Agent Routing）。

这篇内容就是想把这个机制讲透：为什么单体模型撑不住真实业务、路由到底在决策什么、主流的几种路由机制各自适合什么场景、怎么搭一条能落地的路由链路，以及接入之后会遇到哪些坑。适合正在做大模型应用、智能体产品，或者已经在用单一模型但成本和效果双双失控的开发者参考。下面全部是我实际操作中的经验，尽量少讲虚的。

1. 单体模型的“大而全”迷思：什么时候你会真正需要路由

1.1 请求长尾分布下的成本失控

真实业务里的请求分布从来不是均匀的，而是典型的长尾分布。以我接触过的某内容社区项目为例，每天的模型请求里，大约七成是“这篇文章讲了什么”“帮我翻译这句话”这类简单任务，两成是中等复杂度的信息整理任务，真正需要深度推理、多步规划的高难请求可能只占一成左右。

如果所有请求都调用同一个高配模型，那七成简单任务就变成了纯浪费：每多一次调用都在烧钱，但产出和轻量模型几乎没差别。这是个非常要命的隐性浪费，因为它不会在功能测试里暴露，只在月底账单里爆发。

我在另一个项目里做过一个粗略测算。假设每天有1万次请求：

• 7000次简单请求，若全部走高配模型，每次约消耗3000个token的输入加500个token的输出；
• 若这些请求能被一个成本只有高配模型十分之一的轻量模型接住，光这一层就能砍掉一大半调用费用；
• 省下的预算还可以匀给那10%的高难请求，升级成更强的推理链路。

这就是路由机制最直接的价值：把资源花在真正需要的地方。

1.2 复杂任务与简单任务混跑时的质量稀释

成本只是其中一个问题，另一个更隐蔽的问题是质量稀释。同一个模型面对简单任务和复杂任务时的表现是不一样的，而当混合请求共享同一套上下文、同一个提示词模板时，这种不一致会被放大。

举个例子。客服场景里，“订单号是多少，帮我查物流”和“根据这几页退货政策，判断我这种情况能不能全额退款”是完全不同性质的任务。前者只需要关键词抽取和格式化输出，后者需要逻辑推理、条款比对和可能的多轮澄清。如果两者共用一套提示词和模型，要么简单任务响应过于啰嗦，要么复杂任务因为上下文被压缩而表现浮躁。

我当时的判断标准很简单：当一个系统里“简单任务的失败率”和“复杂任务的失败率”同时上升，且两者用了同一个模型时，就是该拆的时候。智能体路由的本质，是把不同复杂度的需求从同一根管道里拆开，让每个任务去匹配合适能力的模型。

2. 智能体路由决策什么：任务特征、模型能力与约束条件的三方匹配

2.1 路由对象是“任务”而不是“用户”

很多人容易犯一个直觉错误：按用户来分模型。比如“付费用户走强模型，免费用户走弱模型”。这种策略看起来合理，但真实场景里同一个用户往往是多面的——他可能上午问一个简单天气问题，下午问一个复杂的法律纠纷问题。如果按用户身份一刀切，简单问题被浪费了预算，复杂问题又得不到足够的模型能力。

所以路由的对象应该是单个任务（一次请求），而不是一个用户或会话。在我实现的系统里，每个请求进入时都携带一个任务特征向量，路由层根据这个向量的内容来决定去哪个模型，而不是看请求来自谁。这个思想一旦扭转过来，路由设计的思路就清晰了。

2.2 我常用的五个路由特征信号

在实践里，我主要会抽取以下五类特征作为路由决策的依据：

这五类特征不用全部参与每次决策，大多数情况只需要两到三个。关键是要先搞清楚：你的系统最在意什么约束？如果是客服，延迟和成本优先；如果是科研分析，准确率和推理深度优先。路由策略不是越复杂越好，而是要贴合业务的最大痛点。

2.3 从“选最强”到“选够用但便宜”的思维转换

我见过不少团队在设计路由时会把问题想成“哪个模型最强就选哪个”，这其实等于没做路由。真实做法应该是建立一个候选模型池，给每个模型标注能力画像，比如适合处理对话类任务、适合代码生成、适合长文档摘要、响应速度快但复杂推理能力弱等。

路由要做的不是选择“最强”，而是选择“最匹配且经济”。这个概念就像一个运输调度中心，不会让所有货物都上飞机，也不会让所有货物都走海运，而是根据时效、体积、成本来安排不同的运输方式。模型选择也是一样，匹配永远比强弱重要。

3. 主流路由机制拆解：从规则到强化学习，各自的算盘和天花板

3.1 规则路由：白名单式分流的简单与脆弱

规则路由是最朴素也最容易落地的一种。它的实现方式就是维护一组关键词、正则表达式或逻辑判断，命中某个规则就将请求分流到对应模型。

def rule_based_route(req): text = req["text"] if "退货" in text or "退款" in text: return {"route": "after_sale", "model": "high_domain_model", "reason": "rule_after_sale"} if "物流" in text or "订单号" in text: return {"route": "logistics", "model": "low_cost_fast_model", "reason": "rule_logistics"} return {"route": "unknown", "model": None, "reason": "no_rule_match"}

规则路由的优势是可解释性极强，出问题可以直接追到某条规则，线上排查容易，响应时间也几乎没有额外开销。缺点是脆弱，一旦用户换一种说法，或者业务场景引入新词，规则就失效了。我在早期项目里吃过不少亏，靠关键词很难覆盖口语化表达的多样性。

所以我的建议是：规则路由适合做第一步粗筛，过滤掉那些意图极其明确、覆盖度极高的任务，而不是指望它解决所有分流问题。

3.2 语义路由：用向量相似度做冷启动分类

语义路由是我用得最多的一种方式。它的核心思路是把用户请求用嵌入模型转成向量，然后和一批“代表性样本向量”做相似度对比，取最接近的类别作为路由结果。

这里有三个关键点：

1. 需要有一个嵌入模型，把文本映射成高维向量；
2. 需要给每个路由目标准备若干条典型样本，比如“商品咨询”这个类目下准备几十条真实用户怎么问这类问题的例句；
3. 相似度计算通常用余弦相似度，阈值需要根据验证集调。

这个方案的优点是不需要标注大量数据就能冷启动——准备每个类别二三十条样本即可，并且对用户的自然表达有很好的容忍度。缺点是需要额外部署嵌入模型，而且对阈值很敏感。阈值设得太严，大量请求会落入“unknown”走兜底；阈值设得太松，误分类又会拉低下游质量。

我在客户项目里针对“售后咨询”“商品咨询”“闲聊”三类各准备了30条样本，用开源嵌入模型做向量化。实测下来，对于超过0.82相似度的请求，分类准确率大约有九成以上，已经足够支撑生产环境的第一层分流。

3.3 分类器路由：小模型的性价比与误判代价

如果语义路由满足不了你，可以考虑训练一个轻量级分类器，比如基于几万条已标注历史请求训练一个小型文本分类模型。它的推理开销远低于大模型，且分类精度通常比纯向量相似度更高，因为它是专门针对你业务场景优化过的。

不过分类器也需要付出代价：第一，必须积累一定量的历史标注数据，冷启动阶段很难用；第二，分类器只能判断意图类别，对“任务复杂度”“输出格式要求”这类连续特征帮助有限；第三，模型更新和迭代需要一套数据回流流程，维护成本比规则和语义路由都高。

我的经验是分类器适合在半稳定业务中使用——业务方向不会频繁变化时，花两周时间训一个专用分类器，性价比是很高的。

3.4 LLM自评价路由：让模型给自己的任务“选路”

还有一种非常灵活但成本也高的思路：把“该走哪条路由”这个问题本身交给一个高能力模型来判断。你可以把用户请求和所有候选模型的能力描述拼接成一个提示词，让模型输出“该由哪个模型处理”。

def llm_judge_route(req, candidate_models): prompt = f""" 这是一个用户请求：{req['text']} 以下是可选模型及擅长能力： - 模型A：快速响应，擅长简单对话，成本低 - 模型B：擅长复杂推理和多步分析，成本高 请选择最合适的模型，只输出模型名。 """ result = call_llm(prompt) return {"route": result.strip(), "model": result.strip()}

这种“用模型做路由”的方式非常灵活，对新出现的任务类型适应能力强，而且可以让LLM同时考虑成本、延迟和复杂度。缺点是三个：一是每次路由决策都多一次模型调用，额外的时延和成本不可忽视；二是LLM的决策不够稳定，同一个请求可能被路由到不同模型，线上行为不可预测；三是如果这个LLM自身能力不够，就会成为一个新的瓶颈。

所以我通常只把LLM自评价路由用在规则和语义都无法判定的“残余流量”上，而不是让它做全量路由。

3.5 分层组合路由：生产环境的常态

说完上面四种，你应该能感觉到：没有哪一种机制是万能的。生产环境里真正起作用的，往往是它们的组合。我把这种组合叫做“漏斗式路由”：先走最快的规则层，筛掉明确任务；再走语义层，覆盖大部分模糊表达；最后走LLM裁判层，处理少数疑难请求。

分层的好处是每一层只需要承担一小部分流量，整体延迟可控，成本也不会失控。后面我会给出一个完整的三层路由落地案例。

下面是五种机制的综合对比，方便你做选型参考：

4. 一次完整的智能体路由链路：从请求进来到响应回去要经过什么

4.1 路由入口：先把所有请求变成同一种“语言”

很多路由系统失败，不是因为路由算法不行，而是入口的数据结构太混乱。不同渠道进来的请求，有的是JSON，有的是纯文本，有的带着HTML标签，有的把多个问题塞在同一个字段里。如果不做规范化，路由层根本没法稳定抽取特征。

我在项目里会在路由层之前加一道“请求规范化”处理，把所有渠道的请求统一成一个标准结构：

@dataclass class NormalizedRequest: request_id: str text: str source: str user_id: str extra_meta: dict = None

这一步看似简单，却能规避大量后续问题。请求ID用于全链路追踪，text是路由决策的主输入，source用于分析不同渠道的分流差异。没有这个统一结构，后面什么特征抽取、日志回放都无从谈起。

4.2 决策层：特征打分与路径选择的实操计算

规范化之后进入决策层。我会基于项目目标构造一个打分函数，把模型选择转化为一个带约束的最优化问题，而不是靠感觉拍板。

假设有三个候选模型，分别代表高配、中配、轻量。我给每个模型定义一个能力值（0到1）和成本值（每次调用的相对成本），路由决策就是让“质量收益”和“成本代价”的加权和最大。

用一个简化的打分公式来解释，核心思想是：

• 对于高复杂度任务，质量收益的权重调高；
• 对于低复杂度任务，成本代价的权重调高；
• 对于高延迟敏感任务，额外加入延迟惩罚项。

这个打分过程在代码层面其实就是一个映射表加加权计算，并不复杂。难的是确定权重：要拿历史数据回归一遍，或者通过AB实验迭代。我之前第一次做的时候把权重拍得太主观，导致路由结果完全偏离预期，后来老老实实抽样标注了几百条历史请求，才把权重调到了一个合理范围。

4.3 执行层：并行探测、超时与降级策略

路由决策完成后，接下来就是真正的模型调用。执行层有一个常见陷阱：为了“保险”，把所有请求都串行等待主模型返回，一旦主模型超时，整个链路就失败。

我认为比较稳的做法是给每个模型调用设置独立的超时时间，并准备降级路径。比如目标是调用高配模型做复杂推理，但高配模型超时，可以降级到中配模型用简化提示词重试一次；如果中配也失败，再走预设的兜底回复模板。降级路径至少要有两条，不然路由系统自己会成为新的单点故障。

另外，对某些置信度不高的路由决策，还可以使用一种“并行探测”技巧：同时把请求发给轻量模型和规则处理模块，哪个先返回可靠结果就用哪个。这在大促或高峰期很有用，能有效降低响应延迟，但成本会有所上升，需要根据场景权衡。

4.4 观测层：让路由决策随时可回溯

我特别想强调观测层的重要性。很多团队把路由搭完就上线，出问题时完全不知道请求当初被路由到了哪里，也不知道是路由错了还是下游模型错了。这会让排错变成灾难。

我的做法是路由层必须打印完整的决策日志，至少包含以下字段：

• 请求ID；
• 路由目标模型；
• 命中规则或相似度得分；
• 各候选模型的打分明细；
• 实际调用耗时与返回状态。

有了这份日志，当用户反馈某个回答不对时，我可以立刻定位到是路由误判，还是下游模型本身能力不足。没有观测层，你连自己错在哪都不知道，这是做路由系统的大忌。

5. 落地到某智能客服项目的全过程复盘

5.1 项目现状与路由改造的目标

这个项目是典型的电商智能客服场景，日请求量大约两万次，原本所有请求都调用同一套高配模型。改造前的情况几乎可以写进反面教材：预算曲线陡增，简单问题响应慢，复杂问题又处理不好。当时定的改造目标有三个：

1. 整体成本下降百分之五十以上；
2. 简单问题平均响应时间压到两秒以内；
3. 复杂问题的有效解决率不能下降。

5.2 三层路由的搭建与参数配置

针对这个项目，我采用的就是前面提到的三层漏斗结构。

第一层是规则层，拦截那些关键词极其明确的请求，比如包含“订单号”的查单请求、包含规格参数的比价请求。这一层覆盖了约四成流量，路由到轻量快速模型，单次调用成本很低。

第二层是语义层，针对售后、商品咨询、物流查询、闲聊四类常见意图各准备了三十条典型样本，用嵌入模型实时计算相似度。相似度超过0.82的请求，按对应意图路由到中配模型。这一层再覆盖接近三成流量。

第三层是残余流量处理，用LLM裁判模型做兜底。剩余的未知意图请求进入这层，由高能力模型综合判断该走哪条路径。

三层之间的衔接代码大概是这样的：

def hybrid_route(req, sample_vectors): first = rule_based_route(req) if first["route"] != "unknown": return first vec = embed(req["text"]) matched = find_best_match(vec, sample_vectors) if matched.similarity >= 0.82: return { "route": matched.route, "model": model_for_route(matched.route), "score": matched.similarity, } judge = llm_judge_route(req, candidate_models) return {"route": judge.route, "model": judge.model, "score": -1}

5.3 路由前后的成本与质量对照

为了让大家对这个机制的效果有直观感受，我把那个项目改造前后的数据整理成了下表。数据带有一定项目特性，仅供趋势参考，但方向和量级是真实可信的。

有一点要说明：成本下降的最大来源不只是把简单任务切给了轻量模型，还包括“复杂问题路由到高配模型后，一次解决率提高，减少了重复提问次数”。后者常常被忽略，但它很惊人。

5.4 第一版路由踩过的两个典型坑

第一版上线的时候，我犯了两个典型的错误。

第一个错误是规则层做得太激进。当时为了降成本，我把“退”“换”这类单字都定义为售后规则，结果“我想换个说法”这种非售后请求也被拦下来扔进售后模型，导致大量误分类。后来我把规则条件从“是否包含某词”改成了“是否同时包含两个以上强信号词”，误判率才降下来。

第二个错误是忽略了语义层的灰度验证。新路由上线后，我没有做小流量对比就直接全量切换，结果某个深夜语义层突然把一批“询问营业时间”的请求判定为“闲聊”，引发的线上投诉花了两天才消化掉。后来所有语义层的阈值调整都必须在测试集上跑一遍，并且按5%、20%、50%的比例灰度放量，再也没出现过类似的事故。

6. 路由长期稳定运行的三张“安全网”

6.1 回流样本动态更新路由样本库

路由系统上线只是开始，真正的挑战是“它会慢慢变钝”。用户语言在不断变化，业务活动会带来新的说法、新的产品名、新的活动词。如果语义层的样本库不更新，三个月后相似度匹配的准确率会肉眼可见地下降。

我现在的做法是每天定时拉取路由日志，筛选那些相似度介于0.6到0.82之间、最终被LLM兜底处理的请求，抽样人工标注后补充到对应类别的样本库中。每个类别每周新增五到十条典型样本，持续迭代。这个动作看起来不酷，但它是路由效果能长期保持稳定的核心。

6.2 模型能力变化后的路由重新校准

还有一个很容易被遗忘的风险：模型本身会更新。很多团队在路由系统里写死了某个模型的能力描述，比如“模型B擅长复杂推理”，但几个月后模型B发布新版本，可能复杂推理能力更强，成本却变了，或者推理风格发生了变化。路由决策依据如果还是老信息，系统就会在不知不觉中降级。

我的建议是每季度做一次模型能力复测，拿一组固定的标准问题集重新验证所有候选模型，根据结果更新模型能力画像和路由权重。这个复测可以自动化，并不费多少人力，但能避免很多难以排查的线上劣化。

6.3 请求失败的兜底与人工重放机制

最后一张安全网是请求失败后的处理。路由系统接的模型越多，可能的失败点就越多。超时、限流、内容格式异常、下游服务不可用，每一种失败都应该有对应的降级动作。

我会为每个路由目标预设一个最低可接受模型，比如高配模型挂了可以降级到中配模型，中配模型挂了可以降级到轻量模型加简化提示词。如果所有模型都不可用，还需要一个模板回复兜底，并接入人工坐席。等系统恢复后，再把失败请求按照原路由路径重新处理一遍，避免用户问题被悄悄丢弃。

这套兜底机制一度在一个大促场景里救了我：那次高配模型服务短时抖动，外部调用大面积超时，系统自动把高复杂度请求降级到了中配模型，虽然回答深度有所下降，但至少没有中断服务，也没有出现大规模用户投诉。要知道，在那种流量下，哪怕中断十分钟都是事故。

我个人在做了几个带路由的智能体项目以后，最大的体会是：路由不是一个“选个模型”的动作，而是一整套围绕任务分配、成本控制、质量保障的工程体系。如果你刚开始接触，不要急着上复杂的分类器或LLM裁判，先把规则层和语义层搭起来，跑两到四周，看看日志里的数据分布，再逐步增加兜底机制和动态更新。先能跑，再跑稳，最后再优化——这个顺序能让你的路由系统越用越顺手，而不是越维护越吃力。