Agent 学习路线：先学工作流，再学智能体框架

Agent 学习最容易犯的错，是把 n8n、Dify、LangGraph、AutoGen 当成四个相邻框架一起学。它们解决的问题层级不同：前两个更适合看清工作流和应用边界，后两个才把状态、循环与多角色协作推到代码层。

四个入口的分工

| 工具 | 先学什么 | 前置 | 第一份产物 | | --- | --- | --- | --- | | n8n | 触发器、节点、分支、重试、人工确认 | 会读 API 文档 | 一个确定性审批流 | | Dify | Prompt、知识库、工作流与发布界面 | 理解模型调用 | 一个带人工兜底的 AI 应用 | | LangGraph | 显式状态、节点、边、持久化、中断 | Python 与状态机 | 可暂停恢复的工具调用图 | | AutoGen | Agent 消息、团队协作和运行时 | Python、异步与工具调用 | 有终止条件的双角色实验 |

许可不能一笔带过：LangGraph 为 MIT；AutoGen 代码与文档可能采用不同许可，应分别查看仓库 LICENSE 与文档声明；n8n、Dify 也有各自的开源/商业边界，部署和再分发前要按当前条款核验。本文核验日期为 2026-07-15。

为什么先从确定性工作流开始

先做“表单进入、查客户资料、生成草稿、人工批准、写回 CRM”这类流程。n8n 会迫使你标出输入、分支和失败重试；Dify 会让你看到模型节点怎样嵌入应用。只要每一步能写成规则，就没有必要先引入自主 Agent。

一句话解读：工作流先教你画清责任边界，Agent 框架才有地方安放不确定性。

一句话解读：框架层级越高，学习目标越应该从“功能更多”改成“自主动作仍然可停止、可追踪”。

何时升级到 LangGraph

当任务需要多轮状态、暂停后恢复、人工批准后继续，或某个工具失败要沿不同路径回退时，图式状态管理开始有价值。练习不要从“研究助手”这种宽任务开始，而应把上面的销售流程改造成可恢复状态图，并保存每次状态迁移。

AutoGen 应放在更后面

多角色对话会快速增加消息、终止与成本问题。只有当单一状态图已难表达角色间协作，且你能定义每个角色的输入、工具权限和停止条件时，再用 AutoGen 做受限实验。两个 Agent 互相聊天很容易演示，却不自动形成可靠分工。

这条路线哪里最难

前置知识从 API、JSON 和目标 SaaS 使用开始；进入代码框架前还要会 Python 与基本状态机。

n8n 的难点是外部系统凭证与幂等；Dify 的难点是模型行为与工作流配置同时变化；LangGraph 的难点是状态模型和恢复；AutoGen 的难点是消息膨胀、角色重叠与终止。学习曲线由责任扩大驱动，不是由界面转代码驱动。

第一阶段只需要 API、JSON 和目标 SaaS 的使用经验，练的是确定性触发、分支与重试；第二阶段需要模型调用和基本评估能力，练的是生成结果如何进入人工确认；第三阶段才要求 Python、状态机和异步基础，练的是持久化、恢复、工具权限与终止。每跨一段，产物应从流程图升级为运行记录，再升级为状态迁移与失败恢复测试。

一句话解读：Agent 学习曲线的拐点不是第一次调用工具，而是第一次必须为错误动作设计恢复路径。

一次四阶段练习

先在 n8n 完成不含模型的审批流程；再在 Dify 加入一段受控生成，并保留人工确认；随后用 LangGraph 重写需要暂停恢复的部分；最后仅在确有角色协作价值时，用 AutoGen 比较双角色方案。每一阶段都保留相同输入与验收表，才看得出新增复杂度换来了什么。

最低可行学习路径可以止于三步：第一步用 n8n 或等价工具完成确定性审批并验证重复提交；第二步只给一个节点加入模型，准备十条输入并记录人工退回；第三步仅把“暂停后继续”这一段移到 LangGraph，主动中断一次再恢复。只有单角色状态图已经无法表达真实协作，才把 AutoGen 作为第四步。

升级与停止条件

若问题来自脏数据、权限不清或外部 API 不稳定，换 Agent 框架不会解决。若工作流已经可预测、成本可控，也不必为了“更智能”升级。框架升级的理由应是出现了新的状态或协作需求，而不是教程进入下一章。

常见失败是让“研究员”和“审稿人”两个角色自由对话，却没有最大轮次、工具白名单和最终审批；演示中它们像在协作，运行记录里却只是重复改写同一段文字。这个失败应通过收紧角色责任和终止条件修复，而不是再增加第三个 Agent。高风险写入、支付、删除和对外发送也不适合无人审批地练习。

同一个销售线索何时真的需要升级

第一版流程只接收表单、查重、分配负责人并通知，所有规则都可枚举，用 n8n 足够。第二版增加“根据公开信息起草跟进摘要”，模型只生成草稿，销售确认后才写回 CRM，Dify 或受控模型节点即可。第三版出现等待销售补充、外部查询失败后恢复、审批后继续等跨时状态，才值得用 LangGraph 表达 checkpoint 和中断。

即便到了第三版，也未必需要多 Agent。只有研究和审核确实使用不同数据、工具权限与停止标准，而且单图已经难以维护，才设计两个角色。每次升级都用同一批十条线索比较成功、人工退回、重复写入、步骤数和无法恢复次数。新增框架若只让流程图更漂亮，却没有减少一种明确失败，就退回上一层。

我的建议

把四个工具当成四级台阶，而不是四门并行课程。先交付一条可以审计的工作流；只有当它无法表达真实状态时，才进入代码框架。这样学到的不是 Agent 名词，而是何时值得让系统拥有更多自主权。

下一步用纸面先画出销售线索流程，标出唯一一个需要模型判断的节点和唯一一个必须人工批准的动作；画不出来，就暂时不要安装任何 Agent 框架。

开始前检查清单

写出唯一业务目标、允许读取的数据、允许执行的工具、必须审批的动作、最大步骤和终止状态。六项中任何一项空白，都先补流程设计，不进入框架安装。