上下文压缩与缓存

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"    # default — built-in lossy summarization
  engine: "lcm"           # example — plugin providing lossless context

该引擎负责：

• 决定何时触发压缩操作（should_compress()）
• 执行压缩操作（compress()）
• 可选地暴露可供代理调用的工具（如 lcm_grep）
• 跟踪来自 API 响应的 token 使用量

配置由 context.engine 在 config.yaml 中驱动。解析顺序如下：

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

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

可通过 hermes plugins → 提供商插件 → 上下文引擎 进行配置，或直接编辑 config.yaml。

有关开发上下文引擎插件，请参阅 上下文引擎插件。

双重压缩系统

Hermes 具有两个独立运行的压缩层：

                     ┌──────────────────────────┐
  Incoming message   │   Gateway Session Hygiene │  Fires at 85% of context
  ─────────────────► │   (pre-agent, rough est.) │  Safety net for large sessions
                     └─────────────┬────────────┘
                                   │
                                   ▼
                     ┌──────────────────────────┐
                     │   Agent ContextCompressor │  Fires at 50% of context (default)
                     │   (in-loop, real tokens)  │  Normal context management
                     └──────────────────────────┘

1. 网关会话净化（85% 阈值）

位于 gateway/run.py（搜索 _maybe_compress_session）。这是一个 安全网，在代理处理消息前运行。防止会话因长时间积累（如 Telegram/Discord 中过夜累积）导致 API 失败。

• 阈值：固定为模型上下文长度的 85%
• token 来源：优先使用上一轮 API 报告的实际 token 数；若不可用，则回退至粗略的字符估算（estimate_messages_tokens_rough）
• 触发条件：仅当 len(history) >= 4 且压缩功能启用时
• 目的：捕获逃逸出代理自身压缩器的会话

网关净化阈值有意高于代理压缩器的阈值。将阈值设为 50%（与代理相同）会导致长会话中每轮都提前压缩。

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

位于 agent/context_compressor.py。这是 主要压缩系统，在代理的工具循环内部运行，并能访问准确的 API 报告 token 数。

配置

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

compression:
  enabled: true              # Enable/disable compression (default: true)
  threshold: 0.50            # Fraction of context window (default: 0.50 = 50%)
  target_ratio: 0.20         # How much of threshold to keep as tail (default: 0.20)
  protect_last_n: 20         # Minimum protected tail messages (default: 20)
  summary_model: null        # Override model for summaries (default: uses auxiliary)

参数详情

参数	默认值	范围	描述
threshold	0.50	0.0–1.0	当提示 token 数 ≥ threshold × context_length 时触发压缩
target_ratio	0.20	0.10–0.80	控制尾部保护 token 预算：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() 方法采用四阶段算法：

阶段 1：清理旧工具结果（低成本，无需 LLM 调用）

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

[Old tool output cleared to save context space]

这是一种低成本的预处理步骤，可显著节省冗长工具输出（文件内容、终端输出、搜索结果）所占用的 token。

阶段 2：确定边界

┌─────────────────────────────────────────────────────────────┐
│  Message list                                               │
│                                                             │
│  [0..2]  ← protect_first_n (system + first exchange)        │
│  [3..N]  ← middle turns → SUMMARIZED                        │
│  [N..end] ← tail (by token budget OR protect_last_n)        │
│                                                             │
└─────────────────────────────────────────────────────────────┘

尾部保护基于 token 预算：从末尾开始反向遍历，累计 token 直至预算耗尽。若预算保护的消息少于固定值 protect_last_n，则回退至该固定数量。

边界对齐以避免拆分 tool_call/tool_result 组。_align_boundary_backward() 方法会跳过连续的工具结果，找到父级助手消息，确保组内完整。

阶段 3：生成结构化摘要

中间部分通过辅助 LLM 和结构化模板进行摘要：

## Goal
[What the user is trying to accomplish]

## Constraints & Preferences
[User preferences, coding style, constraints, important decisions]

## Progress
### Done
[Completed work — specific file paths, commands run, results]
### In Progress
[Work currently underway]
### Blocked
[Any blockers or issues encountered]

## Key Decisions
[Important technical decisions and why]

## Relevant Files
[Files read, modified, or created — with brief note on each]

## Next Steps
[What needs to happen next]

## Critical Context
[Specific values, error messages, configuration details]

摘要预算随压缩内容量动态调整：

• 公式：content_tokens × 0.20（其中 _SUMMARY_RATIO 为常数）
• 最小值：2,000 token
• 最大值：min(context_length × 0.05, 12,000) token

阶段 4：组装压缩后消息

压缩后的消息列表包含：

1. 头部消息（首次压缩时，在系统提示末尾附加说明）
2. 摘要消息（角色选择避免连续同角色违规）
3. 尾部消息（保持不变）

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

• 引用已删除调用的结果 → 删除
• 其结果已被删除的调用 → 注入占位结果

迭代式再压缩

在后续压缩中，上一次的摘要会被传递给 LLM，指令为 更新 而非从头总结。这可跨多次压缩保留信息——项目从“进行中”变为“已完成”，新增进展，过时信息被移除。

压缩器实例上的 _previous_summary 字段用于存储上一次摘要文本，以实现此功能。

压缩前后示例

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

[0] system:    "You are a helpful assistant..." (system prompt)
[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 more turns of file editing, testing, debugging ...
[38] assistant: <tool_call> terminal: pytest </tool_call>
[39] tool:      "8 passed, 2 failed\n..."  (5KB output)
[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 token）

[0] system:    "You are a helpful assistant...
               [Note: Some earlier conversation turns have been compacted...]"
[1] user:      "Help me set up a FastAPI project"
[2] assistant: "[CONTEXT COMPACTION] Earlier turns were compacted...

               ## Goal
               Set up a FastAPI project with tests and error handling

               ## Progress
               ### Done
               - Created project structure: main.py, tests/, requirements.txt
               - Implemented 5 API endpoints in main.py
               - Wrote 10 test cases in tests/test_api.py
               - 8/10 tests passing

               ### In Progress
               - Fixing 2 failing tests (test_create_user, test_delete_user)

               ## Relevant Files
               - main.py — FastAPI app with 5 endpoints
               - tests/test_api.py — 10 test cases
               - requirements.txt — fastapi, pytest, httpx

               ## Next Steps
               - Fix failing test fixtures
               - Add error handling"
[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

通过缓存对话前缀，使多轮对话的输入 token 成本降低约 75%。使用 Anthropic 的 cache_control 断点机制。

策略：system_and_3

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

Breakpoint 1: System prompt           (stable across all turns)
Breakpoint 2: 3rd-to-last non-system message  ─┐
Breakpoint 3: 2nd-to-last non-system message   ├─ Rolling window
Breakpoint 4: Last non-system message          ─┘

工作原理

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

# Cache marker format
marker = {"type": "ephemeral"}
# Or for 1-hour TTL:
marker = {"type": "ephemeral", "ttl": "1h"}

标记根据内容类型不同而应用方式不同：

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

缓存感知设计模式

1. 稳定的系统提示：系统提示为断点 1，跨所有轮次缓存。避免在对话中途修改它（压缩仅在首次压缩时追加说明）。

2. 消息顺序至关重要：缓存命中要求前缀完全匹配。在中间插入或删除消息会使之后所有内容的缓存失效。

3. 压缩与缓存的交互：压缩后，压缩区域的缓存被清除，但系统提示缓存仍保留。滚动的 3 消息窗口可在 1–2 轮内重新建立缓存。

4. TTL 选择：默认为 5m（5 分钟）。对于用户在轮次间有长时间停顿的长期会话，建议使用 1h。

启用提示缓存

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

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

# config.yaml — TTL is configurable
model:
  cache_ttl: "5m"   # "5m" or "1h"

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

💾 Prompt caching: ENABLED (Claude via OpenRouter, 5m TTL)

上下文压力警告

代理在达到压缩阈值的 85% 时发出上下文压力警告（不是上下文总量的 85% —— 而是阈值的 85%，而阈值本身为上下文的 50%）：

⚠️  Context is 85% to compaction threshold (42,500/50,000 tokens)

压缩后，若使用量降至阈值的 85% 以下，警告状态将被清除。若压缩未能将使用量降至警告水平（对话过于密集），警告将持续存在，但压缩不会再次触发，直到阈值再次被突破。