1. 三种 Agent 工作流架构到底在解决什么问题1.1 从单次调用到多步协作的必然演进很多人第一次接触 Agent 这个概念脑子里浮现的就是给大模型一个提示词它返回一段结果。这种单次调用模式在简单任务上确实够用比如翻译一句话、总结一段文本、生成一个函数。但一旦任务变成帮我调研一下某个技术方案的优劣然后写一份对比报告最后生成一个可执行的验证计划单次调用就彻底歇菜了。原因很简单上下文窗口有限、推理链条太长容易跑偏、中间结果无法校验、错误会一路累积到最终输出。Agent 工作流架构就是在这个背景下被逼出来的。它的核心思路是把一个复杂任务拆成多个可管理的步骤每个步骤由一个 Agent 节点负责节点之间通过明确的输入输出契约传递数据。这样做的好处是每一步都可观测、可调试、可替换。你不需要一次性把所有逻辑塞进一个提示词里而是像搭积木一样把能力拼起来。我刚开始做 Agent 相关项目的时候最大的误区就是一个提示词打天下。结果就是提示词越写越长从 500 字膨胀到 3000 字模型开始忽略中间指令输出格式时好时坏。后来改成工作流架构把任务拆成信息提取 → 逻辑推理 → 格式生成三个节点每个节点的提示词控制在 300 字以内稳定性立刻上了一个台阶。这个经验告诉我Agent 工作流的本质不是让模型更聪明而是让工程更可控。1.2 增强型、链式、路由式三种架构的定位差异标题里提到的三种架构其实对应了三种不同的复杂度层级和适用场景。我用一个生活化的类比来解释增强型架构像是给一个员工配了工具箱他还是一个人干活但手边多了锤子、扳手、计算器链式架构像是流水线每个工位只做一件事做完传给下一个工位路由式架构像是前台分诊先判断你是什么问题再把你分配到对应的专科医生那里。这三种架构不是互相替代的关系而是可以嵌套组合的。一个路由式架构的每个分支内部可能是一条链式流程链式流程的某个节点可能是一个增强型 Agent。理解它们的定位差异是设计出靠谱工作流的前提。下面这张表是我自己总结的对比放在项目文档里给团队新人看效果很好架构类型核心特征适用场景典型节点数调试难度增强型单 Agent 外部工具/知识需要实时数据或精确计算1-2低链式多节点顺序执行任务可拆成固定步骤3-8中路由式先分类再分发输入类型多样、处理逻辑不同5-15高选型的时候不要一上来就追求最复杂的架构。我见过不少项目明明一个增强型 Agent 就能搞定的事情非要搭一套路由加链式的组合结果维护成本翻了三倍效果还没提升多少。架构复杂度应该由任务复杂度决定而不是由技术炫技决定。1.3 什么规模的项目该上哪种架构判断标准其实很朴素看你的任务能不能用一句话说清楚处理逻辑。如果能比如根据用户问题查数据库然后回答那就是增强型如果不能需要分情况讨论比如用户可能问订单、退款、物流三类问题每类处理方式不同那就需要路由式如果任务有明确的先后依赖比如先提取关键信息再基于信息做推理最后生成报告那就是链式。从项目规模看我的一般建议是个人项目或 MVP 阶段优先用增强型快速验证核心价值当任务步骤超过 3 步且步骤间有强依赖时升级到链式当输入类型超过 3 种且处理逻辑差异明显时引入路由式。这个演进路径的好处是每一步都有明确的触发条件不会过度设计。还有一个容易被忽略的点工作流的节点数量和数据传输量是成正比的。每增加一个节点就多一次序列化和反序列化的开销多一个可能出错的环节。所以在设计阶段就要问自己这个节点能不能合并到上一个节点里这个中间结果真的需要单独传递吗我踩过的坑是一开始把提取关键词和提取实体拆成两个节点后来发现完全可以一次调用完成合并后延迟降低了 40%。2. 增强型架构让单个 Agent 拥有外挂能力2.1 工具调用的本质与边界增强型架构的核心就一件事给 Agent 挂工具。工具可以是搜索引擎、数据库查询、代码执行器、API 调用、文件读写等等。它的工作原理是Agent 在推理过程中判断这个问题我需要外部信息或外部操作然后生成一个结构化的工具调用请求系统执行后把结果返回给 AgentAgent 继续推理。这里有个关键认知工具调用不是让模型变聪明而是让模型变准确。模型本身的知识是静态的、可能过时的但通过工具它可以获取实时数据、执行精确计算、操作外部系统。比如你问今天某只股票的价格模型直接回答大概率是错的但如果它调用一个行情查询工具结果就是准确的。工具的定义要尽可能原子化。我见过有人把查询用户信息并计算用户等级并生成推荐打包成一个工具这就违背了原子化原则。正确的做法是拆成查询用户信息计算用户等级生成推荐三个工具让 Agent 自己决定调用顺序。这样做的原因是Agent 的推理能力体现在编排上如果你把编排逻辑写死在工具里那 Agent 就退化成了一个普通的函数调用器。2.2 工具描述怎么写才能让 Agent 正确调用工具描述是增强型架构里最容易被低估的环节。很多人写工具描述就像写 API 文档只写参数类型和返回值结果 Agent 要么不调用要么乱调用。工具描述实际上是给 Agent 看的提示词它需要回答三个问题这个工具是干什么的、什么时候该用、参数怎么填。我总结的工具描述模板是这样的第一句用一句话说明工具功能第二句说明适用场景和不适用场景然后列出参数并给出示例值。举个例子一个天气查询工具的描述可以这样写{ name: get_weather, description: 查询指定城市指定日期的天气情况。适用于用户询问天气、温度、是否下雨等问题。不适用于查询历史气候数据或长期气候趋势。, parameters: { city: { type: string, description: 城市名称使用中文如北京、上海 }, date: { type: string, description: 日期格式为YYYY-MM-DD如2024-06-01。不填则默认为今天 } } }注意描述里的不适用于部分这是很多人会漏掉的。明确告诉 Agent 什么情况下不该用这个工具能大幅减少误调用。另外参数描述里给示例值也很重要模型对示例的敏感度远高于对类型说明的敏感度。实操心得工具数量超过 10 个之后Agent 的调用准确率会明显下降。这时候要么做工具分组要么引入路由机制先筛选工具集。我实测下来单次暴露给 Agent 的工具控制在 5-8 个是最佳区间。2.3 记忆机制短期上下文与长期知识库的配合增强型架构的另一个支柱是记忆。没有记忆的 Agent 每次对话都是失忆状态用户体验很差。记忆分两层短期记忆就是当前对话的上下文长期记忆是跨对话的知识沉淀。短期记忆的管理核心是上下文窗口的分配。我的做法是把上下文分成四个区系统提示区固定不变、长期记忆召回区动态填充、近期对话区保留最近 N 轮、当前输入区。当总长度接近窗口上限时优先压缩近期对话区把早期对话做摘要后存入长期记忆。长期记忆的实现方式我试过几种最实用的还是向量数据库加关键词检索的混合方案。纯向量检索在语义相似但关键词不匹配的场景下会漏召回纯关键词检索在语义泛化场景下会漏召回两者结合能覆盖大部分情况。具体做法是先用关键词检索召回一批候选再用向量相似度排序取 Top-K 注入上下文。这里有个参数需要计算召回数量 K 取多少合适。我的经验公式是 K 上下文剩余预算 / 单条记忆平均长度。假设剩余预算是 2000 token单条记忆平均 200 token那 K 就是 10。但实际使用中我会取 5-8留出余量给模型推理。因为召回的记忆越多模型被干扰的概率越大精准召回比大量召回更重要。3. 链式架构把复杂任务拆成可管理的步骤3.1 链式架构的设计原则与节点划分链式架构的核心思想是分而治之。把一个端到端的复杂任务拆成若干个有明确输入输出的节点节点之间顺序执行。每个节点只关心自己的输入和输出不关心上游怎么来的、下游怎么用的。这种解耦带来的好处是每个节点都可以独立测试、独立优化、独立替换。节点划分的原则我总结为三条单一职责、输出可验证、粒度适中。单一职责是指一个节点只做一件事比如提取信息和验证信息应该是两个节点而不是一个节点里既提取又验证。输出可验证是指每个节点的输出应该是结构化的、可以被程序检查的比如 JSON 格式而不是一段自由文本。粒度适中是指节点不能太粗也不能太细太粗了失去拆分的意义太细了增加编排开销。我做过一个文档处理的项目最初的链路是读取文档 → 提取信息 → 生成摘要 → 输出。后来发现提取信息这一步经常出错但错误要到生成摘要才暴露出来。于是我在中间加了一个信息校验节点专门检查提取的信息是否完整、格式是否正确。加了这一个节点之后整体成功率从 72% 提升到了 91%。这个案例说明链式架构的价值不仅在于拆分任务更在于在关键位置插入校验点。3.2 节点间数据传递的格式约定链式架构最容易出问题的地方就是节点间的数据传递。如果上游输出的是自由文本下游解析起来就很痛苦经常出现模型这次输出格式又变了的情况。解决办法是强制所有节点输出结构化数据通常是 JSON。格式约定要包含几个要素字段名、字段类型、是否必填、示例值。我一般会定义一个 schema每个节点输出后先做 schema 校验校验不通过就触发重试或降级。这样做的代价是增加了一次校验开销但收益是下游节点的稳定性大幅提升。# 节点输出 schema 示例 node_output_schema { type: object, required: [status, data, confidence], properties: { status: {type: string, enum: [success, partial, failed]}, data: {type: object}, confidence: {type: number, minimum: 0, maximum: 1}, error_message: {type: string} } }注意 confidence 字段这是很多人会忽略的。让每个节点输出自己的置信度下游节点可以根据置信度决定是否继续、是否重试、是否降级。比如置信度低于 0.6 就触发重试重试两次还不行就走降级分支。这个机制在长链路里特别有用能避免一个节点的低质量输出污染整条链路。3.3 错误传播与重试策略链式架构的致命弱点是错误会沿着链路传播。第一个节点错了后面所有节点都白做。所以错误处理必须设计在架构层面而不是等到出问题了再补。我的做法是在每个节点外面包一层执行器执行器负责三件事超时控制、重试、降级。超时控制是防止某个节点卡死拖垮整条链路一般设置单节点超时时间为预估耗时的 2-3 倍。重试策略要区分错误类型网络类错误可以重试逻辑类错误重试也没用。降级策略是当重试都失败时返回一个兜底结果让链路能继续走下去。重试次数不是越多越好。我实测下来重试 2 次是性价比最高的第 3 次重试的成功率提升已经很小但延迟增加很明显。而且有些错误是提示词导致的重试同样的提示词结果大概率还是一样这时候应该触发提示词改写而不是简单重试。注意事项链式架构里不要做全链路重试也就是从头开始重跑。这样会导致已经成功的节点重复执行浪费资源。正确的做法是记录每个节点的执行状态只重试失败的节点及其下游节点。4. 路由式架构先分类再分发的智能调度4.1 路由决策的实现方式对比路由式架构的第一步是判断输入属于哪一类然后分发到对应的处理分支。路由决策的实现方式主要有三种规则匹配、模型分类、混合方式。规则匹配是用关键词、正则、意图模板来判断优点是快、可控、可解释缺点是泛化能力差遇到没见过的表达就失效。模型分类是让大模型来判断意图优点是泛化能力强缺点是慢、有成本、可能不稳定。混合方式是先用规则做粗筛规则匹配不上的再用模型判断兼顾了速度和泛化。我一般推荐混合方式。具体做法是维护一个规则库覆盖高频的、明确的意图比如包含退款关键词就路由到退款分支。规则匹配不上的输入再走模型分类。这样能覆盖 80% 的常见情况用规则快速处理剩下 20% 的长尾情况用模型兜底。模型分类的提示词设计有个技巧不要让模型输出类别名称而是输出类别编号。因为类别名称可能有多种表达编号是唯一的。同时要求模型输出置信度置信度低于阈值时走默认分支或人工介入。4.2 路由分支的粒度控制路由分支的粒度是个需要仔细权衡的问题。分支太粗每个分支内部逻辑复杂失去了路由的意义分支太细路由判断本身变得复杂而且容易出现没有匹配分支的情况。我的经验是一级路由控制在 3-7 个分支比较合适。超过 7 个分支时考虑做二级路由也就是先分大类再在大类内分小类。比如客服场景一级路由分售前咨询订单问题售后问题三类订单问题下面再分查询修改取消三个子类。分支粒度还要考虑每个分支的处理成本。如果某个分支的处理逻辑特别复杂可以单独拆出来如果几个分支的处理逻辑很相似可以合并。判断标准是如果两个分支的处理逻辑有 70% 以上重合就应该合并。4.3 默认分支与兜底策略路由式架构必须设计默认分支。因为无论你的路由判断多完善总会有输入匹配不上任何分支。默认分支的作用是兜底避免用户输入被吞掉。默认分支的处理方式有几种一是返回通用回复告诉用户我没理解你的问题请换个说法二是转人工把输入转给人工处理三是走通用处理流程用一个通用的 Agent 来处理。选择哪种取决于业务场景。客服场景一般选转人工工具类场景一般选通用处理。兜底策略还要考虑路由判断失败的情况。路由判断本身也可能出错比如模型分类超时、规则库加载失败等。这时候应该有一个降级路由比如直接走默认分支或者走最近最少使用的分支来分散风险。5. 三种架构的组合与选型实战5.1 嵌套组合的常见模式实际项目里三种架构很少单独使用更多是嵌套组合。最常见的组合模式有两种路由套链式、链式套增强。路由套链式是指一级路由分发后每个分支内部是一条链式流程。这种模式适合输入类型多样、每种类型处理步骤固定的场景。比如一个内容审核系统一级路由分文本图片视频三类每类内部是一条提取内容 → 检测违规 → 生成报告的链式流程。链式套增强是指链式流程的某个节点是一个增强型 Agent。这种模式适合大部分步骤是固定流程、但某个步骤需要灵活调用工具的场景。比如一个数据分析流程数据清洗 → 数据分析 → 报告生成三步其中数据分析这一步需要根据数据特征动态选择分析方法和工具就适合用增强型 Agent。组合的时候要注意层级不要超过三层。三层以上的嵌套调试难度会指数级上升而且性能开销也很大。如果发现需要三层以上说明任务拆分可能有问题应该重新审视拆分逻辑。5.2 选型决策树与成本估算选型的时候我会走一遍决策树先问任务能不能用一句话说清楚能就用增强型不能就问任务是否有明确的步骤依赖有就用链式没有就问输入类型是否多样是就用路由式如果都不满足说明任务需要进一步拆解。成本估算主要看三个维度token 消耗、延迟、维护成本。增强型的 token 消耗主要在工具调用和结果处理上延迟取决于工具执行时间维护成本主要是工具描述和记忆管理。链式的 token 消耗是各节点之和延迟是各节点延迟之和维护成本主要是节点间契约和错误处理。路由式的 token 消耗多了路由判断这一层延迟也多了路由判断时间维护成本主要是路由规则和分支管理。我一般会做一个粗略的估算表把三种架构的预期成本列出来再结合业务对延迟和成本的敏感度来选。如果业务对延迟敏感优先选增强型如果对成本敏感优先选链式如果对准确性敏感优先选路由式。5.3 从 MVP 到生产环境的演进路径我的建议是不要一上来就搭完整架构而是从 MVP 开始逐步演进。第一阶段用增强型 Agent 验证核心价值确认任务可行、用户有需求。第二阶段把验证过的流程拆成链式提升稳定性和可观测性。第三阶段引入路由支持更多输入类型和业务场景。每个阶段都要有明确的升级触发条件。比如增强型升级到链式的触发条件是任务步骤超过 3 步且步骤间有强依赖链式升级到路由的触发条件是输入类型超过 3 种且处理逻辑差异明显。有了触发条件就不会因为想试试新架构而过度设计。演进过程中要注意向后兼容。新架构上线时旧架构要保留一段时间作为降级方案。我一般会做灰度发布先切 10% 流量到新架构观察一周没问题再逐步扩大比例。这样即使新架构有问题也能快速回滚。6. 实操中的常见问题与排查技巧6.1 节点输出格式不稳定的排查思路节点输出格式不稳定是最高频的问题。表现是同样的提示词有时候输出 JSON有时候输出带 markdown 代码块的 JSON有时候输出一段解释文字。排查思路是先从提示词入手检查是否明确要求了输出格式、是否给了示例、是否用了结构化输出功能。如果提示词没问题就检查模型版本。不同模型版本对格式要求的遵循程度不一样有些版本对 JSON 输出支持更好。如果模型版本也没问题就检查输入内容。输入内容里如果包含特殊字符、超长文本、多语言混合都可能影响输出格式。我的终极解决方案是在节点执行器里加一层格式修复。先用正则提取 JSON 部分如果提取失败就用模型做一次格式转换如果还失败就触发重试。这层修复能覆盖 95% 以上的格式问题。6.2 链路延迟过高的优化手段链路延迟高通常是因为节点太多、串行执行、或者某个节点特别慢。优化手段对应有三种合并节点、并行执行、优化慢节点。合并节点是把可以合并的节点合并减少序列化开销和调用次数。并行执行是把没有依赖关系的节点改成并行比如提取关键词和提取实体可以并行。优化慢节点是找出耗时最长的节点针对性优化比如换更快的模型、减少输入长度、缓存结果。我一般会先做一次链路 profiling记录每个节点的耗时找出瓶颈节点。80% 的延迟问题都集中在 20% 的节点上优化这几个节点就能大幅改善整体延迟。6.3 路由误判的修正与迭代路由误判是指输入被分到了错误的分支。修正方法是先收集误判案例分析误判原因然后针对性调整。误判原因通常有三类规则覆盖不足、模型判断偏差、边界情况模糊。规则覆盖不足就补充规则模型判断偏差就优化提示词或换模型边界情况模糊就明确定义边界。我一般会维护一个误判案例库每次发现误判就记录进去定期分析并迭代路由逻辑。迭代的时候要注意不要过度拟合。如果为了修正几个案例而大改路由逻辑可能会引入新的误判。我的做法是每次迭代只改一个点改完观察一段时间确认没有引入新问题再改下一个点。6.4 常见问题速查表问题现象可能原因排查方向解决方案节点输出格式不稳定提示词不明确、模型版本问题检查提示词和模型加格式修复层、换模型链路延迟高节点多、串行、慢节点profiling 找瓶颈合并节点、并行、优化慢节点路由误判规则不足、模型偏差分析误判案例补规则、优化提示词工具调用失败描述不清、参数错误检查工具描述和参数优化描述、加参数校验上下文超限记忆召回过多检查召回数量减少召回、做摘要压缩重试无效错误类型判断错误分析错误类型区分可重试和不可重试错误这张表我放在项目 wiki 里团队新人遇到问题先查表能解决 80% 的常见问题。剩下的 20% 再拉群讨论。7. 我踩过的坑与实战建议7.1 不要过早引入路由我做过一个项目一开始就设计了路由架构结果发现 90% 的输入都是同一类路由判断完全是多余的。后来把路由去掉直接用增强型 Agent效果一样但成本降低了一半。这个教训是路由的价值取决于输入类型的分布如果输入高度集中路由就是负收益。正确的做法是先上线一个简单版本收集真实输入数据分析输入类型分布。如果发现输入类型确实多样再引入路由。不要凭想象设计路由分支要用数据说话。7.2 节点粒度宁粗勿细我早期做链式架构的时候喜欢把节点拆得很细觉得这样更灵活。结果发现节点太多导致调试困难一个端到端流程要跟踪十几个节点的日志出了问题很难定位。后来改成宁粗勿细能合并的节点尽量合并节点数量控制在 5-8 个调试效率大幅提升。节点粒度的判断标准是如果一个节点的输出没有独立的校验价值或者两个节点的处理逻辑高度相似就应该合并。节点的价值在于提供校验点和替换点不在于数量多。7.3 日志和可观测性是生命线Agent 工作流最怕的就是出问题了不知道哪里出的问题。所以日志和可观测性必须从第一天就做好。我的做法是每个节点执行时记录输入、输出、耗时、token 消耗、置信度、错误信息。这些日志汇总到一个看板能实时看到每个节点的健康状态。可观测性还包括链路追踪。每个请求分配一个 trace_id所有节点的日志都带上这个 trace_id这样能完整还原一个请求的执行路径。出问题的时候拿着 trace_id 一查哪个节点出的问题一目了然。7.4 提示词版本管理不能省提示词是 Agent 工作流的核心资产但很多人不重视提示词的版本管理。改了提示词之后效果变差了想回滚却发现旧版本没保存。我的做法是把提示词当成代码来管理用 git 做版本控制每次修改都写 commit message 说明改了什么、为什么改。提示词版本管理还要配合 A/B 测试。新版本提示词上线前先在小流量上做 A/B 测试对比新旧版本的成功率、延迟、成本。确认新版本更好再全量上线。这样能避免改了一个词效果崩了的情况。7.5 成本控制要从架构层面考虑Agent 工作流的成本主要是 token 消耗。控制成本要从架构层面考虑而不是等到账单出来了再想办法。架构层面的成本控制手段有减少节点数量、缩短输入长度、缓存重复结果、选择性价比高的模型。我一般会做一个成本预算表估算每个节点的 token 消耗汇总成单次请求的成本。如果成本超出预算就针对性优化。比如某个节点输入特别长就考虑做输入压缩某个节点调用特别频繁就考虑加缓存。实操心得缓存是成本控制的大杀器。很多 Agent 工作流里有大量重复或相似的请求。对这些请求做缓存能节省 30%-50% 的成本。缓存的 key 可以用输入的哈希值缓存的过期时间根据业务特点设置。8. 架构演进中的取舍与平衡8.1 灵活性与可控性的平衡Agent 工作流架构设计本质上是在灵活性和可控性之间找平衡。增强型架构灵活性最高但可控性最差链式架构可控性最好但灵活性最差路由式架构在两者之间。平衡的方法是分层设计。在需要灵活的地方用增强型在需要可控的地方用链式在需要分流的地方用路由式。不要试图用一种架构解决所有问题而是让不同架构在各自擅长的场景发挥作用。8.2 开发效率与运行效率的平衡开发效率是指搭建和迭代工作流的速度运行效率是指工作流执行的速度和成本。一般来说架构越简单开发效率越高但运行效率可能越低架构越复杂运行效率可能越高但开发效率越低。平衡的方法是分阶段演进。MVP 阶段优先开发效率用简单架构快速验证生产阶段优先运行效率逐步优化架构。不要一开始就追求极致的运行效率那样会拖慢验证速度。8.3 通用性与专用性的平衡通用性是指架构能处理多种任务专用性是指架构针对特定任务优化。通用性强的架构复用性好但针对特定任务的性能可能不如专用架构专用性强的架构性能好但换个任务就要重新搭。平衡的方法是核心通用、边缘专用。核心的调度、记忆、工具管理做成通用的边缘的业务逻辑做成专用的。这样既能复用核心能力又能针对业务优化。9. 后续可以扩展的方向9.1 多 Agent 协作的引入时机当单个 Agent 的能力不足以处理任务时可以考虑引入多 Agent 协作。多 Agent 协作是指多个 Agent 各自负责一部分任务通过消息传递来协同。引入时机是任务需要多种专业能力、单个 Agent 的提示词过于复杂、需要并行处理多个子任务。多 Agent 协作的挑战是协调成本高、调试难度大。我的建议是先从两个 Agent 开始验证协作机制可行后再扩展。不要一上来就搭一个十几个 Agent 的系统那样很难调试。9.2 自适应工作流的探索自适应工作流是指工作流能根据输入特征动态调整执行路径。比如简单输入走短链路复杂输入走长链路高置信度输入直接输出低置信度输入触发校验。这种自适应能力能提升整体效率和准确性。实现自适应工作流的关键是有一个准确的难度评估器。难度评估器可以用模型实现也可以用规则实现。评估器的准确性直接决定了自适应策略的效果。9.3 工作流编排的标准化目前工作流的编排还比较碎片化每个项目都有自己的实现方式。未来可能会走向标准化出现通用的工作流描述语言和编排引擎。标准化的好处是工作流可以跨项目复用降低搭建成本。在标准化到来之前我的建议是尽量把工作流逻辑和业务逻辑分离。工作流逻辑用配置描述业务逻辑用代码实现。这样即使将来换编排引擎业务逻辑也不用重写。这个内容后续还可以这样扩展把工作流的每个节点做成可插拔的组件建立一个组件库新项目直接复用组件库里的节点。这样能大幅提升搭建效率也能保证节点的质量。我现在就在做这件事把常用的节点信息提取、格式转换、校验、路由判断等封装成标准组件新项目直接引用省去了重复开发的时间。 
长河君 · 2026/10/20 23:46:21 · 阅读 1.2k Agent工作流架构实战：增强型、链式与路由式选型指南
1. 三种 Agent 工作流架构到底在解决什么问题1.1 从单次调用到多步协作的必然演进很多人第一次接触 Agent 这个概念脑子里浮现的就是给大模型一个提示词它返回一段结果。这种单次调用模式在简单任务上确实够用比如翻译一句话、总结一段文本、生成一个函数。但一旦任务变成帮我调研一下某个技术方案的优劣然后写一份对比报告最后生成一个可执行的验证计划单次调用就彻底歇菜了。原因很简单上下文窗口有限、推理链条太长容易跑偏、中间结果无法校验、错误会一路累积到最终输出。Agent 工作流架构就是在这个背景下被逼出来的。它的核心思路是把一个复杂任务拆成多个可管理的步骤每个步骤由一个 Agent 节点负责节点之间通过明确的输入输出契约传递数据。这样做的好处是每一步都可观测、可调试、可替换。你不需要一次性把所有逻辑塞进一个提示词里而是像搭积木一样把能力拼起来。我刚开始做 Agent 相关项目的时候最大的误区就是一个提示词打天下。结果就是提示词越写越长从 500 字膨胀到 3000 字模型开始忽略中间指令输出格式时好时坏。后来改成工作流架构把任务拆成信息提取 → 逻辑推理 → 格式生成三个节点每个节点的提示词控制在 300 字以内稳定性立刻上了一个台阶。这个经验告诉我Agent 工作流的本质不是让模型更聪明而是让工程更可控。1.2 增强型、链式、路由式三种架构的定位差异标题里提到的三种架构其实对应了三种不同的复杂度层级和适用场景。我用一个生活化的类比来解释增强型架构像是给一个员工配了工具箱他还是一个人干活但手边多了锤子、扳手、计算器链式架构像是流水线每个工位只做一件事做完传给下一个工位路由式架构像是前台分诊先判断你是什么问题再把你分配到对应的专科医生那里。这三种架构不是互相替代的关系而是可以嵌套组合的。一个路由式架构的每个分支内部可能是一条链式流程链式流程的某个节点可能是一个增强型 Agent。理解它们的定位差异是设计出靠谱工作流的前提。下面这张表是我自己总结的对比放在项目文档里给团队新人看效果很好架构类型核心特征适用场景典型节点数调试难度增强型单 Agent 外部工具/知识需要实时数据或精确计算1-2低链式多节点顺序执行任务可拆成固定步骤3-8中路由式先分类再分发输入类型多样、处理逻辑不同5-15高选型的时候不要一上来就追求最复杂的架构。我见过不少项目明明一个增强型 Agent 就能搞定的事情非要搭一套路由加链式的组合结果维护成本翻了三倍效果还没提升多少。架构复杂度应该由任务复杂度决定而不是由技术炫技决定。1.3 什么规模的项目该上哪种架构判断标准其实很朴素看你的任务能不能用一句话说清楚处理逻辑。如果能比如根据用户问题查数据库然后回答那就是增强型如果不能需要分情况讨论比如用户可能问订单、退款、物流三类问题每类处理方式不同那就需要路由式如果任务有明确的先后依赖比如先提取关键信息再基于信息做推理最后生成报告那就是链式。从项目规模看我的一般建议是个人项目或 MVP 阶段优先用增强型快速验证核心价值当任务步骤超过 3 步且步骤间有强依赖时升级到链式当输入类型超过 3 种且处理逻辑差异明显时引入路由式。这个演进路径的好处是每一步都有明确的触发条件不会过度设计。还有一个容易被忽略的点工作流的节点数量和数据传输量是成正比的。每增加一个节点就多一次序列化和反序列化的开销多一个可能出错的环节。所以在设计阶段就要问自己这个节点能不能合并到上一个节点里这个中间结果真的需要单独传递吗我踩过的坑是一开始把提取关键词和提取实体拆成两个节点后来发现完全可以一次调用完成合并后延迟降低了 40%。2. 增强型架构让单个 Agent 拥有外挂能力2.1 工具调用的本质与边界增强型架构的核心就一件事给 Agent 挂工具。工具可以是搜索引擎、数据库查询、代码执行器、API 调用、文件读写等等。它的工作原理是Agent 在推理过程中判断这个问题我需要外部信息或外部操作然后生成一个结构化的工具调用请求系统执行后把结果返回给 AgentAgent 继续推理。这里有个关键认知工具调用不是让模型变聪明而是让模型变准确。模型本身的知识是静态的、可能过时的但通过工具它可以获取实时数据、执行精确计算、操作外部系统。比如你问今天某只股票的价格模型直接回答大概率是错的但如果它调用一个行情查询工具结果就是准确的。工具的定义要尽可能原子化。我见过有人把查询用户信息并计算用户等级并生成推荐打包成一个工具这就违背了原子化原则。正确的做法是拆成查询用户信息计算用户等级生成推荐三个工具让 Agent 自己决定调用顺序。这样做的原因是Agent 的推理能力体现在编排上如果你把编排逻辑写死在工具里那 Agent 就退化成了一个普通的函数调用器。2.2 工具描述怎么写才能让 Agent 正确调用工具描述是增强型架构里最容易被低估的环节。很多人写工具描述就像写 API 文档只写参数类型和返回值结果 Agent 要么不调用要么乱调用。工具描述实际上是给 Agent 看的提示词它需要回答三个问题这个工具是干什么的、什么时候该用、参数怎么填。我总结的工具描述模板是这样的第一句用一句话说明工具功能第二句说明适用场景和不适用场景然后列出参数并给出示例值。举个例子一个天气查询工具的描述可以这样写{ name: get_weather, description: 查询指定城市指定日期的天气情况。适用于用户询问天气、温度、是否下雨等问题。不适用于查询历史气候数据或长期气候趋势。, parameters: { city: { type: string, description: 城市名称使用中文如北京、上海 }, date: { type: string, description: 日期格式为YYYY-MM-DD如2024-06-01。不填则默认为今天 } } }注意描述里的不适用于部分这是很多人会漏掉的。明确告诉 Agent 什么情况下不该用这个工具能大幅减少误调用。另外参数描述里给示例值也很重要模型对示例的敏感度远高于对类型说明的敏感度。实操心得工具数量超过 10 个之后Agent 的调用准确率会明显下降。这时候要么做工具分组要么引入路由机制先筛选工具集。我实测下来单次暴露给 Agent 的工具控制在 5-8 个是最佳区间。2.3 记忆机制短期上下文与长期知识库的配合增强型架构的另一个支柱是记忆。没有记忆的 Agent 每次对话都是失忆状态用户体验很差。记忆分两层短期记忆就是当前对话的上下文长期记忆是跨对话的知识沉淀。短期记忆的管理核心是上下文窗口的分配。我的做法是把上下文分成四个区系统提示区固定不变、长期记忆召回区动态填充、近期对话区保留最近 N 轮、当前输入区。当总长度接近窗口上限时优先压缩近期对话区把早期对话做摘要后存入长期记忆。长期记忆的实现方式我试过几种最实用的还是向量数据库加关键词检索的混合方案。纯向量检索在语义相似但关键词不匹配的场景下会漏召回纯关键词检索在语义泛化场景下会漏召回两者结合能覆盖大部分情况。具体做法是先用关键词检索召回一批候选再用向量相似度排序取 Top-K 注入上下文。这里有个参数需要计算召回数量 K 取多少合适。我的经验公式是 K 上下文剩余预算 / 单条记忆平均长度。假设剩余预算是 2000 token单条记忆平均 200 token那 K 就是 10。但实际使用中我会取 5-8留出余量给模型推理。因为召回的记忆越多模型被干扰的概率越大精准召回比大量召回更重要。3. 链式架构把复杂任务拆成可管理的步骤3.1 链式架构的设计原则与节点划分链式架构的核心思想是分而治之。把一个端到端的复杂任务拆成若干个有明确输入输出的节点节点之间顺序执行。每个节点只关心自己的输入和输出不关心上游怎么来的、下游怎么用的。这种解耦带来的好处是每个节点都可以独立测试、独立优化、独立替换。节点划分的原则我总结为三条单一职责、输出可验证、粒度适中。单一职责是指一个节点只做一件事比如提取信息和验证信息应该是两个节点而不是一个节点里既提取又验证。输出可验证是指每个节点的输出应该是结构化的、可以被程序检查的比如 JSON 格式而不是一段自由文本。粒度适中是指节点不能太粗也不能太细太粗了失去拆分的意义太细了增加编排开销。我做过一个文档处理的项目最初的链路是读取文档 → 提取信息 → 生成摘要 → 输出。后来发现提取信息这一步经常出错但错误要到生成摘要才暴露出来。于是我在中间加了一个信息校验节点专门检查提取的信息是否完整、格式是否正确。加了这一个节点之后整体成功率从 72% 提升到了 91%。这个案例说明链式架构的价值不仅在于拆分任务更在于在关键位置插入校验点。3.2 节点间数据传递的格式约定链式架构最容易出问题的地方就是节点间的数据传递。如果上游输出的是自由文本下游解析起来就很痛苦经常出现模型这次输出格式又变了的情况。解决办法是强制所有节点输出结构化数据通常是 JSON。格式约定要包含几个要素字段名、字段类型、是否必填、示例值。我一般会定义一个 schema每个节点输出后先做 schema 校验校验不通过就触发重试或降级。这样做的代价是增加了一次校验开销但收益是下游节点的稳定性大幅提升。# 节点输出 schema 示例 node_output_schema { type: object, required: [status, data, confidence], properties: { status: {type: string, enum: [success, partial, failed]}, data: {type: object}, confidence: {type: number, minimum: 0, maximum: 1}, error_message: {type: string} } }注意 confidence 字段这是很多人会忽略的。让每个节点输出自己的置信度下游节点可以根据置信度决定是否继续、是否重试、是否降级。比如置信度低于 0.6 就触发重试重试两次还不行就走降级分支。这个机制在长链路里特别有用能避免一个节点的低质量输出污染整条链路。3.3 错误传播与重试策略链式架构的致命弱点是错误会沿着链路传播。第一个节点错了后面所有节点都白做。所以错误处理必须设计在架构层面而不是等到出问题了再补。我的做法是在每个节点外面包一层执行器执行器负责三件事超时控制、重试、降级。超时控制是防止某个节点卡死拖垮整条链路一般设置单节点超时时间为预估耗时的 2-3 倍。重试策略要区分错误类型网络类错误可以重试逻辑类错误重试也没用。降级策略是当重试都失败时返回一个兜底结果让链路能继续走下去。重试次数不是越多越好。我实测下来重试 2 次是性价比最高的第 3 次重试的成功率提升已经很小但延迟增加很明显。而且有些错误是提示词导致的重试同样的提示词结果大概率还是一样这时候应该触发提示词改写而不是简单重试。注意事项链式架构里不要做全链路重试也就是从头开始重跑。这样会导致已经成功的节点重复执行浪费资源。正确的做法是记录每个节点的执行状态只重试失败的节点及其下游节点。4. 路由式架构先分类再分发的智能调度4.1 路由决策的实现方式对比路由式架构的第一步是判断输入属于哪一类然后分发到对应的处理分支。路由决策的实现方式主要有三种规则匹配、模型分类、混合方式。规则匹配是用关键词、正则、意图模板来判断优点是快、可控、可解释缺点是泛化能力差遇到没见过的表达就失效。模型分类是让大模型来判断意图优点是泛化能力强缺点是慢、有成本、可能不稳定。混合方式是先用规则做粗筛规则匹配不上的再用模型判断兼顾了速度和泛化。我一般推荐混合方式。具体做法是维护一个规则库覆盖高频的、明确的意图比如包含退款关键词就路由到退款分支。规则匹配不上的输入再走模型分类。这样能覆盖 80% 的常见情况用规则快速处理剩下 20% 的长尾情况用模型兜底。模型分类的提示词设计有个技巧不要让模型输出类别名称而是输出类别编号。因为类别名称可能有多种表达编号是唯一的。同时要求模型输出置信度置信度低于阈值时走默认分支或人工介入。4.2 路由分支的粒度控制路由分支的粒度是个需要仔细权衡的问题。分支太粗每个分支内部逻辑复杂失去了路由的意义分支太细路由判断本身变得复杂而且容易出现没有匹配分支的情况。我的经验是一级路由控制在 3-7 个分支比较合适。超过 7 个分支时考虑做二级路由也就是先分大类再在大类内分小类。比如客服场景一级路由分售前咨询订单问题售后问题三类订单问题下面再分查询修改取消三个子类。分支粒度还要考虑每个分支的处理成本。如果某个分支的处理逻辑特别复杂可以单独拆出来如果几个分支的处理逻辑很相似可以合并。判断标准是如果两个分支的处理逻辑有 70% 以上重合就应该合并。4.3 默认分支与兜底策略路由式架构必须设计默认分支。因为无论你的路由判断多完善总会有输入匹配不上任何分支。默认分支的作用是兜底避免用户输入被吞掉。默认分支的处理方式有几种一是返回通用回复告诉用户我没理解你的问题请换个说法二是转人工把输入转给人工处理三是走通用处理流程用一个通用的 Agent 来处理。选择哪种取决于业务场景。客服场景一般选转人工工具类场景一般选通用处理。兜底策略还要考虑路由判断失败的情况。路由判断本身也可能出错比如模型分类超时、规则库加载失败等。这时候应该有一个降级路由比如直接走默认分支或者走最近最少使用的分支来分散风险。5. 三种架构的组合与选型实战5.1 嵌套组合的常见模式实际项目里三种架构很少单独使用更多是嵌套组合。最常见的组合模式有两种路由套链式、链式套增强。路由套链式是指一级路由分发后每个分支内部是一条链式流程。这种模式适合输入类型多样、每种类型处理步骤固定的场景。比如一个内容审核系统一级路由分文本图片视频三类每类内部是一条提取内容 → 检测违规 → 生成报告的链式流程。链式套增强是指链式流程的某个节点是一个增强型 Agent。这种模式适合大部分步骤是固定流程、但某个步骤需要灵活调用工具的场景。比如一个数据分析流程数据清洗 → 数据分析 → 报告生成三步其中数据分析这一步需要根据数据特征动态选择分析方法和工具就适合用增强型 Agent。组合的时候要注意层级不要超过三层。三层以上的嵌套调试难度会指数级上升而且性能开销也很大。如果发现需要三层以上说明任务拆分可能有问题应该重新审视拆分逻辑。5.2 选型决策树与成本估算选型的时候我会走一遍决策树先问任务能不能用一句话说清楚能就用增强型不能就问任务是否有明确的步骤依赖有就用链式没有就问输入类型是否多样是就用路由式如果都不满足说明任务需要进一步拆解。成本估算主要看三个维度token 消耗、延迟、维护成本。增强型的 token 消耗主要在工具调用和结果处理上延迟取决于工具执行时间维护成本主要是工具描述和记忆管理。链式的 token 消耗是各节点之和延迟是各节点延迟之和维护成本主要是节点间契约和错误处理。路由式的 token 消耗多了路由判断这一层延迟也多了路由判断时间维护成本主要是路由规则和分支管理。我一般会做一个粗略的估算表把三种架构的预期成本列出来再结合业务对延迟和成本的敏感度来选。如果业务对延迟敏感优先选增强型如果对成本敏感优先选链式如果对准确性敏感优先选路由式。5.3 从 MVP 到生产环境的演进路径我的建议是不要一上来就搭完整架构而是从 MVP 开始逐步演进。第一阶段用增强型 Agent 验证核心价值确认任务可行、用户有需求。第二阶段把验证过的流程拆成链式提升稳定性和可观测性。第三阶段引入路由支持更多输入类型和业务场景。每个阶段都要有明确的升级触发条件。比如增强型升级到链式的触发条件是任务步骤超过 3 步且步骤间有强依赖链式升级到路由的触发条件是输入类型超过 3 种且处理逻辑差异明显。有了触发条件就不会因为想试试新架构而过度设计。演进过程中要注意向后兼容。新架构上线时旧架构要保留一段时间作为降级方案。我一般会做灰度发布先切 10% 流量到新架构观察一周没问题再逐步扩大比例。这样即使新架构有问题也能快速回滚。6. 实操中的常见问题与排查技巧6.1 节点输出格式不稳定的排查思路节点输出格式不稳定是最高频的问题。表现是同样的提示词有时候输出 JSON有时候输出带 markdown 代码块的 JSON有时候输出一段解释文字。排查思路是先从提示词入手检查是否明确要求了输出格式、是否给了示例、是否用了结构化输出功能。如果提示词没问题就检查模型版本。不同模型版本对格式要求的遵循程度不一样有些版本对 JSON 输出支持更好。如果模型版本也没问题就检查输入内容。输入内容里如果包含特殊字符、超长文本、多语言混合都可能影响输出格式。我的终极解决方案是在节点执行器里加一层格式修复。先用正则提取 JSON 部分如果提取失败就用模型做一次格式转换如果还失败就触发重试。这层修复能覆盖 95% 以上的格式问题。6.2 链路延迟过高的优化手段链路延迟高通常是因为节点太多、串行执行、或者某个节点特别慢。优化手段对应有三种合并节点、并行执行、优化慢节点。合并节点是把可以合并的节点合并减少序列化开销和调用次数。并行执行是把没有依赖关系的节点改成并行比如提取关键词和提取实体可以并行。优化慢节点是找出耗时最长的节点针对性优化比如换更快的模型、减少输入长度、缓存结果。我一般会先做一次链路 profiling记录每个节点的耗时找出瓶颈节点。80% 的延迟问题都集中在 20% 的节点上优化这几个节点就能大幅改善整体延迟。6.3 路由误判的修正与迭代路由误判是指输入被分到了错误的分支。修正方法是先收集误判案例分析误判原因然后针对性调整。误判原因通常有三类规则覆盖不足、模型判断偏差、边界情况模糊。规则覆盖不足就补充规则模型判断偏差就优化提示词或换模型边界情况模糊就明确定义边界。我一般会维护一个误判案例库每次发现误判就记录进去定期分析并迭代路由逻辑。迭代的时候要注意不要过度拟合。如果为了修正几个案例而大改路由逻辑可能会引入新的误判。我的做法是每次迭代只改一个点改完观察一段时间确认没有引入新问题再改下一个点。6.4 常见问题速查表问题现象可能原因排查方向解决方案节点输出格式不稳定提示词不明确、模型版本问题检查提示词和模型加格式修复层、换模型链路延迟高节点多、串行、慢节点profiling 找瓶颈合并节点、并行、优化慢节点路由误判规则不足、模型偏差分析误判案例补规则、优化提示词工具调用失败描述不清、参数错误检查工具描述和参数优化描述、加参数校验上下文超限记忆召回过多检查召回数量减少召回、做摘要压缩重试无效错误类型判断错误分析错误类型区分可重试和不可重试错误这张表我放在项目 wiki 里团队新人遇到问题先查表能解决 80% 的常见问题。剩下的 20% 再拉群讨论。7. 我踩过的坑与实战建议7.1 不要过早引入路由我做过一个项目一开始就设计了路由架构结果发现 90% 的输入都是同一类路由判断完全是多余的。后来把路由去掉直接用增强型 Agent效果一样但成本降低了一半。这个教训是路由的价值取决于输入类型的分布如果输入高度集中路由就是负收益。正确的做法是先上线一个简单版本收集真实输入数据分析输入类型分布。如果发现输入类型确实多样再引入路由。不要凭想象设计路由分支要用数据说话。7.2 节点粒度宁粗勿细我早期做链式架构的时候喜欢把节点拆得很细觉得这样更灵活。结果发现节点太多导致调试困难一个端到端流程要跟踪十几个节点的日志出了问题很难定位。后来改成宁粗勿细能合并的节点尽量合并节点数量控制在 5-8 个调试效率大幅提升。节点粒度的判断标准是如果一个节点的输出没有独立的校验价值或者两个节点的处理逻辑高度相似就应该合并。节点的价值在于提供校验点和替换点不在于数量多。7.3 日志和可观测性是生命线Agent 工作流最怕的就是出问题了不知道哪里出的问题。所以日志和可观测性必须从第一天就做好。我的做法是每个节点执行时记录输入、输出、耗时、token 消耗、置信度、错误信息。这些日志汇总到一个看板能实时看到每个节点的健康状态。可观测性还包括链路追踪。每个请求分配一个 trace_id所有节点的日志都带上这个 trace_id这样能完整还原一个请求的执行路径。出问题的时候拿着 trace_id 一查哪个节点出的问题一目了然。7.4 提示词版本管理不能省提示词是 Agent 工作流的核心资产但很多人不重视提示词的版本管理。改了提示词之后效果变差了想回滚却发现旧版本没保存。我的做法是把提示词当成代码来管理用 git 做版本控制每次修改都写 commit message 说明改了什么、为什么改。提示词版本管理还要配合 A/B 测试。新版本提示词上线前先在小流量上做 A/B 测试对比新旧版本的成功率、延迟、成本。确认新版本更好再全量上线。这样能避免改了一个词效果崩了的情况。7.5 成本控制要从架构层面考虑Agent 工作流的成本主要是 token 消耗。控制成本要从架构层面考虑而不是等到账单出来了再想办法。架构层面的成本控制手段有减少节点数量、缩短输入长度、缓存重复结果、选择性价比高的模型。我一般会做一个成本预算表估算每个节点的 token 消耗汇总成单次请求的成本。如果成本超出预算就针对性优化。比如某个节点输入特别长就考虑做输入压缩某个节点调用特别频繁就考虑加缓存。实操心得缓存是成本控制的大杀器。很多 Agent 工作流里有大量重复或相似的请求。对这些请求做缓存能节省 30%-50% 的成本。缓存的 key 可以用输入的哈希值缓存的过期时间根据业务特点设置。8. 架构演进中的取舍与平衡8.1 灵活性与可控性的平衡Agent 工作流架构设计本质上是在灵活性和可控性之间找平衡。增强型架构灵活性最高但可控性最差链式架构可控性最好但灵活性最差路由式架构在两者之间。平衡的方法是分层设计。在需要灵活的地方用增强型在需要可控的地方用链式在需要分流的地方用路由式。不要试图用一种架构解决所有问题而是让不同架构在各自擅长的场景发挥作用。8.2 开发效率与运行效率的平衡开发效率是指搭建和迭代工作流的速度运行效率是指工作流执行的速度和成本。一般来说架构越简单开发效率越高但运行效率可能越低架构越复杂运行效率可能越高但开发效率越低。平衡的方法是分阶段演进。MVP 阶段优先开发效率用简单架构快速验证生产阶段优先运行效率逐步优化架构。不要一开始就追求极致的运行效率那样会拖慢验证速度。8.3 通用性与专用性的平衡通用性是指架构能处理多种任务专用性是指架构针对特定任务优化。通用性强的架构复用性好但针对特定任务的性能可能不如专用架构专用性强的架构性能好但换个任务就要重新搭。平衡的方法是核心通用、边缘专用。核心的调度、记忆、工具管理做成通用的边缘的业务逻辑做成专用的。这样既能复用核心能力又能针对业务优化。9. 后续可以扩展的方向9.1 多 Agent 协作的引入时机当单个 Agent 的能力不足以处理任务时可以考虑引入多 Agent 协作。多 Agent 协作是指多个 Agent 各自负责一部分任务通过消息传递来协同。引入时机是任务需要多种专业能力、单个 Agent 的提示词过于复杂、需要并行处理多个子任务。多 Agent 协作的挑战是协调成本高、调试难度大。我的建议是先从两个 Agent 开始验证协作机制可行后再扩展。不要一上来就搭一个十几个 Agent 的系统那样很难调试。9.2 自适应工作流的探索自适应工作流是指工作流能根据输入特征动态调整执行路径。比如简单输入走短链路复杂输入走长链路高置信度输入直接输出低置信度输入触发校验。这种自适应能力能提升整体效率和准确性。实现自适应工作流的关键是有一个准确的难度评估器。难度评估器可以用模型实现也可以用规则实现。评估器的准确性直接决定了自适应策略的效果。9.3 工作流编排的标准化目前工作流的编排还比较碎片化每个项目都有自己的实现方式。未来可能会走向标准化出现通用的工作流描述语言和编排引擎。标准化的好处是工作流可以跨项目复用降低搭建成本。在标准化到来之前我的建议是尽量把工作流逻辑和业务逻辑分离。工作流逻辑用配置描述业务逻辑用代码实现。这样即使将来换编排引擎业务逻辑也不用重写。这个内容后续还可以这样扩展把工作流的每个节点做成可插拔的组件建立一个组件库新项目直接复用组件库里的节点。这样能大幅提升搭建效率也能保证节点的质量。我现在就在做这件事把常用的节点信息提取、格式转换、校验、路由判断等封装成标准组件新项目直接引用省去了重复开发的时间。