AI 时代的 App Store 时刻到了?

2008 年，苹果开放 App Store 的那一刻，有多少人意识到这是一个历史性的分水岭？当时大多数人只觉得这是一个让手机能下载应用的商店，但两年不到，苹果就向开发者支付了超过 10 亿美元的分成。一个全新的市场就这样从零开始长了出来，无数个人开发者和小团队靠这个平台改变了自己的命运。现在，我觉得一个极其相似的时刻正在发生，只不过这次的舞台不是手机，而是 AI agent（AI 智能体）。

Meta 最近宣布向开发者开放 Muse，也就是他们的个人 AI agent，并推出了一个叫做 Connector（连接器）的机制，允许开发者把自己的服务接入进来，当用户向 Muse 发出请求时，Muse 可以调用这些外部服务来完成任务。初创公司研究者、播客主持人 Greg Isenberg 做了一期深度分析，专门聊了这件事意味着什么，以及他看到的创业机会在哪里。听完之后，我有很多想说的，既有对 Greg 观点的梳理，也有我自己的一些思考。

App Store 的类比 有多像就有多重要

Greg 用 2008 年 App Store 开放来类比这次 Muse Connector 的推出，我觉得这个比喻抓住了最核心的结构性变化。App Store 出现之前，软件分发是一件极其昂贵且复杂的事，你要自己建网站、自己做支付、自己做推广，门槛很高。App Store 把分发和支付这两件最难的事都帮你做了，开发者只需要专注于做出好东西。而这一次，Meta 做的事情本质上也一样，他们已经建好了那个"手机"，也就是 Muse 本身，拥有了大量用户，现在他们在说，外部的服务可以通过 Connector 接进来，当用户有需求的时候，Muse 会帮你触达到他们。

但 Greg 还点出了一个比 App Store 类比更有趣的地方，我觉得这才是真正值得深想的部分。在传统 App Store 里，用户要主动搜索、主动下载，你的服务必须是他想找的那个东西。但在 Muse Connector 的逻辑里，用户不需要知道你的存在，他只是在向 Muse 说他想做某件事，Muse 会在中途判断需要调用哪个服务来完成这个请求。Greg 举了一个很形象的例子：一个人在组织一场小型活动，对话一开始是关于场地的，但聊到某个时刻，他意识到还需要租设备。这时候，一个做设备租赁的 Connector 就可以在对话中途插进来，成为整个流程的一部分。这种"在需求链条中途被调用"的逻辑，是 AI agent 时代特有的分发方式，App Store 里根本没有这种东西。

我自己理解下来，这其实意味着一件很重要的事：在 AI agent 时代，服务的可发现性不再依赖用户的主动搜索，而是依赖 agent 的智能调度。这对小团队和初创公司来说，既是机会，也是挑战。机会在于你不需要砸钱做品牌知名度就能被触达到，挑战在于你必须让你的服务足够垂直、足够具体，让 agent 在正确的时刻调用你，而不是调用别人。

Connector 到底是怎么工作的

Greg 用了一个很具体的例子来解释 Connector 的运作方式：你告诉 Muse 你需要在周二下午租一个两小时的播客录音室，预算 200 美元。Muse 需要知道你在哪个城市、要录什么类型的内容，然后去找一个能回答"周二有没有合适的房间"这个问题的服务。这个服务通过 API（应用程序编程接口，即两个软件之间互相通信的方式）接入进来，像一个服务窗口一样：你问它周二的档期，它告诉你有一个 160 美元含设备的房间。Muse 把这个结果展示给你，你确认之后，服务完成预订，发回确认信息。

这个流程听起来简单，但 Greg 补充了一句我觉得特别重要的话：agent 让服务变得更容易被请求了，但服务本身还是得好。换句话说，Connector 解决的是触达问题，不是质量问题。录音室的日历得是准确的，设备得能用，客人进门遇到问题得有人处理。这一点我很认同，很多人看到 AI 的分发红利就觉得只要接进去就能赚钱，但如果服务本身不扎实，被调用一次可能就被用户差评排到后面去了。

他还提到了一个现实案例，一家叫 Duffel 的旅行服务公司，他们的 Muse 集成可以让用户直接通过 Muse 搜索航班和管理预订。Duffel 的年度交易额已经超过 10 亿美元。Greg 说这个案例说明的是：一个已经提供了有价值服务的公司，通过新的接口让自己变得更容易被访问。这个思路我觉得对已经有产品的人来说很有参考价值，不一定要新建一套东西，看看你现在的 API 里是不是已经有一个可以直接包装成 Connector 的能力。

Greg 给出的四个创业方向

Greg 在视频里列了四个他认为有潜力的 Connector 创业方向，我把它们梳理一下，也说说我自己的看法。

方向一是本地商业供应商的 lead gen（潜在客户生成）。Greg 举的例子是一个迈阿密的亚麻布料服务商，他们给餐厅供应桌布和餐巾。他们可以向 Muse 询问附近有哪些新开的餐厅可能需要他们的服务，Connector 就去追踪这些开业信息，拉回来相关餐厅的联系方式和预计开业时间。Greg 说这类业务的核心价值是"时效性"，不是一般的联系人搜索，而是在正确的时机发现正确的潜在客户，比如一家餐厅刚宣布要开业，这就是切入的窗口。他估算了一下，如果 100 个客户每月付 99 美元，每月就是近 1 万美元的 MRR（月度经常性收入）。Greg 说他会把这个方向放在最优先，因为在写多少代码之前就可以先做一个样本展示给潜在客户看，验证需求的成本极低。

方向二是上门维修调度。场景是用户告诉 Muse 洗碗机坏了，需要找一个能修特定型号三星洗碗机、明天能上门的师傅。Connector 去核查合作维修公司，返回能处理这台机器且有明天档期的服务商，用户选择后确认预约。Greg 说可以向维修公司收一个固定的 lead 费或预约费，大约 100 美元一单。他提到 Thumbtack 这个平台已经验证了人们愿意为上门服务的客户 lead 付费，所以商业逻辑是成立的，关键是你的 lead 质量得足够高，维修公司才愿意持续买单。

方向三是本地运动场地和约战匹配，Greg 用的是 padel（帕德尔球，一种流行于欧美和拉美的拍类运动）的例子，因为他本人就很喜欢这项运动。用户在 Muse 里说想找今晚附近和自己水平相近的 padel 对手，Connector 去查合作球场的空档，返回合适的场次和费用。Greg 还提到 Meta 本身是一家社交属性极强的公司，Muse 未来大概率会越来越社交化，这类涉及多人参与的场景会有天然的优势。

方向四是家庭晚餐规划加买菜集成。父母告诉 Muse 接下来三晚的晚餐每顿最多做 20 分钟，家里已经有米和西兰花，Connector 根据这些条件给出食谱，把缺少的食材整理成购物清单，再通过 Instacart（一家美国在线生鲜配送平台）的开发者工具生成一个可以直接结账的购物单。Greg 说这个方向有订阅潜力，如果孩子喜欢这些菜，家长就有理由每周都用，核心是食谱得真的好吃，分量得真的合适。Greg 甚至提到，如果这个方向跑起来了，Instacart 这样的大平台没准直接把这个 Connector 收购了。

这四个方向我觉得有一个共同逻辑，Greg 选的都是"有明确金钱流动的真实交易"，不是信息查询，不是内容推荐，而是有人付钱、有事情发生的场景。在 AI agent 的分发逻辑下，能够真正完成交易闭环的 Connector 才是最有价值的，因为它能证明自己创造了真实的经济价值，也更容易被 Meta 推荐，被用户记住。

你的 Connector 怎么让人用到

Greg 专门聊了一个很现实的问题：进了 Meta 的 Connector 目录又怎样？目录里有那么多服务，凭什么是你被调用？他给了三个他认为更可靠的增长路径。

第一个是和有受众的创作者合作（creator partnership）。Greg 举的例子是：如果你做的是家庭晚餐规划的 Connector，就去找一个专门分享素食食谱的育儿博主，让她展示如何用你的服务把几顿饭变成一个超市购物单。这种合作的核心不是创作者的粉丝量有多大，而是她的受众是不是真正有这个需求的人。Greg 说他更在意第一批用户完成第一个任务的比例，而不是触达多少人。

第二个是产品本身带动传播，也就是 product-led sharing（产品驱动的分享）。Greg 用 padel 的例子说明：一个人预订了球场，会自动给另外三个球友发一个含有时间和地点的分享页面。这些球友在看到这个分享、用它来确认参与之前，根本没用过你的 Connector，但他们已经在体验你的产品了。Greg 说这种机制在移动互联网时代驱动了大量社交 app 的增长，在 AI agent 时代同样有效，因为 agent 天然是帮人完成任务的，而很多任务本来就是多人协作的。

第三个是通过已有的联网平台来获取供给。Greg 提到 Ticketmaster 现在已经是一个 Connector，活动主办方在 Ticketmaster 上发布活动，就等于自动进入了 Muse 的生态，不需要自己单独做集成。如果你所在的行业有一个这样的聚合平台，搞清楚如何在上面参与，可能比自己单独建一个 Connector 更快。

关于靠 Meta 目录的自然流量来获客，Greg 说得很直白：不要指望它。他自己当年在 App Store 获得首页推荐是半随机的事件，你无法预测也无法控制。重要的是，在等待那个运气之前，你要有一条自己能掌控的路径把第一批真实用户带进来。

我自己在想，这三个路径背后有一个更底层的逻辑，就是在 AI agent 时代，你的服务能不能在用户自然的对话流里被发现，取决于两件事：一是你是不是真的在正确的时刻被调用，二是被调用之后的体验好不好，好到让人愿意分享或者下次再用。这两件事都跟产品质量直接相关，绕不开。

怎么开始做一个 Connector

Greg 对如何动手构建第一版 Connector 给出了很具体的建议，我觉得这部分对真正想行动的人来说最有参考价值。他说最重要的第一步，是写下用户通过你的 Connector 应该能完成的一件具体事情，越具体越好。用 padel 球场举例，就是"给我看明天晚上我附近可以预订的球场，每个都显示价格"，就这一件事，不要多，先把这件事跑通。

然后，你可以把这个需求描述交给 Claude Code 或者 Codex 这样的 coding agent（AI 编程助手），同时提供你要接入的那个系统的文档，让它帮你构建可用性查询和报价功能，先跑通这两个，预订功能等这两个稳了再加。Greg 特别强调了这件事的历史意义：在 App Store 时代，做一个高质量的移动 app 需要一两百万美元和一个十人团队，现在任何人打开 Claude Code 就能开始做这件事，这是一个真实的门槛变化。

在提交给 Meta 审核之前，Greg 建议做充分的边界测试：试着预订一个已经被占掉的时段，试一个过期的报价，检查重复请求会不会重复创建预订，以及在用户最可能追问的下一个问题上测试系统，比如"能不能把球场改到另一天"。这些边界情况处理不好，被 Meta 拒审的概率很高，而且就算过了审，真实用户遇到这些情况会直接流失。

Meta 目前要求提交 Connector 时提供 API 信息或已有的 MCP server（MCP 是一种让 AI 应用可以调用外部工具的标准协议），还需要填写产品介绍和具体使用场景的示例。Greg 说这个项目太新了，现在连 Meta 每天审多少个提交都不清楚，所以他建议边建边提，不要等到完美再提。

我自己的一些深度思考

听完 Greg 的整个分析，我有一个想法一直在脑子里转：这一次 Connector 这个入口，可能比 App Store 更深刻地改变服务的分发逻辑，但同时也更难判断谁是真正的赢家。

App Store 时代，用户还是主动的，他知道自己在找什么，搜索一个关键词，看评分，然后决定下不下载。这个过程里，服务的品牌和名字都是有价值的，用户记住了你，下次还会回来。但在 Muse Connector 的逻辑里，用户不需要知道你叫什么名字，他只是把任务丢给 Muse，Muse 帮他找谁来做。这意味着，品牌在这套体系里的权重被大大削弱了，用户的忠诚度首先是给 Muse 的，不是给你的服务的。

这让我想到了一个很重要的问题：对于那些通过 Connector 接进来的服务，长期的竞争壁垒是什么？如果壁垒只是"我进了 Muse 的目录"，那等到更多 Connector 进来之后，这个壁垒几乎什么都不是。真正的壁垒应该是：你的服务在某个垂直场景里做到了最深，有独特的供给或数据，Muse 在这个场景里调用你比调用任何人都能给用户更好的答案。Greg 提到的那几个方向，lead gen 的时效性数据、维修服务的本地合作网络、球场资源的独家接入，这些才是真正的壁垒，不是 Connector 这个形式本身。

还有一个我一直在思考的问题，就是 Muse 本身能不能成为一个足够大的平台。Greg 在视频里说这是他最大的不确定性，Muse 到底会有多少用户，这直接决定了这个 Connector 生态的天花板。Muse 现在在美国 App Store 排名第一，这个数字很亮眼，但排名第一不等于长期留存，更不等于用户会真的用它来完成这些复杂的跨服务任务。这需要时间来验证。

但有一件事我觉得是确定的，不管 Muse 最终的体量如何，这次的开放是一个信号，证明 AI agent 的入口之争已经进入了一个新阶段，不再只是比谁的大模型更聪明，而是比谁能把生态建起来，让外部服务愿意接进来、用户愿意留下来。这场仗才刚开始打，但 Greg 说的那句话我觉得说得最准：现在最值得做的事，是找到一个你真正了解的用户群体，去聊清楚他们每天在哪里卡住，然后用 Connector 的逻辑去解决那一个卡点。不是发明一个宏大的 AI 产品，就是把一件小事在正确的时刻做得足够好，这就够了。

Greg 这期内容里我印象最深的，不是那四个创业点子，而是他说的那句：那个球场有一个明天晚上空出来的档期，那个球队想找一块场地打球，帮他们完成这个预订，本身就是一门生意。这种把机会具体化、接地气化的思维方式，我觉得是 AI 时代创业者最需要的一种直觉，不是追着概念跑，而是去找那个真实发生的卡点，然后让 AI 把它解决掉。