本文深入探讨了Agent系统的长期记忆问题指出当前多数Agent存在“金鱼记忆”缺陷难以应用于实际场景。文章详细解析了Agent Memory的四个核心组件信息提取、记忆管理、记忆存储和信息检索并提出了记忆分类和选型建议。作者建议采用文件记忆显式规则结构化item混合检索定期压缩的方案并针对不同场景如个人助理、Coding Agent、Research Agent等提供了具体的选型指导。最后文章还分享了作者在实战中的选型和避坑经验为开发者构建高效Agent Memory系统提供了实用参考。先说结论Agent Memory 不是把历史对话塞进向量库。它是一套上下文管理机制什么信息值得留下、怎么组织、什么时候取出来、取出来后怎么影响 Agent 的推理和行动。核心不是存更多历史而是让 Agent 在正确时刻拿到正确的过去信息并且不被错误、过期、冗余的记忆拖累。如果你现在要做 Agent Memory我的建议是文件记忆 显式规则 结构化 item 混合检索 定期压缩。大多数场景做到这里够用。Memory 值不值得单独做成一个系统坦率讲有争议。Memory 的形态完全取决于 Agent 怎么用。客服 Agent、Coding Agent、Research Agent、个人助理需要记住的东西完全不一样。底层 LLM 越强对粗糙记忆和长上下文噪声的容忍度也越高。但从架构选型角度看把不同方案拉到统一框架下比较仍然有价值。只有拆成组件才知道不同系统到底在比什么。Memory 不是 RAG先区分三个东西。上下文是模型当前能看到的信息。RAG 是从外部知识库里找相关材料。Memory 是 Agent 从过去交互、任务和用户反馈中沉淀出来的可复用经验。举个例子。用户问“上次我们为什么不用 Supabase RLS 那个方案”RAG 会去项目文档里搜Supabase RLS可能搜到一堆技术文档。Memory 应该直接知道之前讨论过这个方案当时因为权限策略过复杂、测试成本高所以暂时放弃了。RAG 解决知识在哪里。Memory 解决过去发生了什么、现在应该怎么接着来。Agent Memory 其实就是对 context 的精细管理。记忆不是孤立的东西它要跟具体业务问题走。很多方法做着做着就扩展成 RAG 平台或 Agent 框架的一部分已经偏离了 Memory 本身。四组件框架所有方案都逃不开这四件事不管是 A-MEM、MemGPT、Mem0、Zep还是 ChatGPT Memory、Claude Memory Tool、Hermes拆开看都在做四件事1. 信息提取从交互中判断什么值得记2. 记忆管理对已有记忆做合并、更新、关联、遗忘3. 记忆存储决定用什么结构保存4. 信息检索在需要时把相关记忆找回来写入路径和读取路径是两条不同的流。写入交互日志 → 提取 → 更新/合并/遗忘 → 存储读取当前任务 → 查询重写/意图检测 → 检索 → 重排/过滤 → 注入上下文 → Agent 响应很多系统的问题出在哪呢只做了存储和检索没有认真做提取和管理。结果记忆越积越多越来越像一个塞满垃圾的向量库。我自己第一版就犯了这个错。记忆应该分六类不要把所有历史都叫 Memory。实际工程里至少得分清楚六种东西。短期记忆服务当前任务。“现在正在修支付回调 bug。”刚跑测试失败错误是 TypeError。只在当前 session 内有效。情节记忆记录发生过什么。“2026-05-12 讨论过迁移 Supabase因为 RLS 复杂度暂缓。”上次部署失败是因为环境变量没同步到 preview environment。带时间、事件和决策。语义记忆记录稳定事实。“项目用 Next.js Prisma PostgreSQL。”“主分支叫 main部署走 GitHub Actions。”用户画像记录偏好。“用户偏好中文回答。”写笔记喜欢先给判断再展开。ChatGPT 把 Memory 分成 saved memories 和 chat history 两种用户可在设置中管理。技能记忆记录怎么做事。“处理 Vercel 部署问题时先看 build logs再看环境变量再看 Node 版本。”规则记忆比偏好更硬。“不要自动提交代码。”不要删除迁移文件。AGENTS.md、CLAUDE.md、.cursor/rules 都属于这类。这里有个我觉得很多人忽略的区分Rules 是确定性的、必须遵守。Memories 是概率性的、需要判断是否适用。 Cursor 和 Windsurf 都把这两者分开了不是没有原因的。信息提取三种路线信息提取是 Memory 系统的入口。问题很直接从原始对话、工具结果、用户行为里哪些东西值得进入记忆系统直接归档最简单保存原始消息加时间戳。优点是信息完整缺点是噪声大、存储膨胀、检索成本高。MemoryBank 和 MemGPT 偏这一类。摘要式提取用 LLM 从一轮或多轮对话中提取摘要、关键词、标签。A-MEM 会为新记忆生成包含上下文描述、关键词和标签的综合笔记并通过动态链接构建知识网络。Mem0 也是从持续对话中动态提取显著信息。摘要式提取适合大多数工程场景在完整性和成本之间比较平衡。图式提取用 LLM 抽取实体、关系、时间构建知识图谱。Zep/Graphiti 就是典型代表动态综合非结构化对话和结构化业务数据同时保留历史关系。适合企业关系数据、CRM、多跳推理。但图式提取有天然问题三元组化会损失语义。一句话里的语气、犹豫、上下文暗示很难变成主语-谓语-宾语。图谱不是越早上越好除非你真的需要关系推理。记忆管理五类操作信息进入系统后不应该只是被保存。管理操作可以拆成五类。关联在相关记忆之间建立连接。“用户喜欢简洁回答”“用户写技术笔记”“用户讨厌营销腔”这三条单独看是散的一起看能更好指导写作风格。A-MEM 通过动态链接建立记忆网络Zep 通过实体图谱建立关联。整合把碎片化记忆合并成更稳定的摘要。多次对话里用户都说不喜欢太油腻的表达系统可以整合成一条用户偏好自然、克制、判断明确的中文表达。这类记忆比多条散落原文更好用。跨层转换把短期记忆迁移成长期记忆。MemoryOS 采用短/中/长三层架构短期到中期按 FIFO 迁移中期到长期结合访问频率和最近性评分。关键是不是所有东西都应该一步进入长期记忆。更新有三种范式更新方式做法优点缺点规则驱动按时间衰减、访问频率更新可控、便宜僵硬LLM 驱动用模型判断合并、改写、冲突灵活成本高、不稳定Agent 驱动Agent 自己调用工具决定写/改/删自主性强最难调试MemoryBank 的艾宾浩斯遗忘曲线属于规则驱动。MemTree 用 LLM 做聚合更新。MemGPT/Letta 偏 Agent 自主工具调用。过滤就是删除或降权无效记忆过期信息、重复信息、低价值信息、错误信息、当前 scope 不适用的信息。如果没有过滤机制Memory 系统会越用越脏。记忆存储五种结构扁平向量存储最常见。把 memory item 做 embedding放进 FAISS / Qdrant / Milvus / pgvector按语义相似度检索。简单成熟但关系推理弱、时间推理弱、精确匹配弱。混合存储在生产里更常见。数据库存正文和元数据事实源向量索引做语义召回全文索引做 BM25/FTS图索引做实体关系。不要让向量库成为唯一事实源否则更新、删除、审计会很麻烦。图存储适合实体关系和时间变化。Zep/Graphiti 就是典型因为企业知识经常动态变化客户状态、交易进展、组织关系、历史决策。传统 RAG 适合静态文档企业 Agent 需要持续整合对话和业务数据。树存储是 MemTree 的思路。叶子节点保存细节上层节点保存抽象摘要。既保留原始信息又能在高层做概念召回。但维护成本高对话越长插入时需要更新路径上的摘要。分层存储是 MemGPT、MemoryOS、MemOS 的方向。Active Context → Short-term → Mid-term → Long-term → Archive。来自操作系统的思路上下文窗口像内存贵、小外部存储像磁盘大、便宜需要调度。文件存储是工业界最常用的。MEMORY.md、USER.md、rules 文件。简单、可读、可版本控制。信息检索混合检索 排序公式检索阶段四种范式检索方式机制适合场景问题词汇检索BM25、FTSID、文件名、错误码语义泛化弱向量检索embedding ANN语义相似问题精确性不稳定结构检索图遍历、多跳关系推理、时间链路图维护贵LLM 辅助query rewrite、rerank模糊问题、复杂意图token 成本高生产系统里通常是混合流程当前任务 → 意图识别/Query Rewrite → BM25 召回 向量召回 图谱扩展 → 候选合并 → Rerank → 过滤过期/冲突/低置信 → 注入 Prompt我自己用的排序公式final_score 0.35 * semantic_similarity 0.20 * lexical_match 0.15 * recency 0.15 * importance 0.10 * scope_match 0.05 * confidence这个公式不是固定的。 Coding Agent 要提高 lexical_match 权重函数名、错误码很重要。个人助理提高 recency 权重。企业系统提高 graph relevance 和 temporal validity 权重。10 种学术方案组件矩阵一张表看完所有学术方案的定位差异方案信息提取记忆管理存储结构检索方式适合场景A-MEM摘要标签上下文描述动态关联链接网络向量链接多跳知识网络MemoryBank原始归档遗忘曲线扁平池向量/时间权重简单长期陪伴MemGPT原始Agent工具Agent自主管理Core/Recall/Archival工具调用向量长任务长对话Mem0LLM摘要式ADD/UPDATE/DELETE扁平向量元数据向量混合召回个性化AgentMem0g实体关系提取实体合并知识图子图检索关系推理MemoChat主题摘要主题级整合主题-记录分层LLM辅助长程对话Zep/GraphitiSPO时间社区聚类时间知识图谱图遍历向量企业动态知识MemTree递归摘要LLM聚合更新动态树自顶向下遍历层级长记忆MemoryOS分段摘要FIFO热度迁移短/中/长三层向量画像长期个人记忆MemOS多形态记忆OS级管理分层多模态混合检索通用Agent平台这张表的核心信息多数方案不是在有没有 Memory上差异而是在记忆的组织方式和更新机制上差异。工业界怎么做五个实践学术方案喜欢做加法。工业界反而在做减法。ChatGPT产品化个人记忆ChatGPT Memory 重点不是做开发者可编程的记忆数据库而是产品级个性化。官方文档里Memory 有两个设置Reference saved memories用户明确让 ChatGPT 记住的信息和 Reference chat history参考过去聊天改善未来回答。重点是用户可控、个性化、跨会话体验、偏好和稳定事实、可以关闭/管理/删除。它走的路线偏把相关 memory 拼进 context让模型自己消化不是复杂 RAG 检索。Claude Memory Tool把存储交给开发者Claude API 的 Memory Tool 很有工程启发。官方文档说Claude 可以通过/memories目录在会话之间存储和取回信息。启用后Claude 会在开始任务前检查记忆目录可以创建、读取、更新、删除该目录下的文件。这个工具是 client-side 的Claude 发起工具调用应用程序在本地执行。所以开发者控制记忆存在哪里、怎么存。很 Unix philosophy不给黑盒 memory service给清晰的文件工具接口。你自己决定后端是本地文件、数据库、加密存储还是企业权限系统。我觉得这个设计思路很对。核心价值是 just-in-time context retrieval不预先加载所有信息而是把学到的东西存在 memory 里需要时再取回来。对长期运行 Agent 很重要跨 session 项目上下文、从历史决策中学习、构建长期知识库、重复工作流的持续改进。LettaMemGPT 延续分层记忆 Sleep-time ComputeMemGPT 的核心来自操作系统有限上下文窗口相当于 RAM外部存储相当于 diskAgent 需要学会把信息换入换出。Letta 进一步提出 memory blocks把上下文窗口拆成有标签的区块persona、human、task state可被 API 读取、更新、删除可在多个 Agent 之间共享。另一个重要概念是 Sleep-time Compute。官方博客解释sleep-time compute 是让 Agent 在空闲时间处理信息、形成新连接、重写 memory state而不是只在对话时处理。这点工程价值很大在线对话时 Agent 要快记忆整理时 Agent 要认真。这两个目标冲突Sleep-time 把它们解耦了。适合个人助理、长期项目 Agent、代码库反思、多 Agent 共享知识、需要持续改进的工作流。Hermes文件记忆 插件记忆Hermes 的设计很克制。内置 persistent memory 核心是 MEMORY.md 和 USER.md。如果需要更深的持久记忆可以启用外部 memory provider 插件Honcho、Mem0、Hindsight 等。外部 provider 是 additive不替代内置 memory。这是一个很好的二层架构第一层内置文件记忆简单、稳定、可读第二层外部 provider语义搜索、知识图谱、自动事实提取。几个现实的设计决策MEMORY.md 和 USER.md 有容量边界满了后 Agent 会整合条目session 中写入磁盘的 memory 不会立刻出现在系统提示词里要等下次 session 启动才快照进去prompt cache 很重要不能每轮都打破缓存外部 provider 是增强不是基础依赖Cursor/WindsurfRules Memories 分层Coding Agent 的 Memory 和通用聊天 Agent 不一样。它面对的是代码库、文件、终端、错误、项目规范。很多记忆其实是规则和约定。Cursor 把 Rules 定位为 persistent instructions包括 Project、Team、User Rules 和 AGENTS.md。Windsurf 的 Cascade 则明确有 Memories 和 Rules 两套机制Memories 用于跨对话共享和持久化上下文可由 Cascade 自动生成Rules 是用户手动定义的全局、工作区或系统级规则。在 Coding Agent 里rules 通常比 memories 更重要。 项目规范、代码风格、禁止操作、测试命令最好显式写下来不要让 Agent 从对话中猜。写入协议什么时候该记我自己给 Agent 设了一个明确的 Memory Write Protocol只有在以下情况写入长期记忆1. 用户明确要求记住2. 信息会在未来多次影响任务表现3. 信息是稳定偏好、项目事实、长期限制、重要决策或可复用流程4. 信息有明确来源不是临时情绪、一次性草稿或不确定猜测写入前必须判断是否已经存在相似记忆是否和旧记忆冲突是否只属于当前项目scope是否应该设置过期时间是否需要用户确认是否涉及敏感信息不要写入API key、密码、token 等敏感信息一次性任务细节未确认的猜测大段原文很快变化的信息除非带上时间戳和有效期这个协议比自动记住一切安全得多。检索协议什么时候该查记忆在以下情况先检索记忆1. 用户提到之前“上次”“我们当时”“继续”2. 当前任务涉及长期项目、个人偏好、历史决策3. 需要恢复未完成任务4. 需要避免重复踩坑5. 当前问题和某个已知项目、客户、代码库相关6. 回答会受到用户偏好或项目规则影响检索后只注入最相关的 3-8 条优先使用同一 scope 的记忆新记忆优先于旧记忆高置信记忆优先于低置信记忆如果存在冲突明确标出冲突不要擅自合并不同场景怎么选型个人助理推荐Saved memory User profile 少量可检索历史 用户可见可删。不推荐一上来做图谱。重点是边界和控制权。Coding Agent推荐Rules Memory 分层、AGENTS.md / CLAUDE.md / .cursor/rules、代码库索引、会话日志检索、技能记忆、错误和决策记录。不推荐把所有代码历史都当成 memory。重点是项目规则、代码事实、可复用流程。Research Agent推荐RAG citation store、Research log、Hypothesis memory、Decision memory、Source credibility metadata、长期主题摘要。可以考虑图谱但要保留原始来源。重点是证据链不是用户画像。企业 Agent推荐Temporal knowledge graph、CRM/ticket/document integration、Entity resolution、Access control、Audit log、Memory expiration。Zep/Graphiti 这类时间知识图谱适合企业动态知识处理结构化业务数据和非结构化对话保留历史关系。重点是权限、时间、实体关系和审计。长期陪伴/角色 Agent推荐短/中/长期分层、情节记忆、用户偏好、主题摘要、遗忘曲线、情绪和关系事件时间线。但要非常注意心理安全和隐私边界。七个常见坑坑一把 Memory 做成无限上下文。 更多历史不等于更好。过多无关信息会让模型被噪声干扰推理质量反而下降。我试过把最近 50 轮对话全塞进去效果反而变差。坑二只用向量库。 向量检索对语义相似有效但对精确匹配不稳定。代码里的函数名、错误码、文件路径、版本号都需要 BM25/FTS 精确匹配。我现在是混合检索向量负责语义BM25 负责精确。坑三没有 scope。 全局偏好、项目事实、临时状态混在一起会造成记忆污染。用户在 A 项目里说不用 Tailwind不代表所有项目都不用 Tailwind。记忆必须带 scope。坑四没有过期机制。 旧记忆如果不降权会污染新任务。应该引入 expires_at、last_accessed_at、valid_from/valid_to、statusactive/superseded/archived。坑五自动提取太激进。 LLM 很容易把一次性表达提炼成长期偏好。用户说这次写短一点不代表以后永远要短。坑六图谱过早上场。 图谱适合关系推理但也会带来实体消歧、关系抽取、时间维护、冲突合并等一堆问题。没有明确图推理需求就先别上。坑七不可见不可删。 用户不知道 Agent 记了什么就很难信任它。产品级 Memory 必须可查看、可编辑、可删除、可关闭。我的实战选型三层架构研究完这些方案我给自己的 Agent 选了三层Layer 1显式规则优先级最高稳定、短小、明确。比如默认用中文回答、不要营销腔、先给判断再展开原因、代码修改前先说明风险。这些是硬约束不需要 Agent 去回忆直接写在 rules 里。Layer 2稳定文件记忆类似 Claude Memory Tool 和 Hermes 的做法用 markdown 文件保存稳定事实/memories USER.md PROJECT.md MEMORY.md DECISIONS.md SKILLS.md好处可读、可改、可审计、可版本控制。出了问题打开文件就能看到 Agent 到底记住了什么。Layer 3可检索历史记忆把对话和决策变成结构化 item。推荐 schema{ id: mem_123, type: preference | fact | decision | task_state | skill | warning, scope: global | project | session, content: 用户偏好技术笔记先给判断再展开原因。, source: { conversation_id: conv_456, timestamp: 2026-05-15T15:30:0009:00 }, importance: 0.82, confidence: 0.91, expires_at: null, status: active, conflicts_with: [] }检索时结合 BM25 向量相似度 时间新鲜度 scope 匹配 重要度 置信度。不要一上来就做 GraphRAG 或 MemoryOS。 只有当你真的遇到跨 session 多跳推理、实体关系持续变化、企业级权限审计这些问题时再考虑图谱和分层 OS。从 MVP 到高级版的路线图阶段 1文件记忆。 几个 markdown 文件USER.md 和 PROJECT.md。最简单也最值得先做。你会发现光是这一步Agent 的跨会话体验就好很多了。阶段 2结构化记忆。 把记忆拆成 item带类型、scope、来源、重要度。这样能按条管理能过期能删除。阶段 3混合检索。 BM25 Vector Rerank。到这一步大多数场景已经够用了。阶段 4分层记忆。 短期任务状态、中期项目摘要、长期稳定事实分开。阶段 5图谱/时间线。 只有关系和时间变化很重要时再上。阶段 6Sleep-time 整理。 参考 Letta 的思路把记忆整理放到空闲期不阻塞当前对话。我目前在阶段 3暂时没有往图谱走的需求。大多数人做到阶段 2-3 就够用了。几条跨方案经验分层/树状结构通常更强。 扁平向量库只能找相似条目树和分层结构可以同时保留概念和细节。对多跳推理尤其重要。信息完整性比结构化抽象更重要。图谱看起来更高级但结构化提取容易丢信息。原始对话里的语气、上下文、否定、条件、时间范围经常无法完整进入三元组。摘要式 原文可追溯比纯图谱更稳。关联机制是多跳推理的命门。如果每条记忆都是孤立的系统很难回答这件事和上次那个决策有什么关系。A-MEM 的动态链接、Zep 的图谱、Mem0 的相似记忆更新都在增强关联能力。时间推理不能只靠存储结构。需要时间戳、有效期、版本、事件链、最近性权重、冲突处理。用户以前喜欢 A 现在不喜欢了客户上个月是 active 现在 churn risk这类问题不能只靠向量检索。还有一个容易忽略的索引维护成本很容易被低估。 图越大去重越难树越深插入越贵记忆越多冲突越多自动更新越多调试越难。论文里看不到这些成本但生产里直接体现在延迟、账单和线上 bug 上。最后说一句Agent Memory 这东西很容易被讲得很玄。什么让 AI 像人一样积累经验什么记忆操作系统。但做工程的人知道先做最简单的版本遇到真实问题再加复杂度。这个原则在 Memory 这件事上尤其适用。Memory 的价值是让 Agent 少忘关键事、少重复犯错、少被错误历史误导。 一个好的记忆系统应该让 Agent 更稳定而不是更神秘。如果你也在做 Agent Memory 相关的事情欢迎来聊。我会持续分享实战过程中的真实经验包括踩的坑。毕竟这东西目前还没有标准答案大家都在摸索。附录参考文献全解析这篇文章涉及的 14 个项目/论文完整列表分为学术研究和工业落地两部分。学术研究项目#项目核心技术链接1A-MEM高效长时记忆检索解决 KV Cache 内存浪费论文[1] · GitHub[2]2MemoryBank「记忆库」分层存储结构化记忆的奠基工作论文[3] · GitHub[4]3MemGPT操作系统内存分页思想引入大模型虚拟内存机制突破上下文窗口论文[5] · Letta[6]4Mem0动态记忆管理、选择性遗忘、个性化记忆工业级开源标杆论文[7] · GitHub[8]5MemoChat长对话信息留存与关键信息提取解决多轮对话上下文衰减论文[9] · GitHub[10]6Zep / Graphiti图结构记忆对话/文档转知识图谱精准语义检索论文[11] · GitHub[12]7MemTree树状层级记忆架构分层索引实现超长文本高效召回论文[13]8MemoryOS通用记忆管理底层系统跨场景记忆复用论文[14] · GitHub[15]9MemOS长时程记忆高效调度与压缩论文[16] · GitHub[17]工业界落地产品#产品落地场景文档10Claude Code Memory超长代码库、多轮编程对话的上下文记忆文档[18]11Letta Sleep-time Agents模拟睡眠记忆巩固后台压缩/整理/遗忘文档[19]12Hermes Memory长时程 Agent 个性化记忆与历史对话留存文档[20]13Windsurf Cascade MemoriesIDE 场景跨文件、跨会话长时程代码记忆文档[21]14Cursor Rules轻量级规则记忆长期一致的代码生成风格文档[22]如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线互联网企业工作十余年里指导过不少同行后辈。帮助很多人得到了学习和成长。我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限很多互联网行业朋友无法获得正确的资料得到学习提升故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】为什么要学习大模型我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年人才缺口已超百万凸显培养不足。随着AI技术飞速发展预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。大模型入门到实战全套学习大礼包1、大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通2、大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。3、AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。4、大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。5、大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。适用人群第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…学习是一个过程只要学习就会有挑战。天道酬勤你越努力就会成为越优秀的自己。如果你能在15天内完成所有的任务那你堪称天才。然而如果你能完成 60-70% 的内容你就已经开始具备成为一名大模型 AI 的正确特征了。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】