AI Agent入门先学什么？别急着啃框架，先吃透核心原理

AI Agent入门，到底先学什么？框架不是第一课

我先说一个比较反直觉的结论：新手和转行者学AI Agent，最不该做的就是一上来就啃LangChain、Dify、CrewAI这类框架。

为什么这么说？因为我见过太多人走了这条路，然后卡在原地。打开LangChain的文档，满屏的Chain、Runnable、Tool、Memory抽象概念，还没搞清楚Agent到底是怎么工作的，就先被框架的封装逻辑绕晕了，边看文档边怀疑自己的智商。最后要么放弃，要么学了一堆API用法，但换一个场景依然无从下手。

这个现象现在太普遍了。AI Agent赛道火爆，随便刷一下招聘网站，满屏都是“Agent开发工程师”“大模型应用工程师”，月薪两万起步，转行者心动很正常。但心动归心动，学习路线要是走错了，效率差距是三到五倍。

这篇文章主要面向两类人：一是完全零基础的程序员，想切入AI Agent方向但不知道从哪下手；二是非技术背景的转行者，比如运营、产品、测试，想往这个方向靠拢但被技术门槛吓住。我会把Agent学习的底层逻辑、必须掌握的核心概念、以及一条可复用的自学路径讲清楚，尽量不用晦涩的术语堆砌，让不同基础的读者都能找到自己的切入点。

先说一个核心观点：Agent的本质不是某个框架，而是一种软件架构模式。框架只是帮你实现这种模式的工具。先懂模式，再选工具，顺序不能反。

1. 为什么“别一上来就啃框架”成了入门铁律

1.1 框架解决的是效率问题，不是认知问题

LangChain、Dify这类框架的价值在于：把Agent开发中重复性高、通用性强的部分抽象出来，让你少写样板代码。比如管理对话历史、接入各种大模型API、封装工具调用逻辑，这些基础设施如果从零写，确实要花不少时间。

但这里有个关键陷阱：框架帮你省力的前提是，你已经知道这些事情为什么需要做、底层是怎么运作的。如果你连“模型一次请求能处理多少文本”“函数调用是什么”“上下文窗口满了会怎样”这些基本概念都还没建立，直接用框架，等于让一个没学过发动机原理的人去开车，能开，但一旦出故障就完全蒙圈。

我举个具体的例子。LangChain里有个概念叫Memory，用来保存对话历史。新手用的时候可能只是简单配置一下，但完全不知道Memory内部是怎么处理token的，也不知道对话太长会超窗口报错，更不知道怎么裁剪历史。等真上线遇到报错，排查半天找不到原因，最后问了一圈才知道是token超限。这其实就是基础认知缺失导致的典型问题。

框架本身没错，错的是学习顺序。基础没打好之前，框架的抽象层反而成了障碍。

1.2 框架更新太快，盲目追新等于在流沙上盖楼

还有一个很现实的问题：Agent框架的更新速度，快到你根本追不过来。LangChain的API隔几个月就变一次，版本升级经常导致老代码直接跑不起来；Dify的功能迭代也很猛，隔阵子就出一批新节点；CrewAI的版本号蹭蹭往上涨。如果你是靠死记API来学习，那基本上一半时间都在跟进版本变化，真心扛不住。

反过来，如果底层原理已经理解了，框架更新对你来说就只是了解新变化、看看有没有新用法而已，代码迁移成本会低很多。因为你知道核心机制没变，变的只是封装形式。

1.3 业务场景千差万别，不存在万能框架

我在网上看到很多人在纠结：LangChain、Dify、CrewAI哪个好？说实话，这个问题可能问到根上就是错的。不同框架解决不同层次的问题，适用场景完全不一样。

拿我自己接触过的一些项目来说，如果只是做个简单的客服问答机器人，用Dify的可视化编排就够了，拖拖拽拽就能上线，没必要上LangChain。但如果要做一个自主规划、多工具调用的复杂Agent，LangChain这类代码型框架会更合适。CrewAI则适合多Agent协作的场景。你要先去理解自己的业务需要什么，再去选框架，而不是反过来让框架限制你的设计。学框架是手段，不是目的。

2. AI Agent的核心机制拆解：模型、循环、工具三件套

想把Agent学好，第一步就是建立对Agent本质的认知。AI Agent并不是一个新物种，拆开来看，底层就三样东西：大语言模型、循环控制逻辑、工具调用能力。把这三者的关系搞明白，框架里那些眼花缭乱的概念，你基本就能猜个八九不离十。

2.1 大模型在Agent里的角色：一个会“说话”的决策大脑

大模型本身擅长的是文本生成、逻辑推理、意图理解。但在Agent的体系里，大模型不是用来写文章的，它的核心作用是充当“决策中枢”：根据当前的输入和任务目标，判断下一步该干什么。

比如一个负责查天气并决定是否提醒带伞的Agent，用户的输入是“明天北京适合出门吗”，模型要做的不是直接回答，而是分析：这个任务需要获取实时天气数据，我手头没有这个数据，所以我需要调用查天气的工具，然后把结果转成用户能看得懂的结论。

这个“分析任务、决定调用哪个工具、根据工具返回结果继续推理”的过程，本质上就是一次模型推理。你能看到模型的能力边界在哪，也能理解Agent能做什么、不能做什么，全都取决于这个基础模型本身的能力上限。如果你的模型算不明白逻辑题，那套再华丽的Agent外壳也救不了它。

2.2 循环是Agent的灵魂：感知-决策-执行的闭环

Agent与普通程序的本质区别，在于它有一个反复运行的循环逻辑。这个循环可以简化成三步：感知（Perception）、决策（Decision）、执行（Action）。

感知：获取用户输入，加上之前对话留下的上下文信息，形成当前这一步的完整请求。

决策：把请求发给大模型，让模型根据推理给出行动方案，可能是“直接回答用户”，也可能是“需要调用某个工具”。现在的模型一般通过函数调用（Function Calling）机制来输出结构化指令。

执行：如果有工具调用指令，就去执行对应的工具代码，拿到返回结果，再把它作为新的上下文喂回给模型，进入下一轮循环。

这个环会一直转，直到模型判断任务完成了、直接输出最终答案为止。实际工程里这个循环还得设置最大轮数保护，否则模型可能陷入死循环，一个工具反复调，白白消耗钱和时间。

2.3 工具是Agent的手脚：为什么函数调用如此重要

大模型的能力边界在于，它只活在训练数据组成的“知识世界”里，无法触达实时信息，也无法执行真实世界的操作。这时候工具系统就是Agent的手脚，负责补上模型的天生短板。

工具的范围非常广：一个查天气的API、一个发邮件的接口、一个数据库查询函数、一个控制智能家居的指令，都可以封装成工具。关键在于，你要把工具“描述”清楚，让模型知道有什么工具可用、什么情况下用哪个。现在的实现通常是给模型传一组JSON Schema的工具定义，模型根据任务内容选择并输出调用参数。

如果能把“模型作决策、工具做执行、循环串全程”的机制吃透，AI Agent最核心的骨架你就已经握在手里了。框架再怎么变，万变不离其宗。我自己把这些机制彻底搞明白，大概是在用原生代码手写了一个Agent之后的事，后面才去看LangChain，发现很多东西都通了。

3. Token、上下文窗口和提示词设计：绕不开的地基工程

如果说Agent机制决定了你的系统架构，那Token和提示词设计就决定了Agent实际能跑多稳、多聪明。这块没有扎实基础，很多问题遇到的时候根本无从下手。

3.1 Token到底是什么：一次搞清楚它为什么贵

Token是大模型处理文本的最小单位。你可以粗略把它理解成“字符碎片”，英文里一个单词通常对应一到两个Token，中文里一个汉字大概对应一到两个Token。但模型不按字数计费，按Token数计费，所以Token就是Agent世界里实实在在的成本单位。

我经常跟新手说，不要觉得Token是个高深的技术概念，它对你的直接意义就是钱袋子。一个Agent跑一次任务会产生多少Token，单价是多少，你有没有预算让它跑完整个循环，这些都得心里有数。很多项目做到一半，翻一下账单发现成本吓人，就是因为启动时没认真估算Token消耗。学Agent，一定要先学会算Token账。

3.2 上下文窗口和“失忆症”：Agent状态管理的起点

上下文窗口是模型单次能处理的最大Token数。你发给模型的内容加上模型生成的内容，总长度不能超过这个窗口，否则就会报错。

Agent的运行方式是把多轮对话历史全部塞进上下文里，让模型“记得”之前的推理过程。这就有个天然瓶颈：上下文窗口是有限的，对话一长，要么装不下，要么费用飙升。而截断历史又会导致模型“失忆”，忘了前面说过的关键信息，做出错误判断。

这就是Agent开发里最经典的工程难题，记忆管理。你用框架时看到的“记忆模块”，本质上就是在处理这个问题：一句话总结历史、提取关键信息、按重要性丢弃旧内容。不懂上下文机制，你都不知道那些配置项是干嘛用的。

3.3 提示词大全是误区：Agent时代的提示词重设计逻辑

传统提示词工程里，大家习惯搞一套庞大的“提示词大全”，把各种知识、规则都塞进System Prompt里。但在Agent场景下，这条路走不通了。因为Agent的提示词不是写一段静态文案，而是要精准控制模型的思考路径和行为边界。

一个合格的Agent提示词至少要有几块内容：角色定位，这个Agent是什么身份；任务说明，目标是干什么；行为约束，什么能做、什么绝对不能做；输出格式，中间输出和最终输出的结构。最重要的还有工具使用指引，告诉模型什么情况下该用什么工具、什么情况下不要乱用。

异步并行思维在Agent提示词里也特别重要。你不需要写“如果用户问天气，就查天气API；如果用户问股票，就查股票API”这种穷举式分支，那是传统规则引擎的思路。模型本身已经会决策了，你只需要把工具的适用边界说清楚，它自己会判断。你的提示词是给模型一把尺子，不是给它编一本行为说明书。

4. 从零手写一个Agent：用100行代码打通所有底层认知

原理讲了这么多，现在说点实操的。我个人最推荐的学习方式，是用原生代码手写一个Agent，不用任何框架，就靠直接调大模型的API把循环跑通。

4.1 最小实现思路：为什么自研能打通认知

我当年带过几个转行做Agent的同事，发现一个规律：凡是先手写过原生Agent的人，后面学框架都特别快。反之，一上来就啃框架的人，很容易陷入“会配置但不懂原理”的状态，遇到点特殊需求就黔驴技穷。

手写一个Agent的正确姿势是：第一步，只用大模型API做一个能聊天的脚本；第二步，给脚本加一个工具，比如查天气的API；第三步，利用Function Calling机制，让模型在回答用户问题时，自动判断“现在该调天气工具了”；第四步，把工具返回的结果再喂给模型，生成最终回答。到这里，一个最小的Agent循环就已经成型了。

4.2 核心代码讲解：一个可跑的天气查询Agent

直接用Python的openai SDK风格写一个最小示例。这个例子里的模型接口是国内可用的标准OpenAI兼容接口，你可以替换成任何一家支持函数调用的模型服务。

import json import requests from openai import OpenAI client = OpenAI( api_key="your-api-key", base_url="https://your-model-endpoint" ) # 1. 定义一个查询天气的工具 def get_weather(city: str) -> str: # 这里简化处理，实际项目可接第三方天气API weather_data = { "北京": "晴，15~27℃", "上海": "小雨，20~25℃", "广州": "多云，24~30℃" } return weather_data.get(city, "暂未收录该城市天气") # 2. 定义工具描述，交给模型识别 tools = [ { "type": "function", "function": { "name": "get_weather", "description": "查询指定城市的实时天气情况", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名称，比如：北京" } }, "required": ["city"] } } } ] # 3. 工具执行分发 def call_tool(name: str, arguments: str) -> str: args = json.loads(arguments) if name == "get_weather": return get_weather(args["city"]) return "未知工具" # 4. Agent主循环 def run_agent(user_input: str, max_steps: int = 5): messages = [ {"role": "system", "content": "你是一个友好的天气助手。如果需要了解实时天气，请调用天气查询工具。"}, {"role": "user", "content": user_input} ] for step in range(max_steps): response = client.chat.completions.create( model="your-model-name", messages=messages, tools=tools ) msg = response.choices[0].message # 如果模型没有要求调用工具，说明可以直接回答用户了 if not msg.tool_calls: print(f"模型最终回答：{msg.content}") return msg.content # 模型要求调用工具，把这条带有工具调用指令的消息加入历史 messages.append(msg) # 逐个处理工具调用 for tool_call in msg.tool_calls: tool_name = tool_call.function.name tool_args = tool_call.function.arguments print(f"第{step + 1}步：调用工具 {tool_name}({tool_args})") result = call_tool(tool_name, tool_args) # 把工具返回结果以 tool 角色追加到对话中 messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": result }) print("已达最大轮数，Agent停止循环") return None if __name__ == "__main__": run_agent("北京天气适合跑步吗？")

这段代码的关键设计点有三个，我给新手拆一下：

第一，messages列表就是Agent的全部状态。系统提示词、用户问题、模型决策、工具返回结果，全部以追加消息的方式写回messages，每一轮循环模型都能看到之前的完整轨迹。这也是框架里Memory的雏形，理解了它，框架的Memory配置你就能秒懂。

第二，循环退出条件有两个：模型不再返回工具调用，说明任务完成，可以直接输出；或者达到max_steps上限，强制终止，防止死循环。

第三，工具定义用JSON Schema描述，这是让模型从“自由文本回答”升级为“结构化工具调用”的关键一步。你现在看框架里的Tool概念，本质上就是这个结构的封装。

4.3 跑通之后的几个进阶问题

最小Agent能跑通之后，建议马上加新东西，才能加深对边界情况的理解：加入多工具，比如再加一个查股票价格的API，看模型在多个工具之间会不会选对；加历史对话轮次，把之前几轮用户问题也塞进messages里，看看对话长了会出现什么问题，逼自己思考裁剪策略；把工具调用封装成装饰器，模拟框架的注册机制，这时候再看LangChain的@tool装饰器，就会有一种“原来如此”的通透感。

这一步不要贪快，一个礼拜能写透彻一个手写Agent，后面就会省出很多试错成本。

5. 框架怎么选：LangChain、Dify、CrewAI的分工与边界

基础打牢之后，回到文章开头那个绕不开的问题：项目要用什么框架？我给一个比较务实的判断框架，分场景去选，而不是纯看谁名气大。

5.1 代码型V S 可视化型：先分清两类框架路线

市面上的Agent框架大体分两类：代码型和可视化型。

代码型以LangChain、CrewAI、LlamaIndex为代表，核心是让你用代码编排Agent逻辑，灵活度高，适合需要深度定制、和现有代码体系深度集成的项目。它的学习成本主要是编程能力和设计模式，但对程序员来说上限高。

可视化型以Dify、Coze为代表，核心是拖拽节点、填配置表单来搭建Agent，不需要写大量代码就能上线，原型速度快，适合快速验证想法，很多运营同学也能上手。但自由度相对低，遇到框架里没有预设的功能，就得琢磨绕路方案。

选哪条路取决于你的背景和项目。我见过纯运营背景的人用Dify搭客服机器人，半个月上线，效果还不错；也见过后端程序员用LangChain搭企业知识库Agent，在深度定制上更顺手。没有绝对的好坏，只有是否匹配。

5.2 三个主流框架的定位差异：该用啥时用啥

LangChain：生态最全、支持最多模型和工具，适合Python技术栈的开发者做中等偏上复杂度的Agent应用。缺点是概念多、更新快，容易学得累，但一旦你理解了Agent底层原理，这些概念就是在帮你节约时间。我个人用它来搭过几个偏流程编排的工具链项目，整体可控。

Dify：开源的可视化Agent开发平台，适合产品经理、运营、以及需要快速交付MVP的团队。它的核心价值在RAG知识库和工作流编排上，你不需要写代码就能把检索增强、多轮对话、工具调用串起来。缺点是做非常复杂的分支逻辑时，可视化节点多了会看到头疼。

CrewAI：定位多Agent协作，适合任务可以拆成多个角色分工协作的项目，比如一个研究Agent负责收集资料，一个写作Agent负责成稿。核心概念是Role、Task、Process，理解成本比LangChain低一些。但多Agent协作在实际生产里稳定性要求高，不建议新手一上来就玩这个，先把单Agent练熟了再说。

5.3 别人踩过的选型坑：我的真实建议

说个比较常见的翻车场景：团队为了赶项目，选了Dify想快速上线客服机器人，但业务方突然要求对接内部工单系统，还要实现复杂的多条件判断。Dify的标准节点搞不定，最后硬着头皮在Dify里写代码扩展，反而比直接用LangChain更折腾。

还有一个坑是传播比较广的：看网上别人用LangChain搭了个很牛的Agent，就以为自己也能复现。但很多案例文章都隐藏了前提条件，比如人家花了两周调提示词、做了大量数据清洗。你只看最终效果，不看到背后成本，期望值很容易崩。永远记住一点：框架只是起点，真正耗时的往往是数据处理、提示词调优、工具接口对接这些脏活。

我自己的选型习惯是三层判断：单人快速原型或非技术团队首选可视化框架；技术团队做深度定制、需要复杂状态管理，首选代码型框架；多Agent分工协作刚需才考虑CrewAI。选型之前先清楚自己属于哪一种，能省一个月弯路。

6. 面向新手和转行者的Agent自学路线：这几个月可以这样安排

前面把原理和工具选型都铺开了，最后专门聊聊学习和转行的实操路径。我给不了什么三个月速成大法，但有一条经过验证的路径，可以帮你少走弯路。整体分三个阶段：先建认知，再写代码，最后学框架。

6.1 阶段一：用两周时间建立大模型基础认知

第一阶段的目标不是写代码，而是把基本概念弄明白。要搞懂的核心知识点包括：Token和计费逻辑、上下文窗口与超限报错、温度参数和控制随机性、提示词的系统角色和用户角色、一次完整的大模型API请求长什么样。

这一阶段用到的资源可以是：模型厂商的官方文档，很多写得已经很通俗了；一些讲大模型基础概念的博客文章和视频；自己注册个API玩玩，在调试台里调参数看输出变化。重点不在于学了什么高大上的架构，而在于把地基概念真正吃透，一些看似简单的细节，后面越学越有价值。

6.2 阶段二：用两到三周手写一个最小Agent

第二阶段就是前面说过的自研环节。目标很明确：把“模型加循环加工具”的机制用原生代码复现一遍，不借助任何Agent框架。这一个阶段做完，你就真正建立了Agent的骨架认知。

建议选择场景时，用日程管理、天气查询、计算器这类功能边界清晰的小工具来练手，不要一上来就做复杂的客服系统。写完之后给自己加进阶需求，比如让Agent同时拥有三个以上工具，看它能不能在复杂指令下正确选择；再加几轮上下文，逼自己实现一个简单的历史消息管理。这个阶段的成就感会特别足，也会为你后续学框架打好基础。

6.3 阶段三：回到框架，带着问题学比通读文档高效十倍

有了前两个阶段的底子，你再学LangChain或者CrewAI，应该带着“这个东西内部是怎么实现的”这种问题去读源码和文档，效率比通读文档高得多。

一个更高效的做法是：选一个框架，找个真实的小项目直接做，比如用LangChain搭一个私密知识库问答机器人，需要你处理文档切分、向量检索、RAG流程编排。把它们做出来之后，你对应用层面的理解会更强。翻译一下刚才说的：先学会走路，再学开车，千万别指望第一天就上赛道。造车不重要，先得会开。

6.4 转行者特别提醒：技术深度不够也不怕，你的优势在其他地方

最后想对非技术背景的转行者多说几句。你们在Agent领域有一个程序员不具备的优势，就是对业务和用户场景的理解力。Agent项目落地，踩坑点往往不在代码，而在对业务需求的拆解、对用户对话逻辑的设计、以及对数据质量的管理。

转行者建议重点补两块：一是把基础的API调用和Python语法学扎实，不需要成为高级工程师，但至少要能自己调通API、能在调试台修改参数；二是把你们擅长的场景理解发挥到极致，用Dify这类可视化工具多搭几个项目，积累作品集。现在很多企业招Agent相关岗位，看的不是学历背景，而是你到底能不能把一个需求从零做成一个可用的Agent。

我个人见过一个运营背景的转行者，用Dify给公司搭了一套私域运营自动回复机器人，从需求梳理到上线全流程都是她一个人搞定的。面试时直接把后台截图和用户反馈一拍，Offer手到擒来。这说明Agent领域和传统开发不太一样，它更看重你能否把技术和场景打通，背景反而没那么重要。

另外再提一个很多人忽略的点：数据思维。Agent输出的质量严重依赖喂给它的数据和工具返回的数据，如果你能帮团队把数据整理干净、格式梳理清晰、接口文档写明白，价值一点都不比写核心代码的人低。

写在最后的一个小提醒

最后再分享一个实际经验：初学阶段，别囤教程。现在的学习资料严重过剩，很多人光收集“Agent学习资料包”“框架入门教程合集”就能花一星期，但真正动手写的时间少得可怜。我自己的经验是，动手写代码才是消耗资料最快的方式。卡住了就去查文档，查完马上回来继续写，循环中学会的东西，远比看教程学会的牢固。

希望你少踩我走过的弯路，把这套路径真正跑起来。如果对自己的项目场景不确定该从哪一步开始，可以先动手写最小Agent，它会告诉你答案。