1. 为什么 AI 写作需要一个「结构化记忆」层做过 AI 写作工具的人大概都有过这种体验第一轮对话生成的内容还挺像样一旦进入多轮修改、章节扩写、风格统一这些环节模型就开始「失忆」——前面定好的人物设定、章节大纲、语气基调到第三轮就漂移了。你不得不把上下文一遍遍塞回去token 烧得飞快效果还不稳定。Goink 这个项目要解决的就是这个问题。它的核心思路很直接把 AI 写作过程中产生的所有结构化信息大纲、人物卡、章节摘要、风格约束从对话上下文里抽出来存进一个独立的记忆层让模型每次只拿它当下需要的那一小块。后端用 Go 扛住并发和状态管理前端用 React 做可视化的记忆编辑与写作界面。这套架构适合谁参考如果你正在做 AI 辅助写作、长文档生成、多轮内容协作类产品或者单纯想搞清楚「怎么让大模型在多轮任务里不丢状态」Goink 的分层设计值得拆开看一遍。它不是什么黑科技而是把工程上该做的脏活累活做扎实了。我先把它的整体骨架摆出来再逐层往下钻。2. 整体架构拆解三层分离的设计逻辑2.1 为什么是「Go 后端 React 前端 记忆层」这个组合先说说选型背后的考量这部分很多人容易忽略但恰恰决定了后期能不能扩展。Go 做后端核心原因是 AI 写作场景的请求特征大量并发的流式响应SSE、频繁的记忆读写、以及需要长时间保持的会话状态。Go 的 goroutine 模型在处理成千上万个并发流式连接时内存占用比传统线程模型低一个数量级。我实测过一个类似的流式接口单机 4 核 8G 跑 2000 个并发 SSE 连接Go 服务的内存稳定在 300MB 左右换成某些动态语言早就爆了。React 做前端是因为记忆层需要「可视化编辑」。用户要能看到大纲树、能拖拽调整章节顺序、能实时看到某个记忆块被哪些生成任务引用。这种强交互、状态频繁同步的场景React 的组件化和状态管理生态最成熟。记忆层独立是整个架构最关键的一刀。它不跟对话上下文混在一起而是作为独立的存储和检索单元存在。这样做的直接好处是模型上下文窗口只装「当前任务相关」的记忆而不是全部历史。2.2 三层之间的数据流我用一个具体的写作流程来说明数据怎么流动用户在 React 界面创建项目输入主题「一篇关于城市夜跑的中篇纪实」前端把主题发给 Go 后端后端调用模型生成初始大纲解析成结构化 JSON大纲的每个节点作为独立记忆块写入记忆层打上type: outline、parent_id、order等标签用户点击某一章开始写作前端请求该章节后端从记忆层检索「该章节节点 其父节点摘要 全局风格约束」三块记忆拼成精简 prompt 发给模型生成结果流式返回前端同时后端把这一章的摘要写回记忆层供后续章节引用这个流程里每次发给模型的上下文都是「按需检索」出来的而不是全量历史。这是 token 成本能降下来的根本原因。2.3 记忆层的三种记忆类型Goink 把记忆分成三类这个分类方式我觉得很实用直接抄记忆类型存储内容生命周期检索触发条件全局记忆风格约束、人称、禁忌词、整体基调项目级长期每次生成都带上结构记忆大纲树、章节层级、顺序关系项目级可编辑生成某章节时检索其路径片段记忆章节摘要、人物卡、关键情节章节级滚动更新生成相邻或引用章节时检索全局记忆是「宪法」结构记忆是「目录」片段记忆是「便签」。三者分开存检索逻辑才能各管各的不会互相污染。3. 记忆层的核心实现细节3.1 记忆块的数据结构设计记忆层的最小单元是「记忆块」Memory Block。我在参考这套设计时把它的字段精简成了下面这样你可以直接拿去用type MemoryBlock struct { ID string json:id ProjectID string json:project_id Type string json:type // global / outline / fragment ParentID string json:parent_id // 用于构建树形结构 Order int json:order // 同级排序 Content string json:content // 实际文本内容 Summary string json:summary // 压缩后的摘要用于检索 Tags []string json:tags // 自定义标签如人物场景 Version int json:version // 版本号支持回滚 UpdatedAt time.Time json:updated_at }这里有几个设计点值得说Summary 字段单独存而不是每次检索时现算。因为摘要生成也要调模型如果每次检索都算一遍延迟和成本都受不了。做法是内容更新时异步触发摘要重算检索时直接读 Summary。Version 字段是为了支持「记忆回滚」。写作过程中用户经常改主意比如把主角从「冷静」改成「冲动」这时候需要把受影响的记忆块批量回滚到某个版本。没有版本号这个操作做不了。Tags 用数组而不是枚举因为写作场景的标签太灵活了硬编码枚举会限制用户。用数组 前端筛选扩展性最好。3.2 检索策略怎么决定「这次生成该带哪些记忆」这是整个架构里最需要动脑子的地方。带少了模型失忆带多了 token 爆炸。Goink 用的是「路径检索 标签检索 相似度检索」三路合并路径检索生成第 3 章第 2 节时沿大纲树往上找把「根节点摘要 → 第 3 章摘要 → 第 3 章第 2 节节点」这条路径上的记忆全带上。这是必须的保证层级一致性。标签检索如果当前章节的标签里有「人物主角」就把所有带这个标签的人物卡记忆块带上。这解决了「人物设定漂移」的问题。相似度检索把当前章节的标题和已有片段记忆做向量相似度匹配取 top-3 带上。这是为了捕捉「隐性关联」比如写「雨夜追逐」时自动带上之前写过的「雨夜场景描写」记忆。三路结果合并去重后再按 token 预算截断。我一般给记忆部分留 2000-3000 token 的预算超了就按「路径 标签 相似度」的优先级砍。3.3 记忆的写入时机与压缩记忆不是生成完就立刻全量写入的那样记忆层会迅速膨胀。Goink 的策略是「分级写入」实时写入全局记忆和结构记忆用户一改就写因为这两类量小且关键延迟写入片段记忆的摘要生成完成后异步算不阻塞主流程批量压缩当某个父节点下的片段记忆超过阈值比如 20 条触发一次「向上压缩」把子节点摘要合并成父节点摘要这个压缩逻辑很关键。我踩过的坑是一开始不做压缩写到第 50 章时光记忆检索就要花 3 秒因为要遍历的片段太多了。加上向上压缩后检索时大部分情况只需要读父节点摘要速度回到 200ms 以内。提示压缩阈值不要设太小否则摘要会丢失细节也不要太大否则检索变慢。我实测 15-25 条之间比较平衡具体看你的章节粒度。4. 前后端协作的实操要点4.1 流式生成与记忆同步的并发处理AI 写作的生成是流式的SSE但记忆写入是离散的。这两者怎么协调是个容易出 bug 的地方。Goink 的做法是流式响应和记忆写入走两条独立的通道。前端通过 SSE 接收生成内容用于实时显示后端在生成完成的回调里触发记忆写入。这样即使记忆写入慢一点也不影响用户看到内容。但这里有个坑如果用户在生成过程中就点了「保存」而记忆还没写完会导致数据不一致。解决办法是给每个生成任务一个task_id前端保存时带上这个 id后端检查该任务的记忆写入是否完成没完成就返回「处理中」状态前端轮询等待。// 前端轮询记忆写入状态的简化逻辑 async function waitForMemorySync(taskId, maxRetries 10) { for (let i 0; i maxRetries; i) { const res await fetch(/api/task/${taskId}/memory-status); const data await res.json(); if (data.status synced) return true; await new Promise(r setTimeout(r, 500)); } throw new Error(记忆同步超时); }4.2 React 端的记忆树可视化前端最核心的组件是「记忆树」。它要同时满足两个需求展示大纲层级 允许直接编辑记忆内容。我用的是「受控树 虚拟滚动」的方案。树节点用递归组件渲染每个节点绑定一个记忆块。编辑时走「乐观更新」先在本地改再发请求失败了回滚。这样交互最跟手。虚拟滚动是必须的。一个中篇项目大纲可能有几百个节点不虚拟化直接卡死。我用的是react-window的FixedSizeTree实测 500 个节点滚动依然流畅。注意记忆树的编辑要加防抖。用户连续输入时不要每敲一个字就发一次请求300ms 防抖后再发。否则后端会被打爆而且记忆版本号会疯狂增长。4.3 后端的状态管理与并发安全Go 后端维护着每个项目的记忆状态。多个用户或同一用户的多个标签页可能同时操作同一个项目并发安全必须处理好。我的做法是记忆块级别加乐观锁。每个记忆块带version更新时带上客户端读到的 version后端比对不一致就拒绝并返回最新版本让前端合并。这比全局锁粒度细并发性能好很多。func (s *MemoryStore) UpdateBlock(blockID string, newContent string, expectedVersion int) error { s.mu.Lock() defer s.mu.Unlock() block, ok : s.blocks[blockID] if !ok { return ErrBlockNotFound } if block.Version ! expectedVersion { return ErrVersionConflict // 前端收到后拉取最新版重新合并 } block.Content newContent block.Version block.UpdatedAt time.Now() return nil }这里用sync.Mutex是因为单项目内的记忆块数量有限通常几百到几千锁竞争不激烈。如果是超大项目可以按parent_id分片加锁。5. 常见问题与排查技巧实录5.1 模型「失忆」的三种典型表现与定位表现一人物性格前后矛盾。定位方法检查生成该章节时人物卡记忆块是否被检索到。常见原因是人物卡的 Tags 没打对导致标签检索没命中。解决统一人物卡的标签规范比如强制用character:主角名格式。表现二章节之间情节断裂。定位方法检查上一章的摘要是否写入了记忆层。常见原因是摘要生成失败但没报错异步任务静默失败。解决给异步摘要任务加重试和告警。表现三整体风格漂移。定位方法检查全局记忆是否每次生成都带上了。常见原因是全局记忆的检索优先级被其他记忆挤掉了。解决全局记忆强制占预算不参与截断。5.2 记忆层膨胀的排查与治理记忆层膨胀的典型症状是检索变慢、token 成本上升、生成质量反而下降因为带了一堆无关记忆。排查步骤统计各类型记忆块的数量和平均大小找出异常增长的类型检查压缩任务是否正常执行看日志里有没有压缩记录检查是否有「孤儿记忆块」parent_id 指向已删除节点治理手段我整理成了一张表问题排查点治理手段片段记忆过多单父节点下片段数调低压缩阈值触发向上合并记忆块过大单块 token 数强制摘要化原文归档孤儿记忆parent_id 有效性定期清理任务重复记忆内容相似度写入前去重5.3 流式响应中断的记忆一致性处理流式生成最怕中途断网或用户关闭页面。这时候已经生成的部分内容要不要写入记忆我的策略是只有完整生成的内容才写入记忆。中断的生成标记为incomplete不进入记忆层但保留在草稿区供用户手动恢复。这样保证记忆层里全是「可信」的内容不会因为半截话污染后续生成。实现上后端在流式响应结束时才触发记忆写入中断时走defer里的清理逻辑把临时状态标记为废弃。提示如果你用的是 WebSocket 而不是 SSE要注意心跳检测。我遇到过连接假死但没触发 close 事件的情况导致记忆写入一直等不到完成信号。加个 30 秒心跳超时能解决。6. 几个我踩过的坑和优化心得第一个坑是摘要生成的模型选择。一开始我用的是和正文生成同一个大模型来算摘要结果成本和延迟都受不了。后来换成小模型专门做摘要质量够用成本降到十分之一。摘要这种任务不需要太强的模型别浪费。第二个坑是记忆检索的缓存。每次生成都重新检索一遍记忆重复计算很多。后来加了一层 LRU 缓存key 是「章节 ID 记忆版本号」命中率能到 70% 以上。注意缓存要跟着记忆版本号失效否则会读到旧记忆。第三个优化是把全局记忆做成「不可变」的。全局记忆一旦设定生成时只读不写这样可以用共享内存的方式传给所有生成任务不用每次拷贝。这个优化在高并发下效果明显。第四个心得是给记忆块加「引用计数」。记录每个记忆块被哪些生成任务引用过这样用户删除某个记忆块时能提示「该记忆被 3 个章节引用删除可能影响这些章节」。这个功能用户反馈很好避免了误删导致的连锁问题。这套架构跑下来一个中篇项目的记忆层大概占用 2-5MB 存储检索延迟稳定在 100-300ms相比全量上下文方案token 成本降了大概 60%。数字不算惊艳但胜在稳定可控不会随着项目变长而线性恶化。如果你也在做类似的东西建议先把记忆层的「分类 检索 压缩」这三件事做扎实剩下的都是水到渠成。 
长河君 · 2026/10/22 10:45:49 · 阅读 1.2k AI写作多轮失忆怎么破？Goink结构化记忆层架构拆解
1. 为什么 AI 写作需要一个「结构化记忆」层做过 AI 写作工具的人大概都有过这种体验第一轮对话生成的内容还挺像样一旦进入多轮修改、章节扩写、风格统一这些环节模型就开始「失忆」——前面定好的人物设定、章节大纲、语气基调到第三轮就漂移了。你不得不把上下文一遍遍塞回去token 烧得飞快效果还不稳定。Goink 这个项目要解决的就是这个问题。它的核心思路很直接把 AI 写作过程中产生的所有结构化信息大纲、人物卡、章节摘要、风格约束从对话上下文里抽出来存进一个独立的记忆层让模型每次只拿它当下需要的那一小块。后端用 Go 扛住并发和状态管理前端用 React 做可视化的记忆编辑与写作界面。这套架构适合谁参考如果你正在做 AI 辅助写作、长文档生成、多轮内容协作类产品或者单纯想搞清楚「怎么让大模型在多轮任务里不丢状态」Goink 的分层设计值得拆开看一遍。它不是什么黑科技而是把工程上该做的脏活累活做扎实了。我先把它的整体骨架摆出来再逐层往下钻。2. 整体架构拆解三层分离的设计逻辑2.1 为什么是「Go 后端 React 前端 记忆层」这个组合先说说选型背后的考量这部分很多人容易忽略但恰恰决定了后期能不能扩展。Go 做后端核心原因是 AI 写作场景的请求特征大量并发的流式响应SSE、频繁的记忆读写、以及需要长时间保持的会话状态。Go 的 goroutine 模型在处理成千上万个并发流式连接时内存占用比传统线程模型低一个数量级。我实测过一个类似的流式接口单机 4 核 8G 跑 2000 个并发 SSE 连接Go 服务的内存稳定在 300MB 左右换成某些动态语言早就爆了。React 做前端是因为记忆层需要「可视化编辑」。用户要能看到大纲树、能拖拽调整章节顺序、能实时看到某个记忆块被哪些生成任务引用。这种强交互、状态频繁同步的场景React 的组件化和状态管理生态最成熟。记忆层独立是整个架构最关键的一刀。它不跟对话上下文混在一起而是作为独立的存储和检索单元存在。这样做的直接好处是模型上下文窗口只装「当前任务相关」的记忆而不是全部历史。2.2 三层之间的数据流我用一个具体的写作流程来说明数据怎么流动用户在 React 界面创建项目输入主题「一篇关于城市夜跑的中篇纪实」前端把主题发给 Go 后端后端调用模型生成初始大纲解析成结构化 JSON大纲的每个节点作为独立记忆块写入记忆层打上type: outline、parent_id、order等标签用户点击某一章开始写作前端请求该章节后端从记忆层检索「该章节节点 其父节点摘要 全局风格约束」三块记忆拼成精简 prompt 发给模型生成结果流式返回前端同时后端把这一章的摘要写回记忆层供后续章节引用这个流程里每次发给模型的上下文都是「按需检索」出来的而不是全量历史。这是 token 成本能降下来的根本原因。2.3 记忆层的三种记忆类型Goink 把记忆分成三类这个分类方式我觉得很实用直接抄记忆类型存储内容生命周期检索触发条件全局记忆风格约束、人称、禁忌词、整体基调项目级长期每次生成都带上结构记忆大纲树、章节层级、顺序关系项目级可编辑生成某章节时检索其路径片段记忆章节摘要、人物卡、关键情节章节级滚动更新生成相邻或引用章节时检索全局记忆是「宪法」结构记忆是「目录」片段记忆是「便签」。三者分开存检索逻辑才能各管各的不会互相污染。3. 记忆层的核心实现细节3.1 记忆块的数据结构设计记忆层的最小单元是「记忆块」Memory Block。我在参考这套设计时把它的字段精简成了下面这样你可以直接拿去用type MemoryBlock struct { ID string json:id ProjectID string json:project_id Type string json:type // global / outline / fragment ParentID string json:parent_id // 用于构建树形结构 Order int json:order // 同级排序 Content string json:content // 实际文本内容 Summary string json:summary // 压缩后的摘要用于检索 Tags []string json:tags // 自定义标签如人物场景 Version int json:version // 版本号支持回滚 UpdatedAt time.Time json:updated_at }这里有几个设计点值得说Summary 字段单独存而不是每次检索时现算。因为摘要生成也要调模型如果每次检索都算一遍延迟和成本都受不了。做法是内容更新时异步触发摘要重算检索时直接读 Summary。Version 字段是为了支持「记忆回滚」。写作过程中用户经常改主意比如把主角从「冷静」改成「冲动」这时候需要把受影响的记忆块批量回滚到某个版本。没有版本号这个操作做不了。Tags 用数组而不是枚举因为写作场景的标签太灵活了硬编码枚举会限制用户。用数组 前端筛选扩展性最好。3.2 检索策略怎么决定「这次生成该带哪些记忆」这是整个架构里最需要动脑子的地方。带少了模型失忆带多了 token 爆炸。Goink 用的是「路径检索 标签检索 相似度检索」三路合并路径检索生成第 3 章第 2 节时沿大纲树往上找把「根节点摘要 → 第 3 章摘要 → 第 3 章第 2 节节点」这条路径上的记忆全带上。这是必须的保证层级一致性。标签检索如果当前章节的标签里有「人物主角」就把所有带这个标签的人物卡记忆块带上。这解决了「人物设定漂移」的问题。相似度检索把当前章节的标题和已有片段记忆做向量相似度匹配取 top-3 带上。这是为了捕捉「隐性关联」比如写「雨夜追逐」时自动带上之前写过的「雨夜场景描写」记忆。三路结果合并去重后再按 token 预算截断。我一般给记忆部分留 2000-3000 token 的预算超了就按「路径 标签 相似度」的优先级砍。3.3 记忆的写入时机与压缩记忆不是生成完就立刻全量写入的那样记忆层会迅速膨胀。Goink 的策略是「分级写入」实时写入全局记忆和结构记忆用户一改就写因为这两类量小且关键延迟写入片段记忆的摘要生成完成后异步算不阻塞主流程批量压缩当某个父节点下的片段记忆超过阈值比如 20 条触发一次「向上压缩」把子节点摘要合并成父节点摘要这个压缩逻辑很关键。我踩过的坑是一开始不做压缩写到第 50 章时光记忆检索就要花 3 秒因为要遍历的片段太多了。加上向上压缩后检索时大部分情况只需要读父节点摘要速度回到 200ms 以内。提示压缩阈值不要设太小否则摘要会丢失细节也不要太大否则检索变慢。我实测 15-25 条之间比较平衡具体看你的章节粒度。4. 前后端协作的实操要点4.1 流式生成与记忆同步的并发处理AI 写作的生成是流式的SSE但记忆写入是离散的。这两者怎么协调是个容易出 bug 的地方。Goink 的做法是流式响应和记忆写入走两条独立的通道。前端通过 SSE 接收生成内容用于实时显示后端在生成完成的回调里触发记忆写入。这样即使记忆写入慢一点也不影响用户看到内容。但这里有个坑如果用户在生成过程中就点了「保存」而记忆还没写完会导致数据不一致。解决办法是给每个生成任务一个task_id前端保存时带上这个 id后端检查该任务的记忆写入是否完成没完成就返回「处理中」状态前端轮询等待。// 前端轮询记忆写入状态的简化逻辑 async function waitForMemorySync(taskId, maxRetries 10) { for (let i 0; i maxRetries; i) { const res await fetch(/api/task/${taskId}/memory-status); const data await res.json(); if (data.status synced) return true; await new Promise(r setTimeout(r, 500)); } throw new Error(记忆同步超时); }4.2 React 端的记忆树可视化前端最核心的组件是「记忆树」。它要同时满足两个需求展示大纲层级 允许直接编辑记忆内容。我用的是「受控树 虚拟滚动」的方案。树节点用递归组件渲染每个节点绑定一个记忆块。编辑时走「乐观更新」先在本地改再发请求失败了回滚。这样交互最跟手。虚拟滚动是必须的。一个中篇项目大纲可能有几百个节点不虚拟化直接卡死。我用的是react-window的FixedSizeTree实测 500 个节点滚动依然流畅。注意记忆树的编辑要加防抖。用户连续输入时不要每敲一个字就发一次请求300ms 防抖后再发。否则后端会被打爆而且记忆版本号会疯狂增长。4.3 后端的状态管理与并发安全Go 后端维护着每个项目的记忆状态。多个用户或同一用户的多个标签页可能同时操作同一个项目并发安全必须处理好。我的做法是记忆块级别加乐观锁。每个记忆块带version更新时带上客户端读到的 version后端比对不一致就拒绝并返回最新版本让前端合并。这比全局锁粒度细并发性能好很多。func (s *MemoryStore) UpdateBlock(blockID string, newContent string, expectedVersion int) error { s.mu.Lock() defer s.mu.Unlock() block, ok : s.blocks[blockID] if !ok { return ErrBlockNotFound } if block.Version ! expectedVersion { return ErrVersionConflict // 前端收到后拉取最新版重新合并 } block.Content newContent block.Version block.UpdatedAt time.Now() return nil }这里用sync.Mutex是因为单项目内的记忆块数量有限通常几百到几千锁竞争不激烈。如果是超大项目可以按parent_id分片加锁。5. 常见问题与排查技巧实录5.1 模型「失忆」的三种典型表现与定位表现一人物性格前后矛盾。定位方法检查生成该章节时人物卡记忆块是否被检索到。常见原因是人物卡的 Tags 没打对导致标签检索没命中。解决统一人物卡的标签规范比如强制用character:主角名格式。表现二章节之间情节断裂。定位方法检查上一章的摘要是否写入了记忆层。常见原因是摘要生成失败但没报错异步任务静默失败。解决给异步摘要任务加重试和告警。表现三整体风格漂移。定位方法检查全局记忆是否每次生成都带上了。常见原因是全局记忆的检索优先级被其他记忆挤掉了。解决全局记忆强制占预算不参与截断。5.2 记忆层膨胀的排查与治理记忆层膨胀的典型症状是检索变慢、token 成本上升、生成质量反而下降因为带了一堆无关记忆。排查步骤统计各类型记忆块的数量和平均大小找出异常增长的类型检查压缩任务是否正常执行看日志里有没有压缩记录检查是否有「孤儿记忆块」parent_id 指向已删除节点治理手段我整理成了一张表问题排查点治理手段片段记忆过多单父节点下片段数调低压缩阈值触发向上合并记忆块过大单块 token 数强制摘要化原文归档孤儿记忆parent_id 有效性定期清理任务重复记忆内容相似度写入前去重5.3 流式响应中断的记忆一致性处理流式生成最怕中途断网或用户关闭页面。这时候已经生成的部分内容要不要写入记忆我的策略是只有完整生成的内容才写入记忆。中断的生成标记为incomplete不进入记忆层但保留在草稿区供用户手动恢复。这样保证记忆层里全是「可信」的内容不会因为半截话污染后续生成。实现上后端在流式响应结束时才触发记忆写入中断时走defer里的清理逻辑把临时状态标记为废弃。提示如果你用的是 WebSocket 而不是 SSE要注意心跳检测。我遇到过连接假死但没触发 close 事件的情况导致记忆写入一直等不到完成信号。加个 30 秒心跳超时能解决。6. 几个我踩过的坑和优化心得第一个坑是摘要生成的模型选择。一开始我用的是和正文生成同一个大模型来算摘要结果成本和延迟都受不了。后来换成小模型专门做摘要质量够用成本降到十分之一。摘要这种任务不需要太强的模型别浪费。第二个坑是记忆检索的缓存。每次生成都重新检索一遍记忆重复计算很多。后来加了一层 LRU 缓存key 是「章节 ID 记忆版本号」命中率能到 70% 以上。注意缓存要跟着记忆版本号失效否则会读到旧记忆。第三个优化是把全局记忆做成「不可变」的。全局记忆一旦设定生成时只读不写这样可以用共享内存的方式传给所有生成任务不用每次拷贝。这个优化在高并发下效果明显。第四个心得是给记忆块加「引用计数」。记录每个记忆块被哪些生成任务引用过这样用户删除某个记忆块时能提示「该记忆被 3 个章节引用删除可能影响这些章节」。这个功能用户反馈很好避免了误删导致的连锁问题。这套架构跑下来一个中篇项目的记忆层大概占用 2-5MB 存储检索延迟稳定在 100-300ms相比全量上下文方案token 成本降了大概 60%。数字不算惊艳但胜在稳定可控不会随着项目变长而线性恶化。如果你也在做类似的东西建议先把记忆层的「分类 检索 压缩」这三件事做扎实剩下的都是水到渠成。