如何防止长对话耗尽整个上下文窗口？
摘要
一位用户分享了一个自定义的插件SDK钩子，该钩子逐渐压缩较早的轮次，同时保留最近的轮次不压缩，以防止在长时间OpenClaw会话中上下文窗口耗尽，将重新发送的上下文减少了80%。
我一直在运行长达数小时的OpenClaw会话，上下文窗口填满是我的主要痛点。原生压缩机制启动较晚（接近阈值时），而且是全有或全无——一旦它进行总结，较早的细节就丢失了。我真正想要的是：在每一轮中*逐步*压缩，但保留最后几轮完全不压缩，这样代理就不会丢失它正在进行的线程。我最终编写了一个自定义的Plugin SDK钩子，放在before_prompt_build上，它可以将较早的轮次折叠成压缩的片段视图，同时逐字保留最后的轮次。在长时间会话中，它将重新发送的上下文减少了约80%，且没有让代理丢失对早期轮次的追踪。对于长时间运行会话的用户，有两个问题：1. 你依赖原生压缩，还是自己实现上下文管理？2. 有没有人找到合适的“保留N轮不压缩”的数字？我默认为4，但感觉这取决于工作负载。（如果有用，钩子在这里——MIT核心：https://github.com/compresh/compresh-mcp ——但我主要好奇其他人是如何处理这个问题的。）
相似文章
如何在重新启动 llama.cpp 后处理长上下文会话？
用户提出在 llama.cpp 中为长上下文会话实现自动缓存机制，以避免重启后的重复预填充，提升在较慢硬件上的可用性。
我是如何解决持续运行的Anthropic智能体循环中上下文窗口膨胀问题的（Opus + Sonnet架构）
一位开发者分享了一种架构模式，用于管理持续运行的Anthropic智能体循环中的上下文窗口膨胀问题，采用KV缓存、动态工具模式加载，以及通过Claude 3.5 Sonnet和Claude 3 Opus解耦执行器与顾问角色。
不要轻信大上下文窗口
分析表明，LLM 声称的大上下文窗口具有误导性，因为有效注意力在约 10 万 token 时会下降。为开发者提供实用建议：通过使用工件（artifacts）和切换（handoffs）将会话保持在“智能区”。
你的 Openclaw 使用什么记忆？
一位开发者讨论了使用 Engram 为 Hermes 代理构建自定义记忆插件，该插件将新信息与现有记忆进行协调，以避免过时和重复，并向 OpenClaw 社区询问他们记忆使用的情况。
使用llama-server自托管？修复每次轮次中提示缓存重载的问题
一份故障排除指南展示了将OpenClaw的contextInjection设置从 'always' 更改为 'continuation-skip' 后，如何解决使用 llama-server 时每次对话都会重载提示缓存的问题，从而在长时间会话中实现100倍的加速。