做 Agent 应用开发团队里聊得最多的话题往往不是模型参数也不是提示词技巧而是工作流架构设计。模型能力已经够强真正决定产品上限的是这些能力在 Agent 之间到底怎么组织、怎么流转、怎么避免互相干扰。增强型、链式、路由式这三种架构基本覆盖了绝大多数业务场景。尤其是最近很多人开始做多 Agent 协作系统之后绕来绕去最后都会回到这三种形态的组合上来。这篇内容我打算把三种架构彻底拆开讲清楚每种架构到底解决什么问题、代码层面怎么落地、踩过哪些坑、选型时看哪些指标。不是堆概念是我在实际项目里反复对比、重构、验证过的东西。1. 三种架构的核心逻辑与适用边界先建立一张整体认知图。很多刚接触 Agent 开发的读者会把架构想得太玄其实它就是回答三个问题谁在干活、活怎么分配、结果怎么汇合。1.1 增强型架构把复杂度压进单一 Agent增强型Enhanced Agent不是多个 Agent 协作而是让一个 Agent 拥有多种能力典型的实现是 ReAct 模式Agent 自己决定“下一步调用哪个工具、需要哪些输入”然后根据工具返回结果继续推理直到任务完成。这个架构最大的特征是决策内聚。所有业务判断都发生在一个上下文里Agent 能看到完整的对话历史、工具返回结果、中间推理过程因此非常擅长处理目标模糊、步骤不固定的任务。比如让 Agent 帮用户规划一次旅行它需要查天气、找酒店、比价格、看评价每一步用户都没指定顺序Agent 自己统筹。但代价也很明显单次调用 token 消耗高、上下文容易被撑爆、复杂任务经常出现“想太多但执行不动”的问题。我见过不少团队让一个 Agent 硬扛所有任务结果上下文里塞了十几轮工具调用记录最后模型开始胡言乱语。1.2 链式架构用固定流程换取确定性链式Chained Agent是把任务拆成若干个固定顺序的步骤每个步骤由一个独立的 Agent 或流程节点处理前一步的输出就是后一步的输入。它回答的是“已知任务路径时如何保证每一步执行质量”的问题。我拿一个内容生产管道举例第一步抓取原始资料第二步清洗去重第三步提炼大纲第四步生成正文第五步审核校对。每个环节一个 Agent职责单一输出格式严格约定任何一步出问题都可以单独回流修复。这种架构最大的优点是确定性流程可控、每步可观测、召回和修正都很容易。缺点就是死板。任务路径一旦变化链路就要重新设计。如果链路里某一步依赖前一步的多种可能输出节点间就需要复杂的分支逻辑这时候链式就变得臃肿了。1.3 路由式架构先分流再让专业 Agent 干专业事路由式Routing Agent是在业务入口设置一个路由器先判断当前请求属于哪类任务再把它分发给下游对应的专用 Agent。它解决的是“任务类型庞杂、单 Agent 无法全覆盖”的问题。这种架构在运营系统里特别常见。用户可能发来售后问题、商品咨询、投诉建议、订单查询任何单一 Agent 都无法对四类问题都保持高质量回复。路由器的职责不复杂但极其关键意图分类要准、分发要快、兜底要好。它本质上把“广度”问题转化为“分类派单”问题让下游 Agent 保持专注。路由式架构的挑战在于路由器本身的误判率。一旦分错整个回答质量都会垮掉所以路由逻辑必须设计兜底机制而且下游 Agent 的设计不能做成完全黑盒。2. 增强型 Agent 的落地细节与上下文管理2.1 工具定义是最关键的设计决策增强型 Agent 里工具就是 Agent 的手脚。工具定义的质量直接决定 Agent 能用多大程度完成任务。我在项目里常用的定义维度有五个工具名称、一句话描述、参数 Schema、返回值格式、错误语义。工具名称和一句话描述要足够直白因为模型是靠这两个信息判断“什么时候用这个工具”。我曾经有一个工具叫process_data描述是“处理数据”模型经常在需要做格式转换时也去调它导致输出混乱。改成normalize_text_to_standard_format并补充参数示例之后调用准确率立刻上来了。工具描述里可以写入调用时机、典型场景示例、参数边界这些都是隐性的提示工程。参数 Schema 要严格控制类型和枚举范围避免模型自由发挥产生非法参数。返回值格式尽量标准化。比如天气查询工具统一返回{ city: 上海, date: 2025-01-15, condition: rain, temperature: 7 }Agent 做后续推理时会省力很多。错误语义也很重要工具超时、无权限、数据为空要返回不同的错误码Agent 才能做出正确的恢复动作。2.2 感知-行动循环与中断恢复增强型 Agent 的核心运行机制是循环观察当前状态决定下一步动作执行工具调用读取结果继续推理。工程实现上不能让它无限循环下去一定要限制最大迭代轮次。我做模拟项目 X 的时候遇到过一个问题Agent 在某个环节反复调用同一个失败工具直到把预算耗尽。后来在循环里加了三道闸门最大调用轮数比如 12 次、单工具失败重试次数2 次、连续相同动作检测发现 Agent 重复调用同一工具超过 3 次就打断要求它换思路。如果 Agent 的调用链比较长比如超过 5 次工具调用就必须考虑中断恢复。最简单的方式是把每一步的工具输入输出都持久化到本地进程崩溃后可以用历史记录重建上下文。这一步看似冗余在真实生产环境里价值极大尤其是配合模型服务不稳定时一次断连不至于从头再来。2.3 记忆管理短期上下文与长期知识的配合增强型 Agent 的记忆分两层短期对话上下文和长期用户偏好/领域知识。短期上下文直接装进模型提示词长期记忆则靠向量检索补充。短期上下文最怕的就是无限增长。我常用的处理方法是按 token 预算动态截断保留“系统指令 最近 N 轮对话 最相关的 K 条历史摘要”。这里有个经验值对话摘要尽量控制在 200~300 字以内太长的摘要本身会挤占上下文空间。长期记忆用向量库存储。这里注意一个关键点不能把检索到的内容全部塞进提示词而是要做一次“相关性重排”只保留与当前任务最相关的 3~5 条记录。如果不做这一步模型容易被无关历史干扰回答会表现得非常“散”。增强型 Agent 的调试难度是所有架构里最高的因为它内部是一个黑盒推理过程。我的建议是从一开始就在每个工具调用的输入输出上打结构化日志并且记录推理过程的思考片段。这样出了问题至少能定位到是工具返回异常还是模型决策出错还是上下文被污染。3. 链式架构的设计方法与可靠性保障3.1 任务边界的划分原则链式架构好不好用九成取决于任务切得对不对。切得太粗每个 Agent 又变成一个复杂系统切得太细链路太长延迟和错误率都会叠加。我总结了一个实用的划分原则每一个节点的输出必须能被下一个节点直接使用且不需要“重新理解”。比如内容生产管道里“去重清洗”节点的输出是干净的文本列表“生成大纲”节点拿到列表就可以直接提炼不需要再做判断。如果某个节点还需要在内部做大量格式猜测说明边界切错了。另一个判断标准是节点间的依赖强弱。强依赖顺序的任务适合串行链式弱依赖任务适合并行节点。比如“资料收集”可以同时抓多个来源但“生成正文”必须等“大纲确认”完成这两类不要混在一条链路里。3.2 中间产物与接口契约链式架构里节点间传递的不是“对话”而是结构化的中间产物。这意味着设计传输格式时就要下功夫。我在实践中倾向于每个节点都定义严格的输入输出 Schema并且用数据模型在代码层面强制校验。这样做有三个直接好处一是节点实现可以完全解耦开发时可以并行推进二是链路中间任一步出错可以精确判断是上游产物问题还是本节点处理能力问题三是可以单独对某个节点做单元测试不需要整条链路跑通。中间产物的落盘也别忽视。链路可能执行到一半某个节点因为模型服务超时失败如果没有持久化的中间产物整个流程要重头再来。我在项目里会把每个节点的输出以 JSON 文件形式保存在临时目录并记录链路 ID这样方便排查和恢复。3.3 容错、重试与降级策略链式链路越长出错的概率越大。错误处理不能等到上线之后再补架构阶段就要规划好。每个节点要设置独立的重试策略。模型调用类节点由于服务偶发超时采用指数退避重试比较有效通常最多重试 3 次间隔策略为 1 秒、2 秒、4 秒。数据处理类节点如果出错一般是逻辑错误重试没有意义应该直接报错进入人工处理队列。如果某个节点连续失败要触发降级策略。我在一个模拟项目中做过这样的设计正文生成节点如果连续两次模型调用失败不会强行重试而是自动降级为“大纲生成 模板拼接”模式用预先编写的模板填充必要信息确保用户至少能拿到一个可用的初稿而不是一个报错提示。链式架构还有一个容易忽略的点就是链路延迟的预算控制。每个模型节点基本都要消耗 3~8 秒如果链路有 5 个模型节点总延迟就可能逼近 30 秒。对用户交互类场景这是不可接受的。要么把部分节点换成非模型处理规则算法代替要么拆成异步任务做离线管道。是提前设计不是上线后补救。4. 路由式架构的分发策略与系统设计4.1 路由器的三种实现思路路由器的实现方案按照从简单到复杂大概有三种。一是硬编码规则路由基于关键词、正则、业务字段判断二是少样本分类提示让模型自己判断请求类型并返回结构化结果三是语义向量匹配把用户输入 Embedding 后与预置意图向量做相似度检索。硬编码规则适合任务边界特别清晰的场景比如检测到“退款”字眼就转到售后 Agent。优点是零成本、零延迟、完全可控缺点是无法处理同义表达。少样本分类是大多数项目的常用选择。让模型输出一个 JSON例如{ intent: after_sale, confidence: 0.92, key_entities: [订单号, 退款] }然后根据 intent 分发。这种方式对模糊表达的容忍度比规则高不少但要注意限制模型的“自由发挥”分类类别必须锁定在预置列表内。语义向量匹配适合意图很多且经常增加新类别的系统。你把每个 Agent 能处理的典型问题预生成一批向量用户进来之后算最相似的那一类。它的好处是扩展新意图只需补充样例向量不需要改代码。缺点是阈值难调相似度阈值设低了会乱分设高了会分不出去。4.2 路由规则与兜底机制路由规则的设计不能只看意图还要考虑业务权重。我在项目里常用“意图 优先级 上下文”三级分发先判断是什么类型的问题再判断这个类型的优先级比如投诉高于普通咨询最后结合用户历史上下文决定是否要带额外的背景信息给下游 Agent。兜底机制是路由器最重要的一环。无论用哪种路由实现都要处理“模型不确定该分给谁”的情况。我的做法是设置一个默认的通用 Agent任何低置信度的请求都进通用 Agent 处理而不是硬塞给一个不匹配的专用 Agent。通用 Agent 的回复目标是“不解决具体问题但要保证用户不流失”比如先给一个基本回应再引导用户选择自助选项或转人工。还要设计的路由反馈闭环。如果下游 Agent 收到一个请求后发现完全不属于自己的领域可以把请求回写给路由器并标记“路由误判”。这些样本会被收集起来用于后面调整路由规则或扩充少样本示例。没有这个闭环路由器的准确率会一直卡在同一个水平上。4.3 路由后的专用 Agent 设计路由式架构的精髓是“让专业 Agent 干专业的事”所以下游 Agent 的设计直接决定最终体验。下游 Agent 不需要像增强型那样拥有海量工具它只需要与自己的职责相关的最精炼能力。每个专用 Agent 要保持独立的上下文系统指令和接口契约。比如售后 Agent 的指令聚焦“如何处理退换货”商品咨询 Agent 的指令聚焦“怎么解读商品参数”。如果两个 Agent 的职责边界有重叠必须明确“什么情况必须拒接并转交”。我在项目里用一句话原则约定与其让一个专家硬撑不如让它说“这个我不擅长”并转手。这比很多团队执着于把所有情况都塞进一个 Agent 要可靠得多。路由后还要补齐用户侧的可观测体验。当路由器把用户从入口转到某个专用 Agent 时用户是感知不到架构切换的但我们内部要在日志里记清楚路由结果和置信度。出现问题至少能知道是哪一级分的锅是路由器判断错了还是专用 Agent 处理错了。5. 架构选型从业务约束倒推方案5.1 五个关键判断维度遇到一个新的 Agent 业务需求我不建议直接拍板架构而是用五个维度条条对照再把结果汇聚成方案。第一个维度是任务确定性。任务路径是否清晰固定越是固定的流程越适合链式。第二个维度是输入多样性。用户请求种类繁多、格式杂乱的必须引入路由。第三个维度是单任务的复杂度。任务内部步骤多且没有固定顺序的需要增强型的自主决策。第四个维度是响应时效。要求秒级响应的场景要尽量避免长链路和过多模型调用。第五个维度是成本约束。token 消耗预算有限时链式和路由式往往比纯增强型更经济。我拿一个招聘简历初筛系统举例。输入简历格式差异极大这是输入多样性高需要先路由到“技术岗”“非技术岗”“管培生”等不同通道每个通道内的筛选步骤比较明确任务确定性中等可以先做关键词硬筛再做 Agent 深筛深筛里需要对候选人的项目经历做开放性评估单任务复杂度局部高所以特定环节允许 Agent 自主调用多个工具。这种场景天然就是路由 链式的组合而中心评估环节带有增强型的影子。5.2 组合架构三者不是互斥的这三种架构不是只能三选一实际生产系统里最常见的是组合形态。典型的组合模式有两种一种是“路由式入口 链式上下游”先解决任务分发的广度再用固定流程保证每个子任务的质量另一种是“链式为主体 增强型局部替代”链路中的某些节点不固定用规则实现而是在局部换成增强型 Agent 来做开放判断。组合架构要特别注意状态传递的边界。路由分发后的专用 Agent 与后续链路节点之间可能传递的是结构化的 JSON 数据也可能是自然语言文本。如果中间夹着一个增强型决策节点它的推理结果要能映射成上游约定的输出格式。我在实际项目中遇到过很多次“前面链路一切正常换成增强型节点后输出格式漂移”的问题解决方式是给增强型节点也加上严格的输出 Schema 校验不满足格式要求就重新生成。架构选型不是一次性决定而是要留出演进空间。新业务刚起步数据少、意图不明确可以先从简单的增强型或规则路由开始随着数据积累、意图固定再往链式或更复杂的路由结构迁移。为了将来好迁移在开始时就要把各模块的接口做干净防止日后重构时牵一发动全身。6. 真实项目的踩坑记录与排查实录6.1 token 消耗失控在增强型架构项目里我最常遇到的坑就是 token 消耗失控。原因通常是工具返回的结果太大Agent 每次决策都要重新读一遍上下文越积越长单轮成本飙升。排查方法是给每个工具调用记录 token 消耗按“调用次数、输入 token、输出 token”分维度统计。定位到是某个工具的返回值过大之后处理办法有几种一是工具侧增加结果精简逻辑本来返回 100 条记录改成只返回 Top 10 加汇总统计二是在工具返回前做摘要先让模型读完事。这些措施上线后单次任务 token 消耗能降 30%~50%效果非常直接。6.2 上下文污染链式架构里出现过一种隐蔽的问题A 节点生成的指令文本传给了 B 节点B 节点不仅没有执行指令反而把指令内容当成“用户输入”分析了一通输出完全跑偏。这就是上下文污染。解决办法有两种思路一是在消息结构中区分“角色来源”每个节点接收到的字段要明确标记“这是上游产物不是本节点要分析的对象”二是给每个节点设定独立的消息模板进入节点前先做字段映射把非本节点关心的字段过滤掉。我在项目里把节点间传递的 Schema 收敛到最小只保留下游真正需要的字段问题就很少再出现了。6.3 路由误判与故障恢复路由式架构最头疼的问题就是路由误判。有一次系统把用户对“商品售后政策”的咨询分到了“商品推荐”Agent推荐 Agent 愣是给用户推荐了三款同类商品。用户反馈非常强烈。事后复盘发现路由器的少样本示例里“售后”相关的样例太少而用户原话里带着商品型号模型被商品信息干扰了。改进方案是扩充售后意图的典型表达同时在路由结果中增加一个字段route_reason记录分类依据方便排查。还有一个机制我没提到的如果路由置信度低于某个阈值比如 0.6就不直接分发而是先反问用户确认意图。这个策略可以把误判率降一个量级。6.4 调试与追踪体系的搭建Agent 系统的调试难度明显高于传统后端系统因为每个节点的输入输出都不是固定枚举值而是不可预测的模型输出。没有追踪体系出了问题基本只能靠猜。我建过一个简单的追踪规范每次请求分配一个全局链路 ID每个节点处理时把输入、输出、模型调用信息、token 消耗、耗时全部按这个 ID 汇入结构化日志。排查问题时先看路由结果对不对再看哪个节点耗时长、哪个节点输出格式异常就能快速定位。另一个实用技巧是给每个模型的输出记录一个“自评置信度”字段让 Agent 在输出时顺便评估自己对这个结果有多大把握低于阈值自动触发重写或人工审核。追踪体系不需要一开始就做得很完整但至少要保证“链路 ID 节点日志 样本存档”这三样东西从第一天就有。上线后再补代价会高出很多。7. 个人实操经验与后续扩展思路我把这三种架构反复实践下来最大的体会是架构没有好与不好只有匹配不匹配。增强型灵活但贵链式确定但死板路由式能扩展但依赖分发准确性。真正优秀的系统往往是找到业务里“确定性最高”的那部分做成链式“开放性最强”的那部分交给增强型入口再放一个路由做分流。这样既保证了体验又把成本和风险控制住。最后分享一个我自己常用的迭代节奏第一个版本不要直接上大而全的架构先选业务里最核心的一条路径用最小的成本实现闭环。跑通之后再根据实际数据和痛点逐步增加路由、扩展链路。我见过太高比例的项目一上来就设计六七个 Agent 的复杂编排结果大部分时间花在协调链路错误上业务本身反而没推进。从小闭环起步逐步演进是 Agent 工作流架构设计里最稳妥的路子。