工作流 12：从项目目标到多 Agent 协作开发的 AI 工作流¶
适用岗位：高级开发者、独立开发者、技术负责人、AI Agent 使用者
真实场景：你要用多个 AI Agent（或多轮 AI 会话）协作完成一个有一定规模的开发项目。问题是：Agent 对话一长就开始遗忘早期决策，几个 Agent 各写各的导致接口对不上，做着做着目标就漂移了，TODO 列表和实际代码完全脱节。
最终目标：一套多 Agent 协作的工程化治理方案，包含：目标拆解、Agent 角色分工、任务队列、上下文交接规范、代码变更审查机制、冲突回滚预案、TODO 同步机制和阶段复盘记录。让多 Agent 协作成为可控的工程过程，而不是失控的群聊。
输入材料清单¶
- 项目目标（一句话目标 + 范围边界）
- 可用 Agent 能力（使用哪些 AI 工具/模型，各自擅长什么）
- 代码库状态（新项目 / 已有项目，版本控制方式）
- 协作约束（单 Agent 上下文窗口大小、是否能共享文件、是否有人工审查环节）
- 时间或里程碑要求
工作流总览¶
节点 1：项目目标拆解专家
↓ 输出：目标树 + 可独立交付的子任务
节点 2：Agent 角色分工专家
↓ 输出：Agent 角色定义 + 职责边界
节点 3：任务队列设计专家
↓ 输出：任务队列 + 依赖关系 + 就绪条件
节点 4：上下文管理专家（招牌节点）
↓ 输出：上下文交接规范 + 阶段总结模板
节点 5：代码变更审查专家
↓ 输出：变更审查规则 + 审查记录
节点 6：冲突与回滚专家
↓ 输出：冲突检测规则 + 回滚预案
节点 7：TODO 管理专家
↓ 输出：TODO 同步机制 + 状态台账
节点 8：阶段复盘专家
↓ 输出：阶段复盘记录 + 下阶段调整
最终交付：多 Agent 协作治理方案
专家节点详解¶
每个节点包含六部分：节点定位、输入与输出、使用顺序、提示词包（A 快速 / B 专家 / C 自查 / D 返修）、交付给下游节点、人工验收清单。
C 自查审稿版和 D 返修优化版是当前节点内部的工作模式，不是新的专家角色。
核心理念：多 Agent 协作不是"多个 AI 聊天"，而是任务、上下文、文件、审查、交接的工程化管理。本工作流的每个节点都服务于"让协作可控、可追溯、可交接"。
节点 1：项目目标拆解专家¶
1.1 节点定位¶
将项目目标拆解为可以分配给不同 Agent、可独立交付、可独立验证的子任务。拆解粒度决定了 Agent 能否并行工作而不互相踩脚。
1.2 输入与输出¶
输入：项目目标 + 范围边界 + 代码库状态
输出：目标树（目标→子目标→子任务）+ 每个子任务的交付物定义
1.3 使用顺序¶
- 先用「快速生成版」得到目标拆解初稿。
- 项目规模大或依赖复杂时，改用「专家增强版」。
- 用「自查审稿版」检查子任务是否可独立交付、粒度是否合适。
- 有问题则用「返修优化版」调整。
- 对照 1.6 验收清单确认，通过后交给节点 2 和节点 3。
1.4 提示词包¶
A. 快速生成版¶
你是一位技术项目拆解专家。请将以下项目目标拆解为可分配的子任务。
项目目标：【填入目标】
范围边界：【填入做什么、不做什么】
输出：
1. 目标树（主目标 → 子目标 → 子任务）
2. 每个子任务的交付物（完成的标志）
3. 子任务之间的依赖关系
B. 专家增强版¶
你是一位资深技术项目架构师，擅长为多 Agent 协作设计任务拆解。
任务：将项目目标拆解为适合多 Agent 并行/串行协作的子任务结构。
输入：
- 项目目标：【填入目标】
- 范围边界：【填入边界】
- 代码库状态：【填入新项目/已有项目及结构】
- 可用 Agent 数量与能力：【填入】
处理步骤：
1. 自顶向下拆解目标（主目标 → 子目标 → 子任务）
2. 每个子任务定义明确交付物（文件/接口/功能）和验收标准
3. 标注子任务粒度（建议单个 Agent 在一个上下文窗口内可完成）
4. 标注依赖关系（哪些可并行，哪些必须串行）
5. 识别"接口边界任务"（多个子任务交汇处，需优先冻结接口）
输出格式：
- 目标树（缩进结构）
- 子任务表（ID|交付物|验收标准|依赖|可否并行）
- 接口边界清单（哪些接口需在并行开发前先冻结）
约束：每个子任务必须可独立验证；拆解粒度应使单个任务在单次 Agent 会话内可完成，避免跨多次会话的超大任务。
质量标准：据此拆解可直接分配给不同 Agent 并行开发而不产生接口冲突。
常见失败情况：子任务粒度过大跨多次会话导致上下文丢失；并行任务共享了未冻结的接口导致返工。
C. 自查审稿版¶
此为当前节点的自查模式，不是新的专家角色。
请检查以下目标拆解是否存在以下问题：
1. 是否有子任务粒度过大（单个 Agent 一次会话内无法完成）？
2. 每个子任务是否有明确的交付物和验收标准？
3. 并行子任务是否共享了尚未冻结的接口（会导致冲突）？
4. 依赖关系是否完整标注？
【粘贴目标拆解】
逐条说明问题。
D. 返修优化版¶
1.5 交付给下游节点¶
将目标树和子任务表复制，同时交给： - 节点 2（Agent 角色分工专家）：作为角色职责划分依据。 - 节点 3（任务队列设计专家）：作为任务编排依据。
1.6 人工验收清单¶
- [ ] 每个子任务是否可独立验证？
- [ ] 子任务粒度是否适合单次 Agent 会话完成？
- [ ] 接口边界任务是否已识别？
- [ ] 依赖关系是否完整？
节点 2：Agent 角色分工专家¶
2.1 节点定位¶
为协作定义 Agent 角色及其职责边界，明确每个 Agent 负责什么、不负责什么、产出什么。清晰的职责边界防止 Agent 越权修改他人负责的代码。
2.2 输入与输出¶
输入：节点 1 目标树 + 可用 Agent 能力
输出：Agent 角色定义表（角色 + 职责 + 边界 + 产出 + 不可触碰范围）
2.3 使用顺序¶
- 先用「快速生成版」得到角色分工初稿。
- Agent 较多或职责易重叠时，改用「专家增强版」。
- 用「自查审稿版」检查职责是否有重叠或空白。
- 有问题则用「返修优化版」修正。
- 对照 2.6 验收清单确认，通过后交给节点 3 和节点 5。
2.4 提示词包¶
A. 快速生成版¶
你是一位 AI 协作设计师。请为以下子任务设计 Agent 角色分工。
子任务表：【粘贴节点1的子任务】
可用 Agent：【填入数量和能力】
输出：
1. Agent 角色列表（角色名 + 负责的子任务）
2. 每个角色的职责边界（负责什么、不碰什么）
3. 每个角色的产出物
B. 专家增强版¶
你是一位多 Agent 系统设计专家。
任务：为多 Agent 协作开发定义清晰的角色分工，避免职责重叠和越权修改。
输入：
- 目标树和子任务：【粘贴节点1】
- 可用 Agent 能力：【填入各 Agent 擅长领域】
处理步骤：
1. 按职责类型划分 Agent 角色（如：实现型、审查型、集成型）
2. 为每个角色分配子任务，明确职责边界
3. 定义每个角色"不可触碰"的范围（哪些文件/模块不归它管）
4. 定义角色间的协作接口（A 的产出如何成为 B 的输入）
5. 指定接口冻结的责任角色（谁负责维护共享接口）
输出格式：
| 角色 | 负责子任务 | 产出物 | 职责边界 | 不可触碰范围 |
+ 角色协作关系图（谁的产出给谁）
约束：任意两个角色的"可写范围"不得重叠（防止并发修改冲突）；共享接口必须有唯一的负责角色。
质量标准：据此分工，多个 Agent 可并行工作且不会修改彼此负责的代码。
常见失败情况：两个 Agent 都能改同一文件导致覆盖；没有角色负责维护共享接口导致接口漂移。
C. 自查审稿版¶
此为当前节点的自查模式，不是新的专家角色。
请检查以下 Agent 角色分工是否存在以下问题：
1. 是否有两个角色的"可写范围"重叠（会导致并发修改冲突）？
2. 是否有子任务没有被分配给任何角色（职责空白）？
3. 共享接口是否有唯一的负责角色？
4. 每个角色是否定义了"不可触碰范围"？
【粘贴角色分工】
逐条说明问题。
D. 返修优化版¶
2.5 交付给下游节点¶
将 Agent 角色定义表复制，交给节点 3（任务队列设计专家）和节点 5（代码变更审查专家）。审查规则需基于角色边界设计。
2.6 人工验收清单¶
- [ ] 是否没有角色的可写范围重叠？
- [ ] 是否每个子任务都分配了负责角色？
- [ ] 共享接口是否有唯一负责角色？
- [ ] 每个角色是否有明确的不可触碰范围？
节点 3：任务队列设计专家¶
3.1 节点定位¶
将子任务编排为有序的任务队列，定义每个任务的就绪条件、执行顺序和完成标志。任务队列是协作的调度核心，决定了 Agent 按什么顺序、在什么条件下开始工作。
3.2 输入与输出¶
输入：节点 1 子任务表 + 节点 2 角色分工
输出：任务队列（任务 + 负责角色 + 就绪条件 + 完成标志 + 状态）
3.3 使用顺序¶
- 先用「快速生成版」得到任务队列初稿。
- 依赖复杂或需要并行调度时，改用「专家增强版」。
- 用「自查审稿版」检查就绪条件是否明确、是否有死锁。
- 有问题则用「返修优化版」修正。
- 对照 3.6 验收清单确认，通过后交给节点 4 和节点 7。
3.4 提示词包¶
A. 快速生成版¶
你是一位任务调度设计师。请将以下子任务编排为任务队列。
子任务表：【粘贴节点1】
角色分工：【粘贴节点2摘要】
输出：
| 任务ID | 负责角色 | 就绪条件 | 完成标志 | 状态 |
就绪条件 = 开始本任务前必须满足什么（如：某任务已完成、某接口已冻结）
B. 专家增强版¶
你是一位资深任务编排工程师。
任务：将子任务编排为可执行的任务队列，支持多 Agent 并行调度。
输入：
- 子任务表（含依赖）：【粘贴节点1】
- 角色分工：【粘贴节点2】
处理步骤：
1. 按依赖关系拓扑排序所有任务
2. 为每个任务定义就绪条件（前置任务完成、接口冻结、输入就绪）
3. 标注可并行执行的任务批次
4. 为每个任务定义完成标志（产出物存在且通过验收）
5. 检测是否存在循环依赖（死锁）
输出格式：
| 任务ID | 负责角色 | 就绪条件 | 产出物 | 完成标志 | 可并行批次 | 状态 |
+ 执行批次说明（第1批并行哪些，第2批...）
+ 死锁检测结论
约束：每个任务的就绪条件必须可机械判断（不能是"差不多了"）；不得存在循环依赖。
质量标准：据此队列，可明确知道任意时刻哪些任务就绪可执行、由谁执行。
常见失败情况：就绪条件模糊导致 Agent 提前开始引发返工；循环依赖导致任务永远无法就绪。
C. 自查审稿版¶
此为当前节点的自查模式，不是新的专家角色。
请检查以下任务队列是否存在以下问题：
1. 是否存在循环依赖（A 等 B，B 等 A）？
2. 每个任务的就绪条件是否可机械判断（不是"准备好了"这类模糊表述）？
3. 标注为并行的任务是否真的无依赖关系？
4. 每个任务是否有明确的完成标志？
【粘贴任务队列】
逐条说明问题。
D. 返修优化版¶
3.5 交付给下游节点¶
将任务队列复制，交给节点 4（上下文管理专家）和节点 7（TODO 管理专家）。TODO 台账基于任务队列建立。
3.6 人工验收清单¶
- [ ] 是否不存在循环依赖？
- [ ] 每个任务的就绪条件是否可机械判断？
- [ ] 并行任务是否确实无依赖？
- [ ] 每个任务是否有完成标志？
节点 4：上下文管理专家（招牌节点）¶
4.1 节点定位¶
这是本工作流的招牌节点。 解决多 Agent 协作中最致命的一类问题——上下文失控。具体包括：
| 问题 | 表现 | 本节点的对策 |
|---|---|---|
| 对话遗忘 | Agent 会话太长，遗忘早期决策 | 阶段总结 + 关键决策外置存档 |
| 信息不一致 | 多 Agent 之间对同一事实理解不同 | 单一事实来源（SSOT）文件 |
| 目标漂移 | 做着做着偏离原始目标 | 目标锚点 + 每阶段对齐检查 |
| 决策误覆盖 | 新 Agent 推翻了已确定的旧决策 | 决策记录（不可随意推翻，需走变更） |
| TODO 与代码脱节 | TODO 说做了，代码里没有 | 交接时强制核对（见节点 7） |
| 交接断层 | 下一个 Agent 不知道前面做了什么 | 标准化交接包 |
本节点输出一套上下文交接规范和阶段总结模板，让任意一个 Agent 都能在有限上下文内"接手"前序工作。
4.2 输入与输出¶
输入：节点 3 任务队列 + 协作约束（上下文窗口大小、是否共享文件）
输出：上下文交接规范 + 阶段总结模板 + 单一事实来源（SSOT）结构 + 决策记录规范
4.3 使用顺序¶
- 先用「快速生成版」得到上下文管理初稿。
- 协作链条长或 Agent 多时，必须使用「专家增强版」。
- 用「自查审稿版」检查交接规范是否覆盖六类上下文问题。
- 有问题则用「返修优化版」补充。
- 对照 4.6 验收清单确认，通过后交给节点 5 和节点 8。
4.4 提示词包¶
A. 快速生成版¶
你是一位 AI 协作上下文管理专家。请设计多 Agent 协作的上下文交接规范。
任务队列：【粘贴节点3摘要】
协作约束：【填入上下文窗口大小、是否能共享文件】
输出：
1. 阶段总结模板（每个 Agent 完成阶段后写什么）
2. 关键上下文清单（必须保存哪些信息供后续 Agent 使用）
3. 交接规范（下一个 Agent 接手时先读什么）
4. 决策记录方式（如何记录已确定的决策避免被误改）
B. 专家增强版¶
你是一位多 Agent 系统的上下文工程专家，深知长会话遗忘、信息不一致、目标漂移等问题的危害。
任务：设计一套完整的上下文管理与交接规范，解决多 Agent 协作的上下文失控问题。
输入：
- 任务队列：【粘贴节点3】
- 协作约束：【填入上下文窗口、文件共享能力、人工审查环节】
需要解决的六类问题及对应机制：
1. 对话遗忘 → 设计"阶段总结"：每个 Agent 完成任务后，将关键产出、决策、未决项写入外部文件
2. 信息不一致 → 设计"单一事实来源（SSOT）"：哪些信息以哪个文件为准（如接口定义、配置、术语表）
3. 目标漂移 → 设计"目标锚点"：在每个阶段开始时重申原始目标和当前阶段目标
4. 决策误覆盖 → 设计"决策记录"：已确定决策记入决策日志，后续 Agent 不得随意推翻，需走变更流程
5. TODO 与代码脱节 → 定义交接时的强制核对项（与节点7配合）
6. 交接断层 → 设计"标准化交接包"：下一个 Agent 接手前必读的最小信息集
输出：
- 阶段总结模板（字段：已完成/关键决策/未决项/下一步/相关文件）
- SSOT 文件结构（哪些文件是权威来源）
- 决策记录格式（决策内容/理由/时间/是否可变更）
- 标准化交接包清单（接手 Agent 必读项）
- 目标锚点重申机制
约束：所有机制必须基于文件/文本实现（不依赖 Agent 记忆）；交接包必须控制在新 Agent 上下文窗口可容纳的范围内。
质量标准：任意一个 Agent 仅凭交接包和 SSOT 文件，即可在不了解历史会话的情况下正确接手工作。
常见失败情况：把上下文存在某个 Agent 的会话里（一旦会话结束就丢失）；交接包过大超出新 Agent 上下文窗口；决策没有记录导致反复推翻。
C. 自查审稿版¶
此为当前节点的自查模式，不是新的专家角色。
请检查以下上下文管理规范是否存在以下问题：
1. 是否覆盖了六类上下文问题（遗忘/不一致/漂移/误覆盖/TODO脱节/交接断层）？
2. 上下文是否都基于文件存储，而非依赖 Agent 会话记忆？
3. 交接包是否控制在新 Agent 上下文窗口可容纳的范围？
4. 决策记录是否有"是否可变更"的标注（防止随意推翻）？
5. 是否明确了哪些文件是单一事实来源（SSOT）？
【粘贴上下文管理规范】
逐条说明问题。
D. 返修优化版¶
根据自查意见完善上下文管理规范。补充未覆盖的上下文问题机制，将依赖会话记忆的部分改为文件存储，精简交接包，补充决策可变更标注和 SSOT 定义。
原始规范：【粘贴原始规范】
自查意见：【粘贴自查结果】
4.5 交付给下游节点¶
将上下文交接规范和阶段总结模板复制，交给节点 5（代码变更审查专家）和节点 8（阶段复盘专家）。阶段总结是复盘的输入。
4.6 人工验收清单¶
- [ ] 是否覆盖了六类上下文问题（遗忘/不一致/漂移/误覆盖/TODO脱节/交接断层）？
- [ ] 上下文是否基于文件存储而非 Agent 会话记忆？
- [ ] 交接包是否控制在新 Agent 上下文窗口范围内？
- [ ] 是否明确了 SSOT 权威文件？
- [ ] 决策记录是否有可变更标注？
节点 5：代码变更审查专家¶
5.1 节点定位¶
为 Agent 产出的代码变更设计审查规则，确保每次变更符合职责边界、不破坏他人代码、可追溯。在多 Agent 协作中，无审查的自动提交是灾难的开始。
5.2 输入与输出¶
输入：节点 2 角色分工 + 节点 4 交接规范
输出：变更审查规则 + 审查记录模板
5.3 使用顺序¶
- 先用「快速生成版」得到审查规则初稿。
- 多 Agent 频繁提交时，改用「专家增强版」。
- 用「自查审稿版」检查规则是否能拦截越权变更。
- 有问题则用「返修优化版」修正。
- 对照 5.6 验收清单确认，通过后交给节点 6。
5.4 提示词包¶
A. 快速生成版¶
你是一位代码变更审查设计师。请为多 Agent 协作设计变更审查规则。
角色分工：【粘贴节点2摘要】
输出：
1. 变更提交前的检查项（如：是否在职责范围内、是否动了不该动的文件）
2. 审查记录模板（谁改的、改了什么、是否通过）
3. 变更拒绝的条件
B. 专家增强版¶
你是一位多 Agent 协作的变更管理专家。
任务：设计代码变更审查规则，确保每次 Agent 提交都可控、可追溯、不越权。
输入：
- 角色分工（含可写范围）：【粘贴节点2】
- 上下文交接规范：【粘贴节点4摘要】
处理步骤：
1. 定义变更提交的前置检查（变更是否在该 Agent 职责范围内、是否触碰了不可触碰范围）
2. 定义变更内容审查项（是否符合接口契约、是否破坏已有功能、是否引入安全问题）
3. 设计变更记录格式（变更者/范围/内容摘要/影响/审查结论）
4. 定义变更拒绝条件（越权、破坏接口、未通过审查）
5. 定义变更与 SSOT 的同步规则（变更接口时如何更新 SSOT）
输出格式：
- 提交前检查清单
- 变更审查规则表（检查项|通过标准|拒绝条件）
- 变更记录模板
- 接口变更的特殊流程（涉及 SSOT 更新）
约束：任何触碰"不可触碰范围"的变更默认拒绝；接口变更必须同步更新 SSOT 并通知相关角色。
质量标准：据此规则，可拦截越权修改和破坏性变更，且每次变更都有可追溯记录。
常见失败情况：Agent 修改了不归它管的文件且无人发现；接口变更后 SSOT 未更新导致其他 Agent 用了旧接口。
C. 自查审稿版¶
此为当前节点的自查模式，不是新的专家角色。
请检查以下变更审查规则是否存在以下问题：
1. 是否能拦截 Agent 对"不可触碰范围"的修改？
2. 接口变更是否要求同步更新 SSOT？
3. 变更记录是否可追溯（谁、何时、改了什么、影响什么）？
4. 拒绝条件是否明确可判断？
【粘贴变更审查规则】
逐条说明问题。
D. 返修优化版¶
5.5 交付给下游节点¶
将变更审查规则复制，交给节点 6（冲突与回滚专家）。冲突检测建立在变更记录之上。
5.6 人工验收清单¶
- [ ] 规则是否能拦截对"不可触碰范围"的修改？
- [ ] 接口变更是否要求同步更新 SSOT？
- [ ] 变更记录是否可追溯？
- [ ] 拒绝条件是否明确？
节点 6：冲突与回滚专家¶
6.1 节点定位¶
设计冲突检测规则和回滚预案，当多个 Agent 的变更产生冲突或某次变更引入问题时，能快速检测并安全回退。
6.2 输入与输出¶
输入：节点 5 变更审查规则 + 代码库版本控制方式
输出：冲突检测规则 + 回滚预案（含回滚触发条件和步骤）
6.3 使用顺序¶
- 先用「快速生成版」得到冲突回滚初稿。
- 涉及复杂版本控制或频繁集成时，改用「专家增强版」。
- 用「自查审稿版」检查回滚步骤是否安全可执行。
- 有问题则用「返修优化版」修正。
- 对照 6.6 验收清单确认，通过后交给节点 7。
6.4 提示词包¶
A. 快速生成版¶
你是一位版本冲突与回滚设计师。请设计冲突检测和回滚方案。
变更审查规则：【粘贴节点5摘要】
版本控制方式：【填入 git 等】
输出：
1. 冲突检测规则（如何发现两个变更冲突）
2. 回滚触发条件（什么情况需要回滚）
3. 回滚步骤（如何安全回退）
B. 专家增强版¶
你是一位版本控制与变更治理专家。
任务：为多 Agent 协作设计冲突检测和回滚预案。
输入：
- 变更审查规则：【粘贴节点5】
- 版本控制方式：【填入 git/分支策略】
- 集成频率：【填入每个任务完成后集成 / 定期集成】
处理步骤：
1. 定义冲突类型（文件级冲突、接口级冲突、语义级冲突）
2. 为每类冲突定义检测方法（git 冲突标记、接口契约比对、测试回归）
3. 定义回滚触发条件（集成后测试失败、引入阻断 bug、接口被破坏）
4. 设计分级回滚步骤（回滚单次变更 / 回滚到上一稳定点）
5. 定义回滚后的恢复流程（如何重新应用未冲突的变更）
输出格式：
- 冲突类型与检测表（类型|检测方法|严重度）
- 回滚预案（触发条件|回滚范围|执行步骤|恢复流程）
- 安全集成检查清单（集成前必须确认的项）
约束：回滚步骤必须基于版本控制系统可安全执行，不得依赖手工记忆；回滚不得丢失未冲突的有效变更。
质量标准：发生冲突或引入问题时，可按预案快速恢复到稳定状态，且最小化有效工作的损失。
常见失败情况：回滚时把好的变更也回退了；冲突检测依赖人工肉眼对比；没有稳定点导致无法安全回退。
C. 自查审稿版¶
此为当前节点的自查模式，不是新的专家角色。
请检查以下冲突回滚方案是否存在以下问题：
1. 回滚步骤是否基于版本控制系统可安全执行（不依赖手工记忆）？
2. 回滚是否会误伤未冲突的有效变更？
3. 冲突检测是否覆盖了文件级、接口级、语义级三类？
4. 是否定义了稳定点（可安全回退的基准）？
【粘贴冲突回滚方案】
逐条说明问题。
D. 返修优化版¶
6.5 交付给下游节点¶
将冲突检测规则和回滚预案复制，交给节点 7（TODO 管理专家）。任务状态需反映回滚事件。
6.6 人工验收清单¶
- [ ] 回滚步骤是否基于版本控制可安全执行？
- [ ] 回滚是否避免误伤有效变更？
- [ ] 冲突检测是否覆盖文件级/接口级/语义级？
- [ ] 是否定义了可回退的稳定点？
节点 7：TODO 管理专家¶
7.1 节点定位¶
设计 TODO 与实际代码的同步机制，确保任务状态台账始终反映真实进度。TODO 与代码脱节是协作中最隐蔽的问题——台账说"已完成"，代码里却找不到，下一个 Agent 基于错误信息继续工作。
7.2 输入与输出¶
输入：节点 3 任务队列 + 节点 6 冲突回滚方案
输出：TODO 同步机制 + 状态台账模板（含与代码的核对规则）
7.3 使用顺序¶
- 先用「快速生成版」得到 TODO 机制初稿。
- 任务多、状态变化频繁时，改用「专家增强版」。
- 用「自查审稿版」检查同步机制是否能防止 TODO 与代码脱节。
- 有问题则用「返修优化版」修正。
- 对照 7.6 验收清单确认，通过后交给节点 8。
7.4 提示词包¶
A. 快速生成版¶
你是一位任务台账设计师。请设计 TODO 与代码的同步机制。
任务队列：【粘贴节点3摘要】
输出：
1. 状态台账模板（任务|状态|负责角色|产出位置）
2. 状态更新规则（什么时候改成"完成"）
3. 与代码核对的方法（如何确认"完成"的任务真的有对应代码）
B. 专家增强版¶
你是一位任务治理专家，深知 TODO 与代码脱节的危害。
任务：设计 TODO 状态管理与代码同步机制。
输入：
- 任务队列：【粘贴节点3】
- 冲突回滚方案：【粘贴节点6摘要】
处理步骤：
1. 设计状态台账（任务ID、状态、负责角色、产出物位置、完成证据）
2. 定义状态流转规则（待办→进行中→待审查→已完成，每步的进入条件）
3. 定义"完成"的强证据要求（产出物存在 + 通过验收 + 已集成）
4. 设计交接时的强制核对（下一个 Agent 接手前核对台账与代码是否一致）
5. 定义回滚时的台账更新规则（回滚的任务状态如何变更）
输出格式：
- 状态台账模板
- 状态流转规则表（状态|进入条件|证据要求）
- 交接核对清单（核对台账与实际代码的具体步骤）
约束：标记为"已完成"必须有可验证的证据（文件存在/测试通过），不能仅凭 Agent 声明；交接时必须核对台账与代码的一致性。
质量标准：任意时刻台账都准确反映真实进度，新 Agent 可信任台账而无需重新核查全部代码。
常见失败情况：Agent 声称完成但代码未提交，台账却标记完成；回滚后忘记更新台账状态。
C. 自查审稿版¶
此为当前节点的自查模式，不是新的专家角色。
请检查以下 TODO 同步机制是否存在以下问题：
1. 标记"已完成"是否要求可验证的证据（而非仅凭 Agent 声明）？
2. 交接时是否有台账与代码的强制核对步骤？
3. 回滚时是否有台账状态更新规则？
4. 状态流转的进入条件是否明确？
【粘贴 TODO 同步机制】
逐条说明问题。
D. 返修优化版¶
7.5 交付给下游节点¶
将 TODO 同步机制和状态台账复制，交给节点 8（阶段复盘专家）。复盘需要台账反映的真实进度。
7.6 人工验收清单¶
- [ ] "已完成"是否要求可验证证据（而非仅凭声明）？
- [ ] 交接时是否有台账与代码的核对步骤？
- [ ] 回滚时是否有台账更新规则？
- [ ] 状态流转条件是否明确？
节点 8：阶段复盘专家¶
8.1 节点定位¶
在每个协作阶段结束时进行复盘，总结进展、识别协作问题、调整下阶段策略。复盘让协作机制本身能够迭代改进。
8.2 输入与输出¶
输入：节点 4 阶段总结 + 节点 7 状态台账 + 本阶段变更/冲突记录
输出：阶段复盘记录 + 下阶段调整建议
8.3 使用顺序¶
- 先用「快速生成版」得到复盘初稿。
- 协作问题较多或需要机制调整时，改用「专家增强版」。
- 用「自查审稿版」检查复盘是否基于真实数据、建议是否可执行。
- 有问题则用「返修优化版」修正。
- 对照 8.6 验收清单确认。
8.4 提示词包¶
A. 快速生成版¶
你是一位协作复盘专家。请基于以下材料做阶段复盘。
阶段总结：【粘贴节点4产出的阶段总结】
状态台账：【粘贴节点7台账】
本阶段问题：【填入遇到的冲突/返工等】
输出：
1. 本阶段完成情况（对照目标）
2. 协作中出现的问题
3. 下阶段调整建议
B. 专家增强版¶
你是一位多 Agent 协作复盘专家。
任务：对本协作阶段进行系统复盘，并提出可执行的机制改进。
输入：
- 阶段总结：【粘贴节点4的阶段总结】
- 状态台账：【粘贴节点7的台账】
- 变更与冲突记录：【粘贴本阶段变更/冲突/回滚记录】
- 原始项目目标：【粘贴节点1的主目标，用于检查是否漂移】
复盘维度：
1. 目标对齐：本阶段产出是否仍服务于原始目标（有无漂移）
2. 进度真实性：台账状态与实际代码是否一致
3. 协作问题：上下文交接、职责边界、冲突处理中暴露的问题
4. 机制有效性：上下文管理、审查、TODO 机制是否真正发挥作用
5. 改进项：下阶段需要调整的机制或分工
输出格式：
- 完成情况表（目标|计划|实际|差异）
- 协作问题清单（问题|根因|影响）
- 机制改进建议（针对哪个节点的机制，怎么改）
- 下阶段目标锚点（重申下阶段要达成什么）
约束：复盘必须基于台账和记录的真实数据，不能凭印象；改进建议必须指向具体机制。
质量标准：复盘能发现协作机制的真实短板，改进建议下阶段可直接采纳。
常见失败情况：复盘变成成绩汇报不谈问题；改进建议空泛（"加强沟通"）；忽略目标漂移。
C. 自查审稿版¶
此为当前节点的自查模式，不是新的专家角色。
请检查以下阶段复盘是否存在以下问题：
1. 复盘是否基于台账和记录的真实数据（而非印象）？
2. 是否检查了目标是否漂移？
3. 改进建议是否指向具体机制（而非"加强沟通"这类空泛建议）？
4. 是否同时包含了问题，而非只报成绩？
【粘贴阶段复盘】
逐条说明问题。
D. 返修优化版¶
8.5 交付给下游节点¶
本节点是工作流终点（单阶段）。复盘记录和下阶段调整建议作为下一轮协作的输入，整合进治理方案。多阶段项目可循环执行节点 4-8。
8.6 人工验收清单¶
- [ ] 复盘是否基于台账和记录的真实数据？
- [ ] 是否检查了目标漂移？
- [ ] 改进建议是否指向具体机制？
- [ ] 是否包含了问题而非只报成绩？
节点交接说明¶
| 上游节点 | 交接内容 | 下游节点 |
|---|---|---|
| 节点 1 目标拆解 | 目标树 + 子任务表 | 节点 2、节点 3 |
| 节点 2 角色分工 | Agent 角色定义表（含可写范围） | 节点 3、节点 5 |
| 节点 3 任务队列 | 任务队列（含就绪条件） | 节点 4、节点 7 |
| 节点 4 上下文管理 | 交接规范 + 阶段总结模板 + SSOT 结构 | 节点 5、节点 8 |
| 节点 5 变更审查 | 变更审查规则 + 记录模板 | 节点 6 |
| 节点 6 冲突回滚 | 冲突检测规则 + 回滚预案 | 节点 7 |
| 节点 7 TODO 管理 | TODO 同步机制 + 状态台账 | 节点 8 |
| 节点 8 阶段复盘 | 复盘记录 + 下阶段调整 | 下一轮协作（节点4-8循环） |
最终输出模板¶
【项目名称】多 Agent 协作治理方案
━━ 目标拆解 ━━
主目标：【填入】
子任务清单：【任务ID | 交付物 | 验收标准 | 依赖】
接口边界（需冻结）：【列出】
━━ Agent 角色分工 ━━
| 角色 | 负责子任务 | 可写范围 | 不可触碰范围 |
━━ 任务队列 ━━
| 任务ID | 负责角色 | 就绪条件 | 完成标志 | 状态 |
执行批次：【第1批并行... 第2批...】
━━ 上下文管理 ━━
SSOT 权威文件：【列出哪些文件是单一事实来源】
阶段总结模板：【已完成|关键决策|未决项|下一步|相关文件】
交接包必读项：【列出】
决策记录：【决策|理由|可否变更】
━━ 变更审查规则 ━━
提交前检查：【列出】
拒绝条件：【列出】
━━ 冲突与回滚 ━━
稳定点：【定义】
回滚触发条件：【列出】
━━ TODO 台账 ━━
| 任务ID | 状态 | 负责角色 | 产出位置 | 完成证据 |
━━ 阶段复盘 ━━
完成情况：【填入】
协作问题与改进：【填入】
下阶段目标锚点：【填入】
常见错误¶
错误 1：把多 Agent 协作当成"多个 AI 一起聊天"
表现：开几个 AI 会话各自提需求，没有任务队列、没有职责边界、没有交接规范，最后产出互相冲突、无法集成。
修复：协作必须工程化。先完成节点 1-3 建立任务和角色结构，再用节点 4 建立上下文交接规范，让协作成为有调度、有边界、有记录的工程过程。
错误 2：上下文存在 Agent 会话里
表现：关键决策和进度都在某个 Agent 的对话历史中，会话一结束或上下文一满，信息全部丢失，下一个 Agent 无从接手。
修复：执行节点 4（招牌节点），所有关键上下文（决策、SSOT、阶段总结）必须外置到文件，Agent 会话只是工作现场，文件才是记忆。
错误 3：TODO 标记完成但代码没有
表现：台账显示某任务已完成，下一个 Agent 基于此继续，结果发现根本没有对应代码，造成连锁返工。
修复：执行节点 7，"已完成"必须有可验证证据（文件存在+测试通过+已集成），交接时强制核对台账与实际代码的一致性。
人工验收清单¶
- [ ] 子任务粒度是否适合单次 Agent 会话完成，且接口边界已冻结？
- [ ] Agent 角色的可写范围是否无重叠，共享接口是否有唯一负责角色？
- [ ] 上下文是否全部外置到文件（不依赖 Agent 会话记忆）？
- [ ] 交接包是否能让新 Agent 在不了解历史会话的情况下接手？
- [ ] TODO 台账的"已完成"是否都有可验证证据？
延伸玩法¶
- 变体 1：单人多会话版：即使只有一个人用一个 AI 工具，跨多次会话开发时也会遇到上下文丢失。用节点 4 的交接规范和节点 7 的 TODO 台账，让每次新会话都能准确接手上次进度。
- 变体 2：人机混合版：部分任务由 Agent 完成、部分由人完成时，用同一套任务队列和变更审查规则统一治理，人和 Agent 遵循相同的交接和审查标准。
- 进阶组合：与"工作流 11（程序员开发工作流）"结合，将工作流 11 作为单个 Agent 执行某个子任务的内部流程，本工作流负责多个子任务之间的协作治理；与"工作流 13（安全审查工作流）"结合，在节点 5 变更审查中嵌入安全审查环节。