Code Agent 团队编排与基于 Worktree 的并行会话有何差异？
Code Agent 团队编排与基于 Worktree 的并行会话并不是两种互斥方案。前者解决“多个执行者怎样共同完成一个目标”，后者首先解决“多个任务怎样在同一仓库中拥有彼此隔离的文件、索引和分支状态”。如果只是把几项边界清晰的工作同时交给多个会话，Worktree 加人工协调通常已经够用；如果任务之间存在依赖、需要交换发现、动态改派工作并由统一角色验收，才需要真正的团队编排。
先区分三个容易混在一起的概念
讨论并行编码时，经常把“多会话”“Worktree”和“多 Agent 团队”当成同义词。它们实际位于不同层级。
并行会话是运行方式
并行会话指同时打开多个独立的 Agent 上下文。每个会话有自己的对话历史、任务描述和推理过程，可以同时分析不同问题。终端复用器、桌面客户端或云端任务面板都能承载这种模式。它回答的是“能否同时运行”，却不自动回答“谁负责拆分任务”“任务之间怎样传递信息”以及“最终由谁决定可以合并”。
Worktree 是工作区隔离方式
Git Worktree 允许一个仓库关联多个工作目录，并让它们同时检出不同分支或提交。各工作树拥有独立的 HEAD 和索引，因此一个 Agent 切换分支或暂存文件时，不会直接改变另一个 Agent 的工作目录。与此同时，它们仍共享同一个对象库和大部分仓库级配置，所以创建速度和磁盘开销通常优于完整复制仓库。
这种隔离很重要，但并非容器级隔离。多个 Worktree 仍可能共享数据库、端口、缓存目录、包管理器全局状态、外部服务账号以及某些仓库配置。两个 Agent 即使编辑的是不同目录，也可能同时执行迁移、占用同一测试端口或覆盖同一生成物。因此，“每个会话一个 Worktree”只能消除一部分文件状态冲突，不能替代运行环境治理。
团队编排是协作控制方式
团队编排关注的是任务图和信息流。一个协调者会把目标分解成子任务，指定负责人，追踪依赖和完成状态，并在结果返回后决定继续调查、返工还是进入集成。成熟的实现还会限制并发数、传递必要上下文、收集证据、安排审查，并处理某个子任务失败或结论冲突的情况。
所以，团队编排可以把 Worktree 当作执行环境，也可以让多个只读研究任务共享同一工作区。反过来，多个 Worktree 完全可以由人手工管理，而不引入任何 Agent 间通信。把两者放在同一维度比较，容易误判真正的成本。
二者最关键的差异
任务分解由谁完成
Worktree 并行通常要求操作者提前定义边界，例如让会话 A 修改认证模块，让会话 B 补充接口测试，让会话 C 更新文档。只要边界稳定，这种方式简单透明，操作者也能清楚知道每个分支为何存在。
团队编排则允许协调者在执行过程中继续分解。例如调查性能下降时，协调者可以先派出数据库、网络和应用三个诊断任务；数据库方向发现锁等待后，再新增索引分析与事务追踪任务。此时任务结构不是一开始就完全确定，而是随着证据展开。
信息是否能横向流动
独立会话默认不知道其他会话发现了什么。人需要把关键结论复制到另一个上下文，或者等待各分支完成后统一审阅。这种弱耦合反而适合互不依赖的工作，因为不会产生大量通信噪声。
团队编排通常提供消息、共享任务状态或集中式产物，让一个 Agent 的发现能够改变另一个 Agent 的行动。但通信并非越多越好。完整转发所有日志会浪费上下文，也可能让错误假设迅速扩散。有效的编排应传递结论、证据位置、接口约束和待确认问题，而不是复制全部推理记录。
依赖怎样被表达
在手工并行模式中，依赖往往存在于操作者的脑中。比如数据库迁移必须先确定字段，API 实现完成后前端才能接入。如果所有任务同时启动，下游 Agent 可能依据尚未稳定的接口写出大量需要返工的代码。
编排系统可以显式表达“阻塞”“可并行”“等待验收”等状态，只在前置条件满足后调度任务。它的价值不只是启动更多 Agent，而是避免不该并行的工作被强行并行。对于具有明显关键路径的改造，这一点通常比会话数量更重要。
完成标准怎样收敛
多个 Worktree 各自通过测试，不代表合并后仍然正确。不同分支可能修改同一接口、依赖相反的设计假设，或者分别通过局部测试却破坏端到端流程。手工模式下，操作者负责比较差异、解决冲突、运行集成测试并决定取舍。
团队编排可以设置专门的集成或审查角色，将“代码已经生成”和“目标已经满足”区分开。验收应基于可观察证据，例如测试命令、静态检查、迁移回滚结果和需求清单，而不能只接受子 Agent 的完成声明。编排并不会自动保证质量，它只是提供一个更系统的收敛位置。
Worktree 并行会话适合什么任务
当子任务边界明确、依赖很少、合并顺序容易控制时，优先选择简单的 Worktree 并行。例如同时修复三个互不相关的缺陷、分别为多个模块补测试、比较两种实现方案，或者让一个会话只做代码审查。此时人工维护一张短任务清单往往比引入协调 Agent 更可靠。
一个最小流程可以为每项任务创建独立分支和工作树：
git worktree add ../repo-auth -b agent/auth-fix main
git worktree add ../repo-tests -b agent/api-tests main
git worktree list
随后分别在两个目录中启动会话。每个会话都应获得明确的文件范围、验收命令和禁止修改项。完成后先在各自分支提交，再由主工作区按确定顺序合并并运行完整测试。任务结束后，确认分支内容已保留，再移除关联工作树：
git worktree remove ../repo-auth
git worktree remove ../repo-tests
git worktree prune
不要让两个 Worktree 检出并修改同一个普通分支。更稳妥的做法是每项任务使用独立分支，或者为纯实验使用 detached HEAD，并在需要保留结果时及时创建分支。还应为开发服务器分配不同端口，为临时数据库和构建缓存设置独立路径。
什么时候值得使用团队编排
第一类场景是探索性问题。故障原因未知、代码归属不清或解决方案需要多轮验证时，协调者可以根据中间发现动态调整调查方向。第二类场景是存在任务依赖的大型变更，例如同时涉及数据模型、后端接口、前端适配、迁移和回滚方案。第三类场景是需要多种角色相互制约，例如实现者、测试者和安全审查者分别给出证据。
是否使用编排，不应只看代，而应看协调复杂度。一个跨三个文件的安全修复可能需要威胁建模、复现、修复和回归验证，适合分角色处理；一个改动上百个文件的机械重命名反而可能只需单个 Agent 配合可靠的自动化工具。
可以用四个问题快速判断：任务能否在开始前完整拆分；子任务是否会频繁改变彼此的输入；失败后是否需要动态改派；最终验收是否需要独立角色。如果多数答案为“否”，并行 Worktree 通常足够。如果多数答案为“是”，编排带来的状态管理和信息传递才可能抵消其额外成本。
常见误区与实际风险
更多 Agent 不等于更快
并行收益受关键路径限制。任务切得过细，会增加上下文准备、消息传递、分支合并和重复检查的成本。多个 Agent 还可能同时阅读相同代码、提出相似方案，形成昂贵的重复劳动。开始时应限制并发，只把真正独立且耗时的部分拆出去。
文件不冲突不等于语义不冲突
一个 Agent 修改接口返回结构，另一个 Agent 修改调用方，即使 Git 没有产生文本冲突，组合后也可能行为不一致。分配任务时应明确接口所有权，并把共享契约视为单独产物。接口、数据结构或配置格式变化后，需要通知所有消费者并重新执行集成验证。
共享仓库不代表共享认知
Agent 可以读取同一代码库，却仍然基于不同时间点或不同假设工作。长任务开始前要记录基准提交；上游变更后，决定下游是继续在旧基线完成，还是同步并重新验证。否则最终合并时很难判断失败来自实现本身，还是来自基线漂移。
编排器不是正确性证明
协调 Agent 也可能错误拆分任务、遗漏依赖或过早接受结果。任务状态“已完成”只表示流程推进，不表示软件满足需求。测试、类型检查、静态分析、代码审查和可复现的验证步骤仍然是最终依据。高风险改动还需要人工确认权限边界、数据影响和回滚方案。
推荐的组合模式
实践中最稳妥的结构通常是“轻编排加 Worktree 隔离”。协调层只负责维护目标、任务依赖、接口约束和验收证据；每个会产生代码修改的执行任务进入独立 Worktree；只读研究任务则不必机械地创建分支。这样既避免多个执行者互相覆盖文件，也不会让编排层承担所有实现细节。
任务卡至少应包含目标、允许修改范围、基准提交、输入依赖、验收命令和交付形式。执行者返回时提供变更摘要、提交标识、验证结果以及仍未解决的风险。集成者按依赖顺序合并，并在合并后的统一环境中重新运行验证，而不是简单拼接各会话的“通过”结论。
当两个 Agent 需要持续编辑同一组核心文件时，不要勉强并行。可以让一个负责实现，另一个在独立会话中只读审查；也可以让两个 Agent 分别提出方案，选定一个后再进入编码。把并发用于信息增益，而不是制造合并冲突，通常能获得更稳定的速度提升。
如何衡量编排是否真的有价值
不要只统计同时运行了多少会话。更有意义的指标包括端到端完成时间、首次集成通过率、返工次数、人工协调时间、重复调查比例和每个有效交付消耗的资源。若引入编排后 Agent 数量增加，但人工仍需频繁搬运上下文、修复接口分歧和重新验证，那么系统只是把复杂度隐藏到了任务面板里。
可以先用两到三个 Worktree 做小规模实验，记录从分派到合并的全过程。只有当人工协调成为稳定瓶颈，且瓶颈能够用依赖追踪、结构化消息或自动验收明确解决时，再增加编排能力。这样得到的流程会贴合仓库实际，而不是为了采用“多 Agent”概念而增加一层系统。
选择原则
基于 Worktree 的并行会话提供的是隔离、可见性和可撤销性，适合边界清楚的并发任务；团队编排提供的是分工、通信、依赖管理和结果收敛，适合结构会变化或协作关系复杂的任务。两者不是替代关系：Worktree 可以成为团队编排的执行底座，团队编排也可以只在必要处介入。
最实用的起点是保持控制面简单：先明确任务边界和验收标准，再为会改代码的任务建立独立 Worktree，最后根据真实的协调成本决定是否引入自动编排。并行的目标不是让更多 Agent 忙碌，而是缩短关键路径，同时保持每项变更可审查、可验证、可合并。
