Roo Code 3.3.13 版本解析DeepSeek R1 × Ollama 兼容、终端上下文菜单与上下文截断策略改进【免费下载链接】Roo-CodeRoo Code gives you a whole dev team of AI agents in your code editor.项目地址: https://gitcode.com/GitHub_Trending/ro/Roo-Code本篇文章聚焦 Roo Code 3.3.13 版本更新说明见 v3.3.13.md中的四项核心变更DeepSeek R1 模型在 Ollama 下的正确运行、集成终端右键菜单支持、面向不支持 prompt caching 模型的滑动窗口截断策略改进以及 API Profile 切换缺陷的初步修复。读完本文你将理解这些修复背后的消息格式转换原理、上下文管理回退机制与配置管理实现并能据此排查同类问题。版本概览Roo Code 3.3.13 是一个以「提供商兼容性 终端体验 上下文稳定性」为核心的增量版本。官方发布说明将其归纳为This release includes provider support updates, terminal improvements, and fixes.具体包含以下 4 项变更变更项类型致谢确保 DeepSeek R1 模型在 Ollama 下正常工作Provider 兼容性修复sammcj启用 Roo Code 集成终端内的右键菜单命令如复制/粘贴终端体验改进samhvw8改进不支持 prompt caching 模型的滑动窗口截断策略上下文管理优化nissa-seru修复与 API Profile 切换相关的首批缺陷后续仍将持续改进Bug 修复—下文将逐项结合仓库源码剖析其实现原理与影响面。一、DeepSeek R1 × Ollama从「能用」到「正确」1.1 问题背景推理模型对消息序列的苛刻要求DeepSeek ReasonerDeepSeek-R1有两个区别于常规 Chat 模型的关键特性导致它与通用消息格式兼容性差不支持连续相同角色的消息相邻两条同为user或同为assistant的消息会导致请求失败或行为异常interleaved thinking交错思考模式API 在返回content与tool_calls的同时会携带reasoning_content并且要求在同一轮次内的后续请求中把reasoning_content原样回传否则推理链会被丢弃。Roo Code 内部统一使用 Anthropic 消息格式建模对话再按提供商做转换。因此要让 DeepSeek R1 在 Ollama 上跑通必须同时解决「格式合并」与「推理内容保序」两个问题。1.2 消息转换层convertToR1Format 的保序合并核心实现在 r1-format.ts。该文件的类型注释直接点明了设计目标/** * Extended assistant message type to support DeepSeeks interleaved thinking. * DeepSeeks API returns reasoning_content alongside content and tool_calls, * and requires it to be passed back in subsequent requests within the same turn. */ export type DeepSeekAssistantMessage AssistantMessage { reasoning_content?: string }convertToR1Format函数在把 Anthropic 消息转换为 OpenAI 格式时执行三类关键操作相邻同角色消息合并连续user消息、连续assistant消息会被拼接为一条满足 DeepSeek Reasoner「不允许连续同角色消息」的约束tool_result → tool 消息把 Anthropic 的tool_result块转换成 OpenAI 的tool消息role: tool并通过tool_call_id与 assistant 的tool_calls一一对应reasoning_content 透传assistant 消息上的reasoning_content会被保留既支持消息顶层字段也支持从content中的reasoning块提取并合并进同角色的相邻 assistant 消息保证推理链不丢失。const assistantMessage: DeepSeekAssistantMessage { role: assistant, content: textParts.length 0 ? textParts.join(\n) : null, ...(toolCalls.length 0 { tool_calls: toolCalls }), // Preserve reasoning_content for DeepSeek interleaved thinking ...(finalReasoning { reasoning_content: finalReasoning }), }对应转换逻辑的单元测试位于 r1-format.spec.ts。1.3 关键开关mergeToolResultText在 deepseek.ts 中Roo Code 针对思考模型启用了mergeToolResultText// For thinking models (deepseek-reasoner), enable mergeToolResultText to preserve reasoning_content // create user messages that cause DeepSeek to drop all previous reasoning_content. const convertedMessages convertToR1Format([{ role: user, content: systemPrompt }, ...messages], { mergeToolResultText: isThinkingModel, })其含义是当tool_result之后还跟着一段文本例如工具返回后的environment_details环境信息时不再单独生成一条user消息而是把文本合并进最后一条tool消息。原因在 r1-format.ts 的注释中有明确说明For DeepSeek interleaved thinking: when mergeToolResultText is enabled and we have tool results followed by text, merge the text into the last tool message to avoid creating a user message that would cause reasoning_content to be dropped. This is critical because DeepSeek drops all reasoning_content when it sees a user message.即DeepSeek 一旦见到新的 user 消息就会清空此前累积的 reasoning_content。Roo Code 是工具调用密集的 Agent 应用每轮工具调用后都会回填环境信息文本若不合并长任务的推理链会反复被重置。1.4 Ollama 侧的实现模型识别与推理标签解析Ollama 原生提供商实现在 native-ollama.ts。其createMessage首先根据模型名判断是否为 R1 系列第 210 行const { id: modelId } await this.fetchModel() const useR1Format modelId.toLowerCase().includes(deepseek-r1)随后针对该模型做了两处适配默认温度R1 推理模型使用DEEP_SEEK_DEFAULT_TEMPERATURE而常规模型默认温度为0第 229 行think 标签解析通过TagMatcher(think, ...)把 Ollama 返回流中think.../think包裹的推理内容解析为reasoning类型的流块与 Roo Code 的推理展示/归档体系对接第 217-224 行。工具调用同样走 Ollama 原生格式convertToolsToOllama会把 OpenAI 格式的工具定义转换为 Ollama 的tools字段并将流式返回的tool_calls以tool_call_partial/tool_call_end事件形式输出兼容 Roo Code 的 NativeToolCallParser。1.5 对用户的意义如果你在 Roo Code 中使用 Ollama 运行deepseek-r1系列模型例如本地拉取的deepseek-r1蒸馏版本3.3.13 之前可能遇到对话上下文被清空、长任务推理断裂、连续消息报错等问题。该版本之后模型名包含deepseek-r1即自动走 R1 适配路径无需额外配置工具调用循环中reasoning_content可持续保留长链路 Agent 任务多次读文件 → 改代码 → 跑命令的思维链不再中途丢失think推理内容在 UI 中按「推理块」展示而非混入正文。注意以上行为基于仓库当前源码src/api/providers/native-ollama.ts、src/api/providers/deepseek.ts不同版本实现可能有差异以实际版本源码为准。二、集成终端右键菜单复制/粘贴终于可用3.3.13 的另一项体验改进是启用了 Roo Code 集成终端integrated terminal内的右键上下文菜单命令如复制、粘贴。这属于终端 Webview 层的交互增强使终端区域的行为与系统/编辑器原生习惯对齐便于在调试过程中快速复制输出或粘贴命令。与终端相关的命令体系可以从 registerTerminalActions.ts 看到 Roo Code 对终端的深度集成终端内容可一键注入 Agent 上下文、请求 Agent 修复/解释命令export const registerTerminalActions (context: vscode.ExtensionContext) { registerTerminalAction(context, terminalAddToContext, TERMINAL_ADD_TO_CONTEXT) registerTerminalAction(context, terminalFixCommand, TERMINAL_FIX) registerTerminalAction(context, terminalExplainCommand, TERMINAL_EXPLAIN) }配合本次右键菜单修复用户在终端中的复制、粘贴操作无需再依赖键盘快捷键直接右键即可完成——这对需要频繁把终端报错粘贴给 Agent 分析的工作流如「把这段报错加入上下文」有明显效率提升。三、滑动窗口截断为不支持 prompt caching 的模型兜底3.1 上下文管理的两级策略Roo Code 的上下文管理Context Management在对话接近上下文窗口上限时采用「先压缩、后截断」的降级链路实现在 src/core/context-management/index.ts首选压缩condensation调用模型对历史消息做摘要压缩后继续对话。摘要能力强的模型支持 prompt caching、具备良好总结能力优先走此路径回退截断sliding window truncation当压缩不可用或失败时退化为滑动窗口截断——从会话开头保留第一条删除一部分最旧的消息。源码中的truncateConversation第 65 行实现了这一回退并记录了明确的函数契约This implements non-destructive sliding window truncation, allowing messages to be restored if the user rewinds past the truncation point.即非破坏性截断被隐藏的消息并不会被物理删除而是被打上truncationParent标记、同时插入一条truncationMarker截断标记用户可以回滚到截断点之前恢复完整上下文。3.2 为何要区分「是否支持 prompt caching」3.3.13 改进的核心是针对不支持 prompt caching 的模型优化截断策略。原因在于两类模型在压缩链路上的成本差异巨大支持 prompt caching 的模型压缩本身可以复用缓存前缀反复调用摘要的成本相对可控不支持 prompt caching 的模型每次摘要调用都要完整重算整个上下文的注意力压缩的开销时间与 token会随对话长度线性放大频繁压缩甚至可能比直接截断更贵、更慢。因此对于不支持 prompt caching 的模型Roo Code 选择在合适的时机直接执行滑动窗口截断而不是陷入「压缩一次 → 很快又满 → 再压缩一次」的高成本循环。3.3 触发时机与默认参数上下文管理模块通过TOKEN_BUFFER_PERCENTAGE第 21 行控制触发时机Default percentage of the context window to use as a buffer when deciding when to truncate. Used by Context Management to determine when to trigger condensation or (fallback) sliding window truncation.即当当前 token 用量逼近「上下文窗口 × (1 - buffer 百分比)」时触发上下文管理若自动压缩被禁用auto-condense关闭或压缩失败则只能依赖截断。实际回退路径中truncateConversation默认按约 50% 的比例fracToRemove: 0.5第 331 行移除可见消息随后重新统计剩余有效消息的 token 数确保截断后的上下文安全落在窗口内。3.4 与 3.3.13 的对应关系发布说明中「Improved sliding window truncation strategy for models that do not support prompt caching」正是对这一决策逻辑的收敛在不支持 prompt caching 的模型上以更积极的截断替代高成本的反复压缩从而稳定上下文窗口、降低延迟与 token 消耗。该策略同时保留非破坏性特性用户仍可回滚查看被截断的历史。四、API Profile 切换 Bug 修复首批4.1 背景Profile 是提供商配置的载体Roo Code 通过 ProviderSettingsManagersrc/core/config/ProviderSettingsManager.ts管理多套 API 提供商配置API Profile。Profile 以加密形式存储在 VS Code 的 secrets 中见write provider profiles to secrets、read provider profiles from secrets相关逻辑支持激活activate、导出/导入与重置激活activateProfile(nameOrId)第 413 行按名称或 ID 切换到指定 Profile导出/导入导出时对providerProfilesSchema做解析并保留退役提供商retired providers的完整字段防止旧字段在迁移中丢失第 507-548 行重置删除 secrets 中的 Profile 数据相当于让用户重新选择有效提供商。4.2 3.3.13 修复了什么发布说明明确指出Implemented initial fixes for bugs related to switching API profiles后续仍有改进计划。结合 Profile 切换链路涉及「激活 → secrets 读写 → 提供商实例重建 → 请求路由」多个环节首批修复大概率覆盖了切换后旧配置残留、secrets 读写时序、Profile 字段校验等易错点。由于说明中明确标注这是「initial fixes」首批修复可以推断该问题在后续版本仍会持续打磨。对于使用者而言若此前在多个提供商 Profile 间切换后出现「请求仍走旧提供商」或「配置未生效」等问题3.3.13 已覆盖其中一部分场景遇到剩余问题时可关注后续版本更新说明。五、总结与升级建议Roo Code 3.3.13 是一个「小版本、深修复」的典型四项变更全部落在 Agent 运行链路的要害位置。变更关键价值相关源码DeepSeek R1 × Ollama本地推理模型可正确参与长链路工具调用思维链不丢失r1-format.ts、native-ollama.ts、deepseek.ts终端右键菜单复制/粘贴回归鼠标操作配合终端动作命令提升调试效率registerTerminalActions.ts滑动窗口截断改进不支持 prompt caching 的模型避免高成本反复压缩上下文更稳定src/core/context-management/index.tsAPI Profile 切换修复多提供商场景下配置切换更可靠首批ProviderSettingsManager.ts升级建议如果你是Ollama DeepSeek R1用户强烈建议升级到 3.3.13 或更高版本并在模型名中保留deepseek-r1字样以触发适配路径如果你使用不支持 prompt caching 的自托管/本地模型且经常触发长对话升级后观察上下文截断行为是否更平稳如果你在多 API Profile 间频繁切换升级后先验证切换是否即时生效如仍有问题可继续跟进后续版本。需要深入验证实现细节的读者可对照 v3.3.13.md 与上文列出的源码路径继续阅读。【免费下载链接】Roo-CodeRoo Code gives you a whole dev team of AI agents in your code editor.项目地址: https://gitcode.com/GitHub_Trending/ro/Roo-Code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Roo Code 3.3.13 版本解析：DeepSeek R1 × Ollama 兼容、终端上下文菜单与上下文截断策略改进
Roo Code 3.3.13 版本解析DeepSeek R1 × Ollama 兼容、终端上下文菜单与上下文截断策略改进【免费下载链接】Roo-CodeRoo Code gives you a whole dev team of AI agents in your code editor.项目地址: https://gitcode.com/GitHub_Trending/ro/Roo-Code本篇文章聚焦 Roo Code 3.3.13 版本更新说明见 v3.3.13.md中的四项核心变更DeepSeek R1 模型在 Ollama 下的正确运行、集成终端右键菜单支持、面向不支持 prompt caching 模型的滑动窗口截断策略改进以及 API Profile 切换缺陷的初步修复。读完本文你将理解这些修复背后的消息格式转换原理、上下文管理回退机制与配置管理实现并能据此排查同类问题。版本概览Roo Code 3.3.13 是一个以「提供商兼容性 终端体验 上下文稳定性」为核心的增量版本。官方发布说明将其归纳为This release includes provider support updates, terminal improvements, and fixes.具体包含以下 4 项变更变更项类型致谢确保 DeepSeek R1 模型在 Ollama 下正常工作Provider 兼容性修复sammcj启用 Roo Code 集成终端内的右键菜单命令如复制/粘贴终端体验改进samhvw8改进不支持 prompt caching 模型的滑动窗口截断策略上下文管理优化nissa-seru修复与 API Profile 切换相关的首批缺陷后续仍将持续改进Bug 修复—下文将逐项结合仓库源码剖析其实现原理与影响面。一、DeepSeek R1 × Ollama从「能用」到「正确」1.1 问题背景推理模型对消息序列的苛刻要求DeepSeek ReasonerDeepSeek-R1有两个区别于常规 Chat 模型的关键特性导致它与通用消息格式兼容性差不支持连续相同角色的消息相邻两条同为user或同为assistant的消息会导致请求失败或行为异常interleaved thinking交错思考模式API 在返回content与tool_calls的同时会携带reasoning_content并且要求在同一轮次内的后续请求中把reasoning_content原样回传否则推理链会被丢弃。Roo Code 内部统一使用 Anthropic 消息格式建模对话再按提供商做转换。因此要让 DeepSeek R1 在 Ollama 上跑通必须同时解决「格式合并」与「推理内容保序」两个问题。1.2 消息转换层convertToR1Format 的保序合并核心实现在 r1-format.ts。该文件的类型注释直接点明了设计目标/** * Extended assistant message type to support DeepSeeks interleaved thinking. * DeepSeeks API returns reasoning_content alongside content and tool_calls, * and requires it to be passed back in subsequent requests within the same turn. */ export type DeepSeekAssistantMessage AssistantMessage { reasoning_content?: string }convertToR1Format函数在把 Anthropic 消息转换为 OpenAI 格式时执行三类关键操作相邻同角色消息合并连续user消息、连续assistant消息会被拼接为一条满足 DeepSeek Reasoner「不允许连续同角色消息」的约束tool_result → tool 消息把 Anthropic 的tool_result块转换成 OpenAI 的tool消息role: tool并通过tool_call_id与 assistant 的tool_calls一一对应reasoning_content 透传assistant 消息上的reasoning_content会被保留既支持消息顶层字段也支持从content中的reasoning块提取并合并进同角色的相邻 assistant 消息保证推理链不丢失。const assistantMessage: DeepSeekAssistantMessage { role: assistant, content: textParts.length 0 ? textParts.join(\n) : null, ...(toolCalls.length 0 { tool_calls: toolCalls }), // Preserve reasoning_content for DeepSeek interleaved thinking ...(finalReasoning { reasoning_content: finalReasoning }), }对应转换逻辑的单元测试位于 r1-format.spec.ts。1.3 关键开关mergeToolResultText在 deepseek.ts 中Roo Code 针对思考模型启用了mergeToolResultText// For thinking models (deepseek-reasoner), enable mergeToolResultText to preserve reasoning_content // create user messages that cause DeepSeek to drop all previous reasoning_content. const convertedMessages convertToR1Format([{ role: user, content: systemPrompt }, ...messages], { mergeToolResultText: isThinkingModel, })其含义是当tool_result之后还跟着一段文本例如工具返回后的environment_details环境信息时不再单独生成一条user消息而是把文本合并进最后一条tool消息。原因在 r1-format.ts 的注释中有明确说明For DeepSeek interleaved thinking: when mergeToolResultText is enabled and we have tool results followed by text, merge the text into the last tool message to avoid creating a user message that would cause reasoning_content to be dropped. This is critical because DeepSeek drops all reasoning_content when it sees a user message.即DeepSeek 一旦见到新的 user 消息就会清空此前累积的 reasoning_content。Roo Code 是工具调用密集的 Agent 应用每轮工具调用后都会回填环境信息文本若不合并长任务的推理链会反复被重置。1.4 Ollama 侧的实现模型识别与推理标签解析Ollama 原生提供商实现在 native-ollama.ts。其createMessage首先根据模型名判断是否为 R1 系列第 210 行const { id: modelId } await this.fetchModel() const useR1Format modelId.toLowerCase().includes(deepseek-r1)随后针对该模型做了两处适配默认温度R1 推理模型使用DEEP_SEEK_DEFAULT_TEMPERATURE而常规模型默认温度为0第 229 行think 标签解析通过TagMatcher(think, ...)把 Ollama 返回流中think.../think包裹的推理内容解析为reasoning类型的流块与 Roo Code 的推理展示/归档体系对接第 217-224 行。工具调用同样走 Ollama 原生格式convertToolsToOllama会把 OpenAI 格式的工具定义转换为 Ollama 的tools字段并将流式返回的tool_calls以tool_call_partial/tool_call_end事件形式输出兼容 Roo Code 的 NativeToolCallParser。1.5 对用户的意义如果你在 Roo Code 中使用 Ollama 运行deepseek-r1系列模型例如本地拉取的deepseek-r1蒸馏版本3.3.13 之前可能遇到对话上下文被清空、长任务推理断裂、连续消息报错等问题。该版本之后模型名包含deepseek-r1即自动走 R1 适配路径无需额外配置工具调用循环中reasoning_content可持续保留长链路 Agent 任务多次读文件 → 改代码 → 跑命令的思维链不再中途丢失think推理内容在 UI 中按「推理块」展示而非混入正文。注意以上行为基于仓库当前源码src/api/providers/native-ollama.ts、src/api/providers/deepseek.ts不同版本实现可能有差异以实际版本源码为准。二、集成终端右键菜单复制/粘贴终于可用3.3.13 的另一项体验改进是启用了 Roo Code 集成终端integrated terminal内的右键上下文菜单命令如复制、粘贴。这属于终端 Webview 层的交互增强使终端区域的行为与系统/编辑器原生习惯对齐便于在调试过程中快速复制输出或粘贴命令。与终端相关的命令体系可以从 registerTerminalActions.ts 看到 Roo Code 对终端的深度集成终端内容可一键注入 Agent 上下文、请求 Agent 修复/解释命令export const registerTerminalActions (context: vscode.ExtensionContext) { registerTerminalAction(context, terminalAddToContext, TERMINAL_ADD_TO_CONTEXT) registerTerminalAction(context, terminalFixCommand, TERMINAL_FIX) registerTerminalAction(context, terminalExplainCommand, TERMINAL_EXPLAIN) }配合本次右键菜单修复用户在终端中的复制、粘贴操作无需再依赖键盘快捷键直接右键即可完成——这对需要频繁把终端报错粘贴给 Agent 分析的工作流如「把这段报错加入上下文」有明显效率提升。三、滑动窗口截断为不支持 prompt caching 的模型兜底3.1 上下文管理的两级策略Roo Code 的上下文管理Context Management在对话接近上下文窗口上限时采用「先压缩、后截断」的降级链路实现在 src/core/context-management/index.ts首选压缩condensation调用模型对历史消息做摘要压缩后继续对话。摘要能力强的模型支持 prompt caching、具备良好总结能力优先走此路径回退截断sliding window truncation当压缩不可用或失败时退化为滑动窗口截断——从会话开头保留第一条删除一部分最旧的消息。源码中的truncateConversation第 65 行实现了这一回退并记录了明确的函数契约This implements non-destructive sliding window truncation, allowing messages to be restored if the user rewinds past the truncation point.即非破坏性截断被隐藏的消息并不会被物理删除而是被打上truncationParent标记、同时插入一条truncationMarker截断标记用户可以回滚到截断点之前恢复完整上下文。3.2 为何要区分「是否支持 prompt caching」3.3.13 改进的核心是针对不支持 prompt caching 的模型优化截断策略。原因在于两类模型在压缩链路上的成本差异巨大支持 prompt caching 的模型压缩本身可以复用缓存前缀反复调用摘要的成本相对可控不支持 prompt caching 的模型每次摘要调用都要完整重算整个上下文的注意力压缩的开销时间与 token会随对话长度线性放大频繁压缩甚至可能比直接截断更贵、更慢。因此对于不支持 prompt caching 的模型Roo Code 选择在合适的时机直接执行滑动窗口截断而不是陷入「压缩一次 → 很快又满 → 再压缩一次」的高成本循环。3.3 触发时机与默认参数上下文管理模块通过TOKEN_BUFFER_PERCENTAGE第 21 行控制触发时机Default percentage of the context window to use as a buffer when deciding when to truncate. Used by Context Management to determine when to trigger condensation or (fallback) sliding window truncation.即当当前 token 用量逼近「上下文窗口 × (1 - buffer 百分比)」时触发上下文管理若自动压缩被禁用auto-condense关闭或压缩失败则只能依赖截断。实际回退路径中truncateConversation默认按约 50% 的比例fracToRemove: 0.5第 331 行移除可见消息随后重新统计剩余有效消息的 token 数确保截断后的上下文安全落在窗口内。3.4 与 3.3.13 的对应关系发布说明中「Improved sliding window truncation strategy for models that do not support prompt caching」正是对这一决策逻辑的收敛在不支持 prompt caching 的模型上以更积极的截断替代高成本的反复压缩从而稳定上下文窗口、降低延迟与 token 消耗。该策略同时保留非破坏性特性用户仍可回滚查看被截断的历史。四、API Profile 切换 Bug 修复首批4.1 背景Profile 是提供商配置的载体Roo Code 通过 ProviderSettingsManagersrc/core/config/ProviderSettingsManager.ts管理多套 API 提供商配置API Profile。Profile 以加密形式存储在 VS Code 的 secrets 中见write provider profiles to secrets、read provider profiles from secrets相关逻辑支持激活activate、导出/导入与重置激活activateProfile(nameOrId)第 413 行按名称或 ID 切换到指定 Profile导出/导入导出时对providerProfilesSchema做解析并保留退役提供商retired providers的完整字段防止旧字段在迁移中丢失第 507-548 行重置删除 secrets 中的 Profile 数据相当于让用户重新选择有效提供商。4.2 3.3.13 修复了什么发布说明明确指出Implemented initial fixes for bugs related to switching API profiles后续仍有改进计划。结合 Profile 切换链路涉及「激活 → secrets 读写 → 提供商实例重建 → 请求路由」多个环节首批修复大概率覆盖了切换后旧配置残留、secrets 读写时序、Profile 字段校验等易错点。由于说明中明确标注这是「initial fixes」首批修复可以推断该问题在后续版本仍会持续打磨。对于使用者而言若此前在多个提供商 Profile 间切换后出现「请求仍走旧提供商」或「配置未生效」等问题3.3.13 已覆盖其中一部分场景遇到剩余问题时可关注后续版本更新说明。五、总结与升级建议Roo Code 3.3.13 是一个「小版本、深修复」的典型四项变更全部落在 Agent 运行链路的要害位置。变更关键价值相关源码DeepSeek R1 × Ollama本地推理模型可正确参与长链路工具调用思维链不丢失r1-format.ts、native-ollama.ts、deepseek.ts终端右键菜单复制/粘贴回归鼠标操作配合终端动作命令提升调试效率registerTerminalActions.ts滑动窗口截断改进不支持 prompt caching 的模型避免高成本反复压缩上下文更稳定src/core/context-management/index.tsAPI Profile 切换修复多提供商场景下配置切换更可靠首批ProviderSettingsManager.ts升级建议如果你是Ollama DeepSeek R1用户强烈建议升级到 3.3.13 或更高版本并在模型名中保留deepseek-r1字样以触发适配路径如果你使用不支持 prompt caching 的自托管/本地模型且经常触发长对话升级后观察上下文截断行为是否更平稳如果你在多 API Profile 间频繁切换升级后先验证切换是否即时生效如仍有问题可继续跟进后续版本。需要深入验证实现细节的读者可对照 v3.3.13.md 与上文列出的源码路径继续阅读。【免费下载链接】Roo-CodeRoo Code gives you a whole dev team of AI agents in your code editor.项目地址: https://gitcode.com/GitHub_Trending/ro/Roo-Code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考