# OpenCode 2.0 能给自己写插件了，旧插件怎么办？

**Summary:** OpenCode 2.0 能给自己写插件并热加载，但 V1 扩展需要移植。升级前我会先验证现有集成，再放开后台任务的控制范围。

- Canonical: https://markhuang.ai/zh/news/opencode-2-plugins-need-a-port
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-10-14
- Section: News
- Tags: OpenCode 2.0, 编程 Agent, 插件迁移, 开发者工具, Agent 可靠性
- Source: [Anomaly](https://anoma.ly/notes/opencode-2-0/)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![一台模块化计算设备连接三块玻璃面板，旁边有一枚旧卡带，接口对不上敞开的插槽](https://cdn.markhuang.ai/news/opencode-2-plugins-need-a-port/hero.webp)

*升级的隐喻：运行时更开放了，扩展照样得兼容。*

[Anomaly 发布的 OpenCode 2.0 公告](https://anoma.ly/notes/opencode-2-0/)里有一个承诺很吸引人：agent 可以在一次会话中给自己写插件，写完立刻用上。同一篇公告也说，OpenCode 1.0 的插件在 2.0 里跑不了。升级之前我得掂量一下：扩展 agent 的新路子很诱人，但现有工作流依赖的旧插件还得移植。

方向我认可。但在让 agent 写更多插件之前，我会先把手头工作流依赖的插件移植好。Anomaly 说 2.0 几乎所有功能都做成了内部插件，现在有 80 多个。团队有动力维护好插件 API，但这不等于一个生成的扩展就能保留我想要的权限和工作流。

OpenCode 原本就有客户端和服务端的设计；2.0 把共享后台进程做成了终端、网页和桌面应用的默认模式。升级之后搭集成会更方便，但我也得多查几样东西——整套环境都得过一遍，包括挂上去的插件和脚本。

## 围绕 agent 搭东西，底座更合适了

公告提到了新 API，还有一个能自动发现本地服务的 `@opencode/client` 包。OpenCode 能调自己的 API，连把会话挪到 Git worktree 这种事都能做。后台子 agent 加上异步 shell 命令，跑长任务的时候别的事不用干等。

想围绕编程 agent 搭自定义自动化的开发者，看到这些应该会感兴趣。脚本和终端客户端走同一个服务，自定义自动化跟交互式会话终于有了共用的底座。Jeff Morhous 在[他的独立文章](https://www.augmentedswe.com/p/whats-new-in-opencode-2)里也说了差不多的意思：这些改动让围绕 OpenCode 搭软件变得更顺手。

公告还介绍了 Code Mode，能把 MCP 服务器或 OpenAPI 端点变成 agent 可以用 JavaScript 组合的函数。例子里从 GitHub issue 拉数据，再创建对应的 Linear issue，一个脚本就能把前一个工具的输出喂给后一个工具。这种便利我确实想要，但在给 agent 接入更多服务之前，我还是会先确认它能不能选对操作。

## 旧插件要的不只是改个文件名

[官方迁移指南](https://opencode.ai/v2/docs/migrate-v1/)把主要的破坏性变更说得很清楚：插件、服务端 API 契约、终端配置。指南明确提醒，光把插件文件挪个位置或者改一下配置项的名字是不够的。插件作者需要重新实现。

指南也给老用户吃了一颗定心丸：受支持的 V1 配置、agent 和命令定义、技能、MCP 设置都能继续用，不必急着全部转成原生 V2 配置格式。两个版本共用同一套配置路径，指南建议在验证 V2 的同时保留一份 V1 设置的副本。

这改变了我的升级判断。用标准 agent、配置也在支持范围内的人，可能几乎不用动。但如果你的团队依赖自定义审查插件，或者有脚本在调旧的服务端 API，这些集成就得单独验证。我会在装之前把依赖列清楚，然后逐个检查实际行为，而不是数有多少个文件迁移时没报错。

## provider 挂了会怎样，我会先查清楚

有一个公开报告给了我一个值得查的场景：一个 [GitHub issue 请求 provider 级别的重试协调](https://github.com/anomalyco/opencode/issues/55075)。报告者描述并发会话各自独立重试一个挂掉的 provider，希望有共享的退避策略和熔断机制。我没有复现过这个问题，所以我会拿它来设计检查方案，而不是估算它有多普遍。

共享后台进程让会话更容易被管理，但不一定协调它们怎么处理挂掉的 provider。在依赖后台任务之前，我想先看到 provider 不响应时会发生什么、怎么找到受影响的会话、怎么从另一个客户端中断它们。这些是我在依赖它之前要跑的检查。

自己写的插件也值得同样的审视。[插件文档](https://opencode.ai/v2/docs/build/plugins)暴露了权限评估和工具执行的钩子。一个改动权限决策的扩展，我会比一个改终端外观的扩展查得更仔细。有了热重载，试一个扩展很快，但在留下它之前，我会先看它改了什么。

## 先把工作流搬过去，再考虑扩展

我会从一个熟悉的、边界清楚的任务开始，只接它需要的集成。检查移植过的插件是不是还在执行该执行的规则，自定义客户端能不能跑完正常操作，后台任务能不能找到、能不能中断。配置改动保持小范围，方便和保存下来的 V1 设置做对比。

这和我在[证明 agent 补丁的那篇文章](https://markhuang.ai/news/coding-agents-patch-proof-cost)里说的是同一笔账：生成一个改动和接受一个改动是两件事。OpenCode 能给自己写扩展，让这笔账变得更直接。

我会因为共享运行时和新的扩展 API 考虑 2.0。现有工作流跑对了，我才算升级成功。如果这个工作流依赖某个插件，移植它就是我会让 agent 先做的事。