多 AI 会话并行开发不失控：一套从实战长出来的工作流，以及它的开源实现

ParallelAgent：让"仲裁者 + 多轨会话"的并行开发自动跑起来 开源地址：https://github.com/YorickFin/ParallelAgent （Apache 2.0）

起因

前几天收到 AI IDE 产品 Trae 发来的产品调查问卷短信。填完问卷后，我顺手打开了它的 Work 模式想看看具体形态——结果这一看，把一个搁置已久的想法重新点着了。要说清这个想法，得先从我一直在用的一套工作流讲起。

一个从实战里长出来的工作流

在过去的项目实践中，我经常需要多个 AI 会话并行干活：改前端的同时补测试、写文档的同时修 bug。单会话串行干，效率上不去；开一堆会话乱干，又很快就失控。

踩过一阵坑之后，我慢慢沉淀出一套"仲裁者 + 多轨 + 文件信箱"的工作流：

• 一个仲裁者会话负责决策：任务怎么拆、拆几轨、谁先谁后，并且持笔写所有协调文档；
• 多条轨道会话（T-A/B/C/D）各自独立上下文，只管自己那一摊活；
• 全程文件留痕：契约块嵌在代码注释里，转达单按轨分节，各轨收工写回执，仲裁者独立实检后进入下一轮；
• 每批结束后回写快照，配合交接手册，任何会话挂掉都能冷启动接力。

这套模式跑起来非常抗造：全程可溯源、不怕会话死亡、不怕上下文压缩——所有关键状态都在磁盘上，会话只是"工人"，文件才是"账本"。

"这不是 subAgent 就能干的事吗？"

写到这里，你可能会问：现在的 agent 产品不都有 subAgent 机制吗，为什么还要自己折腾一套？

我认真对比过这两条路线。subAgent 是"宿主内置的临时工"，我这套是"文件账本 + 常驻工人"，各有各的好：

维度	subAgent 路线	仲裁者 + 多轨路线
接入成本	宿主原生支持，零 hack	需要自己维护一套协议与文档纪律
派活体验	一句话派出，结果自动回传	仲裁者写转达单，靠人转发到各轨
过程留痕	只回传最终摘要，中间过程即弃	转达、回执、证据全部落盘，可溯源可审计
验收方式	信任摘要，难以独立实检	仲裁者拿证据独立实检，不合格打回
会话记忆	一次性，跑完即销毁	轨道常驻，上下文跨批次延续
主会话负担	所有子任务结果灌回主上下文，易膨胀	主会话只读回执与证据，负担可控
抗压缩/抗崩溃	上下文一压缩就丢细节	状态在文件里，冷启动即可接力

一句话总结：subAgent 胜在"自动化"，短板在"黑盒与健忘"；这套工作流胜在"可审计与抗造"，短板在"全靠人肉驱动"。

两条路线的天花板，能不能一次解决？

把各自的短板摆出来，答案就浮出来了：

• subAgent 的短板是结构性的：摘要回传导致过程不可审计，一次性会话导致长任务健忘——这些是它的运行模型决定的，使用方很难改；
• 这套工作流的短板是工程性的：会话间没有消息通道，转达单写好了还得人工复制粘贴逐轨转发，收工与否也得自己盯——说白了，人只是个"人肉邮差"兼任"人肉调度器"。轨道越多，人在消息总线上损耗越大，还经常出现快照漂移（写单和发单之间代码又动了）、发错轨这类"运维税"。

结构性短板改不了，工程性短板却是可以消灭的。理想形态很清晰：把"文件账本 + 常驻轨道"保留下来，再把 subAgent 那种"派活即走、结果自回"的自动化体验嫁接过来——也就是需要一个编排层，把"建会话、派活、收工判定"这些脏活全部自动化，人只在产品决策和异常升级时出场。

这就是 ParallelAgent 的由来。

可行性验证与方案冻结

需要一个具体宿主来验证这个想法。我当时选择以 Trae Work 作为验证对象——它的形态恰好适合承载：同一项目下可以创建多个独立任务会话，各自独立上下文、共享同一文件系统。于是直接在 Trae Work 里开了一个任务，先验证前提、再冻结方案。

第一步：环境实测。 用探针脚本把关键事实摸清楚，而不是靠猜：

• Work 与 IDE 是同一二进制的两个"场景"，Electron 内核（Chromium 142）；
• 加 --remote-debugging-port 启动后，CDP 调试端口可用，能枚举目标、跑 WebSocket 指令；
• 同一项目可以创建多个独立任务会话，各自独立上下文、共享同一文件系统；
• 关键事实：任务之间没有官方的会话间消息通道。

第二步：架构结论。 会话间既然没有官方通道，自动化就必须从应用外层（CDP）或扩展宿主层（插件）接入——好消息是两条路都走得通，可行性成立。这个结论不依赖具体产品：凡是基于 Electron、能开调试端口、支持多会话的 AI IDE，都满足同样的前提。

第三步：方案设计。 核心是"三件套"，正好对应前文的两条短板：

部件	职责	铁律
仲裁者 Skill	判拆分、写契约/转达/快照、发控制信号、读回执独立实检	只决策持笔，不碰重活
轨道 Skill	读转达节、执行任务、写回执	自扫门前雪，不做决策
编排器插件	CDP 建会话/切轨/派发 + 文件信箱 watch	无脑执行，不解析任务内容

编排器插件负责消灭"人肉邮差"：自动建会话、切轨、把固定话术发进各轨，再靠文件 watch 监视回执——回执文件一出现，本轮收工自动判定。文件信箱则原样保留：可审计、可交接、抗压缩的优点一个不丢。

再配两条贯穿全局的安全设计：

• 数据面 100% 文件：裁决、代码、证据、回执全走文件信箱；
• 控制面只传信号：HTTP / 信号文件只含"轨号 + 轮次 + 文件指针 + 固定话术"，绝不含任务内容。这样即使控制层出错，最坏也只是"铃没摇成"，不会把错误内容送进错误的轨。

任务生命周期分为三阶段：奠基串行 → 并行多轨 → 收尾串行，配套拆分判据、收回判据和交接手册。

整个过程里，这些设计文档、探针脚本都是在目标宿主内部完成的——相当于用它设计了它自己的并行编排层，有点自举的味道。

已开源

方案冻结后，我把整个项目以 Apache 2.0 协议开源了：

https://github.com/YorickFin/ParallelAgent

仓库里目前有：

• docs/ — 方案文档：定稿（架构 + 判据 + 接口设计）、探针前的候选设计、生命周期治理、实现路径
• scripts/ — CDP 探针与运维脚本（连通性验证、WebSocket 指令、状态检查）

写在最后

回过头看，这条链路是：日常使用中的一套并行工作流 → 和 subAgent 路线认真对比 → 在具体宿主上完成可行性验证和方案冻结 → 开源。

这套思路本身不绑定任何特定产品：核心协议（仲裁者、轨道、文件信箱、控制面信号）是宿主无关的，仓库里的实现以 Trae 为第一个适配宿主，后续可以平级扩展到其他满足前提条件的 AI IDE。

如果你也在做多 agent 并行方向的尝试，或者对"可审计的多会话协作"有自己的想法，欢迎到仓库交流，Issue 和 PR 都可以。