Appearance
Cloud Agent、Worktree 与多 Agent：并行不是把任务复制十份
系列第 12 篇
核心问题：什么时候适合异步委托，怎样隔离并行工作，并把结果重新整合为一个可信交付
最后核验：2026-07-20
对应视频：第 09 集《Cloud Agent、Worktree 与多 Agent：并行不是复制任务》
本地同步 Agent 的节奏接近结对编程：人提出任务，看到搜索和 Diff，快速纠偏。Cloud Agent 把任务放到隔离环境后台执行，用户可以同时处理其他工作；本地 Worktree 允许多个任务共享 Git 对象但拥有独立文件树；多 Agent 再进一步，将研究、实现、验证或不同模块分给不同执行者。
它们最吸引人的指标是墙钟时间：原来串行三小时的工作似乎可以由三个 Agent 一小时完成。但并行系统还增加任务拆分、环境启动、Token、冲突、集成测试、审查和交接成本。Agent 数量只提高潜在吞吐，任务独立性和验证能力决定收益能否兑现。
阅读路线：先看全局，再进入机制
视频版先展示整章地图，再逐层展开。博客沿用同一判断顺序，但保留更多机制、案例、失败模式和生产边界：
- 云端与隔离：拆开临时环境、分支、工具、Secret 与可重建前提。
- 任务与角色：按输入输出契约设计协调、研究、实现、验证和整合角色。
- 冲突与成本：同时计算语义冲突、协调、排队、Review 和失败重跑。
- 集成与交接：让每个异步结果可接手，并在整合状态重新验证。
这四步不是目录装饰，而是一条决策链：云端与隔离 → 任务与角色 → 冲突与成本 → 集成与交接。阅读后面的案例时，可以随时回到这条链判断当前问题发生在哪一层。
真实问题：为什么三个 Agent 各自测试通过，合并后仍然失败
Agent A 修改后端 DTO，Agent B 根据旧 DTO 修改前端，Agent C 更新文档；三个分支文件几乎不冲突，也都通过各自局部检查。合并后，JSON 字段、生成客户端与示例不一致。Git 只发现文本冲突，不理解语义契约。并行越快，错误假设也可能越快扩散。
另一个常见失败是任务太模糊。协调者把“重构订单系统”拆成“改 Domain”“改 Service”“补测试”，但没有冻结接口和状态语义。每个 Agent 都做出合理而不同的设计，整合成本高于串行。并行之前最重要的工作不是启动更多执行者，而是找到可以独立验收的边界。
机制：Cloud Agent 是一个受控的远程开发环境
典型 Cloud Agent 从 Issue、Chat 或 API 接收任务，在临时 VM/Container 中检出仓库和专用分支，安装依赖，使用受限工具与 Secrets，运行测试，最后返回提交、Diff、日志、截图或 PR 草稿。人类审核后才进入主干。
云端并不天然比本地更自治。它能否工作取决于环境是否可重建：依赖是否锁定，构建是否非交互，测试数据是否可获得，服务依赖是否有替身，组织凭据能否按最小权限注入。一个只能在某位工程师笔记本上启动的项目，搬到 Cloud Agent 只会更快暴露环境债务。
远程任务还需要停止条件。Agent 应在验收检查通过、权限受阻、预算超限或遇到高风险决策时停止，并返回已完成节点与缺口。后台运行不代表可以无限重试，也不授权部署、发消息或修改生产。
1. Git Worktree 隔离文件系统，不隔离语义
git worktree 让一个仓库对象库关联多个独立工作目录，每个目录检出不同分支。Agent A 不会覆盖 Agent B 的未提交文件，各自可以运行构建和保留日志。相比在同一目录频繁切分支，它特别适合同时进行长测试、修复与文档任务。
bash
git worktree add ../orders-cancel -b feature/cancel
git worktree add ../orders-review -b review/cancel baseline
git worktree list使用前要确认构建缓存、端口、数据库和外部资源是否也隔离。两个 Worktree 可能都启动 8080，写同一 Docker Volume，或使用同一测试账号。文件树隔离只是第一层，运行时资源也要命名空间化。
Worktree 不解决公共接口冲突。两个分支修改不同文件仍可能语义不兼容，最终必须在集成分支运行全量测试。任务结束后安全移除 Worktree，先确认提交和状态，不能用清理命令覆盖用户改动。
哪些任务值得并行
低耦合且可自动验证的任务最适合：独立模块测试、互不共享文件的文档、多个清晰缺陷、不同平台的只读调查。低耦合但难验证的研究可以并行收集证据，但需要统一标准去重和判断。高耦合但可验证的任务只有在接口先冻结时并行。高耦合且难验证的架构、产品方向和大规模重构不应简单拆给多个 Agent。
任务独立性至少检查四层：文件是否重叠；符号和接口是否共享；运行时资源是否共享；业务决策是否共享。只有第一层独立远远不够。
可验证性同样关键。若每个子任务有清晰输入、输出和测试，协调者可以机械收集结果；若完成依赖审美和隐性业务，多个候选反而增加审查。并行应该用于减少等待，不用于逃避需求澄清。
多 Agent 编排需要角色契约
多 Agent 不一定按角色拆，也可以按模块或备选方案拆。角色式结构中，协调者定义目标、子任务、接口和完成条件；研究 Agent 只读收集事实；实现 Agent 在隔离分支修改；验证 Agent 以新上下文尝试反驳；整合者处理冲突、运行全量验证并准备交付。
角色名称没有价值，输入输出契约才有价值。研究输出应包含来源、已确认事实和不确定性；实现输出包含提交、Diff、测试和限制；验证输出包含可复现发现和优先级；整合输出说明接受、拒绝与冲突处理。只让五个 Agent 都“分析一下”，会得到五份相似摘要。
协调者也不能只负责转发。它要识别共享决策、冻结接口、控制并发数量、停止低价值分支、检查交接完整性。任务规模小于协调成本时，单 Agent 同步完成更高效。
并行冲突不仅是 Git 冲突
冲突可分为：文本冲突，同一行被修改；接口冲突，一方改变签名而另一方依赖旧版；语义冲突，双方对幂等或错误码理解不同；资源冲突，共享端口、数据和账户；策略冲突，不同 Agent 读取了不同版本规则。
文本冲突最明显，却常是最容易解决的。语义冲突可能合并干净但运行错误。因此整合阶段要重新读取任务契约，比较公共接口，运行组合测试，不应只依赖 git merge 返回 0。
减少冲突的方法包括：任务开始前冻结共享类型；将公共接口变更串行完成后再扇出；为每个 Agent 分配所有权明确的路径；统一基线提交和规则版本；及早合并小节点；在集成分支持续运行契约测试。不要让子任务运行数小时后才第一次交换信息。
异步任务必须返回可接手的交接包
“任务完成，请查看”不是可用交接。后台执行结束时至少返回：目标与实际状态；基线和最终提交；改动文件与关键决策；运行的命令和原始结果；失败、未覆盖和限制；复现环境；下一步建议。若等待用户选择，应写清分歧和各方案影响。
交接内容要与仓库状态相互验证。接手者先运行 git status、检查提交和关键测试，再信任摘要。Agent 可能在生成说明后又发生文件变化，或把一次局部绿灯写成全量通过。
长任务可以在中间节点产生 checkpoint，尤其是云环境可能过期或预算耗尽时。Checkpoint 包含可提交的最小进展，而不是半写文件和大量聊天历史。恢复任务从真实 Git 状态开始，不从模型记忆猜测。
多 Agent 的总成本模型
并行主要优化墙钟时间，不一定减少总工程成本。可以用一个简单模型思考：
text
总成本 = Σ模型与环境执行
+ 任务拆分
+ 交接阅读
+ 冲突整合
+ 额外审查
+ 错误返工
完成时间 ≈ 最慢关键路径 + 排队 + 集成验证五个 Agent 同时工作，Token 和云 CPU 可能接近五倍；Reviewer 还要理解多个 Diff。若任务真正独立，墙钟时间显著下降；若共享决策多，协调与返工抵消收益。团队应按任务类别记录净收益，不以“并发任务数”作为成功指标。
异步也带来等待隐藏。Agent 运行二十分钟后请求一个权限，若无人处理，整个关键路径停滞。任务契约应提前识别授权、凭据、环境和决策点，或者让 Agent 在无权限时转向只读产物。
同步、异步和并行的选择树
需求仍在探索、需要频繁业务判断时，用同步 Agent；环境无法重建或依赖本机设备时，优先本地；任务稳定、结果可自动验收、环境可隔离时，适合异步；多个任务低耦合且有统一接口时，再考虑并行。
自治程度也由风险决定。文档和测试可以后台完成并提交候选 Diff；数据库迁移可以异步生成方案和验证脚本，但执行生产迁移仍需审批；身份、资金和数据删除任务通常把 Agent 限制为只读分析和草稿。
不要把同步理解为落后。复杂设计在十分钟人机来回中澄清，可能比两个小时后台返工更快。工具的最好入口取决于反馈周期。
并行系统需要更强的集成门禁
每个任务使用独立分支或 Worktree；共享接口在扇出前确认；子分支运行自己的聚焦与全量检查；整合分支运行组合测试、端到端和静态检查；人工处理业务冲突并批准。Agent 数量增加时，不应降低每个结果的证据要求。
可以设置并发上限和 WIP 限制。十个待审 PR 会把瓶颈从编码转移到 Review，增加分支过期和冲突。让任务进入系统的速度服从整合能力，而不是模型席位数量。
治理还包括成本预算、环境到期、Secret 撤销、日志保留和异常终止。云任务结束后应清理临时凭据和资源，但保留必要的提交与审计证据。
可重建环境是异步能力的前置基础设施
Cloud Agent 不能依赖“先手动点开 IDE，再从某个聊天窗口复制 Token”这类隐性步骤。仓库应固定运行时与依赖版本，提供非交互安装、测试数据构造、服务健康检查和明确退出码；需要浏览器、数据库或消息队列时，用可声明的容器或受控测试环境启动。时间、随机数和区域设置也可能造成本地与云端差异，应在测试中固定或显式记录。
缓存能缩短启动，但会引入跨任务状态。依赖缓存可以按锁文件键隔离，构建产物不应冒充当前分支结果，包含凭据或用户数据的目录不能跨环境复用。端口、Docker Project、临时数据库和对象存储前缀都应带任务标识，否则两个并行 Agent 可能在没有文件冲突的情况下互相污染验证。
环境准备失败时，Agent 应区分“代码测试失败”和“基础设施未就绪”。交接包记录镜像、运行时、锁文件、启动命令、失败阶段和日志位置；不要为了绕过环境错误修改业务断言。团队可以把云端准备脚本也放进 CI 定期执行，避免只有真正委托时才发现它早已过期。
可重建不要求把生产完整复制到每个任务。目标是提供足以验证当前契约的最小环境，并明确模拟与真实系统的差异。支付、身份和第三方服务通常用契约替身；需要高保真验证时进入受控集成环境，而不是向普通 Cloud Agent 注入生产访问。
一个订单服务并行示例
取消订单的 Domain、Service 和 HTTP 强耦合，不适合三个 Agent 同时改。更合理流程是主实现 Agent 完成契约和核心状态；另一个只读验证 Agent从 baseline 与 Diff 检查状态矩阵；文档 Agent 在接口冻结后整理说明；整合者运行 16 个测试与 HTTP Smoke。
若未来同时增加“订单查询”和“客户地址校验”，可以在冻结公共 Order 变化后分 Worktree。两个任务分别拥有 Controller/Service 流程，但都修改 Order 时仍需协调。先完成共享模型提交，再让分支基于同一节点开始，能减少语义分叉。
视频和博客制作也可以并行生成图、配音和代码证据，但必须共享同一脚本时间轴与 Git 节点。否则字幕、画面和讲解会引用不同状态，这正是非代码资产的语义冲突。
失败模式
失败一：按文件数量机械拆分
不同文件可能共享接口和业务决策。先画依赖与验收边界，再拆任务。
失败二：所有 Agent 使用同一工作目录
未提交文件会互相覆盖，测试结果也无法归属。使用独立 Worktree、分支和运行时资源。
失败三：只检查 Git 是否冲突
干净合并仍可能语义不兼容。比较契约并运行组合测试。
失败四：异步任务没有交接包
一句完成迫使接手者重建全部上下文。交付提交、命令、证据、限制和下一步。
失败五：用更多 Agent 处理模糊问题
并发会放大不同假设。先同步澄清或让多个 Agent 只提供备选方案，不直接同时实现。
失败六：忽略 Review 吞吐
编码加速后，待审任务堆积导致分支老化。限制 WIP，让并发服从整合能力。
失败七：后台运行被误认为扩大授权
异步只改变时间和环境，不授权生产、外发或删除。高风险动作仍需明确审批。
生产边界
云环境会处理源码、依赖、日志和凭据，需要数据区域、保留、网络和供应链策略。短期环境不代表无风险；构建脚本与依赖也可能外传数据。Secrets 应按任务最小 Scope 注入，结束撤销，日志脱敏。
多 Agent 产生更多身份和动作记录。组织要能追踪任务发起者、基线、权限、提交、测试、Review 和合并。高风险整合不能由协调 Agent 自动批准自己或子 Agent 的结果。
实践清单
- [ ] 先检查文件、接口、资源和业务决策四层耦合。
- [ ] 只并行边界清晰且可独立验收的任务。
- [ ] 云环境提供锁定依赖、非交互构建和受限凭据。
- [ ] 每个任务使用独立分支、Worktree 和运行时命名空间。
- [ ] 扇出前冻结共享接口、规则版本和基线提交。
- [ ] 为每个角色定义输入、输出、停止条件和证据。
- [ ] 异步结果包含提交、验证、限制、环境和下一步。
- [ ] 集成阶段重新读契约并运行组合测试。
- [ ] 记录墙钟时间、总成本、Review 与返工，不只看并发数。
- [ ] 外部副作用与生产动作保持独立授权。
读完之后，你应该能完成什么
- 能判断任务是否真的可并行。
- 能解释 Worktree 隔离文件树但不隔离业务语义。
- 能设计多 Agent 交接包和停止条件。
- 能用关键路径净收益决定是否增加 Agent。
如果只能复述概念，却不能完成上述动作，说明还没有把内容转化成工程能力；可以回到对应机制图、失败模式和实践清单重新核对。
小结
Cloud Agent、Worktree 和多 Agent 扩大的是执行容量，不会自动创造任务独立性。可靠并行从接口和验收开始，以环境和分支隔离减少互相覆盖，以交接包保持可接手状态，以集成测试发现语义冲突，最后由人类承担整合责任。并行的目标不是让更多 Agent 同时忙碌，而是缩短真正的关键路径，同时保持证据质量。