夜雨聆风最近排查了一个挺有迷惑性的 OpenCode Desktop 问题。
现象看起来很简单：桌面端能正常打开，`oh-my-openagent` 插件也显示已经加载，但实际进入界面后，只有 OpenCode 原生的两个模式：
一开始很容易误判成“插件没装好”或者“MCP 把启动流程卡住了”。但真正的根因并不在插件注册，也不在 MCP，而是在插件内部初始化阶段。
这篇文章记录一下完整排查过程。
现象：插件显示已加载，但功能没有生效
最关键的一点是，这不是“插件完全没有加载”。
OpenCode Desktop 的插件列表里能看到 `oh-my-openagent`，也就是说：
- `opencode.json` 里的插件配置被读取到了
- 桌面端知道这个插件存在
- UI 层显示它已经注册或加载
但实际功能没有出现。界面里仍然只有：
插件表面显示已加载，但内部初始化失败，导致扩展能力没有注册成功。
这类问题比“完全报错打不开”更麻烦，因为 UI 给了一个看似成功的信号。
第一层问题：数据目录 Junction 断链
最开始桌面端甚至打不开，报错：
```textENOENT: no such file or directory, mkdir 'C:\Users\Administrator\.local\share\opencode'```
```textE:\program\opencode-data\home\.local\share\opencode```
问题是这个 E 盘目标目录不存在。
于是出现了一个很 Windows 的现象：源路径看起来存在，但实际写入时报 “路径不存在”。
修复方式很直接：创建 Junction 的目标目录。修复后 OpenCode Desktop 可以正常打开。
但插件仍然只有 `build / plan`。
第二层问题：插件缓存包不完整
继续看日志：
```textC:\Users\Administrator\.local\share\opencode\log```
发现过这样的错误：
```textENOENT ... packages\shared-skills\skills\frontend-ui-ux\SKILL.mdENOENT ... packages\shared-skills\skills\debugging\SKILL.md```
也就是说，OpenCode 缓存里的 `oh-my-openagent@4.7.5` 包缺少部分 shared skills 文件。
本地另一个缓存包 `oh-my-opencode@4.7.5` 是完整的，于是把完整的：
```textpackages/shared-skills/skills```
同步到了实际加载的：
```textoh-my-openagent@4.7.5```
同步后，缺文件的问题解决了。
但重启后，插件仍然没有完整生效。
第三层问题：排除 MCP
因为配置里有一个本地 MCP：
```json"mcp": {"wiki-kb": {"command": ["python","C:/Users/Administrator/.config/opencode/mcp/wiki-kb/server.py"],"enabled": true,"type": "local"}}```
所以一度怀疑是 MCP 初始化影响了插件加载。
于是先把 MCP 停掉：
```json"enabled": false```
重启后问题仍然存在。
这一步很重要，因为它排除了一个很容易背锅的组件：MCP 不是根因。
真正根因：runtime skills 依赖 Bun.serve
继续看最新日志，终于看到决定性错误：
```textRuntime skill source server requires Bun.servefailed to load plugin```
追到 `oh-my-openagent@4.7.5` 的插件代码后，发现它默认启用了两个 runtime skills：
```textsecurity-researchsecurity-review```
这两个 skill 会启动一个 runtime skill source server，而这个 server 依赖：
```jsBun.serve```
问题在于，OpenCode Desktop 加载插件时，并不是在 Bun runtime 里运行。也就是说，桌面端插件加载环境里没有：
```jsglobalThis.Bun```
于是插件内部初始化失败。
最终形成了这个“假加载”状态：
```text插件配置被读取UI 显示 oh-my-openagent 已加载插件内部初始化失败扩展能力没有注册界面只剩原生 build / plan```
这才是真正根因。
最终修复方案
解决方式是在：
```textC:\Users\Administrator\.config\opencode\oh-my-openagent.json```
中禁用这两个 runtime skills：
```json"disabled_skills": ["security-research","security-review"]```
完整配置中保留原有 `agents`、`categories`、`backgroundTask` 等内容，只新增这一段即可。
然后完全退出 OpenCode Desktop，再重新打开。
这次插件功能恢复正常，不再只剩 `build / plan`。
之后再把 MCP 重新启用：
```json"enabled": true```
也没有影响插件加载。
## 验证结果
运行：
```powershellnpx oh-my-opencode doctor```
最终只剩：
```textGitHub CLI missing```
这个只影响 GitHub 自动化，不影响 oh-my-openagent 插件加载。
最终有效配置是：
```json"plugin": ["oh-my-openagent@4.7.5"]```
以及：
```json"disabled_skills": ["security-research","security-review"]```
MCP 可以保持启用。
这次排障的几个经验
第一，插件“显示已加载”不等于“功能已注册成功”。
很多插件系统会把“配置项存在”或“入口被发现”显示成加载成功，但真正的内部初始化可能已经失败了。这时要看日志。
第二，最新日志比旧错误更重要。
这次过程中先后遇到了目录断链、缓存缺文件、Bun 路径等问题。每修一步，错误都会变化。如果一直盯着旧错误，很容易在已经解决的问题上打转。
第三，桌面端运行时和命令行运行时不一定一致。
即使系统里安装了 Bun，甚至配置了 `BUN_BINARY`，也不代表桌面端插件加载环境里有 `globalThis.Bun`。这类 runtime 差异，在 Electron / Desktop 应用里很常见。
总结
这次问题最有意思的地方，不是某个配置写错了，而是系统处在一种“半成功”的状态：
插件注册成功了，但初始化失败了；
UI 显示加载了，但能力没有注册；
MCP 看起来可疑，但不是根因；
Bun 装了，但桌面 runtime 里没有 `Bun.serve`。
最终修复只是一行配置：
```json"disabled_skills": ["security-research","security-review"]```
security-research 和 security-review 是 oh-my-openagent 里的安全审计类 skills。
security-research：偏主动安全研究/漏洞挖掘。它会组织多个子 agent 去并行检查代码库，寻找潜在漏洞、验证可利用性、区分误报和真实风险，适合做比较深入的安全审计。
security-review：基本是 security-research 的别名/入口，面向“安全 review”这种表达。功能上也是调用同一套安全研究流程。
这两个 skill 在 oh-my-openagent@4.7.5 里是 runtime skills，会启动一个动态 skill source server。这个 server 依赖：Bun.serve
oh-my-openagent@4.7.5 在 OpenCode Desktop 环境中，无条件启用了依赖 Bun.serve 的 runtime skills；但 Desktop 插件加载环境不保证存在 globalThis.Bun。结果不是只让这两个 skill 不可用，而是导致整个插件初始化失败，最终 UI 只剩 build/plan。