441 lines
24 KiB
Markdown
441 lines
24 KiB
Markdown
---
|
||
title: "Fischer AgentKit 专家团演进路线图 v2 — 竞品差距分析与下一步方向"
|
||
type: strategy
|
||
status: active
|
||
created: 2026-06-17
|
||
updated: 2026-06-17
|
||
origin: 竞品深度调研 + 代码库全量扫描
|
||
version: 2
|
||
---
|
||
|
||
# Fischer AgentKit 专家团演进路线图 v2
|
||
|
||
## Summary
|
||
|
||
Fischer AgentKit 定位为**通用 Agent 平台**，以 `@board`（群聊决策讨论）和 `@team`（流水线任务交付）构成双模式协作体系。基于对 10 个竞品的深度调研和代码库全量扫描，识别出当前核心问题是 `@team` 代码完整但完全未集成（死代码），且 `CollaborationPlan` 已被移除导致无法支持流水线编排。
|
||
|
||
v2 路线图相比 v1 的关键调整：专家模板从"50+"收缩为"少而精 5-8 个编程专家"（对标 Qoder/Cursor/Claude Code），隔离机制从"git worktree + 沙盒"降级为"上下文隔离"（对标 Trae Solo/Claude Code Subagent），编排模式从"hub-and-spoke"升级为"流水线模式"（对标 Qoder Team Lead + 阶段依赖）。新增 R0 修复死代码和前后端不一致。
|
||
|
||
`@board`（群聊决策讨论，保留名人专家）是唯一无竞品的能力，应保持和放大；`@team`（流水线任务交付，新增编程专家）是对标 Qoder 的核心补齐方向。两者构成"决策→执行"的完整闭环。
|
||
|
||
---
|
||
|
||
## Problem Frame
|
||
|
||
### 当前状态（代码库全量扫描结果）
|
||
|
||
Fischer AgentKit 专家团系统存在严重的"代码完整但未集成"问题：
|
||
|
||
| 模式 | 容器 | 编排器 | 路由器 | WebSocket 集成 | 实际状态 |
|
||
|------|------|--------|--------|---------------|----------|
|
||
| 群聊讨论 | `BoardTeam` | `BoardOrchestrator` | `BoardRouter` (`@board`) | ✅ 已集成 | 可用 |
|
||
| 任务分解 | `ExpertTeam` | `TeamOrchestrator` | `ExpertTeamRouter` (`@team`) | ❌ 未集成 | **死代码** |
|
||
|
||
**核心问题清单**：
|
||
|
||
1. **`TeamOrchestrator` 从未被实例化** — `grep` 在 `src/agentkit/server` 中搜索 `TeamOrchestrator(` 返回零匹配，整个代码库中仅在 `__init__.py` 导出但无调用方
|
||
2. **`CollaborationPlan` 已被移除** — 替换为简化的 `TeamPlan`（仅 `subtasks` 列表，无阶段依赖图），VOTE/FUSION 合并策略已删除仅保留 BEST
|
||
3. **前后端数据模型不一致** — 前端 `team.ts` 仍用 `plan_phases` 概念，后端 `TeamPlan` 已改为 `subtasks`，一旦集成 `@team` 会立即暴露
|
||
4. **集成测试已损坏** — `tests/integration/test_expert_team.py` 导入已移除的 `CollaborationPlan, ParallelType, PhaseStatus, PlanPhase`，会 ImportError
|
||
5. **多模型路由未消费** — `ExpertConfig.llm` 字段存在但两个 Orchestrator 均硬编码 `model="default"`
|
||
6. **AGENTS.md 文档过时** — 描述的"CostAwareRouter 三层路由"、"serial/parallel/competitive + merge"已与实际简化后的代码不符
|
||
|
||
### 竞品差距矩阵（10 个竞品深度调研）
|
||
|
||
| 能力维度 | Fischer AgentKit | Qoder | WorkBuddy | Trae Solo | Cursor 2.0 | Devin | Claude Code | Codex | 差距大小 |
|
||
|----------|-----------------|-------|-----------|-----------|------------|-------|-------------|-------|---------|
|
||
| 群聊讨论 | ✅ `@board` 独有 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | **领先** |
|
||
| 任务分解执行 | ⚠️ 死代码 | ✅ 流水线 | ✅ 多窗口 | ✅ 主子 | ✅ 8并行 | ✅ 舰队 | ✅ 委派 | ✅ 沙箱 | **大** |
|
||
| 编排模式 | hub-and-spoke(未集成) | 流水线 | 多窗口并行 | 主子协同 | 纯并行 | 递归管理 | 委派+并行 | 计划→沙箱 | **大** |
|
||
| 隔离机制 | ❌ 零实现 | 多Workspace | 沙箱 | 上下文隔离 | git worktree | 独立VM | 上下文+worktree | 沙箱 | **大** |
|
||
| 专家模板数 | 9(名人) | 5类(编程) | 100+(办公) | 用户自定义 | 8并行 | 无上限 | 5内置+自定义 | 6角色插件 | **需定位** |
|
||
| 多模型路由 | 配置存在未消费 | 4模式 | 多模型 | 按需选择 | 按阶段 | 单一 | 单一 | GPT-5.5 | **中** |
|
||
| 仓库级理解 | ❌ | 10万+文件 | — | ✅ | ✅ | ✅ Wiki | ✅ | ✅ | **大** |
|
||
| 自进化系统 | ✅ 遗传+AB | ✅ Expert+Team Skill | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | **缩小** |
|
||
| 记忆系统 | ✅ 4层+pgvector | ✅ 记忆感知 | — | ✅ 智能压缩 | — | ✅ Wiki | ✅ Session | ✅ Memory | **缩小** |
|
||
| MCP 支持 | ✅ 完整 | ❌ | ✅ | — | ✅ | — | ✅ 标准 | ✅ | **持平** |
|
||
| IDE 集成 | Web+Tauri | IDE+JetBrains+VS Code | 桌面 | IDE | VS Code fork | Web+Desktop | CLI+VS Code | Web+CLI+IDE | **中** |
|
||
|
||
### 三个独特优势（应保持和放大）
|
||
|
||
1. **私董会群聊讨论** — 10 个竞品中唯一支持多专家群聊式决策讨论的能力。`@board` 前缀触发，多轮自主循环，主持人小结，用户可干预。无任何竞品实现此模式。
|
||
2. **自进化系统（但优势在缩小）** — 遗传算法优化 prompt + A/B 测试 + 坑点检测 + 路径优化。Qoder 已跟进 Expert Skill + Team Skill 双向进化，需重新定位差异化（见 R4）。
|
||
3. **4 层记忆系统（但优势在缩小）** — SOUL/USER/MEMORY/DAILY + pgvector 情节记忆 + 语义检索。竞品（Qoder 记忆感知、Claude Session Memory、Codex Memory）正在跟进，需深化场景化记忆。
|
||
|
||
### 三个关键差距（需优先补齐）
|
||
|
||
1. **`@team` 死代码 + 编排模式不足** — 代码完整但从未调用，且现有 hub-and-spoke 不支持流水线编排。是投入产出比最高的改进。
|
||
2. **无隔离机制** — 缺乏任何形式的隔离（worktree/容器/上下文），多 Agent 并行会互相干扰。选择上下文隔离作为最轻量方案。
|
||
3. **编程专家模板缺失** — 当前 9 个均为名人专家（用于 @board），无编程领域专家（用于 @team 流水线）。
|
||
|
||
### 行业趋势（影响演进方向）
|
||
|
||
1. **从 Agentic Coding 到 Agentic Engineering** — 行业从"AI 帮你写代码"转向"AI 帮你交付软件"，Qoder 1.0、Devin、Trae SOLO 都体现这一范式切换
|
||
2. **Human on the Loop 成共识** — 从 Human in the Loop（人在循环中）转向 Human on the Loop（人在循环上）— 人负责定义、驾驭、判断，Agent 负责执行
|
||
3. **MCP 成事实标准** — Anthropic 的 Model Context Protocol 获得 OpenAI、Google、Meta 联合支持，Fischer 已支持，不再是差异化优势
|
||
4. **记忆与进化能力成标配** — 竞品普遍跟进，Fischer 需从"有"升级为"深"
|
||
|
||
---
|
||
|
||
## Requirements
|
||
|
||
### R0: 修复死代码与前后端不一致
|
||
|
||
**目标**：在集成 `@team` 之前，修复代码库中已存在的死代码、损坏测试和前后端不一致问题，确保集成工作建立在干净的基线上。
|
||
|
||
**需求**：
|
||
- 修复 `tests/integration/test_expert_team.py` 中对已移除类的导入（`CollaborationPlan, ParallelType, PhaseStatus, PlanPhase`）
|
||
- 统一前后端数据模型：前端 `team.ts` 和 `ExpertTeamView.vue` 从 `plan_phases` 迁移到 `subtasks`（或后端恢复阶段概念，取决于 R1 决策）
|
||
- 更新 `AGENTS.md` 中过时的描述：CostAwareRouter 三层路由 → RequestPreprocessor、serial/parallel/competitive → hub-and-spoke
|
||
- 清理 `TeamOrchestrator` 的死代码状态：要么集成（R1），要么标记为实验性
|
||
|
||
**验收标准**：
|
||
- `pytest tests/integration/test_expert_team.py` 不再 ImportError
|
||
- 前后端数据模型一致
|
||
- `AGENTS.md` 与代码实际状态一致
|
||
|
||
**关联文件**：
|
||
- `tests/integration/test_expert_team.py` — 修复导入
|
||
- `src/agentkit/server/frontend/src/stores/team.ts` — 数据模型迁移
|
||
- `src/agentkit/server/frontend/src/components/chat/ExpertTeamView.vue` — 数据模型迁移
|
||
- `AGENTS.md` — 文档更新
|
||
|
||
---
|
||
|
||
### R1: `@team` 流水线模式集成到 WebSocket
|
||
|
||
**目标**：将 `ExpertTeamRouter` + 重新实现的流水线 `TeamOrchestrator` + `ExpertTeam` 集成到 `chat.py` WebSocket 流程，支持阶段依赖的串行/并行混合编排，对标 Qoder 的 Team Lead + 流水线协作。
|
||
|
||
**需求**：
|
||
|
||
**R1.1 流水线编排引擎**：
|
||
- 恢复阶段依赖图（`CollaborationPlan` 或等效设计），支持：
|
||
- 串行阶段：规划 → 前端 → 后端 → QA → 评审（有依赖关系）
|
||
- 并行阶段：同一阶段内无依赖的子任务并行执行
|
||
- 阶段间数据传递：前一阶段输出作为后一阶段输入
|
||
- Lead Expert 负责任务分解和阶段规划
|
||
- 保留 BEST 合并策略用于并行子任务结果汇总
|
||
|
||
**R1.2 上下文隔离**：
|
||
- 每个子任务在独立上下文窗口运行，不继承主对话历史
|
||
- 子任务间通过 `SharedWorkspace` 共享中间产物（代码片段、文档、测试结果）
|
||
- 子任务完成后，结果汇总到 Lead Expert 的上下文
|
||
|
||
**R1.3 WebSocket 集成**：
|
||
- 用户输入 `@team 任务描述` 时，通过 `ExpertTeamRouter.resolve()` 解析专家列表和任务
|
||
- 创建 `ExpertTeam`，注册 handoff handler，广播 `team_formed` 事件
|
||
- 流水线执行驱动：Lead 分解 → 阶段串行 → 阶段内并行 → 结果汇总
|
||
- WebSocket 事件流：`team_formed` → `plan_update`（阶段计划）→ `expert_step`（每个子任务）→ `expert_result` → `phase_started`/`phase_completed` → `team_synthesis` → `team_dissolved`
|
||
- 失败时 fallback 到单 Agent REACT 模式（已有 `_fallback_to_single_agent`）
|
||
|
||
**R1.4 路由支持**：
|
||
- 支持 `@team 任务描述` → 使用默认编程团队
|
||
- 支持 `@team:frontend_engineer,backend_engineer 任务` → 显式指定专家
|
||
- 支持 `@team:dev_team 任务` → 调用整组开发团队
|
||
|
||
**验收标准**：
|
||
- `@team 开发用户登录功能` 能触发流水线：规划 → 前端 → 后端 → QA → 评审
|
||
- 前端 `ExpertTeamView.vue` 正确显示阶段计划、当前阶段、专家步骤
|
||
- `TEAM_COLLAB` 执行模式不再 fallback 到 REACT
|
||
- 子任务在独立上下文执行，互不污染
|
||
- 与 `@board` 互不干扰，用户可自由切换
|
||
|
||
**关联文件**：
|
||
- `src/agentkit/server/routes/chat.py` — 新增 `_execute_team_collab` 函数（参照 `_execute_board_meeting` 模式）
|
||
- `src/agentkit/experts/router.py` — `ExpertTeamRouter`（已实现，需集成）
|
||
- `src/agentkit/experts/orchestrator.py` — `TeamOrchestrator`（需重写为流水线模式）
|
||
- `src/agentkit/experts/plan.py` — `TeamPlan`（需恢复阶段依赖图）
|
||
- `src/agentkit/experts/team.py` — `ExpertTeam`（已实现，需适配流水线）
|
||
- `src/agentkit/server/frontend/src/components/chat/ExpertTeamView.vue` — 前端组件（需适配阶段展示）
|
||
|
||
---
|
||
|
||
### R2: 新增 5-8 个编程领域专家模板
|
||
|
||
**目标**：为 `@team` 流水线模式新增 5-8 个编程领域核心专家，对标 Qoder 的 5 类专家（Team Lead + 前端/后端/QA/评审），与 `@board` 的名人专家形成区分。
|
||
|
||
**需求**：
|
||
- 新增编程专家模板（YAML 格式，存放 `configs/experts/`）：
|
||
1. **tech_lead** — 技术负责人：任务分解、架构决策、代码审查、阶段协调
|
||
2. **frontend_engineer** — 前端工程师：UI 实现、组件开发、样式编写、前端测试
|
||
3. **backend_engineer** — 后端工程师：API 设计、服务逻辑、数据库操作、后端测试
|
||
4. **qa_engineer** — QA 工程师：测试用例设计、自动化测试、缺陷验证、质量报告
|
||
5. **code_reviewer** — 代码审查员：代码规范、安全漏洞、性能问题、最佳实践
|
||
6. **devops_engineer** — DevOps 工程师：CI/CD、部署配置、基础设施、监控（可选）
|
||
7. **security_expert** — 安全专家：安全审计、漏洞扫描、加密设计（可选）
|
||
8. **database_expert** — 数据库专家：Schema 设计、查询优化、数据迁移（可选）
|
||
- 每个专家配置：`persona`、`thinking_style`、`speaking_style`、`bound_skills`（绑定工具）、`avatar`、`color`
|
||
- 新增 `dev_team.yaml` 组合模板，包含默认编程团队成员列表
|
||
- 专家模板可通过 API 动态注册（已有 `ExpertTemplateRegistry.register()`）
|
||
|
||
**验收标准**：
|
||
- `configs/experts/` 目录包含 5-8 个编程专家 YAML + 1 个 `dev_team.yaml`
|
||
- `@team:frontend_engineer,backend_engineer 开发用户登录功能` 能调用对应专家
|
||
- `@team:dev_team 任务` 能调用默认编程团队
|
||
- 前端 `MentionDropdown.vue` 支持按领域筛选专家（名人专家 vs 编程专家）
|
||
|
||
**关联文件**：
|
||
- `configs/experts/` — 新增专家模板 YAML
|
||
- `src/agentkit/experts/registry.py` — `ExpertTemplateRegistry`（已实现，无需修改）
|
||
- `src/agentkit/server/frontend/src/components/chat/MentionDropdown.vue` — 专家筛选（需适配）
|
||
|
||
---
|
||
|
||
### R3: 上下文隔离机制
|
||
|
||
**目标**：为 `@team` 流水线子任务提供上下文级隔离，对标 Trae Solo 的独立上下文环境和 Claude Code Subagent 的上下文隔离。子任务在独立上下文窗口运行，不继承主对话历史，避免上下文污染。
|
||
|
||
**需求**：
|
||
- **上下文隔离**：
|
||
- 每个子任务创建独立的 `ConfigDrivenAgent` 实例，不共享对话历史
|
||
- 子任务的 LLM 调用使用独立上下文窗口，仅包含：任务描述 + 专家 persona + 前置阶段输出
|
||
- 子任务间通过 `SharedWorkspace` 传递中间产物（代码片段、文档、测试结果）
|
||
- **SharedWorkspace 强化**：
|
||
- 复用现有 `SharedWorkspace`（Redis 后端 + 内存回退）
|
||
- 新增约定 key：`{task_id}/phase/{phase_id}/output` 存储阶段输出
|
||
- 新增约定 key：`{task_id}/artifacts/{artifact_name}` 存储代码片段、文档等
|
||
- Lead Expert 可读取所有阶段的输出用于汇总
|
||
- **配置化**：
|
||
- `agentkit.yaml` 中配置隔离模式：`context`（默认）/ `none`（调试用）
|
||
- 上下文窗口大小可配置（默认遵循 LLM Provider 限制）
|
||
|
||
**验收标准**：
|
||
- `@team` 子任务在独立上下文执行，主对话历史不泄漏到子任务
|
||
- 阶段间数据通过 `SharedWorkspace` 正确传递
|
||
- Lead Expert 能读取所有阶段输出进行汇总
|
||
- 子任务失败不影响其他子任务的上下文
|
||
|
||
**关联文件**：
|
||
- `src/agentkit/experts/orchestrator.py` — 子任务上下文创建
|
||
- `src/agentkit/core/shared_workspace.py` — `SharedWorkspace`（已实现，需强化约定 key）
|
||
- `src/agentkit/core/config_driven.py` — `ConfigDrivenAgent`（已实现，需确保独立实例）
|
||
|
||
---
|
||
|
||
### R4: 多模型智能路由
|
||
|
||
**目标**：按任务类型和专家角色自动选择最优 LLM 模型，对标 Qoder 的 4 模式和 Trae 的多模型选择。当前 `ExpertConfig.llm` 字段已预留但 Orchestrator 硬编码 `model="default"`，需消费该字段。
|
||
|
||
**需求**：
|
||
- **专家级模型配置**：
|
||
- 每个 `ExpertConfig` 可配置 `llm.provider` 和 `llm.model`
|
||
- Orchestrator 读取 `ExpertConfig.llm` 而非硬编码 `model="default"`
|
||
- 示例：`tech_lead` 用 Claude Opus（推理强）、`frontend_engineer` 用 DeepSeek-Coder（代码强）、`qa_engineer` 用 GPT-4o（均衡）
|
||
- **任务类型路由**：
|
||
- 编程任务 → 代码能力强的模型（如 Claude Sonnet/Opus、DeepSeek-Coder）
|
||
- 对话任务 → 响应快的模型（如 GPT-4o-mini、Doubao-Lite）
|
||
- 推理任务 → 推理能力强的模型（如 Claude Opus、o4-mini）
|
||
- 中文任务 → 中文优化模型（如 Doubao、Wenxin、Qwen）
|
||
- **路由策略**：
|
||
- 基于 `ExpertConfig.llm` + 任务关键词 + 用户配置偏好
|
||
- 支持用户在 `agentkit.yaml` 中自定义路由规则
|
||
- 支持 `@team:expert --model=claude-opus 任务` 显式指定模型
|
||
- **成本控制**：
|
||
- 每次路由决策记录模型选择原因
|
||
- 月度成本报告按任务类型/模型维度统计
|
||
- 超预算时自动降级到更便宜的模型
|
||
- **Fallback 链**：
|
||
- 首选模型不可用时自动 fallback（已有 `_get_models_to_try`）
|
||
- Fallback 决策记录到 usage tracking
|
||
|
||
**验收标准**：
|
||
- 编程专家自动使用代码能力强的模型
|
||
- 用户可自定义路由规则
|
||
- 成本报告展示模型选择分布
|
||
- Fallback 链正常工作
|
||
- `board_orchestrator.py` 和 `orchestrator.py` 不再硬编码 `model="default"`
|
||
|
||
**关联文件**：
|
||
- `src/agentkit/experts/orchestrator.py` — 读取 `ExpertConfig.llm`（移除硬编码）
|
||
- `src/agentkit/experts/board_orchestrator.py` — 读取 `ExpertConfig.llm`（移除硬编码）
|
||
- `src/agentkit/llm/gateway.py` — `LLMGateway`（已实现，无需修改）
|
||
- `configs/experts/*.yaml` — 专家模板新增 `llm` 配置
|
||
|
||
---
|
||
|
||
### R5: 仓库级代码理解
|
||
|
||
**目标**：支持 10 万+ 文件级上下文检索和跨模块语义理解，对标 Qoder 的 Repo Wiki 和 Devin 的 Wiki。为 `@team` 编程任务提供代码上下文。
|
||
|
||
**需求**：
|
||
- **代码索引**：
|
||
- 对项目代码库建立向量索引（复用 pgvector）
|
||
- 支持函数级、类级、文件级粒度索引
|
||
- 增量索引：文件变更时自动更新索引
|
||
- **语义检索**：
|
||
- Agent 可通过 `code_search("用户认证逻辑")` 检索相关代码
|
||
- 返回代码片段 + 文件路径 + 上下文
|
||
- 支持自然语言查询和代码片段查询
|
||
- **架构图谱**：
|
||
- 自动生成项目架构图（模块依赖、调用关系）
|
||
- 前端可视化展示（复用 `WorkflowView.vue` 的图编辑器）
|
||
- **Repo Wiki**：
|
||
- 自动生成项目文档（README、API 文档、架构说明）
|
||
- 代码变更时自动更新文档
|
||
|
||
**验收标准**：
|
||
- `@team 重构用户认证模块` 能自动检索相关代码
|
||
- 架构图正确展示模块依赖关系
|
||
- Repo Wiki 自动生成并可浏览
|
||
|
||
**关联文件**：
|
||
- `src/agentkit/memory/episodic.py` — `EpisodicMemory`（pgvector 可复用）
|
||
- `src/agentkit/tools/` — 新增 `code_search` 工具
|
||
- `src/agentkit/server/frontend/src/components/` — 架构图可视化
|
||
|
||
---
|
||
|
||
### R6: IDE 插件（VS Code 扩展）
|
||
|
||
**目标**：将 Fischer AgentKit 能力嵌入 VS Code 编辑器，对标 Cursor 的原生 IDE 体验和 Qoder 的 JetBrains 插件。
|
||
|
||
**需求**：
|
||
- **VS Code 扩展**：
|
||
- 侧边栏聊天面板（复用 Web GUI 的 Vue 组件）
|
||
- 内联代码补全和建议
|
||
- 选中代码 → 右键 → "发送给专家团"
|
||
- `@team` 和 `@board` 前缀路由在 IDE 内可用
|
||
- **上下文感知**：
|
||
- 自动获取当前打开的文件、光标位置、选中文本作为上下文
|
||
- 诊断信息（lint 错误、类型错误）自动传递给 Agent
|
||
- 工作区符号搜索
|
||
- **操作集成**：
|
||
- Agent 可直接编辑文件（通过 VS Code WorkspaceEdit API）
|
||
- 终端命令执行（通过 VS Code Terminal API）
|
||
- Git 操作（通过 VS Code Git API）
|
||
- **Tauri 桌面端保留**：
|
||
- 现有 Tauri 桌面应用继续维护
|
||
- VS Code 扩展作为轻量级替代方案
|
||
|
||
**验收标准**：
|
||
- VS Code 扩展可安装和使用
|
||
- `@team` 和 `@board` 在 IDE 内正常工作
|
||
- Agent 可编辑文件和执行终端命令
|
||
- 选中文本可发送给专家团
|
||
|
||
---
|
||
|
||
## Scope Boundaries
|
||
|
||
### 本次范围内
|
||
|
||
- R0: 修复死代码与前后端不一致 — 最高优先级（基线修复）
|
||
- R1: `@team` 流水线集成 — 最高优先级（核心功能补齐）
|
||
- R2: 5-8 个编程专家模板 — 高优先级（场景覆盖）
|
||
- R3: 上下文隔离 — 中优先级（轻量隔离）
|
||
- R4: 多模型路由 — 中优先级（成本优化）
|
||
- R5: 仓库级理解 — 低优先级（长期）
|
||
- R6: IDE 插件 — 低优先级（长期）
|
||
|
||
### 延后到后续迭代
|
||
|
||
- **git worktree 隔离**：v1 路线图中的 worktree 方案延后，v2 选择上下文隔离作为更轻量的方案。若未来需要文件系统级隔离再评估
|
||
- **沙盒/容器隔离**：延后，需 Docker 环境，当前上下文隔离已满足需求
|
||
- **实时协作**：多用户共享 Agent 会话（对标 Google Docs 协作模式）
|
||
- **Agent 市场**：用户分享和下载专家模板/Skill 配置
|
||
- **语音交互**：语音输入和输出（对标 ChatGPT Voice、Cursor Voice Mode）
|
||
- **工作流模板库**：预置行业工作流模板（如"电商运营全流程"）
|
||
- **企业级权限**：RBAC、审计日志、SSO 集成
|
||
|
||
### 不在产品身份内
|
||
|
||
- **纯代码补全**：不做 GitHub Copilot 式的行内补全，聚焦 Agent 级任务
|
||
- **模型训练/微调**：不训练自有模型，保持模型无关性
|
||
- **CI/CD 流水线**：不做持续集成/部署系统，与现有 DevOps 工具集成
|
||
- **100+ 专家模板**：不走 WorkBuddy 的多而广路线，聚焦少而精
|
||
|
||
---
|
||
|
||
## Dependencies / Assumptions
|
||
|
||
1. **R0 依赖**：无外部依赖，纯代码修复
|
||
2. **R1 依赖**：R0 完成（基线干净）；`ExpertTeamRouter` 代码已完整；需重新实现流水线 `TeamOrchestrator` 和阶段依赖图
|
||
3. **R2 依赖**：`ExpertTemplateRegistry` 已支持动态注册，扩展工作主要是 YAML 编写
|
||
4. **R3 依赖**：`SharedWorkspace` 已实现（Redis 后端 + 内存回退）；`ConfigDrivenAgent` 支持独立实例
|
||
5. **R4 依赖**：`LLMGateway` 已支持 6 个 Provider 和 fallback 链；`ExpertConfig.llm` 字段已预留
|
||
6. **R5 依赖**：pgvector 已用于情节记忆，可复用；需要新增代码解析和索引模块
|
||
7. **R6 依赖**：VS Code 扩展 API + 现有 Web GUI 组件可复用
|
||
|
||
**假设**：
|
||
- 用户有可用的 LLM API 密钥（至少一个 Provider）
|
||
- 项目代码库规模在 10 万文件以内（R5 的索引能力上限）
|
||
- Redis 可用于 `SharedWorkspace`（R3 的上下文共享）
|
||
|
||
---
|
||
|
||
## Success Criteria
|
||
|
||
### R0 成功标准
|
||
- `pytest tests/integration/test_expert_team.py` 不再 ImportError
|
||
- 前后端数据模型一致（`subtasks` 或恢复 `plan_phases`，取决于 R1 决策）
|
||
- `AGENTS.md` 与代码实际状态一致
|
||
|
||
### R1 成功标准
|
||
- `@team` 流水线在 WebSocket 中端到端可用
|
||
- 前端正确显示阶段计划、当前阶段、专家步骤
|
||
- 与 `@board` 互不干扰，用户可自由切换
|
||
- 子任务在独立上下文执行，互不污染
|
||
|
||
### 整体成功标准
|
||
- 编程专家模板数 5-8 个（R2）
|
||
- `@team` 子任务在上下文隔离环境中执行（R3）
|
||
- 编程任务自动选择代码模型，成本降低 30%+（R4）
|
||
- 10 万文件项目代码检索延迟 < 500ms（R5）
|
||
- VS Code 扩展日活用户 > 100（R6）
|
||
|
||
### 差距缩小目标
|
||
|
||
| 能力维度 | 当前 | 目标 | 对标 |
|
||
|----------|------|------|------|
|
||
| 任务分解执行 | ⚠️ 死代码 | ✅ 流水线可用 | Qoder |
|
||
| 编排模式 | hub-and-spoke(未集成) | ✅ 流水线+并行 | Qoder |
|
||
| 隔离机制 | ❌ | ✅ 上下文隔离 | Trae Solo/Claude Code |
|
||
| 编程专家模板 | 0 | 5-8 个 | Qoder 5类 |
|
||
| 模型智能路由 | ❌ 硬编码 | ✅ 按专家路由 | Qoder/Trae |
|
||
| 仓库级理解 | ❌ | ✅ 10万文件 | Qoder/Devin |
|
||
| IDE 集成 | Web+Tauri | +VS Code 扩展 | Cursor/Qoder |
|
||
| 群聊讨论 | ✅ 独有 | ✅ 保持领先 | 无竞品 |
|
||
| 自进化 | ✅ 遗传+AB | ✅ 深化场景化 | Qoder Expert+Team Skill |
|
||
| 记忆系统 | ✅ 4层 | ✅ 场景化深化 | Qoder/Claude/Codex |
|
||
|
||
---
|
||
|
||
## Implementation Priority
|
||
|
||
| 优先级 | 需求 | 预期收益 | 复杂度 | 变化（vs v1） |
|
||
|--------|------|---------|--------|--------------|
|
||
| P0 | R0: 修复死代码+不一致 | 干净基线 | 低 | **新增** |
|
||
| P0 | R1: `@team` 流水线集成 | 核心功能可用 | 高 | 范围扩大（需重写编排器） |
|
||
| P1 | R2: 5-8 个编程专家 | 场景覆盖 | 中 | 从 50+ 收缩为少而精 |
|
||
| P1 | R3: 上下文隔离 | 子任务隔离 | 中 | 从 worktree+沙盒 降级 |
|
||
| P2 | R4: 多模型路由 | 成本优化 30%+ | 中 | 保持 |
|
||
| P2 | R5: 仓库级理解 | 代码任务质量 | 高 | 保持（长期） |
|
||
| P3 | R6: IDE 插件 | 用户入口扩展 | 高 | 保持（长期） |
|
||
|
||
---
|
||
|
||
## Competitive Positioning
|
||
|
||
### Fischer AgentKit 的差异化策略
|
||
|
||
**核心差异化（无竞品）**：
|
||
- `@board` 群聊决策讨论 — 10 个竞品中唯一支持多专家群聊式决策讨论
|
||
|
||
**对标差异化（有竞品但独特组合）**：
|
||
- `@board`（决策）+ `@team`（执行）双模式闭环 — 竞品要么只有执行（Qoder/Cursor/Devin），要么只有单模式
|
||
- 自进化系统（遗传算法+AB测试）— 比 Qoder 的 Expert Skill + Team Skill 更深层，但需深化场景化
|
||
- 4 层记忆系统（SOUL/USER/MEMORY/DAILY+pgvector）— 比竞品的记忆能力更结构化，但需场景化
|
||
|
||
**非差异化（持平）**：
|
||
- MCP 支持 — 已成事实标准
|
||
- 多 Provider LLM Gateway — 竞品普遍支持
|
||
- 工具系统 — 竞品普遍支持
|
||
|
||
**需补齐（落后）**：
|
||
- `@team` 任务分解执行 — 死代码，需集成
|
||
- 流水线编排模式 — 需实现
|
||
- 上下文隔离 — 需实现
|
||
- 编程专家模板 — 需新增
|
||
- 多模型路由 — 需消费已有字段
|
||
- 仓库级理解 — 需实现（长期）
|