1. 从能跑到跑得稳Agent工作流架构到底在解决什么问题很多人第一次接触Agent开发都是从写一个能对话、能调工具的Demo开始的。一个循环、几个工具函数、一段系统提示词跑起来看着挺像那么回事。但一旦把它放到真实业务里问题就全冒出来了任务稍微复杂一点就开始胡言乱语工具调用顺序完全不受控中间某一步失败了整个流程直接崩掉想加一个新能力就得把提示词改得面目全非。这些问题的根源其实不在模型本身而在工作流架构。模型是发动机架构是底盘和传动系统。发动机再好底盘设计得乱七八糟车照样跑不起来。Agent工作流架构设计要解决的核心问题就三个任务怎么拆、控制权怎么流转、异常怎么兜底。我见过太多项目前期靠一个万能提示词硬撑后期需求一多就变成了一坨谁也不敢动的意大利面。所以这篇文章想聊的不是怎么让Agent跑起来而是怎么让Agent跑得稳、跑得可维护、跑得可扩展。围绕这个目标目前业界比较成熟的三类架构范式是增强型架构、链式架构、路由式架构。它们不是互斥的更多时候是组合使用的。下面我会把这三类架构逐个拆开讲清楚它们各自适合什么场景、内部怎么设计、以及我在实际落地时踩过的坑。这篇文章适合已经写过基础Agent Demo、准备把它工程化的开发者也适合正在做技术选型、纠结到底该用哪种架构的团队参考。如果你还停留在提示词怎么写的阶段建议先补一下工具调用和ReAct范式的基础再来看架构层面的东西会更有感觉。2. 增强型架构给单个Agent装上外挂的正确姿势2.1 增强型架构的本质不是加功能而是加能力边界增强型架构Augmented Architecture这个名字听起来很唬人但它的核心思想非常朴素在单个Agent的基础上通过外部能力增强它的表现而不是靠堆提示词。这里的增强通常包括三类记忆增强、工具增强、知识增强。很多人误以为增强就是多接几个API这是典型的理解偏差。增强的关键在于明确能力边界——Agent自己能干什么、外部能力补什么、两者怎么衔接。举个例子一个客服Agent它自己负责意图理解和话术组织但订单查询、退款操作这些必须走外部工具因为涉及真实数据变更不能让模型自由发挥。我一般会用一个简单的判断标准来决定某个能力要不要做成增强如果这个能力需要访问模型训练数据之外的信息或者需要产生副作用写数据库、发请求就必须做成外部增强而不是塞进提示词里。提示词里塞得越多模型越容易在关键时刻忘记某条规则。2.2 记忆增强短期、长期、工作记忆该怎么分层记忆是增强型架构里最容易被做烂的部分。常见做法是把所有历史对话一股脑塞进上下文结果就是token爆炸、模型注意力涣散。正确的做法是分层短期记忆当前会话的最近N轮对话直接放上下文N一般控制在5到10轮。工作记忆当前任务执行过程中的中间状态比如已经查了订单A还没查订单B用结构化格式JSON存储而不是自然语言。长期记忆跨会话的用户偏好、历史事实存向量库或KV库按需检索注入。这里有个实操细节工作记忆一定要用结构化格式不要用自然语言描述。我试过让模型自己用自然语言记录我刚刚做了什么结果它经常记错或者漏记。改成让它输出固定schema的JSON后稳定性提升非常明显。因为结构化输出本身就是一种约束模型在生成时会被schema框住。提示工作记忆的schema不要设计得太复杂字段控制在5个以内。字段越多模型填错的概率越高。我一般只保留task、status、result、next_step这几个核心字段。2.3 工具增强工具描述写得好Agent少犯错一半工具增强的坑90%出在工具描述上。很多人写工具描述就一句话查询订单信息。模型看到这种描述根本不知道什么时候该调、参数怎么填、返回什么格式。一个合格的工具有三个要素用途说明、参数约束、返回格式。用途说明要写清楚什么场景下用这个工具而不是这个工具是干嘛的。比如不要写查询订单而要写当用户询问订单状态、物流进度、预计送达时间时使用此工具。参数约束要写明类型、是否必填、取值范围。返回格式最好给一个示例。我踩过最深的坑是工具数量超过15个之后模型的选择准确率断崖式下降。后来我的做法是工具超过10个就做分组用路由式架构先分流这个后面会讲或者用工具检索的方式动态注入相关工具。不要指望模型能在30个工具里精准挑出对的那个这不是模型能力问题是架构问题。2.4 知识增强RAG不是万能药检索时机才是关键知识增强基本等同于RAG但很多人把RAG做成了每次对话都检索一遍既慢又容易引入噪声。正确的做法是按需检索先判断当前问题是否需要外部知识需要才检索。判断时机有两种策略一是让模型自己决定在提示词里加一个是否需要检索的判断步骤二是用规则或小模型做前置分类。前者灵活但多一次模型调用后者快但需要维护规则。我一般对延迟敏感的场景用后者对准确性要求高的场景用前者。检索回来的内容也不是越多越好。我实测下来注入3到5个最相关的片段效果最好超过8个反而会让模型抓不住重点。而且片段之间要有明确的分隔标记否则模型会把不同来源的信息混在一起。3. 链式架构把复杂任务拆成流水线的工程化思路3.1 链式架构适合什么任务可分解、步骤有依赖链式架构Chained Architecture的核心是把一个大任务拆成多个有先后依赖的子任务每个子任务由一个Agent或一次模型调用完成前一步的输出是后一步的输入。它适合那种步骤明确、依赖清晰的场景比如文档处理流水线解析→摘要→翻译→格式化、数据分析流程取数→清洗→分析→出报告。链式架构最大的好处是可调试。每一步的输入输出都是明确的哪一步出问题一目了然。相比之下单体Agent出了问题你只能看到最终结果中间过程是个黑盒。我在做需要高可靠性的业务时几乎都会优先考虑链式。但链式也有明显的代价延迟叠加。5步链路就是5次模型调用如果每步2秒总延迟就10秒起步。所以链式架构的设计重点之一就是能合并的步骤尽量合并能并行的步骤尽量并行。3.2 链的两种形态线性链与DAG链最基础的链是线性链A→B→C→D一步接一步。但真实业务里步骤之间往往不是纯线性的。比如生成报告这个任务可能需要先并行地做数据统计和竞品分析两者都完成后再综合成文。这就是DAG有向无环图链。线性链实现简单用顺序调用就行。DAG链需要引入一个简单的调度器管理节点依赖和并行执行。我的建议是如果步骤少于5个且都是线性的别上DAG直接顺序写就行一旦出现并行分支或者条件跳转再引入调度器。过早引入复杂调度是典型的过度设计。下面是一个简化的DAG链调度逻辑用Python伪代码示意# 节点定义每个节点有依赖列表和执行函数 nodes { fetch_data: {deps: [], fn: fetch_data}, clean_data: {deps: [fetch_data], fn: clean_data}, analyze: {deps: [clean_data], fn: analyze}, report: {deps: [analyze], fn: generate_report}, } def run_dag(nodes, inputs): results {} # 按依赖拓扑排序执行无依赖的节点可并行 for name in topological_sort(nodes): deps nodes[name][deps] dep_results {d: results[d] for d in deps} results[name] nodes[name][fn](dep_results, inputs) return results这个骨架很粗糙但核心思想就一句话用依赖关系驱动执行而不是用代码顺序驱动。这样加节点、改依赖都很方便。3.3 链式架构的失败处理每一步都要能重试和回滚链式架构最怕的就是中间某一步失败。如果第3步挂了前面两步的成果全白费用户体验极差。所以链式架构必须设计检查点checkpoint机制每一步完成后把结果持久化失败时从最后一个成功的检查点恢复而不是从头再来。我一般用两种策略组合重试 降级。对于偶发性失败比如网络超时自动重试2到3次对于确定性失败比如输入格式不对走降级路径比如返回一个默认结果或者跳过这一步继续往下走。关键是要在链的设计阶段就明确这一步失败了整个任务还能不能继续。注意重试一定要加退避策略不要立即重试。立即重试在遇到限流时只会雪上加霜。我一般用指数退避第一次等1秒第二次等2秒第三次等4秒。3.4 链式架构的上下文传递别把整个历史往下传链式架构里一个常见的错误是每一步都把完整的历史上下文传给下一步。这样token消耗会随步骤数线性增长到后面几步上下文可能已经几万token了又慢又贵。正确做法是每一步只传递必要的结构化数据。比如第1步解析文档输出一个结构化的{title, sections, metadata}第2步摘要只需要sections第3步翻译只需要摘要结果。每一步的输入输出都应该是精简的、结构化的而不是自然语言的对话历史。我通常会给每一步定义一个明确的输入schema和输出schema用代码做校验。这样既能控制token又能在schema不匹配时快速定位问题。这一步的工程投入在链路变长之后回报非常明显。4. 路由式架构让对的Agent做对的事4.1 路由式架构的核心先分类再分发路由式架构Routing Architecture解决的是多能力场景下的选择问题。当你的系统需要处理多种类型的任务比如客服系统要处理售前咨询、售后问题、技术支持、投诉建议用一个Agent硬扛所有类型效果一定差。路由式架构的思路是先用一个轻量的路由层判断任务类型再分发给对应的专业Agent处理。路由层可以是一个小模型、一套规则、或者一次专门的模型调用。它的职责非常单一输入用户请求输出任务类型标签。不要让它做任何实际的任务处理保持轻量是路由层的关键。我见过有人把路由层做成了一个全能Agent既做分类又做处理结果就是路由不准、处理也不精。路由层就该像公司前台只负责你找哪个部门不负责解决具体问题。4.2 路由策略规则、模型、混合怎么选路由策略有三种主流做法各有适用场景策略实现方式优点缺点适用场景规则路由关键词、正则、意图模板快、可控、零成本覆盖有限、维护累任务类型少且边界清晰模型路由小模型分类或大模型判断灵活、泛化好有延迟和成本任务类型多、表达多样混合路由规则兜底模型主判兼顾速度和覆盖实现稍复杂大多数生产场景我的经验是任务类型少于5种且关键词明确直接用规则超过10种或者用户表达很口语化用模型中间地带用混合。混合路由的具体做法是先用规则快速匹配高置信度的请求匹配不上的再走模型判断。这样大部分请求走快路径只有模糊请求才走慢路径。4.3 路由的置信度处理不确定的时候怎么办路由最怕的不是分错而是分错了还不知道。所以路由层必须输出置信度并且对低置信度的请求有明确的处理策略。我一般设两档阈值高置信度0.8直接分发到对应Agent。中置信度0.5~0.8分发但在Agent的提示词里加上用户意图可能是X请确认。低置信度0.5不分发走澄清流程直接问用户您是想咨询A还是B这个策略看起来简单但能挡掉大量误路由。我实测下来加了置信度处理之后路由错误率能降一半以上。因为很多错误其实来自模型也不确定但硬着头皮选了的情况让它有机会说我不确定反而更准。4.4 路由式架构的扩展多级路由与动态注册当任务类型继续增长单级路由也会扛不住。这时候可以上多级路由第一级分大类售前/售后/技术第二级在每个大类内再分小类。多级路由的好处是每一级的分类空间小准确率高。另一个扩展方向是动态注册让每个专业Agent自己声明我能处理什么类型的任务路由层根据注册信息动态构建路由表。这样新增Agent时不需要改路由层代码只需要新Agent注册自己即可。这个设计在Agent数量多、迭代快的团队里特别有用。不过动态注册也有代价路由表的构建和更新需要额外的管理逻辑而且注册信息的质量直接决定路由质量。我的建议是Agent数量少于10个时老老实实写死路由表超过10个再考虑动态注册。5. 三种架构怎么组合真实项目里的混合打法5.1 组合原则路由做入口链式做流程增强做单点真实项目里这三种架构几乎不会单独使用。一个典型的组合方式是路由式做入口分发链式做任务流程编排增强型做每个节点的能力补强。举个我实际做过的场景一个智能助手要处理查数据、做分析、出报告这类请求。整体架构是这样的路由层判断用户请求属于数据查询分析报告闲聊中的哪一类。链式流程如果是分析报告走取数→清洗→分析→成文的链。增强节点链中的分析节点用增强型架构挂上计算工具和知识库检索。这样每一层各司其职路由层保持轻量链式层保证流程可控增强层保证单点能力足够强。改任何一层都不会影响其他层维护起来清爽很多。5.2 组合时的边界划分什么逻辑放哪一层组合架构最容易出的问题是职责边界模糊。比如判断用户意图这个逻辑到底放路由层还是放链式流程的第一步我的划分原则是跨任务的通用判断放路由层比如这是查询还是分析。任务内的步骤判断放链式层比如数据够不够要不要再取一次。单点的能力调用放增强层比如调计算器算一下。判断标准很简单这个逻辑是选路还是走路。选路放路由走路放链式走路时用的工具放增强。按这个标准划分基本不会乱。5.3 混合架构的调试怎么定位问题出在哪一层混合架构的调试是个技术活。出了问题你得先判断是路由错了、链断了、还是增强节点挂了。我的做法是全链路打点每一层的输入输出都记日志带上trace_id。出问题时按trace_id一拉整条链路一目了然。具体来说我会记录这几个关键点路由层的分类结果和置信度、链式层每一步的输入输出和耗时、增强层每次工具调用的参数和返回。这些日志不需要多漂亮但必须全。我踩过的坑就是前期没打点出了问题只能靠猜排查一个bug能耗半天。提示trace_id一定要从入口就生成并且贯穿整个链路。不要用时间戳当trace_id并发场景下会撞车。用UUID或者雪花ID。5.4 架构演进从单体到混合的渐进路径最后聊聊架构演进。不要一上来就搞混合架构那是给自己找麻烦。合理的演进路径是单体Agent起步先跑通核心场景验证需求真实存在。加增强单体扛不住了先加记忆、工具、知识增强这是成本最低的优化。拆链式单点增强也扛不住了把复杂任务拆成链提升可控性。上路由任务类型多到单个链处理不了再加路由层分发。每一步都是被真实问题逼出来的而不是提前设计出来的。我见过太多团队在需求还没验证的时候就上复杂架构结果架构的维护成本比业务价值还高。架构是长出来的不是设计出来的这句话在Agent领域尤其成立。6. 几个我踩过的坑和对应的解法6.1 坑一把路由层做成全能大脑早期我做路由的时候总想让路由层聪明一点顺便把一些简单任务直接处理了。结果就是路由层越来越重分类越来越不准因为它既要分类又要处理注意力被分散了。后来我把路由层砍到只剩分类准确率立刻上来了。路由层就该是纯粹的任何顺便处理的念头都要掐掉。6.2 坑二链式流程里用自然语言传状态前面提过链式流程里用自然语言传中间状态是个大坑。我早期让模型自己总结上一步做了什么传给下一步结果经常丢信息或者加戏。改成结构化JSON之后不仅稳定了还能用代码做校验出错能立刻发现。能用结构化数据的地方绝不用自然语言这是血泪教训。6.3 坑三增强工具没有做超时和熔断工具增强最怕的就是某个外部工具挂了整个Agent卡死在那里。我遇到过一次第三方接口超时Agent等了30秒才返回用户体验极差。后来我给所有工具调用都加了超时一般3到5秒和熔断连续失败N次就暂时禁用该工具。外部依赖永远不可靠必须假设它会挂。6.4 坑四混合架构没有统一的可观测性混合架构最大的维护成本在排查问题。如果每一层各记各的日志出了问题根本串不起来。我现在的做法是强制统一日志格式所有层都用同一个trace_id日志里必须包含层级标识route/chain/augment。这样排查时按trace_id一搜整条链路清清楚楚。可观测性不是可选项是混合架构的必需品。7. 写在最后的一点个人体会架构这东西没有最好的只有最合适的。增强型、链式、路由式它们不是三个互斥的选项而是三种可以叠加的能力。我自己的经验是先用最简单的架构把需求跑通然后被问题推着往复杂走每一步都解决一个真实痛点。反过来如果一开始就照着最佳实践搭一套复杂架构大概率会在需求变化时发现架构和需求对不上改起来比重写还痛苦。另外一点Agent工作流的稳定性很大程度上不取决于模型多强而取决于边界划得清不清。路由层只管分类链式层只管流程增强层只管单点能力每一层都做自己该做的事不越界。边界清晰了系统自然就稳了。这个道理和写代码时的单一职责原则是一回事只是换了个场景而已。