Claude Code 插件对本地生态系统构成风险？

如今，一种针对代理任务（agentic work）的复杂扩展分发方式日益流行，即专属于 Claude Code 的 Code 插件。例如，微软开发的 [deep-wiki](https://github.com/microsoft/skills/tree/main/.github/plugins/deep-wiki) 插件，可通过分析项目仓库生成维基百科。它功能强大，远超技能（skill）：用户可以手动通过斜杠命令（如 /deep-wiki:generate、/deep-wiki:ask 等）激活，还能根据请求任务生成不同的子代理（subagent）配置文件，外加 Anthropic 未来可能推出的更多功能。插件的 TLDR（由 LLM 生成）：*技能是一项单一能力：一个包含名称、描述和提示文本的 SKILL.md 文件，当描述与用户请求匹配时，模型会自动调用。插件是一个分发单元——一个包含 plugin.json 清单的目录，将多种不同类型的能力捆绑在一起：技能（自动调用）、斜杠命令（在 /插件名:命令 命名空间下显式调用）和子代理（在各自上下文中生成）。因此，技能和插件并非同一层级的替代品——插件是包，技能是插件可以包含的多个组件之一，此外还有命令和代理。你可以单独分发一个技能而不需要插件，但如果没有插件，你无法分发斜杠命令或命名空间化的能力捆绑包。* 插件支持相当重度的任务，例如 deep-wiki 拥有 3500 行代码，包含大量指导/提示文本和自定义路径，集成在一个完整的包中。但插件并非像 Skills 那样的开放标准，代理应用也难以轻易实现。目前大多数代理应用不支持子代理或自定义斜杠命令，更不用说兼容 Code 插件了。您认为这是否会让 Claude Code 因隐形的供应商锁定而彻底领先竞争对手（更进一步），因为高级用户会专注于 Code 插件？（顺便提一下，我做了些研究，在开源代理中，据我所知只有 Qwen Code 支持安装 Code 插件，甚至可以直接从 Claude 市场安装。阿里巴巴做到了。但这只是一个应用，而且我很少看到有人讨论它。）