上下文压缩与缓存

Hermes Agent 使用双重压缩系统和 Anthropic 提示缓存来高效管理长对话中的上下文窗口使用。

源文件：agent/context_engine.py（ABC）、agent/context_compressor.py（默认引擎）、 agent/prompt_caching.py、gateway/run.py（会话卫生）、run_agent.py（搜索 _compress_context）

可插拔的上下文引擎

上下文管理建立在 ContextEngine ABC（agent/context_engine.py）之上。内置的 ContextCompressor 是默认实现，但插件可以用替代引擎（例如无损上下文管理）替换它。

context:
  engine: "compressor"    # 默认——内置有损摘要
  engine: "lcm"           # 示例——提供无损上下文的插件

引擎负责：

决定何时应触发压缩（should_compress()）
执行压缩（compress()）
可选地暴露智能体可以调用的工具（例如 lcm_grep）
从 API 响应跟踪令牌用量

选择由配置驱动，通过 config.yaml 中的 context.engine。解析顺序：

检查 plugins/context_engine/<name>/ 目录
检查通用插件系统（register_context_engine()）
回退到内置的 ContextCompressor

插件引擎永远不会自动激活——用户必须显式地将 context.engine 设置为插件的名称。默认的 "compressor" 始终使用内置引擎。

通过 hermes plugins → Provider Plugins → Context Engine 配置，或直接编辑 config.yaml。

关于构建上下文引擎插件，请参见上下文引擎插件。

双重压缩系统

Hermes 有两个独立的压缩层，彼此独立运行：

                     ┌──────────────────────────┐
  传入消息           │  网关会话卫生            │ 在上下文的 85% 触发
  ─────────────────► │  （智能体前，粗略估算）   │ 大型会话的安全网
                     └─────────────┬────────────┘
                                   │
                                   ▼
                     ┌──────────────────────────┐
                     │  智能体 ContextCompressor │ 在上下文的 50% 触发（默认）
                     │  （循环内，真实令牌）     │ 正常上下文管理
                     └──────────────────────────┘

1. 网关会话卫生（85% 阈值）

位于 gateway/run.py 中（搜索 Session hygiene: auto-compress）。这是一个安全网，在智能体处理消息之前运行。它防止会话在轮次之间增长过大时导致 API 失败（例如 Telegram/Discord 中的过夜累积）。

阈值：固定在模型上下文长度的 85%
令牌来源：优先使用上一轮实际 API 报告的令牌；回退到基于字符的粗略估算（estimate_messages_tokens_rough）
触发条件：仅在 len(history) >= 4 且压缩启用时
目的：捕获从智能体自身压缩器漏掉的会话

网关卫生阈值有意高于智能体的压缩器。将其设为 50%（与智能体相同）导致在长网关会话的每一轮都进行过早压缩。

2. 智能体 ContextCompressor（50% 阈值，可配置）

位于 agent/context_compressor.py。这是主要压缩系统，在智能体的工具循环内运行，可以访问准确的 API 报告令牌计数。

配置

所有压缩设置从 config.yaml 的 compression 键下读取：

compression:
  enabled: true              # 启用/禁用压缩（默认：true）
  threshold: 0.50            # 上下文窗口比例（默认：0.50 = 50%）
  target_ratio: 0.20         # 阈值中保留为尾部的比例（默认：0.20）
  protect_last_n: 20         # 最小保护尾部消息数（默认：20）
 
# 摘要模型/提供商在 auxiliary 下配置：
auxiliary:
  compression:
    model: null              # 用于摘要的覆盖模型（默认：自动检测）
    provider: auto           # 提供商："auto"、"openrouter"、"nous"、"main" 等
    base_url: null           # 自定义兼容 OpenAI 的端点

参数详情

参数	默认值	范围	描述
`threshold`	`0.50`	0.0-1.0	当提示词令牌 ≥ `threshold × context_length` 时触发压缩
`target_ratio`	`0.20`	0.10-0.80	控制尾部保护令牌预算：`threshold_tokens × target_ratio`
`protect_last_n`	`20`	≥1	始终保留的最近消息最小数量
`protect_first_n`	`3`	（硬编码）	系统提示词 + 首次交换始终保留

计算值（以默认值在 200K 上下文模型上为例）

context_length       = 200,000
threshold_tokens     = 200,000 × 0.50 = 100,000
tail_token_budget    = 100,000 × 0.20 = 20,000
max_summary_tokens   = min(200,000 × 0.05, 12,000) = 10,000

压缩算法

ContextCompressor.compress() 方法遵循 4 阶段算法：

阶段 1：修剪旧工具结果（低成本，无 LLM 调用）

受保护尾部之外的旧工具结果（>200 字符）被替换为：

[旧工具输出已清除以节省上下文空间]

这是一个低成本的前置处理，可从冗长的工具输出（文件内容、终端输出、搜索结果）中节省大量令牌。

阶段 2：确定边界

┌─────────────────────────────────────────────────────────────┐
│  消息列表                                                    │
│                                                             │
│  [0..2]  ← protect_first_n（系统提示词 + 首次交换）          │
│  [3..N]  ← 中间轮次 → 被摘要                                 │
│  [N..end] ← 尾部（按令牌预算 或 protect_last_n）             │
│                                                             │
└─────────────────────────────────────────────────────────────┘

尾部保护基于令牌预算：从末尾向前遍历，累积令牌直到预算耗尽。如果预算保护的消息数少于固定的 protect_last_n 计数，则回退到该计数。

边界会对齐以避免拆散 tool_call/tool_result 组。_align_boundary_backward() 方法会向后遍历连续的工具结果，以找到父级 assistant 消息，保持组完整。

阶段 3：生成结构化摘要

:::warning 摘要模型上下文长度摘要模型的上下文窗口必须至少与主智能体模型一样大。整个中间部分通过一次 call_llm(task="compression") 调用发送到摘要模型。如果摘要模型的上下文较小，API 会返回上下文长度错误——_generate_summary() 捕获它，记录警告，并返回 None。然后压缩器会在没有摘要的情况下丢弃中间轮次，静默丢失对话上下文。这是压缩质量下降的最常见原因。 :::

中间轮次使用辅助 LLM 和结构化模板进行摘要：

## Goal
[用户试图完成什么]

## Constraints & Preferences
[用户偏好、编码风格、约束、重要决策]

## Progress
### Done
[已完成的工作——具体的文件路径、已运行的命令、结果]
### In Progress
[正在进行的工作]
### Blocked
[遇到的任何阻塞器或问题]

## Key Decisions
[重要的技术决策及其原因]

## Relevant Files
[已读取、修改或创建的文件——每个附简短说明]

## Next Steps
[接下来需要做什么]

## Critical Context
[特定的值、错误消息、配置细节]

摘要预算随被压缩的内容量扩展：

公式：content_tokens × 0.20（_SUMMARY_RATIO 常量）
最小值：2,000 令牌
最大值：min(context_length × 0.05, 12,000) 令牌

阶段 4：组装压缩消息

压缩后的消息列表为：

头部消息（首次压缩时在系统提示词后附加一条注释）
摘要消息（角色选择为避免连续相同角色违规）
尾部消息（未修改）

孤立的 tool_call/tool_result 对由 _sanitize_tool_pairs() 清理：

引用已移除调用的工具结果 → 移除
其结果已被移除的工具调用 → 注入桩结果

迭代重新压缩

在后续压缩中，之前的摘要会传递给 LLM，指令是更新它而不是从头摘要。这可以在多次压缩之间保存信息——项目从”进行中”移动到”已完成”，添加新进度，移除过时信息。

压缩器实例上的 _previous_summary 字段为此目的存储了最后的摘要文本。

前后示例

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

[0] system:    "You are a helpful assistant..."（系统提示词）
[1] user:      "Help me set up a FastAPI project"
[2] assistant: <tool_call> terminal: mkdir project </tool_call>
[3] tool:      "directory created"
[4] assistant: <tool_call> write_file: main.py </tool_call>
[5] tool:      "file written (2.3KB)"
    ... 30 多个文件编辑、测试、调试轮次 ...
[38] assistant: <tool_call> terminal: pytest </tool_call>
[39] tool:      "8 passed, 2 failed\n..."（5KB 输出）
[40] user:      "Fix the failing tests"
[41] assistant: <tool_call> read_file: tests/test_api.py </tool_call>
[42] tool:      "import pytest\n..."（3KB）
[43] assistant: "I see the issue with the test fixtures..."
[44] user:      "Great, also add error handling"

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

[0] system:    "You are a helpful assistant...
               [注意：一些早期的对话轮次已被压缩...]"
[1] user:      "Help me set up a FastAPI project"
[2] assistant: "[CONTEXT COMPACTION] 较早的轮次已被压缩...

               ## Goal
               设置一个带测试和错误处理的 FastAPI 项目

               ## Progress
               ### Done
               - 创建了项目结构：main.py、tests/、requirements.txt
               - 在 main.py 中实现了 5 个 API 端点
               - 在 tests/test_api.py 中编写了 10 个测试用例
               - 8/10 测试通过

               ### In Progress
               - 修复 2 个失败的测试（test_create_user、test_delete_user）

               ## Relevant Files
               - main.py — 带 5 个端点的 FastAPI 应用
               - tests/test_api.py — 10 个测试用例
               - requirements.txt — fastapi、pytest、httpx

               ## Next Steps
               - 修复失败的测试装置
               - 添加错误处理"
[3] user:      "Fix the failing tests"
[4] assistant: <tool_call> read_file: tests/test_api.py </tool_call>
[5] tool:      "import pytest\n..."
[6] assistant: "I see the issue with the test fixtures..."
[7] user:      "Great, also add error handling"

提示缓存（Anthropic）

源文件：agent/prompt_caching.py

通过在多轮对话中缓存对话前缀，减少约 75% 的输入令牌成本。使用 Anthropic 的 cache_control 断点。

策略：system_and_3

Anthropic 每个请求最多允许 4 个 cache_control 断点。Hermes 使用 “system_and_3” 策略：

Breakpoint 1：系统提示词           （所有轮次中稳定）
Breakpoint 2：倒数第 3 条非系统消息  ─┐
Breakpoint 3：倒数第 2 条非系统消息   ├─ 滚动窗口
Breakpoint 4：最后一条非系统消息     ─┘

工作原理

apply_anthropic_cache_control() 深拷贝消息并注入 cache_control 标记：

# 缓存标记格式
marker = {"type": "ephemeral"}
# 或 1 小时 TTL：
marker = {"type": "ephemeral", "ttl": "1h"}

标记根据内容类型不同位置应用：

内容类型	标记位置
字符串内容	转换为 `[{"type": "text", "text": ..., "cache_control": ...}]`
列表内容	添加到最后一个元素的字典中
无/空	添加为 `msg["cache_control"]`
工具消息	添加为 `msg["cache_control"]`（仅原生 Anthropic）

缓存感知的设计模式

稳定的系统提示词：系统提示词是断点 1，跨所有轮次缓存。避免在对话中途修改它（压缩仅在第一次压缩时追加一条注释）。
消息顺序很重要：缓存命中需要前缀匹配。在中间添加或移除消息会使之后的所有缓存失效。
压缩缓存交互：压缩后，压缩区域的缓存失效，但系统提示词缓存仍然存活。滚动 3 消息窗口会在 1-2 轮内重新建立缓存。
TTL 选择：默认是 5m（5 分钟）。对用户会在轮次之间休息的长时间运行会话使用 1h。

启用提示缓存

提示缓存在以下情况下自动启用：

模型是 Anthropic Claude 模型（通过模型名称检测）
提供商支持 cache_control（原生 Anthropic API 或 OpenRouter）

# config.yaml — TTL 可配置（必须是 "5m" 或 "1h"）
prompt_caching:
  cache_ttl: "5m"

CLI 在启动时显示缓存状态：

💾 提示缓存：已启用（Claude 通过 OpenRouter，5m TTL）

上下文压力警告

中间的上下文压力警告已被移除（参见 run_agent.py 中的迭代预算块，其中指出：“没有中间压力警告——它们导致模型在复杂任务上过早’放弃’”）。压缩在提示词令牌达到配置的 compression.threshold（默认 50%）时触发，无需事先警告步骤；网关会话卫生作为二级安全网在模型上下文窗口的 85% 处触发。

好奇心花园🪴

探索

最近的笔记

note-template

getMoon.js

getWeather.js

context-compression-and-caching