什么是 AI 架构师？ — Bret Taylor
以下内容整理自播客“Latent Space”最近的一期“The AI Architect — Bret Taylor”，邀请到了嘉宾是 Bret Taylor，是一位拥有传奇经历的 Sierra CEO、OpenAI 主席，以及 Google Maps / Facebook Likes 的缔造者，在节目中分享了他对软件工程未来的见解，以及在 AGI 曙光降临之际，如何打造优秀的产品和团队。内容比较长，但是值得认真看看，我对于一些有价值的内容已加粗，如果时间有限，也可以挑重点看看。
要介绍 Bret Taylor 这样的人，实在太难了。我们可以简单念一下他的维基百科页面，或者回顾他在硅谷众多顶尖公司的辉煌履历，但所有人都已经这样做过了。
作为一档由 AI 工程师为 AI 工程师打造的播客，这一次我们想尝试一些不同的内容。我们希望从过去 20 年来 Bret 一直身处行业顶端的视角，探讨他所观察到的趋势，以及这如何促成了他在 Sierra（领先的对话式 AI/CX 平台）推动 “AI 架构师” 这一新角色的兴起。
“在我们所有的客户群体中，我们看到一个全新的角色正在出现——AI 架构师。 这些领导者负责为公司定义、管理并随时间推移不断演进他们的 AI 智能体。他们可能来自技术背景，也可能来自商业背景。我们认为未来每个公司都会有一位或多位 AI 架构师，来管理他们的 AI 智能体 及相关体验。”
在访谈中，Bret Taylor 证实了 Paul Buchheit 那段广为流传的轶事：他曾在一个周末就重写了 Google Maps，只借助当时刚刚面世的 Google Closure Compiler，并未使用任何其他现代化工具。但更令人惊讶的是，当时他是 Google Maps 的产品经理（PM），而不是工程师，尽管他当然依旧认为自己是工程师。我们在 Bret 的职业生涯和世界观中反复看到了这一主题。很显然，在当下瞬息万变的时代，AI 领导力必须是动手且具备技术背景的：
“把产品、设计和工程融为一体且尽量由少数人负责，这会非常强大。因为，很少有伟大的事物真的是通过委员会做出来的。”
“如果工程只是按照产品的指示去执行，有时确实能做出有价值的东西，但要想创造出精雕细琢、真正突破性的产品，就比较罕见。那种产品往往由小团队打造，他们对需要解决的用户需求有深刻的理解，并且对成果有着近乎狂热的关注。”
“我觉得其中的原因是，如果你看看大约五年前的软件即服务（SaaS），也许把产品和工程分开还可以，因为当时大部分 SaaS 产品都不需要很多技术上的突破。比如你要做一款报销软件，它确实有用，我不是在贬低报销软件，但你基本上只需要搞清楚财务部门的需求、个人提交报销的需求，然后照着做就好了。你也知道 Web 应用大概该怎么实现，数据库怎么用，如何在 AWS 上自动扩容之类的，这些东西都是成熟的做法，只是用同样的方法再去解决另外一个问题而已。”
“可如果你面对的是早期的移动端开发，或早期的交互式 Web 应用（比如 Google Maps 和 Gmail），或者是如今的 AI 智能体，你会不断地与客户、利益相关者，以及所有和产品互动的人之间反复沟通需求，同时还要考虑技术本身的能力。”
这是我们第一次如此清晰地理解到，“普通” 软件与 “AI” 软件在技术领导力上存在的区别。未来我们会持续深思这一点。访谈里还有很多内容值得细品，所以我们希望你能和我们一起深入探讨（并感谢 Bret 做客我们的播客！）
嘉宾介绍
Alessio 00:02:05
大家好，欢迎收听 Latent Space 播客。我是 Alessio，Decibel Partners 的合伙人兼 CTO。和我一起的是我的联合主持人 swyx，smol.ai 的创始人。
swyx 00:02:17
大家好，今天我们非常高兴邀请到 Bret Taylor 做客。欢迎你，Bret。 谢谢邀请我来。能在这个录音室里见到你们，有点不真实的感觉。
swyx 00:02:25
多年来我一直在各种报道里读到你的事迹，甚至在 OpenAI 之前我就对你很熟悉了。我今天用 Google 地图来这里，真的非常感谢你所做的一切。你的经历非常丰富，人们可以很容易地发现你过去的“高光时刻”。
Bret Taylor 的早期教育和职业经历
swyx 00:02:40
通常在别人让你做自我介绍、总结你职业生涯的时候，你会怎么概括自己呢？你是如何看待自己的？
Bret 00:02:47
这是个好问题。刚才我们在开麦之前聊到，这个播客的受众更偏向工程领域。其实我会根据听众的不同，选择不同的介绍方式，因为我在职业生涯中有很多企业和董事会层面的经历。但如果只选一个身份，我更认同自己是名工程师。即使我在 Salesforce 工作时，周末也会写代码。所以我首先把自己看作工程师，然后我职业生涯中的所有角色也都从这个出发点开始，因为我感觉工程是一种思维模式，我对生活中的大部分事情都是用工程的思路去处理。我是个工程师，这就是我对自己的描述。
Bret 00:03:24
你在 1998 年开始学计算机科学？
swyx 00:03:25
对，我那会儿还在上高中呢？
Bret 00:03:28
实际上，我本科是 2002 年毕业，硕士是 2003 年。所以对，我有点“老”了。
swyx 00:03:33
我是说，从 1998 年到 2003 年那个阶段。那时“工程师”这个称谓还不像现在这样流行，也没有“高级工程师”之类的职级。可能只是“程序员”或者“开发者”。那你在斯坦福读书时是什么感觉？你会觉得当时正处在计算机革命的边缘吗，还是觉得这只是一门小众兴趣？
斯坦福和互联网泡沫
Bret 00:03:57
嗯，我在 1998 年到 2002 年就读于斯坦福。1998 年差不多是互联网泡沫的巅峰时期。那时候大家在机房里写代码，因为那里有 Sun Microsystems 的 Unix 服务器，我们大多数人都要在那里完成作业。几乎每天都有某个 .com 公司来给大家买披萨。
我头两年在大学里几乎没花过饭钱。然后在我大学生涯的中段，互联网泡沫就破灭了。所以等我快毕业的时候，就业招聘会简直冷冷清清，少有人问津。很难描述当时那种反差：在泡沫顶峰做计算机专业，机会多得数不清；到我毕业的时候，就只剩下微软、IBM 之类的公司了。
那时我只投了两个创业公司：VMware 和 Google。最后之所以选择去 Google，很大程度上是因为 Marissa Mayer。她曾经做过我当助教时的助教（我们叫 section leader，相当于大课助教下面更初级的助教），她去了 Google，也在招人。我认识她，觉得这样比较稳妥。当时其实没想太多，但结果证明这是个非常幸运的决定。事后想想，你当然会觉得如果能选，肯定会选 Google，但在那时大家并不知道 Google 会那么成功。
我也在想，如果我 1999 年毕业，会不会就跟我妈说，“我在 pets.com 找到工作了，挺好的”。只是当时没有那么多选择。
最后我就想，“去 VMware 做内核软件？还是去 Google 做搜索？”我就选了 Google。一半一半的机率吧，也不能真说就是一半一半。总之我感觉自己很幸运，因为那次经济下行迫使我进入了一个极好的公司，但在当时，也可以说是运气成分比较大。
Google 地图重写的故事
Alessio 00:05:47
有一个著名的故事，说你在收购了 Quest Maps（MapQuest）之后的一周，就把整个 Google Maps 给重写了。这个传说是真的吗？有没有被夸大？这个事情是怎么发生的？有没有什么细节是 Paul 之前没提到过的？
Bret 00:06:06
整体上说是大体真实的，但让我详细说说背景。实际上，当时我重写的是前端，不是后端。不过对 Google Maps 来说，前端部分其实是最难的。因为 Google Maps 当时大概是最早——或者说最早之一——真正意义上支持交互式的 Web 应用。Gmail 也很超前，但对普通非工程背景的人来说，Gmail 可能只是感觉“哦，速度很快嘛”，并没有看到它在交互方面的创新。而 Google Maps 因为可以拖拽地图、而且是图形界面的，所以让主流用户一下子感受到了不同。
swyx 00:06:41
当时的 MapQuest 之类的产品都是点上下左右箭头，然后等好几秒才出现新的地图吧？
Bret 00:06:44
对，就是上箭头、下箭头、左箭头、右箭头。每次地图只是一张图片。你点一下“左”，然后等几秒钟下一张图片才会出现。图像也特别小，因为在当时生成大幅地图需要的计算资源很昂贵。
所以 Google Maps 在这个层面上算是一次真正的创新。
故事是这样的：有家小公司叫 Where 2 Technologies，创始人是丹麦的兄弟俩 Lars 和 Jens Rasmussen。我和他们现在是非常要好的朋友。他们做了一个 Windows 应用叫 Expedition，地图效果非常好。2004 年左右，我们收购了他们的公司。当时做 Windows 桌面应用已经不算流行了，但他们对地图非常有热情。
我们当时做了一个本地搜索产品，类似黄页的形式，也不算太热门。想要继续在地图领域做大，所以就跟他们的团队对接。他们对地图很有激情，我们就说：“加入我们吧，一起把这个产品做起来。”
技术挑战和创新
Bret 00:07:42
事实证明，把它做成一个 Windows 应用这件事，是个巨大的优势，因为在原生应用里，你不会受到浏览器那么多的技术限制。那时还没有真正的互动式 Web 应用。这样一来，他们在 Windows 应用里对地图体验的要求就会更高，等到把它搬到浏览器时，也就为我们定下了相当高的质量标准。所以他们那些不走寻常路的技术选择反倒变成了宝贵的财富。我们花了很多时间去想：“怎么才能在浏览器里做一个可拖拽的交互式地图？”“怎么在用户拖动的时候按需加载新的地图切片？”
甚至包括一些非常底层的东西，比如当时最主流的浏览器是 IE（Internet Explorer），它一次只能从同一个域名并行加载两张图片。所以我们专门弄了几十个子域名来并行加载这些地图切片。很多类似的小技巧，如果你们感兴趣我可以多说一点。
swyx 00:08:44
这跟 HTTP 连接数限制有关，对吧？
Bret 00:08:46
对，IE 限制同域名最多只能同时下载两张图片。如果地图界面上需要加载 8 个或更多切片，那就会很慢。
所以我们必须想尽各种办法去绕过浏览器的限制。这就需要很多底层的功夫。我对浏览器的内部机制也比大多数人更了解。
但是到最后，整个代码里有不少“临时拼凑”的感觉。如果你做过那种“从 A 点到 B 点”还不知道怎么走的项目，就像一间房一间房地临时拼起来盖房子，最后在架构上就会比较混乱。
然后我们还收购了一个叫 Keyhole 的公司，它做了 Google Earth 这样一个独立的 Windows 应用，也很棒。而且我们因此获得了很多卫星影像的授权。到了 2005 年 8 月，我们又在 Google Maps 中加入了卫星图像。这使得代码库的复杂度更上一层楼。
之后我们想要兼容 Safari。当时还没有智能手机，Safari 只是 Mac 上一个刚起步的浏览器。结果发现我们原本做 Windows 应用时的一些技术选择，比如大量使用 XML、XSLT 之类的东西，都在 IE 中运行得还行，但在 Safari 上就支持不好。我们还得自己实现 XML 解析器，这就变得越来越混乱。
所以最初我们觉得这是一款优雅的应用，但后来大概有上百 KB 的 JavaScript 代码要加载（在当时这已经很大了），大家还普遍用着调制解调器（或者网速相对较慢）。所以加载变得很慢，代码库很脆弱。
我当时真是苦恼，就在一个周末把它全部重写了。那会儿“JSON”这个词还没被发明，大家都还在用 XML。其实我们当时用的东西严格来说就相当于 JSON，但是当时没有那个命名，我们只是说“把服务器返回的 JavaScript eval 一下”来解析数据。
所以我其实就是在一个周末喝了很多咖啡，把所有东西都重新写了一遍。也不是我有多么天才，而是当你已经知道所有需求和坑后，如果能从头再来就能做得很好。因为原先的大部分前端代码都是我写的，所以需求和功能我也都很熟悉。就这样，周末硬着头皮熬了下来。
后来 Paul（Gmail 的创始人，也跟我一起创业过）在一档播客里提到这件事，大家才都知道了。大体上那就是事实。我最骄傲的一点是，当我重写之后，Google Maps 整个应用在未压缩前端包大小只有 20 KB，Gzip 压缩后更小，比之前减少了 10 倍左右。
在 Google 这样面向大众的公司，速度提升对流量增长的影响非常大。代码变小、速度变快，就能明显提高使用率。在那种规模下，哪怕是一点速度上的提升都会带来很大的增长。
swyx 00:12:03
当时你们有什么现代化的工具吗？比如测试框架、编译器之类的？
Bret 00:12:07
其实也有一个。那就是 Google 内部的 Closure Compiler（现在开源了）。不知道现在还有没有人用。估计用得不多了。它现在已经有点被淘汰了。
不过在当时，它比大多数 JS 压缩工具要更强大，因为它不仅仅是做一些变量名替换和压缩，而是做更多编译层的优化。现在大家可能都用 ESBuild，因为它快，而且 Closure Compiler 用 Java 写的，比较慢。但当时我们就只有这个工具。
Web 应用程序的演变
Bret 00:12:39
那时候在 Google 内部，其实有不少团队都在做比较先进的 JavaScript 开发，只是外部世界还没怎么开始做。比方说 Google Suggest（Kevin Gibbs 领导的项目）是浏览器里最早实现的实时联想输入之一（即在搜索框中输入时出现提示）。现在这种功能随处可见，比如在搜索框里自动补全。
swyx 00:13:01
: ChatGPT 刚刚也加了这个功能，感觉像是转了一大圈又回来了。
Bret 00:13:03
是啊，现在这种交互已经变得很普遍。但当年那是 Kevin 的一个 20% 个人项目。然后 Gmail 那边，Paul 经常讲他当时也是出于自己的需求才做了更多客户端的交互，因为邮件是生产力工具，必须够快，他当时就是为了让它更快。
我们这边有了 Lars 和 Jens 的引导，也想把地图做得像原生 Windows 程序那样，可以拖拽，所以我们不仅仅是做了一个客户端-服务器的单页应用（类似现在所说的 SPA），还在前端实现了大量图形相关的交互。
当时我们也经常把 Firefox 搞崩溃，因为 Firefox 的文档对象模型就是针对文档设计的，而我们做的很多事情其实是“滥用”了这些接口。那时它的许多代码路径都还没针对我们这种用法进行优化。
不过那段时间真的很有趣。我们有编译器和工具来帮助压缩 JS 代码，内部也有非常棒的工程团队。所以 Closure Compiler 能做得好，也是因为它不是简单的正则替换，而是真正从编译器的角度去做。
此外，当时有一支后来变成 Chrome 团队的工程师——我不确定具体情况，但我相信 Google 应该是当时对 Firefox 贡献代码最多的公司之一。很多浏览器开发大牛都在 Google。每次我们把 Firefox 搞崩溃，就跑到楼上去找那些人，一起用调试器查看到底哪儿崩了。然后想办法在我们的 JS 里绕过这个问题。因为你不能直接改浏览器代码，浏览器发布迭代很慢。
总之，那个时候大家都在探索未知领域，很有意思。
至于当时我们称之为 Ajax——全称是 Asynchronous JavaScript and XML，其实你看这个名里还有 “XML”。那是因为当时我们用来在客户端发 HTTP 请求的对象叫 XMLHttpRequest。它是微软当年为了 Outlook Web Access 做的，和 XML 关系不大，只是当时 XML 非常流行，所以大家就这样命名了。而 JSON 则是后来慢慢出现并流行起来的。再加上各种在 JS 中开发大型应用的最佳实践也逐渐积累。那是 React 诞生之前的时代。
我觉得 React 带来了一个非常重要的概念飞跃。就像我在离开 Google 后做的第一个社交网络，前端还在用大量的 innerHTML 插入或拼接 DOM，想要实时更新很麻烦。直到有了 React，这种思路才发生了根本变化。
我非常喜欢那种“你看见了才觉得理所当然，但在没看见之前却没人想到”的概念性突破。我想我们在 AI 智能体上也会经历类似的过程。现在我们还缺少一些核心抽象。十年后我们肯定会说：“天哪，之前我们怎么能那样做 AI 智能体呢？”就像当年做早期的单页应用时遇到的各种麻烦一样。
swyx 00:16:22
对，确实也有很多团队在做类似“AI 领域的 React”，但还没有明显的胜者。我觉得你刚才讲了太多精彩的内容，我们其实还可以展开很多话题。你刚才说的每一点都挺值得深挖的……
产品管理与工程协同
swyx 00:16:32
我注意到一件事，我觉得早期的 Google 时代在 PM（产品经理）和工程师之间有一种有趣的融合。我想你就是这样，你并不会等着 PM 告诉你，“这是我的 PRD。”
swyx 00:16:42
这是我的需求。
mix 00:16:44
哦，
Bret 00:16:44
好的。
swyx 00:16:45
技术上来说我并不是一名软件工程师。我是说，
Bret 00:16:48
当然，从头衔上看是这样。对，对，对。
swyx 00:16:51
这更像是一种混合。我觉得现在，产品已经成了一门独立的学科，也有自己的知识体系和行业，而工程则是另一个体系。两者之间有一套流程，它们往往被分开，但如果这两者由同一个人来做，产品往往会更好。
swyx 00:17:06
我想知道，你怎么想？在对比早期的 Google 和你现在看到的一些现代初创公司时，你是否也有同样的感受？
Bret 00:17:16
我自己确实会身兼多职，所以也许我有点偏见。不过我确实同意，**把产品、设计和工程融为一体且尽量由少数人负责，这会非常强大。**因为，很少有伟大的事物真的是通过委员会做出来的。于是——
如果工程只是按照产品的指示去执行，有时确实能做出有价值的东西，但要想创造出精雕细琢、真正突破性的产品，就比较罕见。那种产品往往由小团队打造，他们对需要解决的用户需求有深刻的理解，并且对成果有着近乎狂热的关注。
我觉得其中的原因是，如果你看看大约五年前的软件即服务（SaaS），也许把产品和工程分开还可以，因为当时大部分 SaaS 产品都不需要很多技术上的突破。比如你要做一款报销软件，它确实有用，我不是在贬低报销软件，但你基本上只需要搞清楚财务部门的需求、个人提交报销的需求，然后照着做就好了。你也知道 Web 应用大概该怎么实现，数据库怎么用，如何在 AWS 上自动扩容之类的，这些东西都是成熟的做法，只是用同样的方法再去解决另外一个问题而已。
可如果你面对的是早期的移动端开发，或早期的交互式 Web 应用（比如 Google Maps 和 Gmail），或者是如今的 AI 智能体，你会不断地与客户、利益相关者，以及所有和产品互动的人之间反复沟通需求，同时还要考虑技术本身的能力。
当你并不确定技术限制在哪里时，就很难提前把产品需求写死。这也是我用“对话”这个词的原因，当然这里并不是字面意义上的对话——在当下这个对话式 AI 时代用这个词也挺有意思。你会不断地想：“理想情况下，我们能不能撒点神奇的 AI 粉，来解决所有问题？”但事实并非如此，最后你往往会发现一些典型例子。
AI 智能体 与现代工具
Bret 00:19:26
我想大多数人在听节目的时候可能会用 Copilot 来写代码，比如 Cursor、Devon、微软的 Copilot 等等。这些工具确实很了不起，我现在都无法想象没有它们会怎样写代码。不过它们还做不到自动自治。我不会让它们自动写大部分代码而不进行交互式的审查。我们现在的状态更像是介于“很棒的协作助手”与“自动化的软件工程师”之间。
Bret 00:19:53
作为产品经理，你当然会有对产品的种种想法。但如果你是一个产品经理，你也许会说：“它应该是自动的。我只要点一下按钮，就能得到成品程序。”然而，这种需求本身并不重要。真正重要的是：根据技术非常微妙的局限性，它到底能做到什么？然后我们该如何最大化它对软件工程团队的帮助？再考虑到这些微妙的限制正在以我记忆里最快的速度演变——大概每几个月就会出现新的模型和新能力。
Bret 00:20:34
那么，你要怎么构建产品，才能以同样快的速度吸收这些新能力？这就**需要技术深度和对用户的理解紧密结合。**所以我觉得，这也是为什么每当大技术浪潮出现时，初创公司往往更占优势，因为它们通常更能将这些职能紧密结合在一起。
Bret 00:21:00
尤其对于创业者来说，如果你是所谓的全栈工程师，你也会很有优势。因为我认为大部分突破之所以出现，是因为有人既能理解非常细微的技术取舍，又拥有对产品的远景想法。而在搭建产品的过程中，你会和技术进行我之前所说的那种“比喻性的对话”——比如说，“哎，我没料到在这里会遇到技术上的极限，那我也许不只是改一两个功能，我可能得重构整个产品架构。”我觉得眼下尤其如此。所以说，如果你要构建一个大型 ERP 系统，可能确实存在把产品和工程分开的合理性。总的来说，这些职能各有其道理。但当你所处理的技术像大语言模型这样微妙时，把产品、设计和工程在组织层面进行更紧密的整合就会更有优势。
Alessio 00:22:05
说得非常有道理。我过去带过不少工程团队，我觉得**产品和工程之间的冲突往往更多是关于工作量的争议，而不是功能能不能做出来。**不过确实，你能看到，如今很多时候模型真的做不到某些事。我觉得最有趣的是，在初创公司里，人们并不知道 AI 的价值最终会落在哪里，所以现在很多人都在做各种框架、基础设施堆叠的东西，但其实还不清楚未来的计算形态会是什么样。我想知道你们在 Sierra 是怎么思考内部构建大量的评估工具，或者你们在搭建智能体等方面的做法？同时，你觉得这个市场里还存在哪些初创机会？
Bret 00:22:46
我们在 Sierra 里大部分工具都是自己做的，但并不是抱着“自己发明轮子更好”的心态（尽管可能有一点），主要是因为我们想打造一个经久不衰的平台，想对自己的命运有更多掌控。你刚刚提到的，比如说我们还没确立所谓的“反应式智能体”最终会是什么形态，我倒是认为它们还没真正出现过。我并不觉得这是要等评判结果——我们现在大概还处在智能体的 “jQuery 时代”，离“React 时代”还有距离。
swyx 00:23:19
我觉得也不该太着急，是吧？
Bret 00:23:23
对，这正是我的观点。我们想要把 Sierra 打造成能传承下去的公司，所以不想把自己的马车系在那匹还不确定的马身上。简单来说，我们作为一家公司，就是帮助消费品品牌构建面向消费者的 AI 智能体。从 Sonos 到 ADT Home Security、Sirius XM 等等，如果你给他们打电话，接线的就可能是一个 AI；或者你去 Sirius XM 官网对话，那个叫 Harmony 的 AI 智能体 就是基于我们平台搭建的。我们想深入探讨，为了构建一个完整的、面向客户的对话式 AI 体验，到底需要哪些要素？我们如何取舍：什么时候用微调？什么时候把模型串起来？什么时候使用推理，什么时候使用生成？怎么进行推理？如何为智能体设置边界？如何在天生不确定的技术上实现确定性？这里的设计空间特别大。
我可以现在就告诉你我们平台最好，但任何创业者都会这么说（笑）。我倒是希望两年后再看，我们能觉得现在的想法还不够成熟，因为这个领域变化非常快。谈到初创的机会，我并不完全否定工具型公司，但我保持谨慎。肯定也会有例外。我相信在预训练大模型层面是有很大市场的，但更多属于那些拥有巨大 CapEx（资本开支）预算的公司，比如 OpenAI、微软、Anthropic、AWS、谷歌云、xAI 这些——它们资本非常雄厚。如果你想靠预训练基础模型赚钱，竞争就会非常激烈，因为你面对的对手可以投入大量资金，就像现在的云基础设施市场一样，大概率会被那些大公司把持。
我也非常看好 AI 的应用。我说的并不是搭建智能体之类的，而是真正去解决某个业务痛点。比如 Harvey 在法律领域做的事情，Cursor 在软件工程领域的帮助，或者我们自己在客户体验和客服领域的做法。
因为在 AI 时代，软件能真正地完成一项工作，这跟两年前软件的概念并不一样。所以，为某个领域提供的解决方案也会和过去不一样。这意味着传统玩家是否就有优势其实还不一定。当然，它们有些东西会更完善，但形态已经完全不同，而且价值非常大。
举个例子，**Cursor 给工程团队带来的效率提升，或者说帮他们带来的收入增长，这很可观。**反观在工具型产品这边，确实比较难做。如果你回看云市场，也能发现很多有趣的工具公司，比如 Confluent（做 Kafka 商业化）、Snowflake、Hortonworks 等等。它们中很多都采用了开源或者开源核心（open core）等模式。我对这块不是很精通，但我知道开发者的选择往往比较多变。
在工具领域，我往往倾向于认为开源会成为主流。要完全靠工具赚钱会有些挑战，然后就会出现一些围绕开源模式建立公司的案例，这当然是可行的。但现在工具的更新换代太快了，所以我并不是说我对工具公司彻底悲观，而是觉得大概率开源会占主导。再加上在预训练大模型方面需要投入的资本实在太大，估计也会被少数大公司垄断。
接着我还非常相信**那些专注特定垂直领域的智能体，会成为 AI 时代的“软件即服务（SaaS）”形式。如果对比云计算，你可以自己去租一台服务器，这就像是最基础的原语；但你也可以直接用 Shopify 这样的成品。大部分人要搭建一个电商网站，会更倾向于 Shopify，而不是从零开始做。我认为 AI 也会出现类似的情况。所以我一般会建议那些问我意见的创业者，“多往上走，往用户的真正需求那里去靠。”**这并不代表我对“反应式智能体”的探索不感兴趣，因为那确实是一个重要问题，只是我觉得它大概率会先在开源社区里发酵。
swyx 00:28:21
是的，而且这并不是你们的首要任务。这里涉及很多东西。我挺好奇你对“点子迷宫”（idea maze）的看法。市面上有很多用户需求，你们选择了“客户体验”这个方向，但也有人会做编码助手之类的。我想知道的是，你是如何自上而下地审视这个世界，以及这些潜在需求空间的？因为也有很多聪明人，最后却选错了问题来解决。
Bret 00:28:47
这是个好问题。
软件开发的未来
Bret 00:28:48
顺便说一句，我也很想谈谈软件的未来，因为尽管我并没有从事编程工作，但我对那方面有很多想法。不过我可以先回答你的问题。你知道，**当有一项技术（比如大语言模型）非常酷的时候，就会出现很多人从技术出发，去寻找要解决的问题。**我认为这就是为什么你会看到很多工具类公司，因为作为一个软件工程师，你开始构建一个应用或演示时，你会遇到一些痛点，然后你会想，很多人都在经历同样的痛点。我要是做个工具会怎样？这就非常渐进式。你知道，我一直喜欢用一个比喻：你可以卖咖啡豆，烘焙咖啡豆，这当然会增加一些价值，你拿了生咖啡豆去烘焙，而烘焙过的咖啡豆基本上就是按照咖啡豆的成本定价。或者你可以卖拿铁，而拿铁的定价很少是直接和咖啡豆的价格挂钩的。事实上，如果你在机场买拿铁，那是个“圈地”环境，所以拿铁会非常贵。而这里面还有很多决定价格的因素，比如“在机场买一杯拿铁要花多少钱？”。
我举这个例子是因为从种植咖啡豆，到烘焙咖啡豆，到你可以自己在家做，或者你可以在机场买，这是一整条供应链。而机场里卖拿铁的公司利润率要远高于只做咖啡豆烘焙的公司。原因是他们在机场确实解决了一个旅客的“燃眉之急”，对此刻的旅客而言，这价值很高。 我也用同样的角度看待技术。
**如果你只是把大语言模型当作“咖啡豆”，然后在它之上卖一些工具，那么从某种意义上说，你的市场很大，但定价可能会被压缩，因为你只是一个基础设施的一部分，而且还要与开源和其他各种竞争。而如果你去真正地解决某个重要的商业问题，而 AI 又恰恰能帮上忙，那么企业会根据这个商业问题本身的价值来为你的方案定价。**因此我实际上觉得，人们应该多想想……
哦，你说这不公平。如果你正在找一个主意来创业，我是非常支持大家去尝试的，哪怕会失败。因为很多最棒的想法，起初都不被人看好。所以如果你对什么东西有激情，那就去做。我没有资格告诉任何人“不”，对吧？
……或者说 Gmail，像 Paul 当时……我不确定，现在很多都成了传说了，但是说 **Gmail 其实是 Paul 在很长一段时间里个人在用的内部邮件。然后有一个很有意思的说法，Paul 可能会发出一个链接，第一个评论是，“这个东西很棒，但要是能不是你的邮箱，而是我的邮箱就好了。”**我不知道这个故事是不是真的，但我好像在哪儿读到过。总之，“为自己解决问题”是一种做法，取决于你的目标是什么。如果你想做一个风险投资支持的公司，和只是想做一个“热爱项目”——那如果只是热爱项目，就去做呀，别听任何人。相反，如果你想创立一个可以长久发展的公司，那就去解决一个重要的商业问题。我还认为，在“AI 智能体”的世界里，软件行业正在转变，你不再只是帮助人们更高效，而是让 AI 真正自动化地完成任务。
这样一来，我认为可服务的市场空间会大大扩张，因为软件现在是真的可以做事了，可以完成任务。自动补全代码的价值是多少？相当可观。但如果有一天我们真的拥有了可以写代码并交付给你的软件智能体，那价值就会大得多。所以我会建议**大家先稍微抬头看看，不要完全埋头在大语言模型上，而是多想想经济层面的问题。用第一性原理去思考一下：经济中哪些领域最能受益于这种智能？哪些领域最容易吸收它？一个在这个行业里的智能体形态会是什么样？它的客户是谁？技术是否可行？我会从这些商业问题入手。我发现最好的公司往往是：他们有很棒的工程师，同时对一个市场也有很棒的洞察。**而后一个条件经常是很多人并不具备的，或者说他们光盯着技术看，结果就有点“捡了芝麻丢了西瓜”。
Alessio 00:33:02
你怎么看待把它做成某种形式的软件来卖，和把它做成更像“包裹劳务”（package labor）的模式？我感觉有些人在卖“包裹劳务”时，这种状态是无状态（stateless）的，比如你只是在输入点东西然后获得输出，那可能换谁做输出都可以，你对他们的依赖比较小。如果想想写代码的例子，如果没有一个 IDE，你只是输入一些提示词，然后就得到了一个应用程序，谁生成的其实没那么重要，你的粘性就不大。但像你们在做的这个平台，在后台需要客户把他们的文档放进来，然后有各种工作流程可以接入。你们是怎么划定界限的？是走到完全外包“这是你的客户支持团队”的模式，还是说“这是一个可搭建的 CRM 平台”？你们当时是怎么做这个选择的？
Bret 00:33:44
我觉得可以把这个问题拆成几个层面。首先是，**当我们说到智能体时，谁在用这个智能体？他们想用它做什么？**就拿“写代码”的智能体来举例好了，我稍后也会讲一下我们在做的 Sierra。 如果我们假设，某个可以产生软件的智能体到底是谁在买单？是软件工程经理？是软件工程师本人，然后把这个智能体当作是“实习生”？我不知道。我们会在接下来几年里逐渐摸索清楚：智能体生成的代码最后要不要开发者审阅？它有没有生成单元测试通过的代码？它是怎么保证满足需求的？诸如此类的问题都会慢慢出现，而这些需求最终会决定我们以什么产品形态和价格模式提供服务。现在整个行业也还没定下来，我觉得每个智能体都会有不同的模式。
至于我们自己的客户群体，我们采用的是 **“基于结果（outcome-based）”的定价模式。**也就是每当我们的 AI 智能体 成功解决一个问题、挽留一个客户之类的，我们都会按照事先约定的费率来收费。我们之所以这样做，是因为我们觉得这才是智能体应该有的定价方式。想想以前的云计算软件时代，浏览器的出现催生了通过浏览器交付的软件，比如 Salesforce，后来又出现了所谓的“软件即服务（SaaS）”——这既是一种技术交付模式，又是一种商业模式，让你用订阅费代替以前的一次性永久授权。它们在某种程度上是正交的，但又互相关联。浏览器端运行的软件，如果你让客户买断授权，谁来负担中间的维护和更新呢？所以最终就催生了订阅模式。结果连 Adobe Photoshop 现在都变成了订阅制，这种商业模式的转变有时会带来比技术本身更深远的影响。
而针对智能体，因为它能真正完成一项工作，所以我不觉得我们会用那种付费来“享用软件本身”的模式。比如那个“写代码”的智能体，如果它写出来的代码很差，你就会想“把它炒掉”吧？对吧？如果只是“你可以使用这个软件”的许可，那就有点怪了。我的观点是，你只应该为“做好了的工作”付费。毕竟我们给软件工程师发工资也是为了他们能把事情做好，而不是按键盘输入的字节数付费，不是吗？
我知道这不完全一样，因为工程师有固定工资，还会有期权，分几年来归属。是的，这确实是个例子。但我的意思是，**你不会因为某个工程师写的代码行数多而付更多钱，那就有点像按 token 数量或者按 token 来付费。**还有苹果公司那个经典故事：**他们想看某个工程师一天写了多少行代码，结果那人拿出一个负数，说他只是在做一个大规模重构，把很多东西删了，这就讽刺了管理层对软件的不了解。**所以我觉得以前我们那些基于使用量或者席位数量的模式，放在“智能体真正完成某项工作”这个角度上，就显得很过时。因为就像问你的软件工程师今天写了多少行代码一样——谁在乎啊？这跟结果没有直接关系，而且还会导致 AI 出现奇怪的激励，比如智能体会去写又长又罗嗦的函数。
所以我总体觉得，**随着智能体真正能完成工作，我们会看到软件商业模式逐渐往“基于结果”转变，而在交付模式上也会有变化。**拿我们和客户的合作举例，我们要让客户真正掌控智能体的行为和内容，这对他们很重要。但是他们的角色也变了——很多客户团队原先叫“客户体验运营（customer experience operations）”，但现在改称自己是“AI 架构师（AI architects）”，我觉得这很酷。就像互联网早期有“Webmaster”一样，这个词现在已经过时了，也没有这个岗位了，我不确定“AI 架构师”这个称呼是否能流行下去，但确实反映了角色的变化。
对于在座所有软件工程师，我也会想，那个可以生成代码的智能体要怎么和人配合？就像我在圣诞节前写的那篇博文，探讨了软件开发的未来。有一点很有意思：就拿我现在在用的 Cursor 来举例，它其实是一个重新封装过的 Visual Studio Code 环境，我有时会使用它的一些智能体功能，但主要还是在进行代码自动补全。通过一定的参数或提示技巧，我可以让它按我想要的方式写出自动补全的代码。可是一想到它实际上能写代码，我就会想：编程环境的未来会是什么样子呢？
我觉得把这些智能体放在一个像 VS Code 这样以“单文件编辑”为中心的形态里，有点奇怪。就像你开 Waymo 的自动驾驶车，车里明明没有人坐在驾驶座，可是方向盘还在那里，而且会自动转动。将来如果自动驾驶普及了，为什么还要方向盘呢？为什么乘客的座位还要都面向前方呢？也许为了防止晕车会这样设计，但其实整个车可以完全重新安排嘛。现在很多车的结构都是围绕司机而设计的，所以**当智能体真正能够自动写代码的时候，还要在 VS Code 里打开一个源文件，然后你看它写，感觉就像是“我们还留了个方向盘在那里”。**所以这就会引发一个问题：人和生成代码的智能体到底是什么关系？
在我们所处的客户体验行业里也是类似情况：谁在管理这个智能体？他们需要什么样的工具？肯定需要工具，但这些工具和我们之前手动培训客服团队时用的工具会非常不同。回到软件工程师这个话题，我特别希望看到在编程语言层面的一些创新。因为我们现在实际上把“写代码的成本”降到了几乎为零。那我们为什么还要用人性化的、易于手写的 Python 呢？Python 并不安全，性能也不高。而我更希望看到的，是如何利用 AI 来验证程序的正确性。我在大学里学过一些形式化验证（formal verification），虽然当时这还是个比较冷门的领域，因为它效率很低而且实现起来很复杂。但现在如果大量代码是机器写的，最大的人力价值就在于“确定”它真的符合预期。
我觉得在软件开发流程的各个环节，比如测试方面，可能会出现很多有趣的创新。因为如果我们必须人工检查每一行机器生成的代码，那就限制了机器的产出速度。但如果完全不检查，又会有巨大的风险。我觉得最理想的情况，是**有一套真正面向 AI 生成软件的流水线，让我们确保它的可靠性。**这会是个巨大的机会。比如把所有的 C 代码都用 Rust 重写，提高安全性，减少安全漏洞。**如果我们可以让机器写出的代码即高效又安全，而我们只需要做一次快速验证，那就太棒了。我觉得这是一个非常值得期待的未来。我认为现在对自动补全的关注其实有点目光短浅，包括我自己也常用这些功能。但是我希望能看到一些更大胆的想法。**你提到“React 对应的新东西”之类的，我想我们还远远没到顶峰。当然，这个领域发展很快，我觉得我们确实在走出当前这个局限的状态。
Alessio 00:41:00
在 2023 年底，我写过一篇博文，叫《从语法到语义》（From Syntax to Semantics）。你想想 Python，其实就是在 C 语言的基础上增加了更多语义层面上的便利。LLM 则几乎把“语义编程”发挥到极致——你只要和它对话，它就能帮你生成任何语言的语法。但问题是，现有的语言都是为人而设计的，不是为模型设计的。可只要还需要人来审阅或干预，语言就必须保留人类可读性。我的疑问是：到底要等自动化发展到什么阶段，我们才敢去改动底层语言？还是我们一直要用 Python，因为人类容易理解 Python，而人类才是最后做决策的那个。但我觉得这个会变，我只是不了解需要两年、五年还是更久的时间。
我觉得其实很微妙，像现在比较有意思的是，一些更先进的语言会把语义融合到语法里来。我不是太确信，但至少 Rust 做到了内存安全，而且是静态的，这里有很多概念性的东西。所以它确实难写，很多人就会退回去写 Python。但 Rust 程序一般更加安全、高效……
我们之前邀请了 Chris Lattner 来做节目，他在做 Modular，把 Rust 和 Python 结合在一起，把 LLVm 之类的都整合进去，基本上就是想让 Python 有 Rust 的安全和速度，这其实也很酷，但对于他们来说，要兼容 Python 就是为了那些数据科学和机器学习的人群。然后……
我不知道**什么时候会出现真正彻底面向 AI 的语言，而不是在 Python 上打补丁。**你怎么看？
Bret 00:43:13
我觉得情况可能更复杂一点。一些更有意思的编程语言，会把语义“写死”在语法里。我的意思是 Rust 的内存安全是静态保证的，这非常有意思，但这也是为什么 Rust 写起来没那么轻松，为什么人们依旧会选择写 Python。可 Rust 程序确实比 Python 程序更安全、更快一些，当然编译时间更长。不过，如果真的不需要在意人工成本的话，Rust 理论上是更好的，因为它在安全性和性能上都有优势。就算你做一个 Web 服务，用 Rust 来写会更安全、更省成本，因为它是静态分析的，不容易在运行时出问题。我的理解是，Rust 是 Mozilla 团队为了浏览器安全和性能开发的。他们宁可在写程序的时候多花点功夫，也要确保在运行时更少出错。
反观**今天的编程语言，多数都是为了“让人类写起来更方便”而设计的。**但当我们进入 “由 AI 生成代码，再由人来验证和审查”的时代，也许就该思考一下：为了让 AI 生成的代码更容易被机器或人自动验证安全和正确性，我们是否需要一套全新的编程系统？我之所以提到 Rust，就是因为它是一个恰好的例子。要是在 C 和 Rust 之间选，我想现在很多人都会选 Rust，因为 C 明显更容易出现安全漏洞。如果 AI 帮你写代码，你就不必自己写 Rust 的那些“麻烦”了，那你为什么不选一个更安全更高效的语言呢？
另外一个问题是：如果我问你“这个 Rust 程序在内存管理上是不是安全的？”，你可能都不用读代码，只要编译一下就知道大概率是安全的，这对依靠人工审阅来说简直是“降维打击”。所以这是一个非常初步的形式化验证的例子。而如果我们再让 AI 自己来检查 AI 写的代码，那就更有意思了。我会觉得，如果我们最终只能让 AI 来审 Python，那就太可惜了。因为我做过大规模的 Python 服务，运行成本是很高的，还要各种花式优化，比如 PyPy 之类的，才能勉强提升一点性能。它本身又缺乏真正的多线程能力，总之你会发现它要占用的资源很多。如果将来的大部分软件真的由机器来写，我们还停留在 Python 上，我会觉得这是一种局限。
所以我的理想是：我们能不能创造一种更“面向 AI”的编程语言，或者说编程系统，让我们用 AI 大规模地产出功能，然后通过更智能的验证手段来保证正确性，你不需要逐行阅读它的输出。就像我举的 Rust 的例子，你只要编译通过，就可以保证它基本在内存上是安全的。这是一个非常小的例子，但确实提供了某种编程语言能否帮助我们去实现这种更大规模、更安全的自动化。我不知道最终会是什么形态，但我觉得这是很酷的一件事。
所以我希望看到有更多人去创新，比如在编程语言、形式化验证、自动化代码审查、测试等方面，去打造一个“AI 原生”的开发流程，让大量由机器生成的代码可以被信任，而不必让人类去逐行审查。你说有一个控制台像《黑客帝国》里那样显示绿色的字符流，然后有个人在那儿当“操作员”就行了，我觉得那画面挺酷的。当然，这些都还需要时间，也需要更好的工具。现在能做的还比较有限，但是我希望我们能看到一些更大胆的尝试。如果所有智能体都只是在 Python 上做自动补全，那就太可惜了。毕竟 Python 30 年前就出现了，它是为人类而设计的语言。这种状态可能会在某些领域形成局部的最优解，但我认为最终会出现一套完全基于 AI 的方法，让我们开发软件的方式彻底改变。
swyx 00:47:42
那我逼你做个预测。Python 大概已经有 30 年历史了，那再过 30 年，你觉得 Rust 会不会比 Python 更流行？
Bret 00:47:46
我也不确定能不能称之为预测，但我想表达的是：**我希望在未来的某一天，我们能有一套真正面向 AI 的编程语言和系统，它和现在的主流编程语言没有太大关联（或者说不依赖于我们现在已有的一套东西）。因为多数编程语言都是在让人类更好写代码的时代发展出来的，但将来我们更多是让机器来写，人类只是来审阅和把关，那语言和工具也许应该从根本上重新设计。**再强调一遍，我并不是真要抨击 Python，但它确实是过去时代的产物，而我们正在进入一个全新的时代。
编程语言的演进
Bret 00:48:15
你知道的，有像 Haskell 这样的语言，它们是为并行等抽象概念而设计的。还有像 Python 这样的编程语言，它的设计初衷就是让编程非常容易，上承 Perl 和 Python 的传统，这也是为什么数据科学家会用它。
它可以，它有一个交互模式之类的东西。我很喜欢它，我是一个超级 Python 粉丝。所以尽管我对 Python 说了很多垃圾话，但其实我是个超级粉丝。我写的至少三家公司里，有两家是完全用 Python 写的。然后 C 语言诞生于 Unix 的发展过程。它不是第一个，但肯定是汇编语言之后最突出的一步，对吧？
你有了更高级的抽象，而不仅仅是 go to，还包括像 for 循环和 while 循环这样的抽象。
软件工程的未来
Bret 00:49:01
所以，我只是在想，如果写代码这件事不再是人类有意义的活动，也许是这样，也许不是。我只是说，它好像正变得不再那么重要了，但软件工程师这个角色仍然存在，也就是那个真正搭建系统的人。
对吧。那么，面向这种形态的编程系统会是什么样子呢？
React 与前端开发
Bret 00:49:25
我只是希望，就像我提到的，我还记得我在 Facebook 非常早期的时候，现在被称作 React 的东西就是在那时被创造出来的。我记得当它开源发布的时候，我已经离开那儿了，但我当时想：“这也太他妈酷了。”
比如说，把你的应用逻辑和数据流分离开来进行建模，让一切都更简单。然后现在……比如说前端软件的生态对我来说有点混乱，说实话。就好像是“抽象大杂烩”一样，但是其中一些核心理念真的很顺手。
我只是期待有一天，会有人做出一个编程系统，让我觉得既有“啊哈”的那种顿悟时刻，同时又让我感到完全陌生。因为他们是从第一性原理出发，认识到在编辑器里写代码也许已经不是编程系统存在的主要原因了。
我觉得，那一天对我来说会非常令人兴奋。
AI 在编程中的作用
swyx 00:50:28
是啊，可以说我们已经讨论过各种版本的这个话题，但归根到底，你仍然需要准确地表达你想要什么。作为一个管理者，一个曾经处理过很多法律合同的人，你也知道这有多难。
而现在我们还要对机器这样做，AI 要去揣测我们的意思，几乎要读懂我们的想法。我不知道该如何跨越把人类意图翻译成指令这道鸿沟。是的，指令可以更具声明性，但我不知道它是否真的能从编程语言跨越到别的层次。
Bret 00:51:00
我同意你的看法。而且如果你看一下法律合同就会发现，英文语言的模糊性就像系统的一个漏洞，里面有多少漏洞。
是啊。我确实认为，**当你在构建一个对任务至关重要的软件系统时，你应该避免用自然语言的提示来写，这种做法很可笑。因为你需要编程语言的精确性。**我的重点并不在这，而是在于，如果真正的“编写”这个动作……
软件的形式化验证
Bret 00:51:32
想想有些嵌入式系统确实会用形式化验证。我知道在安全协议领域，这已经很常见了，因为对正确性的要求非常高。
我的小小思想实验是：为什么不把它用在所有软件上？我知道，这听上去可能有点傻，毕竟把我们对这些底层安全协议做的事情照搬到所有地方也许并不切实际。我们之所以现在不这样做，只是因为它很难，又很费力。但如果“难”和“费力”都不再是阻碍的话……
你想想，你手机上那种最无聊的 App，让它进行正式验证可能听上去很可笑。因为你会想：“天啊，我为什么要花时间干这个？”但如果成本变成零呢？那好像也不错，毕竟它永远不会崩溃。为什么不呢？我就是想把标准设得很高：
我们应该去做，因为软件本身已经非常了不起了。就像马克·安德森写过一篇博文《软件正在吞噬世界》。我们的整个生活都在被数字化主宰，并且随着 AI 的发展，这种趋势只会越来越强。我们将有个人智能体跟各种各样的智能体交流，就像一个无穷递归一样，而我们的核心基础设施也都跑在这些数字系统上。
长久以来，我们一直缺少足够多的软件开发人员。而因此，我们也看到过一些后果，比如“医改网站（healthcare.gov）”的灾难，比如安全漏洞导致国家级行为体能够访问关键基础设施等等。
现在我们已经有了一个如此神奇的系统，我们完全可以修好它。我对提高生产力的想法非常兴奋，但我也认为，作为软件工程师，我们应该更大胆一些。我们应该有更高的目标，去真正修复这些系统，让它们在我们期望的范围内真正按规范运行。
我的话可能有点空泛，我们的确还需要一些配套的系统。但我觉得这应该是我们的目标，特别是当我们的生活在如此依赖这些数字基础设施时。
好的，说回你刚才说的东西，它的确是正确的。
规格说明的重要性
Bret 00:53:33
规格说明，这也许是我觉得 AI 智能体最有意思的部分。**大多数规格说明其实是不完整的。**我们回到产品工程的话题：
你说：“好，这里有一份 PRD（产品需求文档），里面有非常详细的线框图、流程说明，比如点这个按钮会怎样……” 但是百分之百你能想到这份文档里没有写的一些需求场景。假如你点了这个按钮，而网断了，那怎么办？
也许文档里就没写。你知道，**总会有各种各样的细节被遗漏，因为人很复杂。**然后最终会发生什么呢？对于一个传统的产品来说，你可以去量化一下它的实际功能里，有多大比例是由代码决定的，而不是由规格决定的？也许是 95%？可能更少或者更多。但无论如何，代码其实就是规格说明。
开源与隐性标准
Bret 00:54:29
这也是为什么，如果你看一下技术史，你会发现开源往往比纸面规格走得更远。以前有 W3C 的工作组来定义 HTML 规范，但自从 WebKit 开始流行之后，互联网的发展速度就加快了。这并不是在说标准化组织不好，而是说让一群人坐在那吵来吵去，还不如有人直接在代码里提交变更，这样你就马上能得到矢量图形之类的非常酷的新功能。
你知道，对于当年做 Google 地图的人来说，SVG 支持就能让他们的生活轻松很多。因为你不用再想办法在没有矢量图形的环境里画一条驾驶路线。总之，我们经历了一个从文档定义协议，到开源代码变成事实上的标准的过程。比如说 Linux 下的系统调用也是这样。
它的确有规范，比如 POSIX，但实际人们会直接针对内核编写程序，同时遵循文档里和文档外的一些行为。这些行为或好或坏都存在。这也是为什么 Linus 和其他人会如此坚持二进制兼容之类的问题——这些都很重要。
所以对一般来说，你说要和各种智能体一起工作，该如何设置这些“防护栏”？这是可以做到的。但那些没有指定的行为怎么办？像我们做软件工程的时候，你会遇到这样：你调用某个接口，返回一个错误码，你得处理它。
比如当网络断了，你要做点什么？可能你就会自己决定：“好吧，那就这样处理吧”，而不是去问产品经理“这个情况该怎么办？”要不然效率太低了。
如果是 AI 来帮你做这个决定，它并没有错，因为你没告诉它如何处理。**AI 智能体——这个“智能体（agent）”词本身就意味着它拥有“决策权（agency）”，所以它自己做了一个决定。**它会记录下来吗？大概不会，因为有那么多隐含的决策要做。
当你点击按钮时网络断线了，AI 做了些你不喜欢的事情。你怎么改？我觉得我们正走向一个新的世界：我们如何向 AI 智能体表达我们真正想要的东西？这个说明永远都是不完整的，而这也正是智能体的价值所在，它能在有一定推理能力的前提下帮你填补这些空白。
当你用它来构建一个应用——把它当成你的软件工程伙伴——一定会出现一个非常漫长的功能“长尾”，无限大可能有点夸张，但它的确会很长，而且肯定有一些功能你没在规格里写到。我们要如何微调它？
这就是我说需要一个新的编程系统的原因。我觉得我们现在还不知道那个系统是什么。而且同样地，如果是客服、法律或是软件工程领域的智能体——构建这些智能体的公司，本质上就是在建立一套系统，让人可以在里面表达他们希望的行为，包括各种细节。对吧？我觉得这是一个非常令人兴奋的领域，因为产品的精髓就会在于，怎样去应对、处理、迭代这些“空白处”。
这些都融入了系统的用户体验中。
swyx 00:57:58
我们不能只是说“好好写 Prompt 就行了”，对吧？
Bret 00:58:00
不，不可能。
因为那个 Prompt 会长得离谱。想象一下，有一个 PRD 把代码里所有行为都细写出来……那就还是代码本身了，对吧？
所以我想说的是，**Prompt 很好，但它并不能完整描述任何事物，它永远做不到。所以我们需要人机交互，需要有人在流程里决定什么时候该人工介入，这也是我相信“领域专用智能体”的原因。**因为在抽象层面去想这些问题可能很有意思，但它并不能真正解决具体问题。
你说 **“智能体”这个词究竟意味着什么？无非就是软件在帮你做决定，对吧？至少从简化的层面说是这样的。但如果回到“软件工程”这个场景，你就知道从需求到产品上线，再到用户反馈，是一个循环过程。**你可以想象如果有人做出一个产品来支持这种循环过程，该如何表达全部需求——包括你一开始知道的需求，以及后来在用的过程中发现的新需求，这两部分加起来才是你真正需要的。剩下的就交给 AI。
如果是法律领域，我也相信一定会有方法来解决“什么时候问，什么时候不用问”、“AI 错了怎么改”的问题。客户服务领域也很明确。我们自己也让客户审查所有对话，但如果对话数量以百万计，他们不可能逐条检查，所以我们需要帮助他们找出真正需要关注的少数。并且如果某些对话处理得不对，他们可以反馈，这样下次就会改正。我们还要知道 AI 当时为什么那么做。但最终判断什么是正确的，不是我们说了算，而是客户说了算。
所以我觉得，当**你考虑在某个领域构建智能体时，真正有价值的东西往往就是怎样把人的需求和行为注入进来。**对于我们做产品的人来说，这才是最大的挑战，也是最有创意的部分。
swyx 01:00:03
如果我问得有点烦，你可以打断我。但我确实想说一点：我有点难以理解你对“领域专用智能体”的信念，和“AGI（通用人工智能）真的会到来”的信念之间的关系。因为后者强调的是“通用性”。有一种看法是“苦涩的教训（the bitter lesson）”：我们总能在更领域化的层面上做出进步，但下一次突破一来，这些就又被推翻了。显然，你并不这么看，但你自己是怎么调和这两者的呢？
Bret 01:00:34
哇，这是个很沉重的问题。
AGI 对各行业的影响
Bret 01:00:36
你知道，我因为在 OpenAI 的角色会经常思考 AGI，但即便对我来说，真正去概念化它都很困难。
我也喜欢花时间和 OpenAI 的研究人员以及整个社区里的人聊天，一起讨论这些影响，因为有一些是第一层效应和影响，也有一些是第二层、第三层的效应，这些就更难预测了。
首先，我认为很可能的是，初期的 AGI 在数字领域会很强，因为它本身就是软件。所以如果你想，假设 AI 发现了一种新的药物疗法，那么其中的障碍可能不在于发现本身，而是在于临床试验。
而且 **AI 并不一定能帮助你做临床试验，对吧？那是一个和智能无关的流程，是一个物理过程。**同样的，如果你考虑气候变化或碳移除的问题，其中很大一部分需要好点子，但不管你想出的点子多么好，如果想要去封存那么多碳，就免不了有巨大物理层面的投入。
所以那并不完全受制于智能。也许 AI 能在某种程度上加速它，但也只是加速。经济学家 Tyler Cohen（泰勒·科恩）最近有一次很有意思的谈话，我看了他的视频，他说到**经济中有些部分确实把“智能”当作稀缺资源，那些部分会非常迅速地采用 AI 或 AGI，并带来不可思议的生产率提升。但也有其他部分并不是这样，而这些部分会相互影响。又回到那些复杂的二级影响，比如那些能快速吸收智能的行业价格会上涨，这反过来又会放慢别的部分的发展。**所以我觉得这不会是平均分布的，也不会像人们想象的那样在所有经济领域都那么快。我可能会错，但我确实觉得你可以从它在不同领域推理能力的角度去概括，这可能就是大多数人对 AGI 的定义，但它未必会在现实世界广泛适用，因为在很多行业里，智能并不是限制因素。
回到你那个更实际的问题：如果 AGI 要来了，那我们为什么还要做软件呢？也可以说“我们还需要学写代码吗？”
swyx 01:03:01
代码要不要学？
Bret 01:03:01
这是各种各样的版本。我个人看法是，我真把 AI（乃至 AGI）视为人类的工具。所以就我们之前聊的，**如果你是个软件开发者，你的工作是用编辑器写代码吗？我会说，不是。**就像上一代人的工作不是用打孔卡去打卡片一样——那并不是他们的工作。**他们的工作是产出某种“数字的东西”，无论它是什么，你编写软件的目的是什么，你的工作就是去产出那个东西。**所以我觉得我们的工作会迅速而且非常有意义地改变，但如果说我们的工作就是在编辑器里一行行打代码，那更像是一种工具落后的表现，而不是真正雇你来做的事——你是被雇来产出数字体验，为烤面包机做固件，或者别的什么。
我觉得因为这个原因，AGI 出来之后，肯定会让软件工程这个领域受到很大影响。我也可以说，也许在所有行业当中，它的影响都是非常大的，也可能比别的都大。但不管怎么说，软件工程肯定是受影响最深的学科之一。所以如果你在软件工程行业里，你只把自己定位在“我每天能在编辑器里敲多少行代码”上，那恐怕就不是什么能长期稳定立足的地方，因为 AI 当然比你更能做这件事。但你对于“要造什么、怎么造”这一判断力依然适用，这永远都是真实存在的。
可以用一个比较简化的方式来思考：对比一下初创公司和大公司。谷歌、亚马逊等公司有那么多工程师，而有些初创公司照样能胜出。为什么？他们做出了更好的决策，对吧？**并不是他们敲代码更快，或者代码更多，而是在正确的时间、正确的市场、用正确的方式做出了正确的东西。**同样，如果你看一些优秀的公司，它们的成功往往不是因为它们有什么独一无二的创意，当然也不排除有这样的，但更多还是很多其他层面的执行。所以总体上，海量智能的出现会改变很多东西，也会改变我们的工作，但它并不改变为什么数字技术在经济中存在的根本原因。
因此，我还是非常看好软件行业的未来。我觉得很多今天特别昂贵的东西将来会变得几乎免费。但这也意味着……我们必须承认，在我们这一代里，很多科技公司本来就活不长。我之前在一次谈话中举过这个例子，当我去谷歌时，我们还只在山景城的一栋楼里办公，后来才搬到一个园区（GooglePlex），而那个园区之前是 Silicon Graphics（硅谷图形公司，简称 SGI） 的园区。当时那是谷歌的第一个园区，我想现在还在用，可能现在已经有一大堆了，反正也还是那个地方。
SGI 当年也是特别大的公司，大到能有自己的园区，但后来就倒闭了，而且还没活多久，也不像 IBM 那样经历过很长岁月，而是我一生中看着它能有园区，又倒闭了。然后，我去 Facebook 的时候，我们在帕洛阿尔托的办公室——我去的时候并不是那个最初的小办公室，而是第二个办公地点，是斯坦福附近一个老的惠普大楼。后来我们做大了需要一个园区，就把 Sun Microsystems 的园区买了过来。Sun Microsystems 也是当年从斯坦福出来，一飞冲天，是那个互联网泡沫时代的宠儿，最后被甲骨文贱价买走了。所有这些公司，在我有生之年，都曾大到可以上市、拥有园区，最后又纷纷走向破产或被收购。
所以我觉得未来会有很大的变化。我并不是说这会很轻松，或者说任何人的商业模式都安然无恙，但数字技术重要的地位不会变。有没有创业者能有好的判断力，知道该怎么用这些技术创造经济价值，这一点依然是适用的。
我一直举的比方是，如果你回到 1980 年，向人们描述我们现在的很多工作，人家很难想象。比如说“我是一名播客主持人”，对方会不明白那是干什么的。那如果你回到 1776 年，去和本杰明·富兰克林说我们今天的经济形态，更是无法想象，更别说科技行业本身了，仅仅是服务经济就够颠覆了。他可能会问，“那谁来种粮食？” 因为对他来说，可能很难想象我们国家这么少的人就能为这么多人生产足够的粮食，这和他对农业是怎么运作的认识有巨大差异，估计得要花上好几个小时解释。
有点类似于现在，我们基于目前世界的制约条件来想象它的未来，但其实还有大量新的机会和事物会涌现。所以我觉得，写代码在现在确实非常重要，而且很快就会发生变化。大家需要保持足够的灵活性。我常打的比方是，**好比我们是一群会计师，而微软 Excel 刚刚问世。你是想当第一个放下 HP 计算器学 Excel 的人，因为这是更好的工具，还是想做那个死抱着计算尺和 HP 计算器不放，还在那儿说“这帮年轻人只会用 Excel，他们不懂行”的人？**虽然这个比方有点粗糙，但我觉得对大多数人来说，这是最好的姿态，就是拥抱变化，尝试这些工具。装上最新的代码助手，比如 0.3 版本什么的，真正去用它写点你本来不想写的代码。你可不想做那个最后才用上 Excel 的会计吧，那样你很可能丢了饭碗。
swyx 01:08:59
我们也有些个人问题，比如你怎么跟进 AI 的进展之类的。但我还想说，你刚才提的粮食这个比方真的很有意思，我和 Alessio 都非常有共鸣。我感觉我们确实就好像在用“以物易物”的形式交换“智力”，而现在突然进入了“智能工业化”。对我来说就像突然顿悟了一样。
Alessio 01:09:21
是啊，那你怎么看待“用一个智能体来替代某个人”以及“智能体之间的对话”？比如像在 Sierra 里，你现在就让人们跟智能体对话，但将来可能是智能体去抱怨订单给客服智能体，一路这样下去。而你之前在 Facebook 当 CTO 的时候，你们做了 Open Graph，我觉得它有很多好处，能实现很多东西，但后来也引发了很多负面影响。你认为我们在构建智能体协议（Agent protocols）时，应该怎么思考这些，比如隐私、数据、可发现性等等问题？
Bret 01:09:57
我觉得现在就要出现一种标准协议还为时过早。我也看过一些尝试，也许有的会被广泛采用吧。不过有一点很有趣，就是大语言模型因为是用人类语言训练出来的，所以它非常擅长使用我们设计给人类的接口。我现在的直觉是，因为我们能设计一个既适合人用、又适合 AI 用的接口，也许这就够了。
当然我也许会错。让机器和机器之间用某种人类无法读懂的协议，这当然有一些好处，但负面影响也不小。我记得好像是 Andrej Karpathy 说的，他说他的工作中一半时间都在写英语注释。我的直觉是，至少在相当长一段时间里，智能体和智能体之间还是会用自然语言交流。我不知道会不会一直这样，但短期内似乎有很多原因会让它一直维持这种形式。
那么，当你的个人智能体和 Sierra 的智能体对话，去解决为什么你的 Sonos 音箱一直闪橙灯时，我猜它们会先用英语对话。我觉得这其实也有好处。至于现在那些长时间运行的智能体还处于早期阶段，不知道你们有没有试过刚出来的 Deep Research 智能体……
swyx 01:11:22
我们给你做了一个呢。
Bret 01:11:25
真的啊。它让我第一次感受到 OpenAI 会在一件事完成之后通知我。我之前说过，我最感兴趣的是 AI 跟人交互的部分。因为多数“智能体工作流”其实都比较短暂，但我们在 Sierra 以及更广泛的领域会碰到那种多参与方、长时间、多系统的流程，我觉得这些会很有意思。我一直在举的例子是：在智能手机普及之前，互联网服务要通知你就只能发邮件给你，因为那时除了邮件也没什么法子。你在 Facebook 被人照片“@”了，就只能给你发邮件。后来，当每个人口袋里都有智能手机了，每个 App 都可以直接给你发通知，现在我用的大多数 App 都不会再给我发邮件提醒了，而是直接推送到手机上。
我也想知道，这种形态对智能体意味着什么？智能体要如何和别的智能体互相通知和召唤？然后它会在什么合适的时机把我们这些操作员拉入流程？我确实相信像 ChatGPT 之类的服务会成为主要的消费界面之一，它有很强大的用户基础。但如果你考虑那些特定领域的工作流，那里还要思考很多。所以比起智能体和智能体之间的协议，我更好奇的是它怎样恰当地把人整合进来，这才是我想多关注的。
我想起的核心问题是“角色访问控制（RBAC）”，比如这个智能体能不能访问这个数据？在客户服务里也许不那么明显，但在企业内部就会很突出。然后语言上，假设人不需要读取这些日志，智能体之间就能直接压缩对话，减少 token 消耗，速度更快。你之前说，你得到一个“Deep Research”通知，是不是意味着当 OpenAI 里“Deep Research”达成某个阶段，会给内部所有人发个通知，然后董事会就全部聚过来？能跟我们分享一下背后是什么流程吗？
**OpenAI 是一个使命驱动的非营利机构，我更多是把它当作一个研究实验室，虽然它不止这些。比如 ChatGPT 已经成为了当代文化中一个极具标志性的产品。但归根结底，它的使命是确保 AGI 能让全人类受益，所以我们董事会的大部分讨论都是关于研究和它对人类的影响，主要是安全问题。显然，如果你想造出 AGI，却不把安全放在首位，这是不行的。**当然也包括公平访问等别的问题。所以像 Deep Research 这种东西，我们肯定会聊，因为这是在讨论“造出 AGI”这一使命过程中非常重要的一环。我们也会讨论很多别的东西……
有时候我们会非常早地听到一些动向，有时候如果那和核心使命关系不大，我们就只做些随意的了解。但能听研究人员分享他们怎么看未来，以及通往 AGI 的下一个里程碑，我每次都很喜欢。
swyx 01:14:44
有很多里程碑，也许先从头说起。能说说你是怎么被卷进 OpenAI 的？很少有人去过你去过的那些房间。这个故事的开头是怎样的？大家怎么找到你的？你也可以聊一聊那场“闹剧”，如果你乐意的话。就带我们走进那个会议室吧，究竟发生了什么？
Bret 01:14:56
那是个……好像是周四还是周五，反正就是 Sam 被解雇的那天——对，是周五。大家都从社交媒体上知道他被解雇了，我也是，我还记得我当时在走路，看到新闻就惊了。
后来周六的时候，我为了保护当事人的隐私就不说太具体了，但我那天和 Adam D'Angelo 以及 Sam Altman 都取得了联系，让他们给我大致解释了一下状况。我的理解是——当然他们自己也许会有不同的表述——基本上就是，董事会和 Sam 都对我比较信任，但公司里的人对 Sam 被解雇非常反感，大家显然很愤怒，也完全不知道发生了什么。董事会当时陷入了一个困境，需要想办法找到出路。
结果我就被他们找来做了一个中间人，那时也不是正式授权，但实质上就是在充当调解角色。然后我也和 Sam 进行了很多交流。当时董事会也想找办法让 Sam 回去做 CEO，同时还想就之前发生的事情进行一次调查，好充分解决董事会之前的那些担忧。所以最后就走到了那个结局。
我想主要就是因为涉及的各方都认识我，也都信任我的操守吧，他们就想在这复杂情况下找到一个出路。我也因此和 Sam、Greg 建立了很好的关系，虽然对公司来说这是一次非常具挑战的时刻。我一开始并没打算进董事会，是因为这次危机才被拉进去的。我以后可能也不会一直待在董事会里。我加入的时候就发文说，我只是临时加入。我更想把精力放在 Sierra，但我真的非常在意这项使命，因为它实在是太了不起了。
应对高风险情况
swyx 01:17:15
我可能只经历过那种高风险场景大概两次，但显然都没有这么高的风险。不过，你在知道这是最高层级的自尊心、最高的赌注、最高金额，等等的情况下，你有什么原则吗？
面对这样的情况，你会带着哪些原则？很明显你有很好的声誉，也有很棒的人脉。那么，你觉得有哪些事情是“必须要做的”和“绝对不能做的”？
Bret 01:17:39
我不确定是否存在一本关于这些情况的“操作手册”，否则这类情况就会简单得多了。我通常还是回到我一贯的做事方式。
首先是基于第一性原理的思考。所以，我确实认为有一些危机应对手册，但在当时没有任何一件事和这种情况完全类似，你真的需要去理解究竟发生了什么，以及为什么会发生。我觉得很多危机时刻，从根本上来说都是“人”的问题。你当然可以去分析大家的动机、利益，以及各种各样的因素，但我认为非常重要的是要真正理解所有相关的人，以及是什么驱动他们、为什么这么做——这其实本质上是个“同理心”的练习。你是否真的明白了为什么他们要做这些事情？
**然后是要得到好的建议。我觉得在高关注度的危机中，大家都会抢着给你建议，所以你并不缺建议，但是好的建议往往需要具备真正的判断力。也就是说，这些建议来自哪些人？**基于对局势的第一性原理分析，基于对所有涉事人员的评估，这些人是否拥有真正的专业知识和良好的判断力，从而帮助你验证自己的直觉，或者在你不熟悉的领域（比如法律方面）提供你需要的世界顶尖水平的建议。我实际观察到，很多人往往会向错误的人寻求建议，而在这种环境里，找对人非常重要。
swyx 01:19:08
我觉得你在这件事里处理得非常好。我还有一个问题，之后我们就可以换个话题了。那个“微软收购”或者说让 Sam 和团队整体跳槽的提议，当时是真的吧？是那个周末某个时刻的真实选项，对吗？
Bret 01:19:19
我不太确定。我当时只是在其中一个视角里，其实挺有意思的，我自己并没有太多既得利益。我当时加入这个事情，我至今在 OpenAI 里也没有任何股权，只是一个对整个过程意义重大的旁观者。你刚才的问题也会提到这一点，但我之所以加入这个事件，纯粹是因为我在乎 OpenAI。
我离开 Salesforce 的工作后，刚好下个月 ChatGPT 就出来了，我和其他人一样都被“技术击中”了，心想：“我想把我的人生都投入到这个上面，这太不可思议了。” 如果不是因为 OpenAI 用 ChatGPT 激励了全世界，我不知道自己会不会再创办公司，或许也会，但不一定。总之，这确实给我，也给我们所有人都带来了很大的影响。
所以想到这个东西会在一个周末内土崩瓦解，我就非常难受。我对 OpenAI 的存在心怀感激，我猜很多竞争的研究机构也多少有类似的想法。就像，OpenAI 让人们看到了“潮起之时百舸争流”的景象，我觉得它为 AI 带来了所谓的“iPhone 时刻”，改变了世界。
当时牵涉了很多方面：微软是 OpenAI 的投资方，有既得利益；Sam 和 Greg 有他们的利益；员工们也有他们的利益。然后有很多幕后交易。我觉得你没法对决策进行 AB 测试，所以不知道如果事情真的破裂了会怎样，其实我也不清楚。你也不清楚哪些是真的，哪些不是。
所以这个问题还得去问他们才能知道微软的提议到底是不是真的。
swyx 01:21:03
你刚才提到顾问。听说 Brian Armstrong 在整个事件过程中对 Sam 的帮助特别大，这是……
Bret 01:21:10
据我所知，Brian Armstrong 和 Ron Conway 在那段时间都和 Sam 走得非常近。我也有跟他聊过，并试着跟董事会聊了很多，去做一些调停。你当然会有自己的立场，但我希望从外部角度来了解为什么会发生这样的事情。整个过程看上去至少可以说是——嗯，颇有争议。我尽量保持冷静客观，因为有一个原则是：如果你想把“碎掉的瓷器”重新拼起来，你不能只关注单一问题，得带着开放的心态去看。那是非常敏感的时刻。
不过对，我也认为 Brian 是最优秀的企业家之一，他在那段时间真是 Sam 的铁哥们儿，也给了很大支持。
swyx 01:21:55
他自己也经历过不少。之所以提到微软，是因为它显然是一个巨大的支持者。我们也和 David Juan 聊过，他当时把对 OpenAI 的首笔 10 亿美元投资方案推介给（微软 CEO）Satya。我的理解是，对微软来说，最理想的情况是：OpenAI 继续保持现状；次好情况就是微软“整体打包”收下 Sam 和 Greg 以及其他团队成员。当时双方关系很紧密，也是独家合作关系。现在的情况已经有点改变了。随着 Stargate 的发展，也有人对微软和 OpenAI 之间的关系产生疑虑或者说 FUD。我想就这个话题展开一下。
因为我们正在做一些事情，Satya 也订阅了我们 InSpace，我们想和他做个采访，了解一下如今这层关系是如何演变的。你会怎么描述微软和 OpenAI 之间的关系？
Bret 01:22:52
微软对 OpenAI 来说是最重要的合作伙伴。我们在很多层面上都和他们保持着非常紧密的合作关系。
我觉得它是一直在演进的，因为这个市场规模一直在增长，尤其是基础设施对资本的需求，比两年前要大得多，更不用说和微软刚开始合作的那时候相比了。那大概是六年前？我其实记不太清了。我应该能一下说出，但时间实在有点久了，在 AI 的世界里那已经算久远了。
我没什么特别可以分享的。我觉得关系在演进是因为市场在演进，但是合作的核心原则还是没变。对 OpenAI 来说，微软依然是最重要的合作伙伴。
swyx 01:23:36
我想再深入一点。其实我们很多听众都很关心 OpenAI 的优先级。我听说有人把 OpenAI 的最高级别目标分成五个：第一是保持前沿模型，永远做最前沿；第二是注重效率；第三是成为多模态领域的先行者，比如视频生成、实时语音之类。你会怎么概括 OpenAI 的核心优先级？当然，除了“让 AGI 出现” 这个最高目标以外。
Bret 01:24:02
其实我一直会回到你说的那个“AGI 最高目标”上去。OpenAI 是一个使命驱动的组织。很多公司会谈他们的使命，但是 OpenAI 真正是被使命所驱动，一切都围绕这个使命展开。
**如果你想预测 OpenAI 要往哪儿走，就要明白这一点：如果某件事情对使命没有帮助，它就不会是 OpenAI 的优先级。**OpenAI 的团队很大，所以偶尔也会出现一些项目，你后来会想：“这其实对使命没有太大帮助，那咱们就别做了。” 但最终来说，人们之所以在 OpenAI 工作，是因为他们相信 AGI 能给人类带来的益处。有人是因为想亲自构建它，写代码本身就很有智力挑战性；也有人想确保 AGI 是安全的。我觉得我们在 AGI 安全方面拥有全世界最好的团队。
这些模型一旦具有越来越强的能力，而且能够访问互联网、使用各种工具，就会出现很多非常有意思的研究议题。大家都对这个使命感兴趣。
因此，如果你看像 Deep Research 这一类工作，从使命角度看就非常合乎逻辑：如果你想创造 AGI，那用 AI 来帮助研究就是很有意义的。你也能理解为什么很多 AGI 实验室都会关注软件工程和代码生成，因为这是你构建 AGI 的重要环节，毕竟很大部分都是代码。
同样地，如果你留意工具使用和智能体（Agents）这块儿，它也非常符合打造 AGI 的需求。对公司来说，我并不认为有个所谓“最重要的前五项”，也许在操作层面会有个前十项的清单吧，但本质上就是为了构建 AGI，并确保它能造福全人类。我们存在的唯一原因就是这个，其他的都算是次要的，或者说这才是组织存在的根本。
让我觉得很了不起的是，如果四年前我跟你们描述这个使命，大家可能会想：**“社会会如何使用 AI？是不是更多工业应用、机器人之类的？” 但 ChatGPT 却成为了一种最让人惊喜的落地方式。当时你恐怕不会想到，但现在看似乎又很合理：你可以去 chat.openai.com，免费就能访问全球最先进的智能系统之一。这是非常了不起的事情。**ChatGPT 一开始只是个“研究预览”，后来却演变成了一个真正具有行业引领地位的品牌。
我觉得从很多方面看，ChatGPT 是最能体现这个使命的，因为它让许多人在日常生活中都能用到这种智能，而不是少数人能用，也不是局限在某些难以接触的形态上。所以我认为，这对于执行 AGI 使命非常关键。至于“让全世界受益”这一面，也就意味着每个人都能用它。
回到你说的成本问题——没错，成本非常重要。如果它非常贵，比如得花 200 美元订阅才能用，那就难以做到让全球都能受益。虽然我个人还是会付那 200 美元，因为只要一条提示词（Prompt）就能让我感到惊艳，但总得来说，你既想做前沿研究，又想让全世界都能收益。所以如果你想预测我们会怎么走，就想象一下，如果你负责这个公司，要“打造 AGI 并让它造福全人类”，你会怎么优先安排。这就是我们的一切优先级的根源。
Alessio 01:27:57
我们差不多要接近尾声了。我想问一些个人问题。首先，你曾经担任 Salesforce 的高管、Facebook 的 CTO 等，你显然也可以做很多其他事情，但你最终做了这些。你在作出这些选择时，有没有一些指导性原则或框架？
Alessio 01:28:16
就先问这个吧。
Bret 01:28:16
我会试着让自己保持在当下，脚踏实地。我希望自己多做到一些，但确实不是完全能做到。**我会专注在“影响力”上，也会考虑“我是否享受这个过程”。**我们之前也聊了一点——如果有创业者想创办公司，他应该做什么？我说过，有时最好的生意反而来自于你真正的热情所在。**我会同时考虑两方面：我能不能给世界带来影响，我会不会真正享受每天在做的事情。**对我来说，即使某个方向影响很大，但如果我不喜欢做，我就不会去做。
同时我也尽量让自己保持平衡。我有家庭，Sierra 也有“竞争强度”这条价值观，但我们也有“家庭”这条价值观。我们喜欢说“强度”和“平衡”是兼容的。你可以很有拼劲儿，同时也要平衡生活。我基本没有什么别的爱好，除了工作就是和家人在一起，但至少这对我来说还是有个平衡的。因为，想象当你走到人生终点时，你希望看到什么呢？我希望身边都是我爱的人，并且我也能为我对世界的影响感到自豪。
Alessio 01:29:35
我知道你也喜欢自己做手工面食。我是意大利人，所以很想知道你有没有最喜欢的面食形状、酱料之类？
Bret 01:29:43
这个问题有意思。我不知道你是在哪儿发现这一点的，是不是做了“Deep Research”之类？哈哈，果然是深入挖掘。
swyx 01:29:48
对啊，你是在哪里发现的？
Alessio 01:29:50
我忘了具体来源，好像是从……
Bret 01:29:52
可能是从 Ling 那边。
我确实喜欢做饭。我开始做面食是因为孩子还小时，我发现让他们一起参与做饭会让他们更喜欢吃饭。他们一起动手，做出来的饭就更珍惜。所以我们家经常会做意面和意大利宽面条之类，因为做起来比较简单，还可以手摇压面机，孩子可以帮忙摇，我负责把面条放进去，很有互动感。酱料方面我做很多种，可能最常做的就是简单的意式番茄酱，用高品质的番茄，经典又好吃。特别是如果你手工面不错的话就更棒了。当然我也都喜欢，不过那可能是做得最频繁的，因为简单好做。
Alessio 01:30:40
我一看到你做手工面就想，我作为个意大利人肯定得问问你最喜欢什么。对，我会推荐一种方形截面的意面，叫做 Spaghetto alla chitarra 之类，比较适合和小番茄酱、橄榄油，甚至加一点儿安肚酱（’nduja）一起做。我们改天可以单独再聊聊“意大利科技黑手党”之类的餐厅话题。
swyx 01:31:00
去跟 Alessio 吃意大利餐厅非常不错，他对这方面很懂。好的，那么我想问，你是怎么跟上 AI 界动态的呢？现在每天都有一堆消息，你有没有什么秘笈？比如什么独家新闻源之类？
Bret 01:31:17
没有特别神秘的东西。**大多数时候早上我会看一下社交媒体上有什么新动态、论文什么的。我们在 Sierra 有个小型的研究团队，遇到有意思的论文，我们会在午餐时段一起聊。有同事会深入读一篇论文，然后给大家做个简报，我发现这样收获很大。**我喜欢研究，但有时会被论文里庞大的术语和公式绕晕。所以大家一起用比较概念化的方式讨论，我才能更清楚地理解这篇论文真正的意义。我还很喜欢和别人聊天，遇到不懂的就直接问：“我不太懂，你给我解释一下。” 我不在意显得自己“无知”。我这样才能不断发现新的技巧、新论文之类的东西。坦白说，要跟上这一切真的很难。
是啊，如果你都觉得难，那对我们其他人来说就更难了。不过你肯定有很多很特别的内部信息，那你觉得，有哪些研究方向是大家要关注的？也许是你内部听到的一些新动向？
这个答案可能不出你们所料。我觉得总体来说，**“推理型模型”会是个大方向。**有趣的是，两年前那篇“链式思维（Chain of Thought Reasoning）”的论文就非常重要，从那时起，Chain of Thought 就一直被视为让模型得到更深入结果的一种有效方式。这篇论文好像是谷歌团队写的，对吧？我记得作者是谷歌这边。
这种方法一直能让模型的结果更扎实。如今，结合“蒸馏”（distillation）和“推理”，会让这些推理模型的性能——或者说延迟——更可控。如果你想想 GPT-4 在发布时是多么大的一次飞跃，但当时它很慢又很贵，所以可用性受到限制。后来 4.0、4.0 mini 出来后，成本和速度就更适合各种应用了。再到 GPT-4.1 也很有意思，质量更高，但速度更慢、成本也更贵，这也限制了应用场景。
我最近看到有人拿 DeepSeek 的一些模型做了蒸馏，把它们做得非常小，而且还能进行链式推理，速度快得惊人，延迟大概和之前的 GPT-4 差不多。这样一来就更有意思了。
**对于那些做 AI 应用的人来说，基本上就是在“价格—性能—质量”之间选平衡。这个市场还很年轻，过去你只能在不同模型里选一个特性来匹配你的用例。现在我们能得到更高质量的推理，同时还不至于慢得吓人，这真的太好了。就好比 GPT-4o 的速度让我用起来很开心，而 o1 就很慢，所以我常常会先在 4o 里写好 prompt，再放到 o1 里去，因为我不想在编写 prompt 和等待响应之间浪费时间。**这些新一代推理模型真的让我很期待，就像当年从 GPT-3 一下子到 3.5 又到 4，那个发展速度非常惊人。
推理模型也会有类似的“寒武纪大爆发”阶段，包括我们在推理层面如何利用推断时的计算资源，以及各种方法带来的新用例。我觉得对这个领域的任何人来说都非常激动。
尤其在编码场景下，推理模型会更对路，因为你需要它仔细思考生成的代码，而 GPT-4 这类模型本来就很擅长。我们在自己的领域也发现，有些问题就真的需要更全面地思考，而这些模型现在开箱即用就有更多“内置电池（batteries included）”，所以我对它们非常看好。
Alessio 01:35:37
那最后有什么想呼吁的吗？比如你们在招人吗？希望更多人用 Sierra 之类的？
Bret 01:35:42
我们确实在扩张团队，正在招软件工程师和智能体（agent）工程师。如果有兴趣可以发邮件给我，地址是 Bret(at)sierra.ai 。我们团队发展得很快。我们的工程团队全部在旧金山线下办公，不过也有一些出差性质的工程师在伦敦等地办公。
Alessio 01:36:00
非常棒。Bret，谢谢你今天花时间来和我们聊天。
Bret 01:36:01
感谢你们邀请我来。