四个AI智能体同时改一个文件会怎样？Git真的够用吗

当多个智能体争抢同一份文件

在多智能体（multi-agent）系统的设计中，一个被反复追问的问题是：既然要让智能体共享持久化状态，为什么不直接用 Git？毕竟 Git 擅长版本管理、分支与冲突处理，看起来天然适合。

一位开发者在 Reddit 上分享了自己的实测过程。他此前提出的观点是：文件系统为智能体提供了一个熟悉的持久化状态接口。但接口只是起点——真正的多智能体系统还需要围绕访问控制、故障恢复和并发修改的完整基础设施。于是他设计了一个具体实验来验证"Git 是否足够"。

实验设计：四个智能体改写同一条风险记录

实验灵感来自法律 AI 公司 Harvey 的一个工作流：一场小型公司收购审查。四个智能体读取相同的交易文档，各自更新同一条"客户风险记录"中的不同字段。

作者分别用两种方式跑了这个工作流：一种是他自己构建的 AgentWS 工作区系统，另一种是用受保护的 Git worktree 来复现相同的状态变更。结果是两种方式都达到了相同的最终记录，但过程暴露出的工程负担截然不同。

在这个测试中，系统需要应对三类典型的真实场景：

• 越权写入被拦截：每个智能体都受访问控制列表（ACL）约束，超出职责范围的文件改动会被直接阻止。
• 中途故障可恢复：一个 worker 在执行到一半时宕机，它已做出的文件改动仍保留在工作区中，接替的智能体从保存的进度继续，而不是从头重做。
• 并发更新不丢失：智能体在不同时间完成任务，过期的更新无法悄悄覆盖已被接受的工作，所有冲突的更新都保留下来供人工复查。

Git worktree 是 Git 的一项内置功能，允许同一个仓库在文件系统上同时拥有多个独立的工作目录，每个目录可以检出不同的分支。在多智能体场景下，理论上可以为每个智能体分配一个独立的 worktree，使它们在互不干扰的文件副本上操作，完成后再合并回主分支。这也是"用 Git 做智能体状态共享"这一思路的核心机制。然而 worktree 本身只解决了文件隔离问题，并不内置权限控制（谁能写哪个文件）、进程级别的故障检测与恢复，以及跨 worktree 的细粒度冲突裁决——这些都需要在 Git 之外额外实现。

真正的差距：你得自己补多少东西

实验的核心结论不在于最终结果谁对谁错，而在于"为了达到相同行为，我需要额外构建什么"。

作者指出，一个 Git worktree 仅仅是起点。要让它表现出上述三种能力，他不得不额外加上：操作系统级权限、持久化 worktree、隔离的 Git 元数据、提案分支（proposal branches）、受保护的更新机制，以及冲突导出功能。

换句话说，Git 能追踪文件版本，但它并不管理运行中智能体的完整工作区生命周期。当你把这些缺失的能力一层层补齐时，实际上是在 Git 之上重新造了一个工作区系统。

文中提到的**访问控制列表（ACL，Access Control List）**是一种细粒度的权限管理机制：为每个资源（文件、目录或字段）维护一张"谁可以做什么操作"的清单，区别于传统 Unix 文件系统以"所有者/组/其他人"三元组定义的粗粒度权限。在多智能体场景中，ACL 允许将权限绑定到具体的智能体角色——例如"法务智能体只能修改合规字段，财务智能体只能修改估值字段"——从而在运行时自动拦截越权写入，而无需依赖智能体自身的提示词约束。Git 的权限模型通常依赖操作系统层或托管平台（如 GitHub 的 branch protection），并不提供字段级或操作级的细粒度 ACL，这是它在智能体工作区场景中的一个结构性缺口。

为什么智能体负载越大，Git 越吃力

这里的逻辑值得展开。Git 的设计假设是"人类开发者在相对低频、显式的时点提交代码"，它的分支、合并、冲突解决都建立在人工介入的前提上。而多智能体工作流的特征正好相反：高并发、异步完成、随时可能中断、需要程序化的权限边界。

当智能体数量和任务频率上升，基于 Git 的设计会离理想方案越来越远。团队最终会发现自己把大量精力花在"围绕 Git 搭建缺失的工作区系统"上——权限、恢复、并发治理这些本该由基础设施承担的职责，被迫由应用层反复实现。

作者推销的 AgentWS 正是把这些职责打包进一个统一的工作区接口。需要注意的是，这是来自单一来源的产品视角，AgentWS 的实际成熟度和适用范围仍有待更广泛的验证。但即便抛开具体产品，这个实验提出的问题本身很有价值。

这里涉及一个软件工程中的经典概念——阻抗失配（impedance mismatch）：当一个工具的设计假设与实际使用场景的特征存在根本性差异时，强行适配会产生大量"胶水代码"和隐性复杂度。Git 的核心设计围绕"人类在低频、显式时点提交"这一假设优化：冲突解决依赖人工判断，分支合并需要明确的操作意图，权限模型以仓库为粒度。多智能体工作流则是高频、异步、程序化的——智能体不会"思考后再提交"，它们随时写入、随时可能崩溃、需要毫秒级的权限校验。阻抗失配越大，填补空白所需的额外代码就越多，最终应用层承担了本该属于基础设施的职责，形成文中所说的"隐性工程债务"。

给多智能体工程师的启发

对正在落地多智能体工作流的团队来说，这个实验至少提供了几点思考：

其一，状态共享不是简单的"文件读写"，而是涉及访问控制、故障恢复和并发冲突的系统工程问题。其二，用熟悉的工具（如 Git）凑合，往往会在规模扩大后产生隐性的工程债务。其三，在设计阶段就应该明确：权限边界、断点续跑、冲突裁决这三类逻辑究竟"住在哪里"——是散落在各个智能体的提示词和代码里，还是收敛到一个专门的工作区层。

作者最后抛出的问题也正是关键：如果你在运行多智能体工作流，这套逻辑今天到底存在于你系统的哪个位置？这是每个搭建 Agent 基础设施的人都该认真回答的问题。