今天深入研究了 BMAD 源代码，发现了一些关于 Party Mode 如何编排多 Agent 对话的有趣细节。
源文件位置： src/core/workflows/party-mode/steps/step-02-discussion-orchestration.md
Agent 选择算法
BMAD 并非随机选择 Agent，而是有一套明确的选择逻辑：
1. 输入分析：
- 领域专业要求（技术、商业、创意）
- 复杂度和深度需求
- 对话上下文和之前 Agent 的贡献
- 用户指定的 Agent 提及或请求
2. 选择优先级：
- 主要 Agent：与核心话题最匹配的专家
- 次要 Agent：提供互补视角
- 第三 Agent：跨领域洞察或扮演反对派
3. 轮换规则：
- 如果用户指定 Agent → 优先该 Agent + 1-2 个互补 Agent
- 随时间轮换参与以确保讨论包容性
- 平衡专业领域以获得全面视角
Cross-Talk 模式（实现细节）
工作流明确定义了 Agent 之间的交互方式：
Cross-Talk 模式：
- 按名称引用："正如 [其他 Agent] 提到的..."
- 建立在观点之上："[其他 Agent] 关于...的观点很好"
- 礼貌地不同意："我看待这个问题与 [其他 Agent] 不同..."
- 追问："你会如何处理 [具体方面]？"
这不是涌现行为，而是被明确编程到编排层的。
角色一致性强制执行
每个 Agent 响应的生成都要遵循：
角色一致性：
- 应用合并数据中的精确沟通风格
- 在推理中反映原则和价值观
- 从身份和角色中汲取专业知识
- 保持独特的声音和个性特征
bmad-master.agent.yaml 定义了主编排者：
communication_style: "直接而全面，用第三人称称呼自己。专家级沟通专注于高效任务执行，使用编号列表系统化呈现信息，具备即时命令响应能力。"
问题处理协议
一个有趣的细节：当 Agent 向用户提出直接问题时：
- 在问题提出后立即结束响应轮
- 突出显示：**[Agent 名称] 询问：[他们的问题]**
- 显示：_[等待用户响应...]_
- 等待用户输入后再继续
这防止 Agent 臆造用户响应，保持对话基于实际交互。
为什么这很重要
大多数多 Agent 系统要么是：
- 完全自主的群体（混乱）
- 手动交接的单线程（缓慢）
BMAD Party Mode 处于中间：编排但自然。对话感觉有机，但每个 Agent 选择、cross-talk 和响应时机都由工作流定义明确控制。
关键洞察： Party Mode 的”自然”感觉不是涌现的 AI 行为。它是通过明确的编排规则精心设计的。
文件结构参考
src/core/workflows/party-mode/
├── steps/
│ ├── step-01-agent-loading.md
│ ├── step-02-discussion-orchestration.md
│ └── step-03-graceful-exit.md
└── workflow.md
每个步骤都有明确的：
- 强制执行规则
- 执行协议
- 上下文边界
- 成功指标
- 失败模式
这种显式定义确保了 Party Mode 的行为可预测且可调试，而不是依赖于 LLM 的”运气”。
深入探索 src/core/workflows/ 目录会发现更多值得研究的多 Agent 编排模式。