企业官网建设流程全解析

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-Code

Roo Code 的模式（Modes）是一组"专业化人格"，它让同一个 AI 助手在不同任务阶段切换成最合适的角色——写代码、答疑、做架构、调试或统筹委派。本文基于 using-modes.md 展开，结合仓库内模式定义、工具组注册与配置校验源码，完整讲解五种内置模式的差异、四种切换方式、Sticky Models 持久化机制，以及如何通过自定义模式把团队规范固化到工作流中。读完本文，你将能按需在模式间自由切换，并亲手定制符合项目要求的专属模式。

什么是 Roo Code 模式

模式是 Roo Code 针对不同任务定制的助手行为集合。每个模式拥有不同的能力范围、专业知识和工具访问级别：有的模式可以读写文件、执行命令，有的模式只能阅读与提问，从而在"专注于规划/学习"时避免对项目造成意外修改。

从源码结构看，模式并不是分散在各处的硬编码逻辑，而是一组数据驱动的配置。仓库在 packages/types/src/mode.ts 中以DEFAULT_MODES数组集中定义了五种内置模式，每个模式由以下字段组成（对应modeConfigSchema，见 mode.ts）：

运行时，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. 键盘快捷键

按下快捷键可按顺序循环所有可用模式，到达末尾后回到第一个：

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 模式（slug 为code）声明了最完整的工具组["read", "edit", "command", "mcp"]，没有任何fileRegex文件限制。它同时也是仓库的默认模式——在 src/shared/modes.ts 中defaultModeSlug = modes[0].slug，即取DEFAULT_MODES数组首项。

Ask 模式

Ask 模式的customInstructions明确要求"除非用户明确要求，不要切换到实现代码"，同时允许使用 Mermaid 图表让回答更清晰。它的工具组仅["read", "mcp"]，天然杜绝了对工作区的任何写操作——这正是"学习/答疑"场景的安全保障。

Architect 模式

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 模式同样拥有完整工具权限，但它的差异化体现在customInstructions：要求先反思 5～7 个可能的错误来源，收敛到 1～2 个最可能的原因，添加日志验证假设，并在修复前明确请用户确认诊断结果。这套流程避免了对问题根源未加验证就贸然改代码。

Orchestrator 模式（又称 Boomerang 模式）

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中有精确映射：

另外还有一个不直接暴露给用户的modes组（包含switch_mode、new_task），它被标记为alwaysAvailable。与此同时，ALWAYS_AVAILABLE_TOOLS（src/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 文档，这里给出核心要点：

创建方式

1. 直接让 Roo 创建（推荐）：例如对 Roo 说"创建一个叫 Documentation Writer 的模式，它只能读文件和写 Markdown 文件"，Roo 会引导完成其余配置；
2. Modes 页面：打开 Roo Code 面板 → 点击聊天框下方的模式菜单 → 点击齿轮图标，进入 Modes 页面手动填写Name、Slug、Description、Role Definition、Available Tools、Custom Instructions等字段；
3. 手动编辑配置文件：全局模式编辑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 完全覆盖、不合并任何属性）：

1. 项目级配置（.roomodes）
2. 全局配置（custom_modes.yaml，其次custom_modes.json）
3. 内置默认模式

因此你可以用同 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，疑问交给 Ask，Bug 交给 Debug，复杂项目统筹交给 Orchestrator。借助 Sticky Models，每个模式还能记住各自偏好的模型；借助自定义模式、工具组与fileRegex文件权限，你可以把团队规范、安全边界和专属工作流都固化进这一套数据驱动的配置里。深入理解模式的字段与源码实现，是精准掌控 Roo Code 行为的第一步。

进一步阅读：

• Custom Modes 文档
• switch_mode 工具说明
• new_task 工具说明
• 可用工具总览
• Boomerang Tasks（Orchestrator 委派详解）

【免费下载链接】Roo-CodeRoo Code gives you a whole dev team of AI agents in your code editor.项目地址: https://gitcode.com/GitHub_Trending/ro/Roo-Code