# AI 扩展能力路线

当前 GoNavi 的 AI 链路是：

1. 前端 `AIChatPanel` 组装 system messages。
2. 前端声明本地固定工具 `LOCAL_TOOLS`。
3. 后端 `aiservice.Service` 只负责 Provider 配置、安全级别与模型转发。

这套结构已经足够承接“用户级提示词”，但要继续承接 MCP 和 Skills，需要先把“提示词 / 工具 / 技能”三层职责拆开。

## 1. 用户级自定义提示词

已落地的方向：

- 配置存储在 `ai_config.json` 的 `userPromptSettings`。
- 由 `AISettingsModal` 提供编辑入口。
- 由 `AIChatPanel` 在运行时追加为 system message。

建议长期保持 4 个层级：

- `global`: 所有 AI 会话统一追加。
- `database`: 数据库 / SQL 场景追加。
- `jvm`: JVM 资源浏览与分析场景追加。
- `jvmDiagnostic`: JVM 诊断命令规划场景追加。

这样既能满足“个人习惯”定制，也不会把所有场景揉成一条超长总提示词。

## 2. MCP 能力开放

目标不是把 MCP 做成新的聊天面板，而是把它变成“外部工具源”。

建议后续拆成三层：

1. `tool registry`
   - 统一收口内置工具、本地扩展工具、MCP 工具。
   - 对模型只暴露统一的 `tools[]`。
2. `mcp server config`
   - 保存 server 名称、transport、启动命令或 URL、超时、启用状态。
   - 由后端维护生命周期与连通性。
3. `mcp runtime bridge`
   - 负责 `list tools / call tool / errors / timeout / auth`。

### MCP 是否需要单独 GitHub 仓库

不需要把“GoNavi 对 MCP 的支持”单独拆仓库。

更合理的边界是：

- `GoNavi 主仓库`
  - 维护 MCP client、配置、UI、工具注册和运行时桥接。
- `单独仓库（可选）`
  - 只在你要发布一个可复用的 MCP Server 时才有价值。
  - 例如 `gonavi-mcp-sql-tools`、`gonavi-mcp-jvm-agent` 这类独立 server。

结论：

- “客户端支持 MCP” 不需要新仓库。
- “某个独立 MCP Server” 是否拆仓库，取决于它要不要单独发布、复用或部署。

## 3. Skills 设计

Skills 不建议直接等同于“另一种提示词”。

更合适的定义是：

- `skill manifest`
  - 名称、说明、适用场景、是否默认启用。
- `skill prompt`
  - 该技能追加的 system prompt / few-shot / 输出约束。
- `skill tool requirements`
  - 该技能依赖哪些内置工具或 MCP 工具。
- `skill shortcuts`
  - 可选地给欢迎卡片、斜杠命令或快速动作提供入口。

一个 Skill 本质上应该是“提示词 + 工具依赖 + 使用入口”的组合，而不是单独一段文案。

### Skills 是否需要单独 GitHub 仓库

第一阶段不需要。

建议顺序：

1. 先在 GoNavi 主仓库内把 Skills manifest/runtime 跑通。
2. 等格式稳定后，再考虑增加“本地目录导入”或“Git 仓库导入”。

只有当你明确要做下面两件事时，独立仓库才值得：

- 把 Skills 当作社区共享资产分发。
- 让不同团队独立维护自己的 skill pack。

## 建议的下一步实现顺序

1. 抽出统一 `ToolRegistry`，让 `LOCAL_TOOLS` 不再硬编码在聊天面板内部。
2. 在 AI 设置中新增 `MCP Servers` 配置页。
3. 后端先支持最小 transport：
   - `stdio`
   - `http/sse`（如果后续确认需要）
4. 在 AI 设置中新增 `Skills` 配置页。
5. 让 Skill 以 manifest 形式声明：
   - `id`
   - `name`
   - `description`
   - `systemPrompt`
   - `requiredTools`
   - `scopes`
6. 再决定是否增加“从 Git 仓库同步 MCP/Skills 包”的分发能力。