把一支云端智能体小队跑起来，大致长这样：仓库里放一份需求文档、一份接口契约、几张任务卡；在 Claude Code 的 Projects 里建一个项目、连上仓库；然后为每张任务卡开一条独立会话。几个 Agent 在各自的沙箱里并行改代码，各自推分支、各自写一份交付报告；最后用一条"汇总会话"只读报告和 diff，产出可以直接贴回 Word 或 Excel 的交付说明。
以一个常见需求为例：给订单页加"导出 CSV"。一次流程跑完，你能拿到这些东西——
- 3～5 个命名规范的分支与 PR，每个只动自己那一块代码；
- 每个任务一份
docs/reports/T-xxx.md； - 一份面向非技术同事的交付摘要，可以直接粘进文档或幻灯片；
- 一条清晰可回滚的路径：回滚哪个分支、影响哪些功能。
Projects 的具体入口、命名和可用范围会随官方迭代变化，以官方文档当前版本为准。下面讲的是不管界面怎么改都成立的做法。
前置条件清单
动手之前，把这几样准备好，后面会顺很多：
1. 一个 Git 托管账号（GitHub、GitLab 等均可），仓库已有 main 分支，并开启分支保护，禁止直接推主干。
2. 一个可用的 Claude 账号，且账号具备云端会话 / Projects 的使用权限。具体套餐与地区可用性以官方页面为准。
3. 本地装好 Claude Code CLI。即使主力在云端跑，本地留一份用于复现问题、验证契约。
4. 仓库自带运行环境声明：package.json、pyproject.toml、go.mod 之类，以及一条能跑通的测试命令。
5. 一份需求文本。放在 Word、Excel、飞书文档里都行，但最终要转成纯文本进仓库。
6. 约定好的分支命名规则，例如 feat/T-002-export-api。
步骤 1：把"小队编制"写进仓库
云端 Agent 每次都是从零开始读仓库，所以规则必须落在文件里，不能只存在于你的脑子里。在仓库根目录建 CLAUDE.md：
```markdown
项目约定
命令
- 安装依赖：
npm ci - 跑测试：
npm test - 跑单个子集：
npm test -- src/server/export
硬性规则
- 不允许修改
main分支，所有改动走功能分支。 - 每个任务一张任务卡，位于
docs/tasks/。 - 跨模块的接口以
contracts/下的文件为准，不得擅自改动契约。 - 完成一个任务后必须写
docs/reports/<任务ID>.md，包含：改动文件清单、验证命令与结果、未请求的额外改动、遗留风险。 - 不要做任务卡之外的重构、格式化或依赖升级。
```
再建一个任务卡目录 docs/tasks/，每张卡一个文件：
```markdown
T-002 后端导出接口
目标
提供 GET /api/orders/export，按筛选条件返回 CSV 流。
允许改动
- src/server/export/**
- src/server/routes/index.ts（仅新增一行路由注册）
禁止改动
- src/server/auth/**
- src/server/billing/**
契约
contracts/export.openapi.yaml
验收标准
npm test -- src/server/export全绿- 大数据量（10 万行）下内存占用不随行数线性增长
交付物
- 分支 feat/T-002-export-api
- docs/reports/T-002.md
```
任务卡写得好不好，直接决定并行能不能成立。"允许改动"和"禁止改动"两栏是关键，它把冲突概率压到了架构层面。
步骤 2：先冻结契约，再开并行
这是整套流程里容易被跳过的一步。多智能体并行失败，绝大多数不是模型能力问题，而是接口没定死：前端 Agent 以为返回的是 JSON，后端 Agent 直接吐了 CSV 流，两边都"通过了自己的测试"。
所以在派单之前，先单独用一个会话（或者干脆手工）把契约写出来：
```yaml
contracts/export.openapi.yaml
paths:
/api/orders/export:
get:
parameters:
- name: from
in: query
schema: { type: string, format: date }
- name: status
in: query
schema: { type: string, enum: [paid, pending, refunded] }
responses:
"200":
content:
text/csv:
schema: { type: string }
"403":
description: 无导出权限
```
契约文件一旦提交，就进入"只读模式"。任何 Agent 想改契约，必须先在报告里提出来，由人来裁决，而不是自己改掉。
步骤 3：在 Projects 里建项目、连仓库
到 Claude Code 的 Projects 界面新建一个项目，关联目标仓库。需要配置的东西通常是这几类：
```text
项目名称：order-export
关联仓库：<org>/<repo>
默认分支：main
环境初始化：npm ci
健康检查：npm test
环境变量：按需注入（密钥放平台的环境变量里，不要写进仓库）
```
环境初始化命令要写清楚。云端沙箱是干净的，Agent 不会"记得"你本机装过什么。让它自己去猜依赖怎么装，浪费的是你的时间。
项目建好后，建议先用一条只读会话验证连接是否正常：
```text
请只读地做一些检查，不要修改任何文件：
1. 列出仓库根目录结构；
2. 跑一次 npm ci && npm test，报告结果；
3. 告诉我 src/server/export 目录当前是否存在。
```
步骤 4：一张任务卡开一条会话
并行的单位是"会话"，不是"消息"。一个任务一条会话，做完就关，不要在同一个会话里连续塞三个不相关的需求——那样上下文必然互相污染，Agent 会把前一个任务的假设带进后一个任务。
派单指令可以直接引用任务卡，避免重复粘贴：
```text
你负责 docs/tasks/T-002.md 这一张任务卡。
要求：
- 先完整读一遍 CLAUDE.md 和任务卡，再动手。
- 只允许改动任务卡里列出的路径。
- 契约文件 contracts/export.openapi.yaml 只读，不得修改。
- 完成后运行
npm test -- src/server/export，把真实输出贴进报告。 - 提交到分支 feat/T-002-export-api，并写 docs/reports/T-002.md。
- 如果有任何地方与任务卡冲突，停下来在报告里说明，不要自行决定。
```
按同样方式再开三条会话：T-001 前端导出按钮与状态、T-003 权限与审计日志、T-004 测试与文档。四条会话同时跑，互不干扰。
步骤 5：上下文隔离靠三件事
隔离不是靠"提醒 Agent 别乱看"，而是靠环境本身：
路径隔离。 每个任务在自己的分支或工作区里干活。如果要在本地复现，用 worktree 而不是切来切去：
```bash
git fetch origin
git worktree add ../repo-T-002 -b feat/T-002-export-api origin/main
git worktree add ../repo-T-003 -b feat/T-003-permission origin/main
```
契约隔离。 多个任务之间共享的只有 contracts/ 目录，其余代码各改各的。共享面越小，冲突越少。
会话隔离。 一条会话只装一个任务的上下文。不要把 A 的构建日志贴给 B 看，也不要让 B "顺便参考一下 A 的思路"——那不是协作，那是污染。
步骤 6：结果汇总，只读 diff 和报告
四条会话跑完后，先做机械核对，再让汇总会话做归纳。机械核对的命令是确定的：
```bash
git fetch --all
每个分支相对 main 改了哪些文件
git diff --stat main...feat/T-002-export-api
git diff --stat main...feat/T-003-permission
有没有多个分支动了同一个文件
git diff --name-only main...feat/T-002-export-api | sort > /tmp/a.txt
git diff --name-only main...feat/T-003-permission | sort > /tmp/b.txt
comm -12 /tmp/a.txt /tmp/b.txt
```
comm -12 输出的就是重叠文件，有重叠就说明任务拆分需要调整。
然后开一条汇总会话，只喂报告和 diff 统计，不要喂全部源码：
```text
下面是四个任务的交付报告和 diff 统计。请只基于这些材料工作，
不要猜测未提供的内容。
请输出：
1. 每个任务的状态（完成 / 部分完成 / 阻塞），并给出依据；
2. 分支之间的文件冲突清单；
3. 一份变更说明，分三段：交付内容、影响面与回滚方式、遗留风险；
4. 需要人工确认的问题列表。
输出纯 Markdown，不要用表格。
```
把上下文限制在"报告 + diff 统计"，汇总质量反而更稳。
步骤 7：用 Office 入口串起需求与交付
很多团队的真实入口不是仓库，而是一份 Excel 台账或一份 Word 需求。可以这样接：
需求进。 在 Word 里写清需求后，另存为纯文本，人工整理成任务卡，再提交进 docs/tasks/。不要让 Agent 直接读带样式的文档——格式噪声会带来歧义。
台账管。 在 Excel 里维护一张任务台账，字段建议：任务 ID、任务卡路径、负责会话、分支名、状态、验收人、报告路径。这张表是给人看的，不参与自动化。
交付出。 把步骤 6 生成的变更说明直接粘回 Word 或幻灯片，发给非技术同事。因为是纯 Markdown，粘过去基本不用重排。
Claude 的 Office 侧集成具体支持哪些文档类型、哪些账号可用，以官方页面为准。原则是一样的：文档负责给人看，仓库负责给 Agent 看，中间用纯文本转换。
步骤 8：合并与收尾
按任务卡逐条验收，不要因为"报告里说全绿"就放行——以 CI 的实际结果为准。合并顺序建议：先合契约和公共部分，再合后端，最后合前端。合并完主干跑一次全量测试，再关掉对应的云端会话。
常见坑与排错
两个 Agent 改了同一个文件。 症状是合并时反复冲突。根因通常是任务拆分按"功能"而不是按"路径"。回到步骤 1，把"允许改动"写成目录白名单，重叠的文件提取成独立任务先行完成。
Agent 顺手做了重构。 在 CLAUDE.md 里明确禁止，并要求报告里单列"未请求的额外改动"。看到这一栏非空，就先回滚那部分再评审。
云端环境跑不起来。 通常是初始化命令没写、依赖没锁定、或者需要密钥。把安装命令写进项目配置，密钥走平台环境变量。让 Agent 自己猜怎么装依赖，只会得到一堆"我已修复"的错误结论。
会话越跑越慢、结论越来越飘。 一条会话里塞了太多历史。任务做完就开新会话，长任务拆成两段：先出方案，确认后再动手。
汇总说"全部通过"，但 CI 挂了。 报告是 Agent 的自述，CI 是事实。把 CI 状态作为唯一放行依据。
从文档粘贴过来带了一堆不可见字符。 先在纯文本编辑器里过一遍，再去建任务卡。
下一步建议
跑顺一两次之后，可以考虑这几件事：
1. 把任务卡做成模板，用一个脚本按任务 ID 批量创建分支和 worktree，减少手工步骤。
2. 在 CI 里加一条检查：任何 PR 如果改了 contracts/ 却没有对应的评审标记，直接失败。
3. 给每个任务卡加"预估影响文件数"，用来判断这个任务适不适合并行。
4. 复盘一次：记录哪些任务并行成功、哪些必须串行。通常涉及同一张数据库表迁移、同一份配置文件的改动，串行比并行省事。
5. 把步骤 6 的汇总提示词固化成文件，放进仓库，让汇总行为可版本化、可复现。