Agent工作流架构设计：增强型、链式与路由式实践指南

很多刚开始做 Agent 开发的朋友一上来就喜欢把所有能力塞进同一个 Agent 里结果指令互相污染、上下文越拖越长、出错之后根本不知道问题出在哪一环。“Agent 工作流架构设计增强型、链式与路由式架构” 这个方向本质上就是要解决这个问题怎么把一个大而全的 Agent拆成一套可控、可维护、可扩展的工作流。这篇文章我会结合自己做过的项目把这三类架构的适用场景、核心实现思路、以及在实际开发里踩过的坑一次讲清楚。适合已经写过简单 Agent、正准备把项目做正规的开发者也适合团队里负责技术方案选型的朋友。1. 三种架构到底在解决什么问题1.1 为什么单 Agent 会撑不住我最早做的 Agent 项目结构非常单纯一个系统提示词、一堆工具函数、一个循环调模型。表面上看好像“Agent 该有的都有了”工具能调、上下文有记忆、回答也算流畅。但随着需求变多问题集中爆发在四个地方。首先是提示词失控。你想让 Agent 同时处理简历解析、岗位匹配、面试问题生成、候选人评估报告这些任务的说明全部塞进一个 system prompt 里最后光指令就有几千字模型经常抓不住重点甚至出现“回答简历问题的时候突然开始讲面试技巧”这种串台行为。其次是上下文浪费。每轮对话都要把完整工具列表、领域规则、历史记录全部带进模型token 消耗直线上升响应延迟也变高。然后是排错困难。一旦输出不对你根本分不清是模型理解错了、工具返回的数据有问题、还是任务本身太复杂。最后是扩展性差。每加一个新需求你都得重新梳理整个提示词和工具逻辑之前的测试全要回归一遍。单 Agent 的极限不在于模型能力而在于你的系统设计。它的上下文窗口是有限的注意力是有限的你强行让它当“万能角色”它只会变成“样样通、样样松”。工作流架构的意义就是把这个大角色拆成多个小角色每个人只负责一小块再通过设计好的协作方式把它们串起来。1.2 增强型、链式、路由式分别是什么我习惯于用“组织分工”来理解这三种架构。增强型架构Augmented Agent本质是“给同一个 Agent 加外挂”。它主体还是单个 Agent但给它配上工具Tools、记忆Memory、知识库RAG、技能包Skills让它在自己的推理循环里按需调用。你可以把它理解成一个能力很强的个人助理虽然只有一个大脑但手里有计算器、档案柜、联络簿遇到事情自己决定用什么工具。链式架构Chained Workflow本质是“流水线”。任务被拆成固定顺序的多个阶段每个阶段可能是模型调用、规则脚本、或者是外部 API前一阶段的输出作为后一阶段的输入。你不需要让一个 Agent 同时考虑所有事只需要保证每个环节做好自己的事。它更像工厂里的生产线每个工位只负责一个动作动作之间严格串行。路由式架构Routing Workflow本质是“前台调度”。系统入口先判断用户请求属于哪一类任务再分发给对应处理模块。分类这个动作可以是大模型也可以是规则甚至是模型加规则混合。分发之后每个分支内部可以是增强型、链式、也可以是别的架构。这就像一个大楼的前台先问你来办什么事然后告诉你该去哪个窗口而不是让所有窗口都能处理所有业务。之所以要把这三种分开讲是因为我发现很多开发者把它们混为一谈。有人以为只要加了工具调用就算链式了也有人把路由当成链式的进阶版。实际上三种架构解决的问题完全不同增强型解决的是“能力边界”链式解决的是“流程确定性”路由式解决的是“多任务分发”。它们可以组合但不能互相替代。1.3 什么样的业务更适合哪种架构不是所有场景都需要一上来就搭复杂的路由架构。我自己的选型经验看三个问题就够了任务是不是单一类型处理流程是不是固定顺序分支分支之间是否相互独立我整理了一个简单的对照表方便你快速判断自己的项目靠哪边判断信号倾向架构典型场景示例单一任务类型需要调用多个外部工具增强型个人知识问答助理、代码生成助手任务步骤明确先后顺序几乎不变链式文档解析流水线、简历初筛、报告生成用户请求类型多需要不同处理路径路由式客服机器人、多技能工作台、任务分发系统任务固定但每步都可能出错需要人工兜底链式 增强型合同审核、医疗预问诊仅辅助入口不确定分支内部又需要多步骤处理路由 链式 增强型综合型业务助手从这张表也能看出来三种架构不是“哪个高级用哪个”的关系而是“哪个匹配用哪个”。我见过很多团队把客服机器人硬做成全增强型结果一个 Agent 里挂了几十个工具模型频繁选错工具最后稳定性一塌糊涂。后来改成路由式入口先判断银行卡、网络、账单三类问题再分别走独立子链路立刻清爽很多。2. 增强型架构单 Agent 的能力外挂2.1 核心组成工具、记忆与知识注入增强型架构的出发点很简单模型的参数知识是“截止到训练时刻”的也是“通用”的你需要把私有数据、实时数据、外部操作能力给挂上去。具体落地时我主要关注三个模块。第一个是工具层Tool Layer。每一个工具就是一个函数模型在推理过程中根据用户意图生成调用请求系统负责执行并把结果返回给模型。工具层的关键不是“写得出来”而是“让模型正确选得出”。工具数量少的时候随便写一旦超过十几个工具的命名、描述、参数 schema 就必须非常讲究。我见过一个惨痛案例某团队把一个工具命名成get_info描述只写了“获取信息”模型几乎每次都在错误场景调用它结果拿回来的信息跟问题完全不匹配。第二个是记忆层Memory Layer。短期记忆靠对话上下文长期记忆靠外部存储加向量检索。我的经验是不要把历史对话全部塞进上下文里而是按需检索。比如用户第二次问“我上次那份简历你分析到哪了”你应该检索出上一次任务的状态摘要喂给模型而不是把第一次的完整 PDF 内容重新灌进去。第三个是知识注入层RAG / Skill。常见做法是把领域文档拆块、向量化用户提问时先检索再拼进提示词。但这里有一个常被忽略的细节拼进去的知识要先做“相关性裁剪”和“冲突检测”。如果两份文档对同一问题的说法不一致模型会无所适从。我在做一个模拟项目 X 的简历筛选 Agent 时就在知识注入前加了一层规则校验先按 JD 字段映射关系筛掉明显不匹配的文档片段检索效果稳定很多。2.2 一个可落地的增强型实现骨架给你看一个我实际用过的简化模板基于 Python 风格描述核心是工具注册、执行循环和记忆注入三层# tools.py每个工具必须自带清晰描述与参数 schema tools [ { name: parse_resume, description: 解析 PDF/Word 简历文件返回结构化字段, parameters: { file_path: {type: string, required: True} }, function: resume_parser, }, { name: match_jd, description: 将简历结构化结果与岗位 JD 做匹配度打分, parameters: { resume: {type: object, required: True}, jd: {type: object, required: True} }, function: jd_matcher, }, ] # memory.py长短期记忆统一接口 class MemoryStore: def get_relevant(self, query: str) - str: # 向量检索 摘要返回控制上下文长度 pass def remember(self, content: str): pass # agent.py主循环 def run_agent(user_input: str): memory MemoryStore() context memory.get_relevant(user_input) messages [{role: system, content: SYSTEM_PROMPT context}] messages.append({role: user, content: user_input}) for step in range(MAX_STEPS): # 限制循环次数 response call_llm(messages, toolstools) if response.type tool_call: result execute_tool(response.tool_name, response.args) messages.append(tool_result_message) memory.remember(result) # 值得记的才记别全量写 else: return response.content这段代码虽然简单但它体现了我对增强型架构的三个坚持第一工具必须显式声明不能允许模型“自由发挥”调外部函数第二循环必须有上限否则模型会陷入无限调工具的死循环第三记忆要主动管理不是所有中间结果都值得写进长期存储。实测下来加了这三条之后Agent 的可用性会有一个肉眼可见的提升。2.3 增强型的权衡与失控点增强型架构最大的问题是“自由度太高”。模型每轮都可能生成工具调用你给了它 30 个工具它就有 30 种出错方式。我把踩过的坑总结成几条经验。第一控制工具数量。别把什么都挂到 Agent 上。我自己建议单 Agent 的工具不要超过 20 个超过之后就考虑拆分或走路由。工具之间还要避免功能重叠比如不要同时提供search_web和search_news模型很难分清楚边界。第二工具描述要“按需命中”。描述里不要写太多废话要写清楚“什么情况下用这个工具”“输入参数应该长什么样”。你甚至可以做一个反面示例放在描述里“不要用它来查询天气”。这个做法听起来笨实测对模型选择正确率提升非常明显。第三设置护栏。增强型 Agent 一旦挂了可以触达外部系统的工具比如发邮件、改数据库、调用支付接口就必须加确认环节。我在一个内部工具里加了一行简单规则所有“写操作”工具执行前必须先生成一个待确认指令由用户点击确认后才真正执行。代价是交互多了一步换来的是不再担心模型“手滑”改坏数据。第四关注成本。增强型架构的 token 消耗往往比你预期的高因为模型每次决策都要把工具列表塞进请求。你可以在已经判断清楚用户意图后把工具列表裁剪到只保留相关的一部分。这个优化类似索引下推能显著降低延迟和费用。3. 链式架构确定性优先的流水线3.1 链式工作流的本质是“切分与编排”链式架构的核心是把一个复杂任务切分成若干个“阶段节点”节点之间严格串行每个节点接收上一个节点的产物处理后交给下一个节点。这些节点不一定是大模型调用也可以是纯代码函数、规则引擎、外部 API。把不适合模型干的活交给代码把需要语义理解的活留给模型这是链式架构设计的精髓。我拿一个实际做过的“简历筛选工作流”来说。如果让单 Agent 一步做完“读简历 → 和 JD 比对 → 给出排序 → 生成报告”它很容易在中间某一步“想当然”。链式做法是拆成四个节点节点 A简历格式解析。PDF、Word、HTML 统一转成结构化 JSON这个环节不需要模型参与解析失败的直接丢到人工队列。节点 B关键字段抽取。用模型从简历 JSON 中抽取工作年限、技术栈、教育背景、跳槽频率等字段。此时模型面对的是干净的结构化输入抽取准确率会高很多。节点 CJD 匹配打分。用规则加模型混合打分学历、技能关键词硬性匹配走规则项目经验匹配度走模型。节点 D报告生成。只负责把打分结果和理由组织成一份易读的评估报告。这样做最大的好处是每段都可以单独调优和测试。你发现字段抽取不准就单独优化节点 B 的提示词不会影响节点 C 和 D。而在单 Agent 模式下你几乎没法做这种局部优化动一处牵全身。3.2 节点间数据传递的关键设计链式架构能不能跑得顺取决于节点之间传的数据长什么样。很多问题都出在“上一个节点输出了一段自然语言下一个节点只能靠猜”。我的建议是尽可能让节点之间传结构化数据不要传散文。哪怕节点 A 是模型生成的中间结果也要用指令约束它只输出 JSON。比如让字段抽取节点只返回这样一段{ candidate_name: 张三, years_of_experience: 5.5, top_skills: [python, nlp, langchain], education: {degree: 硕士, school: 某高校}, match_score: 82, match_reasons: [技术栈高度匹配, 缺少大模型训练经验] }后面的打分节点只需要按既定 schema 读取字段不需要再让模型“读懂”一段自然语言描述再决定怎么做。这不仅省 token还大幅降低误差传播概率。我还习惯在每个节点后加一层“校验器Validator”。校验器就是纯代码规则检查输出 schema、字段范围、必填项。数据不合法就触发重试重试两次还不行就进入人工队列。链式架构虽然确定性高但也最怕“脏数据”顺着流水线往下传校验器就相当于流水线上的质检工位。3.3 链式架构的代价刚性流程无法应变链式架构不是银弹它的缺点同样明显。最核心的问题是流程一旦定死就失去了应变能力。举一个简单场景。我的筛选工作流节点顺序是“先解析简历再抽取字段再匹配打分最后生成报告”。如果某份简历的 PDF 里图片占了一大半解析节点直接失败了后续节点全停。但实际业务中这个候选人的信息可能已经在过往沟通记录里存了一部分完全可以跳过解析直接走人工补充。链式架构做不到这种跳跃它只会机械地停在失败点。所以链式架构更适合“流程极其稳定、变化很少”的业务。如果你的流程经常因为用户输入不同而走完全不同的路径就别硬拆成链式。这时候应该考虑路由式或者把链式当作路由分发后的子模块。另一个代价是单点误差会被放大。链式每个节点都是在前一个节点结果上做推理前置节点一旦识别错误后面所有节点都会在错误基础上“一本正经地胡说八道”。校验器能挡住 schema 层面的问题但挡不住语义层面的幻觉。比如节点 B 把“在 G 公司的实习经历”抽成了“在 G 公司的工作经验”节点 C 就会凭这个错误字段打分。我处理这个问题的方式是在关键节点上引入“置信度”的概念——模型输出字段时顺便给出置信度低于阈值就标记为待人工复核这样至少不会把错误一路推进到最终报告里。4. 路由式架构统一的入口聪明的分发4.1 入口路由先判断再分流路由式架构的起点是一个“入口判断器”。它接收用户的原始输入判断属于哪一类任务然后选择对应的处理路径。如果你写过 WEB 服务可能对类似的机制很熟——不同请求路径匹配到不同的处理逻辑本质上就是一种路由分发机制。Agent 里的路由也是这个思路只不过判断依据不是 URL 前缀而是语义。入口判断可以用大模型也可以用规则我更推荐“规则优先 模型兜底”的混合策略。规则能直接命中的比如用户输入包含“上传简历”“检查 JD 匹配”这类明确关键词直接走对应分支规则无法确定时再交给一个轻量分类模型做意图识别。这样做的好处是高频且确定的任务不浪费大模型的判断成本低频模糊任务又不至于因为没有兜底而报错。给一个路由判断的最小实现思路intent_routes [ {name: resume_screening, keywords: [筛选简历, 简历匹配, 评估候选人]}, {name: interview_question_gen, keywords: [出面试题, 面试问题]}, {name: report_writer, keywords: [生成评估报告, 写报告]}, ] def route(user_input: str) - str: for intent in intent_routes: for kw in intent[keywords]: if kw in user_input: return intent[name] # 规则没命中才调模型判断 return llm_intent_classify(user_input)入口判断器输出路由指令之后真正的工作由各分支模块完成。这里有个很多人忽略的设计点路由指令不应该只包含一个目标名称还应该附加上下文摘要。比如入口判断出“简历筛选”之后可以同时提取出“候选人姓名”“岗位名称”作为路由注入参数让子 Agent 不用重新理解一遍用户请求。这一步能省掉不少重复的上下文读取。4.2 分支模块的独立性与协作路由式架构中分支模块可以被设计成任意架构——增强型、链式、甚至再套一个子路由。我推荐的做法是把每个分支模块封装成独立的“子应用”有自己独立的提示词、工具集、记忆空间彼此之间只通过路由层交换有限的信息。这样做有两个好处。第一个是隔离性。一个分支挂了不影响其他分支。比如“生成面试问题”分支配置错了用户切到“简历筛选”分支照样能用。第二个是可扩展性。新增一个业务能力不需要改动其他分支只需加一条路由规则和对应的分支模块。实际开发中我会额外注意“分支间工具冲突”的问题。你可能会觉得很荒谬——不同分支怎么可能工具冲突真有。我之前同时上了“简历筛选”和“面试问题生成”两个分支前者有get_candidate_info工具后者也有一个同名工具但返回字段不一样。路由分发后虽然走的模块不同但工具服务层是共享的两个模块调用同名工具时返回结果却对不上。最后我被迫把所有工具改成“分支前缀 动作”的命名方式比如resume_get_candidate、interview_gen_question才彻底解决冲突。这是一个提倡“干净命名”的教训工具命名不仅要给模型看也要考虑工程层面的可维护性。4.3 路由式架构的瓶颈与兜底策略路由式架构的问题也很典型主要在三处。第一入口是单点。如果入口分类器出错后面一切全错。我遇到过用户输入“帮我看看这个候选人匹配度高不高”入口把它分到了“报告写作”结果只生成了报告格式模板完全没做匹配分析。后来我在入口加了一条校验如果分类置信度低于阈值直接把请求同时分发给两个最可能的分支让它们并行跑最后再根据结果质量选一个。虽然浪费了一点算力但兜底效果非常好。第二路由表膨胀。分支越来越多之后入口判断的粒度很难把握。分得太粗每个分支内部逻辑还是复杂分得太细路由表本身就成了维护噩梦。我现在的经验是分三层领域层比如“招聘”还是“销售”、任务层比如“筛选简历”还是“生成题库”、动作层比如“解析文件”还是“打分”。不是每层都需要显式建表但心里要有这个分层概念否则路由规则早晚乱成一团。第三分支间的资源隔离和权限控制。不同分支能访问的数据集不一样路由层必须把权限带下来。比如“简历筛选”分支只能读取简历库和 JD 库不能碰财务数据。我实现的方式是在路由指令里附带一个权限标识每个分支模块在调用外部服务时先校验这个标识。听起来像多余但一旦系统里有了几十个 Agent权限控制缺失会埋很大雷。5. 三种架构的选型框架与组合实践5.1 选型时我会重点评估的五个维度有人问我到底该怎么在三种架构里做选择。我的回答不是看“哪个技术听起来更厉害”而是评估五个维度。第一是确定性需求。如果业务结果是必须可复现的同一个输入同一个输出就要尽量多用链式少给模型自由发挥的空间。第二是维护成本。几个相互独立的链式节点比一个塞满工具的单 Agent 好维护得多路由式则需要在路由规则上投入持续维护。第三是成本与延迟。链式架构每多一个节点就多一轮模型调用延迟是叠加的增强型则更容易出现工具调用多了导致 token 爆炸。第四是错误定位难度。链式有明确阶段容易定位增强型里的错误往往藏在模型“选择工具的决策过程”里难排查。第五是演进速度。业务需求一变再变路由式的扩展性最好但这要求你有一个稳定的入口分类体系。这五个维度没有绝对最优我几乎每个项目都能找到不同侧重。比如做一个内部效率工具时我会优先考虑维护成本和演进速度路由式更合适做面向外部用户的稳定性系统时我宁可牺牲一点灵活性也要保确定性链式会占大头。5.2 案例回顾某模拟项目 X 的架构演进过程我在做某跨平台系统里的“简历筛选 Agent”模块时实际经历了一次从增强型到链式加路由的完整演进。这个案例很能说明选型框架怎么落地。第一阶段我直接做了增强型。想法是让一个 Agent 既会解析简历、又会匹配 JD、还会写报告。上线后发现工具调用错误率接近三成经常出现“匹配打分时引用了一段并不存在的项目经历”。用户反馈也不理想因为报告风格不稳定有时候详细有时候敷衍。这个阶段让我意识到单 Agent 承担复合任务时缺少“阶段约束”模型很难自觉按正确顺序做事。第二阶段我把流程改成链式。解析走代码工具字段抽取走一个专用模型调用匹配打分走规则加模型报告生成为最后一个节点。稳定性明显上来了错误率从三成降到一成以下报告风格也统一了。但也暴露了新问题一旦简历解析节点失败整个流水线就卡住没有任何变通空间。第三阶段我加上了路由入口。因为业务逐渐扩展用户不只是要“筛选简历”还要“生成面试问题”“生成岗位 JD”“评估上轮面试反馈”。我把这些能力做成独立分支入口先判断用户意图再分发。在“筛选简历”分支内部依然保留链式结构。这个混合架构运行最顺畅维护起来也清晰。如果你也在做同类项目我建议你可以先别追求复杂架构。第一版哪怕只有一个分支也要把“入口 → 分支”这个骨架搭好后续加能力只是新增分支的事而不是重构整个系统的事。5.3 混合架构是常态别排斥“不纯粹”现在聊 Agent 架构经常有人把“用了哪种架构”当成技术标签来炫耀仿佛只用一种架构才正统。实际工程里混合架构才是常态。最强的组合在我看来是路由式做入口链式做主干增强型做节点。路线是这样。路由入口负责确定“任务类型”把它分发给对应链路链路按固定顺序执行几个阶段某个阶段内部如果需要复杂决策再放一个挂载工具的增强型 Agent。三层各司其职路由层要“选对路”链式层要“走稳路”增强型节点要“能干细活”。但要提醒一句混合架构对可观测性的要求更高。你必须有手段追踪一个请求经过了哪条路由、走到了哪个链路节点、节点内调用了几次工具。否则一旦出错你就要在路由表、链路日志、工具日志三个维度里来回翻找痛苦不堪。这个问题我会在下一节展开细说。6. 实操中的坑与排查经验6.1 状态与记忆的管理经验链式和路由式架构里最容易被忽视的是“状态管理”。每个分支或者链路节点执行的中间状态比如“简历文件临时路径”“已抽取字段的缓存版本”“上次打分结果”必须有一个统一的上下文传递机制。我踩过的坑是这样的路由入口判断完任务类型之后为了让分支模块能干活把用户原始输入一股脑传下去。分支模块为了拿到自己关心的字段又自己解析了一遍用户输入。结果分支模块解析出来的“岗位名称”和入口判断时用的“岗位名称”不一致导致打分链路跑完才发现用的是旧版本岗位描述。后来我改成所有原始信息在上游先做规范化统一生成一个 context 对象下游只消费 context 里的值不重新解析用户原始输入。还有一个经验是模型容易“过度记忆”。上下文里存在多条历史记录时模型可能会被旧问题带偏。我在链路节点之间传递上下文时只传当前节点需要的最小集合不做全量透传。这个优化既省 token也显著减少了“串台”问题。6.2 工具与节点协议永远别信任模型输出无论是增强型的工具调用还是链式节点的中间输出只要是模型生成的都必须经过校验和清洗这是我做 Agent 开发最深刻的体会之一。具体来说工具侧要校验参数 schema。模型声称要调用match_jd工具但参数里出现了未定义字段或者必填字段缺失系统要能自动拒绝并请求模型重新生成。节点侧要校验输出格式。模型返回的 JSON 里字段值可能是字符串5.5也可能是数字5.5如果你不强制规定类型后续代码很容易在类型转换时炸掉。我甚至会为每个关键节点准备一个“异常输出样例”喂给模型让它知道什么样的情况算违规。比如字段抽取节点我会在提示词里写school字段只填学校名称不要填学历。模型常常会把“某高校硕士”整个塞进 school加上这些样例之后输出质量明显改善但还是不能完全消除所以校验器才是底线。6.3 可观测性设计日志是 Debug 的第一现场做 Agent 开发最大的痛点是“黑盒”。模型为什么这么决策、工具为什么被调用了三次、某一个节点为什么重试了两遍你如果不在设计阶段埋好日志排查问题就像蒙着眼睛找针。我给自己定了一条硬规矩每个工具调用前后、每个链路节点开始结束、每次路由判断结果都必须输出结构化日志。字段至少包括请求 ID、时间戳、阶段名、模型或工具名、输入摘要、输出摘要、耗时、token 数、是否成功。这就是一个简单的链路追踪体系。排查的时候非常有用。有一次路由总是不走预期分支我看了日志才发现入口分类模型每次拿到用户输入后会因为上下文里的历史记录里带着“简历”两个字就误判成简历筛选分支。历史记录的相似度影响了当前判断。知道原因之后我很快做了修正路由入口只传用户当前输入不传历史会话。这是一个典型的靠日志才能发现的隐性 bug。6.4 常见问题速查表我把日常排障过程中攒出的经验整理成一个表格可以当作自查清单用症状可能原因排查方向解决建议模型总是调用错误工具工具描述模糊、工具间功能重叠查看工具调用日志和模型原始返回精简工具数量、强化描述差异链路最终输出质量差前置节点输出含幻字段检查每个节点的输出样例加置信度标记、增加人工复核节点路由判断不稳定上下文历史干扰、分类置信度低查看路由日志和分类分数入口只传当前输入、加并行兜底token 消耗异常高上下文全量透传、循环调用上限过高查看每轮 token 统计裁剪上下文、限制最大工具循环次数工具执行后状态不同步没有统一 context 对象检查上下文传递逻辑上游规范化、下游禁止重新解析分支模块之间互相影响工具命名冲突、共享存储污染查看模块依赖图工具名加前缀、存储按分支隔离重试后结果更差了重试策略盲目重放查看重试时的输入是否变化设置幂等重试失败走人工或降级路径这个小表对纯新手特别有用。很多人第一次遇到“Agent 乱调工具”时第一反应是换更强的大模型但换了之后问题依旧。实际上八成是工具描述和协议设计的问题跟模型聪明程度关系不大。先用表格里的方向排查往往能省下大量无意义的模型调试时间。6.5 一条实操小技巧分支级并发与超时控制最后分享一个我在混合架构里常用的优化手段。路由分发之后如果多个分支可以并行跑就不要串行等待。比如“简历筛选”和“面试问题生成”两个任务虽然属于不同分支但业务上经常同时触发我就把它们放进并发池里跑等两个结果都回来再统一返回给用户。要注意的是并发必然带来超时和降级问题。我给每个分支设置了独立的超时时间一个分支超时不阻塞另一个分支的结果展示超时分支直接返回“需要人工介入”的提示而不是让用户一直傻等。这个优化听起来简单但实际收益非常明显。用户体感上同样的任务组合响应时间几乎压缩了一半。而你要付出的代价仅仅是多写几行并发控制代码和更细致的日志埋点。做了这么多 Agent 项目我最大的体会是架构设计的本质不是画出多漂亮的系统图而是把“不确定性”关进笼子里。增强型把能力扩展的不确定性交给工具约束去管链式把流程的不确定性交给阶段顺序去管路由式把任务分发的不确定性交给意图判断去管。你管住的不确定性越多系统就越接近“可控”而可控才是 Agent 能不能真正上线的分水岭。