1. 别急着啃框架，先把地基打牢

1.1 为什么我不建议新手一上来就学 LangChain

我带过不少想转行做 AI Agent 的朋友，十个里有八个第一句话就是：“我是不是该直接学 LangChain？”每次听到这个，我都会先泼一盆冷水——不是 LangChain 不好，而是它太“重”了。你连 Python 的装饰器、异步、类型注解都还没搞明白，就去啃 LangChain 的 Chain、AgentExecutor、Tool 抽象，结果就是照着文档抄一遍能跑，稍微改个需求就彻底懵。

AI Agent 的本质是什么？说白了就是一个能“自己决定下一步做什么”的程序。它接收一个目标，然后循环执行“思考→行动→观察结果→再思考”这个过程，直到任务完成。这个循环在学术界叫 ReAct（Reasoning + Acting），在工程上就是一个 while 循环加上大模型的调用。你用纯 Python 写一个最简陋的 Agent，核心代码不超过 50 行。框架帮你做的，是把工具注册、记忆管理、多轮对话、错误重试这些工程细节标准化了，但如果你不理解底层在干什么，框架对你来说就是个黑盒，出了问题你连从哪查都不知道。

我自己的学习路径是这样的：先用纯 Python 手写一个能调用一两个工具的 Agent，理解 token 是怎么消耗的、消息历史是怎么拼接的、工具调用的 JSON 结构长什么样；然后再去看 LangChain 或者 Spring AI 的源码，你会发现它做的事情你全都认识，只是封装得更优雅。这个顺序反过来，痛苦程度至少翻三倍。

提示：如果你现在连 Python 的虚拟环境、pip 安装、函数定义都还不熟练，先花两周把 Python 基础过一遍，再来看 Agent。这不是浪费时间，是省时间。

1.2 转行者的知识清单：哪些必须会，哪些可以缓

转行做 AI Agent 的人背景五花八门，有做前端的、做测试的、做产品的，甚至完全非技术背景的。我按“必须会”和“可以缓”给你分个类，你对号入座。

必须会的基础（优先级从高到低）：

• Python 基础语法：变量、循环、条件、函数、类、异常处理。不用会元编程，但至少能读懂别人的代码。安装 Python 这件事我就不多说了，官网下载安装包，勾选 Add to PATH，一路下一步就行。版本选 3.10 以上，因为很多 Agent 框架用到了 match-case 语法和新的类型注解特性。
• HTTP 请求与 JSON：Agent 调大模型 API、调外部工具，本质上都是发 HTTP 请求、解析 JSON 响应。你得知道 GET 和 POST 的区别，知道怎么用 requests 库发请求，知道 JSON 的嵌套结构怎么取值。
• 环境管理：virtualenv 或者 conda 至少会一个。我见过太多人把所有包装在全局环境里，最后版本冲突到怀疑人生。用python -m venv myenv创建一个干净环境，这是基本素养。
• 命令行操作：cd、ls、mkdir、cat 这些不用说了，pip install、python xxx.py 得会。如果你在 Windows 上，PowerShell 的基本命令也得熟悉。

可以缓一缓的：

• 异步编程：asyncio、await 这些，等你需要并发调用多个工具的时候再学也不迟。初期用同步代码完全够用。
• Docker 和部署：本地跑通了再考虑部署的事。很多新手连本地都没跑起来，就开始研究 Kubernetes，纯属本末倒置。
• 特定框架的深入源码：LangChain、Spring AI、Dify 这些，等你手写过一个 Agent 之后再去挑一个深入，效果完全不一样。

1.3 一个最小可用的 Agent 长什么样

我给你描述一下一个最简 Agent 的骨架，你感受一下它到底有多“薄”。核心就三部分：一个循环、一个提示词模板、一个工具调用解析器。

循环的逻辑是：把用户的问题和当前的消息历史发给大模型，大模型返回一个响应。如果响应里包含工具调用的指令，你就执行对应的工具，把结果追加到消息历史里，然后再次调用大模型。如果响应里没有工具调用，说明模型认为可以直接回答，循环结束，输出结果。

提示词模板的作用是告诉模型：“你可以使用以下工具，格式是 JSON，工具列表是这些。”工具调用解析器就是把你定义的工具函数和模型返回的 JSON 对应起来，执行函数并返回结果。

就这么简单。你手写一遍这个流程，对 Agent 的理解会比看十篇教程都深。而且你会发现，所谓的“主流架构”无非是在这个骨架上加了记忆模块、规划模块、多 Agent 协作模块。骨架清楚了，加什么都是顺理成章的事。

2. 核心概念拆解：Token、MCP 和工具调用到底怎么回事

2.1 Token 不是钱，但比钱还金贵

很多人第一次用大模型 API 的时候，看到计费单位是“token”，一脸懵。Token 是什么？你可以把它理解成模型处理文本的“最小单位”。英文里一个单词大概对应 1 到 2 个 token，中文里一个汉字大概对应 1 到 2 个 token。模型不是按字数收费的，是按 token 数收费的。

为什么 Agent 开发要特别关注 token？因为 Agent 的循环机制会导致 token 消耗量急剧膨胀。你问一个问题，模型思考一次，消耗 token；调用工具，工具返回结果，这个结果也要塞回消息历史，又消耗 token；模型再思考，再消耗。一个稍微复杂点的任务，来回五六轮，token 用量可能是普通对话的几十倍。

我实测过一个简单的场景：让 Agent 查一下某个城市的天气，然后根据天气推荐穿什么衣服。就这么一个任务，因为中间调用了天气 API，把 API 返回的 JSON 塞回了上下文，最终消耗的 token 是直接问“今天穿什么”的 8 倍左右。所以你在设计 Agent 的时候，一定要有 token 意识：工具返回的结果能不能精简？消息历史能不能做摘要压缩？这些优化直接关系到你的 API 账单。

注意：不同模型的 token 计算方式不一样，中文和英文的 token 比例也不同。你在估算成本的时候，最好用官方提供的 tokenizer 工具实际算一下，别凭感觉。

2.2 MCP 是什么，为什么它突然火了

MCP 全称是 Model Context Protocol，翻译过来叫“模型上下文协议”。你可以把它理解成 AI Agent 世界的“USB 接口标准”。在没有 MCP 之前，你想让 Agent 调用一个外部工具，比如查数据库、读文件、调某个 SaaS 服务的 API，你得为每个工具单独写适配代码。工具一多，代码就乱成一锅粥。

MCP 做的事情，是定义了一套标准协议，让工具提供方和 Agent 开发方解耦。工具提供方按照 MCP 规范暴露自己的能力，Agent 开发方按照 MCP 规范去发现和调用这些能力。两边不用互相认识，只要都遵守协议就能对接上。

这个思路其实在软件工程里很常见，就像你电脑上的 USB 接口，不管你是鼠标、键盘还是U盘，插上去就能用，因为大家都遵守 USB 协议。MCP 就是 AI 工具生态的 USB 协议。

现在你看到的各种“xxx MCP”，比如 Playwright MCP、IDA MCP、Figma MCP，本质上都是有人把某个工具的能力按照 MCP 规范包装了一层，让 Agent 可以直接调用。Playwright MCP 让 Agent 能操作浏览器，IDA MCP 让 Agent 能分析二进制文件，Figma MCP 让 Agent 能读取设计稿。这些在以前都需要写大量胶水代码，现在只要接上对应的 MCP Server 就行。

2.3 工具调用：Agent 的“手”是怎么伸出去的

工具调用是 Agent 区别于普通聊天机器人的核心能力。普通聊天机器人只能动嘴，Agent 能动手。这个“动手”的过程，技术上是怎么实现的？

大模型本身是不能直接执行代码的，它只能输出文本。工具调用的本质是：你在提示词里告诉模型“你有这些工具可用，如果你想用某个工具，就按照这个格式输出一段 JSON”。模型在生成回复的时候，如果判断需要用工具，就会输出这段 JSON。你的程序解析这段 JSON，找到对应的函数，执行它，把结果再喂回给模型。

举个例子，你定义了一个get_weather(city)函数。你在提示词里写：“如果用户想知道天气，你可以调用 get_weather，参数是城市名，输出格式为{"tool": "get_weather", "args": {"city": "北京"}}。”模型收到“北京今天天气怎么样”这个问题后，就会输出那段 JSON。你的程序捕获到 JSON，调用get_weather("北京")，拿到结果“晴，25度”，再把结果拼成一条消息发给模型。模型最后生成“北京今天晴天，25度，适合穿短袖”。

整个过程里，模型负责“决策”，你的代码负责“执行”。模型是大脑，你的代码是手脚。理解了这个分工，你就理解了 Agent 的工作原理。

3. 实操路径：从零手写到框架选型

3.1 第一步：用纯 Python 写一个能查天气的 Agent

我建议你第一个练手项目就做天气查询 Agent，因为天气 API 免费、简单、返回结构清晰，非常适合入门。你不需要用任何框架，就用 requests 库调大模型 API，用标准库写循环。

具体步骤是这样的。先去申请一个大模型 API Key，国内国外都有很多选择，选一个你方便付费的就行。然后写一个函数call_llm(messages)，把消息列表发给模型，返回模型的回复。再写一个函数get_weather(city)，调用天气 API 返回结果。主循环里，你把用户问题和工具说明拼成提示词，调用call_llm，解析返回的 JSON，如果包含工具调用就执行get_weather，把结果追加到消息列表，再次调用call_llm，直到模型不再调用工具为止。

这个项目我建议你至少写两遍。第一遍照着教程写，能跑通就行。第二遍关掉教程，自己从空白文件开始写，遇到卡住的地方再查。第二遍写完，你对 Agent 的理解就完全不一样了。

提示：天气 API 有很多免费额度，注册一个账号就能用。返回的 JSON 里通常包含温度、湿度、天气状况、风力等信息，你可以在提示词里告诉模型这些字段的含义，让它生成更自然的回答。

3.2 第二步：给 Agent 加上记忆和多个工具

第一个版本跑通之后，你会发现两个问题。第一，Agent 没有记忆，每次对话都是全新的，上一轮说了什么它完全不记得。第二，只有一个工具太单调了，想让它同时能查天气、查时间、做计算，怎么办？

记忆的实现其实很简单，就是维护一个消息列表，每次调用模型的时候把历史消息一起发过去。但这里有个坑：消息列表不能无限增长，否则 token 会爆炸。你需要做一个简单的截断策略，比如只保留最近 10 轮对话，或者当消息列表超过一定长度时，让模型自己总结一下之前的对话，用摘要替代原始消息。

多工具的实现也不复杂。你定义一个工具注册表，把每个工具的名称、描述、参数格式、对应的函数都存进去。在生成提示词的时候，遍历注册表，把所有工具的描述拼进去。在解析模型返回的时候，根据工具名称去注册表里找对应的函数执行。这样你加一个新工具，只需要在注册表里加一条记录，不用改主循环的逻辑。

这个版本写完，你基本上就理解 LangChain 的 Tool 和 Memory 模块在干什么了。再去看它的文档，会有一种“哦，原来你是在帮我做这件事”的感觉。

3.3 第三步：框架选型，LangChain、Spring AI 还是别的

等你手写过一个完整的 Agent 之后，再来看框架选型，思路会清晰很多。我按不同的使用场景给你分析一下。

LangChain：Python 生态里最流行的 Agent 框架，工具链最全，社区最大。优点是文档多、示例多、遇到问题容易搜到答案。缺点是抽象层太厚，版本迭代快，经常出现“昨天能跑的代码今天报错”的情况。适合快速做原型、做实验，不太适合对稳定性要求极高的生产环境。

Spring AI：Java 生态的 Agent 框架，如果你本身是 Java 技术栈，或者公司项目是 Spring Boot 的，选它最合适。它的设计思路和 LangChain 类似，但更贴近 Spring 的编程习惯，依赖注入、配置管理这些都很自然。缺点是生态还在建设中，工具库没有 LangChain 那么丰富。

Dify、CrewAI 等低代码平台：如果你不想写太多代码，或者想快速搭一个能用的 Agent 给非技术人员用，这些平台值得一试。Dify 的可视化编排做得不错，CrewAI 的多 Agent 协作概念很清晰。但低代码平台的通病是灵活性受限，遇到平台不支持的需求就很麻烦。

我的建议是：先手写，再选框架。手写让你知道底层发生了什么，选框架让你知道哪些轮子不用自己造。顺序不能反。

3.4 第四步：理解 Agent 的主流架构模式

你手写过、也用过框架之后，可以回头看看 Agent 的几种主流架构模式。这些模式不是非此即彼的，很多时候是混着用的。

ReAct 模式：最基础的模式，就是“思考-行动-观察”循环。适合任务步骤不太确定、需要模型根据中间结果动态调整的场景。缺点是容易陷入死循环，需要设置最大轮次限制。

Plan-and-Execute 模式：先让模型制定一个完整的计划，然后按计划逐步执行。适合步骤明确、可以提前规划的任务。优点是效率高，不用每步都问模型；缺点是计划一旦有误，后面全错。

Multi-Agent 模式：多个 Agent 各司其职，有的负责规划，有的负责执行，有的负责审核。适合复杂任务，但通信成本和调试难度都大幅上升。新手不建议一上来就搞多 Agent，先把单 Agent 玩明白。

Reflection 模式：Agent 执行完一步之后，自己反思一下“我做得对不对”，如果不对就重来。这个模式能显著提升输出质量，但 token 消耗也会翻倍。

我个人的经验是，80% 的场景用 ReAct 就够了，剩下 20% 里有一半可以用 Plan-and-Execute 解决，真正需要 Multi-Agent 的场景少之又少。别为了炫技而过度设计。

4. 踩坑实录：新手最容易翻车的几个地方

4.1 提示词写得太随意，模型根本不按套路出牌

我见过太多人写提示词就像在跟朋友聊天：“你帮我看看今天天气呗。”然后抱怨模型不调用工具。兄弟，模型不是人，它需要明确的指令。你得告诉它：你有哪几个工具、每个工具的参数是什么、输出格式是什么、什么情况下该用哪个工具。

一个好的工具调用提示词，至少包含这几部分：角色定义（你是一个助手，可以调用工具）、工具列表（名称、描述、参数格式）、输出格式（JSON schema）、约束条件（如果不确定就说不确定，不要瞎编）。这四部分缺一不可。

还有一个坑是工具描述写得太模糊。比如你写“查询信息”，模型根本不知道查什么信息。你得写“根据城市名称查询当前天气状况，包括温度、湿度、风力”。描述越具体，模型调用越准确。

4.2 消息历史管理不当，token 烧得心疼

前面提过 token 的问题，这里展开说。Agent 的消息历史里，最占 token 的往往是工具返回的结果。比如你调了一个 API，返回了一大坨 JSON，里面 90% 的字段模型根本用不到。你把这坨 JSON 原封不动塞回上下文，纯属浪费。

我的做法是，在工具函数里就把返回结果精简一下，只保留模型需要的字段。比如天气 API 返回了 20 个字段，我只取温度、天气状况、风力三个，拼成一句自然语言“晴，25度，微风”，再返回给模型。这样 token 消耗能降一个数量级。

另外，消息历史的截断策略也很重要。我一般设置一个 token 上限，比如 4000 token，超过就把最早的消息删掉。但删的时候要注意，不能把系统提示词删了，也不能把工具调用的请求和结果拆散，否则模型会困惑。

4.3 工具调用失败不处理，整个 Agent 直接崩

工具调用失败是常态，不是异常。网络超时、API 限流、参数格式错误，这些都会发生。如果你的代码没有错误处理，一个工具调用失败就会让整个 Agent 抛异常退出。

正确的做法是，在工具执行的外层包一个 try-except，捕获所有异常，把错误信息作为工具返回结果塞回给模型。模型收到错误信息后，可能会尝试换一种方式调用，或者直接告诉用户“我暂时查不到”。这样 Agent 至少不会崩，用户体验也好很多。

还有一个细节是超时设置。调外部 API 一定要设超时，不然一个请求卡住，整个 Agent 就挂在那里了。我一般设 10 秒超时，超过就返回“请求超时，请稍后重试”。

4.4 常见问题速查表

提示：调试 Agent 的时候，一定要把每轮的消息历史打印出来。很多时候你看一眼消息历史，就知道问题出在哪了。别偷懒，打印日志是最高效的调试手段。

4.5 关于学习节奏的一点个人体会

最后说点虚的，但我觉得比技术本身更重要。AI Agent 这个领域变化太快了，今天流行的框架明天可能就过时了，今天的最佳实践明天可能就被推翻了。如果你追着热点跑，会非常累，而且永远追不上。

我的策略是：抓底层，放表层。底层是什么？是大模型的基本原理、是 HTTP 和 JSON、是 Python 编程能力、是软件工程的基本功。这些东西五年十年不会变。表层是什么？是某个框架的某个 API、是某个平台的某个功能。这些东西半年就换一茬。

你把底层抓牢了，表层的东西花两天看看文档就能上手。反过来，你只学表层，底层一塌糊涂，换个框架你就废了。我见过太多人简历上写“精通 LangChain”，结果让他手写一个 Agent 循环都写不出来。这种“精通”是虚的，面试官一问就露馅。

所以回到标题那句话：新手和转行者先学什么？先学 Python，先学 HTTP 和 JSON，先手写一个最简陋的 Agent。别一上来就啃框架，那不是捷径，那是弯路。等你把这些基础打牢了，LangChain 也好，Spring AI 也好，MCP 也好，都是水到渠成的事。