title: “上下文压缩与缓存” description: “Hermes 的可插拔上下文引擎、双层压缩策略和 Anthropic 提示缓存。”

上下文压缩与缓存

Hermes 需要在长会话中控制上下文长度，同时尽量保留决策、目标和重要状态。为此，它提供上下文压缩和 provider 级提示缓存两类机制。

可插拔 Context Engine

上下文处理由 ContextEngine 抽象承载。默认实现会做有损摘要，但也可以通过插件替换为更复杂的策略。

更多细节见 Building a Context Engine Plugin。

双层压缩系统

1. Gateway Session Hygiene（85% 阈值）

Gateway 层会在会话过长时做较早期的卫生处理，避免消息平台会话持续累积到不可控长度。

2. Agent ContextCompressor（50% 阈值，可配置）

Agent 层的 ContextCompressor 更接近实际模型窗口。它会根据模型上下文长度和配置阈值判断是否压缩。

配置

压缩相关配置通常包括：

• 是否启用压缩；
• 触发阈值；
• 目标压缩比例；
• 用于摘要的模型；
• 是否裁剪旧工具结果。

参数细节

阈值越低，越早压缩，安全余量越大，但可能损失更多上下文。阈值越高，保留信息更多，但更容易触碰模型窗口上限。

计算值示例

对于 200K 上下文模型，默认配置可能会在中等压力时开始压缩，并把压缩后的上下文控制在安全目标范围内。

压缩算法

阶段 1：裁剪旧工具结果

这是便宜的第一步，不需要 LLM 调用。旧工具输出往往很长，但其中只有结论重要，因此可以先删除或缩短过时结果。

阶段 2：确定边界

压缩不会简单处理全部历史。通常会保留：

• 最新消息；
• 系统与关键上下文；
• 未完成任务；
• 需要继续引用的工具结果。

中间较旧的消息才是主要摘要对象。

阶段 3：生成结构化摘要

摘要不是随意概括，而是尽量保留：

• 当前目标；
• 已完成事项；
• 进行中工作；
• 阻塞点；
• 关键决策；
• 相关文件；
• 下一步；
• 重要上下文。

Goal

摘要中的 Goal 描述当前会话要完成的目标，帮助压缩后的 Agent 继续保持方向。

Constraints & Preferences

这里记录用户偏好、工程约束、安全限制和不能违反的上下文规则。

Progress

进度通常拆成 Done、In Progress 和 Blocked，方便压缩后继续工作。

Done

已经完成的事项。

In Progress

正在推进但尚未完成的事项。

Blocked

被外部条件、缺失信息或错误阻塞的事项。

Key Decisions

记录重要设计选择和取舍，避免压缩后重复讨论已经决定的问题。

Relevant Files

列出与当前任务直接相关的文件路径。

Next Steps

给压缩后的 Agent 明确下一步执行方向。

Critical Context

记录不能丢失的细节，例如用户明确要求、危险操作限制、测试结果或未提交变更。

阶段 4：组装压缩后的消息

压缩完成后，系统会把摘要和保留消息重新组合成新的上下文序列。

迭代式重复压缩

如果压缩后仍然过长，系统可以继续压缩，直到达到目标范围或触发安全失败。

压缩前后示例

压缩前（45 条消息，约 95K tokens）

原始历史可能包含大量中间命令输出、完整工具结果和重复讨论。

压缩后（25 条消息，约 45K tokens）

压缩后保留最新交互、关键文件、结构化摘要和必要工具结果，从而降低上下文压力。

Prompt Caching（Anthropic）

Anthropic 支持对提示前缀设置缓存断点。Hermes 会把稳定的系统提示层组织成可缓存前缀。

策略：system_and_3

该策略通常缓存系统提示以及前几条稳定消息，减少长系统提示在多轮调用中的重复成本。

工作方式

缓存标记会加在 provider 支持的消息位置上，例如：

# Cache marker format
# Or for 1-hour TTL:

缓存感知设计模式

为了让缓存有效，应尽量把稳定内容放在前缀层，把动态内容放在靠后位置。

启用 Prompt Caching

# config.yaml — TTL is configurable

上下文压力警告

当上下文接近风险阈值时，系统可能会发出警告或提前压缩，避免下一次 API 调用直接失败。