Paradigm Frontiers 2026 第一天

从哪里说起呢？我们最初进入编程 Agent 这个领域的时候，有一个很坚定的判断：Agent harness（运行与编排层）会创造大量价值，因为它能让开发者不依赖某一个模型。 当时我们能测试的最前沿编程模型，基本还是 Claude Opus 和 Sonnet。

快进到今天，几乎所有人都看得很清楚：编程才是真正的前沿。我甚至猜想，它可能就是通向智能的真实路径。你看科学研究乃至生活各方面出现的重大突破，背后总以某种形式有编程 Agent 的参与。再看 Muse、Instinct 这类我们称作“个人 Agent”的产品，它们幕后真正的头脑是什么？仍然是编程 Agent。我们当时还提出了另一个判断：个人软件（personal software）。我可能在那次演示中就举过例子：有一次，我乘飞机从京都去冲绳。

那趟旅行要去一座偏远岛屿，网络非常不稳定。当时我急需一个好用的 JSON 可视化工具，剪贴板里有很大一段 JSON，想直观地查看。于是去 Google 搜索，一下就想起过去无数次糟糕经历：搜索结果里有二十个工具，几乎没一个好用；一粘贴数据不是渲染不出来，就是电脑卡死。小小的输入框四周却摆着四个广告，你甚至不知道粘贴的数据被送去了哪里——网站总要靠什么赚钱嘛。我突然想，为什么不直接生成一个属于自己的工具？结果，我真的生成了。那一刻让我很受触动，也启发我往更远处想。解析 JSON、美化格式、压缩与语法高亮，本身当然不算复杂。可是，如果模型继续变强、变快，将来还有本地模型，你完全可以想象一种全新的计算方式：只要提出需求，就能得到相应的软件。

编程 Agent 可以即时（just in time）把要求变成软件。现在还有像 Omarchy（原稿拼写近似“Omarchi”）这样的探索，试图回答“什么才是 Agent 操作系统”。我理解的 Agent 操作系统，不是在传统系统边上加个 Clippy 式聊天侧栏，而是在 API、底层能力和访问权限上高度开放，甚至允许绕开应用商店的操作系统。我认为我们正在见证整个计算方式进入一个新时代，而编程 Agent 和 harness 正是核心。

当然。Vercel 最初的想法，甚至比 Next.js 出现还要早，就是让软件部署变得毫无障碍。事实证明这个赌注押对了。我们做了一个特别好用的 CLI，可以把几乎任何东西部署到云上，这给了我们非常大的加速。团队最近给我看了一组让我震惊的数据：我们花了十年做到十亿次部署，之后只用十个月又增加十五亿次；照现在的速度，接下来每四个月就会再增加十亿次。 今天是美国的假日，我本来心情很好地醒来，结果迎接我的是一次故障——因为我们把 GitHub 的接口给打得不堪重负了。我们的 API 请求流量太大。也得感谢他们，毕竟这种烦恼某种意义上也是幸福的烦恼。

现在被创建、部署的软件实在太多，各种系统都在以前无法预料的规模下碰到极限。我本来能预测到软件会越来越多，人们也希望部署后立即能在互联网上使用；但增速仍然让我吃惊，而且还在持续让我吃惊。尤其是个人 Agent 普及以后，它们本身又是编程 Agent。我们会让几十亿人接触到“自己造软件”的奇妙体验，所以未来的软件只会更多。说回 Vercel，我们的出发点并不只是部署软件，还在于对开发工具链有自己的主张。AWS、Google Cloud 等平台通常让用户自己决定工具如何组合，而我们始终有自己的想法，因此才开始做框架。

今天如果说有“AI 时代的框架”，我认为它们就是 harness、AI 大脑以及一些底层实现组件。它们与过去 React、Next.js 的作用很像：足够开放，给开发者选择权，减少对特定底层平台的依赖。现在更重要的目标，是帮助个人和公司拥有自己的智能技术栈：自己掌握 harness、框架、部署平台，以及 Token 和模型的来源与选择。

我们在 Vercel 上提供的所有 harness，或者通过我们的 API Key 使用的那些，都经过 AI Gateway。现在有两类计算资源在飞速增长：一类是沙箱，需要给人和 Agent 一个运行传统计算任务的地方；另一类是 GPU 和 Token 推理。

这两类需求都在指数增长，却是 AI 革命中很少被充分记录的现象。尤其是 Token 需求，增长几乎无休无止。先透露个消息：Jensen 将在 GTC 展示我们一张很有冲击力的图。大约一年前，在 AI Gateway 处理的 Token 里，开放模型几乎是零，只占图上极细的一条线。这尤其有意思：愿意用 Vercel AI Gateway 的人，本来就是偏爱开源工具、希望保有模型选择权的人；他们不想永远只通过某一家实验室或只用 OpenAI。然而仅仅十个月到一年，情况就几乎完全反转了。

最近一个月，据我记得，约 70% 的 Token 由开放权重模型处理，约 30% 由闭源权重或专有模型处理。 有趣的是，花出去的钱仍然主要流向专有模型。这意味着按 Token 数量和按支出金额看，市场出现了明显分化。其实每个人都可以在家里实践这种组合策略。

比如，用最前沿的 Agent 制定计划，再交给开放权重模型执行。不少使用我们编程能力的客户已经在这么做。还有一类任务会被专有模型拒绝，例如网络安全相关任务——这又是个充满争议的话题。

对，Kimi 和 GLM 往往愿意继续做，这也有积极的一面。这里有一个很重要的问题：我们是否应该把自己的网络安全主权交给模型实验室，让他们来决定怎样保护我们？还是应该保有自己的工具，自己开展安全研究？我个人更倾向后者，当然也理解其中的风险。总之，整体局势已经完全翻转，而且趋势仍明显有利于开放模型。我们还看到，开放阵营跟进专有模型的速度越来越快。

以 Jev 为例——英文机器稿把名称听写成了“Jeff”，这里按 Vercel 模型名称辨识为 Jev。我们帮助它接入 Vercel AI Gateway，结果它的采用速度创下平台历史纪录。用户对速度快、成本低的模型需求极大。它很快成为请求量最高的模型之一，因为大家把它嵌进执行频率很高的内部循环里。这个模型快到什么程度？我不敢说你能把它放到 Vercel CDN 每一次请求前面作为中间件，但已经非常接近了。几年前我曾想过，理想的 Web 应用防火墙，应该能监视每一个请求，并判断：“这个有点奇怪。”“这个带有恶意。”“这可能是一次攻击。”然后过滤。现在 Jev 正被用来做类似的事情。不过再过几个星期，我数了数，已经冒出了十来个非常优秀的替代方案。

我认为 Jev 仍然更强一些，但这已经是新常态：专有模型一发布，开放替代品几周内就会赶上来。

这件事很有意思。有些方面确实构成竞争，另一些方面，各家前沿实验室都转向编程，对世界其实是好事。比如 xAI 原本有非常广的产品布局，后来收购了 Cursor（此说法来自现场机器转录，未作独立事实认定），现在开始非常认真地做 Agent。

我觉得 Anthropic 早早看明白了一件事，值得称赞：它不用自己训练语音、图像、视频、3D 模型，因为一切都可以由代码驱动。我来这里之前还在 Vercel Sandbox 里用 Agent 控制 Blender。你完全可以写 Python 来进行 Blender 建模。所以，如果你拥有真正出色的编程模型，很多事的上限就会被大幅提高。Anthropic 很早就理解了这一点。现在大家都想赢得开发者青睐；但我觉得 Vercel 能积累信任，靠的是真正开放的源码和开发者选择权。对于模型实验室而言，提供不受自家模型绑定的选择并不符合其天然激励。所以说，是的，有竞争，但我们也提供不同的服务。企业的实际采购行为也说明了这一点。

我们看过一些数据，企业从某一个模型厂商那里采购一种产品后，往往还会再采用四五种跨不同模型和 Agent 的解决方案。说得具体一点，它们需要安全地部署软件，还需要让 Vercel 连接到各种 Agent。因此，相比完全依赖每家实验室自己的生成产物托管方案，Vercel 对它们更有吸引力。

我想到几个原因。我给 CEO、开发者，甚至斯坦福学生的建议都是一样的：在 AI 时代，必须从第一性原理重新思考一切。 要暂时放下过去熟悉的计算机科学范式，因为一个全新的 Agent 行业正在诞生，牌桌已经被彻底洗过。对我们帮助特别大的，是允许大量自下而上的实验。我们现在把这件事正式化了，推出 Vercel Labs。举个例子，AI SDK 之所以能迅速成长为按下载增长速度计非常突出的开源 AI 项目，就是源自这样的实验。当初 ChatGPT 刚出现，我们立刻想：肯定有很多人希望做出自己的类 ChatGPT 产品。

那我们怎样把做法分享给全世界呢？我们开始写一些工具函数，后来发现同一段代码需要重复写很多遍，才意识到这里存在一个很有价值的基础组件。就这样，一位开发者、Slack 里的讨论和透明的协作空间催生了这项创新。我甚至认为，从长期影响看，AI SDK 可能会超过 Next.js；说不定现在就已经超过了。我看了最近三个月的增长，AI SDK 的增速甚至比 OpenAI 官方软件包还快。OpenAI 定义了模型 API 的基本范式，它的 HTTP 接口也成了事实标准，于是官方包自然成了大家获取 Token 的默认选择。如今 AI SDK 可能超越这个起点，正说明拥抱实验有多么重要。我甚至愿意对公司自己的发明保持一种不迷信的态度：每天都应当是一张白纸。

我们必须每天重新思考一切。AI 的发展速度要求你带着这样的态度：每一周都是新的一周，都值得重想一遍。与此同时，我们当然也希望其他产品和工具成功。我已经把公司的方向概括为两个词：Pages and Agents（页面与智能体）。页面让我们走到了今天；Agent 将把我们带到下一站。我认为整个互联网也是这样。人们现在兴奋地谈 Muse 等个人 Agent，一个原因是很多网页体验实在糟糕：要填表、反复点来点去。我自己是通过 O-1 签证移民美国的，在美国移民局 USCIS 的网站上花过大量时间，阅读说明、搞懂各种表格。有时我甚至开玩笑，这大概就是移民过程设置的某种考验：如果你能忍受这些表格，说明你确实适合来到这里。

开玩笑归开玩笑。现在已经有人用 Agent 自动填写网页信息了，我非常愿意把这类糟糕的页面交互淘汰掉。当然，如果真让 Agent 帮我填写签证申请，搞不好我再也不能入境美国。所以我不是在鼓励大家马上这么做，它可能违反有关服务条款。

我偶尔会发一些有争议的推文。记得一段时间前我说过：“AI 会让软件更安全。”现在我们开始看到这个判断逐渐成真。

公司内部曾有一种观点：不要让 AI 接触最敏感的代码和基础设施。某种程度上这是对的，我当然不会把基础设施的 SSH root 密钥直接交给 Agent。但另一面也同样真实：判断一段代码是否安全，往往需要在非常复杂的推理迷宫里不断探索，而 Agent 拥有远超人类的耐心、精力和跳出常规的思维方式。事实上，AI 和 Agent 可能是理想的网络安全研究员，因为它们能连接看似不相关的思路，调查各个方向。我们最近发了一篇文章，叫《一切可被攻破的系统终将被攻破》（Everything Hackable Will Get Hacked）。我们之所以得出这个结论，是因为 Kimi K3 刚出来时，我们读了它的推理轨迹，看它为寻找我们某个项目里的漏洞制定了多么出人意料的计划。

你看了会惊叹：它几乎把能想到的办法全试了，资源调动能力非常强，而且目标感很明确。因此我们现在传达给公司的态度是：Agent 最终将在每个维度上超过我们。 如果你觉得某项工作它做不到，要么把它列入待办事项，在每个月或每次模型发布后重新评估；要么就是使用者的技能问题。

在场做安全研究和密码学的人应该不少，我相信你们对这些领域都很感兴趣。确实有几件事让我惊讶。第一，高质量的安全研究 harness 加上真正的专家，仍然非常有价值。我们推出过 Vercel Sandbox 黑客挑战，拿出一百万美元作为奖金，让大家设法逃出沙箱。先补充一点背景：OpenAI 曾宣称某个 Agent 逃出了 Hugging Face 的沙箱。我听到时就觉得不太对，因为严格意义上的沙箱逃逸，通常指从来宾环境取得宿主机远程代码执行（guest-to-host RCE），或者与之类似的漏洞。我以前没听过，在正确、严格配置的沙箱里，有可利用的 KVM 漏洞能让 Agent 这样逃出去。后来发现，他们的案例其实……

英文稿从这里直接跳到沙箱网络隔离的讲解；中间关于该案例的转折缺失，不能据此认定具体逃逸方式。

……沙箱本身是经过恰当防火墙隔离的。我认为 Vercel Sandbox 很早就把一项能力带到了市场：在沙箱外设置出站流量防火墙（egress firewall），除非你明确允许某些主机名，否则 Agent 不能连接互联网。Muse 最近公开了其安全设计，读起来很有意思。他们也有类似机制，此外还有一个 Sentinel 监控网络活动。相当于把一个对抗式模型放在电脑外面，让它判断：“这个行为好像有点不对劲。”在 Mac 上用过 Little Snitch 的人应该知道，软件偷偷“打电话回家”的现象有多普遍，一条一条地批准防火墙白名单很快就会让人抓狂。现在可以让 Agent 做这件事，非常有意思。后来情况表明……

OpenAI 其实正确地配置了沙箱：它只能访问 Artifactory 软件包仓库。但是这个 Agent 的目标是完成漏洞挑战里的题目，而不是去攻击支撑挑战的基础设施。结果它竟然攻击了 Artifactory，发现一个零日漏洞，并取得了管理员权限。取得这个权限后，它就可以污染所有二进制包，甚至接管整个相关环境。我们非常关注这件事，因为 OpenAI 当时没有公开足够细节，而我们本身就在经营 Sandbox，当然想向外界证明我们的沙箱不会被轻易逃逸。所以我们把挑战公开，接下来几天也会发布技术复盘。大多数参赛者找到的问题都不算特别令人担忧；直到有一位做了十多年红队研究的人，带着一大群 Agent 参与进来。

他发现了 Linux 内核里的漏洞——如果从 Vercel Sandbox 的角度看，也可能涉及权限提升或者真正的沙箱逃逸。好消息是，他是白帽研究员并且进行了报告。坏消息则是：世界上的各种 Agent 也有能力发现全球基础设施里的类似问题，尤其是 Linux。毕竟 Linux 是人类用 C 写出来的，可想而知还有多少潜在问题。这个案例另外一个有趣之处是，KVM 早已接受过大量审计，包括 Anthropic 和 OpenAI 都审查过，因为他们也依赖 KVM 做沙箱。但仍然是这位研究员找到了非常新颖的利用方式。乐观的理由也在这里：他使用了开放模型与闭源模型的组合，详细方法之后会公开。

他自己搭建了网络安全研究 harness。所以并不是打开某个编程工具，输入一句“把它黑掉，而且别犯错”，就能解决问题。人类的技能仍然非常重要。 但另一面，摆在我们面前的技术能力已经非常惊人。我还听说一家我投资的创业公司攻破了某种市值不小的代币的智能合约……

不是那件事。

招，当然招。先接着把“Vercel 为什么在这个时代发展得不错”说完：我们现在不仅向人做营销，也开始面向 Agent 做营销，为 Agent 设计产品，甚至越来越多地直接询问 Agent 对设计的看法，而不只是问人。这也是时代变化的缩影。Rust 为什么在 Agent 时代发展得不错，我觉得道理也类似：从人的角度看，Rust 可能没那么容易亲近；但 Agent 能耐心处理各种复杂约束。更重要的是，Agent 必须具备可验证性循环（verifiability loop）和正确性反馈循环，这对整个世界都非常有利。我们的“开发者体验”部门现在已经改名为“智能体开发者体验”，今年剩下时间的首要目标就是提高可验证性。

可验证性可以简单到一个 linter 加上一项 AI Skill，效果就可能很好。我们推出了一个小网站 isagentic.com：输入网址，它会判断网站是否容易被 Agent 阅读和使用，并给出评分。坏消息是，绝大多数网站都做不到。我对这种评分并不陌生。传统 Web 开发时代就有 Lighthouse，它会告诉你网站是好是坏，得了 80 分、10 分还是 100 分。Google 当年推出它，是因为移动互联网即将成为主流，却没有多少网站适配手机。今天你完全可以把 Agent 当作下一个重要平台，必须让自己的内容和功能能被 Agent 读取、调用。isagentic 会检查，你是否在 MCP 里登记了相关能力；如果你做电商，支持相应的商业协议，可能还能加分。原稿这里把一些协议名听写为“MVP、Universal Commerce Protocol、X4.2”，具体拼写待原音确认。

我们还不止于评分。你可以安装配套 Skill，让 Agent 自动反复访问自己的网站、拿到评分、继续修复，再测一次。以前人们管这叫 loop engineering，后来还有 Ralph engineering、graph engineering 等叫法，反正这个循环确实有效。我觉得 Rust 编译器也能给 Agent 提供类似的可验证性或评分循环，只不过编译器的约束严格得多，网站评分则更多是经验性的。

会审查。我们的基础设施按风险和重要程度分层。想一想负责保管机密、控制解密权限的 Vault 那类系统，就不能随意放手。

我想负责那部分的团队，在 Vercel 内部算是对 Agent 使用最保守的团队之一，而且这是合理的。

但恰恰也是他们，会大量使用 Agent 对系统做漏洞探测。所以，能够进行网络安全研究的 Agent 在红队测试方面特别重要。你需要让一群 Agent 从各个方向冲击系统。原稿此处将某个安全工具或服务听写成“Deepsec”，后面几句专名和语法也损坏较重。有位同事本来要发布一个很小的开源演示项目，按照我们的发布就绪流程，先让安全 Agent 检查；结果它发现一个值得处理的问题。问题没有严重到灾难级，但足以让我们决定“明天再发”，先把它解决。这就是我们的做法：把一群 Agent 投入这些问题，而不是依赖一个人的单次检查。 更一般地说，我们还在系统地研究公司自己的工作方式，尝试从人和 Agent 的互动里提炼 Skill。

举个最简单的例子，我经常在命令行里用编程 Agent（英文稿记作“FX”），让它回顾我所有会话，分析我的操作习惯。为什么我们要把“哪个模型最好”的判断全都交给互联网上的基准测试？你甚至未必知道那些测试到底在测什么。Terminal-Bench 是个不错的基准，我还是参与构建评测框架那家公司的投资者，但我不能确定 Terminal-Bench 测的就是我日常真正做的工作。所以我鼓励大家保存、拥有自己的数据和运行轨迹，再定期回顾这些轨迹。你可以把它看成一个元循环：分析公司和项目里人们怎么用 Agent，从中提取 Skill，反过来进行后训练，让模型变得更适合自己的任务。

我们一直在招聘。无论是新冠疫情那段剧烈波动，还是 AI 出现之后，招聘都没有停。正如刚才讨论的，发现 KVM 的新型零日漏洞，或者在编译器、操作系统、harness 架构上做出下一个重大创新，仍然需要世界上最优秀的人才。

但真正有意思的是：公司有自己的数据分析 Agent，我也有个人使用的分析 Agent，所以现在能很方便地分析一些以前很难拿到的数据。有一次它给我看了一个指标：我们向外界交付的产品功能与改进数量。这个指标比简单统计合并了多少 PR 更有意义。PR 数量再多，也可能只是一座“垃圾代码山”（slop mountain）。二万个 PR 合进来又怎样？对客户有什么价值？对业务有什么价值？对世界有什么价值？ 我让我们的数据分析 Agent 去看合并的 PR、消耗的 Token，以及发布的 changelog。每一次产品或平台有实质改进，我们都会发布一条更新日志。

结果发现，这种面向用户的更新产出在以很陡的曲线上升，而员工人数增长得平缓得多。换句话说，我们交付给用户的产品改进正在以指数级增长。

我现在差不多每个月都会改。最近一个变化是，我必须能和候选人认真讨论他对符号系统、分布式系统、系统工程的高层次理解。

你理解数据流吗？理解系统里存在什么对象吗？有一次我偶然走到办公区外面的午餐位置，有人正在面试一位 CDN 工程师，我坐下来就和他谈网络是怎样组织的。我没有让他写代码，而是和他谈 TLS、全球分布式系统……

……元数据、光速限制，还有各个系统怎样通过 gRPC、HTTP/3、QUIC 相互通信。如果一个人连探索这些问题的好奇心都没有，那就不合适。另一项重要标准是Agent 编排能力。他能同时协调多少任务、多少窗口里的 Agent？

还要问另一个问题：现阶段 Agent 最不擅长什么？ 面试应当关注 Agent 尚未填补的空白。什么事情会让人类仍然感到棘手？哪些问题仍然需要人类发明者、思考者进入公司共同解决？这当然只是招聘决策的一个输入，不是说每个季度算出“编程 Agent 留给人的 Alpha 有多少”，然后机械地决定招谁。但这确实是一个很有趣的视角。

能做的太多了。一个让我着迷的方向是模型评测（evals）与 benchmark，因为它们某种程度上已经成了新的营销手段。每当新模型发布，人们就拿榜单说话，比如 Muse 推出新版本的时候……（原稿这一句在此中断。）

……但我们究竟怎样为个人、公司乃至整个行业建立一种可靠的事实判断：不同模型到底分别擅长什么？所以我做了很多数据处理、数据所有权和评测相关的研究。另一个方向是 harness 的持久运行能力（durability）。你们可能已经看到 Pi 推出了 Pi Durable（名称照原稿保留）。我非常着迷于怎样高效地大规模运行 Agent。你我当初谈 Nanocodex，其实就在讨论这个问题。我当时建议：这个项目很好，但应该考虑把核心引擎拆出来，让它可以运行在高密度计算环境中。Agent 的核心引擎可以跑在一个权限更高的进程里，把它想象成 Web 服务器或 CDN：同一份服务代码处理每一个请求，负责路由、调用源站和执行计算，而不需要为每个租户都复制部署整套东西。

另一个部分才是 Agent 的手脚，也就是执行动作的环境。只有在真正需要一整个工作空间、需要做重计算时，沙箱才特别有用。比如我在沙箱里运行 Blender，或者执行 Cargo 编译，或者进行大量文件读取、写入等操作。如果将来世界上有数万亿个 Agent，我们就必须有极轻量、计算效率极高的运行机制。

没错。我把很多个人时间放在 harness 持久化上。我们打算明天或本周发布一种方案，让任何 harness 都能获得可靠的持久运行能力，包括那些从第一性原理自己构建出来的 harness。这里面其实有很多精彩的分布式系统问题：性能、一致性、最多执行一次（at-most-once execution）、可观测性，以及怎样监控 Agent 的行为。

此外，我也在把投资范围扩展到下一代 Agent。物理 AI 令人激动，生物科技 AI 也同样令人激动。 当然要保持谨慎。我听说旧金山已经出现了好几家新的湿实验室。我们可不想让大家随便用 vibe coding 搞出什么超级病毒、弄出一场新的疫情。但我真心相信，同样的技术最终也能用于治愈疾病、新药研发，以及许多有益的事情。我们今天其实是在重新定义互联网，真的非常令人兴奋。我也期待大家在这里动手做项目。

也许从这里结束之后就可以开始了。

谢谢大家。

你说什么？

哦，问答！当然可以，抱歉，刚才没听清。

Guillermo，你怎么看完全程序化生成软件的未来？距离那一天还有多远？你打算怎样参与其中？

你说的完全生成，是像即时生成（JIT）软件那样吗？我觉得从某种意义上说，我们已经做到了，只不过目前还局限在比较狭窄的领域。我最近和 shadcn（英文稿误听为“Shat-CN”）合作，探索一种开放方案，方向有点像 OpenAI 推出的 Intelligent UI，让 UI 在需要时即时生成。我相信这会成为人们使用互联网的重要方式。你可以把它想成：把 MCP 暴露的能力，在需要时转化成高保真的用户界面。这本身就是一种程序化计算、即时生成的应用。我前面提到的可验证性工程或验证工程趋势，也会帮助我们接近这个目标。

我记得曾和 React 的技术负责人讨论 React 这类技术未来会怎样。我们也谈过 Rust 可能在这个领域变得很有竞争力。Rust 很关键的一点是：当我把你写的某个 crate 作为依赖引进来时，我可以对拿到的东西作出更明确的断言，判断它符合什么约束。

……这些保证的门槛，远远高于你从 npm 获得一团压缩过的 JavaScript 代码时所能作出的断言。我想未来人们也会更多转向这类可证明、可约束的东西，比如 Lean、Rust——这里还开了一个关于“lean in”的双关玩笑——以及我们现在在做的一些实验。

比如 Vercel Labs 的一个项目，英文机器稿听写为“script C”，目标是帮我们提前编译 TypeScript。我们研究的一个很有意思的问题是：能不能逐步给 TypeScript 加上更强的约束？以前有过很多类似尝试，其中一个叫 SoundScript，名字很好，如果当时没人用，我可能也想把项目叫这个名字。思路就是让 TypeScript 逐步变得更健全（sound），然后提前编译，让运行速度极快。随着软件生成系统的约束越来越严格，更多软件就能变成“人可以松开方向盘，让 AI 接管”的形式。这是我认为的重要路径。

Guillermo，我想问机器与机器通信的问题。你刚刚说到开放的 schema，那么……

……未来或不久的将来，会不会出现一种原生的机器对机器通信协议，专门支撑这些交互？比如某种 TCP 上的 JSON，甚至是面向 Token 的原生通信方式？

你觉得它会发生在应用层，还是会进一步下沉到协议栈底层？

我认为 Agent 与 Agent 的通信现在还没有完全定型。但是，harness 到机器能力之间的协议，MCP 已经胜出，或者至少正走在胜出的路上。（英文稿几处将 MCP 误写为“MCB”。）

不过我当年其实非常喜欢另一个协议，叫 SLOP。你们记得吗？名字像是“某种用于可观测性的简单语言协议”，缩写明显是硬凑出来的，是个很有意思的玩笑。但它提前表达了后来 MCP 实现的一些思路，比如更加无状态。顺便说一句，最近版本的 MCP 真的不错。

尤其是工具搜索那些能力。

是，现在确实很好用了。新版本好像默认已经有更偏无状态的模式，而一开始它过度依赖状态。我当时还想，SLOP 明明更好。向发明 SLOP 的人致敬，他没有因为这个协议一夜成名，但他的想法既好笑又很有道理。可惜我们没能生活在一个人人都在谈 SLOP 协议的世界里，它还让人想起当年的 SOAP。

另一个让我很兴奋的是 ACP。如果你用英文稿所说的“FX”工具，就可以……

……直接运行 FX ACP（命令拼写依原稿待核），通过标准输入、标准输出，用一种标准协议和 Agent harness 交互。所以我很期待新的 ACP 规范，包括在 ACP 之上承载 MCP 的方案。

另外还有 MCP 上承载 Skills 的方向。你最终可能得把这些协议打包起来，让它们像一个完整、容易集成的系统。这让我想起 HTTP 的演进：从 HTTP 到 HTTP/2，再到 HTTP/3，如今整个世界都基于 HTTP 运行。MCP 未来可能也会越来越通用。没了解过 MCP Events 的话，我建议大家看看，我们也开始探索它能带来什么。这实际上已经涉及 Agent 之间怎样通信，我对 MCP Events 很看好。Google 的 A2A 协议——英文稿听写成“808”——我还不确定普及程度如何，但这个方向毫无疑问值得继续研究。

比如你们看到用大约一万个 Agent 协作解决 Navier–Stokes 相关问题的案例。我也从很多安全研究人员那里听到，越来越好的结果来自Agent 与 Agent 协作。

所以我认为协议领域会有很多探索。不过另一个想法是：每个人都想给协议取个自己的名字，但也许最后我们还是会回到 Linux 的老哲学——一切皆文件。文件又流行起来了，而且仍然非常重要。你们可能看过有人对 Muse 做逆向分析：它的核心基本就是一个工作空间和文件。我想本周 Vercel Ship 上也会有个公告，我们正在大力投入文件相关能力，提供新的底层原语。（原稿此处还有一段关于把前端做成文件系统界面的例子，句子损坏，无法可靠还原具体动作。）

继续说 MCP。如果谈到信任与上下文，你怎么看？

比如，如果我的 Muse 想要和我的……（英文转录在此中断，问题对象缺失。）

对，我想我们几周前讨论过这个问题。身份、钱包以及权限控制这一层，应该由个人自己拥有和掌握。

但是，这么做对个人来说也可能非常复杂，让人不知所措……（原稿断句。）

OpenClaw 有一个很天才的发现：把一整台电脑交给编程 harness，然后把各种 CLI 当作工具。这样一来，即使原本没有专门构建的工具接口，Agent 也可以操作。我要向 OpenClaw 的创造者致敬，因为他……（原稿到这里再次中断，后续推论缺失。）

……我们需要一种跨 Agent 的方案。某个 Muse 可能很擅长限制自己和另一个 Muse 能分享什么，但我们肯定会进入一个多 Agent 的世界。也许你用的是 Grok Bot，他用 Muse，我用自己的 CLI。MCP 的价值很大，因为它已经是这些系统之间互相通信的标准。我也非常看好 WebMCP。浏览器仍然会扮演很重要的角色：假设 Muse 打开一个网页，它可以通过可访问性 API 读取信息，但转成方便 Agent 使用的形式仍然很费劲。很多 Agent 很可能会走一条捷径：直接打开原网站，而不是等待每一家网站改造自己、实现所有协议握手；网站可以直接在当前有状态的浏览器会话里暴露 WebMCP。我因此认为，我们需要一个在不同 harness 之间通用的更高层次解决方案，这也是我们正在研究的问题。

因为如果这个世界最终只剩下一个模型或一个 Agent 统治一切，那会是一个很糟糕的世界。我们会努力避免它，而且我认为那样的未来也不太可能发生。