多 Session 还是多 Agent？
我跑了 27 个 agent 来回答这个问题

TL;DR先看结论

1. 并行本身不产生质量，契约才产生质量。 同样是 5 个 agent 并行写 5 个模块：有契约的那组 6 个文件零接口错误、一次组装成功；没契约的那组 5 套组装方案里 2 个直接白屏，报的是模块加载期的 SyntaxError，不是能慢慢调的运行时 bug。
2. 没有契约时，agent 会把大量算力花在「猜队友接口」上。 无契约组里最慢的那个 agent 跑了 831 秒、10.4 万 token——它自己造了一套假队友模块和 18 条断言来验证自己的猜测。同组最快的只用了 169 秒。
3. 命名分歧不是均匀分布的，它集中在语义最复杂的那个接口上。 5 个互不通信的开发者，具名 import 的命中率高达 24/26（92%）——但唯独 physics 的核心步进函数，三个人给了三个名字（stepPlayer / updatePhysics / stepPhysics），而它恰恰是全场最关键的调用。
4. subagent 拿不到你的对话历史、用户记忆和偏好设置。 实测确认：它只拿到系统提示、任务消息、CLAUDE.md、git status、环境信息和工具/skill 清单。你以为它「知道」的背景，它全不知道。
5. subagent 无法向你提问。 实测它的工具清单里没有 AskUserQuestion，没有 SendUserMessage。它能单向推文件和通知给你，但不能问一句「这个手感对吗」然后等你回答。对游戏开发这是硬伤。
6. worktree 隔离不消除冲突，只是把冲突延后。 两个 worktree 各自干干净净地改了同一行，运行期零干扰——合并那一刻立刻 CONFLICT (content)。
7. 「并行」的收益受宿主并发度硬约束。 这个云沙箱只有 2 核，实测 8 个「并行」agent 是 2 个一批、跑了 4 批。写 workflow 时以为的扇出，在这里是排队。

Part 1机制：其实有四种，不是两种

「多 session vs 多 agent」这个问法本身把选项压扁了。翻官方文档会发现现在是四种并行方式，它们在谁协调、worker 之间能不能说话、文件怎么隔离这三个维度上各不相同。

Part 2探针实测：隔离边界到底在哪

网上关于 subagent「有独立 context」的说法很多，但「独立」到什么程度没人说清。我起了 6 组探针 agent 直接去问、去做，结果如下。标记为实测的都是这次跑出来的

探针 1 · 并行 subagent 共享文件系统，且实时可见 实测

两个 agent 同时启动，各写一个文件，各 sleep 30 秒后列目录。两边都看到了对方的文件，时间窗口确认重叠（A: 1785147960382→1785148004867，B: 1785147960821→1785148006985）。

探针 2 · subagent 继承了什么，没继承什么 实测

我让一个 agent 在不使用任何工具的前提下，如实报告它启动时收到的全部上下文。

探针 agent 的原话很值得抄下来：

它唯一能做的是从环境反推：看到工作目录叫 probe-repo、看到已装的 skill 偏向 iOS 游戏开发和中文 HTML 文档，于是猜「这个账号平时关心这些方向」。这是猜，不是知道。

探针 3 · subagent 无法向你提问 实测

我让一个 agent 逐条核对自己的工具清单：

探针 4 · worktree 隔离：运行期完美，合并期爆炸 实测

两个 agent 各建一个 worktree，各自把 config.js 里同一行的 SPEED = 100 改成不同的值并提交，中间 sleep 20 秒制造重叠。

运行期表现完美：主仓库工作区始终干净（SPEED 仍是 100），两条分支从同一 base 各自前进，没有任何 index.lock 争用或 git 报错。A 甚至在自己 sleep 期间观察到 B 的 worktree 凭空出现，但毫无影响。

然后我把两条分支合并：

$ git merge feat-a
Fast-forward

$ git merge feat-b
Auto-merging config.js
CONFLICT (content): Merge conflict in config.js
Automatic merge failed; fix conflicts and then commit the result.

探针 5 · 真实并发度：说好的并行，其实在排队 实测

我起了 8 个 agent，每个只做一件事：打时间戳、sleep 15 秒、再打时间戳。结果时间戳呈现清晰的四批两两配对：

宿主 nproc = 2，实测最大并发就是 2。8 个 agent 跑完花了 109 秒，真并行的话应该是约 20 秒。另外每个 agent 在 15 秒的 sleep 之外还有约 5 秒的启动与模型开销。

Part 3三臂对照实验

探针回答了「机制是什么」，这一节回答「效果差多少」。

设计

同一份 SPEC.md（一个 640×360 的 canvas 平台跳跃小游戏，硬性拆成 physics / input / level / render / hud / main / index.html 七个文件），三种编排各做一遍：

量化结果

Arm C 到底怎么崩的

5 个开发者各写了一版 main.js，我把 5 个模块凑齐后，逐个用它们组装并放进无头 Chromium：

命名收敛度：比想象中高，但错在了最要命的地方

把 5 个人的具名 import 和真实作者的导出做交叉比对：

具名 import 命中率：24 / 26 = 92%

命中的（大家不约而同）：
  input.js  : createInput      ✓ 三个人都猜对
  level.js  : getPlatforms     ✓
  render.js : render           ✓
  hud.js    : drawHUD          ✓

没命中的（全部集中在同一个接口）：
  physics.js 实际导出 : stepPlayer / stepBody
  dev2 猜的           : updatePhysics   ✗
  dev4 猜的           : stepPhysics     ✗

三个产物长什么样

三个 PASS 的版本我都截了图（无头 Chromium，跑 2.5 秒后按住右键 + 空格）：

Arm A · 1,057 行星空、远山、圆角平台、带眼睛的角色、生命格子、操作提示

Arm B · 657 行严格按契约，一个像素的自由发挥都没有

Arm C · 1,628 行视觉最丰富，也最臃肿，5 个组装方案里 2 个白屏

为什么会这样

把 Arm C 那 5 个 agent 的自述读一遍，机制就很清楚了。没有契约时，一个理性的开发者会做三件事，每一件都在烧钱：

1. 放弃具名 import，改用命名空间 + 候选名表。 dev3 的原话：「用命名导入的话，队友只要名字差一个字母，浏览器就是链接期 SyntaxError 直接白屏。」于是它给每个符号准备了一串候选名，逐个尝试。
2. 给共享状态做属性别名对冲。 好几个 agent 用 Object.defineProperty 把 state.vy 和 state.player.vy 指向同一份存储，还顺手加了 w↔width、onGround↔grounded——纯粹因为不知道队友会用哪个名字。
3. 自己造一套假队友来验证猜测。 dev3 在自己目录里建了个 .selftest，写了三套完全不同风格的假模块（一套故意跟自己的猜测对着干），跑了 18 条断言。这一步就是它比同组慢 4 倍的原因。

它甚至在报告里留了这么一句，很能说明问题：

——防御性编程能挡住命名分歧，挡不住语义分歧。而一份 250 秒就能写出来的契约，把这三件事全省了。

Part 4七条结论

1 · 契约是并行的前置条件，不是可选项

Arm B 用 256.6 秒写契约，换来的是零接口错误、一次组装成功、代码量最小。Arm C 省掉了这 256.6 秒，代价是总工作时长翻倍、40% 的组装方案白屏、以及两个模块重复实现同一个函数。契约不是开销，是杠杆。

2 · 并行不省总工作量，只压缩关键路径

A 串行 885.6s，B 契约并行总工作量 849.5s——几乎相等。并行没有让活变少，它只是把 512.5 秒的关键路径压出来了（比串行快 42%）。所以：如果你不在乎墙钟时间，并行没有任何好处，还多烧 3 倍 token。

3 · 并行的收益上限由你的机器决定，不由你的脚本决定

本机 2 核，实测并发上限就是 2。Arm B 的理想关键路径是 512.5s，实测墙钟 1012.7s——并行度打了对折还多。写 workflow 前先看 nproc。

4 · subagent 是「哑的」：不知道背景，不能提问

它拿不到对话历史、记忆、偏好；它不能问你问题。这两条合起来意味着：凡是需要「你说了算」的决策，都不能下放给 subagent。它只适合做那种「目标明确、判据客观、做完给结论」的活。

5 · worktree 管的是「同时写」，不管「写得不一样」

两个 worktree 并发写零冲突，合并立刻 CONFLICT。隔离手段解决的是物理冲突，语义冲突只能靠契约或人工裁决。

6 · 「同一个模型应该能对上」是危险的直觉

92% 的命名收敛度会让人产生这个错觉。但剩下 8% 精确落在最核心的接口上，而且失败方式是硬失败（白屏），不是软退化。

7 · 契约压制发挥，别拿它去管创意

Arm B 的产物最规整也最朴素。做基础设施这是好事；做「手感」「关卡节奏」「美术风格」这类需要发挥的部分，不该用同一套并行流水线去压。

Part 5决策 SOP

决策树

并行开工前 checklist

下面这份直接照着走。前四条是硬门槛，缺一条就不要开并行。

硬门槛

• 契约已写好并落盘。 精确到：共享状态的每一个字段名 + 类型 + 默认值 + 谁有权写；每个模块的导出函数名 + 参数顺序 + 参数类型 + 返回值；调用顺序。含糊的契约等于没契约。
• 文件所有权已划清。 一个文件只有一个主人。划不清的那部分，留在串行里做。
• 「没人认领的活」已经点名。 Arm C 里 index.html 五个人都没写——不在任何人职责里的东西，就是没人做。清单化，指派到人。
• 验证方式已经能自动跑。 并行的产物必须有一个客观判据（能编译 / 测试通过 / 能启动无报错）。没有自动判据，你会淹死在人工 review 里。

写 prompt 时

• 把主会话里说过的关键约束手动复述进每个 agent 的 prompt——它们看不到你们的对话。
• 能固化的规则写进 CLAUDE.md：这是唯一自动进到每个 subagent 上下文的东西。
• 明确写「你不负责什么」，不只写「你负责什么」。drawGameOver 被两个模块各写一遍，就是因为没人被告知这不归自己。
• 禁止 agent 越界读别人的目录——否则你测的不是并行，是伪装成并行的串行。

规模与成本

• 先看 nproc。并发上限约等于机器能给的核数，不是你脚本里写的数字。
• 3–5 个 worker 是甜点区（官方建议与本次观察一致）；超过 8 个，协调开销开始吃掉并行收益。
• 预算：并行大约 3 倍 token（本次 A→B 是 3.2×）。官方公开数据是多 agent 相对聊天约 15×、单 agent 约 4×。
• 如果只是想省自己的时间而不是墙钟，别并行。

合并时

• worktree 分支合并前，先跑一次自动验证，别等冲突解完才发现接口对不上。
• 接口不一致时，改调用方还是改被调方，按契约裁决，不要「谁先合谁赢」。
• 合并后重跑一次全量验证——两个模块单独都对，合起来不一定对。

session 该怎么切

Part 6iOS / SpriteKit 专章

前面的通用结论在 Xcode 项目上有一个额外的放大器：project.pbxproj。

为什么 iOS 项目对并行格外不友好

.pbxproj 是一个单体 plist，每次增删或移动文件，文件引用和组引用都会更新。两个 session 各加一个 Swift 文件，就是同一个文件的相邻区域各写一遍——git 的自动合并在这种结构上表现很差。而这正是并行开发最常发生的操作。

三档缓解方案，按投入排序

档位 1 · 不改工程结构（今天就能做）

• 写码 session 保持唯一。 这是成本最低、收益最高的一条。其它 session 只做不碰 .pbxproj 的事：素材、调研、文案、数值表。
• 如果一定要并行写码，约定「本轮谁都不新增文件」——只改已有文件的内容。改内容不动 .pbxproj，冲突风险掉一个数量级。
• 新增文件集中在一个人手上，批量加完再分发。

档位 2 · 用 Xcode 16+ 的文件系统同步组

• 右键 group → Convert to Folder，把手工维护的 group 换成跟文件系统同步的文件夹。此后新增文件不再写 .pbxproj。
• 转换前先让本地目录结构和 Xcode group 结构对齐，否则会一次性产生巨大 diff。

档位 3 · 工程文件生成化 / 模块化

• XcodeGen 或 Tuist：用 YAML/Swift DSL 描述工程，源文件用 Sources/**/*.swift 通配符匹配，.pbxproj 变成生成物、不进版本库，冲突从根上消失。
• 按域拆成本地 Swift Package：Gameplay / Rendering / Audio / UI 各一个包，每个包一个主人。代价是编译和索引变慢。

SpriteKit 游戏的 session 排布建议

Part 7本次没验证的

把话说全，下面这些是这次没测到或测得不干净的，结论不要外推：

• 真正的多 session 没有被直接测量。 我在这个环境里开不了第二个 Cowork session。Arm C 是用「独立目录 + 禁止跨读 + 无共享契约」模拟的，它复现了多 session 的信息隔离，但没复现跨天、人在回路、上下文重新灌注这几维。
• Arm C 的隔离是自报的。 5 个 agent 都声称没读别人目录，我没有逐条核对 transcript 去证伪。
• 墙钟数据被并发上限污染。 本机 2 核，三臂之间还互相抢占。表里的「理想关键路径」是按各 agent 实测时长重算的模型值，不是实测墙钟。
• n = 1。 每臂只跑了一次，没有重复实验，没有方差估计。831 秒那个离群值可能不可复现。
• 任务规模偏小。 一个 600–1600 行的小游戏，跟一个真实的 iOS 游戏项目差着量级。契约的价值大概率随项目规模上升，但这次没测。
• 没测长会话的上下文衰减。 多 session 最重要的收益之一——突破上下文总量——本次完全没有直接测量，只能引用外部研究（见来源）。
• Agent teams / background agents 只读了文档，没实跑。 它们是 Claude Code CLI 的能力，不在本次环境里。

附录来源

实验产物（本次生成）

• 探针 workflow：14 个 agent，419,907 tokens，369.7 秒
• 三臂 workflow：13 个 agent，755,388 tokens，2266.2 秒
• 验证工具：Playwright + Chromium 无头运行 7 次；ES module 导入导出静态交叉分析

官方文档

• Create custom subagents —— 上下文继承清单、并发/总量/嵌套三个限制、fork 机制、resume 机制
• Run agents in parallel —— 四种并行方式的官方对比表
• Orchestrate agent teams —— teammate 互相通信、共享 task list、不自动隔离文件、3–5 人建议
• Manage agents with agent view —— 后台独立 session、自动 worktree 隔离、配额线性消耗
• Run parallel sessions with worktrees —— --worktree、.worktreeinclude、桌面 app 每个 session 自动分配 worktree
• How we built our multi-agent research system —— 多 agent 相对单 agent +90.2%；token 约 15× / 4×；token 用量解释 80% 性能方差；并明确指出大多数编码任务的可并行性低于研究任务

实践与研究

• The Code Agent Orchestra —— 3–5 人甜点区、一文件一主人、「瓶颈已从生成变成验证」
• From Conductor to Orchestrator —— Ralph loop、计划先审批、每 3–4 个 builder 配 1 个 reviewer
• Context Rot —— 18 个模型全部随长度退化；中段信息准确率掉 30%+；agent 超过 35 分钟后开始退化，时长翻倍失败率翻四倍
• Strategies to avoid merge conflicts in Xcode Projects —— 同步组、XcodeGen/Tuist、按模块拆包
• Run Multiple Claude Code Sessions in Parallel With Git Worktrees —— 社区 worktree 并行实践