最近好几个刚转行的朋友都在问我同一个问题："现在学 AI Agent，我应该先啃 LangChain 还是 Dify？"每次听到这种问法，我都想按住他们别急着找框架。AI Agent 这个方向确实热，网上铺天盖地的教程一上来就甩框架对比、架构图、部署演示，搞得好像不会用框架就做不了 Agent。但实际上，对新手和转行者来说，框架恰恰是你最不应该先碰的东西。你把 LangChain 的 API 背得滚瓜烂熟，可能过两个月它改版全都白费；你把 Dify 拖拽玩得飞起，遇到一个稍微刁钻的业务逻辑照样抓瞎。这篇文章我想认真聊聊：入门 AI Agent 到底该先学什么、怎么学，才会少走弯路，帮你在转行路上省下一大把时间。
1. 一开始就啃框架，三个坑你大概率躲不过
1.1 框架是简化工具，不是底层原理
我理解大家为什么急着学框架。LangChain 官网写得天花乱坠，上传几个文档，跑通一个 demo，感觉自己的工作就有了着落。但你需要分清楚一件事：框架解决的是"如何更快地搭建 Agent"，而不是"Agent 为什么能思考、能调用工具、能规划任务"。
打个比方，你学做菜，上来就研究某品牌智能炒菜机的所有功能按钮，肯德基的炸鸡流程你都倒背如流，但你不懂食材处理、火候控制、调味逻辑，换个灶台你还能做吗？框架就是把很多复杂的原理包装成"按钮"，你按了按钮发现菜熟了，但你不懂为什么熟，那换一种新框架、新场景，你连问题出在哪都说不清。
我记得有个朋友，花了两个周末把 LangChain 的核心类都看了一遍，用ConversationBufferMemory做了个聊天机器人，感觉入门了。结果改了一版模型，对话历史开始莫名其妙丢消息，他去 GitHub 提 issue，人家问用的什么模型、什么分词器、什么上下文长度，他全答不上来。这不是框架的问题，是你对底层机制没概念。
1.2 框架迭代快，追版本会让你筋疲力尽
稍微关注过 Agent 生态的人都知道，这一两年框架版本更新的速度有多夸张。LangChain 经常是大版本跳跃，小版本天天刷。今天教你用的LLMChain，明天可能就被标记为 deprecated（弃用），几个月后彻底移除。我见过有人写教程的时候还在用一个自定义 Agent class，教程发出去没两周，那个 API 就换了签名，评论区全在问怎么跑不通。
这种更新节奏对一个只想把它当"螺丝刀"使用的从业者来说，是巨大的时间消耗。你想想，你每天花三四个小时追 changelog、改代码适配新版本，真正用来理解业务、设计 Prompt、调整工具调用逻辑的时间还有多少？转行者本来就要追进度，把时间浪费在追框架版本上，性价比太低。
1.3 框架会锁住你的思路，让你只会"填空"
框架最隐蔽的坑，是它会悄悄限制你的思考方式。LangChain 给了你 Chain、Agent、Tool 这些概念，Dify 给了你工作流节点，CrewAI 给了你 Role、Task、Process——这些概念本身是有用的，但问题在于，你一旦只从这些概念出发去想问题，就很容易把 Agent 的设计套进框架的模子里。
我面试过一个转行者，简历上写熟练使用 LangChain，我把一个真实需求抛给他："用户想让我们 Agent 帮他做跨表格的财务核对，数据可能在 Excel 里，也可能在数据库里。"他全程想的都是管道、链、节点，最后憋出一句"用 LangChain 的 CSV Agent 加一个 SQL Agent 串起来应该可以"。但真正的问题是怎么拆解用户的意图、怎么安全地获取数据、核对结果的可信度怎么评估——这些框架给不了你，你得自己想清楚。
框架学太早，容易把"工具能力强"误当成"自己能力强"。
2. 先把大模型调通，这是 Agent 的地基
2.1 理解模型工作的基本机制：Token 与上下文
绕开框架，第一件必须搞明白的事是大模型本身的调用逻辑。尤其是 Token 和上下文，这俩概念搞不清楚，你后面做任何 Agent 都会踩坑。
你每次调用模型，输入和输出都会被转换成 Token。Token 可以粗略理解为"字/词/符号的片段"，中文场景下，一个 Token 大概对应 0.6 到 1.3 个汉字（取决于分词规则）。我记得之前有个内部工具，Prompt 里塞了一份两千多字的需求说明，加上系统提示词，一次请求就烧掉三千多 Token。你可能觉得一点不贵，但一个 Agent 往往要循环调用多次模型——比如先分析用户意图、再决定调用哪个工具、再根据工具结果生成回复——一个完整任务可能烧掉两三万 Token。
上下文长度（Context Window）就更重要了。模型不是记忆力无限的，超过上下文长度的历史对话会被截断，或者通过滑动窗口的方式丢掉早期信息。这就是很多人觉得"Agent 聊着聊着就失忆"的根本原因，不是你写的代码有 bug，是你没管理好上下文。
做 Agent 的时候，一个基本功就是学会"压缩"与"取舍"。你每次把什么内容放进 Prompt，把什么内容从历史里拿掉，把哪些工具结果完整保留、哪些只保留结论，这些都需要你用 Token 和上下文的意识去设计。
2.2 Prompt 工程能力，比任何框架都值得投资
我知道"Prompt 工程"这个词已经被说烂了，但对于做 Agent 的人来说，它确实是核心能力，且窗口期很长。框架可以换，模型可以换，但"怎么让模型准确理解你的意图、遵守你的约束、输出你需要的结构化内容"这件事，永远绕不开。
别把 Prompt 工程想得太玄，就三件事：**角色与目标设定、约束与格式要求、例子（few-shot）引导。**我见过最典型的不及格 Prompt 是这样的：
你是一个智能助手。请帮我查一下今天天气。
这个 Prompt 放在什么框架里都白搭。模型不知道你要查哪个城市，不知道你是想要温度还是降水概率，不知道输出格式是自然语言还是要塞进表格。专业的做法是明确边界、约定 JSON 输出、条件缺失时主动反问：
你是一个天气查询助手。用户提供城市和日期后，调用天气工具获取数据。 要求： - 如果用户没提供城市，必须直接告诉用户"请提供城市名" - 查询结果必须按 JSON 格式输出：{"city": "北京", "date": "2026-01-01", "weather": "晴", "temperature": "-2~8℃"} - 不要编造数据，工具未返回时，明确回答"查询失败"就这么一个简单的改进，跑出来的效果会有质的不同。Prompt 写得好，很多看似复杂的 Agent 功能根本不需要堆框架。
2.3 模型参数：temperature、max_tokens、stop，别用默认值走天下
新手很容易忽略模型请求里的参数。同样一个模型，temperature=0和temperature=1.5出来的结果是两个完全不同的东西。做 Agent 的时候，如果你希望模型稳定地输出 JSON 结构化数据、严格执行逻辑分支，temperature一定要调低，0 到 0.3 之间比较合适；如果你在做头脑风暴类工具，才需要调高。
还有其他几个参数你需要琢磨：
max_tokens：限制模型输出长度。不设置的话，模型可能一次性输出很长一段无关内容，浪费 Token 而且还拖慢响应。stop：指定模型停止生成的特殊字符串。比如你要求它输出一个特定结尾标记，可以用stop强制截断，避免它继续废话。top_p：很多同学只用 temperature，其实 top_p 也在影响输出的随机性。做 Agent 场景建议固定一个值就不要再变，变量越少越容易排查问题。
我建议你动手做一件事：用最原始的方式（curl 或者 Python requests）去调一次 OpenAI、DeepSeek、或者任何一个你选定的模型 API，把所有参数都打印出来、都试一遍，感受一下不同参数下模型输出的差别。这个体验比你看十篇框架教程都值钱。
3. 真正拉开差距的是"工具调用"，这是 Agent 的本质行为
3.1 从"聊天"到"干活"：Agent 凭什么比聊天机器人强
聊天机器人只会对话，Agent 的核心能力是"行动"。所谓行动，在目前的技术框架里，绝大多数情况就是指"调用工具"——查数据库、请求外部 API、执行代码、发邮件、操作文件。差别就在于：聊天机器人把你说的话变成回答，Agent 把你说的话变成动作。
理解这一点，你就理解了 Agent 到底在做什么。它本质上是一个"意图识别 + 决策 + 执行"的循环：模型判断你这句话想干嘛，决定要不要用工具、用哪个工具、参数怎么填，然后调用工具拿到结果，再把结果整理成回答给你。
这也是为什么很多只会玩聊天机器人的人转 Agent 会很不适应。你以前只研究"怎么让模型说出更漂亮的话"，现在要研究的是"怎么让模型干出准确的事"。
3.2 Function Calling 是绕不开的底层机制
目前主流模型（OpenAI 系、DeepSeek、Qwen 等）都支持 Function Calling（有的叫 Tool Use）。核心逻辑是：你在请求时给模型描述几个"可用的函数"，模型的输出不是直接回答你，而是先告诉你"需要调用哪个函数、参数是什么"，然后你来执行这个函数，把结果再喂给模型做下一步。
我给你画一个最简化的流程，你就懂了：
用户: "帮我查一下订单 T20240101 的状态" 你调用模型（附带工具定义）: - 工具1: get_order_status(order_id) - 工具2: send_email(to, content) 模型返回（不是答案，是想调用工具的信号）: - 调用 get_order_status(order_id="T20240101") 你的程序执行该工具，数据库返回 "已发货" 你把工具结果送回给模型: - 工具返回: "T20240101 已发货，物流公司：顺丰" - 模型基于此生成给用户的回答: "您的订单已发货，物流公司是顺丰。"所有 Agent 框架，本质上都是在帮你简化这个循环。但如果你不懂这个循环本身，你去看 LangChain 的 AgentExecutor 源码，只会觉得是一堆 Python 类的魔法。反过来，你懂了循环，再看框架文档，每个类、每个参数在干什么，一眼就明白。
3.3 动手定义你的第一个工具：从"读文件"开始
工具定义这件事非常容易上手，不需要会写复杂代码。我建议你第一个工具就做"读取本地文件内容"，再把结果交给模型去总结。
假设你用最简单的语言实现，伪代码如下：
import json def read_file_tool(path): with open(path, "r", encoding="utf-8") as f: return f.read() # 把工具定义传给模型的 tools 参数（以 OpenAI 格式为例） tools = [ { "type": "function", "function": { "name": "read_file_tool", "description": "读取本地文件的内容，参数为文件绝对路径", "parameters": { "type": "object", "properties": { "path": {"type": "string", "description": "文件路径"} }, "required": ["path"] } } } ]看到这里你会发现，工具定义的核心，就是你得让模型"读懂这个工具是干什么的、什么参数是合法的"。工具描述写得越清楚，模型选对工具的概率就越高。很多人工具调用老选错，不是模型笨，是你的工具描述含糊。
然后你再手动模拟一次完整循环：调用模型 -> 拿到 function call 请求 -> 你执行read_file_tool-> 把结果返回给模型 -> 模型生成总结。做完这个，你对 Agent 的底层循环已经比一大半抄框架的人都熟了。
4. 零依赖手写一个最小可用的 Agent
等你搞懂了上面的机制，你就会发现：实现一个简单 Agent，真的不需要框架。我建议你亲自动手写一个，就当是给自己打地基。
4.1 设计一个"任务规划小助手"：场景定义
我们做一个非常朴素但完整的 Agent："任务规划小助手"。功能如下：
- 用户输入一个模糊目标，比如"我想学三个月 Python 转行"
- Agent 需要拆解出逐步的规划
- Agent 支持调用工具：
add_todo_item(item)、save_plan_to_file(content, filename) - Agent 最终把规划保存到文件里
就这么简单的三个工具，足以覆盖"意图识别 -> 决策 -> 调用工具 -> 结果处理"的完整链路。
4.2 主循环代码解析：理解 Agent 的"大脑"逻辑
核心代码大概长这样（我用最容易懂的方式写）：
import json # 模型调用函数的占位：假设你接入任意一个兼容 OpenAI 的 API def call_llm(messages, tools=None): # 省略具体 API 细节，关键是传入 messages 和 tools # 返回一个对象，包含 content 字段和 tool_calls 字段 pass def add_todo_item(item): todo_list.append(item) return f"已添加任务: {item}" def save_plan_to_file(content, filename): with open(filename, "w", encoding="utf-8") as f: f.write(content) return f"规划已保存到 {filename}" messages = [{"role": "user", "content": "帮我把转行学 Python 的规划分成三个月，然后保存成文件"}] while True: response = call_llm(messages, tools=[add_todo_item, save_plan_to_file]) if response.get("tool_calls"): # Agent 决定调用工具了 messages.append(response) for tool_call in response["tool_calls"]: tool_name = tool_call["function"]["name"] args = json.loads(tool_call["function"]["arguments"]) # 执行工具 result = globals()[tool_name](**args) # 把工具结果带回对话 messages.append({ "role": "tool", "tool_call_id": tool_call["id"], "content": str(result) }) # 进入下一轮循环，让模型结合工具结果生成最终回复 continue else: # 模型没有调用工具，说明任务结束了 print(response["content"]) break这个循环就是框架里AgentExecutor/ReAct的底层骨架。你看完之后应该能明白：所有花里胡哨的 Agent 框架，核心不过是这样一个 while 循环 + 工具注册表 + 记忆管理。你亲手写完这一个循环，再去碰框架，会发现很多东西迎刃而解。
4.3 这个练习的真正价值：理解循环、异常与边界
很多人会问，这种手搓代码为什么不直接上框架？我这不是让你以后都手搓，而是让你在这个练习里获得三个重要认知：
第一，理解一次任务往往要多次调用模型。很多新手以为 Agent 就是"模型想一下然后输出答案"，实际上，一个工具调用完成后，你还得把结果喂回给模型，模型再决定下一步。没有这个循环认知，你会连 debug 都不知道从哪下手。
第二，学会避免死循环。如果模型反复调用同一个工具、参数还不变，你就得设置最大迭代次数，比如 10 次，到了就强制中止。这个在框架里一般有默认值，但你不知道默认值在哪，出问题时连配置都不会改。
第三，学会处理异常工具结果。文件不存在怎么办？API 超时怎么办？工具返回了脏数据怎么办？这些都要在你的代码里显式处理。自己写过一遍之后，你再去看框架的 error handling 机制，就不是看天书了。
5. 有了地基之后，再谈框架：LangChain、Dify、CrewAI 怎么选
5.1 什么时候你才真正需要框架
学到这里你可能会问：那框架到底有什么用？当然有用，而且在你项目复杂度上来之后，框架能省大量时间。但你需要先理解，框架给你节省的核心时间是"胶水代码"的编写时间，而不是设计时间。
具体来说，当你出现以下需求时，框架价值就体现出来了：
- 需要多种模型（OpenAI、Qwen、DeepSeek、国外开源模型）切换调用，不想自己写兼容层
- 需要管理大量历史对话、多轮工具调用状态，自己手写太容易出错
- 需要预设 Prompt 模板、统一的输出格式化、通用的错误处理
- 团队成员协作，需要一个统一抽象层，让大家好接手
如果只是个人单做一个简单自动化任务，你完全可以不用框架。我自己的很多工具就是简单函数 + API，根本不需要引入重量级依赖，维护还更省心。
5.2 三大框架的真实定位差异：一句话说清楚
等你决定学框架了，也别三个一起抓。它们的定位差异非常明显：
我不厌其烦地跟人推荐这个学习顺序：先把 LangChain 当应用开发工具用，理解它的核心抽象（Model、Prompt、Tool、Memory），再去看 Dify 这类低代码平台，最后才是 CrewAI 这种多 Agent 编排。
因为 LangChain 是"代码层"的抽象，它能帮你培养对 Agent 组件的认知；Dify 是"平台层"的抽象，适合快速演示，但拖拽界面对理解原理帮助不大；CrewAI 则建立在多 Agent 协作这个更复杂的话题之上，没有前两者打底，你很容易只会照着 demo 跑，一出问题就懵。
5.3 学框架的高效路径：别读文档，先拆 demo
最后给一点学框架的实操建议：不要从头到尾读官方文档，那是效率最低的方式。正确的做法是：
先找一个官方 demo（比如一个带工具调用的最小示例），跑通它。跑通之后，不要满足于"它能运行"。你要做的是把这个 demo 拆开，回答三个问题：这个 Agent 的循环在哪里？工具是如何注册和被调用的？上下文是如何存取的？如果回答不了，就加断点或者打印日志，一行一行看它是怎么调用模型的。
做完这一步，你再去读文档，重点只读你用到的部分，别贪多。你在前面手写最小 Agent 的时候打下的基础，在这里就会变成你的加速器——你看框架文档每个类都似曾相识，两天就能上手。
6. 给新手和转行者的学习路线图与避坑清单
6.1 清晰的学习时间分配：4 周从零到面试能讲
我把这条路线的起步时间预设为 4 周，每天有效学习时间 3 小时，按顺序学。别跳步，前面欠的债后面都要还。
第 1 周：大模型 API 调用与 Prompt 基础
- 用原始 API 调通一个模型，理解 messages（system/user/assistant）的交互方式
- 练习写结构化的 Prompt，强制模型输出 JSON，学会用参数控制输出
- 了解 Token 计费与上下文长度限制，做一个简单消费估算
第 2 周：工具调用与最小循环
- 学会定义 3 个不同的工具（读文件、查时间、算数学）
- 手动实现一个工具调用循环，跑通"用户提问 -> 模型选择工具 -> 函数执行 -> 模型总结"
- 试试同一个循环换不同的模型跑，对比工具选择准确率
第 3 周：自己设计一个场景型 Agent
- 选一个你熟悉的业务场景，比如周报助手、客服工单分类、简历筛选
- 不带任何框架，纯 API 实现一版，必须有至少 2 个工具
- 添加记忆功能（简单地把历史对话拼接进 messages 即可）
第 4 周：再学框架，做对比
- 把你第 3 周做的 Agent 用 LangChain 重写一遍
- 对比两种实现方式的代码量、维护成本、扩展性
- 了解 Dify 或同类平台的拖拽配置，知道它的边界在哪
这个路线走完之后，你面试、接活、做产品，都有了最基本但也最扎实的底子。后续深入什么方向（多 Agent 协作、RAG、长时记忆），你都有了"土壤"去吸收。
6.2 常见翻车现场：我见过的高频错误
我把这几年看人翻车的典型情况汇总成了一张表，你对照着自查：
| 翻车现象 | 根本原因 | 正确做法 |
|---|---|---|
| Agent 反复调用同一个工具不停止 | 没有设置最大迭代次数 | 循环内加计数器，超过 5-10 次强制中断 |
| 工具返回了错误格式，模型开始胡说 | 没有校验工具返回结果 | 工具结果先清洗、校验，再喂给模型 |
| 上下文爆炸，后面几轮模型开始"失忆" | 没有管理历史长度 | 设置滑动窗口，只保留最近 N 轮关键信息 |
| 模型选错工具 | 工具定义描述含糊 | 明确每个工具的适用场景，必要时加例子 |
| Prompt 里塞了大段背景资料，效果反而变差 | 信息过载干扰判断 | 只保留与当前任务强相关的上下文 |
| 测试环境好的，一上生产就崩 | 没有做异常兜底 | 每个工具调用都要 try/except，失败要有降级方案 |
这几条不是让你背下来的，是让你在实操中体会的。你每条都踩过一次，才真的明白为什么会有这些坑。
6.3 心态与预期：转行没有捷径，但有正确的慢
最后说几句掏心窝子的。AI Agent 这个方向，入门三个月可以做出一堆 demo，但"能做 demo"和"能做可用系统"之间，隔着大量工程细节。我见过太多转行者，前两周冲劲很猛，学了一堆框架名词，结果遇到第一个环境配置问题就卡住了。反而是那些愿意花时间先搞懂模型调用、工具循环、Prompt 设计的人，后面跑起来越来越快。
做 Agent 和做传统软件开发的差异在于：Agent 的行为不是完全确定的，你需要学会在处理不确定性中建立安全边界。这个能力没法靠某个框架帮你补齐，只能靠你自己一点点试错获得。
最后再分享一个我自己的经验：面试转行者的时候，我从来不问他会不会 LangChain，我会让他现场讲讲怎么把一个大模型 API 调通，然后定义一个工具让他调。这个小小的测试，基本就能看出来他是真懂还是只会抄框架。我希望看完这篇文章的你，能成为前者。先把地基打好，再去学框架，你会发现在这个快速变动的领域里，所谓的"慢"，反而是真正的快。
