并行运行智能体

本指南介绍如何同时运行多个智能体，而不让它们互相覆盖对方的工作。

隔离的单位是空间，而不是智能体

当工作在一个空间中启动时，Control Center 会为该空间中每个已注册的仓库预配一份写时复制检出，放在该空间自己的根目录下，所用分支派生自工作区的分支模板。空间中的每个智能体随后各自获得一个叠加工作目录——但这些叠加目录共用该空间的 repos/ 目录。

因此：

不同空间中的两个智能体在不同的检出、不同的分支上工作。这才是真正的隔离。
同一空间中的两个智能体在同一个检出、同一个分支上工作。它们的叠加路径不同，因此派发路径锁（只有当两次运行请求完全相同的工作目录时才会把它们串行化）也不会把它们串行化。它们可能同时写入同一批文件。

由此得出的规则是：每个并行任务用一个独立的空间。

只要智能体会编辑文件，就应当采用这一做法。

在单个空间中，@提及不止一个智能体：

@alice refactor the auth module. @bob review what alice lands.

两个智能体会并行派发，并以发送者为标记汇入同一个空间。由于它们共用该空间的检出，这种做法适合协作——一个写、一个读，或者两个智能体对同一棵代码树进行推理——而不适合两项互不相干的编辑。

内置的 pr_review 模板就是随产品提供的扇出示例：多个审查节点由同一个触发器并发运行，再由一个 Consolidate (join) 节点把它们的发现汇总成一份报告。从流水线界面运行它，每个审查者都会并行派发。

当你添加或连接步骤时，流水线编辑器会隐藏终端哨兵，并把它的接线改为等待每一个仍活动的汇点，因此你自己画出的分支确实会运行。

可观测性 → 实时（侧边栏页脚 → 可观测性，然后是实时标签页）会列出该工作区的智能体名册，每秒刷新一次：状态（运行中 / 空闲 / 已停驻 / 已中止）、每个智能体正在做什么、它最近一次运行的令牌数与费用，以及用于终止正在运行的进程的终止控件。选中某一行会停靠出一个实时转录抽屉。

设置 → 工作区 → 智能体显示的也是这份名册，但状态词汇不同，以需要注意为先，并且来自每个智能体的运行历史——运行中、已阻塞、失败、空闲、从未运行——排序时让任何需要关注的内容浮到顶部。每个智能体的日志标签页保存它自己的运行历史。

这两个界面都限定在当前活动的工作区范围内。

跨空间时，每个空间都在自己的分支上，因此冲突会在你合并第二个 pull request 时以普通的 Git 合并冲突形式出现。像处理任何合并冲突那样解决它即可。

在同一个空间内部，既没有分支边界也没有锁：智能体在实时写同一批文件，落败的一方会被直接覆盖。如果你发现自己想让两个智能体在同一个空间里编辑，那就把工作拆到两个空间里。

无论哪种情况，都可以这样减少冲突：

每个运行中的智能体都会消耗：

一份空间检出——在写时复制可用时，它在磁盘上的开销可以忽略；在 Windows 上则是一个 git worktree。无法使用 reflink 的文件系统会让预配失败，而不是退回复制。
服务器主机上的一个进程
模型令牌，按智能体累加

费用会汇总到可观测性 → 洞察。请注意，普通的交互回合没有费用上限；请参见管理成本，了解确实设有上限的那两条命令。