Chain vs Agent
先给结论
只要流程可以稳定写死，就先用 Chain。
只有当系统必须根据上下文动态决定“下一步做什么”时，再上 Agent。
这不是功能强弱对比，而是控制成本和不确定性的选择。
一句话区分
Chain是你提前写好步骤，系统按顺序执行Agent是你给出目标和工具，系统自己决定调用路径
快速对比
| 维度 | Chain | Agent |
|---|---|---|
| 流程形状 | 固定 | 动态 |
| 可预测性 | 高 | 较低 |
| 调试难度 | 低到中 | 中到高 |
| 适合任务 | 摘要、分类、固定 RAG、结构化输出 | 工具选择、路径不确定、多步决策 |
| 常见风险 | 过早拆太复杂 | 为简单任务引入不必要不稳定性 |
什么场景优先用 Chain
- 输入到输出的步骤基本固定
- 你已经知道需要哪些信息和处理顺序
- 你更需要稳定性、速度和可调试性
比如这个仓库里的这些任务就更适合链:
- 根据学习主题生成学习计划
- 基于检索结果生成课程回答
- 把模型输出整理成固定结构
这些任务的关键不是“临场决策”，而是把已有步骤稳定串起来。
什么场景才值得用 Agent
- 你不知道用户问题会触发哪一种处理路径
- 系统需要在多个 Tool 之间做动态选择
- 一次工具调用后，还需要根据结果决定下一步
例如:
- 用户问“我现在应该先学哪一章，并顺手给我两道练习题”
- 系统可能要先查课程目录，再看章节摘要，再生成练习
- 这时用固定链可以做，但会变得越来越硬编码
这就是 Agent 真正有价值的地方。
一个实用判断题
如果你已经能在白板上写出稳定流程:
输入 -> 检索 -> 生成 -> 返回
那通常先不要上 Agent。
如果你写到第二步就开始出现“看情况决定下一步”，Agent 才值得认真评估。
常见误判
误判 1：Agent 更智能，所以默认更好
不对。Agent 只是把决策权更多交给模型。
一旦任务本来就固定，这种额外自由只会增加不稳定性。
误判 2：有 Tool 就必须上 Agent
不对。Tool 完全可以被固定链直接调用。
真正决定是否需要 Agent 的，是“工具调用顺序是否必须动态决定”。
误判 3：Chain 不适合复杂任务
不对。很多复杂任务仍然可以拆成多个稳定链，再由更外层逻辑组织。
Agent 不是复杂度的唯一出口。
对当前课程的建议
- 第 3 到 6 章，优先把链式思维练扎实
- 第 7 章再引入 Agent，并且只在动态决策场景里用它
- 如果你发现一个 Agent 经常只走固定两三步，通常说明它应该回退成链
对应回看章节
- 想看最小固定流程: 第 3 章：第一个链式应用
- 想看工具和动态决策边界: 第 7 章：Tools 与 Agent