前些天又在技术群里看到有人问：AI Agent 入门，LangChain 和 Dify 怎么选？底下回复吵成一团，有人力推 LangChain，有人说现在该学 Dify 了，还有人冒出来安利 CrewAI。我问了一句"你现在想做什么"，对方半天没答上来，只说了句"就想入门"。是不是很耳熟？类似的提问我这两年见了太多次，几乎每个新入行的朋友都会经历这个阶段。

我在这个方向折腾了两年多，从最早拿 LangChain 跑 demo，到后来嫌它太绕、自己裸写 Agent，再到现在工作中框架和原生代码混着用。回头看带过的几个新手和转行者，我得出一句话总结：AI Agent 入门最大的敌人不是难度，而是"框架焦虑"。很多人不是学不会，是太急着学框架，把本该用来打基础的时间全花在了工具选择上。

这篇文章就是给所有正准备入坑 Agent 的人——不管是零基础转行，还是做后端、前端、测试想切过来——梳理一条我验证过多次的路径。核心观点很直接：先别碰框架，先把 Agent 的四块核心机制吃透，用原生代码把流程跑通，之后框架只是锦上添花。文章里的代码你都可以直接抄走改着玩，步骤也是按新手节奏设计的。

1. 框架包围的假象：为什么你会在 LangChain 和 Dify 之间纠结

1.1 看看大家在搜什么，就知道焦虑有多重

我翻了一下最近围绕 Agent 的热搜词，满满都是"agent框架""rag框架""智能体框架opencode""agent框架与编排"。还有人搜"mobile6安装谷歌框架""输入法框架""xposed框架路径"——这已经不完全是冲 Agent 来的了，说明很多人的心态是：听说 Agent 火了，先搜搜有什么框架装上再说。

这种心态特别正常，两年前我自己也一样，觉得先找个框架照着抄就行。但真动手之后才发现，框架这层壳子早晚会把人绕晕。原因是框架解决的是"工程组织问题"，它把 Agent 系统该有的代码结构、连接方式都提前安排好了。可如果你对 Agent 内部发生的机制没有概念，你写出来的东西大概率是"跑得起来，但一改就崩"。

1.2 框架是智能锅，不是烹饪课

我打过一个比方：你学做饭，上来先买一堆多功能智能锅，炖、炒、蒸、煮各种模式都有。锅确实好用，但你连"火候""收汁""断生"这些概念都没有，按按钮做出来的菜味道不对时，你根本不知道问题出在哪个环节，只会觉得锅坏了。

框架也一样。LangChain 把一个流程抽象成 Chain、Agent、Tool、Memory 这些概念，你照着文档拼积木，好像挺顺利。但有一天你的 Agent 在真实场景里开始胡说八道，你要排查——是检索有问题？是 Prompt 构造有问题？是工具返回格式不对？如果你不知道这些环节底层分别是怎么工作的，排查起来就是灾难。这种事我在生产环境里见过太多次了，最后救场的永远是底层原理，不是框架文档。

这里我要强调一个实用判断：出问题的时候，框架文档不一定会帮你，但你对底层机制的理解一定能帮到你。所以入门阶段，把"理解底层"放在"使用框架"前面，是性价比最高的事。

1.3 先回答三个问题，再决定学什么

在打开任何框架文档之前，我建议你先自测三个问题：

1. Agent 和普通聊天机器人的本质区别是什么？
2. 一次完整的 Agent 任务，从收到用户请求到返回结果，中间经过了哪几个环节？
3. 你如何判断一次 LLM 返回是好是坏？如果它不按你的要求输出，你第一步会查什么？

如果你能脱口而出，直接学框架没问题。如果卡壳了，说明地基还没打牢——这时候学框架，相当于在沙滩上盖楼。

提示：这三个问题不是我编出来吓唬人的，而是实际面试和项目分工时最常碰到的判断标准。能把它们讲清楚的人，学任何框架都快。

2. 先别碰框架：把 Agent 的四个核心机制吃透

2.1 模型层：LLM 是大脑，但大脑不等于 Agent

很多人把"调一次 LLM API"当成 Agent 的全部。严格来说，那只是 Agent 的第一步。

Agent 的第一块拼图是模型调用，也就是你把系统提示词（System Prompt）和用户请求一起发给 LLM，让它生成回答。这一步有三个关键点：

• 模型选择：不同模型在推理、指令跟随、工具调用上的能力差异很大。GPT 系和 Claude 系各有擅长的场景，国内模型也在快速追上来。
• Prompt 质量：同样的任务，Prompt 结构不同，结果可能天差地别。系统提示词写得好，Agent 就像有个明白人盯着它干活。
• 参数调整：temperature 控制随机性，max_tokens 控制输出长度，top_p 影响采样范围。这些参数不理解，调优时就是瞎蒙。

但如果你只有这一块，你得到的只是一个聊天机器人，不是 Agent。因为聊天机器人不会主动查数据、不会调用工具、不会自己拆解任务，它只是"根据已知内容生成回答"。这也是为什么很多初学者做了个带 API 的聊天机器人，就声称自己"会 Agent 了"——这个定位从根上就有偏差。

2.2 规划层：从"直接回答"到"拆解执行"

Agent 和 Chatbot 的核心区别之一，在于它能把复杂任务拆成多个步骤，再按顺序执行。

举个例子。用户问："帮我对比北京和上海最近三天的天气，哪个更适合户外跑步？"

聊天机器人大概率只能凭训练数据给个模糊回答，或者告诉你"我无法查询实时天气"。Agent 则会：

1. 判断需要两个城市的天气数据。
2. 调用天气工具分别获取北京、上海未来三天天气。
3. 按温度、降雨、风力等维度做对比。
4. 结合用户关心的"跑步"场景给出建议。

这个"拆解—执行—汇总"的过程，就是规划层干的事。业界常见的实现方式是让 LLM 自己生成下一步动作，形成 ReAct（Reasoning + Acting）循环：模型先思考，再决定调用什么工具，拿到执行结果后再思考，再决定下一步。在框架里，这段逻辑通常被封装成 AgentExecutor 之类的组件；但入门阶段，我强烈建议你跟着手写版 ReAct 循环走一遍，后面第三部分会给出代码。

2.3 工具调用层：Function Calling 是分水岭

如果说规划和感知是 Agent 的"思维"，那工具调用就是 Agent 的"手脚"。

现代 LLM API 基本都支持 Function Calling。简单理解：你在请求里声明一组工具（名字、描述、参数结构），模型在回答时不是直接输出最终答案，而是输出"它想调用哪个工具、参数是什么"，再由你的代码执行这个工具，把结果喂回给模型。

这个机制的意义非常大。它让 Agent 不再是"语言模型"，而是"能干活的系统"。查数据库、发 HTTP 请求、跑本地脚本、操作浏览器，全都能挂上来。

这里有个新手常踩的坑：工具描述写得太敷衍。Function Calling 的准确率，很大程度取决于你给模型的工具说明是否清晰。你写"查天气"，模型可能乱传参；你写清楚"根据城市名查询实时天气，city 参数必须是标准中文城市名，比如'北京'"，准确率立刻上一个台阶。我在项目里见过太多因为工具描述模糊导致 Agent 反复调用错参数的例子，这个问题在所有框架里都存在，必须在底层阶段就养成好习惯。

2.4 记忆层：上下文长度不等于记忆

最后一块是记忆。

很多新手以为 LLM 的上下文窗口大就等于有记忆。其实不是。上下文只是"这次请求里你能塞进去多少字"，记忆是"在多轮对话和多次任务中，怎么保留和检索有用信息"。这两个概念混淆，后面做 RAG 时一定会走弯路。

我习惯把记忆分成两层：

• 短期记忆：当前对话的 messages 历史，直接放上下文里，但要注意控制长度，别把整个聊天记录无脑塞进去。常用的做法是只保留最近 N 轮，或者对旧消息做摘要压缩。
• 长期记忆：跨会话的有用信息，比如用户偏好、历史结论、项目状态。通常存到数据库或向量库，需要时检索出来塞回上下文。

框架受欢迎，很大程度是因为它把历史管理、向量检索这些工程细节封装好了。但如果你不理解"为什么需要记忆""什么时候该用向量检索""什么时候直接查数据库更快"，用起来就会出问题。我在实际调试中见过不少把 RAG 用错的案例，根源就是对记忆和检索的理解只停留在概念层，一遇到"召回结果不准""回答前后矛盾"就完全不知道从哪下手。

3. 用原生代码把 Agent 跑通：一个能查天气的极简实现

3.1 最小骨架：直接调用 LLM API

概念说再多，不如直接跑代码。前提是你有一个 LLM API 的 Key，国内外的模型大多兼容 OpenAI 格式。先装 Python 包：

pip install openai

然后写一个最基础的调用：

from openai import OpenAI client = OpenAI(api_key="sk-xxx", base_url="https://api.openai.com/v1") response = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": "你是一个天气助手，只能根据已有信息回答。"}, {"role": "user", "content": "北京今天适合穿什么？"} ] ) print(response.choices[0].message.content)

这个脚本跑通，你就完成了"模型调用"这一层的练习。但你也看到了：它什么都做不了，因为模型根本不知道今天的天气。接下来需要给它"手脚"。

3.2 关键一步：让模型"看到"工具

接着定义工具，让模型知道它可以调用一个天气查询函数：

tools = [ { "type": "function", "function": { "name": "get_weather", "description": "查询指定城市的当天天气，city 参数请填写完整中文城市名，如'北京'", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名"} }, "required": ["city"] } } } ]

然后发一次带工具的请求，注意看返回内容：

response = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": "你是一个天气助手。如果需要查询天气，请调用工具。"}, {"role": "user", "content": "北京今天适合穿什么？"} ], tools=tools, tool_choice="auto" ) print(response.choices[0].message.model_dump())

你会发现返回里多了一个 tool_calls 字段，模型的回复变成了"我要调用 get_weather，参数是 {'city': '北京'}"。到这一步，模型完成了"决策"，剩下的事情交给你的代码去执行。这就是 Function Calling 的本质——模型不执行工具，它只是告诉你该执行哪个工具、用什么参数。

3.3 手写一个极简 ReAct 循环

下面把整个流程串起来。核心是一个循环：把模型返回的 tool_calls 执行掉，把执行结果以 tool 角色的消息放回对话里，再让模型继续决策。这个循环是所有 Agent 框架的地基：

import json from openai import OpenAI client = OpenAI(api_key="sk-xxx", base_url="https://api.openai.com/v1") def mock_query_weather(city): """演示用的假天气数据，实际项目请换成真实天气 API。""" return {"city": city, "date": "2025-06-01", "weather": "晴", "temp_high": 28, "temp_low": 18} def run_agent(user_input): messages = [ {"role": "system", "content": "你是一个天气助手，需要查询天气时调用工具。"}, {"role": "user", "content": user_input} ] max_steps = 3 for step in range(max_steps): response = client.chat.completions.create( model="gpt-4o-mini", messages=messages, tools=tools, tool_choice="auto" ) msg = response.choices[0].message messages.append(msg) # 模型没有要求调用工具，说明已经可以直接回答 if not msg.tool_calls: return msg.content # 执行所有工具调用，结果回填给模型 for tc in msg.tool_calls: print(f"[step {step+1}] 调用工具: {tc.function.name}, 参数: {tc.function.arguments}") if tc.function.name == "get_weather": args = json.loads(tc.function.arguments) result = mock_query_weather(args["city"]) messages.append({ "role": "tool", "tool_call_id": tc.id, "content": json.dumps(result, ensure_ascii=False) }) return "超过了最大步骤数，任务中止" print(run_agent("北京今天适合穿什么？"))

这个循环只有二三十行，但它已经包含了 Agent 最核心的骨架：模型决策、工具执行、结果回填、再次决策。你可以在这个脚本上继续加工具、加历史、加约束，就能演化出更复杂的 Agent。我到现在做生产级项目，用的依然是这个模式的加强版。

3.4 这一步练的是什么

有人会问：直接上 LangChain，不也是这个流程吗？是，但有本质区别：

• 用框架，你会花大量时间学 Chain 怎么串、Agent 怎么配置、memory 怎么接——这些是框架自己的概念，换个框架就废。
• 裸写，你只围绕"模型、消息、工具、循环"四样东西打转，全部是 LLM API 原生技能，换哪个框架都不过时。

等你裸写跑通之后再回头看，会发现框架里的很多名词，不过是对这套流程的封装。这时候学框架，完全不是一个体验——你不是在背文档，而是在理解"哦，原来这个参数控制的就是我循环里的那一步"。我见过太多人倒着走，先框架后原理，结果就是在各种"黑盒报错"里反复挣扎。

4. 框架什么时候学：我的判断标准和选型经验

4.1 先满足三个"前置条件"

按我带人的经验，至少满足下面三个条件再去学框架，效率是最高的：

一是能用原生代码跑通一个带工具调用的小 Agent。不用很复杂，能查天气、能查数据库都行。这意味着你对模型调用、Function Calling、消息结构有了切身体验，而不是停留在概念上。

二是踩过至少一次"为什么模型一直不调用工具"或者"为什么上下文越跑越长"的坑。踩坑不是坏事，踩过一次，你才真正知道框架封装了什么、帮你省了什么。

三是有明确的落地场景。比如想做"自动处理小红书评论的机器人"，或者"根据商品信息自动生成文案的工具"。这种具体目标会直接决定你选哪个框架，而不是先选框架再想做什么。

4.2 主流框架到底帮你省了什么

我快速梳理一下目前最主流的几个方向，帮大家建立一个不焦虑的认知框架。

这三个不是"谁替代谁"的关系。LangChain 更像一套积木，Dify 更像装修好的房子，CrewAI 专门处理"多个 Agent 怎么分工合作"。很多人把它们放一起比，本身就是方向错了。

这里我要特别提醒一点：不管选哪个框架，你都需要先清楚"我的 Agent 要调用什么工具、流程分几步、处理什么输入输出"。这个能力不是框架给的，是你自己必须先有的。有些人指望 Dify 这种可视化平台能帮自己绕过理解，最后做出来的工作流全靠直觉拖动，一旦出错根本不知道哪里断了。

4.3 选框架的几条实用准则

结合自己的项目经历，给你几条实在的判断标准：

第一，看你愿不愿意写代码。愿意写，LangChain/LangGraph 这类开发框架会更灵活；不想写太多配置，Dify 这类平台可以先把业务跑通。没有谁更高端，只有合不合适。

第二，看项目规模。做个 demo，Dify 十分钟能拉出一个工作流；但要上生产、做深度定制、应对高并发场景，代码型框架的掌控力会强得多。

第三，框架的稳定性和社区活跃度，比"新""炫"重要得多。我见过不少朋友追着最新框架跑，结果文档不全、生态不成熟、更新频繁变动，两周时间全耗在踩坑上。一个文档完善、社区人多、更新稳定的框架，才是真正省时间的框架。

第四，也是我认为最重要的一条：框架可以换，但你对"用户需求—Agent 流程—工具设计"的判断能力才是核心资产。我有个同事做了三个项目，用了三个不同框架，最后发现自己能带走的东西里，框架占比非常小，真正值钱的是对业务的理解和排查问题的思路。

提示：判断一个框架是否值得深入，我会先看两个东西——它的 GitHub 活跃度和 issue 响应速度。框架再炫，维护跟不上，生产环境里就是定时炸弹。

5. 转行者专属：90 天学习路线和最容易踩的坑

5.1 三个月的具体安排

如果你是从其他方向转过来的，或者零基础但每天能挤出几个小时，我建议按下面的节奏走。这是一条我自己带人验证过的路线，节奏不算快，但每一步都扎实。

第 1~2 周：过一遍 Python 基础。不需要学到精通，能写函数、能调 API、能处理 JSON、能理解循环和异常处理就够了。这些都是 Agent 开发的地基。别花一整月去啃语法书，边做边补效率更高。

第 3~4 周：专注搞懂 LLM API 本身。不管用哪个模型，把官方文档里的 Chat Completion 和 Function Calling 部分看透。自己写几个小脚本：让 LLM 做翻译、做摘要、做结构化输出。这个阶段的目标是熟悉"消息结构"和"返回格式"。

第 5~6 周：自己实现一个带工具调用的极简 Agent，就按我前面第三节的代码来。然后把工具从"查天气"换成查数据库、查文件、查外部 API，多换几种场景练手。换场景的目的是让你理解工具和流程是可以自由组合的。

第 7~8 周：学一点 RAG 和记忆。理解向量检索是什么、什么时候该用、和直接查数据库有什么区别。这里不需要啃论文，把概念和简单实现跑通就行。重点搞明白：为什么不把所有数据都塞进上下文？向量检索到底解决了什么问题？

第 9~12 周：选一个框架正式做项目。这时候你已经有底层认知了，框架学习会非常快——你只是在学别人的封装方式，而不是在学概念。完成一个小的完整应用，比如自动整理 RSS 信息的助手、帮你在多个数据源里找答案的小工具。

5.2 转行者最容易犯的四个错

我看了不少新人的学习记录和代码，几类错误反复出现，在这里集中排一下雷。

一是贪多。今天听说 LangChain 好就学 LangChain，明天听说 Dify 好用又去玩 Dify，后天看到 RAG 火了立刻开始看向量库。三个月下来什么都碰过，什么都不深入，简历上只能写"了解"。解决办法是认准一个主线，至少做完一个完整项目再横向扩展。

二是不动手只看视频。看教程和实际调试是两回事。代码贴下来跑通，和自己在报错中定位问题，差距非常大。我建议每个环节都亲手敲一遍代码，并且故意改错几次——见过报错是什么样，以后遇到才不会慌。

三是忽略工具设计。很多刚上手的人把 Agent 想得太玄，却连"工具描述写清楚"这种基本功都没做好。工具定义质量差，Agent 的表现直接打折。这个基本功在裸写阶段练好，框架阶段会受益无穷。

四是不记录调试日志。Agent 的排查比普通程序难，因为中间有模型"自由发挥"，输出不稳定。我建议从第一天起就养成记录日志的习惯，把每次请求的消息结构、模型输出、工具结果都存下来。真正排错的时候，这些日志比任何文档都有用。

5.3 项目练手方向

最后给不知道做什么的读者几个具体方向。练手的原则是：小、实在、能用真实数据。越具体越好，不然很容易做着做着就放弃。

• 公众号/小红书文案助手：给一段素材，Agent 帮你总结、扩写、生成标题。
• 个人知识库问答：把文档存进向量库，Agent 根据问题检索再回答，顺便练 RAG。
• 搜索增强工具：Agent 接到问题先调用搜索 API，再结合结果回答。
• 自动化信息整理：每天定时抓取某个方向的资讯，Agent 自动筛选并生成摘要。

不要一上来就做"通用助手"或者"全能机器人"。目标越具体，你越容易判断做得好不好，也越容易在完成中获得正反馈。这个正反馈对转行者来说特别重要，因为它能支撑你熬过前面两个月的"平淡期"——说实话，前两个月确实没什么炫酷成果，但地基就是那时候打下的。

写到最后，分享一点我自己的体会。我带过的新手里，动手早的那批，现在基本都能独立做 Agent 相关的项目了；反而是那些一直想"先学清楚再动手"的人，到现在还在收藏各种教程。入门 Agent 这件事，关键真不在框架，也不在天赋，而在于你有没有尽快把"模型、工具、循环"这条最原始链路跑通。

如果你看这篇文章只带走一件事，那就是：先花两周时间把三五十行原生代码跑通，再谈框架。这条路我替你们走过了，走得通。