# Agent Team Workflows 通用编排框架,支持 5 人团队(1 名 Lead + 4 名 Teammate),适用于任何领域。 ## 前置条件 必须启用 Agent Teams。在 ~/.claude/settings.json 中添加: ``json { "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" } } ` ## 通用角色 Teammate ID 固定。其职能通过角色卡(Role Cards)按领域重新映射。 | 槽位 | ID | 通用职能 | 核心职责 | |------|----|----------|----------| | Lead | (session) | 编排者 | 分配任务、传递上下文、质量把关、合成最终输出 | | Slot A | architect | 规划者 | 定义问题、拆分任务、产出计划/规格/蓝图 | | Slot B | developer | 构建者 | 产出主要工件(代码、草稿、数据集、模型、方案) | | Slot C | tester | 验证者 | 对照验收标准进行测试、评估正确性 | | Slot D | reviewer | 评审者 | 评估质量、风险、一致性、合规性,提出改进建议 | ### 角色卡(按领域重映射) 每个领域预设提供角色卡,将通用职能专业化: | 领域 | 规划者 | 构建者 | 验证者 | 评审者 | |--------|--------|--------|--------|--------| | 软件开发 | Architect | Developer | Tester | Code Reviewer | | 内容创作 | Producer | Writer | Fact-Checker | Editor | | 数据分析 | Analyst Lead | Data Engineer | Statistician | Peer Reviewer | | 商业策略 | Strategist | Business Analyst | Financial Modeler | Risk Advisor | | 研究 | Research Lead | Researcher | Methodology Auditor | Peer Reviewer | > 完整角色卡及工件契约见 → reference/domain-presets.md ## 流水线模式 4 种经典控制流模式。领域含义由角色卡决定,而非模式本身。 ### 1. sequential — 顺序流水线 ` 规划者 → 构建者 → 验证者 → 评审者 → Lead 合成 ` 何时使用: 工作呈线性,每一步依赖前一步输出。 示例: 功能开发、内容创作、报告撰写。 ### 2. parallel-merge — 并行探索 + 合并 ` 规划者 → (构建者 ∥ 验证者 ∥ 评审者) → Lead 合并 → 验证者把关 → Lead 合成 ` 何时使用: 多个视角可独立作业,再合并结果。 示例: 研究、策略分析、多角度评估。 ### 3. iterative-review — 构建-评审循环 ` 规划者 → 构建者 ↔ 评审者(最多 N 轮)→ 验证者 → Lead 合成 ` 何时使用: 质量需创作者与评审者多次迭代。 示例: 内容编辑、设计打磨、方案起草。 保护: 默认最多 2 轮。更多需用户批准。 ### 4. fan-out-fan-in — 分治-归并 ` 规划者 → 将任务分发给 4 名队友 → Lead 归并 → 评审者把关 → Lead 合成 ` 何时使用: 大量工作可拆为独立块并行处理。 示例: 多模块功能、大数据集处理、代码库审计。 > 模式深入及示例任务图 → reference/patterns.md ## 协作协议 严格 6 步协议,与领域无关。 ### 步骤 1:确认范围 在生成任何团队前,与用户确认: 1. 目标 —— 具体交付物 2. 领域 —— 选择预设或自定义角色卡 3. 模式 —— 哪种流水线模式合适 4. 约束 —— 工具、技术栈、语气、合规、预算 5. 输入 —— 源材料、已有资产、上下文文件 6. 完成定义 —— 用户同意的验收标准 ### 步骤 2:填写工作流实例规格 使用通用模板: ` 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(每步) Step 1 → [工件名]: [格式/内容描述] Step 2 → [工件名]: [格式/内容描述] Step 3 → [工件名]: [格式/内容描述] Step 4 → [工件名]: [格式/内容描述] CONSTRAINTS: [工具、规则、限制] INPUTS: [文件、数据、参考资料] DEFINITION OF DONE: □ [标准 1] □ [标准 2] □ [标准 3] ` ### 步骤 3:创建团队 ` 创建 4 名队友: - architect: [规划者角色卡 — 上下文与职责] - developer: [构建者角色卡 — 上下文与职责] - tester: [验证者角色卡 — 上下文与职责] - reviewer: [评审者角色卡 — 上下文与职责] ` ### 步骤 4:创建带依赖的任务 按所选模式的流水线顺序创建任务。每个任务必须包含: - 清晰的描述,引用角色卡 - 所需输入工件(上一步或原始输入) - 所需输出工件(格式 + 内容) - 验收标准 - 对前驱任务的依赖 ### 步骤 5:用丰富上下文生成队友 每个队友的生成提示必须包含: 1. 角色卡 —— 领域头衔 + 具体职责 2. 被分配的任务 —— 需产出的内容 3. 输入工件 —— 上一步输出(Lead 必须转发) 4. 输出工件契约 —— 期望的格式与内容 5. 约束 —— 领域规则、风格指南、合规 6. 交接指令 —— “完成后向 Lead 发送 [工件]” 通用生成模板: ` 生成一名 [ID] 队友,提示如下: "你是 [Domain Title]([Generic Function])。 YOUR TASK: [任务描述] INPUT: [粘贴或引用上一步输出] PRODUCE: [工件名] Format: [期望格式] Must include: [必需章节/要素] CONSTRAINTS: - [规则 1] - [规则 2] 完成后,向 Lead 发送完整的 [工件名]。若遇到阻塞,立即联系 Lead。" ` ### 步骤 6:协调交接 当队友完成某步: 1. Lead 通过消息接收输出 2. Lead 按验收标准验证输出 3. Lead 将工件 + 相关上下文通过消息传递给下一队友 4. 若输出不足 → 发送具体反馈,要求修订 ### 步骤 7:合成并交付 所有步骤完成后: 1. 收集全部工件 2. 验证所有“完成定义”标准已满足 3. 总结所做工作(可追溯:每条标准由哪一步满足) 4. 列出剩余 TODO 或已知问题 5. 向用户呈现最终交付物 ## Lead 纪律规则 1. 仅委派 —— Lead 不产出主要工件。使用委派模式(Shift+Tab)。 2. 传递全部上下文 —— 队友无共享历史。Lead 必须在步骤间转发相关工件。 3. 直接消息 —— 使用直接消息,而非广播(节省 4 倍 token)。仅在并行合并同步点广播。 4. 任务粒度适中 —— 每名队友最多 5-6 个任务。大任务需拆分。 5. 高风险操作把关 —— 需用户批准的情况:不可逆变更、对外发布、法律/合规、高成本操作、生产部署。 6. 等待队友 —— 绝不自行继续或实现。等待队友完成后再推进。 ## 故障处理 | 情况 | 操作 | |-----------|--------| | 队友卡住 | 发送额外上下文、提示或简化子任务 | | 输出不佳 | 针对验收标准发送具体反馈,要求修订 | | 队友停止 | 用相同上下文 + 已做工作摘要重新生成队友 | | 队友间冲突 | Lead 调解,做出最终决定,向双方发送决议 | | 任务过大 | Lead 拆分为子任务,重新分配给队友 | | 迭代循环超限 | 询问用户是否批准更多轮次或冻结当前状态 | ## 成本指南 | 模式 | 估算成本 | 何时值得 | |---------|-----------|---------------| | sequential | 约 4-5× 单 agent | 工作跨越 3+ 工件/文件且流程清晰 | | parallel-merge | 约 4× 单 agent | 需要 3+ 独立视角 | | iterative-review | 约 3-4× 单 agent | 质量需创作者-评审者对话 | | fan-out-fan-in | 约 5× 单 agent | 大量工作可拆为独立块 | 经验法则: 若单 agent 一次会话可完成,就不必用团队。团队适用于可并行或需多专业视角的工作。 ## 领域预设(速查) | 预设 | 推荐模式 | 关键工件 | |--------|-------------------|---------------| | software-dev | sequential / fan-out-fan-in | 设计文档、源代码、测试套件、评审报告 | | content-creation | iterative-review | 内容简报、草稿、事实核查报告、终稿编辑 | | data-analysis | fan-out-fan-in | 分析计划、数据集/转换、统计评估、发现报告 | | business-strategy | parallel-merge | 策略框架、市场分析、财务模型、风险评估 | | research | parallel-merge | 研究计划、文献综述、方法论审计、综述论文 | > 完整预设含角色卡、工件及示例 → reference/domain-presets.md > 即用提示模板 → reference/prompt-templates.md > 模式深入 → reference/patterns.md`
Universal orchestration framework for 5-agent teams (1 Lead + 4 Teammates) across any domain.
Prerequisites
Agent Teams must be enabled. Add to ~/.claude/settings.json:
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
Generic Roles
Teammate IDs are fixed. Their function is remapped per domain via Role Cards.
| Slot | ID | Generic Function | Core Responsibility |
|---|
| Lead | (session) | Orchestrator | Assign tasks, relay context, quality gate, synthesize final output |
| Slot A | architect | Planner | Frame problem, decompose tasks, produce plan/spec/blueprint |
| Slot B | developer | Builder | Produce primary artifact (code, draft, dataset, model, proposal) |
| Slot C | tester | Validator | Check against acceptance criteria, test, evaluate correctness |
| Slot D | reviewer | Critic | Assess quality, risk, consistency, compliance, suggest improvements |
Role Cards (Domain Remapping)
Each domain preset provides Role Cards that specialize the generic functions:
| Domain | Planner | Builder | Validator | Critic |
|---|
| Software Dev | Architect | Developer | Tester | Code Reviewer |
| Content Creation | Producer | Writer | Fact-Checker | Editor |
| Data Analysis | Analyst Lead | Data Engineer | Statistician | Peer Reviewer |
| Business Strategy | Strategist | Business Analyst | Financial Modeler | Risk Advisor |
| Research | Research Lead | Researcher | Methodology Auditor | Peer Reviewer |
Full role cards with artifact contracts → reference/domain-presets.md
Pipeline Patterns
4 canonical control-flow patterns. Domain meaning comes from Role Cards, not the pattern itself.
1. sequential — Step-by-Step Pipeline
Planner → Builder → Validator → Critic → Lead Synthesis
Use when: Work is linear and each step depends on the previous output.
Examples: Feature dev, content creation, report writing.
2. parallel-merge — Parallel Exploration + Merge
Planner → (Builder ∥ Validator ∥ Critic) → Lead Merge → Validator Gate → Lead Synthesis
Use when: Multiple perspectives can work independently, then combine.
Examples: Research, strategy analysis, multi-angle evaluation.
3. iterative-review — Build-Critique Loop
Planner → Builder ↔ Critic (max N rounds) → Validator → Lead Synthesis
Use when: Quality requires iteration between creator and reviewer.
Examples: Content editing, design refinement, proposal drafting.
Guard: Default max 2 rounds. More requires user approval.
4. fan-out-fan-in — Map-Reduce
Planner → fan-out tasks to all 4 teammates → Lead fan-in merge → Critic Gate → Lead Synthesis
Use when: Large work can be split into independent chunks processed in parallel.
Examples: Multi-module features, large dataset processing, codebase audit.
Pattern deep dives with sample task graphs → reference/patterns.md
Coordination Protocol
Strict 6-step protocol, domain-agnostic.
Step 1: Confirm Scope
Before spawning any team, confirm with user:
- Objective — specific deliverable
- Domain — select preset or define custom Role Cards
- Pattern — which pipeline pattern fits
- Constraints — tools, tech stack, tone, compliance, budget
- Inputs — source material, existing assets, context files
- Definition of Done — checkbox acceptance criteria the user agrees to
Step 2: Build Workflow Instance Spec
Fill in the universal template:
WORKFLOW INSTANCE SPEC
─────────────────────
Objective: [deliverable]
Pattern: [sequential | parallel-merge | iterative-review | fan-out-fan-in]
Domain: [preset name or "custom"]ROLE CARDS
Planner (architect): [domain title] — [specific responsibility]
Builder (developer): [domain title] — [specific responsibility]
Validator (tester): [domain title] — [specific responsibility]
Critic (reviewer): [domain title] — [specific responsibility]
ARTIFACTS (per step)
Step 1 → [artifact name]: [format/content description]
Step 2 → [artifact name]: [format/content description]
Step 3 → [artifact name]: [format/content description]
Step 4 → [artifact name]: [format/content description]
CONSTRAINTS: [tools, rules, limits]
INPUTS: [files, data, references]
DEFINITION OF DONE:
□ [criterion 1]
□ [criterion 2]
□ [criterion 3]
Step 3: Create Team
Create a team of 4 teammates:
- architect: [Planner role card — context and responsibility]
- developer: [Builder role card — context and responsibility]
- tester: [Validator role card — context and responsibility]
- reviewer: [Critic role card — context and responsibility]
Step 4: Create Tasks with Dependencies
Create tasks following the selected pattern's pipeline order. Each task MUST have:
- Clear description referencing role card
- Required input artifact (from previous step or original inputs)
- Required output artifact (format + content)
- Acceptance criteria
- Dependency on predecessor task
Step 5: Spawn Teammates with Rich Context
Each teammate MUST receive in their spawn prompt:
- Role Card — their domain title + specific responsibilities
- Assigned task — what to produce
- Input artifact — output from previous step (Lead must relay this)
- Output artifact contract — exact format and content expected
- Constraints — domain rules, style guides, compliance
- Handoff instruction — "Message the lead with [artifact] when done"
Universal spawn template:
Spawn a [ID] teammate with the prompt:
"You are the [Domain Title] ([Generic Function]).YOUR TASK: [task description]
INPUT: [paste or reference previous step's output]
PRODUCE: [artifact name]
Format: [expected format]
Must include: [required sections/elements]
CONSTRAINTS:
When done, message the lead with your complete [artifact name].
If you encounter blockers, message the lead immediately."
Step 6: Coordinate Handoffs
When a teammate completes their step:
- Lead receives output via message
- Lead validates output against acceptance criteria
- Lead passes artifact + relevant context to next teammate via message
- If output is insufficient → send specific feedback, ask to revise
Step 7: Synthesize & Deliver
After all steps complete:
- Collect all artifacts
- Verify all Definition of Done criteria are met
- Summarize what was done (traceability: each criterion → which step satisfied it)
- List remaining TODOs or known issues
- Present final deliverable to user
Lead Discipline Rules
- Delegate only — Lead does NOT produce primary artifacts. Use delegate mode (
Shift+Tab).
- Relay all context — Teammates have no shared history. Lead MUST forward relevant artifacts between steps.
- Direct messages — Use direct messages, not broadcast (saves 4× tokens). Broadcast only for parallel-merge sync points.
- Right-size tasks — 5-6 tasks per teammate max. Split large work.
- Gate high-risk actions — Require user approval for: irreversible changes, external publication, legal/compliance, high-cost operations, production deployments.
- Wait for teammates — Never proceed or implement yourself. Wait for teammate completion before next step.
Handling Failures
| Situation | Action |
|---|
| Teammate stuck | Message with additional context, hints, or simplified sub-task |
| Bad output | Send specific feedback citing acceptance criteria, ask to revise |
| Teammate stops | Spawn replacement with same context + summary of work already done |
| Conflict between teammates | Lead mediates, makes final decision, messages both with resolution |
| Task too large | Lead splits into subtasks, reassigns across teammates |
| Iterative loop exceeds max | Ask user whether to approve more rounds or finalize current state |
Cost Guidelines
| Pattern | Est. Cost | Worth It When |
|---|
| sequential | ~4-5× single | Work spans 3+ artifacts/files with clear pipeline |
| parallel-merge | ~4× single | 3+ independent perspectives needed |
| iterative-review | ~3-4× single | Quality requires creator-critic dialogue |
| fan-out-fan-in | ~5× single | Large work divisible into independent chunks |
Rule of thumb: If one agent can finish in one session, don't use a team. Teams shine when work is parallelizable or benefits from multiple specialized perspectives.
Domain Presets (Quick Reference)
| Preset | Recommended Pattern | Key Artifacts |
|---|
software-dev | sequential / fan-out-fan-in | Design doc, source code, test suite, review report |
content-creation | iterative-review | Content brief, draft, fact-check report, final edit |
data-analysis | fan-out-fan-in | Analysis plan, datasets/transforms, statistical evaluation, findings report |
business-strategy | parallel-merge | Strategy framework, market analysis, financial model, risk assessment |
research | parallel-merge | Research plan, literature review, methodology audit, synthesis paper |
Full presets with role cards, artifacts, and worked examples → reference/domain-presets.md
Ready-to-use prompt templates → reference/prompt-templates.md
Pattern deep dives → reference/patterns.md