先别急着调模型、调 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 实践，给我最大的体会还是那句话：好的架构，是让正确的请求以合适的成本，走上有保障的那条路。
