模型: openai/gpt-5.4
生成日期: 2026-04-01
书名: Claude Code VS OpenCode：架构、设计与未来
章节: 第22章 — 可扩展性设计
Token用量: 约 6,000 input + 1,940 output
22.2 MCP通用扩展基底
到了 2026 年，一个越来越清晰的建议已经浮现出来：新增能力应当优先做成 MCP server，而不是做成某个框架私有的 plugin。这并不意味着插件会消失，而是说，默认的能力承载层应该优先选择协议化的 MCP，而不是宿主绑定的扩展包。
为什么？因为 MCP 解决的是一个更通用的问题，而插件通常只是在某个宿主内部局部解决问题。传统 plugin 往往深度绑定宿主的生命周期、配置格式、打包方式、权限模型，甚至绑定某种语言生态。换句话说，插件的扩展能力通常是“本地有效”的。MCP 则不一样。它把能力放在协议边界之后，只要不同宿主都理解这个协议，同一个能力实现就可以被多个宿主共享。
这就是为什么 MCP 更适合被理解为一种 universal substrate（通用基底）。这里的 substrate 可以理解成“承载许多上层构造的基础层”。在传统计算机系统里，TCP/IP 成为网络应用的通用底座，POSIX 成为 UNIX 类工具的兼容底座。MCP 想做的是类似的事：把“LLM 主机如何调用外部能力”这件事，变成一个可复用的标准接口，而不是每个生态各写一套。
这种做法至少有四个明显优势。
第一，MCP 是 语言无关的。你可以用 Python、TypeScript、Go、Rust 去实现 server，只要协议讲得对，宿主就能接入。很多宿主私有插件体系，其实默认把开发者绑在某种语言或某种 SDK 上，这会降低生态扩展的自由度。
第二，MCP 是 宿主无关的。只要 OpenCode、OMO、Claude Code、IDE 插件、桌面客户端、未来的新 agent 平台都支持 MCP，那么同一个能力实现就能在多个宿主之间迁移。这种跨宿主复用，会显著降低生态碎片化。
第三，MCP 有 传输灵活性。它既可以本地跑，比如通过 stdio，也可以远端跑，比如通过网络传输。这里的 transport flexibility（传输灵活性）很关键，因为不同能力对部署位置的要求不同。一个高敏感度的 credential broker（凭证代理）可能更适合部署在受控环境里；一个本地代码查询工具则可以贴着开发者机器运行。MCP 让能力放在哪里，变成了一个可设计选项，而不是被插件模型锁死。
第四，MCP 有利于把 能力实现 和 宿主编排 分离。宿主专注于 prompt、session、安全、UI、工作流；MCP server 专注于把某项具体能力做扎实。这样的 separation of concerns（关注点分离）通常能带来更高的复用性和更低的维护成本。
因此，像仓库搜索、Issue 系统、部署控制、数据库查询、企业内部 API、凭证中介、浏览器自动化、观测平台接入这类新能力，越来越适合先做成 MCP server。宿主层当然还可以有 plugin，但这个 plugin 最理想的职责，不是重写整套能力，而是帮助宿主发现、授权、配置、路由到这个 MCP 能力。换句话说，插件变薄，协议层变厚。
这样做还有一个更长远的好处：避免集成逻辑重复。假设每个宿主都为 GitHub、Jira、Linear、Postgres、Browser、内部平台 API 各写一套私有插件，那长期维护成本会非常可怕。MCP 的价值，就在于它把“能力一次实现，多宿主接入”变成现实，从而减少这种平方级复制。
当然，插件仍然有存在空间。MCP 并不能取代所有宿主本地能力。像 hook 接入、UI 扩展、宿主特定命令注册、生命周期管理、设置界面、产品层工作流，这些仍然往往需要插件来做。只是更好的未来结构，应该是“插件负责宿主本地协同，MCP 负责能力本体”，而不是把所有逻辑塞进一个宿主私有插件包里。
OpenCode、OMO、Claude Code 的对比恰好支持这个判断。OpenCode 提供的开放扩展面很适合作为 MCP 的宿主。OMO 的 skill-embedded MCP（技能嵌入式 MCP）尤其有启发：skill 不只是教模型“有什么工具”，还教它“何时以及如何调用这个 MCP 能力”。Claude Code 同样从 MCP 中受益，因为它不需要为每一种外部能力都开放新的原生扩展 API，也仍然能接入大量外部工具。这就是协议层的复用价值。
从战略视角看，私有插件在强化宿主护城河，MCP 在增强生态复利。如果你希望自己做出的能力，不会被某一个宿主生命周期绑定，那么 MCP 几乎总是更稳妥的长期选项。它把“某产品的集成件”变成“多个产品都能消费的基础设施”。
所以，2026 年的最佳实践建议可以说得非常直接：发明一个新能力时，先问它能不能被设计成 MCP server。 只有当这个能力强依赖宿主本地 hook、UI 嵌入、进程内特权能力时，才优先做框架私有插件。即便如此，也最好考虑混合设计：插件尽量薄，重逻辑尽量放到 MCP 后面。
可扩展性的长期方向，通常不是走向更多孤岛，而是走向更稳定的协议基底。MCP 之所以重要，不是因为它流行，而是因为它让 agent 生态终于有机会在一个共享底座上累积能力，而不必在每个宿主里重复造轮子。