1. 三种 Agent 工作流架构到底在解决什么问题1.1 从单次调用到多步协作的必然演进很多人第一次接触 Agent 这个概念脑子里浮现的画面是“给大模型一个任务它自己想办法搞定”。但真正落地过几个项目之后就会发现单次调用能做的事情极其有限。一个稍微复杂点的需求比如“帮我分析这份销售数据并生成一份带图表的周报”单次调用根本扛不住——模型既要理解数据格式又要做统计计算还要生成可视化代码最后还要组织成文。这就像让一个人同时扮演数据分析师、前端工程师和文案策划不是不可能但出错概率高得离谱。Agent 工作流架构的出现本质上就是把这种“一人分饰多角”的困境拆解成“多人流水线协作”。每个环节由专门的节点负责节点之间通过明确的输入输出契约连接整体形成一个可观测、可调试、可优化的系统。我见过太多团队一开始图省事把所有逻辑塞进一个超长提示词里结果调试的时候完全不知道是哪一步出了问题只能靠反复改提示词碰运气。这种开发体验用“盲人摸象”来形容一点都不夸张。增强型、链式与路由式这三种架构恰好对应了从简单到复杂的三个层次。增强型解决的是“单个节点能力不够”的问题链式解决的是“任务需要多步顺序执行”的问题路由式解决的是“不同输入需要走不同处理路径”的问题。理解这三者的适用边界和组合方式基本上就掌握了 Agent 工作流设计的核心骨架。1.2 三种架构的核心差异与选型逻辑先给一个直观的类比。增强型架构像是给一个员工配了一堆工具和参考资料让他一个人把事情办完链式架构像是把任务拆成几个工位每个工位做完传给下一个路由式架构像是在流水线入口放一个分拣员根据包裹类型决定走哪条线。增强型架构的关键特征是“单节点能力扩展”。它不改变工作流的基本形态而是在单个 Agent 节点上叠加外部能力——比如接入知识库检索、调用计算工具、挂载代码执行环境。这种架构适合任务边界清晰、但需要外部信息或精确计算的场景。举个例子一个客服问答 Agent用户问“我的订单什么时候到”Agent 需要查订单系统、查物流接口然后组织语言回复。这就是典型的增强型核心逻辑还是“理解问题-获取信息-生成回答”只是获取信息这一步被增强了。链式架构的核心在于“顺序依赖”。任务被拆成多个步骤每一步的输出是下一步的输入形成一条有向无环图。这种架构适合流程明确、步骤之间强依赖的场景。比如“合同审查”这个任务可以拆成提取关键条款 → 比对标准模板 → 标记风险点 → 生成审查意见。每一步都必须等上一步完成顺序不能乱。链式架构的挑战在于错误传播——如果第二步提取错了后面全错。所以链式架构里每个节点的输出校验和异常处理特别重要。路由式架构解决的是“分支决策”问题。系统先对输入进行分类或意图识别然后根据结果把请求分发到不同的处理链路。这种架构适合输入类型多样、不同类别需要完全不同处理逻辑的场景。比如一个智能助手用户可能问天气、可能问代码、可能问日程安排这三类问题的处理方式完全不同。路由式架构先判断“用户想干什么”再决定“用什么方式干”。实际项目中这三种架构很少单独使用更多是组合出现。一个完整的 Agent 系统往往是入口做路由分发每条路由内部是链式流程链式流程中的某些节点又做了增强。理解每种架构的独立形态是为了在组合时知道每个部分该用什么模式。1.3 选型时最容易踩的三个坑第一个坑是“过度设计”。有些团队一上来就搞复杂的路由加链式加增强结果发现大部分请求其实走的是同一条路径路由层形同虚设反而增加了维护成本。我的经验是先用最简单的增强型跑通核心流程等到确实出现“不同输入需要不同处理”的需求时再引入路由。第二个坑是“链式节点粒度过细”。有人把链式流程拆成十几个节点每个节点只做一件极小的事情结果节点间的通信开销和状态管理复杂度爆炸。链式架构的节点划分应该以“语义完整性”为标准而不是以“代码行数”为标准。一个节点应该完成一个完整的语义步骤比如“提取所有日期信息”是一个节点“把日期格式从 MM/DD 转成 DD/MM”就不应该单独成节点而应该作为前一个节点的内部逻辑。第三个坑是“忽略路由的兜底路径”。路由式架构最怕的是输入不属于任何已知类别系统直接报错或返回空。好的路由设计必须包含一个默认路径处理那些无法分类的输入——哪怕只是返回“抱歉我暂时无法处理这类请求请换个说法试试”也比直接崩溃强。2. 增强型架构单节点能力扩展的实操细节2.1 增强型架构的典型组成与数据流增强型架构的基本形态是一个“感知-思考-行动”循环。Agent 接收输入后先判断是否需要外部信息或工具如果需要就调用相应能力拿到结果后再生成最终输出。这个循环可以迭代多次直到 Agent 认为任务完成。一个典型的增强型节点包含四个部分意图解析器、能力注册表、执行调度器和结果合成器。意图解析器负责理解当前输入需要什么能力能力注册表维护所有可用工具的元信息名称、描述、参数 schema执行调度器根据解析结果调用对应工具结果合成器把工具返回的原始数据转换成自然语言或结构化输出。数据流是这样的用户输入 → 意图解析 → 匹配能力 → 调用工具 → 获取结果 → 判断是否满足 → 是则合成输出否则回到意图解析继续下一轮。这个循环的上限通常设为 3 到 5 次防止无限循环消耗资源。我实测下来增强型架构的性能瓶颈往往不在模型推理而在工具调用的网络延迟。如果一个任务需要连续调用三个外部接口每个接口平均 500ms那就是 1.5 秒的额外延迟。所以增强型架构里能并行调用的工具一定要并行能缓存的查询结果一定要缓存。2.2 工具注册与参数校验的工程实践工具注册是增强型架构的地基。每个工具需要提供名称唯一标识、功能描述给模型看的自然语言说明、参数定义JSON Schema 格式、调用示例few-shot 示例。这四个要素缺一不可尤其是调用示例——模型对示例的理解能力远强于对抽象描述的理解。参数校验是很多人忽略的环节。模型生成的工具调用参数经常出现类型错误、缺少必填字段、或者值超出合理范围。我的做法是在执行调度器里加一层校验中间件对每个工具调用做三件事检查必填参数是否存在、检查参数类型是否匹配、检查参数值是否在允许范围内。校验不通过时不直接报错而是把校验错误信息返回给模型让它重新生成参数。这个重试机制能解决 80% 以上的参数错误。注意工具描述里一定要写明“什么时候不该用这个工具”。只写“这个工具能做什么”是不够的模型很容易在不合适的场景下调用工具。比如一个“查询天气”的工具描述里应该加上“当用户询问与天气无关的问题时不要调用此工具”。2.3 增强型架构的适用边界与性能考量增强型架构最适合“单轮任务、边界清晰、需要外部信息”的场景。比如基于知识库的问答、需要实时数据的查询、需要精确计算的任务。它的优势是实现简单、调试直观、延迟可控。但它也有明显的边界。当任务需要多步推理且每步依赖前步结果时增强型架构的循环会变得很长每次循环都要重新理解上下文效率低下。当任务需要多个 Agent 协作时增强型架构无法表达 Agent 之间的依赖关系。这时候就需要链式或路由式架构来补位。性能方面增强型架构的延迟主要由三部分组成模型推理时间、工具调用时间、循环次数。优化方向也很明确用更小的模型做意图解析分类任务不需要大模型、并行化无依赖的工具调用、设置合理的循环上限。我见过一个项目因为没设循环上限Agent 在某个边界情况下反复调用同一个工具直接把 API 配额耗尽了。3. 链式架构多步顺序执行的拆解与衔接3.1 链式节点的划分原则与依赖管理链式架构的核心设计决策是“怎么切分节点”。切得太粗单个节点逻辑复杂难以维护切得太细节点间通信成本高。我的经验法则是一个节点应该对应一个可独立验证的语义步骤。什么叫可独立验证就是这个节点的输出你可以单独拿出来判断对错而不需要看后续节点的结果。举个例子“从用户邮件中提取会议时间、参会人、议题”这是一个可独立验证的节点——提取结果对不对一眼就能看出来。“根据提取的信息生成会议邀请”是另一个节点。但“把时间格式从 12 小时制转成 24 小时制”就不应该单独成节点因为它不是一个完整的语义步骤只是数据清洗的一个操作。依赖管理方面链式架构天然是线性依赖但实际项目中经常出现“某个节点需要前面多个节点的输出”的情况。比如“生成会议纪要”这个节点可能需要“原始邮件内容”和“提取的会议信息”两个输入。这时候有两种处理方式一种是把所有中间结果都放在共享上下文里每个节点从上下文里取自己需要的另一种是显式定义每个节点的输入依赖由调度器负责传递。前者实现简单但容易造成上下文膨胀后者更清晰但需要额外的调度逻辑。我倾向于后者因为显式依赖让整个流程更可观测。3.2 节点间数据传递的格式约定与校验链式架构里节点间的数据格式约定是稳定性的关键。我的做法是所有节点间的数据传递都用结构化格式JSON 或类似并且每个节点在输出前做一次 schema 校验。这样做的原因是模型生成的输出格式经常不稳定——有时候多一个字段有时候少一个字段有时候字段类型变了。如果不做校验错误会一路传播到最后一个节点才暴露出来排查成本极高。具体操作上我会为每个节点的输出定义一个 JSON Schema节点执行完后用这个 schema 校验输出。校验不通过时把校验错误和原始输出一起返回给模型让它重新生成。这个重试机制配合清晰的 schema 描述能把格式错误率降到很低。提示schema 描述里不要只写字段名和类型要写清楚每个字段的语义和示例值。比如meeting_time: {type: string, description: 会议开始时间格式为 ISO 8601例如 2024-03-15T14:00:00}。模型对示例的遵循度远高于对抽象类型的遵循度。3.3 链式架构的错误传播与中断处理链式架构最大的风险是错误传播。第二步错了第三步基于错误输入继续执行第四步再基于第三步的错误结果……最后得到一个完全离谱的输出但你根本不知道是哪一步开始错的。解决这个问题有两个层面。第一个层面是节点级校验每个节点执行完后除了 schema 校验还要做业务逻辑校验。比如“提取会议时间”这个节点校验逻辑可以是“时间必须在未来 30 天内”或者“时间必须在工作日”。校验不通过就中断不往下传。第二个层面是全局中断策略。链式流程需要定义清楚某个节点失败时是重试、跳过、还是终止整个流程我的建议是分级处理——格式错误重试最多 2 次业务校验失败终止并返回明确错误信息工具调用超时重试一次后终止。终止时要把当前节点的输入、输出、错误信息都记录下来方便排查。还有一个容易被忽略的点链式流程的中间状态需要持久化。如果流程走到第五步时服务重启了没有持久化的话就得从头再来。对于长流程超过 5 个节点我建议每一步的输入输出都落库支持断点续跑。4. 路由式架构分支决策与动态分发4.1 路由决策的实现方式与准确率优化路由式架构的第一个核心问题是怎么判断输入该走哪条路常见的方式有三种基于规则的关键词匹配、基于模型的意图分类、以及混合方式。基于规则的方式最简单维护一个关键词到路由的映射表。优点是快、可控、零成本缺点是覆盖不全用户换个说法就匹配不上了。基于模型的方式准确率更高但需要标注数据来训练或微调分类模型而且每次路由都要调用模型有延迟成本。混合方式是先用规则做快速匹配匹配不上的再走模型分类。我实测下来混合方式在大多数场景下性价比最高。路由准确率的优化关键在于分类体系的粒度。分类太粗不同意图混在一起后续处理逻辑没法差异化分类太细每个类别的样本太少模型学不好。我的经验是先按“处理逻辑是否相同”来划分大类同一个大类内部如果还有明显差异再用二级路由细分。比如“咨询类”是一个大类下面可以细分“产品咨询”“价格咨询”“售后咨询”但如果这三类的处理逻辑差不多就没必要细分。4.2 多级路由与兜底策略的设计实际项目中单级路由往往不够用。用户输入可能先按“领域”路由技术/生活/娱乐再按“意图”路由查询/操作/闲聊最后按“复杂度”路由简单问答/多步任务。这就是多级路由。多级路由的设计要点是每一级路由的决策依据要明确且互斥。第一级按领域分第二级按意图分第三级按复杂度分——每一级的分类维度不同不会出现“这个输入既属于 A 又属于 B”的模糊情况。如果出现模糊说明分类维度设计有问题需要调整。兜底策略是多级路由的安全网。每一级路由都要有默认路径处理那些无法明确分类的输入。默认路径的处理方式通常是走一个通用的增强型 Agent尝试用最基础的能力回应如果连这个都失败就返回引导性话术让用户换一种方式表达。兜底路径的响应质量不需要很高但必须存在否则系统会在边界情况下直接崩溃。4.3 路由与链式、增强型的组合模式路由式架构很少单独使用它通常是整个系统的入口层。一个典型的组合模式是入口路由 → 链式流程 → 增强型节点。具体来说用户输入先经过路由层判断属于哪类任务。每类任务对应一条链式流程链式流程中的某些节点是增强型节点需要调用外部工具或知识库。这样整个系统既有路由的分发能力又有链式的流程控制还有增强型的单点能力扩展。组合时的关键接口是上下文传递。路由层需要把原始输入和路由决策结果传递给链式层链式层的每个节点需要把中间结果传递给下一个节点增强型节点需要从上下文中获取它需要的参数。这个上下文对象的设计很重要——它应该是一个可扩展的字典结构每个层可以往里写数据也可以从中读数据但读的时候要明确 key 的命名规范避免冲突。我踩过的一个坑是路由层和链式层用了不同的上下文对象导致路由决策结果没法传递给链式层最后只能在路由层把决策结果拼接到原始输入里非常别扭。后来统一了上下文对象的设计所有层共享同一个上下文问题才解决。5. 三种架构的选型对照与组合实战5.1 选型决策表与典型场景匹配架构类型核心能力适用场景不适用场景实现复杂度增强型单节点能力扩展知识库问答、实时查询、精确计算多步强依赖任务、多分支任务低链式多步顺序执行文档处理流水线、多阶段审核、内容生成输入类型多样、需要分支决策中路由式分支决策分发多意图助手、多领域客服、任务调度单一类型输入、流程固定中高选型时先问三个问题任务需要多步吗不同输入需要不同处理吗单步需要外部能力吗如果只需要外部能力选增强型如果需要多步但不需要分支选链式如果需要分支选路由式。如果三个都需要那就是组合架构。5.2 组合架构的落地案例拆解假设要做一个“智能文档处理助手”用户上传文档后系统需要判断文档类型合同/报告/论文然后走不同的处理流程。合同需要提取条款并比对模板报告需要提取数据并生成摘要论文需要提取参考文献并检查格式。这个场景的架构设计是入口路由判断文档类型 → 每类文档对应一条链式流程 → 链式流程中的提取节点是增强型节点调用 OCR 或文档解析工具。路由层的实现先用文件扩展名做一级判断.pdf/.docx/.txt再用文档内容的前 500 字做二级判断用模型分类。链式层的实现合同流程是“提取条款 → 比对模板 → 标记差异 → 生成审查意见”报告流程是“提取数据 → 计算统计量 → 生成摘要”论文流程是“提取参考文献 → 检查格式 → 生成检查报告”。增强型节点的实现提取节点挂载文档解析工具根据文档类型选择不同的解析策略。这个组合架构的关键设计点是路由层的分类结果要传递给链式层链式层根据分类结果选择对应的流程。实现上路由层在上下文里写入document_type字段链式层的调度器根据这个字段加载对应的流程定义。5.3 架构演进路径与重构时机不要一开始就设计复杂的组合架构。我的建议演进路径是第一阶段用增强型跑通核心能力第二阶段在增强型外面包一层链式流程第三阶段在链式流程前面加入路由层。重构的时机判断当你发现“每次加新功能都要改核心流程”时说明需要路由层了当你发现“单个节点的提示词越来越长、越来越难维护”时说明需要链式拆分了当你发现“某些节点需要反复调用外部工具”时说明需要增强型能力了。重构时最需要注意的是保持接口稳定。路由层的输入输出格式、链式层的节点接口、增强型节点的工具注册格式这些接口一旦确定就不要轻易改。接口稳定了内部实现怎么调整都不会影响其他层。6. 常见问题与排查技巧实录6.1 路由误判与链式断链的排查思路路由误判的典型表现是用户问 A 类问题系统走了 B 类流程返回了完全不相关的答案。排查时先看路由层的分类结果确认是分类错了还是分类对了但流程选错了。分类错了就优化分类逻辑加规则、补样本、调阈值分类对了但流程选错了就是路由映射表配错了改配置就行。链式断链的典型表现是流程走到某个节点后没有输出或者输出为空。排查时先看这个节点的输入是否正常——如果输入就是空的说明是上一个节点的问题如果输入正常但输出为空说明是这个节点的执行问题。节点执行问题常见原因有三个提示词里没有明确要求输出格式、模型返回了空内容、工具调用超时但没有正确处理。提示链式流程的每个节点都应该有超时设置和空输出处理。超时后返回明确的错误信息空输出时触发重试或走默认值。不要让空输出静默传递到下一个节点。6.2 上下文膨胀与性能衰减的应对组合架构跑一段时间后常见的问题是上下文越来越长模型推理越来越慢成本越来越高。原因是每个节点都往上下文里写数据但没有人清理。应对策略有三个。第一上下文分层把上下文分成“全局上下文”整个流程共享的少量关键信息和“节点上下文”当前节点需要的临时数据。节点执行完后临时数据可以清理。第二上下文压缩对于长文本内容在写入上下文前先做摘要或提取关键信息不要原文塞进去。第三上下文窗口管理给上下文设一个大小上限超过上限时按优先级淘汰旧数据。我实测下来上下文分层是最有效的。全局上下文通常只有几个字段用户 ID、任务类型、关键参数节点上下文只在当前节点生命周期内存在。这样即使流程很长全局上下文也不会膨胀。6.3 模型输出不稳定的工程化约束手段模型输出不稳定是 Agent 工作流的固有挑战。同一个输入两次运行可能得到不同格式的输出。工程化的约束手段包括结构化输出约束用 JSON Schema 强制输出格式、few-shot 示例在提示词里给 2-3 个输入输出示例、输出后校验用代码校验输出是否符合预期格式、重试机制校验不通过时自动重试。这四种手段的组合使用效果最好。我的标准配置是每个节点都定义输出 schema提示词里包含至少 2 个示例执行后做 schema 校验校验失败重试最多 2 次。这套组合能把格式错误率控制在 1% 以下。还有一个技巧是温度参数调低。对于需要稳定输出的节点比如提取、分类温度设为 0 或 0.1对于需要创造性的节点比如生成文案温度可以设高一些。不同节点用不同温度这个在链式架构里很容易实现因为每个节点是独立调用的。6.4 常见问题速查表问题现象可能原因排查步骤解决方案路由总是走默认路径分类阈值过高或分类器未生效检查分类器输出和阈值配置降低阈值或重新训练分类器链式流程中途卡住某节点超时或死循环查看各节点执行日志和耗时加超时设置和循环上限输出格式频繁错误提示词缺少格式约束检查提示词和 schema 定义加 few-shot 示例和 schema 校验上下文越来越长节点只写不清理检查上下文写入逻辑实施上下文分层和压缩工具调用参数错误工具描述不清晰检查工具描述和参数 schema补充描述和示例加参数校验相同输入结果差异大温度参数过高检查各节点温度设置降低需要稳定输出的节点温度7. 我在实际项目中的几点体会增强型架构的调试成本最低因为它的执行路径是线性的出问题容易定位。链式架构的调试成本中等需要逐节点排查。路由式架构的调试成本最高因为路由决策本身可能出错路由之后的流程也可能出错两个错误叠加时排查难度翻倍。所以我的建议是能用增强型解决的就不要上链式能用链式解决的就不要上路由。架构的复杂度应该由业务需求驱动而不是由技术偏好驱动。另一个体会是日志和可观测性不是可选项是必选项。Agent 工作流的执行过程比传统程序复杂得多没有详细的执行日志排查问题基本靠猜。我的做法是每个节点执行时记录节点名称、输入摘要、输出摘要、执行耗时、是否重试、错误信息。这些日志汇总到一个可查询的地方出问题时按时间线一看就清楚了。最后分享一个小技巧在开发阶段给每个节点加一个“dry run”模式只打印输入输出但不实际调用模型或工具。这样可以快速验证流程连通性和数据格式不用每次都等模型推理。等流程跑通了再关掉 dry run 做真实测试能省不少时间。