企业官网建设流程全解析

1. 当客服机器人开始"胡言乱语"：一个被低估的线上事故

做 AI 智能客服这行的人，迟早会撞上一个让人头皮发麻的场景：用户只是问了一句"我的订单到哪了"，机器人却突然开始长篇大论地讲起某个完全不相干的话题，甚至输出一段明显越界的内容。更糟的是，这类问题往往不是稳定复现的——同一个用户问题，早上问是正常的，下午问就翻车了。你盯着日志看半天，发现模型本身没换、知识库没动、Prompt 模板也没改，那问题到底出在哪？

答案大概率藏在模型路由这一层。所谓模型路由，就是当用户请求进来之后，系统决定"这一条请求交给哪个模型、用哪套 Prompt、走哪条链路"的调度逻辑。在早期的单模型客服系统里，这一层几乎不存在，所有请求都打给同一个模型。但现在的 AI 智能客服早就不是单模型了：简单寒暄走小模型省钱，复杂售后走大模型保质量，涉及订单查询走带工具调用的 Agent 链路，涉及敏感话题走审核模型先过一遍。请求一多、模型一杂、Prompt 一多，路由层就成了整个系统里最容易失控、也最难排查的一环。

这篇内容我想聊的就是这件事：Prompt 失控到底是怎么和模型路由纠缠在一起的，以及一个能落地的管控方案应该长什么样。适合正在做 AI 智能客服、Agent 开发、多模型路由调度的同学参考，也适合被"invalid prompt"、Agent 执行中断、Prompt 闪退这类问题折磨过的同行。我不会给你一套万能架构，而是把我在实际项目里踩过的坑、做过的取舍、验证过的管控手段摊开讲，你能直接抄走的部分我会标清楚，需要结合自己业务调整的地方我也会说明白。

先说一个反直觉的结论：绝大多数所谓的"Prompt 失控"，根因不在 Prompt 本身，而在路由决策时把不匹配的 Prompt 和模型、工具、上下文拼在了一起。你单独测那条 Prompt 是好的，单独测那个模型也是好的，但它们被路由错误地组合起来，就炸了。理解这一点，后面的所有管控手段才有意义。

2. 拆开"失控"这个词：路由层到底在哪些环节埋了雷

2.1 路由不是一次决策，而是一串决策

很多人对模型路由的理解停留在"if 简单问题 then 小模型 else 大模型"这一层。实际生产环境里，一条用户请求从进来到出去，路由层至少要做四五个决策，每一个都可能成为失控的源头。

第一个决策是意图分类：这条请求属于咨询、投诉、售后、闲聊还是越界内容？分类错了，后面全错。第二个决策是模型选择：基于意图、用户等级、当前负载、成本预算选一个模型。第三个决策是Prompt 装配：从 Prompt 库里挑系统提示词、挑 few-shot 示例、拼上知识库检索结果和对话历史。第四个决策是工具与 Agent 链路绑定：这条请求要不要挂工具、挂哪几个、允不允许 Agent 自主多步执行。第五个决策是输出后处理：走不走审核模型、要不要做敏感词过滤、要不要做格式校验。

这五个决策里，任何一个用了过期的配置、错误的映射关系或者不一致的版本号，都会表现为"Prompt 失控"。比如意图分类把"退款投诉"误判成了"闲聊"，路由就把一个本该走严格售后 Prompt 的请求，交给了闲聊 Prompt 加小模型，结果机器人用轻佻的语气回复了一个愤怒的用户——用户截图发到社交平台，这就是一次线上事故。

2.2 三类最典型的失控表现与它们的路由根因

我把实际遇到过的失控现象归成三类，每一类背后对应的路由问题都不一样，排查方向也完全不同。

这张表是我自己在排障时总结的，你可以直接拿去当排查清单用。重点看第三列——表面现象和真实根因之间往往隔着一层，如果你只盯着 Prompt 文本改，永远修不好。

2.3 为什么"多模型"让失控概率指数级上升

单模型时代，Prompt 和模型是一对一绑定的，你调好一条 Prompt，它在这个模型上的表现就是稳定的。一旦进入多模型路由，Prompt 和模型变成了多对多关系：同一条 Prompt 可能被路由到三个不同模型上，而这三个模型对同一条 Prompt 的理解、对格式要求的敏感度、对工具调用协议的支持程度都不一样。

举个具体的例子。你写了一条要求模型"以 JSON 格式输出，字段为 intent 和 confidence"的 Prompt。模型 A 老老实实输出纯 JSON；模型 B 喜欢在 JSON 外面包一层 markdown 代码块；模型 C 会在 JSON 后面加一句"希望对您有帮助"。如果你的下游解析代码只认纯 JSON，那路由到 B 和 C 的请求就会全部解析失败，表现为"Agent 执行中断"。这不是 Prompt 写错了，是路由没有考虑模型间的输出差异。

所以多模型路由的第一条铁律是：Prompt 不能脱离模型单独管理，必须成对管理。这一点后面讲管控方案时会展开。

3. 管控的第一道闸门：把 Prompt 当成有版本的配置，而不是散落的字符串

3.1 Prompt 散落在代码里，是失控的温床

我见过太多项目，Prompt 就是代码里的一个字符串常量，散落在各个 service 文件里。改一条 Prompt 要发一次版，回滚要重新部署，A/B 测试靠 if-else 硬编码。这种状态下，路由层拿到的 Prompt 是"当前部署版本"的，你根本不知道线上正在跑的是哪一版，出了问题也无法快速定位。

正确的做法是把 Prompt 抽出来，做成带版本号的配置资产。每条 Prompt 有唯一 ID、有版本号、有适用模型列表、有变更记录。路由层装配 Prompt 时，拿的是"Prompt ID + 版本号"，而不是一段裸字符串。

# Prompt 配置的结构示例（伪代码，按自己技术栈调整） prompt_config = { "prompt_id": "customer_service_refund_v3", "version": "3.2.1", "applicable_models": ["model_a", "model_b"], "system_prompt": "你是一名售后客服，负责处理退款咨询...", "few_shot_examples": [...], "max_tokens": 800, "output_format": "json", "required_tools": ["order_query"], "created_at": "2025-01-10", "rollback_to": "3.2.0" }

这样做的好处很直接：路由决策时，系统能校验"这条 Prompt 是否适用于被选中的模型"，不适用就直接拒绝或降级，而不是硬拼上去等它翻车。同时，出问题时你能精确知道线上跑的是哪个版本，回滚只需要改一个版本号。

3.2 版本管理要解决的核心问题：可追溯与可回滚

Prompt 版本管理不是为了好看，是为了解决两个具体问题。可追溯：任何一次线上回复，都能反查到当时用的是哪条 Prompt 的哪个版本、哪个模型、哪套工具。可回滚：发现新版本 Prompt 导致失控，能在分钟级切回上一个稳定版本，而不是重新走一遍发布流程。

我在项目里落地时，给每条 Prompt 的每次变更都记录了三样东西：变更内容 diff、变更原因、变更后的灰度表现。灰度期间如果关键指标（比如解析失败率、用户负反馈率）超过阈值，自动回滚。这套机制上线后，我们处理 Prompt 相关事故的平均恢复时间从小时级降到了分钟级。

注意：版本号不要用"latest"这种浮动标签。路由层必须拿到确定的版本号，否则你永远不知道线上跑的是哪一版，可追溯就成了一句空话。

3.3 Prompt 与模型的适配矩阵

前面提到 Prompt 和模型必须成对管理，落地形式就是一张适配矩阵。行是 Prompt ID，列是模型 ID，格子里填"适配状态"和"注意事项"。

路由层在装配前查这张矩阵，不适配的组合直接拦截。这张表维护起来有成本，但它能挡掉大量"Prompt 单独测没问题、组合起来就炸"的诡异问题。我的经验是，矩阵不需要覆盖所有组合，只需要覆盖实际会被路由命中的组合，这样维护量可控。

4. 路由决策本身怎么做才稳：从规则到打分的演进

4.1 纯规则路由的天花板在哪

最开始大家都是写规则：关键词命中"退款"就走售后链路，命中"你好"就走闲聊链路。规则路由的好处是透明、可解释、好调试。但它的天花板很明显：规则覆盖不了长尾。用户说"我昨天买的东西不想要了能退吗"，没有"退款"两个字，规则就漏了；用户说"你们这个服务真是绝了"，是夸还是骂，规则判断不了。

规则路由一旦漏判，请求就会落到默认链路，而默认链路往往用的是最宽松的 Prompt 和最便宜的模型，失控概率最高。所以规则路由不是不能用，而是不能只用，它应该作为兜底和快速通道，而不是唯一决策依据。

4.2 引入分类模型做意图识别，但别把它当真理

进阶做法是训一个意图分类模型，把用户请求映射到预定义的意图类别，再基于意图做路由。这比纯规则强很多，但有个坑必须提前说：分类模型会犯错，而且它的错误是系统性的。某些表达方式它会稳定误判，如果你完全信任它的输出，误判就会稳定地导向错误的路由。

我的做法是给分类结果加一个置信度阈值。置信度高（比如 > 0.85）直接按分类结果路由；置信度中等（0.6 到 0.85）走一个更保守的链路，比如用能力更强的模型加更严格的 Prompt；置信度低（< 0.6）直接转人工或走兜底话术。这样即使分类错了，错误的影响也被限制在一个可控范围内。

4.3 打分式路由：把多个信号综合成一个决策

再进一步，可以把路由做成一个打分函数，综合多个信号输出最终决策。信号包括：意图分类置信度、用户情绪分、用户等级、当前模型负载、成本预算、历史对话轮次等。每个信号有权重，加权求和后按分数段选择链路。

def route_score(signals): score = 0 score += signals["intent_confidence"] * 0.4 # 意图置信度权重最高 score += signals["emotion_negativity"] * 0.25 # 负面情绪加分，倾向强模型 score += signals["user_tier"] * 0.15 # 高价值用户加分 score += signals["history_turns"] * 0.1 # 多轮对话加分 score -= signals["cost_pressure"] * 0.1 # 成本压力减分 return score # 分数段映射到链路 # score > 0.8 -> 强模型 + 严格 Prompt + 工具链路 # 0.5 ~ 0.8 -> 中等模型 + 标准 Prompt # score < 0.5 -> 小模型 + 宽松 Prompt + 兜底话术

打分式路由的好处是平滑：不会因为某一个信号突变就导致链路剧烈切换。而且权重可以调，业务上想更省钱就调高成本权重，想更稳就调高置信度权重。这套东西我在两个项目里用过，比纯规则和纯分类都稳。

4.4 路由决策必须留痕

不管用哪种路由方式，有一条是硬要求：每一次路由决策都要留痕。记录下这条请求命中了哪些信号、每个信号的取值、最终分数、选了哪条链路、用了哪条 Prompt 的哪个版本、哪个模型。没有这份日志，出了失控问题你只能靠猜。

我踩过的最大的一个坑就是早期没做路由留痕。有一次线上大面积答非所问，排查了整整一天，最后发现是分类模型的一次热更新导致某类意图的置信度整体偏移，但因为没留痕，只能靠复现去猜。后来补上留痕，同类问题十分钟定位。

5. 失控发生时的排查链路：从现象倒推到路由决策

5.1 先确认是不是路由问题，再动手改

失控现象出现时，第一反应不应该是改 Prompt。先做一个判断：这条请求如果换一条路由链路，还会不会失控？具体做法是拿这条请求的原始输入，手动指定一条你认为正确的链路重跑一遍。如果重跑正常，那问题在路由决策；如果重跑还是失控，那问题在 Prompt 本身或模型本身。

这个判断能帮你省下大量时间。我见过太多人一上来就改 Prompt，改了半天发现是路由把请求送错了链路，白忙一场。

5.2 完整排查链路：五步定位法

下面这套排查流程是我实际用过的，按顺序走，基本能定位到根因。

第一步，拉取路由留痕。找到这条请求的完整决策记录，看它命中了哪些信号、最终走了哪条链路。这一步能快速排除"路由送错链路"的可能。

第二步，核对 Prompt 版本。看当时装配的是哪条 Prompt 的哪个版本，和当前线上稳定版本是否一致。如果版本不对，大概率是灰度或回滚出了问题。

第三步，检查模型适配。看被选中的模型是否在这条 Prompt 的适配矩阵里。如果不在，就是适配校验没生效。

第四步，复现 Prompt 装配结果。把当时的系统提示词、few-shot、知识库检索结果、对话历史按原样拼起来，看拼出来的完整 Prompt 有没有超长、有没有包含被拦截的内容、有没有格式错误。很多"invalid prompt"和"Prompt 闪退"就是这一步查出来的。

第五步，单模型单 Prompt 隔离测试。把拼好的 Prompt 单独喂给被选中的模型，看输出是否正常。如果正常，说明问题在链路组合；如果不正常，说明问题在 Prompt 或模型本身。

5.3 几个高频根因的具体表现

Prompt 超长导致闪退：多轮对话场景下，对话历史不断累积，如果路由层没有做历史截断或摘要，Prompt 会越来越长，最终超过模型上下文限制，请求直接失败。表现就是"聊到第 N 轮突然闪退"。解决办法是在路由装配阶段就做历史压缩，比如只保留最近 K 轮加一个历史摘要。

工具绑定与模型能力不匹配：某些模型不支持特定的工具调用协议，但路由层没做校验，硬把工具挂上去，结果 Agent 执行到工具调用那一步就报错终止。表现是"Agent execution terminated due to error"。解决办法就是前面说的适配矩阵校验。

审核链路被跳过：后处理决策里审核模型本该执行，但因为路由顺序问题，审核被放在了输出之后而不是之前，或者干脆被某个快速通道跳过了。表现是越界内容直接输出给用户。这类问题最危险，必须把审核做成不可跳过的强制环节，任何链路都不能绕过。

Prompt 版本随机命中：灰度策略设计不当，导致同一类请求有时命中新版本、有时命中旧版本，用户感知就是"同一个问题回复风格忽变"。解决办法是灰度要按用户维度或会话维度稳定分流，而不是按请求随机。

6. 把管控做成体系：几件必须长期坚持的事

6.1 建立 Prompt 上线前的强制校验

每条 Prompt 上线前，必须过几道校验：长度是否在安全范围内、输出格式是否可被下游解析、是否在目标模型上做过冒烟测试、是否包含可能触发内容拦截的表述。这几道校验做成自动化的，不过不让上线。人工评审容易漏，自动化校验才是稳定的防线。

6.2 关键指标监控与自动降级

路由层要监控几个关键指标：解析失败率、Agent 中断率、审核拦截率、用户负反馈率。任何一个指标超过阈值，自动触发降级——把相关链路切到更保守的配置，同时告警。降级不是失败，是保护。我宁可让机器人暂时回复得保守一点，也不愿意它在大流量下持续输出失控内容。

6.3 定期做路由链路的回归测试

模型会更新、Prompt 会迭代、工具会增减，这些变化都可能让原本正常的链路出问题。所以要定期跑回归测试：用一批固定的测试请求，走完整路由链路，检查输出是否符合预期。这批测试请求要覆盖各类意图、各类边界情况。回归测试跑得勤，线上事故就少。

6.4 一个容易被忽略的点：Prompt 和路由的变更要联动

最后说一个我踩过的坑。Prompt 团队改了 Prompt，路由团队不知道，结果新 Prompt 的输出格式变了，路由下游的解析代码没跟着改，直接导致大面积解析失败。Prompt 变更和路由配置变更必须联动发布，任何一方改动都要通知另一方并同步更新适配矩阵。这个流程听起来简单，但真正坚持下来需要机制保障，比如把两者放在同一个发布流水线里。

7. 我在实际项目里沉淀下来的几条经验

做 AI 智能客服的模型路由管控，技术方案是一方面，更重要的是几条原则性的经验，这些是文档里不会写、只有踩过坑才明白的。

第一条，永远假设路由会出错。不要设计一个"路由正确时表现完美"的系统，要设计一个"路由出错时也不会造成严重后果"的系统。审核强制、降级兜底、置信度阈值，本质上都是在为路由出错买保险。

第二条，Prompt 的可观测性和模型的可观测性同等重要。很多人只监控模型的响应时间和成功率，却不知道线上跑的是哪条 Prompt 的哪个版本。把 Prompt 版本打进每一条日志，这个成本极低，收益极高。

第三条，不要追求一次设计到位。路由管控体系是长出来的，不是设计出来的。先做留痕，再做版本管理，再做适配矩阵，再做自动降级，一步步来。一上来就搞大而全的架构，往往还没上线业务就变了。

第四条，失控问题的排查能力比预防能力更稀缺。预防做得再好也会有漏网的，这时候能不能快速定位、快速恢复，决定了事故的严重程度。所以留痕、复现工具、隔离测试环境，这些"排查基础设施"要提前建好，别等出事了才临时搭。

这套东西我在两个不同规模的客服系统里落地过，小到日请求几万，大到日请求几百万，核心逻辑是通用的，区别只在于监控的粒度和自动化的程度。你可以根据自己的业务量级，从留痕和版本管理这两件最基础的事做起，先把"看得见"解决了，再谈"管得住"。