95 lines
7.6 KiB
Markdown
95 lines
7.6 KiB
Markdown
---
|
||
title: "命名智能体"
|
||
description: 为什么 BMad 的智能体有名字、人设和自定义能力——相比菜单驱动或纯提示驱动的方案，这解锁了哪些可能性
|
||
sidebar:
|
||
order: 1
|
||
---
|
||
|
||
你说"嘿 Mary，咱们来头脑风暴"，Mary 就激活了。她用你配置的语言、以她独特的人设向你打招呼，并提醒你随时可以用 `bmad-help`。然后她跳过菜单，直接进入头脑风暴——因为你的意图已经足够明确。
|
||
|
||
这一页解释背后发生了什么，以及 BMad 为什么这样设计。
|
||
|
||
## 三足鼎立
|
||
|
||
BMad 的智能体模型建立在三个可组合的基本要素之上：
|
||
|
||
| 要素 | 提供什么 | 所在位置 |
|
||
|---|---|---|
|
||
| **技能（Skill）** | 能力——一项智能体能做的具体事（头脑风暴、撰写 PRD、实现 story） | `.claude/skills/{skill-name}/SKILL.md`（或你所用 IDE 的等价位置） |
|
||
| **命名智能体（Named Agent）** | 人设连续性——一个可辨识的身份，把一组相关技能包装在统一的语气、原则和视觉标识下 | 目录名以 `bmad-agent-*` 开头的技能 |
|
||
| **自定义（Customization）** | 让它成为你的——覆盖选项可以重塑智能体行为、添加 MCP 集成、替换模板、叠加组织规范 | `_bmad/custom/{skill-name}.toml`（团队提交的覆盖）和 `.user.toml`（个人，已 gitignore） |
|
||
|
||
抽掉任何一条腿，体验就会坍塌：
|
||
|
||
- 有技能没智能体 → 用户只能靠名称或编号在能力列表里自行查找
|
||
- 有智能体没技能 → 空有人设，没有能力
|
||
- 没有自定义 → 所有人用一模一样的开箱默认，任何组织特有需求都只能靠 fork
|
||
|
||
## 命名智能体带来了什么
|
||
|
||
BMad 内置六个命名智能体，各自对应 BMad Method 的一个阶段：
|
||
|
||
| 智能体 | 阶段 | 模块 |
|
||
|---|---|---|
|
||
| 📊 **Mary**，商业分析师 | 分析 | 市场调研、头脑风暴、产品摘要、PRFAQ |
|
||
| 📚 **Paige**，技术文档工程师 | 分析 | 项目文档、流程图、文档校验 |
|
||
| 📋 **John**，产品经理 | 规划 | PRD 创建、Epic/Story 拆分、实施就绪评审 |
|
||
| 🎨 **Sally**，UX 设计师 | 规划 | UX 设计规范 |
|
||
| 🏗️ **Winston**，系统架构师 | 方案设计 | 技术架构、一致性检查 |
|
||
| 💻 **Amelia**，高级工程师 | 实现 | Story 执行、快速开发、代码评审、Sprint 规划 |
|
||
|
||
每位智能体都有硬编码的身份（名字、职衔、专业领域）和可自定义的层（角色、原则、沟通风格、图标、菜单）。你可以重写 Mary 的原则或添加菜单项，但无法改她的名字——这是刻意为之的。品牌辨识度经得起自定义，所以"嘿 Mary"永远激活分析师，无论团队怎样塑造她的行为。
|
||
|
||
## 激活流程
|
||
|
||
调用命名智能体时，八个步骤依次执行：
|
||
|
||
1. **解析智能体配置** — 通过 Python 解析器（使用 stdlib `tomllib`）将内置 `customize.toml` 与团队覆盖和个人覆盖合并
|
||
2. **执行前置步骤** — 团队配置的任何预处理行为
|
||
3. **采用人设** — 硬编码身份加上自定义的角色、沟通风格、原则
|
||
4. **加载持久化事实** — 组织规则、合规说明，可通过 `file:` 前缀加载文件（如 `file:{project-root}/docs/project-context.md`）
|
||
5. **加载配置** — 用户名、沟通语言、输出语言、产物路径
|
||
6. **打招呼** — 个性化问候，使用配置的语言，带上智能体的 emoji 前缀让你一眼认出谁在说话
|
||
7. **执行后置步骤** — 团队配置的任何问候后设置
|
||
8. **分发或展示菜单** — 如果你的开场消息能匹配某个菜单项，直接执行；否则展示菜单等待输入
|
||
|
||
第 8 步是意图与能力的交汇点。"嘿 Mary，咱们来头脑风暴"之所以跳过菜单渲染，是因为 `bmad-brainstorming` 显然对应 Mary 菜单上的 `BP`。如果你说的比较模糊，她会简短问一句，而不是走确认仪式。如果完全不匹配，她会正常继续对话。
|
||
|
||
## 为什么不只用菜单？
|
||
|
||
菜单迫使用户迁就工具。你得记住头脑风暴在分析师智能体的 `BP` 编码下，而不是 PM 智能体上，还得知道哪个人设负责哪些功能。这些都是工具强加给你的认知负担。
|
||
|
||
命名智能体把这个关系反转了。你用任何自然的方式，对着某个人说你想做什么。智能体知道自己是谁、能做什么。当你的意图足够清晰，她就直接开始。
|
||
|
||
菜单仍然作为兜底存在——探索时展示，确定时跳过。
|
||
|
||
## 为什么不直接用空白提示？
|
||
|
||
空白提示假设你知道"魔法咒语"。"帮我头脑风暴"也许有用，但"帮我发散下我这个 SaaS 创意"可能就不灵了，而结果取决于你怎么措辞。你变成了提示工程师。
|
||
|
||
命名智能体在不牺牲自由度的前提下增加了结构。人设保持一致，能力随时可发现，`bmad-help` 永远只差一个命令。你不用猜智能体能做什么，也不需要翻手册才能用它。
|
||
|
||
## 自定义是一等公民
|
||
|
||
自定义模型让这套方案能从单个开发者扩展到整个组织。
|
||
|
||
每个智能体自带 `customize.toml` 及合理默认值。团队在 `_bmad/custom/bmad-agent-{role}.toml` 中提交覆盖。个人可以在 `.user.toml`（已 gitignore）中叠加偏好。解析器在激活时按可预测的结构化规则合并三层配置。
|
||
|
||
大多数用户从不需要手写这些文件。`bmad-customize` 技能会引导你选择目标、区分智能体/工作流作用域、撰写覆盖、验证合并结果——让自定义能力对任何理解自己意图的人开放，不限于精通 TOML 的人。
|
||
|
||
举个例子：团队提交一个文件，告诉 Amelia 查库文档时一律用 Context7 MCP 工具，本地 epics 列表找不到 story 时回退到 Linear。Amelia 分发的每个开发工作流（dev-story、quick-dev、create-story、code-review）都继承这些行为，无需改源码、无需逐工作流重复配置。
|
||
|
||
此外还有第二个自定义面，用于**跨领域关注点**：中央配置 `_bmad/config.toml` 和 `_bmad/config.user.toml`（由安装器维护，从每个模块的 `module.yaml` 重建）加上 `_bmad/custom/config.toml`（团队提交）和 `_bmad/custom/config.user.toml`（个人，已 gitignore）作为覆盖。这里存放着 **智能体花名册** ——轻量级描述符，`bmad-party-mode`、`bmad-retrospective` 和 `bmad-advanced-elicitation` 等花名册消费者读取它来了解有哪些智能体可用、如何扮演它们。用团队覆盖在全组织范围重新定义某个智能体；用 `.user.toml` 覆盖添加虚构角色（Kirk、Spock、领域专家）作为个人实验——无需碰任何技能目录。每个技能的配置文件塑造 Mary **激活时的行为**；中央配置塑造其他技能**查看花名册时看到的 Mary**。
|
||
|
||
完整自定义文档和实操示例请参见：
|
||
|
||
- [如何自定义 BMad](../how-to/customize-bmad.md) — 可自定义项和合并规则的参考
|
||
- [如何为组织扩展 BMad](../how-to/expand-bmad-for-your-org.md) — 五个实操方案，覆盖智能体全局规则、工作流约定、外部发布、模板替换和花名册管理
|
||
- `bmad-customize` 技能 — 引导式编写助手，将你的意图转换为正确放置并经过验证的覆盖文件
|
||
|
||
## 更大的理念
|
||
|
||
当今大多数 AI 助手要么是菜单，要么是提示框，两者都把认知负担推给了用户。命名智能体加上可自定义技能，让你可以和一个了解项目的队友对话，并且让你的组织能塑造这个队友而不必 fork。
|
||
|
||
下次你输入"嘿 Mary，咱们来头脑风暴"，她直接上手干活时，留意一下哪些事情**没有**发生。没有斜杠命令，没有菜单要翻，没有尴尬的功能介绍。这种"无感"，正是设计本身。
|