一个系统工程师的十年：黄东旭访谈全文

English Version

Transcript & Translation: Carrie

Visuals & Editor: dca5 & Shiyu

jiang： 我们这个活动是 Papers We Love，是几年前我在美国的一些活动上遇到一个分布式的活动组织，他们会在各个地方组织一些 meetup 来分享论文，然后大家一起做技术研讨。后来我跟他们联系，在中国做 Papers We Love，当时我在北京。我们这个活动既会讨论一些计算机方面的论文，也会分享一些工程架构和思考。今年我特别想重新思考现在软件行业在新的发展阶段所面临的转型，所以今年的分享普遍也会比较深入一点。

今天很高兴邀请到 PingCAP 的黄东旭来分享，讲一讲他做 PingCAP 这十年的经验，以及他对于现在这个行业以及宏观的科技领域变革的思考。

黄东旭：我叫黄东旭，是 PingCAP 的 Co-founder 和 CTO，我们是一个做分布式关系型数据库 TiDB 的公司，也是国内相当知名的开源项目，今年是第十年，国内的小伙伴可能比较熟悉，并且是用户。

我定义自己的身份还是工程师，每天写代码，现在更偏向研究。过去十多年我主要做分布式系统工程，包括把 scalability（可扩展性）和数据库的问题结合起来，帮助企业客户解决数据规模的问题。

最近这半年兴趣和角色有点转变，在一个 AI 会改变几乎所有事情的时代，今年我在 PingCAP 内部带领新的小团队，进行关于 agent 和 data+AI 方面的研究和实践，看看在 AI 的时代数据库或者数据平台应该是什么样子，会有什么疯狂想象。

个人方面我一直都是典型的开源 hacker，比较喜欢野外，从 22 年搬到现在这个地方，中美两边跑。今天的环境确实是非常特别，在大山里面跟大家做这个分享。

jiang： 我们先从 PingCAP 聊起，你可以讲讲在10年前，PingCAP是怎么开始的？当时为什么选择去做技术社区和技术传播？

黄东旭： 我们公司十年前开始创业的时候，三个创始人全都是工程师，并不是有一个要发财暴富的理想，只是觉得分布式数据库这个事情在程序员圈里面有点像程序员的三大浪漫：operating system、compiler、database。基本上每一个程序员都会觉得，如果真的喜欢编程的话，都会想自己有机会能够挑战。

十年前，当时我在上一家公司，叫豌豆荚，是一个做手机应用分发的平台。当时我在里面负责data infrastructure（数据基础设施），其实说得难听点就是这个公司没有专职的 DBA（数据库管理员），我们得去维护 MySQL。

但好的地方就是当时豌豆荚的业务增长非常快，所以很快就遇到了 scalability（可扩展性）的问题。我们当时不仅是提供 App Store 这种应用分发的平台，同时还帮助 Android 的用户提供了类似今天 iCloud 的功能，帮用户备份各种各样的 data，当用户换手机的时候能直接从 cloud 下载。背后的存储系统一部分是 Hadoop、HBase 等，另外 structured data（结构化数据）其实全都是 relational database（关系数据库）的。

当时我们用的 MySQL，每隔几个月就得去把这个 MySQL 的集群 reshard（重新分片）一下，因为 MySQL 是单机的数据库，当你的数据量超大的时候，就得去分库分表，所有搞数据库的朋友都知道，真的是一个噩梦般的词汇。

当时公司也没有 DBA，所以我跟现在的 CEO，就是 Max，只有我们两个，负责这个 MySQL 的 scalability（可扩展性）或者说 MySQL 的维护工作。当时我们老板给我们的 SLA（服务级别协议）特别高，因为在业务快速增长的时候你的系统崩溃了，或者说 system downtime（停机时间）就意味着丢钱。所以我们基本上扩容或者一些维护都是在大半夜，经常大半夜不能睡觉，天天在倒腾数据、换分片，觉得很痛苦。

另一方面，当时业务团队也非常痛恨我们，说"你们这个 infrastructure 团队，为什么这个数据库不能‘join’，不能‘group by’，不能写这些很灵活的SQL"。因为本身是 SQL 数据库，用户就应该能写 SQL，但是分库分表完以后，可能 99% 的 SQL 功能就不能用了，而且所有的地方都得带一个类似 sharding key（分片键）的东西，很难看。做应用开发的小伙伴肯定不理解这件事情，所以就会说你为什么不让我做这个、不让我做那个。简单来说我们就是属于两头受气：一方面感觉自己阻塞了业务的发展，总是被甩锅，另一方面我们自己也觉得维护这个东西非常费劲。

当时第三个契机就是我们在豌豆荚不仅维护 MySQL，我们还维护 distributed cache（分布式缓存），就是 Redis 那部分。Redis 的部分就更糟糕了，但 Redis 有个好处，我们当时写了一个middleware（中间件），把 Redis 的 scalability（可扩展性）的问题给解决掉了，后来开源出了一个项目叫 Codis。很快这个项目就火了，因为当时 Redis 才二点几的版本，它没有一个分布式的系统。我们当时那个项目就是属于业界几乎唯一的开源的分布式 Redis 解决方案，所以就火了。

那时候我们就发现，如果你真的解决了一个非常重要的问题，就会被使用。结果开源出来后，结果很快几乎你能想到名字的中国互联网公司基本都在用那个 Codis 软件。那个项目就我和现在 CEO Max 两个人写的，也就两个礼拜。

我们就发现这个是一个很好的杠杆，而且确实帮助到了别人。我们当时就想，为什么不把 MySQL 的 scalability（可扩展性）的问题也一起解决了，同时变成一个开源的方案，这样就可以帮助跟我们一样非常痛苦的这些做 data infra（数据基础架构）的程序员，解决他们 OLTP（联机事务处理）系统的 scalability（可扩展性）的问题。我们当时非常自信，觉得我们是世界上最好的工程师了，基本上什么系统我们写不出来？那就干脆挑战一下数据库。

第二点就是当时看到了 Google 在 2012 年跟 2013 年发表的两篇论文。一篇论文是 Google Spanner，如果做数据库的同学肯定知道这篇论文，算是划时代的一篇论文，是数据库系统最近十年最重要的一篇论文之一。另外一篇是 Google 在 2013 年发表了他们的 F1，是关于构建一个基于分布式存储的 SQL 层的一篇论文。

那两篇 paper 其实给我们一个鼓舞。如果大家现在看那两篇论文，从今天的视角去看，其实并没有讲太多细节的东西，只是说这个 system 大概是怎么做的，整体的架构有点像 overview 的 paper。但对于十年前的我们，最大的收获有两点：第一，这件事情原来已经有人做了；第二，Google 已经把这个问题解决了。因为你想象一下，十年前当时我们还在用分库分表、搞 sharding key，但是 Google Spanner 已经开始用上 distributed horizontal scaling（分布式水平扩展），感觉 CAP 定理有点被打破了。我们当时得到最大的一个启发，是这件事情是可以被人类做出来的。我当时下一个推论就是，反正我们是世界上最好的工程师，那为什么我们不能做出来？所以当时就决定，我们要做，而且要用开源的方式做。

当时运气也比较好，正好是中国 VC 的黄金时间。2014 年的时候正好是中国的 A 股创新高，同时有很多中概股去美国上市，这条路已经走通了，于是有一波 VC 是非常有钱的，而且有全球化视野，这波 VC 是跟美国硅谷这边很像的风险投资。

我现在回头看，那个时候我其实也完全不知道风险投资是怎么回事。很神奇，我们去见天使投资人的时候，也完全不知道该怎么融资。我就在黑板上给他们画 Google Spanner 的 system architecture（系统架构），讲这个算法我应该怎么实现，这个 Raft 我应该怎么实现，为什么我一定要做 SQL，SQL 里面的难点是什么，为什么我要从头构建。后来我发现天使轮的所有的 VC 全都不懂这些东西，他们只是觉得这个人很有意思，感觉好像还挺厉害的。而且问了一圈朋友，他们的朋友觉得这个公司的创始人以前好像还做过 Codis，声誉还不错，所以就稀里糊涂地就拿了 100 多万美金开始做。

包括像刚才提到的营销的部分，我们三个程序员创始人，没有任何的营销经验，我们第一反应是看一下市面上大家都是怎么去推销营销自己的产品的。我一看就非常生气，我说这些明明就是软文。

如果你去看十几年前的中国互联网，很多营销团队他不是程序员，所以这些文章写出来的效果，从工程师的角度一看，就知道这是广告，很水。所以我当时就觉得我们应该去做工程师喜欢的内容。这是第一方面，我们不会做别的，我们只会做开源社区，我们只会在开源社区里面去讲我们这东西怎么做的。

第二方面，我觉得当时市场里面非常缺乏这个定位，就是像我们这样的能说出很多技术干货的定位。我们觉得这可能是一个空缺，我们应该去做。但是现在我觉得很多技术类的项目，都沿着 PingCAP 这条路在做，已经不是什么稀奇的事了，但是十年前确实是还挺特别的。

第三个原因其实是我个人的想法，我还是比较喜欢像今天这样的社群的感觉，有人和人之间的沟通，以及有共同的爱好，大家一起去交流一些自己喜欢的东西。当时 PingCAP 最早的 meetup 是每周线下都搞的，其实也没有什么内容，就是大家把最近自己在做的系统功能来分享一下，看到好的论文来讲一下，也就是 Papers We Love 的感觉。我们每周都在讲论文。

回答一开始那个问题，没有什么策略，就是自己喜欢，最后发现这个好像也确实得到了大家的一些回应。因为我们自己也在做数据库这种贴近工程师的事情，所以本身受众也是我们的客户，所以就慢慢这样了。

jiang： 那时候为什么你们是选择从头去写，而不是从 MySQL 的代码里面去做一些改造，比如改造他们存储引擎之类的？

黄东旭： 其实我当时的第一反应和你一样，PingCAP 成立的第一个礼拜，我在做的第一个事情是自己写了一个 MySQL 的 storage engine（存储引擎），因为 MySQL 和 PostgreSQL 其实对底下的存储是有一套 interface（接口）的。我最直观的想法就是说，那我干脆直接在底下去做一个分布式的存储，然后把分布式存储的接口接到 MySQL 后面，不就可以变成分布式的 MySQL 了吗？

但后来发现第一个问题，MySQL 甚至 PostgreSQL 这些单机数据库最大的问题在于 SQL 优化器，因为对用户来说，它使用的一定是 SQL。我们其实一直都不想去做一个 NoSQL 这种 key-value 的东西，因为真正赚钱的东西仍然还是 SQL。而且我也不想做 Spark、ClickHouse 这种 OLAP 的东西，因为 OLAP 虽然很多人做，但是这个东西真的也不赚钱。OLTP 才是真正赚钱的东西，像 Oracle 这些。但是他的问题是在数据量大了以后，OLTP 这边的整个 SQL 的execution engine（执行引擎）、optimizer（优化器）都不是针对分布式的存储设计的。

我举个简单例子，做一个简单的SELECT COUNT(*)，比如说去统计一个表的总数有多少。 MySQL 优化器认为这个 table scan（表扫描）的算子，就是一个单机的，就这么扫一遍。但是你仔细想一想，如果这底下是一个分布式存储，你同时又知道这个底下这张表，我在每台机器上都负责哪一个 range，那这个SELECT COUNT(*)在一个分布式数据库或者分布式SQL数据库下，它的执行计划就应该变成一个分布式的执行计划。我应该把它变成一个 aggregation job（聚合任务）分发到底下，然后再把这个结果再回来做一次 final aggregation（最终聚合）。但是我举的这个是最简单的例子，还有很多其他的例子。你会发现你想要去做这些针对分布式的场景的优化，基于原来的、一个 20 年的东西已经没法改了。如果想要未来这件事情天花板更高，就应该去从头构建。

其实这个也是 Spanner 给我们的一个启示，Spanner 跟 F1 都是这样。Jeff Dean 负责了一些 Spanner 这个项目，他大概几年前在一次采访里面被问到"为什么你的 Spanner 要重新做这个东西？"，他也说了很类似的理由，就是当你基于一个已有的系统改造，你会发现你好像双手双脚都是被束缚住的。我们当时想选择一个天花板更高的方向去做，所以就选择从头构建。虽然这可能是一个更难的道路，但是它的天花板或者说最后的收益会更高。这是官方答案。再说一个个人的想法：首先 MySQL 代码非常丑陋，所有看过 MySQL 代码的同学可能都知道。第二，我非常讨厌 C 和 C++。当时我们非常希望用一个自己能够喜欢的编程语言去搞一个创业公司，所以为什么不呢。（所以就用Go和Rust重新写了整个数据库系统）

jiang： 在这十年的做数据库的过程中，你觉得有哪些比较重要的时刻，或者是你做对了的决策？

黄东旭： 第一个重要的决策，我觉得就是刚才说到的第一个决策：不基于 MySQL 的代码库。这个是我觉得非常正确的，直到今日我也觉得是正确的选择，从头构建这样你的灵活性比较高。

第二个决定，现在如果回头看的话，可能我会重新考虑，是坚定选择了 MySQL 的 wire protocol （线协议/协议层兼容），选择了一个主流数据库的兼容来去做。我非常不喜欢像 MongoDB 这种自己去发明一个 syntax（语法）。因为对于很多客户来说，迁移成本是特别高的挑战，所以 MySQL 的这个选择——我兼容 MySQL，但是我不用 MySQL——这个选择我觉得很对的，至少能够节省我们大概两年时间进入市场的速度。所以选择了一个已有的生态系统去拥抱。

第三个我觉得比较重要的选择，当然也是一段黑历史，我们大概花了大半年时间基于 HBase 上面做了一个 transaction layer（事务层），然后在上面套一个自己的 SQL 层。第一版其实基于 HBase 的，但是当时我做了一个特别重要的不可逆的决定，就是不要再基于 HBase 了，自己去做底层存储，就是现在的 TiKV，用 Rust 来去做的 distributed transactional key-value database（分布式事务型键值数据库）。现在也有好多朋友在用着 TiKV。所以这个又是一个很重要的决定。

另外一个最近这几年比较重要的决定是，把整个公司的方向转成以 cloud 为主的一个模式，甚至为了 cloud 重新再去设计 TiDB 的内核。这个现在看非常正确。

然后最近的一个决定我还不知道正不正确，就是最早说的AI的这一部分，还没看到结果，但是我相信这又是一个未来三年很重要的一个决定。

jiang： 你说到 cloud 这部分，我觉得也是特别重要的，因为在 16 到 18 年，整个云计算在全球、在中国发展特别快，然后也是 Kubernetes 以及相关的云原生的概念极大发展的一个阶段。

黄东旭： 我们拥抱 cloud 其实走了很多弯路。大家提到 cloud，可能是 Kubernetes或者说部署这个级别的。一开始我也是这么认为的，好像我的数据库只要去写了一个 Kubernetes operator，同时提供一个自动化的云服务，就是拥抱 cloud。我一开始是这样想的，但是后来发现大错特错。

我觉得去做 cloud 有两个阶段：第一个阶段是 automatic deployment（自动化部署），这是 DevOps 这个层面，是不是能拥抱这个云原生的 DevOps。这个特征就是你是不是提供了一个 Kubernetes operator 或者说最佳实践？但这是不够的。真正重要的拥抱 cloud 是：我的系统是不是针对云的基础设施作为假设来去设计的？我再稍微展开一点，当你做一个数据库的时候，比如说不管是 TiDB 还是 OceanBase，还是 Redis、MySQL，这些所有的东西其实全都叫做数据库软件。不管是单机的还是分布式的，它是一个软件。Kubernetes 只是怎么把他们部署在一个分布式环境里面，这是第一层。

但是如果我们的假设变成，我要去基于 cloud infrastructure 去设计一个数据库服务，那我就不用去考虑，举个例子，我的存储我就一定不会用磁盘，因为我知道我一定是在云上，我在做一个云服务，我一定会基于对象存储，或者说我在云上的这些东西来做。

第二个，做这个 software 我的第一假设就是：这一定是一个 multi-tenancy（多租户）的系统，它一定是多租户的，以及我的租户本身是虚拟的。我可能要设计 100 万个客户，我不可能给 100 万个客户每个人都提供 3 个副本、3 个节点上来，这样我肯定也付不起这个成本，用户也用得不爽。所以你一定会把你的 system 变成一个一切东西都是 microservice（微服务）。

所以，这两个是完全不一样的设计 system 的思路。我指的 cloud 那个决定是更像是后面那个。前面的那个，如果只是 Kubernetes 的话，我甚至觉得我当时做了一个非常错误的决定，就是因为那时候我对 cloud 的理解是非常不深的。

jiang： 你觉得云计算现在在一个怎样的发展阶段？

黄东旭： 我觉得发展阶段就是，我们现在已经看云，不是在看一台 VM（虚拟机）了。云计算的早期阶段的范式，是IDC（数据中心）的范式，只是云托管了一堆服务器。我只是不用去关心那个 Linux box 在什么地方，但是我看到的还是个 Linux box，这是早期。

但我觉得现在很多使用云的用户，他已经不再是关注 VM 的这个 level 了。以 Vercel 为例，你用 Vercel 去托管自己的服务的时候，你其实完全不知道 Vercel 的服务器在哪，也不会说 Vercel 你给我去买一台服务器，但是我要的就是我的 code 你能帮我托管起来，能要 scale 的时候你帮我 scale 上去。

我觉得现在云计算到达了一个阶段，就是从原来的 IaaS 层慢慢地变成各个层次的 PaaS，已经足够成熟可以去让这种新一代的像我这样的第三方的服务提供方基于此构建。我对 S3（对象存储）的假设就是：“容量近似无穷大”，我也无需关心底层需要多少台机器，100 台、1000 台都无所谓，我看到并依赖的是其 SLA（服务级别协议）、durability（持久性）、throughput（吞吐量）与 consistency（一致性）。我会把自己的系统构建在这些假设之上。如今无论 compute（计算）还是 storage（存储）都在加速 service‑ization（服务化）。

我觉得下一个阶段可能会更加抽象。现在我们可能看到的 compute 还是计算机代码，看到的 storage 还是 database、S3、block storage（块存储）。在下一个时代，大家有想过是什么吗？我觉得就是 agentic（智能体化）。它的接口会进一步的变得更加简单、抽象，目前看来自然语言会是一个抽象的终点。

jiang： 现在数据库行业是一个什么样的阶段？最近的事件像 Snowflake 和 Databricks 的收购，还有 Rockset 被 OpenAI 收购等等，我们可以看到一个怎样的趋势？

黄东旭： 我觉得过去的五年，整个数据库都属于一个非常无聊的时期，大家都在专注于赚钱。因为确实除了 cloud 本身带来的基础设施的范式变化以外，没有什么太多让我感到兴奋的东西。

但是今年不一样。我们先不说这个趋势怎么样，我们先说现在数据库有什么问题，我觉得数据库现在最大的问题就是它还是面向人设计的，面向程序员，像 SQL，Java，Python。还是一个需要你得去了解它，得去写程序，得去用它的 API（应用程序编程接口）。我非常痛恨 API 这个词，Application Programming Interface。现在数据库最大的问题在于它的使用者还是工程师。不管什么数据库，不论是 Snowflake 也好，Databricks 也好，还是 TiDB 也好， OceanBase 也好，它还是 SQL，还是编程接口。本质来说谁在编程？还是人在编程，这就是它最大的问题。可能有人会觉得很疯狂，但我觉得很快，AI agent 会占据 90%，可能甚至更高。我们去设计数据库的终端用户就不是人了，我不是在给人编程了，不是在给人去提供数据的接口和数据库了，应该是去给 AI 来设计这个接口。

有人会问，人去访问数据库跟 agent 访问数据库有什么区别？这两者的区别可太大了。我最近一直在做 agentic system，我发现 agent 使用数据库的方式真的跟人不一样。

最大的一个不一样是：以前我们写好的 data interface 都是静态的，比如说写个 RESTful 接口，背后封装一个 CRUD（创建、读取、更新、删除）。最多就是在这个模板里改一改像 user ID这些，但是大概的执行的 SQL，它还是那样。OLTP 这边这样，OLAP 的话，就是你做一个报表，你写一堆 SQL 很复杂，要去把这个 SQL 给在分布式环境下跑得很好，那 Snowflake、Databricks 都在干这些事情。本质上来说还是以 SQL 为主。

但我发现 agent 在使用数据库的方式很不一样。第一，它会有大量的临时数据，它有大量的这种实时的 query。比如说，我现在自己写了一个 prototype，我把所有的个人数据全都接入到自己的平台里，然后我告诉 AI，可以用 MCP（Model Context Protocol）来查询我的数据源，可以用 SQL，可以各种操作。比如说我要 agent 帮我看一下我最近 10 天的邮件里边有哪些是我必须要马上回复的——大概就是这种我用自然语言描述的需求，我的 AI agent 就会根据这个需求ad hoc（临时自治）地生成它要去访问数据的 SQL，甚至它写了一个 Python 程序去到我的系统里面去捞这个数据。而且这个数据它并不是向量化的。我们现在提到 AI database，大家下意识认为是 Vector database（向量数据库），但是这其实只占整个 AI data platform 的很小的一部分，它只是一种索引的方式。

在我的系统里面，我让我的 agent 可以写 SQL 来去查关系数据，去做全文检索，去做语义搜索，还可以去做知识图谱的 query。想要收到的一个 query 的结果，其实是多种数据源、多种的数据的表示方式、多种的数据类型组合出来得到的一个结果。

所以回答刚才的那个问题，未来数据库会怎么样？我来说下我的想法：第一，这个世界上就没有 SQL 了，未来的数据库的 interface，它一定是像现在 ChatGPT 一样，可以使用自然语言的，也可以直接从这个接口里面丢给它 JSON，丢给它关系数据，丢给它二进制，所有的 data 的格式它都能接受，它能够去根据你所给的 data 来决定应该用以什么样的方式来存储。

第一个接口叫做 save，或者说叫 memorize，就是存储。存储是一个灵活的 API，可存储自然语言。第二个接口叫做 chat，或者叫 query，我可以问任何关于我的 data 的问题，它可以是一条SQL，可以是一个自然语言，也可以是任何的非常灵活的接口。所以数据库就有这两个接口。它背后会有一堆的MCP tools的连接，它可以操作data，可以变成知识图谱，可以向量化，也可以变成全文检索，也可以 SQL。只是说这些东西都会隐藏，变成背后的 agent 的 tools。这是我对 data infra 的接口的变化的一个大的判断。时间关系我不展开更多了，但是在这个方向其实你可以得到非常多的有趣的推论。

jiang： 那会不会有 MCP 原生的数据库？

黄东旭： 我觉得 MCP 可能还更在于这个 tool 这一层，其实只要把能力变成 MCP 暴露给大模型就够了。我的倾向是在 MCP 这边，可以提供更多工具，这些 tools 可能很复杂，也可能很简单。比如说我可以给它一个 insert 的接口，query 的接口，knowledge graph building的接口等等。但这一部分它一定会被隐藏在一个 LLM（大语言模型）的agent之下。

jiang： 所以可能更重要是让 agent 能够直接查询数据库？相当于 agent 自己去构造 query，但同时这个 query 是可以对外开放的，像 GraphQL 那种。

黄东旭： 不要陷入到具体的 protocol，我觉得这个是 agent 决定的，或者是 LLM 决定的。我应该去给它更灵活的东西，我把所有的都给他，包括像文件系统、数据库、各种工具等，但是怎么用是应该是由这个大模型决定的。所以我并不把 PingCAP 定位成一个数据库公司，比如我现在做的这个 agent 的 platform 里只有文件系统的接口。

jiang： 说到 AI，现在你在硅谷感受如何。我 5 月底到 6 月上旬也在湾区，觉得今年跟去年去比起来很不一样，AI 这个主题真的非常热。

黄东旭： 完全正确。我觉得这一波肯定是一个很大的窗口。说点跟技术无关的，第一，现在整个美国是在一个降息的预期里边，我觉得这是对创业者是有好处的，因为热钱会变多。这也很好理解，比如说前几年美国的利率高于 4%，那人们什么都不干，100 万美金存银行，一年的利息就挺多的。但现在降息意味着大家认为反正存银行收益没那么高了，那应该投资点什么，投资的选择就一定是投资在处于炒作期的技术，就是 AI。像扎克伯格拿 1 亿美金去挖工程师，这种事情是不可持续的。但这意味着整个技术一定是在上升期的，在上升期做事情有两个好处：第一，你不管做什么事情，你能获得的关注会变多。第二，你不管做什么事情，你会有更高的溢价。

比如说你现在创业，做数据库，你的估值绝对没有我 2021 年搞数据库的估值高，可能腰斩都不止，即使你做得跟我一样好。但是如果你是做 AI 的话，那这个时候可能 1000 万美金的收入能够让你做到不止 10 亿美金的估值。所以这个时候是非常好的融资创业，甚至把公司卖掉的时机。我觉得现在大家有个 idea，就必须得赶快做、快速做，因为这个大的经济的周期下，现在是一个很好的时机。

从技术层面来讲的话，反而我会更加冷静一点。现在这个时间，我可以有本钱做点研究，但是我自己觉得还不是全力以赴的时间。两个假设：

第一，虽然整个行业在一个特别高的阶段，但是我觉得这个成本可能还要下降一个数量级，才是一个真正能产生出一些有用东西的时刻。因为现在整个算力的成本还是太高，即使已经比起 2 年前下降了一个数量级了，但是我觉得未来可能两三年 AI 算力还会再下降一个数量级成本。所以如果你现在要去做基础建设可能不是一个特别好的时机。

第二，我觉得现在 AI 的从技术层面上来看，明显处于一个炒作阶段，是因为它并没有 to C 的应用出现，还没有迎来它的 iPhone moment，它可能还是在一个做点 to B 的生意的时间。

像 Cursor、Claude 等很多的 AI 应用，可能上来三个月实现 1 亿美金的 ARR（年度经常性收入），我觉得大家就当一个童话故事看一看就好了，也许是真的，但是这个我觉得从长远来看这是不可持续的。即使未来他们会很成功，但是未来他们的产品形态一定跟今天的产品形态绝对不一样。

从钱和功利的角度来说，在 AI 的领域里有很多钱、很多炒作，但从技术的角度来说，我觉得还不太成熟。这为什么我觉得我现在需要去布局做 research，因为我现在所有做的东西可能都是在为了未来三年以后的应用做 infrastructure 而准备。

jiang： 在 AI 工程、AI 产品方面，除了你现在做的数据库这块，有哪些是你觉得特别有意思的项目或者赛道？

黄东旭： 我个人觉得，首先 LL M这件事情跟我无关，我并不是搞 pre-training（预训练）这部分的，而且我也觉得未来这个东西没什么前途。如果你现在还在做 training 相关的基础设施，甚至做推理的基础设施，我觉得都不是一个很朝阳的产业。虽然这个东西很花钱，像 Meta 这样的公司也投了很多钱在干这个事，但是我觉得这些东西到最后一定会收敛成几个，模型本身不会有太多模型，所有的模型一定都会达到一个足够聪明的状态，而且它的成本极低。就有点像现在的水和电，未来智能会像插上墙壁的插座就有电流过来，LLM 的智能它是不值钱的。这是第一个假设。所有 pre-training 的这些模型可能火过一段时间，最终搞出一个比较强的基础模型以后，就变成了大厂的游戏了。有点像发电机一样，现在人们家里除了应急以外会有发电机吗？没有，就是一定是发电厂在发电，自来水也是。所以去研究打井技术是没有前途的，因为最后都是自来水。

但什么东西是在 AI 领域里有价值的？是 data 跟 context。一个模型再聪明，我觉得靠 reasoning model（推理模型）和 chain of thought（思维链）是达不到最终的智能的。真正的智能一定是从跟现实世界和外部世界做交互，在这种交互之间去得到反馈，去学习，才会将这个智能变成真正有用的东西。

所以我觉得 agent 这个事情是成立的，这也是行业共识，今年越来越多的公司开始做 AI agent 相关的事情。一是因为这个基础模型的能力，包括 O1、GPT-4o、DeepSeek，已经达到了够聪明能去做些有用之事的阶段，这是基础。

第二，大家也发现真正让 AI 去完成一件有用的事情，还是得去利用现在的用户的上下文，去把计划给做好。大家现在肯定都在用 Cursor、Claude Code，像 Claude Code，他会先给你做一个计划，然后帮你读文件，它并不是一次性的，跟早期这种 ChatGPT 这种 one-shot conversation（单轮对话）不一样，而是做一个 multi-agent、multi-LLM、multi-round orchestration（多智能体、多模型、多轮编排）的一个过程。

这里的“护城河”，在于如何组织 context、提供正确的上下文、访问正确的数据、保持 state（状态）的推进，以及让 AI 把 token 尽可能花在“更多状态探索”上。这些工程能力目前还在 LLM 侧，没被充分重视。我认为未来很关键的是：第一，search framework（搜索框架），即在多个状态下去探索的 framework。第二，state 的处理，多个 state 要怎么去高效的描述、压缩、存储。这块就是数据库要去想的问题，不能每次完成一个任务，都要把整个 state 复制 100 遍，这不合理。当然 branching（分支）只是最浅的状态管理。通用的搜索框架，state 的存储表示，以及 sandboxing（沙盒环境），这些可能是未来agent的很需要的基础设施。

Memory（记忆）只是刚才我说这套系统里边的一个非常小的模块。举个例子，我要让一个 AI 下棋，每一步可能有两种下法：一种是让这个 agent 在当前状态下选出一条最好的路径去走。另外一种比较聪明的 agent 可能是，现在有十种方案，可能感觉这三条路比较好，那么我就在这个三条路上再去探索一下。再举一个例子，比如现在大家用 Cursor 或者 Claude Code，是不是很多人在前几次给给了建议后都是接受，接受到最后发现这个东西好像也不是特别想要的，但也没办法了，因为它就是一层一层地只走了这条路径。那为什么不能是不要让用户接受所有环节，而是比如在 10 条情况下，每个情况 AI 都自己去继续尝试三五层，最后把这个结果给用户看，或者用户觉得不满意，选到某一个分支，AI 再继续从这个分支往下搞。这个是我觉得更好的做法。现在的问题是 AI 他选择了自己觉得最好的一条路径。但是我其实想要一个tree search（树搜索），这是很不一样的。但 tree search 的问题就是它会消耗可能比原来的方案的指数级别的 token 的消耗以及 state 的、storage 的消耗。但是基于我刚才的假设，算力免费，存储免费，当有这样的一个假设了以后，其实就应该去做 search 这个动作。

jiang： 你怎么看现在 AI 编码和 Cursor，还有最近大家都在用的 vibe coding 这些方向？

黄东旭： 我非常拥抱，我现在可能 90% 的代码都是AI写的。但我觉得可能还得更进一步。大家作为程序员，可能还有一个错觉，觉得 AI 是辅助我的，我还是主要写代码的这个人。但是其实我觉得这个其实就是 Cursor 现在的问题。我觉得 Cursor 虽然现在非常火，但说点反共识的东西，我觉得 Cursor 这个公司非常危险，就是因为他还是站在一个人类或者是程序员为中心的视角去设计产品，他的主体的产品还是一个 IDE（集成开发环境），还是在辅助程序员写代码。

大家反过来看 Claude Code，包括 Devin，我觉得挺好的。我用 Claude Code 用特别多， Claude Code 是完全站在 agent 或者说 AI 为主体的视角去做编程工具。这个区别就是人为主体，人是非常愚蠢的动物。虽然我是人，但是我的假设站在 AI 的视角，我会觉得对于编程的很多事情来说，AI 绝对做得比人好。人给它限制得越多，或者给它的输入越多，那反而是束缚了 AI 的手脚。

这里有一个非常微妙的区别，到底是以 AI 为中心的视角去设计产品，还是以程序员为中心设计产品。这是我觉得对 AI 编程工具里面一个最大的分类。我是坚决站在尽可能的去不要干扰 AI，尽可能让更多的代码是由 AI 生成的这个视角，我觉得这是未来的方向。

当代码产出能够 10 倍高效的时候，是不是应该去设计一些只有 10 倍程序员才能做的产品？未来数据库一定要比今天数据库好 10 倍，这才到及格线，而不是说今天拿着 AI 编程的东西，写一个 30 年前的程序，因为上限本身也提高了。但这么说，这个 10 倍的程序员现在是什么样子，我也不知道，只是说我觉得现在敢想可能是更重要的。

jiang： AI 编程项目的后续可维护性是怎么处理的？

黄东旭： 我在想“维护”的主语是谁？其实我多少是有点认同 Devin 的理念的，AI engineering  team 下，这个代码是 AI 写的，那 AI 就应该负责到底。所以当 AI 写的代码还要人去维护这件事情，本身我觉得就是错的。

只是说现在AI还没有把整个环节都打通，AI 写出了代码，人类拿去部署，然后要人类修复漏洞。但是你仔细想，你作为人，有没有想过给AI这个机会，让他自己去托管，让他自己去修漏洞，让他自己去维护，让他自己去发版本？但是 AI 现在非常愚蠢的，可能花在这个调教 AI 的时间还不够多，或者说这个 AI 的 agent 还不够聪明，这个是现实问题。

但我说的这个点是在于思维方式的变化。对于未来，我可能更倾向于 autonomous（自主）的这个方向。未来我会有更疯狂的想法，但我现在还没敢跟我的团队说。我现在的 research 团队还是人在写代码，AI 只是作为辅助，可能 90% 的代码是 AI 写的，人就是不断的接受、允许。但我觉得下一个阶段应该是什么呢？应该是所有的代码都在一个封闭的环境里，让AI自己来写。每一个人都是"产品经理"或者 AI 调教师。但是我也不知道未来可能某一个时间，我会不允许人写代码，这是我想做的事情。

提问者： 关于这个问题，我其实有一点想法。我觉得其实软件工程不管是人写还是AI写，归根结底要控制的是软件工程当中的熵，不管是人写、还是机器写都会写出奇奇怪怪的东西。所以实际上是我们面临的问题，可能是我们要设计一个工程系统，然后把所有的agent或者是人放在这个之上，来做这个工程的质量的控制，这其实并不是假设 A I变得非常聪明就可以解决的。因为即使非常聪明的人在一起，他们可能写出来的复杂系统也会比较混乱。

黄东旭： 从这个复杂度控制，从你刚刚提到的熵的控制的角度，人跟一个精心设计的 AI 系统或者计算机系统来说，人的上限是很有限的。软件工程发展这么多年，我觉得最后大家会发现，这个系统的最大短板其实是人，而人在控制复杂性这件事情上也就这样了。但我更看好AI在未来对这种复杂系统的理解，能够去控制这个熵增的潜力是更大的。