AI 时代的 Git 革命：多 Agent 并发开发的新基础设施

在 x-cmd v0.10.1 版本中，我们优化了 repo 模块。它关注的问题是：当 Agent 开始参与真实开发，代码仓库应该如何被管理？

一个项目，正在被越来越多的 Agent 同时访问

过去的软件开发方式很稳定：一个开发者、一个代码仓库、一个工作目录。

但随着 Coding Agent 的普及，开发流程正在出现新的变化。

一个项目可能同时有多个角色参与：一个 Agent 负责实现新功能，一个负责修复 bug，一个负责补充测试，还有一个负责代码审查。这些任务彼此相关，但又需要保持独立。

例如，一个 Agent 正在重构认证模块，另一个 Agent 想验证一种新的实现方式。如果它们直接操作同一个目录，修改就会互相影响。一个 Agent 改动的文件，会改变另一个 Agent 看到的环境。

多 Agent 协作首先遇到的问题不是"代码怎么生成"，而是多个 Agent 应该在哪里工作。

给每个 Agent 一个 clone，简单但不够优雅

最直接的方式，是给每个 Agent 一份独立代码。

bash 复制代码

git clone repo

然后：

text 复制代码

project-agent-a/
project-agent-b/
project-agent-c/

每个 Agent 有自己的目录，互不干扰。

一些自动化开发环境也采用类似思路：任务开始时创建一个新的工作目录，通常放在临时位置，例如：

text 复制代码

/tmp/task-001/project
/tmp/task-002/project

对于一次性的任务，这种方式非常合理。它提供隔离：一个任务失败，不影响其他任务；一个实验结束，可以直接删除环境。但当 Agent 从"临时助手"变成长期参与项目的协作者时，问题开始出现。

多份代码副本，会带来新的管理成本

第一个问题是重复。同一个仓库，Agent A、Agent B、Agent C 各 clone 一份，每个副本都包含自己的 Git 数据。大型项目中，这意味着大量重复存储。

第二个问题是难以追踪。随着任务增加，目录可能变成这样：

text 复制代码

project/
project-fix/
project-test/
project-refactor/
project-agent-review/

或者这样：

text 复制代码

/tmp/task-123/project
/tmp/task-456/project
/tmp/task-789/project

过了一段时间，人很难回答：哪个目录对应哪个任务？哪个 Agent 还在使用？哪个工作区可以继续复用？代码还在，但工作空间开始失去秩序。

多 Agent 需要的是更轻量的隔离

其实 Git 早已经提供了一种更适合这种场景的能力：Worktree 。它解决的问题是：一个仓库，如何拥有多个独立工作目录。

例如：

text 复制代码

project.git
project/
project@feature-a/
project@bugfix/
project@test/

这些工作区有自己的文件状态，可以对应不同分支，修改不会影响其他工作区。但它们共享同一个 Git 仓库。

相比复制多个 clone，worktree 提供了一种更适合并行开发的模型：多个工作空间，共享同一份代码历史。这正符合多 Agent 的需求。

Worktree 解决了技术问题，但还缺少工作流

Git 提供了 worktree，但对于 Agent 来说，仅仅有这个能力还不够。还需要解决：仓库应该放在哪里？Agent 如何找到已有项目？不同任务创建的工作区如何命名？任务结束后如何清理？

如果每个 Agent 都按照自己的方式管理，有的放在 ~/projects/，有的放在 ~/workspace/，还有的放在 ~/tmp/，最终仍然会产生新的混乱。

因为多 Agent 时代需要的不只是一个命令，而是一套稳定的代码工作空间规则。

x repo：让 Agent 共享统一的代码工作空间

这就是 x repo 想解决的问题。它用于统一管理 agent、开发者和 CI 环境中的代码仓库位置与工作空间。

它不是替代 Git。Git 负责记录代码变化，worktree 负责提供多个独立工作目录，而 x repo 负责把这些工作空间组织起来。

默认情况下，仓库集中管理在 ~/.x-repo/。一个仓库对应：

text 复制代码

.bare/project.git

多个工作区对应：

text 复制代码

project/
project@agent-a/
project@fix-login/
project@test/

这样，不同 Agent 可以拥有独立工作区，不需要重复 clone，开发者、Agent 和 CI 可以共享同一套仓库布局。

比如 Agent A 接到修复登录 bug 的任务，它不需要重新 clone 仓库，而是直接在固定位置拿到一个独立工作区：

bash 复制代码

x repo wt myrepo fix-login

执行后会得到类似 project@fix-login/ 的工作目录。任务在这里进行，不会污染其他工作区。完成后可以直接清理：

bash 复制代码

x repo wt rm myrepo fix-login

整个工作空间生命周期都可以被统一管理。

让 Agent 遵循统一的仓库工作流

不过，真正重要的并不是增加几个 Git 命令。因为 Agent 最大的挑战，不只是"会不会执行命令"，而是它是否知道什么时候应该使用这些能力。

x repo 的意义在于，它把一套工作约定固定下来：优先复用已有仓库 、使用固定布局管理代码 、多任务时创建独立工作区 、完成任务后正确清理。用户不需要每次通过 prompt 告诉 Agent："不要重新 clone。""请创建 worktree。""代码放在哪里。"这些协作规则已经成为代码工作空间的一部分。

AI Agent 时代，代码工作空间也需要基础设施

过去 Git 解决的问题是"如何保存和协作代码"。而 AI Agent 带来的新问题是：多个智能体产生的代码工作空间，如何保持有序？

未来的软件开发，不只是人与代码的关系，而是人与多个 Agent，共同工作在同一个代码环境中。