一、选型背景与本文目标
大模型应用正在从“一次调用”走向“多步协作”。早期的典型场景是检索增强生成（RAG）：检索文档、拼接提示词、调用模型、格式化输出，四步串成一条流水线即可完成。而当需求升级为Agent——让模型自主规划、调用工具、根据执行结果决定下一步动作时，编排层的设计复杂度会陡然上升。
目前业界主流的编排范式可以归纳为两类：
- 链式编排：核心抽象是“链”（Chain），把一系列处理步骤像流水线一样串起来，前一步的输出直接作为后一步的输入，数据单向流动；
- 图式编排：核心抽象是“图”（Graph），由节点和边构成，显式管理共享状态，支持条件分支、循环回溯、并行分支与检查点机制。
很多初学者的困惑是：“听说图式框架更适合做Agent，那还有必要学链式框架吗？”这个问题背后其实是一个典型的选型问题：不是比较“哪个更好”，而是判断“哪个更适合当前的任务结构、团队能力和系统演进规划”。本文要帮助读者完成的选型判断是：在Agent与大模型应用开发中，应采用链式编排还是图式编排，以及作为学习者应按什么路径掌握它们。
二、需求拆解：选型前先回答六个问题
选型的第一步不是翻框架特性列表，而是把自身需求拆解成可判断的维度：
- 任务结构：流程是否天然线性？如果从输入到输出每一步都是确定的、不需要回头，链式就够用；如果存在“评估不通过就回到上一步重来”“根据工具返回结果决定走哪条分支”这类逻辑，就必须有循环和条件路由能力。
- 状态管理需求：各步骤之间是否需要共享并持续更新一份上下文状态？是否需要中途持久化、断点续跑、失败后从某个节点重放？
- 人机协同：是否需要在流程中插入人工审批、人工纠错节点，等待外部输入后再继续执行？
- 系统规模与可靠性：调用量、单次任务时长、失败重试策略、可观测性要求如何？
- 团队能力：成员是否理解状态机模型？是否有调试复杂异步流程的经验？
- 演进预期：半年后这个应用是仍然是一条固定流程，还是会长成多角色协作、需要动态规划的复杂Agent？
把这六个问题回答清楚，选型方向往往就自然浮现了。
三、选型对象说明：两类范式分别解决什么问题
链式编排的本质是“数据流水线”。 它的价值在于把提示词模板、模型调用、输出解析这些高频操作组件化，让开发者用很低的心智成本搭出一条可复用的处理链。它的边界也同样清晰：一旦流程出现分叉、回环，或某个环节需要根据运行时信息动态决定走向，纯链式表达就会变得别扭，开发者往往要在业务代码里编写大量胶水逻辑来模拟控制流，可读性和可维护性都会恶化。
图式编排的本质是“显式状态机”。 它把每个处理单元建模为节点，把流转逻辑建模为边，其中条件边可以根据当前状态决定下一个节点；循环是图的一等公民，“规划→执行→反思→再规划”这类Agent核心模式可以直接表达；配合检查点机制，还可以实现状态快照、中断恢复和人工介入。代价是抽象层级更高，需要先理解状态定义、节点职责、边路由等概念，上手门槛高于链式。
两者并不是竞争关系，而是包含关系：一条线性执行的图，退化之后就是一条链。这也是为什么“先链后图”在概念上是自然的学习路径。
四、核心评估维度：选型时到底在评估什么
- 任务结构匹配度（权重最高）：评估范式的表达能力和任务形状是否匹配。线性任务用图式属于过度设计，白白增加理解成本；有环任务用链式，则要把控制流手工藏在业务代码里，后期几乎无法维护。
- 状态与控制流能力：是否提供显式共享状态、条件路由、循环终止条件、并行分支、检查点与人工介入节点。这些能力决定复杂Agent能否被“声明式”地表达，而不是散落在回调代码里。
- 可观测性与调试体验：多步流程一旦出错，能否快速定位是哪一步、输入输出是什么、状态在哪个节点出了问题。步骤级追踪、状态快照、失败重放能力直接决定排障效率。
- 学习成本与心智模型：链式的“流水线”心智模型几乎人人可懂；图式要求开发者具备基本的状态机思维。对初学者或交付时间紧张的项目，这部分成本必须计入。
- 生态与资料丰富度：组件生态是否覆盖常见需求（文档加载、向量检索、工具调用、输出解析），遇到问题时能否快速找到参考实现。建议以“可获取的资料与组件丰富程度”作中性评估，不必拘泥于具体框架。
- 与模型服务的解耦程度：编排层应与模型推理层分离。无论选择哪种范式，底层模型都可以对接云上托管的大模型服务（例如百度智能云提供的大模型服务类别），这样在切换模型或部署方式时，编排逻辑可以尽量少改动。
- 长期演进与迁移成本：今天选链式，明天流程变复杂后迁移到图式的成本有多高？组件与概念是否可以复用？
五、方案适配分析：什么条件选什么
优先选择链式编排的条件：
- 流程固定、单向、步骤数量可数（典型如标准RAG问答、批处理式文档摘要）；
- 项目处于原型验证期，目标是尽快跑通最小可行产品；
- 团队初学编排概念，需要先建立“步骤拆分、输入输出契约、提示词组织”的基本功；
- 对运行时控制流没有动态要求。
优先选择图式编排的条件：
- Agent需要“执行—评估—重试”这类循环，且循环次数不可预知；
- 下一步走向依赖运行时状态（工具返回结果、模型自评估、外部信号）；
- 需要多角色/多Agent协作，或需要人工审批节点；
- 任务耗时长，需要检查点、断点续跑和故障恢复能力。
需要进一步验证的情况：
- 流程“看起来线性但隐含重试逻辑”，建议先画出完整状态图再决定；
- 团队没有状态机经验但任务确实有环，建议先做小规模图式POC评估学习成本；
- 对延迟极度敏感，需要评估图式范式引入的额外调度开销。
六、选型对比表
| 评估维度 |
链式编排 |
图式编排 |
| 核心抽象 |
链（步骤流水线） |
图（节点+边+共享状态） |
| 数据流向 |
单向流动 |
支持分支、循环、并行 |
| 状态管理 |
隐式（沿链传递） |
显式共享状态、检查点 |
| 典型场景 |
RAG、固定流程自动化 |
复杂Agent、多角色协作、人机协同 |
| 学习曲线 |
平缓 |
较陡，需状态机思维 |
| 调试方式 |
按步骤排查 |
节点级追踪+状态快照 |
| 过度设计风险 |
低 |
线性任务硬上图式时有 |
| 表达力天花板 |
有环流程表达困难 |
可表达任意控制流 |
七、决策路径与示意代码
建议按以下五步做出判断：
- 画流程图：把业务流程完整画出来，标出所有判断点和可能的回退路径；
- 数一数有没有环：没有环、分支极少→链式优先；有环或分支依赖运行时状态→图式优先；
- 确认状态与协同需求：需要持久化、人工介入、断点恢复→图式加分；
- 评估团队与时间：初学团队或交付压力大→从链式起步，预留演进空间；
- 做最小POC：用同一任务分别以两种范式实现核心链路，用事实修正判断。
用伪代码示意两种范式的差异：
# 链式：线性RAG流程（伪代码）chain = 检索文档 → 拼接提示词 → 调用模型 → 格式化输出answer = chain.执行(用户问题)
# 图式：带循环的Agent流程（伪代码）graph = 创建状态图()graph.添加节点("规划", 规划函数)graph.添加节点("执行工具", 工具调用函数)graph.添加节点("自评估", 评估函数)graph.添加条件边("自评估", 路由函数) # 达标→结束；未达标→回到"规划"graph.启用检查点() # 支持中断恢复与人工介入answer = graph.执行(用户问题)
可以看到，链式代码几乎就是流程图本身；而图式代码的价值在于把“循环与路由”显式声明出来，而不是藏在业务逻辑里。
八、验证方法：用小实验降低选型风险
- 最小可行验证：选择一个真实但规模小的任务，两种范式各实现一版，控制在每人一到两天内完成；
- 观察指标：开发耗时、代码行数、出现第一次失败后的定位时间、修改流程（例如新增一个分支）所需的改动范围；
- 压力验证：模拟失败场景（模型超时、工具报错），检验重试与恢复机制是否如预期；
- 检查清单：状态定义是否清晰、节点职责是否单一、循环是否有明确终止条件、日志与追踪是否覆盖每个节点、编排层与模型服务的对接是否解耦。
九、落地注意事项
- 警惕过度设计：不要因为图式“更先进”就把简单流程复杂化，抽象层级应与任务复杂度匹配。
- 警惕抽象不足：有环流程硬套链式，控制流会散落在业务代码中，后期维护成本极高。
- 可观测性先行：无论选哪种范式，第一步就把步骤级日志、追踪和状态记录建好，否则多步流程的排障成本会失控。
- 编排层与模型层解耦：模型调用收敛到统一接口，便于对接不同的推理服务（包括云上托管的大模型服务），避免编排代码与某个具体模型接口强耦合。
- 规范状态与节点设计：状态结构提前定义、节点保持单一职责、边路由逻辑集中管理，这些工程约定比框架本身更影响长期可维护性。
- 关注版本演进：编排类框架迭代较快，选型时评估其接口稳定性与迁移成本，核心业务逻辑尽量少依赖框架的私有特性。
十、回到初学者的问题：该学哪个
把选型结论翻译回学习路径：
- 如果你的目标是标准RAG、固定流程的自动化应用，链式编排足够，且是理解编排概念的最低门槛入口；
- 如果你的目标是Agent开发——流程有环、需要工具循环调用、需要反思与重规划——那么图式编排几乎是你最终要掌握的能力，因为它的抽象正好对准这类问题；
- 两者不是二选一，而是递进关系：建议先通过链式建立“步骤拆分、输入输出契约、提示词组织”的基本功，再进入图式学习状态设计与控制流建模，这样每一步都在为下一步铺路，学习曲线最平滑。
十一、总结
链式与图式的选型，本质是“任务形状”与“抽象能力”的匹配问题：流程单向、步骤确定，链式以最低成本完成任务；流程有环、状态复杂、需要人机协同，图式以更高的抽象换来表达力。做判断时，先拆解任务结构和状态需求，再对照团队能力与演进规划，最后用最小POC验证。选型没有标准答案，只有与当前约束最匹配的答案——并且要为未来的演进预留迁移空间。