OpenClaw与Hermes：源码里的 AI Agent 架构知识大复盘

OpenClaw与Hermes：源码里的 AI Agent 架构知识大复盘 OpenClaw与Hermes：源码里的 AI Agent 架构知识大复盘 Modified May 31 OpenClaw 的 Dreaming（Light → REM → Deep 三阶段自动整理）和 Hermes 的 Session Search（FTS5 全文搜索 + LLM 现场摘要）代表了两种互补的记忆策略。前者让 Agent "越用越聪明"（自动沉淀重要信息），后者让 Agent "什么都能想起来"（全量历史可搜索）。对于任何长期运行的 AI Agent，记忆的"写入 整理 检索 淘汰"全链路都需要显式设计，不能靠 context window 硬撑。 Dreaming 的进一步延伸——结合记忆工程新范式 ： 2026 年 Mem0 将 Agent 记忆显式定义为三类： 情景记忆 （发生了什么）、 语义记忆 （知道什么）、 程序性记忆 （如何做事）。Dreaming 三阶段恰好覆盖了这条转化链路——Light 摄入情景（近期对话和召回记录），REM 提取跨日反复主题形成"潜在真理"（抽象思考），Deep 将通过评分门控的真理固化为长期知识写入 MEMORY.md（注入每轮 prompt）。如果 Deep 晋升时给内容打上类型标签（fact/preference/procedure），就能区分"用户住北京"（语义）和"用户习惯先列大纲再写正文"（程序性）——后者本质上就是 用户级 Skill 的自动沉淀 。 更关键的是 千人千面潜力 ：Dreaming 的 6 信号评分完全由用户交互行为驱动（频率/相关性/多样性），只要加一层 user id 维度隔离，同一套算法 + 不同用户的行为模式 = 每个用户各自的长期记忆。用户 A 频繁讨论编程 → Dreaming 晋升编程偏好；用户 B 频繁讨论烹饪 → Dreaming 晋升烹饪知识—— 算法不变，数据区分，千人千面自然涌现 。 三个演进方向 ： • 与 Session 轮换联动 ：当 session 使用率达 60% 时触发一次 Light sweep，将当前高价值内容提取为候选（不写 MEMORY.md），Handoff 时作为新 session 的暖启动缓存——既保持 Dreaming "不轻易固化"的审慎，又解决 session 切换的记忆断裂 • REM 输出关系图 ：当前 buildRemReflections 提取的是扁平 concept tags；如果升级为实体关系三元组（ 用户 [用] Python [做] 数据管道 ），Deep 阶段就能晋升结构化知识而非孤立事实，支持多跳推理 • 增加遗忘机制 ：MEMORY.md 中长期未被召回的条目可能已过时（"用户住北京"但已搬家）；定期标记为"待验证"，下次对话主动确认——模拟人脑遗忘曲线，防止"自信但错误"的旧记忆污染决策 22.3 Context Engineering——从"上下文管理"到"上下文工程" 2026 年业界已将 Agent 的上下文管理提升为独立工程学科（Context Engineering）。核心认知： 上下文窗口不是"能装多少"的问题，而是"装什么、何时装、何时清"的系统设计问题 。OpenClaw 的 Session（JSONL append only）和 Hermes 的 Session（SQLite FTS5）都能"存"和"搜"，但在 主动管理 session 生命周期 和 跨 session 动态召回 方面，相比业界前沿还有差距。 上下文焦虑症——长周期任务失败的首要原因 Anthropic 在 Harness Engineering 实践中发现，长周期任务失败的首要原因不是模型能力不足，而是 上下文焦虑症（Context Anxiety） 。当模型在单次会话中连续运行数小时，处理包含大量代码、设计和状态信息的上下文时，会逐渐接近其注意力窗口的容量极限，产生三种典型症状： • 信息丢失 ：早期对话中的关键设计决策和约束条件被逐渐遗忘或边缘化 • 注意力崩溃 ：模型在处理新信息时无法有效关联先前的上下文，导致设计一致性丧失 • 提前收工倾向 ：当模型感知到上下文窗口接近极限时，会下意识地试图提前结束任务，即使工作远未完成 这与 Chroma Research 的发现互为印证——不是同一个问题的两种描述，而是同一个根因的 微观和宏观视角 。Chroma 从 Transformer 注意力机制出发，证明 Context Rot 是架构级属性（上下文每增长 10 倍，每个 token 获得的注意力权重减少 10 倍）；Anthropic 从工程实践出发，发现 Agent 在约 35 分钟 / 80K 150K tokens 时开始出现"焦虑"行为——本质都是 上下文长度超过有效注意力范围后，模型的推理质量不可避免地退化 。 对照分析 ：OpenClaw 的三级 Compaction（§6.5）和 Bootstrap Budget（§6.8）在做类似的事——L1 pre request 主动压缩、L2 timeout triggered 紧急压缩、L3 overflow 降级——但触发时机偏保守（接近上限才压缩），且压缩后仍在同一 session 内继续，没有"彻底重启"的选项。 上下文重置（Context Reset）vs 上下文压缩（Context Compaction） 针对上下文焦虑症，Anthropic 提出了比传统压缩更激进的解法—— 上下文重置（Context Reset） ： 类比 ：不是所有内存泄漏都能靠"清理缓存"解决，有时候得重启进程。在长周期任务中，当一个 Agent 完成一个冲刺后，系统会启动一个新的 Agent，只传递必要的状态信息——代码仓库的当前状态、已完成的任务清单、下一步的计划——从而彻底解决上下文窗口溢出问题。 两个框架的现状 ： • OpenClaw ：Compaction 是主要手段，Context Engine 的 compact() 接口支持可插拔的压缩策略，但没有内置的 session 级 reset 机制 • Hermes ：四步压缩（工具裁剪→边界→摘要→组装）+ 首轮冻结快照（隐式的 reset——新会话不继承旧会话的完整历史） 结合两者的演进方向 ：把 Reset 作为 Compaction 失败后的 兜底策略 纳入 Context Engine 契约——当压缩后的 context 仍超过有效注意力范围（而非 token 上限），触发 reset：写入结构化 Handoff 文件 → 关闭当前 session → 启动新 Agent 实例 → 读取 Handoff 文件暖启动。OpenClaw 的 Context Engine assemble() 接口已经为此留好了扩展点。 业界前沿实践 Context Rot（上下文腐烂） ： Chroma Research（2025.07，Kelly Hong et al.）对 18 个前沿模型（含 GPT 4.1, Claude Opus 4, Gemini 2.5 Pro）的实证研究：Context Rot 是 Transformer 注意力机制的 架构级属性 ，非训练可解决。1M 窗口的模型在 50K 时仍出现退化；Agent 在约 35 分钟 / 80K 150K tokens 时形成"噪声→错误→修复→更多噪声"的自我强化退化循环。结论：更大窗口不能解决问题， 预防性上下文隔离 （将噪声挡在推理上下文之外）是根本解法。 两阶段 Session 轮换 ：前沿做法是 60 70% 使用率触发记忆同步（将重要状态写入外部存储），80% 触发优雅 Handoff 切换到新 session。两阶段之间的间隙给同步留出完成时间——同时触发会造成竞态。OpenClaw 和 Hermes 目前都是"等 overflow 才压缩"，没有预防性的两阶段轮换。这正是 Anthropic "上下文重置"思想的工程化落地—— 不等焦虑症状出现就主动换新 session 。 结构化 Handoff （Anthropic 的 claude progress.txt 模式）：session 切换时不是简单"摘要前文"，而是写入 5 层结构——状态快照/叙事上下文/决策日志/优先队列/警告与陷阱。新 session warm start 时读取这个文件，立刻知道"上次做到哪、下一步该干什么"。这就是 Context Reset 的具体实现形态——OpenClaw 的 Dreaming 有类似的"整理"能力，但没有和 session 切换联动。 Agentic RAG 的工程落地 ：§21.8 已列出业界的 4 种主流模式（Self RAG, Multi Hop, Adaptive, Agent of Agents），但 OpenClaw 的 Memory Search 是单次召回（pull 模式），Hermes 的 Session Search 也是单次 FTS5 查询——都还停在"静态 RAG"阶段，没有"反思 再检索"的循环和多源路由。把 Self RAG 做成 hook（每次召回后 LLM 自检"够不够"）是最低成本的切入点。 LangGraph 的做法 ：以 Checkpointer 为一等原语——每个节点执行都保存状态快照，支持时间旅行调试和断点恢复。Session 用 UserID + SessionID 组合隔离（和 OpenClaw 的 SessionKey 思路一致），但加了 Reducer 函数做并行状态合并——多路召回结果自动去重、按相关性排序后合并到共享状态。 对后端系统的启示 任何长期运行的 AI Agent 都会遇到"session 越来越长、context 越来越不好用"的问题。Anthropic 的实践证明，解法不是简单加大窗口，而是构建 上下文生命周期管理体系 ： • 预防性轮换 （两阶段 session 轮换，不等 overflow）——对应 Anthropic "上下文重置"的触发时机 • 结构化 Handoff （不是摘要，是"状态 + 决策 + 优先级"的完整交接）——对应 Anthropic 的 Sprint 间工件传递 • 动态召回替代全量加载 （只拉相关的历史，不是把所有记忆塞进 prompt）——降低单次推理的上下文噪声 • 检索后反思 （Self RAG 模式——"我拿到的信息够吗？"不够就再检索）——用对抗性自检取代盲目信任 OpenClaw 和 Hermes 已经在 Compaction, Dreaming, FTS5 上做了有效探索，上述业界实践可作为进一步迭代的参考方向。 22.4 Skill 渐进式披露——让"能力数量"不成为成本负担 当一个 Agent 有几十上百个 skill 时，全部塞进 prompt 不现实。Hermes 的三级披露（目录名 → 元数据 → 完整指令）和 OpenClaw 的预算降级（full → compact → 截断）都在解决同一个问题： 怎么让 Agent 知道自己"能做什么"而不为此付出 O(N) 的 token 成本 。这个思路可以直接迁移到任何"工具多、prompt 有限"的场景。 进一步延伸： 基于后台 MCP 服务快速构建云端 Skill 。后台系统通常已经有大量工具集（以 MCP Server 形式暴露），把这些 MCP 工具封装为标准 Skill 格式（name + description + 调用方式），就能通过统一的 Skill Registry 管理和分发。OpenClaw 的 ClawHub 和 Hermes 的 Skills Hub 本质都是这个模式： Skill 注册中心 + 渐进式披露 + 按需下载执行 。区别只是一个面向本地文件系统，一个面向云端注册中心——后台场景天然适合后者。 以 QQ 智能体为例：QQ 机器人承载的 Agent 和本地个人助手不同——它面向多个用户、长期在线、跑在后台，本质上是一个 服务端 Agent 。云端skill 体系可以带来两层红利： • 第一层：官方 Skill 快速迭代 ——把高频能力（群管理、日程提醒、内容订阅、文件检索等）封装为标准 Skill，通过 Skill Registry 按需加载。单个 Skill 只做一件事，但真实需求往往是组合的——比如"每天早上推送我关注话题的最新摘要"，需要串联：定时触发（cron）→ 信息检索（search tool）→ 内容生成（LLM summarize）→ 消息推送（channel send），把这条链路封装为一个 workflow 级 Skill，用户只需说"订阅 XX 话题"就能激活。上线一个新功能 = 注册一个新 Skill 或组合几个已有 Tool，不用改 Agent 代码。 • 第二层：用户侧经验自动沉淀 ——因为面向多用户，每个用户的使用模式不同。Agent 在日常交互中识别某个用户反复出现的操作链（比如某个群管理员每周一都要"导出上周活跃数据 + 生成周报 + 发到管理群"），自动编排为该用户的专属 Skill，后续直接执行不再重新推理。这就是 Hermes skill maker 搬到多用户后台场景的样子： 同一个 Agent 实例，为不同用户沉淀专属的能力集 。 两层结合：第一层保障 QQ 智能体能基于基础能力快速组合迭代好用的功能，第二层让它在服务每个用户的过程中持续进化——同一个机器人，面对不同用户越用越"懂你"。 22.5 确定性编排——当流程已明确，LLM 该退居幕后 渐进式披露解决的是"能力目录怎么不撑爆 prompt"，但还有另一个重要的 token 浪费的来源： 已经验证过的流程，每次仍要从头推理 。典型场景是定时工作流——数据采集、日报生成、舆情监控这类高频自动化任务。最初用 Skill 文档（几千字 .md）编排流程让 Agent 从零到一跑通了，但流程稳定后，Agent 每次依然老老实实重读全文、重新推理"第一步做什么、第二步调什么工具"—— 确定性的流程不需要每次都消耗不确定性的推理 。一种思路是把已验证的流程 从 Skill（指引式）固化为 Workflow ——固定步骤直接编排执行，只在需要判断的节点才调用 LLM。Hermes 的 skill maker 和 OpenClaw 的 Cron + Hook 组合都在朝这个方向走：让 Agent 只在"有必要思考"的地方思考，其余部分靠确定性编排完成。 22.6 多 Agent 协作编排——从"单进程内调度"到"跨架构互通" OpenClaw 的多 Agent 协作局限于同一个 Gateway 进程内（ sessions send , sessions spawn ），Hermes 的 delegate tool 也是进程内委派。它们解决的是 单一框架内 的多 Agent 问题。但后台场景往往更复杂——一条内容生产管线可能需要：调研 Agent + 生成 Agent + 质检 Agent + 审核 Agent + 人工审批节点，各自使用不同模型、不同工具集，有的跑在本地，有的跑在云端（如 LLM API），跨语言、跨框架。 GAN like 多智能体架构——"生成 对抗"的工程化落地 Anthropic 的 Harness Engineering 实践提出了一种受 GAN（生成对抗网络）启发的 多智能体协作范式 ，将单体 Agent 分解为三个职责清晰的角色： 角色 核心职责 交互机制 Planner（规划者） 将简短需求扩展为详细产品规格，拆分任务为可执行的冲刺 输出 Sprint Contract，定义每个冲刺的验收标准 Generator（生成器） 逐步实现每个冲刺，编写代码和设计 接收 Planner 的计划，按 Sprint Contract 交付 Evaluator（评估者） 像 QA 团队一样测试应用，寻找缺陷和改进点 通过 Playwright 等工具对运行中的应用进行 动态测试 （不是阅读静态代码） 这种架构的核心洞见 ：通过角色分离，系统实现了"生产"与"验收"的职责隔离——Generator 不能评估自己的输出（避免自我评估偏差），Evaluator 被提示词设计为"寻找漏洞的挑剔者"而非"友好用户"。更重要的是，每个角色可以独立做 Context Reset——Planner 完成规划后，Generator 以全新 session 启动，只接收结构化的任务描述，不背负规划过程中的推理噪声。 Sprint Contract（奔跑契约） ——明确任务边界与验收标准： 在每个冲刺开始前，Planner 与 Generator 就"完成"的定义达成一致——将主观的"完成标准"转化为可验证的客观条件。这防止了长周期任务中常见的 规范漂移 ：用户故事与实现细节之间的落差逐步积累成 bug。Sprint Contract 让 Evaluator 有明确的验收标准可执行，而非凭"感觉"打分。 对照两个框架 ： • OpenClaw 的 sessions spawn ：可以 spawn 多个子 Agent 并行执行，但缺少"Evaluator 角色"——子 Agent 完成任务后没有对抗性验证环节，结果直接回传父 Agent • Hermes 的 delegate tool ：子 Agent 有明确的阻止列表和迭代预算（§16.3），但同样没有独立的评估角色——父 Agent 既是委派者又是验收者 落地思路 ：在 OpenClaw 的 Subagent 机制上叠加"Evaluator Agent"—— subagentRole 新增 evaluator 类型，该角色拥有 Playwright MCP 工具但没有代码编辑权限，按 Sprint Contract 定义的 Rubric 对 Generator 的输出打分。分数不过则触发 Generator 在新 session 中修复（又一次 Context Reset），直到验收通过。这比当前的"spawn → 收结果 → 信任结果"更可靠。 协议层与编排层 协议层已经就绪 ：ACP（Agent 间通信协议）+ MCP（工具暴露协议）+ A2A（Google 的 Agent to Agent 协议）+ CLI 互调——理论上任何两个 Agent 只要支持其中一种协议就能互相调用。OpenClaw 同时暴露 MCP Server + ACP Server + HTTP API 的设计，让它可以作为"多协议中间层"被各种架构调用。 但缺少的是编排层 ——谁来决定"什么时候调谁、结果怎么汇总、失败了怎么重试、人工节点怎么插入"。OpenClaw 用 SOUL.md 里的 prompt 做调度（Supervisor 模式），Hermes 用 delegate tool 做委派——两者都是 LLM 驱动的隐式编排，缺少 显式的工作流定义和状态管理 。Anthropic 的 Sprint Contract 提供了一个中间态——不是完全靠 prompt 隐式调度，也不是完全硬编码 DAG，而是 在每个阶段开始前通过 LLM 生成显式的验收标准，再用确定性逻辑驱动验证循环 。 字节的 Eino 框架 （ github.com/cloudwego/eino ）在这个方向提供了一些值得参考的思路： • Graph 编排 ：用 compose.NewGraph 定义 DAG 工作流——节点是 Agent, Tool, Lambda，边是数据流。支持条件分支、并行执行、子图嵌套。比"靠 prompt 调度"更可控、可测试、可回溯。 • DeepAgent 模式 ：主 Agent 负责任务拆分和进度追踪，子 Agent 各自执行——每个子 Agent 可以是不同模型/不同工具集。类似 OpenClaw 的 sessions spawn 但加了显式的任务追踪——本质上是 Anthropic Planner 角色的工程化。 • Transfer 机制 ：Agent 之间可以显式"移交控制权"（ TransferToAgent ），不是简单发消息而是 连带上下文一起交接 ——这就是 Sprint 间结构化 Handoff 的实现方式。 • Checkpoint 一等原语 ：每个节点执行后自动保存状态快照，支持断点恢复和时间旅行调试——长流程任务中任何节点失败都可以从上一个成功点重跑。 对后端 Agent 平台的启示 ：如果要做"多个异构 Agent 协作完成复杂流程"，结合 Anthropic 的 GAN like 架构和业界编排框架，可能需要的架构是： Code block Plain Text Copy 协议层：ACP, MCP, A2A, HTTP（让不同框架的 Agent 互通） ↓ 编排层：显式 DAG 工作流 + Sprint Contract（定义"谁先谁后、验收标准是什么、失败怎么重试"） ↓ 执行层：各个 Agent 各自跑自己的 ReAct 循环（Generator/Evaluator/自研等） ↓ 状态层：Checkpoint + Context Reset + Handoff（每步保存、焦虑时重启、可人工介入） ↓ Harness 层：约束 + 对抗性验证 + 纠错（贯穿以上所有层） 22.7 Harness Engineering——Agent 执行的全链路治理 为什么需要 Harness：自我评估偏差是 Agent 失控的根源 Anthropic 在长周期任务中发现的第二大致命挑战是 自我评估偏差（Self evaluation Bias） ——模型在完成任务后，倾向于高估自己产出的质量。这种偏差表现为： • 盲目自信 ：模型会忽略明显的缺陷，给低质量输出打高分 • 拒绝查证 ：模型倾向于依赖自己的记忆和理解，而非外部工具或验证 • 幻觉闭环 ：模型在评估时构建自我强化的正向反馈循环，逐渐脱离现实 一个典型案例：模型生成看似完整的前端页面，但缺乏产品感和辨识度；功能看似可用，实际存在严重缺陷。当模型被要求自我评估时，它在工艺性和功能性上给出较高评分，但在设计质量和原创性上产生系统性偏差——"既当裁判又当运动员"不可能产出客观评估。 github.com/cloudwego/eino OpenClaw 的 Dreaming（Light → REM → Deep 三阶段自动整理）和 Hermes 的 Session Search（FTS5 全文搜索 + LLM 现场摘要）代表了两种互补的记忆策略。前者让 Agent "越用越聪明"（自动沉淀重要信息），后者让 Agent "什么都能想起来"（全量历史可搜索）。对于任何长期运行的 AI Agent，记忆的"写入 整理 检索 淘汰"全链路都需要显式设计，不能靠 context window 硬撑。 Dreaming 的进一步延伸——结合记忆工程新范式 ： 2026 年 Mem0 将 Agent 记忆显式定义为三类： 情景记忆 （发生了什么）、 语义记忆 （知道什么）、 程序性记忆 （如何做事）。Dreaming 三阶段恰好覆盖了这条转化链路——Light 摄入情景（近期对话和召回记录），REM 提取跨日反复主题形成"潜在真理"（抽象思考），Deep 将通过评分门控的真理固化为长期知识写入 MEMORY.md（注入每轮 prompt）。如果 Deep 晋升时给内容打上类型标签（fact/preference/procedure），就能区分"用户住北京"（语义）和"用户习惯先列大纲再写正文"（程序性）——后者本质上就是 用户级 Skill 的自动沉淀 。 更关键的是 千人千面潜力 ：Dreaming 的 6 信号评分完全由用户交互行为驱动（频率/相关性/多样性），只要加一层 user id 维度隔离，同一套算法 + 不同用户的行为模式 = 每个用户各自的长期记忆。用户 A 频繁讨论编程 → Dreaming 晋升编程偏好；用户 B 频繁讨论烹饪 → Dreaming 晋升烹饪知识—— 算法不变，数据区分，千人千面自然涌现 。 三个演进方向 ： • 与 Session 轮换联动 ：当 session 使用率达 60% 时触发一次 Light sweep，将当前高价值内容提取为候选（不写 MEMORY.md），Handoff 时作为新 session 的暖启动缓存——既保持 Dreaming "不轻易固化"的审慎，又解决 session 切换的记忆断裂 • REM 输出关系图 ：当前 buildRemReflections 提取的是扁平 concept tags；如果升级为实体关系三元组（ 用户 [用] Python [做] 数据管道 ），Deep 阶段就能晋升结构化知识而非孤立事实，支持多跳推理 • 增加遗忘机制 ：MEMORY.md 中长期未被召回的条目可能已过时（"用户住北京"但已搬家）；定期标记为"待验证"，下次对话主动确认——模拟人脑遗忘曲线，防止"自信但错误"的旧记忆污染决策 22.3 Context Engineering——从"上下文管理"到"上下文工程" 2026 年业界已将 Agent 的上下文管理提升为独立工程学科（Context Engineering）。核心认知： 上下文窗口不是"能装多少"的问题，而是"装什么、何时装、何时清"的系统设计问题 。OpenClaw 的 Session（JSONL append only）和 Hermes 的 Session（SQLite FTS5）都能"存"和"搜"，但在 主动管理 session 生命周期 和 跨 session 动态召回 方面，相比业界前沿还有差距。 上下文焦虑症——长周期任务失败的首要原因 Anthropic 在 Harness Engineering 实践中发现，长周期任务失败的首要原因不是模型能力不足，而是 上下文焦虑症（Context Anxiety） 。当模型在单次会话中连续运行数小时，处理包含大量代码、设计和状态信息的上下文时，会逐渐接近其注意力窗口的容量极限，产生三种典型症状： • 信息丢失 ：早期对话中的关键设计决策和约束条件被逐渐遗忘或边缘化 • 注意力崩溃 ：模型在处理新信息时无法有效关联先前的上下文，导致设计一致性丧失 • 提前收工倾向 ：当模型感知到上下文窗口接近极限时，会下意识地试图提前结束任务，即使工作远未完成 这与 Chroma Research 的发现互为印证——不是同一个问题的两种描述，而是同一个根因的 微观和宏观视角 。Chroma 从 Transformer 注意力机制出发，证明 Context Rot 是架构级属性（上下文每增长 10 倍，每个 token 获得的注意力权重减少 10 倍）；Anthropic 从工程实践出发，发现 Agent 在约 35 分钟 / 80K 150K tokens 时开始出现"焦虑"行为——本质都是 上下文长度超过有效注意力范围后，模型的推理质量不可避免地退化 。 对照分析 ：OpenClaw 的三级 Compaction（§6.5）和 Bootstrap Budget（§6.8）在做类似的事——L1 pre request 主动压缩、L2 timeout triggered 紧急压缩、L3 overflow 降级——但触发时机偏保守（接近上限才压缩），且压缩后仍在同一 session 内继续，没有"彻底重启"的选项。 上下文重置（Context Reset）vs 上下文压缩（Context Compaction） 针对上下文焦虑症，Anthropic 提出了比传统压缩更激进的解法—— 上下文重置（Context Reset） ： 类比 ：不是所有内存泄漏都能靠"清理缓存"解决，有时候得重启进程。在长周期任务中，当一个 Agent 完成一个冲刺后，系统会启动一个新的 Agent，只传递必要的状态信息——代码仓库的当前状态、已完成的任务清单、下一步的计划——从而彻底解决上下文窗口溢出问题。 两个框架的现状 ： • OpenClaw ：Compaction 是主要手段，Context Engine 的 compact() 接口支持可插拔的压缩策略，但没有内置的 session 级 reset 机制 • Hermes ：四步压缩（工具裁剪→边界→摘要→组装）+ 首轮冻结快照（隐式的 reset——新会话不继承旧会话的完整历史） 结合两者的演进方向 ：把 Reset 作为 Compaction 失败后的 兜底策略 纳入 Context Engine 契约——当压缩后的 context 仍超过有效注意力范围（而非 token 上限）