fischer
/
fischer-agentkit
1
0
Fork 0
Code Issues Pull Requests Actions 87 Packages Projects Releases Wiki Activity
fischer-agentkit/docs/brainstorms/2026-06-14-expert-team-mode...

13 KiB
Raw Blame History

date topic
2026-06-14 expert-team-mode

Summary

在对话框中引入专家团模式（Expert Team Mode），支持用户手动指定或系统自动组建多专家协作团队。底层采用 Plan-Execute 协作模式（结构化协作计划 + 去中心化执行），前端以多角色对话流呈现协作过程。Expert 是比 Skill 更高的角色抽象，聚合多个 Skill 并包含人格、思维方式和协作策略。

Problem Frame

当前 AgentKit 的多 Agent 协作依赖 Orchestrator-Worker 的集中式编排或 Pipeline 的 DAG 流程驱动。这两种模式适合结构化、可预测的工作流，但无法支撑需要多专家自主协作、实时讨论、动态调整的复杂任务场景。用户在对话框中面对复杂任务时，只能与单个 Agent 交互，无法获得多视角、多专长的协作产出。类似 Qoder 的专家团模式填补了这一空白——让多个专家以目标为导向，自主分析、分工、执行、验证、汇报。

Key Decisions

  • Plan-Execute 而非纯 Swarm：结构化协作计划保证任务收敛和可预测性，Expert 在职责范围内自主协作（去中心化），但整体框架由计划约束。纯 Swarm 模式自由度最高但收敛风险大。

  • Expert 聚合 Skill：Expert 是比 Skill 更高的角色抽象。一个 Expert 聚合多个 Skill，并包含人格设定、思维方式、协作策略。Skill 是能力单元，Expert 是角色单元。

  • 混合 Agent 生成：核心角色从预定义专家模板库选择（保证质量），辅助角色由 LLM 根据任务现场动态生成（保持灵活性）。

  • 前端对话流展示：协作过程以多角色对话流呈现给用户，每个 Expert 有独立头像和颜色标识。底层是结构化计划驱动，前端是对话式体验。

  • 两种并行模式统一支持：子任务级并行（各做各的，结果汇总）和竞标式并行（同一任务多人做，取最优/融合）都在协作计划中标注，执行引擎按类型处理。

Actors

  • A1. 用户 — 发起任务、指定专家团成员、干预协作过程（调整分工、增减 Expert、修改方向）
  • A2. Lead Expert — 首个加入团队的 Expert 或用户指定的负责人，负责初始任务分解、协作计划生成、最终结果汇总
  • A3. Expert — 具有特定专长的角色，在职责范围内自主工作，可与其他 Expert 直接交互和交接
  • A4. ExpertTeam — 专家团容器，管理 Expert 的加入/退出、共享上下文、协作计划的生命周期
  • A5. ExpertTemplate Registry — 专家模板注册中心，存储预定义的 Expert 模板供选择和组装

Requirements

Expert 定义与管理

  • R1. Expert 配置包含：名称、人格描述、思维方式、绑定的 Skill 列表、协作策略偏好、头像/颜色标识
  • R2. Expert 可聚合一个或多个已注册 Skill，执行时按 SkillConfig 驱动
  • R3. ExpertTemplate 是可复用的 Expert 预设，存储在 YAML 配置或注册中心中，包含完整的 Expert 配置
  • R4. ExpertTemplate Registry 支持模板的注册、查询、列表展示
  • R5. 临时 Expert 由 LLM 根据任务分析动态生成 ExpertConfig，包含角色名称、职责描述、建议绑定的 Skill

专家团组建

  • R6. 用户可通过对话框手动指定专家团成员（选择 ExpertTemplate 或指定角色描述）
  • R7. Lead Expert 在接收任务后评估复杂度，建议升级为专家团模式（需用户确认，不自动强制升级）
  • R8. 自动组建时，Lead Expert 分析任务后生成协作计划，计划中包含需要的 Expert 角色定义
  • R9. 自动组建采用混合模式：核心角色从模板库匹配，辅助角色动态生成
  • R10. 专家团组建后，所有 Expert 的角色信息对用户可见

协作计划

  • R11. CollaborationPlan 定义专家团的结构化协作蓝图，包含：任务分解、角色分工、依赖关系、并行节点、合并策略
  • R12. 协作计划中的每个节点标注执行类型：串行、子任务级并行、竞标式并行
  • R13. 竞标式并行节点需指定评判策略：取最优、投票、融合
  • R14. 协作计划可由 Lead Expert 或用户动态修改；普通 Expert 可提议修改，需 Lead Expert 审批后生效
  • R15. 计划修改后，受影响的 Expert 立即感知变更并调整行为

去中心化协作

  • R16. Expert 之间可直接交互、请求协助、交接任务，无需经过 Lead Expert 中转
  • R17. Expert 间的交互通过共享对话流进行，所有消息对团队内所有 Expert 可见；上下文管理采用摘要共享策略（长内容自动摘要后广播，原始内容存入 SharedWorkspace 按需获取）
  • R18. Lead Expert 负责初始分解和最终汇总，但不控制中间流程
  • R19. Expert 通过共享上下文中的角色描述了解其他 Expert 的专长，可据此发起协作请求

并行执行与结果合并

  • R20. 子任务级并行：多个 Expert 同时执行不同子任务，结果由 Lead Expert 或指定 Expert 汇总
  • R21. 竞标式并行：多个同类型 Expert 独立完成同一子任务，结果按评判策略处理
  • R22. 评判策略"取最优"：由 Lead Expert 或指定评审 Expert 选择最佳结果
  • R23. 评判策略"投票"：所有 Expert 投票选择最佳结果，平局时由 Lead Expert 仲裁
  • R24. 评判策略"融合"：由 Lead Expert 或指定 Expert 将多个结果融合为统一产出

用户干预

  • R25. 用户可随时在对话流中插入指令，指令对全体 Expert 可见
  • R26. 用户可调整专家团分工（修改协作计划）
  • R27. 用户可增减 Expert（添加新 Expert 或移除已有 Expert）
  • R28. 用户可修改任务方向或补充需求，Lead Expert 据此重新规划

前端展示

  • R29. 协作过程以多角色对话流形式呈现，每个 Expert 的消息带有独立头像和颜色标识
  • R30. 协作计划以可视化方式展示（分工图/时间线），用户可展开查看详情
  • R31. 并行执行时，多个 Expert 的消息流通过消息标签（expert_id）复用同一 WebSocket 通道同时更新，用户可按 Expert 切换关注焦点
  • R32. Expert 间的交接、请求协助等交互以特殊消息类型展示（区别于普通对话）

触发与路由

  • R33. Lead Expert 在接收任务后评估复杂度，建议升级为专家团模式（与 R7 一致）
  • R34. 用户可通过 @team 或类似指令主动触发专家团模式
  • R35. 用户指定专家团成员时，跳过自动分析，直接进入协作计划生成
  • R36. 专家团任务完成后，团队自动解散，临时 Expert 被回收；临时 Expert 的产出保留在 SharedWorkspace 中不随实例销毁丢失

Key Decisions (Updated)

  • Expert 与 Agent 的关系：Expert 是 Agent 的配置层（ExpertConfig），运行时通过 AgentPool 创建对应的 ConfigDrivenAgent 实例。Expert 本身不是 Agent 实例，而是角色定义 + Skill 聚合 + 协作策略的配置单元。

Key Flows

  • F1. 手动组建专家团

    • Trigger: 用户在对话框中指定专家团成员
    • Actors: A1, A4, A2
    • Steps: 用户指定 ExpertTemplate 或角色描述 → ExpertTeam 创建 → Lead Expert 生成 CollaborationPlan → 计划展示给用户确认 → Expert 按计划开始协作
    • Covered by: R6, R10, R11, R35

  • F2. 自动组建专家团

    • Trigger: 系统检测到高复杂度任务或用户请求专家团
    • Actors: A1, A4, A2, A5
    • Steps: Lead Expert 分析任务 → 识别需要的 Expert 角色 → 核心角色从模板库匹配、辅助角色动态生成 → 生成 CollaborationPlan → 计划展示给用户确认 → Expert 按计划开始协作
    • Covered by: R7, R8, R9, R11

  • F3. 去中心化协作执行

    • Trigger: CollaborationPlan 确认后开始执行
    • Actors: A2, A3, A4
    • Steps: Expert 按计划执行各自任务 → Expert 间可直接交互和交接 → 并行节点同时执行 → 结果按合并策略处理 → Lead Expert 汇总最终产出
    • Covered by: R16, R17, R18, R20, R21

  • F4. 用户干预协作

    • Trigger: 用户在对话流中插入指令
    • Actors: A1, A4, A2
    • Steps: 用户发出指令 → 指令对全体 Expert 可见 → Lead Expert 评估影响 → 修改 CollaborationPlan（如需要） → 受影响 Expert 调整行为
    • Covered by: R25, R26, R27, R28

  • F5. 竞标式并行执行

    • Trigger: CollaborationPlan 中某节点标注为竞标式并行
    • Actors: A3, A2
    • Steps: 多个同类型 Expert 独立完成同一子任务 → 各自提交结果 → 按评判策略处理（取最优/投票/融合） → 产出最终结果
    • Covered by: R21, R22, R23, R24

  • F6. 专家团解散

    • Trigger: 任务完成或用户主动解散
    • Actors: A4, A1
    • Steps: Lead Expert 汇总最终结果 → 结果呈现给用户 → 临时 Expert 被回收 → ExpertTeam 销毁 → 模板 Expert 保留在注册中心
    • Covered by: R36

Acceptance Examples

  • AE1. 手动组建 + 子任务并行

    • Covers R6, R20. Given 用户输入"帮我分析这份市场报告，叫上数据分析师和战略顾问", When 系统创建 ExpertTeam 并生成计划, Then 数据分析师和战略顾问各自独立分析，Lead Expert 汇总两份分析为统一报告

  • AE2. 自动组建 + 竞标并行

    • Covers R7, R21, R22. Given 用户输入一个复杂的技术方案评审任务, When 系统自动升级为专家团模式, Then Lead Expert 生成 3 个架构师 Expert 竞标式并行出方案，Lead Expert 选择最优方案

  • AE3. 用户干预调整方向

    • Covers R25, R26, R28. Given 专家团正在执行任务, When 用户在对话流中说"重点看成本优化，别管性能了", Then Lead Expert 修改计划，受影响 Expert 调整分析方向

  • AE4. Expert 间直接协作

    • Covers R16, R17. Given 数据分析师 Expert 需要行业数据, When 数据分析师直接请求行业研究员 Expert 协助, Then 行业研究员提供数据，无需 Lead Expert 中转

  • AE5. 动态增减 Expert

    • Covers R27. Given 专家团正在执行, When 用户说"再加一个法律顾问", Then 系统从模板库匹配或动态生成法律顾问 Expert，加入团队并更新计划

Success Criteria

  • 专家团能在 5 分钟内完成一个需要 3+ 专家协作的中等复杂度任务
  • 用户能清晰追踪每个 Expert 的工作状态和产出
  • 用户干预后，Expert 在 1 轮交互内感知并响应变更
  • 临时 Expert 在任务完成后被完全回收，不残留资源

Scope Boundaries

Deferred for later:

  • Expert 间的学习与进化机制（经验共享、能力提升）
  • 跨会话的 Expert 持久化和记忆共享
  • Expert 市场和共享模板库
  • 专家团的 A/B 测试和效果评估

Outside this product's identity:

  • 通用的工作流引擎（已有 PipelineEngine）
  • 人工审核节点（已有 Workflow approval）
  • 实时音视频协作

Dependencies / Assumptions

  • 依赖现有 AgentPool 管理 Agent 实例的创建和销毁
  • 依赖现有 MessageBus 支持 Expert 间的消息通信
  • 依赖现有 HandoffManager 支持 Expert 间的任务交接（需扩展为进程内模式）
  • 依赖现有 Orchestrator 的任务分解能力（GoalPlanner + LLM 分解）
  • 依赖现有 PipelineEngine 的并行执行和拓扑排序
  • 假设 LLM 能生成质量合格的 CollaborationPlan（含角色定义、依赖关系、并行标注）
  • 假设前端 WebSocket 能支持多路并发消息流

Outstanding Questions

Resolve Before Planning:

  • 协作计划的粒度：定义大阶段和角色分工（粗粒度，灵活调整）还是精确到每步操作（细粒度，强约束）
  • 协作计划失败时的降级策略：回退到单 Agent 还是重试
  • HandoffManager 进程内模式的实现策略：扩展现有 HandoffManager 还是新建 InProcessHandoff

Deferred to Planning:

  • ExpertTemplate 的 YAML Schema 设计
  • 协作计划的可视化组件选型
  • 并行消息流的前端渲染策略
  • 竞标式并行执行引擎的扩展设计（当前 PipelineEngine 仅支持拓扑排序并行）

Sources / Research

  • src/agentkit/core/orchestrator.py — Orchestrator-Worker 编排模式，三级任务分解降级
  • src/agentkit/orchestrator/pipeline_engine.py — DAG 拓扑并行执行、Saga 补偿、对抗闭环
  • src/agentkit/orchestrator/handoff.py — Redis Pub/Sub 点对点任务转交
  • src/agentkit/orchestrator/dynamic_pipeline.py — 条件/嵌套/循环动态 Pipeline
  • src/agentkit/core/agent_pool.py — 运行时 Agent 实例管理
  • src/agentkit/core/shared_workspace.py — Redis 共享状态 + 分布式锁
  • src/agentkit/chat/skill_routing.py — CostAwareRouter 三层路由
  • src/agentkit/skills/base.py — SkillConfig 定义，ExpertConfig 可参考扩展