这两年只要聊到大模型应用层有一个词你一定绕不开AI Agent。从技术社区到公司内部项目从应届生简历到技术Leader的PPT“AI Agent学习”几乎成了标配。我自己的微信里隔几天就有人发来一份学习资料链接问这个顺序对不对。说实话市面上的资料已经多到看不完但真正能帮你把Agent从概念落到代码的其实就那么几条线。这篇文章算是我一份阶段性的资料整理总结专门讲我筛过、读过、在项目里用过的AI Agent学习内容以及按什么顺序看最不容易半途而废。无论你是刚开始接触的新人还是已经用LangChain写过Demo但还缺系统底层的开发者都可以对照着查漏补缺。1. 先搞懂运行逻辑Agent不是高级聊天机器人很多朋友一上来就问我Agent跟ChatGPT有什么区别不都是对话吗这个问题问不清楚后面看资料就会很痛苦。Agent的核心不是“会聊天”而是“能干活”。它可以自己把用户的目标拆成步骤按顺序去做遇到问题自己调整甚至调用外部工具来补足大模型本身做不到的事情。举一个最直观的例子你让普通聊天机器人生成一份周报它给你一段文字但你让Agent做这件事它可能会先去读取项目管理系统里的任务数据把内容整理成表格再按模板生成一份Markdown文件最后调用邮箱接口发给你的领导。这个过程里对话只是入口任务执行才是核心。1.1 Agent与Chatbot的核心区别为了把概念讲扎实我列了一张对比表你后面看任何资料都可以拿这张表去对照。它回答的核心问题是什么能力是Agent独有的什么能力只是上下文聊天的自然延伸。很多面试和项目评审里这块也是第一个被追问的地方。维度普通ChatbotAI Agent任务方式单轮/多轮对话直接返回回答自主规划任务步骤逐步执行能力边界只有模型本身的知识可调用工具、API、数据库、浏览器等是否感知环境通常不感知只能根据对话内容可以读取文件、网页、系统状态是否具备记忆依赖上下文窗口短时记忆有短期工作记忆和长期存储机制失败处理答错就重新生成能观察反馈、自我纠错、调整计划这张表在面试时很常用你可以把它当成基础话术。说到“对话只是入口”其实还有一层含义是Agent的交互方式正在快速扩展到语音、图像甚至自动触发任务但底层决策循环是不变的。理解了这一点你再看各种花哨的Agent产品就不会被外壳迷惑。1.2 拆解Agent运行循环感知、规划、行动、记忆理解Agent不能停留在概念上要把运行循环刻在脑子里。目前市面上的Agent框架不管名字多高级本质上都在做这么几件事感知把用户的指令、环境状态、工具返回结果转成模型能理解的上下文。规划大模型根据目标拆解出子任务形成执行计划常见的做法是ReAct、Plan-and-Execute、多Agent协作。行动调用工具或代码执行器把规划变成真实世界的操作比如发HTTP请求、写文件、执行SQL。观察与反思拿到工具返回的结果后判断下一步是继续执行、重试还是终止。记忆把对话历史、任务状态、领域知识存起来短期记忆对应上下文窗口长期记忆对应向量数据库或知识库。我建议你在读任何Agent源码之前先拿这个循环去套。看LangChain的一个Agent你会发现它的核心就是“LLM根据输入决定要调哪个Tool然后调用然后把工具结果再丢回LLM判断”看AutoGen你会发现它多个Agent之间本质上也是这个循环的角色化变体。一旦你把这个框架内化后面所有资料都会变得好懂。我见过不少人一上来就啃源码结果被AgentExecutor、ToolNode、StateGraph这些名词淹没其实它们都只是在为“感知-规划-行动-观察”里的某个环节服务。1.3 理解运行逻辑对选资料和学习顺序的影响这个环节很多人会忽略。你一上来就翻代码看到一堆抽象类和回调函数就懵了。反过来你先把运行逻辑捋清楚再去看资料你会带着“哦原来这个函数就是实现规划的那一步”的对应感去读。所以我在下面的学习资料部分会把理论放在代码前面不是不看代码而是我试过很多次这个顺序最不容易劝退自己。它还能帮你过滤掉无效资料凡是连“感知、规划、行动、记忆”都讲不清楚的文章基本不值得花时间。2. 学习资料清单按顺序看才能形成体系我之前收集资料有个毛病先收藏再吃灰。后来我把AI Agent学习资料整理成了一条主线按顺序推进效率高了很多。下面这条线不是简单罗列资源而是每一份资料用来解决什么问题的说明以及我为什么把它放在这个位置。2.1 第一份资料李博杰《深入理解AI Agent》在AI Agent相关的中文资料里李博杰的《深入理解AI Agent》是最近讨论度很高的一份PDF材料许多只言片语的热搜词都是绕着它转的。圈内不少人把它当成“Agent第一课”原因是它的系统性强从LLM的基本能力讲到Agent的整体架构再到规划、记忆、工具使用和多Agent协同最后落到典型应用场景几乎是按教科书逻辑写的。这对中文读者非常友好因为Agent领域的术语在中文社区里还没有完全统一作者的系统梳理能帮你把概念锚定住。我对这份材料的建议是拿到手后先别急着划线把目录过一遍然后在纸上画一份思维导图只需要写出“感知-规划-行动-记忆-工具”和“Agent生命周期”这些主节点。之后随着你读代码、看论文再回来补细节点。很多人说这份PDF难找其实你在技术圈搜一下标题作者授权过的转载版本还是有的但如果找不到去看作者相关的演讲或直播回放内容框架也差不多。注意别把这个当成唯一资料它是地图不是终点否则你会陷入“光看懂不会做”的状态。2.2 必要的英文课程与经典论文理论地图有了接下来填英文世界的优质内容。这部分我不建议全都看本着“够用就行”的原则挑三个方向Hugging Face的Agent课程免费网页上直接读它的特点是把Agent拆成“模型工具指令”三层还提供了很多可运行的小例子适合第一批动手代码。DeepLearning.AI上的Functions, Tools and Agents with LangChain偏工程短课能快速理解工具调用和AgentExecutor的来龙去脉。几篇论文ReAct、Toolformer、Reflexion再加2023年的综述《The Rise and Potential of Large Language Model Based Agents》。论文不需要精读重点是提取“为什么”ReAct为什么要交替Reason和ActReflexion为什么要加自我反思带着问题读比从头读到尾有效得多。很多中文平台也翻译了几篇关键论文但我的经验是能读原文就尽量读原文。原因是Agent领域的术语翻译还不统一同一个词在不同文章里可能被译成“代理”“智能体”“主体”尤其在技术讨论时名词不一致会带来很大的沟通成本。英文原文至少能让你回到准确术语上后续查资料也会顺很多。2.3 值得精读的开源项目源码资料看得再多不动手拆代码是不完整的。我只推荐三个项目按顺序来LangChain的agent相关示例适合初学你能看到最标准的create_react_agent写法。LangGraph的官方示例适合理解状态机式的Agent流程它的设计比LangChain更接近生产。MetaGPT或AutoGen一个偏多Agent协作一个偏对话自动化和代码生成适合进阶参考。读源码时有个技巧不要用眼睛过代码要“按调用链走”。比如LangChain里的Agent先找到入口然后看LLM被调用后输出了什么格式哪个函数解析了这个输出哪个函数根据输出选了工具工具返回后结果又回到了哪里。把这条链路走通一遍胜过你抄十遍Demo。很多人卡在“读不懂抽象层”其实只要抓住一个点Agent就是“模型决定调什么工具程序去执行再把结果喂回给模型”所有框架都在给这个循环做封装。2.4 中文社区里比较靠谱的导航仓库中文方面GitHub上有几个无版权风险的导航仓库可以收藏比如Awesome-AI-Agents和LLM-Agent-Paper-List。前者收集了Agent相关开源工具和研究文章后者按主题整理了论文列表。你不需要全部读完作为“查资料时知道去哪找”就够了。另外知乎上一些Agent落地实践的专栏也值得看但要注意筛选凡是只讲概念不贴代码或没有真实数据支撑的大概率是营销号。判断一篇Agent文章是否值得读我就看一点它有没有贴出完整的工具调用链路以及有没有说清楚工具返回异常时怎么处理。没有这两点的基本可以跳过。到这里你已经有了一条“理论→课程→论文→源码→导航”的完整学习线。如果你严格按这条线走大概两到四周就能搭起自己的认知框架。接下来我们要聊动手的事。3. 动手搭建框架选型与最小Agent示例学Agent如果不动手写一个能跑的程序很快会忘。这一章我分成选型、Python示例、Java路线和生产注意点四块最后一块是我在实际项目里吃过亏才总结出来的建议你重点看。3.1 主流框架怎么选LangChain/LangGraph/AutoGen/CrewAI对比市面上框架很多但底子大同小异。我根据自己的使用体感列了一张表你可以按项目类型去选不必追求“最火的”而是要选“最不别扭的”。框架核心风格适合场景上手难度LangChain组件丰富开发快快速做原型、工具调用、RAG中LangGraph图状态机可控性强复杂流程、生产级Agent中高AutoGen多Agent对话多个角色互相协作、代码执行中CrewAI角色分工清晰模拟团队做任务低我的建议是第一遍用LangChain或直接写不带框架的原生工具调用代码把运行逻辑吃透第二遍如果做正式项目再切LangGraph因为它能显式定义状态、回边和条件分支对“某个步骤失败了怎么办”这类问题处理得比LangChain老版本优雅得多。AutoGen适合你有“两个Agent互相辩论”这类需求时再看CrewAI则适合做业务演示因为它的“角色、任务、流程”概念非常直观老板容易看懂。3.2 Python生态里的一个最小Agent示例如果不想在一开始就背框架API可以直接用OpenAI兼容接口来做“函数调用”这是理解Agent工具机制最快的方式。下面这个例子用最少的代码实现一个能查本地天气的Agentfrom openai import OpenAI client OpenAI(base_urlhttp://localhost:11434/v1, api_keyollama) # 如果你用本地Ollama也可以用这样的兼容地址 tools [ { type: function, function: { name: get_weather, description: 查询某个城市的天气, parameters: { type: object, properties: { city: {type: string, description: 城市名} }, required: [city] } } } ] def get_weather(city: str): # 这里真实开发会调天气APIdemo阶段先返回固定值 return f{city}当前气温26摄氏度多云 messages [{role: user, content: 北京天气怎么样}] response client.chat.completions.create( modelqwen2.5, messagesmessages, toolstools, tool_choiceauto ) msg response.choices[0].message if msg.tool_calls: # Agent决定调用工具 for tool_call in msg.tool_calls: if tool_call.function.name get_weather: city eval(tool_call.function.arguments)[city] result get_weather(city) print(result)这个示例的核心价值在于你亲眼看到了“模型输出工具调用请求→程序执行真实函数→拿到结果”这一条链路。在这个基础上再去写while循环让模型根据工具结果继续判断就是一个mini Agent了。当然生产环境不要用eval解析参数要用json.loads来做类型安全处理。很多教程会直接用eval这会让代码跑起来很爽但也会让线上服务变得很脆弱。3.3 Java开发者路线Spring Boot Spring AI/LangChain4j不少后端同学是Java技术栈问得最多的就是“Java能不能做Agent”。当然可以现在Java生态也有两个方向Spring AI和LangChain4j。它们都提供了类似Python版本的工具调用、Agent执行器和模型客户端接口。如果你本身就在Spring Boot项目里把它们当作一个客户端模块接入比自己用HttpClient去拼Prompt要省心得多。以Spring Boot为例常见做法是引入spring-ai-openai或langchain4j-open-ai依赖。配置base-url指向你的模型服务地址比如Ollama、vLLM或云厂商兼容接口。定义一个工具类在方法上注册Tool注解框架会在Agent需要时自动调用。Spring AI的好处是跟Spring生态无缝整合事务、配置、监控都能用上LangChain4j更接近LangChain的设计如果你习惯Python侧的概念切换成本低。我见过不少项目把Agent作为Spring Boot的一个客户端模块接收上层请求再调用模型和工具返回结构化结果。这种架构很适合企业里已有的Java服务做能力升级因为它不需要推翻原来的系统只需要在旁边加一个Agent编排层。3.4 把Agent接到生产环境的注意点Demo能跑不代表能上线。我在生产环境里踩过几个坑值得提醒你工具调用的超时和重试大模型响应本身就慢工具如果再调外部API很容易超时。一定要给工具调用设置超时时间并且要设计重试策略。我习惯把工具超时设为3秒最多重试两次重试之间加指数退避避免雪崩。上下文窗口管理Agent每轮都会把历史消息和工具结果塞给模型多个工具返回很长文本时窗口会迅速膨胀。需要做消息裁剪或摘要比如把最旧的对话转成摘要再塞回上下文。权限隔离Agent能调用工具意味着它能执行真实操作。生产环境里要给每个Agent分配独立的指令集和权限范围不要让它直接操作生产数据库或支付接口除非你有完整的审批流。日志和可观测性一定要把“模型输入、模型输出、调了哪个工具、工具返回了什么、下一步决策”打出来。否则线上出了问题你根本不知道是模型判断错了还是工具返回错了。这些点看起来琐碎但恰恰是Agent能不能稳定跑起来的分水岭。很多项目Demo很惊艳一上生产就翻车多半是这些边界情况没处理。4. 进阶场景Skill、知识库与专业工具联动学到这个阶段你已经会搭基本Agent了接下来可以玩几个进阶场景。这些场景其实都来自真实需求也是热搜词里频繁出现的点。把它们做一遍你对Agent的掌控力会有质的提升。4.1 Agent Skill的设计与注册所谓Skill就是Agent的“能力包”。在大模型时代一个技能本质上是一段带有描述和参数定义的工具函数或者是一套提示词加工具的组合。比如你希望Agent会发邮件那么你需要写一个send_email(to, subject, body)函数并在函数的description里写清楚“当用户需要发送邮件时调用”。模型不是真的理解代码它是通过描述来决定什么时候用什么工具。设计Skill有几个原则描述要站在模型视角写不要写“发送邮件函数”要写“当用户要求给某人发邮件时需要提供收件人地址、主题和正文。注意如果用户只给了收件人没给主题可以主动询问或生成默认主题”。描述越具体模型选错工具的概率越低。参数尽量少且类型明确模型填充JSON参数参数越少越不容易出错。复杂的对象结构尽量在函数内部再拆解。一个函数只干一件事不要做一个“万能方法”否则模型会困惑该传什么参数。我在给Agent加技能时还会额外维护一份“工具清单”记录每个函数什么时候被调用、调用频率和失败率。这样后面做Agent评估时一眼就能看出哪些工具设计得不合理。4.2 Obsidian Agent个人知识库变成长期记忆很多人都用Obsidian做笔记其实它也可以作为Agent长期记忆的载体。核心思路是把你笔记库里的Markdown文档切块、向量化然后让Agent在回答问题或规划任务时先检索相关内容。这个方案特别适合程序员、研究员和内容创作者因为你的笔记本身就是训练数据外的高质量信息源。具体做法大概是用Obsidian保存所有笔记建议每个文档有清晰标题方便解析。写一个脚本或使用插件把笔记文件同步到向量数据库比如Chroma、Qdrant或LanceDB。在Agent里增加一个search_knowledge_base(query)工具内部实现“向量召回→重排序→返回TopK文档块”。当Agent遇到跟你的资料库相关的问题时先调用检索工具把结果当作上下文再生成答案。如果你要自己写切块逻辑建议chunk_size设置在500到800字符之间overlap在50到100字符太小信息不完整太大又会稀释关键信息。这样你的Agent就拥有了“读过的资料”这个长期记忆。我见过有人把Obsidian里几百篇技术笔记做成知识库然后用Agent做技术问答效果比直接问大模型准很多因为它能引用你自己的笔记上下文。4.3 画图工具与Agent对接draw.io和hermes agent的集成思路关于“Next AI Draw.io是否支持与Hermes Agent对接”这类问题可以拆成两层看。首先draw.io本身不提供官方开放API但它有一个可以自动生成文件的格式.drawio文件本质上是XML结构你可以让Agent直接生成或修改XML然后交给draw.io打开。也就是说Agent能够通过“生成文件”的方式完成流程图绘制。其次如果hermes agent是一个你可以扩展的智能体系统最常见的对接方式有三条路让Agent调用draw.io命令行工具或脚本比如用drawio-cli把生成好的XML导出为图片。走通用协议如果hermes agent支持MCP或Function Calling那么把drawio-xml-generator封装成工具就行。落到文件系统再同步Agent生成.drawio文件写入指定目录由客户端定时刷新或用户手动打开。一句话不要期待天然兼容本质是“Agent会不会生成draw.io认识的XML文件”。只要你掌握了这个思路不管用什么Agent都能对接上。这个问题背后其实是Agent与专业工具协作的一个常态没有现成API就通过文件格式或自动化脚本来桥接。4.4 硬件场景让Agent生成Verilog代码热搜词里“ai agent verilog代码”这个点有点硬核但它确实是芯片设计领域最近在验证的一条路让Agent根据芯片模块的功能描述直接生成Verilog HDL代码。这个场景很有意思因为Verilog代码有很强的结构化特征适合被大模型生成但验证又非常严谨不能随便糊弄。如果你本身有数字电路基础这是很好的业务切入点。一种比较务实的用法是用Agent帮你搭模块框架、写testbench、生成注释和文档然后再由工程师手工检查和优化关键路径。你可以让Agent做两件事根据模块端口定义生成可编译的Verilog骨架。根据功能描述生成对应的testbench测试向量。要注意的是Agent生成的RTL代码并不能直接用于流片它更适合做前端设计和验证的效率提升工具。如果你在学Agent又懂一点硬件这个方向非常小众却很有前景因为量产落地窗口往往就在这类专业工具辅助场景里先打开。至少我看到的趋势是大模型加专业工具链正在把很多领域的“初稿工作”成本压到很低。5. 面试与实战考核高频考点和答题思路整理AI Agent学习资料的过程中有不少读者是准备面试或转岗所以我单独拿出一章来说面试。面试官问Agent一般绕不开概念、设计和工程细节三座山。5.1 概念题的答题框架遇到“什么是Agent”千万别只回答“能自主规划的AI程序”。你可以用“一个核心三个特征”来组织答案一个核心以LLM为大脑决策是否调用工具、下一步做什么。三个特征有目标导向的规划能力、有调用外部工具的闭环、有利用反馈进行迭代优化的能力。如果再深入一点可以补充“ReAct是Agent的典型实现范式它交替进行推理和行动把思考过程外显化”。面试官最怕听到的是一堆名词最想听到的是你把名词之间的关系讲清楚。你可以边说边画一张流程简图用户输入进LLMLLM输出想法和行动行动调工具工具结果回到LLM循环直到任务完成。这张图一画概念题基本稳了。5.2 设计题的答题套路如果让你设计一个客服Agent可以用下面这个套路明确边界说出Agent可以做初级问答、工单分发和订单查询但涉及退款必须人工介入。设计意图识别模块通过分类器或LLM判断用户意图再决定走FAQ还是工具调用。工具集设计列出需要接的系统订单系统、退换货系统、知识库、客服转接接口。记忆与上下文保存用户会话状态必要时用向量库存历史工单。评估方法用准确率、任务完成率、转人工率、用户满意度来评估而不是只看回复好不好。这个套路在面试中很讨巧因为它展示了你不只会调框架还有产品感和工程意识。如果面试官追问“你怎么保证Agent不会乱承诺”你可以补一句“在Prompt里限制Agent只能基于订单系统的返回结果回答问题超出范围的表达直接拒绝”。这会让面试官觉得你有安全边界意识。5.3 容易翻车的细节面试官通常会追着某个细节往下问这几个坑我见过很多人踩分不清Prompt Engineering和AgentAgent的核心是“模型决定是否调用工具”而Prompt Engineering只是优化单次输出。你可以说Prompt是Agent里规划模块的一部分但Agent多了执行和反馈闭环。忽略工具调用失败很多面试者设计的方案里工具调用永远不会失败。实际工程里工具超时、参数错误、返回非预期格式都是常态需要设计异常路径。记忆方式说不清不要只说“用向量数据库”。要说明哪些信息放短期上下文、哪些放长期向量库以及什么时候做摘要压缩。把这些点准备好面试的胜率会明显提高。我后来也帮朋友模拟过几次Agent方向的技术面发现能从容聊“工具失败后如何兜底”的候选人往往比只会背概念的人拿到的评级更高。6. 2026年趋势判断成熟窗口下学什么更保值最后一部分聊聊最近常被提到的“技术成熟窗口”AI Agent、大模型、多模态交互技术已具备量产落地条件。说实话这个判断我基本认同但落地路径比炒作的要慢核心原因是工程化成熟度还不均衡。6.1 为什么说量产落地窗口到了大模型的API成本在过去一年下降了很多调用一次工具决策的成本已经降到可以支撑商业场景。同时多模态模型能看图、看屏幕、读文档让Agent不再局限于纯文本输入。再加上MCP这类统一工具协议的出现Agent接入企业系统成本大幅降低。三者叠加“量产落地窗口”确实到了。但你需要区分“技术能落地”和“业务能赚钱”。现在跑得比较快的赛道是代码辅助、客服与工单处理、办公自动化、私域知识库问答。这几个场景的共同点是容错率高、流程标准化、ROI容易算清楚。如果你在选方向优先看这些。6.2 多模态Agent是下一个能力爆发点我建议你在学习计划里加上多模态。未来的Agent不只是聊天框它可以直接理解界面截图、操作软件、识别表格和流程图。比如一个Agent看到系统报错弹窗能自行截图并识别错误码再检索知识库给修复方案这已经不再是概念而是很多桌面自动化工具正在做的事。多模态的学习不用单独学太多算法重点理解“模型如何把图片变成token”以及“多模态输入如何影响工具调用判断”。多跑几个把截图传给模型做决策的Demo你就知道下一步应该学什么了。6.3 对学习者的具体建议在这波技术浪潮里我给所有正在整理AI Agent学习资料的人三条建议别追新框架追底层逻辑框架月月更新你学不完的。掌握“感知-规划-行动-记忆”这个逻辑换任何框架都只是改API。坚持做一个端到端项目哪怕只是一个能读本地文件、调用计算器、查天气的Agent也一定要从零做一遍。做过一次你才懂“工具调用失败”有多常见。关注数据和安全2026年的Agent竞争拼的不只是模型聪明不聪明更是谁能把Agent安全地连到企业内部系统里。懂权限控制、知识库隔离和可观测性的人会越来越值钱。我在整理这份资料的过程中最大的感受是AI Agent不是一个新概念2023年就有了但它正在从一个Demo技术变成工程基建。如果你手里的资料还是收藏夹里吃灰不如按这篇的顺序挑一份开始先跑通那个最小的工具调用Demo。只要迈出这一步后面就快了。 
长河君 · 2026/9/8 20:31:49 · 阅读 1.2k AI Agent学习路线：从大模型原理到工程落地的实践指南
这两年只要聊到大模型应用层有一个词你一定绕不开AI Agent。从技术社区到公司内部项目从应届生简历到技术Leader的PPT“AI Agent学习”几乎成了标配。我自己的微信里隔几天就有人发来一份学习资料链接问这个顺序对不对。说实话市面上的资料已经多到看不完但真正能帮你把Agent从概念落到代码的其实就那么几条线。这篇文章算是我一份阶段性的资料整理总结专门讲我筛过、读过、在项目里用过的AI Agent学习内容以及按什么顺序看最不容易半途而废。无论你是刚开始接触的新人还是已经用LangChain写过Demo但还缺系统底层的开发者都可以对照着查漏补缺。1. 先搞懂运行逻辑Agent不是高级聊天机器人很多朋友一上来就问我Agent跟ChatGPT有什么区别不都是对话吗这个问题问不清楚后面看资料就会很痛苦。Agent的核心不是“会聊天”而是“能干活”。它可以自己把用户的目标拆成步骤按顺序去做遇到问题自己调整甚至调用外部工具来补足大模型本身做不到的事情。举一个最直观的例子你让普通聊天机器人生成一份周报它给你一段文字但你让Agent做这件事它可能会先去读取项目管理系统里的任务数据把内容整理成表格再按模板生成一份Markdown文件最后调用邮箱接口发给你的领导。这个过程里对话只是入口任务执行才是核心。1.1 Agent与Chatbot的核心区别为了把概念讲扎实我列了一张对比表你后面看任何资料都可以拿这张表去对照。它回答的核心问题是什么能力是Agent独有的什么能力只是上下文聊天的自然延伸。很多面试和项目评审里这块也是第一个被追问的地方。维度普通ChatbotAI Agent任务方式单轮/多轮对话直接返回回答自主规划任务步骤逐步执行能力边界只有模型本身的知识可调用工具、API、数据库、浏览器等是否感知环境通常不感知只能根据对话内容可以读取文件、网页、系统状态是否具备记忆依赖上下文窗口短时记忆有短期工作记忆和长期存储机制失败处理答错就重新生成能观察反馈、自我纠错、调整计划这张表在面试时很常用你可以把它当成基础话术。说到“对话只是入口”其实还有一层含义是Agent的交互方式正在快速扩展到语音、图像甚至自动触发任务但底层决策循环是不变的。理解了这一点你再看各种花哨的Agent产品就不会被外壳迷惑。1.2 拆解Agent运行循环感知、规划、行动、记忆理解Agent不能停留在概念上要把运行循环刻在脑子里。目前市面上的Agent框架不管名字多高级本质上都在做这么几件事感知把用户的指令、环境状态、工具返回结果转成模型能理解的上下文。规划大模型根据目标拆解出子任务形成执行计划常见的做法是ReAct、Plan-and-Execute、多Agent协作。行动调用工具或代码执行器把规划变成真实世界的操作比如发HTTP请求、写文件、执行SQL。观察与反思拿到工具返回的结果后判断下一步是继续执行、重试还是终止。记忆把对话历史、任务状态、领域知识存起来短期记忆对应上下文窗口长期记忆对应向量数据库或知识库。我建议你在读任何Agent源码之前先拿这个循环去套。看LangChain的一个Agent你会发现它的核心就是“LLM根据输入决定要调哪个Tool然后调用然后把工具结果再丢回LLM判断”看AutoGen你会发现它多个Agent之间本质上也是这个循环的角色化变体。一旦你把这个框架内化后面所有资料都会变得好懂。我见过不少人一上来就啃源码结果被AgentExecutor、ToolNode、StateGraph这些名词淹没其实它们都只是在为“感知-规划-行动-观察”里的某个环节服务。1.3 理解运行逻辑对选资料和学习顺序的影响这个环节很多人会忽略。你一上来就翻代码看到一堆抽象类和回调函数就懵了。反过来你先把运行逻辑捋清楚再去看资料你会带着“哦原来这个函数就是实现规划的那一步”的对应感去读。所以我在下面的学习资料部分会把理论放在代码前面不是不看代码而是我试过很多次这个顺序最不容易劝退自己。它还能帮你过滤掉无效资料凡是连“感知、规划、行动、记忆”都讲不清楚的文章基本不值得花时间。2. 学习资料清单按顺序看才能形成体系我之前收集资料有个毛病先收藏再吃灰。后来我把AI Agent学习资料整理成了一条主线按顺序推进效率高了很多。下面这条线不是简单罗列资源而是每一份资料用来解决什么问题的说明以及我为什么把它放在这个位置。2.1 第一份资料李博杰《深入理解AI Agent》在AI Agent相关的中文资料里李博杰的《深入理解AI Agent》是最近讨论度很高的一份PDF材料许多只言片语的热搜词都是绕着它转的。圈内不少人把它当成“Agent第一课”原因是它的系统性强从LLM的基本能力讲到Agent的整体架构再到规划、记忆、工具使用和多Agent协同最后落到典型应用场景几乎是按教科书逻辑写的。这对中文读者非常友好因为Agent领域的术语在中文社区里还没有完全统一作者的系统梳理能帮你把概念锚定住。我对这份材料的建议是拿到手后先别急着划线把目录过一遍然后在纸上画一份思维导图只需要写出“感知-规划-行动-记忆-工具”和“Agent生命周期”这些主节点。之后随着你读代码、看论文再回来补细节点。很多人说这份PDF难找其实你在技术圈搜一下标题作者授权过的转载版本还是有的但如果找不到去看作者相关的演讲或直播回放内容框架也差不多。注意别把这个当成唯一资料它是地图不是终点否则你会陷入“光看懂不会做”的状态。2.2 必要的英文课程与经典论文理论地图有了接下来填英文世界的优质内容。这部分我不建议全都看本着“够用就行”的原则挑三个方向Hugging Face的Agent课程免费网页上直接读它的特点是把Agent拆成“模型工具指令”三层还提供了很多可运行的小例子适合第一批动手代码。DeepLearning.AI上的Functions, Tools and Agents with LangChain偏工程短课能快速理解工具调用和AgentExecutor的来龙去脉。几篇论文ReAct、Toolformer、Reflexion再加2023年的综述《The Rise and Potential of Large Language Model Based Agents》。论文不需要精读重点是提取“为什么”ReAct为什么要交替Reason和ActReflexion为什么要加自我反思带着问题读比从头读到尾有效得多。很多中文平台也翻译了几篇关键论文但我的经验是能读原文就尽量读原文。原因是Agent领域的术语翻译还不统一同一个词在不同文章里可能被译成“代理”“智能体”“主体”尤其在技术讨论时名词不一致会带来很大的沟通成本。英文原文至少能让你回到准确术语上后续查资料也会顺很多。2.3 值得精读的开源项目源码资料看得再多不动手拆代码是不完整的。我只推荐三个项目按顺序来LangChain的agent相关示例适合初学你能看到最标准的create_react_agent写法。LangGraph的官方示例适合理解状态机式的Agent流程它的设计比LangChain更接近生产。MetaGPT或AutoGen一个偏多Agent协作一个偏对话自动化和代码生成适合进阶参考。读源码时有个技巧不要用眼睛过代码要“按调用链走”。比如LangChain里的Agent先找到入口然后看LLM被调用后输出了什么格式哪个函数解析了这个输出哪个函数根据输出选了工具工具返回后结果又回到了哪里。把这条链路走通一遍胜过你抄十遍Demo。很多人卡在“读不懂抽象层”其实只要抓住一个点Agent就是“模型决定调什么工具程序去执行再把结果喂回给模型”所有框架都在给这个循环做封装。2.4 中文社区里比较靠谱的导航仓库中文方面GitHub上有几个无版权风险的导航仓库可以收藏比如Awesome-AI-Agents和LLM-Agent-Paper-List。前者收集了Agent相关开源工具和研究文章后者按主题整理了论文列表。你不需要全部读完作为“查资料时知道去哪找”就够了。另外知乎上一些Agent落地实践的专栏也值得看但要注意筛选凡是只讲概念不贴代码或没有真实数据支撑的大概率是营销号。判断一篇Agent文章是否值得读我就看一点它有没有贴出完整的工具调用链路以及有没有说清楚工具返回异常时怎么处理。没有这两点的基本可以跳过。到这里你已经有了一条“理论→课程→论文→源码→导航”的完整学习线。如果你严格按这条线走大概两到四周就能搭起自己的认知框架。接下来我们要聊动手的事。3. 动手搭建框架选型与最小Agent示例学Agent如果不动手写一个能跑的程序很快会忘。这一章我分成选型、Python示例、Java路线和生产注意点四块最后一块是我在实际项目里吃过亏才总结出来的建议你重点看。3.1 主流框架怎么选LangChain/LangGraph/AutoGen/CrewAI对比市面上框架很多但底子大同小异。我根据自己的使用体感列了一张表你可以按项目类型去选不必追求“最火的”而是要选“最不别扭的”。框架核心风格适合场景上手难度LangChain组件丰富开发快快速做原型、工具调用、RAG中LangGraph图状态机可控性强复杂流程、生产级Agent中高AutoGen多Agent对话多个角色互相协作、代码执行中CrewAI角色分工清晰模拟团队做任务低我的建议是第一遍用LangChain或直接写不带框架的原生工具调用代码把运行逻辑吃透第二遍如果做正式项目再切LangGraph因为它能显式定义状态、回边和条件分支对“某个步骤失败了怎么办”这类问题处理得比LangChain老版本优雅得多。AutoGen适合你有“两个Agent互相辩论”这类需求时再看CrewAI则适合做业务演示因为它的“角色、任务、流程”概念非常直观老板容易看懂。3.2 Python生态里的一个最小Agent示例如果不想在一开始就背框架API可以直接用OpenAI兼容接口来做“函数调用”这是理解Agent工具机制最快的方式。下面这个例子用最少的代码实现一个能查本地天气的Agentfrom openai import OpenAI client OpenAI(base_urlhttp://localhost:11434/v1, api_keyollama) # 如果你用本地Ollama也可以用这样的兼容地址 tools [ { type: function, function: { name: get_weather, description: 查询某个城市的天气, parameters: { type: object, properties: { city: {type: string, description: 城市名} }, required: [city] } } } ] def get_weather(city: str): # 这里真实开发会调天气APIdemo阶段先返回固定值 return f{city}当前气温26摄氏度多云 messages [{role: user, content: 北京天气怎么样}] response client.chat.completions.create( modelqwen2.5, messagesmessages, toolstools, tool_choiceauto ) msg response.choices[0].message if msg.tool_calls: # Agent决定调用工具 for tool_call in msg.tool_calls: if tool_call.function.name get_weather: city eval(tool_call.function.arguments)[city] result get_weather(city) print(result)这个示例的核心价值在于你亲眼看到了“模型输出工具调用请求→程序执行真实函数→拿到结果”这一条链路。在这个基础上再去写while循环让模型根据工具结果继续判断就是一个mini Agent了。当然生产环境不要用eval解析参数要用json.loads来做类型安全处理。很多教程会直接用eval这会让代码跑起来很爽但也会让线上服务变得很脆弱。3.3 Java开发者路线Spring Boot Spring AI/LangChain4j不少后端同学是Java技术栈问得最多的就是“Java能不能做Agent”。当然可以现在Java生态也有两个方向Spring AI和LangChain4j。它们都提供了类似Python版本的工具调用、Agent执行器和模型客户端接口。如果你本身就在Spring Boot项目里把它们当作一个客户端模块接入比自己用HttpClient去拼Prompt要省心得多。以Spring Boot为例常见做法是引入spring-ai-openai或langchain4j-open-ai依赖。配置base-url指向你的模型服务地址比如Ollama、vLLM或云厂商兼容接口。定义一个工具类在方法上注册Tool注解框架会在Agent需要时自动调用。Spring AI的好处是跟Spring生态无缝整合事务、配置、监控都能用上LangChain4j更接近LangChain的设计如果你习惯Python侧的概念切换成本低。我见过不少项目把Agent作为Spring Boot的一个客户端模块接收上层请求再调用模型和工具返回结构化结果。这种架构很适合企业里已有的Java服务做能力升级因为它不需要推翻原来的系统只需要在旁边加一个Agent编排层。3.4 把Agent接到生产环境的注意点Demo能跑不代表能上线。我在生产环境里踩过几个坑值得提醒你工具调用的超时和重试大模型响应本身就慢工具如果再调外部API很容易超时。一定要给工具调用设置超时时间并且要设计重试策略。我习惯把工具超时设为3秒最多重试两次重试之间加指数退避避免雪崩。上下文窗口管理Agent每轮都会把历史消息和工具结果塞给模型多个工具返回很长文本时窗口会迅速膨胀。需要做消息裁剪或摘要比如把最旧的对话转成摘要再塞回上下文。权限隔离Agent能调用工具意味着它能执行真实操作。生产环境里要给每个Agent分配独立的指令集和权限范围不要让它直接操作生产数据库或支付接口除非你有完整的审批流。日志和可观测性一定要把“模型输入、模型输出、调了哪个工具、工具返回了什么、下一步决策”打出来。否则线上出了问题你根本不知道是模型判断错了还是工具返回错了。这些点看起来琐碎但恰恰是Agent能不能稳定跑起来的分水岭。很多项目Demo很惊艳一上生产就翻车多半是这些边界情况没处理。4. 进阶场景Skill、知识库与专业工具联动学到这个阶段你已经会搭基本Agent了接下来可以玩几个进阶场景。这些场景其实都来自真实需求也是热搜词里频繁出现的点。把它们做一遍你对Agent的掌控力会有质的提升。4.1 Agent Skill的设计与注册所谓Skill就是Agent的“能力包”。在大模型时代一个技能本质上是一段带有描述和参数定义的工具函数或者是一套提示词加工具的组合。比如你希望Agent会发邮件那么你需要写一个send_email(to, subject, body)函数并在函数的description里写清楚“当用户需要发送邮件时调用”。模型不是真的理解代码它是通过描述来决定什么时候用什么工具。设计Skill有几个原则描述要站在模型视角写不要写“发送邮件函数”要写“当用户要求给某人发邮件时需要提供收件人地址、主题和正文。注意如果用户只给了收件人没给主题可以主动询问或生成默认主题”。描述越具体模型选错工具的概率越低。参数尽量少且类型明确模型填充JSON参数参数越少越不容易出错。复杂的对象结构尽量在函数内部再拆解。一个函数只干一件事不要做一个“万能方法”否则模型会困惑该传什么参数。我在给Agent加技能时还会额外维护一份“工具清单”记录每个函数什么时候被调用、调用频率和失败率。这样后面做Agent评估时一眼就能看出哪些工具设计得不合理。4.2 Obsidian Agent个人知识库变成长期记忆很多人都用Obsidian做笔记其实它也可以作为Agent长期记忆的载体。核心思路是把你笔记库里的Markdown文档切块、向量化然后让Agent在回答问题或规划任务时先检索相关内容。这个方案特别适合程序员、研究员和内容创作者因为你的笔记本身就是训练数据外的高质量信息源。具体做法大概是用Obsidian保存所有笔记建议每个文档有清晰标题方便解析。写一个脚本或使用插件把笔记文件同步到向量数据库比如Chroma、Qdrant或LanceDB。在Agent里增加一个search_knowledge_base(query)工具内部实现“向量召回→重排序→返回TopK文档块”。当Agent遇到跟你的资料库相关的问题时先调用检索工具把结果当作上下文再生成答案。如果你要自己写切块逻辑建议chunk_size设置在500到800字符之间overlap在50到100字符太小信息不完整太大又会稀释关键信息。这样你的Agent就拥有了“读过的资料”这个长期记忆。我见过有人把Obsidian里几百篇技术笔记做成知识库然后用Agent做技术问答效果比直接问大模型准很多因为它能引用你自己的笔记上下文。4.3 画图工具与Agent对接draw.io和hermes agent的集成思路关于“Next AI Draw.io是否支持与Hermes Agent对接”这类问题可以拆成两层看。首先draw.io本身不提供官方开放API但它有一个可以自动生成文件的格式.drawio文件本质上是XML结构你可以让Agent直接生成或修改XML然后交给draw.io打开。也就是说Agent能够通过“生成文件”的方式完成流程图绘制。其次如果hermes agent是一个你可以扩展的智能体系统最常见的对接方式有三条路让Agent调用draw.io命令行工具或脚本比如用drawio-cli把生成好的XML导出为图片。走通用协议如果hermes agent支持MCP或Function Calling那么把drawio-xml-generator封装成工具就行。落到文件系统再同步Agent生成.drawio文件写入指定目录由客户端定时刷新或用户手动打开。一句话不要期待天然兼容本质是“Agent会不会生成draw.io认识的XML文件”。只要你掌握了这个思路不管用什么Agent都能对接上。这个问题背后其实是Agent与专业工具协作的一个常态没有现成API就通过文件格式或自动化脚本来桥接。4.4 硬件场景让Agent生成Verilog代码热搜词里“ai agent verilog代码”这个点有点硬核但它确实是芯片设计领域最近在验证的一条路让Agent根据芯片模块的功能描述直接生成Verilog HDL代码。这个场景很有意思因为Verilog代码有很强的结构化特征适合被大模型生成但验证又非常严谨不能随便糊弄。如果你本身有数字电路基础这是很好的业务切入点。一种比较务实的用法是用Agent帮你搭模块框架、写testbench、生成注释和文档然后再由工程师手工检查和优化关键路径。你可以让Agent做两件事根据模块端口定义生成可编译的Verilog骨架。根据功能描述生成对应的testbench测试向量。要注意的是Agent生成的RTL代码并不能直接用于流片它更适合做前端设计和验证的效率提升工具。如果你在学Agent又懂一点硬件这个方向非常小众却很有前景因为量产落地窗口往往就在这类专业工具辅助场景里先打开。至少我看到的趋势是大模型加专业工具链正在把很多领域的“初稿工作”成本压到很低。5. 面试与实战考核高频考点和答题思路整理AI Agent学习资料的过程中有不少读者是准备面试或转岗所以我单独拿出一章来说面试。面试官问Agent一般绕不开概念、设计和工程细节三座山。5.1 概念题的答题框架遇到“什么是Agent”千万别只回答“能自主规划的AI程序”。你可以用“一个核心三个特征”来组织答案一个核心以LLM为大脑决策是否调用工具、下一步做什么。三个特征有目标导向的规划能力、有调用外部工具的闭环、有利用反馈进行迭代优化的能力。如果再深入一点可以补充“ReAct是Agent的典型实现范式它交替进行推理和行动把思考过程外显化”。面试官最怕听到的是一堆名词最想听到的是你把名词之间的关系讲清楚。你可以边说边画一张流程简图用户输入进LLMLLM输出想法和行动行动调工具工具结果回到LLM循环直到任务完成。这张图一画概念题基本稳了。5.2 设计题的答题套路如果让你设计一个客服Agent可以用下面这个套路明确边界说出Agent可以做初级问答、工单分发和订单查询但涉及退款必须人工介入。设计意图识别模块通过分类器或LLM判断用户意图再决定走FAQ还是工具调用。工具集设计列出需要接的系统订单系统、退换货系统、知识库、客服转接接口。记忆与上下文保存用户会话状态必要时用向量库存历史工单。评估方法用准确率、任务完成率、转人工率、用户满意度来评估而不是只看回复好不好。这个套路在面试中很讨巧因为它展示了你不只会调框架还有产品感和工程意识。如果面试官追问“你怎么保证Agent不会乱承诺”你可以补一句“在Prompt里限制Agent只能基于订单系统的返回结果回答问题超出范围的表达直接拒绝”。这会让面试官觉得你有安全边界意识。5.3 容易翻车的细节面试官通常会追着某个细节往下问这几个坑我见过很多人踩分不清Prompt Engineering和AgentAgent的核心是“模型决定是否调用工具”而Prompt Engineering只是优化单次输出。你可以说Prompt是Agent里规划模块的一部分但Agent多了执行和反馈闭环。忽略工具调用失败很多面试者设计的方案里工具调用永远不会失败。实际工程里工具超时、参数错误、返回非预期格式都是常态需要设计异常路径。记忆方式说不清不要只说“用向量数据库”。要说明哪些信息放短期上下文、哪些放长期向量库以及什么时候做摘要压缩。把这些点准备好面试的胜率会明显提高。我后来也帮朋友模拟过几次Agent方向的技术面发现能从容聊“工具失败后如何兜底”的候选人往往比只会背概念的人拿到的评级更高。6. 2026年趋势判断成熟窗口下学什么更保值最后一部分聊聊最近常被提到的“技术成熟窗口”AI Agent、大模型、多模态交互技术已具备量产落地条件。说实话这个判断我基本认同但落地路径比炒作的要慢核心原因是工程化成熟度还不均衡。6.1 为什么说量产落地窗口到了大模型的API成本在过去一年下降了很多调用一次工具决策的成本已经降到可以支撑商业场景。同时多模态模型能看图、看屏幕、读文档让Agent不再局限于纯文本输入。再加上MCP这类统一工具协议的出现Agent接入企业系统成本大幅降低。三者叠加“量产落地窗口”确实到了。但你需要区分“技术能落地”和“业务能赚钱”。现在跑得比较快的赛道是代码辅助、客服与工单处理、办公自动化、私域知识库问答。这几个场景的共同点是容错率高、流程标准化、ROI容易算清楚。如果你在选方向优先看这些。6.2 多模态Agent是下一个能力爆发点我建议你在学习计划里加上多模态。未来的Agent不只是聊天框它可以直接理解界面截图、操作软件、识别表格和流程图。比如一个Agent看到系统报错弹窗能自行截图并识别错误码再检索知识库给修复方案这已经不再是概念而是很多桌面自动化工具正在做的事。多模态的学习不用单独学太多算法重点理解“模型如何把图片变成token”以及“多模态输入如何影响工具调用判断”。多跑几个把截图传给模型做决策的Demo你就知道下一步应该学什么了。6.3 对学习者的具体建议在这波技术浪潮里我给所有正在整理AI Agent学习资料的人三条建议别追新框架追底层逻辑框架月月更新你学不完的。掌握“感知-规划-行动-记忆”这个逻辑换任何框架都只是改API。坚持做一个端到端项目哪怕只是一个能读本地文件、调用计算器、查天气的Agent也一定要从零做一遍。做过一次你才懂“工具调用失败”有多常见。关注数据和安全2026年的Agent竞争拼的不只是模型聪明不聪明更是谁能把Agent安全地连到企业内部系统里。懂权限控制、知识库隔离和可观测性的人会越来越值钱。我在整理这份资料的过程中最大的感受是AI Agent不是一个新概念2023年就有了但它正在从一个Demo技术变成工程基建。如果你手里的资料还是收藏夹里吃灰不如按这篇的顺序挑一份开始先跑通那个最小的工具调用Demo。只要迈出这一步后面就快了。