让 Codex “用上”Android Studio：JetBrains MCP Server 接入与实践

本文基于 2026 年 8 月的 JetBrains MCP Server 与 Codex 配置方式编写。不同 Android Studio版本可能略有差异，请以实际为准。

很多 AI 编程工具已经可以读取文件、搜索代码和执行 Shell 命令，但这并不等于它真正理解 IDE。它可能知道项目里有哪些 Kotlin 文件，却不知道 Android Studio 如何解析某个符号；可以运行 ./gradlew，却不知道你已经配置好的 Run Configuration；也能做全局文本替换，却无法完成 IDE 级的安全重命名。

JetBrains MCP Server 解决的正是这层断档。它通过 Model Context Protocol（MCP）把 JetBrains IDE 内部的代码索引、Inspection、项目模型、运行配置和重构能力开放给 Codex 等外部 AI 客户端。

换句话说，接入以后，Codex 不再只是"在项目目录旁边运行的 AI"，而是可以调用一部分 Android Studio 能力的开发代理。

一、JetBrains MCP Server 是什么

MCP 是一种让 AI 客户端发现并调用外部工具的开放协议。JetBrains MCP Server 运行在 IDE 一侧，把一组 IDE 操作包装成结构化工具，例如：

• 构建项目并返回编译错误；
• 运行 Android Studio 中已有的 Run Configuration；
• 获取模块和项目依赖；
• 查询符号、类型、签名和 Quick Documentation；
• 调用 IDE Inspection 检查指定文件；
• 搜索项目文件、文本和代码符号；
• 读取项目源码、依赖源码以及反编译后的 JAR/JRT 类；
• 使用 JetBrains 重构引擎完成符号重命名；
• 按项目 Code Style 格式化文件；
• 创建文件、应用补丁以及在编辑器中打开文件；
• 在 IDE 集成终端中执行命令。

这不是另一个 LSP 服务。LSP 主要解决编辑器和语言服务器之间的补全、跳转、诊断等语言能力；MCP 则让 AI 以工具调用的方式执行更完整的 IDE 工作流。JetBrains MCP 背后还可以直接利用 JetBrains 的 PSI、索引、Inspection 和项目模型，其能力边界通常比普通文本搜索或单纯的 LSP 查询更广。

二、如何在 Android Studio / JetBrains IDE 中启用

1. 检查 MCP Server 插件

JetBrains 官方文档说明，IntelliJ IDEA 从 2025.2 开始内置 MCP Server 插件并默认启用。Android Studio 的实际情况取决于所使用的版本和发行包。如果设置中没有 MCP Server：

1. 打开 MCP下载链接；
2. 根据Android Studio版本下载可用的MCP版本；

3. 安装或启用本地插件；

4. 按提示重启 IDE。

如果已经能看到 Settings → Tools → MCP Server，说明插件已经可用。

2. 启用服务

进入：

Settings / Preferences → Tools → MCP Server

点击 Enable MCP Server。首次启用时，IDE 会提示外部程序将获得哪些项目访问能力，确认后继续。

MCP Server 需要 IDE 保持运行，并且目标项目已经在 IDE 中打开。存在多个 IDE 窗口或多个项目时，最好在给 Codex 的任务中明确项目路径，以免调用落到错误的项目。

3. 配置 Exposed Tools

进入 Exposed Tools 页面，可以按工具集控制哪些能力允许被外部 AI 调用。常见分组包括 Analysis、Code Insight、Execution、File、Formatting、Patch、Read、Refactoring、Search、Terminal 和 VCS。

默认是全部勾选的。

JetBrains MCP 的权限过滤与 Codex 自己的审批、沙箱机制是两层控制：IDE 决定"是否暴露这个工具"，Codex 决定"本次是否允许调用"。两层都保留，通常比把所有操作无条件放开更稳妥。

4. 选择传输方式

JetBrains 设置页可以生成多种客户端配置：

• STDIO：客户端启动本地代理进程，通过标准输入输出通信；
• HTTP Stream：客户端通过本机地址连接 IDE 提供的 Streamable HTTP 服务；
• SSE：主要用于兼容仍依赖旧式 SSE 传输的客户端。

Codex 当前原生支持 STDIO 和 Streamable HTTP。新配置建议选择这两种之一，建议使用 Streamable HTTP。

最省事的方法，是在 Clients Auto-Configuration 中找到 Codex ，点击 Auto-Configure，然后重启 Codex。JetBrains 会根据检测到的客户端写入相应配置。

[mcp_servers.studio]
url = "http://127.0.0.1:64342/stream"

也可以打开 Auto-Configure 旁边的菜单，查看配置文件或复制配置。

三、接入以后有什么好处

这一部分才是 JetBrains MCP 真正值得使用的原因。

1. AI 得到的是 IDE 的语义，而不只是文件文本

只靠文件读取时，AI 看到的是一组字符串。它需要自己判断某个名称究竟是类、扩展函数、资源引用还是同名变量，并且容易被生成代码、依赖源码和同名符号干扰。

通过 get_symbol_info、符号搜索和 IDE Inspection，Codex 可以直接利用 JetBrains 已经建立的索引，获得符号的声明、类型、签名、文档和位置。对于 Kotlin 重载、Java/Kotlin 混编、Android 资源以及大型多模块工程，这会显著减少"搜到了文本，却找错了代码"的情况。

2. 可以完成真正的 IDE 级重构

重命名是一个很典型的例子。文本替换会误改注释、字符串或同名符号，也可能漏掉 Java 调用、XML 引用和跨模块引用。

rename_refactoring 调用的是 JetBrains 的语义重构能力。IDE 会先解析目标符号，再更新它能够识别的全部引用。这使 Codex 可以处理"把这个类或方法改名，并保持项目可编译"这类任务，而不是把风险交给一次全局替换。

3. 复用现成的 Run Configuration

Android 项目的运行条件经常隐藏在 IDE 配置中：Build Variant、启动 Activity、环境变量、程序参数、测试目标和工作目录都可能影响结果。让 AI 自己拼命令，往往需要多轮试错。

get_run_configurations 可以列出项目已有的运行配置，也能发现代码中带 Run 图标的测试方法、main() 等可执行入口。execute_run_configuration 随后可以直接运行对应配置，并返回当前输出、退出码以及完整输出文件路径。

这样一来，Codex 可以复用团队已经验证过的运行环境，而不是重新发明一套启动命令。

4. 形成"修改---检查---构建---运行"的闭环

普通聊天式 AI 往往在生成代码后就结束了。接入 JetBrains MCP 后，可以形成一条更可靠的验证链路：

1. 通过 IDE 索引定位符号和相关文件；
2. 读取实现和依赖源码；
3. 应用补丁或执行语义重构；
4. 使用项目 Code Style 格式化；
5. 调用 Inspection 检查文件；
6. 构建项目并读取编译错误；
7. 执行目标 Run Configuration 或测试；
8. 根据结果继续修正。

关键提升不是"AI 多了几个命令"，而是验证过程使用了与开发者相同的 IDE 上下文。

5. 更容易理解大型 Gradle 多模块项目

仅解析 settings.gradle.kts 和各模块构建脚本，并不总能得到 IDE 最终导入后的真实项目结构。版本目录、Convention Plugin、复合构建和动态依赖会进一步增加难度。

模块与依赖查询接口可以直接返回 IDE 已解析的模型。Codex 因此更容易回答：

• 某个类属于哪个模块；
• 当前项目有哪些模块；
• 某项能力来自哪个依赖；
• 修改公共模块可能影响哪些消费者；
• 某个库的源码或反编译实现是什么。

6. 可以读取依赖源码和反编译结果

JetBrains 的读取接口不仅面向项目目录，也可以读取项目依赖、JAR/JRT 内的源码，在需要时返回反编译后的类文件内容。

排查 SDK 行为时，这一点非常实用。Codex 可以先查询外部符号，再阅读库实现，而不必把整个 JAR 解压到项目中，也不必依赖网上可能与当前版本不一致的代码片段。

7. 输出更精确，也更节省上下文

让 AI 递归读取大量文件不仅慢，还会消耗上下文。IDE 的符号索引、文件问题列表和结构化构建错误，可以把范围缩小到真正相关的位置。

例如，查询一个符号的声明通常比全项目搜索同名字符串更干净；获取指定文件的 Inspection 结果，也比把完整构建日志反复交给模型更高效。

8. 对 Android 日志的支持边界更清楚

当前这组工具可以直接返回构建和 Run Configuration 的控制台输出，但没有专门读取 Android Studio Logcat 面板的接口。

如果开启了 Terminal 工具，Codex 可以间接执行有限范围的 ADB 查询，例如：

adb logcat -d -v threadtime -t 300

实际使用时最好继续按 PID、包名或 Tag 过滤。终端接口通常有超时和输出行数限制，不适合长时间挂起实时日志流。

四、如何验证配置真的生效

不要只看"已连接"状态，最好做三层验证。

首先测试只读能力：

使用 JetBrains MCP 列出当前项目的模块和依赖，不要调用 Shell。

然后测试 IDE 语义能力：

使用 JetBrains MCP 查询 MainActivity 的符号信息，并检查这个文件中的 IDE Inspection 问题。

最后测试执行能力：

使用 JetBrains MCP 获取现有 Run Configuration，选择测试配置执行，并总结失败原因。

如果 Codex 总是退回 Shell，可以在提示中明确要求"使用 JetBrains MCP，不要使用终端命令"。如果完全看不到工具，则依次检查：

• IDE 是否正在运行，目标项目是否已经打开；
• MCP Server 是否启用；
• 对应工具是否在 Exposed Tools 中勾选；
• Codex 是否已经重启；
• codex mcp list 或 /mcp 是否显示服务已连接；
• 多窗口情况下是否明确提供了项目路径；
• 构建类工具是否因为超时而中断。

五、安全建议

MCP Server 获得的是实际 IDE 和项目操作能力，配置时不要忽略权限边界：

• 只连接可信的本地 AI 客户端；
• 不需要的工具不要暴露；
• Terminal、Patch、File Creation 和 Run Configuration 建议保留审批；
• 开启 Brave Mode 前，先理解它会跳过哪些 IDE 确认；
• 不要为了方便把本地 MCP 服务暴露到公网；
• 执行修改后继续使用 Git diff、Inspection、构建和测试验证结果。

结语

JetBrains MCP Server 最大的价值，不是让 Codex 多了一套读取文件的方式，而是把 IDE 已经拥有的"语义、项目模型和执行上下文"交给了 AI。

接入前，Codex 更多依靠文件系统和命令行推断项目；接入后，它可以查询真实符号、调用 Inspection、执行安全重构、复用 Run Configuration，并在同一条工作流中完成修改和验证。对于 Android、Kotlin、Java 以及大型 Gradle 多模块项目，这种差异会非常明显。

如果只准备开启少量工具，优先考虑符号查询、Inspection、模块与依赖、语义重命名、构建和 Run Configuration------这些也是普通 Shell 最难替代的部分。

参考资料

注：部分内容由AI生成。

• JetBrains：MCP Server
• JetBrains Marketplace：MCP Server 插件
• OpenAI：Codex 中的 Model Context Protocol
• Model Context Protocol 官方介绍