CLAIUDE.md、CURSOR 规则、Copilot instructions 等多 Agent 指令文件分散在机器上无法对齐的根因与解法。
你写了一份 CLAUDE.md。六个月后,你的笔记本上有了十八份,而你无法说出哪一份是正确的。
这不是假设。我扫描了自己的机器,发现确实如此。以下是它发生的原因,以及为什么那个显而易见的修复方案并不能真正解决问题。
副本是由工具创建的,不是你
每个 Agent 都会从它自己的路径读取指令。
你并没有决定保留四份副本。你只是决定使用四个工具。副本是跟着这些工具一起产生的。
漂移不是由粗心造成的
产生漂移有三个机制,都不涉及任何人的疏忽大意。
在使用的位置编辑。一个 Agent 在任务中途行为异常。你修复了眼前打开的那份指令文件。那只是四份中的一份,修复只落在了那一份上。
检出的副本不是最小单元。你把同一个仓库克隆了两份——一份用于主分支,一份用于一个长期分支。两个都有指令文件。一旦其中任何一个被修改,它们就开始分叉。
主目录规则是不可见的。~/.claude/CLAUDE.md 不属于任何仓库。它不在任何 CI 中。它是你不想在 review 里争论的那些规则的归宿。
从单一源生成并不能杜绝这个问题
自然的反应是停止保留副本:写一份 AGENTS.md,然后生成其余的。
我做了这个工具。它能工作。它叫 agent-fanout——单文件 Python,零依赖,MIT 协议。
create CLAUDE.md
create .cursor/rules/from-agents-md.mdc
create .github/copilot-instructions.md
生成的文件带有一个头部注释,这样没有人会直接编辑它们,而 CI 中的 --check 会把手工修改的衍生文件变成一个失败的构建。
这覆盖了这个仓库,这里 CI 是运行的。听起来像是覆盖了所有场景,直到你列出哪些不在范围内:
主目录中的全局配置——没有仓库,没有 CI
编辑与生效之间的时间窗口——Agent 在文件变化的瞬间就读到了它;CI 要到 push 时才会注意到,而且还得有 push 发生
没有 CI 的仓库——原型、一次性的克隆、上周的实验。这些地方指令被最自由地重写,而门控却最少
最小单元是机器,不是仓库。Agent 运行在一台笔记本上,那里有许多检出的副本、同一仓库的多份拷贝,以及一个主目录。任何局限于单个仓库的作用域都无法看到这些。
所以要测量,而不只是预防
预防是策略。检测是测量。策略会以你看不见的方式被绕过,除非你先去测量。
agent-drift 扫描的是路径而不是仓库,并按内容相似性分组而不是按文件名:
python3 agent_drift.py ~/work ~/side-projects
Scanned 47 instruction files.
DRIFT: 2 documents, 5 distinct versions between them.
claude-code:CLAUDE.md
6 copies, 3 versions
9b01aeaa204d 3 files, 406 lines
2dc3c616c279 2 files, 411 lines
按文件名匹配在这里毫无用处。不相关的项目有不同的 CLAUDE.md 是正常的,而一个把这些报告为漂移的工具很快就不会再被使用了。把它指向你的整个工作目录,而不是单个项目——有趣的结果是跨仓库边界的。
生成去除了副本存在的理由。检测捕获的是那些出于你未曾预料的原因而存在的副本。只做其中一件会让你感觉被覆盖了,而这比知道自己没有被覆盖更糟糕。我自己就踩过这个坑。
说实话,最终状态是这两个脚本都不需要——资产不会作为文件散落在机器上,一份审查过的副本会到达每一台机器。这是我目前在 untactit 正在做的事情,目前处于 pre-launch 阶段。
这些脚本不依赖于那个愿景。取其中有用的部分就好。