夜雨聆风
记太多让 AI 变蠢?Hermes‑Agent 上下文压缩,提速降本实战
AI 记太多反而变笨？Hermes‑Agent 内置 ContextCompressor，解决上下文膨胀、延迟高、信噪比低，实测成本大降、体验飞升。
上篇文章讲了怎么给 AI 装上记忆。有读者问：装了记忆之后会不会太重，反而「记太多」？这是一个好问题。今天的故事，就从「记太多」开始。
01. 🌟 老王的新烦恼
上线两个月后，老王的 AI 客服彻底翻身了。
满意度从 61% 拉到了 87%，首次解决率从 34% 提到了 79%。复盘会上，老王得意地说了一句「这个 AI，值 1/8 的钱，干了 3 倍的活」，全场鼓掌。
然后，三个月后，问题来了。
02. 记太多了
老王发现了一个诡异的现象：某些对话开始变得特别慢。
慢到用户已经开始抱怨：「怎么还没回复？」
他去看后台日志，发现了问题：
用户：我的订单#7823什么时候到？AI：[等待了 6 秒]AI：您好，您的订单#7823已于上周五发出，预计周三到达。这 6 秒在等什么？
老王顺着日志往下看，发现 AI 每次回复前，都在重新计算上下文 token——上下文已经膨胀到了十几万 tokens，API 请求越来越慢。
更糟的是：AI 开始记错了。
不是记不住，是记太多。
它把三年前的一个退货投诉、三周前的一次换货请求、三天前的一次物流延误，全部塞进了 prompt。结果是：AI 读完了所有历史，反而不知道这次客户真正想问什么。
老王对着屏幕发呆，这叫什么现象来着？
🌟 信噪比下降。
AI 记住了太多噪音，反而找不到信号——不是记性差了，是噪音太多把信号盖住了。
03. 上下文窗口不是硬盘
很多产品经理会犯一个直觉错误：上下文窗口越大越好。
这个直觉对了一半。
上下文窗口不是硬盘——不是塞多少存多少。上下文窗口是工位。你可以在工位上放东西，但放太多，工位就乱了，人就找不到工具了。
AI 也是这样。上下文窗口越大，有效信息密度反而可能下降，因为 AI 要在更多内容里找重点。
老王面对的是一个新问题：
🌟 AI 不是记不住，是装不下了。
04. 扩大工位 vs 智能收纳
当时摆在他面前的有两条路。
第一条：把工位继续扩大。
买更大上下文的模型。Claude Sonnet 4.6 1M 上下文，够大了吧？
现实是：上下文越大，单次 token 消耗越高。1M 上下文跑一次，成本是 128K 上下文的约 8 倍。更关键的是：大上下文本身不能解决信息筛选问题——AI 有了更多空间，反而更难从海量历史里快速定位到真正相关的那几段。很多测试里，200K 上下文的 AI 在长对话后半段的表现，反而不如专注处理近期内容的 32K 模型。
第二条：给工位装一个智能收纳系统。
不是扩大空间，而是让空间始终保持最优状态——把不重要的东西收起来，把重要的东西放在手边。
🌟 这就是 ContextCompressor（上下文压缩器）的核心思路。
05. ContextCompressor：一个工位收纳系统
ContextCompressor 是 hermes-agent 里内置的一个组件。名字很直白：把上下文压缩一下。
它的目标不是「记住更多」，而是「让上下文始终保持最优体量」。
打个比方：
-
记忆系统像是一个 档案室（长期存储，冷备） -
ContextCompressor 像是一个 桌面整理器（随时保持工作台干净）
档案室里可以存很多东西，但你在工位上工作时，桌上只能摊开当前要用的。ContextCompressor 做的是：定时把桌面上的东西分类，能收的收，能缩的缩，保证手边始终有空间。
06. 🌟 Hermes 的五步整理术
第一步：先扫一遍，把不重要的东西拿掉。
工具执行结果（tool result）是最占空间的内容。ContextCompressor 先把那些超过 200 字符的旧工具输出替换成占位符——
[Old tool output cleared to save context space]
这一步不需要调用 LLM，完全是字符串操作，零成本。
第二步：保护头部。
系统提示词（system prompt）和第一轮对话，绝对不动。这是 AI 的「工作手册」和「第一现场」，剪掉就彻底乱了。
第三步：保护尾部，按预算来。
最近发生的事最重要。ContextCompressor 用** Token 预算**而不是固定条数来保护尾部：
-
上下文 200K 的模型，尾部保留约 20K tokens -
上下文 8K 的模型，尾部保留约 800 tokens
自适应——大上下文有大空间，小上下文有小空间，但策略一致。
第四步：中间部分，找 LLM 做摘要。
这是有损压缩的核心。
中间那些「既不是最新、也不是最重要的」的对话，让一个小模型（便宜、快速）生成一段结构化摘要：
## Goal用户要做什么## Progress / Done已完成的工作（包含具体文件路径、命令、结果）## Key Decisions做过的关键决策及原因## Relevant Files读/改/写过的文件## Next Steps下一步要做什么## Critical Context具体的数值、错误信息、配置参数摘要保留了有价值的信号，丢弃了无价值的噪音。
第五步：如果要压缩第二次，迭代更新。
对话继续进行，再次触发压缩时，LLM 不是从零摘要，而是在上一份摘要的基础上更新。给它的 prompt 里直接带上上一份摘要，让它做三件事：
-
把「进行中」移到「已完成」 -
把「新进展」追加进去 -
把「已经过时」的信息删掉
举个例子：上一份摘要写着「Goal: 帮用户查物流 → In Progress: 正在查订单#7823」，第二轮压缩后变成「Goal: 帮用户查物流 → Done: 已查到，预计周三到达 → New: 用户还问了发票问题，暂未处理」。
🌟 这意味着：摘要不是每次清零重写，而是像滚动日志一样持续更新。历史不会丢失，只是换了一种更紧凑的载体存在。
07. 🌟 一个细节：工具调用不能截断
🌟 这是整个压缩系统里最危险的地方。
AI Agent 的对话里有大量的工具调用：用户说「帮我查一下订单」，AI 调用 order_query工具，工具返回结果。这是一对一的。
如果压缩把中间的 tool_result截掉了，但保留了这轮对话开头的 tool_call，API 会报错：
No tool call found for function call output with call_id xxxContextCompressor 在压缩前做了配对完整性检查：
-
如果一个 tool_call 找不到对应的 tool_result → 插入空 stub result -
如果一个 tool_result 找不到对应的 tool_call → 直接删掉
同时，压缩边界会智能对齐——如果边界落在工具调用的中间，会自动往外扩，确保不切断配对。
08. 🌟 上线之后
老王配置完 ContextCompressor，对话日志里出现了这样一条：
[Context compression triggered (95000 tokens >= 80000 threshold)][Summarizing turns 5-47 (42 turns), protecting 3 head + 28 tail messages][Compressed: 54 -> 17 messages (~47000 tokens saved)]上下文从 54 条消息压缩到 17 条，节省了约 47K tokens。
一个月后的数据：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
💡 计算前提：实际费用因模型、计费方式和对话长度差异较大，此处取典型值示意，重点看压缩前后的相对降幅。
09. 记忆和压缩，一枚硬币的两面
记忆系统解决的是「AI 记不住历史」的问题——把值得长期保存的东西，存到专门的记忆库，每次对话按需调取。
ContextCompressor解决的是「AI 上下文太重」的问题——在对话进行中，把不再需要的东西压缩清理，让 AI 始终在一个清爽的工作台上运转。
一个是往里存，一个是往外清。
但两者服务的其实是同一个目标：
🌟 让 AI 每次回复，都是基于正确的上下文。
10. 两者怎么配合
实际落地时，有几个经验：
1. 压缩阈值不是越高越好。
hermes-agent 默认阈值是上下文长度的 50%——用到一半就压缩。这比 Claude Code 的 85% 低很多。
老王踩过坑：阈值设到 80% 时，压缩触发时已经太晚了，API 已经报了 413 错误，压缩变成了「亡羊补牢」。提前压缩才是正确的策略。
2. 摘要模型可以比主模型便宜。
压缩不需要调用最好的模型，用便宜的模型（如deepseek-V3.2）或者自己部署的开源模型（如qwen_v3_32b）做摘要即可。hermes-agent 支持单独配置 summary_model_override，这是成本优化的关键。
3. 记忆系统和 ContextCompressor 不是替代关系，是互补关系。
Mem0 负责「客户是谁、有什么偏好、发生过什么」——这是要长期记住的。ContextCompressor 负责「当前这轮对话里，哪些历史是噪音」——这是要实时清理的。
🌟 两者一起用，才是完整的工作台 + 档案室系统。
11. 🌟 一张表说清楚：什么时候用什么
实际落地时，很多团队会问：这两个东西怎么配合？记住一个原则就够了：
「每个客户都要知道的」→ 记忆系统。
「这轮对话里用完就扔的」→ ContextCompressor。
具体来说：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
一个实操技巧：用 ContextCompressor 处理「过程」，用记忆系统处理「结论」。每次对话结束后，把压缩摘要里的关键结论（比如「用户要求赔偿」「承诺了周三到货」）手动或自动写进 Mem0，这些才是真正值得长期记住的东西。