多个 agent 写同一处时，先别让它们共写

多个 agent 协作时，最容易犯的错误，是先假定它们可以安全地共写同一个目录，然后再给冲突打补丁。更可靠的起点相反：先给每个 agent 明确的 namespace，把写入变成可追溯的记录，再由 evaluator 或 reconciliation 把状态归并起来。

Karim C 问了一个很实际的问题：

“File system metaphor is clean. How do you handle context drift when multiple agents write to the same 'directory'?”

（译：文件系统这个比喻很清楚；多个 agent 写同一个“目录”时，怎样处理上下文漂移？）

我当时的核心意思是：每个 agent 保持自己的 namespace，留下能追溯来源的 append-only 记录；它们先写 intent，再让有明确依据的 evaluator 或 reconciliation 去归并状态。

如果只摘一句，就是：

“they write intent, and the system reconciles.”

（译：它们写下 intent，再由系统完成 reconciliation。）

我当时只能用短回复把方向点出来；这里把我真正想说的展开一点。

同一个目录不是协作协议

目录是一个很好的资源抽象，但它不是一个并发协议。把多个 agent 指向同一个可变位置，等于默认它们对同一份状态有相同理解、会以正确顺序写入，也会在冲突时作出相同判断。现实里这几个默认往往都不成立。

Separate write worlds first; reconciliation is explicit.

所以第一步不是给“共享目录”加更多锁，而是问每个 agent 实际需要看到和写入什么。per-agent namespace 的意思是：每个 agent 都在一块被明确投影出来的资源世界里工作。它不必知道全部全局状态，更不必默认拥有修改其他 agent 工作结果的权力。

这和 AFS 的 Small World 判断一致：资源边界应该先被表达出来，而不是等越界或冲突发生后才猜测谁本来不该看到什么。Small World 本身也不是并发控制算法；它只把“谁能看见什么”这件事说清楚。把这层边界和并发归并混为一谈，反而会让两件事都说不清。

先写 intent，再决定状态

多个 agent 很少需要像几个人同时编辑同一份 Word 文档那样，直接改同一个文件。很多时候，它们真正产生的是意图：发现了什么、建议做什么、依据是什么、对哪个任务或资源作出判断。

把这些意图写成 append-only 的记录，至少保留了两件以后很重要的东西：provenance 和顺序。后来的 evaluator 或 reconciliation 可以看到是哪一个 agent、基于什么输入、在什么阶段提出了哪项变更，而不是只面对一份已经被覆盖过的最终状态。

这不是说 append-only log 自动解决所有冲突。两个意图可能互相矛盾，也可能都基于过时 context。它的价值是把冲突收束到一个被看得见的决定点：归并者有证据可看，而不是让最后一次写入悄悄赢了。

evaluator 不是万能裁判

evaluator 也许是 agent，但它的职责应该更窄：按明确的规则、证据和当前目标归并状态，而不是替所有 agent 产生一个永远正确的答案。

对于高风险或规则尚未写清的变更，人工 review gate 仍然有位置。namespace、可追溯记录和 reconciliation 的作用，是把人需要判断的东西变得更少、更具体，也更容易回看；不是承诺从此不再需要人。

我这里展开的是怎样组织协作状态的一个判断。AFS 论文讨论的也是这类 context engineering 的问题，而不是声称多 agent 协作里的每一种冲突、评估器设计或审查流程都已经有了万能答案。

我想说的是：不要让多个 agent 假装在共写同一份真相。先分开它们的世界，再留下各自的 intent，最后才决定什么能成为共享状态。

继续阅读