把插件做成“安装、管理、接入现有能力”的入口，而不是第一期就重写一个扩展平台

1. 先给结论

一句话拆解

现在的 Kimi Code 已经有“能力被发现、展示、执行”的基础。缺的是一个稳定的插件包格式、安装位置、管理界面，以及把插件声明的能力接入 Session 的 RPC。做 /plugins 时，不应该让 TUI 直接读 agent-core，而是走 packages/node-sdk 暴露出的会话 API。

第一期成功标准

• 用户输入 /plugins 后，可以看到插件列表、插件来源、启用状态、能力摘要和加载错误。
• 用户可以从本地目录安装一个插件，也可以禁用、启用、卸载已安装插件。
• 插件里的 skill 可以出现在现有的 skill 列表和 slash 补全里。
• 插件声明的工具如果被模型调用，走现有权限/确认机制，不能静默执行。
• 旧 kimi-cli 的 ~/.kimi/plugins 至少有清楚的迁移提示，最好能做验证后迁移。

2. 当前仓库是什么

/Users/moonshot/code/kimi-code 是一个 TypeScript monorepo。核心产品是终端里的 Kimi Code CLI/TUI， 底层由 SDK 和 agent-core 提供会话、skills、tools、MCP、权限、后台任务等能力。

3. 当前已有可复用能力

4. 参考实现对比

下面四套参考实现的关注点不一样：old kimi-cli 最像第一期本地插件；Claude Code 是完整扩展平台； Codex 是 marketplace 和 /plugins UI 的强参考；Pi 展示了 TypeScript 扩展系统的另一种边界。

5. /plugins 应该解决什么

对用户来说，/plugins 不应该只是列一个目录。它要回答四个问题：我装了什么、它能做什么、它有没有问题、我能怎么处理。

用户流程建议

6. 插件包形态

最小可用的插件包应该容易手写，也能兼容 old kimi-cli 的目录插件。建议第一期固定根目录 plugin.json，允许同时带 SKILL.md 和工具脚本。

my-plugin/
├── plugin.json
├── SKILL.md
├── tools/
│   └── search.js
└── mcp.json       # 可选，建议第二期再自动接入

推荐 plugin.json 示例

{
  "name": "repo-search",
  "version": "0.1.0",
  "description": "Search repository files and summarize matches.",
  "skills": "./skills",
  "tools": [
    {
      "name": "search",
      "description": "Search files with ripgrep and return compact matches.",
      "command": ["node", "./tools/search.js"],
      "parameters": {
        "type": "object",
        "properties": {
          "query": {
            "type": "string",
            "description": "The ripgrep query."
          }
        },
        "required": ["query"]
      }
    }
  ]
}

字段建议

7. 推荐实现方案

实现上建议分三层：core 负责发现和执行，SDK 负责暴露会话 API，TUI 负责展示和用户操作。

建议新增/修改路径

工具命名建议

old kimi-cli 遇到工具名冲突时直接跳过插件工具。这个做法简单，但用户很难发现为什么工具不可用。 新实现更应该在 /plugins 里明确显示“工具名冲突”或采用命名空间避免冲突。

安装目录和配置建议

• 安装目录：~/.kimi-code/plugins/<plugin-name>。
• 临时安装 staging：~/.kimi-code/plugins/.tmp-<random>，验证成功后原子替换。
• 启用状态：优先写入现有 config，例如 [plugins."repo-search"] enabled = true。
• 插件私有数据：后续可以加 ~/.kimi-code/plugin-data/<plugin-name>，卸载时询问是否保留。
• 远程 marketplace：第一期不建缓存层，第二期再考虑 plugins/cache/<source>/<name>/<version>。

8. 分阶段落地

最小第一 PR 建议

1. 新增 packages/agent-core/src/plugin/manifest.ts，只支持本地已安装目录扫描和错误收集。
2. 新增 SDK/RPC listPlugins()，返回结构化列表，不做安装/执行。
3. 新增 /plugins 命令和只读 TUI 浏览器。
4. 补测试：manifest 成功/失败、路径越界、TUI slash 注册、空列表 UI。

这个 PR 小，能先把用户界面和数据模型定下来；后续再接 skill、tools、安装操作，不会一口气改太多核心路径。

9. 风险和安全边界

第一期明确不要做

• 不要支持自动安装远程 marketplace 插件。
• 不要让插件声明任意 hook 并在启动时直接执行。
• 不要默认把用户密钥写入插件配置文件。
• 不要允许插件工具裸名覆盖内置工具。
• 不要让 TUI 绕过 SDK 直接操作 core 内部对象。

10. 测试清单

11. 需要先拍板的问题

1. 第一期是否只支持本地插件？我建议是。远程 git/zip/marketplace 放第二期。
2. 是否兼容 old kimi-cli 的 plugin.json？我建议兼容核心字段，尤其是 tools 和顶层 SKILL.md。
3. 插件工具是否允许裸工具名？我建议内部强制命名空间，UI 里再展示友好名。
4. 安装后是否必须热刷新当前 session？最好支持，但可以第一期提示“新会话生效”；如果做工具执行，热刷新体验更重要。
5. MCP 是否第一期自动接入？我建议第一期只解析和展示，第二期再合并执行。
6. 启用状态是全局还是项目级？第一期全局更简单；项目级适合有 workspace policy 后再做。

12. 调研来源

本报告基于本机源码和文档检索，不依赖远程网络资料。下面是主要证据路径。

Kimi Code 当前仓库

• /Users/moonshot/code/kimi-code/apps/kimi-code/AGENTS.md
• /Users/moonshot/code/kimi-code/apps/kimi-code/src/tui/commands/registry.ts
• /Users/moonshot/code/kimi-code/apps/kimi-code/src/tui/commands/resolve.ts
• /Users/moonshot/code/kimi-code/apps/kimi-code/src/tui/commands/skills.ts
• /Users/moonshot/code/kimi-code/apps/kimi-code/src/tui/kimi-tui.ts
• /Users/moonshot/code/kimi-code/packages/node-sdk/src/session.ts
• /Users/moonshot/code/kimi-code/packages/node-sdk/src/rpc.ts
• /Users/moonshot/code/kimi-code/packages/agent-core/src/session/rpc.ts
• /Users/moonshot/code/kimi-code/packages/agent-core/src/session/index.ts
• /Users/moonshot/code/kimi-code/packages/agent-core/src/skill/scanner.ts
• /Users/moonshot/code/kimi-code/packages/agent-core/src/skill/parser.ts
• /Users/moonshot/code/kimi-code/packages/migration-legacy/src/detect.ts
• /Users/moonshot/code/kimi-code/apps/kimi-code/src/migration/migration-screen.ts
• /Users/moonshot/code/kimi-code/docs/en/customization/skills.md
• /Users/moonshot/code/kimi-code/docs/en/customization/mcp.md
• /Users/moonshot/code/kimi-code/docs/en/reference/slash-commands.md

参考实现

注：本文里的“第一期/第二期”是实现建议，不代表已有产品承诺。真正开工前建议先用上面的“需要拍板的问题”确认范围。