A2A 网络的"Stripe 机会"——这个类比撑得住吗？
两篇文章的位置
上一篇拆了一个流行叙事：A2A 网络要吃掉美团。结论是——UI 层会被 agent 吃掉，但吃它的是通用 agent 入口（ChatGPT、千问、豆包），不是独立的 A2A 网络。信任、支付、合规、监管依然厚，美团不死，会变成被调用的后端。
这个结论留下一个空白：那机会在哪？
过去半年，在 VC 圈、创业圈、AI 从业者圈——包括我自己上一篇结尾——逐渐形成了一个共识答案：做服务业的 Stripe。不抢 C 端入口，不和 ChatGPT 硬碰，只做"让 agent 能调用本地服务"的后端 + MCP 层。50 到 100 人公司，抽 1 到 2%，跨品类横向扩张。
上一篇结尾我把"服务业的 Stripe"说成是机会，给了 12 到 18 个月的窗口。当我又走了一遍这个叙事的前提，发现它比第一篇的"吃掉美团"还脆。这篇是我对自己上一个结论的重新审视。
这个答案听起来够好。它绕开了第一篇指出的所有坑（不做新平台、不做 UI、不复现冷启动补贴），又给 A2A 创业者一个能投入的方向。
但这篇文章要说的是——这个答案可能比第一轮"A2A 吃掉美团"的叙事还弱。
弱在什么地方？弱在"Stripe 类比"被当成了不证自明的起点。一旦拷打它，类比的三个前提在服务业全部塌掉，整套方案就失去了锚。
下面按顺序拆：先把"服务业的 Stripe"最强版本写清楚（不绑稻草人），再看 Stripe 真正做对了什么，再一个一个检查那些前提条件在服务业里成不成立，最后给出在这个叙事塌掉之后，真正可能跑通的路径是什么。
"服务业的 Stripe"具体说什么
这个叙事的 steel-man 版本大致是这样：
产品形态是一组面向 agent 的 MCP server 集群。按服务类别切分——餐饮一组、酒店一组、本地生活（家政、装修、婚庆）一组、出行一组、医美一组。每组 MCP server 暴露一套标准工具：search、filter、check_availability、book、pay、cancel、follow_up。通用 agent 厂商（ChatGPT、千问、豆包、Kimi 这类面向 C 端的 AI 助手厂商）接入整套协议，就获得"调用中国本地服务全部类目"的能力。
商家端是一个接入 SDK。商家不需要懂 MCP，装一个微信生态或者 POS 厂商合作的 SDK，菜单、库存、排期、价格自动同步成标准 MCP 协议。
结算和合规层端到端包办。用户 agent 发起订单，MCP server 处理和商家对接、支付通道对接支付宝 / 微信 / Visa、履约、仲裁——整个过程通用 agent 不需要关心"钱怎么收""有问题找谁"。
分发上和通用 agent 做分成。不做 C 端 App，不争入口。通用 agent 把这个后端作为"本地服务供给源"，每笔交易分 20 到 30% 给 agent 厂商，换取流量。
商业模式是对商家抽 1 到 2%（远低于美团的 18 到 22%），对通用 agent 分 20 到 30% 的抽成，自己留 0.7 到 1.4%。听起来薄但规模大——跨 20 个品类、20 个城市，流水足以养 50 到 100 人的团队。
这个叙事的魅力在哪？
在于它把 A2A 网络创业者从"做新平台"的死局里拽出来，放进了"做基础设施"的新位置。Stripe 的成功证明了这条路走得通——做发卡行和开发者之间的一层，既不争 C 端，也不做监管，照样能做到 650 亿美元估值。
然后大家顺手把 Stripe 的剧本套到了服务业上。
问题就在这里。
Stripe 真正做对了什么——三个前提
Stripe 的商业成就当然巨大。但要学它，得先看清它能跑通的前提是什么——不是 Stripe 本身多聪明，是 Stripe 踩在什么样的基础设施上。
Stripe 2010 年启动的时候，世界长什么样？
前提一：底层协议早已被统一。
1973 年 ISO 发布了 ISO 8583 标准，规定了信用卡授权、捕获、冲正、退款、结算的所有字段定义。1990 年代 EMV 再加了一层——芯片卡的认证协议全球统一。到 2010 年，世界上任何一家银行、任何一台 POS、任何一张卡，对"授权"的数据包长什么样、对"退款"的请求该怎么发——字段定义完全一致。
Stripe 做的是什么？它做的是协议翻译器——把开发者能看懂的简单 API（stripe.charges.create）翻译成 ISO 8583 的电文发给银行。
注意：Stripe 没有制定协议，Stripe 是在一个已经被统一 40 年的协议上做了一层抽象。协议的统一是 Visa、Mastercard、ISO 花了三十年做的事情，不是 Stripe。
前提二：底层数字化程度已经极高。
Stripe 的客户是什么？是电商网站的开发者。电商网站从定义上就是数字化的——它有数据库、有订单系统、有库存状态、有 HTTPS 接口。Stripe 接入的是一个已经在互联网上原生运行的实体，不是一个还需要先被数字化的线下商家。
前提三：需求侧已经有集中的、强动机的调用方。
谁是 Stripe 最早期的客户？YC 那一批里的电商创业者。他们有什么共同点？必须接支付——不接支付就没收入。这是刚需中的刚需。
而且他们已经在苦苦挣扎。2010 年之前他们花 3 到 6 个月申请商户号、读 400 页 PCI-DSS 合规文档、写上千行 PHP 代码对接银行。Stripe 出来，他们 7 行代码解决——每一个电商开发者都有强烈动机切换到 Stripe。
服务业里，这三个前提全部有问题
现在把"服务业的 Stripe"对照这三个前提看一遍。
问题一：协议同构——不存在
餐饮的"预订"是什么？
在海底捞，它是一条 reservation 记录，带桌型、人数、时段、特殊备注，通过海底捞自己的 CRM 系统。
在外婆家，它是另一套格式，通过哗啦啦或奥琦玮的 SaaS。
在杭州某条小街上的夫妻店，它是老板娘脑子里那张 A4 纸，上面写着"8 号桌，张先生 4 位，7 点半"——没有数字记录，没有接口。
酒店的"预订"更乱。七天连锁有自己的 PMS，华住有华住的，丽思卡尔顿和万豪有万豪的，单体民宿可能直接通过微信确认。
医美的"预约"、家政的"派单"、装修的"开工"——每一个都没有统一的协议定义。
"服务业的 Stripe"想做的事情是什么？既要做协议制定者，又要做协议翻译器。
这两件事 Visa 和 Mastercard 做了 30 年。你想 12 个月内干完。
问题二：底层数字化——只有头部成立
上一篇讲过：中国餐饮 800 万家门店里，连锁占 18%（约 150 万家），夫妻店占 82%（约 650 万家）。小餐厅里约 70% 没有真正的 POS 系统——不是能联网能导数据的那种 POS，是纸账本 + 微信收款码。
这个数字决定了"服务业的 Stripe"只能在头部玩。连锁餐饮、连锁酒店、连锁医美、头部家政公司——这些有 ERP / PMS / CRM 的地方，SDK 同步得起来。
问题是——这部分市场有多大？
连锁餐饮 2024 年市场规模约 1.2 万亿人民币，占餐饮总盘的 23%（上一篇讲连锁门店数占 18%，这里流水占 23% 更高——因为连锁单店流水远高于夫妻店）。取 5% 穿透（乐观），take rate 1%，净留 0.5%——可能一年 30 亿人民币。这养得活公司，但和"20 个品类 × 20 个城市 × 180 亿"的叙事差了一个数量级。
"服务业的 Stripe"从一开始就只在高数字化的那 20% 里成立，另外 80% 的市场进不去。这和 Stripe 当年的处境不一样——Stripe 是面向一个 100% 数字化的客户群（电商开发者）。
问题三：需求侧动机——根本不存在
Stripe 的客户是谁？电商开发者。他们需要 Stripe 吗？必须需要。不接支付就没收入。
"服务业的 Stripe"的客户是谁？通用 agent 厂商（ChatGPT、千问、豆包、Kimi）。他们需要你吗？
此刻，不需要。
千问现在没接入任何第三方本地服务 MCP，它的模型照样在卖，它的用户照样在用，它的融资照样在进行。豆包也一样。ChatGPT 甚至连中国本地服务市场都没进。
没有接第三方本地服务 MCP，通用 agent 厂商的业务不会死。这和 Stripe 当年电商开发者"没 Stripe 就没法收钱"的处境完全相反。
这是最致命的一条：Stripe 是"你必须用我否则你的业务不能跑"；"服务业的 Stripe"是"你可以用我但不用也没事"。
更准确的类比：不是 Stripe，是 Plaid 或 Twilio
当客户没有"必须使用"的强动机时，你不是 Stripe，得是 Plaid 或 Twilio。
Plaid 的故事
Plaid 做什么？银行 + 开发者之间的翻译层。用户授权后，Plaid 从银行拉账户数据给应用用。PayPal、Chase、Square、Venmo 都用过 Plaid。
2020 年 Visa 要以 53 亿美元收购 Plaid——当时看起来是 Stripe 式的成功。
结果监管否决了。否决之后发生了什么？
银行开始自建 Plaid 的替代品。Chase 推了自己的 API，Bank of America 推了自己的，富国银行推了自己的。PayPal 也不再主要依赖 Plaid。
Plaid 的估值从 2021 年的 135 亿美元跌到 2024 年 60 多亿。它还活着，但"基础设施收租"的故事没跑通——因为客户有能力自建。
Twilio 的故事
Twilio 做什么？短信 / 语音 / WhatsApp API 层。应用要给用户发验证码、发营销短信、发 WhatsApp 通知，都走 Twilio。曾经是短信 API 界的 Stripe。
2020 年发生了什么？Meta 把 WhatsApp Business API 自己接管。原先 Twilio 代客户发 WhatsApp 消息是一条高毛利业务，一夜蒸发。
2021 到 2024 年，Twilio 股价跌了 80%。它还是成功公司，但"纯 API 中间商"的叙事在被 Meta 这种平台方持续挤压。
规律
纯后端公司成功的前提是：客户没能力自建你。
Stripe 的客户（Shopify、Lyft、DoorDash）没能力自建支付——他们不会为了省 2.9% 自己去拿发卡行牌照。所以 Stripe 的定价权稳。
"服务业的 Stripe"的客户（通用 agent 厂商）完全有能力自建。他们的自建成本是什么？一个 BD 团队（50 到 100 人）+ 几千万预算 + 半年时间，直接去和美团、携程、连锁餐饮总部签战略合作。
当最大客户同时是你最大的潜在竞争对手，你就不是 Stripe，你是被收购前的 Plaid。
最致命的那个前提（基本没人问过）
上面讲了 Stripe 类比的三个前提都有问题。但还有一个更底层的前提，一旦戳穿，整个"服务业的 Stripe"叙事瞬间塌。
这个前提是：
通用 agent 厂商愿意把 C 端流量导向一个独立的第三方 MCP 后端，并且长期按 20 到 30% take rate 分成给它。
这个前提现在没有任何证据支持。相反，所有证据指向它不成立。
证据一、二：阿里百炼和字节 Volcano Ark 的态度。上一篇坑 3 已经拆过——阿里百炼 MCP 是审核制（第三方 server 必须通过智能体应用层接入，不能直接被 Qwen API 调用），字节 Volcano Ark 对高频应用"仍持谨慎态度"。这两件事合起来翻译成一句话：两家头部中国通用 agent 厂商，都不愿意让第三方 MCP 直接接触自己的用户核心流量。
证据三：OpenAI Plugin 生态 2023 年做过一轮。 2023 年 3 月 OpenAI 发布 ChatGPT Plugins，第三方可以做 plugin 接入 ChatGPT。一年后基本废掉——Plugins 功能 2024 年被 GPTs 替代，2025 年 GPTs 热度也消退。为什么？模型厂商发现开放第三方生态反而削弱了自己的产品边界。
证据四：通用 agent 厂商的估值逻辑。 为什么千问、豆包、ChatGPT 能撑起几百亿美元估值？VC 给它们的估值逻辑是"我是用户的唯一入口，未来会 monetize 全部用户行为"——这个估值逻辑和"把流量分给独立第三方"天然冲突。每一分分给第三方的流量，都是在削弱"我是唯一入口"的叙事。
把这四条合起来：通用 agent 厂商既没有动机接入独立第三方 MCP（业务不依赖你），又有强动机不接入（防止削弱自己的入口叙事）。
"服务业的 Stripe"这个叙事的全部前提，是通用 agent 扮演 Stripe 故事里"Shopify 开发者"的角色——愿意调用第三方、没动机自建。这个前提没证据。如果这个前提不成立，整个方案就塌了。
那真正的机会可能在哪？
如果"服务业的 Stripe"不成立，A2A 方向的玩家还能做什么？
下面列三个更真实、也更不性感的路径。没有一个能撑起"服务业 Stripe"那种愿景，但每一个都更接近市场的实际形状。
路径 A：agent 厂商的 BD 公司（收购退出）
不要想"独立平台"。一开始就定位成"帮通用 agent 厂商做本地服务 BD"的服务公司。
做连锁餐饮、连锁酒店的商务对接，把 API 接入通用 agent，签 3 到 5 年独家或优先权协议。团队规模 20 到 50 人，大部分是销售和合规，不是工程师。
终局是被通用 agent 厂商收购——因为他们确实需要本地服务能力，但不想自建 BD 团队。参考 Google 2022 年收购 Zync、Meta 2024 年收购 Kustomer 这类小规模 BD / 数据收购。
估值不高（5 到 20 亿人民币级别），但路径清晰。
路径 B：美团 / 携程的技术服务商
不争"替代美团"，而是做"加速美团变成 agent-first 后端"的技术供应商。
卖给美团一套 MCP server 框架、一套 agent 调用协议、一套风控系统。帮美团把自己的 2000 万商家数据包装成 agent 能用的形态，收 SaaS 费。
这条路需要深厚的平台合作关系（不是一般创业公司能进）。但如果能进，收入稳定、抗周期。估值对标 SaaS 公司——50 到 100 亿人民币级。
路径 C：窄垂直 + 独家合作
不做"跨 20 品类"的大愿景，只做一个品类 + 一个 agent 厂商 的 3 到 5 年独家。
比如：连锁医美行业 + 和某一家通用 agent 签独家 3 年。只做医美的预约、变价、营销、复购。
估值小（一个垂直 + 一个客户的 TAM 有限），但可以成为一门好生意。相当于某一个行业的 Shopify，而不是全服务业的 Stripe。
这三条路径的共同点
都不是"颠覆美团"。都是"给大玩家供货"——给美团供货、给通用 agent 厂商供货、给连锁集团供货。
这不浪漫。但它比"服务业的 Stripe"更有可能成。
浪漫的叙事在 2026 年 4 月的 A2A 讨论里已经过剩了。少一些浪漫，多一些计算——这是第二篇文章的用意。
12 到 18 个月，赛道上要看的几件事
最后给几个赛道级别的可观察信号。注意：这些是观察型的，不是某一个团队做不做就能决定的。它们是整个市场给 A2A 方向玩家的环境信号。
信号 1：通用 agent 是否公开接入第三方垂直 MCP 并给流量。不是"允许接入"（那是技术能力），是"主动分流 + 付费分成"。如果 12 个月后这个状态没变，"服务业的 Stripe"路径基本不通。
信号 2：是否出现一家 agent-native 公司月交易额过百万。主要流量来自通用 agent 调用，不自己做 C 端入口。现在没有这样的公司。如果 18 个月后还没有，行业共识没形成，先发优势不存在。
信号 3：美团 / 携程 / 滴滴是否启动 agent-first 后端战略。如果美团先做，"替代美团"和"服务业的 Stripe"两条路同时关闭——独立玩家要么被收购，要么转型给美团做供应商（路径 B）。
信号 4：美元 VC 是否投资过"服务业 MCP 后端"方向。如果 Sequoia、a16z、Bond 领投一家 A 轮（1000 到 3000 万美元级别），说明行业开始相信这个叙事。如果 12 个月一家都没有，说明顶级资金还在观望。
判断规则
- 12 个月内 0 个信号出现 → "服务业的 Stripe" 基本死；A2A 方向的玩家应该转向路径 A、B 或 C
- 1 到 2 个信号 → 叙事还活着但窗口没打开
- 3 到 4 个信号 → 窗口打开，land grab 阶段
3 个能把整条路搞死的风险
风险一：美团先做。最大的风险。上一篇反驳 3 已经讲过美团的技术投入（研发 200 亿/年 + 公开招 agent 方向岗位）——这里补一个时间优势角度：美团看到这个趋势后，先建 agent-first 后端 + 第三方 MCP 接入的速度，会比新创业团队从零搭建所有东西快得多。一旦它决定做，独立玩家的窗口直接关闭。
风险二：通用 agent 厂商自建。他们缺的不是技术，是线下 BD。可以收购一家 BD 公司解决，比独立玩家成长快 5 倍。
风险三：监管介入。agent 代理下单的法律责任归谁？欧盟 AI Act 2024 年已经出台，中国对应立法 2025 到 2026 年会清晰。如果监管判定"agent 代理交易 = 连带责任"，中小创业公司承担不起合规成本。
回到开头
两篇文章的主题，现在可以合起来讲：
第一篇拆穿了叙事 1——"A2A 网络会吃掉美团"。结论：UI 层会被吃，但吃它的是通用 agent 入口，不是独立 A2A 网络。平台不死，换衣服。
第二篇拆穿了叙事 2——"做服务业的 Stripe"。结论：Stripe 类比的三个前提在服务业全部有问题，更贴近的类比是 Plaid 或 Twilio。而且最致命的前提（通用 agent 厂商愿意给你分流）没证据。
两篇的共同模式是一样的：每一个流行叙事的诞生，都是大家相信了上一个叙事被拆穿之后的替代品。A2A 吃掉美团的第一轮叙事塌了之后，大家拿"Stripe 类比"做第二轮包装。但第二轮往往比第一轮更弱——因为防御姿态降低，华丽类比更容易掩盖根本矛盾。
真正的机会可能更窄、更不性感、更像是给美团或者给通用 agent 厂商供货。而不是浪漫的"基础设施玩家"。
一句话
每一个流行叙事的第二轮，都是用新类比包装旧悖论。
Stripe 做的是协议翻译器，不是协议制定者。想做服务业的 Stripe——你得先是 Visa。
当你的客户同时是你的最大潜在竞争对手，你就不是 Stripe，你是被收购前的 Plaid。
后记
这两篇文章起点是一次 2小时 的对抗式讨论（辩论/争吵）。没有那场讨论，就只会有第一篇的第一部分（甜蜜的商业想象），不会有第一篇的后续部分，和第二篇——第二篇的全部价值，在于指出"替代叙事"本身也需要被同样严格地拷打，而不是因为它听起来更温和就接受它。
2026 年 4 月，A2A 讨论已经火过两轮。接下来的 12 到 18 个月里，会用真实的交易数据、真实的融资事件、真实的平台反制来告诉我们：哪一个叙事是对的、哪一个是错的、机会到底在哪。
在此之前，不要用类比代替思考。