全网最完整的 Agent 开发学习指南，一张图讲清楚

事情是这样的。

前段时间的一天晚上，我朋友突然问我说，如果他想转行到Agent开发，需要学什么。

先说他的情况，Java开发出身，之前做物联网方向，刚从公司提了离职。

觉得Java现在一片红海，太卷了，不想继续卷下去，想往AI方向靠拢。

刷了一段时间Boss直聘后，发现 Agent开发 这个岗位很适合他。

但这个岗位还太新了。

不像Java开发有一套完整的体系，从入门到精通，路线清清楚楚，Agent开发没有，他不知道要学什么才能转行成功。

我想了一下，说其实要学的不多，无非是RAG、Dify这类低工作流、RAG、MCP、多Agent智能体、提示词工程、LangChain和LangGraph 这类开发框架、模型部署和微调。

他说停，你在说啥，这些都是啥。

我说你先别急，来，我们一个个掰扯。

先说 RAG。

这个东西现在几乎每个企业都在聊，但很多人其实没搞明白它到底解决了什么问题。

讲个最简单的例子，你要做一个企业员工知识库，让员工可以问公司年假怎么算、报销流程是什么。

这些内部规则，通用模型不可能知道。

RAG 的作用就是在模型回答之前，先去你的知识库里匹配到对应的信息，然后把这条信息追加到对话上下文里。

这样模型就能基于你的业务知识来回答了。

再说 Coze 和 Dify 。

这是目前做 AI 应用最主要的两类工具，用来搭建多 Agent 协作和整个 AI 工作流。

但我的建议是，只学 Dify就可以了，学一个其他的很容易就会。

像 Coze、FastGPT、N8N 都是类似的东西。

只不过这几个适用场景不同，你得知道怎么选。

• 选 Coze ，可以最快、最简单地创建一个功能丰富的 AI 聊天机器人。
• 选 Dify，如果你需要在企业内部构建、管理和运维复杂、专业的 AI 应用。
• 选 FastGPT ，如果你的需求极度聚焦于知识库问答，希望一个轻量、专注、开箱即用的解决方案。
• 选 N8N ，如果你的核心需求是连接和自动化各种业务系统，AI 调用只是这个自动化流程中的一环。

我自己用下来，Dify 在企业场景里的掌控感确实更强一些。但不是说其他的不好，是看你到底要干什么，没有最好用的，只有最合适的。

说到LangChain 和 LangGraph 。

像我们上面说的Dify 其实是一个低代码平台。

但如果你不想依赖平台，而是要自己开发一个带有工作流的 AI 应用，这时最好的方法就是借助框架来完成。

比如 LangChain，就是链式的工作流开发。但这条链在方向上是单向的，不能向回流或者循环。

随着 AI 逐渐深入到业务，大家发现使用这种单向的链，有些应用搞不定，需要具备循环的功能。

这时就需要用图结构来表示业务了。

于是 LangChain 团队去年搞了一个扩展库，叫 LangGraph。

如果你看了我前天那篇文章。

想转 AI 产品经理？先别急着交钱，看完这篇再决定

就会发现这是跟 AI 产品经理 不同的一个点。

AI 产品经理一般是用 Dify 这类平台。而 Agent 开发可能采用的是 LangGraph 进行工作流开发。

但说真的，这两个不是非此即彼的关系。

Dify 让你快速上线，LangGraph 让你深度定制，你可以根据项目的不同阶段灵活选择，用Dify搭建MVP产品， LangGraph 做后续拓展迭代。

接下来说 多 Agent 协作。

这是为了解决单 Agent 上下文膨胀和工作范围不清晰的问题，让各个 Agent 的职责清晰单一，协作起来的效率会更高。

就像一个团队里，有人专门负责售前，有人专门负责售后，有人专门负责订单，各司其职，配合起来才顺畅。

我有时候觉得，多 Agent 的设计哲学跟 微服务架构 特别像。

Agent 就像一个独立的微服务，有明确的职责边界，通过接口进行通信。

之前做 Java 开发的同学，这块理解起来应该很快。

而可定制的领域Agent，这是 AI 能力的最终体现形式。

它不是零散的功能点，而是一系列面向业务目标、可自主执行任务的领域专用智能体。

比如商机转化Agent。

可以设计成这样：自动分析新线索、生成个性化跟进邮件，并创建后续任务分配至销售人员。这些智能体面向客户关系管理流程中的各个领域单独定制，企业也可以根据自身独特的销售方法论进行配置和调整。

这些就是Agent开发最终交付的产物之一。

工具调用这块， Function Call 和 MCP 。

这是为了解决接入企业目前的研发体系，支持调用企业正在运行的软件应用。不能只让AI说话，还要让AI能动手。

比如 AI 客服回答完用户问题之后，需要直接帮用户查订单状态、改收货地址、发起退款。

这些操作都要调用企业现有的系统。

Function Call 和 MCP 就是让 AI 能调用这些系统的手。

不管什么模型，只要支持 MCP，就能插上各种工具即用。

这个方向我觉得特别重要，因为企业不可能为了适配不同模型去重写一遍接口，这样可以让那些存量的业务接口都被接入进来。

还有就是提示词工程。

这块东西看起来简单，但真要深入下去，要学的也不少。

先说 ReAct。

ReAct 是 Reasoning and Acting 的缩写。

让大模型通过「观察、思考、行动」三个步骤，循环往复，能够自主决定使用一些工具去解决问题。

从代码层面来讲，本质是递归或者循环，递归结束的条件往往是超过次数限制、问题已经得到解决。

再说 Plan-and-Execute 。

跟 ReAct 相比，会先让大模型制定计划、步骤，也就是子任务，然后按照计划依次执行，中间可能会调整计划。

从一些测评集来看，ReAct 响应速度更快，消耗 token 量少。

但处理复杂任务的表现不及 Plan-and-Execute。

说实话，提示词工程这块入门很快，但要写出真正稳定、可复用的 Prompt，需要大量的实践和调优，我自己也同样还在摸索。

最后说部署和微调。

这块可能跟你之前想象的 Agent 开发不太一样，可能大家会以为是模型算法工程师的工作，但我觉得这是高阶Agent岗位的核心能力。

这个是为了解决企业项目的数据安全问题。对于通用的、非敏感的任务，调用外部领先的公有大模型以获取最佳性能。

对于处理企业核心、涉及特定业务逻辑的关键任务，比如客户流失预警、精准推荐，使用在企业私有数据上进行微调的私有模型或更小的领域专用模型。

这种策略在能力、安全、成本和可控性之间取得了最佳平衡。

私有化部署通常会采用 Ollama 加开源模型。

进阶可能会采用 AI 网关 Higress 加 Ollama 加 Docker 做高可用。

微调现在一般采用 LoRA 的形式。

它的核心思想是，在微调时不更新整个庞大的原始模型参数，而是注入并训练一组额外的、参数量极小的低秩矩阵，以此来让模型适应新任务。

这两个不算是 Agent 开发的常规要求。

但高阶一点的岗位会有这部分要求，所以这个还是需要学习了解一下的。

好了，基本上就是这些。

我朋友听完之后说，感觉没那么迷茫了。

我说其实要学的东西没有你想象的那么多。

关键是你得先动手，别光看教程。

去 Dify 上搭一个最简单的知识库问答，去 LangGraph 上跑一个多 Agent 协作的 demo 。

踩了坑，才知道哪里需要补。

我自己也是这样过来的。

有些东西你看着觉得难，真上手了反而觉得就那样。

有些东西你看着觉得简单，真做的时候才发现全是坑。

对了，最后为了方便大家理解，我整理了一张 Agent 开发转型路线图。

从 Java 到 Agent 开发，每一步该学什么，都标清楚了。

你可以把它当成一张地图。

不急着全看完。

先找到自己现在的位置，然后看下一步该往哪走。

遇到具体的问题，再回来对照着看该补哪块。

这样不会一下子被信息量淹没。

所以别慌，慢慢来。