谷歌开放统一 MCP 应用接入预览

dev.to · AI#谷歌#MCP#应用集成

Editor brief · 编辑速览

Connected Apps Platform 让开发者通过一套 MCP 接入流程，将第三方应用发布到 Google Search、Gemini 或两者。平台提供注册、测试与提交控制台，目前处于预览阶段，后续将逐步扩大开放范围。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

Google 想把第三方服务接入 Search 和 Gemini 的流程收拢到同一个开发者平台。按原文介绍，2026 年 10 月 28 日公布的 Connected Apps Platform 预览版，提供统一的 MCP 接入路径，以及注册、测试、提交审核的控制台。

对程序员来说，值得关注的是服务接入后的管理方式：同一套接入流程可以面向两个 Google 产品，还能查看流量、延迟和错误。但它目前给出的是接入框架，具体能覆盖哪些市场、获得多少用户，仍然有待确认。

Connected Apps Platform 的核心，是把跨产品接入做成一个共同的开发者项目。开发者可以在接入时选择目标位置：Google Search、Gemini app，或者两者都选。

这里要分清「选择目标」和「实际可用」。选择两个产品，不代表应用提交后就会立即出现在所有用户面前。原文明确提到，平台采用分阶段开放，接下来几个月会逐步扩展开发者、市场和产品，应用也需要通过审核。

统一接入流程，不等于承诺统一分发。

平台的管理入口叫 Google Connected Console。开发者在这里注册应用、测试集成并提交审核，也能管理应用品牌信息、Logo 和已认证账号。它把协议连接之外的上线事务放到了同一个地方。

Google 表示，Search 和 Gemini 上已经有超过 50 个 Connected Apps。不过，这个数字只能说明已有接入基础，不能用来推断预览版的开放程度。原文没有说明这批应用的市场分布、接入条件或实际使用量。

因此，这次变化更适合理解为「接入与管理层的整合」。至于不同产品里的交互是否一致、能力是否完全相同，原文没有给出足够信息。

原文确认了两种接入方式：

MCP 的全称是 Model Context Protocol。放在这里理解，它承担的是第三方应用与 Google 产品之间的连接协议角色，让服务可以通过平台规定的方式参与交互。

这两个选项很具体，但原文没有提供实现代码、SDK 版本、接口定义或部署要求，也没有解释两条路线的能力差异。不能仅凭「支持 MCP」，就断言现有 MCP server 可以不做适配直接上线，更不能把 Android MCP 的条件套到普通 Web 应用上。

更有用的规划顺序，是先回答一个产品问题：用户在 Search 或 Gemini 中，为什么需要调用你的服务？

原文建议先找一个范围明确的任务，弄清楚它需要什么信息或工具访问权限，再选择连接路线和目标产品。这个顺序成立，因为一个服务即使已有许多 API，也不代表每个接口都适合放进搜索或对话场景。接入价值取决于它能否帮用户完成具体事情。

对前端和全栈团队而言，可以先把已有服务整理成一份清晰的任务说明：用户输入什么、服务返回什么、何时涉及账号。之后再评估连接方式。这里的任务梳理是工程准备建议，原文并没有给出一套已经验证过的实现模板。

Connected Apps Platform 提供三类分析数据：流量、延迟和错误。

这三类指标分别回答不同的问题：有没有请求到达、响应需要多久、请求是否失败。对接入外部入口的服务来说，它们很实用。只看调用量，很容易把「有人触达」误判为「体验有效」；响应缓慢或持续报错，同样会让集成失去价值。

但原文没有给出性能阈值，也没有服务级别承诺。不能据此推断平台会保证某个响应时间，或者自动解决服务端的稳定性问题。平台提供观测数据，团队仍需决定怎样使用这些数据定位和改进问题。

商业机会也要按同样的尺度看。Google 公布的合作方包括 Adobe、Experian、Localiza 和 Peloton，并提到 Calm 正向 Search 与 Gemini 两个产品扩展。这些名字能说明平台尝试覆盖多种服务类别，却不能证明普通开发者会获得相同的展示位置和接入待遇。

原文还留下两项直接影响决策的信息空白：哪些应用会在哪些市场可用，以及参与平台需要什么费用。对国内团队来说，目标市场是否在开放范围内，应当放在投入评估的前面。

我认可统一管理入口的方向。相比为不同 Google 产品分别维护接入流程，把注册、测试、审核、目标选择和运行指标集中起来，确实有机会减少重复工作。

但「有机会减少」仍然是判断。原文没有作者或团队的实测过程，没有接入耗时、维护成本，也没有与分别集成 Search、Gemini 的对照数据。它是一篇平台公告解读，不能当成效果评测。

MCP 也只回答了一部分问题。连接协议得到统一之后，任务设计、账号使用方式、失败处理和服务质量仍然需要团队自己解决。原文没有交代认证的具体机制，不能从「支持已认证账号」进一步推导出完整的权限方案。

相比继续经营自己的网页或应用，这个平台可能增加一个用户接触服务的入口，但现阶段还不足以支撑「用户会迁移过来」的判断。触达规模、使用频率和商业回报都没有数据。更稳妥的取舍，是准备一个边界清楚的候选任务，等接入条件明确后再评估投入。

另外，原文末尾出现了 Scalevise 的 MCP 实施服务推广。它不影响前面列出的平台信息，但商业建议部分带有服务销售目的，阅读时应与 Google 已确认的能力区分开。