模型: openai/gpt-5.4
生成日期: 2026-04-01
书名: Claude Code VS OpenCode：架构、设计与未来
章节: 第16章 — 可扩展性对比
Token用量: 约 4,780 input + 1,210 output

16.5 Manifest驱动发现

可扩展性不只是“扩展能不能运行”，还包括“扩展怎么被发现、怎么被识别、怎么被装载”。这就涉及 manifest-driven discovery。所谓 manifest，可以理解为一种显式元数据声明：这个扩展是什么、放在哪、系统应该怎么理解它。它不一定是单独叫 manifest.json 的文件，也可以是 frontmatter、配置块、目录约定等。

OpenCode 的发现机制相对轻量，但非常实用。Skill 通过目录扫描和 frontmatter 识别，Command 可以从配置、MCP prompt、Skill 派生，Plugin 和其他资产也主要通过约定路径与配置完成发现。这种方式不算特别“重规范”，但它有很强的工程实用性：对作者友好、对阅读友好、对实验友好。

轻量 manifest 的一个优势是：它降低了扩展作者的心理门槛。一个 markdown 文件加几行 frontmatter，就是一个 skill；一段配置，就是一个 command。你不需要先建立一个完整的打包和发布流程，才能开始扩展系统。这种低摩擦设计，对开源生态尤其重要。

OMO 在这件事上做得更进一步。它不仅能识别 OpenCode 风格目录，还能兼容 Claude 风格目录、.mcp.json、skill 目录、command 目录等。也就是说，OMO 把 manifest-driven discovery 从“自家资产发现机制”，扩展成了“跨生态兼容机制”。这非常关键，因为它意味着发现系统不只是为自己服务，还能作为生态桥梁，把不同格式的扩展资产吸纳进统一运行时视图。

Claude Code 则更偏向产品结构化约定。插件、agent、hook、skill、MCP 配置通常在固定位置、遵守固定 schema。这样做的好处，是产品可预测性更强，用户也更容易知道“什么装在哪、什么会生效、什么当前处于启用状态”。商业产品天然会偏爱这种更强结构，因为可支持性和可诊断性很重要。

这里有个核心问题：manifest 的“仪式感”应该多强？

太弱，会导致歧义。扩展能被扫到，但不容易验证；命名冲突难处理；错误路径也可能被误加载。

太强，则会抬高创作成本。很多本来应该轻松写出来的小扩展，会因为必须补一堆元数据和打包步骤而变得笨重。

OpenCode 更偏向“低仪式感发现”，OMO 更偏向“广兼容吸纳”，Claude Code 更偏向“高结构清晰”。三者其实代表了三种生态管理策略。

Manifest-driven discovery 还和安全直接相关。只要扩展是通过显式元数据和显式位置被发现的，系统就更容易做 schema 校验、来源检查、重复命名警告、启用前策略审查。相反，如果发现机制完全随意，安全治理就会困难得多。

另一个重要维度是可移植性。OpenCode 愿意扫描相邻生态目录，这是一个非常聪明的反锁定设计。OMO 更进一步，把兼容读取做成系统能力。Claude Code 则更享受标准化目录带来的产品一致性，但相对不那么格式无关。三者没有绝对高下，只是优先级不同。

对未来 agent 平台来说，一个很可能的最佳实践是混合式方案：对 Skill、Command 这类内容型资产，使用轻量 manifest；对 Plugin、MCP 这类可执行扩展，使用更强 schema；同时提供对相邻生态格式的兼容读取器。这样既能保留可用性，又不会牺牲可治理性。

所以，Manifest-driven discovery 看起来像一个偏“工程琐事”的问题，实际上它决定了扩展生态的健康程度。OpenCode 证明了轻量 manifest 也能很好用，OMO 证明了发现系统可以成为互操作层，Claude Code 则说明强结构对于商业稳定性非常有价值。真正好的扩展平台，不只是允许扩展存在，还要让扩展可见、可懂、可管。