“一切皆插件”究竟是一种什么产品哲学

最浅的插件观是“装上一个包，多一个按钮”。更深一层，插件会向环境提供服务、订阅事件、注册工具、增加界面槽位，同时依赖模型、存储、权限或其他插件。它不是孤立文件，而是运行图中的一个节点。

Cordis 用 Context 和 Fiber 追踪这段关系：当依赖满足时插件进入 active；依赖消失时可以回到 pending 或 disposed；插件创建的受控资源由 disposer 清理。DeepSeek Harness 进一步把 Agent preset、模型 provider、工具、session persistence、UI 等大量能力放进插件图。

这对产品架构的启发是：不要把每种客户需求写进 Core。图片生成、视频、画布、行业流程都可以成为受治理的能力贡献。但插件应进入既定对象模型和 UI slot，而不是每个插件都发明自己的根导航、权限体系和数据真源。

DeepSeek Harness 的 Loader 和 Include 本身也是特权插件，但 Node 进程必须先被操作系统启动，bootstrap 必须先创建 Context，再挂载 Loader。配置从哪里读取、模块如何解析、包由谁安装、子进程怎样隔离、JSON-RPC 如何传输，都不会因为口号自动变成普通插件。

这并不是缺点，而是所有动态系统都要面对的事实：可扩展层总要站在一个更小、更稳定的宿主之上。正确做法不是假装地基不存在，而是明确 TCB（可信计算基）的范围、版本、权限和审计责任。

对 LumiClaw 来说，Core 对象、授权、证据账本和发布身份属于稳定宿主；Runtime、Provider、Skill、Renderer 和业务 Pack 可以扩展。越接近业务权威与安全边界，越不应该让任意第三方代码在进程内自由替换。

如果一项能力必须修改 Core 才能发布，平台团队会成为所有客户需求的排队瓶颈。如果能力可以通过稳定协议和 slot 贡献，FDE 团队、合作伙伴和客户团队就能在不分叉底座的情况下交付差异。平台团队负责合同与治理，业务团队负责领域逻辑。

商业上，这让“同一个底座服务很多客户”成为可能：共享 Foundation 的升级节奏，同时按客户组合 Pack、Overlay、Runtime Binding 和 Policy。真正可复用的不是代码片段，而是带版本、权限、兼容性、回滚和证据的能力单元。

但开放生态过早也会放大支持成本。平台在协议不稳定、权限模型不完整、升级回滚没闭环时，应该先做 curated registry：只允许官方或审核过的扩展，先把 Control Center、兼容矩阵和 previous-good rollback 做实，再逐步开放。

Foundation/Core 定义通用事实和执行合同；Official Pack 提供跨客户复用的领域能力；Customer Pack 表达某类客户的扩展；Overlay 只配置品牌、文案、受限策略和数据；Runtime/Adapter 承担外部执行；UI contribution 只能进入宿主批准的 slot。

这套分层的重点不是命名，而是权限。Overlay 不能扩大 Pack 权限，Pack 不能绕过 Core Acceptance，Runtime session 不能成为业务真源，UI bundle 不能直接注入任意 DOM。每层都有允许的输入、输出、升级责任与审计证据。

因此 LumiClaw 可以学习 Harness 的高组合度，却不应该变成一个巨大 plugin graph。我们的主叙事仍然是可交付的 Engagement，而不是插件、进程或聊天。