把 AI 编程助手调教成自己人:OpenCode 的 Skills、Agents 和 Plugin 怎么玩

OpenCode 和其他 AI 编程工具最大的区别，很多人以为是免费、开源、支持多模型。但用了一段时间之后我发现，真正拉开差距的，是它背后那套扩展机制——Skills、Agents、Plugins。

01 开箱即用只是起点

我用 OpenCode 写代码大概四个月。刚装上的感觉和大部分人一样：装好模型，扔进去一个需求，它就开始干活。最初的感觉就是"也就那样"——和 Claude Code 或者 Cursor 差不了太多。

真正的变化发生在第三个月。

当时我在做一个项目，每天要重复好几遍类似的事情：写完代码要审查一遍安全性，改完接口要检查性能和边界情况，提交之前还要确保测试覆盖率达标。每次都要重新描述一遍上下文：帮我看看这段代码的安全问题，注意 OWASP Top 10 那几个点，重点看看鉴权有没有漏……

大概重复了一个星期之后，我终于受不了了。然后我去翻了翻 OpenCode 的文档，才发现它有一套完整的扩展系统。

Skills、Agents、Plugins，三个层级，从轻到重。这套系统我研究了一下午，改写了我的工作流。这篇文章就聊聊这三层分别能干什么，以及怎么搭配着用。

Skills 是这套扩展系统里最轻量的一层。你可以在 ~/.config/opencode/skills/ 里放一些 Markdown 文件，每个文件描述一种任务怎么做。OpenCode 看到这些文件，就会把它们当成"可复用的工作流程"。

拿我自己来举例。我每天都要做代码审查，每次都要手动告诉 AI"注意安全问题、关注性能瓶颈、检查错误处理"。重复多了真的很烦。

所以我自己写了一个 code-review skill，放在 ~/.config/opencode/skills/code-review/SKILL.md 里，大概长这样——前面加了几个必要的配置字段，后面是具体的审查指导。就是把以前手打的那一套话固化下来，AI 能直接读到。

之前	之后
每次手动敲一遍 prompt：帮我看安全性、性能、代码质量	直接 `opencode run --skill code-review`
每次结果不稳定，时好时坏	输出格式统一，检查项固定
队友问我"你是怎么审的"，没法标准化	团队共享同一个 Skill 文件

我后来又把技能拆分了一下，security-review 只查安全，performance-review 只查性能，然后写了一个叫 full-review 的 skill，把前面几项合并成一个综合审查。OpenCode 支持 skill 相互继承，所以不需要在一个文件里堆几百行，拆开写反而好维护。

Skills 最适合的事情：任何你反复对 AI 说的同一类话，都可以写成 Skill。不只是代码审查，commit message 怎么写、API 接口怎么生成、文档怎么组织——都可以。

Skills 搞定了一次性的 prompt 模板。但有些场景需要的是持续对话——一个"人设"从头到尾不跑偏。这时候需要的是 Agent。

Agents 是 OpenCode 里更重的一层。你可以为它指定专门的模型、系统提示词、可用工具，甚至温度参数。不同 Agent 可以配置成不同的"专业角色"。

我做了一个 security-reviewer 的 Agent，配置大概是这样：

模型：claude-sonnet-4-5温度：0.3（低温度，让它少发散）可用工具：read, grep, glob（没有 write，不允许改代码）系统提示：专注 OWASP Top 10、权限校验、加密安全

关键在这里：这个 Agent 没有 write 权限。它只能读代码、搜索代码，但不能改。这意味着我放心地把它交给代码库，让它做安全审查，不用担心它自作主张改东西。

还做了一个 architect Agent，配置完全不一样：

模型：claude-opus-4-5（深度推理更强）温度：0.5（需要一点创造性）可用工具：read, write, grep, glob系统提示：专注系统架构、微服务设计、数据库规划

同一个 Agent 会话里，它可以跟我连聊好几轮——我在改需求，它能记住之前讨论过的架构决策，不会从零开始。

Agents 和 Skills 的搭配方式：Agent 可以加载指定的 Skill 集合。比如我的 security-reviewer Agent，只加载以 security- 开头的 Skill。其他不相关的 Skill 自动屏蔽，减少 Agent 的"选择负担"。

Skills 和 Agents 都是在 OpenCode 的能力范围内工作。但有些场景需要连接外部系统——数据库、部署流水线、第三方 API。这时候就要上 Plugin 了。

Plugin 是 npm 包，用 TypeScript 写，可以注册自定义命令、工具钩子、生命周期事件。

我用过一个叫 opencode-plugin-database 的社区插件，它注册了 db:query、db:migrate、db:seed 三个命令。直接在终端里跑：

opencode db:query "SELECT * FROM users WHERE active = true"

AI 在对话里也能调用数据库工具，直接查表结构来写查询。不用手动切换终端窗口，也不用复制粘贴表名和字段。

不过我目前用得最多的还不是数据库插件，而是部署相关的。我写了一个小插件，对接 Kubernetes 的 API，注册了几个部署相关的命令。流程变成了：AI 写代码 → 我审查 → AI 打包镜像 → AI 触发部署。以前这段流程要不同的工具来回切，现在都塞进 OpenCode 的工作流里了。

Plugin 的开发门槛比 Skills 和 Agents 高不少——你需要会 TypeScript，了解 OpenCode 的插件 SDK。但它的上限也最高。

说了一堆各自能干什么，说点实际的：我现在的开发流程是怎么串这三层的。

第一步：打开 architect Agent，讨论新功能的设计方案。这部分需要深度思考，所以用的是 Opus 模型，温度高一点，接受它给出一些不那么常规的方案。

第二步：切换到 build Agent（OpenCode 默认的干活主力），开始写代码。这时候用 Skill 来加速——比如遇到要写 API 接口，直接调 generate-api Skill，参数传进去，模板化的代码就出来了。

第三步：代码写完之后，跑 full-review Skill 做综合审查。Security、性能、代码质量，一次跑完。

第四步：过一遍测试覆盖率，确保绿了，用部署 Plugin 推送上线。

以前这些步骤分布在至少四个不同的工具里：IDE 写代码、终端跑命令、浏览器查监控、CI 看部署状态。现在虽然不能说完全合并了，但至少 "AI 能做的事情" 和 "我必须做的事情" 分清楚了。

如果你刚接触这套系统，有几点踩坑的经验可以省你不少时间。

先从 Skills 入手，别一上来就搞 Plugin。 写一个 SKILL.md 只需要十分钟，效果立竿见影。Plugin 开发从设计到调试可能要一个下午，不是每个人都值得。

一个 Skill 只做一件事。 我第一个 Skill 写了五十行想涵盖所有审查项，结果 AI 输出变得很泛。拆成三四个小 Skill 之后，每个的输出质量都有提升。

Agent 的工具权限要克制。 安全审查 Agent 不要给 write 权限，架构 Agent 可以给但最好设 ask。我一开始把所有权限都放开了，结果某个 Agent 自己改了代码我还不知道。

模型选型别凑合。 同一个 Agent 换不同模型，表现差距可能很大。Sonnet 适合日常编码，Opus 适合深度推理，轻量模型适合快速任务。别省这点钱。

Skills 存经验，Agents 定角色，Plugins 打通外部系统。 三层的复杂度不同，解决的问题也不同。从一层开始，够了再加。AI 助手不是你装好就完事了，值钱的部分在后面这些调整里。