7.6 KiB
| title | description | sidebar | ||
|---|---|---|---|---|
| 命名智能体 | 为什么 BMad 的智能体有名字、人设和自定义能力——相比菜单驱动或纯提示驱动的方案，这解锁了哪些可能性 |
|
你说"嘿 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"永远激活分析师，无论团队怎样塑造她的行为。
激活流程
调用命名智能体时，八个步骤依次执行：
- 解析智能体配置 — 通过 Python 解析器（使用 stdlib
tomllib）将内置customize.toml与团队覆盖和个人覆盖合并 - 执行前置步骤 — 团队配置的任何预处理行为
- 采用人设 — 硬编码身份加上自定义的角色、沟通风格、原则
- 加载持久化事实 — 组织规则、合规说明，可通过
file:前缀加载文件（如file:{project-root}/docs/project-context.md） - 加载配置 — 用户名、沟通语言、输出语言、产物路径
- 打招呼 — 个性化问候，使用配置的语言，带上智能体的 emoji 前缀让你一眼认出谁在说话
- 执行后置步骤 — 团队配置的任何问候后设置
- 分发或展示菜单 — 如果你的开场消息能匹配某个菜单项，直接执行；否则展示菜单等待输入
第 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 — 可自定义项和合并规则的参考
- 如何为组织扩展 BMad — 五个实操方案，覆盖智能体全局规则、工作流约定、外部发布、模板替换和花名册管理
bmad-customize技能 — 引导式编写助手，将你的意图转换为正确放置并经过验证的覆盖文件
更大的理念
当今大多数 AI 助手要么是菜单，要么是提示框，两者都把认知负担推给了用户。命名智能体加上可自定义技能，让你可以和一个了解项目的队友对话，并且让你的组织能塑造这个队友而不必 fork。
下次你输入"嘿 Mary，咱们来头脑风暴"，她直接上手干活时，留意一下哪些事情没有发生。没有斜杠命令，没有菜单要翻，没有尴尬的功能介绍。这种"无感"，正是设计本身。