Gemini MCP Apps 完整教程：MCP 交互式 UI、Cloud Run 部署、OAuth 认证与 AI Agent 开发

一、Google 发布 Gemini MCP Apps 开发指南：Agent 不再只能输出文字

2026 年 10 月 19 日，Google Cloud 发布《Developer's guide to implementing MCP apps in Gemini》，介绍如何为 Gemini Enterprise 构建具有交互式用户界面的 MCP 应用。

这篇官方技术文章反映了 AI Agent 生态的重要变化。

传统聊天机器人主要输出自然语言和 Markdown。

用户提出问题后，模型生成文字回答。

如果用户希望修改某个条件，就需要再次输入消息，等待模型重新处理。

随着 AI 开始参与财务分析、文件审查、设计工作和企业自动化，纯文字交互已经难以满足所有需求。

例如，用户希望调整财务预测中的增长率。

传统聊天方式可能需要不断发送“将增长率改为 8%”“重新计算结果”“显示新的图表”等指令。

但如果 AI 可以直接呈现滑块、图表和操作面板，用户就能够像使用普通软件一样修改参数。

这正是 MCP Apps 希望解决的问题。

Google 的新开发指南展示了如何将 MCP 工具与交互式界面组合，并直接显示在 Gemini Enterprise 的对话流程中。

需要强调，这是一份新的开发实现指南，而不是 MCP 协议在 10 月 19 日才首次诞生。

二、什么是 MCP？

MCP 的完整名称是 Model Context Protocol，即模型上下文协议。

它是一套开放协议，用于规范 AI 应用与外部工具、数据资源之间的交互。

在传统 AI Agent 系统中，开发者往往需要为每个平台分别编写工具适配代码。

例如，一个业务系统想同时向不同 AI 助手提供订单查询功能，可能需要处理不同的工具调用格式。

MCP 提供了一种较统一的交互方式。

MCP Server 可以向兼容客户端公开工具、资源和其他能力。

模型能够根据用户任务发现并调用相应工具。

例如，一个知识库 MCP Server 可以提供搜索文档工具。

一个项目管理 MCP Server 可以提供读取任务和创建事项的工具。

一个数据库 MCP Server 可以提供经过授权的查询功能。

但传统 MCP 工具的结果通常仍然以文本或结构化数据形式返回。

用户如果希望进一步调整，就需要再次通过 AI 对话。

MCP Apps 则是在这一基础上增加交互式界面能力。

三、MCP Apps 与传统 MCP 工具有何不同？

Google 将企业 AI 助手的发展划分为三个阶段。

第一阶段是文字聊天机器人。

用户输入问题，系统返回静态文本。

第二阶段是标准 MCP 工具。

模型可以调用外部服务，但工具结果通常依然需要转化为聊天中的文字内容。

第三阶段是交互式 MCP Apps。

工具能够同时提供一个可操作的界面，让用户直接与数据、控件和工作区交互。

例如，在法律文件审查中，标准 MCP 工具可以返回需要遮盖的敏感字段列表。

而 MCP App 可以展示完整的文件预览，让审核人员点击需要遮盖的区域。

在财务分析中，传统工具可能只返回一张静态图表。

MCP App 则可以提供参数滑块，让用户即时调整假设。

对于复杂工作流，这种方式有机会减少不必要的模型调用。

但交互式界面不是所有任务的最佳选择。

简单文本问答依然可以使用普通聊天方式完成。

四、SEP-1865 是什么？

Google 此次实现采用 MCP Apps 扩展机制，对应 SEP-1865。

该扩展为 MCP 工具提供了声明和加载交互式 UI 的标准方式。

在协议层面，工具可以通过元数据引用一个 ui:// 资源。

这个资源通常包含 HTML、CSS 和 JavaScript。

当兼容 MCP Apps 的宿主调用工具时，可以读取相关 UI 资源，并将其放入受控界面环境。

这让工具不仅可以返回模型能够理解的数据，也能提供适合人类直接操作的展示界面。

例如，一个查询库存的工具可能返回结构化库存数据，同时提供可以筛选商品、调整数量和提交申请的表格。

在这种情况下，模型负责理解用户意图。

MCP Server 负责处理业务请求。

UI 则负责展示结果和接收用户操作。

三者通过清晰的协议边界协作。

五、MCP Apps 的 ui:// 资源是什么？

MCP Apps 使用 ui:// URI 标识交互界面资源。

例如：

ui://inventory/dashboard

这个 URI 不是普通网页地址。

它用于在 MCP 协议中标识由服务器提供的应用视图。

一个工具可以通过 _meta.ui.resourceUri 声明对应的 UI 资源。

例如：

{
  "name": "get_inventory",
  "description": "查询库存数据",
  "inputSchema": {
    "type": "object",
    "properties": {
      "category": {
        "type": "string"
      }
    }
  },
  "_meta": {
    "ui": {
      "resourceUri": "ui://inventory/dashboard"
    }
  }
}

以上是说明协议结构的示例，不是可以直接部署的完整 MCP Server。

实际实现还需要在服务器中注册工具和资源处理器，并返回符合 MCP Apps 规范的 UI 内容。

MCP Apps 官方规范使用的 UI MIME 类型为：

text/html;profile=mcp-app

宿主会根据工具元数据获取相应资源，并在支持的情况下渲染界面。

如果宿主不支持 MCP Apps，开发者应准备普通文本或结构化数据回退方式。

六、Gemini Enterprise 中的 MCP Apps 如何运行？

Google 官方文档介绍了三层架构。

第一层：客户端浏览器

用户在浏览器中打开 Gemini Enterprise。

聊天界面可以同时展示 MCP App 提供的交互式面板。

根据具体应用设计，面板可以出现在聊天中，也可以扩展为侧边栏或全屏工作区。

第二层：Gemini Enterprise

Gemini Enterprise 负责提供默认 Assistant、工具调用连接、身份管理和 UI 消息转发。

Google 在架构中介绍了 AppBridge 代理，用于处理交互式界面与宿主之间的消息。

第三层：Google Cloud 项目

开发者在自己的 Google Cloud 项目中部署 MCP Server。

Google 推荐使用 Cloud Run 运行相关服务。

MCP Server 暴露 /mcp 接口，处理 JSON-RPC 请求，并提供 HTML Widget 资源。

这三层架构的好处，是让对话平台与业务服务保持一定程度的解耦。

企业可以利用 Gemini Enterprise 的用户入口，同时保留自己的服务端业务逻辑。

七、为什么使用 Cloud Run？

Cloud Run 是 Google Cloud 的托管容器运行服务。

开发者可以将应用封装为容器，并交由平台管理运行环境。

在 MCP Apps 架构中，Cloud Run 可以承担 MCP Server 的托管职责。

例如，服务器负责处理用户提出的查询请求，访问经过授权的数据系统，并返回工具结果。

Google 的示例还涉及后台任务。

对于运行时间较长的工作流，系统可以先返回任务状态，再通过轮询获取执行进度。

这种设计能够避免一次同步工具调用长时间阻塞。

官方示例建议部署时启用适合后台执行的 CPU 配置，并根据需要保持最小实例数量。

但这些配置也可能增加持续运行成本。

因此，实际生产环境需要根据任务耗时、并发量和预算进行选择。

八、MCP Server 为什么使用 /mcp 接口？

根据 Google 官方开发指南，MCP Server 可以通过单个 Streamable HTTP 端点提供服务。

常见路径为：

POST /mcp

请求和响应使用 MCP 所需的 JSON-RPC 通信格式。

与传统 REST API 不同，MCP 协议定义了工具发现、工具调用和资源读取等统一交互方式。

例如，宿主可以查询服务器公开了哪些工具。

随后调用其中一个工具。

如果工具关联 UI 资源，支持 MCP Apps 的宿主还可以加载相应界面。

但不能简单认为任何普通 HTTP API 加一个 /mcp 路径就自动符合 MCP 协议。

服务器仍然需要实现规范要求的消息结构、初始化、工具注册和错误处理。

因此，建议优先使用官方 MCP SDK，而不是自行拼接全部协议报文。

九、如何创建一个 MCP App？

Google 官方提供了两种方向。

第一种是使用 MCP Apps SDK 手动开发。

第二种是使用支持相关开发流程的 AI 编程工具辅助生成项目。

如果采用手动开发，可以按以下步骤进行。

第一步，确定业务场景。

例如，建立一个能够查看商品库存并调整筛选条件的管理面板。

第二步，定义 MCP 工具。

例如 get_inventory，用于读取库存数据。

第三步，创建 UI 资源。

例如 ui://inventory/dashboard，包含展示数据的 HTML 界面。

第四步，在工具元数据中关联 UI URI。

第五步，实现工具处理和返回结果。

第六步，在兼容的 MCP Apps 宿主中测试界面。

第七步，增加权限管理和生产监控。

MCP Apps 官方 SDK 仓库提供了完整的工具与资源注册示例：

https://github.com/modelcontextprotocol/ext-apps

对于第一次开发的团队，建议先运行官方最小示例，再逐步增加业务功能。

十、Gemini Enterprise 如何部署 MCP Server？

Google Cloud 官方文章提供了完整部署思路。

首先，在 Google Cloud 项目中启用 Cloud Run、Discovery Engine、Agent Platform 等必要服务及相关组织配置。

随后准备 MCP Server 容器。

使用 Cloud Run 部署时，应根据官方指南配置非公开访问和适合后台任务的运行参数。

例如，官方示例包含：

gcloud run deploy YOUR_SERVICE \
  --source . \
  --no-allow-unauthenticated \
  --no-cpu-throttling \
  --min-instances=1

其中，YOUR_SERVICE 需要替换为实际服务名称。

这是部署参数示例，不是可以在任意空目录直接运行成功的完整项目。

部署前还需要准备应用源码、项目配置、权限、区域及相关服务账号。

--no-allow-unauthenticated 用于避免服务被直接匿名公开调用。

--no-cpu-throttling 则与服务实例在请求之外是否继续获得 CPU 资源有关。

--min-instances=1 可以保持一定的最小实例数量，但可能产生持续费用。

因此，生产配置应同时评估安全性、冷启动和成本。

十一、为什么需要双层认证？

这是 Google 官方架构中最值得关注的安全设计。

MCP Apps 不是只提供一个公开网页。

它可能访问企业内部数据、执行工作流，甚至修改业务记录。

因此，需要同时判断调用服务的主体和实际用户身份。

第一层：Cloud Run IAM

这一层负责判断哪个服务有权限调用 Cloud Run。

Google 官方将其描述为服务级认证。

Gemini Enterprise 的相关服务代理需要获得适当的调用权限。

不符合要求的请求可能被拒绝。

第二层：应用内部 OAuth

这一层负责判断实际发起操作的用户是谁。

用户通过 OAuth 2.0 完成身份验证。

MCP Server 需要进一步验证用户身份，并根据业务规则决定哪些数据可以访问。

这两层验证解决的问题不同。

Cloud Run IAM 负责服务之间的访问控制。

OAuth 负责用户身份及业务授权。

即使 Gemini Enterprise 被允许调用 MCP Server，也不意味着所有用户都应该拥有相同的数据访问权限。

十二、Google 官方 OAuth 配置有哪些关键点？

Google 官方指南要求创建 OAuth 2.0 Web Client。

其示例使用的重定向 URI 为：

https://vertexaisearch.cloud.google.com/oauth-redirect

开发者需要为相关 MCP 连接器配置授权 URL、Token URL、客户端 ID、客户端密钥与权限范围。

官方还建议启用 PKCE 支持。

PKCE 可以提高 OAuth 授权码流程的安全性，降低特定授权码拦截风险。

但 OAuth 的安全性不只取决于是否启用 PKCE。

生产服务还应正确校验令牌、授权范围、到期时间和用户身份。

不应该将客户端密钥硬编码在前端 HTML 中。

企业还应根据实际数据访问需求配置最小权限。

十三、如何在 Gemini Enterprise 注册 MCP 工具？

部署 MCP Server 后，还需要将其注册到 Gemini Enterprise。

根据 Google 官方指南，可以在 Google Cloud Console 中进入 Gemini Enterprise 的数据存储配置。

随后选择自定义 MCP Server 类型，配置对应服务地址和 OAuth 参数。

对于 Cloud Run 服务，MCP Server URL 通常采用类似格式：

https://YOUR-SERVICE.run.app/mcp

完成连接器创建后，需要重新加载服务器提供的工具列表。

Gemini Enterprise 可以通过工具发现机制识别 MCP Server 中的能力。

但工具并不会因为被发现就自动获得执行权限。

Google 官方说明，新导入的操作默认处于禁用状态。

管理员需要审核并选择允许使用的操作。

随后，将 MCP 数据存储连接到目标 Gemini Enterprise 应用。

这里需要注意，官方建议通过 Connected data stores 连接 MCP 服务，而不是将其作为外部子 Agent 随意添加。

二者属于不同集成方式。

十四、为什么交互式 UI 能降低模型调用次数？

考虑一个财务预测场景。

用户要求 AI 根据收入、成本和增长率生成分析。

传统聊天应用可能需要多轮交互。

第一次生成预测。

第二次修改增长率。

第三次修改成本比例。

第四次重新生成图表。

每次调整都可能产生新的模型调用。

如果使用 MCP App，模型可以先帮助用户建立预测界面。

随后，用户通过滑块或输入框直接调整参数。

部分计算可以由应用本身执行，而不必每次重新调用大模型。

这样有机会减少等待和 Token 消耗。

但并不是所有交互都可以完全在本地执行。

如果用户改变的问题涉及复杂自然语言理解，或者需要新的模型推理，仍然需要调用模型。

因此，MCP Apps 的价值是让传统 UI 与 AI 推理合理分工，而不是彻底取消模型请求。

十五、MCP Apps 有哪些典型商业场景？

法律文件审查

展示合同内容、条款风险和可操作的遮盖界面。

用户可以直接确认需要处理的区域。

企业财务分析

提供图表、参数滑块和预测工作区。

适合进行情景比较和预算调整。

3D 设计与 CAD

在兼容环境中提供可视化模型预览和交互操作。

模型负责解释设计任务，UI 负责具体展示。

数据分析

连接 BigQuery 等数据源，展示交互式图表和筛选条件。

客服后台

让 Agent 查询客户信息，再由授权员工在 UI 中确认后执行业务操作。

企业流程审批

显示待办事项、业务背景和批准按钮。

对于重要操作，审批必须经过可信的服务端授权验证。

以上是技术应用场景，不代表 Google 已经提供了每一种具体行业应用的完整现成产品。

十六、沙箱 iframe 是否意味着绝对安全？

不是。

Google 官方介绍，MCP Apps 的交互界面可以在沙箱 iframe 内运行。

这种设计能够在一定程度上隔离 UI 内容与宿主页面。

但 iframe 沙箱只是安全体系中的一层。

如果 UI 通过工具接口访问企业数据，后端仍然必须校验用户权限。

如果应用允许打开外部链接，还需要限制不可信目的地址。

如果用户上传文件，系统应检查文件类型、大小和处理权限。

同时，还要防范恶意网页内容或工具返回结果中的 Prompt Injection。

不能让工具返回的一段文字自动获得高权限命令执行能力。

因此，MCP Apps 应采用分层安全设计：宿主隔离、工具权限、身份认证、服务端验证和操作审计缺一不可。

十七、Human-in-the-loop 为什么重要？

Google 在 MCP Apps 官方文章中强调人工参与决策。

对于高风险业务，AI 可以准备操作建议，但最终执行需要用户明确确认。

例如，财务 Agent 可以计算新的预算方案。

但正式提交预算调整，应由有权限的人员批准。

同样，合同审核系统可以标记建议遮盖的敏感信息。

但最终导出文件之前，仍然应该由人员检查结果。

这类设计被称为 Human-in-the-loop。

它不是简单地给 UI 增加一个按钮。

真正重要的是，后端必须验证批准者的身份、权限以及操作对象。

如果只在前端显示一个确认按钮，而服务端没有执行授权检查，就不能形成有效的安全控制。

十八、MCP Apps 与普通 Web 应用有什么区别？

普通 Web 应用通常独立拥有自己的页面、导航、账户系统和业务交互。

MCP App 则可以被嵌入支持该协议的 AI 对话宿主中。

用户能够在同一个界面里完成自然语言交流和可视化操作。

两者并不完全互相替代。

对于复杂企业系统，独立 Web 应用仍然可能更适合大量页面、复杂表单和完整业务管理。

MCP Apps 更适合把某些任务型界面直接嵌入 Agent 工作流。

例如，一个完整 ERP 系统可能仍然保留自己的后台。

但其中的库存查询、审批或报表模块，可以根据需要通过 MCP App 提供给 AI 助手。

这种组合有机会提高用户的操作效率。

十九、企业部署需要控制哪些成本？

MCP Apps 的成本主要来自几个部分。

首先是 Cloud Run 等服务端基础设施。

其次是 Gemini Enterprise 及相关产品的服务费用。

第三是模型调用产生的费用。

第四是外部数据库、存储和业务 API 费用。

第五是开发维护和监控成本。

虽然交互式 UI 可能减少部分重复模型调用，但 Cloud Run 最小实例、后台任务和持续运行服务也可能增加固定支出。

因此，不能直接认为 MCP Apps 一定比普通聊天工具更便宜。

企业应该比较完整任务成本。

例如，完成一次财务分析需要多少模型调用、多少后台计算和多少人工操作。

只有结合真实业务，才能判断交互式 UI 是否带来可量化收益。

二十、如何测试 MCP App 是否达到生产要求？

建议至少覆盖五类测试。

第一类是功能测试，确认工具能够返回正确数据。

第二类是交互测试，检查按钮、表单和图表是否符合预期。

第三类是权限测试，确保不同用户只能访问被授权的数据。

第四类是异常测试，模拟网络中断、Token 过期和后台任务失败。

第五类是性能测试，记录界面加载时间、工具调用延迟和完整任务耗时。

对于具有审批功能的 App，还需要测试重复提交、并发修改和撤销行为。

此外，应测试宿主不支持交互式 UI 时的文本回退路径。

这样有助于提高 MCP 工具在不同客户端之间的可移植性。

二十一、常见问题 FAQ

MCP Apps 是 Google 独有协议吗？

不是。MCP Apps 是开放的 MCP 扩展机制，Google 展示的是其在 Gemini Enterprise 中的实现方式。

Gemini 普通聊天用户都能使用 MCP Apps 吗？

不能这样理解。此次官方指南主要针对 Gemini Enterprise 的开发和管理环境。

MCP Apps 必须部署在 Cloud Run 吗？

MCP Apps 协议本身不强制使用 Cloud Run，但 Google 此次 Gemini Enterprise 开发指南提供的是 Cloud Run 集成路线。

MCP Apps 能显示真正的交互式网页吗？

在支持的宿主中，可以通过沙箱 iframe 呈现交互式 HTML UI。

所有工具操作都需要调用大模型吗？

不一定。部分 UI 内交互可以直接由应用处理，但复杂任务仍可能需要模型推理。

是否支持 OAuth？

Google 官方示例使用 OAuth 2.0，并结合 Cloud Run IAM 建立双层身份验证。

MCP Apps 是否能替代整个企业业务系统？

通常不应这样理解。它更适合把特定业务操作和可视化工作区嵌入 AI Agent 使用流程。

二十二、结语：AI Agent 正在从对话框走向可操作的工作空间

Google Gemini Enterprise 的 MCP Apps 开发指南，展示了 AI Agent 交互方式的重要演进方向。

过去，用户主要通过自然语言让模型完成任务。

未来，AI 可以先理解用户目标，再将适合的工具和界面直接提供给用户。

对于简单问题，自然语言仍然是高效的交互方式。

对于需要反复调整参数、查看图表和完成审批的任务，交互式 UI 则可能更加适合。

MCP Apps 的价值，是让 AI 推理与传统软件界面相互配合。

但真正可靠的企业应用，仍然需要规范的工具接口、OAuth 权限验证、服务端业务控制、沙箱隔离和人工审批。

对于开发者而言，这意味着 MCP 不再只是连接模型和 API 的协议，也开始成为构建 AI 原生交互应用的基础。

未来 AI Agent 的竞争，将不仅取决于模型能够回答什么问题，还取决于它能否以安全、直观和可验证的方式，帮助用户真正完成工作。

官方参考资料

1. Google Cloud — Developer's guide to implementing MCP apps in Gemini https://cloud.google.com/blog/topics/developers-practitioners/devs-guide-to-mcp-apps-in-gemini

2. MCP Apps 官方项目与 SDK https://github.com/modelcontextprotocol/ext-apps

3. MCP Apps 官方快速入门 https://github.com/modelcontextprotocol/ext-apps/blob/main/docs/quickstart.md

4. MCP Apps 协议规范 https://github.com/modelcontextprotocol/ext-apps/blob/main/specification/2026-01-26/apps.mdx

5. Google Cloud Run 官方文档 https://cloud.google.com/run/docs