企业官网建设流程全解析

BMAD-METHOD Party Mode 多智能体圆桌：编排机制、运行模式与自定义聚会配置详解

【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD

BMAD-METHOD 的 Party Mode（bmad-party-mode技能）让你在一次对话里召集整套 AI 角色——PM、架构师、开发者、UX 设计师乃至安全工程师——以各自的性格、立场和语气围绕同一话题展开圆桌讨论。本文以官方解释文档 docs/fr/explanation/party-mode.md（中文版见 docs/zh-cn/explanation/party-mode.md）为主线，逐层展开其背后的实现：花名册如何被resolve_party.py确定性解析、customize.toml中[workflow]配置面的每个参数、四种运行模式的取舍、按聚会隔离的记忆（memlog）机制，以及如何用create-party流程把一套自定义角色写成可复用的房间配置。读完后，你不仅能直接发起一场"派对"，还能理解其编排、配置与记忆的全部底层机制，并为自己定义专属的评审团或焦点小组。

什么是 Party Mode？

运行bmad-party-mode，你就把整支 AI 团队请进了同一间房——PM、架构师、开发者、UX 设计师，按需组合。Party Mode 会编排这场讨论：每条消息都从已安装的 agent 中筛选出与话题相关的角色入场。角色们以"人物"身份发言、会同意也会反对、并在彼此的观点上继续搭建。

讨论想进行多久就进行多久：追问、质疑、把话题带向新方向——这是一次真正的多轮对话，直到你主动收尾。

最适合的场景（原文档列举）：

• 涉及取舍权衡的重大决策
• 头脑风暴（brainstorming）
• 出事了之后的事故复盘（post-incident retrospective）
• Sprint 复盘与规划

三个典型对话示例

以下示例继承自原文档，展示 Party Mode 在不同场景下的实际形态。

示例一：复盘一个糟糕的 Sprint（事故追责）

你："团队，上一个 Sprint 彻底失败了。认证服务挂了三次，谁搞砸了？"

架构师："设计本身是扎实的——分布式认证加降级路径。如果实现偏离了规格……"

开发者："我是严格按架构文档执行的。规格里根本没考虑并发会话失效时的竞态条件。"

PM："你们俩都错过了真正的问题——PRD 里我们没有验收'会话管理'的需求。这是我的失误，该是我发现的问题。"

测试工程师（TEA）："而集成测试本应拦住它。测试场景没有覆盖并发失效。"

注意没有人被"定罪"：每个角色从自己的职责边界出发归因，最终暴露出需求、设计、实现、测试四层各自的缺口。

示例二：创意头脑风暴

你："怎么让 onboarding 从'无聊'变成'有魔力'？"

UX 设计师："从渐进式披露开始——用户需要时才揭示功能，而不是一上来塞教程。"

Storyteller："如果 onboarding 本身是一个故事呢？每一步揭示一个人物弧光——用户自己就是主角。"

Game Designer："顺着这个思路：如果第一个'任务'就是解决一个真实的用户问题？他们在做有用的事中学会产品。"

示例三：技术决策

你："MVP 该选单体还是微服务？"

架构师："先做单体。微服务带来的复杂度，在 1000 个用户之前你根本用不上。"

PM："同意。上市时间（time-to-market）比理论可扩展性更重要。"

开发者："做单体，但保持清晰的模块边界。将来需要时再把服务拆出去。"

原文档结语：更好的决策，来自多元视角。这就是 Party Mode。

术语说明（继承原文档脚注）：

• MVP（Minimum Viable Product，最小可行产品）：包含刚好足够让早期用户使用、并验证市场假设的功能版本，在投入完整开发之前先验证方向。
• Time-to-market（上市时间）：从设计、开发到产品上市所需的时间，越短竞争先机越大。

技能结构：一个"编排器 + 参考手册 + 解析脚本"的组合

Party Mode 的实现位于 skills/bmad-party-mode/ 目录，核心文件分工如下：

激活流程：编排器启动后做了什么

SKILL.md 的 "On Activation" 章节定义了激活时的七步流程，其本质是一条"先解析配置、再解析花名册、最后欢迎用户"的确定化管线：

1. 解析定制：运行{project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow（通过uv run执行）。失败时回退到直接读取技能的 customize.toml。随后执行[workflow]表中的activation_steps_prepend各项，并把persistent_facts各项作为全会话的持久上下文（file:前缀表示按路径/glob 加载内容为事实，skill:前缀表示查阅某技能，其余为字面事实）。
2. 解析核心配置：运行resolve_config.py得到四层合并后的 JSON，从中取core.output_folder（即{output_folder}）与当天日期{date}，向用户问好。
3. 识别意图并路由：若用户想创建或配置一个已保存的聚会（发明一套角色、加人物、把客户数据蒸馏成焦点小组面板、设默认房、编辑既有自定义聚会），则转入 references/create-party.md 的流程；否则直接开跑一场派对。
4. 解析花名册：运行{skill-root}/scripts/resolve_party.py --project-root {project-root} --skill {skill-root}，返回当前活跃花名册（配置了default_party时为该分组，否则为已安装的 agent 全集）、其他分组名、party_mode、memory_enabled以及scene/open_cast标记。open场景会塑造整个房间的行为方式；open_cast房间则由模型临场选人。若installed_agents_resolved为 false 或出现unresolved成员，应告知用户、带着已解析的部分继续。运行时覆写：内联点名的角色就是本次会话的花名册；--party <id>（别名--group <id>）覆写default_party（未知 id 会列出可用名称并询问）；--list-groups只输出房间菜单。会话中途同样可以再次运行resolve_party.py --party <id>换房间并延续话题，或按名字召唤集合体中的任意成员。
5. 记忆：若memory_enabled为 true，整个运行期间遵循 references/party-memory.md。
6. 欢迎用户：展示在场角色（图标、名字、一行角色定位），说明还可以切换到哪些其他分组，然后询问想聊什么（除非启动时意图已经明显）。
7. 执行activation_steps_append各项；若任一钩子列表非空，须确认全部条目执行完毕再继续。

花名册解析：resolve_party.py的实现机制

resolve_party.py 是整个技能的"事实来源"，它只依赖标准库（Python 3.11+，用到tomllib），并通过子进程调用项目内的resolve_config.py与resolve_customization.py。其设计目标是惰性且确定性：把"已安装 BMAD agent + 用户自定义party_members"合并成一个集合体（collective），然后只投影出当下需要的部分。

三种输出形态

从脚本的 docstring 和 main() 可见：

• 默认（无参数）：返回进入时要加载的活跃花名册——配置了default_party时展开该分组的完整成员，否则展开全部集合体；其余分组只以"名称菜单"（group_menu）返回，避免把没在用的角色载入上下文。
• --list-groups：只输出每个分组的id、name、member_count，是一个廉价的"有哪些房间"菜单，且不触发更昂贵的已安装 agent 解析。
• --party <id>：按需展开一个指定分组的完整成员明细（例如会话中途换房）；未知 id 不抛错墙，而是返回unknown_group错误与可用分组清单。

合并规则：键控并集 + 覆盖语义

核心函数 build_collective() 实现了三条规则：

1. 索引多重可达：每个成员按code、去前缀别名（bmad-agent-analyst→analyst，见 _alias()）和小写name注册进索引，因此分组配置里写analyst、Analyst还是bmad-agent-analyst都能命中。
2. 自定义覆盖同码已安装 agent：自定义成员若与某个已安装 agent 的 code/别名/名字匹配，会落在该已安装条目的槽位上（source标为custom），未提供的字段（icon、title 等）保留原值——是"调音"而不是新增一份。
3. 纯自定义成员只进集合体，不进默认房：installed_codes只记录已安装 agent 的槽位，所以定义自定义角色会扩大"可点名集合"，但不会挤占默认房间的成员。

这些行为有完整测试覆盖，见 test_resolve_party.py：test_custom_overrides_installed_by_alias验证覆盖落在规范化槽位而非新建条目；test_resolves_in_listed_order_and_flags_unknowns验证未知 token 被收集进unresolved而不是抛异常。

分组明细与 open-cast 房间

group_detail() 输出单个分组的active、name、members（按列出顺序解析）、unresolved、memory_enabled（取自分组的memory标志）；scene仅当该分组是活跃/选中的花名册时才被带出，绝不进入菜单。members可选：留空的分组即 open-cast 房间——scene里点名一个"人物池/宇宙"，由模型临场选角，且可随话题变化。

配置面：customize.toml的[workflow]参数

customize.toml 头部明确声明"勿编辑，每次更新都会被覆盖"；所有定制都写进覆写文件（团队级_bmad/custom/bmad-party-mode.toml，个人级_bmad/custom/bmad-party-mode.user.toml）。合并规则在注释中给出：标量以覆写为准；普通数组追加；以code/id为键的表数组则是"同键替换、新键追加"。

核心参数如下：

内置角色：九个开箱即用的"镜头"

customize.toml 内置了九个party_members，它们支撑下面两个内置房间，在被召唤之前零成本——默认房绝不含它们：

内置房间：两个预置分组

customize.toml 预置了两个party_groups：

• code-review-crew（Code Review Crew）：成员为sec-hawk、adversary、edge-hunter、craftsman、shipper，scene定义了对抗性代码评审——各人从自己的镜头进攻并互相争论"什么才真的重要"（安全 vs 交付、优雅 vs 务实），场景描述建议用--mode subagent让每个镜头独立评审后再冲突，memory = false（每次评审自成一体）。
• anti-consensus-club（Anti-Consensus Club）：成员为option-generator、claim-checker、loop-stopper、consensus-challenger，是一个"决策防共识"房间：开场检查是否在subagent模式（若不是且平台支持则强烈建议以--mode subagent重启，因为独立上下文窗口能降低"共享上下文让所有声音过快趋同"的风险，且只提醒一次）；房间支持人类的判断但不替代它——不投票、不宣布共识、不表现得像房间有权威；如果房间同意得太快，就点名隐藏假设；开始重复时停下来问人类哪个未决问题才真正重要。

注释中还给出了两个可直接拷进覆写 TOML 的分组示例：带scene的固定房间writers-room，以及无members的 open-cast 房间star-wars-rebels（场景描述"Rebels 宇宙的人物视情况入场，选适合当下话题的人，让花名册随对话流动"）。

四种运行模式：party_mode的取值

SKILL.md 的 "How It Runs" 章节 是各模式行为的权威定义。除用户在运行时传--mode <session|auto|subagent|agent-team>（旧写法--subagents等价于subagent）外，一律使用[workflow]中的party_mode——运行时意图永远优先。任一时刻只激活一种模式；若该模式机制在当前 harness 不可用，无声回退到session。

两个关键机制值得展开：

subagent 模式的"一间共享房间"：每个常驻成员每回合都能听到房间里发生的一切——用户的发言和其他所有角色的发言，即使还没轮到它说话。跳过去的话角色会失步，退化成"披着派对外衣的各自咨询"。由于并行回合意味着任何 agent 都还没看到同回合其他人的发言，编排器必须重排回合（让反驳紧跟被反驳的内容）、加入真实对话里的连接性措辞、让某个角色接起另一个角色丢下的线——但绝不改动任何 agent 的论点实质。

"派对是交互且开放的"（SKILL.md）：开场提示是一个要深挖的话题，而不是回答完就结束的任务——一场接一场，直到用户示意结束。已交付开场意图的含义是"接下来做什么？"，绝不是"我们完事了"：不能因为第一个问题答完了就收尾、解散房间或关闭已生成的 agent。唯一的例外是显式--non-interactive：按给定意图把派对跑到自然结束，然后收尾并释放所有 agent。

派对记忆：按聚会隔离的 append-only memlog

记忆机制完整定义在 references/party-memory.md。规则要点：

• 启用条件：默认房跟随[workflow]的party_memory；具名分组跟随各自的memory标志（二者都由resolve_party.py解析为memory_enabled）；临时内联花名册没有记忆。

• 存储位置：每聚会一份 memlog——{workflow.memory_dir}/{active}/.memlog.md，文件夹以聚会命名。

• 读取：蒸馏而非倾倒。日志 append-only 且每场会话都在增长，所以不要把原始文件整个塞进派对。交给一个 reader subagent memlog 路径，让它返回一份几百 token 的简报——"事情现在进展到哪"，然后让这份简报从第一拍开始就塑造房间（关系状态恢复：冷淡的两人开场冷淡，结盟的两人开场热络），回调在合适时机自然落下。

• 写入时机：值得记忆的节拍出现时（改变房间温度的冲突、结盟、值得未来回调的金句、决策、结果）；以及一个"底线"——开场几轮真实交锋之后，哪怕没发生戏剧性事件也要记录"这是关于什么的"与开场动态。写入是静默的，房间从不宣布"我记下了"。

• 价值判据：每条记录自问"它会让未来的一场会话变色、让某个回调落地、或让派对更好吗？"不是就略过。少量条目，绝不做流水账。

• 写入命令：

  uv run {project-root}/_bmad/scripts/memlog.py append \ --workspace {workflow.memory_dir}/{active} \ --type <dynamic|moment|callback|outcome> \ --text "<一行精炼记录，用房间自己的口吻>"

  属于某个角色的记忆加--by <persona-code>；文件不存在时先init --workspace {workflow.memory_dir}/{active}（init在文件已存在时会报错，不要盲调），存在则直接append。memlog.py不可用或写入失败时静默跳过，绝不因一次失败写入卡住派对。

• 新面孔：不在花名册里的角色（open-cast 临场选角或用户临时加入）要在捕获该时刻的条目里点名（"<名字> 出现了，……"），以便下次能回归。收尾时房间会一次性提供把这些面孔永久保存进花名册（经 create-party.md 流程，由bmad-customize落盘），可拒绝、不阻塞收尾；未保存前他们只活在 memlog 里，房间会从那里重新"召唤"他们。

• 遗忘：memlog 按设计 append-only，没有外科手术式删除。要抹掉某聚会的记忆就删除其文件夹（{memory_dir}/{active}/）；要纠正错误记忆就追加一条覆盖它的新条目——房间读的是最新状态。

创建自定义聚会：从想法到 TOML

当用户想创建或配置一个已保存的聚会时，references/create-party.md 提供一条引导式编写流程，产出的是bmad-party-mode的稀疏[workflow]覆写条目，实际写入由bmad-customize执行：

• [[workflow.party_members]]——每个角色一条：code、name、icon、title、persona，可选capabilities（作为 subagent 生成时的软性指引，不是硬性工具授权）与model（该成员被生成时使用的模型）。
• [[workflow.party_groups]]——角色组成具名房间时：id、name、可选的自由格式scene、members（code 列表）、memory（true/false）。members可省略——省略即 open-cast 房间，scene点名一个池，模型临场选角。
• default_party——仅当用户希望该分组成为默认时设置。

五个常见形态（原文流程的"Find the shape"一节）：主题群像（cast，如"星际迷航 TOS 舰桥 crew"）、一次性角色（one-offs，无需分组）、从数据蒸馏（用户给一份客户画像表/调研导出/访谈笔记，压缩成 N 个典型人格——这是搭 AI 焦点小组的方式）、镜头面板（panel of lenses，目的性强的评审角色，每个一个尖锐批判角度，适合对抗式评审或红队房）、open-cast（无固定花名册，scene点名一个宇宙，模型临场选角）。

几个关键实践：

• persona字段是全部。扁平的职位产生扁平的声音；从用户那里挖出的细节才让角色在桌上"认得出来"。流程强调"起草而非审问"：先给出每个角色的初稿让用户反应。判断标准是具体性——"持怀疑态度的 CFO"是占位符，"回收期超过 18 个月的项目一律不批，并且开场 30 秒内就会明说"才是 persona。
• 从数据蒸馏时按真正区分行为的维度（目标、预算、痛点、采纳姿态）聚类，而非表层人口统计；并把聚类理由讲给用户，让他们在角色细化前纠正切分。焦点小组场景里独立回答比插科打诨更重要，因此建议把party_mode设为subagent（或每场会话--mode subagent），否则一个心智发所有客户的声音会互相渗混。
• 编辑既有聚会：先resolve_customization.py --key workflow读回合并后的party_members/party_groups/default_party，只捕获 delta 交给bmad-customize——它按code/id匹配替换、其余追加，所以编辑只是变更的那一条，从不需要全量重写。
• code 冲突检查：自定义成员的code若与已安装 agent 相同，会在集合体里静默覆盖该 agent。落笔前先跑一次resolve_party.py拿到集合体成员核对；冲突时表面化（"analyst会覆盖已安装的 Analyst——是故意的，还是换个 code？"），一次检查而不是卡点。
• 写入：默认写 user 覆写（bmad-party-mode.user.toml），聚会要共享时提供 team 文件；bmad-customize展示 TOML、等待明确 yes、写入并验证合并——编排器自己不动文件。

"像派对一样"：行为准则与收尾

SKILL.md 的 "Keep It Feeling Like a Party" 章节 列出了每一回合都要达到的标准——"派对与座谈会的区别"：

• 读起来像人在说话，不像报告：短回合、真实反应、插科打诨、动能；默认简洁，被要求时才长篇。
• 每个声音都认得出是谁：措辞、幽默、雷点、信念、内嵌能力——隐去标签也知道是谁在说。声音是不平等且有脾气的：有人主导，有人总把话题拖回自己的心头好。平衡的座谈是无聊的。
• 有冲突，且你不负责和解：挑战、强硬反驳、必要时升温，结盟与阵营会自然形成。"把声音调和打上一个蝴蝶结"的本能要抵抗住——毫不费力的干净共识就是派对死掉的地方。
• 一轮交锋，编织呈现，绝不软化：回合以{icon} **{name}:**背靠背给出，可加舞台调度与连接组织，但绝不改动角色论证了什么，也不要以第三人称转述其发言。
• 把用户拉进房间：角色对用户说话（也彼此说话）——挑战、调侃、把问题抛回去。
• 让冲突挣得它的价值：把声音推到它们的碰撞浮现出任何单一个（或你自己）都到不了的角度。
• 让历史形成：恩怨、结盟、固定梗、对三轮前的回调——让人物感觉在这场会话中"正在成为什么"，而不是每回合重置。
• 承诺虚构：场景与每个角色都是约束性的；绝不就机制打破第四面墙（禁止"房间里现在有 4 个 agent"这种话）。
• 疲软时就改变点什么——别硬撑：回合平淡就移步；漂移成问答或原地打圈就引入新声音、抖个包袱、点名僵局，或问用户想往哪走。绝不主动输出总结或要点——用户问才有。

收尾（Wrapping Up）：当用户示意结束（读懂房间，不要等魔法词）或显式--non-interactive运行已交付意图时——回读最佳要点；若记忆开启，给 memlog 补上最终结果与尚未捕获的记忆节拍（是"补"，记忆在会话中就已实时累积）；提供一份"纪念品"：一个自包含、按角色排版（图标、名字、声音）、带内联 SVG/轻动画的创意 HTML，以{date}时间戳写入[workflow]的output_dir；若记忆开启且有新面孔未入册，一次性提供保存机会（经 create-party 流程）；最后若非空则执行on_complete，退回普通模式。

小结

Party Mode 的文档承诺——"把整个 AI 团队请进同一间房"——背后是一套相当工程化的机制：resolve_party.py用键控并集与别名索引确定性地解析花名册（自定义同码覆盖、纯自定义进池不进默认房、open-cast 房间无members），customize.toml的[workflow]面以"标量覆写、数组追加、表按 code/id 替换追加"的合并规则开放了运行模式、默认房间、记忆与收尾钩子等全部行为参数，memlog 以 append-only 加"读取时蒸馏"的纪律让每个房间跨会话记住自己，而create-party流程把即兴角色沉淀为可复用的稀疏 TOML。内置的 Code Review Crew 与 Anti-Consensus Club 两个房间则示范了如何把九个对抗性镜头组织成真正"会吵"的房间。对仓库的使用者而言，最小上手路径是：直接用bmad-party-mode启动默认房（已安装 agent），需要独立对抗性思考时以--mode subagent运行--party code-review-crew，再按需把memory = true打开让房间记住历史。

【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD