Cline SDK v0.0.94 发布：插件隔离与重试机制升级

Cline 的 SDK 迎来了 v0.0.94 版本更新。本次更新虽然版本号跨度不大，但在插件运行机制、错误重试策略以及模型目录上做了不少实质性调整，尤其是对插件安全边界的收紧，值得开发者关注。

插件运行模式全面收紧

本次更新最显著的变化是插件执行环境的调整。插件现在只在 worker 线程（默认，CLINE_PLUGIN_MODE=worker）或子进程沙箱（sandbox）中运行。原有的 in_process 模式被彻底移除，连同它曾经保留的静默回退机制也一并消失。

这意味着什么？过去如果一个宿主没有正确配置插件沙箱，插件可能悄悄在 hub 进程内运行，这种“兜底”行为虽然方便，却埋下了稳定性和安全性的隐患。现在，如果宿主没有提供 plugin-sandbox-bootstrap.js，每一次插件加载都会失败，并抛出 PluginBootstrapMissingError，错误信息中会明确指向 CLINE_PLUGIN_BOOTSTRAP_PATH 这个环境变量。

hub 守护进程的未捕获错误处理器也重新变为致命级别，不再默默吞掉异常。你可能没注意到，SSH 远程 hub 目前还没有附带 bootstrap，因此它会把插件工具报告为缺失。对于依赖 SSH 远程协作的团队，这可能会带来短期的不便。

worker 线程与子进程沙箱的区别是理解这次改动的前提。worker 线程共享同一进程的内存空间，但拥有独立的 JavaScript 执行栈和事件循环，启动开销小、通信成本低，适合信任度较高、需要频繁与宿主交换数据的插件；而子进程沙箱把插件放进独立的操作系统进程，拥有自己的内存空间与权限边界，即便插件崩溃或越权也较难影响 hub 主进程，代价是进程创建与 IPC 序列化的开销更高。CLINE_PLUGIN_MODE 这个环境变量正是让宿主机在这些隔离级别之间做出显式选择，而不再依赖插件自行判断。

in_process 模式为何危险：在进程内直接执行插件代码意味着插件与 hub 共享同一个 V8 上下文、同一份全局状态和同样的文件系统与网络权限。任何插件里的未捕获异常、内存泄漏、死循环，甚至恶意代码，都会直接波及宿主本身。过去的静默回退机制还有一层更隐蔽的问题：它让宿主以为自己处于隔离状态，实际却运行在无隔离的环境中，安全审计和故障排查都会因此得出错误结论。移除这一回退，实际上是把“隐式安全假设”变成了“显式启动失败”，从而让配置缺失在第一时间暴露。

PluginBootstrapMissingError 的应对方式：plugin-sandbox-bootstrap.js 是宿主为插件准备沙箱运行时的引导脚本，它负责初始化隔离环境并向插件暴露受限的 API。CLINE_PLUGIN_BOOTSTRAP_PATH 用于告诉 Cline 该脚本所在位置。如果你在自建宿主或 CI 环境中看到这个错误，需要确认该环境变量已设置、路径可被 hub 访问，并且引导脚本与 SDK 版本匹配。对于 SSH 远程 hub，由于它当前没有随附 bootstrap，插件工具会被报告为缺失，依赖远程插件能力的团队需要评估这一限制是否可接受。

模型流重试策略更精细

在模型交互层面，v0.0.94 对错误处理做了细化。当一个模型流已经开始后收到的 Provider 错误，现在最多重试 3 次，最终失败会记录到日志和 Langfuse traces 中。

更关键的改动是：重试次数耗尽后，不再额外触发 agent 的整轮重试。这个改动避免了重试预算的“乘法效应”——过去两者叠加可能导致请求被反复放大，浪费资源和时间。同时，模型请求失败的日志现在会包含 Provider 的 request id，便于排查问题。

什么是“重试预算的乘法效应”：假设一次用户请求触发模型流，流内部失败最多重试 3 次，而 agent 在整轮失败后又会重新发起这一轮，于是同一次调用实际可能产生 3 × 3 = 9 次乃至更多的上游请求。如果请求本身因为限流、计费或网络问题注定失败，这种叠加只会成倍放大负载和费用，并让日志中出现大量重复记录。区分“流级重试”和“agent 级重试”的意义在于：前者针对的是网络抖动、Provider 临时 5xx 这类可恢复的瞬时故障，后者针对的是整个任务规划失败，两者的触发条件与代价完全不同，混在一起使用就会失去对重试次数的控制。

Langfuse traces 与 request id 的作用：Langfuse 是一套用于追踪 LLM 应用调用链的可观测性工具，它会把每次模型请求、重试、耗时与错误记录成可检索的 trace。将最终失败写入 traces，意味着开发者可以在事后按会话或请求维度回放失败路径，而不是只看到一条模糊的错误日志。Provider 的 request id 则由上游服务生成，是向 Provider 提交工单或对账时的唯一凭据，把它记入日志能显著缩短“用户报告失败—定位到具体上游请求”的时间。

嵌入宿主与远程连接的改进

对于把 Cline 嵌入到自己产品中的开发者，本次更新提供了几个便利入口。新增的 setHubDaemonLauncher 允许嵌入宿主通过捆绑的 Cline CLI 启动 hub 守护进程；ensureDetachedHubServer 则新增了 beforeSpawn 钩子，只在真正启动新守护进程时运行。

独立的 SSH 远程辅助入口点被移除，SSH 远程现在通过上传的 Cline CLI 来运行 hub。NodeHubClient 开始接受 resolveConnectionHeaders，这样远程代理的 WebSocket 升级可以用每次重连时刷新的 HTTP 头来认证，该能力已贯穿 HubRuntimeHost 和 RemoteRuntimeHost。

另外，AskQuestionExecutor 现在可以返回文本和图像块，因此随答案一起发送的附件能够真正到达模型。@cline/shared 中新增了 buildTelemetrySelfcheckReport 导出。

setHubDaemonLauncher 与 beforeSpawn 钩子的用途：当 Cline 被嵌入到 IDE、桌面应用或其他产品中时，宿主往往已经自带了一份 Cline CLI，希望直接用它来拉起 hub 守护进程，而不是依赖系统中另行安装的版本。setHubDaemonLauncher 正是为此提供的注入点。ensureDetachedHubServer 负责确保有一个脱离当前进程的 hub 在运行，新加的 beforeSpawn 钩子只在确实需要新建守护进程时触发，开发者可以借此在启动前完成端口分配、环境变量注入或日志目录准备，而不必担心复用了已有 hub 时钩子被误触发。

resolveConnectionHeaders 解决的认证问题：远程代理的 WebSocket 升级需要携带认证信息，但 token 往往有有效期。如果只在建连时读取一次请求头，重连时就会使用过期凭据。resolveConnectionHeaders 允许在每次重连时重新计算 HTTP 头，从而支持 token 刷新、签名时间戳这类动态认证方案，并且这套能力在 HubRuntimeHost 和 RemoteRuntimeHost 中保持一致，减少了本地与远程行为分叉带来的调试成本。

模型目录与默认模型大调整

模型目录从 6,862 个刷新到 6,952 个。新增了 Boundless 和 Standard Compute 两个 Provider；SambaNova 现在从目录中获取，默认模型为 MiniMax M3。

Cline 推荐列表新增 Gemini 4 Argon 并移除了 Grok 4.7；免费列表用 Nemotron 3.5 Super VL 替换了 Step 5 Preview。OpenCode Go 不再列出 MiniMax M2.7。

默认模型发生变化的 Provider 相当多：Cortecs、CrossModel、Eden AI、Google Gemini、GitHub Copilot、Google Vertex AI、LLM Gateway、Ofox、OpenCode Go、Prime Inference 现在默认 Gemini 4 Argon；Fireworks AI、Nebius Token Factory、Requesty 转向 Muse Spark Open；CoreWeave、DigitalOcean、NanoGPT、Nvidia 采用 Nemotron 3.5 Super VL；Aixy 和 Neon 使用 Claude Haiku 5.5；Agnes AI、Ambient、IteraCompute、Poe、Scaleway、SenseNova 也有各自调整。此外，cline provider 的捆绑默认模型从 Claude Sonnet 5.5 换成了 Gemini 4 Argon，原因是推荐列表现在以它为首。

模型目录与“默认模型”的关系：模型目录是一份包含各 Provider 可用模型、上下文窗口、定价与能力标记的集中清单，Cline 用它来校验用户配置的模型是否存在、并据此渲染可选列表。默认模型则是当用户或项目没有显式指定模型时实际调用的那一个。因此，目录刷新与默认值变更影响的是两类不同的人群：前者影响能选到什么，后者影响不配置时会用什么。像 Gemini 4 Argon、Muse Spark Open、Nemotron 3.5 Super VL、Claude Haiku 5.5 这类条目，分别代表不同厂商在通用推理、开放权重、多模态与轻量低成本方向上的定位，Provider 切换默认值通常是在成本、延迟与质量之间重新做了权衡。

为什么升级后必须回归验证：默认模型变更不会修改你代码里的显式配置，但会在所有“未指定模型”的调用路径上悄悄改变输出。不同模型在指令遵循、输出格式、工具调用风格和上下文长度上都有差异，尤其是依赖结构化输出或严格 JSON 解析的流程，可能因为模型措辞习惯变化而解析失败。建议在升级前梳理项目中所有隐式依赖默认模型的位置，升级后对这些路径跑一遍端到端测试，必要时把关键链路的模型显式固定下来，避免后续再被目录刷新意外影响。

对开发者的实际影响

这次更新的核心信号很明确：Cline 正在把插件运行的安全边界从“尽力而为”变成“强制约束”。如果你的宿主环境还没有准备好 plugin-sandbox-bootstrap.js，升级后插件会直接不可用。建议在升级前先确认沙箱引导文件的路径配置。

模型默认值的广泛调整也意味着，如果你的项目依赖特定默认模型，升级后需要重新验证输出是否符合预期。整体来看，v0.0.94 是一次偏向稳定性和安全性的版本，适合对插件隔离有要求的团队尽快跟进。