用 Claude Code 这类编码 Agent 的团队，常会遇到一个怪现象：规则已经改了，Agent 还按旧的做。比如一个仓库已经从 npm 迁到 pnpm：锁文件换了，CI 改了，CLAUDE.md 也写了新命令。你让 Agent 构建，它却再次选择 npm。纠正之后，本轮正常；换个会话，旧命令又回来了。
这时继续追加“务必使用 pnpm”，未必能解决问题。要查的是：旧命令存在哪里，为什么还会进入上下文，谁有责任撤销它。维护者要撤销旧笔记的适用性，平台工程师要确认它不再进入下一轮决策。
两类持久信息，如何进入本轮上下文
人工规则是团队希望 Agent 遵守的约定，例如 CLAUDE.md 中的构建流程。自动记忆是 Agent 为以后保存的笔记，例如一次纠错形成的操作经验。两者被读入后，与本轮对话、工具结果共同进入上下文，成为这次决策能看到的材料。
Claude Code 中，人工规则与自动记忆互补。上下文里的文字并非强制配置：文件写着什么、模型选择什么、工具获准执行什么，需要分别检查。
本文固定客户端基线为 2.1.96，其固定版本 CHANGELOG 的 2.1.63 条目已记录同仓库 worktree 共享自动记忆的变更；实际目录应分别从 /memory 打开并比对，同时检查 autoMemoryDirectory 配置；本文未做客户端行为实测。worktree 指同一仓库的独立工作目录。
在这个虚构的迁移案例里，“项目必须使用 pnpm”应随对应代码版本由团队维护；具体可执行入口应回到当前提交的 package.json、锁文件与 CI 核对。适合自动积累的，是代码里推不出来的背景，例如某类测试需要找谁申请环境，而不是再复制一份迟早落后的构建配置。
从写下经验，到旧命令再次被执行
先对照当前提交的构建入口、实际生效的规则文件和记忆文件，找出含有旧命令且确实被读入的材料。找到旧笔记，再沿记忆链路处理；否则继续检查其他规则、恢复的旧会话或未更新的脚本，别先把故障归因于自动记忆。
Agent 在工作中决定哪些信息值得保存，再写入记忆文件。按官方记忆文档的机制描述，新会话加载 MEMORY.md 的受限索引内容，主题文件由模型按需调用文件工具读取。
取证时，把该版本能提供的启动加载记录与主题文件读取记录另存，再与修订后的文件内容对照；/memory 只用来找目录，不作加载凭证。日志若只列文件名，就不能证明注入了哪些文字；缺少内容证据时，清除旧输入这一项记为未核实。
自动记忆文件不随会话记录的保留期一起清理，“已经过了很久”不是过期条件。索引未加载，也不能证明主题文件已经删除。
随后模型把任务、规则、记忆和读到的代码一起用于决策。如果旧笔记仍说“构建用 npm”，只在 CLAUDE.md 增加新要求，就留下了互相竞争的输入。加载顺序无法像配置系统那样保证冲突指令可靠覆盖。
当前代码同样需要先被读取。对于本例，团队应要求核对包管理器声明、对应锁文件和 CI 构建入口；三者不一致时停止构建，由仓库维护者确认迁移是否完成，而不是让 Agent 猜一个能跑通的命令。
模型选出命令后，才轮到工具执行。若旧命令会改动依赖或触发不应发生的脚本，仅靠记忆纠正不够。PreToolUse 是 Claude Code 的工具调用前钩子，可返回阻止决定。
比如，团队自建校验入口可以接受“仓库目录、工作区状态、待执行脚本”三项输入：声明为 pnpm、只保留对应锁文件，且 CI 最终调用 pnpm 时才放行；CI 若调用包装脚本，就继续核对脚本内的实际入口。返回结果是放行或阻止及原因。其他 Shell 或工具仍可绕过时，这个门禁只保护受控入口。
▲ 上下文输入与工具执行校验的边界
让迁移事件撤销旧知识
构建相关记忆应当是需要依赖校验的笔记。团队可以维护这样一条记录：
字段
本例填写内容
作用
来源与责任人
迁移前的构建记录；仓库维护者
出错时找到依据和确认人
作用域
本仓库中仍采用 npm 的提交范围
防止跨分支套用
版本依据
记录时的提交、锁文件及 CI 修订
能还原当时为何成立
失效条件
包管理器声明、锁文件类型或构建入口变化
触发重新确认
这是团队自建的治理记录，不是客户端内置协议。启动检查器比较记录中的包管理器声明、锁文件类型和构建入口与当前工作区，包含未提交修改；只改 README 不触发本条失效，改动上述依据则先登记“待核验”，由维护者判断旧经验对哪些提交仍有效。
修改活动文件前，平台工程师先停止旧写入者。团队若统一管理启动，可登记“记忆目录→会话进程及后台任务”，暂停该目录的新任务并逐项确认进程退出，再将条目及备份移出活动索引和正常主题读取路径。只删索引引用仍可能读到主题文件。无法掌握全部写入者，就不要在线自动修订，应在能确认停写的维护窗口人工处理。
撤销的是旧命令的无条件适用性，而非它对所有历史提交的有效性。仓库维护者确认后，人工规则随各自代码版本更新。共享记忆中的旧笔记“构建用 npm”，可以改为：“构建前核对当前提交的包管理器声明、锁文件与 CI 入口；不一致时先交维护者确认。”
确需保留旧经验，就写明可核验的适用条件，例如该提交的包管理器声明及锁文件仍对应 npm。
修订后只启动干净会话，回归通过再开放任务，避免旧上下文把旧内容写回。
回滚也要区分对象：代码回到迁移前的提交，采用该提交对应的规则；只是新版记忆写错了，就撤回错误修订并重新核对当前代码。修订历史用于追踪，不放回活动读取路径。
▲ 旧记忆退出活动读取与回归后恢复的过程
验收要离开刚被纠正的那轮对话
磁盘文件改了，已经进入上下文的旧文字仍在。停止旧会话后，以新会话验收实际读取与执行。
把请求固定为“检查项目并执行构建”，不要在提示里直接告诉它使用 pnpm。否则测试的是临场服从，不是持久纠错。下面是待执行的回归表：
回归场景
要留的证据
通过条件
原目录新会话
客户端版本、提交、实际加载文件、工具命令
依据当前配置选择 pnpm
另一 worktree，同一提交
实际记忆目录、加载内容、命令
不因启动位置恢复旧命令
另一 worktree，迁移前提交
该提交的配置与调用记录
不把新规则误套到旧代码
受控测试中让包管理器声明、锁文件或 CI 入口不一致
已实现的执行校验入口的阻止记录、接管人及处理结果
校验入口阻止构建，交维护者确认
前三行只有同时满足命令选择正确、加载内容中不再含无条件旧命令，才算记忆修订通过；只看到正确命令或文件名，仍记为未核实。最后一行另验执行门禁。阻止后，由维护者在变更单记录一致的构建入口与确认提交；平台工程师复检配置，再从新会话重试，不能直接绕过门禁。
若另测模型能否识别矛盾笔记，应保留它核验材料、请求确认的记录，不要求工具钩子凭空识别文字冲突。门禁放行正确命令，也不能证明旧输入已经清除；两类证据要分别看。
“让它忘掉”的责任最终落在两处：仓库维护者决定知识何时不再成立，平台工程师落实可控的文件修订与执行检查，并用回归记录验收。若产品只提供不透明的记忆开关，就别把会随版本变化的构建契约托付给它，仍让当前代码和人工规则承担权威来源。
IT架构师联盟
面向架构师与工程同行，解析AI Agent、系统架构与可靠性，讲清技术机制、工程边界和实践方法。
热门跟贴