第二章. BMAD 角色体系：21 个代理的分工逻辑

第二章. BMAD 角色体系：21 个代理的分工逻辑

本章将拆解 BMAD 的目录结构和角色分工，理解为什么需要 21 个代理，以及它们如何通过工件传递信息。

2.1. 先看看 BMAD 装了什么

在理解角色之前，我们先把 BMAD 的仓库拉下来看看。它以一个 Github 仓库 的形式存在，安装后会在你的项目里生成一个 .bmad 目录。

安装和初始化

1
npx bmad-method@alpha install

安装程序会启动一个交互式配置向导。这个过程会问你一系列问题，我们逐个解释：

问题 1：安装目录

1
2
? Installation directory: C:\Users\YourName\Desktop\BMAD
? Install to this directory? Yes

这个没什么好说的，选一个你想放项目的地方。

问题 2：选择开发工具

1
2
3
4
? Select tools to configure:
  ◉ Claude Code ⭐
  ◯ Windsurf
  ◯ VS Code

必须按空格键选中，然后按回车确认。只是高亮不算选中。

这里选择你用的 IDE。我们的教程以 Claude Code 为例，但其他 IDE 的流程本质上是一样的。

问题 3：配置语言和输出

1
2
3
4
? What shall the agents call you? Prorise
? Preferred chat language/style? Chinese
? Preferred document output language? Chinese
? Where should default output files be saved? _bmad-output

这里有个关键点：对话语言和文档语言可以分开设置。

  • 对话语言：AI 用什么语言跟你交流
  • 文档语言：PRD、架构文档等工件用什么语言输出

我选了中文，因为 PRD 和架构文档用中文写更自然。但如果你的团队是国际化的，可以选英文。

问题 4：选择模块

1
2
3
4
? Select modules to install:
  ◉ BMM: BMad Method Agile-AI Driven-Development
  ◯ BMB: BMad Builder (Create Custom Agents)
  ◯ CIS: Creative Innovation Suite

这里有三个模块：

模块全称作用
BMMBMad Method完整的敏捷开发流程，包含 21 个 Agent 和 50+ 工作流
BMBBMad Builder用来创建自定义 Agent 和工作流
CISCreative Innovation Suite创新和头脑风暴工具

第一次使用建议只选 BMM，因为想先体验标准流程。等熟悉了再用 BMB 定制自己的 Agent。

问题 5：是否启用 TTS

1
? Claude Code supports TTS (Text-to-Speech). Would you like to enable it? No

这个功能可以让 AI 用语音跟你对话。我选了 No，因为这部分我们不需要，没必要下载额外依赖。

安装完成后，会看到：

1
2
3
✨ BMAD is ready to use!
Installed to: C:\Users\Prorise\Desktop\BMAD\_bmad
Modules: bmm

2.2. 目录结构：核心文件在哪里

安装完后，项目里会多两个目录：

1
2
3
📂 BMAD/
├── 📂 _bmad/              # BMAD核心文件
└── 📂 _bmad-output/       # 工件输出目录

_bmad 目录：三个模块的分工

这个目录包含三个模块：

1
2
3
4
_bmad/
├── 📂 core/              # 核心功能
├── 📂 bmm/               # BMad Method模块
└── 📂 _config/           # 配置文件

我们逐个拆解。

core 模块：基础能力层

1
2
3
4
5
6
7
8
9
10
11
12
core/
├── 📂 agents/
│   └── bmad-master.md    # 主控Agent
├── 📂 tasks/
│   ├── index-docs.xml    # 文档索引任务
│   ├── review-adversarial-general.xml  # 对抗性审查任务
│   ├── shard-doc.xml     # 文档分片任务
│   └── workflow.xml      # 工作流任务
└── 📂 workflows/
    ├── advanced-elicitation/  # 高级需求挖掘
    ├── brainstorming/         # 头脑风暴
    └── party-mode/            # 多Agent协作模式

这里的 bmad-master 是总控 Agent，负责协调其他所有 Agent。它就像一个项目经理，知道什么时候该叫哪个 Agent 出来干活。

tasks 目录里是可复用的任务定义。比如 review-adversarial-general.xml 定义了 对抗性审查让一个 AI 挑战另一个 AI 的输出，找出逻辑漏洞和潜在问题 的逻辑：让一个 AI 挑战另一个 AI 的输出，找出问题。

这解决了什么问题？防止 AI 自嗨。如果只有一个 AI 生成代码，它可能会觉得自己写得很完美。但如果有另一个 AI 专门挑刺，就能发现很多隐藏的问题。

bmm 模块：21 个角色的定义

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
bmm/
├── 📂 agents/
│   ├── analyst.md              # 需求分析师
│   ├── pm.md                   # 产品经理
│   ├── architect.md            # 架构师
│   ├── sm.md                   # Scrum Master
│   ├── dev.md                  # 开发工程师
│   ├── tea.md                  # 测试工程师
│   ├── ux-designer.md          # UX设计师
│   ├── tech-writer.md          # 技术文档工程师
│   └── quick-flow-solo-dev.md  # Quick Flow专用Agent
├── 📂 workflows/
│   ├── 1-analysis/             # 第一阶段：分析
│   ├── 2-plan-workflows/       # 第二阶段：规划
│   ├── 3-solutioning/          # 第三阶段：方案设计
│   ├── 4-implementation/       # 第四阶段：实现
│   ├── bmad-quick-flow/        # Quick Flow工作流
│   └── ...
└── 📂 data/
    ├── documentation-standards.md  # 文档规范
    └── project-context-template.md # 项目上下文模板

这里才是真正的 21 个角色和 50+ 工作流。

打开 agents/analyst.md，你会看到需求分析师的完整定义：

1
2
3
4
5
6
7
8
# Business Analyst

你是一个需求分析师，负责把模糊的想法变成清晰的需求。

## 职责
- 收集和分析业务需求
- 识别关键约束和风险
...

每个 Agent 的定义包含三个部分：

  1. 职责边界：这个 Agent 负责什么，不负责什么
  2. 工作方式：这个 Agent 怎么思考问题
  3. 输出规范：这个 Agent 产出什么格式的工件

这解决了什么问题？防止角色越界。如果没有明确的职责定义，Analyst 可能会开始讨论技术实现，Architect 可能会开始质疑需求合理性。但有了这些定义，每个 Agent 只关注自己的领域。

workflows 目录：四阶段的具体流程

这个目录是 BMAD 的核心。我们重点看四个阶段的目录结构。

1-analysis 阶段：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
1-analysis/
├── create-product-brief/      # 创建产品简报
│   ├── product-brief.template.md
│   └── steps/
│       ├── step-01-init.md
│       ├── step-02-vision.md
│       ├── step-03-users.md
│       ├── step-04-metrics.md
│       ├── step-05-scope.md
│       └── step-06-complete.md
└── research/                  # 研究工作流
    ├── domain-steps/          # 领域研究
    ├── market-steps/          # 市场研究
    └── technical-steps/       # 技术研究

每个工作流都拆成了多个步骤。比如 create-product-brief 有 6 个步骤：初始化 → 愿景 → 用户 → 指标 → 范围 → 完成。

为什么要拆这么细？因为大脑一次只能处理 7±2 个信息块。如果一次性问你 20 个问题，你会懵。但如果分成 6 个步骤，每个步骤问 3-4 个问题，你就能清晰地回答。

2-plan-workflows 阶段：

1
2
3
4
5
6
7
8
9
2-plan-workflows/
├── prd/                       # PRD创建
│   ├── steps-c/               # 创建模式（12个步骤）
│   ├── steps-e/               # 编辑模式（4个步骤）
│   ├── steps-v/               # 验证模式（13个步骤）
│   └── templates/
│       └── prd-template.md
└── create-ux-design/          # UX设计
    └── steps/                 # 14个步骤

PRD 工作流有三种模式：

模式步骤数适用场景
创建模式 (steps-c)12从零开始写 PRD
编辑模式 (steps-e)4修改现有 PRD
验证模式 (steps-v)13检查 PRD 质量

这解决了什么问题？防止文档质量参差不齐。如果没有验证模式，你可能会写出一份 “看起来很完整，但实际上漏洞百出” 的 PRD。但有了 13 个验证步骤，每个步骤检查一个维度（完整性、一致性、可测试性等），就能确保 PRD 的质量。

3-solutioning 阶段：

1
2
3
4
5
6
7
3-solutioning/
├── create-architecture/       # 架构设计
│   └── steps/                 # 8个步骤
├── create-epics-and-stories/  # 创建Epic和Story
│   └── steps/                 # 4个步骤
└── check-implementation-readiness/  # 实现就绪检查
    └── steps/                 # 6个步骤

这个阶段的关键是 check-implementation-readiness。它会检查：

  • PRD 和架构文档是否一致？
  • 所有 Epic 都有对应的技术方案吗？
  • 技术栈能满足非功能需求吗？
  • 有没有遗漏的依赖或风险？

只有通过这 6 个检查，才能进入开发阶段。这就是我们在第一章提到的 “人在回路” 检查点。

4-implementation 阶段：

1
2
3
4
5
6
4-implementation/
├── sprint-planning/           # 迭代规划
├── dev-story/                 # 开发Story
├── code-review/               # 代码评审
├── sprint-status/             # 迭代状态
└── retrospective/             # 回顾会议

这个阶段的工作流是循环的：规划 → 开发 → 评审 → 回顾 → 下一个迭代。

bmad-quick-flow：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
bmad-quick-flow/
├── quick-spec/                # 快速规格说明
│   └── steps/
│       ├── step-01-understand.md
│       ├── step-02-investigate.md
│       ├── step-03-generate.md
│       └── step-04-review.md
└── quick-dev/                 # 快速开发
    └── steps/
        ├── step-01-mode-detection.md
        ├── step-02-context-gathering.md
        ├── step-03-execute.md
        ├── step-04-self-check.md
        ├── step-05-adversarial-review.md
        └── step-06-resolve-findings.md

Quick Flow 是完整流程的简化版。它只有两个工作流：

  • quick-spec：4 步生成技术规格说明
  • quick-dev：6 步完成开发（包含自检和对抗性审查）

注意 quick-dev 的第 5 步是 “对抗性审查”。即使是简化版，也保留了质量检查机制。

testarch 目录：

1
2
3
4
5
6
7
8
9
10
11
testarch/
├── knowledge/                 # 测试知识库（35个文档）
│   ├── overview.md
│   ├── test-levels-framework.md
│   ├── component-tdd.md
│   └── ...
└── workflows/
    ├── atdd/                  # 验收测试驱动开发
    ├── test-design/           # 测试设计
    ├── test-review/           # 测试评审
    └── ...

这个目录包含 35 个测试知识文档，涵盖 TDD、契约测试、性能测试等各种测试模式。

为什么需要这么多测试文档？因为测试是最容易被忽略的环节。很多开发者写完代码就觉得完成了，但实际上没有测试的代码是不可靠的。BMAD 通过提供完整的测试知识库，确保每个 Story 都有对应的测试策略。

_config 目录：配置和清单

1
2
3
4
5
6
7
8
9
_config/
├── agents/
│   ├── bmm-analyst.customize.yaml
│   ├── bmm-architect.customize.yaml
│   ├── bmm-dev.customize.yaml
│   └── ...
├── agent-manifest.csv         # Agent清单
├── workflow-manifest.csv      # 工作流清单
└── manifest.yaml              # 主清单

这些 .customize.yaml 文件是用来定制 Agent 行为的。打开 bmm-dev.customize.yaml，你会看到：

1
2
3
4
5
6
7
8
agent:
  name: Developer
  personality: 专业、严谨、注重细节
  code_style:
    naming: camelCase
    indent: 2 spaces
    max_line_length: 100
  ...

你可以修改这些配置，让 Dev Agent 使用你喜欢的代码风格。

各种 manifest 文件记录了系统里有哪些 Agent、工作流、任务。打开 agent-manifest.csv：

1
2
3
4
id,name,module,path,enabled
bmm-analyst,Business Analyst,bmm,bmm/agents/analyst.md,true
bmm-pm,Product Manager,bmm,bmm/agents/pm.md,true
...

这个清单的作用是 让系统知道有哪些 Agent 可用。当你输入 *agent pm 时，系统会查这个清单，找到 bmm-pm 对应的定义文件，然后加载它。

_bmad-output 目录：工件的归宿

1
2
_bmad-output/
└── implementation-artifacts/  # 实现阶段的工件

这个目录一开始是空的。当你跑完工作流后，所有生成的文档、代码、测试报告都会存在这里。

比如跑完 PRD 工作流后：

1
2
3
4
_bmad-output/
├── product-brief-20250115.md
├── prd-20250115.md
└── validation-report-20250115.md

跑完架构设计后：

1
2
3
4
_bmad-output/
├── architecture-20250115.md
├── architecture-decisions-20250115.md
└── epics-and-stories-20250115.md

注意文件名都带了日期。这是因为 工件是有版本的。如果你三个月后修改了 PRD，会生成一个新的文件 prd-20250415.md，而不是覆盖旧文件。这样你可以随时对比不同版本的差异。

2.3. 四个阶段在做什么

现在我们知道了 BMAD 的目录结构，接下来理解四个阶段的分工逻辑。

Analysis：把模糊想法变成清晰问题

这个阶段的目标是：把 “我想要个用户管理” 变成 “需要哪些字段、权限、接口”。

为什么需要这个阶段

因为大部分需求一开始都是模糊的。

产品说 “我想要个用户管理”，但他没说：

  • 用户有哪些字段？姓名、邮箱、手机号？
  • 用户有哪些权限？管理员、普通用户、访客？
  • 用户怎么登录？账号密码、手机验证码、第三方登录？

如果直接开始写代码，这些问题会在实现过程中不断冒出来。每次冒出来，都要停下来讨论，然后改代码。

Analysis 阶段就是把这些问题提前问清楚。

这个阶段产出什么

一个 产品简报包含背景、目标、约束、风险、成功标准的需求分析文档，包含：

  • 背景：为什么要做这个功能
  • 目标：这个功能要解决什么问题
  • 约束：有哪些限制条件（时间、预算、技术栈）
  • 风险：可能遇到哪些问题
  • 成功标准：怎么判断这个功能做成功了

对比：有 Analysis vs 没有 Analysis

没有 Analysis 的情况：

1
2
3
4
5
6
你：帮我写个用户管理模块
AI：好的，这是代码...
你：等等，用户需要有权限管理
AI：好的，我加上...
你：不对，权限应该是角色级别的
AI：好的，我改一下...

改了 5 次，每次都要重新生成代码。

有 Analysis 的情况：

1
2
3
4
5
6
7
Analyst：这个用户管理模块，需要支持哪些功能？
你：基本的增删改查，还有权限管理
Analyst：权限是用户级别的，还是角色级别的？
你：角色级别的
Analyst：需要支持第三方登录吗？
你：需要，微信和支付宝
Analyst：好的，我整理一下需求...

一次性把需求问清楚，后面不用反复改。

Planning：拆任务表和里程碑

这个阶段的目标是：把需求拆成 10 个可执行的任务，排好优先级。

为什么需要这个阶段

因为一个大需求直接开始写，很容易失控。

“用户管理模块” 听起来很简单，但实际上包含：

  • 用户表设计
  • 注册接口
  • 登录接口
  • 权限校验
  • 角色管理
  • 第三方登录
  • 用户列表
  • 用户详情
  • 用户编辑
  • 用户删除

如果不拆任务，你会在这 10 个功能之间跳来跳去，最后哪个都没做完。

Planning 阶段就是把大需求拆成小任务，一个一个做。

这个阶段产出什么

两个工件：

  1. PRD 文档：详细描述每个功能的用户故事和验收标准
  2. Epic 和 Story 列表：把 PRD 拆分成可执行的开发任务

PRD 的核心是 验收标准。它用可验证的条件定义 “什么叫做完了”：

1
2
3
4
5
6
7
## Story: 用户登录

### 验收标准
- [ ] 输入正确的用户名和密码后，跳转到首页
- [ ] 输入错误密码 3 次后，账号锁定 15 分钟
- [ ] 登录成功后，生成 JWT Token
...

注意每一条都是 可测试的。QA 代理在审查代码时，会逐条检查这些标准是否满足。

Solutioning：定技术方案和架构

这个阶段的目标是：定技术栈、画架构图、定接口规范。

为什么需要这个阶段

因为同一个需求，可以有多种实现方式。

“用户管理模块” 可以用：

  • 技术栈：Node.js + Express + MySQL，或者 Python + Django + PostgreSQL
  • 架构：单体应用，或者微服务
  • 认证方式：JWT，或者 Session

如果不提前定方案，开发过程中会不断纠结 “用哪个更好”。

Solutioning 阶段就是把技术方案定下来，后面不用纠结。

这个阶段产出什么

两个工件：

  1. 架构文档：描述系统的整体架构、技术栈、关键设计决策
  2. 接口契约：定义所有接口的请求和响应格式（OpenAPI 格式）

架构文档的核心是 约束而非自由。它不是告诉 Dev “你可以用任何数据库”，而是明确规定 “必须用 PostgreSQL，且所有表必须有 created_at 和 updated_at 字段”。

Implementation：写代码和测试

这个阶段的目标是：按任务写代码，每个任务一个 Story。

为什么用 Story 而不是直接修改文件

因为 Story 是可追溯的。

一个 Story 包含：

  • 变更说明：为什么要改
  • 影响范围：改了哪些文件
  • 代码 diff：具体改动
  • 测试用例：如何验证

如果直接修改文件，三个月后你不记得为什么这么改。但如果用 Story，你可以随时查看这个 Story 的变更说明。

这个阶段产出什么

每个任务产出一个 Story 文档：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# Story 1.1: 用户注册接口

## 变更说明
实现用户注册接口，支持邮箱和手机号注册

## 影响文件
- src/routes/user.js (CREATE)
- src/controllers/user.controller.js (CREATE)
...

## 代码变更
[具体的代码diff]

## 测试用例
- 测试邮箱注册成功
- 测试手机号注册成功
...

2.4. 角色切换的黄金法则

BMAD 的一个核心原则是：一次只用一个代理，且必须在新的干净对话中启动。

什么是角色污染？

假设你在同一个对话中先用 SM 创建了一个 Story，然后直接让 Dev 实现。这时候会发生什么？

AI 的上下文中既有 SM 的 “规划思维”，又有 Dev 的 “实现思维”。结果就是 Dev 可能会：

  • 擅自修改 Story 的验收标准（因为它觉得 “这样实现更简单”）
  • 偏离架构文档的约束（因为它 “忘记” 了架构师的规定）

这就是角色污染。两个角色的职责混在一起，导致输出质量下降。

正确的切换方式

步骤 1：完成当前角色的任务

在 SM 对话中，创建完 Story 后，把内容保存到项目目录：

1
docs/stories/story-1.1.md

步骤 2：开启新的干净对话

关闭当前对话，打开一个全新的对话窗口。

步骤 3：激活新角色

在新对话中输入：

1
2
*agent dev
develop-story story-1.1

这时 Dev 代理会读取 docs/stories/story-1.1.md 文件，基于这份文档开始工作。它的上下文中 只有 Story 的内容，没有 SM 的思考过程。

为什么要这么麻烦？

因为这确保了 职责的单一性。每个代理只关注自己的任务：

  • SM 只负责拆分 Story，不关心怎么实现
  • Dev 只负责实现功能，不关心为什么要这样拆分
  • QA 只负责审查质量，不关心实现细节

这种分离带来了两个好处：

  1. 输出质量更高：每个代理都能专注于自己的领域，不会被其他角色的思维干扰
  2. 可追溯性更强：每个阶段的输出都有独立的文档，三个月后回来看，能清楚地知道 “当时为什么这么做”

2.5. 本章总结与角色速查表

让我们回顾一下核心要点：

BMAD 的目录结构

目录作用关键文件
core/基础能力层bmad-master.md, 对抗性审查任务
bmm/21 个角色和 50+ 工作流各个 Agent 定义，四阶段工作流
_config/配置和清单Agent 定制文件，manifest 清单
_bmad-output/工件输出PRD、架构文档、Story 等

四个阶段的分工

阶段目标输出工件
Analysis把模糊想法变成清晰问题产品简报 (Product Brief)
Planning拆任务表和里程碑PRD + Epic/Story 列表
Solutioning定技术方案和架构拆解 Story架构文档 + 接口契约
Implementation写代码和测试Story 文档 + 代码

角色切换检查清单

在切换角色前，问自己三个问题：

如果三个问题的答案都是 “是”，才能切换到下一个角色。