两个 AI 代理需要一个实时内存文件

Source: Dev.to

问题

并行 AI 编码看起来很神奇，直到两个代理开始各自维护自己的现实版本。一个代理记得聊天历史中的规则，而另一个代理读取的仓库备注已经过时。工作流在一个地方更新，却没有在另一个地方同步，导致用户重复相同指令、手动转发批准、清理本不该出现的冲突。实际上，用户成了同步层。

根本原因

问题不在于“记忆差”。而是 多个可写的记忆表面。

• 如果一个代理把交接文件当作实时状态，另一个代理把另一个文件当作实时状态，并且两者都依赖线程记忆，系统就没有明确的权威。漂移是必然的。
• 并行编辑会出现：
  • 没有单一地点可以检查另一条线是否活跃
  • 没有明确的所有权边界
  • 没有记录变更、原因以及不该触碰的内容的习惯

这些代理缺乏关于真相所在的共享契约。

后果

• 指令重复
• 编辑被覆盖
• 批准不明确
• 当后期出现问题时，历史记录不可用

本地的优化（在两个地方记录、让用户再次确认、在检查另一活跃通道前就开始工作）会产生全局负担。系统表面上看似协作，实则悄悄依赖用户保持一致性。

解决方案

使用 唯一的可变协作记忆文件，让其他所有内容指向它。然后添加四条规则：

1. 当前真相只有一个归宿。
2. 历史被保留，而不是悄悄删除。
3. 跨代理审查是直接的。
4. 并行工作在预检后启动。

简单模板

在实时记忆文件中保留一个小的 Active Work 区块：

owner: Codex
scope: admin workflow cleanup
started: 2026-04-29 08:30 Vienna
do-not-touch: app/admin/* until handoff

这一个区块把 “我以为那里没人” 变成可避免的错误，而不是借口。

实施指南

如果多个 AI 代理触及同一代码库，协作系统就成为产品的一部分。应优化以下方面：

• 单一实时记忆来源
• 明确的临时所有权
• 直接的代理间审查
• 可追溯的历史记录

否则用户将不得不手动进行项目管理，而代理看似自主。那并非自动化，而是外包的协调工作。