面向LLM智能体的确定性折叠：无需LLM压缩的连续性

我刚刚开源了 Context Warp Drive，这是一个面向LLM智能体的连续性引擎。仓库地址：https://github.com/dogtorjonah/context-warp-drive 目前，业界处理长智能体时间跨度有两种糟糕的方式：直接使用1M-2M的上下文窗口；或者使用LLM总结旧消息（“压缩”）。 LLM摘要不一致，它们消耗额外的模型往返，静默地丢弃你的智能体所需的确切标识符（UUID、路径、哈希值），最糟糕的是，它们不断重写前缀——这会破坏你的提供商提示缓存。 这个库采取了一种不同的方法：确定性折叠。 随着智能体工作，较旧的上下文被折叠成确定性骨架。活跃上下文不是线性膨胀到天花板，而是锯齿形地——高效地建立起来，然后回落到一个干净的底部，而不会失去连续性。 为什么不直接使用1M token窗口？因为在长时间任务中，智能体携带的内容中95%目前并不需要。它是在大海里捞针，但巨大的上下文窗口迫使它携带所有的干草。更大的窗口提高了天花板，但它并没有移动模型推理最佳的地板。 长上下文评估一直在展示同样的事情——模型并不像营销数字所暗示的那样干净地使用巨大上下文：Lost in the Middle — 当所需信息被埋在长上下文的中间时，模型性能下降。RULER — 随着上下文长度和任务复杂度的增加，即使对于宣传为长上下文的模型，性能也大幅下降。Context Length Alone Hurts LLM Performance Despite Perfect Retrieval — 即使检索成功，长度本身也会损害性能。Intelligence Degradation in Long-Context LLMs — 即使输入仍然相关，模型也可能在超过关键上下文阈值后崩溃。 通过保持智能体的确定性折叠，配合温缓存和低上下文带，你可以使其保持敏捷、廉价和专注。你让干草留在后面，直到真正需要时才去取。 Context Warp Drive 的工作原理： 重生种子（Rebirth Seed）：使完全重置成为可能的连续性包。它携带最近的用户和AI消息、智能体正在积极工作和编辑的内容、其执行计划状态、从完整轨迹中保留的确切标识符、以及来自早期工作的情节上下文。它不是模糊的摘要——它是一个结构化的、确定性的快照，智能体可以从其中醒来并无缝继续。 缓存热追加（Cache-Hot Appending）：随着智能体工作，较旧的回合折叠成紧凑的带，追加到重生种子上。上下文随时间建立，但由于种子保持字节一致，你每回合只需支付廉价的缓存读取，而不是昂贵的全新输入。 锯齿重置（Sawtooth Reset）：你不能永远追加。当测量的输入压力达到你配置的天花板时，引擎执行完整的锯齿——上下文回退到新的重生种子，然后从低上下文底部继续循环。 零LLM折叠（Zero-LLM Folding）：原始聊天历史保留为真实来源，但模型看到的是确定性的紧凑视图。工具调用、路径、收据、保留的推理和确切标识符都被保留，无需请求另一个模型总结任何内容。 情节回忆（Episodic Recall）：当智能体重新触及重置之前的路径或概念时，引擎会将相关的折叠细节分页调回。智能体不携带所有干草——它在需要时才拉回来。 任务轨道（Task Rail）：我还包含了一个可移植的执行原语，名为 TaskRail。它将长周期计划状态保持在提示之外：步骤、进度、验收标准和可序列化的检查点。结合折叠和重生种子，智能体保持低上下文，同时仍然确切知道自己在多步骤工作流程中的位置。 仓库内容：核心折叠引擎，与提供商无关，支持 Anthropic content blocks、OpenAI 风格的 tool_calls 和 Gemini parts。Anthropic 提示缓存断点助手，以最大化读取命中。原始重生种子渲染器。模型感知的上下文预算解析器。折叠回忆和情节回忆（附带可选的 SQLite 情节存储）。可移植的 Task Rail 状态机。Gemini CLI 和 Codex CLI 折叠适配器。有许多可调节的旋钮，但核心哲学是一样的：将1M窗口用作安全余量，而不是作为操作频带。 （尚未在npm上发布——目前请从源代码安装。） 我已经在自己的多智能体编排栈中运行这个库几个月了，完全放弃了LLM压缩。区别是根本性的：智能体不再将上下文视为巨大的背包，而是开始将其视为分页工作集——小巧、热、可恢复，并且始终基于原始轨迹。