工作记忆管理——不要让 Token 成为瓶颈

一、Token 不是无限的，即使上下文再大

2023 年，4K 上下文是主流。2024 年，128K 开始普及。2025-2026 年，1M 甚至更长的上下文窗口出现了。

上下文窗口在扩大，但一个基本矛盾没变：窗口越大，注意力越稀薄。

长上下文的研究表明，LLM 在长上下文中的"有效注意力"集中在开头和结尾，中间部分存在明显的注意力衰减——无论上下文窗口多大，中间部分的信息都容易被忽略。

这意味着：

更大的上下文 ≠ 更好的记忆
更大的上下文 = 更多的 Token 成本 + 更稀释的注意力

工作记忆管理的核心不是"塞得下更多信息"，而是"在有限的注意力预算内，让关键信息始终处于有效位置"。

二、Token 预算管理

工作记忆管理的第一步是给 Token 定预算。

一个典型的分层上下文结构

┌────────────────────────────────────────────┐
│  系统指令（System Prompt）       约 500 Tok  │
│  ── 角色定义、行为边界、输出格式            │
├────────────────────────────────────────────┤
│  关键事实（Key Facts）           约 500 Tok  │
│  ── 用户偏好、当前项目上下文、重要约束      │
├────────────────────────────────────────────┤
│  会话历史（Conversation History） 约 2K Tok  │
│  ── 最近 N 轮对话（摘要压缩后）            │
├────────────────────────────────────────────┤
│  当前轮（Current Turn）          约 1K Tok  │
│  ── 用户的当前输入 + Agent 正在推理的内容   │
├────────────────────────────────────────────┤
│  可用余量（Buffer）              约 1K Tok  │
│  ── 给工具调用结果、检索结果预留的空间      │
└────────────────────────────────────────────┘
总预算：约 5K Tok（以 8K 模型为例，预留余量）

预算分配原则

三、三种压缩策略

当对话变长，需要压缩时，有三种主流策略，各有取舍。

策略一：滑动窗口

保留最近 N 轮对话，丢弃更早的内容

优点：实现最简单，成本可预测，不会引入压缩误差
缺点：早期信息完全丢失

适用场景：每轮相对独立的场景（如客服对话）

策略二：摘要压缩

定期将前面的内容压缩为摘要

优点：保留关键信息，Token 节省效果显著
缺点：摘要可能丢失细节，LLM 生成摘要有成本

适用场景：需要保留长期上下文的复杂对话

策略三：优先级保留

为每条信息打上优先级标签，低优先级的先被压缩或丢弃

P0 - 关键决策、核心参数（永不压缩）
P1 - 重要上下文、中间结论（摘要后保留）
P2 - 过程信息、尝试记录（可丢弃）
P3 - 低价值信息、闲聊（直接丢弃）

优点：关键信息有保障
缺点：需要判断"什么重要"

适用场景：复杂的技术工作、多轮决策场景

组合推荐

在实践中，三种策略可以组合使用：

分层上下文（框架）+
摘要压缩（每 N 轮触发）+
优先级保留（标记关键信息）

具体做法：

1. 上下文保持分层结构（系统指令 + 关键事实 + 对话历史 + 当前轮）
2. 每 5 轮或每 2K Tok，触发一次摘要压缩——把对话历史部分的前半段压缩
3. 对话中遇到关键决策时，由 Agent 自动打 P0 标签，存入"关键事实"区
4. Token 水位超过阈值时，先丢弃 P2/P3 信息，再压缩 P1

四、关键事实的识别和持久化

工作记忆管理中最重要的技巧之一：把关键决策从对话历史中"提"出来，放到关键事实区。

什么是"关键事实"

如何识别

在 Agent 的推理过程中，用一个轻量的分类器（或者 LLM 自己的判断）识别关键决策点：

用户说了一段话 → Agent 推理 → 输出结果

同时在输出时检查：
  - 是否有新的决策被做出？→ 提取为关键事实
  - 是否有约束条件被确定？→ 提取
  - 是否有之前方案被否定？→ 提取

关键事实区的最佳实践

• 数量控制： 关键事实区建议控制在 3-5 条，超过就做合并或淘汰
• 显式更新： 新决策覆盖旧决策时，在关键事实区做替换而不是追加
• 可追溯： 每条关键事实标记来源会话 ID，方便回溯

五、工作记忆转存为情景记忆

工作记忆是易失性的。会话结束后，它应该被转存为情景记忆，而不是直接丢弃或保留原样。

转存时机

转存内容

转存到情景记忆的不是原始对话，而是结构化的事件摘要：

{
  "type": "session_summary",
  "session_id": "sess_abc123",
  "timestamp": "2026-07-07T14:30:00",
  "duration": "45min",
  "key_decisions": [
    {"topic": "字段映射方案", "decision": "从 field_mapping 表动态读取"}
  ],
  "entities": ["sync_engine", "field_mapping"],
  "open_issues": ["API 限流还没处理"],
  "summary": "调试了同步引擎的字段映射问题，找到了根因并修复。"
}

六、你在 Hermes 中能直接做的优化

基于当前 Hermes Agent 的能力，几个可以立刻改进的点：

1. 改进 session_search 的使用时机。 新会话启动时，自动执行一次 session_search 检索相关历史，而不是等到 Agent 觉得"需要回忆"时才手动触发。
2. 建立"关键事实"区。 在系统提示词中增加一个"关键事实"区域，让 Agent 在对话过程中主动提取和更新关键决策。当前 Hermes 的 memory 工具已可以做类似的事。
3. 使用记忆沉淀流程。 每次会话结束前，让 Agent 自动生成一个会话摘要和关键决策列表——这就是工作记忆转存情景记忆的雏形。