Roo Code 3.11.5 技术解析Amazon Bedrock 提示词缓存、MCP 工作目录与 API Profile 管理【免费下载链接】Roo-CodeRoo Code gives you a whole dev team of AI agents in your code editor.项目地址: https://gitcode.com/GitHub_Trending/ro/Roo-CodeRoo Code 3.11.5 是 2025-04-03 发布的补丁版本重点为 Amazon Bedrock 增加提示词缓存prompt caching能力、允许为 MCP 服务器单独配置工作目录cwd、向开发者 API 补齐 Profile 管理函数并改进了 diff 编辑体验。本文将逐项解析这些新特性的配置方式与源码实现帮助你充分理解并利用该版本的能力本文引用与核对的代码均来自当前仓库src/、packages/types/等目录可对照源码继续深入。版本概览一次聚焦开发者体验的补丁发布3.11.5 作为 3.11 系列中的一个补丁版本没有引入新的 UI 大改或模型接入而是围绕四件事做精做深成本优化为 Amazon Bedrock 接入提示词缓存降低长会话下的重复输入 token 费用可配置性支持为每个 MCP 服务器指定独立的当前工作目录可编程性在 Roo Code 的 API 中新增 ProfileAPI 配置档的增删改查与切换函数编辑体验对 diff 应用功能、测试与错误提示进行完善。对应社区贡献者包括 Smartsheet-JB-BrownBedrock 缓存、shoopapaMCP 工作目录、gtaylorProfile API、p12ticdiff 编辑、diarmidmackenzie 与 benny123twBug 修复。Amazon Bedrock 提示词缓存长会话成本的优化基石为什么需要提示词缓存在 Roo Code 这类 Agent 产品中每一轮模型调用都会携带系统提示词、历史工具调用记录等大量上下文。上下文越长重复计费的输入 token 越多长任务成本呈线性增长。提示词缓存允许在服务端复用前缀相同的输入内容命中缓存的部分按更低价格计费从而显著压缩长会话成本。源码中的缓存落点在 Bedrock Provider 的请求转换阶段convertToBedrockConverseMessagessrc/api/providers/bedrock.ts负责把 Anthropic 格式消息转换为 Bedrock Converse 格式。该方法接收usePromptCache开关与可选的conversationId当usePromptCache为 false 时直接返回未附加任何缓存标记的消息行为与旧版本完全一致当开启缓存时先将消息交给缓存策略模块计算最优缓存点再向命中的消息内容块追加{ cachePoint: { type: default } }对应 Bedrock Converse 的缓存指令。缓存点落位由独立策略类MultiPointStrategysrc/api/transform/cache-strategy/multi-point-strategy.ts计算其核心决策逻辑为模型能力探测通过modelInfo.cachableFields判断模型是否支持 system / messages 两个区域的缓存系统缓存优先若系统提示词 token 数达到minTokensPerCachePoint阈值则在 system 块末尾放置缓存点消息区多缓存点支持消息缓存的模型会在未缓存 token 超过阈值的位置继续放置缓存点总数量受maxCachePoints约束跨轮一致性Provider 通过previousCachePointPlacements记录上一次的缓存点位置并在下一轮以conversationId为键回传保证多轮对话中缓存点前缀稳定最大化缓存命中率。Provider 侧还同时兼容两套 token 计数字段命名cacheReadInputTokens与cacheReadInputTokenCount等见 src/api/providers/bedrock.ts用于把缓存的读/写 token 计入成本统计并配套 bedrock-native-tools.spec.ts 等测试用例验证缓存链路。整体实现与缓存策略的单元测试位于 src/api/transform/cache-strategy/tests/cache-strategy.spec.ts。使用前提提示词缓存依赖具体的 Bedrock 模型是否支持缓存supportsPromptCache、maxCachePoints等由模型元数据决定同时需要对应的 AWS SDK 版本支持cachePoint内容块。也就是说这是一项模型能力与 SDK 双重依赖的优化并非所有 Bedrock 模型默认生效是否启用由模型配置中的能力位决定代码结构上保留了对不支持缓存模型的完整降级路径。MCP 服务器工作目录让 stdio 服务器跑在正确的位置特性背景MCPModel Context Protocol服务器通过commandargs以 stdio 方式由 Roo Code 拉起此前服务器的进程工作目录与 Roo Code 的当前工作区一致。但对于针对特定仓库目录提供服务的服务器例如读取指定项目的索引、运行项目内脚本的工具固定在工作区根目录并不总是合适。配置方式3.11.5 之后在 MCP 服务器配置中为 stdio 类型新增可选的cwd字段示例配置如下{ mcpServers: { docs-indexer: { type: stdio, command: node, args: [indexer.js], cwd: /path/to/target-project, env: { NODE_ENV: production } } } }源码级校验与默认行为在 src/services/mcp/McpHub.ts 中stdio 服务器配置通过 zod 模式严格校验command必填且不能为空字符串z.string().min(1)cwd可选未显式配置时默认取当前工作区的第一个文件夹路径若工作区不存在则回退到process.cwd()见cwd: z.string().default(() ...)sse/streamable-http类型仍只允许urlheaders与command/args/env/cwd互斥混用会触发明确的校验错误Cannot mix stdio and (sse or streamable-http) fields服务器启动时会把注入后的cwd作为子进程启动目录src/services/mcp/McpHub.tsWindows 下还会自动用cmd.exe包装以正确处理npx.ps1等脚本。也就是说cwd是一个可选、有合理默认值、有严格校验的配置项不写就跟随工作区写了就以指定路径为基准启动服务器进程。API Profile 管理把配置档变成可编程对象特性背景Roo Code 允许保存多个API 配置档Profile每个 Profile 包含 Provider、模型、密钥等一组完整设置用于在不同场景间快速切换。3.11.5 把这一能力开放给了开发者 API此前只能通过 UI 操作现在可以通过RooCodeAPI编程管理。完整函数清单接口定义位于 packages/types/src/api.ts新增的 Profile 相关方法如下函数签名要点行为说明getProfiles()(): string[]返回所有已配置的 Profile 名称列表getProfileEntry(name)(name): ProviderSettingsEntry \| undefined按名称查询 Profile 详情不存在返回undefinedcreateProfile(name, profile?, activate?)(name, profile?, activate true): Promisestring新建 Profile默认创建后立即激活已存在则抛错updateProfile(name, profile, activate?)(name, profile, activate true): Promisestring \| undefined更新已有 Profile默认更新后激活不存在则抛错upsertProfile(name, profile?, activate?)(name, profile?, activate true): Promisestring \| undefined有则更新、无则创建一次调用完成写档deleteProfile(name)(name): Promisevoid按名称删除 Profile不存在则抛错getActiveProfile()(): string \| undefined返回当前激活的 Profile 名称setActiveProfile(name)(name): Promisestring \| undefined切换当前激活的 Profile不存在则抛错编程示例基于上述接口可以用类似下面的代码完成建档—切档流程api为RooCodeAPI实例// 创建并激活名为 claude-sonnet 的配置档 await api.createProfile(claude-sonnet, { apiProvider: anthropic, apiModelId: claude-sonnet-4-20250514, // ... 其他 Provider 设置 }) // 查看当前激活档 const active api.getActiveProfile() // 切换配置档 await api.setActiveProfile(claude-sonnet) // 更新并保持激活 await api.updateProfile(claude-sonnet, { apiModelId: claude-sonnet-4-20250514 }) // 删除不再使用的配置档 await api.deleteProfile(legacy-profile)需要注意的是activate参数默认都为true即默认行为是操作后立即生效若要静默写入不切换需显式传activate: false。相关类型与校验逻辑可进一步参考 src/shared/ProfileValidator.ts含基于 Provider/模型的组织级白名单校验及其测试 src/shared/tests/ProfileValidator.spec.ts。Diff 编辑改进更稳健的应用与更清晰的报错改进内容diff 编辑是本版本的另一条主线涉及功能、测试与错误消息三个维度见 src/core/tools/ApplyDiffTool.ts缺失参数提示path或diff缺失时分别给出明确的缺参错误而非含糊失败访问控制前置应用前先经rooIgnoreController.validateAccess校验目标文件是否被.rooignore规则保护被保护时返回rooignore_error文件存在性检查目标文件不存在时输出格式化错误信息error_details...分步失败信息多段 diff 中部分段落失败时错误信息会携带失败的details与具体原因帮助模型定位是哪一段 diff、为什么失败错误统一上报通过task.recordToolError(apply_diff, formattedError)记录工具级错误便于追踪排查。底层策略与测试diff 应用的核心由多段 search/replace 策略实现src/core/diff/strategies/multi-search-replace.ts针对尾部换行等边界情况还专门编写了回归测试见 multi-search-replace.spec.ts 与 multi-search-replace-trailing-newline.spec.ts覆盖正常替换、尾部换行、逐段失败等场景。对使用者而言最直接的变化是当 diff 应用失败时模型收到的反馈从笼统的错误变成了可定位的明细信息自动修复的成功率因此更高。Bug 修复交互细节的回归收敛本版本还修复了两处影响日常使用的交互问题跟随提问不再抢占焦点修复了 follow-up questions需要用户确认的提问出现时强制夺取输入焦点的问题。此前该行为会打断正在进行的键盘输入或快捷键操作修复后提问以非侵入方式呈现用户可自主选择何时处理。弹出标签页时显示菜单按钮当把 Roo Code 面板拖拽弹出到独立标签页时菜单按钮得以正确显示。此前在弹窗/标签页形态下部分菜单入口缺失导致无法在弹出视图中执行切换模式、查看历史等操作。这两项虽然不涉及架构变化却直接影响高频使用的顺畅度属于典型的小改动、大体验补丁项。小结3.11.5 带给开发者的四件事回顾 3.11.5可以把它的价值归纳为四句话花钱更省Bedrock 提示词缓存配合多点缓存策略为长会话提供了成本优化的工程路径部署更准MCP 服务器可指定工作目录stdio 服务可以挂载到真正需要它的项目上集成更活API 层的 Profile 管理函数让配置档可以纳入脚本化工作流为团队自动化铺路编辑更稳diff 应用的成功与失败信息都更可靠Agent 自主修文件的能力上限随之提高。本文引用的所有实现均可在当前仓库对应路径查阅Bedrock 缓存见 src/api/providers/bedrock.ts 与 src/api/transform/cache-strategy、MCP 校验见 src/services/mcp/McpHub.ts、Profile API 见 packages/types/src/api.ts、diff 相关见 src/core/tools/ApplyDiffTool.ts 与 src/core/diff/strategies。该版本为后续功能迭代奠定了缓存与配置可编程性的基础后续版本在此基础上持续演进。【免费下载链接】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），仅供参考