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, tools=tools) 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 中抽取工作年限、技术栈、教育背景、跳槽频率等字段。此时模型面对的是干净的结构化输入，抽取准确率会高很多。
• 节点 C：JD 匹配打分。用规则加模型混合打分，学历、技能关键词硬性匹配走规则，项目经验匹配度走模型。
• 节点 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 常见问题速查表

我把日常排障过程中攒出的经验整理成一个表格，可以当作自查清单用：

这个小表对纯新手特别有用。很多人第一次遇到“Agent 乱调工具”时，第一反应是换更强的大模型，但换了之后问题依旧。实际上八成是工具描述和协议设计的问题，跟模型聪明程度关系不大。先用表格里的方向排查，往往能省下大量无意义的模型调试时间。

6.5 一条实操小技巧：分支级并发与超时控制

最后分享一个我在混合架构里常用的优化手段。路由分发之后，如果多个分支可以并行跑，就不要串行等待。比如“简历筛选”和“面试问题生成”两个任务虽然属于不同分支，但业务上经常同时触发，我就把它们放进并发池里跑，等两个结果都回来再统一返回给用户。要注意的是，并发必然带来超时和降级问题。我给每个分支设置了独立的超时时间，一个分支超时不阻塞另一个分支的结果展示，超时分支直接返回“需要人工介入”的提示，而不是让用户一直傻等。

这个优化听起来简单，但实际收益非常明显。用户体感上，同样的任务组合，响应时间几乎压缩了一半。而你要付出的代价，仅仅是多写几行并发控制代码和更细致的日志埋点。

做了这么多 Agent 项目，我最大的体会是：架构设计的本质，不是画出多漂亮的系统图，而是把“不确定性”关进笼子里。增强型把能力扩展的不确定性交给工具约束去管，链式把流程的不确定性交给阶段顺序去管，路由式把任务分发的不确定性交给意图判断去管。你管住的不确定性越多，系统就越接近“可控”，而可控，才是 Agent 能不能真正上线的分水岭。