Agent 到底应该怎么“记住事情”讨论 Agent 记忆时最容易陷入一个误区以为记得越多越好。但 Hermes Agent 展示的是另一种思路记忆首先是一个工程取舍问题。一个长期运行的 AI Agent应该如何在“记住更多”和“保持上下文可控”之间取平衡好的 Agent 记忆系统不是“什么都塞进 prompt”而是把信息按热度、稳定性、结构化程度和读取成本分层。Hermes 可以看成 4 套记忆系统、5 个讲解层次。4 套系统是内置记忆、会话记忆、程序记忆和外部记忆展开讲解时session 压缩单独作为第三层来看内置热记忆MEMORY.md / USER.md小而精常驻 prompt。会话记忆state.db / session_search完整历史会话按需召回。session 压缩context compression / session lineage长会话过长后保留连续性。程序记忆Skills保存“遇到这类任务怎么做”。外部记忆Honcho 等 external provider提供深层用户建模和语义记忆。这套分层背后的主线是保持系统提示词稳定充分利用 prompt cache大体量、低频、历史性的信息通过工具按需取回。下面重点看 Hermes 如何把“记忆”拆成可缓存、可检索、可审计、可扩展的几类工程组件。总体架构与 Prompt Runtime可以把 Hermes 的 memory/runtime 看成“五层记忆 prompt runtime”这张图里最关键的分界是MEMORY.md / USER.md 是 always-on但容量小。state.db 是完整历史但不自动进 prompt。compression / lineage 是长会话连续性层把当前会话压短同时保留逻辑会话关系。skills 是过程知识默认只给索引具体内容需要 skill_view 加载。external provider 是增强层不应该替代基础 memory 和 session archive。从 prompt 组装顺序看Hermes 的关键不是“把所有记忆都拼进去”而是先构造稳定前缀再把动态内容放到后面或工具返回里Prompt 构建为什么 Hermes 强调稳定前缀Hermes 的系统提示词不是每轮临时拼出来的散装字符串而是分层组装并尽量保持前缀稳定。源码里的注释明确说明系统提示词会在 session 内缓存只有 context compression 等事件才会重建。一个细节是时间也被处理成 date-onlyConversation started: Tuesday, May 19, 2026Session ID: ...Model: ...Provider: ...不放分钟级时间是为了避免每次重建 prompt 时因为时间字符串变化导致缓存失效。Prompt cache 的基本原理Prompt cache 可以粗略理解为模型服务商把一段已经处理过的 prompt 前缀缓存下来。下一次请求如果前缀 token 序列足够一致就可以复用前缀对应的计算结果而不是从头重新处理。从 Agent 视角看缓存命中通常带来两个收益更低延迟长系统提示词、工具说明、skills index 不必每轮完整重算。更低成本部分服务商会对 cache read tokens 采用更低计费或至少减少实际计算压力。它不是“语义相似就能命中”而更接近“前缀内容一致才有机会命中”。提高 prompt cache 命中的技巧Hermes 的实现可以抽象成几条通用技巧做法目的稳定内容放前面身份、工具规则、skills index 尽量保持字节级稳定动态内容工具化搜索结果、日志、历史回忆不要改写 system prompt冻结 memory 快照会话中途写盘不立即刷新当前 prompt控制时间粒度放日期不放分钟秒级动态时间确定性排序skills、tools、context files 顺序稳定大历史留在检索层历史会话进这里的关键不是某个供应商的 cache API而是架构原则越稳定、越高频、越规则化的内容越应该靠前越动态、越低频、越大体量的内容越应该工具化。第一层MEMORY.md和USER.md热记忆这一层最适合用“会话启动快照”来理解文件在磁盘上是 live 的但进入 prompt 的是 session 开始时的 frozen snapshot。存储位置和容量Hermes 的内置记忆存在~/.hermes/memories/MEMORY.md~/.hermes/memories/USER.md默认容量文件作用默认限制MEMORY.mdAgent 的环境事实、项目约定、工具经验、长期可复用事实2200 字符USER.md用户画像、沟通偏好、工作方式、明确纠正1375 字符注意这里限制的是 字符数不是 token 数。这样实现更简单也和模型无关。文件格式每条记忆用 § 分隔用户偏好回答要直接少写寒暄。§当前机器是 macOS默认 shell 是 zsh。§某项目运行测试要用 make test不要直接 pytest。启动时 Hermes 会读取文件并渲染成系统提示词块类似══════════════════════════════════════════════MEMORY (your personal notes) [67% — 1,474/2,200 chars]══════════════════════════════════════════════...两类文件分别存什么MEMORY.md 和 USER.md 都会进入系统提示词但语义不同文件存储内容作用MEMORY.mdAgent 对环境、项目、工具和流程的稳定认知让 Agent 下次回到同一工作环境时少走弯路USER.md用户画像、沟通偏好、协作方式和明确纠正让 Agent 记住应该如何和这个用户协作简单例子MEMORY.md当前工作区 ~/project 主要用于 项目规范文档和技术方案沉淀。§项目规范文档应保持表达清晰避免混入一次性上下文和临时备注。USER.md用户偏好中文输出回答要直接、结构紧凑少写背景铺垫。§用户在流程治理类任务中偏好“先判断再给最小修改方案”。这里不需要人工给每条信息做复杂分类。Hermes 的 memory 工具 schema 会提示模型用户偏好、身份和协作方式通常写入 user环境事实、项目约定、工具经验通常写入 memory。Frozen snapshot写入立即落盘但不立刻进入当前 prompt这是设计重点。Hermes 在 session 开始时读取 memory 文件生成一个 _system_prompt_snapshot。之后本轮会话中即便调用 memory(add/replace/remove) 修改了文件文件会立即写盘。tool response 会看到 live state。但当前 session 的系统 prompt 不会被改。新记忆通常要到下一次 session或系统 prompt 因 compression 被重建后才进入 prompt。这个机制牺牲了一点“马上生效”的直觉换来 prompt cache 的稳定性。memory 工具能力memory 工具有三个动作action作用add新增一条记忆replace用remove用它没有 read action。原因是 memory 本来就会在 session 开始时注入系统 prompt如果要修改工具响应会返回当前条目和容量。几个工程细节值得借鉴replace/remove 用短子串定位不需要暴露内部 ID。如果子串命中多条不同记录会要求更具体避免误删。精确重复条目不会重复添加。写文件使用 lock temp file atomic replace避免并发读到半截文件。新条目会做安全扫描拦截 prompt injection、凭证外泄、不可见 Unicode 等风险。第二层会话记忆与search-session当前源码里的核心文件是hermes_state.py数据库使用SQLite默认路径~/.hermes/state.db它负责持久化 session metadata、完整 message history以及 FTS5 检索索引。先看数据关系这张图里有两个重点messages 是事实来源FTS 表只是搜索索引。索引维护由 SQLite trigger 自动完成应用层不需要手动双写。SQLite state.db核心表结构sessionssessions 表表示一次会话或会话分支。主要字段字段含义idsession 主键source来源平台如user_id平台用户 IDmodel使用的模型model_config模型配置 JSONsystem_prompt本 session 的系统提示词快照parent_session_id父 session用于 compression、branch、delegation 形成 lineagestarted_at会话开始/结束时间end_reason结束原因如 compressionmessage_count消息数tool_call_count工具调用数input_tokenstoken 计数cache_read_tokensprompt cache 相关计数reasoning_tokensreasoning token 计数estimated_cost_usd成本估计/实际成本title人类可读标题带唯一索引handoff_*跨平台 handoff 状态这个表不只是“聊天列表”而是运行时账本它同时服务 resume、search、cost、compression lineage 和跨平台会话。messagesmessages 表保存每条消息。主要字段字段含义id自增主键session_id所属 sessionroleusercontent文本或 JSON 编码后的结构化内容tool_call_id工具调用 IDtool_callsassistant 发起的工具调用 JSONtool_nametool message 对应的工具名timestamp写入时间token_count单条消息 token 估计finish_reason模型完成原因reasoningreasoning 相关字段codex_reasoning_itemsCodex runtime 兼容字段多模态或结构化 content 不能直接绑定进 SQLite所以 Hermes 会用一个 sentinel 前缀把 list/dict JSON 化\x00json:{...}读取时再 decode 回原结构。其他表和索引还有schema_version记录 schema 版本。state_metakey-value 元数据。idx_sessions_source、idx_sessions_parent、idx_sessions_started、idx_messages_session 等普通索引。idx_sessions_title_uniquesession title 唯一索引。FTS5 表普通全文检索 CJK trigram 检索Hermes 建了两个 FTS5 virtual tableCREATE VIRTUAL TABLE IF NOT EXISTS messages_fts USING fts5(content);CREATE VIRTUAL TABLE IF NOT EXISTS messages_fts_trigram USING fts5( content, tokenizetrigram);区别messages_fts默认 FTS5 tokenizer适合英文、代码标识符、常规关键词。messages_fts_trigramtrigram tokenizer主要解决中文、日文、韩文这类 CJK 搜索的问题。FTS 表里索引的不只是 content而是拼接了message.content tool_name tool_calls这意味着可以搜到用户/助手说过的话。调过哪个工具。工具调用参数里出现过的关键词。FTS 索引通过 SQLite trigger 维护AFTER INSERT ON messages插入 FTS row。AFTER DELETE ON messages删除 FTS row。AFTER UPDATE ON messages先删旧 row再插新 row。这样应用层只需要写 messages 表索引维护由数据库触发器完成。并发和可靠性state.db 默认启用 WAL多读一写更适合 gateway 多平台并发场景。写操作用 BEGIN IMMEDIATE并带随机 jitter retry降低多个 Hermes 进程争抢写锁时的 convoy effect。如果文件系统不支持 WAL比如 NFS/SMB/FUSE降级到 journal_modeDELETE牺牲并发但保证功能可用。每隔一定写入次数做 best-effort WAL checkpoint避免 WAL 文件无限增长。这说明 state.db 不是玩具实现而是被当作多入口、多进程共享状态库来设计。session_search 到底怎么 search当前 session_search 是一个单工具三形态接口模式不是显式传 mode而是通过参数推断调用方式模式作用不传参数browse浏览最近 session传discovery全文检索历史 session传scroll围绕某条消息继续滚动读取什么时候会触发 SQLite FTS 查询这里要把 写索引 和 查索引 分开看。因此 Hermes 的 SQLite FTS 不是每轮自动运行的 RAG 组件。正常同一会话内模型直接读 active context如果早期上下文被 compression 压掉主路径也是依赖 compression summary 延续任务而不是每轮从 FTS 回捞当前 lineage。FTS 查询主要发生在模型主动调用 session_search 时典型触发是跨会话回忆我们之前讨论过 X 吗上次那个 Y 最后怎么定的帮我找一下之前处理 Z 的会话。我最近在做什么上次做到哪了所以这里的边界应该这样理解问题主要机制当前会话如何连续active context compression summary不靠什么时候查 FTS需要跨会话回忆且模型主动调用长期稳定偏好放哪MEMORY.md三种模式Browse / Discovery / ScrollBrowse无查询时列最近会话调用session_search()流程调 list_sessions_rich。默认排除 source tool 的工具型 session。跳过当前 session lineage避免模型搜索自己已经在上下文里的内容。默认跳过 child/delegation session。返回 session id、title、source、started_at、last_active、message_count、preview。适合问题“我最近在做什么”“上次那个任务是哪一个 session”“帮我找最近几次会话。”Discovery传 query 做全文检索调用session_search(queryauth refactor, limit3)流程默认只搜 user,assistant 角色避免 tool output 噪声。调 db.search_messages(query, limit50)先扩大命中数方便后续按 lineage 去重。排除当前 session lineage。按 parent_session_id 解析到 lineage root同一条会话链只保留一个命中。对每个命中调用 get_anchored_view返回命中消息附近 ±5 条窗口。返回 session 开头 bookend_start 前 3 条 user/assistant 消息。返回 session 结尾 bookend_end 后 3 条 user/assistant 消息。返回 snippet、match_message_id、messages_before、messages_after 等定位信息。这不是“把整段历史扔给模型”而是给模型一个足够判断的三段式视图这个设计比单纯 snippet 更好搜索命中本身常常只是中间过程bookends 能让模型快速判断“当时目标是什么”和“最后结论是什么”。Scroll沿着命中继续读调用session_search( session_id20260519_..., around_message_id12345, window10)流程校验 session_id 和 around_message_id。window 限制在 [1, 20]。拒绝滚动当前 session lineage因为当前上下文里已经有。调 get_messages_around取 anchor 前 N 条。取 anchor 自身。取 anchor 后 N 条。按 message id 升序返回。如果 anchor 实际在 child session 中会尝试按 lineage 自动 rebind。这让 session_search 支持渐进式检索先 discovery 找到相关 session。再 scroll 往前/往后看更多上下文。直到 messages_before 或 messages_after 小于 window说明到达边界。FTS 查询细节search_messages 支持 FTS5 查询语法普通关键词docker deployment精确短语“docker networking”布尔docker OR kubernetes、python NOT java前缀deploy*时间排序默认按 FTS rank也可 newest 或 oldest查询进入 SQLite 前会做 sanitize保留成对引号里的精确短语。清理容易导致 FTS5 syntax error 的特殊字符。去掉开头/结尾孤立的 AND/OR/NOT。将带点、横线、下划线的词加引号比如 my-app.config.ts避免被 FTS 拆成多个词。中文检索单独处理如果包含 CJK 且每个 CJK token 至少 3 个字走 messages_fts_trigram。如果是 1-2 个中文字符trigram 不适合降级为 LIKE。短中文 OR 查询会拆成多个 token各自做 LIKE。这说明 Hermes 没有把搜索问题简单丢给 vector DB而是先把 lexical search 做到了工程可用。第三层context compression 和 session lineage长对话不能无限增长。Hermes 有 context compression 机制把中间大量消息压缩成摘要保留头尾和当前任务必要状态。这一层可以单独看作压缩记忆它不负责跨会话搜索也不是长期偏好存储而是解决“同一个长会话怎么继续跑下去”的问题。一边让当前上下文变短一边用 parent-child lineage 保留原始会话的可追溯关系。在 state.db 里compression 会影响 session 结构原 session 会以 end_reason compression 结束。新 session 作为 child 继续parent_session_id 指向原 session。搜索和浏览时会通过 lineage 还原“同一个逻辑会话”。这就是为什么 session_search 要做 lineage deduperoot session └── compression child └── further child从用户视角这是一段连续会话从存储视角是多条 session row。源码里还可以看到一个实现演进旧版本中曾有 flush_memories 这类压缩前记忆冲刷机制但当前 release note 已经标记为移除。当前更重要的是compression 前 external memory provider 可以通过 on_pre_compress(messages) 接收即将被压缩的上下文。compression 后 system prompt 会失效并重建内置 memory 会重新从磁盘加载。background review 在每轮之后异步判断是否需要写 memory 或更新 skill。这比“压缩前强行让模型写 memory”更稳一些因为 memory 写入不应该只绑定在压缩时机上。第四层Skills 作为程序记忆hermes把 skills 当做 procedural memory。MEMORY.md 适合保存事实用户喜欢回答简洁。项目 A 测试命令是 make test。Skills 适合保存流程遇到某类需求拆解任务时先读 request再校验 I/O 边界最后写 result_file。Hermes 的 skills 机制有几个特点系统 prompt 里默认不塞全部 skill 内容只塞 compact skill index。如果任务匹配某个 skill模型必须用 skill_view(name) 加载完整 SKILL.md。Skill 可以带 references/、templates/、scripts/ 等支持文件。后台 review 会在任务结束后判断是否需要更新 memory 或 skill。Curator 会维护 agent-created skills鼓励合并成 class-level umbrella skill而不是一堆一次性小 skill。所以 skills 解决的是另一个问题不是“我知道什么”而是“遇到这类任务我应该怎么做”。这对团队内部 Agent 很关键。比如代码 review 的固定口径。线上问题排查流程。需求拆解输出格式。数据库变更评审步骤。某些平台工具的正确调用方式。这些都不应该塞进普通 memory因为它们是流程知识结构比一条事实复杂。第五层External memory providerHermes 的 MemoryManager 允许内置 memory 加一个 external provider。当前设计限制内置 provider 始终存在。最多注册一个非内置 external provider避免工具 schema 膨胀和多个记忆后端冲突。这一层解决的是前四层不擅长的问题语义召回、用户建模、跨会话事实抽取、知识图谱和更长周期的个性化。Provider 接入点MemoryProvider 抽象类把 external memory 拆成几类接入点接入点时机作用system_prompt_block()prompt 组装时注入静态说明、provider 状态和工具使用规则prefetch(query)每次模型调用前返回和当前问题相关的外部记忆上下文queue_prefetch(query)每轮结束后后台预取下一轮可能要用的记忆减少同步等待sync_turn(user, assistant)每轮结束后把本轮用户/助手内容异步写入外部后端get_tool_schemas()模型显式调用工具时暴露 provider 自己的搜索、推理、写入工具on_session_end(messages)会话结束时做会话级总结、事实抽取或 flushon_session_switch(…)resume / branch / reset / compression 时让 provider 更新内部 session 绑定on_pre_compress(messages)compression 前提前抽取即将被压缩掉的信息on_memory_write(…)内置 memory 写入时把这个设计有两个工程含义external provider 既可以“自动注入上下文”也可以“只暴露工具等模型需要时再查”。provider 写入通常应该异步化否则每轮对话都会被外部网络延迟拖慢。Honcho 例子三种 recall 模式以 Honcho provider 为例它不是简单的 vector search而是偏“AI-native 用户建模”。它会维护 session summary、user representation、peer card、AI self-representation 等结构化上下文。Honcho 的召回模式可以理解成三类模式行为适合场景context自动把相关用户上下文注入到模型调用前想要无感个性化但不希望模型显式操作记忆tools不自动注入只暴露想控制成本和上下文污染让模型按需查hybrid自动注入上下文同时开放工具想要默认个性化也允许复杂问题显式深查它的 prefetch 也分层基础 context 可以缓存并按 cadence 刷新更贵的 dialectic reasoning 可以作为补充层异步预热。这样做是为了避免“每一轮都同步调用外部 LLM/服务”。External provider 适合补什么它最适合补内置层的这些短板内置层短板external provider 可以补的能力FTS 主要靠关键词语义召回、同义改写、多跳关联MEMORY.md更大规模的用户画像和事实库session archive 是原始日志自动抽取事实、偏好、关系、主题演化SQLite 本地为主跨设备、跨平台、跨 workspace 的长期记忆skills 保存流程不保存用户模型建模“这个用户如何决策、偏好什么、反复关注什么”官方文档和插件里能看到 Honcho、Mem0、Hindsight、Holographic、RetainDB、ByteRover、Supermemory 等 provider 或相关集成。它们的定位不完全一样有的偏语义检索有的偏知识图谱有的偏用户画像有的偏长期上下文管理。但它仍然只是增强层external provider 不应该替代基础层MEMORY.md / USER.md 仍然是最高频、最稳定、最 prompt-cache 友好的热记忆。state.db 仍然是完整、可审计、可定位的本地会话事实来源。session_search 仍然负责找回真实消息窗口而不是让模型只相信二次摘要。skills 仍然承载“怎么做事”的流程沉淀。所以更稳的架构不是“接一个高级 memory provider 就完事”而是本地热记忆负责稳定偏好 本地 session archive 负责证据回溯 skills 负责流程复用 external provider 负责语义和用户建模增强工程取舍与设计启发为什么不用一个 vector DB 搞定所有记忆很多 Agent memory 方案会直接说“把历史都 embedding检索 top-k”。Hermes 的实现更保守常驻 memory 是小文件。会话 archive 是 SQLite。搜索先做 FTS5。中文走 trigram 或 LIKE。skills 用文件系统组织。external provider 作为增强而不是基础依赖。优点可解释能看到到底搜到了哪条 message。本地优先部署简单。容易删除和审计。不依赖 embedding 模型质量。对代码、命令、路径、错误字符串这类精确文本更友好。缺点语义召回弱。查询词质量影响很大。没有自动总结时模型需要自己阅读窗口。用户画像和长期偏好需要额外 provider 才能做深。为什么 memory 要小小 memory 不是能力不足而是刻意限制。如果常驻 memory 太大每轮请求 token 成本上升。prompt cache 命中价值下降。过期事实更难治理。模型更容易被低价值历史干扰。安全风险扩大因为 memory 会进入系统 prompt。因此 memory 应该像缓存里的 hot set而不是数据库。为什么 session_search 返回真实消息当前实现不再用 LLM 摘要有一个明显好处检索结果可审计。如果返回摘要模型和用户都要相信摘要模型没有漏掉关键信息如果返回窗口和 bookends主模型可以自己判断必要时继续 scroll。这更适合开发者工具因为开发者通常需要原始证据当时用户到底怎么说。工具到底调了什么。错误文本是什么。最后结论是不是已经验证过。为什么 skills 是 memory 的一部分只记住事实还不够。Agent 经常失败在“流程不稳定”明明上次学过某个项目怎么测下次又乱跑命令。明明用户纠正过输出格式下次又按通用格式。明明某类问题有固定排查顺序下次又凭感觉。这类经验不适合写成一句 memory而应该成为可执行、可维护、可附带脚本的 skill。对做 Agent / Copilot / 工具的启发记忆分层模型可以借鉴 Hermes 的“五层记忆 当前任务状态”模型信息类型应放位置读取方式用户偏好、稳定约定hot memory每次 prompt 自动带上历史对话、任务过程session archive按需搜索长会话连续性compression memory上下文超限时压缩、接续、重建 prompt操作流程、排查路径skills / playbooks任务匹配时加载长期用户模型、语义关系external providerprefetch / recall当前任务状态当前上下文或 artifact当前任务内使用不作为长期记忆层不要把“任务进度”误存成长期记忆很多 Agent memory 会越用越脏根因是把临时状态升格成长期事实。更好的规则memory 保存长期稳定事实。session_search 回忆过去任务进度。artifact/result file 保存当前任务交付物。skill 保存可复用流程。先做可审计检索再谈语义智能企业内部场景里很多查询其实是精确文本错误码。接口名。服务名。配置 key。表名。PRD 标题。命令行参数。这类内容 FTS5 往往比纯 embedding 更可靠。可以先做SQLite/Postgres FTS- message/window/bookends- 用户或模型确认- 必要时再接 semantic layerprompt cache 是架构约束不是优化细节一旦 Agent 运行频繁prompt cache 会影响延迟。成本。多轮体验。是否敢放长系统规则。因此系统 prompt 应该有稳定分层稳定 identity / policy / tool rules。session 级上下文。小型 memory snapshot。动态检索结果不要改 system prompt放在当前 turn 的工具返回或用户消息附加上下文里。技能库需要治理Skills 会自然膨胀。Hermes 的 curator 思路很有参考价值不鼓励“一次任务一个 skill”。更倾向 class-level umbrella skill。支持 references/templates/scripts。保护 bundled/hub/pinned skills。可以归档不直接硬删除。风险和不足Hermes 的设计很务实但不是没有问题。FTS 不是语义搜索如果用户问上次那个我们讨论过的“权限隔离问题”是什么但历史里实际写的是tenant-level access control纯关键词可能搜不到。需要更好的 query rewriting。同义词扩展。语义 provider。或者让模型先生成多个候选 query。memory 容量小治理要求高小 memory 的前提是有好的写入判断。如果模型乱写重要事实会被低价值事实挤掉。用户偏好可能过期。修正可能被写得过于绝对。一次性环境问题可能变成长期禁令。所以 memory 写入应该有强约束和可视化维护能力。session archive 有隐私和合规问题state.db 保存完整会话包括 tool calls、reasoning 相关字段、系统 prompt 快照等。这意味着必须考虑用户是否知道完整历史会被保存。如何删除某个 session。如何删除包含敏感信息的 message。是否需要加密。团队共享环境下 session 是否隔离。备份和迁移时是否会泄露。skills 自更新可能固化错误经验background review 会主动更新 skills这很强但也有风险把一次 workaround 固化成通用规则。把当前环境故障写成长期限制。生成过窄 skill污染 skill index。多个 skill 之间重复或冲突。所以需要 curator、保护规则、人工 review以及明确的“什么不能保存”。Compression 摘要有损压缩能降低上下文但摘要一定有损。Hermes 用 session lineage 保存历史并可以通过 session_search 找回原始会话这降低了风险。但如果当前任务依赖中间细节而压缩摘要漏了模型仍可能偏航。因此关键决策应写 artifact。重要长期规则应写 memory/skill。历史细节应能通过 session_search 找回。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
