【交流会速递】插件按需,QwenPaw 更轻

随着接入渠道和工具增多，未使用的扩展若参与启动加载，会导致额外的初始化和内存开销积累。

目标是让未使用的能力更少占用运行资源，减轻内存压力。

此前平台适配代码与内部实现耦合紧密，修改需理解大量主工程代码且易受影响。

目标是提供清楚、稳定的接入方式，通过明确接口连接宿主，限制修改影响范围。

加载方面：未使用渠道仍参与导入和初始化，造成资源浪费。

接入方面：平台代码与内部实现联系密切，耦合度高。

更新方面：失败处理分散，牵扯范围大，易导致整体不稳定。

开发方面：直接依赖内部对象，接口变动易导致插件不可用。

加载方面：未使用渠道不参与导入，显著减轻内存压力。

接入方面：平台实现放入插件，通过明确接口与宿主连接。

更新方面：统一流程管理，将影响限定在单个插件内，具备兜底恢复机制。

开发方面：提供公开 SDK 模板和测试支持，职责清晰，降低维护成本。

在注册能力（如工具、命令）时记录归属，插件停止时自动撤销对应能力，避免留下失效接口。

插件创建的链接、任务、线程和进程通过托管接口交给框架管理。

停止时确认资源确实结束，若未停止则明确报告状态，防止旧实例叠加占用资源。

新代码先检查再进入切换流程，失败时按统一机制恢复。

任务占用时给予明确提示，确保单个插件更新不影响其他功能。

日常停用与彻底卸载分别处理，更新和重载不会随意覆盖用户已修改的配置和数据。

通过 Plugin Context 向插件提供公开能力，开发者声明所需能力和版本要求。

减少对主程序内部结构的依赖，通过对应接口注册工具、渠道、应用命令等扩展。

提供配套模板，快速建立插件目录和入口，减少摸索工程结构的时间。

复用宿主能力（配置存储、日志、模型），统一构建工具、Channel 和钩子的公开入口。

提供检查器和测试宿主，验证加载、调用、重载和卸载及实际业务流程。

新旧兼容路径同时保留，已有插件可继续正常使用，无需集中重写。

第一步：完善公共插件逻辑，相关重构和 SDK 开发已合并至主仓库。

第二步：将 Channel 拆分为插件化，目前已有相关实现。

第三步：逐步将其他非核心内容插件化，明确每类能力的宿主接口、资源归属和兼容方式。

升级过程兼容原有体验，正常升级即可，无需额外操作。 

保留用户数据和配置，已有的频道沿用原使用方式，安装、卸载流程保持正常。

本次改造的核心是通过插件化实现轻量化，解决未使用扩展的资源占用问题。

新 SDK 和统一资源管理框架旨在降低开发门槛，确保插件生命周期的资源安全与更新稳定。

第一版重点落地 Channel 插件化，并承诺对现有插件和用户数据的完全兼容。

Channel 插件化预期将包含 17 个频道在内的 Channel 模块改为按需安装与启动。

对于从 PyPI、源码或脚本安装的用户，默认采用轻量模式，不安装全部频道及对应的 SDK 依赖。

用户可根据需要在 CLI（命令行）界面选择安装对应 Channel 的依赖并配置使用方式。

插件化改造后，所有频道独立运行，频道连接平台 SDK 和消息收发置于子进程中。

Agent 执行保留在主进程，主进程与子进程通过进程间通信进行协作交流。

每个频道的子进程与主进程复用一套运行环境，仅在频道开启时才导入 SDK 依赖并启动子进程。

开启前仅展示频道列表及配置，无需预先导入所有 SDK，从而降低 QwenPaw 包启动开销及主进程内存占用。

更新旨在尽可能降低用户体感变化，平滑延续原有配置。

系统会保留用户之前启用过的 Channel 配置，并对已启用的频道进行兼容迁移。

用户安装频道插件时，可直接在原来的 QwenPaw 频道页面入口完成安装配置、扫码、授权和启用。

无需前往专门的插件管理页面寻找组件，确保用户在更新前后对 Channel 的使用体感变化不大。

在单工作区的捆绑测试环境下，插件化前后对比显示：运行内存减少了约 35.9%。

启动时间减少了约 48.7%，性能提升显著。

即使只启用钉钉这么一个 Channel，也会带来明显的运行内存和启动时间减少。

随着工作区数量的增加，性能提升幅度预计会更高。

Channel 插件化的核心价值在于通过按需加载和子进程隔离，大幅降低主进程内存占用与启动耗时。

在保障用户配置无缝迁移和操作入口一致的前提下，实现了 35.9% 的内存节省和 48.7% 的启动加速。

已分享内容主要包含插件化重构与在产品上真正实施插件化两个部分。

感兴趣者可关注代表这两部分工作的两个 PR。

后续将在每一个版本逐步将其他非核心内容插件化掉，使其逐渐脱离出来。

目标是解耦它的核心能力架构。

目前比较确定可能包含的内容有：第三方 Harness 或者 MCP、ACP 之类的相关内容。

若想开发新功能，可继续围绕自己的需求去做工具、渠道或继续开发应用插件。

希望公开的接口和开发工具能让这件事更直接，也让插件维护更加的独立。

欢迎已有插件的作者去验证自己的插件在新版中的使用情况。

重点反馈哪一些地方还需要依赖宿主内部的实现。

这些反馈可以帮助把公共接口补得更完整。

欢迎日常使用 QwenPaw 的朋友们反馈升级后的实际使用体验。

特别关注原有的渠道配置插件是否保持正常。

官方已做过测试，保证这一部分是可以正常的。

通过逐步剥离非核心内容（如 MCP、ACP 等）实现核心架构解耦，同时依靠社区反馈完善公共接口，降低对宿主内部的依赖。