Qwen Code 改进建议

April 5, 2026 · View on GitHub

核心洞察：Qwen Code 已经具备扩展安装与 marketplace 解析基础，能够兼容 Claude/Gemini 扩展格式，也能从 GitHub、本地路径、npm 等来源安装扩展；但 Claude Code 在此之上又构建了一整套“Marketplace 生命周期管理”系统：声明层与状态层分离、启动期后台 reconcile、自动更新、企业策略阻断、缓存与刷新、UI 管理闭环。两者的差距不在“能不能装插件”，而在“是否已经把插件生态做成一个可运维、可治理、可灰度演进的平台子系统”。

返回改进建议总览

一、问题定义：插件系统不只是在本地加载目录

当 Agent 从“可扩展工具”演进为“可分发平台”时，核心问题很快不再是：

能不能加载一个本地插件目录？
能不能识别一个 manifest？

而变成：

生命周期阶段	真实问题
声明	哪些 marketplace 来源是被允许和启用的？
安装	插件和 marketplace 如何在启动时自动补齐，而不是要求用户手动操作？
更新	marketplace 变了以后，插件何时跟着更新？是否需要重启？
治理	企业策略如何阻止某些插件或来源？
缓存	离线时怎么工作？更新失败后如何回退？
UI/CLI	用户如何浏览、管理、移除、刷新、确认状态？

也就是说，真正成熟的 marketplace 系统不是“扩展安装器”，而是：

插件分发 + 同步 + 更新 + 策略治理 + 用户界面的一体化生命周期系统。

这正是 Claude Code 相对于 Qwen Code 的一个明显平台化差距。

二、Claude Code 的做法：把 marketplace 当作一个长期运行的状态系统

Claude Code 在插件生态上最值得注意的，不是“有 marketplace”，而是它把 marketplace 分成了多层次状态，并围绕这套状态构建后台运维逻辑。

1. `marketplaceManager.ts`：声明层（intent）与状态层（materialized state）分离

utils/plugins/marketplaceManager.ts 的开头注释已经把它的职责写得非常清楚：

管理已知 marketplace sources
本地缓存 marketplace manifests
从 marketplace entry 安装插件
跟踪并更新 marketplace 配置

更关键的是，它明确管理两层不同语义的数据：

Declared marketplaces：用户/项目/隐式默认源“声明了哪些 marketplace 应该存在”
Known marketplaces config：当前磁盘上实际 materialized 的 marketplace 状态

源码里甚至直接出现了 DeclaredMarketplace 类型与 getDeclaredMarketplaces()：

支持 implicit official marketplace
支持 sourceIsFallback
支持从 merged settings 和 --add-dir 推导 marketplace intent

这意味着 Claude 的设计不是“读一个配置文件然后直接装插件”，而是：

先确定系统“应该拥有”的 marketplace 集合，再拿它和磁盘真实状态做 diff 与 reconcile。

这是平台化系统常见的控制面设计。

2. 启动期后台 reconcile：`PluginInstallationManager.ts`

Claude 在 services/plugins/PluginInstallationManager.ts 中又向前走了一步：

启动时计算 declared vs materialized 的差异
对缺失或 source changed 的 marketplace 做后台安装
安装过程通过 onProgress 映射到 AppState
安装成功后自动 refresh active plugins
若只是更新则标记 needsRefresh

这个流程有几个很重要的产品含义：

用户无需手动补齐 marketplace
只要 settings / seed dir / implicit declaration 指向了一个 marketplace，系统会尝试在后台使真实状态收敛。
UI 能展示 marketplace 安装状态
pending / installing / installed / failed 这种状态流，不是 loader 层能天然提供的，而是系统专门设计出来的。
更新与首次安装被区别对待
新 marketplace 可能触发自动 refresh；已存在 marketplace 更新则可能只提示 needsRefresh。

这已经非常接近“包管理器 + 控制平面”的感觉，而不是简单的插件扫描器。

3. 自动更新：`pluginAutoupdate.ts`

Claude 还有一层非常平台化的机制：后台自动更新。

utils/plugins/pluginAutoupdate.ts 明确实现了：

先更新 marketplace
再更新这些 marketplace 上已安装的 plugins
按 marketplace 的 autoUpdate 配置控制行为
记录 pending notification
启动时静默执行，不阻塞用户交互

这里的设计非常成熟：

marketplace 的更新不是孤立动作，而会传导到其上的插件版本
autoUpdate 可按 marketplace 配置，而不是全局粗暴开关
更新结果会转化成用户可见通知 / restart-needed 状态

换句话说，Claude 的 marketplace 不是“静态目录索引”，而是一个会持续维护自身一致性的动态系统。

4. 企业策略治理：`pluginPolicy.ts`

utils/plugins/pluginPolicy.ts 的实现虽然短，但战略价值很高：

export function isPluginBlockedByPolicy(pluginId: string): boolean {
  const policyEnabled = getSettingsForSource('policySettings')?.enabledPlugins
  return policyEnabled?.[pluginId] === false
}

这说明 Claude 把插件治理纳入了 managed settings / policy settings 体系：

某些插件可被组织策略强制禁用
阻断不仅影响 UI，还会作用到安装和启用 chokepoint

这类能力对个人用户未必立刻可见，但对企业环境非常关键：

允许哪些插件来源
哪些插件能装、能启用
哪些 marketplace 可 auto-update
如何在组织层做统一控制

5. UI 管理闭环：`ManageMarketplaces.tsx`

commands/plugin/ManageMarketplaces.tsx 表明 Claude 不是只有后端状态系统，还有完整的管理界面：

加载 marketplace 及其已安装 plugins
pending update / pending remove
applyChanges
refresh/remove/autoupdate 管理
graceful degradation 加载 marketplace 数据

这让 marketplace 成为真正可操作的产品功能，而不是隐藏在配置和磁盘里的实现细节。

Claude Code 关键源码：

utils/plugins/marketplaceManager.ts
services/plugins/PluginInstallationManager.ts
utils/plugins/pluginAutoupdate.ts
utils/plugins/pluginPolicy.ts
commands/plugin/ManageMarketplaces.tsx

三、Qwen Code 现状：已具备安装与转换能力，但生命周期管理仍偏“安装器”

Qwen Code 并不是没有 marketplace 相关能力。事实上，它已经有一套相当不错的扩展系统基础。

1. `marketplace.ts`：安装源解析能力已经存在

packages/core/src/extension/marketplace.ts 显示，Qwen 已经支持相当丰富的安装来源处理：

<repo>:<pluginName> 解析
Git URL
owner/repo 自动转 GitHub URL
scoped npm package
本地路径
GitHub .claude-plugin/marketplace.json 获取

这说明 Qwen 并不是“只能本地 link 扩展”，而是已经在做 marketplace source parsing。

从能力层面说，这一步已经超过了很多只支持本地扩展目录的工具。

2. `extensionManager.ts`：扩展容器能力很强

packages/core/src/extension/extensionManager.ts 进一步说明，Qwen 的 extension runtime 其实很完整：

MCP servers
context files
settings
commands
skills
agents
hooks
channels
Claude/Gemini 格式转换

这意味着 Qwen 的“扩展内容模型”并不弱，甚至相当丰富。它并非只是装一个工具，而是可以装进一整套扩展能力包。

3. `extensionSettings.ts`：敏感配置处理已经具备基础

Qwen 在 extensionSettings.ts 中还支持：

user / workspace scope
.env 文件存储
sensitive setting 使用 keychain 存储
安装/更新过程中提示用户填写设置

这说明 Qwen 在“扩展配置落地”上也已经考虑到了安全性与多 scope 管理。

4. 但缺的不是“安装”，而是“持续管理”

问题在于，和 Claude 相比，Qwen 当前更像是：

有一个强大的 extension manager
有 marketplace source parsing
有设置与转换

但还没有明显形成 Claude 那种：

declared vs materialized marketplace diff
启动期后台 reconcile
marketplace → plugin 自动更新传导
policy-backed plugin blocking
needsRefresh / pending status 的完整生命周期状态模型
面向 marketplace 本体的长期管理 UI/后台作业

所以更准确地说，Qwen 当前处于：

扩展安装器/运行时成熟，但 marketplace 生命周期控制平面尚未完整产品化。

四、差距本质：从“可安装扩展”到“可运维平台”的最后一段路

维度	Claude Code	Qwen Code
多来源 marketplace/source 解析	有	有
扩展容器能力	有	有
Marketplace 声明层 vs 状态层分离	明确存在	未见同等级设计证据
启动期后台 reconcile	有	未见同等级证据
Marketplace auto-update → plugin update 联动	有	未见同等级证据
企业策略阻断	有 `pluginPolicy.ts`	未见同等级 chokepoint
管理界面中的 pending/update/remove 生命周期	有	`/extensions` 为主，生命周期治理较弱