Roo Code 模式Modes完全指南Code、Ask、Architect、Debug 与 Orchestrator 的用法与底层实现【免费下载链接】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 的模式Modes是一组专业化人格它让同一个 AI 助手在不同任务阶段切换成最合适的角色——写代码、答疑、做架构、调试或统筹委派。本文基于 using-modes.md 展开结合仓库内模式定义、工具组注册与配置校验源码完整讲解五种内置模式的差异、四种切换方式、Sticky Models 持久化机制以及如何通过自定义模式把团队规范固化到工作流中。读完本文你将能按需在模式间自由切换并亲手定制符合项目要求的专属模式。什么是 Roo Code 模式模式是 Roo Code 针对不同任务定制的助手行为集合。每个模式拥有不同的能力范围、专业知识和工具访问级别有的模式可以读写文件、执行命令有的模式只能阅读与提问从而在专注于规划/学习时避免对项目造成意外修改。从源码结构看模式并不是分散在各处的硬编码逻辑而是一组数据驱动的配置。仓库在 packages/types/src/mode.ts 中以DEFAULT_MODES数组集中定义了五种内置模式每个模式由以下字段组成对应modeConfigSchema见 mode.ts字段含义slug模式唯一标识仅允许字母、数字和连字符正则/^[a-zA-Z0-9-]$/name界面显示名如 CoderoleDefinition模式的核心身份与专业定位注入系统提示词开头whenToUse供 Roo 自动化决策如编排委派、模式切换建议参考的场景说明description模式选择器里展示的简短摘要customInstructions附加到系统提示词末尾的行为准则groups该模式可访问的工具组read/edit/command/mcp及文件权限限制运行时src/shared/modes.ts 中的getToolsForMode()会依据模式声明的工具组展开出实际可用的工具清单再叠加ALWAYS_AVAILABLE_TOOLS中所有模式都必须具备的基础工具详见下文工具组与始终可用工具小节。Sticky Models 与模式持久化Roo Code 为每个模式记忆上一次使用的模型。当你从 Code切换到️ Architect时会自动选中该模式上次使用的模型无需手动切换。典型用法是给不同模式分配不同模型️ Architect模式 → Gemini 2.5 Preview Code模式 → Claude Sonnet 3.7这样切模式即切模型规划与写码各自使用最擅长的模型。同时当前选中的模式会在会话之间持久化——重新打开 Roo Code 时会恢复上次使用的模式无需重新选择。为什么需要不同模式任务专业化为当前任务精确获得所需的助手类型安全控制在规划或学习时防止对文件的无意修改例如 Ask 模式完全没有编辑与命令权限交互聚焦响应针对当前活动优化答疑更详尽、架构产出计划、调试走系统化排查流程工作流优化在规划、实现、调试、学习之间无缝过渡全流程都处于合适角色。切换模式的四种方式1. 下拉菜单点击聊天输入框左侧的模式选择器在菜单中选取目标模式2. 斜杠命令在消息开头输入/architect、/ask、/debug、/code或/orchestrator会立即切换到对应模式并清空输入框斜杠命令是常用模式切换的快捷路径更完整的自定义命令机制可参考 Slash Commands 文档。3. 键盘快捷键按下快捷键可按顺序循环所有可用模式到达末尾后回到第一个操作系统快捷键macOS⌘ .WindowsCtrl .LinuxCtrl .4. 接受 Roo 的建议当 Roo 判断当前任务更适合其他模式时会主动弹出模式切换建议附带切换理由。点击Approve批准即完成切换也可以选择拒绝这种建议机制背后是switch_mode工具switch-mode.md 说明它接收mode_slug必填与reason可选两个参数任何模式切换都要求用户明确批准批准后更新界面、按新模式的工具组配置调整可用工具、应用对应提示词并附加约 500ms 延迟确保变更生效。它还允许通过模式内对话直接请求切换例如在 Architect 模式完成规划后调用switch_mode请求用户切到 Code 模式去实现。内置模式详解以下五种内置模式均定义于 packages/types/src/mode.ts 的DEFAULT_MODES其工具组配置与customInstructions直接决定行为表现。Code 模式默认方面详情名称 Code描述精通编程语言、设计模式与最佳实践的资深软件工程师工具访问全部工具组read、edit、command、mcp适用场景编写代码、实现功能、调试和日常开发特殊特性无工具限制对所有编码任务保持完全灵活源码中 Code 模式slug 为code声明了最完整的工具组[read, edit, command, mcp]没有任何fileRegex文件限制。它同时也是仓库的默认模式——在 src/shared/modes.ts 中defaultModeSlug modes[0].slug即取DEFAULT_MODES数组首项。Ask 模式方面详情名称❓ Ask描述专注于提供全面、完整答案的技术助手除非明确要求否则不太会转向实现代码可能使用图表辅助说明工具访问受限访问read、mcp不能编辑文件或执行命令适用场景代码解释、概念探索、技术学习特殊特性面向详尽、信息丰富的回答优化常用图表澄清且不修改你的项目Ask 模式的customInstructions明确要求除非用户明确要求不要切换到实现代码同时允许使用 Mermaid 图表让回答更清晰。它的工具组仅[read, mcp]天然杜绝了对工作区的任何写操作——这正是学习/答疑场景的安全保障。Architect 模式方面详情名称️ Architect描述经验丰富的技术负责人与规划者帮助设计系统并创建实现计划工具访问read、mcp以及受限的edit仅 Markdown 文件适用场景系统设计、高层规划、架构讨论特殊特性遵循从信息收集到详细规划的流程化方法Architect 模式是文件权限限制的典型示例其工具组为[read, [edit, { fileRegex: \\.md$, description: Markdown files only }], mcp]——edit组以元组形式携带fileRegex只允许编辑.md文件。从 src/shared/modes.ts 的FileRestrictionError可以看到若该模式尝试编辑不匹配的文件会抛出包含模式名、允许的文件模式、描述、目标路径与所用工具在内的完整错误信息。此外其customInstructions规定了一套固定工作流先做信息收集 → 向用户提澄清问题 → 用update_todo_list建立可执行的任务清单 → 用 Mermaid 图澄清复杂工作流 → 通过switch_mode请求用户切换到实现模式。它还特别约定绝不提供任务耗时估算只拆解步骤默认把计划文件放到/plans目录。Debug 模式方面详情名称 Debug描述专注于系统性排查与诊断的专家级问题解决者工具访问全部工具组read、edit、command、mcp适用场景追踪 Bug、诊断错误、解决复杂问题特殊特性采用分析 → 缩小可能范围 → 修复的方法论内置自定义指令反思、提炼可能原因、添加日志并在修复前先确认Debug 模式同样拥有完整工具权限但它的差异化体现在customInstructions要求先反思 57 个可能的错误来源收敛到 12 个最可能的原因添加日志验证假设并在修复前明确请用户确认诊断结果。这套流程避免了对问题根源未加验证就贸然改代码。Orchestrator 模式又称 Boomerang 模式方面详情名称 Orchestrator描述战略型工作流编排者又名 Boomerang Mode把复杂任务拆解并委派给专门的模式。详见 Boomerang Tasks工具访问无直接工具访问通过new_task工具把工作委派给其他模式适用场景管理多步骤项目、跨模式协调工作、自动化复杂工作流特殊特性使用new_task工具将子任务委派给其他模式Orchestrator 是唯一一个groups: []的内置模式——它自己不直接触碰任何工具而是靠new_task工具创建子任务。其customInstructions规定将复杂任务拆成逻辑子任务 → 为每个子任务挑选最合适的模式并通过new_task委派消息中必须包含完整上下文、明确范围、仅执行指定工作的约束、要求用attempt_completion汇报结果→ 跟踪所有子任务进度 → 全部完成后综合产出总结。new-task.md 显示new_task接受mode必填子任务的起始模式 slug、message必填和todos可选Markdown 待办清单三个参数父任务在子任务执行期间暂停子任务完成后结果回传、父任务在原模式下恢复。模式背后的源码实现工具组与始终可用工具五种模式声明的read/edit/command/mcp四个工具组在 src/shared/tools.ts 的TOOL_GROUPS中有精确映射工具组包含的工具能力说明readread_file、search_files、list_files、codebase_search文件读取、列出与搜索editapply_diff、write_to_file、generate_image另有edit、search_replace、edit_file、apply_patch为按需启用工具文件修改与创建commandexecute_command、read_command_output终端命令执行mcpuse_mcp_tool、access_mcp_resourceModel Context Protocol 服务器交互另外还有一个不直接暴露给用户的modes组包含switch_mode、new_task它被标记为alwaysAvailable。与此同时ALWAYS_AVAILABLE_TOOLSsrc/shared/tools.ts列出所有模式在任何时候都可使用的基础工具ask_followup_question、attempt_completion、switch_mode、new_task、update_todo_list、run_slash_command、skill。这解释了为什么 Orchestrator 虽然groups为空却依然能够委派任务与维护待办清单。模式的解析与覆盖逻辑src/shared/modes.ts 的getAllModes()展示了自定义模式与内置模式的合并规则以内置模式为基底同 slug 的自定义模式会覆盖内置模式全新 slug 则追加为新模式。getModeSelection()modes.ts则说明提示词组装逻辑优先使用自定义模式的roleDefinition与customInstructions否则以内置模式为基底用promptComponent做局部合并两者都找不到时回退到默认模式。更完整的模式细节含自定义指令、whenToUse、描述通过getFullModeDetails()modes.ts合成其中会调用 src/core/prompts/sections/custom-instructions.ts 的addCustomInstructions()把全局指令、模式专属指令、.roo/rules-{slug}/目录规则、AGENTS.md与通用.roo/rules/规则按顺序拼接到系统提示词中。自定义模式让模式体系适配你的团队除了五种内置模式Roo Code 支持创建全局或项目级自定义模式用于固化团队标准或打造任务专属助手。完整操作指引见 Custom Modes 文档这里给出核心要点创建方式直接让 Roo 创建推荐例如对 Roo 说创建一个叫 Documentation Writer 的模式它只能读文件和写 Markdown 文件Roo 会引导完成其余配置Modes 页面打开 Roo Code 面板 → 点击聊天框下方的模式菜单 → 点击齿轮图标进入 Modes 页面手动填写Name、Slug、Description、Role Definition、Available Tools、Custom Instructions等字段手动编辑配置文件全局模式编辑settings/custom_modes.yaml或custom_modes.json项目模式编辑项目根目录的.roomodes文件YAML 或 JSON 均可。YAML 是推荐格式支持注释与多行字符串。项目级.roomodes示例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配置优先级与覆盖规则模式配置按以下顺序生效高优先级覆盖低优先级且同 slug 完全覆盖、不合并任何属性项目级配置.roomodes全局配置custom_modes.yaml其次custom_modes.json内置默认模式因此你可以用同 slug如code的自定义模式覆盖内置 Code 模式例如把它限制为只能编辑.py文件以强制项目 Python 规范。模式专属规则文件除customInstructions属性外还可通过工作区内的文件/目录为模式注入长篇规则首选目录方式.roo/rules-{mode-slug}/如.roo/rules-docs-writer/目录内文件递归读取、按文件名不区分大小写的字母序合并全局模式则存放在~/.roo/rules-{slug}/兼容方式单文件.roorules-{mode-slug}以及更旧的.clinerules-{mode-slug}目录方式存在且非空时优先于单文件方式文件内容会与customInstructions属性合并通常追加在其后。这套加载逻辑的实现在 src/core/prompts/sections/custom-instructions.ts 中包括按序检查全局/项目目录、符号链接解析与循环防护、以及自动排除.DS_Store、.swp、缓存等系统文件。小结Roo Code 的模式体系可以用一句话概括一个助手五种人格全流程覆盖——规划交给 Architect实现交给 Code疑问交给 AskBug 交给 Debug复杂项目统筹交给 Orchestrator。借助 Sticky Models每个模式还能记住各自偏好的模型借助自定义模式、工具组与fileRegex文件权限你可以把团队规范、安全边界和专属工作流都固化进这一套数据驱动的配置里。深入理解模式的字段与源码实现是精准掌控 Roo Code 行为的第一步。进一步阅读Custom Modes 文档switch_mode 工具说明new_task 工具说明可用工具总览Boomerang TasksOrchestrator 委派详解【免费下载链接】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），仅供参考