先别急着调模型、调 Prompt。“Agent 工作流架构设计”这件事决定权往往不在模型能力而在你搭的那条链路长什么样。增强型、链式、路由式这三套架构范式最近一年几乎出现在所有 Agent 项目的评审稿里。但很少有人讲清楚它们分别解决什么问题、各自适合什么业务、怎么组合才不会翻车。这篇文章我把三套架构从设计逻辑到落地参数完整拆一遍适合正在搭多 Agent 系统、做复杂任务编排的读者也适合刚接触 Agent 工程的入门者建立整体判断框架。这三套架构听起来像是“术语包装”实际上对应的是三种非常朴素的工程决策。你自己想想当一个任务进来了你是让单个 Agent 自己拿着工具反复试还是切开成固定步骤一步步走还是先判断一下这个任务该给谁这就是增强型、链式、路由式的本质。想通这一点架构选型就不会再纠结。1. 为什么先定架构而不是先定模型1.1 三种架构的核心区别我把它们放在同一个表格里对比你看完就知道差距在哪儿架构类型工作方式决策权位置典型延迟可控性适合任务增强型单个 Agent 循环调用工具自我反思Agent 自己高取决于迭代次数低结果随机性大开放式探索任务链式多个步骤按固定顺序执行节点之间传数据编排层中可控高每步可校验流程固定、多阶段任务路由式入口节点判断意图再分发给对应处理分支路由节点低一次判断中取决于路由准确率多类型请求、差异化管理增强型强在“智能感”它像一个实习生你给它目标和工具箱它自己想办法链式强在“确定性”像工厂流水线强调固定工序路由式强在“分发效率”像前台的接线员把不同电话转给不同部门。1.2 架构选型的第一问题边界在哪里我见过最多的设计错误是先用增强型架构写一个完整用例跑通了就觉得万事大吉结果上线一星期发现三件事按不住成本飘了、响应时长飘了、同一个问题给出的答案飘了。原因很简单增强型架构把太多决策权交给了模型而模型天然带随机性。你在选架构之前必须先把任务的“边界”划清楚。这个任务是不是有明确目标有明确完成标准吗中间环节用户是否允许等待两分钟任何一个环节允许模型自由发挥都会吃掉时间和预算。所以我的建议是先画出任务流程图标出哪些节点是判断类节点哪些是执行类节点。判断类节点多的用路由执行顺序固定的用链式只有一个目标、需要多步探索的才考虑增强型。1.3 从业务倒推架构三个判断指标具体落到业务上我用三个指标去倒推完成标准是否可自动判定。比如“把文章翻译成英文并把译文放进数据库”完成标准很明确可以拆成链式“帮我写一份竞品分析报告”完成标准模糊适合先路由判断范围再增强式迭代。输入类型是否单一。同一个入口进来的请求意图五花八门那就必须做路由如果入口本身就是服务一个固定场景比如“只做订单状态查询”直接链式即可。失败容忍度。金融交易、医疗建议这类场景绝不允许 Agent 自己在中间乱绕路由加链式是必须的因为每一步都能审计、能回退。内容生产、头脑风暴这类场景容忍度高可以更多用增强型。2. 增强型架构让 Agent 自己想办法2.1 核心循环的五段式结构增强型架构的核心是“循环”不是“一次调用完事”。一个完整的工作循环可以拆成五段接收任务拆分计划调用工具执行观察工具返回结果根据结果决定继续执行还是终止这五段循环会反复走直到 Agent 自己认为任务完成或者命中你设置的终止条件。这个循环里最关键的是最后两段“观察”和“决定”。很多初学者的 Demo 只是让模型生成一句“我要调用工具”然后把工具结果丢回给模型却不告诉它“你现在的状态是什么”。结果是模型会重复调用同一个失败工具原地转圈。真正的增强型架构在每轮循环之后要把历史行动计划、工具结果摘要、当前已完成状态一起打包作为下一轮推理的上下文。2.2 工具层与记忆层怎么增强增强型架构的“增强”主要体现在两个方向工具增强和记忆增强。工具增强的核心是工具注册表。你定义一段结构化描述告诉模型“有什么工具、什么时候用、参数是什么”。比如一个查天气的工具描述写成“当用户询问天气时使用参数为城市名”。听起来很简单但实际工程里必须做工具参数校验避免模型生造参数。我见过模型调用一个日期工具时传出了“2025年2月30日”这种不存在的日期因为模型对历法规则理解不稳定工具层如果不做校验就会把这个错误参数直接发给上游接口。记忆增强最常用的是 RAG 套路。把资料库喂进上下文不现实因为窗口有限所以要先把用户问题转成向量检索把相关片段拉回上下文再让 Agent 基于这些片段推理。注意一个细节增强型架构每次循环都会叠加新的工具返回结果上下文会越来越长这时候不要无脑把历史全部放入而是做一个抽象每轮循环结束后先把“旧的工具结果”压缩成一句摘要再拼接新信息这样能有效控制 Token 增长。2.3 实操要点三个关键参数别用默认值增强型架构落地你一定会碰到几个控制不住爆炸的参数这里必须手动调参数作用建议最大迭代次数限制循环次数的上限内容生成类任务 3~5 次操作类任务 5~8 次单轮并行工具数每轮循环同时调用的工具数量涉及多个独立查询时可设 3~5 个否则设 1结果结构化阈值模型判断任务已达成的置信度标准先设 0.8再按实际准确率微调最大迭代次数是最容易踩坑的地方。设太小复杂任务做到一半被截断输出看起来像“半成品”设太大遇到一个会钻牛角尖的任务它会反复自我纠正一次任务烧掉几十万 Token。我习惯的做法是每次迭代结束时让模型输出一个“当前完成度百分比”如果在连续两轮里完成度没有提升就直接强制终止。2.4 增强型架构的适用场景和性能取舍它最典型的场景是“开放探索型任务”比如给你一份行业数据文档让你发现三个潜在风险点。这类任务没有标准答案需要 Agent 自己去文档里找线索、交叉验证、生成结论增强型天然合适。性能取舍很明确它是三套架构里单次任务成本最高的。因为每次循环都要重新发送一次完整上下文Token 消耗是累加的。一个实测数据同样的任务增强型比链式平均多消耗 40%~60% Token但它的优势是能处理非预期情况不需要你提前把所有路径都写进流程里。所以如果你预算有限、又要做高并发别让所有流量都走增强型给一部分简单任务加路由判断走更经济的分支。3. 链式架构用编排代替自治3.1 流水线的本质上一环节的输出就是下一环节的输入链式架构的核心思想是确定性和可预测性。它把一个大任务切成一串小步骤每一步单独执行上一步的输出是下一步的输入。整条链没有一个“总指挥”在动态决定下一步干什么链怎么走是写死的。举个例子做一个自动周报生成器。你可以拆成四段收集本周提交记录、调用模型生成初稿、调用规则引擎校验格式、最终输出到文档。每一步的输出都有明确 schema。如果第二步生成的内容格式不对第三步能立刻拒绝而不是像增强型那样让模型“自己想办法改”。它解决的核心问题是增强型架构里的“失控感”。当你需要稳定输出、快速响应、成本可控时链式是底线方案。3.2 节点设计解析、校验、结构化状态链式架构的节点不是“让模型做一件事”这么简单每个节点至少要包含三部分输入解析、处理器、输出校验。我用一个实际工作流的 JSON Schema 来说明结构化状态包{ step: summarize, input: { source_text: 待处理文本, config: { max_length: 800, language: zh } }, output: { summary: 摘要内容, key_points: [要点1, 要点2] }, metadata: { step_id: uuid-xxx, status: succeeded, duration_ms: 3200 } }每个节点处理完都必须把这一包状态继续往下传而不只是把纯文本往下传。这一步很多人觉得多余实际上它是全链路可追溯的基础。哪一步慢了、哪一步返回异常、哪个环节内容格式不对一眼就能定位。校验环节特别重要。模型输出是天然不可靠的你在每个节点后面都要接一个校验器校验字段是否存在、类型是否正确、是否命中业务规则。比如“生成邮件正文”这个节点规则可能是“必须包含称呼、正文、落款”。模型经常漏掉落款校验器发现后可以触发一次重试而不是让错误流到下一环节。3.3 状态传递、超时与失败重试链式架构最容易出问题的是状态传递。模型输出会变但流程定义不能变。所以每个节点之间的数据传递要定义好映射关系上一节点输出的 summary 字段下一节点要用的时候必须显式引用比如{summary}这种占位符。不要在状态包之外传隐式数据否则一旦模型输出改变字段名下一节点直接拿不到值。超时和重试也要在编排层管。LLM 调用会有偶发高延迟如果单个节点耗时超过 20 秒大多数用户的耐心就没了。我的做法是给节点设三档超时快速超时 5 秒、正常超时 30 秒、长任务超时 90 秒。重试策略一般不超过两次第一次重试可退避 1 秒第二次退避 3 秒。超过两次还失败把状态包标记为失败并进入降级分支而不是继续死等。失败重试还有一个经验只重试失败的节点不要重跑整条链。很多框架自动帮你重跑整条流程看起来很省事但你算算成本一次上游节点会重复消耗大量 Token。比较稳的方法是记录每个节点的输出快照失败时只让失败节点重新入队。3.4 什么时候必须上链式而不是增强型有这么几类情况我的判断标准基本不会动摇流程有严格要求比如客服工单流程、审批流顺序错了就是事故。中间节点需要人工确认。比如“先生成方案等人确认后再继续执行”链式天然支持在中间暂停。多步骤之间有明确的输入输出契约且每个步骤都要求可审计。任务可以预判全部路径不存在需要模型动态跳出流程的情况。如果你是做企业内部工具宁可用链式把流程写死也别相信一个 Agent 能自己按规矩走完全程。在企业场景里确定性比聪明值钱得多。4. 路由式架构让“判断”先于“执行”4.1 路由节点到底在做什么路由式架构的核心是“入口分流”。它只做一件事判断请求应该去哪个处理分支。你可以把它理解成快递分拣中心包裹来了先看地址再决定送哪条运输线。放在 Agent 系统里路由节点不负责解决问题只负责回答问题这个请求是分类、翻译、数据分析、还是闲聊它判定一次然后把请求连同路由结果一起交给对应的子流程。路由节点通常放在系统最前面是全系统的第一个拦截点。它的价值在于把“选择权”从下游的业务 Agent 身上剥离。下游不需要在每次处理时都做一次“我要不要自己处理”的判断架构边界变得干净。4.2 三种路由实现方式规则、LLM 与向量路由节点有三种常见实现我用表格列出来对比路由类型原理优点缺点使用场景规则路由用关键词、正则、业务规则匹配零模型成本、100%可控泛化差无法处理措辞变化固定选项、内部系统LLM 路由让模型判断意图并输出 JSON 结果泛化强、能处理复杂语意有成本、有延迟、可能误判用户输入多变的外部场景向量路由把请求转为向量和各类别模板计算相似度速度快、适合大规模多类目需要向量库、类目语义要有区分度垂直分类、多知识库选择三种路由我实际都用过各有各的坑。规则路由最稳但对用户表达太敏感比如你判断“推荐产品”这个意图用户说“给我搞一个”就匹配不上。LLM 路由泛化好但它本身也是一个消耗模型调用的环节如果每次都让模型判断一千万次请求就要调一千万次模型。向量路由速度最快但前提是你得把所有类目先向量化而且类目之间如果太相似比如“退款咨询”和“退货咨询”向量距离太近容易分错。一个稳妥的实践方案是三层叠加先用规则把高频、硬性意图拦截掉剩下的模糊请求再交 LLM 判断判断不上来的再落到向量兜底分类。4.3 路由加子 Agent 的组合模式路由式架构真正发挥威力是在“路由加子 Agent”的组合里。入口路由器分完类之后每个类目各自运行一套独立处理流程。这些流程可以是链式也可以是增强型互不干扰。这样的好处是模块化。你想改进“数据分析”这一类目的处理质量只需要改数据分析那条分支不用动其他分支。每个子 Agent 只关注自己的领域上下文更短Prompt 更聚焦效果比一个万能 Agent 要好很多。落地上要注意一个问题子 Agent 之间不要共享同一份上下文。有些团队把路由结果和所有子 Agent 的历史都塞进一个大状态库结果子 Agent 看到别的类目的信息产生认知混乱。正确的做法是各分支状态隔离公共场所只放“路由结果、用户原始请求、必要的全局业务参数”。4.4 误路由怎么兜底路由式架构的硬伤是“判断错”。一旦入口把“退款问题”分到了“产品咨询”后面的流程再强方向也已经错了。所以必须设计兜底机制。我的兜底方案有两层。第一层路由节点输出的时候同时输出置信度标签低于某个阈值就进入默认兜底分支由客服型 Agent 接管。第二层在子流程末尾增加一个“路由正确性自检”节点让子 Agent 看一眼输入和输出判断是否明显不对明显不对就直接回退到路由层重新分发。重分发最多一次避免死循环。在监控上特别要注意“误路由率”这个指标。你需要在系统里打日志记录每次路由的判定理由和后续处理结果。如果发现某一类请求的误路由率超过 15%不是加 Prompt 的事而是要考虑该类目是否需要拆分成两个下级路由或者把该类目改成规则拦截。5. 混合落地实践链式加路由加增强型的协同方案5.1 一个通用套餐入口路由加工序链加末端增强实际生产环境里几乎不会只用一种架构。我经手过的、能支撑较高并发的 Agent 系统基本都长这样入口请求 - 路由判断 - 链式工序 - 关键节点增强 - 输出校验入口先用路由把不同类型的任务分开每个分支内部用链式把固定步骤管住链式里遇到真正需要模型自由发挥的环节比如创意生成、开放解读局部用增强型循环。这样既保证了大部分流程的确定性又把模型的最强能力用在了刀刃上。这个混合结构最大的优势是隔离风险。流程固定大部分流量走低成本快速路径只有少数复杂请求才触发额外循环预算可控。成本、延迟、准确率三者之间你有了调节空间。5.2 状态管理与可观测性设计混合架构跑起来以后最头痛的是全链路追踪。增强型循环内部迭代多次链式节点之间状态流转路由分支又各不相同没有统一的状态管理排查问题全靠猜。我给一个比较标准的做法从请求进系统的那一刻生成一个全局 trace_id路由判断结果、每一步节点输出、每个模型调用的模型名、参数、耗时、Token 消耗、失败重试次数全部以 trace_id 为主键打到日志系统里。人工排查的时候输入 trace_id能看到一次请求的完整生命周期。成千上万条的日志会埋掉关键信息所以至少要打三个事件标记ROUTE_DECISION、STEP_START、STEP_SUCCESS。如果某一条链走到中途失败你要能通过三个标记快速定位是路由分错、链步骤卡死、还是模型调用报错。5.3 评测与灰度怎么判断架构合格架构改完你怎么知道它合格不要只看几个手工用例而是要做三组评测集。第一组是“标准路径测试集”。每个场景准备 20 条左右的标准输入覆盖普通、边界、异常三类跑一遍看成功率。第二组是“鲁棒性测试集”故意输入带错别字、口语化、语义含糊的请求看路由是否扛得住。第三组是“成本跟踪集”记录同一批请求在三种架构下的 Token 消耗和响应时间做横向对比。灰度上线时不要一次全量切流量。先把新架构覆盖 10% 流量对比旧系统的成功率、延迟、成本差连续观察 48 小时再放量到 50%。放量过程中如果某个分支的失败率持续偏高先切回旧架构再定位分支问题。我见过很多团队省略灰度直接切全量结果一个小规约问题把整个线上系统拖崩得不偿失。6. 常见问题与避坑经验6.1 高频翻车清单我把这半年见到的典型问题整理成一个速查表你对照着检查现象根因解决方案Agent 反复调用同一个失败工具缺少“当前完成度”状态反馈每轮循环追加状态摘要记录已完成/失败项链式节点输出字段突然改变模型输出没有强校验节点后接 schema 校验器不合法自动重试一次路由频繁把简单请求分去增强型规则路由层不完善先用规则拦截 80% 高频意图再加 LLM 兜底全链路延迟忽高忽低所有节点共用同一个大模型实例区分快速模型和慢速模型简单节点走小模型日志无法定位失败节点缺少统一 trace_id 和状态包按文中第 5.2 节设计状态管理任务做到一半被强行截断最大迭代次数设太小按任务复杂度区分上限不要全局统一设一个值6.2 成本与延迟的平衡建议最后说说钱和速度。Agent 系统上线以后成本往往不是模型价格算出来的而是“无效率”烧出来的。增强型循环多转几圈链式节点无故重跑整条链路由判断重复调用模型这些都是隐性烧钱点。我做成本优化只盯三个数字单请求平均模型调用次数、单请求平均 Token 消耗、单请求平均延迟。任何一个数字超过同行的合理范围优先查是不是架构设计问题而不是去换更贵或更便宜的模型。比如路由准确率不够导致错误分支返工换再便宜的模型也救不回来。优先降低无用的中断和反复。一次增强型循环的上下文堆积可能让第二轮和第三轮的成本成倍增长如果发现某类任务三轮循环结果变化不大直接在架构层限制它比如改成链式加单次增强。6.3 我的一些实际体会说句实在话三套架构之间不是“高级与低级”的关系而是“确认性与灵活性”的取舍。增强型再高级用在流程固定的高频场景就是灾难链式再死板用在复杂探索型任务就是浪费时间路由再聪明没有兜底就是给自己挖坑。我自己的经验法则是给每一条任务线都画一张“确定性等级表”高确定性的走链式中确定性的走路由加链式低确定性的最后才考虑增强型。这个判断顺序能让你的系统在稳定、成本、智能感之间找到一个平衡点。架构能力不是看你用了多前沿的框架而是看你能不能把每类任务放到合适的轨道上跑。这几年的 Agent 实践给我最大的体会还是那句话好的架构是让正确的请求以合适的成本走上有保障的那条路。
