ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

m[0]/m[1]双层缓存布局:Magic Context实现零缓存失效的终极设计

m[0]/m[1]双层缓存布局:Magic Context实现零缓存失效的终极设计 m[0]/m[1]双层缓存布局Magic Context实现零缓存失效的终极设计【免费下载链接】magic-contextUnbounded context. Memory that manages itself. One session, for life. The hippocampus for coding agents, part of CortexKit.项目地址: https://gitcode.com/gh_mirrors/mag/magic-context长会话 AI 编程为什么账单越来越高Magic Context 是 CortexKit 家族的编码智能体海马体它为 OpenCode、Pi、Claude Code 等宿主管理上下文窗口核心难题就一个字贵。大模型厂商会缓存提示词前缀缓存命中时计费可低至 10%但只要前缀中任何一个字节变了后面全部按全价重算。而一个每轮都在改历史的上下文管理器恰恰是缓存杀手。Magic Context 的答案是 m[0]/m[1] 双层缓存布局——用冻结基线 易变增量两个消息槽位让绝大多数轮次做到零缓存失效。一、问题的本质LLM 缓存为什么这么脆弱缓存计费规则很简单提示词前缀逐字节相同 → 命中缓存按折扣价计费前缀中任何一个字节变化 → 从那一点开始全部按全价重算也就是说一个上下文管理器如果每轮都压缩历史、删工具输出、注入新记忆它省下的 token 会远小于它摧毁的缓存——净效果是越管理越贵。这是 m[0]/m[1] 设计要解决的核心矛盾。二、双层布局m[0] 是冻结的基线m[1] 是滚动的增量Magic Context 把压缩后的历史渲染成对话开头的两条合成 user 消息而不是传统的一条槽位角色内容变化频率m[0]累计基线冻结类似 system 提示词项目文档、基线用户画像、按衰减曲线渲染的历史摘要常规轮次从不变化m[1]易变增量上次 m[0] 重建后新增的记忆、用户画像补充、最新全保真历史摘要有新内容时才变化两者构成system m[0] m[1]前缀其中只有会话尾部原始消息每轮都在变。关键细节m[1] 为空时也渲染一个最小占位符而非空消息——这是为了保证厂商缓存断点结构稳定。 增量记忆通过水位线watermark接入只有 ID 大于上次物化时最大 ID 的新记忆才会出现在 m[1]老记忆永远不触发重建。三、失效分级体系SOFT / SOFT / HARD 三级缓存语义不是所有缓存失效都等价。Magic Context 把每一次变换路径transform pass精确归类为三级这是零失效设计能自洽的关键SOFT纯命中无失效无新内容的 defer 轮次。m[0] 与 m[1]逐字节重放整个前缀保持缓存只有会话尾部在动。这是绝大多数轮次的稳态。SOFTm[1] 失效execute 轮或历史发布时m[1] 重渲染新的摘要/记忆m[0] 保持字节不变。缓存失效点发生在 m[1] 断点system m[0]大前缀仍然命中。HARDm[0] 折叠mustMaterialize触发时m[1] 被折叠进新的衰减基线 m[0]m[1] 重置为占位符。整个前缀重建——但只发生在厂商缓存本来就死了换模型、空闲超时、system 提示词变更或 m[0] 内容真正改变时属于免费重建。四、零失效的秘诀哪些事件故意不触发重建m[0] 的重建触发列表是刻意设计过的更值得看的是不触发清单事件走哪条路为什么不触发 m[0] 重建新增历史摘要compartmentm[1] 增量后台例行工作不能 bust 基线会话内新记忆m[1] 水位线追加式写入走增量记忆更新/归档m[1] 变更日志渲染为memory-updates增量项目文档哈希变化等下次自然 HARD文档编辑单独不驱逐前缀会话空闲超过 TTL触发免费重建厂商缓存已失效重建无成本还有一条压力兜底规则m[1] 相对 m[0] 增长过大时尺寸比例、约 20% 历史预算的绝对上限、或记忆变更数量过大强制触发一次折叠防止马拉松会话攒出过大的增量。历史衰减的重新分层按年龄、重要度、预算压力给摘要降档 P1→P5只发生在 HARD 折叠时——SOFT 轮次永远不改 m[0] 字节这是写进架构契约的硬不变量。五、一次典型会话里发生什么轮次 1~N SOFT 纯命中前缀整段缓存只按缓存价计费 第 N1 轮 历史摘要发布 → SOFTm[1] 重渲染m[0] 仍命中 换模型/超时HARD 折叠m[1] 并入衰减后的新 m[0]免费重建 下一轮起 回到 SOFT 稳态……在稳定工作会话中m[0] 可以数小时乃至数天保持字节不变提示词缓存贯穿整个会话大前缀始终享受缓存 token 折扣价。六、值得细读的源码与文档想深入 m[0]/m[1] 实现推荐按以下路径阅读架构总览与缓存布局契约ARCHITECTURE.mdm[0]/m[1] cache layout 一节有完整的触发/不触发清单面向用户的缓存架构详解cache-architecture.md核心渲染与物化逻辑renderM0/renderM1/materializeM0/mustMaterializeinject-compartments.tsPi 宿主的镜像实现inject-compartments-pi.ts确定性衰减渲染器按年龄/重要度/预算压力选档decay-render.ts缓存 TTL 假设的配置参考configuration.mdcache_ttl一节七、总结把缓存失效变成一门可预算的算术m[0]/m[1] 双层布局的精髓不是永不失效而是让失效只发生在免费或必要的时刻例行工作新摘要、新记忆、画像更新全部走 m[1] 增量SOFT 失效点可控延迟任务只搭车下一次已注定发生的前缀重建从不自己发起失效真正的 m[0] 重建只对齐厂商缓存已死的时刻——换模型、超时、外部编辑衰减降档只在 HARD 折叠时批量执行避免小步频繁重写前缀。对新手来说理解这套设计只需记住一句话m[0] 像只读的文件系统m[1] 像它的日志回放——前缀稳定成本才稳定。这也是 Magic Context 能让一个会话活一辈子而不破产的底层原因。【免费下载链接】magic-contextUnbounded context. Memory that manages itself. One session, for life. The hippocampus for coding agents, part of CortexKit.项目地址: https://gitcode.com/gh_mirrors/mag/magic-context创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表