24 KiB

Raw Blame History

title	type	status	created	updated	origin	version
Fischer AgentKit 专家团演进路线图 v2 — 竞品差距分析与下一步方向	strategy	active	2026-06-17	2026-06-17	竞品深度调研 + 代码库全量扫描	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`)	❌ 未集成	死代码

核心问题清单：

TeamOrchestrator 从未被实例化 — grep 在 src/agentkit/server 中搜索 TeamOrchestrator( 返回零匹配，整个代码库中仅在 __init__.py 导出但无调用方
CollaborationPlan 已被移除 — 替换为简化的 TeamPlan（仅 subtasks 列表，无阶段依赖图），VOTE/FUSION 合并策略已删除仅保留 BEST
前后端数据模型不一致 — 前端 team.ts 仍用 plan_phases 概念，后端 TeamPlan 已改为 subtasks，一旦集成 @team 会立即暴露
集成测试已损坏 — tests/integration/test_expert_team.py 导入已移除的 CollaborationPlan, ParallelType, PhaseStatus, PlanPhase，会 ImportError
多模型路由未消费 — ExpertConfig.llm 字段存在但两个 Orchestrator 均硬编码 model="default"
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	中

三个独特优势（应保持和放大）

私董会群聊讨论 — 10 个竞品中唯一支持多专家群聊式决策讨论的能力。@board 前缀触发，多轮自主循环，主持人小结，用户可干预。无任何竞品实现此模式。
自进化系统（但优势在缩小） — 遗传算法优化 prompt + A/B 测试 + 坑点检测 + 路径优化。Qoder 已跟进 Expert Skill + Team Skill 双向进化，需重新定位差异化（见 R4）。
4 层记忆系统（但优势在缩小） — SOUL/USER/MEMORY/DAILY + pgvector 情节记忆 + 语义检索。竞品（Qoder 记忆感知、Claude Session Memory、Codex Memory）正在跟进，需深化场景化记忆。

三个关键差距（需优先补齐）

@team 死代码 + 编排模式不足 — 代码完整但从未调用，且现有 hub-and-spoke 不支持流水线编排。是投入产出比最高的改进。
无隔离机制 — 缺乏任何形式的隔离（worktree/容器/上下文），多 Agent 并行会互相干扰。选择上下文隔离作为最轻量方案。
编程专家模板缺失 — 当前 9 个均为名人专家（用于 @board），无编程领域专家（用于 @team 流水线）。

行业趋势（影响演进方向）

从 Agentic Coding 到 Agentic Engineering — 行业从"AI 帮你写代码"转向"AI 帮你交付软件"，Qoder 1.0、Devin、Trae SOLO 都体现这一范式切换
Human on the Loop 成共识 — 从 Human in the Loop（人在循环中）转向 Human on the Loop（人在循环上）— 人负责定义、驾驭、判断，Agent 负责执行
MCP 成事实标准 — Anthropic 的 Model Context Protocol 获得 OpenAI、Google、Meta 联合支持，Fischer 已支持，不再是差异化优势
记忆与进化能力成标配 — 竞品普遍跟进，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

R0 依赖：无外部依赖，纯代码修复
R1 依赖：R0 完成（基线干净）；ExpertTeamRouter 代码已完整；需重新实现流水线 TeamOrchestrator 和阶段依赖图
R2 依赖：ExpertTemplateRegistry 已支持动态注册，扩展工作主要是 YAML 编写
R3 依赖：SharedWorkspace 已实现（Redis 后端 + 内存回退）；ConfigDrivenAgent 支持独立实例
R4 依赖：LLMGateway 已支持 6 个 Provider 和 fallback 链；ExpertConfig.llm 字段已预留
R5 依赖：pgvector 已用于情节记忆，可复用；需要新增代码解析和索引模块
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 任务分解执行 — 死代码，需集成
流水线编排模式 — 需实现
上下文隔离 — 需实现
编程专家模板 — 需新增
多模型路由 — 需消费已有字段
仓库级理解 — 需实现（长期）

24 KiB Raw Blame History Unescape Escape

Fischer AgentKit 专家团演进路线图 v2

Summary

Problem Frame

当前状态（代码库全量扫描结果）

竞品差距矩阵（10 个竞品深度调研）

三个独特优势（应保持和放大）

三个关键差距（需优先补齐）

行业趋势（影响演进方向）

Requirements

R0: 修复死代码与前后端不一致

R1: @team 流水线模式集成到 WebSocket

R2: 新增 5-8 个编程领域专家模板

R3: 上下文隔离机制

R4: 多模型智能路由

R5: 仓库级代码理解

R6: IDE 插件（VS Code 扩展）

Scope Boundaries

本次范围内

延后到后续迭代

不在产品身份内

Dependencies / Assumptions

Success Criteria

R0 成功标准

R1 成功标准

整体成功标准

差距缩小目标

Implementation Priority

Competitive Positioning

Fischer AgentKit 的差异化策略

24 KiB

Raw Blame History

R1: `@team` 流水线模式集成到 WebSocket