6.3. 上下文压缩算法是长对话 Agent 的生命线

上下文压缩算法是长对话 Agent 的生命线

2025 年以来，大模型上下文窗口从 128K 一路冲到 1M tokens，甚至出现了“无限上下文”的技术演示。然而长对话 Agent 的工程实践却揭示出一个残酷现实：窗口越长，推理越贵，注意力越散。斯坦福的“Lost in the Middle”研究已经证明，模型对上下文中间位置的信息天然不敏感；更致命的是，在对话轮次飙升到上百轮后，即使模型仍能处理全部历史，单次调用的延迟和成本也早已超过系统的承受极限。

这就是为什么上下文压缩不是一剂补丁，而是长对话 Agent 的生命线——它决定了 Agent 能否在真实生产环境里持续运行上千轮，而不至于被自身记忆压垮。

Hermes Agent 的架构设计者们很早就把这个问题摆到了核心位置。“那些压缩、缓存、摘要、快照冻结等设计，指向的是同一个问题：当前推理到底该携带哪些信息？哪些只要存在数据库里？哪些值得沉淀为长期记忆？”【调研来源】
下面我们将从三种典型策略出发，拆解它们各自的取舍，并给出可落地的选型建议。

滑动窗口与令牌截断：最轻量，也最危险

滑动窗口是最老派、最直观的上下文管理方式——只保留最近 N 条消息，余下的直接丢弃。几乎所有 LLM API 都支持 max_tokens 和 messages 数组截断，零开发成本，延迟最低。

但这种简单背后藏着严重的“失忆症”。

考虑一个客服 Agent 的多轮对话：

用户: 我上个月买的手机屏幕有坏点，能换货吗？
Agent: 请问您的订单号是什么？
用户: 20260218-8892
Agent: 查到您的订单，购买日期是 2 月 18 日，仍在 30 天换货期内。告诉我您具体的地址？
用户: 北京市海淀区中关村南大街5号院，收件人张三
Agent: 好的，请问坏点有几个？
用户: 3个，都在左上角
Agent: [此时窗口已滚动，丢弃了订单号和地址] 
     请告诉我您的订单号？我是专门帮您处理退换货的。

当会话上下文被无情截断后，Agent 开始向用户索要已经提供过的关键信息。用户体验瞬间崩溃。

表 1：滑动窗口策略的维度分析

作者的结论：滑动窗口只能作为最后兜底，绝不能当成唯一策略。长对话 Agent 必须引入更高阶的压缩方式。

层次化摘要：抓住主线，但牺牲细节

为了让 Agent 记住更早的内容，工程界很早就开始实践“递归摘要”：每隔一段轮次（比如 10 轮），取已有历史生成一段摘要，然后把旧的完整消息替换为摘要，仅保留最近几轮的原文。这样上下文长度得到有效控制，同时概要性的意图和事实得以保留。

这是一个典型的摘要触发逻辑：

if token_count(conversation) > threshold:
    # 前面 N-窗口大小的部分压缩为摘要
    old_messages = conversation[:-window_size]
    summary = llm.generate(
        f"将下面对话压缩为适合后续推理的摘要：\n{old_messages}"
    )
    # 新上下文 = 摘要 + 最新 window_size 轮完整消息
    conversation = [{"role": "system", "content": summary}] 
                   + conversation[-window_size:]

在 Hermes Agent 的实践中，这一策略被封装为 Memory Manager 的标准能力之一。其官方文档指出，周期性触发的摘要任务可以在后台线程执行，避免阻塞用户交互【调研来源，需交叉验证】。

但摘要算法也有自己的阿喀琉斯之踵。首先，摘要天然是“有损压缩”，一些将来可能变得至关重要的细节（比如某个具体的配置参数、一个边缘条件的讨论）可能在摘要中被泛化或丢失。其次，每轮摘要都要调用一次大模型，这会带来 计算开销和延迟——假如 100 轮对话触发了 10 次摘要，其成本相当于凭空多了 10 次额外推理。更糟糕的是，如果摘要本身不够准确，这种误差还会在后续摘要中层层放大。

表 2：层次化摘要策略的维度分析

作者的结论：摘要能有效压缩 80% 的冗余，但必须为剩下的 20% 关键细节提供“安全网”。

Hermes 的混合压缩方案：缓存 + 摘要 + 按需检索

真正面向生产的长对话 Agent，几乎都在实践同一种组合哲学：不同类型的信息，用不同的压缩策略。这正是 Hermes Agent Harness 系统的核心理念【调研来源：Hermes Agent Harness 权限控制等】。

它的混合压缩方案包含三个协同组件：

1. 固定缓存（Pinned Cache）：用户明确定义的关键信息（如订单号、问题定义、决策结论）会被标记为“不可压缩”，始终保留在上下文中。这相当于给记忆打上“高亮书签”，避免被摘要或截断误伤。

2. 滑动摘要窗口：每 N 轮（可配置）自动生成会话摘要，旧消息转为摘要，新消息保持原样。摘要也支持分层——可在更长的周期生成“摘要的摘要”，形成金字塔式记忆结构。

3. 按需检索（On-demand Retrieval）：当模型发现自己的上下文缺少某些细节时，可以主动向历史存储发起查询，把相关片段拉回上下文。这得益于 Hermes 内建的向量索引——所有历史消息（包括摘要前的原文）都以 embedding 形式保存在本地向量库中，检索延迟通常在毫秒级。

图：Hermes 混合压缩工作流（概念）

原始对话历史 (100轮)
    │
    ├─[固定缓存]→ 订单号、故障ID等关键信息永远在线
    │
    ├─[窗口管理]→ 最近 10 轮完整保留
    │
    ├─[摘要压缩]→ 前 90 轮生成一份约 200 token 的摘要
    │
    └─[向量索引]→ 旧完整历史索引入库，按需检索

当 Agent 在推理中发现需要对更早的细节进行确认时，它会在生成的工具调用中追加一个 retrieve_memory 操作，从向量库中拉回相关性最高的几条历史消息，再次注入到当前上下文中。这种 “先轻量上下文推理，发现缺口再查全量” 的模式，极大地降低了常态下的上下文成本，同时又保证了关键时刻的信息完整性。

Hermes 的 v0.13 版本公开代码中，我们可以清晰看到 MemoryManager 模块负责这项工作的调度【调研来源：Hermes Agent v0.13 Reference】。其工程上还引入了快照冻结（Snapshot Freeze）技术——在关键决策点自动保存完整上下文快照，以便事后复盘和训练，而不影响主推理链路的上下文长度。

表 3：三种压缩策略综合对比

先给结论：一个节点打不死，组合才是解药

结论：长对话 Agent 的消息压缩不存在银弹，必须建立多级缓存、按需检索与摘要结合的混合流水线。工程上优先投资“固定缓存”与“可配置摘要触发”，再逐步引入向量检索以解决细节追忆。

任何试图用单一机制（比如无限上下文窗口）来硬扛的做法，最终都会在延迟、费用和注意力衰减的三角困境中被迫重构。

为了帮助团队快速决策，下面给出按场景的推荐策略矩阵：

表 4：按场景推荐的压缩策略

实现建议：第一周先落地滑动窗口和固定缓存，确保基础体验无误；第二周引入摘要机制并调试 Prompt，使摘要质量达到 90% 以上的信息覆盖率；第三周上向量检索，打通按需查历史细节的回路。每个阶段都需配套评估任务（参见下一章），确认压缩没有造成能力退化。

结语：压缩的艺术在于“恰到好处的忘记”

上下文压缩本质上是在教会 Agent “懂得遗忘”——丢弃无用的白噪声，凝练经验性的精髓，记住致命的关键细节。Hermes 的工程实践证明，这种能力无法靠单一技术点完成，而需要架构层面的意识。好消息是，一旦混合压缩流水线搭建完成，Agent 就能从“短时记忆的生物”进化为拥有持久记忆的智能体。

然而，遗忘也有代价：如果我们压缩了不该压缩的信息，Agent 就可能做出错误判断。下一章，我们将深入 自进化闭环需要配套的评估体系来避免能力退化——你将看到如何设计评估任务集与监控面板，来持续验证学习与压缩策略是否正在让你的 Agent 变得更好，而非更糟。