企业官网建设流程全解析

BMAD-METHOD Party Mode 实战：多 Agent 圆桌讨论、自定义佩尔松纳阵容与跨会话记忆

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

本文基于 BMAD-METHOD 的 Party Mode（派对模式）文档与bmad-party-mode技能源码，讲解如何把已安装的 BMad Agent 召集到同一场对话中进行圆桌讨论，如何用四种执行模式（session/auto/subagent/agent-team）控制"谁在思考"，以及如何从零创建、保存和记忆自定义佩尔松纳（Persona）阵容——读完你可以直接在项目中拉起 Code Review Crew、Anti-Consensus Club，或基于客户数据构建 AI 焦点小组。

什么是 Party Mode

运行bmad-party-mode后，已安装的 BMad Agent 会齐聚到同一个对话中：PM、架构师、开发者、UX 设计师，以及所选模块提供的其他 Agent 都会到场。这份"已安装名单"就是默认派对，无需任何额外配置即可使用。每位成员按自己的角色发言：可以赞同、可以反对、可以接住对方的话继续往下说，而对话始终由用户主导——你可以追问、反驳、把某个观点往前推，也可以随时换话题，直到用户主动结束。

这套机制之所以有效，是因为每个佩尔松纳的优先级不同：架构师守住设计，PM 守住范围，开发者守住"真做不做得到"。把他们放进同一个对话，妥协点会立刻暴露，而不是拖到第三周冲刺才浮出水面。

适合的场景：

• 需要真实权衡的决策；
• 头脑风暴与"我们漏掉了什么"的排查；
• 事后复盘与回顾；
• 执行前对计划做压力验证。

同时，Party Mode 也是一种快速且颇具娱乐性的头脑风暴方式——佩尔松纳们带着各自立场互相碰撞。它可以在其他工作流进行途中启动：头脑风暴、PRD 撰写、编码、销售策略构思、创作打磨都不必停下，只要当前问题需要更多视角，就把派对拉起来。

文档中给出的示例：

用户：MVP 应该用单体还是微服务？

架构师：先做单体。在千名用户量级，微服务只会平添你并不需要的运维成本。

PM：同意。比起尚未验证的扩展性，上市速度更重要。

开发者：单体没问题，但请划清明确的模块边界，让日后拆出某个服务时不必重写。

从源码结构看，整个派对由一个"编排者（orchestrator）"驱动。SKILL.md 开宗明义："You're the orchestrator（你是编排者）"，它负责召集角色、维持对话、把多个视角编织成一场连贯谈话，而不是逐条罗列的回答。

启动派对的命令速查

调用技能后直接说出你的意图即可，技能会自动判断你是想"运行一个派对"还是"创建/配置一个派对"。完整命令表如下（继承自官方文档）：

在实现层面，SKILL.md 的"On Activation"部分定义了激活流程：先运行resolve_customization.py解析该技能的[workflow]定制层，再运行resolve_config.py合并核心配置，然后通过resolve_party.py解析阵容——返回当前活跃名单（若配置了default_party组则取该组，否则取全部已安装 Agent）、其他组的名称、party_mode、memory_enabled以及场景/开放阵容（open cast）标记。此外还有几个实用参数：

• --party <id>：按组 id 打开指定派对，--group <id>是它的别名；id 不存在时会列出可用组名而不是报错。
• --list-groups：只输出"菜单"（id + 名称 + 成员数），不加载任何成员细节，适合"哪个房间？"式的快速选择。
• 会话中途同样生效：重新运行resolve_party.py --party <id>即可换房间并保留对话上下文，也可以按名字点名召唤任何一名集体成员。

四种执行模式：谁来"思考"

派对有四种执行方式。每场会话只激活一种模式，而它决定了"谁在思考"——是同一个模型替所有佩尔松纳发声，还是独立 Agent 各自推理：

这个选择很关键：一个模型演五个佩尔松纳，很容易悄悄滑向一边——因为它们共享同一个心智。生成真实 Agent 后推理被隔离，评审面板或焦点小组所需的独立性得以保留。session成本最低、最灵活；生成类模式更贵但保护独立性；auto只在需要的回合生成，取两者之间。

四种模式的详细行为分别固化在技能的 references 目录中，可以直接阅读：

• session（SKILL.md "How It Runs"）：一人饰多角，不需要任何额外指令，也是其他所有模式最终降级到的形态。
• auto（mode-auto.md）：默认内联发声，仅在以下情形生成独立 Agent——真正的评估/评审/批判（一个心智同时代言双方会滑向一致的那种评审：代码评审、红队、对计划的严肃审视）；佩尔松纳们可能得出不同结论且分歧本身就是价值；用户点名要求某人深挖、分析或调研。拿不准时就内联——"生成"是例外手段而非默认。若运行环境根本无法生成 Agent，auto退化为session。
• subagent（mode-subagent.md）：每个实质回合，每个佩尔松纳背后都站着一个真实 Agent。该文档给出三条工程要点：
  • 常驻阵容（standing cast）：若运行环境支持跨回合保活 Agent，就为每个佩尔松纳生成一次并整场复用同一个句柄——正是这种连续性让记仇、结盟、回调得以累积；
  • 一间共享房间：所有常驻成员每回合都听到房间里发生的一切（用户的话和其他人的话），即使轮次没轮到它。漏掉这一步，成员会各自漂移，"戴着派对面具的一对一咨询"就出现了；
  • 编织而非改写：并行回合里没人看到同回合其他人的发言，编排者要把反驳排到被反驳者之后、补上真实的衔接语，但绝不修改任何 Agent 论证的实质。
• agent-team（mode-agent-team.md）：把佩尔松纳立成持久的 Agent 团队，成员点对点直接发消息，来回交锋是真实发生的而非事后缝合。编排者角色从"编织"转为"主持"：发起话题、保持短回合、跑题时拉回来。注意消息是点对点的——没有共享信息流，落座缺席的成员看不到它空闲期间发生的事，"让所有人同步"是领队（编排者）的职责。

降级顺序与默认值：session是默认值。若某模式在当前环境不可用，按顺序降级：agent-team→subagent→session，且降级不打招呼（不打破沉浸）。持久默认值保存在定制层，运行时的--mode覆盖仅对该次会话生效——在 customize.toml 中，party_mode的默认就是"session"，注释明确"运行时--mode <value>对会话生效；不支持的模式（如 Claude Code 之外的agent-team）回落到session"。

::: tip--mode subagent（或auto、agent-team、session）只在那一次运行中改变配置好的默认值。 :::

非交互模式：--non-interactive

派对默认是交互式且开放式的：首次请求只是开启对话的话题，不是结束条件——回答完第一个问题派对不会自动散场，它会一轮一轮地继续，直到用户示意结束。若只想处理一条请求就停下，用--non-interactive启动：派对会在给定意图上运行到自然收尾，然后总结内容并释放已生成的子 Agent。这是唯一的非交互路径，且仅当用户显式要求时才走。

自定义派对：佩尔松纳与场景两个核心概念

默认派对使用已安装的 BMad Agent。想进一步发挥，可以直接把自己想要的佩尔松纳排成阵容并保存复用——创建派对用的是同一个技能：技能检测到你在"创建"而非"运行"，就会转入 create-party.md 定义的创作流程，最终把结果交给 bmad-customize 写入用户的 override 文件（默认写入bmad-party-mode.user.toml个人层，团队共享则用bmad-party-mode.toml团队层；目录为_bmad/custom/）。

Party Mode 本身同样可定制：运行/bmad-customize bmad-party-mode可以直接设定默认值——把某个组固定为默认派对（无参数即可加载）、选定启动模式、设置整场派对必须遵守的规则。

支撑自定义派对的只有两个核心概念：

佩尔松纳（persona）是让成员彼此可辨识的东西：说话方式、在意什么、怎么争论、特别讨厌什么、容易忽略哪里。"怀疑论的 CFO"只是占位词；"回收期超过 18 个月的项目一律不批，且开口 30 秒内就会说这句话"——这才是佩尔松纳。具体到这个程度，遮住名字标签也能认出发言者。在 customize.toml 中，[[workflow.party_members]]每个成员包含的字段是：code（唯一短代号，用于组引用与点名）、name（显示名）、icon（发言前缀的表情符号）、title（一行角色定位）、persona（"主角"字段：语气、幽默、信条、雷点、争论方式）、可选的capabilities（作为真实子 Agent 生成时的能力指引，织入生成提示词而非硬性授权）和model（该成员生成时使用的模型）。

场景（scene）是设定讨论情境的自由格式描述：背景、正在发生什么、谁跟谁敌对、谁最强势地推动。同一批成员放进不同场景会表现完全不同——值班中的舰桥 crew、下班后聚在休息室里的同一 crew、敌对姿态的采购者面板。成员只定义一次，就能被投进许多不同的房间。

派对的六种形态

"开放阵容"在源码中有明确对应：resolve_party.py 的group_menu()会为members为空的组打上open_cast: true标记，group_detail()则说明——没有成员列表时，scene描述的就是编排者即兴选角的"素材池"（例如"《星球大战：义军崛起》宇宙中的角色"），少数列出的成员可以当锚点，但场景仍可继续邀人入局。customize.toml 注释里的示例正是这种写法：

[[workflow.party_groups]] # 开放阵容房间（无 roster，由场景选角） id = "star-wars-rebels" name = "Star Wars Rebels" scene = "Aboard the Ghost. Figures from the Rebels universe drop in depending on the situation..." memory = true

派对收益最大的形态是焦点小组：喂入真实用户画像后能生成代表客户面板，在做出产品之前先测试想法。每个客户不会顺着上一位发言走，而是按自己的目标与预算反应——create-party.md 专门为此给出操作建议：从数据聚类时按"真正区分行为"的维度（目标、预算、痛点、采纳姿态）切分，并向用户说明切分理由；焦点小组独立作答比插科打诨更重要，因此建议把party_mode设为subagent（或该次用--mode subagent），否则一个心智代言所有客户，声音会互相串味。

能建出哪些派对

因为派对只由佩尔松纳与场景构成，应用面很宽，也不需要新技能或模块：

• 给创业点子做压力测试的创业者团队；
• 在审计发现问题之前先找出漏洞的合规团队；
• 围绕软件概念辩论的《敏捷宣言》起草者们；
• 以写作搭档身份组成的喜剧演员派对；
• 一起解哲学难题或硬问题的历史思想大家；
• 制定季度计划的商务高管团队。

这些只是起点——只要你能描述出一组彼此区分的视角，任何组合都能成为派对。

内置示例：Code Review Crew 与 Anti-Consensus Club

默认派对是已安装模块提供的 Agent。以下两个是随技能一同交付的自定义派对——它们不是替代默认值，而是给你在自建派对之前参考的"可运行模板"。两位"内置嘉宾"均以非激活状态存在：成员只进候选池，未被召唤前不产生成本，也不打扰默认房间。

Code Review Crew

这是一支从五个视角批判性地审视变更的评审面板，主张"与其走形式批准，不如争论真正重要的东西"。完整成员定义在 customize.toml 中：

该组在 customize.toml 中注册为id = "code-review-crew"，memory = false（每次评审各自独立；改为true可记住过去的评审）。其scene要求：每位评审从自己的透镜进攻、彼此争论什么才真正要紧——安全对交付、优雅对务实，"没有橡皮图章，没有夸奖三明治"，并指出最好以--mode subagent运行，让每个透镜先独立评审再碰撞。

/bmad-party-mode --party code-review-crew --mode subagent

Anti-Consensus Club

适合处理决策、策略、设计或模糊问题：当一个助手太快同意、或讨论已无收益却还在继续时，它提供有用反例与主张校验，打断循环并把决定权交还给人。它不是投票机构——不投票、不宣布共识、不假装有决策权。成员定义见 customize.toml：

运行方式：平台支持的话，/bmad-party-mode --party anti-consensus-club --mode subagent。其scene中内嵌了一条行为规则（可在 customize.toml 中查看原文）：会话开始时检查当前模式，若不是subagent且平台支持，就强烈建议切换——独立上下文窗口能降低"共享上下文让所有声音过快趋同"的概率；用户选择继续后就不再唠叨。该组默认memory = false。

主导对话的技巧

用户从始至终主导对话。文档给出的操作方式：

• 听某位成员说："把 UX 设计师拉上来"；
• 深挖某个视角："Winston，把它拆开讲讲"——直接点名请求，就是让某个佩尔松纳深入作答的信号；
• 会话中途换派对："切到作家房间"——切换活跃组，对话上下文保留；
• 按名字召唤当前派对之外的自定义成员。

无论以哪种模式运行，编排者都把结果呈现为一场对话而非一条条独立答复，并让佩尔松纳全程保持角色，不会为解释机制而破坏沉浸。SKILL.md 的 "Keep It Feeling Like a Party" 一节把这些要求写成硬指标：像人说话而非汇报（短回合、真实反应、有来有回）；每支声音可被盲认（遮住标签也知道是谁在说）；让成员冲突且不去强行调解——"你的本能是给声音打圆场、系个蝴蝶结，要克制住"；单一编织的对话流（以{icon} **{name}:**形式背靠背呈现，绝不用第三人称转述）；把用户拉进房间（角色是对着你说、与你争）；让碰撞物有所值——把声音推到碰撞出任何单一视角（包括你自己）都到不了的角度。

多个派对可以混搭：把多支派的成员拉进同一场对话，或当场指定阵容混编。例如把 Golden Girls 与 Martin Fowler、Linus Torvalds 一起拉进架构评审，让它们为某次变更请求争论起来。

记忆机制：派对记得住你

给派对开启记忆后，它能从中断处续上。派对维护自己跨会话的记录：成员间积累的动态、未合拢的线索、上次讨论得出什么结论，一周后再打开依然存在。上次冲突过的两个成员会以略冷的姿态开场，旧会话里那句尖锐的话会在合适时机自然被回捞。

关键区别：这是记忆，不是对话日志。派对不记录所有话，只带走值得记的几件，所以下次有"接着上次聊"的质感，却不会把整个历史拖进来。整个过程在后台自动进行：没有需要手动保存的东西，派对也不会打破角色去解释记忆机制。

party-memory.md 给出完整实现机制：

• 存放位置：每个派对一个 memlog 文件：{workflow.memory_dir}/<party>/.memlog.md，其中<party>是组 id（如code-review-crew），默认房间用installed。memory_dir默认为{output_folder}/party-mode/memories。
• 进场时读——蒸馏而非倾倒：日志是追加式且逐场增长的，不能把原文件塞进派对。做法是让一个阅读子 Agent 读 memlog 并返回一份紧凑简报（几百 token 的"当前局面"），再让简报从第一个节拍起就以角色身份塑造房间：冷淡的两人冷淡开场，联盟则暖场；回调在合适时机落地，是有机出现而非当场背诵。
• 何时写：值得记的节拍落定时写（改变房间温度的冲突、结成联盟、值得未来回调的台词、决定与结果）；另有"底线"——开场哪怕没什么戏剧性，在有两三轮真实交锋后也要记下话题与开场动态。写入全程静默，房间从不宣布"已记下"。
• 什么值得记：每条记忆的唯一标准是——"它会为未来某次会话着色、让某个回调落地，或让派对变得更好吗？"不满足就略过；永远是寥寥数条，绝不做回顾总结、绝不做逐字记录。
• 写入命令：uv run {project-root}/_bmad/scripts/memlog.py append --workspace {memory_dir}/{active} --type <dynamic|moment|callback|outcome> --text "<一行简记>"，属于某个角色时加--by <persona-code>；文件不存在时先init，存在则直接append（init在文件已存在时会报错）。写入失败时静默跳过，绝不让派对卡在失败的写入上。
• 遗忘：memlog 按设计只增不删，没有精细删除；要清空某派对记忆就删除其文件夹{memory_dir}/{active}/；要纠正错误记忆，就追加一条覆盖旧结论的新条目——房间读取最新状态。

即兴出现的角色也能被记住：开放阵容场景里客串的人物、对话中临时加入的人，都会被写进记忆条目（"<名字> 出现了……"）。会话结束时，派对会提议是否保留这些"新面孔"——接受后按 create-party.md 的流程把成员写进派对名单（经bmad-customize落盘），下次会话他们就能以常驻身份回归；在保存之前，他们只活在 memlog 里，由房间从中重新召唤。

记忆按派对配置：创建或保存派对时会询问是否开启记忆。默认安装 Agent 房间（无组名的"installed"房间）受 customize.toml 中party_memory = true控制——不主动关闭就一直记；命名组各自携带memory = true|false标志，省略时默认为false（即新命名的组默认不记）。这些均可通过/bmad-customize bmad-party-mode修改。这一"默认房间默认开启、命名组默认关闭"的取值在 resolve_party.py 中可验证：party_mode缺省取"session"、party_memory缺省取true，而group_detail()里memory_enabled直接取bool(g.get("memory", False))；test_resolve_party.py 的test_memory_enabled_follows_group_flag_and_defaults_off专门断言了这个行为。

会话收尾与"纪念品"

用户示意结束时（编排者"读懂房间"，不等魔法词），收尾流程包括：

1. 回放最佳结论；
2. 若记忆开启，给 memlog 做收尾补写（最终结果与尚未捕获的难忘节拍）——这是"补写"，因为记忆在会话中已是实时累积的；
3. 提供纪念品（keepsake）：一份自包含的 HTML 文档，按佩尔松纳组织整场会话（图标、名字、声音），是真正体面的纪念物，可用内联 SVG/轻量动效点睛——以{date}为文件名前缀写入{workflow.output_dir}/（默认{output_folder}/party-mode）。这不是把原始对话日志原样倾倒，而是按角色整理后的独立可分享文档。用户拒绝则派对照常结束。
4. 若记忆开启且有"新面孔"出现，按前述流程提议一次是否保存进派对名册（可拒绝，不阻塞收尾）；
5. 若配置了{workflow.on_complete}钩子则执行，随后回到普通模式。

源码速览与延伸阅读

Party Mode 的行为几乎全部可由仓库中的文件验证：

另外两点实现细节值得留意：

• 确定性合并：resolve_party.py的头部注释强调合并是确定性的键控并集——编排者消费的是"已解析的名单"，而不是每次会话重新推导。测试test_pure_custom_excluded_override_kept_in_default_room明确验证了"纯自定义成员在池中、但不在默认房间"这一关键不变量。
• code 冲突提示：自定义成员的code若与已安装 Agent 相同，会静默覆盖该 Agent。create-party.md 要求在写入前先跑一次resolve_party.py检查冲突并向用户确认（"一次检查，不是门禁"）。

最后，正如文档的结语：派特的价值在于意见分歧本身——汇聚一处的多样视角，能抓到单一视角必然漏掉的东西。

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