上周我让一个在 Telegram 里跑的 Agent 帮我跟进一位老客户。我以为万事俱备：对话都留着、模型上下文够大、甚至在 ChatGPT 里还开过 Memory。
三周后，它要给客户发跟进邮件，突然来了一句：
「请问您是哪家公司来着？方便再介绍一下项目背景吗？」
客户截图甩进群里，场面一度很尴尬。那一刻我才确定：Agent 记得聊天，不等于 Agent 有记忆。 后来我们把同一套逻辑拆给几位试点客户看，几乎人人点头——大家亏的不是模型不够聪明，而是把「聊天记录」当成了「Agent Memory」。
下面是我和团队在 OpenClaw 上踩坑、改方案的过程。不讲百科定义，只讲你会遇到的场景，以及我们最后怎么区分 AI Memory（系统怎么存）和聊天窗口里那堆 history。若你在选型记忆栈，可对照 OpenHuman vs ChatGPT Memory 四层栈；若做 IDE Agent，可延伸 Karpathy 的上下文分层。
场景一：聊天记录都在，客户规则还是丢了
一家做 B2B 服务的团队跟我们吐槽过几乎一模一样的事。
客户在第三周明确说过：「以后报价只要 PDF，不要 Excel。」 Agent 当场回复「好的，已记录」。团队去后台翻——聊天记录一字不少，甚至还能搜到「PDF」关键词。
三个月后，同一位客户收到一封带 Excel 附件的报价。客户直接炸毛：你们到底有没有在跟？
问题不在模型「笨」，而在：那句话从未进入可被检索、可被强制执行的 Memory。 它躺在几万字对话中间，和寒暄、表情包、一次错误的抄送名单混在一起。新会话启动时，Agent 没有义务、也没有稳定机制把「客户 A = 仅 PDF」拎到 prompt 最前面。
聊天记录是留痕，适合审计回放；Agent Memory 是下次决策时要用的状态。前者像会议录音，后者像 CRM 里那条「勿发 Excel」——你绝不会指望销售每次签单前重听三小时录音。
场景二：百万 Token 的上下文，救不了 Claude Code 重复劳动
我自己在 Claude Code 里吃过另一种亏。
某次让它分析一个单仓 monorepo，生成架构说明，前后折腾了两天，产出还不错。我以为「反正窗口够大，下次接着聊就行」。
两周后换新会话，我只说了一句：「继续上次那个仓库的文档工作。」
它又重新 clone 思路、重新扫目录、重新写一版结构相近的文档。聊天历史？部分在，但任务状态不在：上次分析到哪个子模块、哪些结论已写入 docs/、哪些待人工确认——这些躺在工具输出和文件系统里，不在「你和模型的寒暄记录」里。
那时我才认同 Karpathy 那套说法里很刺耳的一句：别把无限上下文当硬盘。 窗口越大，你越倾向把一切塞进去，成本和噪声一起涨。真正该进 AI Memory 的，是「上次做到哪」这种可更新的一行状态，而不是两万行 tool stdout。
框架文档也在往这走——例如 LangGraph 把线程状态和持久化 store 分开。我们落地时没有照抄框架，但认同同一件事：消息列表 ≠ 记忆库。
Agent 其实只需要记住三种东西
跟客户、跟同事解释时，我尽量不用一排英文名词。通常只说三句，对方就能对齐预期：
- 用户是谁、有什么硬规矩——客户 A 只收 PDF；老板讨厌长语音；我们团队用 UTC 排期。
- 上次做到哪——Issue #482 卡在等法务；昨晚告警已 ack 未 root cause；文档写到第三章。
- 以后怎么做——发布 checklist、审批链、on-call 先打谁。
聊天记录对这三类的覆盖极不均匀：偶尔蹭到第 1 条，几乎帮不上第 2、3 条。
写方案、跟研发对齐时，我们才会补一句行业叫法：上面三条大致对应 Semantic（稳定事实）、Episodic（发生过什么）、Procedural（标准流程）。名词可以后学，缺哪一类，Agent 就会在哪个场景出丑——这比背定义有用得多。
我们踩过的一个坑：把聊天记录全灌进向量库
去年测 OpenClaw 早期方案时，团队图省事：所有会话原文 embedding 进向量库，以为「先存进去，检索总会命中」。
一个月后，质量反而变差。Agent 会把半年前已废弃的发布流程当成现行 SOP；有时从闲聊里检索到「上次好像说过不用 PDF」和「客户又要 Excel 模板」两条矛盾片段，然后自信地选错一条。
我们当时的判断是错的：Memory 最难的不是存不进去，而是删不掉、改不动、分不清。
后来给每条写入的 Agent Memory 强制带：
- 来源（哪次对话、哪个工具、哪张工单）
- 创建时间
- 过期时间或版本号（流程改版就作废旧条）
检索时先按客户 / 项目过滤，再按时间衰减排序。同样规模的库，胡编乱造的概率明显下降。这事没有银弹，但这是我们在试点里唯一愿意写进交付清单的经验，而不是「建议考虑向量数据库」那种空话。
若你也在用 Cursor / Claude Code 接 MCP，工具返回往往比聊天更长——更要把「结论」写进 Memory，而不是把 stdout 塞进索引。MCP 本身只是管道，见 Model Context Protocol 官网。
ChatGPT Memory 够不够？看你怎么用 Agent
我不会说 ChatGPT Memory 没用。重度在 ChatGPT 里写文案、改邮件的人，开 官方 Memory 很省事——它擅长记住「你喜欢 bullet」「你在湾区」这类聊天偏好。
但一旦 Agent 跑到 Slack、Telegram、Cron、IDE，Memory 就卡在 OpenAI 那个 App 里。你在 Chat 里定的规则，不会自动变成 OpenClaw 网关上的硬约束。
我们现在的分工（细节见 AI Memory Stack 选型文）是：
- ChatGPT Memory：语气与个人偏好（可选，能关则关，避免双份事实）
- 本机 vault / OpenHuman 一类：工作事实 + 多源同步
- OpenClaw + MCP：读 Memory、执行任务，不自己当数据库
只聊天，Memory 够；要 Agent 干活，必须单独做 AI Memory 层。 这是我们会直接告诉客户的判断，不是厂商中立白皮书。
当 Agent 开始长期工作：记忆只是第一步
不少团队把 Memory 修好后，第二个打击来得很快：Agent 活不过一晚上。
笔记本合盖、家里 Wi-Fi 抖一下、本机 MCP 进程被系统杀掉——早上 Cron 该发的提醒没发，昨晚写入的状态没人续上。你会得到一种更诡异的体验：记忆库里有记录，但 Agent 像从没存在过。
所以我们把问题拆成三层，而不是在文章末尾硬塞产品：
- 记忆层：记什么、谁可读、何时过期（本机 vault 或团队 Memory Store）
- 执行层：OpenClaw Gateway 在 VPS 上跑 7×24，扛 Telegram/Webhook/Cron
- 工具层：重 MCP、浏览器自动化、
xcodebuild别和 Memory 同步抢同一台合盖笔记本
我们自己的习惯是：Memory 在主力 Mac 或 NAS；网关在 Linux VPS；编译和重工具丢 云 Mac。不是「为了卖云」，而是避免一次 Archive 把昨晚刚 sync 完的 vault 卡死——这种事我们真遇到过。
网关部署可参考 Linux VPS 上的 OpenClaw Gateway。三层齐了之后，「客户只要 PDF」才会既写进 Memory，又能在周三凌晨被正确执行。
你可能还想问
聊天记录保存了，为什么还会忘？
因为保存的是原文，不是规则。没有提炼、没有检索入口、没有过期策略，Agent 在新会话里不会稳定加载那条约束。
只堆 PDF 做 RAG 行不行？
RAG 擅长「文档里有什么」。它不自动回答「上次工单处理到哪」「这条流程是否已废弃」。我们会用 RAG 当 AI Memory 的一层，而不是全部。
个人开发者最小配置？
只在 ChatGPT 里玩 → 开 Memory 即可。要 Telegram/IDE Agent → 加本机 Memory + OpenClaw。要 Cron 不断 → 再加 VPS。顺序别反：没 Memory 就上 7×24，只会得到「健忘且熬夜」的自动化。