本文深入探讨了 AI Agent 的记忆机制强调记忆工程取舍的重要性。文章介绍了 Hermes Agent 的五层记忆架构包括内置记忆、会话记忆、程序记忆和外部记忆并详细解析了 Prompt Runtime 和 Prompt Cache 的作用。文章还讨论了内存分层模型的设计原理以及如何利用技能库和外部记忆提供商来增强 Agent 的能力。最后文章分析了当前架构的风险和不足并提出了改进建议。1.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 如何把“记忆”拆成可缓存、可检索、可审计、可扩展的几类工程组件。2.总体架构与 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, 2026 Session 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而是架构原则越稳定、越高频、越规则化的内容越应该靠前越动态、越低频、越大体量的内容越应该工具化。3.第一层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 等风险。4.第二层会话记忆与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()流程1. 调 list_sessions_rich。2. 默认排除 source tool 的工具型 session。3. 跳过当前 session lineage避免模型搜索自己已经在上下文里的内容。4. 默认跳过 child/delegation session。5. 返回 session id、title、source、started_at、last_active、message_count、preview。适合问题“我最近在做什么”“上次那个任务是哪一个 session”“帮我找最近几次会话。”Discovery传 query 做全文检索调用session_search(queryauth refactor, limit3)流程1. 默认只搜 user,assistant 角色避免 tool output 噪声。2. 调 db.search_messages(query, limit50)先扩大命中数方便后续按 lineage 去重。3. 排除当前 session lineage。4. 按 parent_session_id 解析到 lineage root同一条会话链只保留一个命中。5. 对每个命中调用 get_anchored_view返回命中消息附近 ±5 条窗口。返回 session 开头 bookend_start 前 3 条 user/assistant 消息。返回 session 结尾 bookend_end 后 3 条 user/assistant 消息。6. 返回 snippet、match_message_id、messages_before、messages_after 等定位信息。这不是“把整段历史扔给模型”而是给模型一个足够判断的三段式视图这个设计比单纯 snippet 更好搜索命中本身常常只是中间过程bookends 能让模型快速判断“当时目标是什么”和“最后结论是什么”。Scroll沿着命中继续读调用session_search( session_id20260519_..., around_message_id12345, window10 )流程1. 校验 session_id 和 around_message_id。2. window 限制在 [1, 20]。3. 拒绝滚动当前 session lineage因为当前上下文里已经有。4. 调 get_messages_around取 anchor 前 N 条。取 anchor 自身。取 anchor 后 N 条。按 message id 升序返回。5. 如果 anchor 实际在 child session 中会尝试按 lineage 自动 rebind。这让 session_search 支持渐进式检索1. 先 discovery 找到相关 session。2. 再 scroll 往前/往后看更多上下文。3. 直到 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 做到了工程可用。5.第三层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 写入不应该只绑定在压缩时机上。6.第四层Skills 作为程序记忆hermes把 skills 当做 procedural memory。MEMORY.md 适合保存事实用户喜欢回答简洁。 项目 A 测试命令是 make test。Skills 适合保存流程遇到某类需求拆解任务时先读 request再校验 I/O 边界最后写 result_file。Hermes 的 skills 机制有几个特点1. 系统 prompt 里默认不塞全部 skill 内容只塞 compact skill index。2. 如果任务匹配某个 skill模型必须用 skill_view(name) 加载完整 SKILL.md。3. Skill 可以带 references/、templates/、scripts/ 等支持文件。4. 后台 review 会在任务结束后判断是否需要更新 memory or skill。5. Curator 会维护 agent-created skills鼓励合并成 class-level umbrella skill而不是一堆一次性小 skill。所以 skills 解决的是另一个问题不是“我知道什么”而是“遇到这类任务我应该怎么做”。这对团队内部 Agent 很关键。比如代码 review 的固定口径。线上问题排查流程。需求拆解输出格式。数据库变更评审步骤。某些平台工具的正确调用方式。这些都不应该塞进普通 memory因为它们是流程知识结构比一条事实复杂。7.第五层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 负责语义和用户建模增强8.工程取舍与设计启发为什么不用一个 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 FTSprompt 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。 * 可以归档不直接硬删除。 9. **风险和不足** ------------ 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 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取