说实话这两年被 AI Agent 吸引进来的人太多了。我经常收到一类私信开头基本是“想转行做 AI Agent要不要先学 LangChain还是直接上 Dify”每次看到这种问题我都想按住对方的肩膀——兄弟方向反了。AI Agent 入门最大的坑不是学不会某个框架而是你还没弄明白 Agent 到底是什么就先一头扎进了框架的汪洋。等你被各种 Chain、Memory、Tool 的抽象概念淹得喘不过气信心也就磨没了。关于 AI Agent 入门先学什么这件事其实答案很简单先学概念和原理再用最小代码亲手跑通一个 Agent最后才轮到框架。这篇不打算推荐任何“神器框架”而是想跟你聊聊一个绕开弯路的学习思路以及我实际踩过的坑。1. 先分清框架是工程工具不是概念教材1.1 新手最常见的翻车路径我见过太多人按同一条路线“入坑”打开 LangChain 官方文档跟着保姆级教程跑通了一个 demo发现能跑但完全不知道它为什么能跑。接下来想改点东西比如让 Agent 换个工具、改个提示词立刻崩溃。也有人反过来去用 Dify 这类可视化平台拖拖拽拽搭了个工作流确实很方便但一脱离拖拽界面就什么都不会做了。这是典型的“工具驱动学习”带来的问题。框架看起来是学习和上手的捷径但本质上它是一套封装好的工程化组件。它假设你已经理解了 Agent 的基本运行逻辑然后帮你省掉大量重复代码。如果你连底层逻辑都不清楚那框架对你来说就是个黑盒。里面某个环节出问题你连报错信息都看不懂更别说定位问题。还有个更隐蔽的坑主流框架迭代极快。LangChain 早期版本和后期的 API 变化非常大网上教程有一大半已经过期。新手照着旧教程写代码经常会碰到“这个模块不存在”“参数名变了”之类的错误。这时候你会怀疑人生是不是自己太笨其实不是是你在错误的时间做了错误的事——你还没学会概念就在追框架的版本。1.2 框架的“药”属性它是来解决工程效率的我习惯把框架类比成厨师手里的料理机。料理机确实能帮你快速切菜、搅拌、加热但前提是你得先知道食材怎么处理、火候怎么控制。一个完全不会做饭的人即便给他顶级料理机做出来的东西也大概率不行。更麻烦的是如果菜做失败了他完全不知道是食材问题、火候问题还是料理机设置错了。框架也一样。LangChain 里的AgentExecutor、Chain、MemoryDify 里的工作流节点、知识库、变量每一个概念都是对某种“原生能力”的封装。原生能力是什么就是大模型 API 调用、提示词组织、工具函数调用、上下文拼接、结果解析。这些底层能力用裸代码就能实现而且并不复杂。只有当你的系统变复杂需要处理错误重试、多步编排、记忆持久化、日志追踪时框架的工程价值才真正体现出来。所以结论很清楚框架是药不是饭。没生病不用急着吃药不懂概念光吃药也补不了身子。新手的第一任务是把 Agent 这台机器拆开看看里面的零件是怎么咬合的而不是直接坐进驾驶舱按自动驾驶。1.3 概念不清时框架只会让混乱加倍遇到一个报错如果你理解底层逻辑脑子里会很快形成几个假设是不是上下文超限了是不是工具返回格式不对是不是模型没按约定输出 JSON但如果你是框架新手这些假设一个都形成不了。你只会去搜索引擎复制报错试一个不成就再试下一个运气好蒙对了运气不好卡好几个小时。我特别不建议新手一上来就啃框架的另一个原因是框架的抽象层次会掩盖问题的本质。举个例子你在 LangChain 里用了一个Tool觉得理所当然就该这么写。但实际上Tool背后是“函数调用的 Schema 执行结果以特定格式回填给模型”。这个机制如果没理解透你换一个框架、换一种写法立刻就不会了。反过来如果你在白板代码里自己定义过工具、自己拼过 Schema、自己处理过模型返回的工具调用指令那么任何框架的 Tool 概念你都会觉得“哦这不就是封装嘛”。我就是在这个过程中想明白的AI Agent 入门学的不是某个框架的 API而是模型、提示词、工具、记忆、循环这几样东西如何咬合。它们才是 Agent 的灵魂框架只是皮肉。2. 动手写 Agent 之前这三块“地基”必须打好2.1 大模型 API 的本质输入输出、Token、参数很多新手对 Agent 的第一印象是“它像个大脑”。这个类比没错但容易把人带偏。实际开发中你面对的不是一个神秘大脑而是一个 HTTP API。你把一段文本发过去模型返回一段文本。仅此而已。这里第一个要搞懂的概念就是 Token。模型不是按“字”理解文本的而是把文本拆成一个个 Token。一个 Token 可能是一个词的一部分可能是一个标点也可能是半个汉字。Token 既是模型的输入计量单位也是输出计量单位还是计费的基本单位。你问“AI Agent token 是什么意思”翻译成实际工程语言就是你每次调用模型都会消耗一定量的输入 token 和输出 token上下文越长、对话轮数越多消耗越大。第二个要搞懂的是模型参数。最常见的是temperature它控制随机性调高一点输出更“发散”调低一点输出更“保守”。做 Agent 时我通常把 temperature 调成 0.2 左右因为我们需要模型稳定地执行指令、输出结构化内容而不是搞创作。还有max_tokens它限制单次回复长度防止模型一次说太多挤占上下文空间。第三个是提示词。很多人对提示词的理解停留在“告诉模型做什么”但对 Agent 开发来说提示词更像一份“操作手册”。你要在系统提示词里写清楚你的任务是完成用户的请求你必须一步步思考你可以调用哪些工具输出格式是什么如果遇到无法解决的问题该怎么回应。这些规则写得越清晰Agent 的行为就越可控。我见过不少新手把提示词写得像作文结果模型也跟着写作文完全忘了自己要调工具。提示词不是越多越好而是要结构化、可执行。2.2 Agent 的底层骨架推理→行动→观察循环如果说大模型 API 是 Agent 的肌肉那“推理→行动→观察”这个循环就是 Agent 的骨架。这也是 AI Agent 主流架构里最核心的思想尤其体现在 ReActReasoning Acting模式上。我用人话解释一下这个循环。人解决问题的时候通常不是一口吃成胖子而是会想我现在有什么信息我能做什么做了之后结果怎么样然后根据结果调整下一步。Agent 就是把这个过程模拟出来。推理Reasoning模型根据当前的任务和已有信息思考“下一步该做什么”。行动Acting模型调用一个工具比如查天气、搜索网页、读取文件或者直接输出答案。观察Observation工具执行后返回一个结果这个结果被拼接回上下文再送给模型。注意这个过程不是一次性的而是循环的。Agent 走完一轮“推理→行动→观察”后会再次进入“推理”直到模型认为自己拿到了足够的信息、可以给出最终答案为止。与 ReAct 并列的主流架构还有 Plan-and-Execute。这个模式是先让模型生成一个完整计划然后逐步执行ReAct 则是走一步看一步。你可以把前者理解成“先做攻略再旅行”把后者理解成“随心旅行边走边订酒店”。实际项目中两者经常混用但新手的核心窄门是先把 ReAct 循环写通因为它是所有 Agent 行为的最基本盘。2.3 工具调用与记忆Agent 的“手脚”和“笔记本”Agent 之所以是 Agent而不是一个普通的聊天机器人关键就在于它能调用工具。这一步在工程上通常叫 Function Calling。它的大致逻辑是你提前定义好一系列工具告诉模型“你有这些工具可以调用”每个工具包含名字、描述、参数 JSON Schema。当模型觉得需要某个工具时它不会自己执行代码而是返回一段特殊的结构化内容“我决定调用get_weather参数是{city: 北京}”。注意关键一点模型不负责执行工具执行权在你的代码手里。你拿到模型返回的工具调用指令后自己执行相应的函数再把执行结果作为“工具消息”回传给模型让它继续下一步。这个机制决定了Agent 的能力边界完全取决于你给它挂了什么工具也取决于你的执行环境是否可靠。然后是记忆。Agent 的记忆分两层短期记忆就是上下文窗口模型能看到的所有对话历史长期记忆则需要靠外部存储最常见的形式是向量数据库 RAG。关于 RAG 框架这个概念很多新手容易跟 Agent 搞混其实 RAG 解决的只是一个问题怎么让模型获取训练数据之外的知识。步骤也很直白先把文档切成片段做向量化存进向量库用户提问时先在向量库里检索相关片段拼进提示词再让模型回答。Agent 和 RAG 是可以结合的——Agent 可以把“检索知识库”当成一个工具来调用。但你必须先分清楚一个是在回答前拉取资料一个是自主决策、循环行动。两者不是一回事。2.4 开发者必须补的最小工程课转行者最容易焦虑的就是不懂工程。但其实做 AI Agent 需要的最小工程知识真不多我列一下会 Python 基本语法能读懂报错会安装依赖会管理 API Key 这类环境变量知道怎么用json库做数据解析会写最简单的函数。如果还想做 Web 端展示学一个 FastAPI 或 Gradio 基本够用。不用去啃操作系统、网络协议更不用先去学 Java 后端。很多 AI Agent 应用核心代码可能就几百行。这一阶段千万不要碰的就是“系统性学一个框架”。框架的学习曲线是给那些已经有一定 Agent 开发经验的人准备的新手的精力必须花在三块地基上API 调用、循环思维、工具抽象。3. 零框架手动档用几十行代码跑通 Agent 核心循环3.1 为什么不建议直接安装框架我自己带过几个转行的朋友最快的路径不是去学框架而是“徒手写一个会调工具的 Agent”。写完之后框架里的概念你一眼就能看懂。我把这个阶段称为“手动挡练习”。开手动挡会让你被迫理解离合器、挂挡、油门的配合关系而自动挡把一切都简化为踩油门和刹车。直接上框架的后果就是你只学会了踩油门车一旦出问题你连引擎盖都不会开。这段代码不需要框架不需要向量库只需要一个 OpenAI SDK或者其他模型厂商的 SDK加上几行工具定义。但它足以覆盖 Agent 的完整闭环。3.2 先写一个最简循环从“想”到“做”到“看”下面这个例子我用来跟新手解释 ReAct。假定你已经有一个call_llm(messages)函数它负责把消息列表发给模型并取回回复。那么一个 Agent 循环可以这样写import json def agent_loop(task, max_steps3): messages [ {role: system, content: 你是助手可以调用工具完成任务。每一步只做一个动作。}, {role: user, content: task}, ] for step in range(max_steps): reply call_llm(messages) if reply.content: print(回答:, reply.content) return messages.append({role: assistant, content: reply.content}) # 实际项目中还要解析工具调用并执行…… print(达到最大步数仍未结束)看到没循环长这样把整个对话历史发给模型模型给出回答把回答追加进历史再来一轮。这个“追加历史”的动作就是最简单的记忆。当然这个版本还没有工具模型只能空想。真正让它能干活需要引入 Function Calling。3.3 给 Agent 挂上工具让它真正“做事”假设我们要做一个“能查天气并给出出行建议”的 Agent。第一步定义一个工具def get_weather(city: str) - str: # 这里模拟真实天气接口返回固定文本 return f{city}晴25℃ TOOLS [ { type: function, function: { name: get_weather, description: 查询某个城市的天气, parameters: { type: object, properties: { city: {type: string, description: 城市名} }, required: [city], }, }, } ]接着把它传给模型。模型会判断“要查天气”然后返回类似这样的结构化内容调用get_weather、传参{city: 广州}。你用代码解析并执行这个函数再把结果以“工具消息”的形式追加回去from openai import OpenAI client OpenAI(api_key这里填你的key) def call_llm(messages): resp client.chat.completions.create( modelgpt-4o-mini, messagesmessages, toolsTOOLS, tool_choiceauto, ) return resp.choices[0].message工具消息不是“用户消息”也不是“助手消息”它有一条独立的拼接规则。代码里大致是这样if tool_call_result: messages.append({...assistant message with tool_calls...}) messages.append({ role: tool, tool_call_id: tool_call_id, content: result, })模型收到工具结果后会继续思考“我现在可以回答用户了”然后输出最终答案。这一步完成后你才真正理解了什么叫做“Agent 调工具”。它不是你写一个if判断去执行函数而是模型主动提出“我要用这个工具”你负责执行再把结果喂回给它。3.4 手动档实测中一定会碰到的四个问题第一次跑通这个循环后千万别高兴太早对照下面的坑做一次体检第一无限循环。模型迟迟不结束总是在“建议再查一个东西”。解决方案很简单给循环设一个最大步数通常 3 到 5 步就够了。这个看似简单的上限既能控制成本也能防止 Agent 跑飞。第二上下文爆炸。每轮对话、每次工具结果都要追加进历史几轮下来 Token 消耗就上去了。这就是 token 计费对你的第一堂现实教育。我处理的办法是只保留最近的几轮关键对话或者每次把“历史摘要”压缩成一小段文字再继续。别让对话无限长。第三工具返回格式不规范。模型是一个概率系统偶尔会返回残缺的 JSON、或者参数里多了个多余字符。新手最常见的错误是用json.loads直接解析模型输出一旦格式不标准程序直接抛异常。更稳妥的做法是解析失败时先做一次简单的清洗比如去掉占位符、补全引号再不行就让模型“重新生成一次”。工程上把这种容错叫作“再试一次”。第四成本失控。真的很多人第一次跑 Agent 时会发现费用涨得飞快。因为一个任务可能要调十几次模型每次都带着越来越长的历史。所以在动手之前我强烈建议你先看一下每家模型的价格别一上来就用最贵的旗舰模型。我自己在调试期通常用 mini 或 flash 版本功能和推理能力已经足够测试循环逻辑成本只有旗舰的几十分之一。4. 等到真要上框架时需求决定选型而不是跟风4.1 先定位你的核心需求再谈“框架哪个好”网上常年有人问“agent 框架如 LangChain、Dify、CrewAI哪个好”。说实话这个问题的提问方式就错了。框架之间不是“谁替代谁”的关系而是“谁更适合你的场景”的关系。你问一个厨师“菜刀和炒锅哪个好”他没法回答因为炒菜都要用。我一般会把需求分成三类。第一类是个人自动化脚本比如让 Agent 定时抓数据、写日报、整理文件这种通常用几十行 Python 搞定框架可有可无第二类是面向业务的应用要做用户界面、要管理会话、要接知识库这时候可视化平台或一个轻量 Web 服务更合适第三类是复杂流程编排比如一个任务要拆给多个角色、多步骤并行这时候才需要考虑多 Agent 框架。换句话说框架选型的最终决定因素不是你“想学什么”而是你“要解决什么问题”。我见过有人为了学习 CrewAI硬是把一个单 Agent 查询需求改造成了多 Agent 系统纯粹给自己添乱。这是典型的锤子看什么都像钉子。4.2 三个主流框架的本质差异我把现在最常被问到的三个框架放在一起对比但请记住它们完全可以混用而不是非此即彼。框架定位最适合的人需要留意的地方LangChain代码优先的 Agent 组件库想深度定制的开发者抽象层次多版本变化快容易迷失Dify可视化 AI 应用平台产品、运营、快速验证想法的人低代码方便但底层逻辑容易变成黑盒CrewAI多 Agent 角色协作框架需要多个 Agent 分工协作的场景单 Agent 场景用它是浪费我单独说几句。LangChain 用过的朋友都知道它早期把一大堆概念堆在一起Chain、Agent、Tool、Memory、VectorStore每个概念背后又有一堆子类。它对已掌握 Agent 原理的人来说是救命的脚手架写半天的手动循环在 LangChain 里几行配置就能搞定。但对新手来说它容易让人“用上了但没懂”。所以我的建议永远是把 LangChain 当作“源码阅读材料”而不是“第一堂课”。Dify 适合快速做产品原型。你不写代码靠拖拽节点就能完成“知识库检索→模型回答→工具调用→回复用户”的流程。它对于没有编程背景的转行者、或者需要跟业务方快速对需求的场景特别友好。但我要说清楚用 Dify 搭起来的 Agent你依然要知道底层发生了什么否则出了问题根本无从定位。Dify 的部署、API 隔离、配置这些工程细节也需要一定的学习成本。CrewAI 的核心是“把你一个 Agent 拆成多个角色”。比如一个写文案、一个做校对、一个做数据分析每个角色有独立的角色设定和目标然后编排它们协作。如果你只是“一个助手回答一个问题”真用不上它。多 Agent 会带来额外的 token 消耗和协调复杂度算下来未必比单 Agent 调用多次工具更高效。新手别为了“高级”而上多 Agent先当好单 Agent 再说。4.3 我的建议框架最好是你“看懂”之后的降维工具我在实际项目里的做法是这样的核心 Agent 循环先用裸代码写一遍搞清楚每个环节等我要集成大量外部工具、做重试与调度、加日志追踪时再把手工代码里那些可复用的部分替换成框架组件。这时候框架对我不是负担而是一种“原来这我也写过现在有现成的”的惊喜。所以我的选型建议很简单还没独立写过 Agent 循环之前不选框架。等能写出来了按需选。早期想快速做给客户看的东西Dify 够用想做成一个有一定复杂度、需要深度控制的系统LangChain 或类似的代码组件库适合你真的碰到需要多个角色互相配合的场景再去看 CrewAI。框架永远是你的工具包不是你的身份标签。5. 新手和转行者的百天路线先学什么、后学什么5.1 第一阶段第 1-3 周不写框架只打地基这个阶段的核心任务是理解 Agent 的底层范式并用最简单的代码把它们复现出来。我给它起名叫“地基周”。任务清单不需要很长把 Python 语法过一遍至少会写函数、循环、字典解析和内建类型的使用。注册一个模型厂商的 API自己写脚本调用 API输入一句提示词拿到返回结果。重点理解 Token 计量跑一次带“历史消息”的多轮对话观察 Token 消耗如何增长。学习 Function Calling 机制试着定义一个或两个工具让模型在需要时返回调用指令。这些任务里最容易被新手忽略的是第二和第三个。很多人学 Python 学了一个月也没调用过一次真实模型这是不对的。AI Agent 开发是实践学科理论看十遍不如调一次接口。调用一次真实 API 后你对“模型是概率系统”“输出可能不稳定”这两件事的感受比任何教程都深刻。这个阶段不需要任何 Agent 框架甚至连“Agent”这个词你都可以先忘掉。你只需要建立一个最基本的认知链模型收到文本 → 模型输出文本/工具调用 → 你的代码处理。5.2 第二阶段第 4-6 周手工搭一个最小但完整的 Agent从第四周开始你会开始挑战一个项目做一个有真实使用价值的 Agent。我建议的场景是“帮我完成一个跨工具的小任务”。比如让 Agent 接收一个任务调用一个工具查询信息再调用另一个工具处理结果最后输出一份结构化总结。这个阶段我不建议做得太大一个小而闭环的项目就够了。具体到手的时候按下面顺序推进设计系统提示词写清楚 Agent 的行为边界和输出格式。创建两个工具函数比如一个查天气一个算日期。实现 ReAct 循环设置最大步数记录每一步的输入输出。故意制造一个错误场景比如让工具返回了一个异常格式看看 Agent 是否还能恢复。加一个简单的检索或记忆机制比如把上一次对话的结论保存到本地文件下次调用时读回来。用同一个项目换模型测试对比不同模型的稳定性差异。我遇到过不少新手在这一阶段会焦虑觉得自己写的代码“太简陋”。但请你相信这个简陋的项目其实已经包含了 Agent 的全部关键要素意图识别、任务拆解、工具调用、结果回填、循环终止。很多用框架的人未必能说清楚这些要素你却能亲手实现。后面你再接触框架框架的每个模块都能对上号自然学得飞快。5.3 第三阶段第 7-10 周再去看框架你会发现没那么神秘到第七周左右你已经有徒手实现循环的经验了这时候可以正式去读框架源码。我推荐先读 LangChain 的 Agent 相关模块但不要当用户手册读而是带着问题读框架是怎么管理 messages 的怎么把工具执行结果拼接回去的怎么处理模型返回格式不稳定的怎么在循环里做 Token 控制的你大概率会发现框架内部那些核心概念一点都不高深跟你手写的循环一一对应。AgentExecutor不就是你那层带最大步数的while循环Tool不就是你定义的工具函数加一个参数 SchemaMemory不就是你把历史消息存到一个变量或者外部数据库里面说白了框架替你做了大量工程化的事情它的价值在于健壮性、可扩展性和生态而不是魔法。当然读框架源码也需要有取舍。LangChain 的代码结构相对复杂你可以先读核心模块别从那些扩展组件读起。你也可以读一些更轻量的框架或者干脆读 OpenAI 官方文档里的 function calling 示例。重要的是建立映射关系看到任何框架概念第一反应是“它在我手写循环里对应哪一步”。等到这个时候你再回头面对用户“哪个框架好”的问题心里会非常平静因为你知道所有框架都只是实现同一件底层逻辑的不同姿势选哪个取决于你的工程约束、团队习惯和业务目标。5.4 转行者的三条特别心得如果你是从非技术背景转行过来的我还有几句额外的话想说。第一不要被“不会写代码”吓退。Agent 开发需要的最小工程门槛比传统后端低得多它可以只涉及 Python 基础、API 调用和 JSON。这些只要每个工作日拿出两小时一个月就能达到够用的水平。第二与其背概念不如攒“作品集”。面试官更愿意看一个你亲手跑通的项目哪怕它很小也比你说得出十个框架名有用。第三继续保持“业务视角”。转行者的优势恰恰在于你更理解真实业务场景中的痛点知道哪些流程值得被 Agent 自动化。技术会过时但“发现一个好场景并把它实现出来”的能力永远不会贬值。我自己的体会是AI Agent 的入场券从来不是某个框架而是你对“模型能力边界和调用方式”的底层理解。框架每个月都有新的概念十年八年不会变。抓住那些不变的东西反复练习你手写的能力就是你在快速变化的环境里最稳的抓手。等哪天你觉得手动循环写累了、项目复杂度上去了再优雅地请出框架那才是框架真正该登场的时候。 说实话这两年被 AI Agent 吸引进来的人太多了。我经常收到一类私信开头基本是“想转行做 AI Agent要不要先学 LangChain还是直接上 Dify”每次看到这种问题我都想按住对方的肩膀——兄弟方向反了。AI Agent 入门最大的坑不是学不会某个框架而是你还没弄明白 Agent 到底是什么就先一头扎进了框架的汪洋。等你被各种 Chain、Memory、Tool 的抽象概念淹得喘不过气信心也就磨没了。关于 AI Agent 入门先学什么这件事其实答案很简单先学概念和原理再用最小代码亲手跑通一个 Agent最后才轮到框架。这篇不打算推荐任何“神器框架”而是想跟你聊聊一个绕开弯路的学习思路以及我实际踩过的坑。1. 先分清框架是工程工具不是概念教材1.1 新手最常见的翻车路径我见过太多人按同一条路线“入坑”打开 LangChain 官方文档跟着保姆级教程跑通了一个 demo发现能跑但完全不知道它为什么能跑。接下来想改点东西比如让 Agent 换个工具、改个提示词立刻崩溃。也有人反过来去用 Dify 这类可视化平台拖拖拽拽搭了个工作流确实很方便但一脱离拖拽界面就什么都不会做了。这是典型的“工具驱动学习”带来的问题。框架看起来是学习和上手的捷径但本质上它是一套封装好的工程化组件。它假设你已经理解了 Agent 的基本运行逻辑然后帮你省掉大量重复代码。如果你连底层逻辑都不清楚那框架对你来说就是个黑盒。里面某个环节出问题你连报错信息都看不懂更别说定位问题。还有个更隐蔽的坑主流框架迭代极快。LangChain 早期版本和后期的 API 变化非常大网上教程有一大半已经过期。新手照着旧教程写代码经常会碰到“这个模块不存在”“参数名变了”之类的错误。这时候你会怀疑人生是不是自己太笨其实不是是你在错误的时间做了错误的事——你还没学会概念就在追框架的版本。1.2 框架的“药”属性它是来解决工程效率的我习惯把框架类比成厨师手里的料理机。料理机确实能帮你快速切菜、搅拌、加热但前提是你得先知道食材怎么处理、火候怎么控制。一个完全不会做饭的人即便给他顶级料理机做出来的东西也大概率不行。更麻烦的是如果菜做失败了他完全不知道是食材问题、火候问题还是料理机设置错了。框架也一样。LangChain 里的AgentExecutor、Chain、MemoryDify 里的工作流节点、知识库、变量每一个概念都是对某种“原生能力”的封装。原生能力是什么就是大模型 API 调用、提示词组织、工具函数调用、上下文拼接、结果解析。这些底层能力用裸代码就能实现而且并不复杂。只有当你的系统变复杂需要处理错误重试、多步编排、记忆持久化、日志追踪时框架的工程价值才真正体现出来。所以结论很清楚框架是药不是饭。没生病不用急着吃药不懂概念光吃药也补不了身子。新手的第一任务是把 Agent 这台机器拆开看看里面的零件是怎么咬合的而不是直接坐进驾驶舱按自动驾驶。1.3 概念不清时框架只会让混乱加倍遇到一个报错如果你理解底层逻辑脑子里会很快形成几个假设是不是上下文超限了是不是工具返回格式不对是不是模型没按约定输出 JSON但如果你是框架新手这些假设一个都形成不了。你只会去搜索引擎复制报错试一个不成就再试下一个运气好蒙对了运气不好卡好几个小时。我特别不建议新手一上来就啃框架的另一个原因是框架的抽象层次会掩盖问题的本质。举个例子你在 LangChain 里用了一个Tool觉得理所当然就该这么写。但实际上Tool背后是“函数调用的 Schema 执行结果以特定格式回填给模型”。这个机制如果没理解透你换一个框架、换一种写法立刻就不会了。反过来如果你在白板代码里自己定义过工具、自己拼过 Schema、自己处理过模型返回的工具调用指令那么任何框架的 Tool 概念你都会觉得“哦这不就是封装嘛”。我就是在这个过程中想明白的AI Agent 入门学的不是某个框架的 API而是模型、提示词、工具、记忆、循环这几样东西如何咬合。它们才是 Agent 的灵魂框架只是皮肉。2. 动手写 Agent 之前这三块“地基”必须打好2.1 大模型 API 的本质输入输出、Token、参数很多新手对 Agent 的第一印象是“它像个大脑”。这个类比没错但容易把人带偏。实际开发中你面对的不是一个神秘大脑而是一个 HTTP API。你把一段文本发过去模型返回一段文本。仅此而已。这里第一个要搞懂的概念就是 Token。模型不是按“字”理解文本的而是把文本拆成一个个 Token。一个 Token 可能是一个词的一部分可能是一个标点也可能是半个汉字。Token 既是模型的输入计量单位也是输出计量单位还是计费的基本单位。你问“AI Agent token 是什么意思”翻译成实际工程语言就是你每次调用模型都会消耗一定量的输入 token 和输出 token上下文越长、对话轮数越多消耗越大。第二个要搞懂的是模型参数。最常见的是temperature它控制随机性调高一点输出更“发散”调低一点输出更“保守”。做 Agent 时我通常把 temperature 调成 0.2 左右因为我们需要模型稳定地执行指令、输出结构化内容而不是搞创作。还有max_tokens它限制单次回复长度防止模型一次说太多挤占上下文空间。第三个是提示词。很多人对提示词的理解停留在“告诉模型做什么”但对 Agent 开发来说提示词更像一份“操作手册”。你要在系统提示词里写清楚你的任务是完成用户的请求你必须一步步思考你可以调用哪些工具输出格式是什么如果遇到无法解决的问题该怎么回应。这些规则写得越清晰Agent 的行为就越可控。我见过不少新手把提示词写得像作文结果模型也跟着写作文完全忘了自己要调工具。提示词不是越多越好而是要结构化、可执行。2.2 Agent 的底层骨架推理→行动→观察循环如果说大模型 API 是 Agent 的肌肉那“推理→行动→观察”这个循环就是 Agent 的骨架。这也是 AI Agent 主流架构里最核心的思想尤其体现在 ReActReasoning Acting模式上。我用人话解释一下这个循环。人解决问题的时候通常不是一口吃成胖子而是会想我现在有什么信息我能做什么做了之后结果怎么样然后根据结果调整下一步。Agent 就是把这个过程模拟出来。推理Reasoning模型根据当前的任务和已有信息思考“下一步该做什么”。行动Acting模型调用一个工具比如查天气、搜索网页、读取文件或者直接输出答案。观察Observation工具执行后返回一个结果这个结果被拼接回上下文再送给模型。注意这个过程不是一次性的而是循环的。Agent 走完一轮“推理→行动→观察”后会再次进入“推理”直到模型认为自己拿到了足够的信息、可以给出最终答案为止。与 ReAct 并列的主流架构还有 Plan-and-Execute。这个模式是先让模型生成一个完整计划然后逐步执行ReAct 则是走一步看一步。你可以把前者理解成“先做攻略再旅行”把后者理解成“随心旅行边走边订酒店”。实际项目中两者经常混用但新手的核心窄门是先把 ReAct 循环写通因为它是所有 Agent 行为的最基本盘。2.3 工具调用与记忆Agent 的“手脚”和“笔记本”Agent 之所以是 Agent而不是一个普通的聊天机器人关键就在于它能调用工具。这一步在工程上通常叫 Function Calling。它的大致逻辑是你提前定义好一系列工具告诉模型“你有这些工具可以调用”每个工具包含名字、描述、参数 JSON Schema。当模型觉得需要某个工具时它不会自己执行代码而是返回一段特殊的结构化内容“我决定调用get_weather参数是{city: 北京}”。注意关键一点模型不负责执行工具执行权在你的代码手里。你拿到模型返回的工具调用指令后自己执行相应的函数再把执行结果作为“工具消息”回传给模型让它继续下一步。这个机制决定了Agent 的能力边界完全取决于你给它挂了什么工具也取决于你的执行环境是否可靠。然后是记忆。Agent 的记忆分两层短期记忆就是上下文窗口模型能看到的所有对话历史长期记忆则需要靠外部存储最常见的形式是向量数据库 RAG。关于 RAG 框架这个概念很多新手容易跟 Agent 搞混其实 RAG 解决的只是一个问题怎么让模型获取训练数据之外的知识。步骤也很直白先把文档切成片段做向量化存进向量库用户提问时先在向量库里检索相关片段拼进提示词再让模型回答。Agent 和 RAG 是可以结合的——Agent 可以把“检索知识库”当成一个工具来调用。但你必须先分清楚一个是在回答前拉取资料一个是自主决策、循环行动。两者不是一回事。2.4 开发者必须补的最小工程课转行者最容易焦虑的就是不懂工程。但其实做 AI Agent 需要的最小工程知识真不多我列一下会 Python 基本语法能读懂报错会安装依赖会管理 API Key 这类环境变量知道怎么用json库做数据解析会写最简单的函数。如果还想做 Web 端展示学一个 FastAPI 或 Gradio 基本够用。不用去啃操作系统、网络协议更不用先去学 Java 后端。很多 AI Agent 应用核心代码可能就几百行。这一阶段千万不要碰的就是“系统性学一个框架”。框架的学习曲线是给那些已经有一定 Agent 开发经验的人准备的新手的精力必须花在三块地基上API 调用、循环思维、工具抽象。3. 零框架手动档用几十行代码跑通 Agent 核心循环3.1 为什么不建议直接安装框架我自己带过几个转行的朋友最快的路径不是去学框架而是“徒手写一个会调工具的 Agent”。写完之后框架里的概念你一眼就能看懂。我把这个阶段称为“手动挡练习”。开手动挡会让你被迫理解离合器、挂挡、油门的配合关系而自动挡把一切都简化为踩油门和刹车。直接上框架的后果就是你只学会了踩油门车一旦出问题你连引擎盖都不会开。这段代码不需要框架不需要向量库只需要一个 OpenAI SDK或者其他模型厂商的 SDK加上几行工具定义。但它足以覆盖 Agent 的完整闭环。3.2 先写一个最简循环从“想”到“做”到“看”下面这个例子我用来跟新手解释 ReAct。假定你已经有一个call_llm(messages)函数它负责把消息列表发给模型并取回回复。那么一个 Agent 循环可以这样写import json def agent_loop(task, max_steps3): messages [ {role: system, content: 你是助手可以调用工具完成任务。每一步只做一个动作。}, {role: user, content: task}, ] for step in range(max_steps): reply call_llm(messages) if reply.content: print(回答:, reply.content) return messages.append({role: assistant, content: reply.content}) # 实际项目中还要解析工具调用并执行…… print(达到最大步数仍未结束)看到没循环长这样把整个对话历史发给模型模型给出回答把回答追加进历史再来一轮。这个“追加历史”的动作就是最简单的记忆。当然这个版本还没有工具模型只能空想。真正让它能干活需要引入 Function Calling。3.3 给 Agent 挂上工具让它真正“做事”假设我们要做一个“能查天气并给出出行建议”的 Agent。第一步定义一个工具def get_weather(city: str) - str: # 这里模拟真实天气接口返回固定文本 return f{city}晴25℃ TOOLS [ { type: function, function: { name: get_weather, description: 查询某个城市的天气, parameters: { type: object, properties: { city: {type: string, description: 城市名} }, required: [city], }, }, } ]接着把它传给模型。模型会判断“要查天气”然后返回类似这样的结构化内容调用get_weather、传参{city: 广州}。你用代码解析并执行这个函数再把结果以“工具消息”的形式追加回去from openai import OpenAI client OpenAI(api_key这里填你的key) def call_llm(messages): resp client.chat.completions.create( modelgpt-4o-mini, messagesmessages, toolsTOOLS, tool_choiceauto, ) return resp.choices[0].message工具消息不是“用户消息”也不是“助手消息”它有一条独立的拼接规则。代码里大致是这样if tool_call_result: messages.append({...assistant message with tool_calls...}) messages.append({ role: tool, tool_call_id: tool_call_id, content: result, })模型收到工具结果后会继续思考“我现在可以回答用户了”然后输出最终答案。这一步完成后你才真正理解了什么叫做“Agent 调工具”。它不是你写一个if判断去执行函数而是模型主动提出“我要用这个工具”你负责执行再把结果喂回给它。3.4 手动档实测中一定会碰到的四个问题第一次跑通这个循环后千万别高兴太早对照下面的坑做一次体检第一无限循环。模型迟迟不结束总是在“建议再查一个东西”。解决方案很简单给循环设一个最大步数通常 3 到 5 步就够了。这个看似简单的上限既能控制成本也能防止 Agent 跑飞。第二上下文爆炸。每轮对话、每次工具结果都要追加进历史几轮下来 Token 消耗就上去了。这就是 token 计费对你的第一堂现实教育。我处理的办法是只保留最近的几轮关键对话或者每次把“历史摘要”压缩成一小段文字再继续。别让对话无限长。第三工具返回格式不规范。模型是一个概率系统偶尔会返回残缺的 JSON、或者参数里多了个多余字符。新手最常见的错误是用json.loads直接解析模型输出一旦格式不标准程序直接抛异常。更稳妥的做法是解析失败时先做一次简单的清洗比如去掉占位符、补全引号再不行就让模型“重新生成一次”。工程上把这种容错叫作“再试一次”。第四成本失控。真的很多人第一次跑 Agent 时会发现费用涨得飞快。因为一个任务可能要调十几次模型每次都带着越来越长的历史。所以在动手之前我强烈建议你先看一下每家模型的价格别一上来就用最贵的旗舰模型。我自己在调试期通常用 mini 或 flash 版本功能和推理能力已经足够测试循环逻辑成本只有旗舰的几十分之一。4. 等到真要上框架时需求决定选型而不是跟风4.1 先定位你的核心需求再谈“框架哪个好”网上常年有人问“agent 框架如 LangChain、Dify、CrewAI哪个好”。说实话这个问题的提问方式就错了。框架之间不是“谁替代谁”的关系而是“谁更适合你的场景”的关系。你问一个厨师“菜刀和炒锅哪个好”他没法回答因为炒菜都要用。我一般会把需求分成三类。第一类是个人自动化脚本比如让 Agent 定时抓数据、写日报、整理文件这种通常用几十行 Python 搞定框架可有可无第二类是面向业务的应用要做用户界面、要管理会话、要接知识库这时候可视化平台或一个轻量 Web 服务更合适第三类是复杂流程编排比如一个任务要拆给多个角色、多步骤并行这时候才需要考虑多 Agent 框架。换句话说框架选型的最终决定因素不是你“想学什么”而是你“要解决什么问题”。我见过有人为了学习 CrewAI硬是把一个单 Agent 查询需求改造成了多 Agent 系统纯粹给自己添乱。这是典型的锤子看什么都像钉子。4.2 三个主流框架的本质差异我把现在最常被问到的三个框架放在一起对比但请记住它们完全可以混用而不是非此即彼。框架定位最适合的人需要留意的地方LangChain代码优先的 Agent 组件库想深度定制的开发者抽象层次多版本变化快容易迷失Dify可视化 AI 应用平台产品、运营、快速验证想法的人低代码方便但底层逻辑容易变成黑盒CrewAI多 Agent 角色协作框架需要多个 Agent 分工协作的场景单 Agent 场景用它是浪费我单独说几句。LangChain 用过的朋友都知道它早期把一大堆概念堆在一起Chain、Agent、Tool、Memory、VectorStore每个概念背后又有一堆子类。它对已掌握 Agent 原理的人来说是救命的脚手架写半天的手动循环在 LangChain 里几行配置就能搞定。但对新手来说它容易让人“用上了但没懂”。所以我的建议永远是把 LangChain 当作“源码阅读材料”而不是“第一堂课”。Dify 适合快速做产品原型。你不写代码靠拖拽节点就能完成“知识库检索→模型回答→工具调用→回复用户”的流程。它对于没有编程背景的转行者、或者需要跟业务方快速对需求的场景特别友好。但我要说清楚用 Dify 搭起来的 Agent你依然要知道底层发生了什么否则出了问题根本无从定位。Dify 的部署、API 隔离、配置这些工程细节也需要一定的学习成本。CrewAI 的核心是“把你一个 Agent 拆成多个角色”。比如一个写文案、一个做校对、一个做数据分析每个角色有独立的角色设定和目标然后编排它们协作。如果你只是“一个助手回答一个问题”真用不上它。多 Agent 会带来额外的 token 消耗和协调复杂度算下来未必比单 Agent 调用多次工具更高效。新手别为了“高级”而上多 Agent先当好单 Agent 再说。4.3 我的建议框架最好是你“看懂”之后的降维工具我在实际项目里的做法是这样的核心 Agent 循环先用裸代码写一遍搞清楚每个环节等我要集成大量外部工具、做重试与调度、加日志追踪时再把手工代码里那些可复用的部分替换成框架组件。这时候框架对我不是负担而是一种“原来这我也写过现在有现成的”的惊喜。所以我的选型建议很简单还没独立写过 Agent 循环之前不选框架。等能写出来了按需选。早期想快速做给客户看的东西Dify 够用想做成一个有一定复杂度、需要深度控制的系统LangChain 或类似的代码组件库适合你真的碰到需要多个角色互相配合的场景再去看 CrewAI。框架永远是你的工具包不是你的身份标签。5. 新手和转行者的百天路线先学什么、后学什么5.1 第一阶段第 1-3 周不写框架只打地基这个阶段的核心任务是理解 Agent 的底层范式并用最简单的代码把它们复现出来。我给它起名叫“地基周”。任务清单不需要很长把 Python 语法过一遍至少会写函数、循环、字典解析和内建类型的使用。注册一个模型厂商的 API自己写脚本调用 API输入一句提示词拿到返回结果。重点理解 Token 计量跑一次带“历史消息”的多轮对话观察 Token 消耗如何增长。学习 Function Calling 机制试着定义一个或两个工具让模型在需要时返回调用指令。这些任务里最容易被新手忽略的是第二和第三个。很多人学 Python 学了一个月也没调用过一次真实模型这是不对的。AI Agent 开发是实践学科理论看十遍不如调一次接口。调用一次真实 API 后你对“模型是概率系统”“输出可能不稳定”这两件事的感受比任何教程都深刻。这个阶段不需要任何 Agent 框架甚至连“Agent”这个词你都可以先忘掉。你只需要建立一个最基本的认知链模型收到文本 → 模型输出文本/工具调用 → 你的代码处理。5.2 第二阶段第 4-6 周手工搭一个最小但完整的 Agent从第四周开始你会开始挑战一个项目做一个有真实使用价值的 Agent。我建议的场景是“帮我完成一个跨工具的小任务”。比如让 Agent 接收一个任务调用一个工具查询信息再调用另一个工具处理结果最后输出一份结构化总结。这个阶段我不建议做得太大一个小而闭环的项目就够了。具体到手的时候按下面顺序推进设计系统提示词写清楚 Agent 的行为边界和输出格式。创建两个工具函数比如一个查天气一个算日期。实现 ReAct 循环设置最大步数记录每一步的输入输出。故意制造一个错误场景比如让工具返回了一个异常格式看看 Agent 是否还能恢复。加一个简单的检索或记忆机制比如把上一次对话的结论保存到本地文件下次调用时读回来。用同一个项目换模型测试对比不同模型的稳定性差异。我遇到过不少新手在这一阶段会焦虑觉得自己写的代码“太简陋”。但请你相信这个简陋的项目其实已经包含了 Agent 的全部关键要素意图识别、任务拆解、工具调用、结果回填、循环终止。很多用框架的人未必能说清楚这些要素你却能亲手实现。后面你再接触框架框架的每个模块都能对上号自然学得飞快。5.3 第三阶段第 7-10 周再去看框架你会发现没那么神秘到第七周左右你已经有徒手实现循环的经验了这时候可以正式去读框架源码。我推荐先读 LangChain 的 Agent 相关模块但不要当用户手册读而是带着问题读框架是怎么管理 messages 的怎么把工具执行结果拼接回去的怎么处理模型返回格式不稳定的怎么在循环里做 Token 控制的你大概率会发现框架内部那些核心概念一点都不高深跟你手写的循环一一对应。AgentExecutor不就是你那层带最大步数的while循环Tool不就是你定义的工具函数加一个参数 SchemaMemory不就是你把历史消息存到一个变量或者外部数据库里面说白了框架替你做了大量工程化的事情它的价值在于健壮性、可扩展性和生态而不是魔法。当然读框架源码也需要有取舍。LangChain 的代码结构相对复杂你可以先读核心模块别从那些扩展组件读起。你也可以读一些更轻量的框架或者干脆读 OpenAI 官方文档里的 function calling 示例。重要的是建立映射关系看到任何框架概念第一反应是“它在我手写循环里对应哪一步”。等到这个时候你再回头面对用户“哪个框架好”的问题心里会非常平静因为你知道所有框架都只是实现同一件底层逻辑的不同姿势选哪个取决于你的工程约束、团队习惯和业务目标。5.4 转行者的三条特别心得如果你是从非技术背景转行过来的我还有几句额外的话想说。第一不要被“不会写代码”吓退。Agent 开发需要的最小工程门槛比传统后端低得多它可以只涉及 Python 基础、API 调用和 JSON。这些只要每个工作日拿出两小时一个月就能达到够用的水平。第二与其背概念不如攒“作品集”。面试官更愿意看一个你亲手跑通的项目哪怕它很小也比你说得出十个框架名有用。第三继续保持“业务视角”。转行者的优势恰恰在于你更理解真实业务场景中的痛点知道哪些流程值得被 Agent 自动化。技术会过时但“发现一个好场景并把它实现出来”的能力永远不会贬值。我自己的体会是AI Agent 的入场券从来不是某个框架而是你对“模型能力边界和调用方式”的底层理解。框架每个月都有新的概念十年八年不会变。抓住那些不变的东西反复练习你手写的能力就是你在快速变化的环境里最稳的抓手。等哪天你觉得手动循环写累了、项目复杂度上去了再优雅地请出框架那才是框架真正该登场的时候。