Token 就是新美元：Stripe 的 Will Gaybrick 与 David Georgea16z

如果你想交付更多、构建得更快，就必须在公司内部创造一种“像创始人一样行动”的自主性。今天，一个工程师能完成两年前两个工程团队才能完成的工作。与此同时，软件能够覆盖的市场机会突然宽了很多。问题变成：你们为什么能发布这么多产品？有些公司把新的 agentic 效率主要用来优化成本结构；而我们的想法——我说得稍微俏皮一点——是：把一切都做出来。

我们还没有在 agentic commerce 里经历类似“Opus 4.5 之后寒武纪爆发”的时刻，其中一个原因是缺少基础原语。另一方面，我们现在合并的代码比去年多得多，所有系统都在承压，所以做了 Stripe Minions。它不是让你反复迭代、进入长时间 planning mode，而是你说“这就是我要的，去做”，然后它完成任务。另一个问题是：Stripe 现在处理的体量已经超过两万亿美元，那么未来我们会怎样访问模型与 token？我对此非常看好。

我想先从 Stripe 现在的状态谈起。我们最初投资时，它很容易被描述为一家支付处理公司；但现在，平均一家 AI 公司会用到 11 个不同的 Stripe 产品，而你们在 Sessions 上好像发布了 288 项不同的产品更新。我当然想谈速度，但先回答最基础的问题：Stripe 今天到底是什么？

我们内部的理解是，Stripe 的价值主张已经倒过来了。过去是“一家支付公司，再加一些附加产品”，现在则是一个多产品平台，核心都围绕金融基础设施：减少摩擦、增加用户的行动能力，让企业更灵活地改变商业模式、进入更多国家，并且让所有与收入和现金相关的事情都跑得更快。

从具体产品看，我们从 Payments 扩展到 Billing、订阅和发票；如果你是平台或 marketplace，有 Connect；Radar 最早做欺诈防护，现在做的事情也更多；还有 Tax。我们其实没有认真数过，可能有二十五到三十个比较显眼、拥有独立品牌的产品，下面还有成百上千个功能。但不管产品数多少，框架仍然是同一个：降低摩擦，提高 agency。

去年有一个很典型的新问题：很多用户第一次遇到免费试用滥用。AI 以前，这通常没那么严重，因为多数 Stripe 用户是软件公司，软件的边际成本很低；有人多用一点免费额度，也就是浪费一点算力，几乎可以忽略。但现在软件本身有了明显的推理和算力成本。Cursor 是我们最早一起处理这个问题的用户之一。

我正想说，我们的被投公司也遇到了。互联网用户当然很会钻空子。

对。我记得当时大约每六个免费试用用户里就有一个属于滥用。有人注册一个账号，再注册一个，再来一个，甚至可能用免费额度做模型蒸馏。这样你实际上是在不断往这些账号上烧钱。

我们就跟客户一起“进地堡”，一个周末搭起了一条识别管线：用基础模型看整个 Stripe 网络，使用我们的 embeddings，再叠一层 reasoning，让系统不仅说“我们认为这是免费试用滥用者”，还能够指出哪些信号支持这个结论。最近 11Labs 告诉我们，他们每天用 Stripe 的信号拦截大约 2,000 个免费试用滥用者。

这很夸张。

是。你要同时想两边：如果完全不拦，你会烧掉多少钱；但如果因为害怕滥用而不给免费试用，又会损失多少本来可以转化的收入。所以必须处理 false positive 和 false negative，而不能只粗暴地关掉试用。

另一个“增加 agency”的方向是全球化。今天要在很多国家注册、计算和代缴税，依然非常困难。新一代 AI 公司卖的是数字商品，它们往往想非常快地进入全球市场。比如有一家公司使用 Stripe Managed Payments：在美国等有自己实体的核心市场，它自己作为 seller of record；但在哈萨克斯坦或 APAC 的长尾市场，没有当地实体时，Stripe 可以作为 merchant of record，承担税额计算、申报和代缴等工作，让它能合规覆盖一百多个地区。

所以它能合规进入一百多个地区，这就是把原本需要企业自己处理的复杂度抽走。

这也说明了网络效应。拿刚才的欺诈例子说，一旦你识别出某类滥用者，这个信号就能在整个网络里帮助更多客户。作为投资人，我们很多被投公司都受益于这一点。

再看产品策略：Stripe 的起点是创业公司，你可以非常快地接入支付、开始在网上卖东西。Stripe 商业模式很漂亮的一点，是你们在 DoorDash、Instacart 还在 YC 的时候就获得了它们，然后一路跟着它们长大。现在你们怎么权衡“服务创业公司”和“服务大型企业”？

Clerk 的 Colin 最近在 X 上有个很好的概括。我转述一下：Stripe 的战略毫不掩饰，就是 “赢下所有创业公司，然后再赢它们一次。”

这首先是很好的商业模式。创业公司有野心，最有机会长成明天的大公司，而且往往像矿井里的金丝雀，最早暴露下一波机会。还有一个更微妙的原因：创业公司其实是我们所有客户里标准最高的一群。

我最近看过 Stripe Reporting 的客户反馈。非常大的企业客户会说：“你们的 reporting 太好了，数据比我们从其他供应商那里拿到的都强。”

因为他们已经习惯传统 incumbent 的水平了。

对。可创业公司会直接说：“你们的 reporting 烂透了，赶紧修，这把我逼疯了。”这种持续的、不留情面的要求让我们变得更好：它们跑得最快、最挑剔，也最愿意指出问题。

但一旦我们开始服务一家创业公司，我们当然希望永远服务它，所以客户自然会把我们往上游拉。我们的标准是，无论 startup 还是 enterprise，都要做到“surprisingly great”。现在我们服务的 Fortune 500 比例我记不清精确数字，还不到一半，但正在接近；Amazon、Microsoft 这类公司都在里面。

企业客户的销售周期、售后激活方式当然不同。签完合同以后，还会有很多上线工作；创业公司往往接好 API 就直接跑了。但底层方法没有变：离用户足够近，听他们真正需要什么，然后在他们在意的指标上证明你明显更好。所以今天我们不是在 startup 和 enterprise 之间二选一，而是两边都做。

“先赢下它，再赢一次。”我很喜欢这个动态。接下来我想换到 AI 新公司这一代的增长速度。

你们公开说过，今年上半年新注册用户同比增长 50%；2026 cohort 的中位公司，收入比可比的 2025 cohort 高 50%。而 2025 cohort 又比可比的 2024 cohort 高大约 70%。到底发生了什么？

我觉得有两件事。第一，AI 创造了大量过去不存在的新创业机会。四年前你根本做不出今天的 Suno——或者最多做出一个差得多的版本；Higgsfield 这样的产品也一样。突然之间，可以用软件解决的问题更多了，整个机会空间变宽了。

第二，做更多软件的成本显著下降。因为 agentic coding，同样一个产品需要的工程师少得多。于是我们看见新软件创建量在爆炸式增长。一个很直接的数据是：Stripe Billing 的同比使用增速明显高于 Stripe 整体，因为 Billing 特别偏向那些正在创建软件公司的用户。

这太好了。那我正好转到你们如何生产这些产品。你们的产品线越来越多，去覆盖线上公司越来越多的需求。最上层的问题其实非常简单：你们到底是怎么做到的？为什么能发这么多产品？

速度一直是 Stripe 最重要的事情之一。可能“对用户保持近乎偏执的关注”排第一，速度紧随其后。

我经常想“制度如何进步”。我们会研究前面那些伟大的公司，也研究今天和我们同时存在的伟大公司。Stripe 的目标设定方式，有一些经过改造的 Google OKR 影子；销售组织和 Microsoft 有相似之处；我们有类似 Apple 的 DRI 责任文化；产品质量标准和产品 review 也会借鉴 Apple。

我日常用来经营公司的很多机制，基本是从 Alan Mulally——前 Ford CEO、也有 Boeing 航空背景——那里“偷”来的。我们不断研究这些公司，把有效机制带进 Stripe，想建立一个能比任何一个具体的人活得更久的机构，因为这样的机构可以成为创业活动很好的容器。

但到了今天，突然没有谁可以直接抄了。两年前两个工程团队做的事，现在一个工程师可能就能完成。面对这种变化，我们当前的判断是：Stripe 过去一直是“外部创始人的平台”，现在还必须比过去任何时候都更像一个“内部创始人的平台”。

外部创始人，也就是你们的客户。

对。而且创始人在 Stripe 内部一直表现得很好。比如我们收购 Metronome 后，CEO Scott Woody 在 Stripe 发展得很好，现在负责 Metronome 和 Billing 的很大一部分。我们这几年还收购了钱包基础设施公司 Privy 和 Bridge，原公司的创始人、负责人后来也在 Stripe 承担了大量 crypto、OpenUSD、Bridge 等业务；Lemon Squeezy 的创始人之一也在参与 Stripe Treasury。这里最重要的观察不是某个具体人，而是：创始人型的人进入 Stripe 后往往仍然能获得足够大的问题空间。

这就来到一个很有意思的时刻：高级工程师现在非常强。你可以想象组织往几个完全不同的方向演化。一个方向是：既然每个人更高效，那以后就只需要少得多的工程师。很多公司确实把 agentic efficiency 当成优化成本结构的方式，于是裁员、缩减 Opex。

我们的看法不同。我说得稍微夸张一点：机会是把一切都做出来。

对。

最好的“优化成本结构”方式，往往是增长得更多。我们有成堆积压了很多年的用户需求没有满足，现在只是想更快把它们一件件做掉。

所以，高级工程师生产力越来越高之后，如果你真的想交付更多、构建更快，就要在公司内部创造 founder-like agency。让每个人更像一个能够直接发现问题、拥有问题并推动结果的创始人。

今天真正拖慢我们的，反而很多是“后台”环节。我们合并的代码比去年多得多，结果每套系统都在受压：新东西怎么进入销售系统？怎么放到 pricing page？产品变化这么快，销售人员来不及培训时，怎么把它带到市场？

我们现在在优化 Stripe 的整条 critical path：从用户需求、产品想法，一直到产品真的进入用户手里。要更快，第一件事就是给 Stripe 里每个人足够的 agency，让工程师能像 founder、像 creator，而不是被一层层中心化流程和组织开销困住。

另一边则是开发者生产力团队不断把工具做得更好。我们做了一个叫 Stripe Minions 的东西，也公开写过一些。Stripe 当然有很多帮助工程师和 agent 交互、迭代的开发工具，但 Minions 有意追求的是 one-shot。

你给它一个 prompt，它就去构建，走 CI/CD，跑完整测试，最后把结果交给你 review。你不是跟它来回迭代，也不是先进入 planning mode。你说：“这就是我要的，去做。”然后它去完成。

我们认为世界正在往这个方向走：更接近 one-shot，或者说一个极度强化的执行 loop，让 agent 变得非常强。我们大概一二月公开 Minions 时，它们每周生成约 1,200 个 PR；而上周，我记得大约有 7,000 个 PR 来自 Minions。

哇。

那周大约 30% 的 PR 是 Minions 生成的。所以一方面把 developer tooling 做得极好，另一方面让内部流程让路——这是我们加速的方式。

高级工程师现在比以往任何时候都强，你们在组织结构上做了什么明显变化吗？Minions 的 30% 我猜一年内还会继续上升。我们听其他公司谈过把最强工程师放进业务单元、让他们更靠近客户，但这样又会出现协调成本。你们怎么做这种“赋权”？

工程师一直都是 Stripe 最重要的产品领导者之一。我们最初就是为工程师、技术用户做产品；今天 persona 已经很多，但工程师长期是 Stripe 的核心 ICP。所以 Stripe 的工程师本来就经常同时扮演 engineer、PM、designer 的角色。

我们现在只是把这个倾向推得更远。我们做工具和平台，让工程师自己完成更多前端开发，甚至更多前端设计。如果一定要用最短的词回答组织变化，就是：更扁平。

更扁平，也就是团队更小？

团队更小，也更扁平。过去很多层级负责组织和协调工作——多数时候那是有价值的——但现在有些层级不再那么必要。最近我跟一位非常资深的工程师聊，他参与做 Stripe Projects。那个项目在几周内主要靠一个 PM、一位很资深的工程师和少数后来加入帮忙的人完成；我得给其他人应有的 credit，但大多数 PR 的确来自一个人。现在他面对一个屏幕，同时编排 16 个 agents，速度快了非常多。

你们有没有一个标准项目团队大小？我们听到的说法从“一人太少、没有社交动态”，到“四人可能已经是上限”，各种都有。

没有一个固定答案。更扁平意味着你会想要更宽的团队，因为那样管理层级更少；但同时，每个人的能力又因为 AI 放大，所以完成同样范围的任务可能确实需要更少的人。这两股力量现在会互相抵消一部分。

所以，这两股力量今天会互相抵消。举个很粗的例子：如果你有一个由经理直接管理、下面有八个人的团队，组织结构可能还跟以前差不多，但这个团队现在能做的事情大约是过去的 3 倍。

对。也就是说，manager 和 IC 的比例未必一定剧烈变化，但同一个团队不再只做一件事，而是同时做三件事。

对，正是这样。

这就引到我们之前聊过的另一个问题。AI 让你突然能做很多过去做不了的事，那你应该把新增能力投到哪里？你们显然很偏向面向用户的一侧：做新产品、扩产品线。可市场上很多讨论是面向后台的：把成本结构优化掉，把公司里每个人做什么都画成流程，把一切写成 Markdown，然后把流程“优化到死”。为什么 Stripe 更愿意做前者，而不是后者？

早期确实有一个很强的叙事：现在有 agents 了，所以公司应该更高效，应该能用更少的资源做更多事。这个叙事今天还在，而且其中当然有一部分是真的。只是我在这个问题上首先想到的，是怎么让现有的人变得更有生产力。

我们内部有个知识 AI 工具叫 Kai。大概六个月前开始做，最初就是两个人做出来的。现在——我先说错了——大概 83% 的日活，不，抱歉，是 83% 的周活；日活大约 60%。在 Stripe 内部，它已经非常普及。销售人员的生产率提高了大约 20%。

但我们的反应不是：“太好了，那我们需要更少的销售了。”而是：“那我们应该要更多销售。”因为每个销售人员的回本效率变好了，就更值得继续投入。

对。

运营团队也是一样。他们每天感觉自己更有生产力，工具更好用，需要做的手工工作更少，日常体验也更好。在科技圈里这几乎已经变成一句陈词滥调，但它就是 Jevons paradox：某种资产一旦生产率更高，你未必想要更少，反而会想要更多。

完全同意。

工程师更是如此。我们的工程师现在生产力高得惊人。你当然可以推论说，既然每个工程师都更强，那全世界未来只需要更少的软件工程师；但我真的不相信这个结论，而且我们看到的事实也不是这样。我们看到的是软件创建量越来越大。

大约九个月前还有一个叙事，说垂直 SaaS 平台会受到很大冲击。可 Stripe 今年看到的 2026 年新 SaaS 平台 cohort，比 2025 年大约大 103%。原因很简单：越来越多人会说，“这个领域其实也需要一个 SaaS 平台，而我现在能比过去更快把它做出来。”

所以我反而觉得，全世界会有更多软件工程师。只是对于我们已经在做的事情，可能需要更少的人；释放出来的能力会去做过去根本做不到、或者以前没有资源排进 roadmap 的事情。

对 Stripe 来说，这意味着它也可以更像年轻工程师和应届生的“孵化器”：你进来，找到一个 high-agency、真正能帮助用户的问题，我们把障碍拿走，把 paved paths 做好，让你更容易往前冲。然后我们就能不断做更多，而且不是随机扩张，而是去做那些会和现有业务彼此复利的邻接领域。

比如 spend management 和 Treasury 就非常相邻。以前这可能是两年以后才会进 roadmap 的东西；现在，一位工程师直接把它捡起来自己做。我其实写了它的第一个 commit，但现在已经是那位工程师在一路推进。

现在等于是多了一双更有能力的手。

对，更有能力的手。所以我们的核心机会，是先 用现在拥有的资源做更多，最终再用更多资源做更多。

我非常同意。我最近写过一篇文章，说“创始人本身正在成为一种资产类别”。在我们做 late-stage venture 的市场里，我越来越觉得，真正能让公司不断找到下一块产品空间的，就是那些创始人型的人。

所以今天公司经常被迫问：到底是把 AI 新增的生产率用来做新产品、找新收入，还是去削减成本？像 Stripe 这种由你们这样的人经营的公司，我觉得“下一块可构建的机会”永远不会消失。总还会有新的用户需求、新的收入机会、新的产品可以做。

是，我完全赞同。不过我也觉得，现在确实是领导者给资源施加一点 back pressure 的好时刻。适度的资源压力会逼着团队更认真、更高效地使用这些新工具，而不是一看到生产率提高就立刻把所有约束全部松开。

再往后看，我可以想象几年后的预算过程跟以前并没有完全不同：我们会说，“看，我们用现在这些人已经做了这么多；如果继续扩大资源，就能做更多。”但在这个阶段，先让现有团队真正把 AI 带来的生产率吃透，是合理的。

另一方面，如果从 users-first 的角度看，用户想从我们这里得到的东西实在太多了。比如 Stripe Tax。很多用户一直希望我们提供全球报税。仅仅把美国报税做通就花了很久，因为美国每个州接受申报的方式都不同，背后是大量不同的 jurisdiction，问题非常难。

美国 filing 做出来以后，下一个任务就是 global filing。用户希望自己在任何市场都不用再思考这件事。我们最后把全球 filing 做出来，所花时间大约只有当初做美国 filing 的 三分之一。

而且复杂度还高得多。

对，复杂度高得多。所以你会发现，用户需求和可做机会几乎是无限的。只要你始终盯着用户，就会自然把新增的生产力投向这里。

我们最近还推出了 Stripe Treasury。现在 fintech 很有意思，因为“银行到底是什么”正在被拆开。Stripe 不是银行，也不想成为银行；但我们希望成为你使用银行服务的 portal，并且帮助你完成全球资金移动。这个需求我们已经被用户问了很多年。

Treasury 让用户可以在很多国家持有几十种货币的资金。换句话说，我们想把今天一个好的 banking portal 理应能做的事情直接做出来。过去我们认为某些产品“最快也得两年”的时间线，现在不断被压缩。

我最近常用一个类比：agent engineering 有点像 注塑成型（injection molding）。这个类比当然有点 reductionist，但二战以后消费品、玩具等产品之所以爆发，很大程度上是因为四十年代人类把“稳定、高效地熔化塑料并把它注入模具”这件事做得非常好了。

软件现在也越来越像这样。你建立模具、模板和固定模式。你刚才提到 Markdown 文件——那些东西其实极其重要。每个 repo 都要有 agent 能理解的规则文件；只要你把这些 pattern 做好，并理解怎样与金融机构之类的外部系统集成，就可以把大量工作交给 agents。它们把代码做出来，人类大量时间会转移到后面的 code review。

甚至 code review 本身，agents 现在也比过去人类单独做时更强。所以真正让我兴奋的，不只是省掉一点成本，而是开发周期一次又一次被压短。我觉得这比单纯优化成本结构大得多。

你可能是第一个把现代 AI 软件工程拿来和注塑成型比较的人，这很好。我还真的去过注塑工厂。

很神奇，对吧？尤其是想到这项工艺大概七十年前就成形了。发明现代往复式螺杆注塑机的人，我记得叫 James Watson Hendry，好像就在宾夕法尼亚。

对，这个类比很好。作为 Stripe 的投资人，而且是一个很大的投资人，我还会从另一个角度看你刚才说的事：成本优化的机会是有限的。你刚才用“做多 / 做空”这个说法，我很喜欢。

对。优化成本结构，就是在做空你自己的未来潜力；构建得更快、构建得更多，则是在做多你的未来潜力。

很像资本配置：一种做法是把现金还给股东，另一种是把现金继续再投资。

对。

明白了。那我们换一个话题。

我想聊一个你们处在最前沿、但市场讨论经常很朦胧的话题：agents 在互联网上做 commerce。今天到底走到哪一步了？最大的 bottleneck 是什么？如果给未来一个框架，它会怎样发生？

我们前面说到类似 “Opus 4.5 之后寒武纪爆发” 的时刻。今天的 agentic commerce 还没有经历这样的爆发。我们还没有看到很多 canonical use cases 一遍又一遍地出现。

原因有几个。第一个很直接：我们还缺 primitives。 这也是我们现在特别关注的。我们和 Tempo 一起做了 machine payments protocol，让一个服务能够告诉机器：这里需要付多少钱，以及应该怎样付款。

比如机器想购买一张图片或一段内容，可以先发起请求，然后收到一个 HTTP 402 响应。它相当于告诉你：“要买我，就按这个方式付。”这就是一种基础原语。我们认为机器会越来越需要从其他机器那里买东西。

另一个还没有答案的问题是：agent 的 checkout 到底应该长什么样？ 浏览器自动化越来越好，所以也许 agent 可以像人一样爬进 checkout form 把表单填完；但那只是一个 skeuomorphic 的版本，最终应该还会出现更原生的版本。

对，先模仿旧界面，最后一定会有 machine-native 的形式。

我同意。所以现在我们还处在“缺少基础原语、把原语补齐”的阶段。再之后还有一个社会学问题：agentic commerce 到底在哪些场景会明显优于 non-agentic commerce？

有些答案其实并不 speculative。比如，我觉得 checkout page 对人类本身都不应该长期存在。Stripe Link、Shop Pay 已经让 checkout 容易很多，但你为什么还一定要进入一个专门的 checkout page？看到商品时直接说“买这个”，不是更自然吗？我认为 checkout page 最终会逐渐消失。这算是比较不激进、但很具体的一种 agentic commerce。

这个点很有意思，因为它不只适用于 agent，也适用于人类。Stripe Link 现在大概已经有 4 亿用户，Shop Pay 应该也有非常大的用户规模。只要这些凭证体系存在，整个购买过程就可以越来越自动化。

对。我们最近推出了 Link Agent Wallet，现在也有 Link CLI。agent 可以在有人类约束、有人类明确授权的前提下拿到 Link credentials，然后直接去使用它们。

真正让我特别兴奋的，其实是 B2B 的 agentic commerce。我们推出了 Stripe Projects。狭义看，它是一个 scaffold app 的方式；但更有意思的是，它让 agent 可以自动 provision B2B services。

比如一个 agent 可以直接决定采用 Vercel 做 hosting，而你不需要亲自打开 vercel.com、注册账号、点击一堆东西。

这其实已经影响到我们最近一些 developer tools 投资的 thesis。我们会问：假设未来真正的“购物者”是 agents，那么这个工具会不会是 agents 自己愿意选的那个？

对，这个框架非常好。agent 也可以自己采用 Browserbase。我们之前在 Stripe 做过一个很有趣的 demo：现场让 agent 使用 Browserbase，去填一个 NCAA bracket。

很酷。

我也觉得很棒。我有三个兄弟，我们都很喜欢体育，但我总是忙得没空参加家里的竞猜池。看着 agent 自己启动一个 Browserbase session、打开 ESPN、做点研究，然后把 bracket 填完，那个感觉非常直观。

它最后填得怎么样？

我其实不知道。我不觉得我们后来真的对结果跑过 eval。

我猜至少跟普通人差不多。

可能还更好。

哈，可能更好。

所以我很相信，agents 会越来越多地自动采用那些偏 utilitarian 的 B2B，甚至一些 B2C 服务。现在我们最先做的，就是把“发现一个服务、采用一个服务”这件事变得更适合 agent。至于面向消费者的 long-running tasks，我们还没有完全找到正确范式。

前几天我自己也在试这种体验。我用 Claude Code 一类的工具，想给侄女生日做一首歌。过去如果没有 Suno 这种生成式音乐服务，我肯定不会做；现在有了这类服务，我可能会做，视频生成也可能用 Higgsfield 之类的产品。

但我未必愿意为了只用一次，就分别开一个每月 10.99 美元或者 9.99 美元的账户。我真正想要的是：这次任务需要多少，就消费多少。也就是说，除了 commerce primitives，还需要一种 micro-consumption API。

服务应该可以告诉 agent：“你可以临时地、一次性地用我，不需要把自己绑定成长期订阅用户。”一旦有这种 ephemeral、one-time consumption，agentic commerce 就会被解锁很多。你不必再想：“这里每月十美元，那里每月十美元，还要维护一堆账户。”你只需要调用服务，然后付钱。

就像对 agent 说：去发现完成这个任务需要的服务，你的预算是 15 美元，开始吧。

对。

我十岁的孩子最近一直在做 rap song，所以我非常熟悉这些服务。说实话，质量已经挺好了。他还会把歌发到 Spotify。AI 写的歌词不错，音乐本身也不错，所以我完全欢迎你说的这种模式。

但这里有一个关键点：micropayments / microtransactions。这个想法大概从互联网诞生起就一直有人提，为什么你觉得今天终于可能成了？

一个原因是 agent 真正放大了 human agency。听起来有点重复，因为 agent 和 agency 是同根词，但想想刚才这些事：给侄女写一首歌、填 NCAA bracket。没有 agent 时，它们都需要你自己花时间，建立很多账户，跨很多网站去做。

所以我非常看好服务主动支持一种更 ephemeral、更 lightweight 的使用方式。而要让这种方式成立，就必须支持 microtransactions。

过去反对微支付的经典理由是：假设你想卖一篇文章，商业模式往往会被夹在订阅和免费广告模式之间。订阅想尽量把消费者剩余锁在长期关系里；广告则干脆把内容免费给你。很多时候，这两个模式中的一个会比“每篇文章收几毛钱”更好。

可当 agent 开始承担更复杂的任务时，情况会变。你会希望它像一只很小的蜂鸟，在互联网上到处飞：这里吸一点数据，那里拿一点能力；这里临时存一点东西，那里跑一点 compute。你不希望背后的那个人，必须事先知道 agent 到底调用了哪些服务。

人类真正需要的是确定这些服务是安全、可信的，而不是在每一个地方都亲手建立账户。所以我认为，微支付会成为这种 agentic economy 能存在的必要条件。

另一边，现在微支付之所以变得真正可行，一个很重要的原因就是 stablecoins。

今天稳定币对人类来说还不算特别“有机”。你经常得跳过很多 hoops 才能开始用。但如果你只是给 agent 一个预算，它可以很自然地拿美元换成 stablecoins，或者直接使用某个 stored balance，然后去完成 checkout。机器并不介意底层在法币和 stablecoin rails 之间来回切换。

我完全同意。其实软件商业模式已经发生过类似变化。过去主流是 subscription 和按 seat 收费，现在越来越多转向 consumption。这样的变化一方面让消费者能接触到更多东西，另一方面也让企业接触到那些过去不会为完整订阅付费的人。

我希望这种逻辑也会在这里发挥作用。既然谈到 stablecoins，我们就顺着往下聊。

我们已经聊了你们如何用 AI 构建软件、如何把公司跑得更快，也聊了 agentic commerce。现在说说 stablecoins。你刚才提到，对今天的人类来说过程还有摩擦。你怎么看稳定币市场现在的状态，以及未来五年左右真正的机会？

我是个 infrastructure nerd，所以会先从基础设施说起。最简单的判断是：stablecoins 本身就是一个比很多现有体系更好的资金移动平台。

我们非常同意。

有几个原因。很多国家其实已经做出了很便宜、很快的支付系统，但它们大多是 national rails。比如印度的 UPI。一个很有意思的现象是——我记得、也只是大概数字——印度 UPI 上 5 美元以下支付占比可能在 86% 左右；而美国卡支付里，5 美元以下可能只有个位数百分比。巴西的 Pix 也是另一套增长极快的国家级系统。

但全球经济需要一个 Schelling point：一个“大家最终都能同意用什么”的共同轨道。Crypto rails 在某种程度上解决了这个政治和协调问题，因为同一个平台可以在不同国家工作。

如果全世界今晚睡觉，明早醒来时大家都已经持有稳定币，那么全球金融系统大概率会运行得更快、更便宜，摩擦更少，资金移动成本也更低。

当然，这也可能是那种“理论上应该如此，但现实永远未必完全这样运作”的问题。所以我们现在非常坚定地想推动它真的发生。

前面说过 Stripe Treasury。我们决定让 stablecoins 在 Treasury 里变成 native：你可以像持有 USD、EUR、GBP 一样持有 stablecoin balance。

我们看到的机会就是三件事：更快的资金移动、更便宜的资金移动、更全球化的资金移动。 今天用 fiat 成为 Stripe 用户，我记不清精确数字，大约覆盖 60 个国家；如果通过 stablecoins，则大约可以覆盖 150 个国家。这个差异意味着更多人能进入线上经济。

软件经济越来越全球化，这一点会越来越重要。今天在泰国用两个工程师做出一家很强的 AI 公司，并不天然比在美国或巴西更困难。所以 stablecoins 对我们来说，核心就是 higher-performance 和 more-global。

我也很喜欢 Stripe 所处的位置，因为这符合“meeting the market where it is”。企业不会一夜之间把所有 fiat 都扔掉，全量迁移到 stablecoins。你们已有的关系和完整产品体系，允许客户按照自己真正愿意接受的速度采用新 rails。

对，而且当公司真的拥抱它以后，效果已经能看到了。比如 Félix，它最初是一家做美国和墨西哥之间 remittance 的公司，现在也扩到了更多走廊。它从一开始就是基于 stablecoins 构建。几年之后，它现在已经占到那条美墨汇款走廊大约 5% 到 10% 的份额，而那是全球最大的 remittance corridor。

这很惊人。想想传统法币汇款体系扩张有多慢，Wise 这样的公司花了多久，更不用说更早的 Western Union。在这么短的几年里做到 5%–10%，非常夸张。

是，非常夸张。那我也想请你谈谈 Tempo。它显然是一个你们深度参与、而且非常重要的项目。现在做到哪一步？最终想成为什么？

我再打一次 infrastructure nerd 这张牌。世界上已经有很多很好的 blockchains，所以一般而言，并没有一个显而易见的理由说“我们还需要另一条链”。但如果把范围缩到 payments，我觉得就完全不同了：一条 payment-specific blockchain 有很多可以被专门优化的东西。

比如 privacy。很多 blockchain 天然是公开的，外部可以反向推断链上发生了什么。支付场景里，我们希望 privacy 是 first-class primitive。

还有 throughput。现在很多 blockchain 被大量用于 trading，一旦遇到巨大的交易事件，性能经常显著下降。对支付来说，你不希望正常结算突然因为别的市场事件就堵住。

再就是 transaction fees。很多链的 gas fee 会浮动，我们想要的是一种支付轨道：交易费不会因为别处的活动突然飙升，资金始终可以以尽可能高效、稳定、便宜的方式移动。

对，predictability 本身就是支付能力的一部分。

正是这样。Tempo 还处在比较早的阶段，但已经获得了不错的 traction，也在和 DoorDash 之类的公司合作。我们希望它成为 Stripe 内部一个默认、但不是唯一的 blockchain rail。我对它非常乐观。

很好。最后一个我想聊的主题是 token economy。这听起来有一点 buzzwordy，但 Stripe 现在处理的 volume，我记得已经超过 2 万亿美元。而我觉得你和我大概都同意，token economy 可能会成为我们见过最大的经济变化之一。

今天大多数人还是在第一方应用里购买、访问模型能力。你怎么看未来我们访问 models 和 tokens 的方式？

我一直很喜欢 token 这个词，因为它听起来本来就像一种对 money 的近似。

对。

而且它正在越来越像钱。前面我们谈过免费试用滥用、multi-accounting。今天像 Cursor、Replit 这种通用 token consumer 平台，遭遇的攻击已经非常 sophisticated。它们越来越像我们在 Stripe 用户身上看到的“有人试图偷钱”的攻击。

所以 tokens 和 dollars 之间的边界正在变模糊。Stripe 过去一直把自己的使命理解成：帮助用户安全、合规地移动钱、存钱、发送钱。现在我们越来越觉得，我们对 tokens 也有同样的 mandate：帮助用户安全使用它，并保护他们不被滥用和攻击。

以后这种模糊只会更明显。想想很多 long-running agentic task。过去你可能付美元给一个人或者很多人去“关账”；以后工作被 agents 大量增强后，你可能需要更少的人，而其中相当一部分经济资源会变成 tokens。刚才我口误说成“用 token 付人”，我的意思是：以前主要以 dollars 支付人力，现在 agents 消耗的 tokens 会成为完成同一个任务的另一种成本。

所以我们希望 tokens 和 dollars 之间的转换，最终像 dollars 和 euros 之间的转换一样无缝、一样安全。 我们现在才刚开始走这条路，但它会成为 Stripe 未来很大的一部分。

这非常令人兴奋。我个人也觉得 Stripe 在这里有很强的“right to play”，因为你们从公司成立一路陪它们长到 enterprise，手里已经有大量真实关系。

我们内部其实会小心用 “right” 这个词。我们更喜欢说 mandate。

这很好。不是说你天然拥有，而是先赢一次，然后再赢一次。

对。我们觉得自己有 mandate 去帮助用户解决这些问题，所以才会真正投入。

比如我们现在也越来越重视客户的 spend management。用户用了 Stripe Treasury，就会自然开始关心：我花了多少钱？怎么减少浪费？这些支出怎样和收入关联？而现在很多 token usage，本身就直接发生在产品里。

所以 token usage 我会分成两类。第一类是 用 token 去构建东西，这是 Opex / cost management 的一侧：我花了多少模型调用成本，怎样控制它。

第二类是 产品 efficacy：我的 token-driven 产品到底有多好？不同模型之间应该怎样切换，才能让产品效果最好？这不是单纯压低 token 单价，而是要在质量、速度和成本之间做 orchestration。我们现在在想，怎样同时帮助用户解决这两类问题。

对，尤其是第二类。能做一个 orchestration layer，让企业把 token 的效用最大化，同时仍然保留某种控制感，这件事从来没有像现在这样 top of mind。

没错。现在有一种 hypothesis，说软件会被严重 commoditized。这是 plausible 的。我们可能已经进入 singularity，也可能只是正在慢慢靠近它；当 models 开始递归地产生更好的 models 时，未来会长什么样确实很难估计。

但至少 今天我们实际看到的恰恰相反：软件创建量正在爆炸。 客户也比以往更快 monetization。前面说过，2026 cohort 相比 2025——我之前说“增长快 50%”，更准确地说是 规模大约大 50%，而且增长也更快；2025 cohort 又比 2024 cohort 大约大 70%，增长也更快。

所以软件更多了，被采用得更快；与此同时，一个公司使用的 Stripe 产品也越来越多。比如 11Labs 现在用了 14 个 Stripe 产品。有一部分我还觉得“要是正好 11 个就更妙了”，不过我当然更高兴它是 14 个。

那就干脆做到 22 个。Mati 什么都喜欢按 11 的倍数来，你们离 22 更近一点。

哈，对。更重要的是，软件从来不只是“把代码写出来”这么简单。一个公司还需要长期维护业务里的 abstractions，知道它们怎样贯穿整个系统。人会离职，内部系统会老化，原来掌握知识的人离开后，expertise 也会消失。

Stripe 真正想解决的是整条 revenue stack：帮助公司管理现金、管理收入、更快 close the books、更快增长、更快全球化。随着软件和 token 经济一起扩张，这个机会只会比过去更大。

完全同意。那最后，我想用一个偏“人”的问题收尾。

我不想把“人和 AI 谁更重要”这个话题聊得太抽象，但 Stripe 多年来一直有一件事几乎被普遍认可：你们有很强的 taste。这对一家基础设施公司来说听起来有点奇怪，但大家确实这么评价。公司已经这么大，而且现在越来越多工作由 AI 完成，你们怎么继续保持这种 taste？

现在大家使用 “taste” 这个词的频率确实很有意思。

哈。

有时候我会想，一个比较 cynical 的解释是：大家只是突然需要一个概念，来证明自己在未来仍然有价值。

对，也许根本没有谁真的拥有神秘的 taste。大家都只是把自己过去见过的东西重新组合、重新生产。

是。以前我们还能说“我的手指很有用，我会亲手做东西”；现在手指没那么稀缺了，于是这个模糊的 taste 突然显得特别重要。然后大家又会说，“models 永远不会有 taste”——这大概也不是真的。

我也同意。

但回到你真正的问题，product quality 的确是 Stripe 文化和身份非常核心的一部分。 一方面是因为我们希望用户手里的工具真的很好：经过仔细打磨，让他们走得更快，也让创业这段本来就很艰难的旅程稍微更愉快。

创业不容易。如果你用到一个 surprisingly great 的工具，会让很多糟糕的时刻好受一点。这是非常 users-first 的理由。

另一方面，高质量也让构建者自己更快乐。你和团队看着刚做出来的东西，会说：“哇，这看起来真棒。”和“我们勉强把这玩意儿拼起来了，虽然能跑，但很难看”是完全不同的感觉。经历那么多长夜、长周末，本来已经够辛苦了，做出一个漂亮、好用的东西会让整个过程更值得。

如果问怎么规模化，我会说两件事。第一，必须 top-down。领导者必须不断重复“质量很重要”。它和“赢下 startup，然后再赢一次”一样：谈质量，然后再谈一次，再谈一次。

第二，就是 自己使用产品，并且让使用产品变得容易。

对。

想想 aviation 为什么如此重视 simulation。你不能说“希望这架喷气机能飞”，然后直接让它上天；你必须先通过模拟证明它真的能工作。Nvidia 真正达到 escape velocity 的一个关键点，也是他们从“等 fab 把芯片造出来再测试”，转到“在芯片真正出来之前就模拟 chip performance”。

Stripe 也在大量投资 模拟产品使用。我们可以指向一个真实账户，然后说：“给我生成一个行为上像它的模拟账户。”但要把 PII 全部去掉，把 growth rate 随机化，让我不知道真实客户到底多大；同时保留它日常会遇到的问题、业务的起伏和 seasonality。

然后让这个模拟环境真的“活”起来：看起来像有 dispute 进来、refund 在发生。当然，那些不是真 dispute，也不是真 refund。目的只是让我和团队能够生活在那个用户体验里，真正感受产品到底哪里难用。

我们特别要求 EMs 去领导这种事情，因为他们控制资源，也有能力说：“这个体验不对，必须修。下一个 sprint 我们先提高质量。”另一边则是不断给团队更好的工具，让修质量变得更容易。

所以对 Stripe 来说，scale taste 最终不是一个神秘天赋。它是一种文化，是一些把质量要求持续抬高的制度化机制——原字幕这里有一个词形不清——也是每天真的去用产品、真的走进用户问题的 rhythm。

太好了。Will，今天聊这些真的很有意思：你们怎么在 Stripe 内部构建这么多产品、怎样站在开发方式变化的前沿，以及未来我们会怎样进入 agentic commerce、stablecoins 这些新的经济轨道。

你们有一句我很喜欢的话，大意是：“我们怎样确保下一个 Stripe，是在 Stripe 内部被造出来的？”

对。

我觉得这句话很适合作为结尾。非常感谢你今天的时间。

谢谢。很高兴来这里。