当四个 AI 代理同时更新同一个文件时会发生什么？

在我上一篇文章中，我提出文件系统为智能体提供了一个熟悉的方式来操作持久化状态。但接口只是一个起点。多智能体系统仍然需要一套基础设施来处理访问控制、故障恢复和并发修改。最常见的问题是：这不就是 Git 吗？于是我进行了一次测试。我仿照 Harvey 的一个工作流，重建了一个小型公司收购审查流程。四个智能体阅读相同的交易文档，并更新同一条客户风险记录中的不同字段。我先在 AgentWS 上运行了这个工作流，然后用受保护的 Git worktree 重放了相同的状态变更。两种方式都得出了相同的最终记录：每个智能体都受到访问控制列表（ACL）的限制，因此超出范围的文件修改被阻止。一个工作进程中途关闭了，但它的文件修改仍然保留在工作区中，因此接替者直接从已保存的进度继续，而不是重新执行这些工作。各智能体的完成时间不同，过期的更新无法悄悄覆盖已被接受的结果，而每一个冲突的更新都保留下来供审查。区别在于我需要自行构建多少东西。Git worktree 只是一个起点。为了获得同样的行为，我不得不添加操作系统权限、持久化 worktree、隔离的 Git 元数据、提案分支、受保护的更新以及冲突导出。AgentWS 将这些职责封装进一个统一的工作区接口中。Git 跟踪文件版本，但它并不管理运行中智能体的完整工作区生命周期。随着智能体工作负载的增长，基于 Git 的设计离理想方案越来越远，团队最终不得不围绕 Git 自行搭建缺失的工作区系统。AgentWS 直接提供了这套系统。如果你在运行多智能体工作流，目前这套逻辑是放在哪里实现的？