为什么你的AI Agent总是金鱼脑LangGraph记忆模板深度揭秘从提取-更新双引擎到长短记忆协同的硬核实现全解手把手教你打通Agent记忆的任督二脉本文将抛开官方文档的抽象描述以工程视角深入LangGraph应用开发模板中的记忆模块。我们将逐一拆解记忆提取的查询链路、状态机流转、Store读写机制以及更新过程中的原子性保障与冲突处理。无论你是刚接触LangGraph的新手还是在生产环境被记忆丢失、状态混乱折磨过的开发者这篇文章都将为你提供一套可直接落地的记忆管理认知框架与实战 checklist。LangGraph记忆模板深度解析提取与更新要点1: 记忆架构全景与分层认知要点2: 短期记忆提取与Checkpoint机制要点3: 长期记忆查询与Namespace设计要点4: 记忆更新时机与数据一致性要点5: 并发冲突与原子性保障要点6: 记忆与上下文的协同注入要点7: 调试观测与问题定位本文目录要点1记忆架构全景与分层认知要点2短期记忆提取与Checkpoint机制要点3长期记忆查询与Namespace设计要点4记忆更新时机与数据一致性要点5并发冲突与原子性保障要点6记忆与上下文的协同注入要点7调试观测与问题定位嗨大家好呀我是你的老朋友精通代码大仙。接下来我们一起学习 《LangChain核心技术与LLM项目实践》。都说好记性不如烂笔头可到了LangGraph这里很多兄弟发现就算自己写了烂笔头AI该忘的还是忘该乱的照样乱。你辛辛苦苦搭了个Agent眼看着它能聊天能推理结果用户多聊了两轮它就开始六亲不认你把用户偏好写进了某个字典重启服务后全没了你想让Agent记住跨会话的知识却发现它要么记忆串台要么干脆直接 hallucination 给你现编。别急这不是你一个人的战斗今天咱们就把LangGraph记忆模板里提取与更新这两个最硬核的环节掰开了揉碎了讲清楚。要点一记忆架构全景与分层认知在LangGraph的世界里记忆从来都不是一个简单的全局变量也不是你在Python脚本顶部写的一个memory {}就能搞定的事情。它的记忆体系是一套严格分层的架构搞混了任何一层你的Agent就会像得了阿尔茨海默症一样要么刚说的话就忘要么把三年前的事当成昨天刚发生的。咱们先把这张地图画清楚。LangGraph的记忆体系大致可以分成三层最上面是Thread State也就是线程级别的短期记忆它跟着一次对话走靠Checkpoint机制做快照恢复中间一层是Store也就是长期记忆仓库用来存放用户画像、业务事实、历史总结这些需要跨会话持久化的数据最底下还有一些特殊的跨线程共享状态比如全局配置、知识库索引或者权限缓存。这三层各有各的存储介质各有各的生命周期你不能把衬衫塞到西装裤的口袋里对吧新手最容易踩的坑就是误以为State里的数据会自动渗透成长期记忆。我见过太多这样的代码了在节点函数里直接写state[user_preference] 喜欢Python然后满心欢喜地觉得这下Agent记住了。结果呢下一次新开一个thread_id或者哪怕只是重启了一下服务这个偏好就人间蒸发了。为啥因为普通的State只活在当前图的执行周期里除非你明确配置了Checkpoint Saver并且从正确的thread恢复否则它连短期记忆都算不上顶多算个临时变量节点跑完就灰飞烟灭。还有更离谱的有人把长期记忆往State里疯狂塞几十条历史记录、几百条用户行为全堆在State那个字典里。State是什么它是图节点之间传递的接力棒你塞太多东西每次节点之间传数据都像在搬砖延迟高得吓人。而且LangGraph的Checkpoint在持久化State的时候会把这一大坨全写进数据库。我曾经见过一个兄弟的Checkpoint表单条记录就几MB Postgres 直接报警读写速度慢得像蜗牛爬。这就是典型的分层不清把仓库里的货全堆在了传送带上。那正确的姿势是什么呢记住一个铁律当前对话要用的上下文放State跨会话需要记住的事实放Store。举个例子用户此刻在问我上一句说的那个需求改了吗这种短期上下文靠Checkpoint就搞定了你只要传对thread_idLangGraph会自动帮你从最近的Checkpoint恢复State你不需要手动去翻历史记录。但如果是这个用户永远只接受Python方案的回复这种长期标签就必须写到Store里给它一个稳稳的namespace和key让它住上产权房而不是临时出租屋。具体来说在你的图定义里你应该明确区分两类节点的职责一类是处理当前推理的业务节点它们读写State关注此刻的上下文另一类是记忆管理节点它们负责在适当的时机去Store里查数据或者写数据。不要把这两件事搅在一锅粥里。比如你可以设计一个load_memory节点在图的开头从Store里读取用户画像塞进State的特定字段再设计一个save_memory节点在图的末尾把新发现的事实写回Store。这样结构清晰后面调试起来也知道水是从哪流过来的。理解分层是避免Agent失忆的第一步。State是Agent的短期工作记忆Store才是它的长期海马体分清楚了后面的路才好走否则你所有的记忆优化都是在沙滩上盖楼。要点二短期记忆提取与Checkpoint机制说完了架构咱们来细聊短期记忆是怎么被提取出来的。LangGraph实现短期记忆的核心武器是Checkpoint它的本质就是对Thread State按时间切片做快照。每次你的图执行到一个断点Checkpoint Saver就会咔嚓一下把当前State拍下来存好。等下一次用户再发消息系统就会根据你提供的thread_id找到最新的那张快照把State恢复到断点处继续往下跑。这听起来很美好对吧但坑就藏在这个自动二字里。很多新手以为只要我在调用graph.invoke的时候传了stateLangGraph就会智能地帮我合并历史。太天真了你每次invoke不传config里的thread_idLangGraph就以为你在开一场全新的对话它会从零开始初始化State之前的上下文不存在的。我见过最经典的报错现场是这样的开发者明明上一轮让Agent记住了我在做电商项目下一轮问那个项目进度如何Agent一脸茫然“什么项目我没听说过啊。” 开发者急得跳脚查了半天代码发现原来是configurable字典里忘了放thread_id。还有一个隐蔽的误区是对Checkpoint恢复时机的误解。有些同学喜欢在图的中间节点里手动去修改Checkpoint或者试图直接读取某个历史Checkpoint的原始数据来做对比。兄弟Checkpoint是LangGraph的私有财产它的读取和写入是由Saver统一管理的。你应该通过正规的State传递来获取历史上下文而不是去挖Checkpoint的墙角。曾经有个小哥为了优化性能自己写SQL去查Checkpoint表试图绕过LangGraph的恢复逻辑结果State版本对不上图执行到一半直接崩掉报错信息还特别迷惑像是checkpoint tuple not found之类的整整卡了他两天。正确的做法其实特别简单简单到让人想哭。你只需要确保两点第一在调用图的时候始终传入包含thread_id的config第二不要试图在业务逻辑里手动管理Checkpoint的序列号。LangGraph的MemorySaver、PostgresSaver或者RedisSaver会自动处理checkpoint_id的递增和回滚。你唯一需要关心的是你的state数据结构里有没有把需要持久化的短期信息放进去。比如如果你希望Agent记住当前对话的主题那就把这个主题放在state的一个字段里只要thread_id不变下一次invoke它自然还在。这里再给你一个血泪经验thread_id的设计一定要稳定。不要用随机UUID每一次都生成新的也不要把timestamp拼在thread_id里除非你真的想开启新对话。我见过有人为了保险每次前端请求都带一个新的thread_id结果用户刷新一下页面Agent就失忆一次用户体验直接归零。正确的thread_id应该绑定到业务实体上比如用户的session_id或者一个稳定的conversation_id。再补一个代码层面的细节。当你在节点里读取State时不要假设某个字段一定存在。因为Checkpoint恢复可能存在版本差异尤其是你升级了图结构、新增了state字段之后旧的Checkpoint里是没有这个新字段的。如果你直接state[new_field]大概率会吃到KeyError。养成习惯用state.get(new_field, default_value)这样你的图才能兼容新旧Checkpoint不至于换个版本就起不来。总之短期记忆靠Checkpointthread_id是你的会话钥匙别丢了也别乱换。把State当成当前对话的草稿纸 Checkpoint就是那个帮你自动存档的云端理解了这个关系你的Agent至少不会再金鱼脑了。要点三长期记忆查询与Namespace设计短期记忆能保你当前会话不断片但真正的智能Agent得认识用户哪怕用户三天后再来它也能记得人家喜欢用什么技术栈、有什么特殊偏好。这就是长期记忆的战场而在LangGraph里长期记忆的载体就是Store。Store这玩意儿本质上是一个键值对外加搜索能力的存储层。它可以是内存里的InMemoryStore也可以是生产环境里的Redis、Postgres甚至向量数据库。但不管底层是什么你在LangGraph里操作Store的时候都会遇到一个核心概念Namespace。很多新手第一次看见store.get(namespace, key)这个API时完全没意识到namespace的重要性。他们往往简单粗暴地写死一个字符串比如namespacememories然后把所有用户的数据都往里面扔。这就好比把全公司员工的档案全塞在一个柜子里还不分格子。结果呢查询的时候互相污染用户A的隐私偏好被用户B的Agent读到了或者不同项目的记忆混成一团Agent回答的时候张冠李戴。这种锅一旦背上可不是改两行代码就能了事的轻则数据错乱重则安全合规暴雷。还有一种常见的错误是混淆了Store和State的查询时机。有些同学在图的中间节点里每次都需要长期记忆的时候都现场去Store里查一次。这本身没问题但问题出在他们查完之后不对查询结果做缓存或者状态绑定导致同一个图执行周期内对Store发起了三四次同样的请求。Latency蹭蹭往上涨Store后端的压力也受不了。更有甚者把Store的查询写在了循环节点里每迭代一次查一次那性能简直酸爽。那Namespace到底该怎么设计记住一个原则Namespace是一个元组tuple而不是一个字符串。它的设计应该体现出数据的层级关系。比如(user_id, preferences)、(user_id, project_id, facts)、(org_id, knowledge_base)。这样设计的好处是你在查询的时候可以精准定位到某个层级既不会读到别人的数据也方便后续做权限隔离。LangGraph的Store API在搜索时是支持前缀匹配Namespace的所以你按层级组织还能实现灵活的批量查询。代码层面我建议你在项目初期就定义好Namespace的常量或者枚举别到处硬编码字符串。比如USER_PREF_NSlambdauid:(uid,preferences)PROJECT_FACTS_NSlambdauid,pid:(uid,pid,facts)在节点里读取长期记忆的时候先明确你的查询策略是精确查某一条store.get还是语义搜索store.search如果是精确查询确保你的key设计有规律比如用fuser_{user_id}_pref。如果是语义搜索那你需要确保存入Store的时候写了embedding查询的时候也要把query向量化。别把store.search当成全文检索来用传进去一个普通字符串却期望它理解语义这样召回的记忆往往风马牛不相及Agent看了这些乱七八糟的相关记忆不 hallucination 才怪。另外长期记忆的提取一定要做相关性过滤。哪怕你的Namespace设计得再好召回的记忆也不一定全都有用。在把记忆注入Prompt之前加一个打分或者排序逻辑只把最相关的top-k条放进去。这不仅能节省Token还能显著提升Agent回答的准确度。你可以用简单的关键词匹配做初筛再用向量相似度做精排具体策略视你的业务复杂度而定。Namespace是长期记忆的地址系统乱了就全乱了。像图书馆编目一样对待它你的Agent才能在最短的时间里找到那本对的档案。要点四记忆更新时机与数据一致性记忆不是只读的。Agent在跟用户聊天的过程中会不断发现新的事实用户改了地址、换了对技术的偏好、项目进入了新阶段。这些信息需要被及时写回Store才能成为真正的长期记忆。但什么时候写、“怎么写”这里面大有学问。新手最容易犯的错是在业务节点的中间就迫不及待地写Store。比如在一个叫process_order的节点里代码跑到一半刚解析出用户的新地址立刻就调用store.put(namespace, key, value)把地址存了。然后呢这个节点后面的逻辑抛了个异常或者下游节点判断当前操作不合法整个图需要回滚。问题是State的回滚由Checkpoint保障但Store的操作是独立的副作用它可不会自动跟着回滚于是你的数据库里留下了一条脏数据下次读取的时候Agent以为用户已经搬到了火星实际上订单根本没成交。这种脏写问题在复杂的图里特别隐蔽。因为LangGraph的节点执行看起来是原子步骤但Store操作绕过了State机的事务边界。还有一个类似的坑是在条件边conditional edge里写Store。条件边的职责是根据State决定下一步走哪个节点它本应该是个纯函数只读不写。如果你在条件边里偷偷写了Store不仅让图的逻辑变得不可预测还会让调试变成噩梦。想象一下你的图走了条不一样的分支原因就是某个条件边里的一次Store写入改变了外部状态这种bug能让你查到怀疑人生。那正确的更新姿势是什么核心思想就一句话让记忆更新靠近事务的边界最好是图的出口处或者一个专门的原子节点内。具体来说有两种主流模式。第一种是收集-批量写入模式。你在各个业务节点里只负责在State里标记待写入的记忆比如往state[pending_memories]里追加一条记录。等所有业务逻辑跑完进入一个专门的persist_memory节点这个节点一次性把pending列表里的内容全部写入Store。因为此时业务逻辑已经走完State是确定的写入Store的数据也是经过校验的。如果前面的节点失败了State回滚pending_memories里自然也就没有脏数据Store还是干净的。第二种模式是利用LangGraph的exit hook或者图的尾部回调。如果你用的是比较底层的Saver实现可以在Checkpoint成功持久化之后再触发Store的写入。这样就把Store的副作用绑定到了Checkpoint的成功提交上近似实现了分布式事务的两阶段提交。当然这需要你对LangGraph的生命周期有足够的了解不适合完全的新手但作为一个进阶方向你可以记在心上。还有一个细节是写入的幂等性。因为网络超时或者重试机制同一个记忆更新请求可能会被发送两次。如果你的store.put不具备幂等性就可能出现重复数据。建议在写入的时候用业务层面唯一的key或者在value里带上版本号、时间戳写入前先做存在性检查。这样哪怕重试也不怕重复。记忆的写入要像银行转账一样谨慎确认好业务成功、State落地之后再把钱数据转过去。别在半路就掏钱包万一交易取消钱要不回来记忆也就脏了。要点五并发冲突与原子性保障如果你的Agent只是单机跑着玩玩可能还体会不到并发带来的酸爽。但一旦上了生产环境同一个用户快速连发两条消息或者多个用户同时操作共享资源记忆的并发问题就会像幽灵一样冒出来。最典型的场景是这样的用户连续发送了两条消息Message A和Message B。你的服务开了两个Worker或者同一个实例里的异步任务几乎同时开始处理这两个请求。它们都读取了Store里同一份长期记忆比如用户的兴趣标签列表当时列表里是[Python]。处理Message A的实例发现用户提到了Go于是它在旧列表基础上加了Go变成[Python, Go]写回Store。几乎在同一时刻处理Message B的实例发现用户提到了Rust它读到的也是旧列表[Python]加了Rust之后写回Store变成[Python, Rust]。最后Store里的结果是[Python, Rust]Go丢了这就是经典的读-改-写竞态条件。新手在这里往往束手无策因为LangGraph的Store API本身并不保证跨请求的分布式锁。store.get和store.put是两个独立的操作中间没有原子性保护。有些同学试图在应用层加个线程锁比如threading.Lock()这在单机多线程里或许有点用但一旦你的服务是多个容器、多个进程线程锁就完全失效了。还有人干脆放弃治疗假装没看见直到用户投诉我明明说了我喜欢Go你怎么忘了才追悔莫及。那怎么破首先如果你的Store底层是Redis可以利用Redis的原子操作比如HINCRBY、LPUSH、或者Lua脚本来实现原子性的列表追加。如果你的Store底层是Postgres可以在应用层利用数据库的行级锁或者乐观锁。LangGraph的Store抽象层允许你传入自定义的Store实现所以这并不是天方夜谭。但对于大多数使用内置Store的同学我推荐一个更务实的方案业务层规避。尽量避免在并发路径上去更新同一个key的同一个字段。比如上面的兴趣标签例子你可以换一个数据结构不再用一个列表来存所有标签而是每个标签单独一条记录key设计成ftag_{tag_name}value是布尔或者时间戳。这样添加Go和添加Rust就是在写两个不同的key天然没有覆盖冲突。查询的时候用store.search前缀匹配一下就能拿到所有标签。另一个策略是串行化写入。如果你一定要修改同一个key那就把记忆更新逻辑集中到图的特定串行节点中并且利用消息队列或者分布式锁确保同一个用户的记忆更新请求是串行处理的。LangGraph的checkpoint机制在同一线程内是串行的所以你只要保证同一个thread_id的请求路由到同一个处理队列就能在很大程度上避免并发写冲突。还有一个取巧的办法就是给记忆加上版本向量或者最后写入时间戳。在读取记忆的时候把版本号一并读出来写入的时候带上预期的版本号Store底层在更新时检查版本号是否匹配如果不匹配说明期间被别的请求改过本次写入失败可以触发重试或者合并逻辑。这比单纯的覆盖要安全得多。并发是记忆的隐形杀手要么在架构上锁好门要么在数据设计上让不同的写入者各行其道别让他们在狭窄的走廊里撞车。要点六记忆与上下文的协同注入好不容易把记忆提取出来了也写好了现在有个更棘手的问题怎么把这些记忆塞给大模型直接全怼进Prompt里吗那你的Token账单可能会让你夜不能寐。而且LLM的上下文窗口是有限的你把成百上千字的长期记忆全塞进去真正重要的当前指令反而被挤到了后面模型根本看不见。我见过最极端的案例是一个做法律咨询的Agent它把用户过去三年的所有咨询记录全拼进了System Prompt。结果用户问一个简单的问题Agent的回复开始胡言乱语引用了已经完全过时的法律条文。为啥因为Prompt太长了后面的关键约束被截断模型只能看到前面那些陈芝麻烂谷子的记录开始张冠李戴。这就是典型的记忆过载引发的幻觉。另一个反面教材是过度依赖向量召回。有些同学一听说RAG好用就把所有记忆都做成向量每次查询扔进去一个问题召回top-5条相关记忆。问题是向量相似度不代表业务相关。你问我的密码是多少召回的可能是如何设置密码、“密码安全规范”唯独没有你的密码是123456。语义搜索有它的盲区对于精确事实的查询有时候不如精确key查询靠谱。那正确的记忆注入策略是什么我总结了一个三段式的配方近期对话摘要 关键事实卡片 当前上下文。这三段分工明确互相补充既能保证模型了解来龙去脉又不会把窗口塞爆。近期对话摘要负责告诉模型咱们刚才聊到哪了。这个摘要不是原始对话记录的堆砌而是对当前Thread State里历史消息的压缩。你可以在图的入口处用一个专门的节点来维护这个摘要。当对话轮数超过阈值时把早期的消息交给LLM做摘要替换掉原始消息。LangGraph的Checkpoint里存的是完整State但你的State里可以只保留最近N轮消息加一个滚动摘要这样State既轻量信息量又够。关键事实卡片来自长期记忆Store。但别一股脑全塞要做一个记忆优先级的排序。我的经验是近期变更的事实 高频提及的偏好 基础的用户画像 通用的背景知识。你可以给每条记忆打一个分比如根据写入时间、被引用次数、与当前query的向量相似度做加权只把得分最高的top-k条比如3到5条格式化成卡片注入System Prompt。卡片格式要统一比如用JSON或者Markdown列表让模型一眼就能看懂。当前上下文就是本次用户的输入和State里临时的计算结果这是Prompt里优先级最高的部分一定要放在模型最容易关注到的位置通常是System Prompt的最后或者User Message的头部。在代码实现上我强烈建议你在注入之前做一次Token预算检查。用tiktoken或者LangChain的token计数工具算一下你的System Prompt Messages总共有多少Token。如果超过了模型窗口的80%就启动裁剪逻辑先裁掉通用背景知识再裁掉老旧的事实卡片保留下来的必须是精华。这样你的Agent才能在各种场景下都保持头脑清醒。记忆不是越多越好恰到好处的上下文才是Agent不胡说的保险绳。像给模型准备考前资料一样只带重点笔记别把整个图书馆都搬进去。要点七调试观测与问题定位讲完了架构、提取、更新、并发和注入咱们来说说最让人头秃的环节调试。记忆问题之所以难调是因为它是隐形的。State在节点之间流来流去Store在暗地里读写出了问题你很难一眼看出来是记忆丢了、脏了还是根本没读到。新手面对记忆bug时最常见的做法就是在每个节点里疯狂加print(state)和print(store.get(...))。这种方法在节点少的时候还行一旦图复杂起来你的日志里全是巨长的字典关键信息淹没在汪洋大海里。更惨的是生产环境往往不能随意打日志或者日志采集有延迟你改了代码上线发现问题还在循环往复效率极低。还有一个误区是只盯着代码逻辑不检查数据本身。曾经有个兄弟Agent总是记不住用户的VIP等级。他查了三天的业务代码最后发现是Store里的key拼写错了写入的时候用的是vip_level读取的时候用的是vipLevel。一个大小写问题三天时间没了。这种case在强类型的数据库里可能编译期就报错了但Store的key是字符串写错了也不会有任何提示堪称静默杀手。那怎么建立一套有效的记忆观测体系呢我给你列一个实战checklist。第一给记忆流动加 trace。不要print整个state而是print你关心的关键字段的变化。比如在一个记忆管理节点的前后打印state[pending_memories]的长度以及store.get(namespace, key)的摘要。更好的做法是接入LangSmith或者类似的Tracing工具把每次Store的读写都包装成一个Span带上namespace、key、value的摘要注意脱敏别把隐私数据直接上传。这样你在Trace视图里一眼就能看到记忆是在哪个节点被读到的在哪个节点被改写的。第二建立Checkpoint inspector。在开发和测试环境写一个小的调试脚本输入thread_id就能打印出该线程所有的Checkpoint历史。看看State在每个步骤后长什么样有没有某个节点把关键字段给覆盖了或者清空了。LangGraph的Checkpoint Saver通常都支持遍历历史这件事并不难但很多人懒得做结果出了问题只能猜。第三本地用MemorySaver做单元测试。在上生产存储比如Postgres、Redis之前先用内存版的Saver和Store跑通你的记忆逻辑。写几个测试case测试同一线程的上下文恢复、测试跨线程的长期记忆读写、测试并发写入的边界情况。内存环境启动快、重置也快能快速验证你的记忆流转是否符合预期。等逻辑稳了再切到持久化存储这时候出问题大概率是配置或者连接而不是业务逻辑。第四做好Namespace和Key的审计。在项目里维护一份记忆资产清单写明每个Namespace是干什么的每个Key的命名规范是什么。写入和读取的时候不要手写字符串用常量或者配置对象来管理。这样即使拼写错了也是在定义处错一次不会散落在几十个节点里。第五利用LangGraph的打断点功能。你可以在图的特定节点后设置中断interrupt然后手动检查State和Store的内容再继续执行。这种交互式调试对于理解记忆在哪个环节变形特别有用。调试记忆要像侦探查案每个读写节点都要留痕别靠猜。当你能从Trace里清晰地看到一条记忆从用户嘴里到State手里再到Store库里的完整链路时你就已经赢了九成。写在最后咱们今天从LangGraph记忆模板的分层架构出发一路穿过了Checkpoint的短期记忆提取、Store的长期记忆查询、更新时机的事务边界、并发冲突的应对策略再到上下文的协同注入和实战调试技巧。这一路走下来你会发现记忆管理本身并不神秘它考验的其实是工程上的细致和规范。很多新手总觉得Agent智能不智能全看模型厉不厉害。但在我看来一个连用户上周说过的话都记不住的Agent哪怕底层接的是再强的模型用户体验也是零分。记忆是Agent的人格基础是你和用户之间信任关系的载体。把记忆的提取和更新做扎实了你的Agent才能真正从聊天机器人进化为靠谱的数字助手。编程这条路从来都不好走尤其是当框架越来越复杂、概念越来越多的时候很容易让人产生我怎么什么都学不会的挫败感。但请你相信每一个被记忆bug折磨过的深夜每一次把并发问题搞明白的顿悟都会变成你技术栈里实实在在的厚度。保持好奇保持耐心把每一个为什么忘了都追到底你也能成为那个让Agent拥有最强大脑的开发者。路还长灯还亮下一篇文章咱们接着聊。关注私信备注“资料代找获取”全网计算机学习资料代找例如:《课程AI 大模型工程师系统课程 (22 章完整版 持续更新)》《课程AI 大模型系统实战课第四期 (2026 年开课 持续更新)》《课程2026 年 AGI 大模型系统课 23 期》《课程2026 年 AGI 大模型系统课 21 期》《课程AI 大模型实战课 8 期 (2026 年 2 月最新完结版)》《课程AI 大模型系统实战课三期》《课程AI 大模型系统课程 (2026 年 2 月开课 持续更新)》《课程AI 大模型全阶课程 (2025 年 12 月开课 2026 年 6 月结课)》《课程AI 大模型工程师全阶课程 (2025 年 10 月开课 2026 年 4 月结课)》《课程2026 年最新大模型 Agent 开发系统课 (持续更新)》《课程LLM 多模态视觉大模型系统课》《课程大模型 AI 应用开发企业级项目实战课 (2026 年 1 月开课)》《课程大模型智能体线上速成班 V2.0》《课程JavaAI 大模型智能应用开发全阶课》《课程PythonAI 大模型实战视频教程》《书籍软件工程 3.0: 大模型驱动的研发新范式.pdf》《课程人工智能大模型系统课 (2026 年 1 月底完结版)》《课程AI 大模型零基础到商业实战全栈课第五期》《课程Vue3.5Electron 大模型跨平台 AI 桌面聊天应用实战 (2025)》《课程AI 大模型实战训练营 从入门到实战轻松上手》《课程2026 年 AI 大模型 RAG 与 Agent 智能体项目实战开发课》《课程大模型训练营配套补充资料》