1. 从零到一：AI Agent 学习资料到底该怎么啃
这两年 AI Agent 这个词被喊得震天响，但真正动手搭过、踩过坑、上线过的人其实没想象中那么多。我前后用 LangChain、LangGraph、FastAPI、Spring AI、Rust 生态里的几个框架都折腾过一轮，也带过几个朋友从零入门，发现大家卡住的地方高度一致：不是不会写代码，而是不知道学习路径该怎么排，资料看了一堆，真到动手时还是不知道从哪下手。这篇就把我整理的 AI Agent 学习资料体系完整拆一遍，从概念到框架选型，从单 Agent 到多 Agent 协作，从本地跑通到扛并发上线，尽量把每一步的“为什么”讲清楚。
先说清楚这份学习资料适合谁。如果你是完全没接触过 LLM 应用开发的程序员，它能帮你把学习顺序理顺，避免一上来就啃 LangGraph 源码被劝退；如果你已经会调 OpenAI API、写过简单的 RAG，那这份资料能帮你补齐 Agent 的核心心智模型——工具调用、状态管理、循环控制、并发与容错；如果你是做后端出身、想用 Spring AI 或者 Rust 来搭 Agent 的，里面关于框架选型和工程化的部分会更有参考价值。核心关键词就一个：AI Agent 学习路线，围绕它展开的所有技术点，我都会给出可复现的路径。
我个人的判断是，AI Agent 的学习不能按“先学完理论再动手”的顺序来，那样大概率学一半就放弃了。正确的姿势是：先用最小可运行示例跑通一个能调用工具的 Agent，建立直觉，然后再回头补 Prompt 工程、状态机、并发这些硬骨头。下面这份资料体系就是按这个逻辑组织的，你可以直接照着抄作业。
2. AI Agent 核心概念与学习路线拆解
2.1 先搞明白 Agent 和普通 LLM 调用的本质区别
很多人学 Agent 第一个误区，就是把 Agent 当成“更高级的 Prompt”。其实不是。普通 LLM 调用是一问一答，你给输入，它给输出，结束。Agent 的核心在于循环和决策：它拿到任务后，会自己判断下一步该干什么，是调用工具、是追问用户、还是直接给答案，然后根据执行结果再决定下一步，直到任务完成或者达到终止条件。
用生活化的类比：普通 LLM 调用像你问路人“地铁站怎么走”，他给你指个方向就完了；Agent 像你雇了个助理，你说“帮我把这份合同寄出去”，他会自己查地址、找快递、填单子、跟踪物流，中间遇到问题还会回来问你。这个“自己判断下一步”的能力，就是 Agent 的灵魂。
所以学习资料的第一块，必须是Agent 的心智模型：感知（Perception）、规划（Planning）、行动（Action）、记忆（Memory）这四个环节怎么串起来。我建议先看 LangChain 官方那篇 Agent 概念文档，别看代码，先把图看懂。然后自己用大白话把“一个 Agent 处理‘帮我订明天去上海的机票’这个任务”的完整流程写一遍，写到你能说清楚每一步它调用了什么、依赖什么状态为止。这一步过了，后面学框架会快很多。
2.2 学习路线怎么排才不劝退
我试过好几种学习顺序，最后验证下来最不容易放弃的是这条线：
- 第一周：LLM 基础调用 + Prompt 工程。把 OpenAI、通义、DeepSeek 的 API 都调一遍，理解 temperature、max_tokens、system prompt 这些参数的实际影响。别跳过这步，很多人 Agent 调不通，根因是 Prompt 写得稀烂。
- 第二周：Function Calling / Tool Use。这是 Agent 的地基。学会定义一个工具（比如查天气、查数据库），让模型自己决定什么时候调、传什么参数。LangChain 的
@tool装饰器、Spring AI 的@Tool注解、Rust 里 rig 的 tool 定义，本质都一样。 - 第三周：单 Agent 循环 + 状态管理。用 LangGraph 或者自己写 while 循环，实现“思考-行动-观察”的闭环。重点理解状态怎么在节点间传递，什么时候该终止。
- 第四周：多 Agent 协作 + 工程化。学 LangGraph 的 multi-agent、CrewAI 的角色分工，同时补 FastAPI 异步、并发控制、错误重试这些工程能力。
- 持续：项目实战。找一个真实场景，比如“让 AI 自动整理小红书评论并回复”，从头搭到尾。
这条线的好处是每周都有能跑起来的东西，正反馈足。我见过太多人卡在第二周，就是因为想直接跳到 LangGraph，结果连工具调用都没搞明白。
2.3 资料筛选：哪些值得看，哪些是噪音
网上 AI Agent 资料现在多到爆炸，但质量参差。我按自己的使用体验给个筛选标准：
| 资料类型 | 推荐程度 | 说明 |
|---|---|---|
| 官方文档（LangChain/LangGraph/Spring AI） | 必看 | 更新快，示例可跑，但概念解释偏简略 |
| 框架源码 | 选看 | 遇到诡异 bug 时看，别一上来就啃 |
| 视频教程 | 选看 | 适合建立直觉，但很多版本过时 |
| 博客/公众号 | 谨慎 | 大量互相抄，注意看发布时间和代码能否跑通 |
| 开源项目 | 强烈推荐 | 直接读别人怎么组织代码，比看教程快 |
我个人最推荐的方式是：官方文档 + 一个高质量开源项目 + 自己动手改。比如你想学 LangGraph，就去找一个用 LangGraph 做的开源 Agent 项目，把它的代码 clone 下来跑通，然后尝试加一个新工具进去。这个过程比看十篇教程都管用。
3. 主流框架选型：LangChain、Spring AI、Rust 到底怎么选
3.1 Python 生态：LangChain + LangGraph 是绕不开的
如果你主要用 Python，那 LangChain 和 LangGraph 基本是默认选项。LangChain 负责把 LLM、工具、记忆、检索这些组件标准化，LangGraph 负责把 Agent 的执行流程建模成图（Graph），让你能精确控制节点和边。
为什么用图而不是简单的链？因为 Agent 的执行路径是动态的。普通 Chain 是线性的 A→B→C，但 Agent 可能 A→B→A→C→B，甚至并行跑几个分支。用图来建模，每个节点是一个操作（调模型、调工具、判断），边是条件跳转，这样循环、分支、并行都能表达。
我实测下来，LangGraph 最值得学的三个点：StateGraph 的状态定义、条件边（conditional edge）、checkpointer 持久化。状态定义决定了你的 Agent 能记住什么；条件边决定了它怎么决策；checkpointer 决定了它能不能中断后恢复。这三个搞懂，LangGraph 就通了七成。
from langgraph.graph import StateGraph, END from typing import TypedDict, Annotated import operator class AgentState(TypedDict): messages: Annotated[list, operator.add] next_step: str def call_model(state): # 调用 LLM，返回新消息 return {"messages": [response]} def should_continue(state): last = state["messages"][-1] if last.tool_calls: return "tools" return END graph = StateGraph(AgentState) graph.add_node("agent", call_model) graph.add_node("tools", tool_node) graph.set_entry_point("agent") graph.add_conditional_edges("agent", should_continue) graph.add_edge("tools", "agent") app = graph.compile()上面这段就是 LangGraph 最核心的骨架，看着简单，但把 Agent 的循环本质表达得很清楚。
3.2 Java 生态：Spring AI Agent 的工程化优势
如果你是 Java 后端出身，不想切 Python，那 Spring AI 是这两年比较靠谱的选择。它的设计思路和 Spring 一贯的风格一致：注解驱动、依赖注入、配置化。定义工具用@Tool，定义 Agent 用ChatClient，和现有 Spring Boot 项目集成几乎零成本。
Spring AI 的优势在于工程化。Python 生态搭 Agent 快，但真到生产环境，线程池、事务、监控、配置管理这些 Java 生态沉淀了十几年的东西，Spring AI 能直接复用。比如你要做一个企业内部的 Agent，需要接公司统一的鉴权、日志、限流，Spring AI 天然就在这个体系里。
不过要提醒一点：Spring AI 的版本迭代也很快，API 时有变动，建议锁定一个稳定版本再动手，别追最新。我踩过的坑就是升级一个小版本后@Tool的参数解析行为变了，排查了半天。
3.3 Rust 生态：性能敏感场景的选项
基于 Rust 的 AI Agent 目前还算小众，但如果你对性能、内存占用、并发有极致要求，Rust 值得看。rig 这个库是比较活跃的选择，它把 LLM 调用、工具定义、Agent 循环都做了抽象，风格偏函数式。
Rust 做 Agent 的最大优势是并发和资源控制。Python 的 GIL 在高并发场景下是硬伤，虽然可以用 asyncio 缓解，但 CPU 密集型的预处理（比如大量文本切分、向量计算）还是吃亏。Rust 的 async 运行时配合 tokio，能真正做到高并发下的稳定低延迟。
但代价是开发效率。Rust 的借用检查、生命周期在快速迭代 Agent 逻辑时会拖慢速度。我的建议是：原型阶段用 Python，性能瓶颈出现后再考虑把核心链路用 Rust 重写。别一上来就用 Rust 搭 Agent，除非你就是想学 Rust。
3.4 框架选型速查表
| 场景 | 推荐框架 | 理由 |
|---|---|---|
| 快速原型、学习 | LangChain + LangGraph | 生态最全，示例最多 |
| 企业 Java 项目集成 | Spring AI | 和 Spring 体系无缝 |
| 高并发、低延迟 | Rust + rig | 无 GIL，资源可控 |
| 多 Agent 协作 | LangGraph / CrewAI | 图建模和角色分工成熟 |
| 可视化编排 | 扣子等平台 | 拖拽式，适合非程序员 |
4. 实操：从零搭一个能用的 AI Agent
4.1 环境准备与最小可运行示例
先说环境。Python 3.10 以上，建议用 uv 或者 conda 管理虚拟环境，别用系统 Python 直接装，依赖冲突会让你怀疑人生。核心依赖就几个：langchain、langgraph、langchain-openai，如果要接国产模型，换成对应的 SDK。
最小可运行示例我建议从“一个能查天气的 Agent”开始。为什么选天气？因为工具逻辑简单（调个 API 返回结果），能把注意力集中在 Agent 循环本身，而不是工具实现上。
from langchain_openai import ChatOpenAI from langchain_core.tools import tool from langgraph.prebuilt import create_react_agent @tool def get_weather(city: str) -> str: """查询指定城市的天气""" # 实际项目里这里调真实 API return f"{city}今天晴，25度" llm = ChatOpenAI(model="gpt-4o-mini", temperature=0) agent = create_react_agent(llm, [get_weather]) result = agent.invoke({"messages": [("user", "北京天气怎么样")]}) print(result["messages"][-1].content)跑通这段，你就理解了 Agent 的最小闭环：用户提问 → 模型判断需要调工具 → 调get_weather→ 把结果喂回模型 → 模型生成最终回答。create_react_agent是 LangGraph 提供的预置 Agent，内部就是 ReAct 模式（Reasoning + Acting）。
注意：
temperature设成 0 很重要。Agent 场景下你需要模型稳定地做决策，而不是发挥创意。我见过有人用 0.9 的 temperature 调 Agent，结果同一个问题每次走的工具都不一样，排查到崩溃。
4.2 工具定义的关键细节
工具定义看着简单，其实坑最多。三个关键点：
第一，docstring 就是给模型看的说明书。模型靠 docstring 判断这个工具是干什么的、什么时候该调。所以 docstring 要写清楚功能、参数含义、返回什么。别写“查询天气”四个字就完事，要写“查询指定城市的实时天气，参数 city 为城市中文名，返回温度和天气状况”。
第二，参数类型要明确。用类型注解，city: str比city好得多。如果参数是枚举，用Literal["北京", "上海"]限定，能大幅降低模型传错参数的概率。
第三，工具要幂等、要能容错。Agent 可能因为重试机制重复调用同一个工具，如果你的工具是“下单”这种有副作用的操作，必须做幂等处理。另外工具内部要 try-except，返回错误信息而不是直接抛异常，让模型知道“这次调用失败了，可以换个方式”。
我踩过的一个坑：工具返回的字符串太长（比如返回了一整页 HTML），直接把模型的上下文撑爆，导致后续决策混乱。后来改成只返回关键字段，问题解决。工具返回要精简，只给模型需要的信息。
4.3 状态管理与记忆：让 Agent 记住上下文
Agent 如果没有记忆，每轮对话都是失忆的，体验很差。LangGraph 里用 State 来管理，最常用的是把消息历史存进 state，每轮把历史一起喂给模型。
但这里有个权衡：历史越长，token 消耗越大，而且模型可能被早期无关信息干扰。我的做法是滑动窗口 + 摘要：保留最近 N 轮完整对话，更早的用 LLM 压缩成一段摘要。LangGraph 的 checkpointer 配合trim_messages能实现这个。
from langchain_core.messages import trim_messages trimmer = trim_messages( max_tokens=2000, strategy="last", token_counter=llm, include_system=True, )如果是需要长期记忆的场景（比如个人助理记住用户偏好），那就得上向量数据库，把重要信息 embedding 后存起来，需要时检索。这块和 RAG 是同一套技术，学 Agent 的时候顺便把 RAG 也补了，一举两得。
4.4 让 Agent 真正“下地干活”：接入真实业务
跑通 demo 只是开始，真正有价值的是让 Agent 接入真实业务。我拿“让 AI 自动处理小红书评论并回复”这个场景举例，完整链路是这样的：
- 数据获取：定时拉取新评论（用官方开放接口或合规的第三方服务）。
- 意图识别：Agent 判断这条评论是咨询、投诉、还是闲聊。
- 知识检索：如果是咨询产品问题，从知识库检索答案。
- 生成回复：结合检索结果和品牌调性生成回复文案。
- 人工审核：敏感或低置信度的回复转人工。
- 发送与记录：发送回复，记录处理日志。
这个链路里，Agent 不是单点，而是编排者。它决定每条评论走哪条分支，调用哪些工具。用 LangGraph 的图来建模特别合适，每个步骤是一个节点，条件边决定分支。
提示：涉及自动发送消息的场景，一定要加人工审核环节和频率限制。一方面是合规，另一方面是防止 Agent 抽风批量发错消息。我见过没加限制的，一晚上发了几百条重复回复，社死现场。
5. 并发、性能与生产化：Agent 上线的硬骨头
5.1 AI Agent 怎么扛并发
这是被问得最多的问题。Agent 扛并发和普通 Web 服务扛并发，难点不一样。普通服务瓶颈在 IO 和数据库，Agent 的瓶颈在LLM 调用的延迟和限流。
一个 Agent 请求可能要调好几次 LLM（每次决策一次），每次 LLM 调用几百毫秒到几秒不等。如果同步处理，一个请求占一个线程好几秒，并发上不去。所以第一原则是全链路异步。Python 用 asyncio，Java 用 WebFlux 或虚拟线程，Rust 用 tokio。
第二原则是连接池和限流。LLM API 通常有 QPS 限制，你得在客户端做限流，超出的请求排队或降级。用信号量（Semaphore）控制并发调用数，别让请求把 API 打爆。
import asyncio sem = asyncio.Semaphore(10) # 最多 10 个并发 LLM 调用 async def call_llm_with_limit(prompt): async with sem: return await llm.ainvoke(prompt)第三原则是缓存。很多 Agent 请求是重复的（比如相同问题），把 LLM 响应缓存起来能省大量调用。简单的用内存缓存，规模大了上 Redis。注意缓存 key 要把 prompt、模型、参数都算进去。
第四原则是超时和重试。LLM 调用偶尔会超时，必须设超时时间，超时后重试或降级。重试要加指数退避，别死循环重试把 API 打爆。
5.2 成本控制：别让 Agent 烧光预算
Agent 的 token 消耗比普通对话高得多，因为每轮决策都要把历史上下文和工具定义一起喂进去。一个复杂任务跑下来，几万 token 很正常。控制成本的手段：
- 精简 system prompt 和工具描述，能省则省。
- 用便宜模型做决策，贵模型做生成。比如用 gpt-4o-mini 判断意图，用 gpt-4o 生成最终答案。
- 限制最大循环次数，防止 Agent 陷入死循环疯狂调 API。
- 监控 token 消耗，设预算告警。
我实测过一个 Agent，因为工具返回格式有问题，模型反复重试同一个工具，一次请求烧了 20 万 token。后来加了最大迭代次数限制，问题解决。任何 Agent 都必须有硬性的循环上限。
5.3 可观测性：Agent 出问题怎么排查
Agent 的调试比普通程序难，因为它的决策是概率性的，同样的输入可能走不同路径。所以可观测性特别重要。至少要记录：
- 每次 LLM 调用的完整 prompt 和响应
- 每次工具调用的参数和返回
- 完整的执行链路（哪个节点到哪个节点）
- token 消耗和耗时
LangSmith 是 LangChain 生态的官方工具，能可视化整个执行链路，强烈推荐。如果不想用第三方，自己用 OpenTelemetry 埋点也行。关键是出问题时能回放整个决策过程，否则你根本不知道模型为什么走了那条路。
6. 常见问题与避坑实录
6.1 高频问题速查表
| 问题现象 | 可能原因 | 解决思路 |
|---|---|---|
| Agent 不调工具，直接回答 | 工具描述不清 / 模型能力不足 | 优化 docstring，换更强模型 |
| 反复调同一个工具 | 工具返回信息不足 / 无循环上限 | 精简返回，加最大迭代次数 |
| 参数传错 | 参数类型不明确 | 用类型注解和 Literal 限定 |
| 上下文超长报错 | 历史消息太长 | 滑动窗口 + 摘要 |
| 并发上不去 | 同步阻塞调用 | 全链路异步 + 限流 |
| 成本失控 | 无预算控制 | 监控 + 便宜模型决策 |
| 结果不稳定 | temperature 太高 | 决策环节设 temperature=0 |
6.2 几个我踩过的坑
坑一：以为 Agent 越复杂越好。刚开始我总想搞多 Agent 协作，结果发现大部分场景单 Agent 加几个工具就够了。多 Agent 的通信开销和调试难度是指数级上升的。能用单 Agent 解决就别上多 Agent。
坑二：忽略 Prompt 的稳定性。Agent 的 system prompt 里如果指令模糊，模型行为会飘。我后来把 system prompt 写成结构化的：角色、能力边界、输出格式、禁止事项，四块写清楚，稳定性大幅提升。
坑三：工具设计得太“重”。一个工具干太多事，模型反而不知道怎么用。拆成多个单一职责的小工具，模型选择起来更准。这跟微服务的设计思路是一样的。
坑四：不做降级。LLM API 挂了怎么办？必须有降级方案，比如返回预设话术、转人工、或者用备用模型。生产环境不能假设 API 永远可用。
6.3 学习资源推荐清单
最后给一份我实际用过、觉得有价值的资源清单：
- LangChain / LangGraph 官方文档：概念和 API 的权威来源，示例可跑。
- Spring AI 官方参考：Java 生态首选，注解式开发很顺手。
- rig（Rust）：Rust 生态里比较活跃的 Agent 库。
- 扣子等可视化平台：适合快速验证想法，非程序员也能上手。
- 开源 Agent 项目：直接读代码，学工程组织方式。
我个人在实际操作中的体会是，AI Agent 这个领域变化太快，与其追新框架，不如把工具调用、状态管理、循环控制、并发容错这几个底层能力吃透。框架会换，但这些核心心智模型是通用的。你把一个框架用透了，换另一个框架基本一周就能上手。真正拉开差距的，不是你会不会用某个库，而是你能不能把一个 Agent 从 demo 做到稳定上线，这中间的工程细节，才是这份学习资料真正想帮你补齐的东西。
