部署、升级与插件市场：如何同时要灵活、成本和性能

传统 SaaS 假设所有客户共享相近产品和发布节奏；FDE 交付往往需要客户数据源、Runtime、权限和业务流程差异。若每个客户永久 fork 一套代码，短期灵活，长期每次安全修复和底座升级都要重复交付。

正确目标是共享可升级的 Foundation 与合同，而不是强迫所有运行资源共享。客户差异由 Official Pack、Customer Pack、Overlay、Runtime Binding 和 Policy digest 组合成 ReleaseIdentity。

这样平台更新可以沿兼容矩阵传播，客户专属内容不进入开源底座；客户也能明确知道自己消费了哪个 Foundation 和哪些扩展。

Pooled Cell 服务中小客户，共享计算与运维基础，租户数据和权限逻辑严格隔离；Dedicated Cell 为高敏感或高负载客户提供独立 Runtime、数据库或网络边界；On-prem/Edge Cell 进入客户环境，满足强驻留与内网集成。

共享控制面维护 Extension Catalog、Release、Policy template、兼容矩阵和升级波次；数据面按 Cell 运行。控制面不能持有不必要的客户 secret，on-prem 也应以签名 manifest 和离线证据参与升级。

不是所有客户从第一天就选最贵隔离。产品应通过明确的风险分级和迁移路径，让客户随着规模与合规需求升级 Cell，而不是重新购买另一套产品。

市场条目需要 publisher identity、artifact/closure、许可证、capability、permission、data class、compatibility、health、support、EOL 和 incident channel。用户安装前看到权限与成本变化，管理员可以限制 workspace/Engagement scope。

官方扩展由平台承担较强兼容与响应责任；合作伙伴扩展需要认证和 SLA 层级；社区扩展可以只提供研究状态或隔离试用。不要用一个“verified”徽章压平所有责任。

Lumi 的市场可以从 curated registry 开始，优先收录跨客户高价值能力：内容、知识、图片、视频、文档、数据连接和专业 Renderer。生态规模不是首要 KPI，可升级成功率、事故率、复用率和客户交付时长更重要。

第一阶段巩固当前通用 Workbench、稳定导航与 Extension Control Center，只读展示来源、权限、健康和版本。第二阶段建设企业扩展协议、ExecutionSessionRef、repo modes 与 Provider admission。第三阶段选择 DeepSeek Harness 作为一个 optional Runtime 做受控 E2，不影响已有 CLI Runtime。

第四阶段用无名初等真实项目验证 Pack/Overlay 与升级通知：底座持续发布，客户按兼容窗口消费，不让客户开发等待 Foundation。第五阶段才扩大 curated marketplace，并围绕真实交付数据决定图片、视频、画布等优先级。

这条路线保留了长期想象力，却不把今天的产品稳定性押在动态插件生态上。灵活性来自稳定协议，成本优势来自共享 Foundation，性能来自正确 Cell，客户信任来自证据和可恢复性。