多 Agent 开发：从 Issue 拆解到隔离验收

多个 AI 编程客户端同时开着，不等于它们能协作。同一个项目在不同助手之间接力，上下文要反复重讲；多个任务并行时，改动混在一起，验收根本无从下手。这篇记录一套把多 Agent 收进一条开发流程的做法。

要解决什么问题

真正的痛点有两个：任务之间互相污染工作目录；人成了上下文中转站，精力全花在搬信息上。

要的不是「同时开更多窗口」，而是一条有边界的流程：每个任务有独立空间，任务结束后又能把改动放回同一个项目里检查。

一条任务如何从想法走到验收

1. 先讨论收敛，再决定怎么拆

需求刚出来时不要急着派活。让多个 AI 席位各自独立判断，然后基于摘要素果过的结论修订——目的不是凑答案数量，是提前暴露分歧：哪些必须做、哪些暂不做、哪些假设还没证据。

2. 把结论拆成能独立完成的 Issue

讨论产出转成任务条目。每条任务的粒度标准：一个 Agent 能独立接住，且目标清楚到不需要执行者再猜。把「想做什么」变成有边界、有输入、有完成标准的任务，这一步比派活本身更重要。

3. 一个任务一个独立工作区

每条任务对应独立的 git worktree，只把带就绪标签的任务交给 Agent。隔离工作区让各任务的改动可以分别查看，不会互相踩着改文件。

注意它的边界：隔离不消除业务依赖，也不替代合并时的冲突检查——这两步仍然要人看。

4. 人看差异，决定合并

任务完成后，改动放在同一项目里，人逐条看 diff：是否符合预期、要不要调整、能不能合并。自动化的终点是「可检查的改动」，不是「无人值守的上线」。

复用价值

这套流程的核心可以脱离具体工具复用的只有一条：讨论收敛 → 任务拆解 → 隔离执行 → 人工验收。前面三步都在为最后一步服务——机器负责把改动变成可检查的状态，人负责判断。