严格的 3,600 字符容量上限是一种信息蒸馏策略

让我们先看一个结论：Hermes Agent 为陈述性记忆设定的 3,600 字符硬上限（MEMORY.md 2,200 字符 + USER.md 1,375 字符），不是开发者疏忽留下的存储限制，而是一个刻意设计的蒸馏器。它将“Agent 能记多少”这个伪命题，转化为一个更深刻的问题：当容量成为稀缺资源，Agent 被迫不断追问“什么信息真正值得占用这 3,600 个字符”时，记忆才会从堆积变为提纯。

截至当前调研资料（2026 年 4 月至 5 月发布的多篇 Hermes Agent 架构分析），这一设计已被实践反复验证。多家技术博客和源码解读均指出：Hermes 的记忆精度显著高于无限制记忆的 Agent，而这种精度提升的核心机制，正是硬限制带来的价值排序压力。

现象：信息膨胀如何杀死推理

2026 年初，随着上下文窗口从 128K 一路膨胀到 1M token，Agent 开发者陷入一种错觉：既然能塞更多上下文，那就把用户所有对话历史都扔进去。但大量实践表明，上下文超限导致的推理退化遵循一个残酷的规律。

作者的结论：无限容量的记忆不是馈赠，而是对推理预算的慢性消耗。3,600 字符硬限制在一个看似苛刻的边界内，迫使记忆系统承担起“信息守门人”的角色。

维度一：信息膨胀的危害与 token 预算压力

当 Agent 不被约束地积累记忆时，每一次上下文加载都变成一场信息杂音的注入。问题出在三个层面：

1. 推理退化：大量非关键事实挤占模型的注意力机制，Agent 无法定位当前任务真正相关的记忆条目。这类似于在满屋杂物的房间里找一个螺丝刀——工具还在，但被噪声淹没了。

2. 工具调用空间被挤压：每次会话的系统提示已经包含了系统指令、工具定义、对话格式和记忆注入。当记忆膨胀，留给 Agent 规划工具调用链的 token 空间就相应萎缩。有实践报告指出，超过 10K 字符的记忆注入后，Agent 往往在复杂任务中提前结束推理循环。

3. 复盘信号被稀释：Hermes 的周期性 Nudge 机制（每执行到一定轮次自动触发复盘信号）依赖清晰的记忆来回溯已完成步骤。当记忆中充斥着冗余信息时，“该复盘的”和“该忽略的”界限模糊，导致自我学习循环停滞。

Token 预算分配对比（单次会话系统提示）

维度二：Agent 如何自主筛选与淘汰记忆条目

3,600 字符容量不是静态的文件大小限制，而是一个动态平衡的压力系统。Hermes Agent 在每次记忆更新时，都面临一个决策矩阵：

记忆价值评估的三维标尺

从当前调研资料看，Hermes 采用了一种“预压缩 + 硬限制”的组合策略。当 MEMORY.md 逼近 2,200 字符或 USER.md 逼近 1,375 字符时，触发以下流程：

1. 候选标记：对现有条目进行新鲜度/频率/重要性三维打分，标记低分段条目。
2. 蒸馏压缩：将多个零散事实压缩为一条聚合摘要，释放 40%-60% 的字符空间。
3. 冲突裁决：如果新记忆与旧记忆矛盾，新记忆覆盖旧记忆（这在下一章 memory_tool 的 add、replace、remove 操作中有精细实现）。
4. 硬淘汰：压缩后仍超限，直接移除最低分条目。

记忆条目生命周期

创建 → 使用（加分） → 冷却（低分） → 逼近容量上限 → 
蒸馏压缩（聚合）→ 仍超限？ → 硬淘汰
                    ↓ 未超限
                 占用精炼后的空间

关键理解：3,600 字符不是一个存储配额，而是一个蒸馏触发信号。每一次逼近上限都是一轮“什么不可删除”的价值排序。

维度三：超限时的决策流程与工具返回提示

当 Agent 执行记忆操作时，memory_tool 会实时返回用量信息，这正是硬限制发挥蒸馏作用的执行节点。

容量告警的层级响应

一次典型的超限处理流程

Agent 尝试写入新记忆 
→ memory_tool 检测超限，拒绝写入
→ 返回：{"error": "character_limit_exceeded", 
          "current_usage": 2235, 
          "limit": 2200, 
          "required_release": 35}
→ Agent 内部推理：“需要释放 35 个字符，当前 MEMORY.md 中有哪条信息可压缩？”
→ Agent 扫描记忆，发现两条陈旧事实可合并
→ 执行 replace 操作，释放 150 字符空间
→ 重试写入，成功

从当前调研资料和源码分析看（阿里云技术博客 2026 年 4 月发布的 Hermes Agent 源码拆解），这个流程并非每次都完全自动成功。在某些边缘情况下——当所有现有记忆都是高重要性条目且无法压缩时——Agent 会暂停操作并向用户发起确认请求：“我无法在不删除重要信息的情况下保存这条新记忆，是否用新信息替换 [已加锁的核心偏好]？”

这正是硬限制设计的精妙之处：它不是把决策权完全交给 Agent，也不是推给用户，而是在绝大多数情况下由 Agent 自主蒸馏，仅在触及不可自动裁决的边界时，将最终判断权交还给人类。

结论：硬限制是一种信息价值排序的压力装置

核心结论：3,600 字符容量上限通过制造“遗忘的代价”，将记忆管理从被动存储转化为主动蒸馏。它不是让 Agent 记得更少，而是逼 Agent 记得更精准。

无限制 vs 硬限制记忆系统的本质差异

按场景推荐：如何在硬限制内构建有效记忆

硬限制的存在，让 Hermes Agent 的记忆系统不只是一个存储模块，而是一个持续运行的蒸馏器。下一章，《memory_tool 的 add、replace、remove 操作实现了精细的冲突处理》，我们将深入这个蒸馏器的操作接口，看看 Agent 如何用三个原子操作完成新旧记忆的安全更新——当新事实与旧印象正面冲突时，replace 和 remove 的裁决机制将决定最终留在 3,600 字符内的，到底是谁的版本。