过去大半年我一直在跟 Agent 工作流打交道从最早只会写单条 Prompt到后来被真实业务逼着把任务拆成可编排的流程中间踩过的坑能写满一本笔记本。回头看Agent 工作流的架构设计其实没有那么多玄学核心就是在增强型、链式、路由式这三大类里做选择和组合。这篇文章我就把这三类架构的底层逻辑、设计要点、实操配置和踩过的坑一次讲清楚。不管你是刚开始做 LLM 应用的新手还是已经在生产环境维护 Agent 的老手都可以拿它当一份选型参考。1. 为什么 Agent 工作流需要架构设计1.1 单次调用的天花板在哪大语言模型再强本质也是一个无状态函数输入一段文本输出一段文本。做真实业务时它的能力边界会很快暴露出来体现在三个方面。第一上下文窗口有限。一次调用能塞进去的内容是有限的业务数据、历史记录、工具返回结果很快就会把窗口撑爆。我见过不少团队把整段对话历史全部丢给模型结果上下文越长模型越容易迷路反而连基础问题都答不好。第二模型不会主动操作外部系统。它不会自己去查数据库、调接口、发消息所有这些都得靠外部代码帮它完成。也就是说模型本身只是一个大脑没有手和脚。第三多步骤推理不可靠。让模型在一个 Prompt 里完成收集数据、清洗数据、分析数据、生成报告这整个链路看起来可行实际上中间任何一步出了错都很难定位是谁的问题。这种黑盒式调用在生产环境里非常难维护。所以 Agent 工作流架构存在的意义就是把一个庞大且不确定的任务拆成多个小而明确的组件再用清晰的逻辑把它们串起来。单次调用像一个全能选手什么都会一点但每项都不稳定工作流架构则像一家公司每个人只做自己的岗位流程明确了出了问题也知道该找谁。1.2 三类架构的心智模型和适用边界我平时给别人讲这三类架构最常用的是三个类比。增强型架构是给一个专家加装备。专家还是他自己但你给他配了助手、资料库和工具箱他一个人能完成更多事。链式架构是一条流水线。多个节点依次干活每个节点只负责一个环节前一个节点的产出是后一个节点的输入。路由式架构是一个派单中心。任务进来之后先判断它属于哪一类再把它分发给对应的处理单元。这三类架构不是互斥的恰恰相反成熟系统里经常叠加使用。比如一个路由节点把任务派给 A 处理单元A 内部是链式流程链条里的某一环又是一个增强型 Agent。理解清楚每一层解决什么问题搭建的时候才不会糊。架构类型核心解决什么问题主要成本点典型应用场景增强型单个 Agent 能力不足上下文长度、工具调用次数客服问答、资料汇总、代码辅助链式多步骤任务不稳定、难排查每节点独立调用、延迟叠加内容生成流水线、数据处理链路路由式任务类别多、单一方案不匹配路由判断延迟、分类错误代价多业务线客服、企业级助手入口记住一个原则能用简单架构解决就不要上复杂架构。复杂度永远跟着任务需求走不是跟着技术潮流走。2. 增强型架构给单个 Agent 装上手脚和记忆2.1 增强型架构的三个支柱增强型架构说到底是三件事工具调用、记忆管理和知识注入。这三件事组合起来能让一个原本只会说话的模型变得能干活。工具调用是让模型具备行动力。现在主流大模型 API 都提供了 function calling 机制模型在输出文本之外可以输出一个结构化的调用指令外部代码拦截这个指令去执行真实的函数再把结果返回给模型。这一步的本质是把模型的输出从纯文本约束成结构化指令让它可以和外部系统对接。记忆管理解决的是跨轮次的问题。模型本身不保存任何状态每次调用都是全新的。短期记忆靠上下文窗口长期记忆就需要外部存储比如把历史对话做摘要、抽取关键信息存进向量库下次用到时再检索出来。知识注入解决的是模型不懂你的业务的问题。通用模型没有你公司的产品手册、售后政策、内部流程通过检索增强生成把相关资料塞进上下文模型才能给出贴合业务的回答。这三者不是可有可无的插件而是增强型架构缺一不可的支柱。我在项目里经常看到有人只接了工具调用遇到用户问业务细节就答非所问就是因为没有做知识注入。2.2 工具调用的接入是第一个关键动作接入工具调用第一个要设计好的是工具描述。模型靠的是你写在工具里的描述来理解什么时候该调这个工具描述写不清楚模型就不会调或者乱调。我总结的要点是名称要短、描述要具体、参数要有默认值、最好带一个使用示例。举个例子一个查询订单状态的工具描述如果只写查询订单模型很可能在用户问我的快递到哪了时不调用它。但如果写成这样命中率会高很多{ name: query_order_status, description: 根据订单号查询订单当前状态适用于用户询问发货、签收、退款进度等场景。用户提供订单号时优先调用。, parameters: { type: object, properties: { order_id: { type: string, description: 用户提供的订单号通常是一串数字或字母组合 } }, required: [order_id] } }工具调用的执行循环也需要注意。模型先产出调用指令外部代码执行工具把结果回填给模型模型再基于结果继续生成。这个循环要设置最大轮数限制否则模型可能卡在反复调用同一个工具的死循环里出不来。我在生产环境里通常把最大工具调用轮数设为 5超过就直接返回当前结果并提示用户转人工。还有个容易忽视的坑工具返回结果太长。有些接口一次性返回几十上百条数据全部塞进上下文既浪费窗口又干扰模型判断。正确做法是在工具内部先做截断和聚合只返回模型真正需要的信息。比如查询订单状态只需要返回状态字段、更新时间、物流公司不要返回完整 JSON。2.3 记忆与知识注入上下文不等于记忆很多人把上下文窗口和记忆混为一谈这是增强型架构里最大的误解。上下文窗口只是一个临时工作台不是记忆库。你在这个工作台上堆再多的历史记录模型也不会真正记住反而会因为信息过载导致注意力分散。我常用的长期记忆方案是摘要 向量化。对话过程中定期把已有内容做摘要摘要存进列表同时把关键实体、用户偏好抽出来存进向量库。下次对话时先用相似度检索捞出相关的记忆片段拼接到当前上下文里。这样既控制了上下文长度又保留了跨轮次的信息。知识注入的做法类似。把业务文档切块、向量化用户提问后先做检索把 top_k 个相关片段放进上下文。这里有个参数值得注意top_k 不是越大越好。我一开始习惯设 8结果模型经常被不相关内容干扰后来改成 5反而准确率提升了。评分阈值也很关键相似度低于某个阈值时就别再往上下文里塞了宁可让模型说这个问题我需要查一下也不要硬答。增强型架构最适合的场景是任务边界清晰、不需要跨多个专业步骤、用户意图相对单一。一旦任务开始需要先判断再处理或者多个环节协作单靠一个增强型 Agent 就会力不从心这时候就该考虑链式结构了。3. 链式架构把任务拆成可编排的流水线3.1 链式架构的三种基本形态链式架构的思想很朴素一个复杂的任务拆成多个节点每个节点只做一件事。这样做的好处有三个每个节点独立可测、出错范围可控、不同节点可以用不同模型或不同参数来优化成本。实际落地中链式架构主要有三种形态。第一种是顺序链。A 做完给 BB 做完给 C严格先后执行。适合有明确依赖关系的任务比如抽取信息 → 清洗校验 → 分析总结。第二种是条件链。中间节点根据结果决定走哪条分支。比如内容审核环节如果判断内容合规就走正常发布流程不合规则走人工复审流程。这种链比顺序链多了一个判断节点这个判断节点通常也是一个模型调用。第三种是并行链。多个子任务互不依赖可以同时跑最后汇总。比如一份调查报告要同时查三个数据源三个查询节点并行执行最后统一汇总。并行链能显著降低整体延迟代价是资源占用更高需要做好并发控制和结果合并。我在最开始做链式架构时犯过一个典型错误把所有逻辑堆在一个超长 Prompt 里跑美其名曰下一步让模型自己判断。结果就是延迟高、不稳定、出了问题没法排查。后来老老实实拆成链每个节点用独立函数封装虽然代码量大了但整个系统变得可控多了。3.2 上下游衔接的规范和状态管理链式架构设计得好不好很大程度上取决于上下游之间怎么衔接。我见过最普遍的问题就是上游节点输出一段自由文本下游节点拿这段文本再去解析解析失败就得重试重试几次之后整个链路就崩了。我的建议是节点之间的数据传递一律用结构化格式不要传自由文本。每个节点输出一个 JSON 对象既有业务字段也有元数据字段比如置信度、状态码、耗时。这样下游节点可以直接读取字段不需要做脆弱的文本解析。# 链式工作流的简化示例每个节点只做一件事数据用 dict 传递 def step_extract(raw_text: str) - dict: # 调用模型抽取结构化信息返回 {entities: [...], confidence: 0.92} ... def step_clean(data: dict) - dict: # 校验、去重、字段对齐返回 {cleaned: [...], status: ok} ... def step_analyze(data: dict) - str: # 基于清洗后的数据生成分析结论 ... def run_chain(raw_text: str) - dict: extracted step_extract(raw_text) cleaned step_clean(extracted) conclusion step_analyze(cleaned) return { extracted: extracted, cleaned: cleaned, conclusion: conclusion, }状态管理是链式架构的另一大难题。每个节点都可能失败失败之后是重试、跳过还是终止必须有明确规则。我常用的做法是给每个任务生成一个任务 ID记录每个节点的状态码、耗时、输入输出摘要。链路跑完日志里能清晰看到哪一步慢、哪一步失败。另外强烈建议在每个节点入口做输入校验。模型输出不可控即使你要求它输出 JSON它也可能给你来一段 Markdown 或者废话。用解析器把 JSON 稳定解析出来解析失败就设置一个最大重试次数超过就终止链路并标记为需要人工处理。这条经验是从多次线上事故里换来的。3.3 链式架构最容易踩的坑链式架构最大的隐患是错误逐级放大。上游一个小错误经过中间节点加工后到下游可能变成一个完全离谱的结果。比如信息抽取节点把用户名字抽错了后续所有环节都基于错误名字运行最后生成的报告就完全不能用。所以在关键节点之间要设置校验点宁可多花一次模型调用做核验也不要放任错误传导。还有一个很多人忽略的问题链式架构一旦中间结果需要人工介入整个链路应该支持暂停和恢复。我在一个审核类项目里做过这样的设计节点跑完如果置信度低于阈值把中间结果挂起推到人工审核队列人工确认后再触发后续节点。这个设计让整个链路的容错能力提升了一大截。最后提醒一句不是所有任务都适合链式。如果任务本身需要反复修正、来回推理比如写代码、做创意设计强行动拆成固定链会非常别扭。这类任务更适合让 Agent 自主循环链式只适合那些步骤明确、依赖清晰、输入输出格式固定的场景。4. 路由式架构让任务到达最合适的处理器4.1 路由器到底在做什么当系统面临的任务类型变多单一处理方案就很难通吃。这时候需要引入路由式架构。路由器的职责很单纯识别意图、做分类、分发给对应的处理器。它不负责具体业务处理但它的判断质量决定了整个系统的上限。路由器和链式架构里的条件分支容易混淆。条件分支是链路内部基于中间结果做分流而路由是系统入口处基于原始请求做分发。一个典型的场景是客服系统用户发来一条消息可能是查订单、可能是退货、可能是投诉、可能是闲聊。路由器先判断这条消息属于哪一类然后交给对应的处理器。路由器的设计里最重要的一件事是明确分类的边界。类别不是拍脑袋定的而是取决于你有哪些处理器。如果某个类别的任务没有对应的处理器这个类别就不应该出现在路由选项里。我见过一个项目路由器定义了 8 个类别实际只有 4 个处理器剩下 4 个类别落到一个泛泛的兜底逻辑上效果极差。类别数量要和处理器能力匹配宁可少而精不要多而虚。4.2 三类路由方案规则、嵌入和模型判断实现路由器有常见的三条路线各有取舍。规则路由最简单用关键词、正则、判断逻辑做分类。优点是快、便宜、完全可解释缺点是脆弱。用户表达稍微换个说法就命中不了。比如规则里写了退款用户说我想把钱退回来就匹配不到。规则路由适合做前置过滤比如明显是垃圾信息的、明显是转人工的先用规则拦下来。嵌入路由是用向量相似度匹配类别。提前把每个类别的典型表达向量化用户请求也向量化算相似度哪个类别最接近就分到哪。优点是能处理同义表达比纯规则灵活缺点是需要维护每个类别的示例样本新类别要准备足够的种子样本才能分得准。模型路由是把分类任务直接交给大模型。把候选类别、每个类别的说明和示例写进 Prompt让模型判断。优点是灵活、能处理复杂长尾表达缺点是延迟高、有成本而且模型偶尔会莫名其妙分错。路由方案延迟成本维护成本适用场景规则极低极低中前置过滤、高频固定场景嵌入低低中高类别固定、表达多样模型高高低类别复杂、需要理解语义我的实际做法是混合规则打底处理明确硬性的情况模型路由处理长尾嵌入路由在中间做补充。核心原则是优先级要清晰规则优先其次模型最后兜底。4.3 处理器设计与兜底策略路由分发的最终目标是把任务交给对它最友好的处理器。处理器本身既可以是链式架构也可以是增强型 Agent。比如同样一个客服系统退货申请走链式流程收集订单号 → 核验资格 → 生成退货单产品咨询走增强型 Agent带知识库检索投诉则直接转人工工单。这样每个处理器都专注自己的领域效果比一个万能 Agent 好得多。兜底策略是不可省的一环。无论路由器多聪明总会有分类失败或低置信度的情况。我的方案是模型路由返回结果时附带置信度低于阈值就走人工队列同时设置一个无法分类的类别所有低置信度的请求统一落到这里由人工判断后回流到正确处理器。这样的闭环设计能大幅降低错分带来的业务损失。路由评估也需要日常化。不要只看线上成功率要定期抽样看路由的混淆情况哪些类别之间经常互相分错哪些表达总是落进兜底。我习惯每周拉一次路由日志把分错样本拿出来补充进对应类别的示例集里。路由和模型一样是需要持续迭代的。5. 三种架构的选型、组合与演进5.1 选型决策的四个核心问题面对一个真实需求怎么决定用哪种架构我总结了一个四问决策法基本能覆盖大多数场景。第一问任务边界是否清晰如果任务有明确的开始和结束、明确的输入输出格式可以考虑链式。如果任务本身是开放式的比如帮我研究一个课题增强型更合适。第二问是否涉及外部系统操作需要调用工具、访问数据库、触发业务流程的至少要有增强型的能力。第三问任务之间是否有依赖关系步骤之间有明确前后依赖的用链式串联互相独立的可以用并行或路由并发。第四问错误容忍度有多高业务敏感度高、出错代价大的场景一定要拆解到能人工介入的粒度同时保留路由的兜底。把这四个问题过一遍架构草图基本就出来了。我看过太多团队一上来就搞一个巨大的编排框架把简单需求复杂化最后维护成本远超收益。正确的姿势是从最小可用架构开始跑通了再逐步演进。5.2 一个真实项目的演进路径我用一个做过的跨平台数据助手项目来举例它能很好地说明三种架构是怎么叠加演进的。项目第一阶段只有查询数据一个需求单条增强型 Agent 就够用户提问检索知识库调工具查数据生成回答。这个阶段系统结构很简单但核心痛点已经解决。跑了一段时间后需求变多了用户要生成周报、要对比趋势、要做异常提醒。这些任务步骤多、依赖强单 Agent 开始不稳定。于是我把周报生成拆成了链式取数节点 → 汇总节点 → 文案节点 → 排版节点。每步独立测试周报质量明显上升。第二阶段从增强型进化成了增强 链式。再往后用户请求五花八门有人查数据有人写周报有人问业务定义有人要告警设置。所有请求都往同一条链路里塞路由开始变得混乱。这时候引入路由器先判断请求类型数据查询走增强型 Agent周报生成走链式定义类问题走知识库问答告警设置走专门的处理流程。第三阶段的结构就变成了路由 增强 链式的混合体。这个演进过程给我最大的感悟是架构是长出来的不是设计出来的。不要让架构跑在需求前面也不要让需求把架构拖垮。每到一个瓶颈点用最克制的方式增加复杂度系统才能长期健康。5.3 常见问题排查与长期维护技巧最后分享一份我在实战中沉淀的排查速查表遇到典型问题可以先照这个思路查。症状可能原因排查思路Agent 反复调用同一个工具工具描述不清、调用轮数上限设置过高精简工具描述检查返回结果质量调低最大轮数链式结果越到后面越离谱上游错误未校验逐级放大在关键节点加输入校验和置信度阈值加人工审核点路由频繁分错类类别边界模糊、示例样本不够拉取分错日志补充类别示例缩小类别数量上下文经常超限历史信息全量塞入、工具返回过长引入摘要记忆工具返回做字段裁剪某类请求总是落兜底路由类别未覆盖该场景补充对应类别并确保该类别有独立处理器长期维护中日志和追踪是最值钱的基础设施。每个节点必须记录输入摘要、输出摘要、耗时、状态码、置信度否则线上出问题根本没法查。我习惯把一个任务的全链路日志串成一个带 ID 的追踪记录问题定位时间能从小时级降到分钟级。另外一个加分技巧让 Agent 每次输出时附带一个结构化元信息字段比如置信度、需要人工介入、下一步动作。这样节点之间传递的就不只是业务数据还有控制信号。链路可以根据这些信号做更精细的重试、升级和终止决策整个工作流的健壮性会强很多。我个人现在拿到一个 Agent 工作流需求第一步永远是先画一张最简单的调用图入口在哪、出口在哪、必须经过哪些节点、哪些可以并行。画清楚之后再用增强、链式、路由去套基本不会跑偏。这个习惯帮我省掉了大量后期返工的麻烦也推荐你试试。
