Lzh on GitHub

switch_mode

switch_mode 工具让 Roo 可以在不同的操作模式之间切换，每种模式都拥有针对特定任务类型的专业能力。这使得在当前任务需要不同专业知识时，可以无缝地在诸如 “代码”、“架构”、“问答” 或 “调试” 等模式之间进行转换。

switch_mode 工具让 Roo 可以在不同的操作模式之间切换，每种模式都拥有针对特定任务类型的专业能力。这使得在当前任务需要不同专业知识时，可以无缝地在诸如 “代码”、“架构”、“问答” 或 “调试” 等模式之间进行转换。

参数

此工具接受以下参数：

  • mode_slug（必需）：要切换到的模式的代号（例如，“code”、“ask”、“architect”）。
  • reason（可选）：切换模式的原因，为用户提供上下文。

功能

当当前任务由另一种模式的能力处理更好时，此工具会请求进行模式更改。它在转移 Roo 的焦点和可用工具集以匹配新任务阶段的要求时，会保持上下文。

使用场景

  • 从信息收集过渡到代码实现时。
  • 从编码转向架构或设计时。
  • 当前任务需要仅在其他模式下可用的能力时。
  • 当复杂项目的特定阶段需要专业知识时。

关键特性

  • 在模式转换中保持上下文连续性。
  • 为模式切换建议提供清晰的理由。
  • 所有模式更改都需要用户批准。
  • 强制执行特定于每种模式的工具组限制。
  • 根据所选模式无缝调整工具可用性。
  • 支持标准和自定义模式。
  • 在用户界面中显示模式切换和原因。
  • 使用 XML 风格的格式进行参数指定。
  • 处理特定于某些模式的文件类型限制。

局限性

  • 无法切换到系统中不存在的模式。
  • 每次模式转换都需要明确的用户批准。
  • 在切换完成之前，无法使用特定于该模式的工具。
  • 模式切换后会应用 500 毫秒的延迟，以允许更改生效。
  • 某些模式具有文件类型限制（例如，“架构”模式只能编辑 Markdown 文件）。
  • 仅 new_task 功能保留模式以供恢复，一般模式切换则不适用。

工作原理

当 switch_mode 工具被调用时，它遵循以下过程：

  1. 请求验证：
  • 验证所请求的模式在系统中是否存在。
  • 检查是否提供了 mode_slug 参数且其有效。
  • 验证用户是否已处于所请求的模式中。
  • 确保 reason 参数（如果提供）格式正确。
  1. 模式转换准备：
  • 将模式更改请求与提供的理由打包。
  • 向用户呈现更改请求以供批准。
  1. 模式激活（在用户批准后）：
  • 更新用户界面以反映新模式。
  • 根据模式的工具组配置调整可用工具。
  • 应用特定于模式的提示和行为。
  • 应用 500 毫秒的延迟，以允许更改在执行下一个工具之前生效。
  • 强制执行特定于该模式的任何文件限制。
  1. 继续：
  • 使用新模式的功能继续执行任务。
  • 保留来自先前交互的相关上下文。

工具组关联

switch_mode 工具属于“modes”工具组，但也被包含在“始终可用”工具列表中。这意味着：

  • 无论模式的配置工具组如何，它都可以在任何模式下使用。
  • 它与其他核心工具（如 ask_followup_question 和 attempt_completion）一起可用。
  • 当任务要求发生变化时，它允许在工作流中的任何时候进行模式转换。

模式结构

系统中的每个模式都有一个特定的结构：

  • slug：模式的唯一标识符（例如，“code”、“ask”）。
  • name：模式的显示名称（例如，“Code”、“Ask”）。
  • roleDefinition：模式的专业角色和能力定义。
  • customInstructions：可选的、指导行为的特定于模式的指令。
  • groups：模式可用的工具组，可附带可选的限制。

模式能力

核心模式提供这些专业能力：

  • 代码模式：专注于编码任务，可完全访问代码编辑工具。
  • 架构模式：专注于系统设计和架构规划，仅限于编辑 Markdown 文件。
  • 问答模式：为回答问题和提供信息而优化。
  • 调试模式：专用于系统性地诊断和解决问题。

自定义模式

除了核心模式，系统还支持自定义的、特定于项目的模式：

  • 可以定义自定义模式，并启用特定的工具组。
  • 它们可以指定自定义的角色定义和指令。
  • 系统首先检查自定义模式，然后才回退到核心模式。
  • 自定义模式定义优先于具有相同代号的核心模式。

文件限制

不同的模式可能有特定的文件类型限制：

  • 架构模式：只能编辑 .md 扩展名的文件。
  • 尝试编辑受限文件类型会产生 FileRestrictionError。
  • 这些限制有助于强制执行模式之间的适当职责分离。

使用示例

  • 讨论新功能时，Roo 从“问答”模式切换到“架构”模式，以帮助设计系统结构。
  • 在“架构”模式下完成架构规划后，Roo 切换到“代码”模式以实现设计好的功能。
  • 在开发过程中遇到 bug 时，Roo 从“代码”模式切换到“调试”模式进行系统性故障排除。

用法示例

切换到 “代码” 模式进行实现：

<switch_mode>
  <mode_slug>code</mode_slug>
  <reason>Need to implement the login functionality based on the architecture we've discussed</reason>
</switch_mode>

切换到 “架构” 模式进行设计：

<switch_mode>
  <mode_slug>architect</mode_slug>
  <reason>Need to design the system architecture before implementation</reason>
</switch_mode>

切换到 “调试” 模式进行故障排除：

<switch_mode>
  <mode_slug>debug</mode_slug>
  <reason>Need to systematically diagnose the authentication error</reason>
</switch_mode>

切换到 “问答” 模式以获取信息：

<switch_mode>
  <mode_slug>ask</mode_slug>
  <reason>Need to answer questions about the implemented feature</reason>
</switch_mode>