1. 三种 Agent 工作流架构到底在解决什么问题

1.1 从单次调用到多步协作的必然演进

很多人第一次接触 Agent 这个概念，脑子里浮现的就是"给大模型一个提示词，它返回一段结果"。这种单次调用模式在简单任务上确实够用，比如翻译一句话、总结一段文本、生成一个函数。但一旦任务变成"帮我调研一下某个技术方案的优劣，然后写一份对比报告，最后生成一个可执行的验证计划"，单次调用就彻底歇菜了。原因很简单：上下文窗口有限、推理链条太长容易跑偏、中间结果无法校验、错误会一路累积到最终输出。

Agent 工作流架构就是在这个背景下被逼出来的。它的核心思路是把一个复杂任务拆成多个可管理的步骤，每个步骤由一个 Agent 节点负责，节点之间通过明确的输入输出契约传递数据。这样做的好处是每一步都可观测、可调试、可替换。你不需要一次性把所有逻辑塞进一个提示词里，而是像搭积木一样把能力拼起来。

我刚开始做 Agent 相关项目的时候，最大的误区就是"一个提示词打天下"。结果就是提示词越写越长，从 500 字膨胀到 3000 字，模型开始忽略中间指令，输出格式时好时坏。后来改成工作流架构，把任务拆成"信息提取 → 逻辑推理 → 格式生成"三个节点，每个节点的提示词控制在 300 字以内，稳定性立刻上了一个台阶。这个经验告诉我：Agent 工作流的本质不是让模型更聪明，而是让工程更可控。

1.2 增强型、链式、路由式三种架构的定位差异

标题里提到的三种架构，其实对应了三种不同的复杂度层级和适用场景。我用一个生活化的类比来解释：增强型架构像是给一个员工配了工具箱，他还是一个人干活，但手边多了锤子、扳手、计算器；链式架构像是流水线，每个工位只做一件事，做完传给下一个工位；路由式架构像是前台分诊，先判断你是什么问题，再把你分配到对应的专科医生那里。

这三种架构不是互相替代的关系，而是可以嵌套组合的。一个路由式架构的每个分支内部，可能是一条链式流程；链式流程的某个节点，可能是一个增强型 Agent。理解它们的定位差异，是设计出靠谱工作流的前提。下面这张表是我自己总结的对比，放在项目文档里给团队新人看，效果很好：

选型的时候不要一上来就追求最复杂的架构。我见过不少项目，明明一个增强型 Agent 就能搞定的事情，非要搭一套路由加链式的组合，结果维护成本翻了三倍，效果还没提升多少。架构复杂度应该由任务复杂度决定，而不是由技术炫技决定。

1.3 什么规模的项目该上哪种架构

判断标准其实很朴素：看你的任务能不能用一句话说清楚处理逻辑。如果能，比如"根据用户问题查数据库然后回答"，那就是增强型；如果不能，需要分情况讨论，比如"用户可能问订单、退款、物流三类问题，每类处理方式不同"，那就需要路由式；如果任务有明确的先后依赖，比如"先提取关键信息，再基于信息做推理，最后生成报告"，那就是链式。

从项目规模看，我的一般建议是：个人项目或 MVP 阶段，优先用增强型，快速验证核心价值；当任务步骤超过 3 步且步骤间有强依赖时，升级到链式；当输入类型超过 3 种且处理逻辑差异明显时，引入路由式。这个演进路径的好处是每一步都有明确的触发条件，不会过度设计。

还有一个容易被忽略的点：工作流的节点数量和数据传输量是成正比的。每增加一个节点，就多一次序列化和反序列化的开销，多一个可能出错的环节。所以在设计阶段就要问自己：这个节点能不能合并到上一个节点里？这个中间结果真的需要单独传递吗？我踩过的坑是，一开始把"提取关键词"和"提取实体"拆成两个节点，后来发现完全可以一次调用完成，合并后延迟降低了 40%。

2. 增强型架构：让单个 Agent 拥有外挂能力

2.1 工具调用的本质与边界

增强型架构的核心就一件事：给 Agent 挂工具。工具可以是搜索引擎、数据库查询、代码执行器、API 调用、文件读写等等。它的工作原理是，Agent 在推理过程中判断"这个问题我需要外部信息或外部操作"，然后生成一个结构化的工具调用请求，系统执行后把结果返回给 Agent，Agent 继续推理。

这里有个关键认知：工具调用不是让模型变聪明，而是让模型变准确。模型本身的知识是静态的、可能过时的，但通过工具它可以获取实时数据、执行精确计算、操作外部系统。比如你问"今天某只股票的价格"，模型直接回答大概率是错的，但如果它调用一个行情查询工具，结果就是准确的。

工具的定义要尽可能原子化。我见过有人把"查询用户信息并计算用户等级并生成推荐"打包成一个工具，这就违背了原子化原则。正确的做法是拆成"查询用户信息""计算用户等级""生成推荐"三个工具，让 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 常见问题速查表

这张表我放在项目 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 工作流编排的标准化

目前工作流的编排还比较碎片化，每个项目都有自己的实现方式。未来可能会走向标准化，出现通用的工作流描述语言和编排引擎。标准化的好处是工作流可以跨项目复用，降低搭建成本。

在标准化到来之前，我的建议是尽量把工作流逻辑和业务逻辑分离。工作流逻辑用配置描述，业务逻辑用代码实现。这样即使将来换编排引擎，业务逻辑也不用重写。

这个内容后续还可以这样扩展：把工作流的每个节点做成可插拔的组件，建立一个组件库，新项目直接复用组件库里的节点。这样能大幅提升搭建效率，也能保证节点的质量。我现在就在做这件事，把常用的节点（信息提取、格式转换、校验、路由判断等）封装成标准组件，新项目直接引用，省去了重复开发的时间。