去年接手的几个项目让我彻底改掉了一个毛病拿到需求先想用什么大模型而是先问一句——这个任务到底需要怎么拆、怎么派这个转变源于一次很狼狈的上线经历。当时做一个面向一线业务人员的工单助手给所有会话都套了一个动态规划Agent用户随便说一句帮我查一下上个季度的退款率系统要先来一轮意图识别再让规划器生成执行步骤然后调工具、汇总结果。听起来很智能实际上线后响应耗时从800毫秒飙到6秒token消耗翻了三倍而且经常在最简单的查余额这类请求上犯迷糊。后来我把高频、低变量、结果可预期的请求全部改成了固定工作流复杂的分析请求才交给Planner去动态编排服务瞬间稳了成本也降下来了。这次踩坑让我认真梳理了任务分发这件事Router、Planner、固定工作流到底各自适合处理什么它们的边界在哪里怎么组合才不会把系统做成一个看上去很聪明、用起来很糟心的玩具这篇文章就把我这一年的实践经验、踩过的坑、以及最终沉淀下来的分流方法论全部摊开来讲。1. 先把三兄弟认清楚Router、Planner、固定工作流到底在解决什么问题很多人在设计AI Agent系统时会把这三样东西混为一谈。有人觉得Router就是Planner有人觉得固定工作流是低端方案还有人一上来就上Planner结果把系统拖垮。它们的本质区别是决策粒度和决策层级完全不同。1.1 Router在岔路口选择路线Router做的事情非常朴素按照既定规则把请求分类、导向不同的处理链路。它不生成步骤不做推理它只回答一个问题——这个请求属于哪一类用一个生活化的类比Router就像地铁换乘站的指示牌。你拿着目的地用户请求指示牌告诉你该走A出口还是B出口路由判断但它不会帮你规划怎么买票、坐几站、要不要换乘。指示牌的判断标准是预先定好的规则清晰结果确定。技术实现上Router可以是纯规则关键词匹配、正则表达式可以是一层轻量分类模型也可以是针对性调优后的小模型。它甚至不一定要用大模型——很多场景下一个训练好的短文本分类器比GPT-4做路由又快又便宜。1.2 Planner在未知地图上找路Planner解决的问题要复杂得多面对一个没有固定解法的任务自动分解步骤、选择工具、编排顺序。它回答的问题是——完成这个目标需要依次做什么继续用地铁类比Planner不是指示牌而是你打开手机地图App输入目的地后它给你算出的那几条换乘方案。如果正好赶上某条线路故障地图会重新规划路线绕开故障区段。这里的核心词是动态。Planner面对的是开放世界任务的解法不唯一依赖的条件可能会变需要用到的工具组合是事先无法穷举的。所以Planner需要借助大模型的推理能力在运行时生成步骤序列并根据中间结果不断校正后续计划。1.3 固定工作流把路铺成铁轨固定工作流就是一段预先编排好的执行链路。A步骤完成后必做B步骤B产生的结果传给C中间没有任何选择和推理只有确定性的执行。还是那个地铁例子固定工作流更像是地铁本身——轨道铺好了列车沿着既定线路走每一站停多久、下一站去哪都是写死在运行图里的。只要不出故障它永远按同样的方式运行结果稳定得让人放心。固定工作流听起来不智能但它是系统工程里最值得信赖的部分。它不需要模型不消耗token不会产生幻觉也不存在今天状态不好答错了的情况。一个成熟的Agent系统80%甚至更高比例的流量都应该由固定工作流承接而不是全部丢给大模型去自由发挥。1.4 三个关键维度帮你看清边界把三者的区别压缩成一张对照表选型时对着看就清楚了维度RouterPlanner固定工作流决策内容请求属于哪个类别如何拆解并达成目标按预定义步骤执行决策时机请求进入时一次确定运行时持续生成和修正设计与编码时已确定输入变量类别有限、可枚举开放、组合爆炸参数少、范围可控实时推理无或极轻量强、依赖大模型无成本很低高极低失败模式分类错误步骤生成错误/工具调用失败参数越界/外部依赖异常判断一个任务该交给谁问三个问题就够了这个任务的解法是固定的吗是——走固定工作流。不是——进Planner。这个任务的类别能穷举吗能——用Router分流。不能——只能让Planner上。这个任务会频繁出现吗高频且稳定的场景再复杂也值得逐步固化成工作流低频且开放的场景才值得用Planner。2. 选型之前必须算清的六笔账从变量数量到错误预算团队在讨论要不要上Planner时经常陷入一个误区觉得Planner 智能 先进固定工作流 笨 落后。但真实的工程决策不应该是选最聪明的而是**选成本最低且能满足需求的**。2.1 变量数量与组合空间第一个要算的账是任务可能的输入变量有多少。如果用户请求可以被拆成固定的几个槽位时间、地点、对象、动作每个槽位的枚举值有限那么这个任务没有理由使用Planner——它要面对的组合空间根本撑不起动态规划的必要性。比如工单系统里的查询退款进度参数是订单号动作是调用查询接口返回模板是固定的。这个任务无论用户怎么问最终要做的都是同一件事。用Planner生成步骤等于让一个博士生去算11能算对但成本完全不合理。反过来如果用户请求是对比这三款产品的性能差异然后根据我的使用场景推荐一款再到用户社区整理一下口碑这个任务的变量组合几乎不可枚举——用什么维度对比推荐标准是什么社区帖子怎么筛选此时Planner才有存在意义。判断方法很简单拿最近三个月的真实用户请求尝试为它们穷举意图 → 动作序列的映射。如果能覆盖90%以上就别上Planner用Router固定工作流就够了。2.2 错误预算与容错空间第二个必须算清的是错误预算。不同任务的错误代价天差地别查天气查错了用户刷新一下就好错误成本约等于零。订单退款金额算错了用户投诉客服介入错误成本中等。医疗建议给错了自动驾驶路径规划错了错误成本是灾难性的。Planner的推理过程天然存在不确定性。即使大模型再强在工具调用、参数生成、条件判断的每个环节都有出错概率。当任务的错误成本远高于省下来的token成本时固定工作流的确定性就变成了最宝贵的资产。我见过一个失败的案例一个报销审批Agent用Planner动态判断发票是否合规、金额是否超限、是否需要上级审批。结果Planner在一次判断中把2024年3月识别成了2024年13月下游系统直接拒绝执行。后来把审批流程改回固定工作流发票校验、金额比对、审批链匹配全部用规则实现只在发票内容模糊、拿不准是否合规的边缘case才升级给大模型做辅助判断错误率直接降了两个数量级。2.3 延迟与成本预算很多人忽略了一个事实Planner的每一次规划都是一次甚至多次大模型调用。一个Plan-Execute结构的任务至少包含一轮生成计划若干轮执行反馈和计划修正意味着单次用户请求可能消耗5到10次模型调用。按当前主流模型定价算单次请求的成本可能达到固定工作流的20到50倍。延迟同理。固定工作流中的每一步都是毫秒级API调用Planner的每一步都是秒级模型推理。如果产品对响应速度有明确SLA比如客服机器人5秒内必须首响那么Planner的延迟预算可能根本不够用。一个务实的做法是把Planner放在异步计算中。用户提交复杂任务后先返回任务已接收正在处理后台由Planner慢慢编排执行最终通过消息通道推送结果。把实时路径留给固定工作流把非实时路径交给Planner这是一种非常实用的分流策略。2.4 可观测性与调试成本Planner的另一个隐性成本是调试难度。固定工作流每步干什么、参数是什么、失败在哪里看日志一目了然。Planner的步骤是模型现编的每次可能不一样失败时你得去翻模型推理的完整链路——这对工程团队的调试能力提出了极高要求。我自己的经验是如果一个任务的调试记录里超过30%的时间花在蹲推理日志、复现模型的随机行为上这个任务就应该被固化。把模型生成过的、验证过正确的步骤序列沉淀下来逐步转成模板化的固定工作流是提高系统稳定性的最佳路径。这也是为什么我常说Planner应该是一个会越来越清闲的组件——它的工作是不断给自己寻找退休机会。2.5 语义的开放程度有些任务表面上是固定流程但用户的表述方式千奇百怪。查一下上个月的电费和帮我看看我家最近用了多少电是同一件事但前者可以直接规则匹配后者需要在语义层面理解。这时候Router就发挥作用了用一个语义分类模型把各种表述归一到固定意图上再让固定工作流去执行。Router负责把开放的自然语言翻译成有限的意图枚举固定工作流负责把这些枚举变成稳定的执行过程Planner只处理真正的非结构化目标。这是三者最理想的分工模式。2.6 团队的维护能力最后一个常常被忽视的维度你的团队有多少精力去维护一个Planner系统Planner的prompt、工具定义、上下文管理、安全防护、模型版本升级适配……每一项都是长期维护成本。如果团队只有两三个人又处于业务验证期我强烈建议先用Router固定工作流把闭环跑通等流量和需求都证明了这个方向可行再引入Planner去覆盖那些固定流程解决不了的部分。3. Router分流的落地姿势路由表设计、意图识别与兜底策略前面讲了那么多选型逻辑这一节进入实操。Router作为分流的第一道关卡设计得好不好直接决定整个系统的效果。我把Router的落地拆成四件事路由定义、意图识别、参数抽取、兜底策略。3.1 路由定义先有工作流再谈Router设计Router的第一步不是写分类模型而是先画出系统里到底有哪些执行链路。没有明确的执行单元Router就没有路由目标。我习惯用一个简单的方法做链路梳理把过去一个季度的用户请求全部导出来人工聚合成若干意图簇每个意图簇对应一个执行链路。比如电商客服场景可能会有这些链路订单查询状态、物流、签收时间退换货处理申请、进度、条件校验发票服务开具、修改、下载商品咨询参数、库存、比价投诉建议记录、升级、回访复杂综合分析需要Planner处理的开放性请求每个链路都要明确三个要素触发条件、执行步骤、成功标准。触发条件写清楚什么情况下请求属于这条链路执行步骤把每一步的输入输出定义好成功标准用来判断链路是否完成使命。实际上路由表的维护是一个持续的过程。上线后要每周或每月复盘一次站内请求看看有没有新的意图簇出现有没有旧的意图簇合并。这个动作花不了多少时间但能让路由表始终贴合真实用户的使用习惯。3.2 意图识别规则的归规则模型的归模型意图识别的实现方案分三层按成本和复杂度顺序排列第一层精确规则。关键词、正则、短语匹配。适合那些表述方式足够固定的场景查订单退换货开发票。这一层零成本、零延迟、零幻觉风险能接住多少就接住多少。第二层小模型分类。用一个几千条标注数据训练出的短文本分类模型去覆盖规则匹配不到的同义不同形表达。比如东西还没到和为啥我的快递这么慢都能归入物流查询意图。这种小模型参数量在几千万级别推理耗时几毫秒成本几乎可以忽略。第三层大模型分类。当小模型实在搞不定、数据标注成本太高时才考虑用大模型做少样本意图分类。这时候一定要给模型提供清晰的选项列表和示例并设置置信度阈值低置信度一律不要硬分类。我见过一个反面教材团队用GPT-4做意图识别但不设置信度阈值。模型在不知道说什么的时候会随便猜一个意图把帮我看看附近有没有充电桩路由到了车辆保养预约——因为会员活动里提到过充电桩。后来加了置信度阈值和无法分类兜底这种情况才被拦住。3.3 参数抽取Router做的是“翻译”不是“理解”意图确定后还需要从用户请求中抽出执行链路所需的参数。这一步有个重要原则参数抽取的可靠性比覆盖面更重要。抽不到参数时宁可多问一轮让用户补充也别用模型猜一个大概率正确的值。——猜参数是系统全面劣化的开始。参数抽取同样分层次固定工作流的参数天生有限可以写规则配合正则或用一个小的序列标注模型只有在参数是开放性自由文本且确实依赖上下文理解时比如投诉内容摘要才考虑用大模型生成并且生成的参数必须经过格式校验。这里额外强调一个容易犯的错误参数抽取和意图识别是两件事别混在一个模型调用里做。虽然技术上可以一条prompt同时输出意图和参数但一旦意图错了参数一定错你还无法定位是哪一步出的问题。拆开做每一步都可独立测试、独立优化调试成本会低很多。3.4 兜底策略Router永远要准备一句“我不知道”Router设计里最容易被忽视的就是兜底策略。任何分类模型都不可能100%准确与其让模型强行分类不如明明白白告诉用户这个请求我暂时处理不了需要转人工。兜底方案要有梯度置信度低于阈值时主动向用户澄清意图您是想查询订单状态还是想申请退换货多轮澄清可以让用户以最小的成本把意图说清楚。澄清一次仍不明确提供人工客服入口自动把会话上下文和用户历史摘要转给人工。转人工时一定把Router的判断过程带上——哪个意图候选、置信度多少、用户原始表述原文——这些信息能帮人工快速理解用户的真实需求。一个好的兜底策略不会让用户体验下降反而会让用户觉得这个系统知道自己的边界。这一点在客服场景中尤其重要用户宁可多敲几个字说清楚也不愿意被一个装懂的机器人带偏。4. Planner的正确打开方式规划-执行闭环与少即是多如果你的任务确实够复杂固定工作流覆盖不住Planner就该登场了。但Planner不是万金油用得好能显著提升系统能力边界用不好就是给线上环境埋雷。4.1 Plan-Execute闭环规划与执行必须分离Planner的正确架构是Plan与Execute分离的闭环。我见过一些团队让一个Agent一边规划一边执行每一步都重新推理下一步干嘛结果就是模型在每一步都有新的想法经常做着做着偏离最初目标。标准的Plan-Execute模式长这样Plan接收到目标后大模型先生成一个完整的步骤清单例如查询数据、分析、生成报告。Execute系统按清单逐步执行每一步调用对应的工具或工作流。Observe每步执行后把结果回填到上下文。Re-Plan如果某一步执行失败或结果与预期明显不符Planner重新调整后续步骤。Finalize所有步骤完成汇总输出。这个结构最大的好处是规划是一次性的、可审计的。用户可以直观看到系统准备怎么做如果计划有问题用户能在执行前提出来而不是等系统黑箱跑完才发现方向错了。这在企业服务场景里几乎是刚需。4.2 Planner的边界别让它做超出工具能力的事一个常见的误区是让Planner做它能力范围之外的事——或者说让Planner去调用一个根本不存在、或能力很弱的工具。Planner再聪明也只能在工具定义允许的范围内工作。如果系统的工具层只有查询订单和查询商品两个APIPlanner无论如何也不可能帮你完成自动比价的任务。所以设计Planner之前先盘点工具层的能力边界每条工具的定义、入参、返回值、可能的失败模式必须全部文档化喂给Planner的工具说明要写得极其清晰。工具说明的质量直接影响Planner的执行效果。工具名要语义化描述要写清楚什么时候用、输入是什么、输出是什么、可能抛什么错。不要用api_query这种名字要用get_order_status描述不要写查询订单信息要写根据订单ID查询订单当前状态返回状态码、物流信息、预计送达时间当订单不存在时返回404错误。工具说明写得好Planner的成功率会有一个肉眼可见的提升。4.3 少即是多Planner里嵌套固定工作流Planner的步骤不应该是一堆原子操作而应该尽可能复用已有的固定工作流。换句话说Planner的一步可以是Router固定工作流的一整段链路。举个例子一个项目分析AgentPlanner生成的步骤可能是统计各渠道的转化率、找出转化率最低的渠道、分析原因并给出建议。这里的统计转化率完全可以复用已有的报表工作流而不是让Planner自己去调数据接口、自己写SQL、自己算指标。这种设计的价值在于把Planner的智能集中在它真正擅长的部分——拆解目标和推理决策——而把确定性强、高频复用的部分交给工作流去执行。Planner负责想工作流负责做两者互相配合系统的稳定性会大幅提升。4.4 Planner的失败恢复主动留下后门Planner必然会遇到执行失败。失败不可怕可怕的是失败后没有恢复路径。我给Planner设计了三种恢复机制步骤重试工具调用超时或返回异常允许重试2到3次每次重试前把错误信息反馈给Planner让它决定是重试还是换一种方式。步骤替换某一步执行彻底失败时Planner可以在满足目标的前提下换一个等价方案。比如查不到官方数据源可以改用公开数据源并明确标注数据来源的变更。人工兜底连续失败达到阈值或者失败步骤触及关键路径且无替代方案时直接转入人工处理。从Planner到人工的转交链路必须提前设计好。等线上事故发生了再想怎么转人工就晚了。关于失败恢复有一条铁律Planner的每一次失败都应该被完整记录。失败原因、上下文快照、当前计划、重试次数、最终结果全都要结构化存储。这些数据是后续优化工具层、优化prompt的黄金素材。5. 固定工作流的三个经典入场时机固化、编排与降级固定工作流虽然看起来不高级但在工程实践里它才是保证系统可靠性的核心底座。真正的问题是什么时候把一段流程固化成工作流什么时候用它去编排已有能力什么时候拿它做降级5.1 时机一验证过的高频路径逐步模板化Planner跑通一个需求后这段过程往往隐含着固定的模式。拿查汇率举例第一阶段Planner刚跑通代码很兴奋地觉得以后再也不用写死逻辑了。结果上线一周发现查汇率这个请求占了总请求量的15%——用户每次都问一模一样的问题Planner每次都要重新规划一遍“找到汇率API→调用→格式化返回”。这不是智能这是浪费。正确的做法是把查汇率这个意图从Planner里摘出来固化成一条固定工作流。用户问100美元是多少人民币走规则匹配汇率API50毫秒返回结果消耗为零。这个从Planner到工作流的过程我称之为**流程沉降**。沉降的触发条件通常是同一目标在一个月内被Planner成功执行超过N次且执行路径没有发生变化。落地方式把那次成功执行的步骤序列作为模板固定下来。5.2 时机二用工作流编排确定性中间过程还有一类工作流的入场时机更早——在系统设计阶段就能确定某些任务的中间环节是确定性的。比如客服工单的分配流程用户提交工单→校验必填字段→创建工单→按SLA分配→通知责任人。这个流程里没有任何一步需要智能它们只是按规则串起来的API调用。把这些环节做成固定工作流不仅稳定而且和上游的Router、下游的扩展点能完美配合。有人可能会问这种固定工作流不算AI系统了吧我的看法是AI的真实落地从来不是让所有环节都智能而是在正确的环节引入智能。固定工作流负责执行AI负责在关键岔路口做判断、在复杂场景下做规划这才是一个吻合成本、稳定、体验三重约束的架构。5.3 时机三Planner失效时的安全降级路径前面提到Planner失败要转人工但在转人工之前还应该有一层半自动降级从Planner降级为固定工作流。比如一个复杂的市场分析报告AgentPlanner要生成分析框架、查询数据源、撰写结论。如果Planner连续两次规划失败系统可以降级为固定工作流模式使用预定义的分析模板固定维度、固定指标、固定格式自动拉取基础数据生成一份简化版报告。这份报告可能不如Planner生成的那么贴合具体需求但至少能交差。“能用但普通”的结果远胜于系统不可用。这个降级路径的价值不只是提升可用性更能保护产品口碑。用户遇到复杂任务失败时若能在几秒内收到一份简版结果负面情绪会小很多。5.4 固定工作流的可维护性把步骤可视化固定工作流最需要注意的是可维护性。流程一旦固化后续肯定会有人来改。如果工作流藏在代码的深层调用里改起来就是一场噩梦。我建议把固定工作流的步骤定义用结构化的方式表格、JSON、流程图文本显式维护每一步都有明确的输入、输出、超时设置和错误处理逻辑。这样后续调整步骤顺序、替换数据源只需要改配置不需要改代码。例如一个标准的订单退款工作流配置至少应该包含以下字段步骤ID、步骤名称、调用方法、超时时间、重试次数、失败后的处理方式。每步的失败处理要跟业务规则对齐——不能因为一步失败把整个退款流程卡死。6. 混合分流架构“Router → Planner/工作流”的双层控制面前面讲了三者的区别和各自的适用场景实际上一个成熟系统里三者不会单独存在而是构成一条两级分流的流水线Router做第一层分流把请求分为固定链路和开放任务开放任务再进入Planner做第二层决策。这条流水线我称为混合分流架构。6.1 两级分流Router管分配到哪个“车道”Planner管怎么“开车”整体架构可以用这样一条逻辑串起来用户请求进入Router——Router先做意图分类和参数抽取。Router判断意图是否命中已有固定链路。命中则直接转入对应的固定工作流。未命中、或意图本身就属于开放性分析/生成型任务的进入Planner——Planner针对目标生成步骤清单。Planner生成的每一步能复用既有工作流的调用既有工作流不能复用的再调用原子工具。执行过程中Planner根据中间结果动态调整后续步骤。执行完成后系统把结果、执行轨迹、成本数据全部记录下来路由分析器定期统计哪些任务被反复规划为该任务标记可固化信号。这套架构的核心思路是把确定性和动态性分层管理不同决策交给不同层级的组件互不干扰。6.2 控制面与数据面的分离把路由策略讲清楚这套架构里Router和Planner共同构成了系统的控制面负责决定怎么做固定工作流和工具层构成了数据面负责真正去做。控制面和数据面分离带来的直接好处是你可以单独升级路由策略和规划策略不需要动执行逻辑也可以独立测试、独立加监控。控制面的一个重要工程实践是策略可视化。我曾经在一个项目里把所有路由规则和兜底逻辑全部写在代码的if-else里结果三个月后没人能说清楚系统对某类请求到底做了哪些判断。后来我把路由规则抽离成一份配置文件什么条件命中什么意图、置信度阈值多少、未命中时走什么兜底、什么条件下请求会被升级给Planner。配置一目了然新同学接手时看一遍就能上手。控制面和数据面分离还有一层深意控制面的逻辑可以不断学习进化数据面的执行必须保持稳定。这个稳定既指运行稳定也指业务逻辑稳定——执行层不要频繁变动否则整个系统的可预期性会瓦解。6.3 可观测性设计给每一次分流留档案混合架构上线后最需要的是好的可观测性。我建议为每次请求保留一份分流档案至少包含原始用户输入Router的意图判断结果和置信度参数抽取结果走了固定工作流还是PlannerPlanner生成的步骤序列如果走了Planner每步执行的结果和耗时总耗时、总token消耗、成本和错误信息有了分流档案能做的事情就多了通过分析Router的置信度分布发现哪些意图边界模糊针对性补充训练数据。通过分析Planner的成功率发现哪些任务当前不适合Planner处理考虑是不是可以直接做沉降变成固定工作流。通过分析整条链路的耗时构成定位性能瓶颈是在Router、Planner还是下游工具。可观测性不只是运维的附属品。对一个持续演进的分流系统来说它恰恰是未来优化的燃料。6.4 容量规划与限流别让Planner打垮整个系统最后提醒一个很容易被忽视的问题Planner对算力的消耗是突发性的、不可预测的。如果不做容量规划一个爆款流量进来大量请求涌入Planner可能导致整个系统的算力被占满连固定工作流都跟着变慢。给Planner设置独立的配额和限流是必须的每秒最大并发数、单任务最大步骤数、单步最大重试次数、单任务最大token消耗这些值必须在设计阶段定下来。超出配额的请求要么排队等待要么直接降级为固定工作流。这个保护机制会让系统在流量洪峰下不至于全面崩溃而是聪明地退让。7. 回到Claude Code配置Router的那些讨论从聊天到代码生成的通用性前面讨论的架构在对话式客服、企业知识库助手这类典型Agent场景中很常见。但其实Chatbot之外的很多领域同样用得上这套分流思路——比如代码生成场景中常见的工具型AgentClaude Code等。7.1 代码生成场景的Router配置选择思考模式前段时间社区里有很多关于Claude Code router配置思考模式的讨论。我发现这和前面讲的任务分流其实是同一个问题——代码生成任务同样要面对简单问题直接答与复杂问题需规划的取舍。在一些代码生成工具里会内置Router机制面对一个Bug修复请求先判断这个Bug是否明确比如第几行抛了个TypeError如果是直接走快速修复路径调用代码搜索和工作流定个格式返回如果问题描述模糊比如我的程序跑起来很慢帮我看看怎么优化Router会把任务交给思考模式让模型生成一个分析计划分步诊断、定位、优化。这其实就是简单请求走固定链路复杂请求走Planner的翻版。好的配置一定是让Router以最快的速度识别出这个问题不需要长时间思考而不是每次请求都把思考模式拉满。思考模式消耗的token和时间是普通模式的数倍如果所有请求都进思考模式整体吞吐量会急剧下降用户体验反而变差。7.2 代码生成任务里什么时候该给Planner思考判断一个代码任务要不要走深度思考模式我觉得核心看一条用户问题的信息量是否足以直接给出可行方案。这段代码为什么会报IndexError——问题具体、上下文明确直接让模型结合报错信息定位即可不需要Router去展开步骤规划。帮我设计一个支持多租户的权限系统要考虑到数据隔离、审计日志和未来的扩展性——这属于开放设计任务目标模糊、约束多样必须让Planner先生成架构方案、再分步实现。在这种情况下Router如果直接把任务当成普通代码问答处理生成的结果大概率是泛泛而谈的样板代码。实际配置思路是把Router的思考模式触发条件和代码任务的复杂度绑定。具体来说可以让Router用一层轻量判断来识别问题是否涉及多文件改动、是否涉及架构设计、是否包含模糊业务目标。这些特征出现越多越应该进入Planner。7.3 跨领域的共同原则效率来自正确地分流所以你看无论是客服机器人还是代码生成Agent底层原则完全一致能确定的任务一定要交给确定性的执行链路。真开放的任务才给Planner去规划。Router的职责是永远以最低成本判断当前请求属于哪种情况。这个原则放之四海而皆准。它跟具体的模型、具体的开发框架、具体的平台没有关系只跟一个朴素的工程常识有关每一个决策层的复杂度都应该与问题的真实复杂度匹配。把所有请求都交给最复杂的决策层处理是对计算资源的巨大浪费也是对产品稳定性的不负责。8. 当Planner遇上规划器从Mission Planner到Lattice Planner的跨领域类比文章写到这里很多读者可能会想你说的Planner跟无人机领域常说的Mission Planner、自动驾驶里的Lattice Planner、图像生成里的Diffusion Planner是一回事吗这个问题问得很好。不同领域对规划器的定义差异很大但共享同一套逻辑——在约束条件下寻找一条可行的执行路径。做一个横向类比对深入理解AI Agent里的Planner设计大有帮助。8.1 无人机/机器人领域Mission Planner与Lattice PlannerMission Planner地面站是无人机领域最常用的地面控制软件之一。操作员在地面站上设定任务航点、飞行高度、速度无人机飞控系统按预定航线自主飞行。这套系统的典型特征是航点是离线规划好的飞行参数是写死的执行过程完全确定。这样做的原因很简单——飞行安全是最高优先级任何飞行中途临时起意的规划都可能带来不可控风险。用这个类比看AI Agent凡是涉及不可逆动作、安全风险高、执行结果影响重大的任务都应该像Mission Planner一样按预设航点执行而不是让模型在运行时自由发挥。比如支付、退款、删除数据、发送营销消息——这些操作的流程必须固定、可控、可解释绝不能依赖Planner的动态推理。Lattice Planner则不一样它是自动驾驶领域常用的局部路径规划器。车辆在行驶中Lattice Planner会在车辆周围生成大量候选轨迹横向位移、纵向速度不同组合再用约束条件避障、舒适性、交通规则筛选出最优轨迹。它的特点是规划发生在行驶过程中实时更新而且每条候选轨迹都是先枚举再筛选的。AI Agent里对应的场景是一次执行过程中根据中间结果不断修正计划的动态规划比如做市场调研时如果发现原定数据源无法访问就立刻切换数据源调整后续分析步骤。Mission Planner和Lattice Planner的对比告诉我们一个重要原则离线规划追求的是最优解和高度可预测性在线规划追求的是可行性和适应变化。Agent的Planner设计里这两者其实对应两种不同模式模式一先生成完整计划再逐步执行——适合目标明确、中间过程不太可能出岔子的任务。 模式二边执行边规划走一步看一步——适合环境变化快、外部依赖多的任务。具体场景选择哪种模式我的建议是能用模式一解决的问题不要用模式二。模式二虽然灵活但每一步都在消耗推理成本而且每一步都可能引入新的错误。8.2 图像生成/规划领域Hyper Diffusion Planner的含义在图像生成领域最近也出现了一些Diffusion Planner、Hyper Diffusion Planner的概念。这里面的Planner更多指向的是用扩散模型的分步去噪过程作为视觉运动规划器让机器人或自动驾驶系统直接基于视觉输入生成运动轨迹。这种从感知直接到规划的思路在AI Agent设计里也有对应物端到端的任务规划——跳过显式的工具调用和步骤分解直接根据用户输入生成最终答案。简单说就是别管我怎么做我直接帮你把活干完了。这种端到端模型适合什么场景适合那些过程不可见也无所谓的场景——比如语义解析、文本摘要、代码生成。而前面说的Plan-Execute模式则适合用户需要看到过程、需要中途介入、需要审计轨迹的场景。这两种模式没有绝对的高下之分但对Agent系统的设计者有很强的启示并不是所有任务都需要显式规划。有些任务是感知→动作的直接映射强行让它们经过Planner反而增加了延迟、成本和出错概率。8.3 规划器无处不在关键在于识别规划层级Mission Planner、Lattice Planner、Diffusion Planner、Agent Planner——每个领域都有自己的规划器它们的共同点都是在不确定中找到一条可行的路。但不同规划器的核心差异其实在于规划的空间/范围有多大、规划的响应时间有多长。规划范围小、响应时间短——那就是Lattice Planner式的实时规划范围大、响应时间长——那就是Mission Planner式的离线任务规划范围介于两者之间、需要兼顾计划和执行的——就是Agent Planner。给系统设计任务分流时本质上就是在做一次规划层级的划分最高层级判断这个任务该由哪套机制来规划——这是Router的工作。中间层级对于开放任务生成步骤序列并动态调整——这是Planner的工作。最低层级对于固定任务严格按照预设链路的执行——这是固定工作流的工作。每一层各司其职系统的整体行为才会既稳定、又灵活。9. 实战复盘一个电商工单助手的分流改造全流程文章最后用一个完整的实战案例来串起前面所有的理论。这个案例不是虚构的是我去年做过的真实项目不涉及客户敏感信息但方法完全可以复用。9.1 原始架构的问题全量Planner的代价项目背景一个电商平台的客服工单助手用户可以通过对话提交售后请求、查询订单、咨询商品问题。第一版架构很简单——所有请求都进一个Planner Agent让它自己决定调用什么工具、怎么组织回答。上线后暴露出来的问题很典型平均响应时间6.8秒远超客服系统3秒内响应的内部SLA。token成本居高不下日均成本是预估的3倍。高频简单问题查订单状态、退换货进度经常因为多轮对话上下文干扰而答错——Planner在前面对话中生成的无关步骤污染了后续判断。排障困难。用户投诉时技术人员需要翻查询日志里的链条才能明白Agent为什么这么做。9.2 分流改造的三个阶段阶段一部署Router拦截高频意图第一步从历史工单里提取Top 10高频意图占了总请求量的78%。针对这10个意图分别设计了固定工作流订单查询、退换货申请、发票处理、物流查询、售后进度、退款查询、优惠咨询、商品参数、库存查询、地址修改然后用一个轻量意图分类模型做Router。Router的置信度阈值设为0.85。命中高频意图且置信度达标的请求直接走固定工作流未命中或低置信度的请求才进入Planner。改造效果立竿见影78%的请求不再经过Planner平均响应时间从6.8秒降到1.2秒token成本降到原来的1/4。阶段二优化低频但固定类请求的工作流Router跑了一段时间后我们从分流档案中发现一个现象有一些意图虽然总量不大但请求结构高度相似——典型的是修改收货地址。把地址改成北京市朝阳区XX路1号这个意图的表述千变万化但执行动作是固定的更新用户地址字段、返回更新结果。这类请求的问题是地址信息经常是开放性自由文本且依赖上下文改成上次那个地址单靠参数抽取规则搞不定。我们的处理办法是给这个固定工作流增加一个参数补全Agent——用大模型专门做地址抽取和歧义消解抽取结果经过程序化校验后传给固定工作流执行。这就是**让大模型做参数理解让工作流做业务执行**的典型案例。改造后这类请求不再进入完整Planner成本又降了一截可靠性反而更高。阶段三给Planner挂上可沉降信号改造完成后Planner只剩三成左右的流量。我们从分流档案里每周拉一次Planner成功执行任务统计一旦发现某个目标连续四周出现、且执行路径稳定就和业务方评估是否固化成工作流。上线两个月后又新增了六个固定工作流Planner的流量进一步降到总请求量的15%左右。系统整体响应速度和成本都保持在很理想的水平。最终效果我列一下几个关键指标给大家一个直观体感指标改造前改造后平均响应时间6.8秒1.1秒P95响应时间12秒2.8秒日均token成本基准值x约0.2x高频意图准确率91%99.2%人工介入率12%5%排障定位时间小时级分钟级这个案例充分说明了分流架构的真实价值不是为了让系统更聪明而是让系统在聪明的同时保持高效和稳定。如果你现在也在做一个重度依赖大模型的Agent系统怀疑为什么我的智能体这么贵、这么慢、还不稳定那大概率不是模型的问题而是分流没有做到位。写到这里我把Router、Planner、固定工作流的分工逻辑、选型方法、落地姿势、以及混合架构的搭建方式都摊开来聊了一遍。最后再分享一条我在实际项目中反复验证的心得设计任务分流永远从最少智能的地方开始——能规则的绝不调模型能小模型的绝不上大模型能固定工作流的绝不上Planner。把智能当成一种稀缺资源集中在真正需要它的地方使用。这套方法才是做高性价比AI应用的正确姿势。