Roo Code 3.2 深度解析:更名、自定义模式(Custom Modes)与多模型生态升级

Roo Code 3.2 深度解析:更名、自定义模式(Custom Modes)与多模型生态升级 Roo Code 3.2 深度解析更名、自定义模式Custom Modes与多模型生态升级【免费下载链接】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.2发布于 2025-02-27是该项目的里程碑版本它完成了从 Roo Cline 到 Roo Code 的品牌更名并首次引入了Custom Modes自定义模式功能——允许开发者按任务创建专属的 AI 助手人格、自定义提示词、精确控制每个模式的工具权限。本文以 v3.2 发布说明 为骨架结合仓库源码mode 配置 Schema、CustomModesManager 实现与官方文档 custom-modes.mdx深入讲解该版本的全部特性更名背景、Custom Modes 的配置语法与底层原理、新增的 Bedrock / Gemini 模型支持以及一批 Bug 修复与体验改进读完后你既能复现这些功能也能理解其背后的实现机制。一、版本定位Roo Cline 正式更名为 Roo Codev3.2 发布说明的第一条即宣告品牌更名Name Change From Roo Cline to Roo Code:Rebranded to Roo Code to better reflect its identity.这次更名主要为了更准确地反映产品身份——它不再仅是另一款 Cline 衍生品而是一个独立的 AI 编码助手品牌。更名发生在 v3.2.0 至 v3.2.2 这一系列小版本周期内与 Custom Modes 的引入同期进行因此这一阶段被发布说明归纳为Name Change Custom Modes (v3.2.0 - v3.2.2)两个核心主题。仓库中大量路径与文件名仍能体现这一演进的痕迹例如扩展入口 src/extension.ts、CLI 目录 apps/cli以及各语言包的package.nls.*.json如 package.nls.zh-CN.json均以 Roo Code 身份发布。从源码结构看更名是全局性的包括 packages/core、webview-ui 等所有子包都已统一使用新品牌命名没有残留旧品牌目录。二、核心新特性Custom Modes自定义模式2.1 特性概述v3.2 为 Roo Code 引入了Custom Modes其核心能力如下为 Roo Code 创建自定义人格persona为每个模式定义自定义提示词为每个模式选择可用的工具工具组范围创建专用助手specialized assistants例如文档撰写、测试工程师、重构专家等。发布说明给出了两种上手入口Prompts 标签页Prompts tab直接向 Roo 提问例如输入Create a new mode for ...创建一个新的……模式。后者在官方文档 custom-modes.mdx 的 Ask Roo! (Recommended) 一节被描述为推荐方式完整示例为Create a new mode called Documentation Writer. It should only be able to read files and write Markdown files.Roo 会引导你补全模式所需的各项属性并以 YAML 格式落盘保存。2.2 模式配置结构以源码 Schema 为准自定义模式的配置由 packages/types/src/mode.ts 中的modeConfigSchema严格校验字段定义如下字段是否必填校验规则 / 说明在系统提示词中的位置slug必填必须匹配/^[a-zA-Z0-9-]$/仅允许字母、数字、连字符是模式的唯一内部标识用于关联模式专属规则目录name必填至少 1 个字符是 UI 中显示的名称—roleDefinition必填至少 1 个字符定义模式的核心身份与专业能力置于系统提示词开头whenToUse可选描述该模式适合何种任务供自动决策如 Orchestrator 委派、switch_mode 切换使用—description可选简短的用户友好摘要显示在模式选择器 UI 中模式名称下方—customInstructions可选额外的行为准则追加在系统提示词接近末尾处groups必填允许访问的工具组列表支持元组形式的文件权限限制—source可选由系统自动标记global全局或project项目级不应手动设置—同时customModesSettingsSchema同文件 L113-L131对顶层配置做整体校验明确要求同一份配置中不允许出现重复的 slug否则会返回 Duplicate mode slugs are not allowed 错误。2.3 全局与项目级双文件加载与优先级自定义模式分两个作用域存储见 custom-modes.mdx 与 CustomModesManager 源码全局模式存储在用户设置目录下的custom_modes.yaml文件名常量见 src/shared/globalFileNames.ts对所有项目生效老版本遗留的custom_modes.json在启动时若检测到且不存在 YAML 文件会自动迁移为 YAML。项目模式存储在项目根目录的.roomodes文件YAML 或 JSON 均可仅对当前工作区生效。从 CustomModesManager.ts 的加载逻辑可以看到Roo Code 会同时读取两个来源并在mergeCustomModesL226-L247中合并项目模式.roomodes优先加入结果集全局模式中 slug 不重复的再加入相同 slug 时项目版本完全覆盖全局版本——不是字段级合并而是整体替换。这一项目级优先的设计使团队可以为单个仓库定制code、debug等内置模式的专属版本详见下文覆盖内置模式。同时 src/core/prompts/system.ts 在组装系统提示词时会先查getModeBySlug(mode, customModeConfigs)找不到才回退到内置模式列表——印证了自定义模式在提示词生成链路中处于最高优先级。2.4 工具组与文件权限控制groups工具组枚举定义在 packages/types/src/tool.tsexport const toolGroups [read, edit, command, mcp, modes] as constread读取文件edit编辑文件可附加文件类型限制command执行终端命令mcp调用 MCP 工具/资源modes模式管理相关工具。旧版本使用的browser组已被列入deprecatedToolGroupstool.ts L16groupEntryArraySchema会在校验前自动剥离废弃组从而兼容老用户配置tool.ts L91-L94。文件权限限制是 Custom Modes 最有价值的精细控制手段edit组可以写成元组形式附带fileRegex正则来限定可编辑文件。例如一个文档撰写者模式来自 custom-modes.mdx 的 YAML 示例customModes: - slug: docs-writer name: Documentation Writer description: A specialized mode for writing and editing technical documentation. roleDefinition: You are a technical writer specializing in clear documentation. whenToUse: Use this mode for writing and editing documentation. customInstructions: Focus on clarity and completeness in documentation. groups: - read - - edit # 元组的第一个元素是工具组名 - fileRegex: \.(md|mdx)$ # 第二个元素是限制选项对象 description: Markdown files only等效的 JSON 形式注意 JSON 中反斜杠需双重转义{ customModes: [ { slug: docs-writer, name: Documentation Writer, description: A specialized mode for writing and editing technical documentation., roleDefinition: You are a technical writer specializing in clear documentation., whenToUse: Use this mode for writing and editing documentation., customInstructions: Focus on clarity and completeness in documentation., groups: [ read, [edit, { fileRegex: \\.(md|mdx)$, description: Markdown files only }] ] } ] }fileRegex的匹配对象是相对工作区根目录的完整路径如src/components/button.js默认大小写敏感。groupOptionsSchemamode.ts L9-L29会在加载时用new RegExp(pattern)校验正则合法性非法模式会被拒绝并提示 Invalid regular expression pattern。常用模式示例概念写法YAMLJSON 写法匹配不匹配\.md$\\.md$readme.md、docs/guide.mdscript.js、readme.md.bak^src/.*^src/.*src/app.jslib/utils.js\.(css|scss)$\\.(css|scss)$styles.css、theme.scssstyles.lessdocs/.*\.md$docs/.*\\.md$docs/api/reference.mdguide.md^(?!.*(test\|spec))\.(js\|ts)$^(?!.*(test\|spec))\\.(js\|ts)$app.js、utils.tsapp.test.js、utils.spec.js当模式尝试编辑不匹配fileRegex的文件时会触发FileRestrictionError错误信息包含模式名、允许的文件模式、描述如有、被拦截的文件路径及工具名便于你理解为何被拦截。2.5 覆盖内置模式与配置优先级你可以在全局或项目级用相同 slug覆盖内置模式code、debug、ask、architect、orchestrator其默认定义见 mode.ts L168-L227。例如项目级将code模式限制为只编辑 Python 文件customModes: - slug: code # 与内置 code 模式的 slug 一致 name: Code (Project-Specific) roleDefinition: You are a software engineer with project-specific constraints for this project. whenToUse: This project-specific code mode is for Python tasks within this project. customInstructions: Adhere to PEP8 and use type hints. groups: - read - - edit - fileRegex: \.py$ description: Python files only - command配置应用的完整优先级自高到低见 custom-modes.mdx 的 Configuration Precedence 一节项目级模式.roomodes全局模式custom_modes.yaml其次custom_modes.json内置默认模式。2.6 模式专属指令文件Rules除了customInstructions字段v3.2 起还支持用文件/目录承载模式专属指令详见 custom-modes.mdx 的 Mode-Specific Instructions 一节首选方式目录.roo/rules-{mode-slug}/目录内文件会被递归读取、按文件名不区分大小写字母序追加并自动排除.DS_Store、.swp等系统文件与缓存文件兼容方式单文件.roorules-{mode-slug}仅在目录不存在或为空时兜底全局模式的规则目录位于~/.roo/rules-{slug}/项目模式位于{workspace}/.roo/rules-{slug}/。目录方式的加载优先级高于单文件方式。这些规则与customInstructions字段内容会组合使用文件内容通常追加在字段内容之后既便于版本管理也让非技术成员无需接触 YAML 即可修改指令。2.7 导入 / 导出与删除Custom Modes 支持将模式配置 关联规则文件打包为一个 YAML 文件进行分享、备份与迁移源码实现在 CustomModesManager.ts 的exportModeWithRulesL715-L837 与importModeWithRulesL926-L999导出从 Modes 视图点击导出按钮Roo 会将模式配置连同项目.roo/rules-{slug}/目录下的规则文件打包成 YAML导出时会去掉source属性并把路径统一规范化为正斜杠跨平台可共享。导入点击导入按钮选择 YAML 文件后可选择导入级别Project项目写入当前工作区的.roomodes规则保存到.roo/rules-{slug}/Global全局写入全局设置规则保存到用户主目录的~/.roo/rules-{slug}/。改 slug 再导入导入前修改 YAML 中的 slug导入过程会自动把规则文件路径更新到新 slug 下无需手动改路径。覆盖行为导入与现有模式 slug 相同时现有模式会被整体覆盖。删除删除模式时会同时询问是否删除关联的规则目录并显示确切路径避免误删自定义指令。导出文件的格式custom-modes.mdxcustomModes: - slug: my-custom-mode name: My Custom Mode roleDefinition: You are a helpful assistant. groups: [read, edit] rulesFiles: - relativePath: rules-my-custom-mode/rules.md content: These are the rules for my custom mode.需要说明的是导入/导出等完整管理能力在后续版本中持续演进v3.2 阶段的核心价值是确立了模式配置 规则文件的 YAML 标准化载体与双作用域存储模型。三、Provider 更新新增模型与兼容性选项3.1 Bedrock 新增 Llama 3.3 70B Instructv3.2 为AWS Bedrock提供商新增了Llama 3.3 70B Instruct模型选项发布说明致谢 Premshay。Bedrock 提供商实现在 src/api/providers/bedrock.ts其模型 ID 通常形如meta.llama3-*-70b-instruct-v*:*仓库测试 bedrock-inference-profiles.spec.ts 中可看到同类 ID 的用法。具体可选的模型 ID 依 AWS 区域与 Bedrock 服务端可用性而定配置时以 Bedrock 控制台实际开放的模型 ID 为准。新增该模型的收益是在 AWS 生态内即可使用 Llama 3.3 70B 级别的开源大模型无需单独配置第三方 API。3.2 Gemini Flash Thinking 01-21v3.2 为 Gemini 提供商新增了gemini flash thinking 01-21模型发布说明致谢 monotykamary。该模型的全名在 packages/types/src/providers/vertex.ts 中有对应记录gemini-2.0-flash-thinking-exp-01-21属于 Gemini 2.0 Flash Thinking 实验系列特点是在生成答案前先进行链式思考chain-of-thought适合需要复杂推理的场景。Gemini 提供商的实现位于 src/api/providers/gemini.ts其中 L360-L364 显示模型 ID 若带:thinking后缀会被识别为 Hybrid 思维模式并在请求前剥离后缀——这说明从 v3.2 起Gemini 的推理型模型已纳入标准的思考配置thinkingConfig管线。发布说明同时提到为该模型做了界面视觉修复Visual Fixes for Gemini Flash Thinking Model说明它从 3.2 起即可在 UI 中正常选择与展示。3.3 Azure 复选框OpenAI 兼容提供商的显式开关针对OpenAI 兼容提供商v3.2 新增了一个显式的使用 Azure复选框发布说明致谢 samhvw8。此前用户需要在文本框里手动输入 Azure 端点容易出错现在可以直接勾选让 Roo Code 走 Azure OpenAI 的认证与请求路径。仓库中 OpenAI 兼容链路的实现集中在 src/api/providers/base-openai-compatible-provider.ts 与 src/api/providers/openai-compatible.ts该开关的引入让 Azure 兼容场景如自定义部署名、api-version参数等的配置过程更直观、更不易出错。四、Bug 修复与体验改进QOL逐条解读v3.2 还修复了若干影响日常使用的问题按发布说明逐条说明其影响修复项影响修复打开 Custom Modes 设置 JSON 的 Bug此前从 UI 打开自定义模式配置文件可能失败或路径错误修复后 Modes 页面可正常打开custom_modes.yaml/.roomodes进行编辑回退 API Key 输入事件onChange→onInput部分用户在输入 API Key 时遭遇输入异常/校验过早触发的问题回退到onInput输入事件而非变更事件后输入行为恢复正常致谢 samhvw8Glama 用量上报修复修复了向 Glama 上报用量数据失败的问题致谢 punkpeye确保用量统计准确修复创建新配置 Profile 的 Bug配置档案API Configuration Profiles创建流程恢复正常修复内置模式 roleDefinition 覆盖 Bug此前对内置模式自定义roleDefinition可能不生效修复后自定义模式配置可正确覆盖内置模式其正确性由 mode.ts 的 Schema 与 system.ts 的查询顺序共同保证Diff 工具使用控制现在只有当设置在设置中启用时才允许使用 diff 工具对应实现位于 src/core/tools/ApplyDiffTool.tsdiff 策略在 src/core/diff/strategies避免用户在未启用时误触 diff 流程修复语言选择器 Bug多语言环境下语言切换的显示/选择问题得到修复这些修复大多属于小修小补但显著提升手感的类型API Key 输入回退、Diff 工具开关联动、语言选择器修复直接改善高频操作路径而配置 Profile 创建、内置模式覆盖修复则保障了 v3.2 两大新能力配置档案与 Custom Modes的可用性闭环。五、总结与升级建议Roo Code 3.2 是品牌与能力的双重转折点品牌从 Roo Cline 更名为 Roo Code确立独立产品身份能力Custom Modes 首次落地形成全局/项目双作用域 YAML 配置 工具组/正则权限 规则文件 导入导出的完整自定义框架其配置 Schemamode.ts、文件加载与合并逻辑CustomModesManager.ts、系统提示词接入system.ts至今仍是该功能的核心实现生态Bedrock 增加 Llama 3.3 70B Instruct、Gemini 增加 Flash Thinking 01-21、Azure 开关让 OpenAI 兼容链路更顺手质量一批关键 Bug 修复保证了配置与日常操作的稳定性。升级建议如果你正在使用旧版本升级到 v3.2 后建议优先体验 Custom Modes——从 Ask Roo 创建第一个专用助手如文档撰写或测试工程师模式并用fileRegex为它划定编辑边界如果使用 Bedrock 或 Gemini可分别在对应 Provider 下拉框中确认新模型是否已在当前区域开放。更多自定义模式的最佳实践与完整属性说明可继续阅读仓库内的 custom-modes.mdx 与 使用模式指南 等文档。【免费下载链接】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),仅供参考