两个智能体，一个仓库

实际会出什么问题#

在一个仓库里跑一个编程智能体，是已经解决了的问题；跑两个就不是。两个智能体持有同一份工作树，而彼此都不知道对方存在：一个正在改文件，另一个切了分支；一个把刚被对方改写的文件加进了暂存区；跑测试时读到的是别人半截的改动。这些都不会报错——失败比报错更安静、也更麻烦：你最后拿到一份没有任何一个智能体打算做出的 diff，而且没人解释得清它是怎么来的。

常见的绕法都比看起来更糟。给每个智能体各克隆一份仓库，会把整部历史复制一遍，而且各克隆之间看不到对方的分支。让智能体排队跑，等于放弃了要两个的理由。而告诉每个智能体「只准改这几个文件」是一条没有强制力的约定——只要有一次它对边界的判断是错的，你就又回到那份说不清的 diff 上。

Linked worktree：一个仓库，多份检出#

Git 从 2.5 起就带着答案。`git worktree add` 会给你另一个工作目录，背后是同一个对象库、同一套引用——是第二份检出，不是第二个仓库。每份 worktree 待在自己的分支上，各有自己的索引与 HEAD，因此两个智能体在两份 worktree 里改代码，看不到对方未提交的改动，不会把对方的文件加进暂存区，也移动不了对方的分支。

而它们共享的，正是复制起来最贵的那部分：对象、历史、远端，以及任何一边建过的所有分支。所以工作始终是可合并的。智能体 A 可以从 B 一小时前推上去的东西起分支；你可以把两份 diff 对着同一个基线审；事后不需要在多个克隆之间做对账。

# one repository, two checkouts, two branches
git worktree add ../feature-a -b feature-a
git worktree add ../feature-b -b feature-b

# each has its own HEAD and index; the objects are shared
git worktree list

为什么把它接进了会话#

上面那套手工做两个分支还行，做六个就烦了。所以在 Mirasim 里，一条会话可以直接起在自己的 linked worktree 上，基线分支由你选；而你正在看的那个面板就是那份 worktree——文件树、终端、diff、你要审的那次提交，都属于它。最多六个面板同时跑，各在自己的 worktree 里。

日常真正起作用的一点是：你不再需要想着它。你不用记哪个终端在哪个分支上，也不用记哪个智能体被交代过不许进哪个目录。每个面板就是一个智能体干活的地方，而隔离是这个地方的属性，不是一条要靠智能体自觉遵守的规定。

有一点值得直说：并行会话是几个智能体同时各干自己的一件事，不是一个编排器把一件事拆给几个工人。这里没有任何东西会跨六个面板做规划，也不会替你把它们的产出合起来——那件事由你在审阅时做，面前摆着几份 diff。