★ FEATURED ARTICLE 前些天又在技术群里看到有人问AI Agent 入门LangChain 和 Dify 怎么选底下回复吵成一团有人力推 LangChain有人说现在该学 Dify 了还有人冒出来安利 CrewAI。我问了一句你现在想做什么对方半天没答上来只说了句就想入门。是不是很耳熟类似的提问我这两年见了太多次几乎每个新入行的朋友都会经历这个阶段。我在这个方向折腾了两年多从最早拿 LangChain 跑 demo到后来嫌它太绕、自己裸写 Agent再到现在工作中框架和原生代码混着用。回头看带过的几个新手和转行者我得出一句话总结AI Agent 入门最大的敌人不是难度而是框架焦虑。很多人不是学不会是太急着学框架把本该用来打基础的时间全花在了工具选择上。这篇文章就是给所有正准备入坑 Agent 的人——不管是零基础转行还是做后端、前端、测试想切过来——梳理一条我验证过多次的路径。核心观点很直接先别碰框架先把 Agent 的四块核心机制吃透用原生代码把流程跑通之后框架只是锦上添花。文章里的代码你都可以直接抄走改着玩步骤也是按新手节奏设计的。1. 框架包围的假象为什么你会在 LangChain 和 Dify 之间纠结1.1 看看大家在搜什么就知道焦虑有多重我翻了一下最近围绕 Agent 的热搜词满满都是agent框架rag框架智能体框架opencodeagent框架与编排。还有人搜mobile6安装谷歌框架输入法框架xposed框架路径——这已经不完全是冲 Agent 来的了说明很多人的心态是听说 Agent 火了先搜搜有什么框架装上再说。这种心态特别正常两年前我自己也一样觉得先找个框架照着抄就行。但真动手之后才发现框架这层壳子早晚会把人绕晕。原因是框架解决的是工程组织问题它把 Agent 系统该有的代码结构、连接方式都提前安排好了。可如果你对 Agent 内部发生的机制没有概念你写出来的东西大概率是跑得起来但一改就崩。1.2 框架是智能锅不是烹饪课我打过一个比方你学做饭上来先买一堆多功能智能锅炖、炒、蒸、煮各种模式都有。锅确实好用但你连火候收汁断生这些概念都没有按按钮做出来的菜味道不对时你根本不知道问题出在哪个环节只会觉得锅坏了。框架也一样。LangChain 把一个流程抽象成 Chain、Agent、Tool、Memory 这些概念你照着文档拼积木好像挺顺利。但有一天你的 Agent 在真实场景里开始胡说八道你要排查——是检索有问题是 Prompt 构造有问题是工具返回格式不对如果你不知道这些环节底层分别是怎么工作的排查起来就是灾难。这种事我在生产环境里见过太多次了最后救场的永远是底层原理不是框架文档。这里我要强调一个实用判断出问题的时候框架文档不一定会帮你但你对底层机制的理解一定能帮到你。所以入门阶段把理解底层放在使用框架前面是性价比最高的事。1.3 先回答三个问题再决定学什么在打开任何框架文档之前我建议你先自测三个问题Agent 和普通聊天机器人的本质区别是什么一次完整的 Agent 任务从收到用户请求到返回结果中间经过了哪几个环节你如何判断一次 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 则会判断需要两个城市的天气数据。调用天气工具分别获取北京、上海未来三天天气。按温度、降雨、风力等维度做对比。结合用户关心的跑步场景给出建议。这个拆解—执行—汇总的过程就是规划层干的事。业界常见的实现方式是让 LLM 自己生成下一步动作形成 ReActReasoning 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_keysk-xxx, base_urlhttps://api.openai.com/v1) response client.chat.completions.create( modelgpt-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( modelgpt-4o-mini, messages[ {role: system, content: 你是一个天气助手。如果需要查询天气请调用工具。}, {role: user, content: 北京今天适合穿什么} ], toolstools, tool_choiceauto ) 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_keysk-xxx, base_urlhttps://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( modelgpt-4o-mini, messagesmessages, toolstools, tool_choiceauto ) 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 {step1}] 调用工具: {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_asciiFalse) }) return 超过了最大步骤数任务中止 print(run_agent(北京今天适合穿什么))这个循环只有二三十行但它已经包含了 Agent 最核心的骨架模型决策、工具执行、结果回填、再次决策。你可以在这个脚本上继续加工具、加历史、加约束就能演化出更复杂的 Agent。我到现在做生产级项目用的依然是这个模式的加强版。3.4 这一步练的是什么有人会问直接上 LangChain不也是这个流程吗是但有本质区别用框架你会花大量时间学 Chain 怎么串、Agent 怎么配置、memory 怎么接——这些是框架自己的概念换个框架就废。裸写你只围绕模型、消息、工具、循环四样东西打转全部是 LLM API 原生技能换哪个框架都不过时。等你裸写跑通之后再回头看会发现框架里的很多名词不过是对这套流程的封装。这时候学框架完全不是一个体验——你不是在背文档而是在理解哦原来这个参数控制的就是我循环里的那一步。我见过太多人倒着走先框架后原理结果就是在各种黑盒报错里反复挣扎。4. 框架什么时候学我的判断标准和选型经验4.1 先满足三个前置条件按我带人的经验至少满足下面三个条件再去学框架效率是最高的一是能用原生代码跑通一个带工具调用的小 Agent。不用很复杂能查天气、能查数据库都行。这意味着你对模型调用、Function Calling、消息结构有了切身体验而不是停留在概念上。二是踩过至少一次为什么模型一直不调用工具或者为什么上下文越跑越长的坑。踩坑不是坏事踩过一次你才真正知道框架封装了什么、帮你省了什么。三是有明确的落地场景。比如想做自动处理小红书评论的机器人或者根据商品信息自动生成文案的工具。这种具体目标会直接决定你选哪个框架而不是先选框架再想做什么。4.2 主流框架到底帮你省了什么我快速梳理一下目前最主流的几个方向帮大家建立一个不焦虑的认知框架。框架定位帮你解决的核心问题最适合的人群/场景LangChain / LangGraph代码型开发框架对话流程编排、工具接入、状态管理需要写代码做深度定制的开发者Dify可视化应用平台数据集管理、工作流编排、应用发布想快速搭应用的非纯技术人员CrewAI多 Agent 协作框架多角色分工、任务委派研究多 Agent 协同、复杂任务拆分的场景这三个不是谁替代谁的关系。LangChain 更像一套积木Dify 更像装修好的房子CrewAI 专门处理多个 Agent 怎么分工合作。很多人把它们放一起比本身就是方向错了。这里我要特别提醒一点不管选哪个框架你都需要先清楚我的 Agent 要调用什么工具、流程分几步、处理什么输入输出。这个能力不是框架给的是你自己必须先有的。有些人指望 Dify 这种可视化平台能帮自己绕过理解最后做出来的工作流全靠直觉拖动一旦出错根本不知道哪里断了。4.3 选框架的几条实用准则结合自己的项目经历给你几条实在的判断标准第一看你愿不愿意写代码。愿意写LangChain/LangGraph 这类开发框架会更灵活不想写太多配置Dify 这类平台可以先把业务跑通。没有谁更高端只有合不合适。第二看项目规模。做个 demoDify 十分钟能拉出一个工作流但要上生产、做深度定制、应对高并发场景代码型框架的掌控力会强得多。第三框架的稳定性和社区活跃度比新炫重要得多。我见过不少朋友追着最新框架跑结果文档不全、生态不成熟、更新频繁变动两周时间全耗在踩坑上。一个文档完善、社区人多、更新稳定的框架才是真正省时间的框架。第四也是我认为最重要的一条框架可以换但你对用户需求—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 这件事关键真不在框架也不在天赋而在于你有没有尽快把模型、工具、循环这条最原始链路跑通。如果你看这篇文章只带走一件事那就是先花两周时间把三五十行原生代码跑通再谈框架。这条路我替你们走过了走得通。
阅读完成 · 觉得有帮助？
