devgo.cn企业级 AI 助手最常见的形态是聊天框：你问一句，它回一段文字。但遇到“帮我审阅这份合同，把敏感条款标红”“调整这个 3D 模型的视角”“把这份财务报告的异常数据圈出来”这类需要视觉、多步骤、反复微调的任务时，纯文本对话就卡壳了——每改一次参数，都要再发一轮消息，等模型重新生成，慢且笨重。
Google Cloud 最近发布的 MCP Apps（SEP-1865 规范）就是冲着这个痛点来的。它是 Model Context Protocol（MCP，一种让 AI 模型与外部工具通信的开放标准，类似给模型装 USB 接口）的扩展，核心思路是：**给每个工具配一个实时 UI**。在 Gemini Enterprise 里，这个 UI 直接渲染在聊天流内部的一个沙箱 iframe（隔离的网页容器，防止页面访问宿主系统数据）中，可以展开成全屏或侧边栏。你在 UI 上做的每次点击、拖拽、调整，都在本地直接执行，不需要再经过一轮模型推理，而助手和这个工作区始终保持同步。
这背后其实反映了企业助手的三代演进。第一代是纯文本聊天机器人，返回静态 Markdown，没有任何交互控件；第二代是标准 MCP 工具，能调用实时 API，但输出仍是静态文本，每次改动都要再让模型跑一轮；第三代就是 MCP Apps，把工具和实时工作区绑定，调整在组件内完成，不打断对话流。
为什么这件事值得关注？因为它把企业助手从“问答机”升级成了“工作台”。六个直接收益：响应式体验（单击操作直接在面板执行，不用绕道聊天）；定制化工作流（给法务做可视化脱敏视图、给 CAD 做 3D 查看器、给金融做敏感度模型）；企业级安全（工作区 OAuth 登录、私有 Cloud Run 入口、沙箱 iframe 层层防护）；人在回路治理（专家在高风险操作执行前审批）；开放标准（可跨兼容宿主迁移，且自动降级为文本）；广泛连接（能接 BigQuery、Agent Platform、Cloud Storage 或内部 ERP/CRM）。
架构上分三层解耦：客户端浏览器负责显示聊天和侧边栏组件；Gemini Enterprise 负责默认助手调用工具、AppBridge 代理转发组件消息、连接器管理 OAuth；你的 Google Cloud 项目负责把 MCP 服务器部署在 Cloud Run 上，暴露一个 JSON-RPC 端点（/mcp），跑后台任务，并托管单文件 HTML 组件。每层只和邻居通信，安全与路由由 Gemini Enterprise 统一管控。
认证是两层独立体系，这点很关键。每个用户通过 OAuth 2.0 登录，每次调用时 Gemini Enterprise 会把服务代理令牌和用户 OAuth 令牌一起发出去。第一层是 Cloud Run IAM（身份与访问管理，控制哪个服务能调用），在 Google 边缘强制执行，回答“哪个服务可以调用”，公网访问被禁用，未授权调用返回 HTTP 403；第二层是应用内 OAuth，在应用内部执行，回答“哪个用户正在调用”，验证失败返回 HTTP 401，提示用户重新登录。为什么需要两层？因为 Cloud Run IAM 无法区分终端用户，所以两层缺一不可。出站调用使用最小权限服务账号。
部署流程也相当顺滑。先用 MCP Apps SDK 构建自定义 MCP 服务器（暴露 POST /mcp 和打包的 ui:// HTML 组件），或者直接用 Google Antigravity 通过一段 starter prompt 脚手架生成并部署。生成的内容包括：单文件 HTML 组件、一个 Streamable HTTP 后端（POST /mcp，异步工具响应小于 2 秒，支持 get_app_state 轮询）、以及 Cloud Run 部署命令（--no-allow-unauthenticated、--no-cpu-throttling、--min-instances=1）。
之后七步接入 Gemini Enterprise：启用 Cloud Run、Discovery Engine、Agent Platform、Organization Policy 的 API；从源码部署容器到 Cloud Run，注意 --no-cpu-throttling 防止后台任务在轮询间隙被冻结，--min-instances=1 保证实例常驻；给 Discovery Engine 服务代理授予 run.invoker 角色（第一层）；创建 OAuth 2.0 Web Client，redirect URI 指向 https://vertexaisearch.cloud.google.com/oauth-redirect（第二层）；覆盖 discoveryengine.managed.disableCustomMcpServerConnector 约束，完成前置条件（管理员要有 roles/discoveryengine.editor，配置 allowedEgressFqdns 和 allowedDataSources）；在 Gemini Enterprise > Data stores 里创建数据存储，选择 Custom MCP Server 注册连接器；在 Actions 里点击 Reload custom actions（会调用服务器上的 tools/list），选择模型可见的工具并启用；最后把数据存储连接到你的应用，注意要用“Add existing data stores”而不是“Add Agent”——后者是给外部子代理用的，不是 MCP 数据存储。
最让我意外的是整个方案的克制：你不需要自己搭聊天前端，也不需要建身份管道，只部署一个 Cloud Run 容器，把它作为 Data Store 挂上去，Gemini Enterprise 就变成了企业工作真正发生的地方。
这套思路能直接用到哪些场景？如果你正在做企业内部 AI 助手，尤其是涉及文档审阅、数据可视化、设计工具、运维控制台这类“需要人反复操作”的任务，MCP Apps 提供了一条不用重造轮子的路径。要注意的坑：一是异步工具响应必须控制在 2 秒内，否则轮询体验会差；二是 Cloud Run 的 --no-cpu-throttling 和 --min-instances=1 是必须的，否则后台任务会被冻结、冷启动会拖慢首次交互；三是两层认证缺一不可，别想着省掉应用内 OAuth。
如果你不想从零写，Google Antigravity 的 create-mcp-app skill 可以直接脚手架生成，值得一试。
内容与图片版权归原作者所有 · 原文: https://cloud.google.com/blog/topics/developers-practitioners/devs-guide-to-mcp-apps-in-gemini/