# 私董会讨论模式(Board Meeting Mode)需求文档 **日期**: 2026-06-17 **状态**: Draft **范围**: Deep — feature **作者**: ce-brainstorm --- ## 1. 背景与动机 ### 1.1 当前专家团实现状态 Fischer AgentKit 现有专家团功能位于 `src/agentkit/experts/`,采用 **hub-and-spoke(中心辐射)模式**: - Lead Expert 分解任务 → Member Experts 并行执行子任务 → Lead 综合结果 - 子任务深度=1,**无 Agent 间通信**,`handoff_transport` 仅用于事件广播 - 协作模式单一:`MergeStrategy` 仅保留 `BEST`,移除了 VOTE/FUSION **关键缺口**: 1. **未集成到主聊天流程** — `src/agentkit/server/routes/chat.py:584-590` 中 `TEAM_COLLAB` 模式回退到 REACT,`emit_team_event()` 已定义但未被调用 2. **无预设专家模板** — 没有 `configs/experts/` 目录,`ExpertTemplateRegistry` 默认为空 3. **`team_dissolved` 事件未触发** — 前端有处理代码,后端不广播 4. **TeamStatus 缺 PLANNING** — 文档/前端有,后端枚举没有 ### 1.2 对标分析 | 维度 | Qoder | WorkBuddy | Legends MCP | colleague.skill | Fischer 当前 | |------|-------|-----------|-------------|-----------------|-------------| | 预设角色 | 7类工程专家 | 160+功能角色 | **36位名人** | **13位蒸馏名人** | ❌ 无 | | 名人/SOUL角色 | ❌ | ❌ | ✅ 马斯克/乔布斯等 | ✅ 5层人格模型 | ❌ | | 协作模式 | 任务图编排 | 任务图并行 | **Party Mode群聊** | 单Agent | hub-and-spoke | | 自主循环讨论 | ❌ | ❌ | ✅ | ❌ | ❌ | | 终止机制 | 任务完成 | 任务完成 | Smart Suggest | - | 任务完成 | | 可视化 | Expert Team Canvas | 对话流 | 对话 | Skill文件 | ExpertTeamView(未启用) | **关键洞察**: - 主流编程工具(Qoder/WorkBuddy/MetaGPT)**均未采用名人角色**,名人角色存在于独立生态(Legends MCP、colleague.skill) - Fischer 若做"名人蒸馏 + 自主循环讨论",是**差异化机会** - 可参考:AgentVerse 通信框架 + colleague.skill 5层人格模型 + ARMOR-MAD 协议阈值终止 ### 1.3 动机 用户希望除了"自动创建子 agent 处理复杂任务"外,还能创建**预设固定的名人专家团**(如私董会:马斯克、贝佐斯、张小龙),针对主题进行**自主循环讨论**,各专家发表意见、碰撞观点,直到得出结果或用户干预。整个过程**像群聊一样**呈现。 --- ## 2. 目标与非目标 ### 2.1 目标 1. **新增私董会讨论模式** — 与现有 hub-and-spoke 任务分解模式并列,通过 `@board` 前缀触发 2. **预设名人专家库** — 内置 5-8 位名人专家(YAML 定义 persona/thinking_style/speaking_style) 3. **自主循环讨论** — 每轮全员发言(并行生成)+ 主持人小结,达到最大轮次后主持人给出最终决策建议 4. **群聊式体验** — 前端以群聊形式展示讨论过程,专家消息带头像/颜色/角色标识 5. **用户随时干预** — 用户可在任意轮次插入消息影响讨论方向 6. **主聊天流程集成** — 在 `chat.py` 中接入 `BoardRouter`,不再回退到 REACT ### 2.2 非目标 1. **不集成外部蒸馏工具**(colleague.skill/nuwa-skill)—— 未来可扩展,本期仅 YAML 定义 2. **不实现 LLM 自动蒸馏** —— 本期仅人工编写 YAML 3. **不实现共识检测自动终止** —— 仅最大轮次 + 用户干预 4. **不改动现有 hub-and-spoke 模式** —— `@team` 保持不变 5. **不做技术评审/创意脑暴场景** —— 本期聚焦决策类私董会 6. **不做 Expert Team Canvas 式可视化** —— 复用现有群聊 UI,仅增强专家消息展示 7. **不实现专家间直接通信** —— 专家发言基于共享讨论历史,不直接对话 --- ## 3. 用户故事 ### 3.1 主流程:发起私董会 > 作为产品负责人,我希望就一个决策类问题(如"是否该做 X 功能")召集名人专家团讨论,获得多视角建议,以便做出更明智的决策。 **触发**:用户输入 `@board:elon_musk,jeff_bezos,allenzhang 是否该做私董会功能?` **期望**: - 系统识别 `@board` 前缀,加载指定名人专家 - 主持人(默认首位或系统指定)开场介绍议题 - 马斯克从第一性原理视角发言 - 贝佐斯从 Day 1/客户至上视角发言 - 张小龙从用户体验视角发言 - 主持人小结本轮要点 - 进入下一轮,专家基于前序讨论继续 - 达到最大轮次(默认 5 轮)后,主持人给出最终决策建议 - 全过程以群聊形式展示,用户可随时插入消息 ### 3.2 干预流程:用户介入讨论 > 作为用户,我希望在讨论过程中随时插入观点或追问,影响讨论方向。 **触发**:讨论进行中,用户输入 `我觉得成本不是主要问题,关键是用户接受度` **期望**: - 系统将用户消息广播给所有专家 - 下一轮发言时,专家会参考用户观点调整发言方向 - 主持人小结时提及用户观点 ### 3.3 配置流程:使用预设专家团 > 作为用户,我希望直接使用预设的"私董会专家团"模板,无需每次指定专家名。 **触发**:用户输入 `@board:private_board 是否该做 X 功能?` 或 `@board 是否该做 X 功能?`(使用默认私董会模板) **期望**: - 系统识别 `private_board` 模板,加载预设的 3-5 位名人专家 - 后续流程与主流程一致 ### 3.4 扩展流程:自定义专家 > 作为高级用户,我希望创建自己的名人专家 YAML 文件,扩展专家库。 **触发**:用户在 `configs/experts/` 目录下创建 `linus.yaml` **期望**: - 系统启动时自动加载 `configs/experts/*.yaml` - 用户可通过 `@board:linus 讨论主题` 调用自定义专家 --- ## 4. 功能需求 ### 4.1 路由与触发 **FR-1: `@board` 前缀路由** - 支持两种格式: - `@board:expert1,expert2 讨论主题` — 指定专家 - `@board 讨论主题` — 使用默认私董会模板(`private_board`) - 专家名验证:`^[a-zA-Z0-9_-]{1,64}$`,最多 10 位专家 - 至少 1 位专家,否则提示选择 - 未识别的专家名:提示可用专家列表 - 路由结果包含:专家配置列表、讨论主题、是否使用默认模板 **FR-2: 与现有路由共存** - `@board` 与 `@team` 互不干扰 - `@board` 优先级高于普通聊天,低于系统命令 - 在 `RequestPreprocessor` 或等效位置集成 `BoardRouter` ### 4.2 专家配置 **FR-3: 预设名人专家库** - 新增 `configs/experts/` 目录 - 内置 5-8 位名人专家 YAML: - `elon_musk.yaml` — 第一性原理、物理思维、激进创新 - `jeff_bezos.yaml` — Day 1 思维、客户至上、长期主义 - `allenzhang.yaml` — 用户体验、极简主义、社交产品直觉 - `charlie_munger.yaml` — 心智模型、跨学科思维、逆向思考 - `paul_graham.yaml` — 创业、做用户想要的东西、反从众 - `steve_jobs.yaml` — 产品设计、现实扭曲力场、专注 - `warren_buffett.yaml` — 价值投资、能力圈、复利思维 - `ray_dalio.yaml` — 原则驱动决策、极度透明、 believability-weighted - 每个 YAML 包含:`name`、`persona`、`thinking_style`、`speaking_style`、`avatar`、`color`、`bound_skills`(可选) **FR-4: `ExpertConfig` 扩展** - 新增 `speaking_style: str` 字段 — 描述表达风格(如"直接、用比喻、偶尔尖锐") - 新增 `decision_framework: str` 字段(可选)— 描述决策框架(如"第一性原理"、"Day 1") - 字段需有默认值,向后兼容现有 `@team` 模式 **FR-5: 默认私董会模板** - 内置 `private_board` 模板,包含 3-5 位默认名人专家 - 模板可被用户 YAML 覆盖 ### 4.3 讨论引擎 **FR-6: `BoardTeam` 容器** - 复用 `Expert`、`AgentPool`、`HandoffTransport`、`SharedWorkspace` - 新增 `BoardStatus` 枚举:`FORMING` → `DISCUSSING` → `CONCLUDING` → `COMPLETED` → `DISSOLVED` - 持有:专家列表、主持人名、讨论主题、讨论历史(所有发言)、当前轮次、最大轮次 - 主持人默认为首位专家,可通过配置指定 **FR-7: `BoardOrchestrator` 讨论引擎** - **开场阶段**:主持人介绍议题、说明讨论规则 - **讨论阶段**(循环): - 每轮:所有非主持人专家**并行生成发言**(基于讨论历史 + 角色 prompt) - 每轮结束:主持人小结本轮要点、判断是否继续 - 发言生成需注入:角色 persona、thinking_style、speaking_style、完整讨论历史、当前轮次/最大轮次 - **总结阶段**:达到最大轮次后,主持人给出最终决策建议(含各方观点汇总、共识点、分歧点、建议行动) - **用户干预处理**:用户消息插入讨论历史,下一轮发言时专家可见 **FR-8: 讨论历史管理** - 讨论历史结构:`[{round, expert_name, content, timestamp}]` - 每轮发言后追加到历史 - 主持人小结也作为历史的一部分 - 用户干预消息标记为 `role: "user"`,与专家发言区分 - 历史过长时(超过 token 限制):主持人先压缩历史,再继续 **FR-9: 终止条件** - **正常终止**:达到最大轮次(默认 5,可配置 1-10) - **用户终止**:用户发送 `/stop` 或 `停止讨论` - **异常终止**:LLM 不可用或所有专家发言失败 → 主持人用已有历史总结 - 终止后广播 `board_concluded` 事件 ### 4.4 WebSocket 事件 **FR-10: 新增事件类型** | 事件 | 触发时机 | 数据 | |------|---------|------| | `board_started` | 讨论开始 | `{team_id, topic, experts: [{name, avatar, color, is_moderator}], max_rounds}` | | `expert_speech` | 专家发言完成 | `{expert_name, expert_avatar, expert_color, content, round}` | | `round_summary` | 主持人小结完成 | `{moderator_name, content, round, continue: bool}` | | `user_intervention` | 用户消息广播 | `{content, round}` | | `board_concluded` | 讨论结束 | `{summary, decision_advice, total_rounds, consensus_points, dissent_points}` | **FR-11: 事件广播** - 通过 `handoff_transport.send(team_channel, event)` 广播 - 在 `chat.py` 中通过 `emit_team_event()` 推送到 WebSocket - 事件类型加入 `_VALID_TEAM_EVENT_TYPES` ### 4.5 前端展示 **FR-12: 群聊式 UI** - 复用现有 `ExpertMessage.vue` 组件,增强展示: - 专家头像(emoji 或图片) - 专家名 + 角色标签(如"主持人"、"第一性原理视角") - 发言内容(支持 markdown) - 轮次标识(如"第 2 轮") - 主持人小结以特殊样式区分(如背景色、边框) - 用户干预消息以右侧气泡展示(区别于专家左侧) **FR-13: 讨论状态展示** - 顶部显示:讨论主题、当前轮次/最大轮次、参与专家列表 - 专家列表可点击查看其所有发言 - 讨论结束后展示总结卡片(决策建议、共识点、分歧点) **FR-14: 干预输入** - 讨论进行中,输入框保持可用 - 用户输入即作为干预消息广播 - 支持 `/stop` 命令终止讨论 ### 4.6 配置 **FR-15: `agentkit.yaml` 配置项** ```yaml board: max_rounds: 5 # 默认最大轮次 default_template: private_board # 默认私董会模板 parallel_speech: true # 是否并行生成发言 history_compression_threshold: 4000 # 历史 token 超过此值时压缩 ``` --- ## 5. 范围边界 ### 5.1 包含 - `BoardTeam`、`BoardOrchestrator`、`BoardRouter` 新模块 - `configs/experts/` 预设名人 YAML(5-8 位) - `ExpertConfig` 扩展(`speaking_style`、`decision_framework`) - WebSocket 事件(5 个新事件) - 前端群聊式展示增强 - 主聊天流程集成(`chat.py` 接入 `BoardRouter`) - 单元测试覆盖核心逻辑 ### 5.2 延后(Deferred for later) - 集成外部蒸馏工具(colleague.skill/nuwa-skill) - LLM 自动蒸馏生成名人 SOUL - 共识检测自动终止(置信度/投票) - 技术评审/创意脑暴场景 - Expert Team Canvas 式可视化 - 专家间直接通信(辩论模式) - 语音/视频输出 - 历史讨论回顾与检索 ### 5.3 不在本产品身份内(Outside this product's identity) - 实时名人数据更新(如抓取最新推文更新 persona) - 名人本人授权或验证 - 娱乐向角色扮演(非决策用途) --- ## 6. 依赖与假设 ### 6.1 依赖 - **现有基础设施**:`Expert`、`AgentPool`、`HandoffTransport`、`SharedWorkspace`、`ExpertTemplateRegistry` - **LLM Gateway**:`src/agentkit/llm/` 提供多 provider 支持 - **WebSocket**:`src/agentkit/server/routes/chat.py` 现有 WebSocket 通道 - **前端组件**:`ExpertMessage.vue`、`ExpertTeamView.vue`、`stores/team.ts` ### 6.2 假设 1. **YAML 足够体现名人思维** — 人工编写的 persona/thinking_style/speaking_style 能让 LLM 生成有差异化的发言,无需深度蒸馏 2. **并行发言可行** — 专家发言基于共享历史,无需严格顺序,可并行生成 3. **token 消耗可接受** — 5 轮 × 5 专家 = 25 次 LLM 调用,单次讨论成本在可接受范围 4. **现有 `Expert` 可复用** — `Expert` 包装器的 `send_message`、`team_context` 注入机制适用于讨论模式 5. **前端群聊 UI 可扩展** — `ExpertMessage.vue` 可通过 props 增强展示,无需重写 ### 6.3 风险 | 风险 | 影响 | 缓解 | |------|------|------| | 专家发言同质化 | 讨论质量低,失去多视角价值 | 强化角色 prompt 差异化,提供 `decision_framework` 字段 | | token 消耗过高 | 成本问题 | 提供轮次配置,历史压缩机制 | | 讨论发散无结论 | 用户体验差 | 主持人每轮小结,最终强制总结 | | 名人 persona 不准确 | 发言不像本人 | YAML 可迭代优化,未来支持蒸馏 | | 与现有 `@team` 集成冲突 | 路由混乱 | 独立 `BoardRouter`,前缀明确区分 | --- ## 7. 成功标准 ### 7.1 功能完成标准 - [ ] `@board:elon_musk,jeff_bezos 讨论主题` 能触发私董会讨论 - [ ] `@board 讨论主题` 能使用默认模板 - [ ] 预设 5-8 位名人专家 YAML 可用 - [ ] 每轮专家并行发言,主持人小结 - [ ] 达到最大轮次后主持人给出最终决策建议 - [ ] 用户可随时插入消息影响讨论 - [ ] 用户可 `/stop` 终止讨论 - [ ] 前端以群聊形式展示讨论过程 - [ ] WebSocket 事件正确广播和接收 - [ ] 单元测试覆盖率 ≥ 80% ### 7.2 质量标准 - 专家发言有明确角色差异(第一性原理 vs Day 1 vs 用户体验) - 主持人小结能准确归纳本轮要点 - 最终决策建议包含各方观点汇总、共识点、分歧点 - 单次讨论 token 消耗可预测(提供配置项) ### 7.3 集成标准 - `@board` 与 `@team` 互不干扰 - 不破坏现有聊天流程 - 前端群聊 UI 兼容现有专家消息展示 --- ## 8. 开放问题 1. **主持人选择策略**:默认首位专家作为主持人,还是引入独立的" facilitator"角色(非名人,专职主持)? - **当前决策**:默认首位专家,可配置。未来可扩展独立 facilitator。 2. **专家发言顺序**:并行生成时,前端展示顺序如何确定? - **当前决策**:按专家列表顺序展示,即使并行生成也按配置顺序追加到 UI。 3. **讨论历史 token 管理**:5 轮 × 5 专家的历史可能超过上下文窗口,压缩策略如何? - **当前决策**:超过阈值时主持人先压缩历史(保留关键观点),再继续。具体阈值和压缩 prompt 在 planning 阶段细化。 4. **预设名人选择**:内置哪 5-8 位名人最合适? - **当前决策**:马斯克、贝佐斯、张小龙、芒格、Paul Graham、乔布斯、巴菲特、Ray Dalio。可在 planning 阶段调整。 5. **与现有 `TEAM_COLLAB` 集成**:是否需要同时修复 `@team` 在 `chat.py` 的集成缺口? - **当前决策**:本期聚焦 `@board`,`@team` 集成作为独立任务。但 `emit_team_event()` 的调用模式可复用。 --- ## 9. 建议的实现路径(供 ce-plan 参考) ### 9.1 模块结构 ``` src/agentkit/experts/ ├── __init__.py # 新增导出 ├── config.py # 扩展 ExpertConfig ├── expert.py # 复用 ├── team.py # 现有 hub-and-spoke(不动) ├── orchestrator.py # 现有(不动) ├── plan.py # 现有(不动) ├── registry.py # 复用 ├── router.py # 现有 @team(不动) ├── board.py # 新增:BoardTeam, BoardStatus ├── board_orchestrator.py # 新增:BoardOrchestrator └── board_router.py # 新增:BoardRouter, @board 前缀 configs/experts/ # 新增目录 ├── elon_musk.yaml ├── jeff_bezos.yaml ├── allenzhang.yaml ├── charlie_munger.yaml ├── paul_graham.yaml ├── steve_jobs.yaml ├── warren_buffett.yaml └── ray_dalio.yaml ``` ### 9.2 关键集成点 - `src/agentkit/server/routes/chat.py` — 接入 `BoardRouter`,调用 `emit_team_event()` - `src/agentkit/server/app.py` — 启动时加载 `configs/experts/*.yaml` 到 `ExpertTemplateRegistry` - `src/agentkit/server/frontend/src/api/types.ts` — 新增 WebSocket 事件类型 - `src/agentkit/server/frontend/src/stores/chat.ts` — 新增事件处理 - `src/agentkit/server/frontend/src/components/chat/ExpertMessage.vue` — 增强展示 ### 9.3 测试策略 - `tests/unit/experts/test_board.py` — BoardTeam 测试 - `tests/unit/experts/test_board_orchestrator.py` — 讨论流程测试 - `tests/unit/experts/test_board_router.py` — 路由测试 - `tests/unit/experts/test_config.py` — 新字段测试 - Mock LLM Gateway 进行集成测试 --- ## 10. 对标差距总结 ### 10.1 Fischer 当前 vs Qoder/WorkBuddy | 维度 | Fischer 当前 | Qoder/WorkBuddy | 差距 | |------|-------------|-----------------|------| | 主聊天集成 | ❌ 未集成 | ✅ 完整集成 | **关键差距** | | 预设专家 | ❌ 无 | ✅ 7-160+ | **关键差距** | | 可视化 | 未启用 | Expert Team Canvas | 中等差距 | | 协作模式 | hub-and-spoke | 任务图编排 | 模式不同,非差距 | | 失败处理 | 三层 fallback | 高风险确认 | Fischer 更轻量 | ### 10.2 Fischer 私董会模式 vs Legends MCP/colleague.skill | 维度 | Fischer 私董会(规划) | Legends MCP/colleague.skill | 优势 | |------|----------------------|----------------------------|------| | 名人角色 | 5-8 位 YAML | 13-36 位蒸馏 | 精度较低,但可扩展 | | 讨论模式 | 全员发言+主持人小结 | Party Mode | Fischer 更结构化 | | 终止机制 | 最大轮次+主持人总结 | Smart Suggest | Fischer 更可控 | | 集成度 | 深度集成到 AgentKit | 独立工具 | Fischer 更一体化 | | 可扩展 | YAML + 未来蒸馏 | 蒸馏工具 | Fischer 更开放 | ### 10.3 优劣势总结 **Fischer 私董会模式的优势**: 1. **结构化讨论** — 主持人小结机制,避免发散 2. **可控终止** — 最大轮次 + 用户干预,成本可预测 3. **深度集成** — 与 AgentKit 生态无缝衔接 4. **可扩展** — YAML 定义 + 未来蒸馏工具集成 **劣势**: 1. **名人精度** — YAML 人工编写,不如蒸馏精确 2. **无共识检测** — 仅轮次终止,可能未达共识就结束 3. **无专家间直接通信** — 辩论深度有限 4. **前置依赖** — 需先完成主聊天流程集成 --- **下一步**: 交由 `/ce-plan` 进行详细实现规划。