我们如何将 1100 万用户迁移至 Cline 史上最大规模的 Harness 升级
Cline 扩展最早诞生于 2024 年，紧随 Claude 3.5 Sonnet 发布之后。它开创了首批被数百万开发者使用的 Agentic Coding 体验之一。自那以后，模型及其在 Agent Harness 中运作的方式都发生了巨大变化。扩展本身也随着 IDE 不断成长，导致底层的 Harness 越来越难以进化。
今年早些时候，我们围绕 Cline SDK 重构了 Cline 的基石，将 Agent Harness 从扩展中剥离出来，打造为一个共享的、模块化的运行时，并借此机会优化了 Harness。我们亲身见证了模型周围的 Harness 对其表现的影响之大，尤其是对于开放权重模型而言。
我们迫不及待地将这个新 Harness 应用于主打的 VS Code 扩展，该扩展已拥有超过 1100 万开发者安装量。但像这样的迁移绝非易事。
我们的第一次尝试耗尽了数月心血，而当最终上线时，问题严重到不得不立即回滚。这迫使我们重新审视不仅是迁移本身，更要思考如何将如此巨大的变更安全地推送给数百万开发者，而不打乱他们每日依赖的工作流。此外，VS Code Marketplace 并未提供逐步发布此类更新的机制。
随之而来的是我们自 Cline 创立以来最大规模的重构，以及为了安全投产而不得不从零构建的发布流程。
以下是我们的操作方式。
我们为何要迁移至 Cline SDK
作为商业决策，这项迁移意味着巨大的投入；若操作不当，还可能导致用户遭遇功能回退和痛点。在快速演进的 AI 编码领域，放慢脚步以确保正确执行，并非我们轻易做出的决定。
Cline 最初只是个 VS Code 扩展，后来陆续推出了 JetBrains 插件、CLI 和 SDK。这些产品形态都依赖同一套核心能力：agent 循环、工具执行、模型供应商对接、上下文管理，以及一个 agent harness 该有的所有功能。
这些新产品都构建在 Cline SDK 之上，唯独最老、用户最多的 VS Code 扩展还在跑自己的私有实现：一个约 76000 行的单体核心。每要改进 agent、接入新的供应商、适配新模型，都得手动改代码、发新版本。
这次迁移就是用 SDK 替换这个单体架构。新模型和新能力几乎每月都在涌现，SDK 能自动完成老核心里大部分需要手动处理的工作。我们需要一个能跟上这个行业变化速度的代码库。
全新的 Cline SDK 还带来了显著的性能提升，对 open-weights 模型尤其明显。以下是我们发布 Cline SDK 时的介绍：
一流的 agent harness。在 Cline 2.0 中，我们大力改进了 harness：重写了提示词、简化了 agent 循环、收紧了上下文管理、改进了反馈回路和错误处理，并重新设计了工具的定义和呈现给模型的方式。这些改进体现在 Cline 的所有产品形态中，因为它们存在于运行时里，而不是某个具体应用中。
Open-weights 模型：
模型 | Cline | Hermes | OpenCode |
DeepSeek V4 Flash | 60.67% | 57.3% | 52.8% |
GLM 5.3 Flash | 64.0% | 56.2% | 61.8% |
Kimi K3 | 82.02% | 71.9% | 76.4% |
DeepSeek V4 Pro | 59.6% | 56.2% | 55.1% |
注：Cline CLI 的得分为 pass@1；N/A 表示在 tbench.ai（terminal-bench 2.0）上，该 agent 与模型的组合没有公开的测试记录。
幸运的是，旧扩展基于 gRPC 构建，它使用一种共享协议的通信系统在核心和 GUI（一个 React webview）之间进行通信。这些组件可以轻松地复用在新版的基于 SDK 的扩展中。用户已经形成肌肉记忆的 UI 通过一个翻译层无缝迁移，该层会将 Cline SDK 的会话事件重新转换回 webview 一直使用的消息类型。
VS Code Marketplace 的局限
Marketplace 只提供一个发布开关：一旦发布，所有 100% 的用户都会立刻获得更新。
你甚至无法回退到更低版本。版本号是严格单调递增的，无论发生什么，你只能向前推。如果某次发布出了问题，唯一的补救措施是准备一个新的高版本号发布，然后等待机群完成更新：这是一个以小时甚至天为单位的循环，而不是分钟。
尽管缓慢推送（slow rollout）在其他地方是标准软件实践，但 VS Code 扩展并不原生支持这种机制。你发布新版本，所有人都立即获得：没有逐步推送，没有测试组，也无法即时撤回。
顿悟时刻：如果我们在一个包里捆绑两个扩展呢？
为了绕过这一限制，我们在同一个发布包中捆绑了扩展的两个版本：原有的旧版本和新的新版本。我们让扩展本身成为推送机制。安装 Cline 实际上会安装三个部分：
- 一个约 46 KB 的加载脚本
legacy/，即迁移前的原始扩展next/，即基于新 SDK 的扩展
每次窗口启动时，加载脚本会根据缓存状态决定激活哪个包，这一过程由 PostHog 功能标志（feature flag）控制的百分比推送机制驱动。具体流程如下：
- 功能标志关闭的用户运行旧扩展；标志打开则运行迁移后的扩展。 旧组（legacy cohort）获得的是与迁移前完全相同的代码，因此生产环境中任何现有用户的体验都不会发生变化或出现故障。这就是我们的对照组，我们会通过开启标志并逐渐提高百分比来扩大新版本的覆盖范围。
- 如果新版扩展崩溃，系统会自动回退。 当
next在激活阶段失败时，加载器会在同一窗口启动旧版并将该机器锁定在legacy状态。用户能继续使用功能正常的产品，同时我们记录崩溃数据到遥测系统。 - 该标志位是紧急制动开关。 如果出现问题，我们可以立即将发布率降至 0%。
- 状态是共享的。 两个 bundle 都读写相同的设置、凭据和任务存储，因此在不同用户组之间切换时，数据可以完整往返。
- 标志位刷新在激活后的后台进行，并在下一个窗口生效。 用户的 Agent 不会在任务执行中途在引擎层面发生切换。
最关键的一点是：legacy 和 next 必须向 VS Code API 暴露完全相同的视图和扩展生命周期入口点，否则包根本无法构建。VS Code 扩展通过 package.json 清单静态声明大部分 IDE 集成细节：包括它们贡献的侧边栏和视图、命令、快捷键、设置架构以及激活事件。由于每个扩展只能有一个清单，我们的构建过程会从两个 bundle 中生成一个联合清单。两个 bundle 都声明的贡献会直接通过；仅在某个 bundle 中存在的命令会被加载器设置的 context key 所门控；如果两个分支的视图或设置架构发生分歧，构建会直接失败。这种构建时的契约保证了在重载时两个代码库可以互换，同时它们都在同一个 package.json 后面运行。
A/B 测试，以及数据、数据、数据
安全发布只是问题的一半；证明新引擎更优是另一半。来自发布构建的每个遥测事件都带有 extension_variant: next | legacy 标识。
我们花了大量时间确保从旧扩展和新扩展捕获的遥测事件具有可比性，这包括为我们的旧版 harness 添加大量事件和指标可观测性。对于任何进行此类迁移的团队，我们建议：在对系统进行比较之前，先为旧系统埋点。
在这项工作之后，我们搭建了一个严格的并排监控面板，实时观察新旧 harness 上最关键的事件。
比如最重要的指标是 task.mistake_limit_reached，这是老 harness 留下的机制：agent 连续犯三次错误就会停下来，直接向用户求助。这是老 harness 中被抱怨最多的 agent 行为，而其中很多错误其实源于 harness 本身的低效导致的工具调用失败。我们一直在新版 SDK harness 中追踪这个指标，但老版扩展里却没有。把语义完全相同的这个指标加到老 harness 上后，我们就能对这一行为做出干净的对比。
为了拿到足够可信的信号，我们花了将近一个月时间逐步提高新版本用户的比例，同时观察面板上的量化数据和 GitHub 上的定性反馈。我们在 50/50 的比例上保持了一周多——这是最干净的 A/B 观测窗口——随后把比例拉到 100%。
图中观察到的占比刻意滞后于灰度开关：每次更新后的第一个窗口仍运行旧版，升级在第二次重载时才生效。机制慢，正是机制安全的体现。同样的滞后也解释了拉到 100% 之后的尾巴：剩余的旧版占比来自尚未更新或重载的机器，每天都在缓慢减少。
结果
最清晰的改善指标就是 task.mistake_limit_reached，它衡量模型连续犯三次错误（格式错误的工具调用、失败的编辑、无效回复）导致 Cline 停下来向你求助的频率。在两组接近 50/50、各自经历了一整天生产流量之后，这类情况的发生频率如下：
老 harness 上有 6.34% 的任务触达错误上限 → 新 harness 上只有 0.62%。出错任务减少了 10 倍。
模型 | 老 harness | 新 harness | 降幅 |
|---|---|---|---|
claude-sonnet-5（直连 API） | 6.7% | 0.63% | 11x |
deepseek-v4-flash（直连 API） | 13.4% | 1.30% | 10x |
deepseek-v4-pro | 11.5% | 1.14% | 10x |
claude-sonnet-4-6 | 4.0% | 0.62% | 6x |
gpt-5.6-sol | 4.1% | 0.70% | 6x |
相比旧 Harness 的改进
旧 Harness 的代码本身并不差，它更像是一个时代的缩影。它是为不同的年份构建的，而我们认为这是故事中最具普适性的部分——在快速变化的 AI 领域，这同样适用于 Cline 之外。Cline 最初的 Harness 设计于 2024 年中旬，围绕当时最强的编码模型 Claude 3.5 Sonnet 打造。那年代的模型确实需要大量辅助。工具在系统提示词中描述，并通过解析模型文本流中的 XML 标签来调用，因为这是从 2024 年的模型中获取工具调用的可靠方式。该 Harness 进行了防护、补偿，并事无巨细地说明了所有事项。
2026 年的模型已通过强化学习（RL）训练，能够原生调用工具。若将其包裹在 2024 年风格的 Harness 中，每一轮都会产生额外开销：格式问题、解析失败、重试以及最终的错误上限。将 Cline 的所有界面迁移到升级后的 Harness，并使其成为表现最好的开放权重模型，是必须迈出的一步。这也是我们在此次旅程中格外谨慎且细致入微的原因。
我们的旅程并未就此止步。我们始终致力于成为开放权重模型的最佳 Harness，并不断反思与改进。我们还深入研究了递归自我改进，以确保我们的 Harness 始终是开放权重模型的前沿探索。详情参见这里。致谢
感谢所有帮助我们报告问题的用户，感谢参与 Google Meet 并与我们分享工作流及故障细节的用户，感谢协助调试回归问题的用户，以及提供反馈以确保平稳上线的用户。Cline 由我们建立，也为我们卓越的社区而建；没有你们，我们将一无所有。
8月23日起，该升级已全面推送至100%：每个更新并重新加载的 Cline 窗口现在都运行基于 SDK 的扩展程序，而现有的传统会话则会随着机器的更新逐步迁移。扩展程序现运行在与 CLI 和 SDK 相同的引擎上。因此，所有智能体改进、新工具，以及新提供商与模型功能都能更快地上线并修复，覆盖我们的全线产品。虽然此次迁移需要停用部分使用频率较低的功能（点击此处查看完整列表），但这次升级是一次艰难而成功的转型，将原有的 Cline 迁移到了为当前模型打造的运行框架上。我们期待您能感受到在 token 效率、成本降低以及结果优化方面的显著差异，并继续与我们一同前行，保持持续改进。