xAI 给 Grok Build 加上了记忆功能。听上去像一次常规更新，但对每天靠编码 Agent 干活的人来说，这件事的分量不轻——往后开新会话，你不必再把上周定下的目录结构、命名习惯、那句「数据库迁移一律走脚本，别手改」重新交代一遍。xAI 的说法是：每轮对话结束后，系统会在后台把项目约定、关键决策和事实记下来，供后续会话读取。记忆按项目切分，另有一份全局偏好；/memory 用来只读浏览记忆文件，/dream 负责把零散笔记整理成主题文件。还有一条容易被忽略的规则：当前对话里你给的指令，优先级高于记忆里的任何内容。
编码 Agent 的瓶颈，早就不在模型智商上
上下文窗口是工作台，不是档案柜
很多人把长上下文当成记忆的解药，这是误会。上下文窗口更像一张工作台，你摊在上面的东西越多，找东西越慢，而且收工就清空。一个跑了三个月的仓库，里面全是约定俗成的规矩：错误码怎么定义、日志往哪打、测试文件放哪个目录。这些东西不会出现在任何一次对话里，却决定了每次改动顺不顺手。Agent 忘掉它们，你就得重新教；教得多了，你会开始怀疑自己是在用工具，还是在带一个每天失忆的新人。
被反复重述的约定，是一笔看不见的账
开发者的耐心消耗往往不发生在写代码上，而是发生在解释代码上。同一个规范讲第五遍的时候，效率损失还只是表面，真正糟糕的是你会不自觉地降低要求——懒得提了，随它去吧，反正是小项目。这种妥协积累起来，代码库就开始发散。记忆功能瞄准的正是这块成本，它想做的事很朴素：让 Agent 第一次被教过的东西，第二次不用再教。
难的不是记住，是判断该记什么
把所有东西都塞进记忆，等于没有记忆。一个健康的项目每天产生大量噪声——临时的调试结论、被否决的方案、随口一提的猜测。哪些属于「项目事实」，哪些只是「这轮对话的上下文」，模型得自己划界。xAI 用后台写笔记的方式绕开了这个判断难题的一部分：你不需要手动打标签，系统自己决定。但代价是，判断权交出去了，你只能在事后通过 /memory 去看它到底记了什么。
xAI 这套记忆机制，拆开看有三层
后台记账：不打断，也不邀功
记忆的写入发生在每轮对话结束之后，而不是插在对话中间。这个设计选择很务实。要是每次都要弹窗问你「是否保存这条结论」，记忆功能三天就会被关掉。放到后台，用户几乎无感，代价是不透明——你不知道它在哪一轮、基于哪句话写下了什么。所以 /memory 的存在不是装饰，它是这套机制的兜底，是唯一能让你把黑箱翻开看的入口。
项目记忆和全局偏好，分两个抽屉放
项目与项目之间的边界，往往比人与人之间的边界还清楚。A 仓库用 Python，B 仓库用 Go；A 项目的提交信息要求带工单号，B 项目根本没这套规矩。把两者混在一个记忆池里，灾难几乎是必然的。Grok Build 按项目区分记忆，再加一份全局偏好，等于默认了两个层级：跨项目通用的个人习惯放上层，跟仓库强绑定的结论放下层。这个划分谈不上新鲜，但划了和没划，用起来的差别很大。
/memory 管看，/dream 管整理
两个命令分工明确。/memory 是只读的，你能浏览记忆文件，但改不了——这一步克制得挺好，避免用户在情绪上来了的时候删掉一堆有用结论。/dream 走的是另一条路，它把散落的笔记归纳成主题文件。这个动作相当于一次离线整理：原始记录是流水，主题文件才是可以拿来读的东西。真正值得盯的是整理的质量，因为归纳一旦跑偏，后续所有会话都会基于错误的前提往下走。
那条优先级规则，比记忆本身更值得琢磨
当前对话里的指令永远压过笔记
这是整套设计里最要紧的一句话。记忆天然带着滞后性，它记录的是过去某个时刻的判断，而项目是活的。上周决定用 A 方案，这周可能已经推翻了。如果记忆的权重高于当前对话，Agent 就会固执地拿旧结论顶你，那种体验比没有记忆更让人恼火。把当前指令放到最高优先级，等于承认了一件事：用户此刻说的话，才是最接近事实的输入。
冲突发生的时候，谁来解释
规则写在文档里很干净，落到实际场景里总有灰色地带。你说「这次先跳过测试」，记忆里写着「提交前必须跑测试」——Agent 照你说的做了，但它有没有在某个地方标记这次例外？下次它会记住这个例外，还是继续按原规则走？这些细节决定了记忆会变成一份活的档案，还是一堆彼此打架的条目。xAI 目前给出的信息里，这部分还是空白。
但记忆会腐化，没人能躲过去
过期决策比没有决策更麻烦
没有记忆的时候，Agent 会问你。有了一份写错的记忆，它会理直气壮地按错的来。这是所有持久化知识系统共有的病：写入容易，清理难。项目从 monorepo 拆成多仓库，构建工具换了一茬，几个月前那条记忆还躺在文件里，等着某次会话把它当成现行规范执行。用户得定期翻 /memory，像清理浏览器缓存一样手动检修，否则记忆库迟早变成考古现场。
看不见的记忆，没人敢信
只读浏览是个好起点，但离「可信」还差得远。可信意味着可追溯：这条结论是从哪次对话里提炼出来的，什么时候写的，是谁说的。三条都没有，你就只能靠感觉判断要不要保留它。团队场景下这个问题更尖锐——同一个项目里三个人各自跟 Agent 对话，记忆是共享的还是隔离的？如果是共享的，一个人的临时判断会不会污染另外两个人的会话？这些答案直接决定了记忆功能能不能从个人玩具升级成团队基础设施。
眼下就能做的三件事
把 /memory 当代码来审
既然它能读，就定期读。打开文件扫一遍，看看有没有明显过时的条目，有没有把一次性的调试结论写成了通用规则。这个动作花不了几分钟，但能挡住很大一部分后续麻烦。把它写进项目节奏里，比如每次发版之前过一遍。
给记忆定几条硬规矩
约定什么该记、什么不该记，最好在团队里形成共识：架构决策记，临时方案不记；跨会话有效的约束记，本轮任务参数不记。规矩不用复杂，三条就够，关键是要说出来，而不是让每个人凭感觉喂给 Agent 不同的东西。
别急着把它当知识库
记忆是给 Agent 用的工作缓存，不是团队文档的替代品。真正重要的结论还是该落在仓库里的 README、ADR 或者设计文档上，那里才有版本历史、有评审、有明确的责任人。把 Agent 的记忆当成第二大脑，意味着你把项目的记忆交给了你看不全也改不动的一份文件——这个赌注，现在下还太早。
