Maka Agent如何处理超长对话LLM Compaction历史压缩机制完全剖析【免费下载链接】makaApache Maka (Incubating) is a local-first AI agent workspace. Model messages, tool calls, tool results, permission decisions, and termination events are recorded as an append-only log.项目地址: https://gitcode.com/GitHub_Trending/mak/maka如果你和 AI Agent 连续工作几个小时对话历史很快就大到模型装不下了。Maka LLM Compaction 历史压缩机制正是为这个问题而生的MakaApache 孵化器项目是一个本地优先local-first的 AI Agent 工作区它把模型消息、工具调用、权限决策和终止事件都记录为只追加append-only的日志再通过一套投影式的上下文压缩让超长对话可以无限继续同时不丢失任何一条真实历史 为什么超长对话会撑爆模型和 Agent 协作时每一轮都会往上下文里堆东西你贴的需求、模型的回答、命令输出、文件 diff……一个两小时的会话日志里可能有几千条事件。但模型的上下文窗口context window是有限的下一轮调用既不需要、也装不下全部历史。它真正需要的只是 当前目标是什么✅ 已经完成了什么、哪些决策不能推翻 当前文件与运行状态⏭️ 接下来该做什么 摘要不够时去哪里找原始事实最危险的做法是生成一段摘要然后删掉原始历史——短期省了上下文长期却让摘要变成无法核验的第二真相。Maka 的设计哲学是让 LLM 忘记但不让系统丢失历史。核心思想Compaction 是投影不是删除Maka 用数据库思维来分层管理三者各司其职、互不混淆层保存什么是否事实源允许丢细节吗Runtime Events Log事件日志已发生的真实事实✅ 是❌ 永不删改Compact Checkpoint压缩检查点一段历史前缀的结构化摘要 覆盖边界否是持久化投影✅ 有损但可重建Provider Request模型请求本次调用实际看到的内容否是临时投影✅ 可裁剪一句话概括日志回答发生过什么检查点回答下次推理怎么继续模型请求回答这一次要看什么。就像数据库的物化视图materialized view——它可以让读取变快但永远不能反过来宣称底层的源日志不再重要。这个设计的完整推导可以阅读项目自带的架构文档llm-compaction-events-log-projection-draft.zh-CN.md。触发压缩的四种时机Maka 只有一套压缩机制由统一的水位线high-water判定触发当预估的下次请求 token 数越过上下文窗口 − 预留量时就发出同一条 Compact 指令。具体有四类触发方⚡Turn 开始前pre-turn下一轮请求预计超限提前压缩Turn 进行中mid-turnAgent 循环执行到一半发现容量不够Provider 溢出恢复真实收到模型的 overflow 报错后补救️手动触发桌面端的sessions:compact命令——它也是一个正式的 Runtime 操作有自己的 Run 生命周期而不是偷偷改数据库四种触发共用同一个规划器和同一套检查点事务唯一的区别只是谁喊的停。水位线算法位于 history-compaction.ts 的exceedsHighWater中已知窗口大小时预留四分之一上限 16,384 tokens作为输出空间。安全前缀绝不从中间切开对话压缩前Maka 要先选出最大的一段安全前缀来折叠。切分规则非常讲究✅ 切点必须落在一个完整、不可变的事件上流式快照这种半成品会先排除 绝不切开Tool Call / Tool Result 配对——这对模型来说是协议整体拆开会留下悬空的结果 当前轮次正在使用的固定事件保持原样留在未压缩尾巴里这段逻辑在 history-compaction.ts 的selectSafeCompactionPrefix中实现。如果找不到安全切点比如剩下的只有一对原子工具调用系统会显式报告预算耗尽而不是硬着头皮发出一个畸形请求。LLM 只负责怎么概括不负责能不能用这是整个机制里最容易被误解的一点LLM 是投影值的生成器不是投影的裁决者。摘要提示词要求保留六类信息目标、已完成/进行中事项、关键决策、下一步、以及包含精确路径、函数名、命令和错误的关键上下文摘要输出上限 4,096 tokens见 history-compact-summarizer.ts。但以下问题全部由确定性的 Runtime 代码回答LLM 插不上手哪些事件属于被覆盖的前缀源事件的 SHA-256 摘要source digest是什么检查点能否替代当前日志必须前缀长度、边界 ID、digest 三者全部匹配哪些最近的原始事件必须原样保留滚动检查点不反复总结整个世界长会话会多次越过水位线。如果每次都把全部旧历史重新丢给 LLM 总结压缩本身会变成越来越贵的请求旧事实还会被反复改写。Maka 用滚动检查点rolling checkpoint解决第 N 个检查点summary S(事件 0..k) 新增淘汰事件事件 k1..m 第 N1 个检查点summary S(上一份摘要, 事件 k1..m)也就是说summarizer 只看上一份摘要 新增的旧事件已被覆盖的原始事件不会再次发给模型。每个检查点还记录previousCheckpointId形成谱系链防止任何迟到的写入乱序覆盖。检查点的持久化结构与校验在 history-compact-checkpoint.ts 中定义。 对 Codex 订阅用户还有一个进阶玩法Maka 可以直接调用 Codex 服务端的远程压缩schema V3把 provider 原生的加密 compact state 存为检查点切换模型或连接时会自动拒绝并回退到原始历史重新投影——见 openai-codex-history-compactor.ts。失败时怎么办宁可少看也不看假历史压缩横跨 token 估算、LLM 调用、持久化写入和多重校验失败是正常路径。Maka 的失败语义非常一致核心只有一句话Fail open to a safe source-derived context, not to an invented summary.回退到安全的源数据上下文而不是编造一份摘要。典型策略摘要生成失败 → 不记录检查点只保留能装下的原始历史尾巴并写入一条可见的失败诊断滚动更新失败 → 复用旧检查点但绝不扩大它的覆盖声明检查点与源日志 digest 不匹配 → 直接拒绝从原始事件重新投影检查点超出当前预算 → 不回放历史上合法不等于现在可用这套十不式的架构不变量在 llm-compaction-events-log-projection-draft.zh-CN.md 的当前必须保护的架构不变量一节有完整列表。代价与边界诚实说明这种设计不是免费的Maka 文档自己列得很清楚存储不会变小源日志完整保留节省的只是推理上下文不是磁盘维护成本更高要维护 coverage、digest、谱系、策略闸门和恢复投影摘要有损误差会累积滚动摘要每次都有轻微损失好在原始日志永远允许从更早的水位线重新生成投影换来的是任何投影都可以被丢弃、校验、或从日志重建——压缩永远是投影而不是隐蔽的数据破坏。延伸阅读源码地图 ️想深入源码的同学按这个顺序读效率最高水位线与安全前缀history-compaction.ts预算与回放策略context-budget.ts、context-budget-policy.ts检查点 schema 与校验history-compact-checkpoint.tsLLM 摘要器history-compact-summarizer.ts请求投影主链ai-sdk-backend.ts完整设计文档llm-compaction-events-log-projection-draft.zh-CN.md、llm-compaction-events-log-projection-draft.md总结Maka 处理超长对话的答案不是把聊天压得更短而是回答了一个更根本的问题如何在保留完整事件事实的前提下为下一次模型决策计算一个更小的继续视图。日志存事实、检查点存投影、请求存当下——三者生命周期不同、权威边界清晰。这也是它作为本地优先 AI Agent 工作区能长期可靠运行的地基哪怕压缩偶尔失败你面对的也只是一份暂时少看了一些旧细节的上下文而绝不是一份被篡改的历史。【免费下载链接】makaApache Maka (Incubating) is a local-first AI agent workspace. Model messages, tool calls, tool results, permission decisions, and termination events are recorded as an append-only log.项目地址: https://gitcode.com/GitHub_Trending/mak/maka创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考