Agent 应用做到一定规模最先失控的往往不是模型本身而是流程。模型可以换、提示词可以调但工作流一旦没有清晰的结构就没办法调试、也没办法复盘。这几年我在不同项目里反复折腾 Agent 工作流最后基本都会落到三种架构上增强型架构、链式架构、路由式架构。分别对应“用一个带工具的模型解决开放式问题”“把固定流程拆成顺序步骤”“按意图把请求分发到不同处理器”。这篇文章不聊某一个框架的 API而是聊架构本身怎么设计、怎么选型、怎么落地。如果你正在准备 Agent 项目或者已经跑通 Demo 但不知道下一步怎么组织流程这篇内容应该对你有用。1. 三种Agent工作流架构的核心设计思路1.1 增强型架构由模型主导的开放式循环增强型架构听起来抽象说直白点就是“让大模型拿着工具箱自己干活”。模型收到一个目标后自己决定先调用哪个工具、看什么结果、下一步再做什么直到它认为任务完成。这里是典型的执行过程循环开始 1. 把用户目标和历史消息发给模型 2. 模型返回两种结果之一 - 需要调用工具返回工具名和参数 - 不需要调用工具返回最终答复 3. 如果是调用工具执行对应函数把结果拼进上下文 4. 回到第1步继续循环 5. 达到最大轮次后强制停止输出当前结论这种架构的核心是“模型主导”。它适合开放性问题比如“帮我整理这个文件夹里的所有素材按主题分类并生成一个提纲”因为实现这个目标需要几步无法提前写死。我见过很多团队一开始就把所有任务都塞进增强型架构结果模型来回调用工具、反复绕弯最后 token 烧掉不少答案也没出来。所以在设计阶段第一个要问自己的问题不是“能不能用 Agent”而是“这个任务到底需不需要自主决策”。增强型架构的落地难点不在循环本身而在工具定义和终止条件。工具描述写不清楚模型就会用错参数终止条件设太宽模型就会自己跟自己对话。后面第3部分会展开讲具体实现。1.2 链式架构用确定性流程替代模型决策链式架构是最“老实”的架构。你把一个复杂任务拆成多个步骤每个步骤完成一个具体动作前一步的输出就是后一步的输入。整条链路在运行前就已经确定不需要模型在运行中做路径选择。比如一个典型的内容处理流水线原始文本 - 敏感信息清洗 - 关键内容抽取 - 摘要生成 - 结构化输出每一步都是一个明确的小函数可以是代码也可以是一次提示词调用甚至可以是外部 API。模型只在“摘要生成”这类需要语言能力的节点出现其它节点交给规则和代码处理。链式架构最大的好处是可测试、可观测。哪个步骤出错直接看日志就知道。响应时间、token 成本、稳定性都可控。缺点是死板一旦用户输入超出了预期路径整条链就可能断掉或者输出一个完全不合理的结果。所以链式架构适合“输入差异不大、步骤相对固定”的场景比如定时报表生成、格式转换、内容审核、数据标准化。只要业务规则能提前写清楚就不要让模型去做决策。1.3 路由式架构在入口处做一次关键分流路由式架构解决的问题是“同一个入口多种不同类型的请求”。它不是一条链也不是一个开放循环而是在最前面加了一个分流器根据请求的意图把任务派发给不同的下游处理器。举个例子。一个工单系统会收到“账号无法登录”“我想开发一个新功能”“账单金额不对”三类请求。如果全部走同一条链处理逻辑会越来越臃肿如果全部交给一个增强型 Agent模型需要掌握太多领域知识准确率也不稳。更好的做法是先用路由判断请求类型然后分别进入各自擅长的工作流用户输入 - 路由分类 - 账号类工单走账号处理链 - 功能需求走需求分析 Agent - 账单问题走账单查询链路由式的关键决策发生在“入口那一次”。路由不准下游处理得再好也没意义。它可以单独使用也可以和链式、增强型组合使用。很多人理解路由式的时候容易把它和链式搞混其实两者的区别很简单链式看的是“步骤先后”路由看的是“从哪条路走”。2. 架构选型背后的判断逻辑2.1 控制度与灵活性的权衡三种架构本质上是三种不同的“决策权分配方案”。增强型把决策权完全交给模型链式把决策权收回到开发者的代码里路由式是只保留一个决策点其余部分仍然由开发者控制。从控制度来看链式最高、路由式居中、增强型最低。从灵活性来看则反过来。我常用的一个判断模型是把任务画成一条数轴左端是“输入格式非常固定输出要求非常明确”右端是“输入千奇百怪输出目标模糊”。越靠近左端越适合链式越靠近右端才需要考虑增强型。大多数业务根本不是纯右端场景真正需要模型自由调用工具的任务没那么多。实际项目里最常见的错误是“为了 Agent 而 Agent”。某个流程原本用规则处理得好好的非要把决策交给模型最后稳定性反而下降。判断该不该用增强型可以问一句如果把这个步骤拆成明确的 if-else我能不能写出来如果能写出来那就先用链式写不出来才是增强型发挥作用的地方。2.2 从业务稳定性反推架构选架构不能只看技术还要看业务对稳定性的要求。金融系统的资金流水异常判断、客服系统中的自动回复、内容平台的内容审核这些场景对准确率、延迟、可追溯性要求很高。如果让模型自由发挥出一次错就可能造成业务事故。我接触过的一个项目早期用增强型 Agent 处理所有用户反馈结果模型经常把“投诉”和“咨询”混在一起处理回了一堆不相关的话。后来改成路由式架构先判断反馈类型投诉类走一条高控制链咨询类走另一条链只有确实需要综合分析的长文本才交给增强型 Agent。上线后分发准确率从 70% 左右提升到接近 95%而且每次出问题都能通过日志定位到是路由错了还是下游某一步错了。所以架构选型的逻辑应该是先看业务风险再看任务复杂度最后看需要多少灵活性。不要先定架构再往里塞业务。3. 落地实现增强型、链式、路由式怎么搭3.1 增强型Agent的循环实现与终止条件实现增强型 Agent 时循环本身并不复杂复杂的是让循环“知道什么时候该停”。我通常会在代码里维护一个最大迭代次数比如 10 轮同时监控每轮调用的工具名和参数如果发现模型在重复调用同一个工具、参数几乎一样就强制终止。单纯的“轮数上限”只能兜底不能解决无效循环因为模型每次都会换一个看起来合理的参数但整体没有往前走。另一个容易踩坑的地方是工具返回的格式。很多工具函数返回的是 Python dict转成字符串后格式千奇百怪模型不一定读得懂。建议统一所有工具返回的文本结构操作成功{字段名字段值, 字段名字段值} 操作失败错误码xxx, 原因xxx模型对结构化程度高的文本理解更好。工具报错时不要直接把异常堆栈丢给模型要先把它转成简短的错误说明再作为一轮工具执行结果返回。这样模型才有可能自我纠正。还有一点尽量把“最终回答”和“工具调用”做成两个显式动作而不是让模型用文本表达“我要调用工具”。现在很多模型都支持原生工具调用能力解析起来稳定得多。如果用的是普通文本输出必须对返回内容做严格的 JSON 片段提取否则业务代码很容易被多余的说明文字干扰。3.2 链式工作流的节点设计与校验链式架构的难点在节点边界。每个节点只应该做一件事不要希望一个节点同时完成“抽取、翻译、打标签、生成摘要”。节点粒度过粗问题排查时就要在一个大黑盒里翻来翻去。我习惯给每个节点定义明确的输入输出字段并用 JSON Schema 做校验。比如“敏感信息清洗”节点输入是原始文本输出是清洗后的文本附带一个标记列表。上游输出只要不符合结构直接中断不进入下一个节点。这样可以避免数据污染一路传递下去整个链条最后输出一个看起来完整但实际已经坏掉的结果。链式架构还需要考虑重试和幂等。如果某个节点是一次大模型调用超时后重试可能重复消耗 token如果节点做了写操作重试可能产生重复数据。所以在设计链式节点时我会给每个请求加一个 request_id并让关键节点先做幂等检查同一个 request_id 不重复处理第二次。同样的思路也适用于外部 API 调用。3.3 路由决策的三种实现方式路由式架构的核心是分类器。我见过三类实现方式各有适用场景。第一类是规则路由也就是关键词、正则表达式、枚举匹配。适合意图边界非常清晰、关键词稳定的场景比如“退款”“发票”“登录失败”这样的词。优点是快、零成本、完全可控缺点是表达多样化一点就漏。第二类是语义路由用 embedding 计算用户输入与每条意图的相似度选最大相似度的意图。这种方式不依赖具体关键词能处理说法不同但意思相近的输入。落地时要注意提前准备每个意图的代表性语料语料质量直接决定路由准不准。建议每个意图至少准备 15-20 条真实历史样本不要凭空编造。第三类是模型路由把意图列表和描述一次性交给大模型让模型输出它认为匹配的意图 ID。这种实现最灵活但延迟和成本也最高。一般在规则和语义路由覆盖不住的长尾场景里使用。我在实际项目中经常是三层叠加先用规则做快速匹配匹配不到再走语义路由再不行才交给模型判断。这样大部分请求能在前两层解决模型路由只兜底既控制了成本也保证了分发准确率。4. 组合架构实战一个用户反馈处理系统4.1 确认业务边界与输入输出用一个我实际带过的虚构项目“用户反馈处理系统”来说明三种架构怎么组合。这个系统每天收到大量用户反馈内容有投诉、咨询、功能建议、技术支持请求。早期方案是全部丢给一个增强型 Agent 自动回复结果经常出现“用户说账单不对模型却回复了功能介绍”的情况。重新设计时我先给系统定了三个边界输入用户 ID、反馈文本、时间戳 输出反馈分类、紧急程度、处理建议、自动回复内容不是所有反馈都能自动处理。像“涉及资金退款”“涉及账户封禁”这两类系统只负责生成处理建议不直接执行操作。边界确定后架构才有的放矢。4.2 路由分流与处理链实现系统入口加了一个路由模块先把反馈分成四类账单问题、账号问题、功能建议、其他咨询。这里用三层路由规则负责识别“账单”“扣费”“无法登录”等强关键词语义路由覆盖“我应该付款吗”“登不上去”这类变体兜底模型路由处理更模糊的表述。四个类别分别对应四条处理链。以账单问题为例反馈文本 - 信息抽取订单号、金额、时间- 订单查询 - 账单状态匹配 - 生成处理结果信息抽取节点用一次大模型调用完成后面三个节点全是代码。这样模型只在最需要理解语义的地方出现其余部分靠业务逻辑保证稳定。账号问题则不同因为登录故障的原因很多一条固定链很难覆盖所以走的是增强型 Agent模型根据用户描述决定是否调用账号状态查询工具、日志检索工具多轮判断后给出处理建议。4.3 增强Agent处理复杂回复负责“其他咨询”的增强型 Agent 不是直接生成回复而是先做一步信息补全。它有两个工具一个是语义检索工具用来查历史类似工单的处理方式一个是用户信息查询工具用来确认用户是否在特殊名单中。模型拿到这些信息后再写回复。我发现这步特别能体现增强型架构的价值用户可能提出一个很含糊的问题比如“你们这个服务怎么用”如果直接让模型回答它只能给出一段泛泛而谈的说明。但让它先查一下用户当前的服务版本、历史记录回复就会具体很多比如“你当前用的是简化版要使用某功能需要先升级”。不过增强型 Agent 也不是没有限制。我把它的最大轮次设为 8并规定如果 8 轮后还没有结论统一返回“需要人工介入”的兜底文案。宁可直接转人工也不要让模型硬编一个答案。5. 常见问题与排查技巧实录5.1 增强型循环失控循环失控最常见的症状是模型不停调用同一个工具成功一次后又有新的想法绕来绕去。排查时先看两样东西工具调用的 log 和 token 消耗趋势。如果连续多轮的调用目标高度相似基本可以判断模型在“原地打转”。我处理过的一个案例是模型反复调用“订单查询”工具因为每次查询返回的结果都有一点差异模型觉得还没找到正确答案。后来把工具描述改成“该工具只返回订单主状态不返回流水明细”并在循环里加入“如果连续三轮调用同一工具进入人工兜底”问题立刻缓解。另一个办法是把工具执行结果中的重复信息压缩掉减少噪声对模型的干扰。5.2 路由分发不准路由不准一般集中在两类场景意图定义重叠和训练语料不足。比如“账号问题”和“安全验证”这两个类别在很多输入里天然模糊。我的建议是意图之间不要设计成完全互斥可以把容易混淆的意图合并成一个让下游进一步区分。排查路由问题时不要只看准确率要把错误样本按预测意图分组看。如果某个意图把大量错误请求吸引过来了说明这个意图的描述太宽泛。这时要做的是收紧意图描述增加反例样本而不是简单加分类器层数。5.3 链式节点失败与数据污染链式节点失败时最常见的问题是上游返回了一段带格式错误的文本下游偏偏“宽容”地继续处理最后输出一个表面正常但内容错乱的结果。解决办法只有一个每个节点入口做强校验不合法直接中断。不要担心中断率太高中断是可控的错误输出流到用户那里才是事故。另外我建议链式节点之间传递的数据都使用容器结构不要用对象引用。Python 这类语言里可变对象在链上被多个节点改来改去最后很难定位是哪个节点动了数据。我见过有个项目排查了整整两天最后发现是两个节点共享了一个 list前一个节点向后一个节点偷偷塞字段。复制一份再传能省掉大量时间。5.4 工具调用与格式问题的处理工具调用的格式问题多出现在参数类型和枚举值上。模型返回参数是一个字符串但工具函数要求整数直接执行就会报错。解决方法是让工具定义中的参数类型尽可能严格并在执行前做一次类型转换和字段校验。还有一类问题是大模型返回 JSON 时夹带注释或多余文字。解析之前先提取被 json 包裹的片段再用容错解析库处理。不要拿官方解析器直接去解模型输出它不会按你想的“标准 JSON”输出。6. 架构设计中的几个关键避坑点6.1 不要过早引入Agent我见过不少项目明明只做了个数据查询工具也要包装成 Agent。结果用户问一句模型先决定调用工具、再等待结果、再生成回答链路长了一大截。如果任务核心就是“输入关键词查数据库返回结果”直接写一个查询接口就够了。Agent 的价值是在“需要多步决策”的场景里而不是所有场景里。真正需要增强型架构的往往是这样的任务用户目标难以一次转成工具参数中间需要看多次结果、做多轮推理比如“找出最近一周所有不符合预算规则的订单并按风险排序”。如果任务一句话能说清工具参数也能直接映射那就不要用 Agent。6.2 给每个工作流留一条“人工兜底”再好的架构也有判断不了的时候。在设计阶段就要预留人工介入通道。路由分类置信度过低时转人工增强型循环达到上限时转人工链式节点连续重试失败时转人工。这不是设计保守而是对用户负责。自动系统负责效率人工系统负责安全感。我在用户反馈系统里加了一个规则自动回复的内容如果涉及“赔偿”“封禁”“法律”等高风险词一律进入人工审核队列。效果非常好因为模型生成的内容语法通顺但合规性可能出问题机器很难判断所有边界。把高风险词拦截出来是成本最低的一层风控。6.3 用日志和指标驱动架构演进架构不是定下来就不动的。我习惯给每个工作流记录三类日志路由决策日志、节点执行日志、Agent 循环日志。统计三个核心指标分发准确率、平均处理轮次、节点失败率。分发准确率低优先优化路由平均处理轮次高但成功率低说明这个任务可能用错了架构考虑降级成链式或拆分。这里有个比较容易忽略的点Agent 循环的平均 token 消耗也要统计。我遇到过模型平均 6 轮才能做完一个本来只需要 3 步的任务说明工具描述或上下文组织有问题。只看成功率不看成本长期下来项目会被 token 账单拖垮。最后再分享一个小技巧给每个工作流打一个版本号同时把每次决策链路的核心信息存下来。这样当你改了一版提示词或工具定义后可以快速对比前后两个版本在某类输入上的表现。很多问题不是“跑不通”而是“跑出来的结果变差了”有版本和日志对照排查效率会高很多。