一次接入，同时出现在搜索和 Gemini 里：Google 开放 Connected Apps 平台预览

10 月 28 日，Google 发布了一个对普通用户几乎不可见、但对开发者可能很重要的东西：Connected Apps Platform 预览。用 Google 自己的话说，这是一个统一的平台，让开发者一次接入，就能把自己的服务能力带进搜索（Search）和 Gemini 应用两个地方。更直白地讲，以后用户在搜索框或者 Gemini 里问一句话、办一件事的时候，答案里可能直接就包含你的应用的功能，而不只是给你一个链接，让用户自己点过去再慢慢找。

先把这次发布到底包含什么说清楚。公告由 Google 搜索产品经理 Chips Mistry 和 Gemini 应用产品经理 Mai Lowe 联合署名，日期是 2026 年 10 月 28 日。平台本身目前处于预览阶段，不是正式全面开放。开发者有两条接入路线：一条是云端托管的 MCP 服务器，MCP 是当下业界普遍采用的开放标准；另一条是 Android MCP，用的是 AppFunctions API，让安卓应用把自己的功能暴露给 Gemini、在设备端运行。接好之后，开发者在 Google Connected Console 里完成注册、测试和提交，上线前自己选：只上搜索、只上 Gemini，还是两个地方都上。上线之后可以在控制台里看流量、延迟和错误率，同时保留对品牌形象的控制，包括经过验证的 logo 和已认证的账号。

已经上线的 50 多个应用，和这次新提到的名字

同一篇公告还交代了现有规模：搜索和 Gemini 之间已经上线了 50 多个 Connected Apps，覆盖生产力、活动票务、健康健身等领域。这次点名的新伙伴包括 Adobe、Experian、Localiza 和 Peloton，这几家的集成已经在 Gemini 里对用户开放，Google 说未来几周内也会把它们带到搜索里。另外还有一个需要仔细区分的名字：Calm。公告对 Calm 的措辞是“也将推出”横跨搜索和 Gemini 的新集成，也就是说它当时还不是已上线状态。把“将要推出”读成“已经上线”，是这类公告最常见的误读。

50 多个这个数字本身也值得多看一眼。公告说的是搜索和 Gemini“之间”一共 50 多个，并没有说明一个同时出现在两个产品里的应用算一次还是算两次，也没有给出完整名单，只是指向了搜索和 Gemini 各自的帮助中心页面。这意味着读者无法仅凭这篇公告还原出完整的版图。数字本身是 Google 自报的，放在“已经有一定规模、但还远没到全面铺开”的位置上理解比较合适：它足够说明这不是一个从零开始的实验，但也远不是一个人人都能立刻用上的开放市场。

为什么“一次接入、两个入口”值得重视

对开发者来说，这次发布真正有分量的部分不是某一个新功能，而是一个分发位置的变化。过去，一个应用想要被用户用起来，通常要先经过下载、安装、注册、打开这一串动作，每一步都会流失人。而 Connected Apps 的逻辑是反过来的：用户先有一个具体的问题，比如订一间房、查一个行程、处理一份文档，Google 在回答的时候直接把能办事的应用能力嵌进去。对用户而言，路径从“先找应用再办事”变成了“在问问题的地方直接把事办了”；对开发者而言，竞争的标的也从“谁的应用装机量大”变成了“谁的功能恰好能回答用户当下的问题”。

这对小团队和独立开发者尤其值得注意。大平台的分发规则一向对头部友好，因为头部有品牌、有预算、有谈判筹码。但在“按问题匹配功能”的模式里，一个功能做得足够准、足够深的小应用，理论上有机会在某类具体问题上被选中，而不需要先在应用商店里爬榜。当然，这只是理论上的机会，实际能分到多少流量，取决于 Google 的匹配和排序规则，而这部分规则这次并没有公开。下文会专门讲这个缺口。但至少从方向上看，这个平台降低了“做出一个好功能”和“让用户在需要的时候遇到它”之间的距离，这对资源有限的开发者是真实的利好。

另一层意义在于技术路线的选择。Google 这次把云端 MCP 服务器放在了和 Android 原生路线并列的位置，这等于公开押注 MCP 会成为应用能力接入 AI 入口的通用语言。对已经在用 MCP 的团队来说，这是一次顺水推舟：同一套服务端能力，以后可能同时服务多个入口。对还没有接触过 MCP 的团队来说，这是一个明确的信号，值得花时间去读一遍文档、理解它的能力边界，而不是等到所有入口都要求它的时候再匆忙补课。技术标准的窗口期往往就是这样出现的：当大平台开始用它来铺分发渠道时，学习成本最低，话语权也最大。

公告没说的四件事，恰恰是最关键的四件事

这篇公告很短，短到可以逐字读完。也正因为短，它没说的部分反而格外显眼。第一，费用和分成。公告没有提到开发者接入要不要付费、平台会不会抽成、用户通过 Connected Apps 完成交易时钱怎么分。对一个要靠它吃饭的开发者来说，这不是细节，这是商业模式本身。第二，入选和排序规则。Google 没有说明什么样的应用能进预览、审核标准是什么、同一个问题有多个应用都能回答时由谁先出现、排序依据是什么。没有这些规则，开发者就无法判断自己投入的开发成本能不能换来稳定的曝光。

第三，市场和语言范围。公告只说“未来几个月会增加更多开发者、市场和 Google 产品”，但没有列出第一批开放给哪些国家和地区、支持哪些语言。对面向全球用户的开发者，这意味着不能假设自己的目标市场已经在覆盖范围内；对面向特定区域的开发者，这意味着要先确认自己在不在第一批里，再决定投入节奏。第四，预览的结束标准。公告没有说预览期多长、转正的条件是什么、预览期间的政策会不会变。一个处于预览阶段的平台，其规则、入口位置、展示方式都可能调整，把核心业务完全押注在一个规则还可能变的入口上，风险需要被认真定价。

还有一个同样没有交代的问题：用户数据。当一个应用的能力嵌进搜索和 Gemini 的回答里，用户的一次提问、一次操作，会在多大程度上流向第三方应用？公告提到了品牌控制和已认证账号，但没有展开数据流转的边界。对处理健康、财务、行程这类敏感信息的开发者来说，这不是可以事后补的问题，必须在接入之前就向 Google 的文档和政策要到明确答案。如果文档里也没有，那就意味着这个方向目前还不适合放敏感场景，至少不适合作为唯一通道。

平台机会和平台风险，永远是同一枚硬币的两面

所有“一次接入、多处分发”的平台故事都有相同的结构：前期红利真实存在，后期规则收紧也几乎必然发生。早期的好处是竞争少、位置好、平台愿意扶持标杆案例；后期的常态是审核变严、排序向头部倾斜、政策调整的成本由开发者承担。Connected Apps 现在处于明显的早期阶段：预览、分阶段开放、50 多个应用。这个阶段最适合做的事情，是用小成本验证“自己的功能是否真的能在问答场景里被需要”，而不是立刻把整个产品的获客策略都押上去。

一个更具体的风险是入口依赖。当用户的习惯从“打开你的应用”变成“在 Google 里问一句、顺手用了你的功能”之后，你和用户之间的关系就隔了一层平台。平台调整一次展示规则、改一次排序算法、收紧一次审核口径，你的流量就可能跟着波动，而你对此几乎没有议价能力。这不是说不要接入，而是说接入的同时要保留自己的直达通道：自己的网站、自己的应用、自己的用户联系方式。把 Connected Apps 当成新增的获客渠道，而不是唯一的获客渠道，是对冲这种风险最简单的做法。

品牌控制这一点也值得单独拎出来看。公告特意提到上线后可以保留品牌形象，包括验证过的 logo 和已认证账号。这个细节说明 Google 意识到了开发者的顾虑：在别人的界面里提供服务，最怕的就是被抹掉名字、变成无差别的后台能力。对中小开发者来说，品牌露出不是虚荣，而是用户下次还能不能找到你的关键。如果你的功能在回答里出现时用户根本不知道是你提供的，那这次曝光的长期价值就大打折扣。接入之前，先确认自己的品牌元素在两种入口里分别长什么样，再决定投入多少。

现在可以做的几件事

第一步是去读文档，而不是先写代码。公告指向的 developers.google.com/connected-apps 是起点，重点看两条路线的适用条件：你的服务更适合云端 MCP，还是更适合 Android 端的 AppFunctions；你的功能是适合一次性调用，还是需要多轮交互；你的用户场景在搜索里更常见，还是在 Gemini 的对话里更常见。这几个判断做在前面，比接入之后再返工要便宜得多。

第二步是想清楚“哪一个用户问题由你来回答”。Connected Apps 的竞争单位不是应用，而是功能。你的应用可能有十个功能，但真正适合嵌进问答场景的也许只有一个：那个用户会在提问时自然想到的、最具体的、一步就能完成的事。把这一个功能打磨到足够可靠、足够快、足够清晰，比把十个功能都接进去更有价值。预览阶段的审核和排序大概率会奖励那些场景清晰、完成度高的功能，而不是功能清单最长的应用。

第三步是按分阶段开放的节奏安排投入。预览是分批开的，第一批没轮到你不代表被拒绝，也不代表要无限期等待。在等待的窗口里可以做的事包括：把 MCP 服务端搭起来并跑通测试、准备好品牌素材和账号认证材料、梳理好数据流转的合规说明、以及在自己的渠道里先验证这个功能本身是不是用户真的需要的。这些准备工作无论最后走哪个入口都有用，不会因为排队而浪费。

放在 10 月底的大图景里看

值得注意的是时间点：Connected Apps 预览和 Gemini 4 Carbon 的发布是同一天，10 月 28 日。一边是最强的模型先给防守者、分阶段放出；一边是把第三方应用能力嵌进搜索和 Gemini 的入口、分阶段开放。两件事的节奏一模一样：先给少数人、边收集反馈边扩围。这说明 Google 在 10 月底同时推进了两条线：模型能力线和分发入口线。对开发者来说，这意味着未来几个月的变量不只在模型本身，还在模型回答问题时愿意把哪些第三方能力带进来。只盯着模型参数变化的人，可能会错过分发规则变化带来的机会。

对 vibe coding 的开发者来说，这件事还有一层更直接的启示。过去，一个 vibe 项目想要获得用户，往往要先解决一整套问题：部署、上线、推广、留存。而 Connected Apps 指向的是一种更轻的可能性：一个功能单一但做得很好的小工具，有机会直接出现在用户提问的地方。当然，这只是可能性，不是承诺。预览阶段的门槛、审核和排序都还没有完全公开，任何把“接入就能获得流量”当成确定收益的说法都是过度承诺。但方向本身值得认真对待：当 AI 入口开始成为用户办事的第一站时，“做一个能被问到的小工具”可能会成为和“做一个应用”并列的另一条路。对资源有限的独立开发者而言，多一条路，本身就是好消息。

最后给一个判断。Connected Apps Platform 预览不是一次轰动性的发布，它没有新模型、没有惊人的基准分数、也没有面向所有人的开放时间表。但它可能是 10 月底最值得开发者花时间读的一篇短公告，因为它讲的不是技术能做什么，而是用户未来会在哪里遇到你的产品。入口的变化总是比模型的变化来得慢，但一旦形成习惯，就很难逆转。现在花一个下午读文档、想清楚自己的功能对应哪一个用户问题，成本很低；而等到入口规则定型、位置被占满之后再入场，成本只会更高。预览阶段最大的价值，从来不是立刻获得流量，而是提前理解规则。

给两类开发者的不同建议

已经有成熟产品的团队，接入 Connected Apps 应该被当成一次渠道实验，而不是一次产品改造。先挑一个最适合问答场景的功能做试点，单独衡量它带来的新增使用和新增用户，再决定要不要扩大接入范围。试点期间最值得记录的指标不是曝光次数，而是完成率：用户在回答里用了你的功能之后，有多少人真的把事情办完了、有多少人中途放弃、有多少人之后又回来直接找你。这些数字会告诉你，这个入口对你的产品到底是增量，还是仅仅把原来就会发生的访问换了一个地方。

从零开始的独立开发者，思路可以反过来。不要先想着做一个功能齐全的应用，再去申请接入；先找到一个具体到可以用一句话描述的用户问题，把解决这个问题的最小功能做到足够好，然后再看它是否适合嵌进搜索和 Gemini 的回答里。这种“问题先行”的做法还有一个附带好处：即使最后没有排上预览、或者排序规则对你不利，这个小工具本身仍然是一个可以独立存在、可以直接分发的产品，不会因为平台的节奏而归零。平台可以放大一个好功能，但不应该成为一个功能存在的唯一理由。

还有一个容易踩的坑值得单独提醒：不要把 Connected Apps 当成搜索优化或者应用商店优化的延续。过去的优化逻辑是争夺排名和关键词，未来的匹配逻辑是理解用户的问题、判断哪个功能最适合回答它。堆砌关键词、夸大功能描述、把不相关的场景都往自己身上揽，在这种模式里大概率适得其反：一次答非所问的匹配，损失的不只是一次曝光，还有用户对这个入口本身的信任。平台对这类行为的容忍度通常会随着规模扩大而收紧，早期靠取巧拿到的位置，往往也是最先被清理掉的位置。把功能描述写得准确、克制、可验证，是在这个新入口里最划算的长期策略。

最后再回到普通用户这一边。这次发布对用户体验的改变不会在一夜之间发生，预览是分阶段的、伙伴是逐步上线的、搜索端的覆盖也要等未来几周。但方向是确定的：搜索和对话助手正在从“给你一堆链接”变成“直接帮你把事办了的一部分”。对用户来说，这意味着以后评价一个回答好不好，不只是看它说得对不对，还要看它能不能顺手把事情办完。对开发者来说，这意味着产品价值的衡量标准也在变：不再只是功能多不多，而是你的功能能不能在用户最需要的那一刻、恰好出现在他面前。Connected Apps 预览的真正意义就在这里：它把这个问题的答案，从“以后再说”变成了“现在就可以开始准备”。