Cline 的 VS Code 扩展积累了约 7.6 万行单体 Agent 核心，而 CLI、JetBrains 与 SDK 已转向共享运行时。迁移能消除重复维护，却要直接面对 1100 万用户。更棘手的是，VS Code Marketplace 只有“发布给所有人”这一个开关，不能原生灰度，也不能回退到旧版本。
旧扩展核心与共享 SDK 的迁移关系
#把两个扩展装进一个包
团队在同一发布包中放入 legacy、next 和一个约 46 KB 的加载器。每次窗口启动时，加载器根据缓存的特性开关选择运行时；新版本启动失败就自动切回旧版并固定该机器。开关降到 0% 就是紧急熔断器，而且切换只在下次窗口生效，不会在任务中途换引擎。
两个运行时共享设置、凭据和任务存储。构建流程还生成二者的联合 manifest：公共能力直接通过，仅一侧存在的命令由上下文条件保护，视图或配置 schema 一旦分叉便让构建失败。兼容性不是发布后的希望，而是发布前可执行的契约。
#先给旧系统补观测，再谈 A/B
所有遥测事件都带有 extension_variant。团队先为旧 Harness 补齐与新系统同语义的指标，再把流量缓慢推到接近 50/50，并维持一周以上。整个过程接近一个月；用户占比故意滞后于开关，因为首次更新仍运行旧版，第二次重载才晋级。
双版本灰度期间的真实流量变化
#结果不是主观“更顺”，而是十倍差异
最关键的指标是连续三次工具或编辑失败后触发人工求助的任务比例。旧 Harness 为 6.34%，新 SDK 为 0.62%，下降约十倍。按模型拆分，改善幅度为 6–11 倍，开放权重模型受益尤其明显。
新旧 Harness 的连续错误率对比
原因也很具体：旧系统为 2024 年模型设计，依赖 XML 工具调用和大量防护性提示；2026 年模型已经针对原生工具调用训练，旧 Harness 反而制造解析、重试和上下文税。迁移证明，模型能力会进步，但围绕旧能力假设构建的基础设施不会自动更新。