自定义工作流

使用 Team Mode 和 12 个 team_* 工具构建自定义多 Agent（智能体） 工作流，以及 Hyperplan 对抗式规划模式的设计哲学。

文章概述

当内置工作流不能满足你的需求时，oh-my-openagent 的 Team Mode（v4.0+）提供了完整的自定义能力。你可以创建自己的多 Agent 团队，定义它们的角色、通信方式和任务分配策略。本文是 Team Mode 的完整指南。

读完本文，你将能够使用 Team Mode 和 team_* 工具构建自定义多 Agent 工作流，理解 Hyperplan 对抗式规划的设计哲学，以及掌握设计自定义工作流的四个关键步骤。

我们从 Team Mode 的架构概览开始，介绍可用的 Agent 类型（sisyphus / atlas / sisyphus-junior / hephaestus）和启用配置。然后逐一讲解 12 个 team_* 工具——从团队创建、成员管理到任务调度和通信的全套 API。接着深入两个内置 Team Skills：Hyperplan（5 个“敌对“评审者交叉批评的对抗式规划）和 security-research（5 人安全团队并行审计），理解它们的设计哲学。最后，你将学会设计自定义工作流的四个步骤（拆解→映射→配置→验证），并看到常见工作流模板和完整的实战示例。

⏱ 时间有限？先读这些： Team Mode 概览 → 12 个 team_* 工具 → 内置 Team Skills → 设计自定义工作流

Team Mode 概览

Team Mode 是 oh-my-openagent（OMO）v4.0 引入的核心创新，它将单 Agent 系统升级为多 Agent 并行协作系统。Team Mode 的价值不仅在于提升效率，更在于实现“职责分离“这一核心安全原则。

架构设计

Team Mode 采用“协调者-工作者“（Orchestrator-Workers）架构，由一个主 Agent（Sisyphus）协调多个子 Agent 并行执行任务。

flowchart TB
    subgraph Team Mode 架构
        A[Sisyphus<br/>主 Agent/协调者] --> B[Atlas<br/>工作者 Agent]
        A --> C[Sisyphus-Junior<br/>轻量协调者]
        A --> D[Hephaestus<br/>工匠 Agent]
    end

    subgraph 工具层
        E[team_* 工具集<br/>12 个 API]
    end

    subgraph 通信层
        F[消息队列]
        G[任务调度器]
        H[状态同步器]
    end

    A --> E
    B --> E
    C --> E
    D --> E
    E --> F
    E --> G
    E --> H

    style A fill:#4A90D9,color:#fff
    style B fill:#50C878,color:#fff
    style C fill:#50C878,color:#fff
    style D fill:#FF9F43,color:#fff
    style E fill:#A66CFF,color:#fff

架构安全特性：

何时不适合 Team Mode

⚠️ Team Mode 并不适合所有场景。在以下场景中，使用 Team Mode 反而会降低效率：（1）简单单文件任务——启动多 Agent 的协调开销超过执行收益；（2）强实时交互——需要与用户频繁确认的任务，多 Agent 的异步通信增加延迟；（3）资源受限环境——每个 Agent 消耗独立的上下文窗口，总 Token 消耗显著高于单 Agent。作为经验法则：子任务少于 3 个或预计执行时间少于 5 分钟的任务，建议使用单 Agent 或派生模式。

启用配置

Team Mode 需要在 .opencode/oh-my-openagent.jsonc 中显式启用（Team Mode 是 OMO 插件功能，配置在插件命名空间下）：

{
  "plugins": {
    "oh-my-openagent": {
      "team_mode": {
        "enabled": true,
        "max_teams": 5,
        "max_members_per_team": 10,
        "default_agent": "sisyphus",
        "communication": {
          "message_timeout": 30000,
          "task_timeout": 300000,
          "retry_count": 3
        },
        "security": {
          "isolate_workdir": true,
          "audit_all_messages": true,
          "deny_nested_teams": true
        }
      }
    }
  }
}

安全配置说明：

可用 Agent 类型

Team Mode 提供四种 Agent 类型，每种有不同的职责和权限边界：

Sisyphus（主 Agent/协调者）

职责：团队协调者，负责任务分配、进度监控和结果汇总。

权限矩阵：

安全考量：Sisyphus 作为协调者，拥有较高权限但不允许委派任务，防止权限链式传递。

Atlas（工作者 Agent）

职责：执行具体任务的工作者，由 Sisyphus 分配任务。

权限矩阵：

安全考量：Atlas 权限受限，只能执行分配的任务，且只能发送消息不能管理团队。

Sisyphus-Junior（轻量协调者）

职责：轻量级协调者，用于子任务组的协调。

权限矩阵：

安全考量：Sisyphus-Junior 是“只读协调者“，适合纯规划/审查场景。

Hephaestus（工匠 Agent）

职责：专注于代码实现的工匠，拥有完整的开发权限。

权限矩阵：

安全考量：Hephaestus 权限最高，适合受信任的实现任务，但必须在隔离环境中运行。

Agent 类型选择决策

下图展示了根据任务特征选择合适的 Agent 类型的决策流程。

graph TB
    A[选择 Agent 类型] --> B{需要协调多 Agent?}
    B -->|是| C{需要编辑权限?}
    B -->|否| D{需要执行任务?}

    C -->|是| E[Sisyphus]
    C -->|否| F[Sisyphus-Junior]

    D -->|是| G{任务类型?}
    D -->|否| H[只读分析]

    G -->|代码实现| I[Hephaestus]
    G -->|通用任务| J[Atlas]

    style E fill:#4A90D9,color:#fff
    style F fill:#50C878,color:#fff
    style I fill:#FF9F43,color:#fff
    style J fill:#A66CFF,color:#fff

12 个 team_* 工具

Team Mode 提供 12 个 team_* 工具，覆盖团队管理、成员管理、通信和任务管理的全生命周期。

工具分类总览

团队管理工具

team_create

创建一个新的 Agent 团队。

参数：

{
  "team_create": {
    "inline_spec": {
      "name": "security-audit-team",
      "description": "安全审计团队，负责代码安全审查",
      "members": [
        {
          "name": "surface-hunter",
          "kind": "category",
          "category": "deep",
          "prompt": "Scan for web vulnerabilities"
        },
        {
          "name": "auth-data-hunter",
          "kind": "category",
          "category": "ultrabrain",
          "prompt": "Scan for auth and data vulnerabilities"
        }
      ]
    }
  }
}

安全最佳实践：

1. 显式定义权限边界：不要继承创建者权限，避免权限泄露
2. 限制可访问路径：使用 allowed_paths 和 denied_paths 控制访问范围
3. 设置合理的成员上限：防止团队无限扩张

返回值：

{
  "team_id": "team-20260602-001",
  "status": "created",
  "created_at": "2026-06-02T14:30:00Z"
}

team_delete

删除一个团队及其所有成员。

参数：

{
  "team_delete": {
    "team_id": "team-20260602-001",
    "force": false,
    "archive_messages": true
  }
}

安全考量：

• force: false 时，如果团队有未完成任务会拒绝删除
• archive_messages: true 会保留消息历史用于审计
• 删除团队需要确认，防止误操作

成员管理工具

team_add_member

向团队添加成员 Agent。

参数：

{
  "team_add_member": {
    "team_id": "team-20260602-001",
    "member_id": "atlas-vuln-scanner",
    "agent_type": "atlas",
    "skills": ["penetration-tester", "vulnerability-manager"],
    "permissions": {
      "edit": "deny",
      "bash": "ask",
      "read": "allow"
    },
    "role": "vulnerability-scanner"
  }
}

权限隔离原则：

team_remove_member

从团队移除成员。

参数：

{
  "team_remove_member": {
    "team_id": "team-20260602-001",
    "member_id": "atlas-vuln-scanner",
    "reassign_tasks": true,
    "reassign_to": "atlas-backup-scanner"
  }
}

安全考量：移除成员时，其未完成任务需要重新分配，防止任务丢失。

team_list_members

列出团队所有成员。

参数：

{
  "team_list_members": {
    "team_id": "team-20260602-001",
    "include_status": true
  }
}

返回值：

{
  "team_id": "team-20260602-001",
  "members": [
    {
      "member_id": "atlas-vuln-scanner-1",
      "agent_type": "atlas",
      "role": "vulnerability-scanner",
      "status": "busy",
      "current_task": "task-001"
    },
    {
      "member_id": "atlas-vuln-scanner-2",
      "agent_type": "atlas",
      "role": "vulnerability-scanner",
      "status": "idle"
    }
  ],
  "total": 2
}

通信工具

team_send_message

Agent 之间发送消息。

参数：

{
  "team_send_message": {
    "team_id": "team-20260602-001",
    "from": "sisyphus-coordinator",
    "to": "atlas-vuln-scanner-1",
    "type": "task_assignment",
    "priority": "high",
    "content": {
      "task_id": "task-001",
      "instruction": "扫描 src/auth/ 目录的 SQL 注入漏洞",
      "deadline": "2026-06-02T15:00:00Z"
    }
  }
}

消息类型：

消息安全机制：

1. 消息签名：每条消息带有发送者签名，防止伪造
2. 权限校验：接收者校验发送者是否有权发送此类消息
3. 审计日志：所有消息记录到审计日志

任务管理工具

team_task_create

创建任务并分配给成员。

参数：

{
  "team_task_create": {
    "team_id": "team-20260602-001",
    "task": {
      "title": "SQL 注入漏洞扫描",
      "description": "扫描 src/auth/ 目录的所有 SQL 查询，识别潜在的注入风险",
      "assignee": "atlas-vuln-scanner-1",
      "priority": "high",
      "deadline": "2026-06-02T15:00:00Z",
      "dependencies": [],
      "skills_required": ["penetration-tester"],
      "expected_output": {
        "format": "json",
        "schema": "vulnerability-report"
      }
    }
  }
}

任务优先级：

team_task_list

列出团队的所有任务。

参数：

{
  "team_task_list": {
    "team_id": "team-20260602-001",
    "status": ["pending", "in_progress"],
    "assignee": "atlas-vuln-scanner-1"
  }
}

team_task_update

更新任务状态。

参数：

{
  "team_task_update": {
    "team_id": "team-20260602-001",
    "task_id": "task-001",
    "status": "completed",
    "result": {
      "findings": [
        {
          "type": "sql-injection",
          "severity": "high",
          "location": "src/auth/login.js:45",
          "description": "用户输入直接拼接到 SQL 查询"
        }
      ],
      "scanned_files": 12,
      "scan_duration": "00:05:23"
    }
  }
}

team_task_get

获取任务详情。

参数：

{
  "team_task_get": {
    "team_id": "team-20260602-001",
    "task_id": "task-001",
    "include_history": true
  }
}

状态查询工具

team_status

查询团队整体状态。

参数：

{
  "team_status": {
    "team_id": "team-20260602-001"
  }
}

返回值：

{
  "team_id": "team-20260602-001",
  "status": "active",
  "members": {
    "total": 5,
    "idle": 2,
    "busy": 3
  },
  "tasks": {
    "total": 10,
    "pending": 3,
    "in_progress": 4,
    "completed": 3
  },
  "health": {
    "message_queue_size": 2,
    "avg_response_time": "00:00:15",
    "error_count": 0
  }
}

team_list

列出所有团队。

参数：

{
  "team_list": {
    "include_archived": false
  }
}

内置 Team Skills

OMO 提供两个内置 Team Skills，展示了 Team Mode 的强大能力：Hyperplan（对抗式规划）和 security-research（安全审计）。

Hyperplan：对抗式规划

Hyperplan 是一种“对抗式规划“模式，通过 5 个“敌对“评审者的三轮交叉攻击，在写一行代码之前发现所有假设的错误。

→ Hyperplan 是 多 Agent 协作 中竞争模式（Adversarial）的形式化扩展。本文将详细介绍 Hyperplan 的实现细节。

设计哲学

核心思想：最好的方案不是“想出来的“，而是“辩出来的“。Hyperplan 模拟了一个“红队会议“场景，5 个评审者从不同角度攻击方案，只有经得起所有攻击的方案才能进入实现阶段。

5 个评审者角色

Hyperplan 使用 5 个 category-based 评审者，由 Sisyphus Lead 协调。每个评审者通过 kind: "category" 路由到对应的 Agent 类别，而非绑定特定 Skill（技能）。

注：以下角色名（Skeptic、Validator、Researcher、Architect、Creative）是概念化的角色标签，用于描述各评审者的立场和关注点。实际的 Agent 类别通过 kind: "category" 路由到对应的内置 Agent 类型（unspecified-low、unspecified-high、deep、ultrabrain、artistry），而非绑定特定 Skill 名称。

对抗式规划流程

Hyperplan 采用 7 阶段对抗式流程：

flowchart TB
    subgraph Phase0[Phase 0: 请求确认]
        A0[用户需求] --> A[Sisyphus Lead<br/>确认规划请求]
    end

    subgraph Phase1[Phase 1: 组建团队]
        A --> B1[Skeptic<br/>unspecified-low]
        A --> B2[Validator<br/>unspecified-high]
        A --> B3[Researcher<br/>deep]
        A --> B4[Architect<br/>ultrabrain]
        A --> B5[Creative<br/>artistry]
    end

    subgraph Phase2[Phase 2: Round 1 — 独立审查]
        B1 --> C1[独立审查]
        B2 --> C2[独立审查]
        B3 --> C3[独立审查]
        B4 --> C4[独立审查]
        B5 --> C5[独立审查]
    end

    subgraph Phase3[Phase 3: Round 2 — 交叉攻击]
        C1 -.-> D1[批评 C2]
        C2 -.-> D2[批评 C3]
        C3 -.-> D3[批评 C4]
        C4 -.-> D4[批评 C5]
        C5 -.-> D5[批评 C1]
    end

    subgraph Phase4[Phase 4: Round 3 — 辩护]
        D1 --> E1[作者辩护]
        D2 --> E2[作者辩护]
        D3 --> E3[作者辩护]
        D4 --> E4[作者辩护]
        D5 --> E5[作者辩护]
    end

    subgraph Phase5[Phase 5: 蒸馏]
        E1 --> F[Sisyphus<br/>蒸馏幸存发现]
        E2 --> F
        E3 --> F
        E4 --> F
        E5 --> F
    end

    subgraph Phase6[Phase 6: 计划生成]
        F --> G[Plan Agent<br/>生成形式化计划]
    end

    subgraph Phase7[Phase 7: 清理]
        G --> H[释放团队资源]
    end

    style A fill:#4A90D9,color:#fff
    style B1 fill:#50C878,color:#fff
    style B2 fill:#50C878,color:#fff
    style B3 fill:#50C878,color:#fff
    style B4 fill:#50C878,color:#fff
    style B5 fill:#50C878,color:#fff
    style F fill:#4A90D9,color:#fff
    style G fill:#50C878,color:#fff

使用方式

# 启动 Hyperplan 规划
/hyperplan 实现用户登录功能

# 指定评审重点
/hyperplan --focus security 实现支付功能

# 限制辩论轮数
/hyperplan --max-rounds 3 重构订单模块

Hyperplan 配置

{
  "skill": "hyperplan",
  "version": "1.0.0",
  "team_create": {
    "inline_spec": {
      "name": "hyperplan-reviewers",
      "description": "Hyperplan 对抗式规划评审团队",
      "members": [
        {
          "name": "skeptic",
          "kind": "category",
          "category": "unspecified-low",
          "prompt": "作为 Pragmatist Skeptic，识别方案中不必要的复杂度，推动减法思维"
        },
        {
          "name": "validator",
          "kind": "category",
          "category": "unspecified-high",
          "prompt": "作为 Integration Tester，关注跨模块边界和集成测试的异常情况"
        },
        {
          "name": "researcher",
          "kind": "category",
          "category": "deep",
          "prompt": "作为 Autonomous Researcher，要求每个设计决策都有证据支持"
        },
        {
          "name": "architect",
          "kind": "category",
          "category": "ultrabrain",
          "prompt": "作为 Architect Strategist，识别架构层面的结构性缺陷"
        },
        {
          "name": "creative",
          "kind": "category",
          "category": "artistry",
          "prompt": "作为 Creative Challenger，提出跨领域的替代方案"
        }
      ]
    }
  },
  "process": {
    "max_rounds": 3,
    "adversarial_rounds": 3,
    "distill_mode": "survivor"
  }
}

关键设计原则：

• 对抗式验证：发现不经投票表决，而是通过 3 轮对抗攻击来验证其可靠性——经得起所有攻击的发现才被视为有效
• Category 路由：成员通过 kind: "category" 路由到对应的类别 Agent，而非绑定特定 Skill
• Sisyphus Lead：协调者使用 Sisyphus（而非 Sisyphus-Junior），因为需要完整的团队管理权限来执行 7 阶段流程
• 蒸馏而非投票：最终输出不是多数同意的结果，而是经 3 轮攻击后幸存的分析发现

security-research：安全审计模式

security-research 是一个 5 人安全团队的并行审计模式，包含 3 个漏洞猎手和 2 个 PoC 工程师，采用类别路由（category-based）配置。

团队组成

架构设计

下图展示了安全研究流水线的三阶段架构设计，包括并行扫描、PoC 验证和修复建议各阶段的 Agent 分工。

flowchart TB
    subgraph Phase1[Phase 1: 并行扫描]
        B1[surface-hunter<br/>category: deep] --> F1[扫描结果 1]
        B2[auth-data-hunter<br/>category: ultrabrain] --> F2[扫描结果 2]
        B3[runtime-supply-hunter<br/>category: unspecified-high] --> F3[扫描结果 3]
    end

    subgraph Phase2[Phase 2: 并行 PoC 验证]
        F1 --> H1[poc-engineer-a<br/>category: unspecified-high]
        F2 --> H2[poc-engineer-b<br/>category: deep]
        F3 --> H1
        F3 --> H2
    end

    subgraph Phase3[Phase 3: 交叉校验]
        H1 --> I1{PoC 结果交叉验证}
        H2 --> I1
    end

    subgraph Phase4[Phase 4: 报告合成]
        I1 --> J[Sisyphus 协调者<br/>合成审计报告]
    end

    style B1 fill:#50C878,color:#fff
    style B2 fill:#50C878,color:#fff
    style B3 fill:#50C878,color:#fff
    style H1 fill:#FF9F43,color:#fff
    style H2 fill:#FF9F43,color:#fff
    style J fill:#4A90D9,color:#fff

为什么是 3+2 配置？

3 个漏洞猎手覆盖不同的攻击面，分工如下：

2 个 PoC 工程师并行验证漏洞并提供修复方案：

使用方式

# 启动安全审计
/security-research --target src/auth/

# 指定审计范围
/security-research --scope web,auth,config

# 深度扫描模式
/security-research --depth deep --target src/

security-research 配置

{
  "skill": "security-research",
  "version": "1.0.0",
  "team_create": {
    "inline_spec": {
      "name": "security-audit-team",
      "description": "安全审计团队，3+2 并行审计模式",
      "members": [
        {
          "name": "surface-hunter",
          "kind": "category",
          "category": "deep",
          "prompt": "Focus on finding exposed endpoints, API vulnerabilities, and injection flaws"
        },
        {
          "name": "auth-data-hunter",
          "kind": "category",
          "category": "ultrabrain",
          "prompt": "Focus on authentication bypass, authorization flaws, and data leakage"
        },
        {
          "name": "runtime-supply-hunter",
          "kind": "category",
          "category": "unspecified-high",
          "prompt": "Focus on misconfigurations, dependency vulnerabilities, and runtime issues"
        },
        {
          "name": "poc-engineer-a",
          "kind": "category",
          "category": "unspecified-high",
          "prompt": "Prove exploitability of discovered vulnerabilities with working PoC code"
        },
        {
          "name": "poc-engineer-b",
          "kind": "category",
          "category": "deep",
          "prompt": "Verify vulnerabilities and provide detailed remediation guidance"
        }
      ]
    }
  },
  "workflow": {
    "phases": ["parallel-scan", "parallel-poc", "cross-check", "report-synthesis"],
    "parallel_scan": true,
    "report_format": "markdown"
  },
  "security": {
    "isolate_poc_environment": true,
    "sanitize_output": true,
    "audit_all_actions": true
  }
}

安全配置要点：

1. isolate_poc_environment: true：PoC 工程师在隔离沙箱中运行
2. sanitize_output: true：输出报告时脱敏敏感信息
3. audit_all_actions: true：记录所有操作用于合规审计

设计自定义工作流

掌握 Team Mode 的基础后，你可以设计自己的工作流。以下是四个步骤的设计方法论。

步骤 1：拆解任务

将复杂任务拆解为可独立执行的子任务。

拆解原则：

1. 单一职责：每个子任务只做一件事
2. 明确边界：子任务之间边界清晰
3. 可验证：每个子任务有明确的完成标准
4. 合理粒度：既不过大也不过小

拆解示例：实现用户登录功能

任务：实现用户登录功能
├── 子任务 1：设计认证方案（规划）
├── 子任务 2：实现后端 API（实现）
├── 子任务 3：实现前端页面（实现）
├── 子任务 4：安全审查（审查）
├── 子任务 5：测试验证（测试）
└── 子任务 6：部署上线（部署）

步骤 2：映射到 Agent 角色

将子任务映射到合适的 Agent 类型和 Skill。

映射矩阵：

步骤 3：配置工作流定义

编写工作流配置文件。

完整配置示例：

{
  "workflow": {
    "name": "user-auth-implementation",
    "version": "1.0.0",
    "trigger": "/implement-auth",
    "team": {
      "coordinator": {
        "type": "sisyphus",
        "skills": ["requirements-analyst"]
      },
      "members": [
        {
          "id": "architect",
          "type": "sisyphus-junior",
          "skills": ["architecture-consultant"],
          "permissions": { "edit": "deny", "bash": "deny", "read": "allow" }
        },
        {
          "id": "backend-dev",
          "type": "hephaestus",
          "skills": ["backend-architect"],
          "permissions": { "edit": "allow", "bash": "ask", "read": "allow" }
        },
        {
          "id": "frontend-dev",
          "type": "hephaestus",
          "skills": ["frontend-architect"],
          "permissions": { "edit": "allow", "bash": "ask", "read": "allow" }
        },
        {
          "id": "security-reviewer",
          "type": "atlas",
          "skills": ["security-architect"],
          "permissions": { "edit": "deny", "bash": "deny", "read": "allow" }
        },
        {
          "id": "tester",
          "type": "atlas",
          "skills": ["qa-engineer"],
          "permissions": { "edit": "deny", "bash": "allow", "read": "allow" }
        }
      ]
    },
    "flow": [
      {
        "stage": "planning",
        "agent": "architect",
        "output": "WORKFLOW_STATE.md#plan",
        "onFailure": "abort"
      },
      {
        "stage": "implementation",
        "parallel": true,
        "agents": ["backend-dev", "frontend-dev"],
        "output": "WORKFLOW_STATE.md#implementation",
        "onFailure": "retry",
        "maxRetries": 2
      },
      {
        "stage": "security-review",
        "agent": "security-reviewer",
        "output": "WORKFLOW_STATE.md#security",
        "onFailure": "feedback"
      },
      {
        "stage": "testing",
        "agent": "tester",
        "output": "WORKFLOW_STATE.md#test",
        "onFailure": "feedback"
      }
    ],
    "qualityGates": {
      "preImplementation": ["plan-approved"],
      "preCommit": ["security-review-passed", "tests-passed"]
    }
  }
}

步骤 4：验证和调试

工作流配置完成后，需要验证其正确性。

验证检查清单：

• 所有 Agent ID 唯一
• 所有 Skill 已安装
• 权限配置符合最小权限原则
• 流程顺序无循环依赖
• 失败处理策略明确
• 输出文件路径正确

调试命令：

# 验证工作流配置
/workflow validate --config .opencode/workflows/auth-implementation.json

# 模拟执行（不实际修改文件）
/workflow dry-run --config .opencode/workflows/auth-implementation.json

# 查看工作流执行日志
/workflow logs --workflow-id wf-20260602-001

需要 OMO v4.0+ 支持。请通过 omo --version 确认版本。

常见工作流模板

PR Review Pipeline

适用于代码审查场景。

{
  "workflow": {
    "name": "pr-review-pipeline",
    "trigger": "/review-pr",
    "team": {
      "coordinator": { "type": "sisyphus-junior" },
      "members": [
        {
          "id": "code-reviewer",
          "type": "atlas",
          "skills": ["requesting-code-review"],
          "permissions": { "edit": "deny", "read": "allow" }
        },
        {
          "id": "security-reviewer",
          "type": "atlas",
          "skills": ["security-architect"],
          "permissions": { "edit": "deny", "read": "allow" }
        },
        {
          "id": "test-coverage-checker",
          "type": "atlas",
          "skills": ["qa-engineer"],
          "permissions": { "edit": "deny", "bash": "allow", "read": "allow" }
        }
      ]
    },
    "flow": [
      { "stage": "code-review", "agent": "code-reviewer", "parallel": true },
      { "stage": "security-review", "agent": "security-reviewer", "parallel": true },
      { "stage": "coverage-check", "agent": "test-coverage-checker", "parallel": true }
    ]
  }
}

Documentation Generation

适用于文档生成场景。

{
  "workflow": {
    "name": "doc-generation",
    "trigger": "/generate-docs",
    "team": {
      "coordinator": { "type": "sisyphus-junior" },
      "members": [
        {
          "id": "api-doc-writer",
          "type": "hephaestus",
          "skills": ["content-research-writer"],
          "permissions": { "edit": "allow", "read": "allow" }
        },
        {
          "id": "readme-writer",
          "type": "hephaestus",
          "skills": ["content-research-writer"],
          "permissions": { "edit": "allow", "read": "allow" }
        },
        {
          "id": "diagram-generator",
          "type": "atlas",
          "skills": ["archimate", "uml"],
          "permissions": { "edit": "allow", "read": "allow" }
        }
      ]
    },
    "flow": [
      { "stage": "api-docs", "agent": "api-doc-writer", "parallel": true },
      { "stage": "readme", "agent": "readme-writer", "parallel": true },
      { "stage": "diagrams", "agent": "diagram-generator", "parallel": true }
    ]
  }
}

并行与串行的选择策略

选择并行还是串行执行，取决于任务性质。

决策矩阵

混合模式最佳实践

大多数场景使用混合模式效果最佳：

flowchart LR
    A[规划阶段<br/>串行] --> B[实现阶段<br/>并行]
    B --> C[审查阶段<br/>并行]
    C --> D{审查通过?}
    D -->|否| E[修复阶段<br/>串行]
    E --> B
    D -->|是| F[部署阶段<br/>串行]

    style A fill:#4A90D9,color:#fff
    style B fill:#50C878,color:#fff
    style C fill:#50C878,color:#fff
    style F fill:#A66CFF,color:#fff

Team Mode 的限制和注意事项

Team Mode 的设计约束——这些限制是为了防止系统失控。

硬性限制

¹ 关于嵌套团队的说明：12 个 team_* 工具在 API 层面不支持嵌套团队（即不能在一个团队内部再通过 team_create 创建子团队），这是为了防止资源无限扩张。但更高层级的分层协调可以通过 Teams 多进程协作模式实现——父 Team 通过消息传递机制协调子 Team，形成 Level 1（项目级）→ Level 2（领域级）→ Level 3（执行级）的分层架构。详见 Teams 并行 Agent 协作 的“分层 Team 架构“一节。

安全注意事项

1. 隔离工作目录：每个 Agent 应有独立工作目录
2. 审计所有消息：生产环境必须启用消息审计
3. 限制敏感路径：使用 denied_paths 保护敏感文件
4. 最小权限原则：只授予必要的权限
5. 定期清理：及时删除不再使用的团队

常见错误及解决

小结

Team Mode 是 oh-my-openagent 的核心创新，将单 Agent 系统升级为多 Agent 并行协作系统。通过 12 个 team_* 工具，你可以创建、管理和协调多个 Agent 团队，实现复杂的工作流编排。

Hyperplan 和 security-research 两个内置 Team Skills 展示了 Team Mode 的强大能力：前者通过 5 个“敌对“评审者的交叉批评，在写代码之前发现所有假设的错误；后者通过 3 漏洞猎手 + 2 PoC 工程师的并行协作，实现高效的安全审计。

设计自定义工作流需要遵循四个步骤：拆解任务 → 映射到 Agent 角色 → 配置工作流定义 → 验证和调试。并行适合探索性任务，串行适合生产性任务，混合模式效果最佳。

Team Mode 的设计约束——禁止嵌套团队、禁止 delegate-task 权限——都是为了防止系统失控。这些限制是必要的安全边界。

常见反模式

自定义 Workflow 过于通用

现象：设计了一个“万金油“Workflow，试图覆盖所有场景，结果每个场景都不适配。

原因：Workflow 设计阶段没有限定目标场景，试图用一个配置解决所有问题。

对策：每个 Workflow 只解决一类特定场景。例如，“登录功能实现“Workflow 严格包含规划 → 后端 → 前端 → 安全审查 → 测试五个阶段。类似场景可以通过复制修改，而不是使用过于通用的配置。Workflow 的 trigger 命令应该反映其用途（如 /implement-auth 而非 /run）。

在 Hyperplan 中定义过多评审视角

现象：Hyperplan 的评审者列表不断增长，从 5 个扩展到 10 个以上，每个评审者的输出贡献递减。

原因：认为“更多评审者 = 更好的质量“，忽略了评审者之间的信息冗余和协调开销。

对策：保持 5 个评审者的标准配置。新增评审视角前先问：这个视角是否覆盖了现有评审者没有覆盖的维度？如果是，考虑替代现有评审者而非增加。

常见错误与陷阱

Workflow 定义中的工具名拼写错误

场景：配置了自定义 Workflow，但运行时报 Tool not found，检查发现工具名拼写错误（如 team-send-message 而非 team_send_message）。

后果：整个 Workflow 在启动阶段失败。

预防：使用 workflow validate 命令验证配置。编写 Workflow 时参考官方工具的精确名称（下划线命名）。配置完成后执行 dry-run 模拟执行。

Quality Gate 配置过于严格

场景：在 Pipeline 中设置了多个 Quality Gate，任何一个失败就终止整个流程，但有些 Gate 是非关键检查。

后果：非关键问题阻塞了整个 Pipeline，频繁人工介入解除阻塞。

预防：区分关键和非关键 Quality Gate。安全审查失败 → 阻塞（关键）；代码风格警告 → 不阻塞但记录（非关键）。使用 severity 分级控制门禁行为。

适用场景与限制

自定义 Workflow 适合有标准化流程的团队和项目：PR 审查流水线、安全审计流程、部署上线流程、文档生成流程。将固化的团队流程编码为 Workflow 定义，实现一键执行。

以下情况自定义 Workflow 可能不划算：流程还在频繁变动的阶段——先手工执行，等流程稳定后再 Workflow 化；一人团队的简单项目——Workflow 的配置维护成本可能超过收益；需要使用暂不支持的 Agent 类型或工具——检查版本兼容性后再设计。

自定义 Workflow 需要 OMO v4.0+。Workflow 定义中的 Agent 类型、Skill 名称必须与已安装的配置一致。Workflow 的 trigger 命令与已有命令冲突时，OpenCode 会报错。建议 trigger 使用 / 前缀的语义化名称。

学习检查清单

完成本章学习后，请确认你能够：

• 解释 Team Mode 的架构设计和四种 Agent 类型
• 使用 12 个 team_* 工具管理团队和任务
• 理解 Hyperplan 对抗式规划的设计哲学
• 配置 security-research 安全审计团队
• 设计自定义工作流的四个步骤
• 理解 Team Mode 的限制和安全注意事项

关联章节

• ← 多 Agent 协作 — Pipeline 是基础，Team 是升级
• ← 工作流模式 — Command 触发 Team 工作流
• → 案例研究 — Team Mode 在案例中的应用