智能体团队工作流

面向任意领域的通用编排框架，支持由 5 个智能体组成的团队（1 名 Lead + 4 名 Teammate）。

前提条件

必须启用智能体团队功能。请在 ~/.claude/settings.json 中添加以下配置：

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

通用角色定义

Teammate ID 固定不变，其职能通过角色卡（Role Cards）按领域动态映射。

角色卡（Role Cards，领域映射）

每个领域预设均提供角色卡（Role Cards），用于将通用职能专业化：

完整角色卡及产物契约 → reference/domain-presets.md

流水线模式（Pipeline Patterns）

共 4 种标准控制流模式。领域语义来源于角色卡，而非模式本身。

1. sequential — 分步式流水线

Planner → Builder → Validator → Critic → Lead Synthesis

适用场景： 工作流程呈线性，且每一步均依赖前一步的输出。
典型示例： 功能开发、内容创作、报告撰写。

2. parallel-merge — 并行探索 + 合并

Planner → (Builder ∥ Validator ∥ Critic) → Lead Merge → Validator Gate → Lead Synthesis

适用场景： 多个视角可独立开展工作，再统一整合。
典型示例： 研究项目、策略分析、多角度评估。

3. iterative-review — 构建-评审循环

Planner → Builder ↔ Critic (max N rounds) → Validator → Lead Synthesis

适用场景： 质量提升需在创作者与评审者之间反复迭代。
典型示例： 内容编辑、设计精修、提案起草。
守卫机制： 默认最多执行 2 轮；若需更多轮次，须获得用户明确批准。

4. fan-out-fan-in — Map-Reduce 模式

Planner → 将任务分发至全部 4 名 teammate → Lead 汇总合并 → Critic Gate → Lead Synthesis

适用场景： 大型任务可拆分为多个相互独立的子任务，并行处理。
典型示例： 多模块功能开发、大规模数据集处理、代码库审计。

各模式深度解析及示例任务图 → reference/patterns.md

协同协议（Coordination Protocol）

严格遵循 6 步协议，与具体领域无关。

第 1 步：确认范围（Confirm Scope）

在启动任何团队前，须与用户确认以下六项：

1. 目标（Objective） — 明确的交付物
2. 领域（Domain） — 选择预设或自定义角色卡
3. 模式（Pattern） — 选用哪一类流水线模式
4. 约束条件（Constraints） — 工具、技术栈、语气风格、合规要求、预算限制等
5. 输入项（Inputs） — 原始资料、已有资产、上下文文件等
6. 完成定义（Definition of Done） — 用户认可的、带复选框的验收标准

第 2 步：构建工作流实例规范（Build Workflow Instance Spec）

填充如下通用模板：

WORKFLOW INSTANCE SPEC
─────────────────────
Objective:      [交付物]
Pattern:        [sequential | parallel-merge | iterative-review | fan-out-fan-in]
Domain:         [预设名称 或 "custom"]

ROLE CARDS
  Planner (architect):  [领域头衔] — [具体职责]
  Builder (developer):  [领域头衔] — [具体职责]
  Validator (tester):   [领域头衔] — [具体职责]
  Critic (reviewer):    [领域头衔] — [具体职责]

ARTIFACTS (per step)
  Step 1 → [产物名称]: [格式/内容描述]
  Step 2 → [产物名称]: [格式/内容描述]
  Step 3 → [产物名称]: [格式/内容描述]
  Step 4 → [产物名称]: [格式/内容描述]

CONSTRAINTS:    [工具、规则、限制]
INPUTS:         [文件、数据、参考材料]
DEFINITION OF DONE:
  □ [验收标准 1]
  □ [验收标准 2]
  □ [验收标准 3]

第 3 步：创建团队（Create Team）

创建由 4 名 teammate 组成的团队：
- architect: [Planner 角色卡 — 上下文与职责]
- developer: [Builder 角色卡 — 上下文与职责]
- tester:    [Validator 角色卡 — 上下文与职责]
- reviewer:  [Critic 角色卡 — 上下文与职责]

第 4 步：创建带依赖关系的任务（Create Tasks with Dependencies）

依据所选模式的流水线顺序创建任务。每个任务必须包含以下要素：

• 清晰的任务描述（需引用对应角色卡）
• 必需的输入产物（来自前序步骤或原始输入）
• 必需的输出产物（格式 + 内容）
• 验收标准
• 对前置任务的依赖关系

第 5 步：以丰富上下文启动 teammate（Spawn Teammates with Rich Context）

每位 teammate 在启动提示词中必须接收以下六类信息：

1. 角色卡（Role Card） — 其领域头衔与具体职责
2. 指派任务（Assigned task） — 需产出的内容
3. 输入产物（Input artifact） — 前序步骤的输出（由 Lead 负责转达）
4. 输出产物契约（Output artifact contract） — 明确规定的格式与内容要求
5. 约束条件（Constraints） — 领域规则、风格指南、合规要求等
6. 交接指令（Handoff instruction） — “完成后向 Lead 发送 [产物名称]”

通用启动模板：

使用如下提示词启动一名 [ID] teammate：
"你是一名 [领域头衔]（[通用职能]）。

你的任务：[任务描述]

输入：[粘贴或引用前序步骤输出]

需产出：[产物名称]
格式：[预期格式]
必须包含：[必需章节/要素]

约束条件：
- [规则 1]
- [规则 2]

完成后，请将完整的 [产物名称] 发送给 Lead。
如遇阻塞，请立即向 Lead 发送消息。"

第 6 步：协调交接（Coordinate Handoffs）

当某位 teammate 完成其步骤后：

1. Lead 通过消息接收其输出
2. Lead 根据验收标准校验输出质量
3. Lead 将该产物及关联上下文，通过消息传递给下一位 teammate
4. 若输出不达标 → 提供具体反馈，并要求修订

第 7 步：整合与交付（Synthesize & Deliver）

所有步骤完成后：

1. 汇总全部产物
2. 逐条核验“完成定义（Definition of Done）”中的各项标准是否均已满足
3. 总结已完成工作（具备可追溯性：每项标准需注明由哪一步骤满足）
4. 列出尚未完成事项（TODO）或已知问题
5. 向用户正式提交最终交付物

Lead 行为规范（Lead Discipline Rules）

1. 仅限委派（Delegate only） — Lead 不得直接产出主要产物。请使用委派模式（Shift+Tab）。
2. 完整传递上下文（Relay all context） — Teammate 之间无共享历史。Lead 必须在各步骤间转发相关产物。
3. 使用定向消息（Direct messages） — 优先使用定向消息而非广播（可节省 4× token）。仅在 parallel-merge 的同步点使用广播。
4. 合理划分任务粒度（Right-size tasks） — 每名 teammate 最多承担 5–6 个任务；大型工作应主动拆分。
5. 高风险操作需人工把关（Gate high-risk actions） — 对以下操作须获得用户批准：不可逆变更、对外发布、法律/合规事项、高成本操作、生产环境部署。
6. 静待 teammate 完成（Wait for teammates） — 不得跳过或自行执行下一步；必须等待 teammate 完成后，方可推进。

异常处理（Handling Failures）

成本参考指南（Cost Guidelines）

经验法则： 若单个智能体可在一次会话内完成任务，则无需启用团队。团队的价值体现在任务具备并行潜力，或显著受益于多个专业视角的协同。

领域预设（Domain Presets，速查表）

完整预设（含角色卡、产物定义与实操示例）→ reference/domain-presets.md
开箱即用的提示词模板 → reference/prompt-templates.md
各模式深度解析 → reference/patterns.md