fischer
/
fischer-agentkit
1
0
Fork 0
Code Issues Pull Requests Actions 87 Packages Projects Releases Wiki Activity
fischer-agentkit/docs/brainstorms/2026-06-17-board-meeting-mo...

19 KiB
Raw Blame History

私董会讨论模式（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 配置项

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 进行详细实现规划。