Devin CLI 插件

插件是一组技能的集合，还可包含可选的规则、钩子、MCP 服务器或自定义子 Agent。你可以从 GitHub repo、git URL、repo 的子文件夹或本地文件夹安装插件。插件可在 Devin 云端会话、Devin CLI 和 Devin Desktop 中使用，但受下文所述的界面特定限制。安装插件后，其中的技能会以 /<plugin>:<skill> 斜杠命令的形式提供。本页介绍 CLI 中的插件；关于 web app——Customize 页面、组织和 enterprise 作用域、索引以及 MCP 连接——请参阅插件指南。 插件是安装的单位。安装插件会安装其所有技能及其 requiredPlugins；你无法单独安装插件中的某项技能。若要单独提供技能，请将它们拆分为独立的插件。插件本质上只是一个包含以下内容的来源：

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

skills/ 目录用于存放常规技能——插件不会引入新的技能格式。有关 SKILL.md 的格式，请参阅创建技能。一个 repo (或一个 git-subdir 子文件夹) 对应一个插件。单个 repo 可以将多个插件托管为子文件夹，每个插件都通过各自的 git-subdir 来源引用。除技能之外，插件还可以附带：

规则——位于插件根目录的 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 会在安装了该插件的本地 Devin 会话 (CLI 和 Devin Desktop) 中注册生命周期钩子。插件钩子目前采用 尽力而为且失败时放行的机制——如果钩子加载或运行失败，会话会在没有该钩子的情况下继续——因此暂时不要将其用于关键护栏。
MCP 服务器——插件可提供随会话一起启动的可选 MCP 服务器。其工具可供 Devin 使用。在 CLI 中，请使用 devin mcp login 对插件的 OAuth 服务器进行身份验证；云端会话则使用在 web app 中建立的连接 (参阅 MCP) 。插件 MCP 配置可以设置 OAuth 客户端 ID 和作用域，但绝不能设置客户端密钥——携带客户端密钥的服务器配置会在激活时被拒绝。请以 ${NAME} 的形式引用 secrets；直接写入配置中的字面值会被剔除。

兼容格式

上述布局是 Devin 自有的插件格式。Devin 还支持加载以另外两种布局打包的插件，清单优先级为 .devin-plugin/plugin.json > .claude-plugin/plugin.json > 根目录的 plugin.json：

Claude 插件 — 如果不存在 .devin-plugin/plugin.json，Devin 会回退使用 .claude-plugin/plugin.json。Claude 插件根目录中的 .mcp.json 以及清单中的 mcpServers 字段均会生效，服务器配置中的 ${CLAUDE_PLUGIN_ROOT} 会展开为插件根目录。
Agent 插件 — 按照开放的 Agent Plugins 1.0.0 规范打包的插件 (插件根目录包含 plugin.json 清单，根目录的 mcp.json 中定义 MCP 服务器，技能位于 skills/ 下) 也会被加载。对于这些插件，根目录的 mcp.json 会作为常规 MCP 源读取 (优先级低于 .mcp.json，发生服务器名称冲突时后者优先) ——旧版 Devin/Claude 布局的插件不会读取它，除非其清单明确声明。 MCP 条目可以使用该规范中的 type 字段 (stdio、 streamable-http 或 sse) 而非 transport 来声明传输方式，服务器配置中的 ${PLUGIN_ROOT} 会与 ${CLAUDE_PLUGIN_ROOT} 一样展开为插件根目录。对无法识别的 $schema 版本会发出警告，但仍会尽力加载插件。 Agent 插件的 MCP 服务器还遵循该规范的运行时约定 (这些仅适用于清单位于根目录的 plugin.json 的插件；Devin 和 Claude 布局的行为与此前完全一致) ：
- args、env 值和 cwd 中的 ${PLUGIN_DATA} 会展开为持久化、可写的插件专属数据目录。该目录按插件身份而非版本区分，因此其内容会在插件更新后保留，并会在卸载插件时删除。
- stdio 服务器进程除接收配置中设置的任何 env 外，还会接收 PLUGIN_ROOT 和 PLUGIN_DATA 环境变量。
- 服务器可以设置 cwd (相对于插件根目录) ；默认值为插件根目录。以 ./ 为前缀的 command 会相对于插件根目录解析，因此插件可以附带自己的可执行文件。系统会验证两者均位于插件根目录或数据目录内。

安装插件

插件来源可以是 GitHub owner/repo、git URL 或本地路径；当插件位于仓库根目录之下时，请追加 #path/to/plugin：

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

# 位于仓库子文件夹中的插件
devin plugins install acme/plugins#plugins/review

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

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

# 仅安装在当前机器上，不会同步到 Devin Cloud 中你的个人插件
devin plugins install --local ./my-plugin

安装前，Devin 会显示该插件将添加的内容——它提供的技能、将自动安装的所有必需插件，以及它引入的任何策略 (例如，是否禁止其他插件) 。传入 -y / --yes 可跳过提示。插件以 user 级别安装，并可在你的所有项目中使用。默认情况下，install 会将该插件记录到你在 Devin Cloud 中的个人清单里，因此你登录的每台机器 (以及你的云端会话中) 都会加载相同的插件。传入 --local 可仅在当前机器上安装。管理插件需要处于登录状态 (devin auth login)；企业可以为其成员禁用 CLI 插件，此时已安装的插件不会生效。

管理插件

# 列出已安装的 plugin、版本，以及是否有 plugin 被 policy 阻止
devin plugins list

# 显示某个 plugin 的 skills、钩子、Rules，以及它的 required/optional/forbidden 列表
devin plugins info review-tools

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

# 从你的个人 plugin 中移除某个 plugin（自动安装的 required plugin 会保留）
devin plugins remove review-tools

# 仅从当前 machine 移除（若 plugin 属于你的个人 plugin，则会失败）
devin plugins remove review-tools --local

# 清除磁盘上已不存在的代码仓库所声明的 plugin 需求，并回收未使用的 plugin 内容
devin plugins prune

remove --force 会强制移除插件，即使仍有其他插件或治理清单依赖它；治理要求的插件会在相应作用域的下一个会话中被重新安装，同时 CLI 会提示是哪个 enterprise、组织或 repository 配置仍然需要它。本地文件夹插件会直接链接到其源文件夹，因此改动会实时生效： devin plugins install --local ./my-plugin → 编辑 skills/<name>/SKILL.md → 改动在下一个会话中生效，无需执行 update。如果 CLI 中已有该插件，但 Customize 中显示内容缺失或已过期，请参阅解决索引问题。 devin plugins update 会刷新本地插件内容；Customize 中的 Reindex plugins 会刷新网页端的列表。通过 --local 安装的插件仅存在于本设备上。

清单

.devin-plugin/plugin.json 用于描述插件。只有 name 是必填项，并且它在已安装插件中必须唯一 (即 /<name>:… 命名空间) 。名称由小写字母和数字组成，可用单个 - 或 . 分隔 (例如 review-tools、acme.tools)。

{
  "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。只有 name 用于插件的身份标识和命名空间；其余字段仅作描述，并由 devin plugins info 显示。

技能和规则

skills 字段用于指定技能的加载位置，替代默认的 skills/ 目录。它接受单个相对于 plugin 根目录的路径，或由此类路径组成的数组：

{ "skills": "custom-skills" }
{ "skills": ["skills", "extra/skills"] }

空数组 ("skills": []) 会完全禁用 skill 加载。路径必须位于 plugin 内部——绝对路径、~ 和 .. 路径遍历均会被拒绝，且任何无效条目都会导致整个清单失效。规则的加载独立于 skills：插件根目录中的 AGENTS.md 始终生效，而 rules/ directory 中的 Markdown 文件会作为触发式规则加载。有关激活详情，请参阅规则。

MCP 服务器

mcpServers 字段可添加 MCP 服务器声明。插件也可使用约定的根目录 .mcp.json (采用 Agent Plugins 根清单布局的插件则使用 mcp.json) 。支持以下四种形式：

// 单个声明文件
{ "mcpServers": "config/mcp.json" }

// 多个文件，按列出的顺序读取
{ "mcpServers": ["config/mcp.json", "config/extra.json"] }

// 仅使用这些文件——禁用根级 .mcp.json / mcp.json 约定
{ "mcpServers": { "paths": ["config/mcp.json"], "exclusive": true } }

// 内联 server 映射（非空时禁用根级约定）
{ "mcpServers": { "linear": { "command": "npx", "args": ["-y", "linear-mcp"] } } }

声明的路径遵循与 技能 相同的包含规则，但会忽略不安全的条目，而不会导致插件失效。无效的 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" }`	位于共享代码仓库子目录中的插件
`{ "source": "github", "repo": "owner/repo", "sha": "3f2a9c1…" }`	固定到某个确切的 commit —— 在你编辑该条目之前不会发生变化
`{ "source": "github", "repo": "owner/repo", "ref": "v2" }`	跟踪某个分支或标签 —— 每次刷新时重新解析

sha 和 ref 适用于所有对象形式 (github、url、git-subdir)，且二者互斥：sha 表示固定，ref 则会浮动。若二者均未指定，source 会跟踪代码仓库的 default 分支。同一代码仓库的所有 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 — 由 Enterprise Admin 配置的账户级托管清单。
Org — 组织级托管清单，分层叠加在其 enterprise 之下 (组织可以在其 enterprise 声明的内容之上添加内容，但不能推翻它) 。云端会话使用该会话所属组织的清单；CLI 和 Devin Desktop 使用你的主组织的清单。
Repo — 检出副本的 .devin/config.json 中的 requiredPlugins / optionalPlugins / forbiddenPlugins，通过从你的工作目录 (在云端会话中，则从每个克隆的代码仓库) 向上遍历来发现。
User — 你通过 devin plugins install (经由你的个人清单同步) 或在本机使用 --local 自行安装的插件。

当你登录时，CLI 会从 Devin Cloud 获取 enterprise、org 和个人清单；Admin 可在 web app 中管理前两者 (参见插件指南)。每个级别都声明相同的三个列表，并且在同一级别内，它们会像单个清单一样，按照相同的拒绝优先、当前用户覆盖规则进行合并。级别在此基础上额外增加的一条规则是：更高权威性优先。

更高权威性优先

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

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

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

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

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

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

冲突与依赖

对于同一个插件，如果在同一级别既有 require 又有禁止，且它们来自不同的清单 (例如两个分别安装的用户级插件) ，则以禁止为准——允许列表只会豁免其自身清单中的条目，因此无法挽回被另一个清单禁止的插件。 (在单个清单内，它自身的 required/optional 仍然不受自身禁止的影响，如上文所述。)
被治理规则阻止的插件会软失败：在会话开始时，其 skills 会被跳过，并给出一条指出禁止发起方的警告，而不是直接中止会话。
被依赖本身并不会带来任何豁免。仅作为传递依赖引入的插件，仍然受所有适用于它的禁止约束，并且会继承所有要求它的插件中的最高权限级别。
出现固定构建冲突——两个清单将同一插件固定到不同的 sha——应通过统一固定值，或将固定权交给权威性更高的级别来解决。
如果在会话开始时无法获取托管清单，该级别会开放失败：其中的内容都不会被安装，且该会话不会强制执行其禁止规则。

入门指南

编辑器集成

扩展性

企业版

参考文档

变更日志

兼容格式

安装插件

管理插件

清单

元数据

技能和规则

MCP 服务器

依赖

`requiredPlugins`

`optionalPlugins`

`forbiddenPlugins`

继承与级别

更高权威性优先

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

冲突与依赖

​兼容格式

​安装插件

​管理插件

​清单

​元数据

​技能 和 规则

​MCP 服务器

​依赖

​requiredPlugins

​optionalPlugins

​forbiddenPlugins

​继承与级别

​更高权威性优先

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

​冲突与依赖

兼容格式

安装插件

管理插件

清单

元数据

技能和规则

MCP 服务器

依赖

`requiredPlugins`

`optionalPlugins`

`forbiddenPlugins`

继承与级别

更高权威性优先

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

冲突与依赖