1. 项目概述：当AI智能体遇上敏捷开发

如果你和我一样，在软件开发的日常里，既想拥抱AI智能体带来的自动化潜力，又头疼于如何让它真正理解并融入一个结构化的开发流程，那么今天聊的这个项目—— BMad Method Plugin for OpenClaw ——可能会让你眼前一亮。简单来说，它把一个名为BMad的AI驱动敏捷开发框架，做成了OpenClaw这个多智能体平台的一个插件。这可不是简单的功能堆砌，其核心设计理念是： 让一个“总指挥”智能体（BMad Master）来全权调度整个软件开发生命周期，从需求分析、规划、方案设计到编码实现，每一步都由一个专属的、上下文隔离的“专家”智能体来完成。

想象一下这个场景：你启动一个项目，一个“项目经理”智能体帮你拆解需求、制定计划；接着，一个“架构师”智能体接过任务，设计出技术方案；最后，“开发”和“测试”智能体们接力完成代码和验证。关键就在于，每个专家只专注于自己那部分工作，干完活就“下班”，记忆和上下文不会污染到下一个环节。这解决了多智能体协作中一个老大难问题： 上下文污染（Context Bleeding） 。OpenClaw本身提供了强大的多智能体对话和工具调用能力，而BMad插件则在其之上，赋予了一套严谨的、可重复的工程化开发方法论和状态管理机制。

这个项目适合谁呢？首先是那些已经在探索或使用OpenClaw进行自动化任务的开发者，尤其是希望将AI智能体应用于复杂、多阶段的软件项目而不仅仅是单次对话的人。其次，是对AI驱动的开发流程（AI-Native Development）感兴趣的项目经理、技术负责人或架构师，它提供了一个现成的、可落地的框架来实践这一理念。即使你只是对多智能体系统设计感兴趣，这个项目在解决“如何让多个AI有序、隔离地协作完成一个长期目标”这个问题上，也提供了非常精巧的架构思路。

2. 核心架构与设计哲学拆解

2.1 为什么必须是“顶级智能体”？

这是理解整个插件设计的第一把钥匙。在OpenClaw的架构里，智能体分为“顶级智能体”和“子智能体”。子智能体通常由用户或另一个智能体在会话中临时创建，用于处理特定任务，但它们有一个关键限制： 子智能体无法再创建新的子智能体 。

BMad Master的核心职责是什么？是 编排（Orchestration） 。它需要根据项目所处的阶段（分析、规划、方案、实现），动态地决定接下来该启动哪个工作流，并为此创建一个专属的专家智能体（例如分析师Mary、架构师Winston）。这个“创建专家”的动作，在OpenClaw里就是调用 sessions_spawn 工具。由于子智能体无权调用此工具，BMad Master就必须被配置为一个 顶级智能体 ，与OpenClaw默认的 main 智能体平级。

注意 ：这个设计决策直接影响了你的OpenClaw配置文件结构。你不能把BMad Master简单地塞到某个现有智能体的工具列表里，而必须在 agents.list 中为其单独声明一个顶级入口。这确保了它在系统层面拥有足够的权限来扮演“总调度”的角色。

2.2 两种执行模式：全自动与带人审核

插件提供了两种驱动工作流执行的模式，对应不同的自动化程度和人工介入需求。

YOLO模式（全自动） ：顾名思义，就是“你只管放手”。一旦启动一个工作流（比如“撰写产品需求文档”），对应的子智能体（如项目经理John）会一口气跑完这个工作流定义的所有步骤，中间不停顿。完成后，它会通过 announce 工具通知BMad Master。Master检查状态后，自动提议进入下一个工作流（比如“进行技术架构设计”）。这种模式适合流程标准化程度高、你对AI输出质量比较有信心，或者希望快速生成初稿的场景。

交互模式（带人审核） ：这是更稳健、更可控的模式。子智能体每完成一个步骤（例如，完成了PRD中的“用户画像”部分），就会自动暂停。此时，BMad Master会提示用户：“专家已完成步骤X，输出已保存。请审阅并给出反馈。”用户检查 _bmad-output/ 目录下的产出物，如果满意，就告诉Master“继续”；如果需要修改，就给出具体的反馈指令。Master会通过 sessions_send 工具将你的反馈精准地传递给那个处于暂停状态的子智能体，让它基于反馈执行下一步或修正当前步。这种模式将人类置于决策环中，实现了 人机协同的敏捷迭代 ，特别适用于关键产出物或探索性任务。

选择哪种模式，取决于你对项目风险的控制欲和对AI当前能力的判断。我的经验是，在项目初期探索或核心架构设计时，使用交互模式；在后续批量生成用户故事、执行代码审查等重复性较高的任务时，切换到YOLO模式提升效率。

2.3 状态管理：项目记忆的核心

多智能体协作最大的挑战之一是“失忆”。A智能体产生的结论，B智能体不知道。BMad插件通过一个中心化的、文件系统的状态管理机制解决了这个问题。

所有项目状态都保存在项目根目录的 _bmad/state.json 文件中。这个文件记录了：

  • 当前阶段 ：项目处于分析、规划、方案、实现中的哪一个。
  • 活跃工作流 ：当前正在执行的是哪个工作流（如 product-brief ）。
  • 已完成工作流 ：哪些工作流已经走完。
  • 产出物索引 ：各个工作流生成了哪些文件，存放在哪里。

当一个工作流（比如“技术调研”）完成后，子智能体调用 bmad_complete_workflow ，这个动作会原子化地更新 state.json 。接下来，当BMad Master决定启动“架构设计”工作流时，它会先读取 state.json ，确保“技术调研”已完成，然后将该调研的产出物路径作为上下文的一部分，传递给新创建的“架构师”智能体。这样，知识就被 结构化地、单向地 传递下去，避免了混乱。

实操心得 ：务必确保你的OpenClaw工作空间以及项目目录对插件工具具有读写权限。 state.json 的读写冲突虽然通过文件锁做了处理，但在极高频调用下仍需注意。建议每个项目使用独立的OpenClaw工作空间，避免潜在的状态文件污染。

3. 插件工具链深度解析

BMad插件提供了7个核心工具，它们像一套精密的齿轮，共同驱动着整个开发流程。理解每个工具的调用者和时机，是手动调试或扩展插件的基础。

3.1 面向Master的指挥工具

这些工具由BMad Master智能体调用，用于全局管控。

bmad_init_project ：项目初始化器。这是一切的起点。它会在你的项目根目录创建 _bmad/ 骨架目录，初始化 state.json ，并建立指向BMad核心方法库（BMM）的符号链接。这意味着，你的每个项目都可以共享同一套BMad方法论定义，但拥有独立的状态。

bmad_list_workflows ：工作流清单。它根据 state.json 中的当前阶段和完成情况，动态计算出哪些工作流是“可执行”的。例如，在“分析”阶段，它只会列出“产品简报”、“市场调研”等工作流，而不会显示“冲刺规划”。这强制了流程的阶段性，防止跳步。

bmad_start_workflow ：工作流启动器。这是最关键的编排工具。Master调用它，并指定一个工作流名称（如 architecture-design ）。该工具会做几件事：

  1. 验证该工作流在当前状态下是否允许启动。
  2. 从BMM库中加载该工作流的定义（包括步骤、提示词模板）。
  3. 准备一个完整的、包含所有必要上下文（项目状态、历史产出物路径）的“任务提示词”。
  4. 返回这个提示词。Master随后用这个提示词作为参数，调用OpenClaw的 sessions_spawn 工具，从而诞生一个专为此任务而生的子智能体。

bmad_get_state ：状态查看器。让Master或用户随时查询项目进展，一目了然。

3.2 面向子智能体的执行工具

这些工具由被 sessions_spawn 出来的专家子智能体调用，用于按步骤推进具体工作。

bmad_load_step ：步骤加载器。子智能体在开始工作或完成上一步后调用它。工具会根据工作流定义和当前进度，返回下一个需要执行的步骤的详细指令和提示词。在交互模式下，完成一步后调用它，会进入等待状态，直到收到用户通过Master传来的反馈。

bmad_save_artifact ：产出物保存器。这是知识沉淀的关键。子智能体完成一个步骤（如写好了一份架构图说明）后，调用此工具保存产出。它有 去重检测 机制：如果内容与已保存的 artifact 高度相似，则会附加版本号而非覆盖，保留了迭代历史。所有产出物按工作流分类，存储在 _bmad-output/ 目录下，结构清晰。

bmad_complete_workflow ：工作流完成器。当子智能体执行完工作流的最后一个步骤后调用。它会将 state.json 中的该工作流标记为“完成”，并触发阶段过渡检查（例如，所有“规划”阶段的工作流都完成后，自动将阶段推进到“方案”）。

3.3 工具间的协作流程

让我们通过一个具体场景串联这些工具：

  1. 用户对BMad Master说：“我们开始为新的微服务设计API。”
  2. Master调用 bmad_list_workflows ，发现“架构设计”工作流可用。
  3. Master调用 bmad_start_workflow(“architecture-design”) ，得到一个给“架构师Winston”的任务提示词。
  4. Master用该提示词调用 sessions_spawn ，Winston智能体诞生。
  5. Winston调用 bmad_load_step ，拿到第一步任务：“识别系统边界和上下文。”
  6. Winston思考并执行，生成一份上下文图描述。
  7. Winston调用 bmad_save_artifact ，将描述保存为 _bmad-output/solutioning/architecture/context-diagram.md 。
  8. （交互模式下）Winston暂停，等待反馈。用户审阅后通过Master发送“很好，请继续定义核心实体及其关系”。
  9. Master通过 sessions_send 将反馈给Winston。Winston调用 bmad_load_step ，拿到第二步任务（结合了用户反馈）。
  10. 循环步骤6-9，直到所有步骤完成。
  11. Winston调用 bmad_complete_workflow ，标记此工作流完成，并 announce 给Master。
  12. Master获悉后，调用 bmad_list_workflows ，提议下一个工作流（如“史诗与用户故事拆分”）。

4. 从零开始的完整配置与实操指南

4.1 环境准备与插件安装

首先，确保你有一个可运行的OpenClaw环境。接着，我们安装BMad插件。

# 1. 进入OpenClaw的扩展目录（通常位于用户主目录下）
# 如果目录不存在，可以先创建
mkdir -p ~/.openclaw/extensions

# 2. 克隆BMad插件仓库
git clone https://github.com/ErwanLorteau/BMAD_Openclaw.git ~/.openclaw/extensions/bmad-method

# 3. 安装插件的Node.js依赖
cd ~/.openclaw/extensions/bmad-method
npm install

这里有个细节：插件目录命名为 bmad-method 是约定俗成的，OpenClaw的插件加载机制会识别这个目录名。使用 npm install 安装的依赖是插件自身运行所需的，与OpenClaw主进程的依赖是隔离的。

4.2 关键配置详解

接下来，需要修改OpenClaw的主配置文件 ~/.openclaw/openclaw.json 。这个配置决定了插件如何被加载，以及BMad Master智能体如何被集成到系统中。

{
  // 1. 插件加载配置
  plugins: {
    load: {
      // 指定插件所在的路径，支持绝对路径和以 ~ 开头的用户目录路径
      paths: ["~/.openclaw/extensions/bmad-method"]
    },
    entries: {
      // 插件入口标识，与目录名对应
      "bmad-method": {
        enabled: true, // 必须设置为true
        config: {} // 目前插件没有额外配置，这里留空对象即可
      }
    }
  },

  // 2. 智能体列表配置 - 这是核心改动
  agents: {
    list: [
      // 你原有的智能体配置，例如默认的main智能体
      // ... 
      // 新增 BMad Master 作为一个顶级智能体
      {
        id: "bmad-master", // 唯一ID，用于内部引用
        name: "BMad Master", // 显示名称
        // 为该智能体启用工具。‘allow: ["bmad-method"]’表示允许使用bmad-method插件提供的所有工具
        tools: {
          allow: ["bmad-method"]
        }
        // 注意：这里通常不需要像main智能体那样配置模型、温度等参数，
        // 因为BMad Master主要作为工具调用和路由的中介，其“思考”能力依赖于你通过哪个会话来驱动它。
        // 实际执行具体工作的，是它通过 sessions_spawn 创建的子智能体。
      }
    ]
  },

  // 3. 启用智能体间通信工具
  tools: {
    agentToAgent: {
      enabled: true, // 必须为true，否则Master无法与子智能体通信
      // 允许哪些智能体可以发起跨智能体通信。这里允许main和bmad-master。
      allow: ["main", "bmad-master"]
    }
  }
}

配置要点解析 ：

  1. agents.list 中新增条目 ：这是将BMad Master引入系统的关键。它被声明为一个与 main 平级的顶级智能体。
  2. 工具授权 ： tools: { allow: ["bmad-method"] } 这行配置至关重要。它意味着这个 bmad-master 智能体实例被授权调用该插件注册的所有7个工具。没有这个授权，Master就是个光杆司令。
  3. 智能体间通信 ： agentToAgent 工具必须启用，并且要将 bmad-master 加入 allow 列表。这样，用户从 main 智能体发起的对话，才能通过 sessions_send 工具将指令路由给 bmad-master ，进而开启整个BMad流程。

4.3 创建工作空间与启动验证

BMad Master需要一个独立的工作空间来管理会话和临时文件。

# 创建专属工作空间目录
mkdir -p ~/.openclaw/workspace-bmad

这个目录路径不是硬编码在插件中的，但通常约定俗成。OpenClaw会在该目录下存储与 bmad-master 智能体相关的会话数据。

配置完成后，重启OpenClaw网关服务以使更改生效：

openclaw gateway restart

重启后，请立即查看OpenClaw的日志输出。如果配置正确，你应该能看到类似以下的关键日志行，这表明插件已成功加载并注册了工具：

[plugins] BMad Method plugin loaded. Method path: /home/your_user/.openclaw/extensions/bmad-method
[plugins] BMad Method: registered 7 tools

如果没看到这些日志，或者有错误提示，请依次检查：1) 插件路径是否正确；2) JSON配置文件语法是否有误（可以使用在线JSON验证器）；3) OpenClaw服务是否拥有对应目录的读取权限。

5. 实战演练：启动你的第一个BMad项目

假设我们要开发一个“个人图书管理系统”。让我们看看如何用BMad插件来走一遍流程。

5.1 项目初始化与主控对话

首先，在你的项目目录（例如 ~/projects/my-book-manager ）下，你需要与BMad Master建立连接。由于Master是一个独立的智能体，你不能直接在默认的聊天窗口对它说话。操作流程如下：

  1. 在OpenClaw中，开始一个与 main 智能体的新对话。
  2. 向 main 发送指令，让它联系 bmad-master 。例如，你可以说：“请让 bmad-master 初始化当前目录为一个新的BMad项目。”
  3. main 智能体会使用 sessions_send 工具，将这个请求转发给 bmad-master 。
  4. bmad-master 被激活，它首先会调用 bmad_init_project 工具。

初始化完成后，你的项目目录会生成如下结构：

my-book-manager/
├── _bmad/
│   ├── state.json          # 初始状态：阶段为“analysis”，无完成工作流
│   ├── config.yaml         # 项目基础配置（可从模板生成）
│   ├── core/ -> (符号链接到插件内的BMad核心库)
│   └── bmm/ -> (符号链接到插件内的方法模块)
└── _bmad-output/           # 目前为空，等待产出物

此时， bmad-master 通常会回复一条消息，告知项目已初始化，并询问你是否要开始第一个工作流（例如“创建产品简报”）。

5.2 交互模式下的需求分析实战

我们选择“交互模式”来开始“产品简报”工作流，以便仔细打磨需求。

  1. 启动工作流 ：你通过 main 告诉 bmad-master ：“开始产品简报工作流。” Master调用 bmad_list_workflows 确认后，再调用 bmad_start_workflow(“product-brief”) ，生成任务提示词并创建“分析师Mary”子智能体。
  2. 执行第一步 ：Mary调用 bmad_load_step ，获得第一步任务：“定义项目愿景和核心目标。” 她开始工作，生成一段关于“个人图书管理系统”愿景的描述。
  3. 保存与暂停 ：Mary调用 bmad_save_artifact ，将描述保存为 _bmad-output/analysis/product-brief/vision.md 。由于是交互模式，她在此处自动暂停，并通知Master。
  4. 人工审核与反馈 ：你收到Master的通知，去查看 vision.md 。你觉得愿景描述过于技术化，希望更侧重普通用户的体验。你通过 main 给 Master 反馈：“愿景描述需要更以用户为中心，强调‘轻松管理’和‘发现乐趣’，减少技术术语。”
  5. 迭代 ：Master将你的反馈通过 sessions_send 传给暂停的Mary。Mary再次调用 bmad_load_step ，此时工具会结合你的反馈，生成第二步任务（可能是“修订愿景陈述”或继续下一步）。Mary根据反馈修改内容，并再次保存。如此循环，直到“产品简报”的所有步骤（可能包括目标用户、核心功能、非功能性需求等）都完成。
  6. 完成工作流 ：最后一步完成后，Mary调用 bmad_complete_workflow 。 state.json 被更新，该工作流标记为完成。Mary通过 announce 通知 Master：“产品简报已完成。”

5.3 阶段推进与自动化衔接

“产品简报”完成后，BMad Master会自动检查状态。它发现“分析”阶段还有其他工作流（如“技术调研”），便会询问你是否开始下一个。或者，如果你在配置中启用了更自动化的策略，它可能直接提议开始“规划”阶段的第一个工作流，例如“产品需求文档”撰写。

此时，Master会调用 bmad_start_workflow(“prd”) ，创建“项目经理John”子智能体。 关键在这里 ：当生成John的任务提示词时， bmad_start_workflow 工具会自动将 _bmad-output/analysis/product-brief/ 下的所有产出物路径作为上下文的一部分注入。因此，John一“出生”就知道之前Mary得出的项目愿景和目标，并在此基础上撰写PRD。这实现了 跨智能体、跨工作流的上下文无损传递 。

6. 常见问题排查与进阶技巧

6.1 安装与配置问题

问题1：插件加载失败，日志中没有“BMad Method plugin loaded”消息。

  • 排查 ：首先检查 openclaw.json 中 plugins.load.paths 的路径是否正确。路径中的 ~ 在JSON中可能不会被正确解析，建议改为绝对路径，如 /home/username/.openclaw/extensions/bmad-method 。
  • 排查 ：检查插件目录是否有 package.json 且 npm install 已成功执行（存在 node_modules 文件夹）。
  • 排查 ：查看OpenClaw更详细的错误日志，通常会有加载失败的具体原因，如语法错误、模块缺失等。

问题2：配置完成后，无法在聊天中与 bmad-master 通信。

  • 排查 ：确认 agentToAgent 工具已启用，且 allow 列表中包含了 "bmad-master" 。
  • 排查 ：确认你在和 main 智能体对话，并使用 sessions_send 来传递消息。指令格式通常是：“请告诉 bmad-master [你的指令]”。
  • 技巧 ：你可以先让 main 智能体执行 list_agents 工具，查看当前已注册的智能体列表，确认 bmad-master 是否存在。

6.2 运行时与操作问题

问题3：子智能体执行失败，提示“工具调用错误”或“找不到工作流定义”。

  • 排查 ：这通常是因为 _bmad/core/ 或 _bmad/bmm/ 的符号链接损坏或指向错误。检查这两个链接是否有效（ ls -la _bmad/ ），并指向插件安装目录内的正确位置。
  • 排查 ：检查 state.json 文件格式是否损坏。可以尝试手动备份后，重新运行 bmad_init_project （注意这会重置状态）。

问题4：在交互模式下，给子智能体发送反馈后，它没有反应。

  • 排查 ：子智能体可能处于非活跃状态。OpenClaw的会话可能有超时机制。检查该子智能体的会话是否仍然存在。
  • 操作 ：最可靠的方式是，始终通过BMad Master来中转反馈。确保你的反馈指令是发送给Master的（例如“告诉架构师Winston，需要补充数据流图”），而不是试图直接回复子智能体的消息。
  • 技巧 ：在复杂反馈时，可以引用之前产出物的具体文件名或内容片段，帮助AI更准确地定位上下文。

问题5：产出物文件混乱或重复。

  • 解析 ： bmad_save_artifact 工具具有基础的去重功能，但它基于内容哈希判断。如果内容有实质性修改，它会产生新文件。所有产出物都按工作流分类存放，结构是清晰的。感到混乱可能是因为同一工作流内多次迭代产生了多个版本文件。
  • 建议 ：养成定期查看 _bmad-output/ 目录的习惯。重要的里程碑产出，可以在工作流完成后，手动将其复制到项目正式的 docs/ 或 spec/ 目录中，作为基线版本。

6.3 进阶使用与定制技巧

技巧1：自定义工作流与提示词 BMad方法的核心定义（工作流步骤、专家角色提示词）位于插件目录的 bmm/ 子模块中。如果你对默认的分析、规划流程不满意，可以 fork 该仓库，修改 bmm/ 中的YAML定义文件。例如，为“架构设计”工作流增加一个“安全性评估”的步骤，或者调整“开发人员”角色的系统提示词，使其更符合你团队的编码规范。修改后，重新链接项目的 _bmad/bmm/ 指向你的自定义版本即可。

技巧2：混合使用YOLO与交互模式 项目不一定要全程使用一种模式。你可以在 bmad_start_workflow 时（通过Master）指定模式。例如，对于“生成API接口文档”这种标准化高的工作流，使用YOLO模式快速生成；对于“设计数据库schema”，则使用交互模式逐步评审。这种灵活性需要你通过自然语言明确指示Master。

技巧3：集成外部工具链 BMad插件管理的是“知识生产”流程，而真正的开发还涉及代码库、CI/CD等。你可以在工作流步骤中，设计让AI生成特定的命令或配置文件。例如，在“实现”阶段，让“开发人员”智能体不仅生成代码，还生成一份 Dockerfile 草案或 docker-compose.yml 文件，保存在产出物目录。然后，你可以结合外部脚本，将这些产出物自动搬运到项目相应位置，甚至触发后续的构建流程，从而实现从AI设计到部分自动部署的衔接。

技巧4：状态备份与恢复 _bmad/state.json 是整个项目的“记忆中枢”。在进行重大操作或插件升级前，手动备份这个文件是明智之举。如果遇到不可预知的状态错乱，你可以用备份文件覆盖，让项目回退到某个已知的正确状态点，然后继续执行。

# AI智能体
Logo
亚马逊云科技技术品牌专区

更多推荐

cover

别再只聊大模型！AI的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区
cover

别再只聊大模型！人工智能的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区
cover

别再只聊大模型！AI的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区