有朋友问我搞 AI Agent 到底该看什么、学什么、练什么。这问题看着简单实际上一头扎进去很容易懵。AI Agent 方向的知识点散落在论文、框架文档、开源项目和大佬博客里不像传统后端有清晰的《某某入门到精通》可以照单全收。今天这一篇我就把自己整理 AI Agent 学习资料的过程、信息源、踩过的坑、以及目前沉淀下来的学习路线一次性摊开来讲希望能帮你少走弯路。这篇内容不只是一份“书单”或者“链接合集”我会把每个资料之间的逻辑关系也一并梳理清楚。你拿过去可以直接当一份行动指南来用先看什么建立认知框架再看什么补全技术细节最后练什么能真正把 Agent 跑起来。适合刚接触 Agent 的开发者也适合已经在写 LLM 应用、但觉得自己对 Agent 的“智能体属性”理解还不够透的人。1. 先搞清楚要学什么AI Agent 的知识地图1.1 一份很容易“学歪”的领域很多人学 Agent 容易走两个极端。一个极端是把它当成“调 OpenAI API 的进阶版”整天研究 prompt 怎么写、temperature 调多少另一个极端是把它当成“分布式系统 知识图谱 强化学习”的缝合怪资料越看越深最后啥也没落地。我的看法是AI Agent 这两个字背后其实有三层东西要分开学第一层是LLM App 层怎么用大模型做工具调用、结构化输出、多轮记忆。这是绝大多数项目用到 Agent 的日常形态。第二层是Agent 架构层Planning规划、Memory记忆、Tool Use工具使用、Reflection反思、Multi-Agent 协作这些概念以及它们在 LangChain / LangGraph / AutoGen / MetaGPT 等框架里是怎么落地的。第三层是Agent 数据层与评测层Agent 跑起来之后产生的轨迹数据怎么存、怎么回放、怎么评估效果。没有这一层做出来的 Agent 就是个黑盒玩具。如果照着“三层”去收集资料你会发现市面上的学习资源其实都能归位。有些人一上来就啃 Agent 论文连 ReAct 是什么都没搞清效果很差反过来只玩框架不读论文遇到 Agent 行为失控时也不知道怎么排查。所以我的建议学习顺序是实践框架 - 读经典论文 - 理解评测 - 自己写一个简单 Agent。1.2 到底什么才算“Agent”还没入门的同学可以先记住一个区分不是所有 LLM 应用都叫 Agent。你写一个 prompt 让模型做翻译那是“自然语言处理”你让模型在回答之前先决定“要不要搜索一下网页、要不要调用一个计算器”并且模型有权限循环执行“观察-思考-行动”的流程这才是 Agent 的雏形。我经常用一个类比来解释传统程序像自动售货机你投币按按钮它固定出货Agent 像一个实习生你给它一个目标它自己琢磨需要哪些工具、按什么顺序用、中途发现走不通还会换个方案。这个“自己琢磨”的过程就是 Agent 和普通 API 调用最大的区别。所以学习资料里如果通篇只教你“怎么写 prompt 让模型输出 JSON 给函数传参”那它其实还是在讲 API 调用没进入 Agent 的范畴。1.3 学习资料的“分类学”我把自己收藏的资料分成五类后面每一类我都会展开讲系统性内容书、长文、课程适合建立框架。代码与框架开源项目、官方文档、示例代码适合动手跟练。论文与博客经典论文、业界大牛的博客适合深入理解原理。面试题与测试题Agent 岗位的面试高频点、测试实战案例适合检验掌握程度。趋势与热点行业报告、2026 趋势预测适合做技术选型和职业规划。这个分类不算学术但我用下来很实用。学习不是线性读完一本书而是“框架 - 实操 - 复盘 - 深入 - 再实操”循环爬升资料分类正好匹配爬升的每一级。2. 资料避坑指南哪些真值得看哪些是浪费时间2.1 经典书籍与长文第一手认知来源如果只让我推荐一份“入门级系统性阅读材料”我会先推李博杰的《深入理解 AI Agent》相关分享内容现在在网上能搜到不少他的演讲文稿和课程 PDF。这位作者常年做 Agent 底层研究讲问题喜欢从“Agent 为什么需要记忆、为什么需要反思”这种本源问题切入而不是上来就贴代码。看他的内容你对 Agent 的“心智层”会有一种豁然开朗的感觉。不过要提醒一点这类 PDF 和文稿通常不是一个体系完整的教材更像一份深度拆解的报告。读的时候我建议你边读边画图——把 Agent 的内部循环感知、决策、行动和外部交互用户、工具、环境之间的关系画成一张图。不要只看文字否则看完了你只知道“Agent 很牛”却说不清它内部怎么转。另外一本经常被提起的是《AI Agents in Action》这类国外新书内容覆盖从 prompt engineering 到 multi-agent systems。国外的书写得比较“工程化”喜欢给你一个端到端项目这一点跟国内一些写作风格偏“概念化”的内容不太一样。我的建议是想快速上手选国外偏工程的书想建立思维深度看国内深度拆解类的内容两边的营养不一样最好都吸收一点。2.2 开源框架与官方文档动手能力的核心来源框架文档是绝对绕不开的。目前主流框架我都过了一遍简单说说它们的定位差异方便你按需选择LangChain生态最大资料最多适合快速验证各种 Agent 想法。缺点是抽象层级多出了问题想深入排查时比较费劲。LangGraphLangChain 团队后面推出的把 Agent 流程显式建模成图结构。我更推荐有状态机思维的开发者深入使用因为它更接近 Agent 运行逻辑的真相。AutoGen微软出品主打多 Agent 对话协作。适合研究多个 Agent 之间怎么聊天、怎么分工。MetaGPT国内团队做的主打“软件公司模拟”让 Agent 扮演产品经理、架构师、工程师。适合看多 Agent 协作的完整落地形态。CrewAI主打角色扮演和任务编排代码量少适合快速搭建一个小团队。学习框架最大的坑就是“看文档觉得都会一跑就废”。我建议不要通读整个文档而是每个框架先跑通它的官方快速入门示例然后把示例里的关键组件改一改比如把一个“简单的问答 Agent”改成“能查数据库的 Agent”你就理解了 tool calling 是怎么回事再改成“有记忆的 Agent”你就知道 memory 组件要接在哪。2.3 编程语言视角的补充材料热词里有一串很有意思java ai agent、springboot ai agent 客户端。这反映出 Agent 开发不只是 Python 圈的专利Java 生态的人也在积极拥抱。如果你是个 Java 后端看到 Python 的 LangChain 教程会觉得“这怎么落地到我现有项目里”这时候我建议看 Spring AI 的相关内容。Spring AI 是 Spring 官方以及社区在 AI 应用层面做的一套抽象思路是把 LLM 调用、向量数据库、结构化输出这些东西往 Spring 的 Bean 模型上靠。之前很多人以为 Java 做不了 Agent其实 Spring AI 加上一些 Agent 编排逻辑是完全能跑起来的只是资料没有 Python 生态那么丰富。我认识的一个资深 Java 工程师朋友就是把 LangChain 的 AgentExecutor 概念用 Spring Boot 重写了一遍配合函数调用和 Redis 缓存最后做出来的 agent 服务稳定性和并发能力反而比 Python 版本更好。如果你是 Java 背景先别急着转 Python。你要学的不是“换个语言”而是“Agent 的核心概念怎么翻译成 Java 的类、接口、消息队列”。等你用 Spring Boot 把一个 Agent 客户端跑通再回来理解 Python 框架里的 Tool、Memory、Planner你会发现都是同一套东西换了层皮。2.4 容易被忽略的“精华碎片”博客、会议与论文系统性资料适合搭骨架但真正让你跟别人拉开差距的往往是那些“碎片化但极深”的内容。我特别推荐去看一些业内大牛的博客和公开分享比如李博杰的各种分享记录、Lilian Weng 的经典博客、以及各类 Agent 相关的技术会议实录。Lilian Weng 那篇《LLM Powered Autonomous Agents》属于必读中的必读。它把 Agent 拆成了规划、记忆、工具使用三个模块每个模块讲了现有哪些做法、有什么问题。这篇博客我刷了不下三遍每次看完都有新理解因为自己的工程经验在涨能看懂的东西也在变。如果你英文阅读有压力可以先找中文翻译版但最后还是要回到原文因为翻译版会丢失很多术语之间的呼应。论文方面我建议按时间线读这几篇每篇读摘要和核心方法就够了不用死磕数学ReAct让模型交替输出 Thought/Action/Observation这是 Agent 最基本的行为模式。Reflexion在 ReAct 基础上增加“反思”机制让 Agent 在失败后总结教训。Toolformer / Gorilla研究模型怎么学会调用工具。Generative Agents斯坦福那个 25 个 AI 小镇居民的论文讲记忆流和社交行为对理解长期记忆非常有启发。Tree of Thoughts讲推理时的搜索策略是规划模块的重要参考。如果对中文圈子更熟悉国内也有不少优秀的技术博客和公众号搬运和解析速度非常快。但注意二手解读终归是别人咀嚼过的东西你吸收效率高却有失真风险。我的习惯是“二手内容获得线索一手论文/文档确认细节”。3. 从 0 到 1 的实操路径怎么把 AI Agent 跑起来3.1 第一个 Agent五步法很多教程喜欢一上来就上 LangChain 全家桶结果新手光安装依赖就装了一天。我自己带人走过一遍觉得最快的路径是先不用框架用裸的模型 API 写一个能调用工具的 Agent。第一步选一个支持 function calling 的模型比如 OpenAI 的 GPT 系列、Claude 系列或者国内的通义千问、智谱 GLM 系列。注册好拿 API Key。第二步定义一个简单的工具函数比如get_weather(city)、calculate(expression)。注意工具函数的定义要用 JSON Schema 格式写清楚参数因为模型要靠这个 Schema 决定怎么调用。第三步写一个循环。循环体就三件事把当前对话历史和工具定义发给模型检查模型返回的是“正常回复”还是“工具调用请求”如果是工具调用请求就执行工具把结果拼回去再让模型继续思考。第四步设置最大轮数防止 Agent 陷入死循环。我第一次写的时候没设上限模型反复调用同一个工具停不下来白白烧了几毛钱 API 费用。这个教训很深刻。第五步打印每一轮的中间过程你会看到模型内部是怎么“思考”的。这一步是理解 Agent 运行逻辑最直观的方式比读任何书都管用。这段代码其实写起来非常简单核心循环不到 50 行。你亲手写完一遍之后再去看 LangChain 的 AgentExecutor 源码会发现它本质上就是把你这个循环抽象化、通用化了那一刻你会觉得框架不再神秘。3.2 框架实践用 LangGraph 搭建带反思的 Agent裸写一遍之后我建议紧接着进入 LangGraph 的世界。为什么不是 LangChain因为 LangGraph 的图结构能真实反映 Agent 的“运行逻辑”——你需要在图上明确画出节点执行哪一步、边下一步走向哪里、条件分支什么情况下进入反思。用 LangGraph 做一个带反思的 Agent核心步骤包括定义状态对象。LangGraph 里所有节点共享一个 state你可以往里面塞消息列表、中间结果、错误信息。定义“生成节点”和“反思节点”。生成节点负责让模型产出答案反思节点负责评价答案质量。用条件边连接如果反思节点认为答案不行回到生成节点重新生成如果质量合格进入结束节点返回给用户。给整个图加上循环限制和超时控制。LangGraph 提供了recursion_limit参数我一开始没注意图循环次数一多直接把 API 配额打满了。我强烈建议把这段代码跑通后打印出每一步的状态变化。你会在终端里看到 Agent 从“生成一个答案”到“反思这个答案哪里有问题”再到“修改答案”的全过程。这个过程会让你对 Agent 和普通 LLM 应用的区别产生肌肉记忆。3.3 场景化练手知识库、绘图工具与代码生成光会跑 demo 还不够要把 Agent 放到真实场景里才算学会。热词里有几个方向特别适合练手我逐个说一下Obsidian Agent 知识库。我个人比较喜欢这个场景因为 Obsidian 的笔记本质是本地 Markdown 文件非常适合做 RAG检索增强生成。你可以把 Obsidian 的 vault 目录变成一个本地知识库用 Embedding 模型给每篇笔记生成向量然后用 Agent 作为问答入口。实现思路是用户提问 - 检索相关笔记片段 - 把片段拼进 context - 让模型回答。这个项目做完你对 RAG 的理解会直接从“看了篇文章”升级到“能说出 chunk size 怎么影响检索结果”。AI Agent 生成 Verilog 代码。这个热词让我有点意外但细想很有前途。Verilog 是一种硬件描述语言写起来规则多、模板性强非常适合大模型生成。如果你有 EDA电子设计自动化背景可以试着做一个“自然语言 - Verilog 模块代码”的 Agent模型先生成代码再调用一个仿真工具比如 Icarus Verilog做语法检查检查不通过就自动修改。这就是“代码生成 Agent”的硬件版做出来非常炫酷在简历上也是很强的加分项。draw.io 与 Agent 对接。next ai draw.io这个热搜说明有人想把 AI Agent 接进绘图工具。从架构上讲有两种思路一是让 Agent 生成 Mermaid 或 PlantUML 代码再导入 draw.io 渲染二是让 Agent 直接调用 draw.io 的文件格式XML生成图表。第一种简单很多适合练手因为 Mermaid 语法模型比较擅长生成正确率很高。我第一次用 Agent 画架构图时它直接把整个系统拓扑用 Mermaid 画出来了那份成就感还是很强的。3.4 测试实战Agent 到底怎么测“AI Agent 测试实战”是热词也是实际工作中最难啃的骨头。传统软件测试是确定性断言——输入 A期待输出 B。Agent 的行为天然带有随机性同样的问题可能每次回答细节都不同这该怎么测我的实践经验是Agent 测试要分三层第一层是特性测试单元级。针对工具函数、状态转换逻辑用传统测试框架pytest/JUnit覆盖。这一层跟普通测试没有区别。第二层是交互测试集成级。模拟用户输入期望 Agent 的“行为路径”是符合预期的。比如你让 Agent 订机票你断言的不是它的自然语言回答内容而是它是否调用了search_flight工具以及调用时的参数是否正确。这一步非常关键与其测“回答内容”不如测“工具调用序列”。工具调用序列本质上是结构化数据可以做严格比较。第三层是效果评估Eval 级。用一组评测集跑 Agent根据重要指标打分。常见的指标包括任务完成率、工具调用成功率、一回合成功率、用户满意度LLM-as-a-Judge 打分等。这一层需要你设计评测集就像给 Agent 准备一张“考卷”。新手最容易犯的错是跳过第一层和第二层直接想第三层。结果评测集做得再漂亮Agent 的工具调用逻辑有 bug分数低却定位不到问题在哪。我的建议是先用三层测试框架把测试体系搭起来再上线。4. 检验学习成果Agent 面试题与常见问题的实战梳理4.1 高频 Agent 面试题清单学完一轮、也练完几个项目之后很多朋友会用“刷 Agent 面试题”来检验自己。我梳理了一些出现频率极高的问题你拿这些问题对照自己的储备ReAct 和 Function Calling 是什么关系这两个概念经常被搞混。简单说Function Calling 是模型接口层的能力ReAct 是 Agent 架构层的模式。前者是“模型能把自然语言映射成结构化函数调用”后者是“Agent 在思考和行动之间交替循环”。Agent 的长期记忆和短期记忆在工程上分别怎么实现短期记忆通常是上下文窗口长期记忆要引入向量数据库或者 KV 存储。当 Agent 调用工具的返回结果不符合预期时应该怎么处理这个问题考察异常处理和反思机制。你怎么设计一个 Agent 来让模型不会陷入“重复循环”常见解法是设定最大迭代次数、增加反思条件、让工具返回更结构化的错误信息。多 Agent 协作时怎么解决“上下文淹没”问题多个 Agent 之间频繁传递消息token 消耗非常大需要设计消息摘要机制。如何评估你的 Agent 比别人的 Agent 好你要能说出来评测集是什么、指标是什么、基线是什么。每道题如果你能用“论文背景 工程实现 踩坑经历”三层结构来回答会非常加分。只答概念是背题加工程细节才是真理解。4.2 实际运行中容易踩的坑我把自己做 Agent 项目踩过的坑集中列一下希望你能绕开第一个坑是工具描述写得不够好。很多人定义工具时随便写一句“查询天气”结果模型老是不调用。原因在于模型只能靠你的描述来理解工具的适用场景。你把工具描述改成“当用户询问任意城市当前天气、温度、湿度时调用该工具获取实时数据参数 city 为城市中文名”调用率会大幅提升。这算 Prompt 工程的一部分但在工具调用场景里尤其重要。第二个坑是忽略 token 成本。Agent 循环中每次都要把工具定义塞到请求里工具一多一次请求的 token 量快速增长。解决办法是动态选择工具不要让模型每次都看全部工具列表。现在很多框架支持工具路由只把可能用到的几个工具塞给模型。第三个坑是“这个 Agent 看起来能跑但没人知道它准不准”。如果你没有一个评测集你是无法判断改了一版 prompt 之后 Agent 是变好了还是变差了。我在做 RAG 类 Agent 时会先准备 50~100 条高质量问答对每条包含“问题内容、期望回答来源、关键打分点”。每次迭代都先跑一遍评测集分数涨了才算进步。这一条强烈建议所有做 Agent 的人都尽早用起来。4.3 测试实战速查表我觉得一张速查表能帮你在做 Agent 测试时快速对齐思路这里分享我常用的表格设计测试层级核心对象典型断言方式常用工具单元测试工具函数、状态转换输入输出严格匹配pytest、JUnit集成测试Agent 行为路径工具调用序列是否符合预期pytest mock、LangSmith效果评估任务完成质量任务完成率、工具调用成功率、LLM-as-a-Judge自建评测集、Ragas上线监控线上真实流量用户反馈、失败率、延迟、成本LangSmith、自建日志系统注意表格里的“工具调用序列”是集成测试的灵魂。你不需要让 Agent 真的去调外部 API可以用 mock 工具函数来固定返回结果这样断言更稳定。我一般会先确认 Agent 的调用序列是稳定的再做效果评估否则评估分数波动大根本没法分析。5. 整理一份“当前最佳清单”按需求速查如果你现在时间非常紧张想在今天之内把学习方向定下来下面是我从资料库里精选出来的一份“最小必要清单”认知入门看李博杰的 Agent 深度分享文稿或视频建立“什么是真正的 Agent”的第一印象。原理核心读 ReAct 和 Generative Agents 两篇论文的摘要和核心方法描述知道 Agent 的基本循环和最前沿的记忆设计。工程起步用裸 API 实现一个 50 行的 Tool Calling 循环跑通“思考-调用-观察”的最小闭环。框架进阶用 LangGraph 搭一个带反思节点的 Agent亲眼看一遍迭代过程。评测闭环准备 20 条评测问题给 Agent 建立最简单的“考卷”每改一版就考一次。领域落地根据自己的主业选一个场景Java 后端就看 Spring AI知识工作者就看 ObsidianRAG硬件工程师就看 Verilog 生成。这份清单适用于“想快速进入状态”的人。如果你已经跑完一轮再回来按 2.1~2.4 的分类去找更深入的内容即可。6. 关于 2026 趋势学习方向该往哪调热词里有“ai agent 2026 发展趋势预测”我也说一说自己的判断。这个判断会影响你接下来学习资料的权重分配。第一Agent 会从“单智能体”走向“多智能体协作”。目前大多数落地项目是单个 Agent 在处理任务2026 年你会看到更多“多角色、多 Agent”配合完成复杂业务流的案例比如一个 Agent 负责信息检索另一个负责方案生成第三个负责质量审查。这意味着你现在就应该熟悉至少一个多 Agent 框架并把“消息传递”“任务编排”当作 Agent 的基本功。第二评估和可观测性会成为硬需求。企业敢不敢把 Agent 放到生产环境核心不是模型聪明不聪明而是出了问题能不能快速定位、效果能不能量化。所以 LangSmith、Helicone 这类可观测性工具以及 RAGAS 这类评测库会越来越重要。你现在学测试不是提前卷而是卡位。第三Agent 开发会跟行业场景深度绑定。通用 Agent 不会消失但真正产生价值的一定是深入业务场景的“专业 Agent”。比如前面提到的硬件代码生成、Java 后端的业务 Agent、知识库问答 Agent都属于这个范畴。你学习时最好带着自己的行业问题去练不要老停留在“写个通用聊天机器人”的水平。这些判断不一定全对但它会帮你筛选资料凡是能帮你提高“多智能体架构能力”“评测能力”“场景落地能力”的内容2025~2026 年都值得投入时间。7. 我的个人学习心得与建议学 AI Agent 和学传统框架最大的不同是这个领域变化太快你没法靠“一本书吃半年”。我现在的习惯是每两周逛一遍 GitHub 上 Agent 相关项目的新星榜每周抽一小时看两三篇高质量博客所有内容看完后都写 100 字左右的总结放进自己的 Obsidian 知识库。这套方法看起来笨但我的知识库已经积累了近百条 Agent 相关的卡片每次写新项目时检索自己的笔记比临时 Google 高效太多。还要说一句心里话不要迷恋“最新”。很多人喜欢一看到新框架就扑上去连基础的 ReAct 循环都没写通过。我见过太多人 LangChain 用了半年问他 Agent 一次完整运行过程分几步答不上来。工具是外功运行逻辑是内功。先把内功练好再花式换外功你会觉得所有框架都长得差不多。如果你能按这篇文章的路径走一遍——建立认知框架、动手写最小 Agent、深入一个框架、做一套评测、再回到行业场景练手——我相信你对 AI Agent 的理解会超过绝大多数只刷教程的人。后边如果你在实操里遇到具体问题带着问题再来找我聊效果会更好。