企业官网建设流程全解析

• 人工智能
• AI Agent
• 代码智能体
• 开发工具
• 工具调用
• MCP Clients

本文围绕 Roo Code 项目官方越南语 README（locales/vi/README.md）展开，完整梳理这一 AI 编程助手在 VS Code 中的定位、七大核心能力、模式驱动的交互设计以及 MCP 服务器扩展机制，并结合仓库源码（如 packages/types/src/mode.ts、src/shared/modes.ts、src/shared/tools.ts）给出实现层面的印证，帮助读者从"能做什么"到"为什么这么做"建立完整认知。

一、项目概览：Roo Code 是什么

Roo Code 是一个直接运行在 VS Code 编辑器内的 AI 编程助手，其官方定位是"你的 AI 驱动开发团队，就在你的编辑器中"（Your AI-Powered Dev Team, Right in Your Editor）。与需要切换窗口、复制粘贴代码的外部 AI 工具不同，Roo Code 以原生 VS Code 扩展的形式融入开发工作流，具备以下特征：

• 编辑器原生集成：作为 VS Code 扩展运行，可直接读写工作区文件、执行终端命令、与代码库交互；
• 模式化智能体：通过"模式"（Modes）机制切换不同的 AI 角色（如编码、架构设计、答疑、调试），每种模式拥有不同的工具权限与行为准则；
• 开源生态：项目采用 Apache 2.0 许可（见仓库根目录 LICENSE），并维护了 18 种语言的 README 本地化版本（分布在 locales 目录下）。

从仓库结构看，该扩展的核心实现集中在 src 目录，包括任务调度（src/core/task/Task.ts）、消息管理（src/core/message-manager）、工具系统（src/core/tools）以及提示词工程（src/core/prompts）等模块，是一个结构完整、可独立扩展的 AI Agent 工程实现。

二、Roo Code 能为你做什么：七大核心能力

官方 README 将 Roo Code 的能力概括为七个方面，覆盖了从代码生产到知识问答、再到自动化与外部工具集成的完整链路：

其中，"模式化自适应"是 Roo Code 区别于普通 AI 补全工具的核心设计，也是理解其工作方式的关键，下文将重点展开。

三、模式系统：Roo Code 如何"适应你"而不是相反

官方 README 强调：Roo Code 适应你的工作方式，而不是反过来。这意味着 AI 的行为（角色定义、可用工具、交互风格）会随当前任务模式动态变化。

3.1 内置模式的源码级定义

在 packages/types/src/mode.ts 中，DEFAULT_MODES定义了全部内置模式。每个模式通过ModeConfig结构描述，包含slug（唯一标识）、name（显示名）、roleDefinition（系统提示词中的角色定义）、whenToUse（何时使用）、description（UI 摘要）、groups（工具组授权）与customInstructions（行为准则）等字段。

各内置模式的对比如下：

3.2 模式权限的底层实现：工具组（Tool Groups）

模式的"能做什么、不能做什么"由groups字段决定。在 src/shared/tools.ts 中，TOOL_GROUPS将全部工具划分为四个核心组：

• read：文件读取、搜索、列表与代码库检索（read_file、search_files、list_files、codebase_search）；
• edit：文件修改与创建（apply_diff、write_to_file、generate_image）；
• command：终端命令执行与输出读取（execute_command、read_command_output）；
• mcp：MCP 服务器交互（use_mcp_tool、access_mcp_resource）。

此外，src/shared/tools.ts 定义了ALWAYS_AVAILABLE_TOOLS——一组对所有模式始终可用的基础工具（如ask_followup_question、attempt_completion、switch_mode、update_todo_list、run_slash_command等），保证任何模式都能提问、汇报完成、切换模式与维护任务清单。

这与文档中的描述完全一致：Ask 模式只有read+mcp组，因此无法改动文件；Architect 模式的edit组被限制为"仅 Markdown 文件"；Orchestrator 模式的groups为空数组，仅靠new_task工具委托子任务（该工具属于ALWAYS_AVAILABLE_TOOLS与modes工具组）。在 src/shared/modes.ts 中，getToolsForMode()负责按模式聚合工具组并追加常驻工具，正是这套权限模型的运行时实现。

3.3 模式的具体工作方式

Code 模式（默认模式）：默认模式下，Agent 拥有全部工具权限，从自然语言描述出发完成编码、编辑与文件操作。从源码看，packages/types/src/mode.ts 中该模式的groups为["read", "edit", "command", "mcp"]，即无任何工具限制。

Architect 模式：先做信息收集（借助read组工具），再通过update_todo_list工具将任务拆解为清晰、可执行的待办清单；当计划被确认后，使用switch_mode请求用户切换到其他模式落地实现。其customInstructions明确要求"不提供工时估算""不写冗长的 Markdown 计划文档，以待办清单为主要规划工具"。

Ask 模式：只读模式，不能修改项目，也不主动切换到编码实现（除非用户明确要求），回答中可以使用 Mermaid 图来澄清概念。

Debug 模式：customInstructions要求 Agent "先反思 5～7 个可能的问题来源，收敛到 1～2 个最可能的根因，添加日志验证假设，并在修复前显式请求用户确认"——即先诊断、再修复的系统化流程。

Orchestrator 模式：不直接操作任何工具，而是将复杂任务拆解为子任务，通过new_task委托给最适合的专用模式执行。每个子任务运行在独立上下文中，完成后仅将摘要返回给父任务，从而避免父任务上下文被执行细节污染（官方文档称此为 Boomerang Tasks，详见 apps/docs/docs/features/boomerang-tasks.mdx）。

四、四种方式切换模式

在日常使用中，你可以在任意时刻切换模式。官方文档（apps/docs/docs/basic-usage/using-modes.md）总结了四种方式：

1. 下拉菜单：点击聊天输入框左侧的模式选择器，在列表中切换；
2. 斜杠命令：在消息开头输入/architect、/ask、/debug、/code或/orchestrator，立即切换到对应模式并清空输入框；
3. 快捷键循环：按Ctrl + .（Windows/Linux）或⌘ + .（macOS）循环切换所有可用模式，到尾后回到第一个；
4. 接受建议：当 Roo 判断当前任务更适合其他模式时，会给出模式切换建议，点击即可采纳。

模式切换除了改变角色与权限外，还有一个实用特性——粘性模型（Sticky Models）：每个模式会记住你上次使用的模型，切换模式时自动选用该模式对应的模型（例如 Architect 模式用 Gemini 2.5 Preview、Code 模式用 Claude Sonnet），无需手动重新选择；同时，你选中的模式会在会话之间持久保留。

五、自定义模式：为团队与工作流构建专用助手

官方 README 将"自定义模式"列为模式体系的重要一环，并在官方文档（apps/docs/docs/features/custom-modes.mdx）中给出了完整配置指南。

5.1 自定义模式的字段

一个自定义模式由以下属性构成（与 packages/types/src/mode.ts 中modeConfigSchema的校验规则一一对应）：

5.2 工具组与文件限制：groups的两种写法

groups支持两种条目形式（见 packages/types/src/mode.ts 的groupEntrySchema）：

• 简单字符串：无限制地授予整个工具组，例如"edit"；
• 元组（二元数组）：带限制的授予，例如["edit", { fileRegex: "\\.(md|mdx)$", description: "Markdown files only" }]。

fileRegex用于限制该模式可编辑的文件路径（正则需匹配从工作区根目录起的完整相对路径），description为可选说明。仓库中的校验逻辑（packages/types/src/mode.ts）会在配置加载时用new RegExp()验证正则合法性，非法正则将被拒绝并提示 "Invalid regular expression pattern"；当模式试图编辑不匹配的文件时，会抛出包含模式名、允许模式、描述、文件路径与所用工具的FileRestrictionError（见 src/shared/modes.ts）。

5.3 YAML 配置示例

以下是一个典型的自定义模式配置（保存于全局custom_modes.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

需要说明的是：全局模式配置文件名为custom_modes.yaml（见 src/shared/globalFileNames.ts），项目级配置文件为项目根目录的.roomodes；Roo Code 同时兼容 JSON 与 YAML 两种格式，但 YAML 为推荐格式（支持注释、多行字符串，且通过 UI 新建的模式默认输出 YAML）。配置的加载与覆盖逻辑位于 src/core/config/CustomModesManager.ts，其优先级为：项目级.roomodes> 全局custom_modes.yaml> 内置默认模式，同 slug 的项目模式会整体覆盖全局模式（不合并属性）。

六、MCP 服务器：接入第三方工具生态

"使用 MCP 服务器"是官方 README 明确的第七大能力。MCP（Model Context Protocol）为 AI 助手提供了一套标准化接口，使其能够调用外部服务器暴露的工具与资源——例如数据库查询、HTTP 请求、CI 系统操作等。

在 Roo Code 中，MCP 相关的核心实现集中在 src/services/mcp 目录，其中 McpHub.ts 负责服务器的连接生命周期管理（包括mcp_settings.json配置文件的监听与热加载）。当某个模式的groups中包含mcp时，Agent 即可通过use_mcp_tool调用 MCP 工具、通过access_mcp_resource读取 MCP 资源（对应 src/shared/tools.ts 中mcp组的定义）。

正因如此，Ask 与 Architect 模式在只读的read之外仍保留了mcp授权——接入 MCP 服务器后，它们可以在不改动项目文件的前提下，借助外部数据与工具回答问题、完善方案。而 Orchestrator 模式默认不包含mcp组，这是其"保持高层视野、避免上下文污染"设计哲学的一部分；若确需扩展，可按照配置优先级机制为orchestratorslug 添加自定义覆盖。

七、文档与资源

• 官方使用指南：安装、配置与进阶使用的中文/英文文档位于 apps/docs/docs 目录，其中 basic-usage/using-modes.md 系统讲解模式用法，features/custom-modes.mdx 详解自定义模式配置；
• 多语言 README：仓库在 locales 目录下维护了 18 种语言的 README，包括简体中文（locales/zh-CN/README.md）、越南语（locales/vi/README.md）、日语（locales/ja/README.md）等；
• 许可协议：项目基于 Apache 2.0 许可发布（LICENSE）。

结语

Roo Code 的价值在于把"一个开发团队"的能力压缩进编辑器：Code 模式承担日常实现，Architect 模式负责规划与拆解，Ask 模式提供答疑，Debug 模式系统化排障，Orchestrator 模式统筹多模式协作，而自定义模式与 MCP 则让这套体系可以无限适配团队与业务需要。理解其模式系统与权限模型，是充分发挥这个 AI 开发助手能力的第一步——而这一切的底层逻辑，都可以在本文引用的源码与官方文档中找到精确的答案。

• 人工智能
• AI Agent
• 代码智能体
• 开发工具
• 工具调用
• MCP Clients