模型: openai/gpt-5.4
生成日期: 2026-04-01
书名: Claude Code VS OpenCode：架构、设计与未来
章节: 第17章 — 安全模型对比
Token用量: 约 4,880 input + 1,240 output

17.3 供应链安全

一个 agent 平台越可扩展，它就越不可避免地变成一个 supply chain（供应链）问题。插件、技能、命令、MCP server、远程 skill URL、manifest、兼容加载器，这些东西都会提升能力，但同时也在扩大信任面。所谓供应链安全，讨论的其实不是“系统自己写得安不安全”，而是“系统愿意接进来的外部东西安不安全”。

OpenCode 由于天然开放，在这方面暴露得最明显。它允许远程 skill、允许强能力插件、允许 MCP 连接外部服务，这对于生态发展极好，但对于 provenance（来源可信度）要求也更高。provenance 这个词在安全和构建系统里越来越常见，传统 CS 教材里不一定展开很多，它可以理解为“某个扩展资产的来历、来源链条和可追溯性”。如果 provenance 弱，开放生态就容易变成高风险生态。

OMO 继承了 OpenCode 的开放性，还叠加了自己的复杂度。因为它支持跨多种格式发现和兼容加载，所以它的 discovery layer（发现层）同时也是 compatibility layer（兼容层）。兼容性本身当然很好，它降低迁移成本、提高复用率，但也意味着系统必须审查更多来源、更多路径、更多格式。格式越多、入口越多，供应链治理压力就越大。

Claude Code 的整体姿态更保守，但同样逃不开这类问题。只要系统支持 skill、plugin、hook、MCP 这类外部资产，它就必须面对：这些东西由谁提供？怎么审核？怎么更新？激活之后会影响多大范围？商业系统一般会通过更强 schema、更清晰目录结构、更严格默认边界来降低风险。

这里最关键的一点是：不同扩展类型的风险等级并不一样。

Plugin 是可执行代码，风险最高。

MCP server 是外部能力桥，也可能很高风险，取决于它连到什么服务、给了什么权限。

Skill 和 Command 主要是内容型扩展，通常风险更低，但它们仍然可能通过误导性指令、坏流程建议、社会工程式提示，间接把模型带偏。

Manifest 看起来最无害，但如果发现机制本身很松散，manifest 也会成为供应链薄弱点。

在这一点上，OMO 的 skill-guardian 非常值得注意。它隐含了一种非常成熟的观点：安装本身就是安全事件。不是说技能装进来以后再看它干了什么，而是在装之前就应该检查它的来源、用途、风险、必要性。这个思路是对的，因为供应链安全不是激活后再补，而是从准入开始。

从三者对比里，可以提炼出几条很明确的实践原则。

第一，可执行扩展的信任门槛必须高于内容扩展。

第二，远程资产最好有 pinning、checksum、签名或至少显式来源声明。这里的 pinning 指“把依赖固定到一个明确版本或提交”，避免悄悄漂移。

第三，manifest 和 schema 应在激活前被验证。

第四，系统应保留清晰的来源元数据，让用户知道每个扩展从哪里来。

第五，安装流程应该被视为策略控制面，而不是单纯的便利入口。

更大一点看，agent 生态正在越来越像包管理器和浏览器扩展生态。大家都要回答一样的问题：这是谁写的？它能做什么？它如何更新？出了事谁来解释？OpenCode 代表开放生态的创新红利与风险暴露，OMO 代表兼容性进一步放大后的治理难度，Claude Code 则代表更强产品化约束下的收口路线。

随着 agent 平台进入生产环境，供应链安全会越来越成为“玩具扩展系统”和“可上生产扩展系统”之间的分水岭。OMO 的 skill-guardian 已经在往这个方向走，它说明未来的成熟系统，不会只比功能数量，还会比“准入治理”能力。