为什么使用插件
Jarvis Core 负责稳定的会话、权限、运行时、UI 和数据边界。插件负责把某个团队、领域或工作方式需要的配置和工具能力打包出来，让别人可以审查、安装、启用、更新和卸载。
这个边界让 Jarvis 能支持更多长尾需求，而不把所有场景都塞进核心产品。
插件解决什么问题
标题为“插件解决什么问题”的章节很多有价值的能力不是所有用户都需要：
- 团队自己的代码审核流程；
- 某个行业的值班、发布或迁移 SOP；
- 特定模型、权限和目录组合的 Agent Profile；
- 一组可复用的 workflow；
- 本机工具或 daemon 通过受控接口暴露给 worker。
如果这些能力都进入 Core，Jarvis 会变重、权限面会变大、发布节奏也会被长尾场景拖慢。插件让维护者把自己的场景作为独立交付物维护，Jarvis 只维护安装、校验、权限展示和运行时接线。
可以共享什么
标题为“可以共享什么”的章节Jarvis 插件当前主要共享声明式贡献点：
| 贡献点 | 适合承载 |
|---|---|
| Agent Profile | 模型、运行时、工作目录、工具和权限默认值 |
| Workflow | 多 worker 流程、交接 schema、监督策略 |
| Slash command | 把常用动作做成 /command 入口 |
| Workspace | 插件需要的 Jarvis-managed 数据目录 |
| Native service | 由 Jarvis 下载、校验和启动的本机 daemon |
| Internal MCP server | 由 Jarvis relay 注入给 worker 的受控工具 |
插件包仍是 data-only。它不能把任意脚本、密钥或隐式安装逻辑塞进 Jarvis。
为什么需要插件市场
标题为“为什么需要插件市场”的章节插件市场解决发现、信任和更新问题：
- 用户能在
https://jarvis.xcos.dev/plugins看到可安装插件； - 本机 Jarvis 会在安装前展示来源、版本、hash、签名、权限和原生依赖；
- 安装时由本机 Jarvis 下载并校验 artifact，而不是网页直接运行代码；
- 更新时 Jarvis 能比较已安装版本和 catalog latest，并要求用户重新审查能力变化；
- 维护者可以把新版本作为不可变 artifact 发布，保留可回滚的来源记录。
公共网页只负责展示。真正的安装入口在本机 Jarvis。
Core 和插件的分工
标题为“Core 和插件的分工”的章节| 领域 | Jarvis Core | 插件 |
|---|---|---|
| 安装 | 下载、验签、hash 校验、写入本机数据库 | 提供不可变 pack 和 metadata |
| 权限 | 展示、审查、启停、阻断危险能力 | 声明需要的能力 |
| 运行 | 启动 worker、合并 profile、注入 MCP | 声明 contribution |
| 原生依赖 | 下载、校验、安装、启动、健康检查 | 声明需要哪个 dependency |
| 数据 | 管理 Jarvis data dir 和用户配置 | 使用受控 workspace |
| 发布 | catalog、签名、版本生命周期 | 提供 changelog、隐私说明和支持入口 |
什么时候不要做插件
标题为“什么时候不要做插件”的章节以下能力应该留在 Core 或先作为 Jarvis 功能设计：
- 每个用户都会用到的基础会话能力；
- 影响全局权限模型或安全边界的能力；
- 需要任意代码执行、复杂 UI 或长期后台权限的能力；
- 还没有清晰维护者、升级策略和隐私说明的实验。
插件适合已能被描述为稳定交付物的场景：谁维护、装了会贡献什么、会访问什么、如何卸载、如何升级，都能在安装审查里说清楚。