前阵子整理 AI Agent 学习资料时我翻遍了手上的收藏夹、PDF 和各类开源仓库发现一个很现实的问题资料非常多但大多数要么是纯理论科普要么是某个框架的 API 文档真正能把“为什么这么设计”和“我怎么跑起来”串起来的太少了。所以我决定按自己的学习路径重新梳理一遍把踩过的坑、看过的书、写过的 demo 都沉淀成一份可以直接照着走的地图。这篇文章适合三类人刚接触 Agent、不知道从哪下手的新手已经会调 API、但想理解 Agent 内部运行逻辑的开发者以及准备面试、需要把零散知识系统化输出的求职者。先说结论AI Agent 不是简单的“大模型套壳”。它是一套把大模型、规划能力、记忆管理和外部工具组合起来的系统。如果你只把它当成“输入提示词、输出结果”的聊天机器人那你做出的东西永远是 demo 级别但如果你理解了它的运行逻辑你就能用几千行代码做出真正能干活的应用。下面我会从概念、学习路线、资料筛选、实操搭建、问题排查到趋势判断把整个学习过程拆开讲。1. AI Agent 是什么核心概念与运行逻辑1.1 从 LLM 到 Agent 的关键跃迁先举一个生活化的例子。普通的聊天机器人就像一个知识渊博但从不主动行动的顾问你问一句它答一句哪怕你让它帮你订机票它也只能给你一段“建议”因为它的输出终点就是文本。而 Agent 更像一个接到任务的实习生它会自己拆解需求订机票需要先查时间、查价格、比选航空公司、下单、再确认出票短信每一步它都会调用合适的工具并且在出错时重新规划路径。这个跃迁的本质在于“行动闭环”。传统 LLM 的输入输出是“文本进、文本出”Agent 则把 LLM 当作“大脑”或“控制器”让模型输出的不只是最终答案还有下一步动作的描述。比如模型说“我需要调用天气查询 API”那么 Agent 框架就会解析这个动作真实地去请求天气服务然后把返回结果再喂给模型进行下一轮推理。这就是 Agent 不同于普通聊天机器人的核心差异它能把语言指令转化为可执行的操作序列。我在学习过程中发现很多人一开始会纠结“AutoGPT 是不是 Agent”“LangChain 是不是 Agent”这类问题。其实这些只是 Agent 的一种实现形式。真正的 Agent 系统应该满足三个条件能感知环境比如获取用户输入、查询数据库、能做出决策用 LLM 推理下一步做什么、能执行动作调用工具或修改状态。如果只用了 LLM 没有工具调用那是“聊天”只写了工具调用但没有模型决策那是“脚本”两者闭环了才叫 Agent。1.2 Agent 的四个核心模块规划、记忆、工具、行动把 Agent 拆开看绝大多数架构都逃不出四个模块理解这四块你就掌握了 Agent 的全局。规划模块负责把大目标拆成小步骤。LLM 本身具备一定的推理能力你可以用 CoT思维链提示词让它“一步一步想”也可以用 ReAct 模式让它在“思考-行动-观察”之间循环。规划不仅仅是“列表式拆解任务”还包括反思和纠错——比如第一步执行失败后Agent 能不能自己换一条路线这决定了它是否真的“智能”。记忆模块分短期和长期。短期记忆就是当前对话的上下文比如用户刚刚说了什么、上一步工具返回了什么结果长期记忆则是把历史信息持久化下来比如用户偏好、项目背景、某个领域的知识。实际开发中短期记忆通常用上下文窗口管理长期记忆则用向量数据库或传统数据库存储需要时检索出来注入提示词。工具模块是 Agent 和外部世界交互的接口。最常见的是函数调用比如定义好一个“get_weather(city: str) - str”的函数LLM 输出 JSON 格式的调用参数框架去执行并返回结果。再复杂一些工具可以是代码解释器、浏览器扩展、数据库查询接口甚至是另一个 Agent。工具的关键在于“接口描述清晰”你得让模型知道这个工具是干什么的、需要什么参数、会返回什么。行动模块负责把决策变成现实。比如执行代码、发送 HTTP 请求、操作文件、调用 Shell 命令。很多 Agent 框架把工具和行动合在一起说但我会分开看因为“决定调用工具”和“把工具调用安全稳定地执行”是两个不同层次的问题。行动模块通常需要权限控制、错误重试和资源隔离不然 Agent 在真实环境里很容易闯祸。当你把四个模块串起来就形成了经典的 Agent 运行循环接收任务 → 规划 → 根据规划选择工具 → 执行工具 → 观察结果 → 更新记忆 → 再次规划直到任务完成。这个循环听起来简单真正跑起来后每一步都可能出幺蛾子后面我会重点写实操中的坑。2. 学习路线图从入门到实战的路径规划2.1 第一阶段打好大模型基础我不建议一上来就啃 LangChain 源码。Agent 再花哨底子还是大模型的理解和生成能力。你至少需要知道 Transformer 的基本结构、Token 是什么、Temperature 和 Top-p 怎么影响输出、上下文窗口是什么意思。这些知识不需要你手推公式但要知道“为什么模型会胡说八道”和“为什么窗口满了对话会断”。这个阶段最有效的学习方式不是看论文而是直接去大模型厂商的开放平台注册账号用 API 跑几个小实验。比如你问模型“11等于几”再问“树上有 10 只鸟打下一只还剩几只”观察它在哪些场景容易出问题。再比如把 Temperature 调到 0 和调到 1对比输出差异。这些动手实验会让你对模型能力边界有体感——这是 Agent 开发最重要的基础。我个人比较推荐的学习资料是吴恩达的《ChatGPT Prompt Engineering for Developers》短视频课虽然名字是 Prompt Engineering但它覆盖了 LLM 的核心用法而且有 Jupyter Notebook 可以直接跑。看完你至少能理解 System Message、Few-shot 和输出格式控制是怎么回事。这一阶段大概需要一周每天两小时重点是形成“模型行为可以控制”的直觉。2.2 第二阶段掌握提示词工程与函数调用有了基础就要开始学提示词工程和 Function Calling。提示词工程在 Agent 里的作用比在普通聊天里更大因为你不再只是让模型回答问题而是让它按照特定格式输出“行动计划”。比如你用 JSON 输出格式控制模型返回{action: search, arguments: ...}如果格式稍微乱了下游解析就会崩。所以这一阶段的核心训练是“让模型稳定输出结构化内容”。Function Calling 是 OpenAI 最早带火的概念现在主流模型基本都支持。它本质上是在请求里声明一些函数签名模型会根据用户问题选择该调用哪个函数并生成对应参数。你不需要让模型自己输出任意 JSON模型会按照你提供的 schema 返回一个结构化的调用请求。这个机制比纯提示词稳定得多因为模型是在“选项”里做选择而不是“创作”。训练方法也很直接自己定义 5 个工具比如查天气、算算术、查新闻、发邮件、生成周报然后写一个交互脚本让模型在多个工具之间切换。你很快会体会到工具描述写得精不精确直接决定模型选得对不对。我自己的经验是工具描述里要写清楚“什么时候用这个工具”“参数是什么格式”“返回值是什么含义”描述越长准确率越高但也不能长到把上下文撑爆。2.3 第三阶段搭建第一个 Agent打牢基础后动手搭第一个 Agent 是最有成就感的一步。方向有很多有人做个人知识库问答有人做自动写周报的工具有人做客服机器人。我的建议是选一个你日常工作里最烦的任务比如自动整理邮件、自动查截图里的日程并生成提醒。需求越具体你越容易判断 Agent 做得对不对。这个阶段你可以直接用现成框架也可以手写一个极简循环。我个人的建议是第一次手写不依赖框架因为框架会把很多细节藏起来。手写一遍之后你对“消息是怎么在模型和工具间流转的”会有肌肉记忆再去用 LangChain 或 AutoGen 时就不会有“黑盒恐惧”。你可以用 Python 写一个不到两百行的小 Agent循环里调用大模型接口如果模型返回的是工具调用就执行工具并把结果拼进对话记录如果模型返回的是最终答案就结束循环。这个经典循环清晰到让人感叹“原来不过如此”。当你跑通第一个 Agent 后再回头去学 LangChain、LlamaIndex 这类框架效率会高很多。因为你会带着问题去学这个框架是怎么管理记忆的它的工具调用协议是怎么设计的整个 Agent 的抽象层在解决什么问题李博杰那篇《深入理解 AI Agent》在网上流传很广PDF 版本可以找来看看里面把 Agent 的架构演进和发展逻辑讲得比较透适合在实战后读因为那时你才看得懂他为什么说“Agent 的核心是执行和反馈”。3. 学习资料精选书籍、课程、开源项目与社区3.1 必读论文与书籍如果要选一篇论文入门我会推荐 ReAct: Synergizing Reasoning and Acting in Language Models。它提出的“思考-行动-观察”模式是绝大多数 Agent 框架的指导思想。它把推理轨迹和动作执行交错在一起模型看到环境反馈后继续推理从而解决长尾任务。理解这篇论文你就理解了很多 Agent 产品为什么用的是“循环而不是单次输出”。另一篇值得读的是 Toolformer它教模型自己决定何时调用工具以及如何调用。虽然这套方法在今天已经变成了微调模型的方向之一但它提出的“让模型大规模自我监督学习工具使用”的思路对理解模型能力上限很有帮助。书籍方面目前系统性的中文专著不多但有一些大模型相关的书可以作为前置知识比如《大规模语言模型从理论到实践》《动手学大模型应用开发》。后者比较实操有大量代码示例适合作为搭配课程的手册。李博杰那篇《深入理解 AI Agent》虽然没有正式出版但在社区里流传的 PDF 质量很高我建议作为进阶读物放在实战之后读别再入门时啃。3.2 优质课程与教程课程方面我按“动手实操”和“理论深入”两个方向分类推荐。动手实操类首推 Hugging Face 的 Agents Course这门课免费从基础 Agent 概念一直讲到 Gradio 前端交互还有环境可以跑代码。其次是 DeepLearning.AI 的 Short Courses 系列里面有好几门和 Agent 相关比如 “Functions, Tools and Agents with LangChain”十几分钟一节课碎片时间刷完。理论深入类可以看斯坦福 CS224N 里关于工具学习和 Agent 的章节视频在 YouTube 上有虽然有门槛但讲得很透彻。如果英文看着累李宏毅老师的机器学习课程里也有大模型相关章节中文讲解比较亲民。国内一些平台上的“AI Agent 系统实战”课程也可以看看但要注意多对比很多课其实就是把 API 文档念了一遍价值和免费文档没什么区别。3.3 开源框架与工具开源框架我踩过很多这里只挑几个真正值得花时间的。LangChain 是最知名的生态最全文档也全但正因如此它抽象层次多新手容易迷失。我的建议是先用它跑一个标准 Demo了解它怎么组织 Agent但不要一上来就深入学习它的所有模块否则会被大量概念淹没。AutoGen 是微软出的多 Agent 框架擅长让多个 Agent 之间协作对话适合模拟团队分工场景。如果你要做“多个角色一起解决一个问题”的演示AutoGen 会很方便。LangGraph 是 LangChain 团队后来出的更底层的框架它把 Agent 定义成一张图节点是操作边是状态流转。如果你想精确控制 Agent 的分支和循环LangGraph 比 LangChain 的原生 Agent 更顺手。还有几个常用组件值得关注函数调用 SDK如 OpenAI SDK 的 function calling、向量数据库Chroma、Milvus 等、以及记忆库工具Mem0 等。如果你在 Java 技术栈Spring Boot 3 已经开始集成 AI 相关的 Starter 了Spring AI 项目提供的客户端封装也能让你在 Java 生态里写 Agent勉强算一种“Spring Boot AI Agent 客户端”的解法。这个方向资料还不多但我看到的热度在上升做 Java 开发的朋友可以提前布局。另外有一些知识库与绘图工具集成的实践也很有意思比如用 Obsidian AI Agent 搭建个人知识库让 Agent 读取笔记、回答跨文档问题还有 Next AI 结合 draw.io 与 Hermes Agent 对接的玩法可以在白板上动态生成流程示意图。这类工具型 Agent 不算核心但能极大提升个人效率适合作为练手项目。3.4 社区与面试题资源社区推荐三个Hugging Face 论坛、LangChain 的 Discord 服务器和 Reddit 的 r/LangChain。那里有很多前沿案例和踩坑帖比看二手公众号有价值得多。中文社区方面知乎上关于 Agent 的讨论也越来越深入但信息密度参差不齐需要自己筛。面试题资源的话不要只看题库。常见的 Agent 面试题包括LangChain 里 Agent 和 Chain 的区别是什么ReAct 和 Plan-and-Execute 模式分别适合什么场景如何缓解 Agent 的幻觉问题长期记忆和短期记忆分别存在哪里函数调用和提示词输出 Json 哪个更可靠这些问题看起来是“知识点”实际考察的是你是否真正做过项目。我建议你准备一个小项目亲手实现一遍面试时能讲清楚里面的取舍远比背十个概念有说服力。4. 从零搭建一个 Agent实操过程与关键细节4.1 技术选型LangChain 还是手写我在搭建第一个 Agent 时用的工具是 Python OpenAI SDK 一个简单的while True循环。当时 LangChain 已经很流行但我刻意绕开了它。为什么因为我想先理解核心循环再选择框架。手写一遍之后你会知道“每个循环里发生了什么”而不是在 LangChain 里看到一个“AgentExecutor”却不知道它内部是怎么把工具结果拼回去的。如果你的场景很标准比如通用的问答、检索增强、网页摘要那么直接上 LangChain 或 LlamaIndex 会快很多。框架帮你处理了提示模板、记忆窗口、工具 schema 生成这些琐碎的事开发效率明显更高。但如果你的 Agent 有复杂的自定义逻辑、需要精细控制状态流转或者要部署到低延迟环境我建议你至少评估一下自己写循环的成本往往反而更可控。一个折中方案是用 LangGraph 这类可编程框架它既有框架的便利又能让你精确控制每个节点的行为。我现在遇到复杂项目时会先用手写循环做原型验证再用 LangGraph 重构。这样既有“理解底层”的底又有“工程效率”的甜头。4.2 搭建一个带记忆和工具的客服 Agent下面我把“客户支持 Agent”的搭建过程完整拆解一遍。它会读取客户问题、查询订单数据库、返回订单状态并且在多轮对话中记住客户的会员等级。这个例子麻雀虽小但包含了 Agent 的全部核心模块。先定义工具函数我用函数签名的方式描述给模型def get_order_status(order_id: str) - str: # 模拟数据库查询返回订单状态 return f订单 {order_id} 状态: 已发货预计明天送达 def get_member_level(user_id: str) - str: # 返回会员等级 return 金卡会员享受95折然后定义工具 schema我直接把它拼进 system prompt让模型在需要时输出特定动作import json system_prompt 你是一个客服助手。你可以使用以下工具 1. get_order_status(order_id): 查询订单状态 2. get_member_level(user_id): 查询会员等级 请逐步思考如果用户的问题需要查询就输出一个 JSON {action: get_order_status, order_id: xxx} 如果已经获得足够信息直接输出最终答案。 真正的循环很朴素messages [{role: system, content: system_prompt}] while True: user_input input(你: ) messages.append({role: user, content: user_input}) while True: response openai.ChatCompletion.create( modelgpt-4o-mini, messagesmessages, temperature0 ) content response.choices[0].message.content.strip() # 尝试解析成动作 try: action json.loads(content) if action[action] get_order_status: result get_order_status(action[order_id]) elif action[action] get_member_level: result get_member_level(action[user_id]) else: result 未知动作 messages.append({role: assistant, content: content}) messages.append({role: user, content: f工具返回结果: {result}}) continue except json.JSONDecodeError: # 不是动作就是最终答案 print(Agent:, content) break messages.append({role: assistant, content: content})这个代码虽然简陋但核心逻辑已经出来了内层循环里模型要么输出动作 JSON要么输出最终答案如果是动作就执行工具并回填结果如果是答案就跳出内层。记忆通过messages列表天然实现了短期记忆——历史对话都拼在上下文里模型能“记得”前面说过什么。我加上记忆模块时会在工具之外再做一个字典缓存存用户的会员等级避免每轮都去查询。然后把这个信息在 System Prompt 最前面动态注入比如“用户张三金卡会员享受95折”。这样模型回答时就自动知道折扣信息不需要每次都调用工具。长期记忆则可以换成向量数据库按用户 ID 存储历史对话摘要后续检索注入。4.3 让 Agent 稳定工作的参数调优经验写完循环后你马上会遇到各种不稳定问题。这里分享几个我实测有效的调优技巧。第一把 Temperature 设成 0 或接近 0。Agent 解析 JSON 动作时任何一点随机性都可能让输出结构跑偏。让模型做工具调用决策的时候你不需要它“有创意”需要它“稳定且可预测”。所以我默认都是 temperature0只在最终生成回复时用稍高一点的温度比如 0.2。第二提示词里明确“如果信息不足就告诉你需要什么”。Agent 最常见的错误是模型自以为知道了答案直接编造订单状态。我在 System Prompt 里加了约束“如果没有调用工具拿到真实结果不得直接回答订单状态。”这个约束虽然简单但能大幅降低幻觉。第三给工具结果加上前缀。比如工具返回的内容是“订单 123 状态已发货”我会拼成“工具返回结果订单 123 状态已发货”。这个前缀看起来只是装饰实际能让模型更容易区分“这是观察结果”和“这是用户说的”减少错位。第四限制工具调用的最大次数。我写过一个死循环 Bug模型一直认为需要调用同一个工具而工具每次返回“查不到”模型就继续查。后来我在循环里加了一个max_iterations 5超过就强制模型基于已有信息回答或者承认失败。这对生产环境很重要不然无限循环会浪费大量 token。第五输出校验。不要只依赖json.loads因为大模型偶尔会在 JSON 前后加一些解释文字比如“好的我将调用以下工具{...}”。我的做法是提取第一个{到最后一个}之间的子串再解析如果解析失败就向模型发送错误反馈“无法解析工具调用请只输出合法 JSON。”这个“自我纠错”机制能显著提高成功率。5. 常见问题与排查技巧实录5.1 模型幻觉严重怎么压都压不住怎么办幻觉在 Agent 里被放大了因为它不仅影响文本回答还会导致模型调用错误的工具或参数。我遇到过一个案例模型需要查询用户订单但它没有调用工具直接“猜”了一个订单状态。原因通常是工具描述不清晰或者提示词里没有强调“必须查询”。排查思路可以按下面顺序走先检查工具描述是否足够具体。原描述是“查询订单状态”后来我改成“当用户询问自己订单的物流、发货、支付状态时必须使用 get_order_status 工具不得猜测”。加了“必须使用”之后行为立刻改善。再看提示词是否给出了完整例子。Few-shot 示例对稳定格式化输出很有用我在 System Prompt 里直接给了两个“用户问-模型调工具”的范例幻觉率下降明显。如果问题依旧就需要考虑是不是模型本身能力不够。小参数模型在复杂工具调用上确实更弱可以换成更聪明的模型或者把工具拆得更简单。比如不要一个工具包含很多功能改成多个单一功能工具模型更容易选对。5.2 工具调用不稳定一会儿成一会儿败工具调用不稳定大多是输出格式不齐和参数提取错误。模型输出 JSON 经常是“非法的”尤其模型版本比较旧的时候。我排查时会在代码里打印原始输出看一眼失败的类型是什么。常见的三种情况模型在 JSON 前后加了说明文字键名变了比如把order_id写成orderId参数值是空字符串或多余空格。针对第一种用提取子串的方法针对第二种做键名映射或让模型严格按照 schema 输出针对第三种在调用工具前加参数校验和清洗函数。还要注意工具本身可能抛异常。比如网络抖动、数据库超时、外部 API 返回错误码。我给每个工具调用包了 try/except并把错误信息作为工具结果反馈给模型让模型决定是换个参数重试还是放弃。这个设计非常重要Agent 不是“不出错”而是“出错后能基于错误信息自我修正”。如果你把异常吞掉模型得不到反馈只能瞎猜。5.3 上下文爆炸聊不了几轮就“失忆”上下文窗口虽然越来越大但 token 成本也随之增高。如果你把整段历史对话和工具日志都塞进 messages几分钟就会打满。我的经验是分三层管理记忆第一层是“最近五轮对话全量保留”。最近的信息对当前决策最关键必须完整。第二层是“历史摘要”。每十轮对话结束后让模型生成一段摘要比如“用户问过订单、反馈过收货问题、是金卡会员”把摘要拼在 System Prompt 前面。第三层是“关键实体数据库”。用户 ID、订单号、会员等级这类结构化信息单独存字段动态注入。这样即使上下文被压缩关键信息也不会丢。我用这个三层结构后一个客服 Agent 可以连续工作很长的会话token 消耗也稳定多了。如果你在做一个长期运行的任务型 Agent还可以考虑用外部向量数据库做检索式记忆每次只把和当前问题相关的历史片段注入提示词而不是全部注入。这类似 RAG但这里检索的是“记忆”不是“知识”。5.4 面试阶段围绕 Agent 的高频考点我看到很多同学在准备 AI Agent 面试时只顾背概念结果被考官一追问就露馅。这里整理几个我实际遇到的高频考点并说一下考官到底想考什么。“Agent 和 Chain 的区别是什么”考点是理解 Agent 的循环决策能力。Chain 是预先写好的步骤Agent 是动态决定步骤。你要能用一个具体场景说明如果需求永远是“查天气然后给穿衣建议”用 Chain 就行如果下一步动作取决于上一步结果用 Agent。“ReAct 和 Plan-and-Execute 有什么区别”考点是对规划模式的掌握。ReAct 是边想边做每步都在行动和观察之间交替Plan-and-Execute 是先生成完整计划然后逐步执行。前者灵活但 token 开销大后者适合任务步骤明确的场景。你还可以说实践中可以两者结合先计划每步再做 ReAct 式执行。“如何让 Agent 不跑偏”考点是 Engineering 经验。你可以从提示词约束、工具结果校验、循环上限、状态管理、可观测性日志等角度回答。最好结合自己做过的项目比如我加过某种输出校验准确率从 70% 提到了 90%。“记忆模块怎么设计”考点系统设计能力。你回答时按短期、长期、缓存三层来讲再结合 RAG 思路基本上就稳了。面试官通常还喜欢追问“如果摘要漏了关键信息怎么办”你可以答“对关键实体单独存储”或“增加摘要更新策略”体现你的工程敏感度。6. 2026 趋势判断与个人学习建议6.1 技术成熟度与量产窗口很多讨论都在说 2026 年是多模态交互和大模型 Agent 的量产窗口。我有同感但更谨慎。从技术成熟度看模型工具调用能力、上下文长度、成本效率这几项已经基本具备落地条件了。比如我用小参数模型跑工具调用准确率已经比两年前高很多Agent 框架也从“玩具”走向了“基础设施”有状态管理、可观测性、权限隔离这些企业级功能。所以对于学习者来说现在入场正好不算太早也不算太晚。但要警惕“风口叙事”。Agent 落地最大的瓶颈不在模型能力而在系统稳定性。真实业务里外部 API 会挂、工具参数会变、用户需求会超出预设边界、安全和合规问题也会接踵而至。能把这些工程问题解决好的人才是未来几年最稀缺的。技术成熟窗口意味着“开发门槛降低”但不代表“工程门槛消失”。如果你想在这个领域建立竞争力除了会调库还要具备系统设计、流程编排、异常恢复能力。6.2 从资料整理到持续学习的闭环最后说点个人体会。我刚开始整理 AI Agent 学习资料时总想找到一个“完美的课程”或“一份全的收藏夹”但后来发现资料的价值不在多而在你能否消化成自己的东西。我现在的方法是每个资料读完必须写一个小 demo哪怕只是改写一个例子也要亲手跑通。然后把这些 demo 沉淀到自己的知识库最好用 Obsidian 这类工具加上 AI Agent 辅助检索让笔记成为“外挂大脑”。你也可以给自己定一个 21 天目标第一周学概念和提示词第二周手写一个极简 Agent第三周用框架做一个完整应用。期间遇到问题去社区搜、去问、去翻源码。反复几轮后你会发现自己已经能看懂各种 Agent 架构图了。到那时资料整理这件事就不再是负担而是一个持续迭代的成长习惯。如果你现在还在犹豫从哪里开始我建议你直接动手写那个最简循环。不要等到“学完所有理论”再实践因为 Agent 这个领域理论和实践是互相喂饭的。跑通第一个循环后你会发现后面的路突然就清晰了。