上个月我在复盘智能体线上服务的性能日志时越翻越坐不住差不多七成的请求把完整的推理链路原原本本跑了一遍——任务分解、规划制定、工具调用、结果回填、最终汇总一个环节都没落下。可这些请求里有不少只是“今天天气怎么样”“帮我算一下15%的小费”这个级别的任务。打个不太恰当的比方用户只是想让系统帮忙递杯水后台却安排了一支专家团队全程陪同。结果就是用户等待首个字的时间接近两秒推理账单跟着请求量同步翻倍系统真正做完的事情和它消耗的算力资源之间差距越来越大。这个效率黑洞逼着我去重构整条推理流程最终落地了一套内部代号叫 DualPath 的架构。这篇文章就围绕它展开它到底解决了什么问题、怎么从实验阶段走向生产、以及那些文档里不会告诉你的坑。1. 效率黑洞的成因慢的不是单次推理而是整套工作流1.1 从“对话模型”到“智能体”的算力跃迁普通大模型对话一次请求基本就是“输入一段文本、输出一段文本”的两段式结构。但智能体彻底改写了这个结构系统不再是有问必答而是要走完一个完整的决策闭环理解意图、判断是否需要外部信息、确定要调用的工具、生成调用参数、发起请求、读取返回结果、继续推理、收敛答案、最终组织输出。看似只是多了几个环节实际的算力消耗却是指数级增长。我举一个亲身统计过的例子同样是“帮我查一下明天的天气”在普通对话模式下输入一段话、输出一段话就结束在智能体模式下规划模块要先产出调用计划工具参数需要模型根据当前上下文生成工具返回后模型还要重新读一遍、理解一遍、再组织语言。整个流程走下来token消耗大约是普通对话模式的40倍以上延迟差距直接拉到两个数量级。这个对比让我意识到智能体的效率问题本质上不是“模型推理一次有多快”而是“整个工作流被放大了多少倍”。1.2 上下文累积放大了每一步的成本这里有个特别容易被忽略的细节智能体每多一次工具调用工具返回的内容都会作为新消息追加到上下文里。上下文变长之后后续每一步的注意力计算量都在增加而工具返回的内容往往又携带大量低信息密度的JSON字段、原始数据、时间戳。于是系统陷入一个让人头疼的循环调用工具让上下文变长上下文变长让后续推理变慢推理变慢让整条链路占用并发资源的时间更久并发资源被长时间占据其他请求又开始排队。我们在生产环境里测过一组数据当单条请求的工具调用次数从1次增加到4次时单请求延迟不是4倍的关系而是接近7到8倍。所以如果只看单次调用耗时永远找不到问题的根源问题出在“上下文像滚雪球一样越滚越大”这个机制上。1.3 并发场景下单点变慢会引发全链路雪崩在生产环境里我还观察到一个更隐蔽的现象单条链路的慢会通过线程池排队传导到整个系统。并发池的核心数就那么多前面几个复杂慢请求把池子占满之后后面新进来的简单请求全部在队列里干等。从用户视角看不管你的请求本身多简单体验都一样糟糕。这也是为什么我坚定地认为智能体服务不能只盯着单条请求做局部优化必须从系统层面对流量做分流。慢的请求不应该拖住快的请求两者需要各走各的路彼此隔离、互不干扰。DualPath的核心动机正是源自这个观察。2. DualPath的解题思路用推理预算匹配任务复杂度2.1 从日志分布里长出来的方案做方案设计之前我先做了一件很笨但回报极高的事拉了一周的生产日志挑出代表性样本逐个标注这些请求真正的复杂度等级。人工标注的结果大致如下约62%的请求在语义上完全不需要外部工具比如问候、概念解释、简单计算约23%的请求需要调用一次工具就能完成剩下约15%才是真正需要多步规划、多工具协作、多轮澄清的复杂任务。这个分布直接说明了一个事实六成以上的流量是在用核武器做杂务。DualPath这个名字也源于这个观察——系统的基座模型不需要在每一条请求上都“火力全开”而是拆成两条路径按需供给。快路径面向不需要工具、不需要复杂推理的请求直接给出答案不走规划、不调工具、不膨胀思维链慢路径保留完整的智能体能力覆盖需要查询、操作、多步协作的任务。两条路径共用一套模型服务但在请求处理方式上完全分离。2.2 与模型量化和蒸馏的本质区别听到这里你可能会问为什么不直接用更小的模型做推理加速这里必须说清楚量化、蒸馏、投机采样这些方案和DualPath解决的是两个维度的问题。量化也好蒸馏也好目标都是把“单个推理动作”本身加速而DualPath关注的是“当前这个任务到底需不需要这么多推理动作”。两者不但不冲突反而可以叠加使用快路径上用量化后的轻量模型慢路径上继续用投机采样加速生成。但如果只做模型加速而不做路径分流复杂任务照样会因为缺少完整推理链而答错如果只做路径分流而不对模型做任何加速快路径也可能因为基座模型太慢而体验不佳。正确的顺序是先分流、再加速收益才能变成相乘的关系。这个顺序在实际落地中非常关键我在项目里见过不少团队一上来就砸重金做模型量化最后一算账延迟没降多少正确率倒是先掉了一截。2.3 路径边界划分的总原则路径边界是DualPath最敏感的设计点。我的取舍原则可以浓缩成一句话快路径的服务范围宁窄勿宽边界请求一律交给慢路径兜底。原因很朴素——智能体系统里结果正确性永远比速度重要。如果把一个需要调工具的请求误判进了快路径最后给出一个一本正经的错误答案这个代价远比让用户多等一两秒高得多。所以初始版本的快路径范围收得非常保守凡是语义中带有执行、查询、操作倾向的请求哪怕只有一点点可能也先归到慢路径等线上数据跑稳了再逐步放宽边界。3. 从实验验证到生产落地路径拆分中的三个关键决策3.1 先在离线回放里证明方案成立技术方案在原理上说得通是不够的必须离线先验证一遍。我们做了一轮完整的离线回放实验取连续一周的生产请求日志按当时实际的作答结果标注难度再在模拟环境里把DualPath的分流逻辑跑一遍逐一对比不同阈值下快路径的命中率、误判率和整体表现。这个过程的收获比想象中大很多。很多在直觉上应该进快路径的简单请求回放时发现它们的上下文已经被“污染”了——比如中间夹杂了一大段工具返回数据“简单问题”根本没法在快路径的无工具模式下正确作答。这类样本逼着我们补充了一条重要规则快路径只能处理上下文干净、不依赖外部信息的请求凡是上下文里出现过工具返回内容的一律不准进快路径。回放还帮我们确定了初始阈值。当时我们盯两个指标一个是覆盖率也就是快路径能接住多少流量另一个是误判率也就是被判进快路径但实际上需要工具的请求比例。我们设定误判率不超过5%在这个约束下尽可能提高覆盖率再用1%的线上请求做人工抽查复核确认无误后才把阈值正式写进代码。3.2 生产环境里最重要的一条铁律上线前我和团队内部反复讨论最多的问题是同一个万一误判了怎么办最后定下的铁律是快路径只能回答资源型问题绝不允许进入操作型场景。什么叫资源型比如“解释一下XX概念”“这篇文章讲了什么”“帮我算一下房贷月供”这类请求的信息都蕴含在用户已有的文本里不需要外部系统参与。什么叫操作型“帮我下单”“查我的物流”“预订明天的会议室”“读取我的订单状态”这类请求涉及操作或者需要读取个人数据哪怕被路由模块判定为简单也必须回到慢路径。这条铁律在后来拦下了很多潜在事故。我们最初上线版本里正是因为没有严格执行这条铁律才出现了后面章节里要讲的“订单查询事故”。可以说这条铁律是快路径安全运行的生命线。3.3 路径粒度先两档起步不要一上来做多档最初设计时我们设想过按任务复杂度分成三档甚至四档比如“纯直答”“单次查询”“多次操作”“深度规划”。但实际落地的经验告诉我先做两档是最稳的选择。多档意味着需要更多的标注样本、更细的边界定义以及更多联动规则复杂度会急速上升。两档架构跑稳之后再把慢路径里最简单的“单次工具查询”独立出来形成第三档反而是很自然的演进方向。我们第一阶段就是靠两档跑了一个多月积累了足够的线上数据后才开始考虑细分。这个“先粗后细、数据够了再分档”的顺序是我在这个项目里学到的最重要的工程节奏之一。4. 路由决策模块决定“走哪条路”的判官4.1 路由需要回答的两个问题路由模块是整个DualPath的心脏它本质上是在回答两个问题。第一个问题这个请求是否需要外部工具第二个问题如果不需要它能否在无上下文的情境下被安全回答第一个问题决定请求走快路径还是慢路径第二个问题决定快路径要不要携带历史会话摘要。两个问题的答案组合起来才能给出正确的分流决策。只回答第一个问题是不够的因为有些请求虽然不需要外部工具但依赖对话历史里的个性化信息贸然丢给快路径同样会答错。4.2 三段式分级路由策略具体实现上我们用的是一种三段式策略每一段都有明确的职责规则前置层。一批高置信度规则比如命中“天气、订单、物流、预订、日程”等与工具强关联的词汇直接判进慢路径。规则层要求速度极快不能做复杂的语义匹配只做词表和实体的快速命中。轻量分类模型层。一个经过量化的句向量模型加分类头输出“简单直答、需单次查询、需多步操作”三类概率。阈值设置非常保守只要“需单次查询”和“需多步操作”的概率加权和超过0.35就判进慢路径。兜底层。所有落入中间不确定区间的请求默认进入慢路径宁可多花推理资源也绝不冒险走快路径。这个设计的核心动机是让错误远离“简单任务被误答”的方向。分类模型犯错的方向主要集中在“该走慢路径却走了快路径”这是我们最不能接受的一类错误所以用非常保守的阈值和兜底规则把它死死摁住。4.3 路由延迟预算必须被严格约束路由模块本身也是一次推理调用如果一次路由判定就要花掉几百毫秒那整个优化就失去意义了。我们当时给路由模块定了硬指标端到端路由判定时间必须低于20毫秒。为了达到这个指标分类模型选了轻量级的句向量模型量化到int8之后在CPU上单次推理稳定在10到15毫秒剩下几毫秒留给规则层和缓存查询。这里有个容易被忽视的工程细节路由模型和服务主模型最好部署在不同进程里否则主模型的一次长推理会阻塞路由判定让路由延迟跟着主模型的尾巴一起抖。4.4 动态校准用业务反馈持续优化路由路由模型不是训练一次就完事的。我们每个自然周都会做一次增量训练把上一周内被系统判定为快路径但用户立刻追问、发起投诉、或者在会话里表现出明显不满的请求捞出来反标为“需要慢路径”的负样本混合到训练集里重新微调。这个机制的效果非常明显。随着业务方不断上新工具、用户语义环境持续漂移路由模型的边界会跟着真实反馈自动校准而不是永远停留在上线那一天的水平。如果省掉这一步路由模型大概运行一个月后就会开始出现偏差因为静态模型永远追不上动态的业务需求。5. 生产实测A/B对比下的延迟、成本和成功率变化5.1 实验设置与样本划分为了不让收益变成自证预言我们专门安排了一组生产环境的A/B实验。连续观测两周对照组走原有完整链路实验组走DualPath分流。两边使用完全相同的基座模型、工具列表和并发规格唯一变量就是是否有快慢路径分流线上流量按请求ID哈希随机分桶确保两组样本在难度分布上一致。5.2 核心指标对比脱敏后的核心数据大致如下表所示指标对照组实验组变化幅度端到端延迟 P50约1.9秒约0.4秒下降约79%端到端延迟 P95约3.7秒约1.5秒下降约59%平均单请求Token消耗基线值下降约57%-推理服务成本基线值下降约44%-任务完成成功率基线提升约0.4%-一个值得注意的现象是P95的降幅明显不如P50这说明长尾部分依然被少量复杂任务主导。换句话说快路径把大部分简单请求的延迟拉下来了但真正吃掉资源的复杂任务还是慢。这就引出了一个后续判断下一阶段的优化重点应该继续放在慢路径本身而不是继续在快路径上抠速度。5.3 成本结构的变化与下一步方向成本降幅虽然可观但细看账单构成会发现慢路径消耗的资源仍然占了大头。快路径因为用了轻量模型虽然承担了六成流量成本占比却不高这符合预期。慢路径上的一次复杂任务token消耗可能抵得上快路径的几百次请求。这个结构告诉我们DualPath的第一阶段收益主要来自分流第二阶段要想继续扩大收益必须对慢路径动刀工具返回结果的压缩、上下文的裁剪、多余推理链的提前终止。每一项改动都能在成本账单上看到直接反馈。5.4 快路径上的语义缓存一个额外红利我们还顺手在快路径上做了一层语义缓存对向量距离相近的重复问题直接复用之前已经生成过的答案跳过完整的生成过程。实测下来高峰期的缓存命中率可以到15%到20%这部分请求的延迟降到几十毫秒成本几乎为零。这个方案几乎是零成本接入的但有一个限制必须强调缓存绝不能用于个性化相关任务比如涉及用户姓名、订单号、会员等级的问题否则下一个用户会看到上一个用户的答案妥妥的事故。我们通过规则层把所有含第一人称和账户信息的请求挡在缓存之外才敢放开这个功能。6. 落地过程中躲不开的坑与修正6.1 教训一快路径也会一本正经地犯错第一个让我印象最深的案例是某次用户问“我的订单为什么还没有发货”。这个请求在规则层漏掉了没有命中任何工具强关联词于是被判进快路径。快路径根据通用知识输出了一段关于“订单可能延迟的常见原因”的科普式回答。用户显然不买账核心问题完全没有被解决。这是一次非常典型的能力围栏事故——快路径没有访问业务数据的权限却接入了本必须查询业务系统才能回答的问题。修复分成两层规则层补上了所有涉及“我的”“订单”“支付”“物流”等第一人称操作词的强制慢路径规则快路径生成侧新增能力校验凡是输出中带有未授权实体词直接放弃作答并降级到慢路径。自从补上这套双重校验快路径的错误率降低了九成以上。6.2 教训二路由模型的冷启动期不能硬撑分类路由模型上线头两周的表现非常不稳定原因是训练数据全部来自人工标注和离线回放样本规模有限线上语义分布和离线数据存在明显差异。我们后来调整了上线节奏分三步走第一阶段先用规则路由撑场同时积累线上样本三周后再把模型加入但初始权重只允许它决策30%的流量剩余70%继续走规则和兜底之后根据观测指标逐步扩权。这套渐进式上线节奏让冷启动期几乎没有出现过指标回撤。如果当初直接全量上线路由模型大概率会在某个流量高峰掉进一个不可预料的判断陷阱。6.3 教训三快路径优化得再猛慢路径不顺路整体收益也有限第一个月我们几乎把所有精力都放在了快路径的系统调优上但账单下降并不如预期。查了数据才发现慢路径上的一次复杂任务token消耗可能抵得上快路径的上百次请求。快路径再省慢路径不动整体成本降幅很快会触顶。于是后面我们把重心转向慢路径做了三件事对工具返回的长文本做摘要压缩降低下一次推理的上下文长度对已经完成的任务做上下文裁剪只保留关键结论在生成最终答案之前先做“是否已收敛”检测提前终止冗余的推理链。这三个改动做完总成本又往下降了接近两成。这个教训让我记住了一件事分流减负治标路径内部的瘦身治本两者缺一不可。6.4 教训四快慢路径必须做并发隔离上线第二天我们就收到过高峰期慢请求超时率升高的告警。排查之后发现根因很有意思快路径的平均耗时很短会让执行引擎更倾向于接收新的快请求导致线程池里的慢路径请求一直得不到调度也就是所谓的“被饿死”。修复方案很简单给两条路径设置独立的并发池和队列按权重分配资源保证慢路径请求在高峰期也能获得最基本的算力配额。这个改动虽然小但对系统稳定性的提升是决定性的。如果当时没及时发现这个问题慢路径请求会在高负载场景下持续超时用户端看到的则是“系统变快了但复杂任务总是失败”的诡异现象。最后再说一点个人体会。DualPath这个名字起初只是我们内部对这套方案的一个代号后来在复盘文档里越写越多就固定了下来。它算不上一套多么复杂的架构真正有价值的其实是那个最简单的观察在大多数场景下我们的智能体都在用最高规格的推理能力去回答最普通的问题。效率优化的本质不是让每一次推理都变快而是让请求和资源实现精确匹配。如果你也在做类似的智能体系统不妨从拉日志分布开始。先把一轮请求按复杂度分类再决定哪些路径值得拆出来这比直接换模型、调参数要有效得多。 
长河君 · 2026/10/21 3:39:44 · 阅读 1.2k 智能体推理效率优化：DualPath快慢路径分流架构实践
上个月我在复盘智能体线上服务的性能日志时越翻越坐不住差不多七成的请求把完整的推理链路原原本本跑了一遍——任务分解、规划制定、工具调用、结果回填、最终汇总一个环节都没落下。可这些请求里有不少只是“今天天气怎么样”“帮我算一下15%的小费”这个级别的任务。打个不太恰当的比方用户只是想让系统帮忙递杯水后台却安排了一支专家团队全程陪同。结果就是用户等待首个字的时间接近两秒推理账单跟着请求量同步翻倍系统真正做完的事情和它消耗的算力资源之间差距越来越大。这个效率黑洞逼着我去重构整条推理流程最终落地了一套内部代号叫 DualPath 的架构。这篇文章就围绕它展开它到底解决了什么问题、怎么从实验阶段走向生产、以及那些文档里不会告诉你的坑。1. 效率黑洞的成因慢的不是单次推理而是整套工作流1.1 从“对话模型”到“智能体”的算力跃迁普通大模型对话一次请求基本就是“输入一段文本、输出一段文本”的两段式结构。但智能体彻底改写了这个结构系统不再是有问必答而是要走完一个完整的决策闭环理解意图、判断是否需要外部信息、确定要调用的工具、生成调用参数、发起请求、读取返回结果、继续推理、收敛答案、最终组织输出。看似只是多了几个环节实际的算力消耗却是指数级增长。我举一个亲身统计过的例子同样是“帮我查一下明天的天气”在普通对话模式下输入一段话、输出一段话就结束在智能体模式下规划模块要先产出调用计划工具参数需要模型根据当前上下文生成工具返回后模型还要重新读一遍、理解一遍、再组织语言。整个流程走下来token消耗大约是普通对话模式的40倍以上延迟差距直接拉到两个数量级。这个对比让我意识到智能体的效率问题本质上不是“模型推理一次有多快”而是“整个工作流被放大了多少倍”。1.2 上下文累积放大了每一步的成本这里有个特别容易被忽略的细节智能体每多一次工具调用工具返回的内容都会作为新消息追加到上下文里。上下文变长之后后续每一步的注意力计算量都在增加而工具返回的内容往往又携带大量低信息密度的JSON字段、原始数据、时间戳。于是系统陷入一个让人头疼的循环调用工具让上下文变长上下文变长让后续推理变慢推理变慢让整条链路占用并发资源的时间更久并发资源被长时间占据其他请求又开始排队。我们在生产环境里测过一组数据当单条请求的工具调用次数从1次增加到4次时单请求延迟不是4倍的关系而是接近7到8倍。所以如果只看单次调用耗时永远找不到问题的根源问题出在“上下文像滚雪球一样越滚越大”这个机制上。1.3 并发场景下单点变慢会引发全链路雪崩在生产环境里我还观察到一个更隐蔽的现象单条链路的慢会通过线程池排队传导到整个系统。并发池的核心数就那么多前面几个复杂慢请求把池子占满之后后面新进来的简单请求全部在队列里干等。从用户视角看不管你的请求本身多简单体验都一样糟糕。这也是为什么我坚定地认为智能体服务不能只盯着单条请求做局部优化必须从系统层面对流量做分流。慢的请求不应该拖住快的请求两者需要各走各的路彼此隔离、互不干扰。DualPath的核心动机正是源自这个观察。2. DualPath的解题思路用推理预算匹配任务复杂度2.1 从日志分布里长出来的方案做方案设计之前我先做了一件很笨但回报极高的事拉了一周的生产日志挑出代表性样本逐个标注这些请求真正的复杂度等级。人工标注的结果大致如下约62%的请求在语义上完全不需要外部工具比如问候、概念解释、简单计算约23%的请求需要调用一次工具就能完成剩下约15%才是真正需要多步规划、多工具协作、多轮澄清的复杂任务。这个分布直接说明了一个事实六成以上的流量是在用核武器做杂务。DualPath这个名字也源于这个观察——系统的基座模型不需要在每一条请求上都“火力全开”而是拆成两条路径按需供给。快路径面向不需要工具、不需要复杂推理的请求直接给出答案不走规划、不调工具、不膨胀思维链慢路径保留完整的智能体能力覆盖需要查询、操作、多步协作的任务。两条路径共用一套模型服务但在请求处理方式上完全分离。2.2 与模型量化和蒸馏的本质区别听到这里你可能会问为什么不直接用更小的模型做推理加速这里必须说清楚量化、蒸馏、投机采样这些方案和DualPath解决的是两个维度的问题。量化也好蒸馏也好目标都是把“单个推理动作”本身加速而DualPath关注的是“当前这个任务到底需不需要这么多推理动作”。两者不但不冲突反而可以叠加使用快路径上用量化后的轻量模型慢路径上继续用投机采样加速生成。但如果只做模型加速而不做路径分流复杂任务照样会因为缺少完整推理链而答错如果只做路径分流而不对模型做任何加速快路径也可能因为基座模型太慢而体验不佳。正确的顺序是先分流、再加速收益才能变成相乘的关系。这个顺序在实际落地中非常关键我在项目里见过不少团队一上来就砸重金做模型量化最后一算账延迟没降多少正确率倒是先掉了一截。2.3 路径边界划分的总原则路径边界是DualPath最敏感的设计点。我的取舍原则可以浓缩成一句话快路径的服务范围宁窄勿宽边界请求一律交给慢路径兜底。原因很朴素——智能体系统里结果正确性永远比速度重要。如果把一个需要调工具的请求误判进了快路径最后给出一个一本正经的错误答案这个代价远比让用户多等一两秒高得多。所以初始版本的快路径范围收得非常保守凡是语义中带有执行、查询、操作倾向的请求哪怕只有一点点可能也先归到慢路径等线上数据跑稳了再逐步放宽边界。3. 从实验验证到生产落地路径拆分中的三个关键决策3.1 先在离线回放里证明方案成立技术方案在原理上说得通是不够的必须离线先验证一遍。我们做了一轮完整的离线回放实验取连续一周的生产请求日志按当时实际的作答结果标注难度再在模拟环境里把DualPath的分流逻辑跑一遍逐一对比不同阈值下快路径的命中率、误判率和整体表现。这个过程的收获比想象中大很多。很多在直觉上应该进快路径的简单请求回放时发现它们的上下文已经被“污染”了——比如中间夹杂了一大段工具返回数据“简单问题”根本没法在快路径的无工具模式下正确作答。这类样本逼着我们补充了一条重要规则快路径只能处理上下文干净、不依赖外部信息的请求凡是上下文里出现过工具返回内容的一律不准进快路径。回放还帮我们确定了初始阈值。当时我们盯两个指标一个是覆盖率也就是快路径能接住多少流量另一个是误判率也就是被判进快路径但实际上需要工具的请求比例。我们设定误判率不超过5%在这个约束下尽可能提高覆盖率再用1%的线上请求做人工抽查复核确认无误后才把阈值正式写进代码。3.2 生产环境里最重要的一条铁律上线前我和团队内部反复讨论最多的问题是同一个万一误判了怎么办最后定下的铁律是快路径只能回答资源型问题绝不允许进入操作型场景。什么叫资源型比如“解释一下XX概念”“这篇文章讲了什么”“帮我算一下房贷月供”这类请求的信息都蕴含在用户已有的文本里不需要外部系统参与。什么叫操作型“帮我下单”“查我的物流”“预订明天的会议室”“读取我的订单状态”这类请求涉及操作或者需要读取个人数据哪怕被路由模块判定为简单也必须回到慢路径。这条铁律在后来拦下了很多潜在事故。我们最初上线版本里正是因为没有严格执行这条铁律才出现了后面章节里要讲的“订单查询事故”。可以说这条铁律是快路径安全运行的生命线。3.3 路径粒度先两档起步不要一上来做多档最初设计时我们设想过按任务复杂度分成三档甚至四档比如“纯直答”“单次查询”“多次操作”“深度规划”。但实际落地的经验告诉我先做两档是最稳的选择。多档意味着需要更多的标注样本、更细的边界定义以及更多联动规则复杂度会急速上升。两档架构跑稳之后再把慢路径里最简单的“单次工具查询”独立出来形成第三档反而是很自然的演进方向。我们第一阶段就是靠两档跑了一个多月积累了足够的线上数据后才开始考虑细分。这个“先粗后细、数据够了再分档”的顺序是我在这个项目里学到的最重要的工程节奏之一。4. 路由决策模块决定“走哪条路”的判官4.1 路由需要回答的两个问题路由模块是整个DualPath的心脏它本质上是在回答两个问题。第一个问题这个请求是否需要外部工具第二个问题如果不需要它能否在无上下文的情境下被安全回答第一个问题决定请求走快路径还是慢路径第二个问题决定快路径要不要携带历史会话摘要。两个问题的答案组合起来才能给出正确的分流决策。只回答第一个问题是不够的因为有些请求虽然不需要外部工具但依赖对话历史里的个性化信息贸然丢给快路径同样会答错。4.2 三段式分级路由策略具体实现上我们用的是一种三段式策略每一段都有明确的职责规则前置层。一批高置信度规则比如命中“天气、订单、物流、预订、日程”等与工具强关联的词汇直接判进慢路径。规则层要求速度极快不能做复杂的语义匹配只做词表和实体的快速命中。轻量分类模型层。一个经过量化的句向量模型加分类头输出“简单直答、需单次查询、需多步操作”三类概率。阈值设置非常保守只要“需单次查询”和“需多步操作”的概率加权和超过0.35就判进慢路径。兜底层。所有落入中间不确定区间的请求默认进入慢路径宁可多花推理资源也绝不冒险走快路径。这个设计的核心动机是让错误远离“简单任务被误答”的方向。分类模型犯错的方向主要集中在“该走慢路径却走了快路径”这是我们最不能接受的一类错误所以用非常保守的阈值和兜底规则把它死死摁住。4.3 路由延迟预算必须被严格约束路由模块本身也是一次推理调用如果一次路由判定就要花掉几百毫秒那整个优化就失去意义了。我们当时给路由模块定了硬指标端到端路由判定时间必须低于20毫秒。为了达到这个指标分类模型选了轻量级的句向量模型量化到int8之后在CPU上单次推理稳定在10到15毫秒剩下几毫秒留给规则层和缓存查询。这里有个容易被忽视的工程细节路由模型和服务主模型最好部署在不同进程里否则主模型的一次长推理会阻塞路由判定让路由延迟跟着主模型的尾巴一起抖。4.4 动态校准用业务反馈持续优化路由路由模型不是训练一次就完事的。我们每个自然周都会做一次增量训练把上一周内被系统判定为快路径但用户立刻追问、发起投诉、或者在会话里表现出明显不满的请求捞出来反标为“需要慢路径”的负样本混合到训练集里重新微调。这个机制的效果非常明显。随着业务方不断上新工具、用户语义环境持续漂移路由模型的边界会跟着真实反馈自动校准而不是永远停留在上线那一天的水平。如果省掉这一步路由模型大概运行一个月后就会开始出现偏差因为静态模型永远追不上动态的业务需求。5. 生产实测A/B对比下的延迟、成本和成功率变化5.1 实验设置与样本划分为了不让收益变成自证预言我们专门安排了一组生产环境的A/B实验。连续观测两周对照组走原有完整链路实验组走DualPath分流。两边使用完全相同的基座模型、工具列表和并发规格唯一变量就是是否有快慢路径分流线上流量按请求ID哈希随机分桶确保两组样本在难度分布上一致。5.2 核心指标对比脱敏后的核心数据大致如下表所示指标对照组实验组变化幅度端到端延迟 P50约1.9秒约0.4秒下降约79%端到端延迟 P95约3.7秒约1.5秒下降约59%平均单请求Token消耗基线值下降约57%-推理服务成本基线值下降约44%-任务完成成功率基线提升约0.4%-一个值得注意的现象是P95的降幅明显不如P50这说明长尾部分依然被少量复杂任务主导。换句话说快路径把大部分简单请求的延迟拉下来了但真正吃掉资源的复杂任务还是慢。这就引出了一个后续判断下一阶段的优化重点应该继续放在慢路径本身而不是继续在快路径上抠速度。5.3 成本结构的变化与下一步方向成本降幅虽然可观但细看账单构成会发现慢路径消耗的资源仍然占了大头。快路径因为用了轻量模型虽然承担了六成流量成本占比却不高这符合预期。慢路径上的一次复杂任务token消耗可能抵得上快路径的几百次请求。这个结构告诉我们DualPath的第一阶段收益主要来自分流第二阶段要想继续扩大收益必须对慢路径动刀工具返回结果的压缩、上下文的裁剪、多余推理链的提前终止。每一项改动都能在成本账单上看到直接反馈。5.4 快路径上的语义缓存一个额外红利我们还顺手在快路径上做了一层语义缓存对向量距离相近的重复问题直接复用之前已经生成过的答案跳过完整的生成过程。实测下来高峰期的缓存命中率可以到15%到20%这部分请求的延迟降到几十毫秒成本几乎为零。这个方案几乎是零成本接入的但有一个限制必须强调缓存绝不能用于个性化相关任务比如涉及用户姓名、订单号、会员等级的问题否则下一个用户会看到上一个用户的答案妥妥的事故。我们通过规则层把所有含第一人称和账户信息的请求挡在缓存之外才敢放开这个功能。6. 落地过程中躲不开的坑与修正6.1 教训一快路径也会一本正经地犯错第一个让我印象最深的案例是某次用户问“我的订单为什么还没有发货”。这个请求在规则层漏掉了没有命中任何工具强关联词于是被判进快路径。快路径根据通用知识输出了一段关于“订单可能延迟的常见原因”的科普式回答。用户显然不买账核心问题完全没有被解决。这是一次非常典型的能力围栏事故——快路径没有访问业务数据的权限却接入了本必须查询业务系统才能回答的问题。修复分成两层规则层补上了所有涉及“我的”“订单”“支付”“物流”等第一人称操作词的强制慢路径规则快路径生成侧新增能力校验凡是输出中带有未授权实体词直接放弃作答并降级到慢路径。自从补上这套双重校验快路径的错误率降低了九成以上。6.2 教训二路由模型的冷启动期不能硬撑分类路由模型上线头两周的表现非常不稳定原因是训练数据全部来自人工标注和离线回放样本规模有限线上语义分布和离线数据存在明显差异。我们后来调整了上线节奏分三步走第一阶段先用规则路由撑场同时积累线上样本三周后再把模型加入但初始权重只允许它决策30%的流量剩余70%继续走规则和兜底之后根据观测指标逐步扩权。这套渐进式上线节奏让冷启动期几乎没有出现过指标回撤。如果当初直接全量上线路由模型大概率会在某个流量高峰掉进一个不可预料的判断陷阱。6.3 教训三快路径优化得再猛慢路径不顺路整体收益也有限第一个月我们几乎把所有精力都放在了快路径的系统调优上但账单下降并不如预期。查了数据才发现慢路径上的一次复杂任务token消耗可能抵得上快路径的上百次请求。快路径再省慢路径不动整体成本降幅很快会触顶。于是后面我们把重心转向慢路径做了三件事对工具返回的长文本做摘要压缩降低下一次推理的上下文长度对已经完成的任务做上下文裁剪只保留关键结论在生成最终答案之前先做“是否已收敛”检测提前终止冗余的推理链。这三个改动做完总成本又往下降了接近两成。这个教训让我记住了一件事分流减负治标路径内部的瘦身治本两者缺一不可。6.4 教训四快慢路径必须做并发隔离上线第二天我们就收到过高峰期慢请求超时率升高的告警。排查之后发现根因很有意思快路径的平均耗时很短会让执行引擎更倾向于接收新的快请求导致线程池里的慢路径请求一直得不到调度也就是所谓的“被饿死”。修复方案很简单给两条路径设置独立的并发池和队列按权重分配资源保证慢路径请求在高峰期也能获得最基本的算力配额。这个改动虽然小但对系统稳定性的提升是决定性的。如果当时没及时发现这个问题慢路径请求会在高负载场景下持续超时用户端看到的则是“系统变快了但复杂任务总是失败”的诡异现象。最后再说一点个人体会。DualPath这个名字起初只是我们内部对这套方案的一个代号后来在复盘文档里越写越多就固定了下来。它算不上一套多么复杂的架构真正有价值的其实是那个最简单的观察在大多数场景下我们的智能体都在用最高规格的推理能力去回答最普通的问题。效率优化的本质不是让每一次推理都变快而是让请求和资源实现精确匹配。如果你也在做类似的智能体系统不妨从拉日志分布开始。先把一轮请求按复杂度分类再决定哪些路径值得拆出来这比直接换模型、调参数要有效得多。