我对许多人未来的可能性感到由衷兴奋。我真正热爱 Supabase 的一点是，我能看到因该平台而涌现的大量创业活动。我非常确信，未来所有能接触到 AI 的人都会以某种形式成为构建者（builder）。你可以构建任何东西，也可以对其进行定制。如果你想对某个应用或用户界面进行微调，你就不必受制于人。实际上我对 2027 年感到非常期待和激动。

欢迎回到又一期的 Lightcone 节目。今天我们请到了 Supabase 的联合创始人兼首席执行官 Paul Copplestone。Supabase 是一个开源 Postgres 后端，已成为 Cloud Code 和 Coda等工具中的默认数据库。Supabase 目前拥有 1300万用户，每周新增超过一百万个数据库。Paul，欢迎做客 Lightcone。 >> 谢谢邀请我参加。 >>那么首先，

众所周知，Y Combinator（YC）在 YC 的第一天会发一件T恤，上面写着“制造人们想要的东西”，但现在我们越来越意识到，应该是“构建智能体（agents）想要的东西”。而你的公司正是这一点的完美体现。你知道，大约 70%的新活动都来自智能体。这难道不疯狂吗？ >> 是的，太狂野了。真的太狂野了。我认为特别是今年，我们在

数据方面看到的拐点是一个巨大的转变，即向智能体倾斜。 >> 为了让我们理解你们增长了多少，因为这确实令人难以置信。是的，比如你关心的数据指标是什么？去年这个时候你们的情况如何，现在又是怎样？ >> 我认为去年的这个时候……是的，我们现在有1300万注册量。大概12个月前，我们可能只有

三百万左右。今年收入将增长4倍。我在想…… >> 比如目前每周创建一百万个数据库。 >> 是的，超过一百万。对、对、对。 >>去年这个时候是多少？ >> 我认为实际上现在管理的数据库数量正接近5000万，而去年这个时候是800万，所以这是一个巨大的拐点。 >> 是什么

推动了这一增长？ >>首先，人们正在肆无忌惮地构建软件，这是软件工程师做的。其次，我认为有更多的构建者开始上线。所以，传统上拥有软件工程背景的人才能做的事，现在非工程师也能够基于 Supabase 实际构建东西了。 >>所以这是一个巨大的转变。你们实际上做了什么来促进或

鼓励这种转变？你知道，显然软件工程师会继续选择 Supabase，但你们如何首先吸引智能体过来呢？ >> 是的，我们在 Supabase 的发展中大致经历了三个阶段。我们最初是一家仪表板公司，然后转型为 API 公司，现在我们要非常明确地成为一家代码优先（code-first）的公司。所以我们试图提供智能体真正想要构建的模态，也就是代码优先。他们大多数时候真的想使用命令行界面（CLI）。另一件事就是被选为大型语言模型中的默认选项，我认为我们极大地受益于这一时机，即我们开始成为数据库的默认选择。 >> 你认为开源在其中也发挥了作用吗？毕竟智能体喜欢

开源的东西。 >> 你知道，很难知道反事实的情况是什么，但我认为这至关重要。我的意思是，我们所做的一切都是开源的，而且似乎对我们有巨大的好处，我们以非常“开源化”的方式运作。比如我们试图支持现有的工具。不仅仅是 Supabase 的工具，我们还支持像 Postgres 这样在 Postgres生态系统中非常著名的工具，并且我们帮助维护它，

所以我们的影响力蔓延到了许多社区。 >> 我猜测智能体实际上非常喜欢开源，因为当出现问题时，它们可以直接查看源代码。 >> 是的。 >> 对，我的意思是，我注意到智能体真的很喜欢感觉强大，而且它们热爱数据。没有什么比撞墙更令人沮丧的了，然后你不知道发生了什么，也

无法修复它。 >> 我认为这也越来越重要，因为现在安全变得如此重要，我想许多企业都希望检查源代码以确认其安全性。如果你拥有闭源代码，那么你可能不会愿意将其作为供应商采用。 >> 开发者仍然是你们追求的核心用户吗？或者

你知道，在2026年你是怎么看待这一点的呢？ >> 是的，我认为我们世界的走向——至少是我们今年看到的——是构建者正在上线，而且人数多到疯狂。今年令人惊讶的是，通常当我们的漏斗顶部注册量加速增长时，通常会看到其他许多数据开始下降，比如激活率、转化率等。但实际上今年所有这些指标都在向右上方增长，这有点疯狂，只是因为模型在构建方面变得如此出色，我们开始看到传统上不具备软件工程背景的人也能来构建东西。 >> 这种区别在于，“构建者”指的是

他们可能实际上并不是软件工程师，所以他们可能只是某个需要构建某样东西的人。比如打开 Cloud Code，结果发现仅靠文件生成能力有限。 >> 嗯哼。是的。而且在某种程度上，这类人群拥有所有这些迸发的想法，他们以前无法说服软件工程师帮助他们构建，而现在他们不必

再说服任何人。他们有各种各样的想法在源源不断地产生。软件工程师仍然占据很大比例，但构建者这一细分领域的增长率相当高。另外……我不知道这上面的天花板在哪里。我记得我们早期的投资者曾说，产品驱动增长（PLG）会在某个收入水平触顶，然后你必须开始进入这个

市场细分领域。但目前看来似乎没有天花板，我也看不到它会在哪里停止。 >> 我的意思是，这在两年前或一年前基本上是真的，但今年肯定不再如此了。 >>是的。 >> 我上周末刚和一个人聊过，如果是构建者这一类别……比如一位金融科技创始人刚刚以超过十亿美元的价格退出他的公司。他一直

处于产品相关的领域，在大学期间在 YC 学习数学，并且能够编写一些 Ruby脚本。但他们总是需要一个工程师来构建软件。而现在他做副业项目，只是在构建自己的东西，并且拥有如何建立金融科技公司的所有知识。所以他实际上可以为自己构建相当复杂的东西

就像资产负债表和追踪软件，他知道如何与银行集成，并且从零开始编写所有集成代码。这完全是那种在两年前根本不可能被构建出来的软件类型。>> 这也是非常理想的建造者，因为像我这样的开发者，我们往往只关注那些以开发为导向的想法和想要构建的东西。

但另一方面，你还有这些领域专家，他们非常清楚自己细分领域的痛点——“这是我的领域中尚未解决的问题”。因此，现在他们能够直接深入这些细分市场，而无需说服其他人加入他们的团队。我想你们之前在 YC 时也讨论过这一点，对吧？关于那种从“你引入团队的人员构成”开始发生的变化。>> 我认为如果回顾一下2022到2025年这个时期，确实存在一种思维上的重大转变。大家开始意识到 AI 即将到来，因此软件工程作为核心技能变得至关重要——无论发生什么，你都需要一个技术联合创始人。这在当时是 YC 中非常突出的主流观点。虽然这一直有一定道理，但在那段时间里这种观念被加倍强化。

而在过去一年中，我们开始说：“实际上，是的，建造者们。”我们看到人们能够……你知道的，更难的事情其实是知道该构建什么。现在，“能够进行开发”这件事几乎任何人都可以随时获取能力，这其实是一件非常棒的事情。想象一下那些永远不会被构建出来的东西？就像你说的，“哦，我们知道人们会买这个产品。我们确实知道这里存在问题，但在边缘情况下，这些人无法说服工程师来工作[笑声]。”>> 保罗，你有没有一些具体的例子？比如人们在 Supabase 上构建的应用程序？也许只是为自己使用的、以前从未被开发出来的那种类型？>> 嗯，一个很酷的例子是在我们的会议上。我们在这里举办了会议，会后一位来自巴西的男士走到我面前，他通过手机构建了一个完整的出租车应用程序。这有点像针对当地市场的小型 Uber。

我只是觉得他很酷，他自己就是个出租车司机。我其实不知道他为什么要构建这个应用，但他能够做到这一点并为此感到非常感激，这真的很棒。而且考虑到他的年龄——大概50岁左右吧——他却有着像十几岁少年般的活力，突然开始构建东西。我觉得这很酷，因为现在的情况是……我认为在某些方面已经显现出来：虽然人们对“未来工作形态将如何”充满不确定性，但在这一类建造者中存在着对未来的兴奋感。而这正是我热爱 Supabase 的原因：人们可以加入其中，那些现在感到不确定的人正在发现这些技能和新机会。以前他们可能只是蓝领工人或这类人群，而现在不同了。>> 好的，所以最近你也在构建一些自己的个人软件？能谈谈你在开发什么吗？>> 是的，正在成长中。这有点像某个阶段的结束，但更多的是源于我对开源核心模式的沉迷。实际上，大概六个月前……说实话有点尴尬，我当时说不会再有 UI 界面了，一切都将通过聊天基于我的开源核心来完成。但事实证明并非如此。

而且我也曾坚决拒绝使用数据库很长一段时间，我只想把一切都放在 Markdown 中。嗯，但事实证明你确实会遇到一个点：数据库是有用的，而且你确实需要 UI 界面。所以在过去的几周里我一直在构建这些功能。我称之为“控制塔”，但它实际上涵盖了我生活的方方面面：我发现我为每个部分都构建了 UI 界面，比如分类处理我的所有电子邮件，这样我就不需要阅读收件箱了。还有财务、支出追踪、健康……我都记录体重和锻炼情况，所有数据都在一个地方。

它的魔力在于，有时候这种想法令人难以置信：我认为我自己使用的这个单一应用程序的财务部分……我觉得至少在功能上与 Mint 或 Monarch 等所有这些东西持平，甚至在某些方面更好，因为你可以开始进行非常个性化的上下文处理。比如它可以通过查找我“G脑”中那个人的名字来识别交易对象，知道那是谁，并正确分类。这曾经是一家公司、几家初创企业专门做个人财务的事情，而我可以直接为自己构建它。我不需要让它为其他人工作，也不需要其他人的意见。这就是我的东西……真的很棒。>> 我们看到很多这样的情况：主要是财务和健康，基本上是你想要拥有自己数据的两个领域。所以我们看到很多人这样做，并将设备上的数据同步到单个数据库中，这简直是一种神奇的技能。你可以提示它来构建跨所有设备的相关性分析。>> 确实如此，再次以健康为例：是的，所有这些数据都在我的 Supabase 数据库中。但它也可以访问我的日历，所以它知道一些事情。比如，“哦，你的体重最近增加了，但因为你正在旅行，这没关系。”你可以说“好吧”，它知道下周可以重新回到正轨。这种上下文信息非常有价值。>> 我还发现，随着我开始使用个人智能体……我有点担心我把所有的例行程序和 CRM（客户关系管理）都塞进了一个智能体里。所以现在我在慢慢将其提取出来，以便如果我想要在上面附加不同的智能体，我知道我可以使用任何智能体。所以 CRM 是另一个非常关键的部分。>> 是的，这就是你们如此有价值的原因：实际上……它是“记录存储”所在之处。数据库才是真正有价值的东西。你想拥有自己的数据库，然后在上面构建所有应用程序或智能体，而不是把所有数据都放在别人的数据库中。>> 这完全是一个疯狂的想法。如果你想想数据库的历史，过去世界上只有相对少数的大型公司运营着非常庞大的数据库。我记得 Supabase 刚起步时，你们有一种想法：应该让每个人都能非常容易地使用它。

就像要建一个数据库，当时觉得这根本说不通：为什么那么多人想这么做？除非你会写代码，不然数据库能用来干嘛呢？其实会真正写代码、构建像个人CRM系统这样的人并不多。对大多数人来说，在AI出现之前这太费功夫了。另一个Supabase对我很有价值的例子是文件上传功能，听起来很简单：我可以把任何文件通过邮件转发给你，或者直接丢进这个界面里。然后我的AI代理会判断这是什么、与我的生活有何关联以及该如何处理，而所有数据都存储在Supabase上。

总的来说，Supabase最终会集中存储我生活的所有数据。一年前我从没想过要一个个人数据库，因为那毫无意义；但现在我觉得这是最有价值的东西。你有一个兼容S3的Supabase文件服务，所有东西都在里面？真的吗？太棒了。这在G-Brain里是默认设置的。（笑声）谢谢。

Paul，你认为这是未来吗？基本上世界上每个人——不仅仅是开发者，而是所有人——都会拥有一个包含自己生活、健康、财务和关系数据的Supabase数据库？我们当然希望如此。我确实认为，所有能接触到AI的人都会成为某种形式的构建者。你可以构建任何东西、进行定制；如果你想修改某个应用或界面，就不必受制于人。

当然，我们自视为一家索引公司。刚进入Y Combinator时，我们只专注于YC的公司，想赢得所有YC客户。这是因为我们知道在企业起步的第一天就必须在场。使命没变，只是视野大幅拓宽了。随着更多构建者上线，我们需要服务他们，这虽然是个完全不同的难题，但也令人兴奋。

大幅拓宽是指增长了一千万倍吗？是的。比如我们现在每周新建一百万个数据库，但如果做点基本算术：假设ChatGPT有12亿周活跃用户，每人每月建一个东西，那就是每月12亿个数据库。这就是我们要迈向的规模，也是我们需要具备的基础架构能力——这在数据库领域以前从未发生过。

Postgres能做到吗？还是你需要自建引擎来扩展以支持每周十亿个新数据库？如果跟AWS谈得更好或许可以，但现在大家都需要电脑。其实很多工作负载不需要那么强悍的硬件（法拉利）。我们最近收购了Turso，他们的架构兼容Postgres和SQLite。我认为SQLite是非常出色的数据库。

我们将提供这一层级服务，称为Supabase Spark，主要面向这些入门级工作负载。理念相同：起步体验一致，但可扩展至PB级别。我们的口号是“从原型到更好、再到Petabytes”。作为公司，我们要确保服务所有人。如果他们业务增长并扩展规模，我们也会让他们拥有良好的体验。

这正是我好奇的地方：你怎么看待这种发展？传统软件公司通常从早期初创企业（如YC批次）做起，同时关注大企业。尤其是数据库公司，在AI之前大家都想成为Oracle，必须尽快进入企业市场以获取利润。因此你会看到大量企业级功能的开发；而转向SQLite似乎是反其道而行：你怎么看待这种策略？是两边兼顾吗？

是的，我们必须同时做这两件事，这非常困难。我们有两个产品分别覆盖两端：Postgres可扩展至PB级别，而Turso则向下扩展以支持原型和SQLite类型的工作负载。试图在如此高的增长率下通过雇佣更多人来解决这个问题，即便有AI辅助也极具挑战，但很有趣。

你最近做过一个调查：起初只有10%的工程师用代码代理编写80%的代码，而在短短6个月内这一比例升至60%。这是怎么发生的？接下来会怎样发展？我们在内部没有AI政策，只是让人们随心所欲地使用他们想要的工具。现在大家确信模型能完成更出色、更多样的工作，因此采用率极高。

我们内部构建的不仅仅是简单的代码生成工具，而是相当复杂的系统。随着向AI编码领域转型，我们进行的测试量以及采用的测试工具非常有用，以确保最终结果的质量。我们在YC看到类似情况：Blacksmith、Depot、Ubi Cloud等公司都在垂直领域发力，因为大家都在做CI（持续集成）。

测试数量简直爆炸式增长。这真的很疯狂：模型现在足够好，人们花时间去尝试后发现“其实效果不错”。大家需要被说服。特别是工程师们——年初时我可能觉得它没那么好，但模型变强了，他们也逐渐意识到用这些模型能实现很棒的成果。

纳维-斯托克斯方程以及诸如此类的事情，比如说服市场相信我们确实能在此开辟新天地。所以我认为这就是我们正在迈向的世界，现在人们已经确信这是未来的发展方向。”

“你见证了 Supabase 经历的三个时代。首先是像 YC（Y Combinator）期间一百天构建仪表板公司的阶段，然后是 API 公司时代，而现在则是……你知道的，某种‘让智能体想要构建什么’的时刻。在每个阶段中，有没有一两个关键点让你特别印象深刻？比如‘哦，就是那个东西在那个时刻成就了我们’。”

“我认为这些转变确实发生了。所以第一个转折点，是的，我想你是在问为什么当我们进入 YC 时还会存在一家数据库公司？”

“在当时看来，这确实是一个如此反直觉的想法。”

“是的。是的。是的。我认为我们看到了即使是开发者使用数据库也多么困难。所以最初的仪表板想法是：‘哦，让我们在后端基于 Postgres 构建一个看起来像 Airtable 的用户界面。’因为我个人也很喜欢 Airtable，我当时想：‘如果后端只是一个 Postgres 数据库，那该多酷啊？’所以那个阶段主要是看到即使是软件工程师也在挣扎。

然后当我们转向 AI 时，我想我们在另一个播客中讨论过这个问题。AI API 的转变是因为有人正在与我们集成，他们说：‘哦，我们想要启动很多数据库。我们需要一个 API 来做所有这些操作。’那大概是2021年。结果证明，这对于2024年是完全正确的举措，当时 Bolt、Lovable 等人都开始在 Supabase 之上构建。

而今年，我只是看到实际上没有人再使用仪表板了。没人……” [笑声] “不再有人访问仪表板了。那么智能体将如何构建？在这个阶段，我只是向团队发布了一份产品备忘录，指出必须代码优先、原生化。Supabase 必须转向代码优先。所以如果仪表板上有功能，它在基础设施即代码方面基本上必须在代码中同步工作。我们重新架构了 CLI 和许多内容，使其能在沙箱中以代码形式运行。”

“你们是否可能有点落后？但你们是受到另一家 YC 公司 Parse 的启发吗？”

“是的。Parse 和 Firebase，我都喜欢这两家公司。有趣的是这些浪潮的轮回，对吧？因为他们做了后端部分：Firebase 被 Google 收购，Parse 被 Meta 收购。但在某种程度上，我认为他们为我们铺平了道路，让我们能够建立一家合法的数据库公司。因为在2014年，如果不使用 RDS 作为你的数据库，那将是荒谬的。然后他们出现了，开始转向 Atlas（MongoDB 的云托管服务），许多这些数据库公司展示了你不需要仅仅使用三大超大规模云服务商之一。你可以拥有一家合法的数据库公司。所以那个时机对我们至关重要。”

“是的，人们似乎忘记了这一点，但它确实是一个构建得非常好的产品。它推出时正好是我第一次开发 iPhone 应用的时候，当我试图处理那些事情时，切换到像样的 RESTful API 感觉相当不错。”

“这些转变总是伴随着拐点发生的。在那个时候，市场上发生了两件事：不知何故，MongoDB 说服了所有人认为 NoSQL 应该是存储数据的绝佳方式。第二点是移动互联网的兴起。所以我们很幸运也赶上了这几波浪潮。而现在我们正处于风暴中心。”

“是的，我的意思是……咳咳……这正是我刚才问到的，关于你如何看待企业客户与早期用户之间的区别。因为我想说得更远一点，Heroku 是第一个采取‘嘿，先从最好的开发者体验开始，然后再扩展’模式的公司。但实际上要随着人员增长进行规模化扩张相当困难。我认为 Heroku 某种程度上未能弥合这一差距，即当应用变大且需要更高性能时如何留住用户等等。但历史上每家公司都必须解决这个问题。你们正在朝这个方向看，但也可能不需要那么做。老实说，如果仅仅拥有从零到十（无论指什么规模）的市场继续以这种速度扩张，那将是非常巨大的。”

“是的，好吧，我们赢得了这一切。所以……” [笑声] “所以我们可能不需要那么做，但我们肯定会这么做。向 Heroku 致敬，我认为他们普及了 Postgres。但在当时，Postgres 还相当……它还处于萌芽阶段，并且在扩展方面仍有一些限制。所以我们不得不在 Postgres 周围包装一些工具，使其能够无限扩展。”

“我的意思是，我想对你们来说更好的类比更像是 AWS 实际上让人们早期加入并实现扩展。那么……是的，有什么经验教训吗？比如你们是如何思考确保无限扩展能力的？”

“我认为他们听到的一个统计数据告诉我……哦，我可能会弄错，所以请核实事实，但类似 AWS 40% 的收入来自那些最初在他们平台上起步然后扩展起来的初创公司。而这正是我们想要的类别。我们知道，说服人们从一个数据库提供商迁移到另一个几乎是不可能的。所以我们只想在第一天就在那里，确保他们拥有良好的体验，然后确保他们实际上不想离开。”

“商业模式就像 Stripe 一样。我的意思是，如果你能实现它，这简直是地球上最好的商业模式。在第一天让他们加入，然后随着世界上增长最快的公司无限扩展。”

“你只需这样做一代人的时间，然后就成为了一家世代相传的企业。基本上就是这样。是的，这很难……因为‘第一天’是什么样子的？这在快速变化着。在过去，我的‘第一天’总是 YC 的客户。而现在，‘第一天’变成了……好吧，每个人都是构建者。他们将要使用什么？有哪些模式？他们将如何选择他们的数据库？这些都是棘手的问题。”

“YC 的下一批次现在正在接受申请。你有创业点子吗？请在 ycombinator.com/apply 申请。为时不晚，填写申请表会让你的想法更上一层楼。好的，回到视频内容。”

“这属于不同的客户群体。就像最初你们开始的时候……当时数据库并没有面向个人的市场。一家数据库公司成为直接面向消费者的业务这一想法听起来简直就像语法错误一样。”

“是的。嗯……”

其实你们有两个细分市场。一个是像早期公司那样，拥有强大的 Stripe 式商业模式；但另一方面，你们也直接向消费者或他们的代理（agents）销售。>> 是的，没错。

这些用例可能无法像初创公司那样以同样的方式实现规模化增长，但他们可能会因为你们正在支撑他们的个人理财软件、出租车公司或其他类似应用而长期使用你们。>> 没错。随着他们生活的发展，信息的积累基本上就是我们自身增长的索引，对吧？所以他们存储的数据越来越多。人们在收集更多的数据。这种“产消者”（prosumer）市场对我们来说本质上是一个良好的增长向量。

那么，从那个角度来看，你怎么看待个人代理（personal agent）的世界呢？如果说编码代理需要 Supabase 是很清楚的，那么下一阶段是什么？假设我们都有个人数据库，他们需要确保让个人代理能够轻松地与之交互吗？这和之前有什么不同吗，还是基本上是一样的>> 事情？

我对个人代理非常看好。在我自己的助理（EA）离开一周，让我确切了解了他们能做什么之后，我现在对为个人代理构建产品这件事着迷。确实，我之前对我们公司说过“代码优先”，即我们为做编码工作的人类构建产品；但实际上，我们是在为代理（agents）构建。那些人类很快将不再直接进行交互。

我目前的工作方式是使用 AI 助手。我经常坐在电话里，一直和它聊天，说：“哦，你能做这些更改吗？”我用来确保我正在正确构建或进行“吃自己的狗粮”（dogfooding）的启发式方法是，我不看代码，除非我想检查它是否真的在正确构建东西时，否则我绝不允许自己查看架构。但是当

我做这些更改时，我只想和它交谈并看看它能改变什么。>> 我们中有一个是同类人（暗示也是AI或高度自动化）。>> [笑声]

这也太疯狂了。它正在做一些很了不起的事情，感觉就像两年前的科幻电影里的场景，但现在我经历了这么多让我目瞪口呆的时刻。如果你六个月前向某人展示这个，他们会认为这是不可能的。>> 是的，几周前我参加了你们的 Supabase Select 大会，那是一场很棒的会议。我当时有个疯狂的想法：当我坐在那里听你谈论 Supabase 推出的所有令人惊叹的新功能时，我想，如果我是在 Supabase 上构建应用的人，也许我甚至不需要自己去理解所有这些新功能。我想让我的代理去 Supabase Select 大会听所有令人惊叹的新功能，并弄清楚如何将它们集成到我的代码库中。

哦，那太狂野了。一个真正的虚拟大会。我们应该这么做。专门为代理举办的大会。>> 为[笑声]代理办的大会。

他们会现场出席。>> 现场直播的。他们可以[清嗓子]像这样互相交谈，交流关于 Supabase Live 的技巧之类的建议。哇哦。>> 你可以桥接它们。你可以像空投一样把 Markdown 文件发给所有人，但你必须身处观众席才能获取它。>> 我们叫它 Artifactory（人工制品仓库/代理工厂）。

[笑声] >> 哦，伙计，我挺喜欢这个称呼的。我们之前聊过，你们做了一些让代理变得更好的事情。比如错误信息（error messages），你知道的，那个关键洞察是什么？还有哪些其他你们正在做的事情，一方面看起来显而易见，另一方面却没人做。

是的，关于错误信息，我在波士顿参加 Dbt Labs 的活动时感到惊讶的是这并不那么显而易见。但我们深入研究了我们的错误信息，以便你可以采用这样一个用例：哦，我想构建一个应用程序。通常开发者看到的错误信息只是“500 系列”的基础报错，你只知道出了问题，但现在你需要代理能够自我修复。所以在错误信息中，你们实际上是在告诉它们如何修复这个错误或去阅读一些文档来解决问题。

所以这很大程度上就是选择你的用例，并尝试通过改进自己的错误信息来进行这些循环迭代，以便基本上能一次性解决任何你想要的问题。>> 是的，这说得通。你基本上知道，如果你被代理使用，代理会遇到错误信息。在过去，人类必须去 Google 搜索并做一堆事情；但在这里你可以直接说：“哦，你只是 inode 用完了，所以你大概应该去做这个。”

没错。因为赢得代理青睐有两个阶段。第一阶段是被模型选中；第二阶段是如果它们卡住了，你不想让它们切换走代理（因为一旦切换可能就回不来了）。所以你要给它们自我修复的工具。这其实并不复杂，现在的代理足够聪明，能解决很多问题；但你必须重新设计许多以前仅针对人类和开发者的东西，使其适用于代理。

你们测试你们的代理产品吗？就像有代理尝试使用 Supabase，然后报告所有遇到麻烦的地方吗？>> 是的、是的。我们在 Evals 网站上有不同的模型，我们可以看到哪些模型构建得最好；我们内部也有自己的评估套件。我们也评估仅使用 Postgres 时哪些表现最佳，这对行业来说很有趣，并围绕它构建技能体系，以便他们能够采用它们并使用 Postgres 进行开发。所以是的，有很多测试工作。事实上，现在我们大部分的工程精力都

投入到针对特定用例的测试中，而不是构建本身。我们要思考人们是如何构建应用的，并围绕这些建立套件。

Gary，当你构建 Gbrain 时，你是基于 Supabase 搭建的。你能谈谈你当时是如何决定基于 Supabase 构建的吗？嗯，作为用户你的体验如何？

是的，我想 Gbrain 是我之前写的一些内容的提炼。我首先研究的是 Gary's List，那是代理式的（agentic）。它像一个代理新闻编辑室。我必须建立一个研究系统用于 RAG 以及政策和论文，它会阅读关于给定主题的每篇报纸文章，然后尝试进行综合。嗯，然后我将其提炼并开源用于 OpenClaw 的检索功能。因为

那个想法是，好吧，我在 Rails 中实现了它，那简直就像是一个代理的富士康工厂。我把每一次 LLM（大语言模型）调用都视为极其昂贵且充满危险的操作。然而，当我看到 OpenClaw 时，感觉完全不同了，它就像 Esselen（注：可能指代某种极简或高效的概念），这是一种截然不同的与 AI 协作的方式。因为你会意识到，AI 很聪明，它不会试图伤害你，所以你应该让它自由行事，只需给它数据和能力即可。

于是我发现，一百万个 token 实际上是一个惊人的工作记忆容量。大多数人类只能在大脑中同时保持大约“七加减二”个信息点，而一百万个 token 大致相当于三本《哈利·波特》小说的内容。但这对于代理来说仍然有点局限，因为在任何给定时刻，将正确的三本《哈利·波特》内容保留在上下文中是一个真正的挑战。因此，感觉中间存在某种东西，用于构建“公司大脑”或个人知识库。

我拥有大约五十万个 Markdown 文件，记录了我所有的沟通历史。这个系统确实掌握着我以及我所关心的一切的上下文信息。但在任何特定时刻，代理可能只需要两页纸左右的内容。这是一个检索问题。因此，当数据量达到几十甚至几百吉字节时，你需要 PG Vector（PostgreSQL 向量扩展），需要 Postgres。你知道的，在 SQL中构建图数据库非常容易。

这就是 G Brain 的核心：它结合了 RAG（检索增强生成）和图数据库，能够从非结构化数据中创建结构。这有点像动态模式，让我想起了 Palantir 早期的做法。整个理念是，当存在这种中间层时，代理会变得更加强大。代理只需说“我在找这个”，它就会遍历图结构，执行向量搜索，然后返回报告并将其加载到上下文中。

这就是 G Brain 的工作原理，而 Supabase 的需求则非常直接：我需要托管的 Postgres，并且需要它能够以极快的速度支持五十、一百甚至三百吉字节的大型数据库语料库。效果非常好，自动扩展功能运行得很完美。现在最有趣的事情是，在使用 Browser Use 时，我使用了一个侧边栏浏览器来运行它。OpenClaw 可以进入 Supabase，利用数据库或新创建的 API，并自行管理这一切。它具备自我管理能力。

你是否需要提示它去理解数据结构，比如图或 RAG？ 有趣的是，我记得当时进入 Claude Code（注：原文为 cloud code，结合语境推测指 AI 编码助手），只是说：“使用 Exa（搜索引擎）去下载并转录你能找到的所有 AI 研究论文。”今天我可以像 Alpha Signal（注：可能指代某种数据源）那样，让它去寻找关于 RAG 和图数据库以及文本检索的所有研究资料，然后针对我的用例进行总结——即“我如何帮助代理访问这些信息？”

是的，那天晚上我在参加一个关于数据库未来的晚餐会时，有一个观点认为：本质上，数据库是数据的检索机制。你可以建立索引以便以特定格式搜索数据，比如图或 RAG。其中一个非常有趣的想法是：将代理置于循环中，以创建完美的数据结构用于搜索。如果你多次查询这个数据集且耗时十秒，为什么不安排一个代理循环运行来创建新类型的索引或找到能在不到一秒内返回结果的最佳索引？

动态检索显然是必然趋势，只要你拥有足够智能的代码生成能力。 是的。目前我使用 OpenClaw，然后在我的生产实例中运行，从中提取追踪数据作为评估数据集。我还有一个名为 G Brain Evals 的独立仓库，包含四十个不同类别的具体检索类型、检索效率以及成本效率和延迟等指标。

评估（Evals）的妙处在于，你可以告诉代理：“循环运行，自动研究并迭代。任何能改善评估指标的东西都提交到主分支。” 是的，并且对于尝试失败的方法，写一个 Markdown 文件解释你认为它为何无效，然后将其归档到 G Brain Evals 中。我使用 Cappy（注：可能是指某种 AI 代理工具）。Cappy 有一个“队长”的概念，类似于 Grok 机器人。你可以给它一个上下文设定。我有一个始终运行的任务：“提出新的类别”；另一个始终运行的任务是：“遍历评估中的所有类别，自动研究并每天尝试找到提高我们内部评估分数的方法。”

它一直在运行。这是针对特定用例的 RSI（注：可能指 Repeated Self-Improvement 或类似概念）的一个非常原始的版本。但我想，如果提高抽象层级，你可以为通用场景做同样的事——不仅限于我的用例（如 OpenClaw），而是适用于任何人的检索需求。唯一变化的是用例、追踪数据和数据集本身。

你显然了解评估机制，并通过围绕框架包装来改进软件。你认为未来开发者是否必须掌握这些知识？ 也许不需要。老实说，我觉得我们还处于非常早期的阶段，我目前只是在随意尝试。我喜欢以开源形式进行这些探索。我希望有人能看到并说：“哦，我可以应用这个。”我认为我们正是在此时构建使用这些技术的基本原语。我记得今年早些时候读过 Steve Yegge 关于“工厂”的文章，当时完全无法理解。现在我觉得至少拼凑出了一个对我有效的方案。

他琢磨出如何构建你脑海中构想的事物。>> 我注册了 openusd.dev 这个域名。之所以这么做，是因为其实存在一种名为 OpenUSD 的文件格式。我喜欢收集域名。突然之间，Stripe、Visa 等公司都宣布支持 OpenUSD。我当时心想：“我得赶紧把这个域名利用起来。”但我一直没时间用它。于是，我和 Dot 聊天，它就像是一个拥有生态系统等的开发者工具。我就在电脑上跟它闲聊。

然后，当我结束一天的工作准备休息时，我在手机上叫出了它——听起来有点可疑，但我>> [笑声] >> 我发誓我只是>> 在输入。>> 只是跟它一起写代码而已。我当时说：“哦，我不喜欢生态系统链接到用例的那种信息架构。你能给些建议吗？”它确实给出了建议。我说：“好的，那就实现它们吧。”

二十秒后，它说：“哦，好的，我已经做完了。你要刷新页面吗？”我刷新了网站。代码写得非常好，所有链接都整合在一起，还接上了 SEO 之类的基础设施。因此，我不需要像传统那样做那些繁琐的工作。我只是跟它聊天，那一刻让我仿佛瞥见了未来的一角。>> 我的意思是，你可以做到这一点，因为你知道自己想构建什么。

没错，就是这样。我显然有工程背景，所以我大概知道如何提示它。但我试着什么都不说，不引导它去 GitHub 之类的地方，而是试图像普通人那样编码——或者说像明年才入门的人那样操作。这样我就能真正“吃自己的狗粮”，了解 Superbase 在一年后是否好用，体验如何。>> 是的，Boris 说“我只是想让它自动完成”有点好笑。

一旦模型进入分发阶段，这些能力实际上已经存在于模型的权重中，它确实能做到。但在那之前，还是需要一些标记语言提示。不需要太多提示，哪怕是很小的量，它也能直接完成。我认为我们正进入社会的一个非常奇特的时刻：AI 研究似乎真的已经到来，从 20% 到 80% 的转变正在发生。这些进展主要发生在 Cloud Coder、Codex 等内部循环中。

与此同时，社会并没有足够多像 Paul 这样知道该构建什么、以及如何向 AI 提问的人。因此，这就像 unstoppable force（不可阻挡的力量）遇到了 immovable object（不可移动的物体）。模型的能力呈抛物线式增长，而真正知道如何利用它对产生社会影响的人数却基本保持不变。>> 是的，而且人们对这一点感到兴奋也是好事。我认为这也是另一回事。很多人变得偏执或焦虑，但我对未来的可能性感到真正的兴奋。

我之前的许多初创公司都专注于蓝领工人，或者那些我必须用技术包裹起来的人群——他们很多人一生都在从事繁重的工作。Superbase 让我真正喜爱的一点是，我看到了因该平台而兴起的创业热潮。因此，我预见了一个未来：将会有更多的创业者出现，这对许多人来说是一种非常有成就感的生活方式。

只要我们能保持这种节奏并避免一些疯狂的事件，我对 2027 年感到非常期待。那对许多人来说将是一段有趣的旅程。>> 我们看到这样一个时刻：垂直 SaaS（软件即服务）创始人实际上在筹集 A 轮融资时遇到困难。即使你的规模很小，比如年经常性收入（ARR）只有 500 万到 1000 万美元，这在历史上已经是一笔巨款了。

就在 9 或 12 个月前，这几乎是 guaranteed（保证）获得 A 轮融资的门槛。但今天看来……人们似乎对垂直领域的投资不太感兴趣，而对水平领域和 AI 的投资则像是完全绿灯放行。但垂直 SaaS 公司真的很难受。然而，这也恰好发生在这样一个时刻：你往往可以用 10 到 15 个人就达到 2500 万、3000 万甚至 5000 万美元的 ARR。

是的，如果有 15 个人，人均创造 200 万美元 ARR，且拥有 50% 的利润率，每个人每年都能赚一百万美元。这对许多人来说都是一个惊人的成果。>> 是的。与此同时，我们在办公时间接待了许多这样的人：他们抓住了机会（拿到了 brass ring），却因为无法筹集 A 轮融资而感到沮丧。

所以，我在办公时间经常对他们说：“你将来可能会回头看这段经历，庆幸它是一场祝福，因为你并不需要这笔钱。”在过去，你必须筹集一亿美元才能达到每年 3000 万美元的收入，因为你必须雇佣大量人员。而现在你不需要那样做了。>> 是的。初创圈里确实存在一种“徽章效应”。对我来说也是如此，起初获得融资感觉像是取得了巨大的成就。

但实际上，在我看来，现在不寻求融资反而是一种伟大的成就。所以，我有点羡慕那些能达到这种状态的公司。>> 是的，我不知道怎么说。世界变化极快，但 Superbase 在所有公司中确实成功地驾驭了每一波浪潮。对于想要效仿你的人，你有什么建议吗？

有一件事让我每晚都能安然入睡，那就是“林迪效应”（Lindy Effect）。数据库已经存在了 50 年。我认为它们还将再存在 50 年，而且无论 AI 如何发展，我非常有信心数据库依然存在。你可以从中解读出你想要的任何东西：你必须选择那些非常持久的类别。如果你要押上你的整个人生——基本上我就是如此——那么你要选择一个你觉得值得投资的领域。

我认为另一件事是，事物变化太快了，所以我们 Superbase 并不试图拥有所有答案，而是确保我们始终以最快的速度适应。对我来说，我评估或观察了许多我最喜欢的开发者工具，它们通常以开发者为重点起步，然后逐渐向上移动，变得非常企业化。

停滞不前，他们会失去那份热爱。从我们的角度来看——至少从我个人的视角来看——像 Stripe 这样的公司，拥有一位真正关心如何专注于构建新方式的创始人。因此，如果你在为下一波浪潮而建设，你就必须始终用一只眼睛注视着未来的方向，因为现在的时间线非常短。事物发展如此迅速，但关键在于保持极高的适应性，并确保团队内部有足够的能力进行快速调整。这正是我们未来一年所关注的重点。

你认为从这些经历中，你学到了什么特定的东西吗？因为你经历过最初的 Vibe Coding 拐点，然后是 Opus 48 的拐点以及 Co-gen。当下一波浪潮——希望是许多拐点中的下一个——到来时，你会做些什么不同的事情来更好地做好准备吗？

首先，吃自己的狗粮（Dogfooding）是最重要的事之一。所以我总是尝试使用这些工具来了解其中的差距，没有什么比你自己在使用自家工具时遇到卡顿更能提供反馈了。其次是保持容量（Capacity）。我们努力与该领域的关键参与者合作，这种生态系统策略非常有益，因为他们会向我们反馈他们正在构建的内容。

我们还努力在团队中保留一些余量，这虽然非常困难，但当他们有新想法时，我们可以尝试一下。即使很多赌注最终并没有赢——即便看起来我们合作做一些很酷的新事物，实际上我们也并不确定。它们可能听起来很棒，但我们尝试后发现失败了。但那些真正奏效的项目最终意味着我们可以一起驾驭这股令人惊叹的浪潮。

这是一个很好的结尾，Paul，非常感谢你。我们下次见。