做 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 工作流架构设计里最稳妥的路子。
做 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 工作流架构设计里最稳妥的路子。