企业官网建设流程全解析

1. 智能体路由：多智能体系统的“交通枢纽”

1.1 没有路由时，系统会变成什么样

先说一个我在实际项目里见过的场景。某个团队搭建了一个企业知识问答系统，里面接了三个能力：一个负责内部制度检索，一个负责产品技术答疑，一个负责把问题转给人工客服。最初他们没做路由，直接把三个能力全部并行调用，再让汇总层挑一个最好的答案返回。

结果上线第一天就出了笑话：用户问“年假剩余天数怎么查”，制度检索答得正正经经，产品答疑也生成了一个看起来很像那么回事的答案，人工客服那边甚至把这个当工单发了出去。用户收到三条回答，内容互相矛盾，体验直接崩了。

这就是典型的缺少路由控制。

智能体路由（Agent Routing）要解决的核心问题，其实特别朴素：**当系统里有多个智能体可用时，决定“当前这个请求该交给谁”。**它处在用户请求和业务智能体之间，是一道调度层，也是一次分类决策。它的质量直接决定了整个系统的响应速度、准确率、成本，甚至是否会被用户信任。

我在这个领域摸爬滚打了几年，从最早的硬编码if-else到后来引入语义检索、再到大模型直接充当调度中枢，把市面上主流的路由方案都试过。这篇文章就基于真实项目经验，把四种主流实现方法从头到尾拆一遍，并给出选型建议。如果你正在做企业级智能体系统，或者正被“一问多能”的调度问题困扰，这篇应该能省下你不少调研时间。

1.2 路由的本质是一次分类决策

很多人一听到“路由”就联想到网络里的网关，觉得这是个基础设施问题。但站在智能体系统的角度看，路由本质上是一个文本分类问题，或者更宽泛地说，是一个决策问题。

输入是一段用户请求（有时还带上下文、用户画像、多轮对话历史），输出是“接下来调用哪个智能体”。区别只在于：

• 决策规则是谁定义的——是人写的规则、是向量相似度、还是模型推理出的结论；
• 决策的依据是什么——是关键词、语义向量、还是模型对意图的综合理解；
• 决策失败后怎么办——是兜底到默认智能体、还是主动澄清、还是返回“无法处理”。

理解了这一点，再看四种实现方法，就会清晰很多。它们不是四种完全无关的技术，而是在同一个“决策问题”上，用了不同的解决方案。

下面我按“从简单到复杂、从确定性到概率性”的顺序，逐一拆解这四种方法：规则路由、向量语义路由、模型路由、可学习路由。

2. 方法一：规则路由——把决策写在明面上

2.1 规则路由的实现形态

规则路由是最容易想到、也最容易落地的一种方案。核心思路是：人工为每个智能体定义一套触发条件，请求进来时，按条件逐一匹配，命中哪条就走哪条。

实现形式通常有这几种：

• 关键词表：例如“请假、年假、加班、考勤”命中“人事制度智能体”；
• 正则表达式：例如/(合同|发票|报价单)相关/命中“商务流程智能体”；
• 决策树：按业务线一级一级往下分，比如先按“是否涉及钱”分，再按“是否涉及合同”分；
• 组合条件：加上时间、地区、用户角色等结构化字段做联合判断。

下面是一个比较典型的规则路由伪代码示例：

def route_by_rules(request): text = request["query"] if request.get("user_role") == "admin" and "审批" in text: return "admin_approval_agent" if re.search(r"年假|请假|考勤|加班", text): return "hr_policy_agent" if re.search(r"合同|发票|报价", text): return "business_process_agent" if "售后" in text or "退货" in text: return "after_sales_agent" return "default_agent"

这种实现的优点是显而易见的：快，几乎没有延迟；逻辑透明，出问题了可以直接查；成本几乎为零，不需要任何模型调用。

2.2 规则路由的适用边界

但规则路由有一个绕不过去的问题：**它只能处理“能写清楚”的场景。**一旦用户的表达超出规则表的覆盖范围，路由就会失效。

举个非常真实的例子。用户说“我最近老是失眠，压力大，想咨询一下心理方面的”，如果规则表里只写了“心理咨询”这个精确词，这条请求很可能被漏掉，落到默认兜底智能体上，用户得到一句“抱歉我无法理解”。但如果用户说的是“最近睡不好，整个人都很焦虑”，而你的路由表里没有任何“焦虑”相关的关键词，同样会漏。

规则的表象是“省”，实际维护起来却是“费”。规则之间可能互相重叠，改一条影响另一条；规则到达几百条以后，排查冲突就变成了一个负担。我见过一个系统，路由规则写了三千多行，每次业务调整都要开专项会议讨论规则改法，比写功能本身还累。

所以我的经验是：**规则路由适合三类场景。**第一，业务边界极其清晰，表达方式相对固定（例如工单系统的“按业务线分单”）；第二，请求量很大，对延迟极其敏感，需要用最低成本完成分流；第三，作为其他路由方案的兜底层，处理已知的、高频的标准表达。

如果你的系统一开始只有一两个智能体，直接用规则路由把场景跑通是完全正确的选择。不要一上来就引入复杂的语义路由或模型路由，那样反而会增加系统复杂度和排障难度。先把规则写好，后续根据实际数据再升级。

3. 方法二：向量语义路由——让数据告诉你该找谁

3.1 从“关键词匹配”到“语义匹配”

规则路由最大的短板是“不智能”：它只认词面，不认意思。向量语义路由正是为了补上这一环。

它的核心逻辑是：将用户请求和每个智能体各自对应的“意图描述库”都转换为向量，通过计算余弦相似度来判断哪个智能体最合适。

这里有一个关键设计：每个智能体不能只有一个描述，而是要有一个“意图样本集”。比如“人事制度智能体”，至少要覆盖这些表达：

• “年假怎么算”
• “迟到几次会被警告”
• “公积金缴纳比例是多少”
• “出差补贴标准”

然后把每个样本的向量存起来。请求进来时，先将请求向量化，再和所有候选智能体的样本向量做相似度计算，取最高分对应的智能体作为路由结果。

import numpy as np from sentence_transformers import SentenceTransformer model = SentenceTransformer("your-embedding-model") agent_profiles = { "hr_policy_agent": [ "年假怎么算", "请假审批流程", "公积金比例", "迟到几次会被警告", "出差补贴标准" ], "product_agent": [ "产品怎么安装", "功能如何配置", "报错怎么处理" ], "after_sales_agent": [ "退货流程", "换货周期", "售后联系方式" ] } def route_by_vector(query): q_vec = model.encode(query) best_score = -1.0 best_agent = "default_agent" for agent, samples in agent_profiles.items(): sample_vecs = model.encode(samples) sims = np.dot(sample_vecs, q_vec) / ( np.linalg.norm(sample_vecs, axis=1) * np.linalg.norm(q_vec) + 1e-9 ) score = sims.max() if score > best_score: best_score = score best_agent = agent return best_agent, best_score

这个方案的优点比规则路由高出一个量级：**泛化能力强。**用户换一种说法，只要语义接近，照样能命中。而且不需要维护大量规则，只需要维护每个智能体的意图样本集。

3.2 阈值与兜底策略

但向量语义路由真正难的不是“计算相似度”，而是阈值怎么定、兜底怎么做。

如果你的路由结果置信度是0.3，你该不该信？显然不该。所以你必须设定一个最低接受分数，低于这个分数就交给“澄清智能体”或者“人工客服”，而不是硬着头皮选一个最接近的。

阈值怎么定？我的经验是：先用真实历史日志做离线评估。收集至少几千条已经标注好“应该交给谁”的请求，统计它们在各智能体意图库下的相似度分布，画个直方图，就能比较直观地看出该把阈值设在什么位置。一般来说，0.65到0.75是一个比较常见的起始范围，但具体还得看你的embedding模型和业务复杂度。阈值调低了会误分，调高了会大量落入兜底，这个平衡点需要用数据来校准。

另外，embedding模型的选型也很关键。通用的中文embedding模型和专门针对业务知识调优的模型，在相似度分布上差别会很大。如果一开始没有条件微调，建议至少先用一个覆盖中文场景较好的通用模型跑起来，等到积累了足够的标注数据，再考虑微调一个领域专用的向量模型。

还要注意缓存。用户请求在短时间内经常重复，比如很多人在同一天问同一个制度问题。可以在路由层加一个简单的缓存，对用户query做归一化和hash后缓存路由结果，能省掉大量重复的向量计算和模型调用。实测下来，这个改动能把路由层的平均延迟降低大约50%，而且几乎没有副作用。

4. 方法三：模型路由——让大模型当总调度

4.1 为什么需要模型来路由

如果说向量语义路由是在“空间里找最近的点”，那模型路由就是让一个大模型来阅读请求、理解候选智能体的能力说明，然后给出一个调度决策。

这听起来有点“杀鸡用牛刀”，但它在实际系统里确实有不可替代的价值——处理复杂的、需要综合判断的路由场景。

举个真实例子。一个企业服务系统里，用户问：“我们公司想升级套餐，但合同还没到期，能不能先换再补流程？”这句话涉及商务条款、合同变更、财务流程三个领域。向量路由很可能只找到“商务智能体”，但模型路由可以理解这句话里的“能不能先换再补流程”是一个流程合规问题，从而建议先走“合同变更智能体”。

再比如，用户一句“把昨天的报表发到群里”可能根本不需要路由到任何业务智能体，而是需要执行类智能体动手操作。模型路由能结合上下文识别出这是一个“动作指令”而不是“知识问答”。

模型路由的典型实现是用大模型做一次带候选列表的“意图分类”。核心是：把候选智能体的名称、职责、触发条件、能力边界描述给模型，让模型选择其中一个，或者输出“无法确认”。

4.2 提示词工程与结构化输出

模型路由能不能做好，关键在人——更准确地说，在于你怎么写那个路由提示词。

我实践下来比较有效的一个结构是：先给定系统角色，再列出候选智能体清单（每条包含名称+职责描述+典型场景），最后要求模型输出JSON格式的决策，并附一个简短理由。

{ "candidates": [ {"name": "hr_policy_agent", "description": "处理请假、考勤、薪酬、公积金等人事制度问题", "example": "年假剩余天数怎么查"}, {"name": "product_agent", "description": "解答产品安装、配置、报错等使用问题", "example": "导出报表时提示内存不足"}, {"name": "after_sales_agent", "description": "处理退货、换货、退款、售后申请", "example": "刚买的设备想退货"} ] }

对应的路由提示词可以这样组织：

你是一个智能体路由决策器。下面有若干候选智能体，每个智能体有名称、职责描述和典型示例。 请根据用户请求，选出最合适的智能体。 规则： - 只能输出JSON，格式：{"agent": "智能体名称", "reason": "一句话理由"} - 如果没有任何智能体能处理，输出：{"agent": "default_agent", "reason": "无法匹配"} - 不要输出额外解释。 候选智能体： {candidates_json} 用户请求： {user_query}

这个方案在准确率上通常明显优于向量路由，尤其是对“多意图混合”“隐含意图”这类复杂场景。但它有两个绕不开的问题：**成本高、延迟高。**每一条请求都要过一次模型推理，即使选一个轻量模型，也会给整体链路增加几百毫秒到几秒的延迟；如果请求量大，这费用会非常可观。

所以我一般建议：**模型路由不要放在第一层，而是放在规则路由和向量路由都“拿不准”的第二层。**先用规则拦截高频精确表达，再用向量路由处理常规场景，最后才用模型路由处理剩余的低置信度、复杂场景。这样既保住了大部分请求的低延迟低成本，又让复杂请求有一个足够聪明的调度决策。这种“分层路由”的结构在企业级系统里非常实用，后面第四节我会再展开讲。

5. 方法四：可学习路由——把路由当作分类器来训练

5.1 特征工程与样本来源

前三类方法有一个共性：路由决策的“知识”是人给的。要么是规则，要么是意图样本，要么是提示词描述。而第四种方法——可学习路由——是把路由决策变成一个有监督的机器学习问题，让模型从历史数据里自己学会“什么样的请求该去哪个智能体”。

这听起来最“高级”，但也是落地难度最高的一种。

先说实现思路。核心是把“请求→目标智能体”作为训练样本，训练一个分类器或者排序模型。特征可以从几个层面提取：

• 文本层面的词法特征：关键词、n-gram、句法特征；
• 语义层面的向量特征：直接用embedding模型生成的向量；
• 业务上下文特征：用户角色、所属部门、请求来源渠道、时间、历史路由记录等。

模型的选择范围很广，从逻辑回归、梯度提升树到轻量级神经网络都可以。在智能体路由这个场景里，数据量往往不会特别大，所以梯度提升树在多数情况下可以得到不错的准确率，而且训练和部署都很轻量。

但这类方案最大的坎是样本从哪来。

企业级系统刚上线时根本不会有标注数据。比较现实的启动方法是“用已有路由方案先跑一段时间，收集日志，再做人工标注和自动标注”。自动标注可以基于用户后续行为：比如用户对回复点了“没用”，说明这次路由大概率错了；用户主动追问“我问的不是这个”，也说明需要重新标注。

5.2 上线与反馈闭环

可学习路由真正进入生产环境之后，还要设计一个反馈闭环。推荐的做法是采用“影子模式”上线：让可学习路由模型与现有路由规则并行运行，但先不让它实际生效；它每次给出的路由结果都会和线上路由结果一起记录，供后续分析。

跑一段时间后，对比两边的准确率、业务指标，再决定是否灰度切换。切换时也不要一刀切，可以先把可学习模型的决策用于“增强已有路由”——比如当旧方案得分低于某个阈值时，参考新方案的输出——然后再逐步扩大控制权。

# 伪代码：反馈闭环中的路由记录 def route_with_learning(query, user_context): legacy_agent, legacy_score = route_by_rules(query) model_agent, model_score = model_predict(query, user_context) log_entry = { "query": query, "legacy_route": legacy_agent, "model_route": model_agent, "user_feedback": None, "final_route": None } if model_score > 0.8: final_agent = model_agent log_entry["final_route"] = model_agent else: final_agent = legacy_agent log_entry["final_route"] = legacy_agent return final_agent, log_entry

可学习路由的优点在于它能持续进化，业务在变、用户在变、表达方式在变，只有用数据驱动的方式才能一直跟上。但它也是最容易被过度工程化的方案。如果你只有两三个智能体，请求量一天也没有多少，完全没有必要上可学习路由。这个方案的性价比要到系统规模足够大、路由错误已经成为一个明确的业务痛点时，才会体现出来。

6. 四路对比：指标、成本与选型决策

6.1 核心指标对比

把四种方法放到一起做横向对比，可以从六个维度来看：准确率、延迟、成本、可解释性、维护成本和冷启动难度。

这里要特别强调一个容易被忽略的维度：**可解释性。**在企业级系统里，路由出错了，不能只说“模型判断失误”，你需要能回答“为什么转到这个智能体了”。在这一点上，规则路由和向量路由的优势非常明显——规则能复现，相似度分数能解释。而模型路由和可学习路由在解释上天然吃亏。对金融、医疗、政务这类强监管场景，这个维度往往比准确率还重要。

6.2 选型决策建议

基于这些对比，我给几条比较直接的选型建议：

第一，业务边界清晰、请求量稳定，优先用规则路由。尤其适合内部知识库、工单分派这类场景。不要嫌它“low”，很多系统撑到最后就是靠规则路由保证下限。

第二，请求表达多样、规则维护不堪重负，升级为向量语义路由。这一步改动相对平滑，只需要准备意图样本和embedding模型，不需要改变系统整体架构。

第三，存在复杂意图、多意图交叉，且对延迟和成本容忍度较高，引入模型路由。建议放第二层，和前两种方法组合成分层路由。

第四，系统规模足够大、有持续的数据积累，再考虑可学习路由。它不是替代品，而是“最后一层优化器”，用来逐步替代人工维护的规则和意图样本。

现在业内讨论这个话题，经常会说到“企业级智能体系统构建核心”。其实核心不在于用了哪个大模型，也不在于接了多少个智能体，而在于分发层有多聪明、多稳定、多可控。路由这层做扎实了，上面的智能体各司其职，下面的性能和成本都好控制；路由这层出问题，系统整体就散架。

7. 企业级路由落地的“最后一公里”

7.1 性能预算与超时降级

上面讨论了四种算法的选型，但真实落地时，还有一堆“局部细节”容易被忽略。这些细节决定了一个路由方案在实验室里跑得通、上了生产会不会翻车。

第一个细节是性能预算。企业级系统往往对接口延迟有硬性要求。假设整体接口P95要控制在2秒以内，那路由层就不能独自吃掉800毫秒。在设计路由方案时，我会先把延迟预算拆好：向量计算多少毫秒、模型路由最多允许几次、数据库查询多少毫秒。超出预算的路由分支要直接砍掉或降级。

第二个细节是超时降级。模型路由是有失败率的，模型服务超时了、返回格式不对了，路由层必须有预设的fallback路径。最常见的做法是：如果模型路由在限定时间内没有返回合法结果，就自动降级到向量路由结果；向量路由也没把握，就直接落到默认智能体。降级路径要在架构上一开始就留好，否则模型一抖动，整个系统跟着抖。

7.2 可观测性设计：给每次路由决策留“黑匣子”

第三个细节是可观测性。

我接手一个已有智能体系统时，最头疼的就是“用户说错了，但不知道问题出在哪一层”。是路由错了？还是智能体答错了？还是用户表达本身就有歧义？没有日志根本定位不到。

所以路由层的日志一定要记录全链路信息：用户请求原文、各候选智能体路由分数、最终路由结果、路由耗时、模型返回的原始内容、用户后续是否追问或纠偏。这些数据不仅是排障的依据，也是后续优化路由方案、标注训练样本的数据来源。

建议给每次路由请求生成一个独立的route_id，贯穿整条调用链。后续无论排查问题还是做效果评估，都能按图索骥。时间久了你会明白，可观测性不是锦上添花，而是路由系统能不能持续优化的前提。

7.3 灰度更新与安全边界

第四个细节是变更机制。

企业系统的一个重要特点是：路由规则不能“一次性全量切换”。今天改了意图样本库，影响面是多大？改了模型路由的提示词，会不会让一部分请求意外转到别的智能体？这些都要求路由层具备灰度发布能力。

比较稳妥的做法是：路由决策支持按比例分流。先让5%的流量走新路由逻辑，对比旧逻辑的效果指标，再逐步扩大到30%、50%、100%。同时要有“一键回滚”的开关。这个开关必须是一个简单的配置项，而不是改代码重新发布。每次路由变更都像一次小实验，做到了心里有数，就不会出大事故。

第五个细节是安全边界。

路由层相当于系统的“总开关”，如果用户在请求里注入恶意指令，引导路由到某个高风险智能体，可能会造成越权操作。所以路由层建议增加基础的安全校验，比如对用户输入做敏感词过滤、对目标智能体做权限校验。尤其是那些有执行能力的智能体（发邮件、改配置、发起审批），路由决策之后一定要结合用户身份做二次授权确认。这不仅是系统设计问题，也是企业合规的基本要求。

最后再说几句实践体会

这几套方法我在不同的项目里都验证过。一个比较深的感受是：很多人一谈到“智能体路由”，就想着一步到位上最复杂、最智能的方案，结果系统上线后一堆问题，连“为什么路由到那边去了”都回答不出来。

我现在的习惯是：先把业务场景拆清楚，统计一下真实请求的主要类型和数量级，再决定用哪一层路由。规则路由永远是我的第一层，向量路由解决大多数常规语义请求，模型路由只处理真正复杂的边缘场景，可学习路由则等数据积累到一定程度再考虑。这不是保守，而是企业级系统实实在在的生存法则。

如果你正在搭建自己的智能体系统，建议从规则路由开始，同时把意图样本和日志体系搭起来。等到你觉得“规则维护不动了”“用户换个说法就识别不出来了”，再自然过渡到向量路由。路由这层做好了，上面任何一个智能体的替换、新增、下线都不会伤筋动骨。这大概就是“企业级智能体系统构建核心”这几个字的真正含义。