项目总被 AI 忘掉，Grok Build 把约定写成了可改文件

同一个仓库，上一轮刚跑过测试，下一轮就又把命令敲错了。

这不是段子。xAI 给 Grok Build 的记忆功能做了一个很克制的示例。某个 Rust 项目直接跑 cargo test 会因为测试数据库没启动而失败，显示 143 项通过、5 项失败。用户补了一句，这个项目应该运行 just test，因为它会先拉起 PostgreSQL。等下一次会话去改 webhook 重试，Agent 读回了测试主题里的约定，直接跑对了命令，151 项通过。

好家伙，模型没有突然学会 Rust。它只是终于没把上一回合最有用的那句话扔进聊天记录的深海里。

9 月 16 日，xAI 把这个能力作为 Grok Build 1.0.34 的正式功能推出。它会在每轮结束后后台提取值得长期保留的内容，写成按项目和全局作用域分开的 Markdown 笔记。新会话开始时，系统再挑与当前工作相关的主题读回来。官方还给了两个入口，/memory 用来浏览记忆文件，/dream 用来把碎片笔记整理进主题文件。

看上去像是 Coding Agent 终于有了长一点的记性。

我更在意的是另一件事。项目记忆一旦跨会话影响代码、测试和设计选择，它就不再只是聊天体验的锦上添花。它开始像一个没有走进 Git 仓库、却会参与下一次改动的旁路知识库。

这东西写对了，省掉的是反复解释。写错了，污染的是之后每一次判断。

记忆不是把聊天记录再存一份

很多人遇到 Agent 忘事，第一反应是把更多对话塞回上下文。听着合理，实际很容易变成另一种混乱。聊天记录里混着临时排查、错误猜测、半截尝试、无关闲聊，还有已经被推翻的决定。把整段历史重新喂给模型，模型只会多一箱旧纸，不会自动得到一本项目手册。

Grok Build 这次给出的筛选标准反而很值得看。它说会留下代码和审查约定、决策与理由、项目里稳定存在的事实，例如某个子系统在哪里、测试套件应该怎样启动。它明确排除了任务瞬时状态、暂定结论、密钥，以及仓库或文档已经覆盖的内容。

这几条看着朴素，背后是在给记忆划边界。

真正适合跨会话带走的，是下一位接手的人也需要知道、而且短时间内不太会变的东西。测试要先起哪个服务，某个目录为什么不能直接改，接口兼容为什么保留一层旧适配，团队对提交信息和 review 的共同约定。这类信息散在聊天里很可惜，散在个人脑子里更危险。

反过来，正在修的 bug 到了哪一步、这次失败是不是数据库抖了一下、刚想到的方案是否靠谱，都不该抢着进长期记忆。它们属于当前任务，不属于项目事实。今天把它们写得太笃定，明天就是一条会误导 Agent 的旧指令。

项目文档负责最终事实，长期记忆保存可复用的工作约定，当前任务状态留在工单与会话里。三层别混成一团。

一个容易被忽略的细节是，官方说当前会话里的指令优先于历史笔记。这很重要。记忆应该给模型提供背景，不应该抢走当前任务的方向盘。你今天明确说这轮要改用另一套测试环境，旧笔记就该退到后排，而不是跳出来把 Agent 拉回以前的习惯。

把这层优先级想清楚，项目记忆就比较像版本控制里的背景资料，而不像一个永远正确的系统提示词。

最危险的不是忘记，是自信地记错

项目里最常见的事故，往往不是没有知识，而是过期知识还在被当成真理。

测试命令是个好例子。一个项目从 npm test 迁到 pnpm test，或者本地测试数据库从 5432 换到 5433。旧命令留在记忆里，Agent 每次新开会话都可能先撞一次墙。人看到失败知道去问同事，模型却可能把失败当作另一个待修 bug，然后顺手改掉一段本来没问题的配置。

技术决策更麻烦。假如团队以前因为流量小，决定先用轮询，不上消息队列。三个月后流量结构变了，决策的前提早就没了。记忆如果只写「不要用队列」，没写当时的约束和取舍，后来的 Agent 看到的就不是经验，是一条失去上下文的禁令。

还有一类更隐蔽，某次排障中的猜测。有人说「大概是缓存」，Agent 做了几次尝试没复现，聊天结束。这句话如果被当成事实写进长期笔记，下一次类似问题出现，模型就会带着一个没有证据的锚点开始查。它看起来很勤快，路却已经歪了。

所以我不太喜欢把 Agent 记忆叫作「自动知识库」。知识库这个词容易让人放下警惕。它更像一套会影响下一次行动的工作便签。便签可以很有用，但前提是有署名、有来源、有更新时间，还能被撕掉。

xAI 的 /memory 给了一个不错的起点。你可以只读查看系统到底记录了什么，再去定位需要修改的文件。官方示例里，记忆按全局和项目作用域分组，还会展示每个主题文件。这个可见性比「模型自己在后台记住了」靠谱得多。

但只读浏览还不够。真正落进团队流程时，至少要问四个问题。它从哪一轮对话提炼出来，谁可以修改，它何时该过期，它会在什么任务里被读回。没有这些答案，记忆文件虽然是 Markdown，实际还是黑箱，只是黑箱换成了一个好编辑的格式。

一条记忆从被采集到影响下一次动作，中间至少要经过可查看、可纠错、可过期和按任务调用几道门。

哪些东西该进记忆，哪些该回到仓库

如果你正在给自己的 Coding Agent 设计跨会话上下文，不用急着造一套 /dream。先把信息放回它该在的位置，已经能解决大半问题。

第一格是仓库里的权威文档。架构边界、部署方式、正式测试入口、编码规范、敏感目录和安全要求，应该放在 README、AGENTS.md、CONTRIBUTING.md 或团队认可的设计文档里。它们需要走 review，需要跟代码一起变，也应该能被新人、CI 和不同工具读到。只把这类规则存进某一家 Agent 的记忆，等于把项目知识锁进一条私有小路。

第二格才是项目记忆。适合它的内容，是能帮助下一次会话快速进入状态、但没有必要每次都塞进项目文档的工作性线索。比如某个测试套件的启动顺序、过去一次迁移为什么绕开了某个依赖、某个目录里最常见的假阳性报错，或者团队偏好的 PR 描述粒度。它们最好很短，附上触发条件和来源，而不是写成一大段模糊经验。

第三格是任务状态。当前 issue 的假设、还没跑完的命令、等待确认的产品选择、临时开关和回滚计划，应该留在 issue、PR、任务卡或这次会话自身。它们需要的是推进和关闭，不是被永久收藏。任务结束后，只有被验证的那一小部分才有资格升级成项目记忆。

第四格是明确禁止写入。密钥、令牌、客户数据、个人信息、生产导出、未经确认的内部结论，别因为「下次也许用得上」就让它们进记忆。官方也把 secrets 排除在外，这条应该没有讨论空间。Agent 的记忆层越方便，越要把最少暴露原则写得更死一点。

把这四格做成一张简单的表，放在团队开始用 Agent 的第一周，比以后追着清理错误记忆轻松得多。

内容	应放的位置	进入长期记忆前要满足什么
正式测试命令、架构边界、权限规则	仓库文档	已 review，能随代码一起更新
已验证的工作约定、决策背景、常见环境坑	项目记忆	有来源、短小、能说明何时适用
当前排障进度、待验证猜测、临时开关	Issue、PR、当前会话	任务结束后默认删除或归档
密钥、客户资料、隐私信息、未确认内部判断	不应进入记忆	默认拒绝，必要时走受控系统

这不是为流程加戏。很多团队现在已经把 Agent 放进仓库搜索、测试、修复和 PR 草稿里。一次新会话读错了上下文，成本不只是一句回答偏了，可能是多跑一轮 CI、改错一处配置，或者让 reviewer 花半小时把旧决策重新讲一遍。

/dream 很酷，合并规则更重要

Grok Build 用 /dream 把最近笔记归并成主题文件，这个设计挺有意思。它承认记忆不是越多越好。碎片如果一直累积，最后会变成另一份没人敢看的日志；按 testing、code style、gateway 这类主题整理，至少让检索有了可读的单位。

可整理本身也会带来风险。两条笔记结论相反怎么办。旧主题里有一个仍然有效的约定，新会话又写进了一个过渡方案，谁覆盖谁。主题文件里每句话是不是都还知道自己来自哪次讨论。要是这些问题没有答案，自动归并很容易从整理资料变成悄悄改写历史。

比较稳的做法，是让「总结」和「裁决」分开。Agent 可以负责把最近几轮内容压缩成候选笔记，把相似内容聚到同一个主题下，把可能过期的条目标出来。最终进入稳定主题的规则，最好仍然有来源链接、更新时间和明确的人工或代码侧确认。至少在架构、数据迁移、权限和测试基线这些地方，不要让一个后台总结独自决定事实。

这不是不相信模型。恰恰是因为它会真的影响后续动作，才值得给它更清楚的证据链。

可以先从一个很小的检查开始。每周挑一个项目的记忆目录，随机读三条，问自己三个问题。这条还对吗。它能回到哪个文档或 PR。这条如果反过来被执行，最坏会造成什么后果。三问里有一问回答不上，就删、改或降级成当前任务备注。别等它攒了几百条再来做历史考古。

官方没有把这项能力包装成万能记忆。它说当前会话优先，排除暂态内容和密钥，并把记忆做成可浏览的文件。这种克制反而比「Agent 永远记住你的一切」更像工程产品。

项目记忆真正该追求的，不是多记一点，而是让下一次会话少猜一点。

今天那句 just test 如果只是被保存下来，价值有限。只有它能被看见、被纠正、知道适用于哪个项目，又在测试规则变化时被替换，它才配成为下一次改代码前的背景。

如果你们团队让 Coding Agent 记住一件事，你更愿意先记测试约定、架构决策，还是 review 习惯？

资料见 xAI 官方发布 和 Grok Build 官方 changelog。