插件 - Devin Docs

插件目前处于 beta 阶段。其行为和配置可能会在后续版本中发生变化。

插件是一组可复用的技能，你可以从 GitHub 代码仓库、git URL 或本地文件夹安装，并在多个项目之间复用。安装插件后，其中的技能会以 /<plugin>:<skill> 斜杠命令的形式提供，并且还会自动拉取其依赖的其他插件。插件本质上只是一个包含以下内容的来源：

my-plugin/
├── .devin-plugin/
│   └── plugin.json     # 插件清单
├── AGENTS.md           # 可选的始终生效规则
├── rules/              # 可选的触发规则
├── agents/
│   └── reviewer.md     # 可选的自定义子 Agent（也可使用 reviewer/AGENT.md）
├── hooks.json          # 可选的生命周期钩子
├── mcp_config.json     # 可选的 MCP 服务器
└── skills/
    └── review/
        └── SKILL.md    # 常规技能

skills/ 目录用于存放常规技能——插件不会引入新的技能格式。有关 SKILL.md 的格式，请参阅创建技能。除技能之外，插件还可以附带：

规则——位于插件根目录的 AGENTS.md 会作为始终生效的规则注入到每个会话中，与项目自身的规则一同生效。rules/ 文件夹中的 Markdown 文件也会一并加载，并使用与 Windsurf 规则相同的 trigger frontmatter 和激活类型。
自定义子 Agent——agents/<name>.md 或 agents/<name>/AGENT.md Profile (与项目子 Agent 使用相同的自定义子 Agent 格式) ，可通过 <plugin>:<name> 使用。插件子 Agent 目前仅在本地 Devin Agent 中加载 ——即 CLI 和 Devin Desktop——不支持在云端 Devin 会话中加载。
钩子——位于插件根目录的 hooks.json 会注册在安装了该插件的每个会话中运行的生命周期钩子。
MCP 服务器——位于插件根目录的 mcp_config.json 会声明随会话一起启动的 MCP 服务器 ("mcpServers": { "<name>": { … } }) 。Claude 插件根目录下的 .mcp.json 和清单中的 mcpServers 字段也同样会被识别。

安装插件

插件来源可以是 GitHub owner/repo、git URL 或本地路径：

# 从 GitHub 安装
devin plugins install acme/review-tools

# 从任意 git 托管平台安装
devin plugins install https://gitlab.com/acme/review-tools.git

# 从本地文件夹安装（非常适合本地开发调试）
devin plugins install ./my-plugin

安装前，Devin 会显示该插件将添加的内容——它提供的技能、将自动安装的所有必需插件，以及它引入的任何策略 (例如，是否禁止其他插件) 。传入 -y / --yes 可跳过提示。插件以 user 级别安装，并可在你的所有项目中使用。

管理插件

# 列出已安装的插件、其版本以及是否有插件被策略阻止
devin plugins list

# 显示插件的 技能 及其必需/可选/禁止列表
devin plugins info review-tools

# 重新拉取某个插件（或所有插件）的最新版本
devin plugins update review-tools
devin plugins update

# 移除插件（自动安装的必需插件将保留原位）
devin plugins remove review-tools

本地插件会直接链接到源文件夹，因此编辑会立即生效： devin plugins install ./my-plugin → 编辑 skills/<name>/SKILL.md → 所做更改会在下一次会话中生效，无需执行 update。

清单

.devin-plugin/plugin.json 用于描述插件。只有 name 是必填项，并且它在已安装插件中必须唯一 (即 /<name>:… 命名空间) 。

{
  "name": "review-tools",
  "version": "1.0.0",
  "description": "Code-review skills for our team",
  "requiredPlugins": [
    "acme/secure-base",
    { "source": "github", "repo": "acme/audit-logging" }
  ],
  "optionalPlugins": [
    "acme/deploy-tools",
    { "source": "url", "url": "https://gitlab.com/acme/extra.git" }
  ],
  "forbiddenPlugins": ["sketchy-org/bad-plugin", "acme/*", "*"]
}

支持的元数据字段：name、version、description、author ({ name, email }) 、homepage、repository、license 和 keywords。另外还有两个可选字段用于控制资源的加载位置：skills——指向 skill 目录的路径或路径数组，用于替代默认的 skills/——以及 mcpServers——MCP 声明文件路径或行内服务器映射，除根目录规范外也会一并读取。依赖项条目表示一个来源——可以是字符串简写，也可以是对象：

形式	含义
`"owner/repo"`	GitHub 代码仓库
`"https://…"`, `"git@…"`, `"ssh://…"`	任意 git URL
`{ "source": "github", "repo": "owner/repo" }`	GitHub，对象形式
`{ "source": "url", "url": "https://gitlab.com/team/plugin.git" }`	git URL，对象形式
`{ "source": "git-subdir", "url": "…", "path": "sub/dir" }`	位于共享代码仓库子目录中的插件

同一代码仓库的所有 GitHub 表示形式 (owner/repo、HTTPS URL、.git URL、SSH 形式) 都对应同一个插件标识。

依赖与治理

插件可以声明三个列表，使单个插件能够作为由其他插件构成的精选、受管控的集合。

`requiredPlugins`

安装插件时会自动 (递归) 安装这些插件。如果某个必需插件被策略阻止，整个安装都会失败——不支持部分安装。

`optionalPlugins`

该插件认可的插件允许列表。这些插件不会自动安装；此列表仅用于将某个被禁用的条目设为例外 (见下文) 。

`forbiddenPlugins`

一个由插件标识和 glob 模式组成的禁止列表。 forbiddenPlugins 条目会与插件标识进行匹配：

精确标识，写作 owner/repo 或 git URL。同一代码仓库的所有 GitHub 形式 (owner/repo、HTTPS URL、.git URL、SSH 形式) 都对应同一个标识。
glob 模式——任何包含 * 的条目。* 可匹配任意字符序列 (包括 /) ：acme/* 匹配 acme 的所有 GitHub 代码仓库，*/secrets 匹配任意所有者下名为 secrets 的代码仓库，https://gitlab.com/acme/* 则匹配该路径下的任意代码仓库。
单独的 "*"，它会匹配其他所有内容 (即完全锁定) 。

这些列表按 deny 优先生效：

Deny 优先。 只要任何一个活动中的清单或已安装插件禁止某个插件，该插件就会被阻止。如果没有任何规则禁止任何内容，就不会有插件被阻止。
自身覆盖例外。 清单 (或插件) 自身的 requiredPlugins 和 optionalPlugins——以及对于插件而言，插件本身——不受其自身 forbidden 列表的限制。因此，"forbiddenPlugins": ["*"] 加上 "optionalPlugins": ["acme/approved"] 的含义是“只允许此清单列出的内容；禁止其他所有内容”。该例外仅适用于这些直接条目，不包括必需插件的传递依赖——在锁定模式下，需要将这些内容显式列出。
不允许跨作用域重新放行。 一个清单或插件的允许列表，不能重新放行被另一个清单或插件禁止的内容。`“forbiddenPlugins”: [”*”]“ 这种完全锁定，无法从更低作用域绕过。

强制执行发生在两个时间点：

安装时——如果要安装的插件已被阻止 (或其必需插件无法满足，或其名称与已安装插件冲突) ，安装会被拒绝。
加载时——如果某个插件在安装后才被阻止，它仍会保留在磁盘上，但其技能会在会话开始时被跳过，并显示一条警告，指出是哪个禁止方导致的。

除上述 owner/repo 和 git URL 形式外，被列入禁止列表的标识也可以是本地路径 (适用于从本地文件夹安装的插件) 。

继承与层级

插件并不是集中在一个地方声明的。除了你自己安装的插件外，你的 repo 和你的组织的 Admin 也可以要求、推荐或禁止某些插件。每个来源都是一个层级，这些层级按权威性排序，最高的在前：

Enterprise — 由 Admin 配置的账户级托管清单。
Org — 位于其账户之下的组织级托管清单，分层叠加在账户级之下 (组织可以在其账户声明的内容之上添加内容，但不能推翻账户级声明) 。这仅适用于云端 Devin 会话：CLI 在账户级进行身份验证，没有组织上下文，因此组织级的必需和禁止规则不会传递给 CLI 用户。任何需要在 CLI 中强制执行的内容，都应放在 enterprise/account 清单中。
Repo — 检出副本的 .devin/config.json 中的 requiredPlugins / optionalPlugins / forbiddenPlugins，通过从你的工作目录向上遍历来发现。
User — 你通过 devin plugins install 自行安装的插件。

每个层级都声明相同的三个列表，并且在同一层级内，它们会像单个清单一样，按照相同的拒绝优先、当前用户覆盖规则进行合并。层级在此基础上额外增加的一条规则是：更高权威性优先。

更高权威性优先

较低级别绝不能重新允许较高级别已禁止的内容。
较低级别绝不能禁止较高级别要求的内容——该禁止会被忽略，插件仍会加载。

因此，Admin 可以强制启用某个任何 repo 或 user 都无法选择退出的插件，也可以禁止某个任何较低级别都无法重新启用的插件。

拒绝列表只能在其所在级别覆盖

由于允许列表不会跨级别生效，因此，要想在拒绝列表中开例外，唯一的方法就是在声明该拒绝列表的同一级别进行设置。某一级别的 forbiddenPlugins 只能由同一份清单中的 optionalPlugins (或 requiredPlugins) 覆盖——绝不会被更低级别的列表覆盖。例如，企业级托管清单可以将该账户限制为仅允许一个已获批准的插件：

// 企业级托管清单
{
  "forbiddenPlugins": ["*"],
  "optionalPlugins": ["acme/approved"]
}

这意味着“在整个账户范围内，只允许 acme/approved，并禁止所有其他插件。”任何 org、repo 或 user 都不能扩大这个允许列表——既不能通过安装插件，也不能通过将其添加到下一级的 optionalPlugins 中。这种例外也只适用于此清单中直接列出的条目；某个必填插件自身的传递依赖并不在豁免范围内，因此在锁定状态下应将这些依赖明确列出。

冲突与依赖

对于同一个插件，如果在同一级别既有 require 又有禁止，且它们来自不同的清单 (例如两个分别安装的用户级插件) ，则以禁止为准——允许列表只会豁免其自身清单中的条目，因此无法挽回被另一个清单禁止的插件。 (在单个清单内，它自身的 required/optional 仍然不受自身禁止的影响，如上文所述。)
被治理规则阻止的插件会软失败：在会话开始时，其 skills 会被跳过，并给出一条指出禁止发起方的警告，而不是直接中止会话。
被依赖本身并不会带来任何豁免。仅作为传递依赖引入的插件，仍然受所有适用于它的禁止约束，并且会继承所有要求它的插件中的最高权限级别。

入门指南

编辑器集成

扩展性

企业版

参考文档

变更日志

插件

安装插件

管理插件

清单

依赖与治理

`requiredPlugins`

`optionalPlugins`

`forbiddenPlugins`

继承与层级

更高权威性优先

拒绝列表只能在其所在级别覆盖

冲突与依赖

​安装插件

​管理插件

​清单

​依赖与治理

​requiredPlugins

​optionalPlugins

​forbiddenPlugins

​继承与层级

​更高权威性优先

​拒绝列表只能在其所在级别覆盖

​冲突与依赖

安装插件

管理插件

清单

依赖与治理

`requiredPlugins`

`optionalPlugins`

`forbiddenPlugins`

继承与层级

更高权威性优先

拒绝列表只能在其所在级别覆盖

冲突与依赖