一个非技术PM的3个月AI Memory实践复盘：记忆断层，App如何保住上下文？

当 AI 开始参与越来越长的任务链，真正稀缺的往往不再是“会不会回答”，而是“能不能记住为什么这样回答、下次还能不能沿着同一条思路继续做下去”。这也是为什么一篇看似个人方法论的 AI Memory 复盘，对 App 开发、产品设计和增长团队会有直接启发：在更复杂的链路里，【智能传参】的本质，其实就是保住上下文。

新闻与环境拆解

这不是技术炫技，而是一个产品人对“记忆断层”的自救

这篇材料的起点非常朴素。作者并不是为了追前沿框架，才去搭建一套个人 AI 记忆系统，而是因为遇到了一个很具体的问题：每天吸收很多信息，几天以后却常常忘掉“自己为什么会做这个判断”。这个问题看起来像个人学习效率问题，本质上却击中了 AI Memory 的核心场景——信息可以被记录，但判断脉络、决策原因和长期模式很容易在时间中断裂。

作者把自己真正想保存的内容拆成了几类：为什么会做这个决定、当时如何理解这个问题、过去类似情况怎么处理、最近反复出现的情绪和行为模式到底说明什么。这一点很关键。因为它说明 AI Memory 关注的并不是“素材存得够不够多”，而是“系统能不能把人的判断过程持续保留下来”。

从产品视角看，这也是 AI Memory 和普通笔记工具、聊天工具的根本区别。普通笔记更像信息仓库，聊天工具更像陪伴式界面，但都很难解决“跨时间、跨会话、跨任务之后，上下文还能不能连起来”的问题。作者后来给这个问题下的定义很准确：不是缺一个记录工具，而是缺一个能持续“记住我自己”的系统。

RULbot 的底层不复杂，关键在“分层压缩”

材料里这套系统后来被命名为 RULbot，底层工具并不神秘：输入层在飞书里按标签记录内容，存储层同步到 Obsidian 文件夹，分析层调用 Claude 做结构化分析，复用层把分析方法写成固定文档供反复调用。真正有价值的，不是用了哪些工具，而是后面补上的压缩结构。

作者一开始只是想把内容存下来，但很快发现，如果没有压缩层，内容越记越乱。于是他把记忆结构拆成了四层：每日日志、十日报告、月度总览、人生成长报告。短期信息先完整保留，随着时间拉长，再一层层压成更高层的判断。这其实已经非常接近很多 Agent 记忆系统采用的分层思路：短期记忆承载原始上下文，长期记忆保留归纳后的模式，技能层再进一步沉淀可复用方法。一个非技术PM的3个月AI Memory实践复盘 Agentic AI基础设施实践经验系列（三）：Agent记忆模块的最佳实践

从行业资料看，这种做法并不是个例。像 Memory Bank、文件系统式 AI Memory、分层长期记忆实践，都在强调同一个逻辑：不是把所有上下文一次性塞给模型，而是要通过摘要、结构和阶段性更新，把“有用的模式”持续留下来。AI编程着突然失忆了：如何实现AI长期记忆？ 用文件系统重构AI记忆：个人操作系统设计实践 这也说明，作者用“土办法”踩出来的路径，其实很接近主流 Memory 系统的收敛方向。

真正让作者理解 Memory 的，不是架构图，而是“手工补丁”

这篇材料最有意思的地方，是作者并不是靠读框架图理解 AI Memory，而是被 Claude 没有跨会话记忆这件事逼出来的。系统搭到第三周时，他遇到一个很现实的问题：今天聊得很深入，明天再开一个新窗口，模型还是得重新认识自己。前面做过的总结，像是没有真正积累下来。

作者后来的补丁很“笨”，但也非常真实：既然模型本身记不住，那就把月度总览和阶段总结文件手工放进每次对话前的上下文里。严格来说，这并不是什么技术突破，但效果却很明显——Claude 给出的建议开始更贴近作者的真实状态，而不是谁都能套上的通用表达。

这段经历之所以重要，是因为它触到了 AI Memory 的一个核心判断：模型不是记忆体，外部文档才是。很多 AI 产品喜欢强调“我记住你了”，但真正可靠的记忆往往不是隐藏状态，而是被写到外部、可以被人看见、编辑、校正、追溯的持久载体。行业里很多 Memory 实践也都在朝这个方向收敛：将知识、上下文和阶段摘要写入文件系统、结构化存储或可查询外部记忆层，而不是完全寄托于模型内部状态。用文件系统重构AI记忆：个人操作系统设计实践 上下文记忆——AI Agent native 的任务存储机制

它和 Hermes、OpenClaw 为什么会是同一类问题

作者后来在看 Hermes Agent 和 OpenClaw 的资料时，发现自己这套系统和它们的设计思路高度同构。这种“同构感”并不来自某个功能细节，而来自几个底层共识。

第一，分层记忆几乎是必然收敛。作者的系统里是每日日志、十日报告、月度总览、人生成长报告，信息不断上压；而 Hermes 和 OpenClaw 虽然命名不同，但本质也都在处理同一个问题：什么内容留在当前会话，什么沉淀为阶段记录，什么进入长期记忆，什么再进一步转化为可调用经验。很多 Agent 记忆架构资料同样把记忆拆为短期记忆、外部记忆、长期记忆、语义记忆或技能层，说明“分层”不是高级玩法，而是可用性的前提。AI学习笔记：Agent的记忆机制 收藏！Agent记忆系统四层架构详解

第二，外部文档比隐藏状态更可靠。作者越来越依赖 Markdown 文档，不是为了工程感，而是因为它朴素、透明、可回看、可修改、不容易被平台锁死。这个判断放在产品层面非常关键。和“系统说它记住了”相比，用户更容易信任“我能看到它到底记了什么”。所以 AI Memory 的透明度并不是附加项，而是信任基础。

第三，Skill 是记忆的高级形态。作者最开始只是把日志分析流程写成可复用文档，后来越来越意识到，真正有价值的记忆不是“存过什么”，而是“下次怎么做”。这和很多 Agent 系统把 skill、tool use、workflow template 当作长期能力资产的思路是同一回事。记忆如果只停留在信息归档，价值是有限的；一旦变成方法沉淀，才更接近生产力系统。

作者最后得到的四个判断，几乎都是 AI 产品要面对的真问题

材料最后给出了四个判断，几乎每一个都值得 AI 产品团队认真看。第一，AI Memory 的核心不是“多记”，而是“会压”。这点非常重要，因为原始信息量一大，真正稀缺的不是存储容量，而是压缩能力。什么该留、什么该丢、什么是后续判断最有用的模式，这些都不是机械问题，而是判断问题。

第二，透明度不是附加项，而是信任基础。尤其和人的长期信息相关时，如果系统只说“我记住了”，却不告诉用户“记住了什么、为什么记、能不能改”，用户很难真正放心。这对面向个人、团队、企业的 Memory 产品都一样。

第三，Skill 比工具清单更能代表长期能力。很多人会下意识用“接了多少工具”判断 Agent 是否强大，但作者的实践说明，工具更像手脚，Skill 更像方法。工具多，不等于会做事；方法一旦沉淀下来，下一次遇到类似问题，系统就不会从零开始。

第四，下一步机会可能是“概念映射”。也就是说，Memory 系统不只是把事件存起来、找出来，而是进一步理解事件之间的结构关系。作者用“阻尼振荡”“相变”“信噪比”之类的跨学科概念来解释自己的变化，这恰好说明，未来更高级的 Memory 可能不只是资料系统，而更像理解系统。

从新闻到用户路径的归因问题

这篇文章看起来像个人知识管理实践，但如果换成 App 和 Agent 场景，它其实直接对应一个更大的问题：上下文为什么总在关键节点丢掉？

传统用户路径里，归因通常围绕触达、点击、安装、首启、转化来展开。系统更关心“用户从哪来”，而较少关心“用户为什么会在这个场景下做这个动作”。在简单流程里，这种粗粒度口径还勉强够用；可一旦链路开始变长、任务开始跨系统、AI 开始介入中间决策，问题就会暴露出来。

很多团队现在都在遇到类似困境：用户也许最初是在文档里提出问题，在客服里留下线索，在内容系统里触发推荐，在 AI 助手里做了前置整理，最后才落到 App 安装、注册或某个业务动作上。表面看，后台依然能记录一次安装、一次激活、一次回调；但真正决定结果的上下文，早在中间层就已经断了。

这和作者在 Claude 里反复重讲背景，其实是同一类问题。模型失去上下文，会重新给出一套通用答案；归因系统失去上下文，也会把一次复杂路径粗暴地压扁成“某渠道带来一次转化”。看上去结果还在，真正有价值的判断脉络却已经消失。

这也是为什么 AI Memory 对 xinstall 不是一个遥远概念，而是和“链路保真”直接相关。作者那句“Claude 没有记忆，Obsidian 里的总结文件，就是它的记忆”，如果放到增长系统里，也可以翻译成一句更业务化的话：系统没有天然上下文，链路里留下的参数和阶段摘要，才是业务真正的记忆。而【智能传参】在这个场景里，本质上做的就是把最容易丢的上下文，尽可能留到后续节点里。

工程实践：重构安装归因与全链路归因

渠道编号 ChannelCode：先让“记忆入口”有身份

问题：很多团队会给广告位、投放计划、达人链接做编号，却不会给“上下文入口”单独建身份。结果是，来自文档、内容、客服、Agent、知识库或 AI 助手的不同触发场景，最终都被笼统地记成同类来源。这样做的问题是，系统可以记住结果，却记不住判断从哪里开始偏移。

做法：可以借助 渠道编号 ChannelCode 的思路，把入口定义从“媒体来源”扩展到“来源 + 场景记忆入口”的组合身份。比如，将 knowledge_entry、assistant_context_entry、doc_memory_entry、content_trigger_entry、crm_recall_entry 等纳入统一入口编号，再补充 scene、source_channel、memory_layer、risk_level 等字段。这样，团队看到的就不再只是“用户从哪里来”，而是“用户先在哪个记忆入口形成了上下文”。

带来的好处：当某类场景带来的转化、留存或复访波动时，团队能更快判断到底是投放来源变了，还是前置上下文变了。对今天的 AI 链路来说，【智能传参】第一步不是传更多参数，而是先让关键记忆入口有身份。

智能传参安装：把阶段上下文一路带进安装和首启

问题：很多高价值上下文在进入 App 之前就已经丢掉了。用户也许先看过一份带标签的分析、在对话里形成了阶段性结论、在知识库里读过对应说明，最后才点击进入安装或首启；但等到业务系统真正接住这个用户时，前面的“为什么而来”往往已经只剩一个抽象来源。

做法：这时，智能传参安装 的作用就不只是带一个渠道 ID，而是把阶段上下文尽量保下来。更合理的方式，是在链接、中转、安装或首启阶段受控保留 source_channel、scene、memory_layer、summary_id、workflow_id、task_type、entry_module 等关键参数，让后续节点知道“这次进入不是孤立事件，而是带着前置判断脉络来的”。关于这类链路承接的底层思路，也可以参考 xinstall 在《智能体分发时代 App 安装传参逻辑的底层重构》中的方法，把“安装带参”升级成“上下文带参”。

带来的好处：产品团队可以按不同上下文层级设计不同承接方式，增长团队能分辨“单次点击用户”和“带阶段记忆进入的用户”之间的差异，数据团队则能把激活、留存、复访放回原始任务语境里理解。注：本文讨论的部分多阶段记忆上下文保留、复杂任务链参数还原等方向，属于对未来分发趋势的前瞻性技术延展与思考，例如知识库驱动承接、跨系统一键拉起、私域上下文续接等。此类链路在不同业务中的成熟度不一，推进时仍需结合实际架构评估。

参数还原与事件模型：让“系统记住什么”变成可解释结构

问题：传统埋点模型很擅长描述“曝光—点击—安装—打开—转化”，却不擅长解释“用户原本带着什么判断路径进入了这条链路”。尤其在 AI 产品和长任务场景里，真正影响结果的往往不是最终动作本身，而是前面几层摘要、阶段总结和上下文累积。

做法：更合理的方式，是在数据层建立统一事件图，把人物流量、上下文流和任务流放到同一张图里。围绕 scene_view、context_recall、summary_attach、click、install、open、callback、retain、complete 等节点建模，并补充 channelCode、memory_layer、summary_id、workflow_id、scene、risk_level、callback_source 等字段。对于多平台、多入口、多阶段场景，也可以结合 全渠道归因 来统一看，让“系统为什么在这一步给出这个结果”不再只是黑箱。类似方法论，也能与 xinstall 在《OpenClaw 引爆智能体分发：AI 个人助理重构 App 参数传参安装范式》和《亚马逊 AI 战略升级？多云多 Agent 时代 App 该怎么认清流量真身》中的思路互相印证：先识别流量和任务真身，再还原链路中的关键上下文。

带来的好处：团队不只是知道某次转化发生了，还知道前面哪一层摘要或场景对这次转化形成了推动；不只是知道某个入口带来留存差异，还知道差异来自哪一段上下文保真。归因系统也会因此从“结果记录器”升级成“上下文解释器”。

这件事和开发 / 增长团队的关系

对开发和架构团队：要开始给“上下文层”留字段

如果你的业务未来会承接来自 AI 助手、知识库、协作系统、记忆系统或复杂任务链的用户和任务，开发团队现在就应该把“上下文字段”预留出来。因为一旦链路开始拉长，再去回补这些信息，往往已经来不及了。

建议优先预留这些字段：

• channelCode：统一入口编号
• source_channel：来源渠道
• scene：触发场景
• memory_layer：当前来自哪一层记忆
• summary_id：关联的阶段摘要
• workflow_id：所在任务链
• entry_module：入口模块
• task_type：任务类型
• risk_level：风险等级
• callback_source：结果回传来源

这些字段不一定第一天都用满，但如果接口层完全没预留，后续很多上下文差异只能靠猜。

对产品和增长团队：不要把“结果发生”当成“链路已解释”

增长团队最容易误判的是：只要看到了激活、转化、留存，就以为路径已经足够清楚。可在 AI Memory 时代，很多结果其实来自前面那几层被压缩过的判断脉络。你看到了结果，不代表看到了原因；你看到了入口，不代表看到了上下文。

因此，产品和增长团队至少要同步做三件事：

• 把“来源”与“上下文来源”拆成两层观察。
• 把不同记忆层的用户行为差异单独统计。
• 把摘要附着率、上下文命中率、任务续接率放进复盘体系，而不是只盯着安装和激活总量。

现在可以做什么

• 先盘点业务里有哪些关键上下文会在链路中途丢失。
• 再确认哪些场景需要把阶段摘要和任务参数保留下来。
• 最后建立一个最小可用的上下文事件图，把来源、记忆层和结果放在一起看。

对很多团队来说，真正的风险不是 AI 记不住，而是业务链路已经在持续失忆，自己却还没意识到。

常见问题（FAQ）

AI Memory 的核心到底是“记更多”还是“记更准”？

从这篇材料看，真正关键的不是无限保留信息，而是把原始信息逐层压缩成对后续判断最有用的模式。也就是说，AI Memory 的核心更接近“会压、会留重点、会续接”，而不是简单存得越多越好。

为什么外部文档会比模型隐藏状态更可靠？

因为外部文档可见、可改、可版本管理，也更容易跨会话延续。相比“系统说它记住了”，用户通常更信任“我能看到它到底记了什么、还能修正它”。

Skill 为什么会被认为是记忆的高级形态？

因为 Skill 保存的不是信息片段，而是可复用的方法路径。记住“发生过什么”更像档案，记住“下次怎么做”才更接近真正的能力沉淀。

这件事为什么会影响 App 的归因体系？

因为很多转化并不是在最后一跳才被决定的，而是在更前面的摘要、标签、阶段总结和上下文累积中逐步形成。原来只围绕显式点击建立的归因体系，很难解释这些长链路上下文，所以【智能传参】和上下文还原会变得越来越重要。

行业动态观察

从行业角度看，“一个非技术PM的3个月AI Memory实践复盘”真正重要的，不只是它展示了一套个人效率工具，而是它用很朴素的方法踩出了 AI Memory 的几条底层规律：记忆必须分层，外部文档比隐藏状态更可信，Skill 比工具清单更接近长期能力，压缩比堆积更重要。很多大而全的记忆系统最终也会回到这些基本问题上：信息怎么沉淀、上下文怎么续接、判断为什么能被保留下来。

对 App 和 B 端团队来说，现在正是把“上下文保真”从个人效率问题升级为系统能力问题的窗口期。因为一旦任务链越来越长、AI 介入越来越深，业务系统最容易先失去的不是结果，而是为什么会产生这个结果的过程。未来真正关键的，不只是系统会不会记，而是能不能把那些对决策最有价值的上下文持续、透明、可还原地带到后续链路里。对今天的开发者、产品经理和增长负责人而言，【智能传参】已经不只是安装能力，而是在 AI Memory 时代保住判断脉络、重建链路解释权的底层能力。