Andrej Karpathy: From Vibe Coding to Agentic Engineering

我们非常兴奋能请来第一位特别嘉宾。他帮助构建了现代 AI，然后又帮助解释现代 AI，偶尔还会给现代 AI 重新命名。他其实就在这间办公室里参与共同创立了 Open AI，当年也是那个真正让 Tesla 的 autopilot 跑起来的人，而且他有一种罕见的能力，能把最复杂的技术转变讲得既通俗易懂，又像是不可避免。大家都知道他去年提出了 vibe coding 这个说法，但就在过去几个月里，他又说了一句更令人吃惊的话：作为程序员，他从未感觉自己如此落后。我们今天就从这里开始。

Andre，感谢你加入我们。

好。大家好。很高兴来到这里，也很高兴为今天的讨论开场。

好，就在几个月前，你说自己作为程序员从未感觉如此落后。这样的话从你口中说出来，确实很让人吃惊。你能帮我们展开讲讲吗？这种感觉是令人兴奋，还是让人不安？

对，肯定两者都有。首先，我想就像你们很多人一样，我已经用了 agentic tools（agent 驱动工具），比如 LotCode，以及一些相邻的东西有一段时间了，也许是过去一年里，随着它们陆续出现开始用的。它们在处理一段一段的代码时已经很好用了，当然有时也会出错，你还得自己修改一下，总体来说算是挺有帮助的。然后我会说，December 是一个非常明确的时间点；对我来说，当时我正在休息，所以时间稍微多一点。我觉得很多其他人当时的情况也类似。

然后我开始注意到，随着最新一代 models（模型）出现，那些代码片段生成出来就是对的。接着我不断要求它做更多，结果还是对的。然后我已经想不起来自己上一次去纠正它是什么时候了。再后来，我就只是，你知道的，越来越信任这个系统，接着我就开始变成 bad coding（不怎么亲自写代码）了。所以我确实觉得，那是一次非常鲜明、非常剧烈的转变。

我觉得其实很多人都是这样。我之前试着在 Twitter，或者说 X 上强调这一点，因为我认为很多人去年体验 AI 时，把它当成一个 chattyptu adjacent thing（一种类似聊天机器人的东西），但你真的必须重新看一遍，而且得以 December 之后的状态来看，因为事情已经发生了根本性的变化，尤其是在这种 agentic coherent workflow（agent 式连贯工作流）上，它真的开始实际运转起来了。所以我会说，是那种意识上的突然领悟，让我一头扎进了整个兔子洞——去做几乎无限多个 side projects（副项目）。我的 side projects 文件夹现在特别满，里面塞满了各种随机的东西，因为我一直都在不停地 coding（写代码）。所以，对，这大概就是 December 发生的事。此后我一直在观察它带来的各种 repercussions（连锁影响）。

你谈过很多关于“LLMs（大语言模型）是一种新计算机”的想法：它不只是更好的软件，而是一个全新的 computing paradigm（计算范式）。Software one point zero 是显式规则，Software two point zero 是 learned weights（学习得到的权重），Software three point zero 就是现在这个东西。如果这真的成立，那么当一个团队真正相信这一点的那一天，他们会以什么不同的方式来构建东西？

对，没错。所谓 software 1.0，就是我在写 code。software 2.0，则是我通过创建 data set（数据集）和训练 neural network（神经网络）来进行编程。所以，这时的编程有点像是在整理 data set，或许再加上一些 objective（目标）和 neural network architecture（神经网络架构）。

然后发生的是，基本上，如果你在足够大的 task（任务）集合上训练其中一种 GPT model 或 LLM（large language model，大语言模型），由于你是在 Internet 上训练，它必须对数据中的各种事情进行 multitask（多任务处理），于是这些模型在某种意义上就变得有点像一台可编程计算机。所以 software 3.0 的核心在于，你的编程现在转向了 prompting（提示词编程）；而 context window（上下文窗口）里的内容，就是你用来操纵这个 interpreter（解释器）——也就是 LLM——的杠杆。它会解释你的上下文，并在数字信息空间里执行 computation（计算）。我想，这大概就是这种转变。我觉得有几个例子特别让我真正意识到这一点，也许会很有启发性。比如，当 OpenCLaw 发布时，如果你想安装 OpenCLaw，通常你会以为这应该是一个 bash script，也就是 shell script。

也就是说，运行这个 shell script 来安装 OpenCLaw。但问题在于，为了适配很多不同的平台，以及很多你可能运行 OpenCLaw 的不同类型计算机，这些 shell script 往往会迅速膨胀，变得极其复杂。可你本质上仍然被困在 software 1.0 的宇宙里，还是想去写那段 code。实际上，OpenCLaw 的安装方式是：复制粘贴一段文本，把它交给你的 agent。基本上，它就是一种小技巧：把这段内容 copy paste 给你的 agent，它就会安装 OpenCLaw。而这之所以强大得多，是因为你现在是在 software 3.0 的 paradigm（范式）下工作，你不再需要把这个 setup（配置）的每一个细节都精确地写死。

agent 会打包并运用它自身的 intelligence（智能），然后按照指令行动。它会查看你的 environment（环境）、你的 computer，并执行智能操作让一切正常工作，还会在循环中调试问题。它的能力就是强大得多。我觉得这是一种完全不同的思考方式。就像是：要复制粘贴给你的 agent 的那段文本到底是什么？

这就是现在的编程范式。我想到的另一个例子，比刚才那个还要更极端，就是我在做 Menujen 的时候。Menujen 的想法是：你去一家餐厅，他们给你一份 menu，通常没有图片，所以我根本不知道这些菜是什么。一般来说，大概有 30% 的东西我喜欢，另外 50% 我完全不知道是什么。我想做的是拍一张餐厅菜单的照片，然后以一种通用的方式，得到这些菜大概会长什么样的图片。

我写了这个 app，它基本上可以让你上传一张照片，然后它会完成这一整套流程；它跑在 Vercel 上，基本上会重新渲染菜单，把所有菜品列出来，并给你一张图片。它会用 image generator（图像生成器）先对不同标题做 OCR（光学字符识别），再用 image generator 生成它们的图片，然后展示给你看。后来我看到了这个东西的 software 3.0 版本，这真的让我震惊：做法居然就是直接把你的照片交给 Gemini，然后说，用 Nanobanana 把这些内容叠加到菜单上。Nanobanana 基本上返回了一张图，和我拍的菜单照片一模一样，但它实际上直接在像素里把菜单上的不同内容渲染了出来。这让我大受震撼，因为说到底，我做的整个 Menujen 其实都是多余的。它是在旧范式下工作的。

那个 app 本来就不该存在。对，software 3.0 范式要原始得多。就是你的 neural network 在做越来越多的工作，而你的 prompt（提示词）或 context（上下文）仅仅就是那张图片，输出也是一张图片。中间根本不需要那个 app。我觉得人们需要重新调整思路，不要继续停留在既有范式里，不要只把它看作是对现有事物的加速。

现在其实是有全新的东西变得可用了。回到你刚才关于编程的问题，我甚至觉得，那也是一种旧思维方式的体现，因为这不只是编程，也不只是让编程变快而已。这其实是更广义的信息处理，现在都可以被自动化了。所以，事情甚至不只是关于 code。因为以前的 code，处理的有点像是 structured data（结构化数据），对吧？

你是在结构化数据之上写代码。但比如说，以我的 LLM knowledge basis project 为例，本质上你是在让 LLM 为你的组织，或者为你个人，等等，创建 wiki。这甚至都不算一个程序。这种东西以前根本不可能存在，因为过去并没有代码能够基于一堆事实自动创建 knowledge base（知识库）。但现在，你可以直接拿这些文档，基本上用另一种方式把它们重新编译、重新排序，然后创造出新的、有趣的东西，作为对这些数据的一种重新框定。

这些都是以前做不到的新东西。我觉得这是我一直想强调的一点：不只是那些原本就能做、现在只是变快了的事情；我认为还出现了新的机会——一些以前根本不可能实现的事情，我甚至觉得这更让人兴奋。

我很喜欢你提出的 menu gen 的演进路径和二分结构，而且我想，这里很多人肯定也都经历了你自己那种编程方式的演进——从去年 10 月一路到今年年初的 1 月、2 月。如果把这个趋势继续外推，那么到了 2026 年，什么会相当于 90 年代做网站、2010 年代做 mobile app、上一轮 cloud 时代做 SaaS？今天仍然大多还没被建出来、但事后回看会显得完全显而易见的东西，会是什么？

嗯，还是沿着 menu gen 这个例子来说吧。我猜，这里面很多代码本来就不该存在，真正做大部分工作的其实只是 neural network（神经网络）。我确实觉得，继续外推下去会显得非常奇怪，因为你基本上可以想象——我觉得是可以的——某种意义上完全由 neural net 构成的 computer。你输入原始视频，想象这样一种设备：它把原始视频或音频送进一个本质上就是 neural net 的东西里，再用 diffusion（扩散模型）渲染出一个在那个时刻独一无二的 UI。

我有点觉得，在 computing 的早期，人们其实对 computers 到底会长得像 calculators，还是会长得像 neural nets，是有些困惑的。在五六十年代，往哪个方向走并不真的显而易见。当然，后来我们走上了 calculator 这条路径，最终构建了 classical computing。而 neural nets 目前则是在现有 computers 上以 virtualized（虚拟化）的方式运行。但我想，你也可以设想，很多东西会反转过来，neural net 会变得有点像 host process（宿主进程）。

而 CPU 则变得有点像 coprocessor（协处理器）。所以我们看到了那张图，你知道的，intelligence compute——也就是 neural networks 的计算——将会接管，并成为 FLOPs 支出的主要部分。于是你可以想象一种非常奇怪、非常陌生的局面：neural nets 在承担绝大多数繁重工作，它们把 tool use 只是当作一种历史遗留的附属物，用来处理某些 deterministic（确定性）的任务。但真正掌控全局的，是这些以某种方式互联起来的 neural nets。

所以，继续外推下去，你可以想象出某种极其陌生的东西；但我觉得，我们大概率会以一种渐进、一步一步的方式走到那里。至于这个演进过程具体会怎样，我会说目前还是 TBD。

我很想再多聊一点 verifiability（可验证性）这个概念：也就是 AI 会更快、更容易地自动化那些输出结果可以被验证的领域。如果这个框架是对的，那么哪些工作马上就会比人们意识到的快得多地发生变化？又有哪些职业，人们其实以为它们很安全，但实际上却具有很高的 verifiability？

是的。所以我花了一些时间写 verifiability（可验证性）这个话题。基本上，传统计算机很容易自动化那些你能用代码明确规定的事情，而这一轮最新的 LLMs 则在某种意义上很容易自动化那些你能够验证的事情。其运作方式是：当前沿实验室在训练这些 LLMs 时，本质上是在巨大的 reinforcement learning（强化学习）环境里进行训练；模型会因“可验证”的结果而获得奖励。由于这些模型的训练方式，它们最终会逐步形成某种“参差不齐”的能力结构：在 math、code 以及邻近的、可验证的领域里能力特别突出，但一旦问题不在这个空间里，表现就会停滞，而且边缘部分会显得有些粗糙。我写 verifiability 的原因，是我想理解为什么这些东西会如此 jagged（锯齿状、参差不齐）。一部分原因和实验室如何训练模型有关，但我觉得还有一部分原因在于实验室的关注重点，以及他们恰好放进 data distribution（数据分布）里的内容。

因为有些事情在经济上明显更有价值，于是最终会形成更多相关环境，因为实验室本来就想在那些场景里发力。所以我觉得 code 是一个很好的例子。理论上他们大概还能想到很多可验证的环境，但那些并没有被纳入整体组合，只是因为围绕那些能力进行投入并没有那么有用。不过对我来说，最大的谜团之一是：之前大家很喜欢举的一个例子是 strawberry 这个词里有几个字母 r，而模型经常会答错，这就是 jaggedness（能力参差不齐）的一个例子。我觉得模型现在大概已经把这个问题补上了，但新的例子是：我想去 car wash 洗车，而它离我只有 50 米。

我应该开车还是走路？而今天最先进的模型会告诉你走路去，因为距离太近了。怎么会出现这种情况：最先进的 Opus 4.7 一方面能同时重构一个 100,000 行代码规模的 code base，或者找出 zero day vulnerabilities（零日漏洞），另一方面却告诉我应该走路去这个 car wash？这太离谱了。而只要这些模型仍然保有这种 jagged 的特性，就说明第一，也许有些地方略微不对劲；第二，你确实需要在 loop（回路）里参与一点，你需要把它们当作工具来使用，而且你确实得持续关注它们到底在做什么。

所以长话短说，我所有关于 verifiability 的写作，都是在试图理解为什么这些东西会是 jagged 的，这里面有没有某种规律。我觉得答案大概是 verifiable（可验证）加上 labs care（实验室重视）这两者的某种组合。再讲一个或许很有启发性的 anecdote（轶事）：从 GPT 3.5 到 GPT four，大家注意到 chess 水平提升了很多。我想很多人当时以为，哦，这只是能力自然演进的一部分。但实际上，更准确地说，我觉得——这应该是公开信息——我想我是从 Internet 上看到的。

有大量 chess 数据被放进了 pre training set（预训练集）里。正是因为 data distribution 里有了这些内容，模型的这项能力提升幅度远大于它默认自然会达到的水平。也就是说，OpenAI 里有人决定加入这些数据，于是你就得到了一项明显更高峰化的能力。所以这也是为什么我一直在强调这个维度：在某种程度上，我们略微受制于这些实验室在做什么、他们恰好往混合数据里放了什么。你必须自己去探索他们交给你的这个没有 manual（说明书）的东西。它在某些场景里有效，但在另一些场景里也许不行，而你必须亲自摸索一下。

如果你的应用落在那些 RL 过程中覆盖到的 circuits（回路）里，你就会飞起来；如果你落在 data distribution 之外的 circuits 里，你就会很吃力。你必须搞清楚，在你的应用中自己到底处在哪些 circuits 里。如果你不在那些 circuits 里，那你就必须认真考虑 fine tuning（微调），做一些你自己的工作，因为这些能力不一定会从 LLM 开箱即用地直接冒出来。

我很想过一会儿再回到 jagged intelligence（参差智能）这个概念。如果你今天是一位 founder，正在考虑建立一家公司，你想解决一个自己认为 tractable（可处理、可攻克）的问题，也就是某种 verifiable 的领域；但你环顾四周会想，天哪，那些实验室在最显而易见的方向上——比如 math、coding 等——似乎已经真的开始达到 escape velocity（逃逸速度）了。对于在场的创业者，你会给出什么建议？

所以我觉得，这大概可以回到前一个问题。我确实认为 verifiability——让我想想。可验证性之所以重要，是因为在当前范式下，它会让一个问题变得 tractable，因为你可以往里面投入海量 RL。所以也许一种理解方式是：即使实验室没有直接聚焦在这个方向上，这一点依然成立。也就是说，如果你所在的是一个 verifiable 的场景，你能够构造出这些 RL 环境或示例，那么这实际上会让你有机会去做自己的 fine tuning，而且你可能会从中受益。但归根结底，这是一种本身就有效的技术路线。

你可以拉一个杠杆。如果你手上有海量而且多样化的 RL（强化学习）环境数据集，诸如此类，你就可以用你最喜欢的 fine-tuning（微调）框架，拉下这个杠杆，做出实际上效果相当不错的东西。所以我也不确定这里具体会有哪些例子，但我确实认为，有一些非常有价值的 reinforcement learning（强化学习）环境，是大家可以去思考的，而且我觉得这些并不属于那个——嗯，对。我不想直接把答案说出来，但我觉得有一个领域非常——哦，好吧。抱歉。

我不是想在台上故意说得很模糊，但这类例子确实是有的。

反过来说，你觉得哪些事情现在看上去像是可以自动化，但其实只是远看如此？

我确实认为，最终几乎所有事情在某种程度上都可以被做成可验证的。有些事情比另一些更容易。因为即便是写作这类事情，你也可以设想组建一个由 LLM judges（大语言模型评审）构成的委员会，而且这种方法大概率能给出某种还算合理的结果。所以问题更多在于什么容易、什么困难。所以我确实认为，最终，是的，我觉得

一切。

一切都可以被自动化。

太惊人了。好，那么去年你创造了 vibe coding 这个说法。而今天，我们所处的世界感觉更严肃一些，更像是 agentic engineering（agent 驱动的工程）。你觉得这两者的区别是什么？你又会如何称呼我们今天所处的这种状态？

对。所以我会说，vibe coding 的意义在于提高每个人在软件方面“能做到什么”的下限。也就是下限被抬高了，每个人都可以用 vibe coding 做任何东西，这很棒，令人惊叹。但我会说，agentic engineering 的重点在于保住此前专业软件开发所存在的质量门槛。也就是说，你不能因为 vibe coding 而引入漏洞。

你仍然像以前一样要对自己的软件负责，但你能不能做得更快？先剧透一下：可以。但问题是，怎样才能把这件事做对？所以在我看来，agentic engineering（代理式工程）之所以这么叫，是因为我确实觉得它有点像一门工程学科。你有这些 agent，它们像是带刺的实体：有点容易出错，也有一点 stochastic（随机性），但它们又极其强大。

你要怎样协调它们，在不牺牲质量标准的前提下提速？把这件事做好、做对，就是 agentic engineering 的领域。所以我会把它们看作不同的东西：一个可能是在抬高下限，另一个则是在做外推、把能力向上延展。而我现在看到的是，agentic engineer 的能力上限非常高。

以前人们常说 10x engineer。我觉得现在这个效应被放大得多得多。你获得的提速并不只是 10x。就我目前的观察来看，那些非常擅长这件事的人，能力峰值远远不止 10x。

我很喜欢这个框架。去年 Sam Altman 来 AISent 的时候，他说过一句让我印象很深的话：不同代际的人使用 ChatGPT 的方式不一样。所以，如果你是 30 多岁，你会把它当成 Google 搜索的替代品；但如果你是十几岁，ChatGPT 就是你通往互联网的入口。那放到今天的编程语境里，对应的平行现象是什么？

如果我们去看两个人用 OpenClaw、Cloud Code、Codex 写代码，一个你会觉得水平平平，另一个你会认为是彻底 AI native（AI 原生）的开发者，你会怎么描述他们之间的区别？

我的意思是，本质上就是尽可能把现有工具的价值榨出来，用上它们的所有功能，并且愿意投入到你自己的 setup（工作配置）里。就像以前一样，工程师们本来就习惯于尽量发挥手头工具的最大效用，不管是 VIM、Versus Code，还是现在的 ClothCode、Codecs 等等。就是投入你的 setup，充分利用你能用到的各种工具，我觉得大致就是这个样子。我确实也觉得，另一个相关的想法是，很多人现在也许是在为这个能力招人，因为他们想招强的 agentic engineers。但据我所见，大多数人仍然还没有围绕 AgenTeq engineer 的能力重构他们的招聘流程。

如果你给候选人一些谜题式题目去解，那这仍然是旧范式。我会说，招聘应该更像是：给我一个真正很大的项目，看这个人能不能把它实现出来。比如说，我们来做一个给 agents 用的 Twitter clone，然后把它做好，做得非常安全，再让一些 agents 在这个 Twitter 上模拟活动。接着，我会用 10 个 codecs 5.4 x high 去尝试攻破你部署的网站；它们会想尽办法把它搞崩，而它们本不应该能成功。

也许它看起来就应该是这样，对吧？在那样的环境里观察人们，看看他们如何构建更大的项目、如何利用这些 tooling（工具链），这大概就是我主要会关注的东西。

随着 agent 能做的事情越来越多，你觉得哪种人类技能会变得更有价值，而不是更不值钱？

所以，是的，这是个好问题。我想，嗯，就目前来说，答案是这些 agents 就像被编入目录的 intern（实习生）实体，对吧？所以这很了不起。基本上你仍然得负责 aesthetics（审美）、judgment（判断力）、taste（品味），以及一点点 oversight（监督）。也许我最喜欢的一个能体现 agents 奇怪之处的例子，是在 MenuGen 里。

你可以用 Google account 注册，但购买 credits（额度）时用的是 Stripe account，而这两者都有 email address。我那个 agent 实际上试图这样处理：当你购买 credits 时，它会把来自 Stripe 的 email address 关联到 Google 的 email address。用户并没有一个持久的 user ID。它是在尝试匹配这些 email address，但你的 Stripe 和 Google 完全可以使用不同的 email address，这样一来资金基本上就不会被正确关联起来。所以这就是这类 agents 现在仍然会犯错的地方。

这就像是在说，为什么你会用 email address 来尝试交叉关联这些资金呢？它们本来就是任意的。你可以用不同的邮箱，等等。这真是件很奇怪的事。我认为人还是必须负责这个 spec（规格说明）、这个 plan（方案），而且其实我甚至都不喜欢 plan mode。

它当然非常有用，但我觉得这里还有个更普遍的点：你必须和你的 agent 一起设计一个非常详细的 spec，也许本质上就是 docs（文档），然后让 agents 去把它们写出来。你负责 oversight 和顶层分类，但 agents 在底层做了大量工作。所以我觉得，你将不会再去关心某些细节。再比如，在 neural networks（神经网络）的 arrays（数组）或 tensors（张量）里，PyTorch、NumPy、各种 Pandas 等等之间有一大堆细节，涉及各种零碎的 API 细节。我已经记不清 keepdims 和 keepdim 的区别了，也记不清到底是 dim 还是 axis，还是 reshape、permute 或 transpose。

这些东西已经不用再记了，对吧？因为你没这个必要。这类细节就该交给 intern 去处理，因为它们的 recall（记忆/检索能力）非常好。但你还是得知道，比如说，底层有 tensor，也有底层的 view；你可以操作同一块 storage（存储）的 view，也可以使用不同的 storage，但那样效率会更低。所以你仍然必须理解这些东西在做什么，理解一些 fundamentals（基础原理），这样你才不会不必要地来回复制内存，等等；但 API 的那些细节已经可以交出去了。

所以你负责的是 taste、engineering（工程判断）、design（设计），以及确保事情讲得通，确保你提的要求是对的，确保你会说：好，这些必须是唯一的 user ID，我们要用它把所有东西都关联起来。所以你仍然在做一部分设计和开发，而 engineers（工程师）是在负责把空白补上。这大概就是我们现在所处的位置，我想这也是现在每个人当然都能看到的情况。

你觉得随着时间推移，这种 taste 和 judgment 的重要性会不会下降，还是说上限只会不断提高？

是啊，这是个好问题。我的意思是，我希望它会变好。我觉得它现在之所以还没有改善，原因大概还是因为这不属于 RL（强化学习）的一部分。可能根本没有什么 aesthetics（美感）方面的成本或奖励，或者这部分做得还不够好，诸如此类。我确实觉得，当你真的去看代码时，有时候我会有点心脏病发作的感觉，因为那并不总是什么特别出色的代码，往往非常 bloated（臃肿），有很多 copy paste（复制粘贴），还有一些很别扭、很脆弱的 abstractions（抽象层）；它能运行，但就是非常粗糙、很难看。

而且我确实希望未来的模型能在这方面改进。另一个很好的例子是这个 micro GPT 项目，我当时想把 LLM（大语言模型）训练尽可能简化到最简单的程度。模型特别不擅长这个，它们做不到。我一直在试着 prompt（提示）一个 LLM 进一步简化、再简化，但它就是做不到，你会感觉自己像是处在 RL 回路之外。

那种感觉很明显，就是你知道，你是在硬拔牙，不是什么光速推进。所以我确实认为，人类仍然掌握着主导权；但我也确实觉得，从根本上说并没有什么东西在阻止这件事发生。几乎只是这些 labs（实验室）还没做到而已。

所以我很想回到这个“锯齿状智能形态”的想法。你写过一点这方面的内容，其中有一篇非常发人深省，讨论的是 animals（动物） versus ghosts（幽灵）。这个想法是：我们不是在构建动物，我们是在召唤幽灵。它们是由数据和 reward functions（奖励函数）塑造出来的锯齿状智能形态，而不是由 intrinsic motivation（内在动机）、fun（乐趣）、curiosity（好奇心）或 empowerment（掌控感）这些经由进化形成的东西塑造出来的。

为什么这种 framing（框架化方式）很重要？它究竟会如何改变你构建、部署、评估，甚至信任它们的方式？

是的，我觉得我之所以写这个，是因为我在试着弄明白这些东西到底是什么，对吧？因为如果你对它们是什么、或者不是什么，有一个好的模型，那么你在使用它们时就会更有能力。我不确定这是否真的具有很强的现实效力。我觉得这多少有点哲学化，但我确实认为，这本质上是在接受这样一个事实：这些东西不是动物式智能。比如说，你冲它们大喊大叫，它们并不会因此工作得更好或更差，或者说那根本不会产生什么影响。

它整体上更像是一种 statistical simulation circuits（统计式模拟电路），其底层 substrate（基底）是 pre training（预训练），也就是统计规律；然后上面又 bolt on（外挂）了一层 RL，所以它有点像是长出了更多 appendages（附肢）。也许这更多只是我进入这个问题时的一种 mindset（思维方式）：什么可能有效，什么不太可能有效，或者该怎么修改它。但我其实并没有那种“这里有五个显而易见的结果，能让你的系统变得更好”的结论。更多只是对它保持怀疑，然后随着时间推移一点点摸索清楚。

事情就是从这里开始的。好。那么你现在已经非常深入地在和 agents（智能体）打交道了，而且它们不只是聊天而已。它们有真实的 permissions（权限），也有本地上下文。

它们实际上会代表你采取行动。当我们都开始生活在那样一个世界里时，这个世界会是什么样子？

对。我想这里很多人可能都对这种 agentic（agent 驱动的）、原生 agentic 的环境会是什么样子感到兴奋，而且一切都得重写。现在的所有东西在根本上仍然是为人类写的，必须重新调整。我现在大多数时候在使用各种 framework、library 之类的东西时，它们的 docs（文档）本质上也还是写给人看的。这是我最受不了的一点。

比如，为什么人们还在告诉我该怎么做？我根本不想自己做任何事。我应该复制粘贴给我的 agent 的东西到底是什么？所以每次别人跟我说，去这个 URL 之类的，我都会觉得，啊，你知道吧？所以我想，大家现在都很兴奋的一点是：我们该如何把必须发生的工作负载拆解成面向世界的 sensors（传感器）和 actuators（执行器）；我们该如何让它变成 agent native，基本上先描述给 agents 听；然后围绕那些对 LLMs 来说非常清晰易读的数据结构，建立大量自动化。

所以我想，是的，我希望外面会有很多 agent first 的基础设施。而且，你知道的，就拿 MenuGen 来说——说“著名地”可能也不一定算著名——但当我写那篇关于 MenuGen 的博客时，很多工作或者很多麻烦甚至都不在于写 MenuGen 的代码，而是在 Vercel 上部署它，因为我得和所有这些不同的服务打交道，我得把它们串起来，我得去翻它们的设置和菜单，还得配置我的 DNS，真的非常烦人。所以这是一个很好的例子：我会希望对于 MenuGen，我只需要给一个 LLM 一条 prompt，告诉它构建 MenuGen，而我什么都不用碰，它就能以同样的方式部署到 Internet 上。我觉得，这会是一个很好的测试，用来判断我们的很多基础设施是否正在变得越来越 agent native。再往后说，最终我确实认为，我们正走向一个世界：无论个人还是组织，都会有自己的 agent representation（agent 代理表示）。

然后我会让我的 agent 去和你的 agent 交流，敲定一些会议细节之类的事情。所以我确实觉得，大致上事情会朝这个方向发展，不过是的，我想在场的每个人都对此很兴奋。

我真的很喜欢你用 sensors 和 actuators 做的这个视觉类比。我之前其实没这么想过。这特别有意思。好，我想我们得用一个关于教育的问题来收尾，因为你可能是这个世界上最擅长把复杂技术概念讲简单的人之一，而且你对我们该如何围绕这些内容设计教育也有非常深入的思考。当 intelligence（智能）变得廉价、我们迈入 AI 的下一个时代时，还有哪些东西仍然值得被深入学习？

对。最近有一条 tweet 让我非常震撼，我几乎隔一天就会想起它一次。它大概是这么说的：你可以外包你的思考，但你无法外包你的理解。

我觉得这话说得特别好。

因为我仍然是这个系统的一部分，信息仍然得进入我的大脑，而我感觉自己正在变成一个 bottleneck（瓶颈）：哪怕只是弄清楚我们到底想构建什么、为什么这件事值得做、我该如何指挥我的 agents，等等。我依然认为，归根结底，还是需要某种东西来引导思考和处理过程等等。而这在某种根本意义上，仍然受限于理解能力。这也是为什么我也对所有 LM knowledge bases 特别兴奋，因为我觉得那是我处理信息的一种方式。而且每当我看到对信息的不同投影方式时，我总会觉得自己获得了新的洞见。

所以对我来说，这其实就是基于某些固定数据，使用大量 prompts 来做一种 synthetic data generation（合成数据生成）。每当我读一篇文章时，我都会把它纳入我那个由这些文章不断构建起来的 wiki，而且我特别喜欢就这些内容提问题。我认为，归根结底，这些都是以某种方式增强理解的工具，而这仍然有点像一个 bottleneck，因为如果你还做不到真正理解，你就无法去指挥——你就不可能成为一个好的指挥者，因为 L1s 显然并不擅长理解。这方面仍然是你独特需要负责的。所以，是的，我觉得朝这个方向发展的工具都极其有趣，也令人兴奋。

我很期待几年后再回到这里，看看我们是否已经被完全自动化地移出了 loop（环路），以及它们是否连“理解”这件事也一并接管了。非常感谢你今天加入我们，Andre。

谢谢。

我们非常感激。