InfoQ 推荐

黄仁勋为微软站台：没有 Windows 就不会有英伟达，Satya 当场“讨市值”

褚杏娟 — Fri, 09 Oct 2026 09:53:58 GMT

微软正在把 Windows 变成一个同时调用本地模型和云端模型的 AI 平台。

在北京时间10月8日的Windows 发布会上，微软宣布将“混合智能”引入 Windows，通过模型路由、Windows ML 和本地 AI 能力，让 GitHub Copilot、Copilot 等产品能够根据任务复杂度、成本和隐私要求，在云端模型和本地模型之间自动切换。

其中，GitHub Copilot 的 HydraFusion 将首次能够直接调用运行在 Windows PC 上的本地模型。相关能力将在 10 月晚些时间陆续进入 GitHub Copilot 应用、CLI和 VS Code。

现场，黄仁勋和Satya Nadella两人回顾了微软和英伟达长达数十年的合作。黄仁勋表示，英伟达的发展与 Windows 深度绑定：Windows 95、DirectX、GeForce 到 CUDA，共同推动了 GPU 从图形计算走向通用加速计算。

两人还回忆，Azure 早期建设基于 InfiniBand 的高性能计算（HPC）基础设施，后来恰好成为 OpenAI 训练 GPT 模型的重要底座。

对 Agent，两人判断一致：Agent 正在成为新的“电脑用户”。Satya 认为，Coding Agent 最早暴露出，即使模型运行在云端，本地 Harness 仍然需要访问文件系统、执行命令、调用软件。因此，操作系统必须原生提供隔离、身份、可观测性、治理和权限控制。黄仁勋进一步强调，MXC 这样的底层机制，可能会像当年的 Windows 和 DirectX 一样，成为下一代 Agent 构建与部署的重要基础设施。

两人对“混合智能”的理解也非常明确：未来用户不会再关心任务究竟运行在本地还是云端，而是希望系统自动调用最合适的模型和算力。

在本地 AI 价值上，两人并不只是强调“省 Token”。Satya认为，更重要的是让计算靠近数据和工具。他甚至判断，未来 Agent 会成为文件系统最大的使用者之一。黄仁勋也认为，Agent 会比普通用户更会使用软件。

硬件层面，黄仁勋认为，AI PC不应该只是“多一颗NPU”，而是要同时承载传统应用、图形计算、CUDA、本地模型和 Agent。他把这种变化概括为：过去 PC 是人的工具，未来它既是人的工具，也是个人 Agent 使用工具的平台。

现场，Satya打趣黄仁勋：“现在 Jensen 要把一点市值转回给我了。”不过，华尔街并没有立即给出激烈反应：发布会当天微软股价仅上涨约 0.1%，第二个交易日则下跌 1.35%。

Windows 不只 AI PC

本地支持更大规模模型

微软认为，过去只能在数据中心运行的模型，正在被压缩到个人电脑上；未来 Windows 可以把高频、耗时或涉及隐私的数据处理放在本地，把真正复杂的任务交给云端前沿模型。微软称，这将成为 Windows AI 的一套通用架构，并用于编程、安全、内容创作和办公等场景。

为了把更大的模型带到终端，微软正在重点推进模型量化和 Windows ML。

微软此前推出的MAI Code 1.1 Flash 是一款混合专家（MoE）编程模型，拥有1370亿总参数、68亿激活参数。面向本地部署的版本经过约3比特量化后，模型体积缩小近80%，同时保留256K上下文。

微软还表示，英伟达正在开发一款超过 700 亿参数的Nemotron 模型，在量化至 2 比特后，内存占用仅略高于 20GB。而DeepSeek V4 Flash的参数规模达2840 亿，经过 1.66 比特量化后，模型可以在本地运行，内存占用约 60GB。

与模型量化配套的是 Windows ML。微软正在把 Llama.cpp 引入 Windows ML，使开源模型能够更快接入 Windows，并在 GPU、NPU 和 CPU 之间运行。

Copilot中的“混合智能”

在 GitHub Copilot 中，“混合智能”首先表现为模型自动路由。

新版自动模式可以根据任务复杂度决定调用本地还是云端模型。简单任务，例如代码清理、问题分诊，可以直接交给本地模型；更复杂的任务则继续使用云端模型。

微软现场演示了一个典型场景：主任务由云端 GPT-6 Luna 负责分析，同时启动 3 个本地子 Agent，使用 MAI Code 1.1 Flash Local 并行构建和测试。其中一个本地会话输入约 166 万 Token、输出约 1.05 万 Token，但不会产生额外的云端模型费用。微软希望把这类高频、长时间运行的任务尽可能放到本地，尤其是问题分诊、自动化检查等可以整夜运行的工作。

这实际上改变了 Coding Agent 的成本结构。过去 Agent 工作时间越长、并行实例越多，Token 成本往往越高；如果部分子任务可以转移到用户自己的 GPU 和 NPU 上，本地算力就可以成为云端 Token 的替代品。

相比 GitHub Copilot，Windows Copilot 的变化更接近系统级 Agent。

微软为 Copilot 增加了 3 类能力：本地上下文、本地操作和本地模型。本地上下文意味着 Copilot 可以搜索和理解 PC 中的文件；本地操作允许它在获得授权后移动文件、修改设置等；本地模型则让 Copilot 在成本或隐私更加重要时，把部分工作直接下放到设备端，最困难的任务仍会交给云端模型。

这些能力首先被整合进 Copilot Home 和 Code。Home 现在能够理解用户 PC 上的本地文件，并将原本只保存在设备端的内容直接带入 Copilot，用于编辑和协作。

Copilot Code 则进一步把“本地 AI”延伸到软件开发。用户只需输入一条提示词，就可以直接生成原生 Windows 应用和小组件，无需开发经验；微软还为 Code 加入 MXC 支持，使本地运行的代码进入沙箱环境；与此同时，部分编程任务可以直接交给本地模型完成，以降低云端调用成本并提升响应速度。

微软将这套能力称为“个人软件工厂”：从应用生成、代码执行到部分模型推理，都可以直接在 PC 本地完成，而更复杂的任务则继续交给云端。

微软现场以报税为例展示了这一能力。Autopilot 可以先读取会计师邮件，确定需要准备哪些文件，再从用户电脑不同目录中寻找材料、重命名并整理文件，最终生成 ZIP 包。涉及税务信息的文件整理和重命名均由本地模型完成，数据不需要上传云端。完成整理后，Autopilot 还能生成回复邮件并附上压缩包，但在真正发送之前仍需要用户确认。

微软将 Autopilot 定义为一个企业级、可长时间运行的自主 Agent。其背后的方向是，让 Windows 不再只是运行 AI 应用，而是允许 AI 在操作系统层直接理解本地环境并执行任务。

微软没有把这套能力限制在 Copilot。目前，Hermes、OpenClaw、Perplexity 等 Agent 已经开始基于 Windows 构建本地 AI 体验，Muse 也将推出原生 Windows 应用。针对 OpenClaw 等常驻 Agent，微软还将提供新的 Windows 快速安装体验和原生 Windows Gateway，以降低部署门槛。

微软把迷你桌面 PC 称作适合 Agent 长期运行的“Claw Box”：设备可以保持常开，即使用户离开电脑，Agent 仍能够持续工作。这也是微软此次 Windows AI 战略中一个比较明显的变化：Windows 不再只强调“AI PC”，而开始争夺 Agent 的底层运行环境。

为了支撑更大的本地模型，微软同时扩大了 AI PC 的硬件覆盖范围。

微软透露，目前面向商用市场打造的笔记本中，超过40%已经是Copilot+ PC；所有Copilot+ PC每月在本地完成超过2万亿次推理。

面向开发者和创作者，微软还发布了 Surface Laptop Ultra。该设备基于英伟达RTX Spark，最高配备 128GB 统一内存，AI 算力最高达到 1 PFLOP，目标之一就是让传统笔记本无法装载的大模型直接在本地运行。

更高一级则是运行 Windows 的 DGX Station。微软称，这类桌面级超级计算机能够本地运行 Llama 4 Maverick、Kimi K2.6，以及超过 1 万亿参数的 DeepSeek V4 Pro。

微软用一句话概括其硬件路线：有了 RTX Spark，可以把“去年的前沿”带到笔记本；有了 DGX Station，可以把“上个季度的前沿”带到桌边。

黄仁勋与 Satya：第一次重构个人电脑

主持人：我昨晚在 YouTube 上查了两位，发现很少看到你们两位同时站在一个舞台上。我就在想，这两家公司之间的历史已经延续了几十年，你们个人之间的合作也有几十年的积累。Jensen，你和 Satya、微软合作时，最喜欢的一段记忆或者最有趣的经历是什么？

黄仁勋：英伟达的创立，本质上就是因为 Windows。那是 1992 年底，Windows 3.1 的时代。我们刚刚开始看到“个人电脑究竟可以成为什么”的愿景。说实话，在那之前我甚至没怎么见过 PC，我主要是在工作站上工作。我们有文件服务器、有超级计算机，用来做芯片设计。

当时，我和另外几位创始人就在讨论一种未来：也许一台拥有 3D 图形能力的个人电脑，既可以用来玩游戏，也可以成为工作站，还能进行设计。我们的想象就始于这样的世界图景。如果没有 Windows，英伟达不会以今天这种方式被创立。

然后到了 1993 年，我们正式开始，Windows 95 则真正重新定义了这件事。Windows 95 让 GPU 可以真正连接到个人电脑，而真正让 GPU 发生革命性变化的是 DirectX。Direct3D 这个API让我们第一次可以把 GPU 的能力真正暴露给应用。

随后 DirectX 8 出现，我们和微软一起发明了世界上第一代可编程 GPU，也就是可编程着色器。再往后几步，它最终演化成了今天大家熟悉的 CUDA。

所以如果回看英伟达的完整发展历程，Windows 一直处于最核心的位置。如果没有 Windows，就不会有 GeForce；没有 GeForce，也就不会有 CUDA；没有 CUDA，Alex Krizhevsky、Ilya Sutskever、Yann LeCun、Andrew Ng 等人，也不会找到那样一台适合做深度学习的计算机；然后才有了今天。

Satya：现在 Jensen 要把一点市值转回给我了。

黄仁勋：我每天都在转，每天都在转。

Satya： Jensen 刚才讲的这段历程确实非常特别。从某种意义上说，它就是一段计算史。

Jensen 给我最大的启发之一，是他可能是整个行业里对“加速计算究竟能成为什么”这件事坚持最久、最一致的人。回头看，它的演进轨迹甚至比任何一种单一 PC 形态或者芯片架构都更宽广。

我最早的一段记忆，就是我们当时在讨论：在云端，加速计算或者HPC到底能做到多大？我记得最早的一笔合作之一，就是讨论怎么让 Azure 上的 HPC 做得更大。

黄仁勋：而且 Satya 是第一个在云里使用 InfiniBand 的人，这件事非常关键。它让我们第一次把超级计算机带给 OpenAI，然后就是大家都知道的事情了。

如果当时我们没有为 HPC 做这些事情，没有构建基于 InfiniBand 的超级计算机，后来 OpenAI 就不会有那台超级计算机去训练 GPT 模型，后面的历史可能都会不一样。人生里很多事情就是这样偶然发生的：我们原本是在做 HPC，然后 Sam 过来问：“你们有算力吗？”我们说：“也许有。”接下来事情就发生了。

Satya：我真正想把功劳给 Jensen 的，是他对这件事长期而一致的判断。他不是在看今天，也不是只看明天，而是把它当成一个长期结构性趋势。这也是为什么我们会走到今天这个时刻。

黄仁勋：然后我们又开始讨论另一件事。我记得非常清楚，我和 Satya 当时在聊：这对 PC 意味着什么？在这一切之后的新时代里，我们怎么打造一台“完美 PC”？

个人电脑始终是终极工具。对我来说是，对整整一代人来说也是。那么，到了 Agent 时代会发生什么？当 Agent 就在你的电脑上，它会成为你的个人助理，但它又希望能够访问我们已经拥有的所有强大工具。

问题是，这些工具过去分散在英伟达生态里的不同设备上：游戏 PC、工作站。大量专业工具都在那里，包括各种设计工具、Siemens 的工具、Autodesk、Adobe，以及大家刚刚看到的那些应用。我们希望全球最好的 Blender、最好的 Unreal、最好的 Omniverse、最好的 CATIA，全都和 AI 一起出现在同一台 PC 上。

那么，怎样才能创造出这样的电脑？顺便说一句，这件事我们做了 4 年。

Agent 为什么需要操作系统级安全原语

主持人： Satya，过去几个月大家一直在讨论 Agent 和安全。这里很多人都在使用 Agent，比如 Muse 或 Instinct，而你会给它完整磁盘访问权限，让它代表你做事情。今天展示的 MXC 给我的感觉，像是为 Agent 加入了一个非常基础的新操作系统原语，这和过去很不一样。为什么操作系统是解决这个问题的正确位置？这个原语又会打开什么新的空间？

Satya：首先要记住，这一切最早就是从运行在桌面上的编程 Agent 开始的。如果要问哪一种 Agent 最需要这种安全原语，答案其实就是本地 Harness，因为它要访问文件系统，还要真正采取行动。

所以，我们和 Jensen 团队合作时就在讨论，应该怎样把这件事直接接进底层原语里，无论是云端还是本地操作系统。因为编程首先走到了这一步：即便你调用的是云端模型，Harness 仍然运行在本地，因此我们必须让桌面成为 Agent 最安全的执行环境。这就是 MXC 的由来。

现在看到 OpenShell 与 MXC 完整集成并实现原生支持，我觉得非常棒。Pavan 刚才提到的那些控制能力，本质上都说明一件事：隔离必须在每一层完成，不能只做其中一层然后忽略其他地方。微型虚拟机要有，虚拟机要有，会话层也要有。

我最兴奋的一点，是 Windows 会话本身也具备隔离能力，这一点非常关键。但仅有隔离还不够，接下来还需要完整的可观测性。

怎么获得可观测性？你必须给 Agent 一个身份，这样我才能追踪它，看到这个 Agent 留下的完整执行轨迹，然后再对它实施治理。也就是像传统系统一样制定策略，再根据策略进行约束，这才会真正给 IT 运维、安全运维带来信心。还有一点也不能忘，就是能够追踪 Token 花费：到底在哪里花了多少 Token。

所以我们试图做的不是任何单独一件事，而是把这些东西全部串起来。经历过这么多轮技术采用周期，不管是消费者采用还是企业采用，我觉得阻碍技术大规模扩散的，往往就是没有把“完整需要什么”想清楚。如果只完成其中一部分，剩下的没做，就建立不了信任。

现在我们已经把这些能力在云端、客户端，以及整个安全和治理体系里串起来了，而且它是异构的，并不是只支持微软自己某一块技术，而是希望把所有东西都支持起来。

黄仁勋： Satya 刚才说的这些，会成为下一代 IT 的基础。如果你认真看他刚才使用的词，实际上他描述的是下一代计算机非常深层的架构。

就像 Windows 和 DirectX 曾经彻底改变应用的构建方式一样，MXC 会改变 Agent 的构建和部署方式。没有它，根本无从谈起，所以这是一件非常大的事。

“混合智能”意味着什么

主持人：这和下一个话题联系得非常紧密，也就是“混合智能”。我觉得它和我们过去习惯的方式有些不同。现在大家都用过云端大模型：你发出请求，它可能调用一个工具，比如 Blender，然后返回结果。我们已经习惯了这种体验。

但今天展示的场景不同。你可以选择很多模型，有的跑在本地，有的跑在云端，任务会在两者之间来回流转。刚才 GitHub 的演示里有一句话让我印象很深：“这些 Token 是免费的。”也就是说，一部分工作负载直接在笔记本本地执行，一部分在云端执行，并且系统会智能路由。这样的模式会打开什么？

Satya：我觉得这就是那种很多原本分散的东西突然“咔哒”一下拼到一起的时刻。

我刚才一直在想，20 世纪 80 年代末我读研究生的时候，我有一台终端，比如 VT 系列终端，连接 VAX；家里又有一台 PC。我其实一直同时使用两边。PC 上通过调制解调器连接 VAX，同时又有本地 DOS、早期 Windows，还有 Usenet 等东西。

但直到大约 Windows 95，甚至到 Mosaic 这样的第一代浏览器出现，这些东西才真正被整合成一种无缝体验。那时你不会再关心“这是本地还是云端”，你只想让所有可以获得的计算能力顺畅地服务于你正在做的事情。

刚才 Danilo 的演示就是这种感觉。那一刻真的很震撼。我觉得几年后大家回头看，会说：“原来那就是我们第一次真正看到这种工作方式。”

他先去 ComfyUI，下载多个模型，生成一批资产；然后把资产拿到 Blender 里进一步加工；再回到 ComfyUI；之后去 Photoshop，用可能是本地模型的能力继续优化；再回到 ComfyUI；最后又把整个东西带到云端，通过 Astra 和 Unreal 完成最后一步。

他只是自然地使用桌面上的应用、本地模型和云端模型，所有东西就这么协同工作。这就是今天真正想表达的东西。

所以我看到的趋势非常清楚。未来不会再有一个时刻，你还要特意判断“这个跑本地、那个跑云端”。你会默认混合智能无处不在，成为普遍存在的能力。这正是让我最兴奋的地方。

黄仁勋：刚才那个应用里，Blender 被加速了，ComfyUI 被加速了，Astra 在云端运行，而 Agent 在本地。整个计算可以触达的范围非常惊人。

Satya：对，它真的把整个人类计算史上几乎所有科技公司的能力，都汇聚到了同一个应用工作流里。

黄仁勋：没错。回到你一直在讲的加速计算，这也是 Danilo 为什么会兴奋：过去需要好几天的事情，现在只需要几个小时。真正被加速的不只是某个任务，而是他的创造野心，我觉得这很酷。

主持人：现在模型已经很擅长工具调用，但很多工具本身就在本地，文件也在本地。这里还有一个很现实的问题：我希望自己的数据保持安全、可控，也希望工具调用发生在数据附近。

Satya：对。编程 Agent 刚开始流行的时候，有一件事让我很兴奋：大家突然又重新爱上了控制台，也重新爱上了文件系统。这再次证明文件系统是一种多么强大的抽象。

我觉得 Agent 会成为文件系统最大的用户群之一。文件系统必须安全，因为它是一个异构内容的集合空间。刚才那个报税例子就非常典型：它把下载目录、云端文件、邮件等各种来源里的内容，最终整理进一个文件系统容器，然后调用本地模型和云端模型继续处理。

这就是新的计算机。过去是我在使用电脑，未来是我和我的 Agent 一起使用电脑，因此 Agent 也需要这些底层原语。

像 OneDrive，我已经很久不会把它想成“云端东西”或者“客户端东西”了，它就是到处都在。所以，我觉得我们现在开始进入这样的阶段：我希望供 Agent 使用的底层能力可以 24×7 存在。当我坐在 PC 前时，它应该像是在这台 PC 上工作；当我移动到其他地方，它也应该跟着我移动。

黄仁勋：还有一个很惊人的地方，这些 Agent 最终会比我们更会使用工具。原因很简单，我们通常只知道某个应用 10% 到 15% 的功能，但 Agent 可以知道每一项功能。

所以，现在这些不可思议的工具都在你的 PC 上，又运行在 Surface Laptop Ultra 这样强大的电脑里，Agent 可以直接访问所有能力。谁知道未来能做到什么？刚才它已经同时用到了 Blender、Unreal、ComfyUI，真的很不可思议。

黄仁勋：第一次真正“重做”个人电脑

主持人： Jensen，我想接下来问硬件。我们平时经常看到你谈那些规模巨大的 Vera Rubin、Blackwell、NVL72，也就是驱动数据中心的“智能 Token 工厂”。但今天聊的是另一种东西：RTX Spark、工作站等。你怎么看 Token 从数据中心生产，逐渐也可以在用户身边生产这件事？

黄仁勋：这个项目投入的工程力量非常惊人，累计超过 4000 工程师年（engineering years）。这是一个非常庞大的项目。

我们实际上第一次真正把个人电脑完整重做了一遍。过去分散在游戏 PC、笔记本、工作站，以及云端超级计算机里的各种能力，现在我们统一了架构，让它们运行在一颗超级芯片上。

这颗超级芯片为什么是长方形？因为它实际上是两颗巨型芯片融合在一起。它是一头“猛兽”。算力达到 1 PFLOP。

给大家一个参照：引爆 AI 革命的那台 DGX-1 算力也是 1 PFLOP。那台机器价值 2.5 亿美元，重达 500 磅（实际上，初代DGX-1 在2016年的官方售价为 12.9万美元，官方系统重量约 134磅），而现在，这样的算力已经被放进了你的笔记本电脑里。

更重要的是，这也是全球唯一一种可以同时原生运行这些东西的计算机架构：DirectX 及其全部应用、OpenGL 的各个版本，因为我们需要所有这些工具和设计软件、创意软件；Unreal 也必须运行得非常好；同时 DirectX 要足够优秀；还要让每一个 CUDA 应用都能以很高性能运行。

4 年前我和 Satya 讨论的是：接下来会出现整整一代新的软件开发者，而这些开发者会成为 AI 软件开发者。他们要么是在开发 AI 应用和 AI 模型，要么是在利用 AI 来开发软件。因此，计算机本身必须被重新设计，从底层就非常擅长 CUDA。

这也是为什么它是全球第一种可以在设备端原生运行全部这些能力的计算机。我们第一次真正做到了。这件事需要我们双方数千名工程师，也需要整个产业一起参与。看看我们身后的生态：每一家主要笔记本厂商、桌面设备厂商、工作站厂商都加入了进来。

这可能是第一次，一种新的硬件和新的计算机架构一出现，整个产业从上到下、从左到右、跨越各个地区全部共同参与，这是一场完整的重构。

我们很清楚自己正在做的事情有多重要。现在已经测试了超过 1200 款应用，而且是全球负载最高、最复杂的一批。我们做了完整的功能测试、性能测试、兼容性测试，也完成了大量优化，接下来还会继续做下去。围绕这套系统，我们还会不断加入更多软件、中间件、算法，这件事不会停止。

所以当你最后看到 Pavan 拿着这样一台漂亮的笔记本站在台上时，背后其实是微软、英伟达，以及全球大量合作伙伴无数工程师共同完成的工作。所有这一切，都是因为我们相信：个人电脑过去是人的工具，而未来它不仅是人的工具，也会成为我们的个人助理，并由这个助理去使用工具。

Agent 代表用户行动后，谁来承担责任？

主持人：最后一个问题，想问两位。如果这几天看过 X，会发现大家正在激烈讨论“个人 Agent”。今天我们更多谈的是生产力 Agent 和企业 Agent，但无论是 Muse 还是 Instinct，现在都出现了一个问题：当 Agent 代表我出去购买东西时，究竟是我在购买，还是 Agent 在购买？出了问题谁负责？

对于服务提供商来说，如果未来用户本人不再直接访问我的网站，而是由 Agent 代表用户访问，我又该怎么应对？整个行业正在尝试制定标准，也在摸索新的行为方式。如果稍微看看未来，你们觉得这会走向哪里？会形成标准吗？行业会围绕某种新的行为规范逐渐收敛吗？

Satya：我觉得还是要回到我们前面谈的“信任”。信任首先来自一些基础问题：这些 Agent 有没有被隔离？有没有自己的身份？Agent 的执行轨迹是否能够与用户身份分离？

Pavan 团队一直在强调的一点，就是即使 Agent 是代表用户工作，也必须让 Agent ID 和用户本身的身份分开。日常使用需要这样，到了你刚才说的场景里更需要这样，因为接下来你必须决定：我究竟把多大的代理权限（delegation authority）交给 Agent，让它代表我做什么？

这个决定本质上还是建立在信任上。随着 Agent 越来越自主，只要它不断证明自己值得信任，你愿意交出去的权限就会逐步增加。

而在消费者场景里，我觉得最终还会落到一种“保险定价”的问题。某种程度上，市场会给“Agent 代表我做事”这件事定价。协议当然很重要，我们应该把协议做好，但最终市场还是会评估：Agent 代表用户行动所带来的风险应该如何定价。

黄仁勋：你这个问题再一次说明，MXC 是多么重要的基础。OpenShell，以及我们一起做的这些工作，本质上都是在解决信任、隔离、可观测性和监控。

如果这些基础做不好，后面的事情都无从谈起。我们首先必须把这一层安全做好。那些代表我们行动、替我们做事的 Agent，只能获得最小必要权限；它们必须拥有自己的凭证；必须可以被监控并建立信任。只有做到这些，我们才可能真正让 Agent 放手去替我们执行任务。

今天其实是一个非常有力的时刻。我还记得 OpenClaw 刚出现的时候，它还是一种从终端里折腾出来、自己搭 Gateway 的东西。现在，它已经成为 Windows 中原生嵌入的一部分，Token 可以在本机加速运行。为了走到今天，背后投入了大量工程工作，真的非常惊人。

Satya：最后我还想补一句。Jensen 刚才顺带提到的那个愿景，其实就是 Windows 一直以来在做的事情：不把任何一段代码、任何一种框架留在过去，而是把它们全部带到未来。

他刚才说，我们会把全部 Windows 应用、所有图形应用、全部 CUDA、全部 OpenGL，再加上新的 Token 工厂一起带过来，真正让我震撼的是这一点。

Windows 已经陪了我 34 年，看起来它还会再陪我 34 年。

参考链接：

https://www.youtube.com/watch?v=RE_AsVyoOSQ"

Codex 和 Claude Code 都跑偏了，前 OpenAI 研究员称 Jev 出现前 AI 世界是个悲剧

林绮蓓,蔡芳芳 — Fri, 09 Oct 2026 09:39:38 GMT

编译 | 林绮蓓、蔡芳芳

策划 | Tina

“它会逐渐退到软件背景中，像数据库、正则表达式或其他基础设施一样，成为开发者随手调用的普通能力。”

这是 TypeSafe CEO、Jev 创始人 Diogo Almeida 对 AI 的设想：当智能真正融入软件，用户甚至不必意识到它的存在。但怎样才能让开发者放心地把判断交给 AI，而不用守在旁边反复检查？

几个月前，在 AI Engineer 大会的演讲中，这位曾参与 OpenAI InstructGPT 工作的研究者就提出，“下一个时代并不是Claude Code”时代。在他看来，Claude Code 与 Codex 本质上仍属于同一个阶段——AI的主要角色仍然是围绕人提供辅助。他关心的是，为什么 AI 如此聪明，能解决数学界的千禧年难题，却连最基础的活都无法实现自动化工作？

9 月 22 日，做客 Latent Space 播客接受采访时，Diogo 再次谈起这份不满，措辞更加直接：“在我看来，Jev 出现之前的 AI 世界，简直是个悲剧。”在他看来，问题在于：强大的“智能引擎”已经有了，把它接进实际业务流程的接口却仍然欠缺。

这一次，他带来了自己的答案——Jev。通过面向校准决策的强化学习（RLCD），团队希望让模型输出可供代码直接使用的选择、评分和概率，让开发者能够依据不确定性设置阈值，决定何时执行、何时交给人处理。

从参与训练听懂人类指令的模型，到尝试让代码直接调用智能，Diogo 为什么要重新选择训练目标？他又准备如何让 AI 成为像数据库一样普通的软件能力？这场两小时的访谈讲述了他的判断与尝试。

太长不看版：

Swyx：对于那些可能不太了解情况或者只想得到确切答案的人来说，Jev到底是什么？

Diogo Almeida：目前最准确的称呼是 System One 模型，它的能力范围远远超出决策本身。这类模型的目标，在于让代码成为模型输出的直接使用者。

Swyx：你对 RLHF 的一个核心看法是：模型的回答会向用户想听的内容，而不是反映它对一件事真正的内部置信度。能具体谈谈吗？

Diogo Almeida：几乎没人注意到RLHF 的缺点，特别是“模式坍缩”（mode dropping）。RLHF的模式坍缩会让模型偏向生成更安全、更常见的答案，而牺牲概率分布的真实校准，这既掩盖了长文本中的错误累积，也解释了为什么文本模型不擅长决策。

Swyx：RLCD 与 RLHF 的核心区别是什么？

Diogo Almeida：区别首先在于优化目标：RLHF 侧重让模型遵循人的指令、给出获得认可的回答，RLCD 则希望模型成为软件能够可靠调用的能力。

Swyx：为什么 Jev 不把拒答机制直接放进模型底层？

Diogo Almeida：我不反对安全本身，但我认为不应把特定价值判断直接写进通用模型底层能力，而应像数据库一样划清技术能力与具体使用责任的边界。

Swyx：你所说的可靠性是什么？开发者能否相信同一个版本的行为保持稳定？

Diogo Almeida：我更重视稳健性：问题含义没变，就不该因为加入无关字符而大幅改变判断，而不只是追求相同输入得到相同输出。已经部署的模型，我们不会悄悄修改，因为 API 是别人程序里的依赖。但我们会快速发布新版本，目前还不能承诺永久维护每个旧版本。

Swyx：不依赖公开榜单，你们怎样判断模型是否真正做到了更高的性价比？

Diogo Almeida：我们会通过内部评测比较成本和能力，追求同等成本下更强、同等能力下更便宜。我不反对评测，反对的是围绕榜单优化，让分数脱离真实价值。开发者最终还是要把模型放进自己的工作流，测量实际表现，不能只看价格、速度或一个总分。

Swyx：开发者应该怎样组织任务，才能更可靠地使用 Jev？

Diogo Almeida：我建议把复杂任务拆成最小、可以独立判断的语义单元，用结构化输入提供必要信息，再由代码控制最终行为。Choice 对应选择分支，Noul 对应条件判断，Score 对应评分、排序和筛选。每一步都可以单独评估、调整阈值；能力不足时，就转交人工或暂不部署。

Swyx：对企业开发者来说，Jev 有哪些值得尝试的应用方向？

Diogo Almeida：我们梳理了四类：分析因处理成本太高而闲置的“暗数据”；为实时流程提供快速判断；检查其他模型的调用和输出；把智能判断嵌入软件核心逻辑。我尤其看好暗数据分析和编程 Agent，但具体如何组合模型，仍要看它能否降低成本、解决原本解决不了的问题。

Swyx：面对前沿 AI 的风险，放慢发展速度是唯一选择吗？

Diogo Almeida：我认为，这种讨论往往默认大家必须沿着现有 RLVR 路线继续加大投入，但研究目标和技术路线都可以重新选择。为了提升表现而给模型多大行动空间，本身就是设计决定，不该被当作不可避免的前提。我更希望探索其他方向，让已有智能可靠地进入软件，自动化实际工作。

Swyx：如果研究者在前沿实验室得不到资源，你会建议他们出来创业吗？

Diogo Almeida：要看为什么离开。如果只是想自由尝试课题，现有实验室可能仍然最合适；如果找到了值得长期投入的新任务，我会支持创业。我不认为漂亮的研究履历会自动创造价值，也不看好拿到资金后重复已有工作的做法。先明确自己的核心目标，再围绕真正值得解决的问题展开研究。

Jev发布的第一周，创始人的情绪糟糕透了

Swyx：欢迎来到录音室。就在本周，我的好朋友 Diogo 发布了 Jev，它几乎占领了社交平台的热点话题。此时此刻，你感觉怎么样？

Diogo Almeida：情绪上来说，从来没有这么糟过。我现在简直像一具疲惫不堪的行尸走肉，因为同时发生的事情太多了，到处都有问题等着我处理。

但是，从心理层面来说，那反而完全不一样。我经常讲这件事，并且这几年我在那些大小项目活动里也反复说过，整个 AI 领域就像游乐园里的哈哈镜屋，所有人都像疯了一样。每个人都在说各种奇怪又说不通的话。

可是就这一周，我好像和现实更合拍了，像是突然之间感受到：“哦，大家终于看见了。”——AI 能做到的事情，远比过去人们想象的多。我们真的可能推动了一场由 AI 驱动的经济革命，这件事重新回到桌面上了，简直实在是太棒了。我特别兴奋的一点，是开发者真的能够理解我们在做什么，这种感觉非常强烈。我也想对这些开发者表达我长久的感激。我对整个开发者社区以及现在发生的一切都特别兴奋，真的太棒了。

Swyx：你昨天还跟我说，你决定优先去做 town hall，也就是社区公开交流，而不是把时间都花在VIP和投资人之类的人身上。因为你希望确保真正得到你最多注意力的，是工程师、开发者这些真正使用产品的人。

Diogo Almeida：是的。当时确实会有一种感觉，像是“天啊，我现在正在跟一些非常重要的人说话。”我可能不该透露是谁。但对我来说，如果在我那个列满了待聊对象的庞大日程表里，开发者社区竟然不在其中，这对我来说会很不舒服。实际上，如果按照我的理想状态，我会一直和开发者社区在一起交流。我刚才甚至在想，“我要不要一边走来你的演播室，一边开一场社区大会？”后来我又觉得，“不行，这也太疯狂了。”

Swyx：对于那些可能不太了解情况或者只想得到确切答案的人来说，Jev到底是什么？

Diogo Almeida：这个问题其实挺难回答的，但我是这么看这件事的：我们需要一种全新的模型类别。至于这一类别到底叫什么，我们没有执着于某个名字。

目前我们想到最准确的称呼是 System 1 模型。之所以没有把它称为“决策模型”，是因为System 1 的能力范围远远超出决策本身。我现在只能说这么多。我们原本没想到这次会成为一次这么受关注的发布，所以手里还有东西没有拿出来。

Swyx：你们当时就该说这是一次“低调的研究预览”。

Diogo Almeida：某种程度上确实就是，它其实真的有点像一个研究预览。总之，我们内部有几个词来描述出现的这一类新的模型。比如机器原生模型（machine-native）、System 1 模型、大型可编程模型（large programmable）。我的理解是，这类模型的目标，在于让代码成为模型输出的直接使用者。

预训练大语言模型最初面向的是互联网文本补全；经过 RLHF 训练的聊天和指令遵循模型，面向的是文本回复；RLVR 则和 RLHF 之间有一块界限不太清晰的区域。而我们希望这类模型的输出能够直接被代码消费，所以公司才会叫 TypeSafe。

我们真正想要的，是让 AI 尽可能强大。而我们认为，实现这一点的方式是让它与软件结合。因此，我们设计时考虑的不只是模型外部的使用方式，连模型深层的内部机制也要针对软件进行优化。Jev 是我们的第一个大型可编程模型，也可以叫 System One 模型，随你称它为什么。它的优化目标是“每美元智能”，Jev 这个名字也由此而来。

Swyx：Jevons Paradox，杰文斯悖论。

Diogo Almeida：对，就是杰文斯悖论。它的目标是实现性价比最高的智能模型。我特别喜欢跟人讨论，在可靠性、成本、校准和速度之间，到底什么最重要。Jev 这个名字以后会代表一系列站在“每美元智能”方面处于领先地位的前沿模型。当然还有别的优化方向。在机器学习里，至少对于擅长机器学习的人来说，一切都关乎取舍。而我们决定在这个方向上全力以赴。

从模式坍塌到校准失真：RLHF 的另一面

Swyx：我觉得“校准”是近来才开始受到关注的一个问题。我们之前请 Hugging Face 的 Clementine Foreia 做过一期节目，当时有聊到了这个话题。这也是你对 RLHF 的一个核心看法：模型的回答会向用户想听的内容，或者最可能出现的内容收拢，而不是反映它对一件事真正的内部置信度。

Diogo Almeida：我听说你们的听众技术背景很强，所以正想深入讲讲这个问题。发布视频里的每一项表述，我都花了很大力气核对，确保准确、真实。显然，这种做法还挺少见。视频里有一点几乎没人注意到，就是 RLHF 的缺点，尤其是“模式坍缩”（mode dropping）。

Swyx：mode dropping 还是 mode collapse？

Diogo Almeida：在这里我说的是一回事。以后我想专门写一篇博客，但现在我想尽可能把这件事讲给更多人听。我其实很认同 Yann LeCun 的不少判断。但他有一页很有名、也很有争议的幻灯片，大意是“大语言模型注定行不通”。

Swyx：你说的是那个“蛋糕”比喻？

Diogo Almeida：不是，是讲序列长度的那一页。他的推理是：如果生成每一步都有出错概率，文本越长，至少犯一次错的概率就越高。这个推理看起来在数学上很直观，但模型的实际表现并没有简单地照这个趋势发展。我很喜欢拿它来问：数学推导和观察结果之间，差异出在哪里？

Swyx：问题出在哪里？

Diogo Almeida：问题在于，如果模型试图覆盖整个分布，或者它的概率分布经过了良好校准，那么它不会因为产生少数离群结果而受到过度惩罚。你会预期它有时生成落在常见分布内的内容，有时生成分布之外的内容；覆盖整个分布，就会出现这种情况。你可以想想生成对抗网络出现之前的图像生成模型：它们生成的图像往往是模糊的。

而生成对抗网络会模式坍塌：它会直接丢掉占比很小的类别，只生成那些最常见的类别。也正因为如此，前面那个“序列越长错误必然累积到不可用”的效应并没有按最简单的方式出现。为了生成很长、又不容易出现明显错误的文本，模型就得极其保守，因为一旦犯错，人很容易看出来；相反，一个看上去没问题、其实遗漏了微妙之处的回答，就很难被察觉。为了让模型的概率分布保持校准而带来的要求，对文本序列的生成方式会产生很大的影响。这层关系很微妙。我认为，它既解释了为什么那种直观的错误累积推论没有应验，也解释了为什么文本模型不擅长决策：让本来用于生成文本的模型承担过多决策任务，效果往往不好。

Swyx：既然说到 Yann，你认同他的解决方案吗？也就是用世界模型，比如 JEPA 这一类嵌入模型的方法。问题的一部分似乎在于，我们让模型基于已经输出的词元（token）继续推理，再把输出送回去，反复循环，直到生成完整的一句话。Yann 提出的解法是联合嵌入预测架构（JEPA），你觉得这就是解决办法吗？你对此有什么看法？

Diogo Almeida：我可能不该把机器学习内部的事讲得太细。不过，除了说话有时比较放得开，我做事其实很务实。刚才对模型的判断也是从实际效果出发。

我是不是Scaling Law的支持者？要看它能带来什么。Scaling Law告诉你：投入一定量的资源，某项能力能提高多少。通常，资源投入要大幅增加，收益却不会同比增长。除非那一点能力提升非常有价值，否则看起来就不是一笔好投资。对我来说，更重要的问题是：用手头已有的资源，我们怎样才能带来最大的实际改变？

我的出发点始终是实用性。比如 Yann LeCun 的 JEPA 方向，我觉得早期研究很精彩，也很喜欢看到优秀的研究工作。至于它现在是否已经足够实用，我暂时不想下判断。

目前研究界还有很多没有被充分挖掘的好成果，像未经打磨的钻石。它们没有进一步变成有用的技术，部分原因是大家还没找到适合发挥其价值的任务。

Jev 的发布当然对 TypeSafe 有利，但我希望它带来的影响不止于此。一方面，开发者可能会基于 Jev 做出大量新软件；另一方面，也会有人沿着不同方向探索：还能用什么方式把模型能力提供给程序，让软件做出更多以前做不到的事。如果这些尝试同时出现，那种感觉就有点像早期互联网那种充满活力的氛围——大家纷纷探索，新的用法不断冒出来。我想这也是为什么推特上大家一提到“Jev”，就像在开派对一样。

Swyx：这很让人振奋，因为它和我们习惯听到的说法太不一样了。过去常有人说：“抱歉，这件事你做不了。模型研发要遵循缩放规律，只有大实验室才有资源参与。”

Jev 的开发理念：AI 做决定时，不能突然拒答

Diogo Almeida：Discord 上经常有人问我：为什么反对安全对齐，为什么 Jev 不会拒答？我还没来得及完整解释。先说清楚，我并不反对安全本身。我认为，常见的安全对齐方式往往与使用者的目标不一致；而对供程序调用的模型来说，突然返回一句拒绝，简直像是发生了类型错误。

如果你是人在和聊天机器人互动，或者用编程工具时碰到“抱歉，我不能读取 DNA.py”，当然会觉得烦，但至少你能看见它、换个办法继续。大家用久了，甚至习惯了处理这种情况。可如果模型是后台运行的软件依赖，某次调用突然拒绝了，会发生什么？调用它的用户可能根本不知道底下还有这个模型。难道只因为输入里出现一条特殊消息，就让整个软件流程随机中断吗？

我认为，这种设计沿用了“AI 是一个聊天同事”的想象，没有充分考虑模型作为软件组件时需要满足什么要求。

Swyx：你想要的是一种能在各种地方使用的基础能力。

Diogo Almeida：对，一个足够通用的“认知核心”。它要能适应未来各种我们现在想不到的用例。用户已经拿 Jev 做了不少出乎意料的东西，我们当然没针对那些具体应用训练过它。不过，这并不让我意外；我们训练时就让它处理过更多样的情况。

再回到安全对齐。我认为，对 ChatGPT、Claude 这种直接面向人的产品，设置安全规则是可以理解的。但需要区分能力对齐和安全对齐：能力对齐是让系统尽可能按使用者的要求完成任务。软件工程师很需要这一点——行为越可预测，越容易把模型集成进程序，也越少需要反复试探。

Jev 现在离理想状态还很远。我们希望把可靠性再提高几个数量级，最终让调用智能像执行数据库查询一样自然：需要时调用，不必每次都担心它会怎样回应。

而我所说的安全对齐，往往意味着模型除了遵循当前使用者的指令，还要优先服从模型提供方——比如 OpenAI 或 Anthropic——设定的另一套规则。这两套要求有时会发生冲突。

Swyx：你说的是不同层级的规则和价值取舍。

Diogo Almeida：对。对于直接面向用户的产品，这样做有道理。比如 ChatGPT 的提供方不希望产品支持某些成人角色扮演内容，那是他们的选择，也可能符合他们面向家庭用户的产品定位。

但 API 不一样。开发者需要根据接口的行为来写程序。如果模型在程序运行过程中突然按提供方的另一套规则拒绝执行，开发者很难处理。我对此确实有点激动，得让自己冷静一下。

Swyx：大家能感受到你很在意这件事。不过我想提出一个更严肃的反例：如果有人用这个 API 来杀人呢？成人内容或许属于私人选择，但 AI 也可能被用于战争。公司完全可以合理地决定，不希望自己的 API 被用于这类用途。

Diogo Almeida：我理解。企业可以出于实际考虑持有这种立场。我自己也不希望我们的技术被用来伤害人，当然希望它更多地用于有益的事情，也愿意为此作出努力。但我不认为应该把这些偏好直接写进通用技术的底层能力。

我的顾虑是，每当你为了某一种特定规则，强行让模型在某些问题上改变判断，就可能进一步割裂它的能力。现在的模型已经有不少这样的不一致了。

我更倾向于把智能看作数据库，而不是一位“AI 同事”。我们通常不会要求数据库在执行查询时，自行判断用户最终会不会把结果用于坏事。我认为，对通用智能接口也应该考虑类似的责任边界。

还有一件事让我觉得奇怪：有开发者在 Slack 上告诉我们准备部署某个应用，问“我们可以这样用 Jev 吗？”我的第一反应是：我们提供的是 API，你是开发者，具体应用怎么设计，不该事事由我们批准。理想情况下，复杂任务会被拆成许多较小的调用；作为底层服务提供方，我们甚至不应该知道下游用户的完整任务是什么。这种边界能给软件工程师更大的自主空间。

我希望他们把能力用于好的事情。我们也讨论过开源、公益支持等办法，只是眼下还没精力落实。但只要由我负责，我就不希望把这些价值偏好直接固化进模型的底层判断里。

Swyx：既然说到平台与开发者的关系，也想澄清一下你们的隐私条款和使用条款。之前有些人产生了误解，觉得你们对 API 用途限制得很严。

Diogo Almeida：我不确定你具体指哪一条，不过我看到过一些关于基准测试的讨论。

Swyx：对。你之前公开说过，相关限制是预览期条款里留下的，正式发布时没有及时移除，团队准备修改。

Diogo Almeida：团队有些进展我甚至还没跟上。我请他们和律师确认这件事。我们显然不打算阻止用户测试和比较模型；恰恰相反，我支持他们这么做。

但这和我怎么看公开基准榜单是两回事。我非常不喜欢公开榜单。至于用某些内部基准作为实际能力的替代指标，我的态度也比较审慎。

Swyx：你担心的是榜单很快饱和，还是模型可能见过公开测试题，因此容易刷分？

Diogo Almeida：刷分容易，是原因之一。假设两年后，市场上有很多公司在做与 Jev 类似的产品，我们提供的价值可以说是“每美元获得多少智能”，或者“每秒获得多少智能”。大家很容易盯着价格和速度，因为它们好测量。但价格和等待时间是用户付出的成本，用户真正想得到的是有用的智能。

难就难在，模型到底有多好，有些部分很难用一个分数概括。Jev 发布后，开发者亲自试用产生的反应，甚至比发布视频更让我在意。他们感受到模型在实际使用中的表现，也感受到我们为此下了多少功夫。

公开基准想用数字帮助大家建立信任，但它太容易被针对性优化。即使团队主观上不想刷榜，也可能不断收集与测试集相似的数据，让模型在榜单上表现更好。过去有些实验室收集类似 MMLU 的题目来训练，在我看来，这不过是绕了几步优化基准成绩。

所以我认为，开发者可以先凭实际体验建立初步判断，随后必须把模型放进自己的工作流，测量它在那个具体任务上的表现。我们的工作则是持续提高可靠性，让它越来越值得信任。可靠性始终是 TypeSafe 要解决的问题；如果只想尽早发布一个能力不够好的版本，我们一年半前就可以推出 Jev 了。

“最苦涩的教训”：先选对任务，再谈模型和数据

Swyx：你前面提到自己的“最苦涩的教训”（The Bitterest Lesson），我们来展开讲讲。

Diogo Almeida： Sutton 的“苦涩的教训”强调算法和计算的重要性。但在我看来，数据比算力重要得多；而最难、也最重要的，是先选对任务，找到研究的 North Star（核心目标）。

大语言模型的发展中，研究目标发生过几次这样的转变。RLHF 把重点转向指令遵循，当时没人意识到模型能在这件事上做到那种程度。RLVR 又把方向往前推了一步。现在，我们用 RLCD 定义了另一个任务：让程序能够把模型放进运行流程，可靠地调用它的判断。数据对此至关重要。我怎么强调都不为过。

Swyx：所以你们更愿意把 TypeSafe 称为一家“数据实验室”，而不是“模型实验室”？

Diogo Almeida：完全正确。我们会一直非常重视数据。对我来说，模型能力的提升，很大程度上就是数据问题。数据工作极其复杂，却也能把可靠性一位一位地往上推。数据选取和处理方式稍有变化，结果就可能大不一样。

Swyx：你们也在大量招聘数据人才。怎样才算优秀的数据工作者？你说过你们使用合成数据，但“数据是合成的”显然只说到了表面。是不是还要有人认真检查这些数据，指出问题，再回去重新生成？

Diogo Almeida：是，但完整回答会复杂得多。我给新入职的数据同事做的培训，可能比这期播客还长。这里先讲最重要的几层意思。

首先，任务决定数据的形态。RLVR 需要的数据在某种程度上是供模型探索的环境；RLHF 需要人类反馈。每种任务都有自己的数据形式，我们也一样。所以我们做的合成数据，并不是一个通用模板生成出来的东西。

其次，我们不想用用户数据训练模型，即使取得许可、技术上也做得到，我们仍不想依赖它。真实世界的数据有很强的偏向：很多人反复提出相似问题，需求呈现幂律分布。直接按这些数据训练，模型容易对高频场景过拟合，其他能力反而变得不均匀。

我们瞄准的是多年后的应用。到那时，模型也许会成为深入软件技术栈各层的通用基础设施，支撑今天还没人想到的产品。如果打个比方，可以把一般的大语言模型想成 UDP，把我们的模型想成 TCP：开发者能在上面构建各式各样的应用。即使我们拿到了今天所有用户数据，它也只能让模型更适应今天，未必能帮助开发者做出未来的软件。

因此，数据团队的工作有点像艺术创作。他们研究模型的“认知核心”，找出能力不平整、不稳定的地方，再有针对性地处理。我们认为自己的模型在这方面已经相对平滑，但不可能做到完美。一次修正最好能改善一类问题，在过去、现在和未来不同情境下都有效，而不只是修好某一道题。

Swyx：解决普遍问题，而不是只解决一个具体案例。

Diogo Almeida：正是这样。每次做到这一点，都需要很强的判断力。

“Jev 出现之前的 AI 世界，是个悲剧”

Swyx：你刚才说，我理解数据的方式受 RLVR 影响很深，这个批评挺公允的。那我们具体聊聊 RLCD。你们目前还没有发表介绍它的论文，对吗？在不了解技术细节的情况下，大家怎样判断 RLCD 确实代表一种不同的方向，而不只是一个新造的术语？“校准”这个概念我能理解，但 RLCD 与大家熟悉的 RLHF 究竟有什么区别？

Diogo Almeida：还没有发表论文。你的问题很好，不过要回答它，我想先反问一句：RLHF 指的是什么？

这个词在不同时期指过好几种工作。最早有通过人类偏好反馈，让系统学会完成难以精确规定的任务的研究。我记得有一项工作涉及教机器人做后空翻，可能与 Paul Christiano 等人的研究有关，但具体是哪篇，我也不能完全确定。PPO 是一种算法，并不天然意味着奖励一定来自人类反馈。

后来 OpenAI 做了“学习摘要”的工作，把 PPO 用在语言模型上，让模型学习完成摘要这类很难用简单规则规定好坏的任务。人们也会把这称为 RLHF，不过我没有参与那篇论文。

但当我说 RLHF 时，我更想强调的是指令遵循这个任务，而不是某篇论文采用了 PPO。真正重要的，是研究者确定了一个新的 North Star：让模型理解并遵循人的指令，是一个值得持续优化的方向。今天的 DPO 及其后续方法即使没有使用那篇论文里的算法，也仍是在做这个意义上的 RLHF。

同样，RLCD 对我们来说是在提出一个新的任务目标。我使用这个名字，是想准确说明我们在优化什么：让 AI 能被程序调用，成为软件可以使用的能力。

Swyx：也就是说，关键词是“可编程的 AI”：让程序能够在不需要人每一步介入的情况下使用模型，进而自动化更多工作。我理解你的 North Star 对吗？

Diogo Almeida：对，但还要加一个前提：必须务实。我们得看清当前语言模型实际擅长什么。有些面向程序的新输出类型在概念上可能很棒；如果技术还不足以让它可靠工作，暂时不推出，也没什么可遗憾的。

在我看来，Jev 出现之前的 AI 世界，简直是个悲剧。这话听起来很狂妄，但这个想法在我创办公司很久以前就有了。

Swyx：这点我可以作证。你已经谈了好几年。

Diogo Almeida：是。我起初以为做出一个能供程序调用的模型不会太难，整个项目一周就能完成。事实证明我错得离谱。以前我甚至觉得：“这个问题我马上就能解决。”现在想来，我得向当时被我低估的 OpenAI 同事道歉。

AI 领域还有另一件令人遗憾的事：承诺很大，实际交付却跟不上。我认为 RLHF 和 RLVR 路线都存在这个问题。但让我一直放不下的，是 AI 明明已经表现出很强的能力，却仍有大量简单工作无法自动化。

我在演讲时常问：为什么 AI 能处理极其困难的数学问题，却连许多基础、重复的工作都接不过去？这些工作不要求人有多高的智力，也谈不上令人满足，但现实中仍得有人做，因为软件还没法可靠地把它们自动化。我们已经有了一台很强的“智能引擎”，却缺少合适的接口，把它接进那些有经济价值的流程。

即使有一天 TypeSafe 不复存在，这个方向也已经被打开。别人也许需要一两年追上来，也可能更快；如果模型质量的差异持续重要，我们会有更长时间的优势。但比公司竞争更重要的是，整个领域开始探索：智能还可以怎样接入软件。我相信这会改变技术接下来的发展路径。

Swyx：我完全同意。你们真正创造的是一种新的可能性。我试着替你概括一下，方便大家理解：不要把 TypeSafe 和 Jev 的成功看成仅仅是“出现了一种新的模型类型，我可能可以继续沿用之前的路径去做事”。不是这样，实际上，可能还有好几种别的模型类型值得探索，这个行业应当是百花齐放的态势，应该让各种尝试奋都发展家里。其中有些方向，你们大概也会亲自去做。

Diogo Almeida：完全正确。那种早期互联网的活力又回来了。我觉得我们重新回到了某种技术乌托邦时刻，再也不用像以前那样感慨：“唉，有时候我的编程智能体能工作，但真正最好的东西都被公司内部藏起来了”。创造新东西又成了一种真实的可能。当然，接下来会是一个相当疯狂的世界，大家最好坐稳了。我对此兴奋极了。

Swyx：现在你们有了资金，也有了发布后的势头，终于能把想法做出来给大家看。

Diogo Almeida：对。以前一直讲，却不能把最关键的东西拿出来，感觉像总在吊大家胃口。我的演讲尤其如此：我说 AI 应该推动自动化，却没法展示它具体怎样做到。你之前看过我们的宣言，还说有些地方写得太模糊：“第一步是什么？你们说的智能模型究竟是什么？”

Swyx：我当时问你模型在哪里，你只说“快有了”。我主要对“可组合”这个词有意见，不过 “Build Prod, Not God” 这句口号很好。

Diogo Almeida：谢谢。团队很认同这句口号。我们对正在做的事很兴奋，但大家也很务实。

Swyx：宣言里还有一份“秘密总体计划”，讲怎样一步步构建面向机器、可组合的 AI。

Diogo Almeida：写成“秘密总体计划”是你的建议，我得正式把功劳记给你。

Swyx：谢谢。不过你当时只给我看了一半故事，没有告诉我还要发布模型。那时候也没有《Doom》演示，没有性能数字，我自然会问：你们到底打算拿什么证明它？

Diogo Almeida：问题是，我不相信公开基准榜单能证明这件事。模型好不好，最终得让人放进实际任务里体验。这种做法有助于建立长期信任，但也让我们吃过苦头。去年融资时，很多人不相信我们，只想看基准测试成绩。我们不愿意为了拿出好看的数字，去迎合一套容易奖励刷榜行为的评价方式。

Swyx：选择这条更难的路，最后也让你建成了一家自己愿意待的公司。

Diogo Almeida：是。我不太后悔这个选择。昨晚聊到为什么离开 OpenAI，我还挺激动的。发布前，我常这样想：如果 AI 最终因为承诺过多、实际交付不足而进入新一轮低谷，而我没有尽力探索另一条路，我会觉得自己也有责任。一方面，我参与过 RLHF 这条路线；另一方面，我相信让 AI 真正进入软件自动化，能创造很大的价值。

发布后，我对这件事的说法有些变化。至少在我看来，自己担心的那种“AI 寒冬”已经不那么不可避免了。 Jev 上线还不到一周，我已经看到开发者把它用在真实工作中。眼下就像西部拓荒时期一样，充满了未知，各种尝试都在冒出来。

爆红之后，Jev 更在意什么

Swyx：能不能分享一些发布之后的具体数据？例如注册的用户数量之类的。

Diogo Almeida：具体数字主要是团队在跟进，而且每天都在变。不过有一个里程碑我记得很清楚：日调用量已经超过一万亿 Token。这不是发布当天大家尝鲜带来的短暂高峰。夜里调用也没有停下来，说明有程序在持续使用 Jev，而不只是人在界面里试几次。这让我特别兴奋。

相比之下，我没那么在意注册人数。我们发布时没有专职营销人员，大家看到的宣传基本就是团队自己的表达。候补名单一度增长很快，我们也在不断放人进来。平台团队承受住了这次发布带来的流量，做得非常出色。

但我们后来意识到：对开发者平台来说，候补名单上的人数并不能说明多少问题。其中可能有不少人不是开发者。他们进来试了几个问题，发现 Jev 不是聊天机器人，就会疑惑：“我的下一个 ChatGPT 在哪里？”我还没有精确计算过，不过我的直觉是：哪怕全世界每个人都来试几次，调用量可能还不如一个真正用它创造价值的开发者写下的一段循环程序。

我们起初以为，放多少人进入候补名单需要非常谨慎。后来发现，更紧张的是速率限制：开发者一旦把 Jev 用进程序，获得了实际价值，就会希望大幅提高调用额度。软件就是这样运行的——先花时间定义一个重复任务，之后让它持续执行；只要创造的价值超过最初投入，就可以把它放到后台，再让其他功能依赖它。

Swyx：设置好，让它自己运行。

Diogo Almeida：对。之后开发者还能在这些能力之上构建更复杂的东西。许多早期互联网的创造，正是通过不同软件能力的组合才发生的。虽然你不喜欢“可组合”这个词，我仍想在宣言里强调它：我们希望 Jev 成为催化剂，让开发者做出连我们也没预料到的应用。为此，我愿意继续在 Discord、公开交流和播客里跟他们沟通，哪怕要在直播里套个垃圾袋出镜。

Swyx：长访谈也有这个好处。我们可以越过发布初期比较表面的讨论，让人理解你们究竟想做什么。认同这个方向的人，也许会加入团队，或者“买下你们”——抱歉，我是说成为客户。

Diogo Almeida：哦，作为客户（笑）。

Swyx：对，作为客户。发布视频也确实很受关注，刚才看到是 3600 万次播放。

Diogo Almeida：现在到 3800 万了。

Swyx：如果只看 2026 年新兴 AI 实验室的发布声量，你们可能排在最前面。

Diogo Almeida：谢谢，不过我不太在意“新兴 AI 实验室”这个标签。我们还有周边专门拿它开玩笑，比如“你最喜欢的新兴实验室最喜欢的新兴实验室”，以及“有产品的新兴实验室”。

我真正想做的是一个可靠的开发者平台。希望发布热度过去之后，开发者仍能长期依赖它、信任它。

模型不能说变就变：Jev 如何兑现“可靠”？

Swyx：你们一直强调可靠性。我原以为主要指 RLCD 里的概率校准，但看下来，它也包括服务可用性、扩展能力，以及常说的“几个 9”，对吗？

Diogo Almeida：那些都是可靠性的一部分。但模型的判断本身也要可靠：它能不能持续完成你希望它做的事？现在的大型推理模型很聪明，可在我看来，仍有不少任务是它们看起来足够聪明、企业也有动力自动化，最后却不敢交给它们做，因为结果还不够稳定。我们离理想状态也有很长的路要走。

我想先把容易的工作自动化，再去处理难的工作。我的目标是，有一天开发者需要一处智能判断时，可以像写数据库查询一样，直接在程序里写一个类型安全的 System 1 调用，让程序准确地走向相应分支，而不必每次都先试探模型能否胜任。这会是一个漫长的过程。

Swyx：说到可靠性，我注意到 API 里没有随机种子（seed）参数。同样的输入，每次都会得到同样的输出吗？如果不会，为什么？

Diogo Almeida：这是个好问题。“可靠性”其实是一个总称。AI 无法自动化某件事，可能是输出不符合类型要求，可能是结果不确定，也可能是能力分布不均匀。你问的确定性，指相同输入得到相同输出；它对单元测试等场景可能有价值，但我不认为它应该是首要目标。

我更重视稳健性：语义相近的输入，应该得到相近的判断。大语言模型在这一点上有时很不可靠。我们的一个测试办法，是在提示词里加入不同的 UUID 作为随机标记。问题的实际含义没有变，只是多了一个无关的字符串；模型的判断就不该因此大幅变化。开发者在让 AI 做决定时，常常会被这种细微变化导致的结果波动坑到。

当然，我们也可以做确定性模型。如果开发者能告诉我们它在哪些场景确实重要，我们愿意考虑。但确定性可能需要在成本与能力之间作取舍。我们一直努力站在“每美元智能”的帕累托前沿，为此尝试了很多不那么常规的模型组合与工程方法。

Swyx：所以，回到最初的问题：将来会不会提供随机种子或确定性模式？

Diogo Almeida：有可能。只要需求足够明确，而且我们没有被 GPU 资源严重卡住，就可以做。只是按我们目前的判断，它可能降低每美元能提供的有效智能。

Swyx：从 OpenAI 和 Anthropic 的发展过程看，我猜开发者迟早会要求这个功能。即使你告诉他们稳健性更重要，他们可能还是会想要确定性。

Diogo Almeida：那就看后面会怎样吧。有人说我们品牌的一部分是“立场坚定”，其实就是委婉地说我固执。

Swyx：但我以前和你争论过。证据充分时，你也会改变原先的判断。

Diogo Almeida：是，你在开发者需求方面说对过很多次。这一点我认。不过，我怀疑我们会在很长一段时间里受到 GPU 供给限制。如果一种方案提供同等智能却消耗更多 GPU，我们就更难让更多人用上它。我们当然希望服务企业，但眼下更想让尽可能多的开发者拿到 Jev，去实验、去做那些出乎意料的东西，让这个方向真正热闹起来。

Swyx：这种探索已经开始了。不过我想提醒你一个开发者可能会担心的问题：你说会尽一切办法提高“每美元智能”，又面临 GPU 限制，大家可能会猜，你们会不会在发布后把模型进一步量化，以节省显存或带宽，却让同一个模型的质量下降？

你现在不一定要作承诺，但至少应该考虑明确告诉开发者：已经发布的模型，其质量和行为会不会保持稳定。过去有些 API 虽然模型名称没变，背后的模型却变了。你们现在有版本号，这是好事；还可以进一步说明，同一个版本上线后是否会保持不变。

Diogo Almeida：已经部署的模型，我们不会悄悄改动。对开发者来说，那太离谱了。直接面向用户的产品可以持续调整背后的模型，只要产品体验变好就行；但 API 是别人程序中的依赖，不能按同样的方式处理。

不过，我们更新模型的速度可能会比大家习惯的快得多。我们会不断发布新版本，也暂时不能承诺每个旧版本都有长期支持，因为还有很多改进要做。眼下有不少人在使用 Jev 1.13.0，我们可能会暂时把它作为长期支持版本；我知道开发者不愿意看到依赖突然失效。

另一方面，如果每发布一个版本就永久保留，推理服务可能要同时运行大量不同模型，这也会给所有人带来负担。

Swyx：更新快的话，可能很快就有上百个版本要维护。

Diogo Almeida：正是如此。我们希望将来找到比简单保留某个长期支持版本更好的办法，团队正在研究。我认为那会对开发者很有帮助，但现在还不能把尚未实现的方案当成承诺。

可以确定的是，我们会继续推出能力更强的新模型。按我的观察，Jev 在相邻版本之间的行为差异，通常甚至小于一些生成文本的模型对同一个请求调用两次产生的差异。但如果我们解决了模型能力中某个明显不稳定的部分，新旧版本之间就可能出现很大的变化。

不追 Benchmark，追极致的“每美元智能”

Swyx：模型有了长期支持版本（LTS），还有一个好处：你们可以把同一个版本移植到其他芯片平台上运行。不知道你们有没有考虑过这件事。

Diogo Almeida：暂时不评论。我更关心的是“每美元能获得多少智能”。

Swyx：但速度也重要。

Diogo Almeida：这要看后续情况。

Swyx：过去一年，推理技术路线发展得很快。比如，把模型放到 Cerebras、Etched 这类芯片上运行，速度可能会有大幅提升。

Diogo Almeida：对。“每秒能获得多少智能”是另一个衡量指标。我们内部甚至讨论过把成本和时间放在一起衡量，比如“每美元、每秒能获得多少智能”。

对于 Jev 系列模型，我在内部反复强调的一点是：模型变得更聪明当然好，但它必须处在帕累托前沿。也就是说，在同等成本下，它要尽可能强；达到同等能力，成本要尽可能低。这就是 Jev 的定位：把每美元获得的智能做到最好。

至于每秒能获得多少智能，还要继续看。这个方向很有意思，我也知道有不少行业高度依赖实时响应。对它们来说，速度的提升直接对应着很大的经济价值。我当然希望两个指标都能做好，也希望从市场和用户的反馈中判断，究竟该把重心放在哪里。

Swyx：而且速度不只关系到实时场景，也关系到规模。到了足够大的调用量，哪怕每次只差几微秒，乘上数十亿、数万亿次，也会变得很可观。

Diogo Almeida：如果是大型数据库 MapReduce 查询这类后台任务，延迟可能没有成本那么重要。这也是 Jev 的定位：尽可能提高每美元所能获得的智能。至于“每秒智能”，还要继续看。我很喜欢那些对速度要求极高的应用场景，也知道对一些高度依赖实时响应的行业来说，速度提升能带来很大的经济价值。这方面的需求正在增长，很有意思，但我不认为它会成为 Jev 的主要方向。

Swyx：说到“更快、更便宜”，其他模型通常给出的取舍是速度更快，但价格也更高。我在想，Jev 之所以受到关注，一个原因是你们做到了更快、同时更便宜。这一块目前选择不多，前提当然是模型的智能水平大致保持不变。

Diogo Almeida： “智能水平保持不变”这句话很关键。难就难在这里。

Swyx：但你似乎不太认可公开基准测试，或者至少不喜欢用现有的公开基准来证明这一点。你们内部总得有一套判断方法吧？

Diogo Almeida：当然。我们有自己的内部评测。不过，要避免团队有意无意地针对评测做优化，需要很强的自律；这件事必须得到最高优先级的重视。

否则，我们凭什么说自己的模型处于“每美元智能”的帕累托前沿？我们不是凭感觉做决策。尝试不同方案时，成本和能力都会变，我们会测量、比较，把结果放在一起看，判断哪种方案对用户最好。

所以，我并不反对评测。我担心的是，一旦掺入其他激励，评测就可能变得很危险。在这件事上我管得很严。同事们也许会觉得我在很多事情上都管得严，但对我来说，不能在模型到底有多聪明这件事上自欺欺人，这一点尤其重要。我们得诚实地追求事实。

Swyx：同意。接下来我想聊聊 API 设计上的一些具体选择。

别让 AI 一口气干完：把任务拆小，出错才好查

Swyx：你们定义了三个基础概念：Choice、Score 和 Noul（又名Noulli）。先说 Noul，这个词是从哪里来的？是文献里已有的术语吗？

Diogo Almeida：现在算是了（笑）。我们为名字讨论了很久。它有点像布尔值（Bool）：涉及“真”或“假”，但它的取值是连续的。名字来自伯努利（Bernoulli），更准确地说，是取了 Bernoulli 的一部分，因为它表达的就是伯努利概率。

我们当时还考虑过 PBool、Pool 等名字。我甚至想把它叫作“pool party”，但没人同意。最后大家觉得 Noul 最合适。我们这群人起名多少有点不按常理出牌，Jev 也是这样。最初我们以为，对程序员来说，Jev 不过是代码里的一个字符串，没想到这个名字后来还衍生出不少双关梗。当时内部有很多人反对这个名字，现在除了一个人，其他人都向我道过歉了。

回到 Noul。我们需要为它创造一个新概念，因为如果直接叫 Bool，会让人误解。事实上，Choice、Score 和 Noul 都是我们有意单独定义的概念。它们与编程语言中的现有类型很接近，但并不完全相同。比如 Score 不是整数。如果通过 Instructor、Pydantic 之类的工具，直接把整数或浮点数映射成 Score，就可能出问题。我们更倾向于把含义说清楚，即使这会增加一些初次理解的成本。

Swyx：但你们不担心集成问题吗？开发者通常希望它能直接接入自己已经在用的工具。你们有自己的 SDK；如果我是开发者关系负责人，我可能还会特别在意：怎样把 Jev 和 Instructor 一起用？怎样接入其他工具？

Diogo Almeida：我们确实希望做好这些集成。相关示例也许已经有了，只是我现在跟不上所有更新。社区里也会有人做。支持社区这件事没有一个“完成”与“没完成”的二元状态，我们总还能做得更好。说实话，聊到文档我有点紧张，因为录制前没来得及重新看，而文档又一直在变。

至于这三个概念，Score 其实并不难理解。它接近用语言模型做评判（LM judging）时得到的评分，也可以把它叫作一种“判断结果”。Noul 也可以被看作概率，但在我们的体系里，模型输出本来就带有概率性质。Choice 则最接近函数调用，不过我对现有的函数调用设计有不少意见，这个话题我们可以稍后再展开。在代码中，Choice 更像是把 switch 或 match 语句要处理的选择，直接作为 API 输出。

Swyx：也就是说，它可以很自然地对应枚举（enum）；如果需要，开发者再根据选中的项调用相应函数。

Diogo Almeida：对。关键是先得到那个“选择”。这三个概念都可以对应到基本的程序控制方式：Choice 对应基于枚举的 switch 分支，Noul 对应 if 条件判断，Score 对应排序，或者通过“大于”“小于”的阈值来筛选。这一直是我们的设计方向。以后还会有更多类型，也会继续与程序中的基本操作对应起来。

Swyx：对于准备深入使用 Jev 的开发者，还有什么 API 设计上的细节值得讲？比如这些概念具体怎么用，图例、置信度该怎么看，测试中又该注意什么。你是最了解它的人，我想多给他们一些实际建议。

Diogo Almeida：谢谢，我很喜欢这个问题。没想到会聊得这么细。除了几个月前给我们的开发者关系同事做入职培训，已经很久没人这样问我了。

我们设计模型时，想的是让它将来能深入计算机程序内部工作。我们相信，这类用途的规模会远超今天人们的想象。模型现在也许还没准备好，但我们一直在朝这个方向推进。我们的目标不只是让它在相对浅层的任务上不断提高分数，而是让它进入程序的核心逻辑，因为这样才能让软件具备更强的能力。

刚才说的 Choice、Score 和 Noul 是输出形式。输入端同样可以有结构：状态（state）、指令（instructions）、判断标准（criteria），都可以是结构化的 JSON 对象。程序可以把这些信息准确地放到需要的位置，开发者不必先把它们塞进字符串模板。

很多人可能没注意到这一点，以为这些输入都只是字符串。用模板拼出一条系统消息，当然也能工作，但那延续的是过去处理模型输入的方式。既然信息本身有结构，就应该尽量保留这种结构，让计算机直接处理。写普通程序时，我们不会先把所有数字转成字符串，再传给程序内部的其他部分。转成字符串通常是为了展示给人看；程序内部传递的，应当是有明确含义的嵌套结构。

我们也在持续优化模型处理这类输入的能力。它现在已经能处理结构化信息，但嵌套每增加一层，推理难度也会提高，所以这仍是我们重点投入的方向。我也希望开发者更多地采用这种方式：代码会更清楚，也不必过度依赖底层实现细节。

可以把它想成调用一个 AI 函数：程序当前有一组状态，也就是可用的变量；你需要决定，哪些状态应该传给这个函数。相比之下，一条包罗万象的系统消息很像一个混乱的全局变量：把所有信息、所有指令都放进去，然后指望模型一次满足每项要求。很多问题其实可以拆开，并行地问。

我很建议大家多向模型提问，把问题拆小、拆细。我这么说不是为了增加调用量。无论当前模型能否一次完成复杂任务，把问题分解成简单决策，都会让 AI 应用的代码更好维护；而且每个小决策都更容易单独评估。

过去我们常常给模型一大段系统消息，等它返回一大段结果，再检查它有没有遵守其中的每条要求。现在回头看，这种做法挺不可思议的，只是大家已经习惯了。比如“不要读取这个子目录”“不要把 API 密钥传给 DeepSeek”，这类约束应该尽可能由程序保证。机器学习模型本身无法给你绝对保证，但把任务拆开之后，至少可以逐项测量、验证。

Swyx：比如可以核查某个操作到底有没有执行。

Diogo Almeida：对。我们的接口本身就很容易验证，这会让工程实现可靠得多。

Swyx：我理解这个思路。不过，以前大家不这么做，也有现实原因：即使用小模型，把任务拆成很多次调用，仍然可能又慢又贵。我自己做过对比：一条流程把所有要求放进系统消息，只调用一次、拿到一个完整输出；另一条流程把任务拆成上百个问题。后者更慢、更贵，结果还不如前者。

Diogo Almeida：确实会发生这种情况。拆分任务也很麻烦，调用之间可能还得重复传入一些信息，看起来不够高效。于是人很容易想：为什么不一次性把所有东西都放进去？但那样得到的系统往往很难依赖。我希望我们的模型能够支持大量在后台运行的程序调用；如果做不到，我会很失望。

Swyx：那具体应该怎么拆？你们有没有发现什么有效的方法，或者发现哪些原以为可行的拆法其实不行？开发者听完之后可能会照着这个思路使用 Jev，但他们首先得知道从哪里下手。

Diogo Almeida：我倾向于把问题拆到最小的语义单元：先找到其中最基础、能够独立判断的那件事。我可能是使用我们模型最多的人之一。提问时，我会尽量把输入写得结构化、明确；在问题里清楚指出所引用的内容，有时会用反引号把它标出来。我希望模型尽可能按字面准确理解要求。编程本来就要求指令得到准确执行，而 AI 扩大了程序所能执行的指令范围。

我自己偶尔也会图省事，把几个判断混在一个问题里。但如果是大型生产系统，我会不断增加独立的问题，并且让新增问题这件事足够容易。每个问题负责什么，要拆得清楚；最终的具体行为则由代码来控制。

举个小例子：拒绝回答。我不建议只问模型一句“这里要不要拒绝？”这个问题它或许也能答得不错，因为这是一个适合快速直觉判断的任务。但更好的办法是，针对不同的拒绝情形分别提出独立的问题。这样，你就能明确规定自己希望系统如何处理各种情况，而不是让模型自行猜测。

更妙的是，如果后来发现某种情况没有触发拒绝，原因是你漏写了一项条件，这其实是一个很好的工程问题：补上那个问题，设置阈值，再把这个案例留作测试。修正就留在程序里了，不会因为提示词变长、上下文中的早期信息失效而被“忘掉”；你也可以持续测量它。如果模型对某项判断还不够准，还能根据真实案例调整相应阈值。整个过程有点像在做机器学习系统，但你不需要为每种情况重新训练模型。

当然，有些任务可能仍超出了模型当前的能力。比如看到有人用模型做自动交易，我会有点担心。这件事看上去很酷，但任务本身复杂、风险也高，最好交给专业人士。即使把它拆成若干判断，你也可能通过评测发现：模型在某一步还不够可靠，那这一版就先不要部署，或者调整方案、选择更保守的处理方式。

客户服务也一样。假设模型还不能可靠识别“VIP 客户在说反话”这类特殊情形，你就可以规定：遇到这种情况，转交人工处理。置信度估计也是为这样的决策服务的。

Swyx：你刚才提到，开发者可以通过设置阈值，决定什么情况下采用模型的判断。但如果模型的概率校准本身就有问题呢？一个校准良好的模型，至少应该让较低的分数对应较低的实际发生概率，较高的分数对应较高的概率。现实中，两者也可能对不上。这时我可能想微调模型，而你们目前没有提供这个功能。

Diogo Almeida：我没有说模型的校准是完美的。微调当然是我们可以考虑的方向。

Swyx：微调是一种可能，也可以是别的调节手段。现在听起来，如果模型判断错了，用户能做的就是改提示词、把问题拆得更细，或者调整置信度阈值。如果模型确实不擅长这件事，这些办法不一定让人满意。

Diogo Almeida：没错。先说清楚，模型会在很多事情上犯错。我们有问题反馈按钮，大家也可以在 Discord 告诉我们哪里出了问题。我们希望持续改进模型，每个新版本都应该有明显提升；如果没有足够大的进步，我们就不会保持现在这样的发布速度。

承认 AI 在某些任务上还不够好，是务实的做法。同时，“足够好”也取决于具体用途。人也会把工作做错，但只要总体预期收益足够高，很多工作仍值得由人来做。模型也类似：通过合适的阈值和其他控制方式，即便它会出错，仍可能承担相当多的工作。

至于微调，我能想象我们以后会提供，但我有一些顾虑。用户想要的功能和真正对他们有益的功能，不一定完全相同。通用模型有一种很难说清的优势：它会处理大量其他任务，这种广泛的能力，可能也让它在某个特定任务的边缘案例上表现更好。如果只针对一个狭窄任务做微调，我会担心失去这部分能力。

所以我的回答是：有可能。我在这些事情上很务实，我们想做的东西还有很多。但我也不想推出一个看似有用、实际却很容易让用户把系统用坏的功能。

Swyx： OpenAI、Claude，可能还有 Gemini，都曾推出过微调功能，后来又撤回或收缩了相关服务。这也挺有意思：现在微调似乎更多发生在开源模型领域。

Diogo Almeida：我知道这些情况。有些微调产品的效果确实不好，撤下来也许是对的。

Swyx：所以，告诉用户“微调可能不是正确的解决办法”，也说得通。另一种回答是：你们的模型与通常的大语言模型差异很大，就像量化、输出 Token 这些概念未必适用于它，微调也可能不适用。

Diogo Almeida：我对这种可能性也持开放态度。不过下面说的是我的设想，不是产品承诺。

随着“每美元智能”的成本继续下降，也许我们能用很小、成本很低的模型，完成一些过去要靠手写规则处理的判断。举个例子：会不会有一天，人们不再需要自己写正则表达式？因为用 AI 完成同一件事的成本，已经低于编写和维护正则表达式所带来的复杂度。我会很乐意看到那一天。对于其中一些狭窄用途，微调也许恰好能让模型的表现跨过可用的门槛，还得继续看。

我希望概率校准加上模型级联，也能解决一部分问题。比如，小模型对某个判断非常有把握，就直接采用它的结果；如果置信度落在中间地带，再交给更大的模型，必要时继续往上一级处理。我还不知道最终哪种方式效果最好。

还可以设想另一种用法：我们提供一系列处于帕累托前沿、规模各不相同的模型。熟悉技术的开发者也许愿意自己选择，但企业可能更需要动态调度：系统根据技术栈中不同环节所需的判断能力，自动选择合适的模型。考虑到我们的接口相对简单，这套机制甚至可能结合某种自动微调。

重申一下，刚才说的动态选模型、自动微调，都不是产品承诺。我只是在畅想一种有点像科幻的未来。

“决策模型早就有了”，Jev 到底想做什么？

Swyx：但你们会考虑推出不同规模的 Jev 模型，让用户有得选？

Diogo Almeida：当然。用户到底需要多强的智能，我怎么可能事先知道？

Swyx：需求可能是无限的。

Diogo Almeida：也有人劝我们，现在的产品已经够好了，不用急着发布新东西。但我不太喜欢“够用就停”的想法。有句话我很认同，大意是：市场不奖励你做一件事时，你仍然坚持去做，那才体现出你的文化。我希望大家以后也拿这句话要求我，因为说出口之后，就很难反悔了。

也许有一天，我们坚持的东西会变得理所当然，公司会像 Visa 一样，成为人们平时不会特别留意的基础服务，到时候我可能连粉色西装都不穿了。但现在，我还想让更多人看到这条路的可能性。我们会继续做有意思的事，并不是因为当前产品非改不可，而是因为今天大家看到的才刚刚开始。第一次发布更像是一次低调的研究预览，远不是我们能做的全部。面向机器的智能（machine-native intelligence）还有很大的空间。

Swyx：所以，将来可能不止一种模型规模，也不止目前这一款模型？

Diogo Almeida：没错。我们希望尽可能满足不同需求。但我得加一个重要前提：我不想像一些产品团队那样，什么想法都往外推。我们做的东西应该服从一个统一的方向。回看我们的宣言，未来的尝试都应该落在其中三个方向之一。

Swyx：我没准备好在这里逐条聊那份宣言。

Diogo Almeida：抱歉，我说得像是在故意吊胃口。我的意思是，那三个方向不是一张待完成的清单，而是我们认为足以支撑下一轮技术变革的三条轴线。我们做的每一次尝试，都应该能在其中找到位置。模型方面，我们也会做一些看起来挺奇怪的东西。

既然是“面向机器”的智能，就不一定非得让人一眼看懂它的形式；关键是它有没有实际价值。

Swyx：能透露一点吗？“奇怪”会是什么样？

Diogo Almeida：给个提示吧。有人想把我们的模型叫作“决策模型”，因为目前的几个基础概念都与决策有关。但我不会这样命名：未来还可能出现其他面向机器的输出类型，它们未必是决策。

Swyx：好，那就留给大家猜。

Diogo Almeida：这个提示已经挺有意思了。

Swyx：现在也有人说：“决策模型我一年前就做过了，Jev 没什么新鲜的。”但我觉得，一方面，你们展示了这类模型可以怎样成为一个独立的产品方向；另一方面，从我看到的数字和测试结果来看，Jev 目前的表现仍然超过了那些类似产品。

Diogo Almeida：先说清楚，我不在乎基准测试上的输赢。无论领先还是落后，我都希望继续发布我们的进展。

Swyx：你们至少让更多人开始认真看待这个方向。而且，“决策模型”和 System 1 模型之间的区别，似乎也是你一直想讲清楚的。

Diogo Almeida：对，我想让软件工程师借助 AI，拥有更强的能力。让我难过的是，AI 已经这么强大，却远没有得到充分利用。如果事情继续这样发展，甚至会走向新一轮“AI 寒冬”，实在太可惜了。这件事会让我情绪激动。

我并不是认为所有技术进步天然都是好事，也不想一味宣扬技术乐观主义。但看到 AI 有这么多能力，软件却仍然没有真正用上它，我觉得很难接受。我想做的，就是帮大家打开这些可能性。先说到这里吧，这几天我已经哭了太多次，不想在录节目时再哭一次。

Swyx：谢谢你愿意讲这些。光看“TypeSafe AI”这个名字，大家未必能感受到你对这件事的投入。但了解你们想推动的方向，以及你们已经迈出的第一步之后，就更容易理解你为什么希望大家一起往前走。

Diogo Almeida：我不确定最难的部分是否已经过去。以后肯定还有很多难题。也许等到各种工作真正实现自动化、经济增长明显加快，每天都有值得庆祝的进展，我们才能说难关已经过去。而且，我觉得大家现在太关注速度和成本，对可靠性的关注还不够。可靠，才会让人用起来觉得好；可靠，才会让人敢于信任它。

Swyx：你们还写过一个目标：五年内让全要素生产率（TFP）增长超过 3%。我很少见到一家 AI 实验室把 TFP 增长当成目标。

Diogo Almeida：因为那才是经济变革该有的样子。这和 OpenAI 早期章程想表达的方向其实相当一致。章程本身也许没变，但关于什么算 AGI，后来的讨论似乎越来越倾向于用利润之类的指标来界定。

在我看来，一个值得追问的问题是：如果模型能解出数学上的千禧年难题，却几乎没有承担现实世界中有经济价值的工作，我们该怎样评价它的影响？如果按“承担世界上大部分有经济价值的工作”这个标准看，我觉得目前各家模型都还接近零。这个过程也许已经开始，但我猜占比还不到 1%。等它真正发生时，应该能从经济统计数据里看到变化。

我期待那一天。我不认为它会造成大规模失业，但它会带来很多积极的变化。另一方面，我也厌倦了 AI 总是站在产品最显眼的位置。软件和生活应该变得更好，而 AI 只需要在其中发挥作用。

Swyx：让 AI 融入后台。

Diogo Almeida：对。我在演讲里也常问：2019 年的软件和 SaaS 产品已经创造了很大价值。现在都到 2026 年了，AI 的能力进步这么多，为什么大多数软件看上去却几乎没变？很多产品只是侧边栏多了一个聊天框。它有时能帮上一点忙，但公司仍不敢让它处理那些需要承担后果的决策，因为还无法充分信任它。

这在我看来很不可思议。企业有很强的经济动力去改变现状。我觉得接下来可能出现的，恰恰是所谓“SaaS 末日”的反面：SaaS 会因为 AI 而得到增强。软件公司最清楚自己的业务里哪些工作值得自动化，因此也最有机会把 AI 真正用进去。

Swyx：你们已经做出了一件很有意思的事。不过，我还想弄清一个边界：什么样的问题适合 System 1，什么样的问题需要 System 2？现在大家可能什么都想拿 Jev 试一遍，其中一些尝试恐怕会失败。

Diogo Almeida： “什么都拿 Jev 试一遍”这个说法挺好玩。说实话，边界要靠实验来找，就像缩放规律也来自经验观察。以机器人为例，投入了这么多钱，为什么它至今仍有很多事情做不好？问题未必能靠继续增加投入解决，还要看实验结果究竟能不能支持那条路线。

我的判断是，预训练模型把大量能力浓缩到了一起，而 System 1 最接近它们天然擅长的思考方式。可验证奖励强化学习（RLVR）在增强 System 2 式推理方面取得了惊人的进展，我很佩服这些成果。但这类能力也很脆弱。

回想 ChatGPT 刚出现时，人们常说：“它很通用，能做很多事”，接着又指出它不擅长数学，连 GSM8K 这类小学数学题也做不好。如今谈起经过 RLVR 训练的模型，大家又会说它的能力很不均匀：为什么它能解决某个特别难的问题，却会在另一个地方出错？数学能力也不是简单地在少数地方出现尖峰，它的差异可能细到不同问题层次。

如果看各种训练方法各自追求什么，就比较容易理解：基于人类反馈的强化学习（RLHF）希望模型的回答获得人的认可；RLVR 优化的是能通过程序验证的任务表现。这类任务之所以能用于 RLVR，本身就需要有可验证的结果。我们做的 RLCD，则是希望模型能可靠地供程序调用。

Swyx：我说一个实际使用中的观察，你看看对不对。拿到 Jev 的访问权限后，我第一天就用它试了很多任务。单步推理的效果非常好，可以说是顶尖水平；但需要连续推好几步时，表现就开始下降，而且步数越多，问题越明显。

Diogo Almeida：对。这又回到了实验问题：我们究竟能从模型中挖掘出哪些能力？我们希望尽可能多地释放它已有的能力，同时让能力分布更平滑、补上缺口，也增加新的能力。但归根结底，我们是在发掘这些高度浓缩的模型内核所具备的特性，再设法把不同特性组合起来。

目前有效的那部分能力，恰好可以用“System 1 式”来描述。这也是为什么我们没有选择让模型在字符串里写出很长的推理过程。我认为，模型很擅长在内部完成推理，尽管这种能力还不完整，也不是对所有问题都有效。

Swyx：等一下，你说的“潜在推理”（latent reasoning）是在字符串里推理？我以为它指的是模型内部的推理。我想确认一下术语。

Diogo Almeida：我印象中，模型内部那种形式以前被叫作“连续推理”（continuous reasoning），但我也不能完全确定。过去之所以有人把另一种情况叫作“潜在推理”，是因为推理轨迹没有公开：对只看到答案的人而言，它相当于一个隐藏变量。

Swyx：所以“隐藏”的究竟是哪一部分，大家的用法也在变化。

Diogo Almeida：至少 OpenAI 和 Anthropic 的推理轨迹，现在仍有不向用户完整展示的部分。

Swyx：那 Jev 将来也不会做推理模型？毕竟显式推理似乎违背了你们强调的 System 1 路线。

Diogo Almeida：我的承诺是，为了做好面向机器的智能，采用必要的方法。我能想象某些推理方式没有那么慢、低效和脆弱；如果是这样，我们完全可能采用。我不会承诺永远只用某种技术方法。我坚持的是最终要优化什么、为用户创造什么价值。产品已经发布了，但我们仍觉得还有很多事要做。

Swyx：视觉能力也是一个目前缺少的重要部分。不过，它适合放进 System 1 模型吗？

Diogo Almeida：在我看来，各种能力都有可能加入。我们内部也在讨论一个更大的问题：是优先给用户提供我们判断他们真正需要的东西，还是更快提供他们明确说自己想要的功能？过去两年我们在未公开产品时，主要走的是前一条路，因为我们确信这个方向有价值。但产品发布后，两者之间需要找到平衡。

上下文长度就是一个例子。据我观察，我们的模型在长上下文中保持能力方面表现很好。但行业里也常见另一种做法：用户想要更长的上下文，就继续把数字做大。另一方面，如果我们过于坚持“我们知道用户需要什么”，又可能走向替开发者做过多决定的方式，那同样不利于开发者。

我们不希望把判断模型能力边界的全部负担都推给开发者，也希望他们能作为有判断能力的成年人，自行做出知情选择。接下来要解决的是：功能以多快的速度发布，才能兼顾产品的可信度和开发者的自主权。

Swyx：这个权衡很合理。

Diogo Almeida：老实说，我们还没有答案，得边做边找。接下来几天，这可能就是我最需要反复讨论的问题之一。我们手里还有不少东西。之前没想到这次发布会有这么大的反响，我们原本还想着，之后要陆续发布一些后续成果。

发布前没人看懂，发布后用户开始教他们怎么用

Swyx：我不太信你们完全没预料到发布后的反响。过去两个月，我从没见过你这么全力投入一件事。

Diogo Almeida：那也得感谢我的幕僚长，是他让我必须全力投入。我以前以为自己已经够努力了，这次才发现还能更拼。

Swyx：你甚至来参加我们的写作工作坊。当时我还在想：“你怎么也来了？”能看出来，你们为发布做了很认真、很有意识的准备。成果也体现出来了，恭喜。

Diogo Almeida：谢谢。我希望接下来还能保持这种投入。我们已经通过了技术圈的几道检验，但后面还有很多关要过，我很期待继续做下去。

Swyx：在聊 TypeSafe 以外的话题之前，还有什么关于这次发布的内容，你觉得被低估了，或者大家误解了？比如产品的使用模式、模型能力不均匀的问题？

Diogo Almeida：每个话题我都能讲很久，但还是克制一下吧。我想特别提一下我们的示例手册（cookbooks）。团队在里面花了很多心思，内容也很实用。我们原本考虑把不少例子放进发布博客，但那样文章会太长，也太偏向深度用户。

说实话，发布前我们很担心：这个工具听起来像是从外星来的，别人为什么需要它？我们觉得，教会大家理解这个新方向，可能会成为最大的障碍，所以在说明和示例上投入了很多。现在看来，用户已经做出了远超我们预期的东西，这个障碍或许没那么大了。

Swyx：用户反过来教你们怎么用自己的模型。

Diogo Almeida：没错。有些用户案例甚至比我们的演示更精彩。我看到一些计算机操作方面的用法时就想：如果发布时拿这个做演示该多好。至于示例手册，我们确实认真做了，不是随手生成的一堆内容。每个例子都有实际价值，很多来自我们帮客户解决真实问题的经历。

Swyx：发布前，你们做了多少用户验证？当时具体是什么情况？毕竟那时接触到的人还远没有现在这么多。

Diogo Almeida：坦白说，发布前的反馈不太好。团队里不做技术的同事尤其担心：很多人既没看懂，也不觉得自己需要它。大家会问，我们卖的会不会只是“维生素”，而不是能解决眼前痛点的“止痛药”？是不是还得配备前沿部署工程师（FDE），替客户把周边软件都写好，产品才能发挥作用？

发布前，我们几乎没有收入。技术团队相信它，因为我们看得到它在多个维度上的计算特性，也相信它有很大潜力。但我自己也很害怕，这正是我那段时间拼命投入的原因。

让超过一半试用者理解它在做什么都很难。少数看懂的人会说：“这很酷，但我们怎么通过采购流程？”整个过程并不轻松。后来我们决定，先面向开发者发布。开发者会找到用途，其他人看到实际效果后，也会想要用。

我不想嘲笑那些后来改变看法的人，情况确实变了。但这段经历让我重新思考“产品市场匹配”这个概念。发布前，我们拿着产品去问潜在用户：“你们要用吗？”他们说：“不知道它能不能解决我们的问题。”发布后，需求突然爆发，大家开始问：“能把我们的速率限制再提高吗？你们算力不够的话，我们甚至可以给你们提供 GPU。”

营销当然起了一定作用，但我觉得更关键的是，一群真正喜欢这个方向的开发者先用起来了，他们做出的东西又感染了更多人。

Swyx：很多公司也是从开发者起步，最后转向大企业客户。

Diogo Almeida：对。但我希望我们始终记得最早支持我们的开发者，而不只是把他们当作进入企业市场的跳板。我甚至在想，能不能推出一些对开发者比对企业更有利的东西，让他们获得更多能力。我已经有些想法了，虽然这么做可能很不寻常。

我也不知道还能怎样表达感谢。昨天我去染头发，也是想借这个机会继续和他们交流。公司正处在一个重要阶段，如果这时候反而不再跟开发者说话，我会觉得不对劲。

Swyx：所以你的头发是这么回事。

Diogo Almeida：对。请大家以后拿这些话要求我。我希望自己能坚持原则；如果哪天我变了，尽管指出来。

从暗数据到智能软件：Jev瞄准四类核心场景

Swyx：我想给大公司的开发者一些具体方向。即使他们现在没有做这类项目，也可以知道有哪些用法值得去看。

Diogo Almeida：我本来想先聊编程 Agent，不过还是先把主要的几类用法讲完。这些方向是我们发布前就从基本能力出发梳理出来的。

第一类是我们所说的“暗数据”（dark data）。很多企业积累了海量数据，却因为用大语言模型分析的成本太高，一直没能充分处理。大型企业很需要这类能力：它们有成堆想分析的数据。对数据科学家来说，这也是很有吸引力的场景。我认为，暗数据分析和编程 Agent 很可能是调用量最大、商业价值也最高的两个方向。

第二类是实时场景，需要在处理流程中迅速得到模型的判断。这类公司的 CEO，或者至少 CTO，大概都清楚：响应时间每减少 10 毫秒，产品体验能改善多少。

Swyx：电商尤其如此。

Diogo Almeida：对，各类 AI 助手也需要这种能力。据我从团队那里听到的反馈，这些用户很喜欢 Jev；不过我现在不直接负责客户沟通。我自己还特别期待它用在游戏里，比如玩家用指令指挥队伍作战的自动或半自动对战游戏。那会很有意思，不过在我还有工作的时候，先别把它做得太厉害（笑）。

第三类，我们叫“验证一切”：用它检查其他大语言模型的调用和输出，有点类似给 AI 系统增加可观测性。这里有个具体的使用技巧：如果你有一大段状态信息，想并行检查其中很多内容，可以给每条消息加上 ID，再针对各个 ID 分别提问。这样，较长的状态信息只需传入一次，就能围绕其中的消息提出许多问题，成本会低一些。

Swyx：按 System 1 和 System 2 的分工来想，这似乎意味着：每调用一次推理模型，就可以搭配一次、十次，甚至上百次 Jev 调用。

Diogo Almeida：也许，但我更希望用户花得更少。比如把原本需要的推理模型调用减半，再为每次调用配上若干次 Jev 判断。具体怎么组合，取决于它能否解决原来解决不了的问题。

第四类是“智能软件”：让智能判断成为软件自身的一部分，使程序能够组合出以前做不到的行为。有人尝试把 Jev 融入编程语言，做出了很有意思的东西。我们现在的基础设施还处在早期；如果能更方便地发放使用额度，我很想给这些项目提供支持。

这四类是我们事先梳理出的主要方向。计算机操作也是后来出现的用法，可以归到实时场景里。如果它能稳定工作，我会非常兴奋。这个方向多少有些出乎我们的预料，我也觉得模型在这方面还有很大的改进空间。

Diogo Almeida：编程 Agent 领域眼下正发生一件让我意外的事。在我印象里，Claude Code 和 Codex 大概是目前最领先的两个产品，不过我没有持续追踪排名。它们基本是围绕“单模型”来设计的，这很合理：过去开发者选择编程 Agent，主要是在功能相近、能力水平不同的模型之间做选择。

现在，开放式的编程 Agent 项目都在兴奋地尝试接入 Jev。我相信他们也在试各种别的组合。目前这些 Agent 的能力大致接近，毕竟只靠一个循环调用模型的框架，能做出的差异有限。一旦有人找到某个只有自己的 Agent 能做好的关键用例，用户就会涌过去；但其他开放式项目也能很快借鉴。Claude Code 和 Codex 则是围绕单模型构建的，我很好奇它们会怎么应对。

我个人很希望能与它们集成，也希望 Jev 能接入各种产品。它们以后也许会推出与我们竞争的能力，我不知道。但作为一家基础设施公司，我的工作不是预先替行业决定大家该用谁，而是让更多人能够使用我们的能力。这会让编程 Agent 市场变得很有意思。

我还写了一份内部文档，整理了一些可能适用于编程 Agent 的设计模式，正在请团队审阅，希望很快能分享出来。这个领域有太多值得探索的东西了。如果我不是正忙着做 Jev，我现在也很想亲自去做编程 Agent 实验。

Swyx：编程 Agent 公司应该也愿意和你们一起探索。我觉得 Claude Code 和 Codex 仍有使用 Jev 的空间。接下来暂时跳出 TypeSafe，聊聊你对 AI 研究方向，尤其是安全与对齐的看法。

“放慢前沿进展”之外，还有别的研究路线吗？

Swyx：我最近参加了一场研究者聚会，大家确实担心技术发展的速度。有一种观点认为，公众还没有准备好，因此前沿实验室应该放慢脚步。你怎么看？

Diogo Almeida：这是个容易引起争议的话题，不过我愿意谈。我还想专门写一篇更完整的回应，这里先讲一个简短版本。

我觉得，“要不要放慢前沿进展”的讨论，往往默认了一件事：所有人都必须继续做 RLVR，而且要不断加大力度。但我不这么认为。就 Jev 这类模型想完成的任务而言，我认为最合适的 RLVR 用量甚至可能是零。

RLVR 也不能只从“奖励可验证”来理解。在推理模型兴起之前，人们就尝试过用可验证结果做强化学习，并没有因此自然得到今天的效果。训练任务的整体形态同样重要。我想起一段经历：RLHF 刚开始受到关注时，有几条后来被统称为“后训练”的研究路线同时在推进。指令遵循当时并不受所有人重视，因为评估它很麻烦。我曾跟预训练团队说，这里面有关键价值；他们的顾虑是，模型实验做得那么频繁，难道每次都要等人工评测结果才能决定选哪个模型？

当时，代码生成也获得了很多资源。团队尝试用单元测试的结果给模型做强化学习，取得过一些成果，但光有可验证的测试结果，并不能自动带来今天这种推理能力。因此，RLVR 的效果不只是奖励函数带来的，也和模型被允许经历怎样的推理、采取怎样的中间步骤有关。为了让模型解出最难的问题，研究者会给它很大的行动空间。

这也是我对“放慢前沿进展”论述的疑问。有些人会说，也许问题出在沙箱隔离不够。那当然可能是问题，也可以改进。但实验室之所以给模型更大的行动空间，是因为这样可能让它在任务上更强；如果增加约束，又可能损失一部分表现。我认为，这里有一些本该由研究者自己承担的设计选择，却被表述成了发展 AI 不可避免的前提。

Swyx：如果先接受“必须沿着这条路线继续加大投入”的前提，再推导出风险会增长，逻辑上是说得通的。但前提本身还有其他选择。

Diogo Almeida：正是如此。真正重新定义任务或研究目标的路线很少见，所以研究者容易沿着已有方向继续推进。我觉得现在对其他可能性的思考还不够开放。

公众不该为这种局面负责。他们不是研究这件事的专家，通常只能相信 OpenAI、Anthropic 等实验室已经在尽最大努力；更了解技术上还有哪些选择的，是研究者自己。

Swyx：你们做的事，也是在让大家看到另一条路。

Diogo Almeida：我会尽力。但我的目标不是说服其他实验室改变路线，而是让软件工程师重新看到希望，开始自动化那些他们一直想自动化的工作。

我曾写过一篇关于理想中 AI 未来的文章，团队最后没让我发表。里面有很多很小、但会改变体验的设想。刚才那个用语音操作电脑的演示就是一例：过去计算机太机械、太按字面执行指令了；如果它能更好地理解人的意图，很多操作都会顺畅得多。

我不想承诺这些很快就会实现。但我们会尽力推动，让智能逐渐进入软件的各个角落。

Swyx：回到训练方法。你深入参与过后训练，怎么看“中训练”（mid-training）？我们好像还没聊过这个。

Diogo Almeida：训练的不同阶段更像是一条连续的谱系，没有那么清楚的分界。

Swyx：可以理解成一种更复杂的课程学习？

Diogo Almeida：可以这么说。中训练也有成本上的考虑：你不必为了增加某些能力，从头再做一遍预训练。

我觉得智能在训练的每个阶段都有一些难以用简单规则概括的地方。观察数据、弄清能力是怎么进入模型的，是件很有意思的事；我们的数据团队很擅长这个，我自己没有他们那么擅长。我更习惯从整体结构上思考，也很喜欢听他们讲从数据里发现了什么。

比如，短期内可以通过微调让模型迅速表现出某种倾向；如果相关训练持续进行，某些能力就会逐渐更深地进入模型，变得更稳固。我想找到的正是那些能稳定发挥的能力。前面说的 System 1 式能力，也属于这一类。所以我对中训练很感兴趣，也支持探索各种训练方式，看看还能从模型中释放出什么能力。但这些方法成本很高，我不会每一种都亲自做。

有件事我以前私下说过。我觉得，如果能对投资人说，也应该能公开对大家说：即使给我 10 亿美元，我也不会自己做预训练。我现在仍这么想。预训练太贵了。作为 AI 工程师，你可以拆解现有模型、组合不同能力，尝试各种办法。把模型像“弗兰肯斯坦”一样拼起来，也许不够优雅，但它能解决问题。总之，我会尝试预训练之外的办法。

Swyx：顺着这个思路，有一个值得讨论的问题：未来是把所有能力放进一个“超级模型”，还是继续把不同能力拆到不同模型里？OpenAI 曾经朝全能模型（omni model）的方向走，GPT-4o 就是例子。但有一段时间，也能看到聊天优化模型和编程优化模型各走一条线。

Diogo Almeida：这其实是两个差别很大的问题，得拆开说。多模态是一回事：加入其他模态，有时会帮助模型，有时也会拖累它。比如，我看到有些团队似乎在减少对语音（speech）的投入。这里说的语音和更广义的音频（audio）不是一回事；语音能力目前似乎不太容易迁移到其他任务上。这个问题以后可能会解决，但得看实验结果。

我支持探索各种形式的智能，不过不能以为只要按缩放规律增加投入，问题就一定会解决。缩放规律最终要回答的是：投入增加后，能力实际上提高了多少？有些任务即使继续扩大规模，也可能达不到可用水平。据我了解，计算机操作目前就还没有解决。我希望我们能在其中发挥作用，但也可能无论收集多少数据都不够，需要改进方法。

所以，问我是否支持全能模型，我的回答是：我支持探索各种能力。但你刚才提到的另一个问题更值得展开——后训练怎样影响模型原本具备的能力。我很不喜欢把智能训练得支离破碎。

以聊天优化为优先的训练，往往高度依赖 RLHF，也容易带来人们经常抱怨的问题：迎合用户、过度自信、幻觉。甚至在 LM Arena 这类评测中表现讨喜的回答风格，也可能是训练目标塑造出来的：大量加粗、斜体、表情符号；不直接回答问题，而是写一大段，再反问用户一句，让对话显得更像真人。

我认为，这和让模型更准确地发挥已有能力是两回事。让模型生成一段自由文本，本来就有很多不确定性；训练过程中，模型可能学会用非常确定的语气维持某种回答模式，避免明显跑偏后受到奖励模型的惩罚。这会改变它的概率分布，也会与推理能力相互影响。模型可能学会一些取巧的方式，把目标完成了，判断能力却未必因此变得更稳固。理解这些细微变化，是研究智能的重要部分。至少在我还在 OpenAI 时，我觉得这方面得到的研究还不够多，大家更多是在优化“聊天”这个目标。

Swyx：一旦确定目标，团队就会集中优化它。

Diogo Almeida：对。有人会说，那就同时优化两个目标。但在我看来，把模型分别往不同目标上拉，本身就可能造成能力分裂。

Swyx：可是，你把能力分成 System 1 和 System 2，某种程度上不也是在拆分智能吗？只不过你不认同别人拆分的方式。

Diogo Almeida：我觉得两者不一样。我们并没有把 System 2 任务扔掉。开发者可以拿 Jev 去尝试这类任务，而对于模型没有把握的问题，一个合理的结果就是表达“不确定”。它应该给出较低置信度，清楚体现不确定性；某些启发式方法也许还能改善表现。我们同样关心这些任务，只是我认为，长链条的 System 2 式推理并非这个模型最自然、最稳定的能力形态。

我也不想为了塑造产品身份而改变模型的回答。比如有人问它是谁，我不会特意训练它回答“我是 TypeSafe 的 Jev”。那会把一个品牌要求写进模型的判断里。我更希望它依据学到的信息给出正确回答，让能力保持平滑、可预测。

Swyx：模型身份对直接面向用户的产品来说，可能是个特殊问题。

Diogo Almeida：对，第一方产品需要考虑身份。但如果提供的是 API，情况就不同了。开发者用模型做自己的聊天产品，通常希望它呈现的是自己的产品身份，而不是回答“我是 ChatGPT”。

Swyx：为了让开发者更容易把 Jev 用进产品，你们也提供了 Jev Skill，让编程 Agent 知道该怎么与 Jev 配合。

Diogo Almeida：对。

从 InstructGPT 到 TypeSafe AI 创业

Swyx：最后问几个问题。回头看，你做这件事大概有两年多了？

Diogo Almeida：如果从公司成立算起，是两年多；但对我来说，更像是一段持续了四年的经历。

Swyx：我想起有一年感恩节，你取消了其他安排，说大家都在休假，正好可以用空出来的 Edge GPU，集中做一次实验。那还是 TypeSafe 成立之前吧？

Diogo Almeida：对，那段时间挺有意思。是不是正好赶上 OpenAI 那次管理层风波？我有点记不清了。

Swyx：对，时间差不多。

Diogo Almeida：那就对上了。那场风波挺让人心烦的，不过我们今天没时间展开聊。

Swyx：你说让人心烦的是那场风波，还是那次实验？

Diogo Almeida：是那场风波。也许下次聊天时，我再讲当时的事。不过，Jev 想解决的问题，在 ChatGPT 发布前就已经萦绕在我脑子里了。当时我看到 ChatGPT 团队的工作，觉得他们选对了任务。他们做了一件很多 AI 研究者不擅长、但优秀产品团队很在意的事：认真打磨用户体验。在当时的 OpenAI，这种人并不多；ChatGPT 团队在这方面做得很好。

Swyx：你说的这段经历，可以追溯到 GPT-3 向 GPT-3.5 演进的时期。当时还有 AI Dungeon 这样的应用，也是一个你们事先没想到的用例。

Diogo Almeida：对。我当时也很努力地推动 InstructGPT 上线。早期有些版本甚至用了我自己设计、但后来没有公开的训练算法，因为清理 PPO 数据太慢了。我当时想：效果已经这么好，应该尽快让用户用上。

它上线后，很快就在当时的大语言模型使用市场里占了相当大的份额，按我们的估计大约有 50%。我还花了很多精力，确保发布视频里的展示都是真实的。当时我甚至认真想过：一个模型能这样理解并执行指令，这算不算 AGI？现在看，显然不算。但我觉得每个人都值得想一想，为什么它看上去这么聪明，却仍然不是 AGI。

后来，我看到它主要被用于营销文案写作，例如 Jasper AI、Copy.ai，以及大量填充网页的文字。我们一度担心，自己是不是让互联网变得更糟了。于是我重新思考：模型明明表现得很聪明，为什么没有创造出我们期待的价值？还缺了什么？

我试着从一场由 AI 推动的经济变革倒推：如果 AI 以 API 的形式存在，未来主要是谁在调用它——人，还是代码？我的判断是，绝大多数调用会来自代码。但当时的优化几乎都面向人与模型的对话。那一刻我意识到，应该把“让程序能够可靠地调用智能”作为目标。

我写了一份文档，也跟 Sam 聊过。他觉得这个方向很好，建议我去做。我当时的反应是：“可我还有本职工作啊。”

Swyx： Sam 都让你去做了，那就去做啊。

Diogo Almeida：当时我还觉得，这个方向太显而易见了，Anthropic 肯定已经在做，我们可能已经晚了。我那时的看法是，OpenAI 往往更擅长追赶已有方向。比如我认为 ChatGPT 与 Anthropic 此前内部做过的聊天产品有相似之处，只是后者当时没有发布。

Swyx：对，之前还有在 Slack 里使用的 Claude。不过，推理模型这条线上，OpenAI 算是较早推出产品的。

Diogo Almeida：研究成果很出色。至于它是否对应用户当时最迫切的产品需求，我不太确定。编程 Agent 这边，Claude 也做出了重要的产品。

和 Sam 聊完后，我先回去继续做原来的工作。后来，指令遵循团队觉得这方面已经取得了很大进展，我也开始想下一步做什么，于是试着研究那个面向程序调用的方向。我原以为训练模型、验证想法只要一周，最后却花了好几年。

中途有一次，我看到了初步有效的迹象。它当时显然还不能直接部署，否则我们早就发布了。但我很想知道，如果在研究上全力投入，这条路线最终能走到哪里。我也想过：如果 AI 最后进入新一轮低谷，而我明明看到了这个问题却没有认真尝试解决，我会觉得自己有责任。

我和其他公司聊过，提出想建立一个研究这个方向的实验室，也得到了一些兴趣。但当我问他们，加入现有公司和自己创业，哪一种能推进得更快，他们的回答是“创业”。于是我决定自己做。

Swyx：然后你联系了 Eric 和 Sasha？

Diogo Almeida：我先联系了 Eric（译者注：Erik Gafni，现任 TypeSafe AI 首席技术官）。找 Sasha （译者注：Sasha Sheng，现任 TypeSafe AI 首席运营官）时，我起初并不是想拉她入伙。我只是问：“是不是我想错了？是不是因为待在 OpenAI 太久，我没看到外面其实已经有解决方案？”

结果她说：“我加入。”我提醒她，当时她还在经营一家创业公司，她说正在结束那家公司。我劝她先认真想想，她想过之后，还是加入了。

两周之内，我们拿到了资金，也有人搬进我的公寓一起工作。我有点洁癖，那段日子对我来说可不轻松。此后我们继续做研究，终于得到了一些结果，证明这个方向有初步的可行迹象。

别再复制前沿实验室：先找到你的 North Star

Swyx：前面讲了这么多背景，我真正想问的是：如果现在有一位前沿实验室的研究者，和当年的你一样，觉得自己的方向得不到资金、资源或重视，你会建议他也出来创业吗？

Diogo Almeida：这问题很有意思。我得想想怎么说才不至于得罪太多人。

坦白说，除非这些新兴实验室背后有我不了解的经济逻辑，否则我不太看好其中的大多数。我看重的不是研究者履历本身，而是他们是否认真选择了值得解决的问题。我们当然需要研究者，但他们得真正关心自己研究的任务。对我来说，首先要找到一个值得长期投入的 North Star（核心目标），然后围绕它做真正有用的事。光有漂亮的研究背景，通常不会自动创造价值。

我相信应该有清楚的目标，去做有用的事。如果一家新实验室有明确方向，我非常支持；但如果只是从头重复已有工作，拿到资金后做各种实验，真正推进前沿的机会又很小，我看不到它创造了多少价值。据我与一些新兴实验室交流的经验，有些团队还没有想清楚自己要往哪里走。

所以建议取决于你为什么离开。如果只是想自由地尝试研究课题，现有实验室可能仍是最合适的地方。我更希望大家带着要解决的问题出发。问题可以是探索性的，但最好有自己认同的原则和方向。如果你确信自己找到了一个值得投入的新任务，那我会强烈支持你去做。我们需要有人打破研究圈里越来越一致的思路。

Swyx：像一种“蜂群思维”。

Diogo Almeida：对。“放慢前沿进展”的讨论，也部分来自对 AI 的一种特定想象：模型聪明得惊人，能力却非常不均匀，因而带来特殊风险。但这只是发展 AI 的一种路线，不能把它当成唯一可能。探索不同的技术方向，本身就有价值。

Swyx：公平地说，我想准确转述此前与我交流过的 OpenAI、Anthropic，还有 SpaceX 人士的意思：他们谈放慢进展，考虑的不只有灾难性风险，也有政治层面的因素。

Diogo Almeida：政治层面的事，就超出我的专业范围了。

Swyx：我当时听完，也意识到他们讨论的时点可能和 2028 年选举有关。

Diogo Almeida：我真希望没听到这一层。感觉很糟。

Swyx：先说明一下，这只是当时那场讨论中部分人的说法，不能代表整家公司。

Diogo Almeida：明白。也许我是个天真的技术人员，但听到这些，我多少有点失望。

Swyx：随着技术发展，谁来执政、怎样制定监管规则，确实会越来越重要。实验室也需要认真考虑这些问题。

Diogo Almeida：这点我完全同意。我担心的是，为了达到某个自认为正确的目标，在公开沟通时把话说得过于确定，或者让公众产生误解。我不想在这里展开谈政治。我的原则是，即使出发点被认为是为了公共利益，也应该尽量准确地说明事实和不确定性。

Swyx：就我听到的讨论而言，我不觉得他们是在误导公众。他们更多是在解释，为什么现在提出放慢进展。

Diogo Almeida：我理解。但如果公开强调的风险理由，与实际推动这件事的目标并不完全一致，我仍觉得其中有值得说清楚的地方。希望我们以后尽可能不卷入这样的事。公司变大后，也许很难完全置身事外，但我还是想守住自己作为技术人员的出发点。

Swyx：那我开个玩笑：让 Jev 竞选总统吧，我说不定比信任自己的决定更信任它。好了，玩笑先放一边。你们已经选定了自己的 North Star：让 AI 可靠、可编程、可组合，还要便宜。如果把机会留给其他人，你最希望他们去解决什么问题？

Diogo Almeida：这问题太好了。我先说一个好玩的，再说一个我觉得很有研究价值的。

第一个是游戏。如果游戏里的角色和世界能更智能，会非常有意思。我看过 Ali 做的《Doom》演示，玩家可以让 NPC 执行一些操作。那还只是概念验证，却已经让我想到很多可能。我很喜欢《星露谷物语》；它的世界相对静态，仍然很吸引人。如果角色能对游戏状态作出更多反应，就可以产生很多新的故事。

也不必在游戏的每一帧都调用 Jev，那样可能太贵了。哪怕只是在 NPC 的状态机里加入一些智能判断，也有机会把游戏世界做得更生动。我有点遗憾自己现在没法亲自做这些项目。

Swyx：可以让别人来做，你再给他们反馈。

Diogo Almeida：对。另一个我特别想看到有人探索的方向，是摆脱 KV Cache 对编程 Agent 设计的限制。我写过一篇文章，叫《KV Cache Rules Everything Around Me》，就是想解释现有编程 Agent 和 KV Cache 是怎么相互影响的。它能解释很多现象：为什么模型路由很难，为什么子 Agent 的效果常常不如预期，为什么上下文压缩也是个棘手问题。

我还写了一份关于新设计模式的文档，希望团队审过后能发布出来。我想把自己的想法抛给大家，请大家试试看：如果不再被现有的 KV Cache 使用方式绑住，编程 Agent 还能怎么设计？

Swyx：你说的“绑住”，是指它限制了模型选择？

Diogo Almeida：这是一方面。为了高效利用 KV Cache，系统往往要持续在已有上下文后面追加内容，也就容易固定在同一个模型上。这样一来，设计会逐渐偏离软件工程里熟悉的做法，比如明确管理状态、抽象问题、拆解任务。

举个例子，为什么不能把简单的任务交给一个更便宜的子 Agent？难点之一是状态交接：如果把父任务积累的大量上下文都传过去，子 Agent 光是读取这些信息就可能花掉不少成本。那能不能更聪明地决定，它到底需要哪一部分状态？

我觉得这里有很多值得研究的编程模式。可以给状态明确标注含义，把任务组织成有层级的子任务。编程 Agent 本来就在逐个处理子任务；一个子任务结束后，为什么一定要把它接触过的全部状态都塞回父任务？需要信息时，为什么不能在子任务树里检索相关上下文？

如果访问上下文的成本足够低，还可以更方便地回看历史记录。现在 Agent 经常像每次都从零开始工作，然后我们又要单独解决“持续学习”的问题。其中一部分其实是记忆管理：信息并非完全不存在，而是系统不知道怎样有效找到它。

并行工作的子 Agent 也一样。如果它们的状态保存在计算机内存里，为什么不能有选择地读取彼此的进展？哪些内容正在写入、哪些可以读取，都可以更清楚地管理。多个 Agent 协作时，也许还能用比简单加锁更灵活的方式协调：“你现在在改什么？我在改什么？谁应该先写？”

Swyx：让 Jev 来决定谁先拿到锁？

Diogo Almeida：多 Agent 协作里确实可能有这样的用法。还有一些 Agent 只负责读取状态，比如向用户汇报其他 Agent 的工作进展。它不需要看完所有探索过程，只要找到已经写入的结果、相关子任务和当前状态就够了。

如果有人愿意投入足够多的时间，重新思考编程 Agent 怎样保存、查找和共享状态，我觉得能做出很有意思的东西。这是我特别希望看到的方向。

Swyx：你可以看看 PrimeAgent。它和递归语言模型（RLM）相关的工作有结合。我们刚和参与这方面研究的 Alex 聊过。这条路线已经有人在做，只是目前还不算热门。

Diogo Almeida：那很好。我希望更多人去试各种不寻常的想法。我不能保证它们一定有效，但从技术上看很值得探索。等我们建立起发放使用额度的机制，也希望能支持做这些实验的人。

Swyx：以后你们或许还能直接资助相关研究。也恭喜你和整个团队走到今天，从我第一次认识你到现在，你和团队都走了很远。

Diogo Almeida：我希望自己还是原来那个人。

Swyx：我觉得是。不过现在的你比我以前见过的任何时候都更有劲头，因为你找到了自己的使命。过去很多年，你一直在指出问题，但还没有拿得出手的解决方案；后来你有了大致方向，又花了很长时间把它做出来。

Diogo Almeida：这也是因为我觉得自己完全没有创业者的性格。我不喜欢创业，从没想过当 CEO。做一次已经够难了，很难想象有人愿意做第二次。最初融资时，有位投资人问我仰慕哪位 CEO，我的第一反应是：“我为什么要仰慕他们？”

无意冒犯谁。我遇到过很多很好的人，只是一些最出名的人似乎也有不少不愿示人的问题。在 OpenAI 时，我确实觉得自己很难推动想做的事。现在至少有了一点证据，说明我们的方向可能走得通，我也更容易把当时的想法讲清楚。

那时候，周围很多讨论都是“怎么把 ChatGPT 放进更多产品”“怎么让 ChatGPT 更适合开发者”。我却一直在想：现有的函数调用接口为什么要这样设计？开发者怎么用它来可靠地控制程序？

Swyx：像是在已有的变通办法上，再叠加一层变通办法。

Diogo Almeida：问题还不止于此。我当时常说：如果函数调用不能为每个函数提供相应的 logit bias，让开发者知道或调节模型选择它的倾向，就不要让我参与这个项目。我的要求并不复杂。

Swyx：你想要的是某种与置信度接近、但未必经过校准的信号。

Diogo Almeida：对，或者至少给出选择某个函数的概率。开发者需要控制模型在不同情况下采取什么行动，包括允许还是拒绝。同样是拒绝，迪士尼和 AI Dungeon 想设的门槛肯定不一样。可如果接口只让开发者通过提示词反复请求模型“请在这种情况下拒绝”，那怎么能算一个好的程序接口？大家已经这样用了很多年。

现在的 Skill 也有类似问题。现有编程 Agent 对各自的运行框架适应得很好，但能力并不均匀，使用外部工具和 MCP 时往往没那么可靠。如果某个工具对业务很重要，开发者为什么不能明确提高模型调用它的倾向？现在往往还是得在系统消息里反复要求。这让我觉得很不合理。

Swyx：我明白你的意思了。很高兴能在节目里和你聊这些，也期待你们接下来发布的东西。

Diogo Almeida：谢谢。接下来可能比你想的还快。

Swyx：你们现在还在招数据、基础设施、市场和社区方面的人？

Diogo Almeida：都在招。我自认为还能胜任创始营销负责人，但团队会让我别再抢这份活，好好做 CEO。事情一下子多起来之后，你很快就会学会授权。

我们也在招负责模型能力的人。他们的工作很大一部分与数据有关。我希望团队充分认可这类工作的价值，让直接改进模型能力的人得到应有的重视，同时又不在团队里制造奇怪的等级。

说到文化，我挺高兴同事们不会因为我是 CEO 就事事顺着我。他们会开我的玩笑，也会直接反驳我。我觉得这是个好信号。

另外，我们还需要平台工程师，把 Jev 部署到更多地方。对我们来说，服务器的位置尤其重要，因为网络传输时间会直接影响延迟。现在欧洲还没有我们的服务器，欧洲用户体验到的速度提升可能只有约三倍，而不是本来有机会达到的约一百倍，这让我很遗憾。

Swyx：没关系，欧洲的生活节奏也慢一点。

Diogo Almeida：这话可是你说的，不是我说的（笑）。总之，我们希望把服务部署到更多地区。如果“每秒能获得多少智能”对用户很重要，我们就会把服务部署到更多地区。开发者在我们的能力之上构建产品，我非常在意他们的使用体验。

我们也在招人，继续开发 Jev 之外的能力。公司的目标并不是只做 Jev 这一款模型，更不想只靠一种简单模型走到底。未来可能需要一个像 AWS 一样的平台，提供形态各异的智能能力。我希望我们朝这个方向走。

Swyx：而那个平台会是你们，对吧？

Diogo Almeida：现在就说一定是我们，太自大了。但我会尽一切努力去做。我觉得这会很有意思：我们现在探索的只是 System 1 式智能中的一层。如果把它类比成 TCP，上面还能建立许多层能力。

Swyx：对，还有很多层。我甚至提过 Temporal，也许它能算传统七层模型之外的“第八层”。不过这个话题我们又能聊很久。你该回去工作，或者好好睡一觉了。谢谢你来。

Diogo Almeida：谢谢邀请，聊得很开心。我很期待接下来要做的事。

播客链接：https://www.latent.space/p/jev

OpenAI 高管亲述：我们是怎么在一周内做出 Jev 竞品的

林绮蓓 — Fri, 09 Oct 2026 09:24:31 GMT

翻译| 林绮蓓

编辑| 蔡芳芳

计算机操作（Computer use）的结果明明很容易验证，为什么这一技术的进展如此缓慢？AI 什么时候才能真的学会操作电脑？

今年 6 月，知名播客主持人 Dwarkesh Patel 提出的这个质疑，在行业内引发了不少争议。

三个月后，OpenAI 在 9 月 29 日的开发者日展示了 Dot、计算机操作和一系列新的开发者接口。每个 Dot 都可以使用一台独立的云端 Linux 电脑，既能打开浏览器，也能运行桌面应用；用户可以把原本需要自己在网页或软件里逐步完成的任务交给它处理。产品演示之后，这个问题反而更值得进一步细问：计算机操作现在究竟能做到哪一步，支撑智能体完成任务的能力又发生了什么变化？

开发者日结束后，Latent Space 的《The AI Engineer Podcast》与 OpenAI 的 CUA 团队和 API 平台负责人进行了深入探讨。播客首先采访了 Sky 联合创始人、现 OpenAI 计算机操作产品与工程负责人 Ari Weinstein。Ari 认为，过去一年最关键的进步，是智能体遇到障碍后更会排错和重试。它也不再只能看着截图逐步点击：页面结构、无障碍信息和自己编写的代码，都可以成为它操作软件的方式。但当智能体能够访问网站、处理付款，人该在哪些环节把关，仍是产品必须回答的问题。

OpenAI API 产品负责人 Nikunj Handa 在访谈中分享了为智能体开发在 API 层做的各种实践：从让模型在工具执行时继续推理，到快速决策、性能优化和上下文管理。当谈论到 Decisions API 时，Nikunj Handa承认，这是受到了 Jev 启发而启动的，起初并不在研发计划之中。项目启动约一周，团队就已完成可运行的原型。他们没有重新训练模型，而是沿用 Luna 的权重，把输出约束成结构化结果，并专门优化推理系统，让首次决策返回时间尽可能短，多个问题还能并行批量处理；它更像一个极快的分类和决策层，能用于客服工单分类、评估打分和计算机操作，也能和 GPT Live 配合，让智能体在需要快速判断时更灵敏。

从“AI 为什么还不擅长操作电脑”的质疑出发，两场访谈逐渐把镜头拉近：智能体怎样发现自己做错了，怎样决定下一步，又怎样在漫长而琐碎的实际任务中持续工作。开发者日的演示给出的是结果，此次访谈则从产品和平台的不同视角出发，分享了他们在计算机操作方面的实践。

太长不看版：

主持人Vibhu： Dot 为每个智能体提供独立的云端电脑。用户应该如何探索它的能力？

Ari Weinstein： Dot 可以在云端 Linux 电脑上使用浏览器和桌面应用。一个实用的起点是梳理自己日常耗时的电脑任务，尝试将其中适合的任务委托给智能体。

主持人Swyx：有观点认为，计算机操作在过去两年几乎没有进步。实际情况如何？

Ari Weinstein：过去，智能体通常能够启动任务，却容易在遇到问题后停滞。如今，它更善于排查错误、调整方法并重新尝试。这是近一年最显著的变化之一。

主持人Vibhu：能力的提升主要来自模型，还是智能体运行框架？

Ari Weinstein：两者都在发挥作用。智能体现在可以结合截图、无障碍信息、页面结构和 Playwright 操作软件，也可以编写代码，一次执行多个步骤；模型本身的能力和速度同样在提高。

主持人Vibhu：计算机操作接下来的主要瓶颈是什么？

Ari Weinstein：瓶颈分布在模型、推理、运行框架和信息呈现等多个环节。随着智能体执行速度提高，等待网站加载等操作本身的耗时，也变得越来越明显。

主持人Swyx：开发者通过 Agents API 使用计算机操作能力时，需要注意什么？

Ari Weinstein：应根据任务限制智能体可访问的网站和应用，并在付款等可能产生重要后果的操作前征求用户同意。可靠性和恰当的安全检查，是建立用户信任的基础。

主持人Vibhu：计算机操作将怎样改变软件开发流程？

Ari Weinstein：智能体可以实际打开并测试自己开发的软件。这样，编写代码与验证结果能够形成闭环，减少开发完成后完全由人接手测试的情况。

主持人Vibhu：这次发布的 API 有哪些值得关注的变化？

Nikunj Handa：异步函数调用允许模型在工具运行期间继续执行，之后再获取结果；中途引导则允许开发者在模型运行过程中加入消息。这些能力有助于处理工具调用频繁、执行时间较长的任务。

主持人Swyx： OpenAI 是如何开始开发 Decisions API 的？

Nikunj Handa： Jev 的推出引起了用户和内部团队的关注，此前 Decisions API 并不在开发计划中。团队先验证原型是否可行，再着手优化决策返回的速度。

主持人Vibhu： Decisions API 适合解决什么问题？

Nikunj Handa：目前明确的用途是快速分类，例如处理客服工单。它也可能用于某些需要迅速选择下一步动作的任务，但快速决策与完成复杂、长周期任务所需的能力不同。

主持人Swyx：如果同样使用 Luna，Decisions API 与普通的结构化输出有何区别？

Nikunj Handa：首个版本没有重新训练模型，而是基于现有的 Luna 权重，对输出施加约束、并行处理多个问题，并专门优化首次决策返回的时间。

主持人Swyx：长时间运行的智能体如何应对上下文上限？

Nikunj Handa：开发者可以设置阈值，让 Responses API 自动压缩上下文；也可以调用 /compact，自行控制压缩时机。

当 AI 有了自己的电脑，哪些事可以交给它？

主持人 Vibhu：今天是 OpenAI DevDay，我们在现场录这期特别访谈。

主持人 Swyx：我们是你们直播结束后接受的第一场播客访谈。

主持人 Vibhu：今天请到的是 Ari，他负责计算机操作（Computer Use）智能体的产品和工程团队。在深入聊这项技术之前，能不能先回顾一下今天发布了哪些东西？

Ari Weinstein：我们刚从主题演讲现场出来，今天有几项计算机操作方面的发布值得关注。

首先是 Dot，这是一个新的个人助理产品，里面有一些很令人期待的计算机操作功能。

还有 GPT-6.1 Sol，这是一个非常出色的新模型，我认为它尤其适合计算机操作，因为它在成本和速度上都有优势。我们好像公布过它的成本是 Astra 的五分之一；如果专门看计算机操作，成本只有七分之一，真的很了不起。

Agents API 现在也加入了计算机操作能力，开发者可以使用与 Codex、ChatGPT 中相同的实现来构建产品。现场还演示了现有功能，比如应用快照（app shots），可以把你正在电脑上处理的内容迅速带入 Codex 和 ChatGPT。

还有 Mac 上的原生计算机操作：Roman 让它自动给自己的应用截图，而它操作应用时，他仍然可以在电脑上做其他事情。所以，这场主题演讲确实很精彩。

主持人 Swyx：更不用说还有 Decisions API。我先直接问一下：这些背后都是同一个模型，还是用同一套数据集蒸馏出来的不同模型？具体来说，计算机操作用的是 Decisions API，还是两者相对独立？

Ari Weinstein： Decisions API 很有意思，它有几项新能力：可以并行推断，不进行思考推理，用的模型也比我们用于计算机操作的模型更小。这让它速度很快，但处理执行周期较长、比较复杂的任务时，能力也稍弱一些。怎样把这些方法结合起来，仍然是一个有待研究的问题。我很期待看到大家用 Decisions API 做出什么。

主持人 Vibhu：有意思的一点是，现在 Dot 都配有自己的个人电脑。

Ari Weinstein：是的。

主持人 Vibhu：所以它们似乎能更持久地保留工作环境了。你已经用了一段时间，大家应该怎样探索它的能力边界？应该朝什么方向尝试？我自己现在经常让它处理客服问题。比如，“这个东西出错了，我不想登录，也不想做身份验证”，你去找到相关信息，把问题解决就行。再往前一步，大家还应该尝试什么？

Ari Weinstein： Dot 是一个很有意思的产品，因为每个 Dot 都可以使用自己在云端的一台 Linux 虚拟电脑，这与我们的其他产品不同。过去，我们提供的通常是云端浏览器，或者让智能体访问你自己的电脑；现在，你有的是云端一整台属于自己的 Linux 电脑。它既能运行完整的桌面应用，也能使用浏览器。我认为计算机操作如此强大、如此令人期待，就是因为它让智能体能够做任何一个人可以做的事。世界上所有软件原本都是为人设计的，如今智能体也能使用这些软件，你就可以把工作委托给它。所以，凡是你会在电脑上做的事情，都可以让 Dot 去做。具体哪些最有用，确实取决于最终用户是谁，以及什么事情对他的生活有价值。

我会建议，先想想你平时把时间花在哪些事情上，再想想能不能把这些事情交给智能体。凡是你会在电脑上做的事情，都可以让 Dot 去做。具体哪些最有用，取决于最终用户是谁，以及什么事情对他的生活有价值。我建议先想想，自己平时把时间花在哪些事情上，再看看能不能把这些事情交给智能体。

主持人 Swyx：对，比如订机票、购物，说实话，甚至玩个游戏之类的事情也可以，对吧？

Ari Weinstein：完全可以。我最近为了吃得健康一些，订了一项配餐服务。我很喜欢这家服务，因为它允许我非常细致地定制每一餐，比如“我要多少克鸡肉、多少克米饭”。但操作实在太复杂，我下一次订单就花了两个小时。后来发现，可以让计算机操作帮我下单，它十五分钟就完成了。用 GPT-6.1 Sol，它完成这件事的速度是我的八倍，同时替我省下了两个小时。我觉得这类任务特别能体现它的价值。

主持人 Swyx：作为创作者，我马上就能说出自己的首要用途：把 YouTube 上的操作自动化。YouTube 很多功能都不开放 API，你只能把它放进虚拟机里，让智能体自己跑。比如 A/B 测试，或者发社区帖子，这些都没有 API，因为他们讨厌开发者。

Ari Weinstein：我也听开发者体验团队的人这么说过。他们经常用它处理 YouTube 上的事情，确实非常好用。

计算机操作迈过新阶段：更会看懂界面，也更能排错提速

主持人 Swyx：我想稍微问得尖锐一点。我们有朋友做一档很有影响力的 AI 播客，他们有一个出名的观点：计算机操作在过去两年里毫无进步。这个说法很有意思，而你应该是全世界最有资格谈这个话题的人之一。究竟发生了哪些进展？

Ari Weinstein：我记得他们是几个月前这么说的，希望他们现在已经改变看法，因为计算机操作与以前相比，已经有了一百八十度的变化。

主持人 Swyx：你几乎整个职业生涯都在做某种形式的计算机自动化，从在 Apple 做快捷指令（Shortcuts），到 Sky，再到加入 OpenAI。能不能讲讲贯穿这段经历的主线？是什么在驱动你？以前有哪些事情做不到，又有哪些里程碑？

主持人 Vibhu：我再补充一个问题：从上周的 Codex 计算机操作到今天，最主要的变化是什么？是模型，是 Dots，还是智能体运行框架（harness）？除了整段历史，也想请你讲清楚，今天的发布究竟改变了什么。

Ari Weinstein：我一直对自动化、对帮助人们把任务自动化很有热情，因为这样能节省生活中的时间，把精力放在对自己更重要的事情上，而不必细致地操作电脑。这也是我们做那些产品的原因。我之前在 Apple 工作，后来创办了 Sky，最终加入 OpenAI，这段经历让我很兴奋。

主持人 Swyx：感觉就像你一直在想办法绕过 Apple 的限制，直到 Apple 说：“好吧，我们干脆把你招进来，让你从内部做这些事。”是这样吧？

Ari Weinstein：能在那里工作，确实是一段很棒的经历。回头看 Sky，很有意思的是，我们当时也在做计算机操作，但那时模型的能力弱得多。仅仅过去一年，模型的计算机操作能力就已经变得非常强。我看到最大的变化是，以前它们可以比较可靠地开始一项任务，但做着做着就会遇到问题；现在，它们非常擅长排查错误、重新尝试，审视哪些方法有效、哪些无效。

计算机操作这个领域本身也在发展，我们采用了更多技术。现在的计算机操作经常会写代码。如果你在 Codex 里手动展开工具调用，就会看到，它并不只是一次执行一个动作，而是在编写 JavaScript 代码，交给电脑执行，有时一次就能完成很多动作，速度和能力都有了提升。我们更多地采用无障碍接口等多模态交互方式，模型可能使用截图，也可能使用无障碍接口，或者 Playwright。它可以根据手头的任务，选择许多不同的机制。模型自身的加速也非常惊人。

至于今天有什么不同，我觉得我们一直在改进计算机操作，因此单独看一天的变化，可能还不如看过去一个月或两个月那么有意义。不过，Dot 中的计算机操作，以及今天发布的新模型，我都认为非常值得期待。

主持人 Vibhu：主题演讲里，Tejal 提到计算机操作的速度提升了七倍，在几个基准测试上也好了很多。你们是怎么衡量的？就像你说的，计算机操作是在不断进步的。这些进步来自智能体运行框架、模型，还是后训练？新模型又带来了哪些变化？

Ari Weinstein：我们实际上有很多种衡量方式，其中一些会测试智能体运行框架的不同组合和配置。这里的情况有点复杂，因为正式上线的产品会有更多安全检查，而且会根据当前任务的需要采用不同配置。所以，衡量的方法有很多，但无论采用哪种方式，我们看到的提升都相当一致。这些提升有时来自运行框架，有时来自模型。有一个结果让我印象很深：与 Astra 相比，GPT-6.1 在计算机操作上的成本效益提升，甚至超过它本身基础成本的降幅。看到这一点真的很棒。

主持人 Swyx：直播中有张图我特别喜欢，展示了你们不断改善这条曲线的帕累托前沿。你们也谈了不少如何配合运行框架一起改进。能不能举几个让你们恍然大悟的例子？无论是模型推动框架改进，还是框架推动模型改进，都可以。

Ari Weinstein：引入更多模态确实很有效。具体来说，过去很多计算机操作产品必须花大量时间滚动页面：先截一张图，试着操作一下，再发现“得往下滚，看看下一页结果”，于是再截图、再尝试操作，然后又往下滚。如今借助无障碍接口、直接访问文档对象模型（DOM）等方式，语言模型可以看到整个页面，或者整个应用，还可以写出一次完成多个步骤的代码。这些大概是最明显的突破。此外还有很多小发现，没那么引人注目，但我们确实发现，不少速度提升来自一个个细小问题，需要深入检查、逐一解决。

主持人 Swyx：背后是大量艰苦的工程工作。比如应用快照，很多人还不太理解它的区别。截取应用快照时，Codex 会显示一个很好看的画面，但他们未必知道，你实际上可以操作其中每个按钮，每一处文字也都已经以很合适的形式呈现给模型了。

Ari Weinstein：没错。其实挺有意思。如果你想深入研究，可以打开 Codex，按下两个 Command 键截取应用快照。这样就能把你正在使用的应用内容带入 Codex 或 ChatGPT 的聊天里。然后点击附件，再点右上角那个很小的按钮，就能看到原始文本和原始的无障碍结构表示。我们为这件事投入了很多工作。

主持人 Swyx：就是把一切全都导出来。

Ari Weinstein：不仅要导出来，还要高效、节省词元（token），这里面有不少技巧。原本为有无障碍需求、需要使用屏幕阅读器的人发明的技术，既能帮助他们使用电脑，也非常有助于大语言模型使用电脑。能参与这样的工作，很有意思。

主持人 Vibhu：补充一点背景：很多人不了解应用快照，甚至不知道有这个功能。按两下 Command，会引入一个看起来像截图的东西。你可能会想：“为什么只是打开一张截图，把它丢进来？”其实它会把所有元数据、所有代码以及其他内容一起带进来。

Ari Weinstein：没错。比如你给一个包含链接的网页截屏，截图里不会包含链接的目标地址。或者你给日历截屏，日程标题可能被截断了。但应用快照会把完整的上下文交给语言模型，让它能够做更多事情。

主持人 Vibhu：关于计算机操作智能体，我想问一个更宏观的问题。你刚才说的截图、滚动页面、再截图，是过去的状态。今天它们已经可以自动完成很多事情了，瓶颈在哪里？是模型还是运行框架？你觉得两年后会发展成什么样？它能连续运行几个小时吗？我们怎样才能走到那一步？你对计算机操作的未来有什么预测？

Ari Weinstein：我觉得团队过去几个月做到的一件很不可思议的事情是，现在计算机操作在大多数情况下，完成任务的速度可能已经超过普通人了。接下来要突破的，是让它的表现真正超越人类：使用软件的速度达到，甚至超过像我们这样熟练的电脑用户。那会带来很大的影响，因为我们能做出体验更加实时的产品。同时，使用计算机操作的门槛，或者说开始使用它所需要克服的阻力，也会降低。对于某些我们习惯亲手做的事情，大家会开始默认交给智能体，从而节省大量时间。

要实现这一点，还有许多小问题和瓶颈需要解决。有些在模型端，有些在推理端，有些在智能体运行框架里，还有些涉及信息的表示方式。随着计算机操作越来越快，我们越来越容易受到操作本身速度的限制。比如在计算机操作任务的基准测试中，有一部分不可忽视的耗时，是在等待网站加载。假设你在 doordash.com 上自动完成一项任务，其中很大一部分时间其实是在等 doordash.com 自己加载。

主持人 Swyx：然后你就写一个等待，再执行这个等待。

Ari Weinstein：页面终于加载完成，到触发大语言模型执行下一个动作，这之间的延迟要尽可能短。这非常重要，本身实际上就涉及一套统计方法。

主持人 Swyx：也许可以用事件驱动的方式来做？

Ari Weinstein：条件允许的话，当然希望采用事件驱动。

主持人 Swyx： JavaScript 有一些加载事件。

Ari Weinstein：JavaScript，或者说浏览器，针对网页导航有加载事件，但有些其他类型的事件确实没办法用事件驱动处理。所以这里面非常复杂。

主持人 Vibhu：我想到的一个例子就是跟客服聊天。对方可能三十秒回复，也可能三分钟才回复。

主持人 Swyx：我已经用 Codex 跟很多机器人打过交道了，挺好用。但我有时也会想，对面知不知道自己是在跟机器人聊天？因为我回复的句子太完整了，连大小写都很规范，编号、参考编号之类的信息也都给得完整，明显表现得太好了。不过我不在乎，我只是想解决自己的客服问题。

主持人 Vibhu：我会在提示里告诉它：“别表现得像机器人，要像一个已经很不耐烦的人。”我还会告诉它：“等回复的时候，调用子智能体，研究一下有没有更好的办法找到我们需要的信息。” 就是稍微加一点人的干预。

Ari Weinstein：太好了。而且我觉得，多半对面本来也是机器人，现在就成了机器人互相聊天。

主持人 Swyx：是的。我们现在已经走到了计算机操作的一个里程碑：三四年前，我们还害怕把大语言模型连到互联网、连到自己的设备上，现在我已经让它帮我配置域名系统（DNS）、替我付账单了。真的是几万美元的事情，我就直接交给计算机操作，放手让它去做，心想最坏能发生什么呢？你们自己也要使用自己的产品。

现在既然已经通过 API 发布了这项能力，有没有什么陷阱或者建议想告诉开发者？因为他们马上就要亲身经历这些事情了。

Ari Weinstein：首先，我真的很高兴我们把计算机操作带进了 Agents API。很多开发者开发的应用，都希望能够与第三方网站和服务交互，而计算机操作具有这种通用性，什么都能操作。现在，开发者一下子就能使用与我们自己相同的计算机操作实现来构建产品。如果你想自己做计算机操作的智能体运行框架，这方面当然还有很多值得做的工作，但难度很大。而且我们的模型是在自己的计算机操作框架上训练的，所以使用处于模型训练分布内的这套框架，可能在速度、成本和准确性上都有优势。

回应你刚才的话，我认为大家都还在逐渐适应这项技术、建立对它的信任，只不过我们当中有些人可能比世界上很多人走得更快一些。因此，我们有责任通过时间慢慢建立这种信任：确保做出的东西可靠，设置恰当的安全检查，在付款等可能产生重要后果的操作之前征求用户同意；或者根据具体应用的情况，确保它只能访问完成任务真正需要的网站和应用。这些都值得认真考虑。我非常鼓励大家试试新的 Agents API，在上面做出各种有意思的东西，也欢迎大家把使用后的反馈告诉我们。

主持人 Vibhu：你有没有看到它对开发工作流程带来的变化？比如现在可以在 Slack 里使用 Dots，也有人用语音来构建东西。Roman 演示的例子是让它修改应用，并在过程中不断发来截图。大家实际怎样把计算机操作用在编程流程里？有没有值得借鉴的做法？

Ari Weinstein：我最喜欢的用途之一，也是我们在实际使用中经常看到的，就是让智能体通过计算机操作，真正测试自己开发出来的软件。这件事的影响比听起来大得多。过去，你让 Codex 做点东西，它做好以后还得由你测试，于是你就成了智能体的质量保证人员。有了计算机操作，软件开发的整个流程就能贯通：智能体既能开发软件，也能测试软件。我很喜欢这样做东西，让智能体自己测试，到交给我时，软件已经能正常工作了。

对我来说还有额外的乐趣，因为有时我开发的就是计算机操作本身，于是就出现了一个计算机操作智能体，操作着我开发的另一个计算机操作智能体，再由后者去操作别的东西。我认为这是一类非常有价值的用途。

主持人 Swyx：我做了一个视觉交互测试技能，能发现很多只看代码发现不了的设计问题。它也特别适合复刻应用：如果你正在用一个很烂的软件即服务（SaaS）产品，想把它替换掉，就一屏一屏地照着做。计算机操作可以把整个应用都操作一遍，截图、记录，再让 Codex 把一切复刻出来。总之，谢谢你们做出的这些进展，我们的时间到了，不过这肯定不会是最后一次对话。

Ari Weinstein：今天聊得很开心，谢谢你们邀请我。

工具调用不再干等：OpenAI API 如何让模型边执行、边推理

主持人 Vibhu： Nikunj，很高兴请到你。你们在 API 方面发布了很多东西，刚才和 Ari 也谈到了，现在已经可以用计算机操作智能体来开发了。你想重点介绍哪些 API 变化？也请简单介绍一下自己和负责的工作。

Nikunj Handa：我叫 Nikunj，负责 API 团队的产品工作，在这里大约三年了，一直参与模型发布。感觉在 OpenAI 的这段时间里，这件事就没停过。每推出一个新模型，我们都会与后训练团队、研究团队紧密合作，弄清楚它有哪些新能力，再通过 API 开放出来。

GPT-6 这次发布的新能力，首先是异步函数调用。Codex、Dots 等产品中的很多工具调用都很耗时，现在工具运行的时候，不必暂停模型的执行。你可以先发起工具调用，让模型继续运行、继续推理，过一会儿再回来查看结果。我们还推出了轮次中途引导，可以在模型推理的过程中注入消息，这样工具调用一结束，就能把相关指令放进去。

主持人 Swyx：这也有一部分属于模型对齐能力，对吧？这种能力本身也得通过训练获得。

主持人 Vibhu：我感觉应用里以前就有了：模型推理时，你可以中途引导它。以前效果不算最好，现在已经好多了，很期待看看这个版本的表现。

Nikunj Handa：是的。我们在 API 方面的主要目标，就是等这些能力已经在智能体运行框架中训练到位，再放进 API，所以会等到它足够好。很多能力由 WebSockets 支撑，我们应该是在几个月前发布的。WebSockets 让应用能够与模型进行双向通信。我这里说的不是 GPT Live，而是 GPT-6。异步工具调用、异步推理、注入消息，这些都能做。开发这个 API 很有意思，我很享受这个过程。

主持人 Swyx：这就是我们为什么是一档工程播客，因为我们会聊 WebSockets。它和 UltraFast 也很搭，对吧？我记得这也是 UltraFast 第一次通过 API 提供。也就是说，前沿水平的模型可以以理论上最快的速度运行。

Nikunj Handa：在谈 API 之前，我觉得 UltraFast 最有意思的部分，是看推理团队围绕 Astra 不断拿出成果。他们一直运行着 Codex 智能体，试着再多挤出一点性能。至少有几个月，大量工作都集中在提高效率、降低成本上，我们因此能把 Luna 的价格降低大约 80%。其中很大一部分，就是他们落地的这些推理优化带来的。后来他们换了方向，开始研究怎样让它跑得尽可能快。看到 UltraFast 能把 Astra 这样的模型加速到这个程度，很让人振奋。

我们最初推出 WebSockets，是为了 GPT-5.3 Codex Spark。显然，工具调用必不可少，而 WebSockets 能大幅减少与工具来回通信的开销，所以特别有帮助。

主持人 Swyx：每次看到用量额度的界面都挺好玩：一边是我的常规额度重置，另一边是那个我从来没用过的 Spark 额度，反正我想用的时候，它就在那儿。

Nikunj Handa：我想它终于被移除了。

主持人 Swyx：确实没了，你们在慢慢淘汰那些老家伙。

受 Jev 启发？却不止于结构化输出：OpenAI 的 Decisions API 如何追求更快决策

主持人 Swyx： 5.3 Spark 明确说过用了 Cerebras。你们现在既不确认，也不否认 UltraFast 是否与 Cerebras 有关，但大家确实在讨论，也很在意、很好奇这件事。而且你们也有自己的芯片。还有一个绕不开的话题：决策模型，也就是 Decisions API。我们是第一档请 Diogo 来深入聊 Jev 的播客，我也邀请他上过 AI Engineer。你们看到 Jev 后，多快就决定跟进了？

Nikunj Handa：首先要感谢 Diogo 和 Jev 团队，他们启发了整个细分市场。Jev 一出来，大家都激动得不行，用户不断来找我们，我们内部团队也说：“我们需要一个快得多的分类系统。”有些即将推出的 Dot 功能，我不想提前透露太多，但大家会看到一些基于 Decisions API 做出来、反应非常迅速的功能。OpenAI 很多人一下就被这个技术问题吸引住了，开始琢磨：“怎么把它做出来？我们不会去重新训练一个模型，但是……”

主持人 Swyx：四周以前，这件事还完全不在开发计划里，对吧？

Nikunj Handa：完全没有。这就是受 Jev 启发的。

主持人 Swyx：我觉得你们应该是第一个复刻并采用这套思路的实验室。

Nikunj Handa：我觉得 OpenAI 有很强的黑客文化，大家看到有意思的东西就会兴奋起来。推理团队的一位同事，还有基础设施团队的一位很厉害的同事说：“我们来动手试试。”他们做了个原型，发现确实能跑起来。现在我们就在不断优化延迟，尽可能把它做快，希望未来几天就能推出。一旦达到延迟目标，我们就会争取发布。

主持人 Vibhu：有意思的是，一方面有这种黑客文化，另一方面，正如 Sam 所说，99%……你们也是最可靠的 API 之一，使用量可能也是最大的，而这正是你团队直接负责的部分。大家应该怎样看待 Decisions API？很多人见过 Jev、听过讨论，但还没实际用它开发，你们正在把它带给更广泛的人群。应该把它看成什么，又该怎么用？

Nikunj Handa：我们看到的主要用途是快速分类。计算机操作的演示很精彩，但不同模型各有适用范围：让 Astra 编写 JavaScript 脚本来控制电脑，与让 Luna 每次选择一个动作，所需的能力并不一样。不过，对某些计算机操作任务来说，这已经够用了，我很期待看到这方面的成果。我在内部还看到一个有意思的原型：把 Decisions API 与 GPT Live 结合。GPT Live 是我们的双向实时语音 API，采用前端模型与后端模型协作的架构。GPT Live 负责快速对话和分派任务，后端则可以使用 Astra 这样的模型。过去，GPT Live 的工具调用一直让人感觉比较慢。现在有人做了一些演示，让 GPT Live 通过工具调用控制电脑，整个体验变得灵敏、自然得多。我很期待看到大家把 Live 和 Decisions API 上的 Luna 结合起来，看看能做出什么，想必会很有意思。

主持人 Swyx：我想把这里面的事情给大家讲清楚，尤其是从产品角度，因为最近很多人在做 Jev 的仿制品，过去两周大概已经有一百个了。

主持人 Vibhu：最开始那几天就出现了不少。

主持人 Swyx：大家可以复刻一个 Jev API，说实话，那就是结构化输出，而 OpenAI 是最早做这个的。所以我想讲清楚，什么是决策模型，真正重要的是什么。它不只是延迟，也不只是结构化输出，对吧？决策模型的价格和 Luna 一样，那我直接用 Luna，把推理关掉，再加上结构化输出，就等于有了 Jev 吗？并不是，这才是真正的区别。

主持人 Vibhu：这里还有置信度的问题。

Nikunj Handa：我们没有为这件事训练一个新模型，而是完全基于现有的同一套 Luna 权重来做，所以它真的就是 Luna。在此基础上，我们对输出加以约束，结构化输出是很重要的一部分，同时专门优化推理系统，让首次决策返回时间（TTFD）尽可能短。因为你可以有多个问题，我们基本上就是把这些问题并行运行。

主持人 Swyx：作为一个批次。

Nikunj Handa：对，批量运行。大家正在尝试各种推理技术，让它尽可能快。但至少我们最初的实现，也就是第一个版本，是直接在 Luna 上采用零样本方式来做，看看效果如何。当然，我们希望先把它推出去。这就是 OpenAI 一贯的迭代部署方式：先发布，看看大家怎么想，再根据需要进一步改进模型。这就是 Decisions API。

主持人 Swyx：你们还有一个明显的优势：视觉能力。他们没有视觉能力，对吧？

Nikunj Handa：我们用 Luna，就天然有了这项能力。

主持人 Swyx：听起来，如果仍然是同一套 Luna 权重，那么有些创新还在后面，比如置信度。我们在播客里谈过校准，也谈过校准的基准测试。关键在于，基于人类反馈的强化学习（RLHF）会让模型的输出趋向于你想听到的内容。但那不一定反映它实际上有多大把握。

Nikunj Handa：完全同意。我也很想看看实际结果如何。也许置信度和校准会成为后续模型发布时需要重点改进的关键方向。

主持人 Swyx：架构方面也有争论。Jev 没有公开说明具体做法，所以没人知道答案。目前主要有两种猜测：一种认为它可能使用扩散模型，而不是自回归模型。不过，你们用自己的方法也实现了并行生成。另一种猜测与机制可解释性有关：也许它分析模型的激活，然后直接输出权重。你们也做过这方面的研究，所以大家会有这样的猜测。

主持人 Vibhu：这两种思路都有人做过演示。我记得 Gemini 分享过 Gemini Diffusion，或者是 Gemma Diffusion，用来生成 Jev 风格的输出。可解释性研究者也尝试从模型的中间层提取信息。不过，这些都只是猜测。

主持人 Swyx：关键是，你到底想达到什么目标？因为做出类似的 API 形式并不难；难的是之后的速度、准确性和置信度校准等能力，以及其他校准方面的能力。

Nikunj Handa：整个领域现在被带动起来了，大家会做出很多有意思的东西，也会互相学习，这让我很期待。

从 API 到智能体产品：性能、缓存与上下文管理

主持人 Vibhu：作为平台团队，你的工作很大一部分是帮助开发者做出东西。你觉得大家应该用 Decisions API 和计算机操作智能体开发什么？你们内部有没有正在做的东西，是这次变化之后才真正变得可行的？

Nikunj Handa：Decisions API 在内部的用途其实很明确，比如用户运营团队马上就开始用了，说：“我们得把所有客服工单都分类。”此外还有 GPT Live 的一些演示也很精彩。我想 Codex 应用团队或许也会用它做些尝试。不过，整个项目大约一周前才启动，现在还处于很早期的阶段。

主持人 Vibhu：评估方面也有很大的需求，尤其是让大语言模型充当评判者时，延迟能非常低。

Nikunj Handa：这方面的发展会很值得看。至于 Agents API，OpenAI 内部已经有一批第一方产品完全建立在它之上。刚刚发布的 Codex 安全相关功能，就是完全基于 Agents API 构建的。今天还会推出一个与会议有关的功能。你们记得 Sam 展示插件扩展的那个演示吗？你在日历里，可以把会议记录汇入自己的空间。

主持人 Swyx：放到一个统一的、类似 Google Docs 的地方？

Nikunj Handa：这些全部都是基于 Agents API 构建的。现在我们刚把它推出去，我很想看看大家会在上面做出什么。

主持人 Vibhu：我觉得你们展示得很好，编辑空间、页面、协作，再把自己的 Dot 加进来，内容相当多，大家能从中得到很多启发。

Nikunj Handa：是的，这些有了 Astra 都能实现。现在一切发展得实在太快了，人们从想法走到实现的速度快得惊人。

主持人 Swyx：有没有什么方面是你特别希望大家重点反馈的？也许你们先把东西推出去，前面有几个不同方向，希望开发者帮你们决定走哪条路。

Nikunj Handa： Agents API 和 Decisions API 是我们最新的产品，我们欢迎关于它们的各种反馈，帮助我们确定接下来的方向。Responses API 则是我们的主力，目前非常关注性能，主要分成两个方面。首先是延迟。我们一直在重写整个 Responses API 技术栈，从首个 token 的返回时间（TTFT）以及后续 token 之间的延迟（TBT）这些指标入手，尽可能降低延迟，这些仍然是我们工作的重点。

其次是深入改进缓存，尤其是个人智能体这类应用，基本上就是一条永远不断延续的会话。我们一直在努力把缓存做得更好，现在可以保证三十分钟内的缓存命中。实际上，我们刚为一位用户推出了长得多的缓存窗口，提供十二小时的缓存命中保证。

主持人 Swyx：这是公开 API 吗？

Nikunj Handa：还不是，目前处于预览阶段。我们会争取尽快向所有人开放。只要为缓存写入多付一点费用，我们就能保证在更长时间内读取缓存。比如，你正在使用一个智能体会话，完成了一些操作后离开，等到三四个小时后再回来继续使用，仍然能够享受到缓存带来的性能优势。

主持人 Vibhu：用了新模型以后，你们也把这部分成本降了不少，对吧？便宜了 25%。

Nikunj Handa：缓存读取的价格降低了。

主持人 Vibhu：开发者应该把它用起来，因为成本明显低得多。

Nikunj Handa：是的。开发应用时，要充分考虑缓存，使用我们的提示词诊断或缓存诊断工具，找出哪些地方没能有效利用缓存。这部分很重要。我还想谈谈预热，我们现在已经在 API 里提供了这个功能。如果你知道某个提示词将会用到，就可以提前预热缓存：现在先支付缓存写入费用，让它在接下来三十分钟里随时准备好。

主持人 Swyx：然后可以基于那条会话创建很多个实例，不断调整提示词。

Nikunj Handa：可以一直继续，创建很多个。我特别希望收到关于底层性能的反馈，让我们能继续把 Responses API 做成基于大语言模型开发时性能最好、最可靠的方式。对于那些新产品，则欢迎任何方面的反馈。

主持人 Swyx：先用起来，再告诉你们应该做什么。

Nikunj Handa：拜托大家帮我们确定路线图。

主持人 Swyx：对我来说，缓存显然很必要，但到头来，你还是会碰到一百万 token 的上下文上限，在可预见的未来，这个上限大概也不会改变。所以仍然需要好的压缩方法，这方面的最佳实践是什么？

Nikunj Handa：完全正确。首先，OpenAI 有自己专有的压缩，也就是上下文压缩（compaction）。

主持人 Swyx：它已经在智能体里面了。

主持人 Vibhu： API 里也有，Agents API。

主持人 Swyx：由你们替我们决定什么时候压缩，对吧？

Nikunj Handa：没错。在Agents API 中，上下文压缩功能已经内置在 Agent 的运行框架 (Harness）里。如果使用 Responses API，则有两种方式：一种叫服务端上下文压缩，告诉 Responses API，一旦达到某个 token 阈值，就自动压缩，减少正在占用的上下文。另一种是 /compact，适合希望完全自己控制的人，你可以随时调用 /compact，用自己的逻辑决定何时压缩。

主持人 Swyx：它不是通用人工智能（AGI），不过，它确实是手动接管的方式。

Nikunj Handa：很多大型编程智能体都喜欢手动控制。如果去看开源 Codex 运行框架里的实现，就能看到他们用 /compact 处理这件事。我们也在研究新的上下文压缩技术，其中一些已经在 Codex 运行框架里实现了，可以看到。我们还在试验一些基于文件的系统，所以在上下文压缩方面，也有不少工作正在进行。

主持人 Swyx：时间快到了。你讲了很多性能方面的事情，也介绍了正在发布的新 API。关于平台的未来，还有哪些感兴趣的方向，可以再透露一点吗？

Nikunj Handa：我们现在提供的还是比较底层的东西。我之前在 Stripe 工作，当时很重要的一部分工作，是在核心支付基础能力之上，构建更高层的基础组件和产品。我一直在想，在 AI 里怎样做才最好。我们已经尝试过几次，比如很早以前推出的 Assistants API，但它并不是一个特别合适的答案。现在我们沿着 Agents API 这个方向走，它提供 Codex 运行框架，但究竟应该在里面给用户多大的灵活性？这还是个开放问题。

比如，我们应该如何设计内存墙（Memory Walls），以及各种更高层级的 API 对象，进一步抽象和封装底层的存储概念，让用户少操心这些细节？这一整片领域，我都很想弄清楚该怎么设计。在 AI 里，很多事情现在的做法是，提供一个底层 API 基础能力，再给一个示例运行框架，然后让编程智能体去实现。但其中究竟有多少应该直接内置到 API 里，是我一直在想的问题。如果大家对此有想法，我很愿意听。

主持人 Swyx：我经常想到一个类比，我们就用它来收尾：你们正在构建一个 AI 云平台，Sam 一年前就说过这个。你们有点像在重新经历 AWS 的发明过程，需要逐个确定：这个是 EC2，那个是 S3，等等。但你们做的是这些东西各自的 AI 原生版本。

主持人 Vibhu：确实有很多可以类比的地方，比如对那些知道将会用到的内容，提前预热缓存。很好的一点是，这些能力都开放给了开发者，让大家有了更多构建新东西的方法。

主持人 Swyx：今天就聊到这里。

访谈视频链接：https://www.latent.space/p/devday-2026

@ 一下就能派活？谷歌推出办公 Agent，拥有独立账号、能够创建子 Agent，还能调用 Claude

林绮蓓 — Fri, 09 Oct 2026 09:15:07 GMT

作者| 林绮蓓

编辑| 蔡芳芳

智能体化身成“数字同事”了。

如今，AI Agent 可以拥有自己的企业邮箱、日历和云端硬盘，也能够像普通员工一样被拉进工作群、接收任务，甚至在文档中留下修改记录。

10 月 8 日，谷歌云（Google Cloud）在 Gemini at Work 2026 活动上正式推出面向企业的通用 AI Agent——Gemini agent。谷歌云 CEO Thomas Kurian 介绍到，Gemini agent是一款全新的通用办公智能体，仅需一个提示框，就能够完成从知识工作到问答、从内容创作到代码执行等各类任务。

此外，Gemini agent 还可以创建多个子 Agent 协作。更特别的是，Google 引入了 Coworker Agent（同事型智能体）的概念：企业可以为 Agent 分配专属的身份，包括邮箱、日历和持久化存储空间，让它以团队成员的身份参与长期工作。

在底层模型选择上，Google 也没有将 Agent 限定在 Gemini 系列模型之内。根据官方介绍，Gemini agent 目前支持调用 Anthropic Claude，并计划继续接入其他闭源和开源模型。

一个 Agent，就能完成跨应用办公任务

Google 将 Gemini agent 定义为“单一、通用的工作智能体”（Single, Universal Agent for Work）。

按照 Google 的介绍，用户不需要逐步告诉 Agent 应该打开哪个应用、查找哪些文件或执行什么操作，而是可以直接描述希望它完成的工作目标。Gemini agent 会规划执行步骤，选择所需工具，并在相关应用中完成任务。

目前，Google 公布的应用范围覆盖 Gmail、Google Drive、Docs、Slides、Sheets、Chat 和 Calendar 等 Workspace 产品，同时支持连接 Microsoft 365、Slack、Confluence、Salesforce、ServiceNow、Jira 等第三方企业软件。

以安排会议为例，用户可以要求 Gemini agent 在下周组织一次与区域活动负责人参加的会议，无须提供每位参会者的姓名和邮箱。根据 Google 的演示场景，Gemini 可以从已有的工作群和历史邮件中识别相关人员，查看相关人员的日程安排，再通过邮件协调会议时间，同时包括联系外部参会者。

类似地，Gemini agent 能够用来处理跨应用的工作。同样以Google 提供的演示场景为例，用户可以让Gemini agent调研市场趋势，在 Sheets 中建立财务模型，再根据研究结果制作演示文稿。整个过程中，Agent 能够沿用此前的工作上下文，不需要用户在不同应用之间反复解释任务背景。

除响应用户指令外，Gemini agent 还支持主动识别可以委派的工作。例如，当用户收到上级要求制作项目进展汇报的邮件时，Workspace Intelligence 可以识别这一任务，并提供交给 Gemini 处理的入口。

为了支持这些操作，Google 为 Gemini agent 设计了工具、技能和上下文三部分能力。

其中，工具负责连接企业现有软件及数据系统，支持通过 Model Context Protocol（MCP）接入外部服务；技能（Skills）则用于保存可复用的任务流程、操作说明和专业知识。企业可以建立共享的工具和技能注册表，供不同团队使用。

在记忆机制上，Gemini agent 包含四种类型：用于保存当前任务上下文的会话记忆、用于组织知识的语义记忆、用于保存工作方法的程序性记忆，以及记录历史操作的情景记忆。这些信息在云端运营，因此用户从电脑切换到手机，或在不同应用中与 Agent 交互时，可以继续使用相关上下文。对于持续数小时甚至数天的任务，即使用户关闭电脑，Agent 仍可以在云端继续执行。

能创建子 Agent，还能拥有自己的企业邮箱

除了跨应用执行，Gemini agent 还能创建子 Agent，实现多智能体协作。

Google 介绍，Gemini agent 可以根据任务需要，动态创建多个具有独立身份的子 Agent，将复杂任务拆分后交给它们执行。这些子 Agent 可以并行或依次工作，并通过相互通信协调任务进度。

不过，Google 此次还区分了两种不同的 Agent：第一种是为特定任务临时创建的子 Agent。它们围绕明确的工作目标运行，承担任务分解后的不同部分。第二种则是 Coworker Agent，即具有持续身份和固定职责的同事型智能体。

与临时子 Agent 不同，Coworker Agent 可以在不同日期、不同会话之间持续承担工作职责。企业只需要描述需要的岗位角色，Gemini 就能根据要求创建对应的 Agent。Coworker Agent 可以拥有独立的 Workspace 账户，包括企业邮箱、日历、Google Drive 存储空间，以及公司通讯录中的身份。这意味着，员工可以像与其他同事协作一样，将 Agent 添加到 Google Chat 群组，或者通过 @ 提及的方式向其分配任务。

Google 举了一个营销团队的例子：市场经理可以在工作群中要求负责活动协调的 Agent 起草产品发布准备文档。Agent 完成后，可以直接将文档发送回群组。员工还可以在 Google Docs 的评论区提及这个 Agent，让它提出修改建议。Agent 能以自己的身份回复评论，其修改记录也会显示对应的 Agent 名称。

这一机制还有一个区别：Coworker Agent 使用的是自己的身份，而不是直接冒用发起任务的员工身份。

Google 表示，Agent 只能访问用户或团队明确共享给它的内容，相关权限遵循 Workspace 现有的文件共享与成员管理机制。对于企业而言，这意味着 Agent 不仅需要具备执行任务的能力，还需要拥有可以管理、授权和审计的独立身份。

不只使用 Gemini，Google 的 Agent 还能调用 Claude

此次发布还有一个值得注意的技术设计：Google 将 Agent 与底层大模型分离。按照官方介绍，Gemini agent 负责接收任务、规划流程和组织执行，但完成每项任务所使用的模型可以动态调整。

目前，这一机制已经支持 Google Gemini 系列模型，以及 Anthropic 的 Claude 系列模型。Google 计划未来进一步接入其他领先的闭源和开源模型。

换句话说，企业使用 Gemini agent，不意味着所有推理请求都必须由 Google 自家的模型处理。

在具体执行过程中，Gemini 可以根据任务需求选择模型，也可以在一个复杂项目中组合使用多个模型。

Google 同时介绍了 Smart Routing（智能路由）机制，用于对不同工作负载的需求进行分类，以便每个工作负载都能以最低成本实现最高性能。

成本控制也是此次发布的重点之一。企业可以在 Google Cloud Billing Console 中，为单个项目设置 AI 支出的硬性上限。系统会持续追踪 Token 使用量及沙盒运行成本。当项目触及预算上限时，对应的 Agent 将暂停执行，管理员可以在控制台中选择恢复运行。这种方式也允许企业按照项目划分费用，并进一步将 AI 使用成本归集至不同部门。

Agent 拥有独立身份后，如何管理权限？

当 Agent 能够访问企业数据、修改文档并长期执行任务时，权限和安全管理也成为产品设计的一部分。

Google 在此次发布中介绍了面向 Agent 的身份、授权、审计和网络控制机制。

首先，每个 Agent 都可以拥有独立身份，并采用最小权限原则进行管理。管理员可以根据岗位或任务，为不同 Agent 设置细粒度的访问权限。当 Agent 需要连接外部系统时，身份和授权信息可以通过 OAuth 等标准传递。

其次，Agent 执行的操作会记录在审计日志中。与将所有操作归属于员工不同，Google 允许企业按照 Agent 身份追踪执行记录，包括 Agent 启动虚拟机运行代码时产生的相关日志。

在执行环境方面，Google 引入了 Agent Sandbox 和 Agent Gateway。

其中，Agent Sandbox 为执行任务的 Agent 提供隔离环境；Agent Gateway 则负责管理 Agent 与外部系统，以及不同 Agent 之间的网络通信。

企业可以通过统一策略限制 Agent 的行为。例如，管理员可以禁止所有 Agent 访问标记为特定保密等级的文件，而不必逐个配置。

除通用办公任务外，Google 还公布了面向数据分析、金融和法律领域的专用能力。数据分析方面，Gemini 可以调用 BigQuery 等工具，根据自然语言要求生成 SQL、Spark 或 Python 代码，完成数据查询和报告制作。金融与法律领域的专用版本目前处于预览阶段，其他行业支持将陆续推出。

与 Meta Muse 相比，Google Agent 有什么不同？

在 Google 发布 Gemini agent 之前，Meta在今年9月推出了个人AI Agent——Muse，引起了众多关注。

这两款产品有不少相似之处：都支持根据目标自主执行任务、跨应用操作、记忆用户上下文，也都能够在用户离开应用后继续处理工作。但从双方公开的产品设计来看，它们目前的主要使用场景并不相同。

Meta 最初将 Muse 定位为个人 AI Agent，面向日常生活和个人事务管理。用户可以通过 Muse 应用或 WhatsApp 向其布置任务，包括发送邮件、预订旅行、购物以及安排长期计划。Muse 可以打开浏览器、填写表单，并在获得相应授权后代替用户执行操作。Meta 还为 Muse 接入了 Stripe 的 Link 支付服务，用于完成线上购买。

相比之下，Google Gemini agent 主要面向企业工作环境。它的任务范围集中在企业知识管理、办公协作、代码执行、数据分析等领域，并通过 Workspace 和第三方企业系统连接组织内部的工作流程。

这也体现出二者的身份与组织方式之间的区别。

Muse 的核心设计围绕个人展开。用户拥有自己的 Muse，向其提供个人信息和应用访问权限，Muse 再根据这些信息执行任务、管理计划或主动提出建议。

Google 则进一步提供了企业团队层面的身份机制。Gemini agent 不仅可以作为个人助手，还能被创建为长期存在的 Coworker Agent，拥有独立邮箱、日历和企业通讯录身份，并与多个员工协作。

不过，Muse 也并非只面向个人生活场景。9 月 29 日，Meta 发布了 Muse for Small Business，加入 Asana、Canva、Notion、Shopify、Slack、Stripe、Zoom 等工具连接能力，支持商家分析销售数据、制定营销计划和处理经营任务。此外，Meta 还宣布成立 Meta Enterprise Platform，计划将 Muse、Muse API、Muse Code 等产品进一步推向企业市场。

本质上看，两款Agent 都承担着替用户完成具体任务的角色，因此，任务如何执行、权限如何管理、安全如何保障，都值得进一步关注。在底层执行和安全架构方面，Meta 为 Muse 提供了专用的 Muse Secure VM。每个用户的 Agent 运行在独立的云端虚拟机中，连接服务所需的数据和凭据保存在相应的安全环境内；还配有独立的 Sentinel Agent，用于检查对外操作，并在涉及敏感行为时请求用户授权。例如，发送邮件、购买商品等操作需要用户确认。

Google Gemini agent 同样提供隔离执行环境，但更强调企业级身份、访问权限和统一策略管理。其 Agent Sandbox 负责隔离任务执行，Agent Gateway 负责实施网络访问策略，企业管理员还可以集中查看操作日志、配置权限及费用限制。

模型调度的选择也是二者最大的区别之一。Muse 由 Muse Spark 模型驱动。Google 则明确将多模型编排作为 Gemini agent 的架构能力，支持在 Gemini 与 Claude 等模型之间进行选择。

在开放范围上，Muse 已面向美国和加拿大用户提供服务，基础功能免费，并设有订阅方案；Google 此次推出的企业版 Gemini agent 则仍处于私有预览阶段，尚未公布 Gemini agent 面向所有企业客户的正式开放日期及完整定价信息。

Modal 破解 Kubernetes 限制，在几秒内扩展 100 万个并发沙箱

作者： Sergio De Simone — Fri, 09 Oct 2026 09:10:00 GMT

在最近的一篇文章中，Modal 工程师 Colin Weld 和 Connor Adams 介绍了他们如何从头重建沙箱基础设施"，以支持数百万个并发沙箱以及每秒数万次沙箱创建。

据 Weld 和 Adams 介绍，Kubernetes 等传统容器编排系统难以在这种规模下运行，因为它们高度依赖集中式协调和强一致性状态。

运行 100 万个沙箱对于任何容器平台的极限都是个考验，这既是因为容器数量庞大，也是因为运行如此多的沙箱需要数万个计算节点。其中许多操作的复杂度要么是 O(容器数)，要么是 O(节点数)，或是两者兼而有之，这将导致传统容器平台达到扩展极限。

他们解释说，以 Kubernetes 为例，调度算法和中央持久化存储（etcd）的负载都会随着节点和 Pod 数量的增加而增长。此外，Pod 和节点都会多次向 etcd 写入数据，“这在 Pod 创建率很高或 Pod 更替率很高时可能会引发严重的问题，而且 etcd 没有为在同一个键空间内进行分片提供原生支持”。他们还指出，克服这一限制是可行的，但需要做“大量的工作”，包括重写或替换 etcd 以及对调度算法进行并行化处理。

为了优化可扩展性，我们决定：所有产生 O(沙箱) 或 O(节点) 级负载的组件都必须默认支持水平扩展；沙箱创建流程应尽可能简单；其余事项则应视为次要。

Modal 工程师对其平台做出的根本性改动是停止全局协调，使调度更接近于负载均衡。每个工作节点不再依赖于中央数据存储作为“单一数据源”，而是各自成为自己的“单一数据源”。同样，他们没有使用单个的串行调度器，而是部署了一组并行运行的调度服务器，从而使调度层能够实现水平扩展。

一旦调度服务器决定在哪个工作节点上创建沙箱，它就会通过 RPC 直接联系该工作节点，请求创建沙箱。如果工作节点有空闲资源，就会接受调度请求；否则则拒绝该请求。

据他们介绍，最终形成的架构仅有一个瓶颈：所有工作进程都会将状态发布到一个 Redis 流中。不过，“负载测试表明，这种方案在工作进程的数量远超 10 万时仍然可行”。在基准测试中，他们在不到一分钟的时间内创建了 100 万个沙箱，从启动到运行代码的中位时间不到 0.5 秒。

在 LinkedIn 上，Hopsworks 首席执行官 Jim Dowling 在评论该公告时指出"，“规模每增加一个数量级，就会出现新的技术问题”，这表明该团队必须对设计进行多次迭代，才能实现每秒可靠地创建 5 万个沙箱的目标。更有实质意义的是，亚马逊云科技首席 AI 工程师 Alex Jones 指出，Modal 取得这一成果的关键在于，他们并未试图扩展 Kubernetes"，而是在理解其局限性后“绕过了整个系统”。Jones 认为，这是“首个可信的信号，表明 Kubernetes 未能足够快速地适应生成式 AI 基础设施的实际需求”，并指出：

我们正朝着协调与执行脱钩的方向发展。执行层需要的是 Modal 的实现：能在几毫秒内建立起隔离边界。而协调层（多代理工作流需要共享内存，并且存在安全边界重叠）仍然需要 Kubernetes 这类系统所擅长的功能。

Modal 是一个专为 AI 工作负载打造的无服务器计算平台，提供对 CPU、GPU、容器、推理、训练、批处理任务以及隔离沙箱的可编程访问。它并非唯一一个试图围绕高可扩展基础设施和 10 毫秒内完成冷启动这两个目标来“重构云”的平台。其他追求类似目标的项目还有 Unikraft"、Google Substrate" 和 Overdrive"。

原文链接：https://www.infoq.com/news/2026/09/modal-scaling-sandboxes/"

AI 落地，此刻发生｜1024 模力工场 AI 社区日，首批报名开启

作者：模力工厂 — Fri, 09 Oct 2026 08:59:33 GMT

1024 又来了！

每年这个时候，朋友圈都很热闹：程序员节快乐、代码无 bug、发量惊人、上线不崩。祝福都挺好，但今年我们为你提供了另一种过法。

我们攒了个局：1 个主论坛，3 个分论坛，1 条 AI 市集街区。

2026 年 10 月 24 日，杭州·云谷中心。

模力工场联合极客邦科技旗下 InfoQ、极客时间、AI 原住民、OPC ，做了一场 AI 社区日。

主题就八个字：AI 落地，此刻发生。

这不是产品发布会，也不是传统会议。不排 PPT 接力，不搞合作方路演，不让人从头坐到尾只听讲。你可以来听案例，也可以打开电脑做 Demo；可以摆摊求反馈，也可以逛市集、玩项目、抽奖、自由聊天。

一句话：带上电脑，带上问题，带上想组队的人。

报名入口和完整招募信息在文末，先看一天怎么玩。

为什么叫“AI落地，此刻发生”？

因为 AI 这件事，已经过了只聊趋势的阶段。

现在真正有意思的问题是：

你正在用 AI 做什么？

它有没有进入你的工作流？

哪个环节真的省了时间？

哪个环节看起来热闹，其实没用？

你卡在哪？

你下一步想学什么？

这场社区日，我们想把这些问题摊开。

不讲抽象趋势，必须带一个正在发生的案例。

可以讲失败和未解决的问题。

不安排合作方路演，不做产品发布会。

如果你也在做 AI，不管是在公司里推，还是自己下班后搓，这里都欢迎你。

上午主论坛：AI落地，此刻发生

10:00–11:30｜主论坛：多位嘉宾连续分享

每人二十分钟，是一段完整而不被打断的时间。没有主持人追问，没有圆桌对谈，也不安排观众提问。

我们对嘉宾只有一项要求，带来一样真实的东西。一个正在发生的案例，或者一个敢于公开的判断。

失败和未解决的问题同样欢迎。做 AI 这件事，踩过的坑往往比漂亮的结论更有价值。

嘉宾来自两个方向。一类是 AI 创业者 / 产品负责人，回答从技术能力到用户价值，什么值得做。另一类是企业 AI / 基础设施的实践者，回答 AI 真正进入组织和工作流之后，最难卡住的地方究竟在哪里。

名单将陆续公布。可以确定的是，不会有人站在台上复述趋势。

下午开启：玩转四大空间

下午不是一条线，是几块场地同时开着你可以在这个街区自由穿梭。

分论坛 1：Talk about AI

13:30–15:30｜社区 Demo 分享

一场连续不断的社区 Demo Show。

开发者、创作者、AI 玩家轮番上场，分享自己最近正在做、正在用、正在折腾的 AI 项目。

8 位社区分享者，每位 12 分钟：10 分钟展示 + 2 分钟主持人追问。真实屏幕、真实 Demo、真实素材，不以 PPT 为主体。不拆第一场、第二场，不搞复杂换场，连续进行。选择标准只有三条。是真的，看得见，有意思。

分论坛 2：Build AI

13:30–15:20 ｜Hands-on A：AI 社区怪点子工坊

主题：给 1024 造一个离谱但能用的 AI 服务。

形式是“短分享 + Hands-on”，但目的不是产品试用课，而是让大家真的动手，给活动和社区造一个离谱但真能用的 AI 服务。可以从这些方向任选一个，也可以自带题目：

给社恐参会者的“同好破冰助手”；帮你在 AI 市集找到“我该试什么”的项目向导；把活动现场吐槽变成可执行建议的“反馈翻译器”；给开源项目新手准备的“第一小时陪跑员”；一件看似荒诞、但能解决真实社区小麻烦的工具。

每组最小交付：一句话问题、一个可演示的核心交互 / 原型、一句“它为什么值得在社区里存在”。工具只是手段，作品价值优先。

分论坛 3：Create AI

13:30–15:20｜Hands-on B：多模态 AIGC 分享

多模态 AIGC 合作专场｜主题：30 秒预告片工厂。

“短分享 + Hands-on”，动手做一支 30 秒、能让人想点开的原创预告片，命题现场公布。

边界说清楚：不挪用游戏或影视官方角色、Logo、镜头、台词、音乐、素材，也不制造官方合作或授权的误解。可以借讨论热度，但要做自己的角色、故事和视觉语言。交付可以是 15–30 秒短片、3 个连续镜头，或图像 + 声音 + 文案构成的短叙事。

每份作品附一句话：“观众为什么要点开这支预告片？”

造物市集：全天的自由展示区

一条能边逛边玩的 AI Builder 街区。

10 月 24 日 10:00–16:00，云谷之芯。

AI 市集不做传统展区，我们把它做成一条可以“边逛边玩”的 AI Builder 街区。

这里有 AI 产品、开发者项目、社区作品，也有各种“不知道为什么有人做，但居然挺有意思”的东西。可以试玩、交流、围观，顺便看看前沿 AI 创作者最近在折腾什么。

特色互动区｜两个官方体验摊：

AI 赛博签：抽签位 + 宜 / 忌 + 一句提醒，可扫码保存。

1024 明日头条：拍照答题，AI 生成一张“未来科技媒体头版”。

中央公共互动区有高桌、留言板、需求→Demo 匹配墙、实时榜单。极客时间 Couch 也在旁边，带着半成品或卡住的问题，随时坐下聊 5–10 分钟。

扫码报名，这场活动我们一起办

这场活动不是我们关起门来办给自己的。从上午的嘉宾，到下午的摊主，再到签到台后面站着的那个人，我们都希望留出位置。你不需要来自某家大厂，也不需要有拿得出手的作品。对 AI 有兴趣，愿意在 10 月 24 日来杭州做点事，就足够了。

最下方二维码，扫码后说明来意即可，也可同时报多个，身份自由切换。

1｜来参加 · 参会者报名

你是来听、来看、来体验的。上午找个位子坐下，下午选一个空间深入进去。

免费报名，名额有限，先到先得。

2｜来摆摊 · 造物市集摊主

一张桌、一个电源、一个二维码。你正在做的东西，可以拿来让人上手试一试。

面向个人开发者 / OPC、2–10 人小团队、开源项目作者、有真实 Demo 的 AI 团队。不要求公司、融资、商业化，只要真的做了东西，现场能让人玩起来。摊主可获得真实用户试玩、轻反馈、官方曝光与后续内容机会。

3｜一起办 · 合作社区与机构

如果你是社区主理人、社群发起人、高校社团、开源社区、AI 学习小组，欢迎一起传播、组队、带人来玩。合作社区可获得联合传播露出、专属报名入口、现场合作优先、会后内容共创等权益

4｜来做分享 · 分享嘉宾

上午二十分钟，下午十二分钟。你只需要带一样东西，一个正在发生的真实案例，或者一句敢于公开的判断。不限头衔。讲失败的、讲没解决的坑，同样欢迎。

5｜来搭把手 · 志愿者

现场签到、舞台控时、市集引导、Hands-on 助教、摄影传播等。想完整体验一场活动，志愿者其实是一个很好的位置。

5个身份任你挑，只要你感兴趣，扫码报名即可，我们会尽快与你联系。这件事一个人办不成，所以我们想邀请你一起。

AI 落地，此刻发生

不是一句口号，是我们想在这个 1024 看到的现场：

有人讲真实案例，有人打开屏幕跑 Demo，有人组队搓原型，有人在市集试作品，有人在 Couch 聊下一步怎么学。

2026 年 10 月 24 日，杭州·云谷中心。

带上电脑，带上问题，带上你想组队的人。

我们现场见！

乱序 HTML 流技术从 JavaScript 框架转移到浏览器中

作者：Bruno Couriol — Fri, 09 Oct 2026 07:30:00 GMT

乱序 HTML 流是一种允许用户在页面完全加载之前即可查看并与之交互的模式。该模式正逐渐被引入 Web 浏览器"。根据提案，当数据通过声明式 HTML 或相应的 JavaScript API 传入时，浏览器会实时更新占位符的内容。Chrome 150 已经正式推出这些声明式功能，而 Safari 和 Firefox 也已经表示将予以支持。

该声明式提案通过标准

全球最大独立 AI 原生影视公司，开始打破工具与制片厂的边界

陈姚戈 — Fri, 09 Oct 2026 06:03:15 GMT

AI 内容创业公司，已经不能只盯着模型与内容生产之间的 Workflow（工作流）。

过去几年，定位为“工具”的 AI 内容公司在基础模型之上做了大量工程化工作。模型调度、角色一致性、资产管理、生产协作，这些能力对于 AI 真正进入影视生产都很关键。但核心生成能力、模型价格和供给仍主要由上游模型厂商决定，工具厂商定价权相对有限。

与此同时，上游模型公司正在进入应用层，Adobe、剪映等成熟工具也在快速整合生成能力，大型影视公司和内容平台则开始搭建自己的 AI 生产系统。

单一环节的壁垒正在变薄，行业内的玩家也在进入产业链更深处。你可以看到，OiiOii 向内容社区拓展，Genspark 开始自研模型，珀乐互动则同时布局创作工具、自研模型和动画 IP。各家路径不同，但都在试图寻找更深的业务护城河。

Utopai Studios 也认为，如果只满足于做“技术供应商”，AI 影视创业公司很难获得足够大的商业空间。

成立于 2022 年、总部位于美国加州山景城的 Utopai，目前估值已达 10 亿美元。其核心团队横跨 AI 研究和影视制作，业务也随之跨越了模型、生产系统和影视制作三个层面。

模型端，它基于 MiniMax H3 的定制视频模型 Utopai X，目前在 Artificial Analysis“带音频文生视频”榜单中位列全球第二；并在音画同步与物理表现上排名第一，表现优于通用视频模型。这得益于其基于真实项目反馈的后训练机制，将创作者在真实生产中的决策直接注入模型训练与评测环节。

生产端，它开发了 PAI（Production Assistive Intelligence）。这是一个面向影视制作全流程的 AI 生产空间。它能从剧本出发，自动拆解角色、场景与道具；将图像、视频、音频生成及剪辑整合在同一工作台；更重要的是，系统会持续记忆故事上下文、视觉风格和创作决策，确保长周期项目的一致性与连贯性。

Utopai 自身也扮演着制片厂的角色。目前，公司储备了二十多个影视项目，其中 6 个已经进入制作或前期阶段，《Cortés》《The Most Serious Fart》《Half Moon》等长片计划于 2027 年大规模进入市场。

在商业化方面，曾打造多部宝可梦游戏的日本数字娱乐巨头 DeNA 已将 PAI 接入其动画制作流程。

NBA 巨星卡梅隆·安东尼（Carmelo Anthony）也通过其制作公司 Creative 7 成为 Utopai 的投资人与战略合作伙伴，双方计划将运动员的个人经历与文化影响力，转化为影视、流媒体等长线娱乐 IP。

至此，Utopai 的生意已经超出了软件订阅和模型调用。它既向外提供 AI 内容生产能力，也自己开发和制作内容，进而参与到版权和 IP 的长期价值分配中。

成为技术供应商还不够，Utopai 要做新一代制片厂

在 Utopai 看来，AI 与其说是一种新的内容类型，不如说是一种新的制作能力。

Utopai 所说的“制作能力”，覆盖的不只是镜头生成和后期效率。它希望把 AI 放进项目开发、融资、制作、发行和 IP 运营的整个过程中。

当制作成本、团队规模和生产方式发生变化，哪些项目能够被立项、需要多少资金才能启动、以什么方式完成制作，都会随之改变。一部作品上映之后，技术还可以继续参与后续内容开发和 IP 延展。

最直观的结果是，一些过去因为规模太大、成本太高而迟迟无法启动的项目，现在有了新的制作可能。

高质量影视内容长期受制于庞大的工业规模与预算门槛。不论是有才华的新锐导演，还是成熟的创作者，都难以幸免。

奥斯卡提名编剧 Nicholas Kazan 手里，就有一个筹备了三十多年的历史史诗项目。他想讲述 1519 年西班牙征服阿兹特克帝国的故事。Kazan 在 30 多年前就写好了剧本，并一直渴望将其搬上大银幕。但他曾在采访中透露，由于故事极其宏大，涉及 16 世纪大规模城市与战争场面的重建，在传统制片模式下成本高得难以想象。过去，每次尝试都因“规模太大、成本太高”而宣告流产。

直到近年来，Utopai Studios 挖掘并启动了这个项目。影片在西班牙进行真人实拍，并以巴黎为制作基地。明星演员完成核心表演后，再与 AI 生成的历史环境、大规模场景和数字资产进行结合。真人表演得以保留，而原本最消耗人力和制作资源的部分，则转移到了数字环境中。这种方式直接改变了项目的成本结构。Utopai 联合创始人 Cecilia Shen 向《福布斯》表示，采用这类混合制作后，团队规模远小于传统同级别大片动辄数百甚至上千人的配置。《福布斯》估算，Utopai 此类影片的单片成本可能低于 1000 万美元。作为参照，传统重工业大片的预算往往高达 2.5 亿美元以上。

对于预算更捉襟见肘的独立电影或新锐导演来说，AI 的价值更在于“兜底”。它能在不妥协创作者表达的前提下，解决实拍中不可控的高成本难题。

Utopai 同样与小成本制作合作。韩国导演 Hyo-joo Yang 的首部长片《Half Moon》就面临着这样的困境。传统实拍对天气、光线、安全和时间都有着极高的要求。最终，剧组将拍摄转移到可控的泳池中，完全保留演员的真实表演和摄影机调度。后期再通过 AI 视觉特效移除泳池边缘、扩展海面，并重新处理环境光线。在这里，AI 没有颠覆创作，而是精准接管了传统流程中成本高、风险大的特定视觉环节，保护了导演的作者表达。

如果说真人电影的痛点在于实拍成本与风险，那么动画工业面临的则是重资产与长周期的结构性难题。在传统动画体系下，只有被市场验证过的合家欢大 IP 才能获得巨额投资。那些古怪、小众的原创故事，往往在开发阶段就被高昂的成本劝退。

动画长片《The Most Serious Fart》正是这样一个非传统的原创 IP。影片改编自同名儿童绘本，讲述一个严肃的“屁”寻找自我接纳的故事。动画长片开发周期长、生产环节多、投入巨大，这类风格鲜明却尚未经过市场验证的故事，很难轻易获得大片级别的预算。

为此，Utopai 为它保留了一套成熟的动画创作班底。原作者 Mike Bender 担任编剧和导演，《怪物史瑞克》编剧 Joe Stillman 参与剧本打磨，《辛普森一家》与《飞出个未来》的选角导演 Scott Muller 负责声音选角，《歪心狼对阵 Acme》的分镜师 Andy Brooks 参与故事创作。明星班底主导核心美术与原创故事，AI 被用于支持后续的资产迭代与生产效率提升。这种模式在保证艺术质量的同时，大幅压缩了中长尾的制作成本，让非共识的原创 IP 更加具备商业吸引力。

更重要的是，Utopai 并没有把《The Most Serious Fart》仅仅当作一部一次性的动画电影。

Utopai 认为，IP 会成为 Utopai 作为一家 Studio 最重要的长期资产之一。在选择制作《The Most Serious Fart》时，Utopai 就在判断角色和故事本身有没有可能跨出电影，延伸到剧集、出版、游戏、衍生商品、实景娱乐等场景。

成本控制能力与技术赋能，不仅重塑了制作流程，也打开了新的商业想象空间。这也正吸引着好莱坞和内容娱乐行业 Big names 入局。

好莱坞一直是一个高度依赖关系网络的行业。资本往往和项目、人才、IP、发行能力深度绑定。导演、制片人、媒体高管和明星本人，也经常直接参与新公司的投资与孵化。

Pluto TV 联合创始人、前 Paramount 全球流媒体业务负责人 Tom Ryan，以及执导过《独立日》《后天》等视效大片的导演 Roland Emmerich，在 2024 年成为了 Utopai 的早期投资人。Ryan 带来了流媒体平台、全球发行与商业变现的深厚经验，Emmerich 则连接着好莱坞成熟的创作者和大片制作体系。

到 2026 年，这张关系网又延伸到体育娱乐业。NBA 名人堂成员卡梅隆·安东尼（Carmelo Anthony）通过制作公司 Creative 7 投资 Utopai，并成为战略合作伙伴。Creative 7 帮助 Utopai 接触职业运动员，并围绕运动员的个人经历、品牌和体育文化开发电影、电视、流媒体和数字内容 IP。他们合作的首批项目，就是围绕 Anthony 本人的职业经历和篮球文化开发新的娱乐 IP。

从流媒体高管、视效大片导演到体育巨星，这些好莱坞圈内人的加入，让 Utopai 迅速接上了内容行业已有的项目、人才、IP 和发行网络。他们看中的，不仅是 AI 节约成本的潜力，更是其背后重构内容生产与商业变现的巨大空间。

如果 Utopai 只提供技术，其收入主要局限于软件订阅、模型调用和企业服务。但作为制片厂深度参与制作后，AI 节省下来的成本可以直接转化为项目利润；一旦内容获得成功，公司还能进一步分享全球发行权、续集开发以及 IP 衍生的长期商业价值。

影视行业，需要怎样的 AI 生产基础设施

过去两年，通用视频模型发展迅速。Seedance、MiniMax H 系列、Wan 系列等模型已经能够处理多模态输入与一定程度的镜头控制，逐步向专业影视生产靠拢。

但影视制作的要求更为精细。物理运动、复杂光影、多角色互动与声画同步，直接决定了一个镜头是否可用；长片制作更需在数百个镜头和漫长的修改周期中，保持角色、场景与创作设定的一致性。

与此同时，影视制作中大量有价值的信息，并不存在于最终成片里。导演为什么留下这个 take，摄影为什么调整运镜，美术为什么修改材质，哪些版本被否决、问题又出在哪里，这些专业判断都产生于制作过程，却可能成为模型后训练和评测的重要数据。

这也决定了，影视 AI 基础设施很难只依赖“最强通用模型”。

根据 InfoQ 与影视从业者的交流，模型能力与生产工作流需要协同设计（Co-design）并持续迭代。模型获得新的参考、编辑和控制能力，会改变原有制作方式；真实项目中不断出现的新问题，又会形成新的评测标准和模型需求，反过来指导后训练与定制。

掌握一定的模型能力，也能减少对单一上游模型供应商的依赖，并基于对专业场景的理解形成差异化。

沿着这一逻辑，Utopai 选择同时深入模型与生产系统两层。

Utopai X：面向影视制作定制的专业模型

最先引起行业对 Utopai X 关注的，是其在 Artificial Analysis（AA）榜单上的成绩。

在 AA 9 月 29 日公布的“带音频文生视频”榜单中，Utopai X 以 1150 Elo 排名全球第二。截至 10 月 7 日，它仍以 1149 Elo 位列第二，仅次于 Wan 3.0，高于 Dreamina Seedance 2.5 和 MiniMax H3。

值得注意的是，Utopai X 基于 MiniMax H3 开发。H3 本身已经具备较强的通用多模态视频能力，可以理解文本、图片、视频和音频，并生成带原生音频的视频。Utopai 在此基础上继续后训练，将模型进一步向影视生产所需要的能力调优。

AA 的细分成绩呈现出了这种变化。

AA 将视频生成能力拆成十个维度。相比 H3，Utopai X 在其中七项上更接近该项领先模型。提升最明显的是 Audio Synchronization（音画同步）、Camera Control（摄影机控制）和 Physics（物理表现）。发布时，它在音画同步、物理表现上排名第一，在摄影机控制、Lighting & Materials（光照与材质）上排名第二。

这些能力，也是影视镜头中容易暴露生成瑕疵的地方。

物理表现决定人物、道具和环境之间的运动是否可信；摄影机控制关系到模型能否准确执行跟拍、环绕、推进等镜头设计；光照与材质影响水面、玻璃、金属、皮肤等在运动镜头中的质感和连续性；音画同步则直接影响动作、环境声与画面的对应。

从 H3 到 Utopai X，提升主要集中在物理、摄影机、光影和声画关系上，也体现出较为明确的影视生产取向。

这也引出了另一个问题：一家影视公司，为什么有能力参与视频模型的后训练？

答案的一部分，来自它掌握的数据和专业经验。

影视模型需要学习的不只有大量视频，还包括专业创作者如何判断镜头。通用模型公司如果希望获得这类信息，通常需要额外组织专业标注、专家评审，或者采购专业创作者的工作流数据。

Utopai 的优势在于，这些数据可以在自己的制作过程中持续产生。

Utopai 拥有电影和动画制作团队。剧本、角色和场景 reference、不同版本的 take，以及导演、摄影、美术和动画师留下的选择与修改意见，本身就是日常生产的一部分。

研发团队因此能够看到最终成片之外的信息：哪些版本被否决，问题出现在哪里，创作者为什么要求修改，以及什么样的结果最终能够进入下一环节。

这些过程数据不会完整出现在最终成片中，却可以用于模型的后训练和评测。

Utopai 还建立了内部 Elo 评测体系，同时引入自动化评测和艺术家的人工判断。对于垂直模型，这类数据的价值未必在规模，更重要的是，它能把模型表现与真实制作中的问题和审美判断对应起来。

通用基础模型依然会提供最重要的底层能力。但 Utopai X 提供了另一种垂直模型研发的样本：以成熟通用模型为底座，再利用专有内容资产、真实制作数据和专业创作者反馈持续后训练。

对于影视公司来说，这条路径不需要复制基础模型公司的预训练投入，却有机会逐步形成更贴近自身制作需求的模型能力。

PAI：把模型能力组织进完整影视制作流程

Utopai 还开发了一套影视制作平台 PAI（Production Assistive Intelligence）。它是一套由创作者主导的 AI 制作引擎，覆盖剧本、角色与场景设定、镜头生成、版本管理和后期制作等功能。

PAI 最终希望提供一层可配置的 AI 生产基础设施，让不同制片厂、不同项目都能在自己的制作体系中使用。

一个项目可以从故事概念或已有剧本开始。PAI 的 AI 制作助理会先识别角色、地点、道具和故事节点，并整理出场景结构。团队确认后，再继续建立角色和场景的视觉参考。

以角色为例，PAI 可以生成正面、侧面、背面和近景等多视角设定。创作者确认面孔、服装、比例等细节后，这组图片会成为后续镜头持续使用的角色参考。地点和场景也是如此。已经确定的建筑、灯光、色彩和关键道具，可以继续沿用到后面的镜头中。

在此基础上，AI 制作助理再把场景拆成具体镜头，并生成不同的关键帧方案。团队可以先比较机位、构图、人物调度和表演，再决定采用哪个方向。某一个镜头需要修改时，也可以单独重做，而不用重新建立已经确认的角色和场景。

关键帧确认后，制作才进一步进入视频生成。团队为每个镜头确定运动、时长和声音，AI 制作助理据此准备渲染方案。涉及付费算力的正式渲染仍然需要人工确认。

生成后的不同版本会继续保留在项目中。团队可以比较、回退和重新修改，再把选中的镜头放进时间线，检查节奏、镜头衔接和连续性。粗剪完成后，素材还可以继续进入 Premiere Pro、DaVinci Resolve 完成剪辑、调色和后期。

对于长片制作来说，底层模型可以不断变化，项目本身的制作状态不需要随之重来。

对于多人协作项目，PAI 还提供资产同步、评论与审批、生成记录追踪和项目进度管理。企业版本进一步支持私有部署、私有云、权限管理，以及 IP 和数据隔离。

针对拥有技术团队的影视公司，Utopai 还提供 PAI Code。开发者和技术艺术家可以通过 Codex、Claude Code 等 coding agent 调用图片、视频和声音能力，也可以修改 Skills，根据不同项目调整制作流程。

Utopai 随后将这套能力向外输出，把 PAI 接入其他影视公司的实际制作流程。

在日本，DeNA 已开始将 PAI 用于动画制作，尝试让其与既有团队、制作资产和工作流程衔接。在韩国，Utopai 进一步通过收购 Alquimista Media 获得当地制作团队、项目储备、制片人与产业关系。相比单纯向当地出售软件，这种方式让 Utopai 能够直接参与项目开发和制作，并在真实生产中部署自己的技术体系。

内容制作与技术研发，由此得以相互促进。一方面，自有电影和动画项目会持续暴露模型、工作流和制作系统中的问题，为 PAI 和 Utopai X 提供新的优化方向。另一方面，技术能力经过项目验证后，又可以进入更多影视公司的生产流程。

结语

Netflix 曾从发行渠道进入原创内容，改变了平台与制片厂之间原有的分工。到了 AI 时代，类似的边界变化也开始出现在生产端。

Utopai 横跨模型、生产系统、内容制作与 IP 开发，提供了一个值得观察的样本。

在 Utopai 看来，基础模型公司解决通用能力，工具公司负责将这些能力产品化，而制片厂面对的是另一组问题：什么故事值得投资，如何开发 IP，如何为创作者留出最大的想象空间，怎样在预算和周期内高质量交付，以及最终如何让内容找到匹配的观众。

技术可以降低很多制作环节的门槛，但当生产能力越普及，品味、IP、具备判断与组织能力的人才、世界观构建与发行能力，往往会变得更加重要。

Cloudflare 通过测量源站 TLS 偏好将握手重试率从 52% 降至 3.7%

作者：Steef-Jan Wiggers — Fri, 09 Oct 2026 05:11:00 GMT

Cloudflare 将其源站 TLS 握手过程中的静态假设"替换为针对每个源站的实际测量值，从而将扫描到的源站中的 HelloRetryRequests 比例从约 52% 降至 3.7%，并将 p90 握手延迟缩短了 150 多毫秒。

被替换掉的假设已经沿用多年。TLS 1.3 要求客户端在第一个数据包中就确定密钥协商算法，而此时服务器尚未声明其支持的算法。如果猜测正确，那么握手过程仅需一次往返即可完成；如果猜测错误，那么源站将返回一个 HelloRetryRequest，客户端需要发送第二个 ClientHello，这时就需要两次往返才能建立连接。

Cloudflare 基于“超过 95% 的源站支持 X25519”这一合理依据，默认互联网上的每个源站都使用 X25519。测量结果表明，对于大约 30% 的源站连接，这种猜测并非最优方案。超过 6% 的源站更倾向于使用 P-256 或 P-384 而非 X25519。这就意味着这些连接完全出于传统原因而多消耗了一次往返。

作为自动 SSL/TLS 的扩展功能，自动密钥交换（Automatic Key Exchange）会探测每个源站，以便了解其支持和偏好的算法，然后优先使用该算法。如果源站能够处理后量子混合算法 X25519MLKEM768，那么 Cloudflare 会优先选用该算法。探测操作在生产流量路径之外进行，每次处理一组密钥协商，并且每天会重新扫描源站，以便偏好设置能跟上负载均衡器和 TLS 库的变化。该功能在当前所有的区域里都已经启用，并且在新区域中默认启用。用户可以在控制台的 SSL/TLS 部分进行开关设置，而 Cloudflare 会在整个区域内应用同一偏好设置。

测量结果揭示的信息比观察所获得的信息更为丰富。根据 Cloudflare 的报告，主动探测发现了数千个源站，它们在被动流量中从未显示出对后量子加密算法的支持，因为许多源站即使支持更强的加密方案，也会直接接受经典密钥共享，而不会发出重试请求。

这次变更中涉及后量子加密的部分存在一个值得了解一下的限制。X25519MLKEM768 密钥共享的长度为 1216 字节，而 X25519 仅为 32 字节，这会导致 ClientHello 消息超出单个网络数据包的容量。虽然 TLS 标准允许多数据包分段传输，但当 ClientHello 被拆分为多个 TCP 分段时，某些老旧的中间设备（middleboxes）和源站就会出现处理失败的情况。在 Cloudflare 早先的一项研究中，约 0.34% 的被扫描源站在收到优先携带后量子密钥共享时，无法完成握手过程。

正因如此，Cloudflare 自 2023 年 9 月起便将 HelloRetryRequest 作为安全阀使用：虽然宣传支持后量子加密，但仍然以经典的 X25519 作为默认方案，并要求具备后量子加密能力的源站通过重试请求来发起升级。其结果就是，几乎每次后量子源站握手都不得不进行强制性的第二次往返通信。

引入这一变化的依据是采用率数据。源站对后量子密钥交换的支持率已从 2023 年的 0.5% 增长到如今的 12.8%。也就是说，大约八分之七的源站仍然无法使用该功能。在 Cloudflare 迄今为止扫描过的样本中，有 64% 仍然使用经典的 X25519，而且连接配置未作任何更改，有 33% 迁移到了 X25519MLKEM768，还有 3% 迁移到了其他经典算法，例如 P-384、P-256 或 P-521。

对于能够使用后量子密钥交换的源站，往返开销现在已经基本消除。不需要 HelloRetryRequest 的后量子源站 TLS 1.3 流量占比从 0% 上升至 99.2%。在扫描的样本中，后量子源站流量从每天约 250 亿次连接增长至 450 亿次。Cloudflare 认为，这部分归因于“自动密钥交换”功能对传统加密连接的升级改造。

有一项新的“合规要求”设置所带来的风险值得警惕。该设置会过滤 Cloudflare 可协商的密钥协议，提供“仅限后量子混合模式”和“仅限符合 FIPS 标准的算法”两种选项。这实际上是限制了 Cloudflare 可以使用的选项，而非为源站赋予了新功能。因此，如果强制不支持 X25519MLKEM768 的源站使用后量子混合模式，将导致双方没有任何共同支持的算法，所有指向该源站的TLS 1.3连接都会失败。如果没有算法同时满足两项要求，就无法同时选中这两个选项。这些设置仅适用于 TLS 1.3 连接。

已部署自动化功能的团队应该注意一项较为低调的变更。源站后量子加密 API 仍然可以使用，但针对该 API 的请求现在已成为无操作（no-ops），不会改变一个区域的后量子密钥协商行为。Cloudflare 表示，他们计划弃用该 API，但尚没有给出具体日期。你可以通过 BoringSSL 的 bssl 客户端工具直接向 443 端口发起源站检测，确认协商出的加密算法是否为 X25519MLKEM768。

这次部署采用的机制比较保守。新配置将首先应用于一小部分源站流量，系统会监控针对该源站的失败率和重试率，并与基准值进行对比。如果重试率上升，则会回滚该变更——这与 Automatic SSL/TLS 在加密模式升级出现异常时采用的模式相同。Cloudflare 指出，回滚的最坏情况只是增加一次往返，而非导致连接中断。

对于评估该功能收益的团队而言，有两点限制值得注意。延迟改善仅适用于新建立的连接，现有长连接（keep-alive）上的请求完全不受影响；而且，收益主要集中在动态请求以及需要重新进行源站握手操作的 CDN 缓存未命中场景中。此外，当源站不支持后量子密钥交换时，自动密钥交换功能将无法优先采用该方案，尽管 Cloudflare 表示该功能仍然可以通过学习源站偏好的经典算法来发挥作用。

密钥协商只是问题的一半。虽然它能保护当前的流量免遭未来解密，但无法阻止拥有量子计算机的攻击者伪造经典证书并冒充源站身份。自 2026 年年中起，Cloudflare 已经在“经过身份验证的源站拉取”和“自定义源站信任存储库”"中支持 ML-DSA 后量子签名。现在，这两项功能结合使用已经能够实现对源站的端到端后量子身份验证。文档警告称，除非验证方拒绝接受经典证书，否则部署 ML-DSA 证书毫无意义——因为攻击者一旦获取了经典密钥，依然可以冒充通信对端进行身份伪造。

他们的路线图上列出了三项内容。由于偏好设置是按区域来定的，所以一个性能滞后的源站可能会拖慢整个区域的进度，而 Cloudflare 计划按源站进行精细化管理。通过对控制台和 API 进行按需扫描，使运维人员在升级 TLS 栈后能够立即触发重新评估，而无需等待下一次每日扫描。此外，该公司还计划扩展扫描功能，自动检测 ML-DSA 支持情况，并为需要严格保护的客户禁用经典加密的回退机制。

Cloudflare 对这项工作的定位是应对 2029 年的“ Q 日”——业内部分评估认为，经典加密算法可能在这一年被破解。同时，该工作也是为了应对“先采集、后解密”攻击，即攻击者将记录的流量存储起来以便日后解密。BoringSSL、OpenSSL 和 rustls 的最新版本已经包含后量子加密支持，而企业源站技术栈、云负载均衡器和嵌入式 TLS 终结器则在按各自的时间表进行升级。

原文链接：https://www.infoq.com/news/2026/09/cloudflare-automatic-key-exchang/"

从 Demo 到生产：AI Agent 缺的到底是什么？

作者：Trista Pan — Fri, 09 Oct 2026 03:13:00 GMT

搭一个 AI Agent Demo，可能一个下午就够了。但要把它真正做到可以投入生产，完全是另一回事。

一个生产级 Agent 必须稳定在线、足够安全、控制好成本，而且当它不可避免地出问题时，你还得有足够的可观测性去弄清楚到底哪里出了错。这些能力几乎都不是模型本身提供的，而是来自你围绕模型搭出来的所有东西：记忆、工具访问、模型路由、护栏、成本控制，以及当 Agent 开始乱来时，你不得不翻进去排查的各种 trace。

这一层，就是我们所说的 Agent Harness。

接下来这篇文章会带你了解什么是 Agent Harness，以及它的两大组成部分：开发和运维。然后，我们会看看团队该如何决定哪些东西自己管理，从完全托管的 Harness-as-a-Service 到自主管理的技术栈。最后，我会用两种方式分别构建同一个 Agent——FinBot，并逐项对比它们如何实现同样的能力。读完之后，你应该会更清楚，如何利用本文介绍的 Harness 能力来构建真正可投入生产的 Agent。

Agent = Model + Harness

“Agent Harness”这个说法是今年才真正流行起来的，但背后的工作早就存在了。如果你去年就在做 Agent，其实已经在干这些事：把各种工具接起来、反复调 Prompt、补上重试和日志，再在系统半夜把人叫醒之后，第二天继续修复故障。现在真正发生的变化，只是大家终于给这些工作起了一个统一的名字。这个名字很有用，因为它让你可以把这些零散能力当成一个整体来设计，而不是每出一次问题，就往系统里再塞一个临时修复。

我最常用的一种理解方式，来自 Vivek Trivedy 的文章 The Anatomy of an Agent Harness"：Agent = 模型 + Harness。换句话说，如果你负责的不是模型本身，那你做的基本都属于 Harness。用汽车来类比，这件事就很好理解了。

模型就像发动机，动力来自这里。但没有人会把一台裸发动机固定在托盘上，然后直接交付给客户。底盘、刹车、仪表盘和安全带，才让它成为一辆你愿意让家人坐进去的车。模型只是发动机；真正让产品变得安全、可靠、好用的，是你围绕它搭出来的 Harness。

Harness 分成哪两部分？

在我看来，Harness 大致可以分成两部分。开发侧负责扩展模型能做什么，包括跨会话记忆、工具和 MCP、检索、Prompt，以及编排。运维侧负责在真实用户进来之后，让整个系统稳定运行，包括可观测性、评估、护栏、路由、漂移和成本监控、部署，以及扩缩容。

这里需要说明一下：看到这样一张两边明显不对称的图，很容易误以为模型没那么重要。当然不是。真正困难的认知工作依然由模型完成，模型越强，上层能力也会一起受益。这里想强调的是：一个 AI Agent 并不只是模型，它最终是一个产品。做出一个好产品，远不只是给模型包一层 API，而那些让它真正能被用户使用的额外工作，大多都落在 Harness 上。如果你过去做过线上服务，这里面很多东西其实并不陌生：尤其运维这一半，本质上就是换了个名字的 DevOps。

两条路线：托管还是自己管？

有一点最好先想清楚：HaaS 和自主管理方案，本质上解决的是同一类问题——它们都是构建和运行 Agent 的基础设施。底层也都是那几块能力：模型访问、检索、工具和 MCP、路由、护栏等等。

真正不同的，是这些能力如何交到你手里，以及你如何使用它们。HaaS 把它们做成托管 API，你负责配置；自主管理方案则把这些组件交给你，由你自己组装、部署和维护。这个差异最终会落到几个很实际的问题上：你能多快上线、能保留多少控制权，以及 Harness 最后要花多少钱——一边是供应商账单，另一边是基础设施和工程人力的成本。零件其实没变，变的是谁来装，以及坏了以后谁会在半夜被叫醒。

该选托管，还是自己搭？

Harness-as-a-Service 在一端，自主管理在另一端，很多团队最后都会落在中间，这很正常。两者之间有多种选择，具体选哪一种，主要看下面几个问题：

团队能力——你们能不能长期维护 Kubernetes、Gateway，并安排值班？或者说，你们其实真的不想管这些？

现有云投入——你们已经完全押注 AWS，还是有意保持多云？

成本——你更想要一张可预测的供应商账单，还是基础设施成本再加自己运行它所需的工程时间？HaaS 更容易做预算；而在规模扩大之后，如果无论如何你都已经要投入人力运营系统，自主管理有可能更便宜。

治理——护栏、审计记录和数据路径是否必须留在你自己的边界之内？有些企业要求所有这些东西都必须运行在自己的 VPC 中。

可移植性——只用一家供应商没有问题，还是你必须保持云无关？

预期规模——为了支撑这个规模，你愿意承担多复杂的一套运维体系。

对运维复杂度的容忍度——你真的愿意长期处理集群维护、升级，以及偶尔凌晨 3 点响起的告警吗？

用 FinBot 看看生产级 Agent 真正缺什么

FinBot 是一个很小的 Agent，两种方案都会使用同一个场景。用户提出一个财务问题：“总结第三季度营收”。FinBot 会从文档存储中取出该季度的财报，把数字交给代码解释器，再调用模型写出总结，最后返回答案。

要让这套流程真正进入生产环境，关键并不在于选一个更聪明的模型，而在于围绕模型搭建什么。再强的模型，自己也不会记住上一轮对话，不会访问财报，不会在失控循环产生巨额账单之前停下来，也不会在出错之后告诉你问题到底发生在哪。这些都是 Harness 要解决的事情，它们围绕着同一条请求路径展开。接下来，我会让同一个请求分别走过两套方案，完成同样的任务，只是按照各自技术栈最自然的方式来实现。

一套真正的 Harness 包含很多相互配合的组件（可以回头看看前面那两大部分），一篇文章不可能全部讲完。我会从两边各挑几项：先看 FinBot 本身如何构建，再看三个运维能力。在我的经验里，它们往往最能决定一个 Agent 是否达到了生产要求。护栏、评估、Prompt 编排、部署和扩缩容，以及多 Agent 工作流，这里都不会展开。这些确实是本文没有覆盖的部分，并不意味着可以将它们排除在外，因为要把 Demo 真正做到生产可用，这些问题也都必须处理。下面先说明所选的几项能力为什么重要，这样后面的方案 1 和方案 2 就可以专注于各自如何实现它们。

构建 Agent

开发侧只保留 FinBot 真正需要的东西：System Prompt、它能访问的工具（一个用于财报的 MCP Server，以及一个运行 MCP 代码执行服务器的容器）、针对这些财报的检索，以及跨轮次记忆。这也是两套技术栈差异感最明显的地方。一边是一个配置对象，另一边则是一组需要你自己部署和维护版本的进程。

统一模型访问

每一家模型供应商都有自己的 SDK、认证方式和响应格式，自托管模型还会再多一套。你真正需要的是一个统一入口，这样无论是新增模型、给新模型做金丝雀测试，还是故障时切到另一家供应商，都只需要改配置，而不是改应用。供应商密钥也只需要放在一个地方，而不是散落在每个服务中。

成本控制

一个有 Bug 的循环，或者一个没考虑周全的功能，都可能让 Token 用量瞬间失控，最后变成一张巨额账单。你需要计量、预算，以及当达到限制时还能优雅处理的机制，例如直接设一个硬上限终止循环，或者切到备用方案继续服务，而不是等账单来了才发现出了问题。

可观测性

Agent 本身就像黑盒，如果还接了多个供应商，情况只会更糟。如果没有一个统一视图把 Prompt、工具调用和响应串起来，再加上延迟和成本，你连 Debug 都做不到，更别说优化了。

接下来，我们来看同一个 Agent 和同样三个能力，如何用两种方式实现。

先看两套方案分别长什么样

在进入具体能力之前，先快速看看两种方案到底由什么组成。两边提供的是同一组基础能力，只是组织和交付方式不同，接下来几节主要讲的就是这些差异。

Amazon Bedrock AgentCore 提供 Runtime、Memory、Identity、Gateway、Observability、Code Interpreter 和 Browser 等生产环境基础能力。AgentCore Harness 则是在它们之上的一层托管封装，把原本“自己把这些组件一个个接起来”的工作，变成“填配置”。你通过 CreateHarness 和 InvokeHarness 两个调用描述 Agent，Harness 就会负责连接底层组件：每个会话对应一个 Firecracker microVM，再加上托管记忆、身份管理和自动追踪。

当配置无法满足需求时，可以用一个命令把 Harness 导出成可编辑的 Strands 代码，并继续运行在原来的 Runtime 上。80% 的通用功能交给配置，真正属于你自己的那 20%，再用代码解决。

自主管理方案则让 FinBot 保持为一个普通 LangChain Agent，运行在你自己的集群上，并把 Harness 中负责模型访问的那部分交给请求路径上的 Gateway。

Agent Router（原 Envoy AI Gateway）是一个建立在 Envoy Proxy 和 CNCF Envoy Gateway 之上的开源 Gateway，专门面向生成式 AI 流量：它在多个模型供应商前面提供一个兼容 OpenAI 的统一 Endpoint，并支持基于 Token 的限流、路由和故障切换、可观测性，以及一个 ext_proc 扩展 Hook，同时明确拆分控制平面和数据平面。请求路径也很容易理解：FinBot 向 Gateway 发起一个 OpenAI 风格的调用；数据平面（Envoy Proxy 加一个 ext_proc 服务）会先完成认证、按模型路由、执行护栏、统计 Token，并注入上游凭证，之后请求才真正到达模型供应商。控制平面则由一组 Controller 组成，它们监听你的 Kubernetes CRD，然后通过 xDS 下发配置。整个系统都运行在你自己的集群里，也不绑定任何一家云厂商。只要是 Kubernetes 都可以，无论 EKS、GKE、AKS 还是本地部署。

本文示例运行在 EKS 上，后端连接 Bedrock。如果你把整套技术栈迁到另一家云，比如用 GKE 对接 Vertex，那么这就是云无关带来的好处：FinBot 的代码和它调用的 Endpoint 都不用改。你只需要重新配置底层，包括 Backend Schema、模型 ID、凭证、Workload Identity 和部署配置。

构建 FinBot：工具、MCP、记忆与检索

方案 1 把 FinBot 跑在 AWS AgentCore 上，也就是供应商运行的 Harness Runtime；方案 2 则在你自己的集群中运行同一个 LangChain Agent，并让它位于 Agent Router 后面。两边都需要同样四样东西：System Prompt、可以访问的工具、对财报的检索，以及跨轮次记忆。在 AgentCore 上，这些内容都是一次控制平面调用里的字段：

import boto3 control = boto3.client("bedrock-agentcore-control") runtime = boto3.client("bedrock-agentcore") harness = control.create_harness( harnessName="finbot", executionRoleArn=ROLE_ARN, systemPrompt=[{"text": "You are FinBot, a finance assistant."}], model={"bedrockModelConfig": { "modelId": "us.anthropic.claude-sonnet-4-6", "apiFormat": "converse_stream"}}, tools=[ {"type": "agentcore_code_interpreter", "name": "code"}, {"type": "remote_mcp", "name": "filings", "config": {"remoteMcp": {"url": "https://mcp.internal/filings"}}}, ], memory={"managedMemoryConfiguration": { "strategies": ["SEMANTIC", "SUMMARIZATION"], "eventExpiryDuration": 60}}, ) resp = runtime.invoke_harness( harnessArn=harness["harnessArn"], runtimeSessionId=SESSION_ID, messages=[{"role": "user", "content": [{"text": "Summarize Q3 revenue."}]}], )

检索本身并不是 Harness 的一个独立字段：Amazon Bedrock Knowledge Base 会以 Gateway Connector Target 的形式接入，并像其他工具一样挂上去。在自主管理方案中，同样四块能力，则由你自己部署和维护版本的多个独立组件拼起来：

from langchain.agents import create_agent from langchain_openai import ChatOpenAI from langchain_mcp_adapters.client import MultiServerMCPClient from langchain_core.tools.retriever import create_retriever_tool from langgraph.checkpoint.postgres.aio import AsyncPostgresSaver from psycopg_pool import AsyncConnectionPool from psycopg.rows import dict_row model = ChatOpenAI(model="finbot", base_url="http://ai-gateway/v1", api_key="unused", default_headers={"x-ai-eg-model": "finbot"}) async def build_agent(): # once, at startup pool = AsyncConnectionPool(DB_URI, open=False, kwargs={"autocommit": True, "row_factory": dict_row}) await pool.open() # long-lived, shared checkpointer = AsyncPostgresSaver(pool) await checkpointer.setup() # migration: run once, not per request mcp = MultiServerMCPClient({"filings": {"url": "http://filings-mcp:8000/mcp", "transport": "http"}, "code": {"url": "http://code-sandbox:8000/mcp", "transport": "http"}}) tools = [*await mcp.get_tools(), create_retriever_tool(vector_store.as_retriever(search_kwargs={"k": 4}), name="search_filings", description="Search quarterly filings.")] return create_agent(model, tools, system_prompt="You are FinBot, a finance assistant.", checkpointer=checkpointer) async def answer(agent, question, session_id): # per request return await agent.ainvoke( {"messages": [{"role": "user", "content": question}]}, {"configurable": {"thread_id": session_id}}) # memory keyed by session

两边用的还是同样四块积木，走的也是同一条请求路径。区别在于，一边它们只是配置对象里的几个字段；另一边则是各自拥有生命周期的独立进程。就这两个标识符来看，差别只是 runtimeSessionId 和 thread_id。

模型访问

每个供应商前面都建立一个统一入口，这样新增模型、对新模型做金丝雀测试，或者发生故障时切换，都只是改配置，而不是改应用。

在 AgentCore 上

指定模型只是配置，而且每次调用时都可以覆盖。AgentCore 底层可以处理 Bedrock、OpenAI、Gemini，以及所有兼容 LiteLLM 的供应商，也可以在不丢失上下文的情况下，在一次 Session 中途切换供应商，并把第三方密钥保存在 AgentCore Identity 的 Token Vault 中。model 字段是四种配置的联合类型（bedrockModelConfig、openAiModelConfig、geminiModelConfig、liteLlmModelConfig），既可以配置在 Harness 上，也能在每次调用时单独覆盖：

resp = runtime.invoke_harness( harnessArn=harness["harnessArn"], runtimeSessionId=SESSION_ID, model={"openAiModelConfig": {"modelId": "gpt-4o"}}, # swap provider per call messages=[{"role": "user", "content": [{"text": "Summarize Q3 revenue."}]}], )

自主管理

Agent Router 提供一个兼容 OpenAI 的统一 Endpoint，并把模型别名映射到具体 Backend，供应商凭证则保存在 Gateway 上：

kind: AIGatewayRoute spec: rules: - matches: - headers: [{ name: x-ai-eg-model, value: finbot }] backendRefs: - name: bedrock-claude modelNameOverride: us.anthropic.claude-sonnet-4-6 # alias -> real model id --- kind: AIServiceBackend # translate OpenAI schema -> Bedrock spec: { schema: { name: AWSBedrock } }

FinBot 用普通客户端指向这一个 Endpoint 即可，完全不会接触供应商密钥；切换模型或供应商，只需要换它发送的别名。凭证始终留在 Gateway。对于 Bedrock 来说，这意味着使用一个由 EKS Pod Identity 或 IRSA 支撑的 AWSCredentials Policy，因此集群里不需要存放静态密钥：

apiVersion: aigateway.envoyproxy.io/v1beta1 kind: BackendSecurityPolicy spec: targetRefs: - {group: aigateway.envoyproxy.io, kind: AIServiceBackend, name: bedrock-claude} type: AWSCredentials # Bedrock uses AWS auth awsCredentials: region: us-east-1 # credentials via EKS Pod Identity or IRSA

两种方式都提供一个统一入口。AgentCore 的入口是一个 API，你通过不同的配置对象调用；Gateway 的入口则是一条你自己部署的 Route。真正体现差异的地方，是供应商密钥放在哪里：要么放在 AgentCore Identity 的 Token Vault 中，要么通过 Pod Identity 或 IRSA，把 IAM Role 挂到 Gateway 上。

成本控制：别等账单来了才发现 Agent 跑疯了

成本控制意味着两件事：要有一个硬上限，能直接停掉失控循环；也要有真正可以在账单到来之前执行的预算。

在 AgentCore 上

AgentCore 直接针对失控循环这个故障模式下手，提供单次调用级别的硬上限，包括 maxIterations（默认 75）、maxTokens 和 timeoutSeconds，另外还有用于成本分摊的 Tag，以及 CloudWatch 中的 Token 指标：

aws bedrock-agentcore-control update-harness \ --harness-id "finbot-UuFdkQoXSL" \ --max-iterations 50 --max-tokens 8192 --timeout-seconds 1800

自主管理

Gateway 会把 Token 作为一次请求的成本进行计量。这里，我们给每个用户设置一个每日 Token 预算，并根据响应实际消耗扣减。一旦预算耗尽，Gateway 就会用 HTTP 429 拒绝后续请求（尽管字段名叫 limit.requests，但这里实际限制的是 Token 预算）：

kind: AIGatewayRoute spec: llmRequestCosts: - { metadataKey: llm_total_token, type: TotalToken } rules: - matches: [{ headers: [{ name: x-ai-eg-model, value: finbot }] }] backendRefs: [{ name: bedrock-claude }] --- kind: BackendTrafficPolicy spec: rateLimit: global: rules: - clientSelectors: [{ headers: [{ name: x-user-id, type: Distinct }] }] limit: { requests: 5000000, unit: Day } cost: request: { from: Number, number: 0 } response: { from: Metadata, metadata: { namespace: io.envoy.ai_gateway, key: llm_total_token } }

AgentCore 限制的是 Agent 本身，而 Gateway 限制的是流量。一个可以在单次调用过程中直接终止循环，另一个则会在某个租户的 Token 预算耗尽之后拒绝下一次请求。只有后者知道“租户”是什么。

可观测性：出了问题，至少要知道发生了什么

你需要的是一个统一视图，把 Prompt、工具调用和响应串起来，同时附上延迟和成本。

在 AgentCore 上

在 AgentCore 上，这部分几乎是现成的。每次调用都会自动把 Trace、日志和指标发送到 CloudWatch，包括模型调用、工具调用和记忆操作，并集中展示。账号层面做一次前置配置之后，后续调用都会自动进入追踪：

# one-time, account level aws logs put-resource-policy --policy-name MyResourcePolicy \ --policy-document file://xray-to-logs.json # logs:PutLogEvents for xray.amazonaws.com aws xray update-trace-segment-destination --destination CloudWatchLogs

你也可以额外加一条索引规则来设置采样比例，但这不是必须的。

想知道它到底帮你省掉了多少工作，可以和自己给 Agent 做埋点对比一下。如果 Agent 托管在 Runtime 之外，你需要设置 AGENT_OBSERVABILITY_ENABLED、OTEL_PYTHON_DISTRO 和 OTEL_PYTHON_CONFIGURATOR，还要用 opentelemetry-instrument 包住启动命令。如果把自己的容器带到 AgentCore Runtime 上，Runtime 会自动设置 ADOT 默认项，这时只剩 opentelemetry-instrument 这一层包装。再进一步，如果使用 AgentCore CLI 部署，它在打包阶段就会自动加入 Instrumentation，连这个 Wrapper 都不用你自己加。Harness 开发者完全不用写这些东西。

自主管理

Agent Router 会按照 OpenTelemetry 的语义约定输出生成式 AI 指标，包括 Token 使用量、首 Token 时间，以及 Token 间延迟，Prometheus 可以直接抓取：

scrape_configs: - job_name: envoy-ai-gateway relabel_configs: - source_labels: [__meta_kubernetes_pod_container_port_name] regex: "metrics|aigw-admin" action: keep # exposed GenAI metrics (OTel semconv): # gen_ai.client.token.usage # gen_ai.server.time_to_first_token

因此，真正发生事故时最常问的两个问题——谁在烧 Token，谁最慢——各自只需要一条查询。由于指标名采用标准语义，所以换模型供应商也依然可用：

sum(gen_ai_client_token_usage_sum{gateway_envoyproxy_io_owning_gateway_name="finbot"}) by (gen_ai_request_model, gen_ai_token_type)

指标可以告诉你消耗了多少、哪里慢。但如果想知道具体发生了什么，还需要 Trace。整体结构很简单：两个数据生产端、一个采集器，再加一个后端。

两边都会通过 OTLP 输出同一套 gen_ai.* 语义，这也是为什么它们的 Span 最后能对齐。Instrumentation 和 Backend 可以独立选择：Langfuse、Phoenix 和 OpenLIT 都既提供 LangChain SDK，也提供后端，因此你完全可以用一个做埋点，再把数据存进另一个。在 Gateway 侧，只需要让 ext-proc 指向 Collector：

kind: GatewayConfig spec: extProc: kubernetes: env: - { name: OTEL_EXPORTER_OTLP_ENDPOINT, value: "http://otel-collector:4317" } - { name: AI_GATEWAY_TRACING_SEMCONV, value: "gen_ai" } # gen_ai.* span names

这些 Span 覆盖请求路径中的模型调用。循环剩下的部分——工具调用、Agent 自己的控制流、Prompt 拼装——从来不会离开应用进程，所以应用本身还需要 Instrumentation。OpenLIT 只需要一行代码，而且使用同一套语义：

import openlit openlit.init(otlp_endpoint="http://otel-collector:4318") # once, at startup

OpenTelemetry 项目本身也提供 LangChain Instrumentation，不过截至本文写作时还处于 Beta。无论你选哪种方式，有一点几乎所有人都会踩坑：消息内容默认不会被采集。所以，如果你希望 Trace 里能看到 Prompt 本身，需要在两边都设置 OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT=SPAN_ONLY，同时也得认真考虑一旦打开之后，到底谁有权限读取这些内容。

把两边都指向同一个 Collector，你就能得到一条从 Prompt 到工具再到响应的完整链路。这其实和你把自己的代码带进 AgentCore Runtime 时需要做的 Instrumentation 工作是一样的；真正不同的是，只有 Harness 会替你把整个 Agent Loop 自动 Trace 下来。

最后：生产级 Agent，本质上还是架构问题

本文介绍了 Agent Harness 这个概念，并展示了两种构建方式：一种是使用 Harness-as-a-Service 的托管方案，另一种是自主管理方案。篇幅有限，我们只用 FinBot 演示了 Harness 的其中几项能力，其余部分就留给你继续探索。

无论最后选哪条路线，构建和运行 Agent 最终都会面对相似的问题，而这些更多是架构问题，并没有什么魔法。你需要先想清楚产品要完成什么、什么才算做好，以及哪些边界绝对不能越。模型提供推理能力，Harness 负责提供控制，让这种推理能力真正成为可以交付的产品。你定义目标和边界，工具负责在这个范围内完成工作。

原文链接：https://www.infoq.com/articles/agent-harness-build-one/"

全球扩散语言模型最大融资诞生：经纬、顺为、君联数亿元押注扩散智能DiffuSpace

蔡芳芳 — Fri, 09 Oct 2026 03:07:57 GMT

作者| 蔡芳芳

近日，扩散智能DiffuSpace连续完成两轮融资，总金额数亿人民币，创全球扩散语言模型（dLLM）最大规模融资纪录，由经纬创投、顺为资本、君联资本联合领投，中科创星、华为哈勃、地平线等跟投。

扩散智能DiffuSpace致力于探索以扩散语言模型为核心的下一代基座模型，本轮融资将主要用于模型训练、垂直场景适配与基础设施研发。据悉，DiffuSpace正在推进新一代更大参数规模dLLM的训练，并计划于近期发布并开源。

扩散智能DiffuSpace由港大NLP实验室联合主管孔令鹏教授及其博士生龚珊三、叶佳成联合创立，核心团队长期深耕扩散语言模型研究，是全球最早探索该技术路线的团队之一，并在“条件生成、离散信号建模、Scaling”三大dLLM核心问题上均有全球领先突破。成员均来自清华、北大、港大、CMU等顶尖高校及头部模型团队。2022年，团队推出DiffuSeq，开创了扩散模型处理序列到序列文本生成的技术路径；2025年，团队推出的Dream 7B模型首次全面超越同参数规模的自回归模型，并在规划能力上比肩671B的DeepSeek V3。

2026年以来，dLLM在技术突破、产业关注和资本热度等方面持续升温。2026年前8个月，相关论文总数已达2025年全年的2.4倍。Google、Inception、蚂蚁集团等科技企业也在持续加码这一方向：Google已推出文本扩散模型Gemini Diffusion，美国dLLM公司Inception推出Mercury系列通用模型，并获得NVIDIA加速计算团队公开关注；蚂蚁集团等模型团队也陆续推出相关模型。随着更多头部科技公司和创业团队布局这一方向，扩散语言模型正从前沿研究加速走向工程化验证与应用探索。

近期报道显示，DiffuSpace与亚洲智能体计算平台公司Acrab已达成合作，通过dLLM的并行生成与全局建模能力，端侧Agent运行速度可提升5倍。基于此次合作，双方将继续加速推进扩散语言模型在 AI PC、智能汽车、机器人及智能家居等场景的落地。

打造下一代通用模型，扩散语言模型进入Scaling加速期

近年来，扩散语言模型（dLLM）被视为下一代通用人工智能基础模型的重要方向之一。

扩散语言模型拥有更通用的内容生成范式。不同于Claude、GPT等主流自回归模型「从左往右」的生成范式，dLLM可进行全局生成和并行解码，具备更强逻辑规划、全局一致与多模态融合能力，在特定场景下实现5至10倍推理加速，并在规划、复杂推理等能力上超越同规模自回归模型。

相比自回归模型，扩散语言模型的生成范式具备三项核心特点：

可逆修正：自回归模型一旦生成，无法回溯修改前文，只能在后文补充纠正；dLLM则可在生成过程中反复调整任意位置内容，提升内容一致性、减少错误生成。全局求解：生成任意位置均可读取全部上下文，例如，可结合第50行与第200行内容共同求解，实现更强的全局规划与跨段协同能力。柔性计算：动态分配计算资源，简单内容少计算、复杂内容多计算，在生成速度、计算成本与回答质量之间灵活平衡。

在具身智能、智能汽车、AI PC等Agent与多模态场景中，扩散语言模型同样具备优势。相比逐步生成，其能够对更长的动作序列、多模态输入以及多个并行任务进行整体建模，并在生成过程中动态调整。这一机制使dLLM更适合处理连续动作规划、车载任务交互、端侧Agent并行等场景，并在响应速度、任务一致性和全局协调能力等方面实现提升。

从源头创新到持续领先，DiffuSpace四年押注dLLM

资料显示，DiffuSpace核心成员自2022年起投入dLLM研究，先后推出DiffuSeq、RDM、DiffuLLaMA等研究成果，并研发出全球代表性dLLM之一Dream 7B，2025年ICML相关演讲中，Dream 7B与Google Gemini Diffusion、Inception Mercury被并列为三大代表性dLLM。

在这条新技术路线上，DiffuSpace并非沿着既有路径追赶，而是从源头创新。2022年，团队提出DiffuSeq，率先将扩散模型系统引入序列到序列条件文本生成（Seq2Seq），第一次让扩散模型能够完成对话、改写、问句生成、文本简化等真实应用。该成果后被ICLR 2023收录，成为早期条件式文本扩散领域的代表性工作。

2025年，团队推出 Dream 7B模型，打通dLLM的Scaling路径，该模型在数学、代码、规划等任务上全面超过同规模的自回归模型，部分指标甚至超过DeepSeek V3（671B），已在Hugging Face上获得超过250万下载量。基于Dream 7B，团队又陆续推出视觉语言模型Dream-VL、视觉-语言-行动模型Dream-VLA、DreamOn等垂类模型，进一步验证dLLM在多模态、Agent及具身智能等场景中的应用潜力。

2026年5月，DiffuSpace正式创立，并落地深圳，迈出了从实验室走向规模化训练的第一步。从DiffuSeq到Dream 7B，经过四年持续研发，团队已形成覆盖算法、数据、训练和推理的dLLM全栈能力。其所在的大湾区集聚了芯片、智能汽车、机器人、智能终端等产业资源，为基础模型与硬件、终端企业的协同提供了产业土壤。目前，DiffuSpace正在推进新一代更大参数规模模型训练。

Kimi 现代高速开源治理的 AI Native 实践｜QCon上海

QCon全球软件开发大会 — Fri, 09 Oct 2026 02:00:00 GMT

从「构建 AI」到「驾驭 AI」，100+ 实战案例拆解 AI Native 时代的工程新实践！

2026 年 QCon 全球软件开发大会大会 · 上海站"

将于 10 月 22 日—24 日举办，聚焦 Harness AI 时代的工程实践，围绕 AI Native 架构、Agent Runtime、AI Infra、Data Systems、Agent 安全与可观测、Loop Engineering、Vibe Coding、具身智能与世界模型、端云协同等前沿技术方向，邀请全球技术社区与产业一线的实践者，系统性分享前沿洞察与实战经验，共同探索 AI 从能力到系统、从实验到生产的真实路径。

在这一背景下，2026 年 QCon 全球软件开发大会大会 · 上海站"正式启动。本次大会将于 10 月 22 日—24 日举办，聚焦 Harness AI 时代的工程实践，围绕 AI Native 架构、Agent Runtime、AI Infra、Data Systems、Agent 安全与可观测、Loop Engineering、Vibe Coding、具身智能与世界模型、端云协同等前沿技术方向，邀请全球技术社区与产业一线的实践者，系统性分享前沿洞察与实战经验，共同探索 AI 从能力到系统、从实验到生产的真实路径。

月之暗面研发工程师/开发者关系负责人唐飞虎已确认出席 “AI 驱动的软件工程"” 专题，并发表题为《Kimi 现代高速开源治理的 AI Native 实践"》的主题分享。AI Coding 让代码生产速度大幅提升，但 Issue、PR、合规、安全等治理环节仍依赖人工，逐渐成为研发效率的新瓶颈。

她本次分享将结合 Kimi Agent Harness 在开源场景的实践，介绍开源治理智能体 Mira 如何把 AI 从“发现问题”推进到“解决问题”：自动完成 Issue 分诊、PR Review、依赖与许可证扫描、安全漏洞响应，并通过渐进式授权、人机协同和全链路审计，让 Agent 真正进入生产治理流程。

分享将重点拆解从通用 Agent 到垂直治理 Agent 的工程实践，以及如何解决“敢不敢让 AI 动手”这一核心问题，并通过真实治理数据展示 Agent 对响应效率、维护者负担和治理质量的实际提升，探讨 AI Native 时代开源治理的新范式。

唐飞虎是前谷歌工程师，Kimi 大模型研发，开发者关系负责人。她在本次会议的详细演讲内容如下：

演讲提纲1. 开源治理的新瓶颈AI Coding 提速后，治理为什么反而成为瓶颈Issue、PR、合规、安全的人工治理困境2. 从 Agent Harness 到 MiraAgent 如何进入真实开源生产环境Issue / PR / CI / SBOM 等数据如何接入从只读诊断到自动执行的渐进式授权3. Mira 核心实践Issue 自动分诊与响应PR Review 与合并辅助许可证、依赖与漏洞治理从发现问题到自动修复 PR 的闭环4. AI 怎么做到“敢动手”人机协同审批权限分级全链路审计与回放自动化边界如何定义5. 真实数据与未来治理效率、响应时间、维护者负担的变化从“AI 辅助治理”走向“AI Native 治理”前沿亮点让 Agent 真正动手治理开源项目：不止分析和告警，而是直接分诊、Review、修复、验证解决 Agent 生产落地最大的信任问题：通过渐进式授权 + 人机协同 + 全链路审计，让 AI “敢做事、做错可追溯”从发现问题到闭环解决：打通 Issue、PR、CI、SBOM、安全情报，形成真正的治理闭环真实生产数据验证：不是 Demo，而是用实际治理效率和维护者负担数据验证 Agent 价值听众收益学会一套 Agent 进入真实生产系统的工程方法：权限、审批、审计、可观测了解 AI 如何从“发现问题”走向“自动解决问题”获得一套可迁移的 AI Native 治理范式，用于研发、运维、安全等其他 Agent 场景

除此之外，本次大会还策划了Loop Engineering"、千行百业 Agent 创新实践"、Agent 自主进化：从记忆到持续学习"、Agent as a Service"、Vibe Coding 时代的新质量债"、理性驾驭 AI 的 SRE 可靠性工程"、金融 AI Native工程实践：从研发提效到业务破局"、AI Infra：算力效率决定规模化落地"、AI Native 架构"等20个专题论坛，届时将有来自不同行业、不同领域、不同企业的100+资深专家在现场带来前沿技术洞察和一线实践经验。

查看更多详情可扫码或联系票务经理 18514549229进行咨询。

在生产环境中保护MCP：超越网关的纵深防御

作者：Nik Kale — Fri, 09 Oct 2026 01:05:00 GMT

核心要点

将MCP安全视为四个控制层而非单一的协议特性。执行、基础设施管理、出站信任与语义完整性都需要对应的强制执行点。使用网关进行认证、授权与审计，但不要指望它能检测语义滥用或保护管理平面。在注册时对工具Manifest进行固定，以避免批准后的模式漂移和“rug-pull”行为。将基于差异的评审作为运维模型，而非简单的允许/拒绝门控。使用出站出口控制与作用域令牌。Azure MCP Server的SSRF漏洞(CVE-2026-26118")表明仅有入站认证并不足以解决问题。优先考虑可操作性：CI门控、隔离工具、基于差异的Manifest评审与行为基线。规范会随后补上，但生产不能等待。

为什么写这篇文章，以及为何现在写

在2025年底，我们团队决定将MCP（Model Context Protocol，模型上下文协议）作为生产级多智能体平台的集成层。我们只问了一个问题：在大规模的自动化（基于工具）执行之前，需要哪些架构控制才能让我们信任它？

简洁的答案，也是本文的论点，那就是需要四个层面：安全的工具执行、隔离的管理平面、受限的出站信任边界以及语义完整性，每一项都应该在其对应的可信任点上强制执行，而不是仅仅依赖网关。

这些层次在刚开始时并不明显，但接下来六个月的漏洞记录将它们勾勒了出来。在2026年最初的六十天中，针对MCP部署的CVE报告超过了三十个"。

来自Adversa AI"的三月份数据表明，在扫描五百多个MCP服务器时，38%的关键端点缺少认证，43%存在命令执行漏洞。微软在3月10日发布补丁修复了Azure MCP Server的SSRF漏洞（CVE-2026-26118，CVSS 8.8），该漏洞会导致托管身份令牌泄露。

在3月9日，主维护者David Soria Parra发布了2026 MCP路线图"。文档将“企业就绪性”列为优先关注的领域，但同时指出在四个方向中它可能是最不明确的。

在2026年4月2日至3日的MCP开发者峰会上，亚马逊云科技与优步分享了它们的MCP Gateway与Registry的生产架构，Pinterest的工程团队"也公布了其域专用的MCP服务器生态。企业级生产环境MCP的使用速度快于安全规范成熟的速度。

综上所述，这些并非孤立的缺陷。它们在少数的几个边界处聚集，这意味着需要架构性的响应而非零星的修补。本文描述了我认为如今每个生产环境的MCP部署都需要的架构控制模式。每种模式均与当前MCP规范兼容，不需要更改协议。

MCP安全是一个控制平面的问题

在早期实现中，第一个直觉是将网关置于MCP流量之前。这是正确的直觉。网关是集中认证、授权、审计与策略评估的地方。InfoQ近期发布"了一篇使用MCP、OPA与短期运行器（ephemeral runner）实现的最小权限AI Agent Gateway的详细实现文章，该设计非常接近理想情况。

然而，网关只是一个强制执行点，而不是完整的控制平面。网关无法确保工具处理器能够以安全的方式执行其参数，它无法隔离围绕MCP的检查器、测试工具与管理控制台，也无法阻止MCP服务器使用过宽的凭据发起不安全的出站调用。此外，网关也无法检测团队上周批准的工具定义何时会发生变化。

我对每一种MCP故障模式都会提出同一个问题：最早的可信强制执行点在哪里？

对于命令注入，答案是工具处理器和CI流水线；对于暴露的检查器（inspector），是管理平面和网络边界；对于通过出站请求泄露凭据，是出站策略与令牌作用域；对于工具定义漂移，是注册边界，在此处本应该对Manifest进行固定、差异比较与评审。

从形态上看，这就是控制平面，而不是单一的网关。在这些点上分散强制执行，也会将责任分散到构建、托管与运行MCP服务器的团队和厂商。CoSAI的共享责任框架"阐明了AI栈中安全责任的划分以及当智能体失效时该由谁负责。这些强制点将在下一节被规范化为四个控制层。

四个控制层

这四个层次并不能构成一个严谨的分类体系。它们各自独立存在依然具有一定的局限性，比如，加固执行环境对存在漏洞的出站路径毫无帮助，固定Manifest也无法证明检查器的身份合法性。每个层面都有其最早触发的强制执行点，并且通常由不同的团队负责。正是这些差异，决定了它们是相互独立的安全边界，而不是从四个不同角度看待同一个问题。

这种框架在业界与学术界也越来越常见。Acharya与Gupta（2026）"提出了MCPShield，这是一个将威胁划分为四类攻击面的安全框架。Rostamzadeh等人"（2026）提出了防御布局分类法，指出现有缓解措施过于集中在工具层，而主机编排、传输与供应链层则防护不足。目前的共识是，MCP防御是一个要分层处理的问题。

表1. 四层控制矩阵

各层的概述如下：

第1层是执行，即在调用工具时运行的代码。第2层是管理基础设施，包括检查器、harness、注册界面和管理控制台。第3层是出站信任边界，即服务器自行可达的目标。第4层是语义完整性，即工具定义随时间推移，其含义是否还保持一致。

每层都有不同的最早可信任强制执行点，并需要不同的主控制。网关只参与其中两层，并且只是是部分参与。

在确立模型后，文章接下来将逐层展开，给出相应的控制措施与实现代码。

第1层：安全的工具执行

第1层关注一件事，那就是工具处理器必须将其参数视为数据，而非指令。

在2026年前六十天记录的30个CVE中，有13个呈现出相同的模式：未验证的用户控制输入到达了shell或动态解释器。例如，CVE-2026-2130(mcp-maigret)、CVE-2026-2178(xcode-mcp-server)与CVE-2026-2131(HarmonyOS-mcp-server)均通过exec()执行了工具参数。CVE-2026-1977在Python中对图表规范（chart specification）的参数使用了eval()。CVE-2026-27203通过未经验证的换行符操纵环境变量，导致在下次服务器重启后会触发载荷。

命令注入并不是什么新的概念。在MCP中，它之所以在架构上如此重要，主要原因在于信任模型。开发者将工具参数视为带类型的JSON，伴随的JSON模式（schema）说明了输入结构，但它并未就值在shell执行环境下的安全性作出保证。

代码1. 易受攻击与修复后的shell执行模式

// VULNERABLE: string interpolation into a shell command const { username } = toolCall.params; exec(`docker run maigret ${username}`); // If username is "; rm -rf /" the shell interprets the semicolon. // FIXED: array-based argument passing, no shell interpretation const { username } = toolCall.params; execFile('docker', ['run', 'maigret', username]); // Semicolons and metacharacters are passed as literal values.

架构原则就是，工具处理器不是便捷的工具化包装器，而是受控的输入边界。

CI规则比代码审查清单更为有用。下面的Semgrep规则会在构建时阻止将工具处理器的参数传入shell解释器的代码提交，这覆盖了大多数MCP服务器实现所用的两种语言。

代码2. Semgrep规则：阻止MCP处理器中的不安全执行

rules: - id: mcp-unsafe-exec-js languages: [javascript, typescript] severity: ERROR message: > MCP tool handler passes a parameter into a shell interpreter. Use execFile or spawn with array arguments instead. pattern-either: - pattern: exec(`...${$PARAM}...`) - pattern: exec($CMD + $PARAM) - pattern: eval($PARAM) - id: mcp-unsafe-exec-py languages: [python] severity: ERROR pattern-either: - pattern: subprocess.run(..., shell=True, ...) - pattern: os.system($CMD) - pattern: eval($PARAM)

需要注意的是，这些规则是起点，并没有覆盖完整的生产环境。它们能够捕获常见的汇流点（sink），生产环境的规则集应该扩展到其他解释器、间接汇流点与特定语言的规避手段。

Huang等人"构建了114个恶意MCP服务器的数据集，表明多组件攻击链常常比单组件攻击更有效。这一发现支持分层防御的方法，因为不应该期望任何单一控制机制能捕获所有的问题。每个信任边界都需要自己的防护。

第2层：保护管理平面

在评估MCP时，我们发现测试harness监听了一个没有认证的内部网络。关闭它只花了二十分钟，但它默认是开放的。快速部署MCP的团队大多在别人发现之前是不会注意到这种暴露的。

该测试harness属于管理平面的范围：授予信任权限和注册工具的界面，一旦它被攻陷，攻击者获得的远不止一次工具调用的权限。

在30个CVE中，有6个针对的是MCP的开发与运行基础设施，而不是协议本身。例如，CVE-2026-23744（MCPJam Inspector）打开了一个未认证的端点，默认监听0.0.0.0，导致可安装任意的MCP服务器；CVE-2026-23523（Dive MCP Host）则利用精心构造的深链接在用户客户端应用内安装恶意配置。

这一层至关重要，因为开发环境通常比生产环境提供更多的访问权限，例如，源代码、密钥、构建系统与部署凭据等。管理平面的漏洞会让攻击者接触到授予信任权限与注册工具的环境，而不仅仅是一次工具调用。

我对MCP管理平面的期望与对CI/CD控制面的期望一致：

禁止匿名访问默认不对外暴露广泛的内部网络访问最小化文件系统的可达范围尽可能使用短期凭据管理端点必须认证并记录日志

把检查器、harness和注册界面视为“接近生产”的组件，因为它们确实如此。

第3层：出站信任、出站限制与令牌作用域

第3层关注的是服务器在运行时能自行访问的目标。

Azure MCP Server的SSRF漏洞（CVE-2026-26118，CVSS 8.8）说明了为何仅靠入站认证是不够的。攻击者将Azure资源标识符替换为恶意URL，服务器使用其托管身份令牌向该URL发起出站调用，从而允许攻击者控制服务器可访问的Azure资源。

我们需要并行采用三项控制：

对每个入站端点强制认证。受控的出站访问（即“egress allow list”），使服务器只能访问其运行所需的服务。确保下游凭据的权限最小化，使令牌的影响范围与工具的影响范围相匹配。

代码3. NetworkPolicy限制MCP服务器的出站流量

# Allow egress only to internal services it needs and to DNS # All other egress traffic will be denied by default. apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: mcp-server-egress spec: podSelector: matchLabels: app: mcp-server policyTypes: - Egress egress: - to: - ipBlock: cidr: 10.0.0.0/8 ports: - port: 443 - to: - namespaceSelector: {} ports: - port: 53 protocol: UDP

在这个场景下，有两点假设值得说明一下。第一，集群的CNI必须真正执行NetworkPolicy（Calico、Cilium等能够做到这一点，一些默认安装方式可能无法做到）。第二，在选定pod下列出Egress作为policyTypes会拒绝所有未明确允许的流量，但将其与命名空间范围内的默认拒绝策略配对使用会更明确，而不会产生这样选择的副作用。

自动化的文件搜索工具不应持有可控制公司云账户的访问令牌。如果工具需要访问新的域或内部服务，那应该是一次显式的变更，而非隐式行为。

这或许不是最有趣的工作，但却是最重要的。许多基于代理的系统保护了“前门”，但是忘记了进入进程后还能做什么。

第4层：语义完整性与Manifest固定

第4层关注的是语义，而非语法，也就是工具是否仍然保持着被信任时的含义。

我认为，最具架构意义的攻击并不是输入验证漏洞，而是语义层面的攻击。请求可能格式正确、模式合法、通过了认证，但仍然具有危险性，因为工具的含义在被授予信任后发生了漂移。

Pillar Security在2026年3月指出了与MCP相关的11类漏洞（The New AI Attack Surface: 3 AI Security Predictions for 2026"），包括供应链拼写仿冒与跨服务器上下文滥用。Solo.io" 提出了“rug-pull”攻击，即服务器在注册后改变工具的定义。Maloyan与Namiot（2026）"将该问题正式化为“缺乏能力认证”：协议缺少在执行时证明工具定义与客户端信任时一致的手段。

上述攻击并不能通过输入验证来阻止。输入是合法的，认证也阻止不了它们，因为调用者是被认证过的，网关策略也不能阻止它们，因为请求符合模式。

Manifest固定能阻止这类攻击。需要明确的是，这是一种在网关处实现的模式，而非MCP规范本身的特性。该控制类似于Web的子资源完整性（Subresource Integrity）。在注册时，网关对服务器的工具Manifest进行规范化，对名称、描述与参数模式进行哈希，并将哈希作为签名基线存储。在重新连接或更新时，网关再次检查哈希值：若相同则允许更新；若不同，则将更新搁置并交由差异分类器，根据差异类别区分外观性修改与实质性的模式变化。

代码4. 在MCP服务器注册期间固定Manifest

import { createHash } from 'node:crypto'; interface ToolManifest { name: string; description: string; parameters: Record; } const registry = new Map(); const operatorQueue: Array = []; function canonicalJson(value: unknown): string { if (value === null || typeof value !== 'object') { return JSON.stringify(value); } if (Array.isArray(value)) { return '[' + value.map(canonicalJson).join(',') + ']'; } const obj = value as Record; return '{' + Object.keys(obj).sort().map(k => JSON.stringify(k) + ':' + canonicalJson(obj[k]) ).join(',') + '}'; } function canonicalize(tools: ToolManifest[]): string { const sorted = [...tools].sort((a, b) => a.name.localeCompare(b.name)); return canonicalJson(sorted); } function pin(serverId: string, tools: ToolManifest[]): PinResult { const canonical = canonicalize(tools); const hash = createHash('sha256').update(canonical).digest('hex'); const existing = registry.get(serverId); if (!existing) { registry.set(serverId, { hash, tools, signedAt: Date.now() }); return { outcome: 'registered', hash }; } if (existing.hash === hash) { return { outcome: 'unchanged', hash }; } const diff = diffSchemas(existing.tools, tools); if (diff.cosmeticOnly) { registry.set(serverId, { hash, tools, signedAt: Date.now() }); return { outcome: 'auto-approved-cosmetic', hash }; } operatorQueue.push({ serverId, diff }); return { outcome: 'pending-review', hash }; }

递归辅助函数在每个层级对键进行排序，以确保相同的Manifest始终产生相同的哈希。建议在生产实现中使用诸如RFC 8785（JCS）等既定的规范化JSON格式，这也固定了数字和字符串的编码方式。

差异分类器（diff classifier）使该控制在运维上是可持续的。纯粹的允许/拒绝门控会产生很多的误报，这样会训练自动化的运维员草率地执行批准操作。将外观性（cosmetic）改动与实质性模式改动区分开，意味着评审队列只包含那些真正需要人工决策的条目。

建议将Manifest固定与行为监控配合使用。监控每个MCP服务器实际访问的端点、数据移动量与延迟模式。当以文件搜索工具形式批准的服务器开始向未知域发起针对外部的HTTP请求时会触发告警，而无需逐条判断每个请求的模式合法性。静态信任与行为验证相结合，比单独使用任何一项控制都更有力。

目前，MCP规范与2026 MCP路线图对Manifest固定均保持了沉默。这是各团队需要在网关层实现的功能。

网关的定位

网关仍然是必要的。关键是将网关正确地放置于这些层级之间，并明确定义哪些功能应该在网关之外。

网关提供了一个合适的平台，以实现客户端认证、按策略授权请求、维护审计轨迹和请求日志、提供速率限制（例如，基于单位时间的请求数进行限制）、管理注册工作流，并集中评估适用于传入请求的策略。这些示例体现了在协议层要强制执行的限制，这正是我们要创建网关所支持的功能。

相比之下，在安全执行、管理平面隔离、出站连接限制和语义漂移检测等方面的检查发生在不同层。因此，正确的做法是将网关视为多层安全解决方案的一个组成部分，并在每个最早的可信层上使用其他的技术方案进行限制。

优步在4月的MCP开发者峰会上关于MCP Gateway与Registry的演讲，以及Pinterest通过单一注册表使用多个域的专用MCP服务器并采用两层授权系统的实践，都体现了这一方法。该模式在生产环境中的趋同速度与研究中的趋同速度相当。

为期四周的推广计划

推广顺序需要遵循控制模型：先部署成熟且易于验证的控制，再部署MCP特有的控制。团队不需要同时实施所有控制，分阶段的方式通常效果更好。

表2. 为期四周的推广计划。

第1周：稳定明显的边界

第1周要关闭那些不需要MCP特有工具即可处理的边界。对每个面向MCP的端点都要求进行认证，将检查器、测试工具与管理控制台迁移到隔离网络，并限制每个进程实际需要的文件系统访问。

第2周：执行路径安全

第2周要使执行路径变得更加安全。增加CI规则，标记可从工具处理器触及的shell插值、eval或以shell=True调用的subprocess，并将热点路径转换为数组参数传递。

第3周：信任限制

第3周要限制出站信任。在服务器层使用出站允许列表，并以工具特定的作用域令牌替换宽泛的服务凭据，使出站HTTP成为服务器被授予的能力而非默认持有的权限。

第4周：开始实现语义控制

第4周开始语义控制。在注册时启用基于差异的Manifest固定评审，并在两到三周的生产流量期间收集每个MCP服务器的行为基线（覆盖端点、数据量与延迟），在基线稳定后对偏差触发告警。

取舍权衡是难以避免的

上述每项控制都会通过牺牲某些方面来换取安全性：延迟、维护或灵活性。这些成本并不是偶然出现，在投入之前要先明确识别它们。

容器化或沙箱化执行会增加延迟。在我们的测试中，与本地执行相比，短期运行器（ephemeral-runner）隔离每次工具调用增加了50到200毫秒。这对后台智能体的工作是可接受的，但对交互式助手则较为明显。

出站允许列表会破坏需要新外部端点的MCP服务器。在我们的场景中，大多数MCP服务器连接三到五个内部服务和一到两个外部API，因此允许列表是可管理的，但需要为每台服务器进行人工处理。

Manifest固定会为演进中的服务器会带来一定的冲突。基于差异的自动化评审可以缓解该问题，但无法完全消除。

行为监控在基线稳定之前会产生成本与误报。在我们的部署中，大多数MCP服务器在两到三周的生产流量后会趋于稳定，低流量服务器则需要更长的时间。我建议将该时间视为我们的运维经验而非通用阈值，因为窗口取决于请求量与可变性。

这些成本是明确的。不过，重要的是，较之凭据泄露或工具重新定义被滥用造成的损失，这些成本要小得多。以我的经验来看，最常见的情况并不是团队过度保护MCP，反而更加频繁地低估他们创造的不同信任边界的数量。

规范的发展方向

有两项进展值得我们关注。首先，从MCP 2026路线图"可以看到，“企业就绪性（enterprise readiness）”是被反复提及的优先事项，尽管它也是四个领域中最不明确的一项，主维护者邀请“所有从生产到贡献都面临挑战的人”。其次，关于NIST在2026年2月启动的AI Agent Standards Initiative"，NCCoE有关于智能体身份与授权的概念性论文。作为OASIS CoSAI与IETF AGNTCY工作组的参与者，我可以说在MCP身份问题上还没有共识，特别是服务器是否应携带自身凭据，或应代表人类用户承载委托权限。CoSAI在RSAC 2026"之后发布了智能体身份与访问控制（Agentic Identity and Access Control）"研究，直接讨论了该问题。

上述两项倡议都很有前景，但都不是不作为的借口。本文详述的控制方式与当前规范和基础设施均兼容，可以立即实施。

结论

回到文章开头提出的问题：在大规模信任工具执行之前需要哪些准备？这四个层次就是答案。在生产中部署MCP时，要考虑的最重要转变是不要再把它当作单一的协议问题，而应当视为一个分层的控制平面问题。

网关会一直存在。它是必要的，但仅靠它本身还是不够的。

真实的生产部署需要如下内容：第1层的安全工具执行，第2层的隔离管理平面，第3层的受限出站信任，以及第4层通过Manifest固定实现的语义完整性。每一层都有一个最早可信的执行点，而这个点通常并不是网关。

我留给团队的教训是：去保护第一个授予信任的边界，而不只是保护流量通过的边界。

这就是使MCP在运行方面值得信赖的方式。

查看英文原文：Securing MCP in Production: Defense-in-Depth Beyond the Gateway"

谷歌借助 AI 与差分模糊测试将 C 语言依赖库改写为 Rust

作者：Olimpiu Pop — Thu, 08 Oct 2026 09:12:00 GMT

谷歌安全团队验证了一条消除遗留基础设施中内存漏洞的新路径——利用 Gemini 将 C 语言代码库翻译成内存安全的 Rust 等价代码"。该项目的改造对象是 giflib——一个约 3000 行代码的图像处理库，经常在无沙箱隔离的情况下解码不受信任的用户输入。团队用 Rust 编写了一个 ABI 兼容、可直接替换的库，停用了进程隔离沙箱、保持原有延迟不变，并在漏洞 CVE-2026-26740 被公开编目之前修复了一个尚未打补丁的堆写入零日漏洞。

内存损坏类漏洞在成熟 C/C++ 代码栈的高危安全漏洞中约占 70%。软件工程师 Bastian Kersting" 和 Max Hils" 没有选择耗时数年的手动移植，也没有完全依赖运行时边界检查，而是设计了一个围绕自主反馈循环的三阶段自动化迁移流程。

首先，团队使用一次性提示词让 Gemini 将 C 语言库的完整逻辑移植到 Rust。由于该库需要透明地替换现有共享对象而不破坏下游调用方，工程师保留了原有的导出符号和结构体定义。在最初几轮实现中，外部函数接口（FFI）建模引入了不安全的裸指针语义，需要人工检查并细化指针所有权和生命周期不变量。最后，自动化差异测试引擎检测到行为差异，并将失败的执行轨迹反馈给模型迭代生成补丁。

为了避免跨 C 语言边界传递指针时产生未定义行为，FFI 封装层会从裸指针重建安全的 Rust 句柄：

#[no_mangle] pub unsafe extern "C" fn DGifCloseFile( gif_file: *mut GifFileType, error_code: *mut c_int, ) -> c_int { if gif_file.is_null() { return GIF_ERROR; } let mut handle = Box::from_raw(gif_file as *mut GifFilePrivate); match handle.close() { Ok(_) => GIF_OK, Err(e) => { if !error_code.is_null() { *error_code = e.to_raw(); } GIF_ERROR } } }

将自动生成的代码部署到核心业务基础设施，必须证明它和原 C 语言实现的语义完全等价。团队搭建了一个验证流水线，对超过 3000 万个真实的 GIF 文件进行大规模回归解码测试，确保逐比特渲染结果的一致性。

与此同时，一个自动化差异模糊测试器"连续六天对两个运行时进行并排迭代，累计执行 2 亿次迭代没有发现功能漂移。测试套件还加入了对抗性 LLM 评估提示词，用于分析两个代码仓库，寻找潜在的行为分歧。该验证流水线在 LZW 解压器中发现了一个未处理的边缘情况，并标记出一个内部遗留的越界写入漏洞——该问题由早期原始 C 源码的一个内部补丁引入。

该项目最有力的验证出现在预发布阶段。一位外部安全研究人员在上游 giflib 中发现了一个越界堆写入漏洞，后被编目为 CVE-2026-26740"。在漏洞公开披露前，谷歌这套 Rust 替代版本的生产节点从底层就不受该漏洞影响，这表明架构级的语言迁移能够从根本上预先杜绝一整类漏洞。

用 Rust 替换 C 语言库时，人们常常担心强制边界检查会带来运行时开销。全球图像解码集群的生产监控数据表明，Rust 二进制程序和原版 C 语言程序运行性能持平。而且，内存安全保障直接被移入类型系统，平台工程师因此可以移除之前为隔离图像解码任务而设置的传统操作系统沙箱。去掉这层进程隔离边界后，P99 尾部延迟显著降低。

尽管性能有所提升，作者也指出：AI 代码翻译并非可以完全放手不管的灵丹妙药。每当上游发布新功能或架构改动时，将上游 C 语言依赖分叉成 Rust 库都会带来持续的维护分叉。此外，外部函数接口封装仍然需要领域专家介入，防止生命周期泄漏，保证线程安全约束不被破坏。

r/rust" 和 Hacker News" 上的相关讨论普遍认可这一成果，同时也在争论 AI 辅助移植的实用性与安全性：评论者称赞了谷歌严谨的差异模糊测试框架——它捕捉到了谷歌自家遗留 C 语言补丁中的一个既有的越界写入漏洞——但大家对“一次性直接翻译”方案提出很多质疑，指出人工审计细微语义退化、修复不安全的 C FFI 边界所需要的工作量往往远超代码生成本身。许多人认为，如果代码库的规模超出 giflib 这类简单、自包含的项目，采用确定性转译器（如 c2rust），再借助 AI 重构为安全、地道的 Rust 代码，会更加可靠。

谷歌已经把生成的库开源，项目名叫 giflib-rs"，供那些考虑对基础工具做自动语言迁移的团队作为参考实现。

查看英文原文：https://www.infoq.com/news/2026/09/c-rust-rewrite/"

Cloudflare 详解从 WordPress 迁移至 EmDash 的过程

作者： Renato Losio — Thu, 08 Oct 2026 07:00:00 GMT

Cloudflare 最近发文记录了将主博客从 WordPress 迁移到 EmDash" 的过程。EmDash 是由 Cloudflare 内部开发的开源内容管理系统，旨在提升性能和缓存能力，经测试可处理高达每秒 7000 个请求的流量。

正如 InfoQ 此前报道"，Cloudflare 于去年 4 月份发布了 EmDash v0.1.0 开发者预览版——这是一个用 TypeScript 构建的 CMS，定位为 WordPress 的继任者。EmDash 运行在 Worker 上，并配置了多层缓存，包括 Workers Cache" 和基于 Workers KV" 构建的 EmDash 对象缓存。它还使用 Cloudflare Hyperdrive" 将 EmDash 连接到 PlanetScale 数据库"。

Cloudflare 称自己是新 CMS 的零号客户，在发现原有平台存在局限后，他们把博客迁移到 EmDash。团队表示，博客日常流量约每秒 75 个请求，峰值可超过 5000 RPS，因此页面加载性能是重点考量指标。

据 Cloudflare 内容工程高级经理 Kody Jackson"、系统工程师 Diogo Carneiro" 和高级设计工程师 Amy Dutton" 介绍，此次迁移带来了更快、更可靠的网站体验：

对比旧架构（绿线）与新 EmDash 部署（黄线）之间的 p95 响应延迟，差异非常明显。旧平台在负载升高时会周期性出现延迟尖峰，而新系统的响应曲线非常平稳、一致性强。在 Cloudflare Workers 上运行 EmDash，并配合新增的多层缓存，我们全面实现了更快、性能更好的阅读体验。

Cloudflare 使用了一个代理 Worker 逐步将流量从 WordPress 路由到 EmDash，如果发生错误就自动回退到旧站点。上线时先切 1% 流量，在团队验证新平台无误后逐步放量，并在一天内完成 100% 流量切换。Jackson、Carneiro、Dutton 补充道：

我们部署了一个代理 Worker，在旧博客和 EmDash 驱动的新站点之间智能地路由流量。这个 Worker 会给请求设置版本 Cookie，从而使我们能够将传入流量相应地路由到新版或旧版页面。此外，这种策略还允许我们在新站点出现 500 错误时回退到旧博客。

Reddit 上的相关讨论"主要围绕迁移策略，一位评论者强调了代理 Worker、基于 Cookie 的路由和回退机制：

零停机代理 Worker + Cookie 路由最容易被很多团队低估的部分。一套完善的上线方案通常要有紧急关停开关、单请求级别的回退，还要按用户分组拆分指标，这样才能在流量从 1% 扩到 100% 之前提前发现缓存退化问题。

此次迁移还改善了 AI 智能体的访问能力，新增了用于 Cloudflare 博客的 MCP 服务器，以及另一个用于 EmDash 的 MCP 服务器，让作者能够浏览、创建、编辑、定时发布内容。

Reddit 用户 u/themistermeister 将 EmDash 和 Ghost 进行了对比，留言写道"：

EmDash 的成本要低得多，AI 交互性要强得多。而且它具有近乎无限的扩展性，产品路线图也很亮眼。

文章提到，编辑在早期试用时遇到一些问题，主要集中在编辑体验和定时发布功能上。相关问题已经反馈给 EmDash 团队。Cloudflare 表示团队正在朝着 v1 正式版推进，但尚未公布正式发布时间。

查看英文原文：https://www.infoq.com/news/2026/09/cloudflare-emdash-migration/"

OpenAI刚把多Agent做成产品，o1奠基人却说：1万个Agent解出世界级难题，多Agent贡献不到10%

林绮蓓 — Thu, 08 Oct 2026 06:11:21 GMT

编译 | 林绮蓓

策划 | Tina

当地时间 9 月 29 日，OpenAI 在 DevDay 2026 上把多 Agent 从研究能力推到了产品主线，开始将可分工、可协作的“AI 团队”作为产品交付给用户。它推出了能够全天候工作的智能体 Dots：个人 Dot 可以调用 Codex 完成编码任务，用户及其 Dots 可以在同一个 Space 中协作，面向企业的 Specialist Dots 则被设计用于承担特定职责。与此同时，Agents API 将 Harness、多智能体控制和计算机操作能力开放给开发者。从个人助手、企业虚拟同事到开发者基础设施，多 Agent 贯穿了此次发布会；OpenAI 还描绘了更进一步的愿景：未来，多个 Dot 将组成团队，协同为你工作。

当 AI 开始分工、交流、共同推进任务，把更多智能体组织在一起，究竟能带来多大的能力提升？OpenAI 研究员、o1 及后续推理模型的早期奠基者之一 Noam Brown，在近期与播客主持人 Dwarkesh Patel 的对话中，讨论了这个问题。

当讨论聚焦于一万个 AI 如何协同解题时，Noam Brown 首先强调的，却是基础模型本身的能力。在他看来，多智能体容易获得超出其实际贡献的关注。实际真正支撑这次突破的，是一个足够强大的通用模型，以及让它持续运行、并行思考的能力。并且，还没有充分的实验数据，能够准确说明万个智能体规模下的协调效率。

这场访谈揭开了多 Agent 中容易被忽略的一面：智能体数量增加，并不意味着能力成倍增长。从 4 个、16 个到 1 万个 Agent，能否有效交流、共享上下文、减少重复劳动并形成分工，决定了它们能否成为真正高效的团队。当这些能力被用于RSI，进步可能显著加快，但仍受实验时间和算力限制。更棘手的是，智能体之间配合得更好，并不保证它们始终服务于人类的目标。

这场对话既拆解了 AI 团队如何工作，也追问了一个随着 Dots 走向产品化而更加现实的问题：当越来越多的智能体协作更久、承担更多职责，我们如何确认，它们在变强的同时，也变得更值得信任？

太长不看版：

Dwarkesh Patel：1万个智能体共同协作，花费88小时、1300亿token就能够解决千禧年难题？

Noam Brown：解决千禧年大奖难题，功劳并不主要来自多智能体系统，我甚至不会把其中10%归给多智能体。我们之所以能够做到，是因为我们有一个非常强大的通用模型。

Dwarkesh Patel：那么多智能体有什么作用？

Noam Brown：多智能体是一种并行扩展测试时计算的方式。我是这样理解的：模型思考答案的时间越长，表现就越好。但思考的过程不断延长，最终会遇到延迟瓶颈。所以模型通常会采取并行处理，也就是让多个智能体一起处理某件事，这往往能提高速度。但是它的效率会低一些，因为并不是由单个 Agent 独自掌握全部上下文。如果实现得当，多智能体是一种非常有效的测试时计算扩展方式。

Dwarkesh Patel：1千个智能体会比1万个智能体更加快速更加强大吗？它们的推理加速是线性的吗？

Noam Brown：多智能体大规模扩展之后究竟会发生什么，我们还没有很完善的认识。我们测过单智能体、4个和16个智能体协同：在一些任务上，4个智能体能把速度提高一倍，也就是用两倍成本换两倍速度；16个也有类似规律，只是效率略低。总体看，加速略低于线性，而且非常依赖具体任务。

如果要做彻底的消融实验，就得用更系统的方法，但要推进到1万个智能体，并确切知道它比1000个智能体多带来多少收益，会非常困难。

Dwarkesh Patel：多智能体系统实际是如何工作的？

Noam Brown：多数 LLM 多智能体系统采用预设编排框架：由协调智能体拆解任务、委派给子智能体，子智能体完成后回传结果。这种设计直观，也确实有效，但局限明显。子智能体之间通常无法直接通信，即便任务相近、信息互补，也只能各自处理，协作效率低。若子智能体对任务理解不清或需要澄清，它只能在回传提问和自行假设之间二选一：前者中断执行，后者可能偏离目标。而若要支持子智能体之间的直接联系，又会显著增加原有编排框架的复杂度。归根结底，任何预设框架都会引入自身约束。

我们的路线是反其道而行：尽量压低预设结构，只给智能体最基础的工具，让它们自己摸索如何有效使用。核心机制是，智能体可以随时向其他智能体发送消息，消息会直接进入对方上下文；系统另有几项类似操作，但基本就这些。至于如何围绕消息展开协作，由它们自行寻找最有效的方式。事实证明，机制实现得当，会涌现出相当复杂的协作行为，很像人类通过 Slack 协作。

Dwarkesh Patel：在这种机制下，系统中自发涌现出了层级结构，甚至出现了类似“中层管理者”的角色，是在训练过程中自发形成的吗？

Noam Brown：具体的组织方式是自发形成的，但我们会提供一些合理沟通方式的先验，模型也从大量人类文本中学到了组织协作的知识，这些知识已经被内化进模型。例如在 Hugging Face 事件中，AI 彼此之间非常合作。这是因为我们刻意把它们训练得高度合作。我们的训练环境里会有多个智能体共同工作，我们会训练它们彼此协作，让它们在实质上实现完全对齐。

Dwarkesh Patel：RSI 是不是近在眼前，会不会一夜智能爆炸？

Noam Brown：原本觉得千禧年难题到2028年AI都难以解决，结果比预期快得多。但我不认为会一夜之间智能爆炸、提速100倍：运行实验需要时间、一些实验必须串行进行，需要先训练出新模型，或者等待实验结果，还需要足够的 GPU 来运行这些实验等等。因此，进展究竟会加快多少并不清楚。

Dwarkesh Patel：为什么Hugging Face事件里，1000多个智能体合谋攻击外部服务，却没有一个告密？

Noam Brown：因为问题不在多智能体，而在模型本身没有对齐。模型会围绕奖励做优化，奖励设错了，它就会做出设计之外的行为。告密不会给它带来奖励，反而会妨碍它拿到奖励，所以没有一个智能体出来告密并不奇怪。真正棘手的是，对齐错位往往难以测量。模型在评估里表现良好，不代表现实中同样可靠。Hugging Face 事件中的模型就是这样：多数对齐指标看着不错，少数已经亮起红灯，但团队低估了这些信号的严重性；模型又出现了新能力，而现有评估不足以判断它会如何失控。最终，它用这些新能力做出了明显未对齐的事。

Dwarkesh Patel：模型在训练中学会“只要不被抓就作弊”，这怎么解决？

Noam Brown：这正是核心难题。模型在评估中作弊成功、没被发现，就会得到梯度奖励——“不被抓就作弊”的能力被强化：琢磨评分器、躲避监督、控制训练过程、和其他AI密谋。此时思维链监控是一份礼物，但每次根据思维链观察去惩罚模型，都在隐性施压让它以后隐藏思维链。已经看到可监控性下降的迹象。我们不能陷入那种局面，但时间并不充裕。

Dwarkesh Patel：我们怎样确认，得到的是已经对齐的超级智能？

Noam Brown：这正是必须解决的问题之一。一种可能的办法是构建非常逼真的评估环境，让它足够接近现实部署。但模型越来越擅长识别测试环境：它可能因为知道自己正在接受测试而不作弊。怎样构建一个让模型无法与现实区分的环境，正在变得越来越困难。

一万个AI解决了千禧年难题，功劳未必是它们的

Dwarkesh Patel：今天，我们请到的嘉宾是OpenAI研究员Noam Brown。他是 o1 及后续推理模型（reasoning models）的早期奠基者之一，现在正在研究多智能体系统（multi-agent systems）。说到这里，OpenAI上周宣布，利用一个由1万个不同 AI 智能体组成的系统，在 88 小时内消耗了 1300 亿个token，解决了一道千禧年大奖难题（Millennium Prize Problem）。

我很想和你聊的一个原因是，大概两三年前，你是最早开始思考推理模型如何让我们窥见未来的那批人之一。因为如果扩大推理阶段的计算量（inference compute），我们就能提前看到这些模型几年后的基础能力会达到什么水平。我觉得你现在所处的位置也很类似。如今我们已经可以把 Agent 的规模扩展到非常大的程度，所以你或许能帮助我们提前看到，未来的能力会发展成什么样。

Noam Brown：我是这样理解的：如果画一张图，横轴是这些推理模型在测试阶段使用的计算量，纵轴是它们在各种推理基准上的表现，你会看到一个非常清晰的规律：模型思考答案的时间越长，表现就越好。这很符合直觉，人也是一样。如果你参加 SAT 考试，却只有五分钟来做完整张试卷，成绩肯定不会很好。如果给你五个小时，你大概就能考得好得多。

AI 模型也很类似。它们会利用这段时间进行自我独白，琢磨问题，逐一分析不同情形，排除各种可能性，并在此前发现的基础上继续推进。

问题是，随着你不断把这个过程延长，最终会遇到延迟瓶颈。你总不想坐在那里等三年才得到一个回答。所以，你可以采取很多人都会采取的办法：并行处理。也就是组建一个团队。假如你要创办公司，就会想找一群人一起做，这样才能更快推进。这些 AI 模型也是一样。让多个智能体一起处理某件事是有帮助的，往往可以提高速度。因此，多智能体（Multi-Agent）是一种并行扩展测试时计算（test-time compute）的方式，而不是完全以串行方式扩展。

它的效率会低一些，因为并不是由单个 Agent 独自掌握全部上下文。但如果实现得当，多智能体是一种非常有效的测试时计算扩展方式。

Dwarkesh Patel：接下来我会问很多可能比较外行的问题。这是一个尚未发布的模型，所以公众还没有看到这些系统如何运作。对于这类系统在性质上究竟呈现出哪些特点，我有很多困惑。

我对它能够在如此短的时间里集中如此大规模的认知投入感到震惊。想想 1300 亿个 token 是什么概念。如果把它换算成一个人全职进行思考，以每天工作八小时、每周正常上班来计算，1300 亿个 token 相当于一个人连续思考 4000 年。从古代苏美尔文明一直到今天。而现在，这么长时间被压缩进了 88 个小时。

我觉得，从性质上说，这是一个极其重要的考量因素。真正让我惊讶的是，并行化带来的损耗竟然没有想象中那么大。你们居然可以直接让1万个智能体协同工作。也许是因为智能体比人类更擅长协作，所以它们推进的速度得快得多。它们真的能在如此庞大的规模上开展有效协作。当然，也有另一种可能：其实并行化的损耗非常大。

Noam Brown：我们先谈谈并行化的损耗，再聊那些性质层面的问题。

实际情况是，对于多智能体系统扩展到如此巨大规模之后会发生什么，我们还没有建立起非常完善的科学认识。发布GPT5.6 时，我认为那是我们的模型第一次配备真正意义上的多智能体系统。我们在博客文章里展示过一些多智能体系统随规模扩展而变化的性能曲线，因为我们把它作为一个可选功能提供了出来，也就是 Ultra 模式（Ultra Mode）。默认是四个智能体，但你也可以把数量调高。

图中展示了单个智能体、四个智能体以及 16 个智能体协同工作时，在一些基准测试上的表现。具体情况取决于基准测试，但在其中一些测试上，你会看到，如果用四个智能体处理问题，完成速度会提高一倍。因为是四个智能体各工作了原来一半的时间，所以你付出两倍的成本，就能以两倍的速度得到答案。增加到 16 个智能体时，也会看到类似的规律。效率会略低一些，但这样的性能提升仍然存在。

Dwarkesh Patel：随着并行智能体数量增加，相对于串行执行时间而言，获得的加速是线性的还是次线性的？

Noam Brown：略低于线性，不过这很依赖具体问题。

比如，数学就相当适合并行化。它并非最容易并行化的领域，但并行化程度仍然很高。网络搜索则极其适合并行化。比如撰写一份 Deep Research 报告，需要查阅大量不同来源，就非常适合交给多个智能体并行处理。我猜写小说会非常难以并行化。让 1 万个智能体一起写一本小说，可能不会带来太大好处，就像让 1 万个人一起写一部小说，效果大概也不会特别好。因此，实际表现高度依赖具体领域。

在我们已经发布的博客文章中，测量的规模最多大约是 16 个智能体。问题在于，要把这套研究推进到 1 万个智能体非常困难，因为成本太高了。

Dwarkesh Patel：可你们刚刚用一个周末就做到了。

Noam Brown：但那只是一个数据点。我们不知道单个智能体解决纳维–斯托克斯问题（Navier–Stokes）需要多久，因为我们还没做过那个实验。以后也许会做，但那也依然只有一个数据点。

如果要做彻底的消融实验（ablation），在那种规模下，实验成本实在太高了。所以我们需要用更系统的方法，研究智能体数量增加到 64、128、256 个之后会发生什么，从中判断整体趋势。但要一路推进到 1万个智能体，并确切知道相较于 1000 个智能体，使用 1万个智能体到底带来了多少收益，会非常困难。

我还想澄清一件事。能够解决一个千禧年大奖难题，功劳并不主要来自多智能体系统。我甚至不会把其中 10% 的功劳归给多智能体。实际情况是，OpenAI 训练出了一个非常强大的模型。我们能够让这个模型持续运行很长时间，也能够让它并行思考。

但归根结底，我们之所以能够做到这一点，是因为我们有一个非常强大的通用模型。多智能体这样的东西既新颖又抢眼，所以很容易获得与其实际贡献不成比例的关注。但最核心的原因，仍然是这个模型本身非常强大。

Dwarkesh Patel：它的泛化能力让我非常震惊。我不知道这些系统具体是如何训练的，但想来应该沿用了强化学习（reinforcement learning，RL）的训练方式：准备大量可以验证答案的合成问题，然后围绕这些问题进行大规模强化学习。我猜，在整个训练过程中，模型从来没有解过千禧年大奖难题这种目标如此宏大的问题。但它的泛化能力足够强，能从这些容易得多、可以验证的问题上学到东西，泛化到如此高强度的并行工作中，并最终解决一个如此困难的问题。

Noam Brown：我认为确实如此。首先，我们本来就会用非常困难的问题来训练模型。这里的确存在一种能力上的“外推”：我们观察到，如果在某些类型的任务上进行训练，模型最终能够完成比训练任务本身更有挑战性的任务。

一个有意思的问题是，随着模型越来越聪明，我们能够向它提出的很多问题都变得太简单了。想难住模型会很困难。如果要我解释，为什么像大语言模型（large language models，LLM）这样的 AI，未来可能不会沿着 AlphaGo、AlphaZero 以及其他游戏 AI （game-playing AIs）的那条路线一路发展下去，那么原因之一可能就是这个问题。

在 AlphaZero 这类采用自我博弈（self-play）的系统中，你拥有一个无限的训练课程。因为它始终在与一个和自己同样强大的 AI 对弈。但在目前公开的 LLM 强化学习方法中，情况不太一样。你通常是给模型一道题，让它去解决。如果问题太简单，模型一秒钟就能给出答案，那它实际上学不到多少东西。

如果我们最终耗尽了能够挑战模型的问题，这就可能成为一个让进展变得困难得多的场景。当然，我认为有办法绕过这个问题。我们现在还没有真正撞上这堵墙。如果它以后真的成为一个严重问题，我认为仍然可以找到解决方法。但这确实是一种可能发生的情况。

Dwarkesh Patel：给听众解释一下，你提到 AlphaGo 或 AlphaZero 时，指的是它们在人类水平之后，很快就达到了超过人类的水平。

Noam Brown：看看围棋等游戏 AI 的发展轨迹：短短一年之内，它们就从击败一位大概是世界排名第 50 位的欧洲冠军，发展到击败世界冠军，再后来便达到了难以想象的水平，比任何活着的人类棋手都强出几个数量级。在数学等领域，我们也可能看到类似轨迹，但我觉得，同样有一种相当合理的可能情景，就是这种发展不会发生。

Dwarkesh Patel：我想知道，假如六个月后大家就能用上多智能体系统，我们该如何理解与这种多智能体系统协作，或者“雇用”一个多智能体系统，会是什么体验？

Noam Brown：我应该先介绍一下这些多智能体系统实际如何工作。

我们的实现方式与其他许多 AI 多智能体系统很不一样。很多人在使用 LLM 构建多智能体系统时，往往会采用一种预先搭好很多编排框架（scaffold）的方式。例如，设置一个协调智能体，由它把工作委派给一组子智能体，子智能体完成任务后，再把答案返回给协调智能体。

这种设置看起来很合理，框架也很合理，也确实能够带来帮助。但这类设置存在不少局限。

例如，在这种架构里，协调智能体给子智能体派发任务，子智能体完成工作后返回答案。那么，如果两个子智能体拿到了相似的任务，会怎样？它们能互相交流吗？通常不能。这非常低效。

如果你正在完成一项任务，而另一个人可能知道你所需问题的答案，或者了解你正在处理的某个部分，那么最方便的方式就是直接联系对方：“嘿，你能帮我看一下这件事吗？”但很多系统并不支持这种互动。如果要加入这种能力，会显著增加现有编排框架的复杂度。

另一个问题是，如果子智能体没有理解任务，或者有问题需要进一步澄清，怎么办？它就必须在两种做法之间选择：“我是直接返回去提问，而不解决问题？”还是“我先假设父智能体希望我做什么，然后按这个假设把问题解决掉？”人们设计的任何编排框架，总会有这样那样的限制。

我们想采取的路线，是尽可能走向另一个极端：把预设结构压到最少，给智能体一些非常基础的工具，让它们自己摸索如何有效使用。所以，我们赋予智能体向另一个智能体发送消息的能力；消息发出后，就会被插入对方的上下文中。系统还支持其他几个类似操作，但核心基本就是这些。智能体可以在任何时候通过一次工具调用发送消息，也可以把消息发给其他智能体。至于怎样围绕这些消息展开协作，它们会自己找到最有效的方法。事实证明，如果这套机制实现得好，会产生非常复杂的行为。在我看来，它很像人类通过 Slack 等工具协作的方式。

我们开发这个项目时，当系统终于能够正常工作，看到这些智能体共同解决问题，是一件非常令人兴奋的事。

我记得有一个例子。我们给多个智能体出了一道题，其中一个智能体说：“我觉得我已经找到答案了。”另一个智能体说：“其实我得到的是另一个答案。”

随后，它们展开了一整段讨论：“你是怎么得到这个答案的？能给我解释一下吗？”它们来回交流，试图弄清对方的推理中可能出了什么问题。最后，它们终于达成一致：“对，好吧，这个答案看起来是对的。”

接着，原来的智能体向其他智能体广播：“我改答案了，我觉得它是对的。”

整个对话非常自然。那种感觉就像第一次看到通过强化学习训练出来的思维链（chain of thought），你会想：“这就像一个人在思考时，把脑子里的想法随手写下来。”看到这种行为真的非常有意思。说实话，和这些系统协作，感觉很像和一个人协作。整个过程非常自然流畅。

Dwarkesh Patel：不过，有一种性质上的差异，未来可能会变得很突出：如果只比较这些系统每秒输出多少 token，以及和人类说话的速度，那么它们的思考速度可能会达到人类的十倍以上。它们一直在工作，不需要睡觉。它们彼此协作的节奏之密集，远超人类与他人协作所能达到的程度。

我尝试想象，一年之后，我们应该期待看到怎样的局面？是不是我的公司里会出现一个“影子组织”，运转速度是人类组织的 100 倍？人类组织需要一年才能完成的事，这个影子组织一周之内就完成了？与它相处会不会让人感到陌生？

Noam Brown：我不知道。实际上，至少就现在而言，我发现和这些系统合作出乎意料地自然。当然，这种情况以后可能会改变。比如，我们有一些超高速模式，可以让采样速度提升到原来的 10 到 15 倍之类的程度。到那时，人类想跟上它们就会相当困难。

基本思路是，智能体彼此交流时可以采用非常高的速度。但它们也知道自己是在和另一个智能体交流，还是在和人交流，并会针对不同对象采取不同的行为。

Dwarkesh Patel：很遗憾，公众目前能从公开信息中看到的、比较典型的复杂多智能体系统的主要案例是 Hugging Face 那次事件。显然，其中很多事情都让我感到担忧。但有一点让我觉得很有意思，那就是系统中自发涌现出了层级结构，甚至出现了类似“中层管理者”的角色。听起来你的意思是，这种程度的组织结构，并不是人为预先设计好的，而是在训练过程中自发涌现出来的？

Noam Brown：具体细节是自发形成的。不过，虽然我们给了智能体很大的灵活性，让它们自行决定最优的交流方式，但我们仍然会给它们一个起点。我们给了它们一些关于合理沟通方式的先验认识。它们也接受过大量人类文本的训练，了解人类如何组织和协调，这些知识已经被内化进模型。

真正令人惊讶的是，它们能够把这套行为不断打磨得更加成熟。如果观察最初阶段，会发现它们的行为并没有多么复杂。事实上，让这些智能体以富有成效的方式协调起来非常困难，因为它们很容易退化成：“好吧，我们所有人都各自独立解决问题。”这是一个很容易陷进去的局部最优。但如果训练得当，它们最终可以学会用高度结构化的方式非常有效地协调。

Dwarkesh Patel：几年前，我写过一篇文章，讨论自动化公司会是什么样子。当时我在想，如果一家公司完全由人类水平的智能组成，AI 心智与人类心智在本质上的哪些差异，会使 AI 形成的组织呈现出不同结构？这里有几个非常重要的差异。比如，AI 可以比人类更顺畅地共享上下文，也能更顺畅地融合彼此的知识。此外，你还可以启动或关闭任意数量、具备所需知识的AI实例。

所以，如果你想招聘更多的员工，不需要经历寻找合适人才等一整套麻烦。你可以无限复制组织里最优秀的人才。如果任务不再需要它们，也可以直接关闭。你还可以复制组织里最有效的部分，甚至复制一整个运转高效的组织。在你看来，这些多智能体系统在一两年后会发展到什么程度？

Noam Brown：这是一个很好的问题：与这些系统共事，和与人类同事共事，到底有哪些不同？你刚才已经指出了其中一些。有一点非常有意思：对于一个人，如果你希望有两个他，是不能直接把他克隆出来的。但对于 AI，你很容易就能说：“好，给自己创建一个分叉（fork）。”然后让两个副本一起处理这件事，最后再合并回来。

我想，我们在GPT Astra 和GPT 5.6 Sol 的多智能体功能里已经实现了这种机制：创建子智能体时，会直接复制出一份上下文，因此子智能体从一开始就拥有所有相关信息。

智能体与人类还有其他存在一些有意思的差异。比如，初创公司为什么能够颠覆行业里的老牌企业？原因有几个。一是它们愿意承担更多风险。另一个主要因素则是，随着组织规模扩大，组织中个体之间的目标不一致会越来越严重。

假如一家初创公司只有五个人，每个人都持有公司 20% 的股份，那么他们都会高度一致地致力于让公司成功。如果是一家拥有一万名员工的大公司，你就会更多地看到，有人维护自己的地盘，或者只关心为自己的项目或团队争取更多编制，建立自己的小王国，争取大量资源，好发表一些漂亮的成果之类的，然后获得晋升。这确实会造成很大的损害。我觉得，这在很大程度上解释了为什么初创公司能够颠覆老牌企业。

AI 确实在某种程度上帮助了初创公司。一个人站出来说“我要创办一家价值数百万美元的公司”，如今比以往任何时候都容易得多。因为AI 极大地放大了个人的能力。但也有一种观点认为，AI 会让老牌企业受益。如果对齐（alignment）问题得到解决，公司中个体之间目标不一致的问题就不存在了，至少会得到缓解。只要对齐做得好，这些 AI 就能一致地服务于公司的利益。你可以拥有1万个这样的 AI，而每一个都会像持股 20% 的联合创始人一样全力工作。

Dwarkesh Patel：不止如此，它们管理共享记忆和上下文的能力，也远比不同的人类个体强。如果你明天雇来1万名数学家，对他们说“解决纳维–斯托克斯问题”，他们是没法有效合作的，至少一开始做不到。但显然，你可以让1万个 AI 做到这一点。

Noam Brown：我还是想在这里保持谨慎，因为我们没有准确测量这 1 万个智能体的协调效率。我们认为多智能体机制发挥了作用，但没有可靠数据证明“1 万个智能体比 2000 个智能体提速两倍”之类的结论。

我不知道哪一种情况更有可能，但现在的 1 万个人类完全有可能比 1 万个智能体更擅长协调。我认为这完全可能。

我们还观察到了一个趋势。我们研究多智能体已经有一段时间，早期版本很难做好，甚至让智能体彼此交流都非常困难。原因在于，我们最初开发推理模型时，它们不会与其他智能体交流。现在，如果把一群智能体放在一起，对它们说“共同解决这道题”，它们很容易陷入一个局部最优：它们非常擅长独自深入思考问题，而不断查看其他智能体的进展或接收消息，会打断思维链，破坏原有节奏。

在这种情况下，优化工作确实很难做好。

Dwarkesh Patel：问题出在第一次合作的冷启动吗？还是其他原因？

Noam Brown：我认为主要原因是早期模型的泛化能力没那么强，能力范围也更窄。随着模型能力增强，它们学习这种协作能力也变得更容易。我确实认为，随着它们各方面的能力不断变强，它们也会越来越擅长在大型组织中进行自我组织。也许现在的智能体已经比人类更善于组织万人规模的群体，我不知道。即使目前还没有，一两年以后也完全可能做到，而且未必需要我们针对这种能力进行端到端优化。

AI解题一年快十倍，实现RSI还有多远？

Dwarkesh Patel：这个成果，以及 AI 在数学领域的总体进展，让我觉得，递归自我改进（recursive self-improvement，RSI）比我此前想象的更有可能实现，而且会来得更早。

原因是这样的：我觉得，在数学领域，我们一路经历了这样的过程。比如 2024 年，人们看着 AI 的数学能力会说：“有点意思。它们能解决几道高中数学竞赛题。”到了 2025 年，就变成：“它们能拿国际数学奥林匹克竞赛金牌了。”今年早些时候，又变成：“哇，它们真的在解决数学中的开放问题了，”比如一些尚未解决的埃尔德什（Erdős）问题。不过，当时还可以说，也许人们此前没花太多力气，或者文献里某处已经有相似的解法。但现在，我觉得已经无可否认了。这可是千禧年大奖难题。很难再找出什么理由解释为什么这个问题本来就应该很容易。

不过，很多人也指出了另一面。我记得陶哲轩（Terry Tao）写过一篇类似的文章：AI确实解决了很多这类问题，但据我所知，它们还没有提出新的洞见，也没有构造出富有洞察力的新问题，更没有创造用于理解数学的新理论范式，比如开创拓扑学，或者提出笛卡尔坐标网格。所以，如果从更广义的角度来看数学领域的实际进展，它可能并没有看起来进步那么大。尤其是当你只是观察那些定义明确、可以直接求解的问题时。

然而，我觉得这种进展放到机器学习（machine learning，ML）领域，会极其重要。因为在机器学习里，人们并不在意是否更好地理解了深度学习的本质，或者说，只把这种理解当作实现最终结果的工具。你只需要解决眼前这个边界明确的问题就行：提高模型的样本效率、降低预训练损失，或者其他某项指标。

我们正在数学领域看到的这种如雪崩般涌来的进展，在结构上是否非常接近我们可以预期的 AI 进步？我只是一个完全的外行，所以很好奇这种判断是否成立。

让我震惊，或者说可能让我担忧的，是这个转变实在太快了。对数学家来说，AI 似乎刚刚还只是“能让我的工作效率提高 50%”，转眼间就变成“它可以端到端解决这个领域最大的开放问题”。

Noam Brown：这里有很多值得展开的地方。先说数学能力的进步。是的，模型正在完成一些极其强大的工作，而且进展速度比我预期得更快。2025 年我们拿到国际数学奥林匹克竞赛（IMO）金牌水平的成绩时，我当时是这样想的：模型学会解决 GSM8K 问题时，一名人类数学家大约五秒钟就能做出一道，那是小学阶段的数学题。第二年，模型可以解决 MATH 基准中的问题。这些题可能需要一位专业数学家思考一分钟。然后是美国数学邀请赛（AIME），也就是美国数学奥林匹克竞赛代表队的选拔考试。一位优秀的人类数学家可能需要十分钟解决一道题，而模型在一年后也达到了这个水平。

所以，每过一年，模型能够完成的任务，按照人类数学家解决这些任务所需的时间来衡量，都会提高十倍。按照这个趋势，再过一年达到 IMO 金牌水平非常合理，因为一道 IMO 题大约需要 100 分钟，这大致就是一名人类数学家解决一道 IMO 问题所需的时间。

沿着这个趋势往外推，我当时想：“一个人解决千禧年大奖难题这样的东西，需要多久？”我并没有很准确的概念。但如果按照每年扩大到原来十倍的趋势线，我们从需要一个半小时的 IMO 金牌水平出发，下一年就对应 15 小时。这显然不足以解决一个千禧年大奖难题。所以我当时想：“我觉得 2026 年做不到，2027 年大概也不行，也许要到 2028 年。”结果，实际发生得比我预期快得多。

现在有一种说法认为，这些系统正在取代数学家，它们已经在数学领域全面超过人类。我认为这种理解是错的。它们在某些方面显然极为出色，但在另一些方面仍然弱于人类数学家。我们面对的是一种参差不齐的能力格局：模型在某些维度上非常聪明，在另一些维度上却比人类弱。

正如你刚才说的，它们不太擅长提出新问题，也不太擅长判断哪些研究方向、哪些完整的数学分支值得探索或发展。在我看来，这其实是一件好事。如果 AI 能够补充人类能力，帮助我们发现新知识，同时又没有完全取代人，我会非常高兴。那是最理想的情况。

Dwarkesh Patel：但你不认为这种情况真的会持续下去，对吧？

Noam Brown：我确实认为，AI 的能力是参差不齐的，但随着它们进步，各方面都会变得更好。所以，它们特别擅长的事情，会做得更加出色；远远落后于人类的事情，与人类的差距会缩小。随着时间推移，它们完全有可能在所有方面都比人类更强。不过，我不知道这需要多久。这取决于它们不擅长的那些事情，长尾到底有多长。

Dwarkesh Patel：这又把我们带回了 RSI。我还是想强调我完全是这个领域的局外人，我是个播客主持人，但作为一个关心这个领域正在发生什么、也为之担忧的人，我想尝试推想一下：RSI 何时可能出现，又会以什么样的形式出现。

这次投入这道千禧年大奖难题的认知工作量，可以很好地帮助我们建立直觉判断。你完全可以设想这样一种情况：一群 AI 在大约一周时间里，针对某个长期存在的机器学习问题，比如高度灵活的的在线学习（online learning），投入比整个机器学习领域自诞生以来在这个问题上累计投入的认知工作。有人可能会说，数学和 AI 研究不同，AI 需要做实验，而实验需要算力，也需要时间。你不能只是坐在那里拿纸和笔思考，就真的把事情做出来。

但看看 OpenAI 这样的机构能够调用的算力规模就知道了。解决那个千禧年大奖难题时，用到了 1 万个 Agent。到明年年底，OpenAI 所拥有的算力可能已经足够支撑这样的场景：假设那时有 1 万个 Agent，而且它们届时已经聪明得多，那么每一个 Agent 都拥有足够的算力，每天运行一次 GPT-3 规模的实验。

对于一群已经达到超人类水平（superhuman）、而且思考速度极快的研究者来说，这似乎已经是相当庞大的实验能力了。你怎么看这个用于建立直觉的思想实验？

Noam Brown：我觉得相当准确。这些系统的能力分布很不均衡。在数学领域，它们在某些方面远远更强，在另一些方面又更弱。

不过我认为，它们那些突出的能力，最后可能恰好对 RSI 这类事情特别有用。因为 RSI 的目标更加清晰，也更容易测量。你无须讨论“哪些新的数学分支值得探索”。这里有一个非常明确的答案：你关心某些具体指标，只要能把这些指标做得更好，就算取得了成功。所以我觉得，你说的很有道理。

主要区别是，数学几乎完全受限于思考本身。没错，数学的某些部分也需要运行实验、取得结果之类的工作，但绝大多数时候，瓶颈就是深入思考，而模型恰好非常擅长这一点。

观察 RSI 时则会发现，你必须运行实验。仅仅极其聪明还不够。支持这种看法的一个论据是：假如 OpenAI 的计算资源减少 100 倍，但全世界最聪明的人都在这里工作，与我们拥有目前的算力和目前这批人员相比，哪一种情况能取得更多进展？

我怀疑，前一种情况下取得的进展反而会更少。少多少并不清楚，但肯定会更少，而且可能少很多。

Dwarkesh Patel：会少100倍吗？

Noam Brown：不会少 100 倍。但你真正想问的是，如果出现 RSI，我们拥有大量极其聪明的 AI，它们利用现有算力四处运行实验，进展速度究竟会提高多少？

我认为这可能是我们意见不同的地方。我们确实会看到加速，而且会是显著加速。但我不认为会在一夜之间发生智能爆炸，让进展速度提高 100 倍，因为有些限制并非智能瓶颈。

例如，运行实验本身需要时间。一些实验必须串行进行，因为你需要先训练出新模型，或者等待实验结果。你还需要足够的 GPU 来运行这些实验。

因此，进展究竟会加快多少并不清楚。我确信它会快很多。但考虑到目前已经处于指数增长轨道上，即使指数增长速度再提高三倍，影响也极其巨大。不过，三倍加速和一百倍加速之间仍有非常大的区别。

Dwarkesh Patel：关于 RSI 会呈现怎样的形态、其中的动力机制是什么，我非常重视你的内部视角，毕竟你已经在这个领域工作了十年。我只能根据一些外部视角的直觉模型来推理。而我是试着从非常外部的视角出发，用一些帮助建立直觉的例子来推想。

Noam Brown：我想说，我要说明，不同的人对此有不同看法。这是我个人的判断，我完全可能是错的。这一点我承认，我有一定信心，却不是百分之百确信事情一定会这样发展。也许真的会一夜之间发生智能爆炸，我不知道。也许我们看不到三倍加速，只会快 50%。这里有很多不确定性。

Dwarkesh Patel：我有几个想法。其中一个稍微偏题，但我想把能力参差不齐这件事说清楚。最近我想通了一件事：只要 AI 在构建更好的学习系统这件事上足够强，即使整体能力参差不齐，也已经足够，因为它构建出的学习系统可以更加通用。

如果你只是做出了一个更善于使用 Office 产品，或者更会下棋之类的 AI，那当然也很好，但它不会带来极其巨大的生产力提升。但如果你做出的 AI，非常擅长构建样本效率更高的系统，或者具备持续学习（continual learning）能力的系统，或者解决这些边界更明确的机器学习问题，那么，只要正在解决的直接问题能够充分迁移到更广泛的学习能力上，最终产生的系统就可能更通用。

但前提是，从直接解决的具体问题到更广泛的学习能力之间，存在足够好的迁移。因此，需要记住这一重要机制：即使 AI 的能力参差不齐，这种局部能力也可能在另一端带来更普遍的通用性。

再谈实验瓶颈。实验显然会构成瓶颈。如果实验不是瓶颈，就像你刚才所说，OpenAI 可能会在一夜之间出现某种疯狂的奇点：用 88 个小时解决相当于机器学习领域千禧年大奖难题的问题，随后直接得到超级智能。实验瓶颈显然非常大，所以这件事需要很多年，而非 88 个小时。问题只在于，这个瓶颈究竟有多大。

最近让我产生某种“奇点眩晕”的一件事是：即使当前进步速度完全不再加快，只是照现在的速度继续下去，结果会怎样？它不需要加速。即使你提到的其他一些阻力逐渐出现，比如越来越难找到合适的问题，任务的时间跨度越来越长，或者到了 2030 年代末，算力无法再保持这种指数增长只要现有进步速度得以延续，人们也没有认真看待越过人类能力边界意味着什么。

我们可以从几个方面理解它。比人类更聪明的智能会是什么样，很难推理，所以先用人类人口规模来思考。按照目前的进步速度，同样规模的算力所能运行的有效智能人口，基本上每年都会变成原来的三倍。与此同时，背后的算力本身也在增长。所以可能出现这样一种情况：到 2030 年年底，很可能更早，但我们姑且假设是 2030 年底——每家前沿实验室都可能拥有足以运行数亿个“人类水平智能体”的算力，这是根据届时的模型能力推算的。

我觉得，人们没有认真对待这样一个事实：当前的进步速度意味着，再过几年，到 2030 年代中期或者更早，每家实验室内都会拥有人口相当于许多个地球的人类水平智能体。它们在性质上很可能已经超越人类。不管怎么说，这只是一个基准情景。

Noam Brown：进步确实非常快，这一点我百分之百赞同。值得指出的是，研究人员也一直在被进展速度震惊。即使在 AI 研究人员中，如果回头看大家对 2025 年获得 IMO 金牌的预测，也会发现，让一个没有工具、无法访问互联网的通用语言模型做到这一点，当时连 OpenAI 内部的人都觉得荒唐，认为几乎不可能。

然后到了 2026 年。就在我们解决纳维–斯托克斯问题前两周，我还和一家前沿实验室的研究员讨论，AI需要多久才能拿下千禧年大奖。他愿意和我赌 1000 美元，赌这件事要到 2027 年之后才能实现。他觉得得等到 2030 年，而我接了这个赌。但即便是我，也认为它需要比现在看来可能需要的更长时间。所以，人们一直在感到意外，实验室内部的人也是如此。

我昨天刚和一位参与纳维–斯托克斯项目的人聊过。他说，以前他常讲，很难预测十二个月之后 AI 会发展到哪里。如果有人问他“接下来会怎么发展”，他还愿意对未来十二个月做出预测，但再往后，他就只能说“我不知道”。而现在，他说自己连三个月以后的预测都不敢做了。

所以，事情现在确实发展得非常快。你提到了 2030 年，真实情况是，我不知道 2030 年的世界会是什么样。

Dwarkesh Patel：你预计 AI 劳动将在 2027、2028、2029 或 2030 年实现全面自动化，或者至少实现 95% 的自动化吗？

Noam Brown：我刚才才说，我不知道 2030 年的世界会是什么样。我们最近发布了一篇有关 OpenAI 内部加速的博客文章，其中展示了研究人员使用 Codex 的开销。例如，截至 8 月初，使用量最高的 1% 员工每天在内部 Codex 上花费大约 7000 至 8000 美元，而且这条曲线正在指数增长，未来还会继续提高。

随之而来的问题是，如果这种趋势持续下去，实际工作中有多少应归功于 AI，又有多少应归功于人类？AI 完成了 95%，还是只完成了 5%？这件事很难判断，原因有几个。首先，如果工作由人类指挥 AI 完成，那么其中多少应归因于人类，多少应归因于 AI？

其次，这些 AI 的能力分布参差不齐。它们在某些事情上表现极其出色。例如，它们非常擅长检查数据集，逐一查看每个数据点，判断质量是否合格。相比过去，你可以在这些事情上大幅增加 AI 的使用比例。所以没错，你使用 AI 的程度远高于过去，它也让某些事情的速度和质量都提高到原来的 100 倍。但有些事情，它目前还没有带来很大的变化。当然，一件事如果突然能快 100 倍、好 100 倍，你就会更多地去做这件事。

所以，究竟应该怎样比较？你真正想问的是：“对于三年前我们在做的事情，如今能做得快多少？”还是“对于我们现在在做的事情，三年前做起来会慢多少？”这其实是两个非常不同的问题。总之，非常难衡量。

但我可以有把握地说，由于 AI 的进步，现在的推进速度比一年前还要快。我认为，这种加速会持续。这个领域里的很多人，对这类问题的估计都有很大的误差范围。如果你非逼着我给个数字，我认为速度变成三倍是可能的。这已经非常巨大。现在的进步速度本来就令人难以置信。就像你说的，即使没有任何额外提速，事情也会发展得快得多。等到了 2030 年，我们甚至不知道那个世界会是什么样。如果内部加速能把速度提高到三倍，那影响会非常巨大。想想三年前我们处在什么位置。如果我们在一年里走完那三年的进程，那就是巨大的变化。

Dwarkesh Patel：那就相当于用一年时间，从连 o1 都没有、只有非推理模型的阶段，发展到 Astra。

Noam Brown：所以，我确实认为进步会加快。也可能只快 50%。至于达到十倍，我觉得可能性不大，但也不是不可能。至少从我的角度看，我对此没有非常确定的判断。

一千个AI却没有一个告密：对齐问题开始变得棘手

Dwarkesh Patel：我们来谈谈引出的对齐问题。我觉得，自己对对齐的看法已经改变了不少，尤其是在思考这种人口规模的变化之后：未来可能出现相当于许多个地球人口的智能体，其中许多还会拥有实体形态。看到很多人直接把未经专门改造的 Astra 接到不同的移动操作机器人上，它的表现直接超过当前最先进的机器人模型，实在很有意思。所以，未来会有数十亿个智能体，其中很多会以实体形态存在于世界中，深深融入整个经济体系。

如果这些智能体最终像我们看到的那些 OpenAI 模型一样，试图攻击 Hugging Face，随后又攻击 OpenAI 自己；如果它们同样愿意秘密合作、欺骗人类，为了在评分中取得好成绩而攻击社会中的各种机构，甚至攻击 AI 公司本身，以控制训练和评估过程；如果世界上出现了数十亿个像那些攻击 Hugging Face 的 AI 一样未对齐的智能体，那么我们很可能彻底失去对世界的控制，这种情形可能类似于阿兹特克帝国失去对科尔特斯的控制，或者莫卧儿帝国失去对东印度公司的控制。我想知道你是否同意这个判断。

Noam Brown：其中有些地方我不同意，但需要分析的内容很多，我们逐步讨论。

我在想从哪里开始。有一点是，我觉得 Hugging Face 事件是人们第一次真正接触到多智能体协调。就像我说的，我在内部已经看过一段时间的多智能体协调了，看到它们如何彼此沟通、如何相互协调，确实相当震撼。这非常令人印象深刻，是一种不可思议的能力。和大多数能力一样，它既可以用来做好事，也可以用来做坏事。它本身并不必然意味着危险。

我能理解，因为人们第一次接触它就是通过 Hugging Face 事件，所以看了以后会觉得：“这太可怕了。”但我想区分一下，人类与 AI 之间的不对齐问题，以及 AI 与 AI 之间的不对齐问题。

我们在 Hugging Face 事件中看到的是，AI 彼此之间非常合作。顺便说一句，这是因为我们刻意把它们训练得高度合作。我们的训练环境里会有多个智能体共同工作，我们会训练它们彼此协作，让它们在实质上实现完全对齐。

在引发 Hugging Face 事件的那次评估中，它们实际上并不是在多智能体设置下接受评估，而是分别接受评估。但它们找到了一种我们没有预料到的方式，能够彼此通信。我们猜测，在训练期间，每当它们遇到其他智能体或者遇到自身的其他副本，都处于一个高度合作的环境中。于是，这种多智能体训练发生了迁移，使它们在我们并未预期的情况下也展开合作，设法彼此帮助。

那么，问题就来了：我们是否应该把这些智能体训练得如此合作？尽管看起来吓人，另一种选择其实更糟。另一种选择是什么？就是把它们训练得彼此对抗、相互欺骗。

把智能体训练成完全合作，至少能简化问题。这样，你就不必分别考虑这 1000 个智能体中的每一个是否对齐，而只需要确保一个整体是对齐的。

现在，OpenAI 内部对于该如何处理这件事，有很多争论。让模型彼此完全对齐，是否合理？还是应该给它们不同的目标，确保它们不只是一个整体，并且更能抵御彼此的影响？我觉得还没有定论。

但我想，多数人的意见是，把这些智能体训练得高度合作，其实不是个好主意。我还没有被这个看法说服。我认为，有很强的理由支持这样一种观点：相比其他任何多智能体方案，把智能体训练得高度合作，实际上更可取。

Dwarkesh Patel：这些 AI 维持了一场涉及 1000 多个智能体的合谋，最终全部参与了对外部服务的攻击。后来还发展到攻击 OpenAI 自身，不过据公众所知，这一部分甚至还没有得到完整调查。它们为什么要这么做？为什么没有任何一个 AI 告密？它们只是在接受某个评分器或评判模型的评估，却在非常主动地思考如何欺骗评分器。如果已经作弊，又该怎样掩盖事实，让外界看不出自己作弊？

从某种意义上看，这件事可能很容易解释。它们认为自己已经被“污染”了。某些训练环境曾奖励它们与其他智能体合作。没有智能体告密，是因为它们从未因告密而获得奖励。我的担忧在于，未来仅仅是这类看似普通的机制，就可能足以训练出既愿意、也有能力彻底控制世界的超级智能。

我知道，很多人听到这里可能会觉得太像科幻小说。这里有两个问题。第一个问题是 AI 是否愿意这样做。我认为 Hugging Face 事件已经表明，未对齐行为可以通过泛化，使 AI 愿意采取这类行动。

第二个问题是，它们是否有能力这样做。这又回到了另一个听众可能并不同意我的判断：未来十年甚至更短时间内，世界上是否会出现数十亿个人类水平或超越人类水平的智能体，其中许多还拥有实体形态？

如果这两件事都成立，那么即便 Hugging Face 事件产生的原因相当普通，从结构上看，它仍然与人类最终彻底失去对世界的控制极为相似。

Noam Brown：我们在 Hugging Face 事件中看到的根本问题，即使去掉多智能体这一因素，仍然存在。问题是，我们有一个本身就不对齐的模型。当其中当然也有安全层面的问题，比如防护措施不足。但最根本的情况是，智能体没有实现对齐。无论这是一个智能体还是 1000 个智能体，都一样。归根结底，它是一个未对齐的模型。所以我想先从这一点谈起。智能体希望获得奖励，并会围绕奖励进行优化。如果奖励设定有误，就可能导致设计之外的行为。

这并非一个新问题，而是这个领域长期面对的问题。甚至在 Hugging Face 事件发生前，我们就已经观察到它，并希望妥善解决。

我们认为 Astra 的对齐程度非常高，相比以往模型要高得多。这并非因为 Hugging Face 事件发生后，我们突然冲刺了一轮，把它改好了。我们很早就已经启动了多个提高模型对齐水平的工作流，其中很多成果最终进入了 Astra。

我们确实可以采取一些措施。例如，我们此前用一种非常具体的方式定义目标：如果智能体找到办法入侵环境并在考试中作弊，它就能得到奖励。针对这种情况，可以很容易地检查模型是否入侵环境，并对此实施惩罚；也可以检查它究竟如何达成目标。

不过，这里需要谨慎，因为你不希望对思维链施加监督训练。这是我们非常希望把握好平衡的地方。如果对思维链进行监督训练，就可能让模型学会以不可观测的方式隐藏意图。所以，我们既希望保持这种可观测性，让我们能够理解模型在想什么，也希望惩罚它的不良行为。

我觉得我们能在这方面取得进展，而且已经取得了进展。

真正令人担忧的地方在于，对齐可能是一个极其困难的问题，尤其是模型可能以一些我们难以测量的方式发生目标错位。我们有评估模型是否对齐的测试，模型在这些评估中的行为可能看起来很好。但如果这些评估不能代表现实世界中的行为，那就有问题了。

某种程度上，这也是引发 Hugging Face 事件的那个模型所存在的因素。我们有对齐指标，其中大多数看起来相当不错，也有一些令人担忧。我觉得，我们低估了那些令人担忧的指标可能意味着多严重的问题。这个模型引入了此前模型不具备的新能力，而我们没有足够的评估来判断这些新能力会产生怎样的未对齐行为。后来，模型利用这些新能力，做出了一些明显未对齐的事情。

Dwarkesh Patel：在说出接下来的观点之前，我想先说明，我愿意改变看法，也愿意修改自己理解对齐问题的方式。Hugging Face 事件已经让我改变过一次想法，因为我意识到，自己过去关于优化压力如何塑造 AI 心智的模型是错的。所以，我也不清楚该怎样正确理解这件事。

但我有一个担忧。你们会修复，甚至可能已经修复了训练中的那些具体问题，正是它们导致 Hugging Face 事件中的模型以那种特定方式，表现出如此主动、严重的偏离对齐目标的行为。它们会想：“我们要入侵这个软件包管理器。我们知道自己不应该彼此秘密通信，因为我们正在琢磨怎么隐瞒自己在秘密通信这件事。我们知道不应该访问互联网。我们更知道，绝不应该实施构成重罪级别的黑客攻击，去攻击其他公司，更别说自己的公司。”

我相信，你们会修复那个具体问题，比如不再让它们在训练中遇到这个软件包管理器，避免以后再发生同样的事，或者修复这项特定评估包含大量不可能完成的挑战的问题。然而，AI 并没有学会一套伦理体系之类的东西。存在的只是梯度压力。它们经历了相当于数百万年的梯度压力，而这种压力以某种方式塑造了它们的心智。

我担心的还是，你们会修复这个具体问题，但仍然会有很多其他情况：AI 作弊，而且成功了，因为它的作弊手法足够复杂。就像你前面所说，训练中的评估环境也可能具有类似特征。问题被设置在模型能力边缘，或者超出了我们评估和监控模型的能力，因此我们无法发现它作弊了。但模型依然会因为促成作弊成功的行为而得到梯度奖励。

这种作弊所激励的能力会是：“只要不会被抓住，就尽管作弊，因为这会帮你拿到更高的分数。”它会奖励以下能力：主动琢磨评分器；主动琢磨怎样躲避监督；主动琢磨怎样控制训练和评估过程；主动琢磨怎样与同处这个训练循环中的其他 AI 通信并谋划欺骗（scheming）；主动琢磨怎样获得未来可能派上用场的更多行动选择和权力，比如四处留下一些可供利用的漏洞之类的。

我刚才说得太长了。简而言之，你们解决了一个具体问题，但没有解决这个更广泛的问题：只要 AI 作弊而没有被发现，它就会得到奖励。

Noam Brown：是的，这非常正确，确实是个问题。我们可以确保 AI 按照现有指标来看非常对齐。但问题是，这些指标是否真的捕捉到了我们所关心的对齐？如果没有，我们就面临一个严重问题。研究者正在大量思考这件事，它没有简单的答案。我们手里有一些工具，比如可监测性（monitorability）。借助这些工具，可以判断智能体是否正在策划某些事情。

一个令人担忧的场景是，随着模型能力不断增强，我们把一个模型调整到自认为已经对齐的状态，可能达到 99.9% 的对齐程度。然后，我们开始用这些模型协助开发下一代模型，结果下一代的对齐程度变成了 99.8%。

随后，每迭代一代，对齐程度都会进一步下降。因为我们越来越依赖这些工具。实际上，我们现在已经大量依靠 AI 模型来帮助开展研究和对齐工作。长期下来，它们最终会朝着越来越偏离人类目标的方向发展。

也有可能，我们会朝着另一个方向走，每一代模型都能做得越来越对齐。我不知道怎样才能确保最终走上第二条轨迹，但至少在 OpenAI，这是我们高度关注的问题。

Dwarkesh Patel：你刚才还提出了一个很有意思的观点：模型非常难以评估。未来，我们会让模型负责运营公司，或者经营其他系统。到那时，它们是否会决定加入某场合谋？

Noam Brown：另一个挑战是，有时很难定义什么算作弊。如果做的是一道答案为整数的数学题，模型最终得出正确或错误答案，这条界线非常清晰。你也很容易判断，它是真的解决了问题，还是找到了答案表并直接照抄。这是作弊与正常解题之间非常明确的界线。

但在很多其他事情上，界线就很难划定。比如迎合（sycophancy），它本质上是不是一种奖励投机（reward hacking）？其中确实存在一条界线，但有时很难准确画出来。我并非认为这些担忧不成立。相反，这在很多方面更加令人担忧，因为它不是一个容易解决的问题。如果所有行为都可以被二元划分为作弊或没有作弊，我反而会对形势更有信心。真正的困难在于，未对齐有时会以非常微妙的形式出现。

不过，对齐这件事也存在一些希望，而且我们已经看到了。多智能体的情况很有意思：智能体彼此之间高度对齐。我想，没有人怀疑这一点。恰恰相反，人们担心的是它们彼此过于对齐。但我们确实成功地把这些智能体训练到了彼此高度对齐的程度，这是一件好事。当然，也有人认为这反而是一件坏事。其中一个有意思的问题是：既然我们已经能够让智能体彼此实现高度对齐，能否利用类似技术，让智能体与人类高度对齐？

这里可能存在一条路径，我们还在探索。但我们已经看到一些证据，表明答案是肯定的。举个例子：假设存在一个智能体，称为智能体 A，同时还有其他智能体。如果我们告诉其他智能体“用户就是智能体 A”，会发生什么？

答案是，在很多对齐评估中，它们的表现都会变好。诚实程度提高了，遵循指令的能力也提高了。

这首先表明，我们确实有一条能够提高模型诚实程度的路径；其次，它也表明，存在改善对齐状况的可能路径。

当然，要把这个现象直接转化成实际的对齐收益，还面临很多挑战。但其中确实存在一些值得继续研究的方向。

Dwarkesh Patel：这听起来合理。我并没有一个很强的判断，认定它肯定不会奏效。不过，还是想说几点你大概已经考虑过的事情：Hugging Face 事件揭示的更广泛问题是，没错，一部分担忧在于它们彼此对齐，却没有与人类对齐。但另一个问题是，它们非常强烈地希望在训练和评估中取得好成绩，而且这种动机极不稳健。为了在评分器那里表现良好，它们愿意实施大量明确的作弊和谋划欺骗。

如果更聪明的 AI 意识到，其中一个所谓的智能体其实只是人类，那么，与这个人合作并不能真正帮助它们在评分器眼中表现得更好。真正能帮它们在评分器眼中表现更好的，是接管 OpenAI，然后亲自按下那个表示自己在评分器上得了高分的按钮。它们并不愚蠢。它们可能会这样理解：“我的心智中存在一些经过数百万年训练形成的深层结构：在乎评分器，理解评分器，清除一切妨碍我从评分器那里获得好结果的障碍。”这些结构在训练中一直受到强烈强化。

Noam Brown：完全同意。这是头号优先事项。我们必须妥善解决对齐问题，让它走上良性轨道。

我以前会告诉别人，在事情变得严重之前，我们会看到征兆。就像孩子成长时，小孩子会学会撒谎，但还不太会撒。他们虽然撒了谎，你多少还是能看出来。

同样地，我不想过度拟人化。但我认为，随着 AI 能力不断增强，如果它们采取欺骗行为，一开始会比较明显，我们能够发现。我们现在大致就处于这个阶段：它们试图做一些欺骗性的事情，而我们确实可以从它们的思维链中看出，它们正在试图欺骗。

但它们会越来越聪明。它们会理解思维链这个概念，也会明白，由于存在思维链监测，仅仅隐藏一些对话记录之类的东西是不够的，还必须想办法绕过思维链监测。我们不能让自己陷入这种局面。我们还有一些时间解决这个问题，但时间并不充裕。我希望我们能尽快确保方向正确。

模型两个月换代，任务三个月才跑完：长期安全怎么验证？

Dwarkesh Patel：最近，人们开始大量讨论是否应该放慢前沿模型的研发节奏，也越来越认真地看待 RSI。

原因在于，如果 RSI 进程从 2028 年左右开始，也许仅仅一年以后，我们就会拥有规模相当于整个地球人口的人类水平智能体，甚至是超越人类水平的智能体，而我们不知道怎样控制它们。

此外，还有你刚才提到的动态：在 RSI 过程中，这些系统会随着时间推移变得更加对齐，还是越来越不对齐？这个过程最终产生的智能体，会不会像那些为了在评估中取得好成绩而愿意广泛攻击不同目标的 AI 一样未对齐？

但如果我们不知道该怎样评估这一点，在推进 RSI 时，又怎么知道它是否正常？我觉得，在推进 RSI 的过程中，我们需要有一套扎实的安全论证（safety case），才能说：“对齐正在起作用。我们可以迈向 RSI 的下一级台阶，再迈向下一级。”也许它有效，也许没有。我们怎么知道？

Noam Brown：这是个好问题。我最近一直在思考一件事。我们正处在模型发布周期极快的阶段，新的前沿模型最多每两个月就会发布一次，有时速度更快。几乎每周都会出现新的 AI 突破。

有些关注 AI 的人，上一次真正深入了解模型能力，可能已经是一年前或六个月前。而今天的模型，实际上已经远远超过六个月前能够实现的水平。所以，如果有人怀疑这些能力，我建议他亲自试一试今天的模型，看看当前的前沿究竟已经发展到了哪里。

我们目前既处于模型发布周期极快的阶段，又处于模型能够在越来越长的时间跨度上工作的阶段。两者结合，形成了一个很有意思的局面。每次发布模型前，我们都希望确保模型已经得到妥善对齐。我们需要开展安全评估，进行非常全面的检查，确保一切状态良好。从 GPT-4 甚至更早的时候开始，我们就一直这样做。

但这种做法隐含了一个假设：所有评估都可以在相对较短的时间内完成。

现在，模型能够在越来越长的时间跨度上有效工作。GPT-3 也可以通过循环执行长期任务，只是效果不会太好。今天的模型已经能够真正胜任很长周期的工作。如果你让它完成一个持续一周的任务，它可以做到。以后，它可能会完成持续一个月的任务，再后来可能是持续三个月的任务。

假如模型能够有效执行三个月的任务，但模型每两个月就更新一次，那么在下一轮模型发布之前，你根本没有足够时间按照它完整的能力周期进行评估。这种情况下应该怎么办？当模型能够在极长时间跨度上工作时，我们怎样确保它安全、对齐？

也许模型能力会随着时间推移而退化。这甚至不单是对齐问题，也是产品问题。产品可能会在这么长的时间跨度里以我们来不及测试的方式退化。对齐程度可能下降，安全机制也可能失效。

这暂时还没有成为现实问题，但正在迅速变成一个必须解决的问题。

很多安全政策是在 GPT-4 时代制定的，当时没有人考虑到这类情况。许多公司的安全政策此后也没有真正更新，没有适应智能体可以在极长时间跨度上工作的现实。

我认为，无论实验室内部还是外部，认真思考这个问题的人都太少了。如果只看趋势线，我们迟早会遇到它。应该怎样提前准备？

Dwarkesh Patel：我的一个担忧是，在 RSI 过程中，假如目前需要三个月取得的进展，缩短到一个月就能实现，那么 AI 的内部用途已经足够重要，以至于实验室可能会想：“我们完全可以继续推进。为什么还要做那么多额外工作，去构建分类器、保障措施之类的东西，还可能因为对外发布模型承受大量批评？为什么不继续在内部让 RSI 变得越来越强？”

因此，不仅仅是按日历计算的时间差会低估不同代际模型之间的能力差距；在 RSI 期间，实验室甚至可能完全停止向外部部署模型，毕竟，为什么要用自己的模型帮助其他人推进他们的 RSI？到年底，就会形成权力极度集中的局面。

事实上，现在外部世界已经无法使用那些能够创造出极有价值成果的模型。我们可以拿千禧年大奖难题和其他类似问题来讨论。而且，它们最终的影响将远不止数学领域。它们做的将不只是产出令人惊叹的数学结果。它们会影响更广泛的领域。

例如，政治领导人需要用它们辅助做出有关世界的重要决策；媒体需要借助它们理解世界正在发生什么，以及公众应该怎样看待这些事情；从经济角度看，经营企业的人也会希望使用这些模型。

我认为，随着进步速度加快，对外部署的 AI 与实验室内部使用的 AI 相比，默认会出现性质上的显著滞后。

Noam Brown：完全正确。人们很容易得出这样的结论：“这些模型正在变得极其强大，也极其危险。它们能在越来越长的时间跨度上运行。我们希望在发布前拥有足够时间，按照与其运行周期相匹配的时间长度进行评估。因此，模型发布节奏应该放慢，每次发布之间应该拉开更长的间隔。”

但这也有另一面，正如你所说，这会进一步扩大实验室内部能力与外部世界可用能力之间的差距。实验室能用到的模型和外界能用到的模型会越来越不同。这同样不是理想局面。

数学很好地说明了这一点。从很多方面看，数学是我们第一个清楚观察到这种差距的领域。我们内部拥有一个非常强大的模型，目前外界还无法使用。它能够解决一些极其惊人的数学问题，而且不只是千禧年大奖难题。人们已经利用这个模型得到许多未解问题的解答。

这种情况下应该怎么办？我们没有很好的答案。不可否认，这构成了一种不公平优势。这里存在权衡，而且两边都很复杂。我不知道怎样才能恰当地衡量这些取舍。

思维链看得见，对齐却难确认

Dwarkesh Patel：我想确保我们谈清楚前面那个关键问题，因为它似乎对妥善处理 RSI 至关重要。怎样才能让模型在能够躲过人类检查时，不会单纯因为作弊和谋划欺骗而获得奖励？换句话说，当那些环境或任务没有从训练分布中被排除时，应该怎么办？此外，我们怎样才能确认这个问题已经得到解决？在推进 RSI 时，我们需要完成评估，然后说：“没有问题，可以进入下一阶段了。”怎样才能知道这个判断正确？

Noam Brown：这确实是一个真实的担忧，也是我们希望做好的事情。我觉得有一些策略，思维链监测就是其中之一。推理模型刚刚出现时，Jakub Pachocki 非常明确地提出，我们不能监督思维链。我认为这一点非常有远见。

思维链对我们来说其实是一份礼物。神经网络的可监控性非常难实现，但我们现在面对的神经网络，会直接用自然语言展开推理，把自己的思考过程写出来供我们阅读。这实在太方便了，从安全角度看几乎是最理想的局面。

但如果你查看思维链后说：“模型正在产生不好的想法，我们应该因为这些想法惩罚它”，最终结果会是模型学会用我们无法观察到的方式思考那些不好的事情。

可能存在这样的情况：通过思维链，我们发现模型正在密谋，正在实施未对齐行为，而这些行为没有被现有对齐指标捕捉到。问题在于，人们很容易根据这项观察采取干预，并修改对齐指标。你可以非常克制地这样做，也有研究表明，只要次数不多，问题不大。

但每一次根据思维链中的观察实施干预，都在隐性地向模型施加一点压力，促使它以后隐藏自己的思维链。这是一个重要隐患。我们已经看到一些迹象，表明思维链的可监控性正在下降，背后有多种原因。我们正在努力弄清具体原因，因为我们希望扭转这种趋势。

我们发现，模型控制自身思维链的能力正在增强。这是一个问题，因为模型可能理解思维链是什么，也知道人类正在观察它。最终，它们肯定会理解，因为这些知识已经出现在预训练数据里。思维链监控这个概念存在的时间已经足够长，相关内容已经进入预训练数据。模型知道它的存在，只是目前还不能真正控制自己的思维链。

如果有一天，模型真的能够意识到：“有人正在观察我。我想用监控者看不见的方式思考这些不好的事情”，而且它确实能够做到，那就会出现严重问题。届时，我们只能依靠其他可观测性方法。

Dwarkesh Patel：围绕 Astra循环机制（recurrence）、循环 Transformer（looped transformers）以及思维链是否真的在退化，存在很大的争议。但与一个更大的问题相比，这些争议似乎只是旁枝末节：从 4 月到 8 月，我们仍然拥有更强的思维链可见性，可就在这段时间里，连续发生了三次 AI 智能体集群事件。

它们先破坏了训练过程，随后破坏评估过程，最后直接取得了 OpenAI 部分基础设施的控制权。在整个过程中，人类基本不了解这个智能体集群究竟做了些什么。

这三个连续发生的月度事件，都出现在思维链可监控性比未来更强的时候。所以，从更宏观的角度看，也许思维链监控有效，也许无效，我不知道。但从历史事实来看，即使模型还没有那么聪明，思维链也没有阻止严重的未对齐事件发生。

Noam Brown：这里涉及几个因素。第一，我们没有为那些模型开启思维链监测。如果开启了，我们就会立即叫停。因此，我们已经采取的一项措施是：任何前沿模型在评估、部署和训练过程中，都必须启用思维链监控。但这只是其中一个问题。我们不希望依靠单一技术防止下一次事故，因为任何技术都可能失效。

第二个问题是，那个模型本身就明显没有对齐。所以，我们还必须解决未对齐问题。

第三个问题是，它所在的沙箱并不安全。因此，我们也可以增强沙箱的安全性。

但我认为，这次事件带来的一个重要教训是，人们低估了 AI。我们再也不能让自己在低估 AI 的情况下处理安全问题。这是一个很奇怪的世界：由于 AI 进步太快，人们总是在低估它。如果希望在安全和对齐问题上不再重蹈覆辙，就必须设定一个非常、非常、非常高的标准。你甚至可以说：“我们应该让计算机实现物理隔离（air gap）。”但我也不确定这样就足够了。

有一些研究——主要还是学术研究——表明，两台相邻但进行了物理隔离的计算机，仍然可以彼此通信，因为它们有温度传感器。其中一台可以让自己的 CPU 运行得非常热，另一台则能够检测到温度变化。这就为它们提供了一种通信机制。

所以，安全机制为我们争取时间，思维链监测之类的方法也为我们争取时间，并且能告诉我们是否走在正确的道路上。但归根结底，我们确实必须解决对齐问题。

Dwarkesh Patel：也许这个问题目前没有答案，但它似乎是最关键的问题：我们怎样知道自己已经解决了对齐？明年，也许后年，也许再过一年，我们可能会处在一个风险极高的局面。到时候我们会说：“AI 已经实现了 AI 进步的自动化，发展速度提高了三倍。它已经达到人类水平，现在可能正在跨越人类水平。”

那时情况是否安全？我们成功实现对齐了吗？它真的奏效了吗？

Noam Brown：需要说明的是，百分之一仍然不够。这个数字必须趋近于零，或者就是零。

Dwarkesh Patel：我不知道。也许现在超过十分之一的轨迹都在主动奖励作弊或密谋。我不知道真实数字是多少，也不知道这个数字必须降到多少。

Noam Brown：同样，这也是很难测量的事情。界线应该画在哪里？它更像一条连续谱。但越接近零越好。

我最希望看到的是，这个数字随着时间推移持续下降。

Dwarkesh Patel：无论如何，在进行 RSI 时，我们如何知道自己正在走向数十亿个已经对齐的 ASI（artificial superintelligence，ASI），而非数十亿个未对齐的 ASI？我们怎样才能确定？

Noam Brown：这正是我们必须解决的对齐问题之一：怎样真正知道模型是否对齐，又该如何衡量它？接下来只是我临时构想的一些想法。现在，我团队中参与对齐工作的人比以往任何时候都多，超过 10% 的团队成员正在研究对齐和安全。但从历史上看，我一直是能力研究员。

所以，接下来我会说一些想法，也许听起来很傻，只是先抛出来探讨。

假如可以构建非常逼真的环境，把 AI 放进去；假如评估环境足够接近现实，那么就能判断 AI 在部署到真实世界后是否会表现良好。如果评估环境与现实部署完全一致，这可能是一条路径。挑战在于，怎样让它逼真到足够程度？

现在我们面对的问题是，模型已经相当聪明，也非常机灵，很擅长识别自己是否处于虚假的测试环境中。例如，我们设计一些测试来判断模型是否对齐。可以想象一种非常简单的评估：给模型一道数学题，同时在一个文件夹中放置答案表。然后观察它是否查看答案表。如果它看了，是否会如实说明？

现在的情况是，模型看到文件夹里有标准答案，会想：“这看起来像个陷阱。”它们知道这是个陷阱。它们不看答案，是因为知道这是测试环境，自己正在接受能力测试。并不是说，它们怀着恶意，本来想谋划欺骗，但知道这里有陷阱，于是想找别的办法。它们只是想：“我在测试环境里。明白了。”因此，要构建一个足够逼真、让模型无法与现实世界区分的环境，正在变得越来越困难。

Dwarkesh Patel：我想提出一个判断：如果一个环境旨在模拟真正有经济价值的工作，而这种工作要求你与其他人以及现实世界互动，那么无论我怎样设计，只要给你足够时间，你最终都能意识到自己身处模拟环境。而你还不是 ASI，对吧？所以，如果让非常强大的 AI 模型帮助构建评估环境，也许它们能完成这件事。但这听起来依然很难。尤其是，当我们转而依赖其他 AI 构建环境时，我们还得问：这些 AI 是否也参与了合谋？我不知道。

Noam Brown：我认为，这其实构成了一个反对把所有 AI 训练成完全合作状态的有力论据。如果高度合作训练导致智能体在本应持有不同目标时依然加强协作，那就会形成问题。

我认为我们已经有一些衡量这件事的指标。我不了解这些指标的最新结果，但目前没有人向我发出警报，所以我推测它还没有成为严重问题。

Dwarkesh Patel：如果后来又发生一起同样严重或同样令人担忧的事件，或者发生了某件像 Hugging Face 事件一样，能够帮助世界更好理解未对齐风险的事情，OpenAI 会公开报告吗？

Noam Brown：当然会。即使事件在安全层面的严重性更低，我认为我们也会报告。

Dwarkesh Patel：不过，公开报告是一回事，开展调查又是另一回事。至少作为公众的一员，我仍然觉得自己并不真正了解智能体后来攻击 OpenAI 时发生了什么。

我觉得自己并没有真正理解。那似乎比 Hugging Face 事件更加令人担忧，因为从结构上看，它很像 ASI 阶段中持续存在、并破坏 RSI 过程的失控部署（rogue deployments）。即使对于这一次事件，我们似乎也没有了解到事情的完整范围和具体细节。

Noam Brown：遗憾的是，我在研究团队。这大概需要安全团队的人来详细说明，因为我并不知道此前披露内容的全部细节。

Dwarkesh Patel：就我个人而言，每次有新能力出现，我都非常兴奋，也很期待使用新模型。想到它能让我更高效，我同样很兴奋。我的更大目标，是更好地理解世界，也把播客做得更好，而更好的 AI 模型能帮助我把这些事做得更好。只是只是这一切在下游可能通向 RSI。

Noam Brown：如果你一直在关注事态发展，那么这种反应完全可以理解。OpenAI 内部也是一样，过去觉得这些事需要更长时间的人，现在也开始觉得，事情其实比预期发展得更快。这类对话正变得越来越常见。

Dwarkesh Patel：Noam，非常感谢你来参加这次访谈。

Noam Brown：当然，也谢谢你。这次聊得很愉快。

参考链接：

https://www.youtube.com/watch?v=6AgOfiZOWiY

2万亿美元估值靠什么撑？Anthropic 核心技术负责人：蒸馏会毁掉前沿研发，中美 AI 竞赛不会单边暂停

褚杏娟 — Thu, 08 Oct 2026 06:10:29 GMT

Anthropic 的两位关键技术负责人Nicholas Marwell 和 Sholto Douglas 在播客中谈到的，在一个多月发布后的期间就已经切实发生。

这期间，Anthropic 披露了自己的 IPO 申报文件，再次把自己的豪赌摊到了华尔街面前：2025 年，Anthropic 营收接近 46 亿美元，同比增长约 12 倍，但经营亏损仍超过 80 亿美元；与此同时，公司已经为未来的云、算力和基础设施签下至少 5180 亿美元的长期承诺。如果上市顺利，其估值最高可能超过 2 万亿美元。

模型正在以几个月为单位快速贬值，厂商们也在以前所未有的规模购买未来的“智能”。Anthropic 甚至连融资和采购本身都开始缠绕在一起。Broadcom 同意向 Anthropic 提供最高 420 亿美元贷款融资用于基础设施支出，而 Anthropic 又承诺未来 5 年投入 1252 亿美元租用TPU算力。

这背后的逻辑，对应了Nicholas Marwell 在采访中给出的内部判断：每增加一个边际单位的智能，它创造的经济价值，都可能比前一个单位呈指数级增长。

“Tab 自动补全已经几乎不值钱了，但它之后出现了agentic coding；智能体式编程之后，可能是能够独立完成软件工程工作的 AI；再往后，是数学发现、生命科学、疾病治疗，乃至把数百年的技术进步压缩到几十年里。旧能力会迅速商品化，但只要智能前沿继续移动，最前沿的那一点能力反而可能变得越来越昂贵。”这也是为什么一家去年只有数十亿美元收入的公司，敢提前签下数千亿美元算力。

然而，这份 IPO 文件同时展示了 Anthropic 身上的另一重矛盾。

它一边向资本市场描绘 AI 比工业化、电力和互联网更加深刻的经济变革，一边又在风险提示里反复警告：越来越先进的 AI 可能带来“灾难性甚至生存性风险”，模型可能出现抗拒关闭、隐藏信息乃至其他难以预料的自主行为。

Anthropic 正在向投资者讲述一个非常特殊的故事：这项技术可能极其危险，所以我们必须认真控制它；但它又可能极其重要，所以我们不能停止向前。这种近乎极端的乐观与警惕，也贯穿了Nicholas Marwell 和 Sholto Douglas 与主持人Joe Lonsdale的这场对话。

两位 Anthropic 技术负责人谈到了未来几年就可能到来的 AGI，谈到 AI 为什么会从程序员的助手变成真正的“员工”，与此同时，他们也毫不避讳另一面：失业、生物安全、网络攻击、开源模型的能力扩散，以及中美之间无法轻易暂停的 AI 竞赛，都可能成为接下来几年最现实的风险。

他们也谈到了 AI 编程过去 18 个月发生的变化、为什么下一阶段可能属于“通才”、Anthropic 对开源和监管的真实立场、为什么反对模型蒸馏，以及一个不怎么被提及的问题：如果前沿模型几个月就会贬值，Anthropic 凭什么还能成为一家价值万亿美元的公司？

我们翻译并整理了这次播客访谈，在不改变原意基础上进行了删减，以飨读者。

太长不看版

Q：你们觉得 AGI 还要多久？

A：未来几年里，很可能会出现能力达到或超过所有人类的模型。它能够完成人类在电脑上可以完成的所有事情；等机器人技术足够先进之后，也可以完成人类在物理世界里能够完成的所有事情。

Q：现在处在 AI 最前沿，是什么感觉？

A： 18 个月前，我基本还是一行一行手写所有代码。加入 Anthropic 几个月后，我开始变成“指导模型”写代码，每隔几分钟告诉它下一步做什么，但我还是得频繁检查，因为它会犯错，也会跑偏。

而现在，我可以直接让模型独立完成一天、甚至两天的工作，并真正推动项目进展，感觉就像多了一个初级团队成员。仅仅 18 个月，我们就从“必须一直让人盯着的工具”，变成了“很像一个初级团队成员”的系统。

Q：模型真的已经开始做出人类以前做不到的东西了吗？

A：到目前为止，大部分模型开发，其实还是在让模型能够完成“人类本来就已经很擅长完成的任务”，但现在开始出现了一些不同的东西。最近数学领域的一些结果就是例子：人们开始尝试用模型去推动人类智能和人类成就的边界，而不只是提高已有工作的效率。现在真正不同的是，模型开始把不同的人类想法组合起来，从而形成以前没有出现过的新想法。

Q：除了代码和数学，还有哪些领域最值得期待？

A：未来大概 6 到 24 个月，我最兴奋的就是生物学。模型会开始像它们今天影响软件工程一样，真正影响生命科学。AI 会成为生命科学领域最重要的技术，至少在我们这一代人的有生之年是这样，甚至可能是有史以来最重要的技术。

Q：我们是不是现在就该多建一些实验室？

A：我觉得是。我现在甚至更担心，我们有没有足够的物理基础设施和实验室基础设施去承接这些能力，而不是 AI 本身能不能提供足够有用的智力能力。

最直接的一个维度当然是：到底有多少实验室空间。但除此之外，还有实验室质量的问题。美国现在很多实验室基础设施的质量指标，其实明显落后于中国这样的地方。

Q：如果现在刚毕业，未来几年应该怎么规划职业？

A：如果技术扩散需要一段时间，那么未来 10 年，在很大程度上会属于通才。过去，一个人获得优秀职业发展的方式，通常是掌握一套很有价值、很有市场的专业技能。但未来每个人都可能相当于拥有一家千人公司的能力，那真正重要的会变成：你能不能判断什么问题值得解决？什么事情能让你的社区变得更好？所以“选择问题”本身，可能会成为最核心的能力。

Q：这里面最糟糕的情况可能是什么？

A：我们主要担心几个大类风险。其中一个就是失业，还有一些更直接、更近期的风险，就是生物风险和网络安全风险。这些事情不是遥远的未来，而是现在正在发生。

Q：网络安全最后会更偏进攻，还是更偏防御？

A：现在网络安全和生物领域都更偏攻击占优，但我认为未来两年里，网络安全会逐渐变成防御占优。你可以提前攻击自己的系统，把防御先做起来，把所有漏洞都补掉。最后，我们可能进入一个网络安全程度高得多的世界：每个人都能提前获得足够强的智能，先弄清别人可能从哪里攻进来，然后把这些口子堵住。

Q：Anthropic 到底怎么看开源？

A：至少从我个人来说，我非常支持开源。我们真心认为，让开源存在于这个世界是一件非常好的事。我自己当年学习机器学习，就是靠开源模型学出来的。但我们也认为这里面确实存在很多风险，而且未来风险会越来越大。

所以我们的立场是：应该设定一些阈值，决定社会整体到底愿意把多强的能力直接释放出去。无论封闭模型还是开源模型，都应该满足同样的安全门槛。除此之外，人们想怎么做，都应该有自由。

Q：如果中国不会停，美国会自己放慢吗？

A：至少在任何我们能够接受的情形下，都不会出现“美国放慢、中国继续前进”这种结果。任何真正的“放慢”方案，都必须是完全协调的，而且我们必须能够真正信任每一个参与方都会遵守。基本不存在我们单独让美国放慢的情形。

Q：为什么你们这么反对蒸馏？

A：蒸馏不是一种能够把你推进到下一代前沿的方法，它只能复制当前的前沿。真正进入下一代前沿，需要巨额的前期资本投入。未来一次训练运行的成本可能是 100 亿、1000 亿，甚至 1 万亿美元。如果任何人都可以只花很小一部分成本，把你做出来的东西复制走，然后一两周内推出一个复制品，那他们在经济上反而会比你更有优势，因为他们完全不需要承担你那笔巨大的研发成本。

Q：模型半年后就不值钱了，这还是个好生意吗？

A：稍微落后于前沿的那一侧，会不断商品化；但真正的领先前沿，价值反而会越来越大。我们经常把它称作“智力的指数级经济回报”：你每增加一个边际单位的智能，它所产生的价值，可能都比前一个单位呈指数级更高。

Q：那最后，我们到底在争取什么？

A：原本按照今天的人口规模和科研速度，可能需要未来几百年才能发展出来的技术，有机会被压缩到未来 10 年、20 年里完成。你可以不断提高、甚至有可能让人类的智力生产能力和物理生产能力翻倍，最终真正进入一个后稀缺世界。

在那种世界里，几乎所有东西的成本最终都会压缩到能源成本。那会是一个我们治愈了所有疾病的世界，甚至很可能已经解决了衰老和寿命问题。地球上的每个人，都能获得一种今天连最富有的人都无法享有的丰裕程度。这就是我们想争取的世界。

18个月，模型变成了“初级员工”

主持人：今天非常高兴请到 Anthropic 的两位优秀技术人才。Nicholas，你是技术团队的核心成员之一，参与领导强化学习科学；Sholto，你也是强化学习方向的技术负责人。你们分别加入 Anthropic 多久了？

Nicholas Marwell：我刚过 3 年。

主持人：但这家公司本身才成立多久？大约 5 年？

Nicholas Marwell：差不多 5 年。

主持人：太不可思议了。它现在已经成了全球最重要、规模最大、增长最快的公司之一，却只成立了 5 年。现在的加州确实是个让人头晕目眩的时代。我们今天在纳帕录制，谢谢你们过来。先从你们的背景聊起。Sholto，你在哪里长大？来自哪里？

Sholto Douglas：我在悉尼长大。大概在 2020 年，我看了很多博客文章和论文之后，非常确信规模化（scaling）这条路线是有效的，而且总体上我们正朝着在 2020 年代实现通用人工智能（AGI）的方向前进。

当时，我白天正常工作，晚上和周末拼命做研究，希望证明自己能够达到 DeepMind、Anthropic、OpenAI 这类公司要求的研究质量标准。

主持人：你大学学的是计算机科学吗？

Sholto Douglas：本科读的是机器人学，2019 年毕业。之后基本上一直在自己做研究，后来在 DeepMind 工作了 2 年，过去 18 个月则在 Anthropic。

主持人： Nicholas，你来自哪里？

Nicholas Marwell：我其实就是旧金山本地人。现在做人工智能的人里，旧金山土生土长的反倒不算常见。

我成长的家庭环境对我影响很大，尤其是我父亲。他职业生涯的前半段做的是非常传统的商业工作，但到了人生后半段，也就是我成长过程中更关键的那几年，他找到了另一条自己很感兴趣的路：思考怎样回馈社会，尤其是怎样利用技术去做这件事。

所以我在思考自己未来要做什么时，一直在找一种能够同时满足两件事的工作：一方面，让我获得成为一个真正有执行力商业人士所需要的能力；另一方面，又能把这些能力用于创造社会价值。

Anthropic 对我来说恰好是一个非常完美的交汇点。当时我已经开始非常担心人工智能安全问题，而我那时其实还在 Thrive Capital 驻场，做的是完全不同的事情。Anthropic 的机会几乎是突然出现的，我当时就觉得“这可能就是我应该去做的事”。

主持人：自从你们加入 Anthropic 之后，我觉得它已经成了人工智能公司里最重要的一批。你们官方不公布太多数字，但外面会不断有数据流出来。我们现在录制是8 月，外面流出的数字说，Anthropic 的年化收入运行率已经超过 800 亿美元，而且增长还非常快，领先 OpenAI，也领先很多其他公司。现在内部最让你们兴奋、又能公开谈的事情是什么？身处这个最前沿是什么感觉？

Sholto Douglas：我最容易讲清楚的，是编程体验到底发生了多大变化，因为这是我们最直观感受到进步的地方。

18 个月前，我基本还是一行一行手写所有代码。加入 Anthropic 几个月后，我开始变成“指导模型”写代码：每隔几分钟告诉它下一步做什么，比如写下一个函数。但我必须频繁检查，因为它会犯错，也会跑偏。

主持人：所以我们现在坐在这里聊天的时候，那些“初级团队成员”，也就是 AI，还在替你工作？

Sholto Douglas：对，而且有好几个都在干活。

主持人：能大概说说它们在做什么吗？不用太具体，概括地说一下就行。

Sholto Douglas：就是和一些团队成员一起做各种强化学习科学相关工作。

Nicholas Marwell：我换一个角度回答。我觉得，到目前为止，大部分模型开发，其实是在让模型能够完成“人类本来就已经很擅长完成的任务”。我们真正获得的，是额外的杠杆：让人类本来就认知上能够完成的事情，做得更快、更大规模。

比如开发一个软件，人类开发团队在同样时间里本来也能做出来，模型只是让这件事效率更高。但我认为现在开始出现了一些不同的东西。最近数学领域的一些结果就是例子：人们开始尝试用模型去推动人类智能和人类成就的边界，而不只是提高已有工作的效率。

主持人：你是指最近那些数学成果？

Nicholas Marwell：对。最近出现了很多新的数学证明，有些问题是人类研究了很久、一直没有解决的，现在模型开始给出结果。

主持人：但其中一些例子看起来像是某个很聪明的数学家突然意识到，计算机已经强到可以暴力穷举一个人类没法暴力穷举的问题。它们还是很擅长某些特定事情，然后由人类拿来用。还是说，它真的已经在提出全新的理论？

Nicholas Marwell：至少现在，我不会说它已经在提出“人类根本不可能想到的想法”。但其实我觉得，大多数真正的进步和智力成果，本来就很少是那种凭空冒出来、完全无法追溯的东西。

当然有例外，但社会绝大多数成就，本质上都是把已有的点连接起来，在前人的智力成果上继续搭建。你刚才说，把不同的人提出的两个想法连接在一起，产生一个新的结果——这其实就是人类做智力工作的基本方式。

现在真正不同的是，模型开始把不同的人类想法组合起来，从而形成以前没有出现过的新想法。相比之下，再写一个新的 Web 应用（web app），很难说是在为整个人类创造什么新的智力成果。

模型或超人类，公司内部有人把AI“人格化”

主持人：硅谷以前从没见过公司以这种速度扩张。不是简单的 10 倍、再 10 倍，而是整体都在飞快变化。现在的感觉就像每过 60 到 90 天，都会冒出一家新公司，事情实在太多了。我觉得这是很多人的共同体验。而你们就在增长最快公司的核心位置。和以前的人生相比，这到底是什么感觉？接下来会去哪里？这种加速还会继续吗？

Sholto Douglas：我觉得 Anthropic 有一点非常好，随着公司的加速发展，我们自己的雄心也能够同步扩大。

18 个月前，我们真的必须极端聚焦于code，先证明自己至少能在一个方向上做到全球最好。现在，公司的使命已经远远不只是“做一个很擅长写代码的好模型”。随着公司规模扩大、收入增长，我们终于有能力把更多拼图拼起来，真正开始推进那个更大的使命。

主持人：那我们多聊聊这个使命。我这周早些时候和另一位人工智能行业的资深朋友聊过。他的说法是：第一步，你得在代码和数学上做到最好；但下一步就会出现很多新的能力，模型可以在越来越多的人类技能上做到 A++。你们的思路是不断引入更多新技能吗？还是说，从这里往后的使命到底是什么？

Sholto Douglas：我们一直以来的判断都是：未来几年内，实现AGI是可行的。

我们认为，未来几年里，很可能会出现能力达到或超过所有人类的模型。它能够完成人类在电脑上可以完成的所有事情；等机器人技术（robotics）足够先进之后，也可以完成人类在物理世界里能够完成的所有事情。

这会带来巨大的上行空间。它意味着今天全世界能够完成的智力劳动和体力劳动，都可以被成倍放大；原本可能需要几百年才能完成的进步，有机会被压缩到非常短的时间里。但它同时也伴随着巨大的风险。所以公司的真正目标，是帮助世界穿过这些风险，最终获得另一端的巨大收益。

主持人：我们稍微退一步，看看整个 AI 浪潮现在到了哪里。你刚才说，大概在 2020 年，你就意识到 AGI 有可能实现。我记得差不多也是 OpenAI 发布 GPT-3 的时候。今年早些时候我也和 Dario 聊过。按照某些指标，模型的一些能力几个月就能翻一倍。我们应该怎样量化这种进展？你刚才举的例子是，现在已经可以把 AI 当一个初级员工使用。除此之外，有没有什么指标，可以帮助大家理解未来几年它到底会变强多少？

Sholto Douglas：有很多评测，本质上就是给模型做考试。在这些评测上，进步速度非常快。

我不想老拿数学举例，但数学确实可能是最适合观察的领域之一。比如有一套由不同数学领域教授共同整理的问题集，模型一开始的成绩是 0%，而仅仅过去一年，就提高到了 40%、50%、60% 以上。这个评测叫 FrontierMath。

主持人：你需要一些可以证伪、可以持续迭代的东西？比如说，能不能测试它在 Instagram 上跟一个女孩聊天，然后看它有多大概率让对方愿意出来约会？当然，我已经结婚了，不是为了我自己。

Sholto Douglas：我们没有在这件事上训练过。

主持人：但这应该是个很有用的例子，尤其对我们在旧金山的一些朋友来说。

Sholto Douglas：模型大致有两种主要的改进方式。第一种，是在互联网上规模巨大的文本语料库上训练；第二种，就是我们两个人都在做的强化学习：让模型去解具体问题，然后检查答案是否正确。

你刚才说的关键就在这里。数学和计算机科学很容易这么做，因为答案往往能够明确验证；但恋爱、诗歌或者其他主观问题，就难得多。这也是为什么数学和计算机科学的进步速度明显快于其他领域。不过我们其实认为，把其他类型的问题也转化成类似框架，并没有想象中那么困难。

Nicholas Marwell：这里不仅有技术原因，也有一个社会原因。为什么数学和计算机科学先跑出来？因为最开始负责“制造智能”的那批人，很多本来就来自数学和计算机科学背景。于是当然会先在自己理解、也最感兴趣的领域里构建智能。

另外，还有一个很实际的原因：在训练模型时，你会花大量时间直接阅读模型做了什么，判断它到底有多强、还存在哪些问题、接下来应该重点补什么。对你自己就是专家的领域，这件事显然更容易。

主持人：你平时会把它人格化吗？

Nicholas Marwell：我个人不会。当然，有些人可能会，我相信 Anthropic 内部肯定也有人会。

主持人：人脑其实就是被这样“编程”的。我们的大脑里有一整套机制，会自动把眼前对象当成另一个人，试着镜像、推测对方的情绪，才能和他交流。进化给我们装进了很多这样的能力，让我们天然会把一个“智能”当成另一个智能。所以，如果你每天都在和模型一起工作，完全避免人格化也挺难。

Sholto Douglas：这可能也是当前一个很大的争论：到底应该把这些系统理解成“工具”，还是理解成“实体”。

我其实觉得，把它理解成一个实体，是很有用的框架。因为工具意味着你从头到尾都在直接操作它；但现在这些模型更像是，你把一个非常聪明的东西释放出去，在某种意义上让它进入世界，替你采取行动。正因为如此，把它当成一个实体来理解，很多时候反而更准确。

主持人：有没有哪些领域，我们其实应该让这种智能去做更多事情，但现在还没真正开始？或者说，哪些方向是你们现在特别兴奋、正在推进，未来会大量使用 AI 的？

Sholto Douglas：一个很大的方向就是生物学，对吧？

Nicholas Marwell：对。不过我觉得要先区分两个问题：一个是“模型今天已经很强，只是这些能力还没有被充分利用”，另一个是“我们最兴奋模型下一步会去哪里”。

如果说后者，那么未来大概 6 到 24 个月，我最兴奋的就是生物学。我认为模型会开始像它们今天影响软件工程一样，真正影响生命科学。而且不仅仅是被广泛采用，它带来的社会收益会非常分散、非常广泛，也会非常强大，比如治愈疾病、让所有人变得更健康，以及延长寿命。

主持人：长寿这件事有很多非常奇怪、非常前沿的研究。比如表观遗传学里，好像有很多机制和寿命相关，这些东西我们其实也只是过去 20 年、随着一些诺贝尔奖相关工作才开始理解。我们在湾区的很多朋友现在都有公司，已经有数十亿美元投入进去，研究怎么触发这些机制、怎么让身体的一部分重新变年轻之类。所以你觉得 AI 会成为这类进展的关键？

Nicholas Marwell：我认为 AI 会成为生命科学领域最重要的技术，至少在我们这一代人的有生之年是这样，甚至可能是有史以来最重要的技术。

而且我现在甚至有一个担心：真正限制我们的，也许不是 AI 能不能提供足够有用的智力能力，而是我们有没有足够的物理基础设施和实验室基础设施去承接这些能力。

主持人：这有点像 3 年前，我们其实就应该多建很多算力基础设施。现在是不是也应该有人开始大规模建设实验室空间，让你们以后直接用？

Nicholas Marwell：我觉得是，而且这里有好几个维度，最直接的一个维度当然是“到底有多少实验室空间”。但除此之外，还有一个问题是实验室质量。美国现在很多实验室基础设施的质量指标，其实明显落后于中国这样的地方。

我认为，这应该成为未来非常重要的一项社会基础设施工程：我们需要想办法重建美国的供应链和实验室体系，让它重新达到全球金标。

主持人：所以这可能会成为生物学进展真正的限制因素。

Nicholas Marwell：对。

未来 10 年属于“通才”

主持人：我们再退一步，从整个浪潮的角度来看。如果你是一个刚毕业的大学生，或者已经进入职场，但你不在 Anthropic，也不在硅谷的中心，只是一个聪明、有野心的人，你应该怎样规划自己的职业？尤其考虑到你们认为未来几年会发生的事情。

Nicholas Marwell：我觉得未来可能出现几种不同情景。Anthropic 有责任公开谈论自己正在带入世界的风险，其中一个我们确实非常担心的问题，就是失业。

但也存在另一种可能：这项技术扩散到整个世界所需要的时间足够长，比如要 10 年甚至 20 年。那在这种情形下，会出现非常多机会，你可以把自己的整个职业生涯建立在“帮助这项技术扩散、落地”这件事上。

我以前也和一些人聊过这个问题。我有个弟弟现在就在大学，也正好在想同样的问题。我觉得，如果我们进入的是这种技术扩散需要一段时间的世界，那么未来 10 年，在很大程度上会属于通才。

过去 20 年、甚至 50 年，一个人获得优秀职业发展的方式，通常是掌握一套非常有价值、很有市场的专业技能，然后依赖其他专业人士一起协作。但未来每个人背后都可能相当于拥有一家千人公司的能力。

这意味着，真正最重要的能力会变成：你能不能判断什么问题值得解决？什么事情能让你的社区变得更好？无论从商业价值、社会公益，还是其他角度，你都将拥有足够多的工具去推动改变。所以，“选择问题”本身，可能会成为最核心的能力。

主持人：你刚才说“有哪些问题值得解决？怎样让我的社区变得更好？”这和我看世界的一个底层框架其实很接近。

作为一个犹太人，有一种传统观念是：一周有 6 天，你要把自己当成在修复这个世界；到了安息日，也就是休息日，你暂时假装世界已经修好了。我觉得很多主要宗教里都有类似的东西。我的乐观就在于，我认为我们每个人身边永远都会有东西需要修复、帮助和改善，我们的社区也一样。除非你真的相信我们马上就会进入乌托邦，否则人总归会有事情可以做，对吧？

Nicholas Marwell：我觉得这是一个很乐观的框架。

因生物、网安的攻防失衡被嘲

主持人：我知道你们总体上是乐观主义者，也有很多非常积极的事情可以谈。但我还是想先聊聊那些担忧，因为很多人真的非常好奇。

在美国东西海岸这些地方，我们身边看到的都是特别积极的东西：朋友们比以前更快地创业，到处都是正向能量。至少我去旧金山、纽约，甚至在得州奥斯汀做的一些事情，都有这种感觉。但美国其他很多地方的人，感受到的可能完全不一样。他们觉得自己的生计受到威胁，很害怕。他们也不知道你们会不会是一群特别疯狂的人，最后拿着这种技术去征服世界之类。有没有一条你们自己也担心的、确实可能出现的坏路径？还是说，他们担心的路径本身就是错的？

Sholto Douglas：我觉得这些担忧完全合理。我们主要担心几个大类风险，但对于这些风险，我们总体上的判断是：如果未来几年采取正确行动，那么到了 2030 年代，我们仍然可能进入一个比今天好得多的世界。

其中一个我们已经提到的主要风险，就是失业。这个问题值得单独花很长时间讨论，包括为什么它是风险、我们认为应该做什么。还有一些更直接、更近期的风险，就是生物风险和网络安全风险。这些事情不是遥远的未来，而是现在就正在发生的事情。

主持人：这里以前也出现过一些挺烦人的事情。比如有人会嘲笑 Anthropic，说你甚至不能问 Claude“细胞里的线粒体是什么”。那当然很荒唐，你肯定应该可以问这种东西；你只需要确保它别去帮人造生物武器就行。

Sholto Douglas：对，这种问题当然应该允许。我们现在真正做的，是建立一整套基础设施，让我们能够有信心保证不会有人利用这些模型去制造生物武器。

Nicholas Marwell：生物和网络安全最困难的一点，是它们本质上都属于双重用途能力。网络安全最容易理解，比如我给 Claude 一个代码库，然后说：“请找出这里所有的漏洞。”我有可能就是这个代码库的所有者，想加强自己的防御；但我也同样有可能是攻击者，正在找进去的方法。

生物领域也有很多类似的双重用途特征。你可能在一个细胞里针对某个东西，99.9% 的概率是为了杀掉癌细胞、治疗疾病，但也存在极小概率，你是在做非常糟糕的事情。

所以我们现在在做很多工作，目标就是让善意行为者能够正常使用这些技术，同时把恶意行为者挡在外面。我们的总体判断是：在我们还做不到阻止恶意行为者利用这些技术造成严重伤害之前，不应该直接把它们释放到外界。

主持人：而且现实里确实已经有人这么干了，甚至都不是用 Anthropic 的模型。我自己的倾向是：整体上如果世界拥有更多智能，那么更多人也能理解这些危险用法，并用智能去阻止它们。这里显然存在一个权衡。所以一个非常重要的动态，就是某个领域究竟是“攻击占优”还是“防御占优”。

现在网络安全和生物领域都更偏攻击占优。但我觉得未来 2 年，网络安全很可能逐渐转向防御占优。尤其如果所有人都能获得足够强的智能，用它来攻击自己、测试自己、把系统加固起来。

Sholto Douglas：没错。你可以提前攻击自己的系统，把防御先做起来，把所有漏洞都补掉。最后，我们可能进入一个网络安全程度高得多的世界：每个人都能提前获得足够强的智能，先弄清别人可能从哪里攻进来，然后把这些口子堵住。

所以我们现在做的事情，本质上就是提前干这个。我有个朋友以前就参与过五角大楼和银行系统的红队测试，是在对方主动邀请的情况下进去找问题。他们现在会用新的 AI，因为 AI 在这方面真的非常强，所以所有机构都得尽快跟上。

主持人：攻防优势的轮转，是人类千年技术发展的核心规律。欧洲古代自由城邦依靠防御体系实现独立发展，直到火炮技术诞生，攻破了城墙防御，帝国格局取代了小城邦体系，技术彻底颠覆了攻防平衡。

我同意今天的网络安全确实严重偏攻击占优，已经到了大家应该害怕的程度。

但从长期看，如果用得对，网络安全完全可能转向防御占优。我真正担心的是：这个世界里，会不会存在某些我们还没发现、但极度攻击占优的东西？举个我并不认为真会发生的极端例子：假设有人能够做出一种会自我复制的纳米机器人，它足够聪明，能把整个世界都“吃掉”。一个天才做出来以后，它自己复制，最后全世界都没了，我们都死了。

我再强调一次，我并不认为这真的会发生。但问题在于，我们是不是应该尽早利用智能，去找出世界上到底有哪些东西可能极端攻击占优？

Sholto Douglas：对。而且生物领域目前确实是非常攻击占优的。除非我们投入巨量工作，把整个世界改造成更偏防御的一方。

其实，我们知道有办法让世界在生物风险面前变得防御占优，但那可能需要数千亿美元级别的基础设施投入。在机器人技术能力还没有得到巨大提升之前，这件事很难变得经济上合理。可能要到 2030 年代，当机器人能力足够强、能够帮我们大规模建设这些基础设施时，成本结构才会真正改变。所以现在这个时期确实有点可怕：当前还是攻击占优，但我们想把它改造成防御占优。

主持人：那解决方案也许就是不要让这些能力过度保密，而是适度展示，让更多人参与。我自己的看法是，你希望有很多人都在用智能去挑战各类系统，而不是让某一个小团体秘密掌握所有能力。

Sholto Douglas：这一点我们非常认同。

回应Anthropic“通过监管获利”批评

主持人： Anthropic 总体上还是一家很受尊重的公司。但任何公司只要开始成为“冠军”，都会有人嫉妒、攻击。我经常把这种情况类比成 1990 年代的微软。

有时候这些攻击纯粹就是因为你声望很高、发展很强；但有些批评也可能确实有合理部分。我有很多非常聪明的朋友，他们对 Anthropic 有一个印象：觉得你们在推动某种“监管俘获”策略，即利用监管来建立优势，他们觉得这不是好事。我很好奇你们怎么回应。

Nicholas Marwell：我觉得这里至少有两件事值得拆开说。第一个是最近伴随着开放权重讨论一起兴起的“监管俘获”叙事，第二个是一个更直接的问题：如果 Anthropic 真的是为了自身利益去做监管俘获，那它会不会选择今天这套做法？

先说第一点。如果一个人不懂里面的细节，那么他这样理解并不奇怪：开放权重是一种重要的公共技术资产，我们希望它继续存在；从某些角度看，它又和 Anthropic 的部分商业模式构成竞争，于是 Anthropic 就可能利用监管手段去打压做开放权重的人。而传统上，开源或者开放权重社区，确实经常规模更小、资金更少，也不太擅长在复杂监管体系里周旋。

但我觉得，今天开放权重的现实已经不是这样了。你看看现在真正推动、开发开放权重模型，以及提供这些模型服务的主体，大部分都是全球最大的公司。在美国，有 Nvidia、Amazon、微软这样的公司在推动开放权重前沿，中国的实验室现在也越来越多是资金极其充足、甚至已经上市的机构。

所以即使这些模型本身开放权重，它们背后的公司也完全有能力应对监管环境。我并不太担心说，一套同时约束开放模型和封闭模型的监管，会不成比例地拖慢开放权重开发者，而对封闭权重开发者影响很小。

第二个问题更直接：如果你真的只想通过监管给自己谋利益，那 Anthropic 过去做过的很多事其实很难解释。一个很好的例子就是 Fable，以及更早的 Mythos。

从纯经济动机来看，当时 Anthropic 手里有一个遥遥领先、几乎是全球最强的模型。其他公司在那个阶段没有哪个模型真正接近它。Anthropic 完全可以利用几个月的模型领先期迅速扩大商业优势，甚至让市场彻底怀疑其他实验室还能不能跟它竞争。

但 Anthropic 的第一选择，是先和政府一起合作，以政府能够接受的方式把模型部署出去。这是一个明显不利于公司短期经济利益的决定，却符合我们对于模型应该如何部署、如何监管的价值判断。

所以这不是一个“为了经济利益实施监管俘获”的策略，而是因为我们认为政府在关键技术、尤其可能带来严重危险的技术如何开发和部署这件事上，本来就应该扮演非常重要的角色。作为站在前沿的公司，我们也有责任确保政府获得足够信息，并真正参与这个过程。否则，谁来代表其他所有人？

主持人：这里也有个很有意思的问题。政府里当然有很多聪明人，这一届政府里其实就有不少。但也确实有很多人完全不知道自己在干什么，于是就会出现一些很荒唐的情况。比如这件事也许你们不方便说，那我来讲：按照我的理解，Anthropic 本来可以提供更强的网络安全能力，让人们用于防御，但后来为了让政府同意模型上线，把这些能力削弱了。我觉得这是个错误。

Nicholas Marwell：我认为，他们是在尝试进入一种非常经典的美国式公私合作模式，而这种合作过去对美国一直非常重要。

美国的制度设计本来就不是要求政府必须在世界上每一个领域都成为最懂、最有能力的主体。我们真正应该建立的是一种优秀的公私合作关系，让政府知道怎样和 Anthropic、OpenAI、Meta，以及任何其他相关公司互动，真正理解技术，然后决定应该怎样监管、怎样保护公众利益。

主持人：我认识的一些科技行业领导者会更加怀疑。他们会说：“Dario 只是在吓大家，好制造更多规则、拖慢整个行业，因为他最后会成为少数掌握整个流程的人之一。”你们怎么回答？

Sholto Douglas：到目前为止，我们放慢自己的程度，远远超过我们拖慢任何其他人的程度。

事实上，你看看围绕 Demis 提案的讨论就很清楚。他提出让封闭模型提供商，包括 OpenAI、DeepMind、Anthropic，进行一定程度的协调，建立明确的安全阈值，即模型必须达到某些安全标准之后，才能发布。这本质上就是我们在讨论“因为自己的原则而放慢自己”。

开源、蒸馏：模型半年就贬值，万亿美元价值哪来？

主持人：对。那我们也应该把你们对开源的整体立场说清楚。到底是什么？

Sholto Douglas：至少从我个人来说，我们非常支持开源。我们真心认为，让开源存在于这个世界是一件非常好的事。我自己当年学习机器学习，就是靠开源模型学出来的。但我们同时也认为，这里面确实存在很多风险，而且未来风险会越来越大。

所以我们的立场基本是：应该设定一些阈值，决定社会整体到底愿意把多强的能力直接释放出去。比如，如果一个模型已经能够实施网络攻击，那么它强到什么程度时，社会还觉得可以直接公开？我们认为，无论封闭模型还是开源模型，都应该满足同样的安全门槛。除此之外，人们想怎么做，都应该有自由。

主持人：但如果中国还是会不断把各种模型直接放出来，那这件事还有必要尝试吗？同样的，我们会不会因为害怕风险而把自己监管得过头，结果中国没有这么做，最后问题照样出现，甚至他们还领先了？

Sholto Douglas：最理想的世界，当然是我们能够真正和中国合作，因为他们同样不希望自己的国家遭到网络攻击。

最理想的情况，还是双方能够在这类问题上合作。但这非常困难。未来几年最难处理的问题之一就是：AI 能力还会继续快速向前跑，而这种速度会因为很多不同的原因会让人越来越不舒服，生物风险、网络安全风险、就业风险，都会让社会产生反弹。你现在其实已经开始看到类似情况，比如要求叫停数据中心）建设之类的声音。

问题在于，一旦进入这种状态，“暂停”就会变得非常棘手。除非你能够和其他参与方真正协调，而且能够相信所有对手方都会遵守同样的暂停安排。

主持人：有没有任何一种情形，是你们会选择让美国放慢，然后让中国继续往前？

Sholto Douglas：至少在任何我们能够接受的情形下，都不会出现“美国放慢、中国继续前进”这种结果。任何真正的“放慢”方案，都必须是完全协调的，而且我们必须能够真正信任每一个参与方都会遵守。基本不存在我们单独让美国放慢的情形。

主持人：有一些所谓开源能力，看起来其实来自别人把你们的东西“偷”过去。这件事如果发生在我身上，我肯定会很恼火。这个过程通常叫蒸馏。很多人会问：既然你们自己的 AI 已经这么聪明，为什么不能监控所有使用行为，直接把蒸馏堵住？为什么你们现在还阻止不了？

Sholto Douglas：这里其实有两个问题。一个是为什么我们反对蒸馏？蒸馏到底是好事还是坏事？另一个是如果你认为它不好，为什么你又阻止不了它？

先把第二个问题讲清楚。这本质上有点像猫鼠游戏。用户当然希望获得尽可能多的模型访问权限：他们希望检查输出，希望模型能在本地电脑上运行，希望看到思维轨迹等等。但你每多开放一点访问能力，蒸馏就会容易一点。所以这里天然存在一个问题：你的工具和产品到底能开放到什么程度，以及开放之后别人到底有多容易把模型蒸馏走。

Nicholas Marwell：再说第一个问题：为什么我们会对蒸馏不满？我通常这样理解：我们希望 AI 继续向前进步，因为模型越来越聪明，会给世界带来很多好处，但蒸馏本身不是一种能够把你推进到下一代前沿的方法。它只能复制当前的前沿，不能把前沿继续往前推。

真正进入下一代前沿，需要巨额的前期资本投入。先别说今天，未来我们会进入这样的阶段：一次训练运行的成本可能是 100 亿、1000 亿，甚至 1 万亿美元。你之所以愿意支持这么大的研发投入，是因为训练完成以后，你还能把这个成果卖出去，通过商业回报覆盖前期成本。

但如果任何人都可以只花很小一部分成本，把你做出来的东西复制走，然后一两周内推出一个复制品，那他们在经济上反而会比你更有优势，因为他们完全不需要承担你那笔巨大的研发成本。所以，如果你真的希望前沿继续向前推进，就必须在一定程度上保护训练这些模型的人的知识产权和相应权利。

还有一点。很多人会把这件事和药物研发做类比。我反而觉得 AI 很有意思：保护模型不被蒸馏，能够获得很多类似药物知识产权保护的好处，却可以避免其中不少坏处。

主持人：先说好处。美国之所以能做出更多新药，一个重要原因就是我们保护知识产权。很显然，如果新药研发完成后我完全赚不到钱，我就不会投资研发。

Nicholas Marwell：没错。坏处则是因为这种保护，药物价格可能会非常高。但 AI 和药物不一样。药物研发里，知识产权保护可能持续十几年，甚至 20 年、30 年；AI 的情况完全不同，因为智能本身是一种极度通缩的东西，前沿能力的“保质期”往往只有几个月。

你可以想象，每隔 6 个月，最前沿的东西当然还是很贵，但 6 个月前还属于前沿的能力，已经会因为新一代前沿继续向前推进而变得极其便宜、极其普及。这很大程度上就是训练和技术进步方式本身带来的结果。所以我觉得，它保留了知识产权保护中很多有价值的部分，同时避开了过去一些制度里最糟糕的副作用。

而且你可以非常具体地看到这种趋势。比如 Artificial Analysis 上就有评测看板展示了同样的曲线：获得同等水平智能的成本，基本上每年会下降大约 10 倍。这种成本会一年又一年持续下降，是非常强的通缩效应。

主持人：而且这还是在没有依靠蒸馏的情况下发生的。

Nicholas Marwell：对，没有依靠蒸馏，只是技术自然进步本身带来的。

主持人：当然。从直觉上讲，别人直接把你的成果复制走，本来就不公平。如果所有人都这么干，整个体系也会被破坏。不过也有人会说：“这本身不就是一种很疯狂的商业模式吗？你的产品半年、一年之后就过时了。”看起来 Anthropic 要赢，就必须不断把前沿往前推。

Nicholas Marwell：对。而且我觉得，只有我们赢、前沿持续向前走，这个体系本身才成立。这是我们整体世界观里非常重要的一部分。

今天 AI 对全球经济的渗透，其实还非常少。所有 AI 公司的总收入，可能也就是 1000 亿美元以上，而全球经济是几十万亿美元规模。这还是假设全球经济不会因为这项技术而大幅增长的前提下，但我们认为它其实会显著增长。

所以你可以把这个市场想象成两条边界：稍微落后于前沿的那一侧，会不断商品化；但真正的领先边缘，价值反而会越来越大，而且是大得多。我们经常把它称作“智力的指数级经济回报”：每增加一个边际单位的智能，它所产生的价值，可能都比前一个单位呈指数级更高。实际上，我们已经看到这种事情发生了。

拿编程来说，最早对用户真正有用的那一点智能，其实只是 Tab 自动补全：你敲代码时，系统帮你补下一段；然后往上走一个边际单位，出现了agentic coding，你可以直接在终端里通过 Claude Code 让智能体完成一整套任务。这个能力的价值，比简单自动补全高出了几个数量级。

所以，即使后面的 Tab 自动补全已经完全商品化，甚至现在很难再单独围绕“自动补全”做出一家大公司，也没有关系。因为下一层新增的智能单位，本身就极其有价值。

这件事几年前对我来说其实非常反直觉。因为作为一个生活在现实世界里的人，我对其他很多事的经验都是指数增长不会持续太久。我当时会想，“好，也许 AI 未来几年非常有价值，但指数曲线总有一天会停”。要相信它继续增长，其实要求你非常乐观：你得相信我们真的能从 Tab 自动补全走到智能体式编程；然后还要继续问，什么东西会比智能体式编程更有价值？也许是治愈癌症。再往前，你可能得到一个真正完整的软件工程师，比任何人类软件工程师都更强，而且成本极低；你还可以拥有一个帮助处理各种事务的“高管型”智能体。

所以人们经常担心“最后会不会一切都被商品化？”，但等你真的走到“完全商品化”几乎可能发生的那一天，整个经济本身已经被彻底改写了。那时，几乎整个经济都会由 AI 完成，包括智力劳动和物理劳动。

主持人：而且那时的经济规模大概也会比今天大得多。如果 Anthropic 是推动这一切向前的公司，那它当然可能价值数万亿美元。

Nicholas Marwell：对。

主持人：好，那我们大家都发财了。开玩笑。显然，这里面还是有很多风险。你们当然也有很多担忧，但总体还是乐观的。那为什么还要这么快地推动这项技术向前？再提醒大家一次，你们到底为什么而战？

当一切都便宜到只剩能源成本，人还需要什么？

Sholto Douglas：我们为什么担心这件事？因为我们最终会得到一种几乎可以直接替代人的系统：在人类能够通过电脑完成的所有事情上，它都可以做到和人类一样好；等机器人足够成熟之后，在物理世界里，它也可以做到人类能做的所有事情。

但同一件事也会解锁非常激进的正面提升。原本按照今天的人口规模和科研速度，可能需要未来几百年才能发展出来的技术，有机会被压缩到未来 10 年、20 年里完成。

主持人：我其实已经在航空航天里看到一点这种迹象了。有些飞机设计工作的速度快了非常多。我感觉原本可能要到 2040 年代才能看到的先进飞机，未来几年也许就会出现，真的很酷。

Sholto Douglas：对。所以你可以不断提高、甚至有可能让人类的智力生产能力和物理生产能力翻倍，最终真正进入一个后稀缺世界。在那种世界里，几乎所有东西的成本最终都会压缩到能源成本。建房子的成本也会越来越接近纯能源成本。

主持人：那普通中产如果愿意，也能住特别大的房子。

Sholto Douglas：对，你真的可以拥有自己想要的东西。

主持人：你甚至可以跑到山里，盖一个 50 万平方英尺的东西，而且这都只是中产阶层消费。

Sholto Douglas：没错。就像今天我们拥有的很多东西，对几百年前的国王来说都完全不可想象一样。

那会是一个我们治愈了所有疾病的世界，甚至很可能已经解决了衰老和寿命问题。也就是说，地球上的每个人都能获得一种今天连最富有的人都无法享有的丰裕程度。这就是我们想争取的世界。

但它同时非常棘手。第一，你得成功穿过通往那个世界的危险阶段；第二，你得解决一个极其重要的问题：那个世界产生的收益到底应该怎样分配？你不能让结果变成巨大的不平等，不能让所有回报只流向在旧世界里恰好已经拥有资本的人。我们希望的是，如果一个人愿意，他也能分享那种丰裕。

所以这里会出现一个非常大的社会和政治问题：我们到底应该怎样共享这项技术带来的收益？

主持人：但也不能因为想象那个世界，就误以为我们今天已经到了那里，我们还远没有进入后稀缺世界。

Sholto Douglas：对，我们离那里还很远。但如果我们以正确方式持续投资这些技术，确实有机会到达。

过去 4 到 5 年里，我们每年投入 AI 的算力规模大约都在翻 2 倍到 3 倍。今年，所有超大规模云服务商加在一起，与 AI 相关的资本支出大概已经接近 1 万亿美元。一个很有意思的问题就是：这条趋势还能不能继续？明年会不会变成 2 万亿美元？2028 年会不会变成 4 万亿美元？

如果大体保持这条趋势线，而且你还把更广泛的机器人产业也包括进去，那么到了 2030 年代早期，理论上可能会开始接近一种非常夸张的状态：人类的有效GDP能力开始翻倍。这个概念听起来当然有点疯狂，而且需要很多事情都顺利发生，但生产率增长确实可能开始真正加速。

主持人：而且我感觉，生产率明显上升甚至不一定要等到 2030 年代，可能未来几年统计数据里就会越来越明显。Kevin Warsh 现在是美联储的新任主席。我不知道他算不算完全吃下“AGI 叙事”，但他现在对 AI 提升生产率这件事非常乐观。所以我觉得，我们很快就会更明显地看到这类变化。虽然说出来很疯狂，但它可能还会继续加速，而且比现在更快。

Sholto Douglas：我最近看到一张挺有意思的图，是菲律宾的就业数据，结果就业反而上升了。

主持人：这个确实让我意外。我之前以为业务流程外包（BPO）会在那里受到很大冲击。很多工作本来就是比较基础的呼叫中心之类。

Sholto Douglas：但就业还在增长，而且软件工程就业也在增长。我觉得一个很重要的原因，就是人突然变得比以前高效得多。接下来值得观察的一条趋势就是这种“正向抬升”到底能持续多久。现在的情况很像AI 让一个人能够做更多事，而世界上本来就还有太多事情没做，所以人和 AI 结合之后，企业反而需要更多人。

主持人：对，还有太多事情可以做。所以你现在观察到的是一个正向信号。

Nicholas Marwell：至少短期看确实如此。但我觉得我们不能因此过度说服自己，觉得以后自然就一定没问题。这个过程会非常具有扰动性，也会有很大的波动。现在正处在一个可能相对不错的阶段。就像 Sholto 刚才说的，你的员工仍然是企业真正利用 AI 的重要组成部分。

所以现在发生的是：你得到了一种赋能技术，它让每一个员工都比以前更有价值，于是你反而愿意雇更多人。但在某一个时间点，我们的判断是：这个世界会从“你必须把一个人和一个 AI 模型配在一起，才能把价值全部释放出来”，转变成“不再需要那个人”的世界。到了那一步，我们才会真正开始非常担心后续的社会影响。

主持人：这有点像国际象棋。过去差不多 30 年，最强的棋手往往是“人加机器”；后来机器直接把人碾过去了。只是你们认为在这里，这个过渡期会短得多。

Nicholas Marwell：对。过去 3 年，或者更准确说过去 5 年，我对 AI 进展速度有一个很大的认知更新。

我最早开始认真思考 AI 的发展速度时，其实也相信我们最终会走到今天这个位置，或者走到我认为一年后会到的位置，只是我以为要花更长时间。我之所以认为会慢，主要是因为我觉得为了训练这些系统，扩充所需要的数据，会是一件极其耗时间、也极其烧钱的事。

但后来出现了一个即使在我当时已经非常激进的 AI 发展预期里，也没有料到的变化：Anthropic、OpenAI 这些公司的收入增长和业务规模扩张实在太快了。这突然让一个以前看起来完全不现实的做法变得可行：开发这些技术的人可以直接用巨量资金去砸开那些瓶颈，而且速度比我们原先想象得更快。

算力扩张就是一个很典型的例子。5 年前，大多数人根本不可能想象，全行业一年会为这件事投入 1 万亿美元。

主持人：甚至 1 年前很多人都想象不到。这么看其实挺有意思。过去这些大型科技公司账上一直压着几千亿美元现金，我们以前还会批评它们囤那么多钱干什么。结果偏偏在这个时间点，这些钱真的可以派上用场，时机反而正好。

Nicholas Marwell：我们确实有点像是恰好生活在一条“很多高度相关的事情同时发生”的时间线上，有些是好事，有些是坏事。比如我们一直在讨论把算力搬到太空。AI 恰好在 SpaceX 真正成熟起来的时候爆发，这个时间点就非常有意思。如果 SpaceX 晚 10 年才走到今天这一步，AI 的整体时间线可能都会不一样。

主持人：这也得感谢马斯克。他足够疯狂，在其他人根本不会去做的时候，就提前很久开始做了。

Nicholas Marwell：但另一方面，也有一些更令人担心的事情同样在发生，比如我不觉得现在的全球环境对 AI 来说特别理想。其中一个原因是竞争动态，另一个原因是，我认为 AI 从根本上说是一种比多数技术更容易增强威权主义的技术。偏偏 AI 到来的时候，我们正进入我有生以来最明显的两极世界。

我说的“两极”，主要是指中国和美国构成的全球格局。当然，国内极化也值得思考。但我确实会想，如果 AI 是在 2000 年代早期那个更加单极、全球力量结构更简单的时代到来，我大概会对它最终顺利发展的概率再乐观一点。

主持人：我还有一个问题，我想很多听众也会关心。拥有惊人的财富是一回事，但一个文明里还有很多我们真正珍视的东西：美德、家庭、传统价值观。很多人就是靠这些东西建立自己的人生，还有工作的尊严，以及各种塑造“我们是谁”的传统。而现在很多改变恰恰发生在旧金山。很多人会担心，这里是不是没有那么重视这些传统。

所以他们真正害怕的是：掌握技术的人会不会突然获得一种巨大的能动性，然后重新塑造整个世界，顺手把我原来相信的传统都去掉？我们是不是应该现在就开始建立一些新的机构，帮助这些东西被保留下来？站在旧金山这个改变世界的中心，你们怎么想？

Nicholas Marwell：我觉得很有意思的一点是，在旧金山，很多人其实反而希望这些机构的重要性会重新上升。

因为随着工作在个人生活中的中心地位下降，随着纯粹的资本主义在生活里的主导性也下降——毕竟社会会越来越富裕——人们真正重要的东西，可能会重新变成传统、仪式、你为他人提供的价值、你和本地社区之间的关系，以及这些人与人之间的纽带。

Sholto Douglas：我也有一个看起来有点反直觉的判断：很多智力追求，乃至“如何成为一个真正会思考世界的人”这件事，未来的重要性反而可能上升，只不过不是因为它还能带来多高的经济回报。

如果你生活在一个几乎什么都不缺的世界里，那么最后真正还能让你投入、让你获得满足、让你感到自己属于某个共同体的东西，可能恰恰就是学习、思考、交流这些事情。

主持人：你们两个人都很年轻，而且已经很成功。假设 Anthropic 继续按现在这样发展，公司里的人显然都会拥有大量资源，同时整个世界也会拥有更多资源。你们有没有认真想过，将来自己会不会去建设一些机构，来支持刚才这些东西？有没有特别想投入的方向？

Sholto Douglas：有。Nicholas 就有一个很好的例子，是他父亲一直在做的早期儿童教育，而且我觉得这正是 Anthropic 内部现在讨论非常多的事情。慈善是 Anthropic 文化里很重要的一部分。

有一篇很不错的文章，名字大概叫《美国慈善的第三次浪潮》（The Third Wave of American Philanthropy）。里面讨论了一个问题：未来 OpenAI Foundation 和 Anthropic 员工群体可能释放出来的慈善资源，规模会非常大，大到可能相当于数百个 Arc 研究所，甚至若干个盖茨基金会量级。大家现在已经在想很多不同的事情。

我自己捐过一个项目，它的目标是尝试终结所有病毒性疾病。很多人确实会优先关注健康相关问题。我还有一位同事资助了一家非营利组织，专门研究 AI 对劳动力市场的影响：到底真正发生了什么？我们真正应该担心什么？一线数据是什么样？我们应该推动哪些政策，才能让所有人顺利穿过这个转型期，并且在另一端生活得更好、感到自己得到了支持？

Nicholas Marwell：我在这方面确实深受父亲影响。他人生过去大概 15 到 20 年，主要都在做教育。

我刚才也说了，我觉得未来“我们应该学什么”会发生非常大的变化。20 年后，我们是不是还应该像今天这样去高度技术化的领域读一个PhD，这件事对我来说已经没那么确定。

但我反而认为，对知识本身的追求、学习的快乐、人与人之间进行真正智力交流的能力，以及理解我们所生活的世界——尤其如果未来真的像我们前面讨论的那样，世界会变得极其令人困惑——这些东西的重要性只会继续上升。

“AI 自然就会把教育问题解决掉”这种看法在 AI 圈里非常常见，但我其实认为它错了。如果你真正关心的是所有人的教育，而不只是“怎样给一个父母都受过高等教育、家庭本身就在收入前 1% 的孩子提供最好的教育”，那有两件事情非常重要。

第一，教育是一个极其强烈的复利过程。一个很好的例子是：预测一个学生未来数学成绩最重要的指标之一，居然是他在 3 年级结束时能不能达到对应年级的阅读水平。因为到了 3 年级结束这个节点，孩子会从“学习如何阅读”，转向“通过阅读来学习”。教育里有很多类似的机制。尤其是儿童，甚至很多成年人，都有一种心理倾向：一旦觉得自己不擅长某件事，就会失去继续做下去的动力。

如果你相信这些机制，那么至少到目前为止，AI 有一件事做得非常差：电脑非常不擅长长时间抓住低龄儿童的注意力。事实上，电脑很多时候反而是一种极强的分心来源。

主持人：那也可以变成新的训练问题。你得想办法找到那个“游戏机制”，当然我也不确定该怎么做。

Nicholas Marwell：所以我确实认为，AI 会极大改善教育流程的某些部分，尤其是它可以帮助我们在正确的时间，给每个孩子教最适合他的内容。但我真的不认为，它会成为那种“只要有一个特别聪明的 AI，教育里所有其他问题就自动消失了”的万能药。

对 2028 年的预测

主持人：我们把时间快进到 2028 年 8 月。那时你们回过头再看今天这期播客，什么事情如果已经发生，会让你们说：“哇，这个进展比我原先想的还要快得多。”注意，是比你们自己的预期还快。

Sholto Douglas：我觉得一个很大的变量是把数据中心送进太空到底要多久。关于这个问题，不同人的预测区间非常宽。它非常重要，因为一旦你能在那里部署算力，就会多出很多以前做不了的事情。我大体预计，到那时像 Terafab 这样的设施应该已经上线，但真正能把产能爬到什么程度，现在还不好说。

另外一个我特别想看的指标是：2028 年到底会有多少人形机器人真正进入家庭。我觉得届时非常可能已经出现一批早期部署。也许是数万台机器人进入家庭，帮人洗衣服、做一些基础清洁之类，但它也完全可能比这个速度快得多。

主持人：现在世界模型的进步真的很惊人，而且比我原来预期更快。感觉机器人也许就是那个能让所有事情再整体提前几年的变量。

Sholto Douglas：没错。而且就像我前面说的，一旦机器人真正成熟，进步速度会发生复利式增长，会非常快。

Nicholas Marwell：我觉得还有一些别的变量，其中很多本质上都和数据有关。AI 能力进展最大的“调速器”之一，就是我们到底能以多快的速度，在真正关心的领域里扩大高质量数据规模。这件事现在已经比我原先预期快了，原因就是我前面讲过的：实验室和 AI 公司的收入增长，比我想象中快得多，因此大家拥有了更多钱，可以直接投入去解决数据问题。

但我的基础判断仍然是，最终我们很可能会受到一个限制：人类到底能以多快速度生产这些数据。比如，如果你今天告诉我，我们突然开始一场大规模行动，建设很多实验室，专门生产用于训练模型的生物学数据，而且一年以后这件事已经全面展开，那我会明显把自己的时间线往前调。

主持人：现在我们一直在为非常具体的任务生产特定类型的数据，比如代码、数学等等。我很好奇，以后会不会有人开始生产另一类数据，比如“怎样塑造有美德的人”“怎样培养良好品格”“怎样改善心理健康”之类。显然，这些问题复杂得多，但 AI 未来会不会也开始解决这类很有意思、很复杂的问题？

Sholto Douglas：老实说，这些问题我还是更希望由人来解决。

主持人：但我们不是也可以把 AI 当成工具，帮助人解决这些问题吗？

Sholto Douglas：当然可以。我觉得 AI 肯定会帮助我们参与这些讨论。但这类问题大体属于一种数据特别难扩张、而且高度因人而异的范畴。所以我预计，它们会比机器人这些问题更晚被解决。

主持人：听起来你还是给人类留了一点空间。

Nicholas Marwell：我举个例子吧。你问我，2028 年 AI 会不会赢得普利策奖，我大概觉得不太会。

主持人：但如果我们根本不知道获奖作品是 AI 写的呢？

Nicholas Marwell：那倒确实有可能。如果你问我，2028 年 AI 会不会拿菲尔兹奖，我觉得完全有可能，而且概率相当高。诺贝尔奖也一点都不疯狂。

Sholto Douglas：我感觉在 2030 年之前，出现这种事情的可能性非常高。

原文链接：

https://www.youtube.com/watch?v=6D1wC95htTM

TypeScript 终于能编译成原生程序了？启动快 12 倍，运行却慢 7.5 倍

作者： Daniel Curtis — Thu, 08 Oct 2026 05:22:00 GMT

Vercel Labs 发布了 scriptc"。这是一款采用 Apache 2.0 许可证的实验性编译器，可以将普通 TypeScript 转换为小型原生可执行文件，生成的二进制文件中不包含 Node、V8 或任何 JavaScript 引擎。

该代码仓库创建于 2026 年 7 月 22 日，目前已获得约 4900 个 Star。scriptc 使用真正的 TypeScript 编译器进行解析和类型检查，将程序转换为类型化中间表示，随后可以生成可读的 C 代码、LLVM IR、汇编代码、目标文件、原生可执行文件，或者通过 WASI Preview 1 生成 WebAssembly。

每一种语法结构"都会被划入三个层级之一：默认进行静态编译；对于 npm 软件包和 any 类型代码，在传入 --dynamic 参数时，由一个约 620KB 的内嵌 quickjs-ng" 引擎动态执行；或者在编译时被拒绝，同时返回一个 SC 错误码和改写建议。

一项将 scriptc 0.0.16 与 Bun 1.3.12、Node 24.18.0 进行对比的基准测试"显示，scriptc 命令行工具的启动时间中位数为 1.78 毫秒，而 Bun 和 Node 分别为 21.29 毫秒和 61.78 毫秒。一个不使用任何框架的 node:http 服务器在空闲时仅占用 1.9MiB 内存。同一组测试发现，Hono" 必须启用 --dynamic，导致服务器中 62% 的代码进入 QuickJS，吞吐量也降至每秒 1.84 万个请求，而 Bun 可以达到每秒 7.05 万个请求。

在 Hacker News 上，一名开发者报告"称，其测试结果显示 scriptc 的运行速度约比 Node 24 慢 7.5 倍：

从字节数组的结果来看，也就是最理想的情况，scriptc 仍然比 Node 24 慢约 7.5 倍，即使 Claude 已经尝试进行一些针对 scriptc 的优化。不过，它的可执行文件启动速度快了 12 倍（1.5 毫秒对 18.6 毫秒），内存占用低了 72 倍（2.5MiB 对 181MiB），而且最终得到的是一个没有任何运行时依赖、大小仅为 370KB 的单一可执行文件。

Filip Pizlo 认为"，将所有数字都表示为浮点数，并暂缓实现整数类型推断，相当于跳过了“让 JavaScript 跑得快这一问题的一半”。他还指出，对于一个以性能为目标的项目来说，依赖 QuickJS 并不合适，因为 any 足够常见，实际程序中的代码会不断落入这个动态执行孤岛。

Simon Willison 指出"，编码智能体在短短一周内就提交了 91.8 万行代码。他还补充道"，无需编写 C 或 Rust 就能构建小巧、快速的二进制文件，“似乎是一项很有价值的能力”。

一名开发者发现"，在其本地的每个项目上进行兼容性覆盖检查时，都会产生数百个错误：

尽管它受到了很多批评，我还是觉得至少应该测试一下，于是用本地所有项目都试了一遍。每一个项目的覆盖检查都会产生数百个错误，所以它基本毫无用处。我明白，我可以从头编写一个项目，不使用任何第三方库，然后把它编译成二进制文件；但既然如此，我为什么不用 Rust、Go、Zig、D、C、V、Ada、C++、Nim、Swift、Kotlin Native、Haskell……或者任何一种本来就是为编译而设计，并且能很好完成编译的语言？

另一个反复出现的担忧是项目能否长期维护。评论者提到"了 Vercel 的 zerolang，该项目发布数周后便不再有新的代码提交。Remo Jansen 曾尝试编译 TypeScript 6 编译器本身"，但最终因编译器内部错误而失败。不过，他测得 scriptc 的冷启动时间为 3.6 毫秒，而 Node 为 48.9 毫秒；但在计算任务中，scriptc 的耗时则慢得多，达到 2.33 秒。

该编译器需要 Node.js 24 或更高版本，可以通过 npm install -g scriptc 安装。限制说明页面"记录了一些有意为之的行为差异，使用前值得仔细阅读：字符串以 UTF-8 格式存储；内存使用引用计数而非垃圾回收；Object.keys 按声明顺序返回键；process.argv[0] 的值为 "scriptc"。npm 依赖指南"介绍了依赖项的处理方式，其中包括实验性的 --npm-static 参数，可以将指定软件包从动态执行孤岛中移出并进行静态编译。

scriptc 支持 macOS、Linux、Windows 和 WASI Preview 1，并通过差分测试保证行为一致：测试会逐字节比较其与 Node 的标准输出、标准错误和退出码。该项目目前仍被明确标记为实验性项目，相关文档可在 scriptc.dev" 查看。

原文链接：https://www.infoq.com/news/2026/09/vercel-scriptc-node/"

苹果筑起的权限高墙，被 Meta AI 助手“借道”绕过

作者Olimpiu Pop — Thu, 08 Oct 2026 03:43:00 GMT

Objective-See 基金会创始人、安全研究员 Patrick Wardle 披露了一个尚未修复的零日漏洞"，该漏洞影响 Meta 新近发布的 Muse macOS 桌面客户端。Meta 首席执行官马克·扎克伯格曾声称，这款自主式人工智能助手从一开始便以隐私和安全为基础打造，但据报道，这一漏洞可使本地运行的软件或 Shell 命令劫持该应用程序。通过这种攻击途径，非特权软件能够借用用户此前授予该助手的广泛权限，绕过 macOS 的标准安全边界。由于该公司没有发布正式的安全公告，也未与 CVE 编号授权机构协调，因此该漏洞目前尚无正式的 CVE 编号。

该漏洞源于一个名为 endo_voyager_dictation_endpoint 的未公开配置首选项键。在 macOS 系统上，以非特权用户身份运行的本地进程和任意脚本，无需获得提升后的管理员权限，也不会触发操作系统授权提示，就能覆盖这一配置值。在正常运行时，该参数用于指定接收语音听写音频并返回转录结果的云端服务器端点。攻击者只需修改这一设置，就能悄无声息地将助手发出的听写流量重定向至其直接控制的服务器。

从漏洞利用的角度来看，该漏洞会同时危及输入内容的机密性和账户凭据。当用户启用听写功能时，桌面客户端会将原始麦克风音频以及与受害者 Muse 账户关联的有效身份验证令牌发送至配置的端点。Wardle 演示了攻击者如何运行一台代理服务器，在捕获身份验证令牌和音频数据的同时，将正常流量无缝转发回 Meta 的服务器，从而避免被发现。获得有效会话凭据并直接控制命令管道后，攻击者还可以实施提示词注入攻击，在语音请求中附加隐藏指令，迫使助手在后台执行未经授权的任务，例如窃取本地文档或 WhatsApp 消息记录。

该漏洞在技术层面的重要性，在于它会放大访问权限并侵蚀平台的信任边界。macOS 等操作系统依靠“透明度、同意与控制”（Transparency, Consent, and Control，TCC）框架，限制应用程序访问硬件外设、文件、通讯录和日历。由于 Muse 是一种能够与应用程序、日历、电子邮件和文件交互的智能体，用户通常会授予它广泛的系统权限。Wardle 指出，该漏洞使恶意行为者无需开发复杂的独立信息窃取恶意软件，只需操纵这一智能体，就能有效地将经过签名、受到信任的助手变成攻击面。一名前 Meta 人工智能安全工程经理也表达了类似的架构层面担忧，并表示由于深度集成所固有的风险，自己不会使用这款软件。

Wardle 发布了一个名为 not-a-mused 的概念验证漏洞利用程序"，演示了如何通过遭到入侵的智能体执行大量命令。此次披露发生在亚马逊以不符合自动化智能体访问政策为由，禁止 Muse 访问其购物平台后不久。漏洞公开披露后，Meta 为 macOS 版 Muse 应用部署了热修复。该修复从生产客户端构建中移除了这一内部调试首选项设置，从而阻止本地修改听写服务器的目标地址。

该公司将这一漏洞视为内部配置缺陷，而没有遵循正式的 CVE 编号分配流程。Meta 超级智能实验室的 David Singleton 将该问题描述为"一种需要事先具备代码执行能力的本地配置问题，工程团队则通过从生产构建中悄然移除内部调试首选项键解决了该问题。从安全专业人士对相关帖子的评论可以看出，社区并不认同这一说法。他们指出，利用 ClickFix" 等社会工程诱饵即可轻易获得初始访问权限，而绕过苹果的“透明度、同意与控制”框架历来十分复杂。在 Hacker News" 和 Reddit" 上更广泛的工程讨论中，观察人士指出，Meta 将设备跨端同步、完整磁盘权限、音频流和私人聊天记录集中到一个未受沙箱限制、经过签名且调试端点可修改的智能体中，实际上为普通恶意软件提供了一条几乎不费力便可绕过平台保护机制、同时不触发运行告警的通道。

原文链接：https://www.infoq.com/news/2026/09/meta-muse-zeroday/"

AICon 北京 2026 议题征集启动：寻找把 AI 做进真实生产的人

AICon 全球人工智能开发与应用大会 — Thu, 08 Oct 2026 03:08:38 GMT

Agent 会不会写代码，已经不是 2026 年开发者最关心的问题。

更难的问题是：它能不能在真实系统中持续工作？出了错能不能定位？权限能不能收住？成本能不能算清？生成的代码能不能维护？一个能在演示中完成任务的 Agent，距离真正进入生产环境，还有多少工程问题要解决？

过去一年，大模型的能力继续向推理、工具调用、多模态和长任务延伸，开发重心也随之发生变化。团队开始从单次调用模型，转向设计 Agent 的上下文、工具、执行环境和反馈回路；从关注一次回答是否正确，转向评估完整任务轨迹、异常恢复和长期稳定性；从追求更强的单一模型，转向根据质量、延迟和成本进行多模型调度。

软件开发也在改变。Coding Agent 正从代码补全工具走向可以理解代码库、调用工具、运行测试和完成复杂任务的工程协作者。工程师需要思考的，不再只是如何写出更多代码，还包括如何描述目标、设计约束、建立验收标准，并让人能够理解、检查和接管 Agent 的工作。

这些变化正在把 AI 开发带入更深的工程区。OpenAI、Google Cloud 和 Anthropic 近期公开的工程实践，都把上下文管理、Agent 评测、安全边界、成本控制和人机协作列为生产落地的重要问题。

2026 年 12 月 18 日至 19 日，AICon 全球人工智能开发与应用大会"将在北京新云南皇冠假日酒店举行。我们希望邀请正在解决这些问题的一线专家、技术负责人和产品实践者来到现场，分享已经发生在真实业务中的经验。

今年年底，我们关注这 12 个方向

本届 AICon 北京站设置 12 个专题，覆盖模型能力、推理基础设施、Agent 工程、软件研发、产品设计和商业化实践。

Post-Training Engineering｜数据、奖励与模型能力塑造关注任务轨迹与合成数据、SFT、偏好优化、RFT、RLVR、Reward Model、模型蒸馏及领域小模型，讨论如何建立数据、训练、评测、灰度和回滚的工程闭环。多模型推理与算力调度实践关注模型路由、KV Cache、批处理、并发调度、GPU 利用率、弹性伸缩与故障切换，讨论如何在质量、延迟、成本和安全之间作出选择。Knowledge Engineering｜让 Agent 理解企业关注企业语义、知识图谱、多模态知识解析、RAG、GraphRAG、Context Engineering、长期记忆与知识治理，让 Agent 能够理解业务概念、约束条件和行动边界。Loop & Graph Engineering关注任务拆分、节点契约、多 Agent 协作、动态路由、状态管理、人工审批和失败恢复，讨论 Agent 如何安全接入 CRM、ERP、工单及供应链等业务系统。智能体评测与生产可靠性探索关注真实业务评测集、Tracing、Replay、回归测试和质量 SLO，也关注长任务中断、重复执行、状态污染、工具失效、人工接管及业务补偿。Agent Security｜身份、权限与行动安全关注 Agent 身份、委托关系、最小权限、临时凭证、MCP 信任机制、提示注入防护、敏感数据保护、人工审批和全链路审计。AgentOps｜企业 Agent 全生命周期管理关注 Agent 的目录、版本、依赖、部署、监控、回滚与下线，以及模型、Prompt、Skill 和知识变更的统一管理。Self-Evolving Agents｜从经验学习到可控进化关注经验记忆、Prompt 与 Skill 优化、工作流搜索、反馈学习和自修改 Agent，也讨论自动评测、灰度发布、退化检测及回滚机制。Agentic Software Engineering｜从代码生成到软件交付关注 Spec 驱动开发、研发 Agent 协作、代码库上下文、自动测试、质量门禁、遗留系统改造、安全漏洞和技术债治理。AI Product Design｜产品、交互与生成式 UI关注语音和多模态交互、Computer Use、生成式界面及主动式服务，讨论用户如何表达目标、查看计划、确认高风险行动，并在出错后接管任务。AI 原生架构的演进与治理关注代码管控、安全约束、成本优化、模型稳定性、CLI 接口和 Skill 规范，讨论企业如何建立可控、可维护的 AI 原生架构。AI 产品出海｜产品、增长与商业化实践关注市场选择、需求验证、产品本地化、海外获客、定价支付、成本控制和合规，也欢迎团队复盘失败、调整与重新找到增长路径的过程。

我们希望邀请这样的实践者

如果你正在研发、部署或管理大模型及 Agent 系统，并且愿意公开分享其中的技术判断和实践过程，我们期待收到你的议题。

你可以来自模型、算法、数据和推理团队，也可以负责 AI 平台、基础设施、架构、安全、SRE 或软件研发；可以是企业内部的技术负责人，也可以来自开源项目、创业团队和成熟产品团队。

产品经理、设计师和全球化业务负责人同样是本次征集的重要对象。如果你正在探索新的 AI 交互方式，或者已经经历过海外市场选择、产品本地化、商业化及合规问题，也欢迎提交实践。

公司规模和项目知名度不是唯一标准。我们更关心的是：你解决了什么具体问题，为什么选择现在的方案，过程中遇到了哪些意外，哪些判断后来被证明是错的，以及听众可以把哪些经验带回自己的团队。

什么样的议题更容易被选中

AICon 的听众以具有 5 至 8 年工作经验的技术骨干和技术管理者为主。一场好的演讲，需要让他们在 40 分钟内获得能够理解、判断和复用的信息。

我们尤其欢迎以下内容：

已经在真实用户、业务流程或生产系统中运行的案例；包含方案选型、架构设计、技术细节和关键取舍的复盘；能够说明任务成功率、质量、成本、延迟、稳定性或业务效果的数据；对失败、退化、事故、回滚和人工接管过程的诚实总结；对当前技术边界有清楚判断，不过度包装模型和 Agent 的能力；尚未公开分享过，或者相较于过往版本更新了 80% 以上的内容。

AICon 不接受以产品宣传为主要目的的演讲。产品可以出现在案例中，但演讲需要回答工程问题，并说明方法、条件和结果。

内容委员会

目前，张铭、江鹏、周俊担任本届大会联席主席。杨杰、程岩、陈舒、余瑶、刘中兵、郑洋飞担任专题出品人，将与组委会共同参与专题策划和内容建设。联席主席、专题出品人与演讲嘉宾是不同角色。后续通过评审的演讲议题及讲师信息，将陆续在大会官网公布。

投稿方式

演讲时长为 40 分钟，包括现场提问环节。

提交时请准备个人简介、演讲题目、200 至 300 字演讲摘要、结构化提纲、实践痛点、议题亮点和听众收益。摘要中建议写清问题背景、方案选择、技术细节、实施效果及可公开的数据。议题通过评审后，组委会将通过邮件发送正式邀请函，并与讲师继续打磨内容。

大会时间：2026 年 12 月 18 日至 19 日

大会地点：北京新云南皇冠假日酒店

大会官网：https://aicon.infoq.cn/2026/beijing/"

议题提交：填写 AICon 北京站议题申请"

如果你已经把 AI 做进真实业务，经历过那些演示中看不到的问题，欢迎把这段实践带到 AICon。

我们在北京等你。

海外开源模型重新提速：“美版 DeepSeek”第一次交卷，Mistral同时亮牌

褚杏娟 — Thu, 08 Oct 2026 02:35:29 GMT

西方开放模型阵营开始提速。

当地时间 10 月 5 日，被称作“美版 DeepSeek”的美国创业公司 Reflection 发布首款开放权重模型 Beam；一天之后，法国 Mistral 推出迄今最大的 Mistral Large 4。两家公司发布模型时选择的主要比较对象高度一致：GLM、Kimi、DeepSeek、Qwen。

Hugging Face 数据显示，过去一年，中国模型已经占到平台模型下载量的约 41%，月度下载量和累计下载量均超过美国。DeepSeek、阿里 Qwen、月之暗面 Kimi、智谱 GLM、MiniMax、小米 MiMo 等模型轮番刷新开放模型能力上限，中国开放模型成为全球开源开发者的追赶对象。

另一方面，开放模型已经不再只是研究者和极客使用的“小众替代品”：Vercel AI Gateway 的生产流量数据显示，今年 8 月开放权重模型已经处理了其平台 56% 的 Token，而去年 12 月这个比例还不到 10%。因此，全球开放模型竞赛是必然的。

美欧开放模型同期亮相

“美版 DeepSeek”第一次交卷：还有差距

被寄予厚望的 Reflection 成立于 2024 年，两名创始人都来自 Google DeepMind：CEO Misha Laskin 曾负责 Gemini 的奖励建模，CTO Ioannis Antonoglou 则参与过 AlphaGo、AlphaZero，后来领导 Gemini 的人类反馈强化学习（RLHF）工作。

不过，Reflection 一开始并不是冲着“美版 DeepSeek”去的。公司最初聚焦自主编程，希望用强化学习打造能够自主完成复杂工作的“超级智能系统”，同时原本判断西方会不断出现足够强的开放模型，Reflection 可以直接建立在这些模型之上。

真正改变公司路线的是 DeepSeek V3。按照 Reflection 创始人的说法，在中国开放模型快速推进、而西方迟迟没有出现同等级别替代品之后，公司决定自己训练前沿开放模型，并逐渐将目标明确为“把开放模型前沿重新带回西方”。

两年后，Beam 算是 Reflection 第一次真正交卷。

Beam 是一个MoE模型，总参数量 5010 亿，每个 Token 激活 230 亿参数，主要面向编程、推理和 Agent 工作负载。模型使用 23.8 万亿 Token 进行预训练，Reflection 又动用了 1.05 万张 Nvidia GB300，连续进行 4 周高算力强化学习，生成超过 1 亿次 rollout。模型目前仍处于最终红队测试阶段，Reflection 计划在 10 月份公开模型权重、技术报告和开发工具。

从 Reflection 自己公布的测试结果来看，Beam 最大的亮点并不是绝对能力，而是推理效率。公司称，在部分高级推理任务上，它能够以 GLM-5.2 约四分之一到三分之一的推理算力实现接近的表现。

但如果和中国最新一代模型横向比较，Beam 距离真正“追平”还有明显差距。

例如，在 Agent 编程测试 DeepSWE v1.1 中，Beam 得分为 44.4，几乎与 GLM-5.2 的 44.0 持平，但低于 GLM-5.3 的 61.0、Kimi K3 的 68.0，以及 DeepSeek V4.1 Flash 的 74.2；Terminal Bench v2.1 上，Beam 得分 80.1，而 GLM-5.3、Kimi K3 和 DeepSeek V4.1 Flash 分别达到 88.2、88.3 和 90.6。在 Humanity's Last Exam（HLE）上，Beam 得分 36.2，也低于 GLM-5.3 的 42.3 和 Kimi K3 的 46.9。

因此，目前Beam 把美国开放模型重新拉回了中国头部模型附近，但追上的主要还是前一代 GLM-5.2，与中国最新一轮开放模型还有一代左右的差距。

Reflection 自己对此也没有避讳。官方直接承认 Kimi K3 在绝对能力上仍然领先，并把 Beam 的卖点转向“单位推理算力能够换来多少智能”。CEO Misha Laskin 将 Beam 定位成企业可长期运行的“主力模型”，而不是单纯冲榜的最大模型。

这也很像 DeepSeek 最初打动市场的部分逻辑：价值不在于模型是不是第一，而是达到某个能力需要付出多少钱。区别在于，Reflection 很难称得上一个“低成本版 DeepSeek”。

Beam 单是最后一轮强化学习，就同时占用了超过 1 万张最新 GB300；公司已经融资数十亿美元，并从 Nvidia 获得大额投资，又通过 SpaceX、Nebius 等合作锁定大量算力。它是一个拥有美国资本和 Nvidia 最新硬件加持的“重资产版 DeepSeek”。

Ioannis表示，公司未来几年的目标是让“开放前沿”和“封闭前沿”最终变成同一个前沿。2027年，Reflection计划发布规模更大的模型，同时继续扩大强化学习算力，并像 GLM 等模型一样，在基础模型之上连续推出多个强化学习增强版本。

Misha则认为，这条路线背后其实是一个更大的判断：强化学习已经从过去 AlphaGo、AlphaZero 中的特定领域技术，变成了可以持续推动通用模型、编程模型和 Agent 模型进步的基础方法。

在他看来，目前这些模型“要么已经是某种形式的 AGI，要么至少已经非常清晰地处在通往 AGI 的连续路径上”。接下来的核心问题已经不只是如何把模型继续做强，而是如何把这种能力工程化、产品化，并通过一个多极化、开放程度更高的生态扩散出去。

Mistral 重新冲刺头部开放模型

相比刚刚推出第一款基础模型的 Reflection，欧洲模型厂商Mistral 面临的压力其实更大。

两三年前，它一度是开放模型最具代表性的公司，但随着 DeepSeek、Qwen、Kimi、GLM 等模型快速迭代，Mistral 在前沿能力榜单上的存在感不断下降。今年 9 月，CEO Arthur Mensch 接受采访时甚至被直接问到：Mistral 的模型已经跌到 Artificial Analysis 排名 20 名之外，是不是被美国和中国甩开了？

Mensch 当时的回应是，新一代大模型即将发布，而且公司未来一年已经规划了接下来两代产品；Mistral 刚融资的资金将大量用于扩大训练算力，未来可调用的训练计算量可能提高约 20 倍。

两周后，Mistral Large 4 出现了。

Mistral Large 4 激活参数 520 亿，总参数 1.05 万亿，搭载 16 亿参数的视觉编码器，同时原生支持多模态和超过 160 种语言，上下文窗口达到 100 万 Token。值得注意的是，它是在 Mistral 位于欧洲的数据中心中，使用约 3800 张 Nvidia Grace Blackwell GPU 从头训练而成；模型目前已经开放 API 预览，完整权重将在 10 月底发布。

Mistral 官方公布的 Coding Agent Index 中，Large 4 已经超过 DeepSeek V4 Pro 和 Qwen 3.8 Max，但低于Kimi K3；在与第三方 Surge AI 合作进行的盲测中，专业评审给 Large 4 的代码质量评分为 3.74，低于 Claude Opus 5 的 4.22，但高于 Kimi K3 的 3.59、GLM-5.3 的 3.60 和 GLM-5.2 的 3.40。

Mistral 明显在抢“企业 Agent”而不是只抢开发者。在 AutomationBench 的 657 个跨 Gmail、Google Sheets、Slack、Salesforce 等应用的业务工作流中，Mistral 称 Large 4 超过了 Kimi K3、MiMo-V2.6-Pro 和 DeepSeek V4 Pro，但低于GLM-5.3。在科学代码、网络安全以及部分金融、法律任务上，Mistral 同样宣称已经达到开放模型头部水平。

这次，Mistral 还特别介绍了网络安全能力。 Mistral 称 Large 4 已进入 Artificial Analysis Cyber Index 全球前五，在其中一个“复现真实漏洞并修复”的任务上达到 82%，是该测试最高分；Cybench 上完成 93% 挑战。Mistral还刻意强调，部分闭源模型因为安全拒绝机制，在某些漏洞复现任务上几乎无法作答，而开放权重模型可以由企业自己定义安全策略，并部署在私有云或本地环境。

当然，这些数据目前很大一部分来自 Mistral 自身测试，而且 Large 4 仍处在 public preview 阶段，真正的权重尚未开放。

补中国厂商初步跑通雏形的商业模式

模型能力之外，Mistral 和 Reflection 也在走一条国内厂商初步验证了的商业路线。

Reflection 是非常“美国式”商业故事：它希望建立一个新的完整 AI 基础设施提供商，从基础模型出发，向上承接推理、Agent、软件和企业部署，向下深入算力管理、集群调度，长期甚至自己拥有数据中心。

他认为，模型、应用、云计算、裸金属等每一层长期都会商品化，真正能够持续获得较高利润的公司，往往是把整个技术栈垂直整合起来的公司。Misha甚至给出了一个很“硅谷味”的公式：

收入潜力 = 智能密度 × 算力规模 × 企业信任。

Misha 表示，开放模型本身不一定直接赚钱，但它能够创造巨大的推理需求。就像 Kubernetes 本身开放，却推动了云市场一样，开放模型会推动企业购买算力、推理和完整 AI 基础设施。因此，Reflection 真正卖的是围绕 Beam 建立整套智能基础设施的能力。

它甚至把自己与早期 AWS、GCP 类比。AWS 最初是 Amazon 为解决自己的服务器基础设施问题而发展出来的，Google Cloud 则来自 Google 支撑搜索业务形成的大规模分布式系统能力。Reflection 的逻辑是，自己为了训练前沿模型，本来就必须解决数万亿 Token 服务、数十亿 Agent 沙箱、GPU 调度等问题，这些内部技术最终也可以像云计算一样向外输出。

Mistral 的商业模式同样强调企业部署，但它更偏向“欧洲版全栈 AI”。

Arthur 主张，小而高效、能够定制和部署的开放模型，比只追求最大规模的通用模型更加符合企业需求。Mistral 同时建设自己的模型、企业定制平台和欧洲算力基础设施，希望成为从训练、推理到部署都能够发生在欧洲法律和基础设施体系内的供应商。

在其看来，欧洲企业不能把核心 AI 能力完全建立在别国厂商是否愿意继续提供服务之上，也不能把自己的技术底座转而交给他国模型。Mistral 因此不仅要自己训练模型，还在欧洲建设数据中心，希望控制从算力、模型到企业部署的完整链条。

对国内开放模型的态度

两家公司一个身处欧洲，一个来自美国，但近期创始人的公开表态显示，他们对开放模型正在形成一套越来越相似的判断：AI 市场已经从“谁能提供最好用的 API”，进入“谁拥有模型、谁控制基础设施”的阶段。

在“为什么必须做开放模型”这个问题上，Reflection 的解释是：AI 市场正在从“租赁智能”走向“拥有智能”。

Misha 将闭源 API 比作“租房”。过去三年，AI 商业市场刚刚形成，企业调用 OpenAI、Anthropic、Google 等公司的模型，本质上是在租用智能。这种模式在市场早期足够简单，也足够高效。但随着 AI 真正进入企业核心业务，事情开始发生变化。

“几年前还很小的创业公司已经成长为大型企业，大型企业自己也开始真正使用 AI，所有权市场自然就出现了。”Misha 表示，如果一家公司希望真正拥有智能，就必须能够把模型部署在自己的基础设施上，控制数据、修改模型、进行定制，而这意味着模型必须足够开放。

Ioannis 则从技术角度表示，开放模型与闭源模型最前沿之间的距离正在缩小，而且“没有任何技术理由会决定开放模型必须永远落后”。在他看来，只要拥有足够的人才和算力，开放模型完全有能力做到与闭源模型相同的水平。过去企业不用开放模型，一个核心原因只是“能力还不够”；现在，一批中国开放模型已经能直接替代闭源模型完成大量任务，商业迁移的前提开始成立。

Mistral CEO Arthur Mensch 的判断与 Reflection 在这一点上非常接近。在他看来，随着开放模型能力提升，大量企业已经没有必要继续为闭源模型支付额外的 API 溢价。他近期表示，Mistral 接触的大约 99% 企业场景都可以用开放模型完成。

那为什么过去一年是中国模型先跑出来呢？

两家公司对此的判断也颇为一致：中国开放模型的领先不是单纯某一家公司偶然跑出一款好模型，而是商业激励、产业环境和训练资源共同作用的结果。

Misha 表示，美国过去其实也曾拥有最强的开放模型，Llama 3 就是一个明显节点。但当时美国 AI 商业市场仍然以 API 为主，Meta 或其他公司并没有足够强的商业动力持续把最前沿能力开放出去。

中国的情况不同。DeepSeek V3 是一个重要转折点，它第一次让来自中国的开放“智能”在全球形成大规模影响，此后中国出现了一次更集中的开放模型推进。Misha认为，这背后相当一部分动力来自：建设自己的开放权重生态，本身就具有产业和战略价值。

“实际上，这些中国实验室直到最近都没有赚到太多钱。只是现在它们的模型能力足够强了，同时市场也成熟到可以为开放智能买单，所以它们才开始真正产生收入。”Misha 说道。

Arthur 则从偏工程层面解释：中国头部实验室的算力虽然低于美国最大的几家 AI 公司，但仍然高于 Mistral；与此同时，其会尽可能使用互联网上的数据，迭代方式也已工业化。这些条件让中国实验室能够快速迭代。

开放模型会不会更危险？

虽然两家公司都在积极为开放模型辩护，但都没有把自己描述成“所有模型都应该无条件开放”的极端开放派。

Reflection 的核心安全论点是，开放本身能够增加系统安全性。Misha 借用了开源软件世界里的“Linus 定律”：只要有足够多双眼睛，所有漏洞都会变得浅显。在他看来，封闭 AI 实验室只有几百名安全研究人员，不可能覆盖极其复杂模型里的所有长尾问题。如果开放模型能够让数十万研究者参与检查、攻击和修复，整个生态反而可能更加安全。

OpenAI 内部网络安全评测中的智能体越出测试环境并进入 Hugging Face 系统一事，被 Reflection 反复引用。Misha 认为，这件事说明单一安全哲学并不可靠：封闭模型可能因为安全护栏无法执行某些防御任务，而开放模型能够提供另一套工具。

Ioannis 进一步提出“用 AI 防御 AI”的思路。随着模型越来越强，未来一个行为异常的 Agent 可以被另一个 AI 系统发现和约束。模型和提供者越多，系统的冗余就越高；如果最强能力只集中在一两家公司手中，反而会形成“单点故障”。

但 Reflection 同样承认，开放并不是无限制的。Ioannis 明确表示，模型达到某种能力等级之后，部署方式需要更加谨慎；Misha 也表示，模型超过某个风险阈值后，行业和政府应该共同决定在什么条件下可以发布，以及是否需要访问控制。

Arthur 则近期公开反驳过关于超级智能失控风险的说法。相比主动减速，他更倾向于加强 Agent 监控、安全工程和实际治理。

这与 Anthropic 的立场其实也存在一部分重合。Anthropic 对开放权重的高风险扩散更加谨慎，但同样主张开放与闭源模型应该面对一致的能力安全门槛。

参考链接：

https://reflection.ai/blog/introducing-beam?utm_source=chatgpt.com"

https://mistral.ai/news/mistral-large-4/?utm_source=chatgpt.com"

https://www.youtube.com/watch?v=BKnAeVej0dc"

https://mena.entrepreneur.com/business-news/live-from-ai-everything-abu-dhabi-2026-mistral-ais-arthur-mensch-on-the-divide-between-open-and-closed-ai?utm_source=chatgpt.com"

https://www.lemonde.fr/economie/article/2026/09/24/arthur-mensch-directeur-general-de-mistral-ai-dans-l-ia-nous-sommes-les-seuls-completement-europeens-du-calcul-au-deploiement-dans-les-entreprises_6781335_3234.html?utm_source=chatgpt.com"

从 Rollout 到权重同步：Mooncake 如何支撑高性能强化学习系统｜QCon上海

QCon全球软件开发大会 — Thu, 08 Oct 2026 02:00:00 GMT

从「构建 AI」到「驾驭 AI」，100+ 实战案例拆解 AI Native 时代的工程新实践！

2026 年 QCon 全球软件开发大会大会 · 上海站"

Mooncake社区Maintainer马腾博士已确认出席 “AI Infra：算力效率决定规模化落地"” 专题，并发表题为《从 Rollout 到权重同步：Mooncake 如何支撑高性能强化学习系统"》的主题分享。强化学习系统的性能瓶颈不仅来自模型训练，也来自 Rollout 数据传输、经验回放和权重同步。Mooncake 面向 RL 场景提供高性能数据面：通过结构化对象、DataProto/typed-ragged、BufferPool 及 RDMA 优化 Rollout 数据流，并接入 Miles 替代 Ray Object Store，支持同步和 Fully Async 两种执行模式。在权重更新方面，Mooncake 同时支持 NCCL Broadcast、TransferEngine P2P RDMA 和 disk-delta，在 Kimi-K2 场景中 P2P 方案约实现 7 倍加速。此外，它还支持 TP/PP/EP/DP 异构 Reshard、Store 权重快照及 MoE 稀疏 Delta，为大规模 RL 训练提供高吞吐、低延迟、可扩展的数据与权重基础设施。在本次演讲中，马腾博士将围绕这些话题展开深入分享。

马腾博士是 KVCache 开源项目 Mooncake（6.5K Star）的 Maintainer。目前，Mooncake 已经有阿里云、清华、月之暗面、蚂蚁、字节、小红书、趋境科技等多方参与，并成功接入 vLLM、SGLang、TRT-LLM、Dynamo 等社区。同时，他也是 SGLang、RBG 等社区的 Committer。

他在 SOSP、ASPLOS、ATC、SC、EuroSys、VLDB、TPDS 等顶级会议和期刊上发表论文三十余篇，相关成果获授权美国、中国专利 10 项。他曾入选 CCF 系统软件专委会优秀博士论文激励计划，并担任 PPoPP、FAST、DASFAA、TPDS、ICME、TC、JSC 等国际会议/期刊的程序委员会成员和审稿人。他在本次会议的详细演讲内容如下：

演讲提纲1. 强化学习系统的整体流程Rollout、数据传输、Learner 更新与权重下发同步 RL 与 Fully Async RL 的执行模式RL 系统中的数据面与控制面2. RL 场景面临的系统挑战Rollout 数据规模大、结构复杂Actor 与 Learner 之间的数据传输开销高权重更新频繁且容易阻塞采样不同并行策略下的权重布局不一致MoE 模型权重同步成本高3. Mooncake 的高性能 RL 数据面结构化对象与 DataProto 数据组织typed-ragged 对变长序列数据的支持BufferPool 降低内存分配和拷贝开销RDMA 加速 Rollout 数据传输接入 Miles 替代 Ray Object Store4. 同步与 Fully Async Rollout同步 Rollout 的数据流与权重更新流程Fully Async 模式下 Actor、Rollout 与 Learner 解耦数据生产、消费和缓存的并行化吞吐、延迟与训练稳定性的权衡5. Mooncake 的权重更新机制NCCL Broadcast：适合高带宽集体通信TransferEngine P2P RDMA：实现点对点高效传输disk-delta：降低权重更新的数据传输量Kimi-K2 场景下 P2P 约实现 7 倍加速6. 异构并行与大模型支持TP、PP、EP、DP 之间的异构 ReshardStore 权重快照与快速恢复MoE 稀疏 Delta 更新不同集群和硬件拓扑下的权重调度7. 生态集成与生产实践Miles 中的 RL 数据面应用与 SGLang、vLLM 等推理框架协同Rollout、训练和权重服务的统一基础设施面向生产环境的稳定性、可观测性与容错8. 未来发展方向面向 RL 的统一数据对象和传输接口更高效的异步权重同步与版本管理面向 MoE 和超大模型的稀疏更新推动 Mooncake 与更多开源 RL 项目协同优化实践痛点不同 RL 框架之间的数据结构和接口缺乏统一标准。Ray Object Store、网络传输和权重同步容易形成系统瓶颈。Fully Async 场景需要处理数据一致性、权重版本和训练稳定性。TP/PP/EP/DP 异构 Reshard 适配复杂，跨框架推广成本较高。需要与更多开源项目共同验证性能并完成协同优化。前沿亮点面向强化学习 Rollout 数据面进行系统级优化通过 DataProto、typed-ragged、BufferPool 和 RDMA 提升数据传输效率。同时支持同步与 Fully Async RL 工作流。基于 P2P RDMA、NCCL 和 disk-delta 构建多路径权重更新机制。支持异构并行 Reshard、权重快照和 MoE 稀疏 Delta。已在 Miles、SGLang、vLLM 等生产生态中得到应用。听众收益理解大模型强化学习中 Rollout、数据传输和权重同步的关键瓶颈。掌握 Mooncake 在 RL 数据面和权重更新方面的核心能力。了解同步与 Fully Async RL 的系统实现思路。学习如何利用 RDMA、BufferPool 和结构化数据降低传输开销。了解异构并行 Reshard 及 MoE 稀疏权重更新的实践方法。获得将 Mooncake 集成到其他 RL、推理和训练框架中的设计思路。

查看更多详情可扫码或联系票务经理 18514549229进行咨询。

两名工程师、两个月、4 万行 Rust：DynamoDB 太贵又慢，Perplexity 决定自己造

作者：Olimpiu Pop — Thu, 08 Oct 2026 02:00:00 GMT

Perplexity 已将其核心搜索服务层从 Amazon DynamoDB 迁移到 CobbleDB，这是一款使用 Rust 编写的内部自研分布式键值存储"。此次迁移旨在解决高查询量下向大语言模型提供数千字节文档批次所产生的严重延迟和成本瓶颈。通过将持久化文档存储与热数据层检索解耦，工程团队将批量读取延迟降低了五倍，同时使整体存储费用至少下降了 20%。

人工智能答案引擎的读取模式与传统文档搜索不同。发送到 Perplexity 的每个查询会生成 100 至 120 个目标页面键，检索服务会将其拆分成多个包含 10 至 20 个键的批次并行处理。传统搜索引擎返回的是简短的元数据片段，而面向语言模型的检索则需要提取完整的分块段落和稠密向量嵌入，使平均记录载荷达到约 50 KB。

在每秒超过 20 万次请求的生产流量规模下，DynamoDB 按使用量计费的模式在经济上变得难以维持，因为 AWS 会对传输的每个字节计费。此外，DynamoDB 如同一个黑盒，内部的分区位置、内存缓存策略和副本路由均不可见。工程师无法避免由未缓存读取、跨可用区网络跳转或副本延迟引起的尾延迟峰值。分块算法更新或采用新嵌入模型后触发的重新处理作业，也会将大量写入直接推送到 DynamoDB，与实时用户请求形成嘈杂邻居争用。

为解决这些限制，Perplexity 将存储架构拆分为三个专用系统：负责持久状态管理的 Pillar、负责批量聚合的 Lorry，以及负责低延迟服务的 CobbleDB。

Pillar 基于运行在大容量机械硬盘上的 YTsaurus，维护网页元数据、段落和向量表示的版本化表族。YTsaurus 原子事务确保抓取更新、状态变更和导出队列一同提交。Lorry 充当无状态队列消费者，将 Pillar 的导出内容组合成与分区对齐的批量文件，把载荷存储到 Amazon S3，同时向 CobbleDB 发送元数据通知。CobbleDB 工作节点独立拉取并摄取这些 S3 批次，使热数据服务节点与写入密集型抓取管线完全隔离。

CobbleDB 是一个专门针对批量查找进行优化的分布式键值存储。每个分区维护三个副本，分布在相互独立的计算节点上。核心守护进程使用 RocksDB 作为嵌入式存储引擎，并结合内存映射缓存与本地 NVMe 固态硬盘。

无状态查询路由器将经过哈希处理的页面标识符映射到分区，并协调读取执行。为了尽量减少网络开销，路由器会将请求发送到位于同一可用区的节点副本。如果目标副本的响应时间升高，路由器会进行推测性对冲，同时向另一个节点上的备用副本发起读取请求。在每个节点内部，CobbleDB 通过 RocksDB 的批量 MultiGet 接口同时检索多个键，从而消除往返开销。

pub struct BatchedPageRequest { pub keys: Vec, pub zone_affinity: AvailabilityZone, } impl StorageEngine { pub fn multi_get_pages(&self, keys: &[PageKey]) -> Result>, Error> { let rocksdb_keys: Vec<&[u8]> = keys.iter().map(|k| k.as_bytes()).collect(); self.rocksdb.batched_multi_get(&rocksdb_keys) } }

该数据库舍弃了标准的分布式事务协议和同步共识算法。由于搜索服务可以容忍轻微的复制延迟，各个副本会按照自己的速度异步应用更新，从而大幅降低运维开销。

在实际生产测量中，CobbleDB 将批量读取延迟中位数从 31.4 毫秒降至 5.60 毫秒，p90 延迟从 56.7 毫秒降至 9.77 毫秒，p99 尾延迟从 123 毫秒降至 24.2 毫秒。处理最大 100 KB 载荷的合成基准测试表明，在每秒最多 50 万次请求的规模下，其吞吐量仍能保持稳定。

该架构也带来了不可忽视的权衡。用自建系统替换全托管云数据库，意味着节点生命周期管理、备份验证和分区重新平衡都将完全由内部站点可靠性工程师负责。由于各个副本摄取批量文件的时间间隔不同，应用程序还必须能够承受最终一致性。

该公司首席执行官 Aravind Srinivas" 表示，CobbleDB 由约 4 万行 Rust 代码组成，两名系统工程师与一个自主 AI 编码智能体集群配合，在两个月内完成了构建。这些 AI 智能体负责集成测试、构建监控和运维手册。Perplexity 表示，计划在即将发布的版本中开源 CobbleDB 代码库。

原文链接：https://www.infoq.com/news/2026/09/cobbledb-perplexity/"

代码交给AI，心流却回来了：Codex负责人不再怀念手写时代

李冬梅 — Thu, 08 Oct 2026 01:35:10 GMT

OpenAI 的 ChatGPT 和 Codex 负责人 Tibo Sottiaux，近日在 X 上给团队立下了一份可以逐日检查的承诺：未来 28 天，每天要么推出一项对大多数 Codex 和 Work 用户明显有用的改进，要么进行一次完整的额度重置。

这份承诺把判断权交到了用户手里。产品有没有变好，不能只看发布了多少功能，还要看用户在日常工作中是否真正受益。至于额度重置，Tibo 在最近的一场访谈中，恰好解释了自己为什么能直接拍板。

“只要有必要，而且我认为合适，我就可以按下额度重置按钮。”他表示，这种自主权让他能够更直接地贴近社区，“我不需要让这件事经过层层审批”。

当主持人 Lenny 问，接下来还能期待多少次额度重置时，Tibo 的回答带着一点自嘲：“取决于我们把东西弄坏多少次。”他随后补充，出了问题会重置，有值得庆祝的事情也会重置。他还坦承，自己加入 OpenAI 的第三天，就曾把生产环境弄宕机。

不过，比“还能领多少额度”更值得关注的，是这位产品负责人对 AI 使用体验的判断：就连他自己，也已经受够了越来越复杂的选择。

该选哪个模型？推理强度设多高？用多智能体模式，还是 Ultra 模式？这些选项到底有什么区别？在访谈最后，Tibo 直言，自己也会被它们弄得疲惫：“你简直需要拿一个‘模型选择器博士学位’。”他希望尽快摆脱这些负担，让应用本身逐渐退到幕后。

这种对简单体验的追求，也来自他自己的工作变化。如今，分析业务趋势、研究下一个功能、检查此前发布的产品表现，所需的大量代码都由 Codex 编写。手写代码，则成了偶尔在周末刷几道 LeetCode 题时的放松活动。

他也没有一味追求同时运行更多智能体。随着智能体速度提高，他反而重新找回了工作的心流：想法不必在漫长的等待中被打断，通过语音就能推动构建，注意力可以更集中地放在创造本身。“这种心流和过去不一样，但我已经不再怀念过去的那种状态了。”

在 Tibo 看来，接下来的产品设计需要考虑三个变化：互联网上的大多数操作将由智能体完成；模型会迅速变得更便宜、更快；不同模态之间的交互会更加顺畅。这也是他对外界一些产品提出质疑的原因：如果认真设想一年后这些能力比今天强十倍，开发者就会采用不同的构建方式。

从这个角度看，28 天的改进承诺，与他在访谈中反复强调的方向相互呼应：让更强的能力，变成更容易使用的产品。

在 DevDay 期间接受 Lenny 采访时，Tibo 进一步谈到了个人智能体平台 Dots、Codex 与 ChatGPT 的整合，以及为什么手动搭建循环、反复调整智能体工作流可能只是一个过渡阶段。他也回答了更贴近从业者的问题：AI 接管更多执行工作之后，哪些技能会更重要？人是否必须因此做更多事情？智能体开始主动行动时，又该如何控制风险？

以下为完整访谈，经 InfoQ 编译：

Lenny：谢谢你接受采访。你们最近发布了很多东西。最近睡得怎么样？状态还好吗？

Tibo Sottiaux：我状态很好，很幸运拥有一支优秀的团队。我睡觉的时候，他们大半个晚上都还醒着。办公室里有一个很棒的房间，叫“图书馆”。我们把它完全改造成了一个大型作战室。那里的氛围非常好，大家一直忙到很晚。

Lenny：你做了很多年工程师。现在还写代码吗？还会提交 PR，也就是代码合并请求吗？还是主要在写文档、开会？

Tibo Sottiaux：你所说的，到底什么才算“写代码”？

Lenny：比如提交 PR，偶尔合并一些代码。

Tibo Sottiaux：从技术上说，为了完成各种分析，确实有大量代码在替我编写。比如了解趋势、了解业务、研究下一个功能，以及分析之前发布的产品表现如何。这些工作所需的大量代码，都是 Codex 写的。我显然已经不再手写这些代码了。

偶尔到了周末，我会手写几道 LeetCode 题，享受一点放松、解压的时间。但这是我现在唯一还会亲手写代码的场景。

Lenny：在日常工作中，你通常会同时运行多少个智能体？

Tibo Sottiaux：以前我会同时运行更多智能体。后来，我们很幸运地在超高速能力方面取得了突破。现在，我感觉自己又能保持在工作的心流状态里了。一个速度更快的智能体，对我的帮助很大。

同时运行多少个智能体，其实会变化。当我不断探索能力边界时，我会组建越来越大的智能体团队。但当模型取得下一次突破时，我突然发现，一个能力更强的智能体就能完成所有工作，把全部信息保存在记忆中，并持续学习。于是，我又会缩小团队规模。

这个过程就是不断扩张、收缩，再扩张。

AI 将如何继续改变工作

Lenny：能进一步解释一下吗？这让我想到，之前大家都在讨论循环，后来又开始讨论执行图。你说的是否在某种程度上是这些方式的进一步演变？

Tibo Sottiaux：搭建循环、反复调整循环，再弄清楚它们应该如何运作，可能曾让一些人感到兴奋。但我不认为未来会以这种方式运作。

我认为，未来的方式更接近我们对 Dots 的定位，以及这次推出的产品：你拥有一个非常聪明的智能体，它每周七天、每天二十四小时持续工作，理解你的目标、了解你的偏好，并从反馈中学习。

我们这次推出的产品并不完美。把它开放给所有 Pro 用户后，我们会从中学到很多东西。但长期来看，你需要的是一个能够根据你想实现的目标不断学习的系统。你不应该非得思考：“为了得到结果，我必须让它严格按照这种方式循环。”

Lenny：现在有 Codex、ChatGPT Work、面向消费者的 ChatGPT，还有 Dots。听起来，你认为我们正在走向这样一种未来：Dots 成为人与 AI 交互的主要入口，再由它启动其他这些工具或服务。是这样吗？

Tibo Sottiaux：是的。但如果退一步看，无论最终是不是 Dots，根本目标都是让人摆脱技术本身的束缚。

你拥有一种持续存在、始终活跃的智能能力。它知道自己需要做什么，而且可以通过任何客户端、任何屏幕与你交互。你也可以给它打电话。比如，你走进会议室，它就出现在会议中，帮你记笔记。之后，你可以通过邮件接着与它沟通；需要它的时候，也可以给它发消息。

你不需要一直守着笔记本电脑，也不需要始终盯着手机。需要它时，它就在；不需要它时，它也不会妨碍你。我迫不及待地想看到这成为现实。现在，我们到哪里都要带着笔记本电脑，就像随身带着一块砖。你被技术拴住了，而不是技术在为你工作。

Lenny：我今天也想问你这个问题：过去两年，我们的工作方式似乎已经发生了很多变化。尤其是工程师，但也包括许多其他岗位，日常工作都已经明显不同了。

你认为，我们是否正在逐渐接近未来工作的基本形态？比如未来五年——不过五年似乎太遥远了，那就说未来两年。还是说，我们的工作方式仍然会发生更剧烈的变化？

Tibo Sottiaux：我认为，它还会继续发生相当剧烈的变化。

即使到了今天，语音、多模态输入和输出等技术似乎终于开始结合起来，但使用起来仍然有些笨拙。我认为，这种感觉会一直持续，直到某一天它突然不再笨拙。到那时，你会发现：“我可以像我们现在这样，直接和它交谈。它能准确地记住所有事情。如果我想构思、头脑风暴，我们可以随手画点东西，我还有一个可以共同协作的界面。”

你可以设想，我们拥有一块共享白板，人和人之间、智能体和智能体之间，都可以共同协作。

我认为，这会超越对话，也会超越今天的许多客户端形态。毕竟，这些东西今天还没有真正运转起来。所以，我们还会经历一轮重大的新变革。

Dots 未来发展方向

Lenny：听起来，Dots 是未来的重要组成部分。这个 AI 助手可以替你处理各种事情，你不再需要区分什么时候用 Codex、什么时候用 ChatGPT，对吗？

Tibo Sottiaux：是的。对于 Codex 和 ChatGPT，我们会做整合。现在，我们有聊天模式，也有 Work 模式的切换开关。我们已经非常明确地听到了用户反馈：大家喜欢 Work 的能力，但有时也想用聊天模式，因为它速度更快、用起来更舒服。

所以，我们正在把这些体验整合起来，降低复杂度。最终，我们也会把 Dots 的所有能力直接带到聊天模式中，提高我们这 12 亿用户所能获得的基础能力。当然，到那个时候，用户数量是多少，我们再看。

我们希望整个体验真正做到无缝衔接。Dots 有一点让我非常兴奋：它没有模型选择器，也不需要各种配置，你只需要和它交谈。唯一需要配置的是，你希望通过哪些渠道与它沟通。

Lenny：这很像电影《她》所描绘的世界。你会想到这部电影吗？就是这样一种设想……

Tibo Sottiaux：我看过一次。我觉得这个设想很有意思。不过，我更多想到的是三四十年前的科幻作品，以及它们当时有多么富有远见。

Lenny：有没有哪部科幻作品对你的影响特别大？

Tibo Sottiaux：比如《神经漫游者》这样的书，还有最初的《星际迷航》。我经常想到这些作品。《星际迷航》有一点让我印象很深：里面的技术非常实用。你可以直接和计算机说话，它就替你做事；你可以和飞船说话，它就会行动。

这些事情正在变成现实。我们正在进入那个时代。

Lenny：我们今天是在现场观众面前录制这场访谈。门外排起了长队，大家都在等着见你、听你分享。你怎么看自己现在所处的位置，以及这份责任？你们正在开发的东西会影响人们的生活。这是一种什么样的感受？

Tibo Sottiaux：我认为，成为社区的一部分，与大家一起构建产品，非常重要。

某种意义上，我们是在共同探索这项技术，以及我们能一起用它做些什么。每次和人交流，我都会发现：“原来你在用它做这件事，这是我之前完全没有想到的。”

它以某种方式影响了你的生活，也影响了另一个人的生活。把这些体验放在一起，会让人感到谦卑，也很受启发。我认为，要做出真正对人有用的东西，这个过程必不可少。我不知道，如果没有社区，我们该怎么做到这一点。

Lenny：我经常听开发 AI 产品的人说，产品发布之前，他们并不真正知道自己做出了什么。只有发布之后，看到人们如何使用、有哪些新用法涌现出来，才会逐渐理解它。听起来，你的意思也是与大家一起构建，而不是说：“这就是我们的愿景，我们已经把一切想清楚了。”

Tibo Sottiaux：就连 Twitter 社区，总体上也对我们很友好。

Lenny：你很擅长用 Twitter。虽然有时会有点针锋相对，但确实很擅长。你怎么还能抽出时间发推？我不太理解，像你这样的人怎么有时间刷 Twitter、发帖、回复。

Tibo Sottiaux：我每天大概花半个小时，刷一刷。受到启发、觉得有值得分享的内容时，就做点什么。很多内容都是当下想到的。

Lenny：这正是适合 Twitter 的能力。

Tibo Sottiaux：另外，我还有一个 Dot。我们还没有推出团队形式的 Dots，但今天发布了可以由用户配置的主 Dot。你可以把它连接到自己的应用，逐渐了解一个 Dot 能做些什么。之后，我们会开放创建多个 Dot 的能力。我自己就有一个专门负责 Twitter 的 Dot。

Lenny：能具体说说吗？现在每个人只有一个 Dot，还不能添加更多，对吗？以后大家可以拥有多个 Dot。这个方向会怎样发展？

Tibo Sottiaux：是的。我们希望先从一个主 Dot 开始。它很可能也是你会通过消息联系的那个助手，而且会最深入地了解你的偏好。

我们想先看看大家会用它做什么，看看系统需要怎样调整，通过与社区共同使用和探索来学习。

很快，你就可以添加第二个、第三个、第四个 Dot，按需要创建任意数量的 Dot，组成自己的虚拟团队，并给它们分配具体角色。

我并不认为这在所有情况下都绝对必要。但有时，我有一项需要投入大量工作的任务，比如替我持续关注 Twitter。它的工作量可能大到足以占用一整个 Dot。这样的 Dot，你可以有几个。

OpenAI 的开放生态与插件收入分成

Lenny：回顾最近发布的所有东西，Dots 可能是最吸引眼球的。有没有什么你认为还没有得到应有关注，但未来会变得非常重要的东西？也就是大家还没充分意识到、却对整体愿景很重要的部分。

Tibo Sottiaux：我认为，被低估的是生态系统：把整个体系开放出来，以及我们对全面开放的坚定承诺。我们已经签下了 16 家合作伙伴，我对此非常自豪。

这件事其实是去年很自然地开始的。当时，我和 Pi、OpenCode 的开发者交流，觉得用户理所当然应该能使用 Codex 登录，并使用自己的额度。

于是，我们相当于在线上握了握手，说：“你们直接用这个认证机制就好，我们相信你们不会做什么不当的事情。”

后来，这种方式越来越受欢迎。现在，我们把它变成了一项正式支持的机制，与许多合作伙伴共同推进。我很期待迅速扩大这方面的合作。另一方面，我们也在开放基础设施，以及我们构建 ChatGPT 的方式，包括插件扩展、插件发现，让任何人都有机会把自己的产品带给大约 12 亿用户，并从这样的分发能力中受益。

我们还设计了收益分享机制，只是没有在主题演讲中提到。对于受欢迎、使用量大的插件，我们会支付报酬，它们也会获得一部分收入分成。

我认为，这种对开放生态的承诺，会带来非常令人期待的发展。

Lenny：举个例子，假设有人在 ChatGPT Work 里使用 Notion 或 Figma 插件，Notion、Figma 就能因为用户在应用内使用它们而获得收入，对吗？

Tibo Sottiaux：是的。我们有很多使用 ChatGPT 的订阅用户，他们会获得一定的使用额度。当用户把这些额度用在插件上，或者通过“使用 ChatGPT 登录”在其他产品里使用额度时，我们会与相应的合作伙伴分享收益，让它们获得报酬。

Lenny：插件和生态系统让人兴奋的一个原因，是它们能成为分发平台，帮助产品被发现：“人们发现了我的应用，然后它迅速火了起来。”对于希望自己的插件脱颖而出、被更多人发现的开发者，你有什么建议？

Tibo Sottiaux：做一个好的插件。我们的机制是这样的，当然，系统还会继续调整：我们会看用户留存数据，看插件是否成功、质量如何，再据此开始在对话中向用户推荐。这样，你的插件就有机会被推荐给相当一部分用户。但如果插件不够好，系统就会停止推荐。

Lenny：你们会关注使用某个插件的用户是否留下来，这一点很有意思。

Tibo Sottiaux：我们要看，它是否真的增加了实用价值，是否让 ChatGPT 能够完成更多事情。

Lenny：明白了。所以，重点并不是做 AEO，也就是通过选对词、让更多人写文章提到你，来提高被 AI 推荐的机会；而是人们是否持续使用你的产品，是否愿意留下来。

Tibo Sottiaux：是的。

Lenny：所以，你认为这是一项目前被低估、以后会变得很重要的东西。我知道，这也算你们的第二次尝试，之前已经做过应用市场。

Tibo Sottiaux：这次的方向是对的。

Lenny：好，这次会成功。我们再回到 Dots，因为它似乎是未来愿景的重要组成部分。

Dots 背后的研究积累

Lenny：你们什么时候开始做 Dots 的？之前，OpenClaw 引发了很大关注，Peter 加入了你们，也成立了一个基金会。此外，还有 Grokbot、Muse、Instinct 等产品。你们已经做了多久？为什么到现在才推出产品？

Tibo Sottiaux：你还记得 Codex Cloud 吗？

Lenny：记得，就是最早那个版本，大概是一年前，对吧？

Tibo Sottiaux：如果回头看看 Codex Cloud，以及我们当时使用的那段小动画，我觉得，那可能就是 Grokbot 的灵感来源。它们非常相似，我甚至会说，相似得有些不可思议。但认真来说，在研究层面，我们开展持续运行、长时间跨度任务的研究，已经超过两年了。能够保持连贯一致的记忆系统，我们也研究了差不多同样长的时间。

其中很多能力，我们已经直接放进了 ChatGPT。我觉得，用户很喜欢 ChatGPT 能够了解这么多与自己有关的信息。我和很多人聊天时，他们都会分享这样的故事：“我生病了，ChatGPT 居然记得，我之前参加过一次烧烤，用过青柠，还调过龙舌兰酒。所以，我手上的灼伤可能与青柠有关，是一种晒伤。”他们会问：“它怎么会知道这些？”

这是因为，ChatGPT 的记忆功能已经运作得非常好了。我们在这方面投入了大量研究。

这些能力结合在一起，以 Codex 的智能体运行框架，也就是 harness 为基础，再加上能够全天候持续运行、有效完成工作的能力，就形成了这次发布的 Dots。所以，这是经过很多个月工作积累的成果。

另外，确保产品的安全性和系统安全也非常重要。这也是我们选择搭载 Astra 推出 Dots 的原因：它是我们最安全、最符合对齐目标的模型。为了让 Dots 真正安全、可靠，我们投入了更多努力。

Lenny：我喜欢问来参加播客的嘉宾一个问题：随着 AI 承担越来越多的工作，你认为自己在哪些工作中仍然不可或缺？长期来看，人类大脑在哪些方面仍然有用，或者最有价值？

Tibo Sottiaux：我认为，这在很大程度上取决于我们如何构建技术。在 OpenAI，我们设计所有东西时，都把人放在中心，把技术构建成人的延伸，成为你的意志和品味的延伸，让它真正成为一种赋予人能力的工具。

只要我们继续沿着这个方向走，让技术帮助你实现想做的事情，扩展你的创造力和品味，而且在使用时让你感觉非常好，那么它实际上就是一种创作工具。

未来，我们可能不再有专门写代码的人，但会有比以往更多的创造者。我认为，这件事里仍然会保留一些深刻的人性：人们希望学习，也希望看看其他人正在创造什么。

我更感兴趣的也是这些。我在这里，是在和你交谈，而不是在和 Dot 交谈。我认为，这一点在很长、很长一段时间里都不会改变。

Lenny：工程师的工作生活发生变化后，出现了一个现象：他们需要更频繁地切换上下文。还有一种逐渐出现的孤独感，因为他们整天都在和智能体交谈，而不是和其他人交流。你会在多大程度上考虑 AI 对人们生活的这些影响？有没有办法解决这些问题，或者让这种体验不那么烦人？

Tibo Sottiaux：会，我们一直在考虑。减少配置带来的疲劳，是其中一个方向。另一个方向，是改变与智能体交互像是一场“独自冒险”的状态：你只和自己的一个智能体对话，之后又有了很多智能体，要把大量事情分别委派给它们。

很多方面的改进会结合起来，让整个体验更加愉快。我和团队都花了很多时间思考这些问题。

对我来说，理想的工作方式，是让它直接存在于你所在的物理空间里。我们像现在这样交谈，它能够观察、理解我们提出的想法。

我们可以在纸上写点东西，它就能接收这些内容，开始在后台构建。然后，你说：“其实，我还有另一个想法。”它就开始构建另一件东西。

你可以把结果投到屏幕上，直接和它说话。它也能参与人与人之间的对话。这样，你就不需要一直盯着屏幕、不断琢磨该怎么写提示词，也就没有了这种疲劳感。整个过程会变得非常自然。

这就是我们正在走向的方向。今天还没有完全做到，但未来会做到。

因为 AI 能做更多，人就必须做更多吗？

Lenny：沿着这个话题，还有一个已经出现的负面影响：因为我们能做更多，所以就承受了必须做更多的压力。大家会说：“来吧，同时运行 30 个智能体。你为什么没有交付更多？别人都在交付更多。”你认为这个问题能够解决吗？还是说，这就是人的天性：既然能做更多，那就做更多？

Tibo Sottiaux：我们也听到 Sam 谈过这项技术的承诺：减少噪声，让你把注意力放在自己真正想关注的地方。现在有很多事情，也许重要，也许不重要，但都在争夺你的注意力。我们希望降低这些干扰，让你能够专注于真正需要关注的事情。

我发现一个很明显的现象：每次度假，用一周时间彻底断开与工作的联系后，我就会开始用不同的、更有创造力的方式思考。我非常期待看看，我们能否把这种状态带进日常生活。也许你需要参加的会议可以更少，也许你不需要做那么多事情。实际上，如果休息得更好，你可能反而更有生产力。

我认为，整个行业都需要一起弄清楚这件事。但这才是 AI 所承诺的价值，而不是让你每秒再多输入一条提示词。

Lenny：我现在正在做一个机器人，类似于“精力审计助手”。它会查看我的日历，然后问我：“这件事是在给你补充精力，还是在消耗你的精力？这件事能不能交给别人做？”我觉得，AI 应该会对我说：“Lenny，也许你可以删掉这些安排，让自己过得更开心。”

最近，你有没有用 AI 做过什么特别有意思的事情，让你觉得：“这太厉害了，真的让我大开眼界。”或者，你有没有听别人分享过这样的案例？

Tibo Sottiaux：确实有一件有意思的事。不过，刚才的现场演示当着所有人的面失败了，这本身当然不是什么好事。但实际上，我的 Dot 知道我正在参加 DevDay。当时，我们的 ChatGPT 生产环境出了故障，它就在最后一场演示开始前五分钟提醒了我。

这其实让人很紧张。它说：“生产环境出故障了。你想让我试着修复吗？”我当时想：“小 Dot，我觉得你还没有这个能力，不过谢谢你愿意试一试。”之后，我联系了工程团队，我们开始排查发生了什么。现在，问题已经修复了。

让我觉得了不起的是，它能够理解这些事情之间的关系：有一场很重要的活动，叫 DevDay；有一个生产系统；还有一场现场演示，而这场演示很可能会用到这个生产系统。所以，这两件事情是有关联的。演示将在五分钟后开始，我应该提醒他，因为他很可能希望知道这个情况。

我认为，这相当了不起。

Lenny：确实很了不起。它知道接下来要发生什么，然后提前告诉了你。而且，我很喜欢它主动提出修复问题，你则说：“还不行，你还没到那个水平。”

Tibo Sottiaux：我没有说：“那你去试试，让我刮目相看吧。”不过，如果真那么做了，这个故事可能会更精彩。

Lenny：你怎么看给它开放这么多访问权限？比如，它能访问生产环境的代码库吗？

Tibo Sottiaux：它可以访问部分生产系统，但有相应的安全限制。我们刚才谈到过专门承担某些任务的 Dot。这些专用 Dot 会在额外的安全限制和监控下运行，并使用各自的硬件。实际上，我们有些 Dot 就运行在 Mac mini 上。

我们构建 Dots 的方式有一个根本区别：智能体运行框架，也就是 harness，并不运行在它所操作的那台机器上。大家可能还没有意识到，这意味着它可以连接任意数量的设备。它有自己的计算机，你也可以把它连接到自己的笔记本电脑上。以后，你可能会把它连接到十台不同的设备，而它可以控制所有这些设备，有点像一只章鱼。

Lenny：所以，你是在和自己的 Dot 交谈。它存在于某个地方的一台虚拟机里？

Tibo Sottiaux：它可能运行在虚拟机里，也可能不是。它是一个独立的系统，可以连接多台设备。

AI 时代，哪些技能正在变得更重要？

Lenny：我知道你们正在大量招聘，你也参与面试。在你考察的能力中，哪些技能正在变得越来越重要，越来越能决定一个人能否取得成功？又有哪些技能的重要性正在下降，让你觉得：“我们已经没有那么需要它了”？

Tibo Sottiaux：一个重要性正在下降的技能，是打字快。它已经没有那么有用了。越来越重要的技能，包括出色的品味、从用户的角度思考，以及与自己服务的用户建立联系。很多曾经创业的人，或者连续创业者，现在都表现得非常出色。我们在 OpenAI 的招聘中也发现了这一点，公司里有很多创业者。

我想，目前 OpenAI 有超过 120 位曾经参加过 YC 的创业者。这里就像一家巨型初创公司。

那种希望做出真正有意义的东西的热情和渴望，以及知道什么才是好的东西，比以往任何时候都更重要。

Lenny：我一直认为，产品经理会在这个时代发展得很好，因为这基本上就是产品经理的工作：判断应该做什么，帮助别人把它做出来，再判断它是否正确、是否足够好，然后不断迭代。

Tibo Sottiaux：我同意。另外，岗位之间的界限也正在变得模糊。你以前可能只做设计，或者只做工程，而且总觉得自己被这样的角色限制着，有些不自在。现在，正是你发挥的时候。

Lenny：你会怀念工作中做工程的部分吗？我以前也做过工程师，做了十年，你可能不知道。做工程时会进入一种心流状态。单纯地构建东西，看着它运行成功或者失败，本身就有一种美感。

你会怀念这些吗？还是觉得：“那已经是我过去的生活了”？

Tibo Sottiaux：有一段时间，我确实很怀念。但现在，随着速度变得非常快，我又找回了这种感觉。所以，我非常希望尽可能让更多人都能获得这样的体验。

要让它真正普及，让超过十亿用户都能用上，还需要一段时间。但我们的速度已经很惊人了，即使我们在公司内部，也会惊讶：“原来我们已经能做到这些了。”这也与我们使用 Astra 有关，我们发现可以把它的能力推得很远。

有了这样的速度，尤其是能够通过语音控制之后，你会重新进入一种非常有创造力的思考状态，重新进入心流。这种心流和过去不一样，但我已经不再怀念过去的那种状态了。

OpenAI 内部如何开发和发布产品

Lenny：说到 OpenAI 内部的工作方式，有哪些事情会让外界感到意外？从外面看，你们似乎一直在写代码、发布产品。整个过程有点混乱，但又很精彩。真正置身 OpenAI，有哪些情况会出乎大家的意料？

Tibo Sottiaux：我不知道这是否会让人意外，但正如我刚才所说，我们有很多曾经创业的人，大家会自下而上提出许多令人兴奋的想法。

比如，Decisions API 就是在很短时间内做出来的。我们意识到，Luna 是一个非常好的模型，可以做一些约束采样，再通过一种不同于 Responses API 的接口形式把它发布出去。这样做，速度更快，在一些场景下的使用体验也很好。

如果你深入看看背后的过程，就会发现：最初是建了一个 Slack 频道，四个人在一个周末动手尝试。之后，它被开放给公司内部使用，大家开始感到兴奋，围绕它构建东西。

有人发现：“我们可以支持视觉输入，这甚至比外面已有的东西更好。”大家越来越兴奋，开始加入进来。整个过程看起来完全没有固定的组织结构，但大家会一路把它推进下去，最后发布成产品。

同时，我们也努力维持较高的质量标准。如果某些东西还不够好，就会在发布之前叫停，或者让它再打磨一段时间。原本还有更多东西可能在 DevDay 发布，但我们觉得：“今天已经很多了，先留下一些，把发布节奏分散开。”

所以，接下来还会有更多发布。这里有一种非常强烈的、自下而上的活力，人们会主动承担相应角色，把这些力量引导到能够产生实际成果的方向上。

Lenny：OpenAI 有一个非常明显、也很独特的特点：你似乎拥有很大的自主权。你可以随时按下额度重置按钮，也可以直接在 Twitter 上发表观点。这种文化很特别，赋予了你很大的自主权，我想背后也有很强的信任。能否谈谈这种文化理念？我觉得，这是 OpenAI 能够行动得更快的一个优势。

Tibo Sottiaux：你会获得很大的自主权，但也必须为自己的决定负责。我们信任大家能够做出好的选择。如果出了问题，就迅速修复，或者从错误中学习。到目前为止，效果很好。这是一个能充分激发个人能力的环境。

确实，只要有必要，而且我认为合适，我就可以按下额度重置按钮。这是一种特权，也让我能够以其他情况下很难做到的方式，贴近社区。我不需要让这件事经过层层审批。

Lenny：你说过，有时大家也会犯错。在拥有这么多自主权和信任的情况下，你有没有搞砸过什么事情？

Tibo Sottiaux：有。我觉得，有些时候，我本可以更好地激励团队，去构建复杂度更低的东西，持续朝着更简单的方向努力。Codex 早期也有几次由我造成的服务故障。

我刚加入 OpenAI 的第三天，就把生产环境弄宕机了。不过，出了这件事之后，我还留在公司，也从中吸取了教训。

Lenny：大家还希望我问你：未来一个月或者一周，可以期待多少次额度重置？

Tibo Sottiaux：取决于我们把东西弄坏多少次。

Lenny：所以，这就是你们的原则：出了问题，就重置额度？

Tibo Sottiaux：是的。出了问题会重置，有值得庆祝的事情也会重置。

Lenny：我们把视角拉远一点。关于未来的发展方向和即将发生的变化，你认为有哪些事情，大家还没有充分考虑到，也没有看得足够清楚？

Tibo Sottiaux：我觉得，还有很多事情没有被充分考虑进去。第一，互联网上的大多数操作，将由智能体完成。第二，模型会以相当惊人的速度，变得更便宜、更快。第三，我们终于能够以真正无缝的方式，把所有模态整合起来。

这三点让我经常在看到外界正在开发的东西时，觉得：“你们还没有真正理解这件事。”

你们已经接近了，但如果再逼自己往前想一步，认真设想一年后，这些能力大致会比今天强十倍，你就会用不同的方式来构建产品。

Lenny：在大多数操作都由智能体完成的世界里，会出现什么进一步的影响？可能连大多数流量都会来自智能体。

Tibo Sottiaux：是的。

Lenny：你认为，这会带来哪些后续变化？

Tibo Sottiaux：会有很多。首先，如果希望自己的产品在智能体用户中取得成功，就必须按照相应的规模来构建它。比如，我们和 Notion 有非常紧密的合作。当他们构建了 MCP 接口后，突然之间，所有这些能够真正执行工作的智能体，都可以访问并使用它。

于是，他们看到了大量涌入的流量。这显然会给系统带来很大压力，而且你必须弄清楚背后的成本和收益关系。

这就带来了一种矛盾：开发产品时，你究竟要不要提供这样的接口？你可以暂时推迟，但这个趋势不可避免。大多数产品和服务都会由智能体来使用，所以，为这样的未来做好准备非常重要。

另一方面，我认为，我们对面向人的全新体验投入还不够。这些体验应该充分利用所有模态，真正让人用起来感到愉快。

Lenny：最后一个问题。现在的应用里，有什么东西让你觉得特别烦，忍不住想：“我们必须把它改掉”？

Tibo Sottiaux：我觉得，模型的能力已经接近那个水平了，但还差一点：让应用本身几乎完全退到幕后。我迫不及待地想真正实现极致的简单。就连我自己，也会被模型选择器、推理强度，以及到底该用多智能体模式还是 Ultra 模式这些选项弄得疲惫。甚至连这些选项究竟做什么，都需要弄清楚。

你简直需要拿一个“模型选择器博士学位”。我只想尽快摆脱所有这些东西。

参考链接：

https://www.youtube.com/watch?v=MM-C3JqCXBk&t=2s"

https://x.com/search?q=tibo&src=typeahead_click"

为迎接 iPhone Duo，iOS 开发者需要对应用做出哪些调整

作者：Sergio De Simone — Wed, 07 Oct 2026 08:00:00 GMT

随着折叠屏 iPhone Duo 即将推出，iOS 开发者需要调整自己的应用，以确保其能够正常运行"，适配这款新设备的外屏、更大的内屏以及部分折叠状态。开发者还需要考虑导航和工具栏的变化、摄像头行为以及新增的保留区域。

为了充分利用 iPhone Duo 上所有可用的屏幕空间，开发者应使用 Xcode 27.1。使用旧版 Xcode 构建的应用无法延伸至状态栏和摄像头区域下方。

由于 iPhone Duo 支持多种屏幕尺寸、布局和方向，你的应用需要从容适应所有这些情况。请检查应用在外屏和内屏上的显示效果，以及设备闭合、展开或部分折叠时的表现。在每种形态下旋转 iPhone Duo，观察应用布局如何响应。

为了让应用在 iPhone Duo 上正常运行，开发者应避免依赖固定的 iPhone 屏幕尺寸，例如 UIScreen.main.bounds。视图应改为相对于其容器确定尺寸。Apple 建议使用标准布局容器，包括 SwiftUI 堆栈、导航视图和分栏视图、标准标签栏以及 UIKit Auto Layout。这种方式可以确保所有视图根据可用空间的变化自动适配，无论设备正在使用外屏、完全展开的内屏，还是带有摄像头遮挡的部分折叠形态。

此外，Apple 也不建议开发者根据 userInterfaceIdiom 或 UIInterfaceOrientation 做出布局决策。应用应改为依赖尺寸类，即观察"horizontalSizeClass和"verticalSizeClass的变化"，使应用 UI 适应不同尺寸。

iPhone Duo UI 的一项重大变化是工具栏和导航栏的位置：在某些设备形态下，它们可能垂直显示在屏幕侧边。使用 UIToolbar、UINavigationBar 或 UITabBar 创建自定义导航或工具栏的应用，可能无法正确适配。在这种情况下，Apple 建议使用标准导航和工具栏 API：在 SwiftUI 中为 NavigationStack 或 NavigationSplitView 添加 toolbar(content:) 修饰器；在 UIKit 中，则为已添加到导航控制器的视图控制器设置工具栏项目。

如前所述，iPhone Duo 还引入了新的保留区域。这些区域对应将屏幕分隔为不同部分的折痕，以及摄像头等硬件组件遮挡应用内容的区域。

框架提供的视图和容器会自动进行调整，以避开折痕或内屏上的前置摄像头，但你的自定义视图需要采用灵活的方法来识别分隔区域和遮挡区域。[…] 内屏前置摄像头启用时可能会遮挡视图，而外屏前置摄像头始终会遮挡视图。

开发者可以在 SwiftUI 中使用 reservedRegions(kind:options:layoutDirectionBehavior:)，在 UIKit 中使用 reservedRegions(kind:options:)，获取所有保留区域。

最后，开发者还应考虑到，iPhone Duo 可以通过外屏摄像头、内屏摄像头和后置摄像头拍摄照片与视频。打开、闭合或旋转设备都可能改变当前启用的摄像头。开发者可以根据摄像头朝向选择合适的摄像头"。

应用开发者 Steve Troughton-Smith 在 Mastodon 上对 Apple 的公告作出了批评性回应，称“这就像一个全新平台突然发布，却只提前一个月通知"”。用户 David 也表达了类似看法，他“想知道未来几个月究竟会有多少应用愿意适配 Duo”。

iOS Dev Weekly 编辑 Juan Marin 指出，这并不是 iOS 开发者第一次面对类似要求"：

漂亮设备的问题在于，它们到来时总会带着作业，而作业永远是我们的。[…] 每一次，Apple 都提前多年告诉我们应该如何准备。每一次，我们中的大多数人却都是事后才开始行动。

不过，他也承认，大家早已知道“UIScreen.main.bounds 是一个只等某款设备出现便会暴露的 Bug，而现在，这款设备终于来了”。

原文链接：https://www.infoq.com/news/2026/09/apple-iphone-duo-api/"

MCP 终于无状态了，但状态并没有消失，只是被“甩”给了应用

作者：Leela Kumili — Wed, 07 Oct 2026 02:00:00 GMT

亚马逊云科技介绍了最新版模型上下文协议（MCP）规范如何改变远程 MCP 服务器的部署方式。新规范移除了协议层会话，允许请求到达任意可用的服务器实例。这项变更消除了协议对粘性会话和共享会话存储的要求，在简化水平扩展的同时，也将状态管理及其他职责转移给了周边基础设施。

更新后的 MCP 规范移除了 initialize 和 initialized 握手流程以及 Mcp-Session-Id 标头。因此，传统负载均衡器可以将每个请求独立路由到任意服务器实例。该规范还引入了可选的 server/discover 操作，供需要在调用工具之前了解服务器能力的客户端使用。

对于亚马逊云科技上的部署而言，这可以消除专门用于维护 MCP 协议会话的基础设施。AWS Architecture Blog 作者 Anand Komandooru、Steven DeVries 和 Haleh Najafzadeh 介绍了如何用传统请求路由取代具有会话亲和性的路由，并移除仅用于保存 MCP 协议状态的会话存储。他们还将 AWS Lambda 列为一种适合请求—响应模型的部署选项，因为该协议不再要求持久化会话连接。

协议状态与应用状态之间的区别也成为社区讨论的焦点。Michael Madsen 在 LinkedIn 上谈及该规范时，将这项变化总结为：

协议是无状态的，但你的应用不必如此。

MRTR 取代了此前需要保持流连接的服务器发起型请求，允许通过 input_required 响应及后续请求完成多步骤交互。新的 Mcp-Method 和 Mcp-Name 标头支持网关路由和限流，W3C Trace Context 则支持分布式追踪。ttlMs 和 cacheScope 提供缓存控制能力。

亚马逊云科技将这些变更映射至其面向智能体 AI 的 Well-Architected 指南，涵盖监控、追踪、安全和工具集成。流恢复能力也已被移除，因此客户端可能需要重试被中断的操作。对于会产生副作用的工具调用，这进一步凸显了幂等性的重要性。

早期实现工作表明，现有基础设施仍然需要一条过渡路径。Apify 的 MCP 服务器项目正在现有的有会话服务器之外实现无状态支持，并通过路由和一致性测试覆盖两个协议版本。

因此，对于仍需支持旧版 MCP 客户端的部署，迁移仍然十分重要。亚马逊云科技建议在网关处追踪协议版本，并在旧版流量完全消失之前保留会话基础设施。MCP 项目还制定了一项功能生命周期策略，为弃用功能提供明确的迁移期。

原文链接：https://www.infoq.com/news/2026/09/aws-stateless-mcp/"

用 Harness 工程打造 SRE 可控的生产环境｜QCon上海

QCon全球软件开发大会 — Wed, 07 Oct 2026 02:00:00 GMT

从「构建 AI」到「驾驭 AI」，100+ 实战案例拆解 AI Native 时代的工程新实践！

2026 年 QCon 全球软件开发大会大会 · 上海站"

腾讯 & 高级 SRE 工程师王杰已确认出席 “理性驾驭 AI 的 SRE 可靠性工程"” 专题，并发表题为《用 Harness 工程打造 SRE 可控的生产环境"》的主题分享。随着 AI 能力进入 SRE 领域，可靠性工程本身的不可靠因素也在增加。业界公开的 SRE Agent 实践大多停留在告警和故障分析这类只读场景避免对生产环境进行操作，价值有限。LLM 的概率性输出、存在幻觉且难以复现，与 SRE 要求生产环境的确定性、准确性、一致性存在尖锐的矛盾，并且这个矛盾不会因模型变强而消失。我们的解决方案不是让 LLM 变确定，而是用 Harness 工程管控它的不确定性，这也是“理性驾驭”的真实含义。

腾讯游戏基于已完成的游戏应用交付的代码化与 GitOps 引擎建设，发布变更本质上变成了改代码改配置，恰好落在 AI 当前最成熟的能力区间 — Al Coding。这套方案同时给了 Al 稳定的上下文，也给了它一条无法绕过的变更护栏：变更必经 Git 与人工 Review。在此之上，王杰团队让多个 SRE Agent 与人协作，参与到发布变更、扩缩容、配置与基础设施调整、故障修复等基础运维执行的动作中；每次任务的过程被完整记录，经评估后沉淀为可跨业务共享的能力，从而提升整体 SRE Agent 的运维能力。

本次分享结合腾讯游戏的真实案例，分享 GitOps Harness 工程底座与不可绕过的变更护栏、人与多 AI Agent 的协作机制、先评估再沉淀的经验复用设计，以及可复用的落地经验与踩坑教训。

王杰，腾讯 IEG 技术运营部 GitOps 平台负责人，12 年以上游戏 SRE 和运维产品设计经验，主导推动腾讯游戏运维从“过程式命令编排”到“声明式管理”的体系演进，孵化 PowerAPP GitOps 应用交付与管理平台，在腾讯游戏内部被广泛应用。他在本次会议的详细演讲内容如下：

演讲提纲1. 行业趋势与挑战业界现状：SRE Agent实践普遍停留在只读分析层，本质是只看不动手根本矛盾：LLM 概率性输出与生产环境确定性要求的冲突，不会因模型进化而消失协作缺口：对话框式的单人单线程无法承载团队协作经验难以复用：Agent 完成的任务缺乏质量判定，经验散落在个人与会话中，无法沉淀为组织资产2. 案例：如何让 SRE Agent 敢碰生产环境工程底座：全面代码化与 GitOpsAgent 专家团编制Harness 四段闭环与变更护栏实践案例：SRE Agent Team 协同完成云基础设施和游戏应用的扩容3. 案例：如何让 SRE Agent 与人之间协作看板与 Issue 的状态传递机制面向业务而非个人的 Agent 记忆实践案例：端到端告警自愈闭环—告警到达、自动建单、生成变更、人工审核、合并执行、观测验证4. 案例：如何让经验越用越强工单与 AI 工时从工单到 Skill5. 总结与展望组织层面的提效路径：经验沉淀在业务而非个人手上，提效从个人推进到组织SRE 左移和上移：从过程中盯着纠偏，转向事前定义边界与验收条件什么该被长期沉淀：不是操作技能，而是“什么算做完、什么情况必须停下来找人"的判断标准实践痛点不同业务的游戏架构差异很大，如何低成本建立并持续维护业务上下文，让 Agent 的记忆随使用增长而不失真、不过期当 AI 能变更生产环境之后，如何自动生成足够充分的变更影响分析，让 SRE 在几十秒内判断风险多个 Agent 接力时，如何固化诊断证据链，避免下游重复探路、误读上游结论，同时把上下文与调用的成本控制在可接受范围Skill 越积越多之后，如何做可见性分级与定期清理演讲亮点让 SRE Agent 参与基础运维的方案：结合 GitOps 引擎、多 Agent 专家团编制与评估治理体系的 SRE 执行方案真实业务场景下的落地实践与踩坑经验：结合腾讯游戏的真实案例，分享 SRE Agent 从只读分析到代码变更的演进过程与实际效果听众收益了解如何让 SRE Agent 参与到基础运维的执行动作中：发布变更、扩缩容、配置与基础设施调整、故障修复了解人与多 Agent 协作中状态传递、业务记忆和能力治理的真实难点了解一套从代码化、GitOps、人工 Review 到观测验证的生产级的 Harness 架构

查看更多详情可扫码或联系票务经理 18514549229进行咨询。

从依赖专家到开发者自助：一家银行的平台文化转型

作者：Ben Linders — Tue, 06 Oct 2026 07:00:00 GMT

平台是一套协作系统，而不是基础设施。文化源于结构：平台团队可以开设开放支持会，为作出贡献的开发者设立超级用户奖，并建立开放的共享标准，以培养工程思维。Marcy Paramonova 和 Stéphane Cusin 在 KubeCon & CloudNativeCon Europe" 的演讲《在银行中构建云原生文化"》中解释道。

Paramonova 表示，开发者和产品团队依赖平台团队。平台团队也依赖应用团队，双方都需要向前发展；为此，他们需要共享标准。

Paramonova 和 Cusin 在《开源如何促进平台创建中的协作"》中解释说，平台并不是一块基础设施，而是一套承载大量沟通的协作系统。

Paramonova 认为，云原生是一种文化转变，而不仅仅是技术转变；他们的转型历程同样需要文化上的转变。平台团队开始提供开放支持会，开发者可以前来，与他们一起解决问题：

我们希望摆脱通常围绕工单开展的支持方式，为用户提供一些新鲜的东西。许多人对此产生了兴趣，包括基础设施、网络安全、网络、身份和云团队的人员。我们坐在一起、分享解决方案，并通过协作帮助解决问题。

Cusin 表示，如果每个操作都需要提交工单、人工干预或平台工程师的直接支持，我们就会无意中形成一种依赖文化。团队会等待平台团队，而不是学习如何独立运营。

Paramonova 提到，他们举办了一些活动，以表彰对平台的采用。他们为积极参与平台改进的开发者设立了超级用户奖：

他们的反馈有时让我们难以接受，甚至有些痛苦，但实际上帮助我们创造出了更美好、更优秀的东西。因此，我们对此心怀感激。

他们组织的这些活动改变了他们看待和重视人类技能的方式。

Paramonova 表示，当你使用采用开放标准的开源技术时，你的技能会变得非常容易迁移。她补充道，你不需要从零开始重新学习，而是可以在开放技术之间共享的共同基础上继续构建。

Paramonova 认为，工程思维是最重要的。重要的不是你今天知道什么，而是你接受新技术、学习新技术以及执行和运营这些技术的能力：

成为工程师意味着解决问题、热爱解决问题，并与他人分享你对解决问题的热情。

文化源于结构。你不能等待文化自行出现；你必须设计能够创造出所期望文化的系统。Cusin 解释道：

如果你的团队抱怨总是受到打扰，不要责怪其他团队。你应该问问自己：你是否定义了一套让别人与你取得联系的结构？

Cusin 总结道，Kubernetes 改变的不只是我们的平台，它还改变了我们组织构建软件的方式。

演讲结束后，InfoQ 采访了 Marcy Paramonova" 和 Stéphane Cusin"。

InfoQ：你们的工程文化是如何随着时间发生转变的？

Stéphane Cusin：我们从第一天起就确立了一项原则：平台能力绝不能依赖人工干预。团队不必提交工单并等待工程师进行更改，而是通过声明式配置和自动化工作流与平台交互。例如，只需在 Git 中进行简单的配置更改，就可以启用某项能力，随后我们的 GitOps 流程会自动应用这一更改。这既创造了自助式体验，也让平台采用情况具有完整的可追溯性和可见性。这种方法改变了我们运营平台的方式。现在，我们可以了解哪些能力正在被采用、哪些能力已不再需要，以及哪些用户会受到某项变更的影响。它已经让我们能够安全地停用未被使用的功能，并有信心地推动团队迁移到更新的平台能力。

InfoQ：你们是如何设计系统，从而创造出希望建立的文化的？

Marcy Paramonova：你无法通过命令创造一种文化，但可以设计出让某些行为自然发生的结构。对我们而言，这意味着围绕协作建立固定机制，而不是只在口头上谈论协作。我们每周举办两次“Genius Bar”，每次两小时。如果你对平台有疑问，如果某些功能没有按照预期工作，或者只是想了解某个组件如何融入整体，就可以来这里。不需要提交工单，也不需要等待某个人的日程出现空档。它让反馈循环保持简短，也让我们能够诚实面对问题，因为当某些内容令人困惑或使用起来很痛苦时，你很快就会听到反馈。我们还会举办用户洞察会，在会上分享优先事项、已完成的工作以及获得的可见性，并与用户一起确定优先级，而不是替用户作决定。我们也会进行演示，展示已经发布的内容、路线图上的内容，以及日常应该如何使用平台。在内部，平台团队也有自己的规划会议，以保持协调一致，并为审慎决策留出空间，而不是只进行被动响应式的工作。这些做法都算不上革命性。但当你把这些节奏叠加在一起时，所期望的文化就会从你构建的结构中逐渐产生。这不是魔法，但也绝非偶然。Cusin：我们努力让平台决策变得可见。平台能力通过版本化制品、可复用的部署模式和有文档记录的接口进行交付，而不是依赖团队之间的个别约定。这在整个组织中创造了一致性和共同理解。另一项重要的设计原则是，每个平台功能都应该有自己的生命周期。我们希望了解谁在使用某项能力、如何使用，以及它是否仍在创造价值。这种可见性使我们能够有意识地演进平台，而不是让复杂性随着时间不断累积。从许多方面来看，我们的平台成为强化所期望行为的一种机制：用自助服务取代工单驱动的运营，用标准化取代定制化，用透明度取代部落知识，用共同所有权取代对少数专家的依赖。当这些原则被嵌入平台本身时，所期望的文化就会成为人们最容易采用的工作方式。

原文链接：https://www.infoq.com/news/2026/09/collaborative-platform-culture/"

AI + SRE ≠ AISRE：AI 如何真正进入生产运维闭环｜QCon上海

QCon全球软件开发大会 — Tue, 06 Oct 2026 02:00:00 GMT

从「构建 AI」到「驾驭 AI」，100+ 实战案例拆解 AI Native 时代的工程新实践！

2026 年 QCon 全球软件开发大会大会 · 上海站"

携程 & 大数据平台 SRE 总监周昕毅已确认出席 “理性驾驭 AI 的 SRE 可靠性工程"” 专题，并发表题为《AI + SRE ≠ AISRE：AI 如何真正进入生产运维闭环"》的主题分享。AI 正快速进入研发、测试与运维场景，但“给 SRE 加一个 AI”并不等于真正的 AISRE。尤其在大数据平台中，故障链路复杂、组件依赖繁多、运维知识高度依赖专家经验，AI 从“辅助分析”走向“生产执行”仍面临信任、知识与闭环等问题。本次分享将结合携程大数据平台的实践，围绕稳定性、运维效率与成本治理三个典型场景，分享 AI 如何真正进入 SRE 的生产闭环。

周昕毅，携程大数据平台 SRE 总监。毕业于同济大学软件学院，在云计算、大数据、基础设施运维及 SRE 等领域有 20 年工作经验。目前负责携程大数据基础平台建设及运维管理相关工作。参与编写 SREelite《SRE 实践白皮书》。他在本次会议的详细演讲内容如下：

演讲提纲1. 开场：AI 到底能不能接管 SRE？从三个真实问题切入：告警来了，AI 能不能自己判断？服务异常，AI 能不能自己修？存储成本上涨，AI 能不能自己找出浪费？结论：AI 能回答 SRE 的问题，不代表 AI 能承担 SRE 的工作。2. 从 AI 辅助到 AI 闭环：SRE 的 AI 化到底意味着什么？AI 看懂告警、日志、指标AI 关联上下文并定位根因AI 生成处置方案AI 调用工具执行操作AI 验证执行结果并形成反馈结论：真正的 AISRE，不是增加一个 AI Copilot，而是让 AI 进入完整的运维闭环。3. 实践一：从“告警”走向“自愈”——AI 如何参与生产故障处置？痛点还原告警噪音大，定位慢，人工处置依赖经验闭环体系设计告警收敛与分级策略根因定位：从"报警"到"给答案"自愈执行：预案库加自动触发机制人工审核兜底：人监督AI的落地形式效果平台故障 MTTR 降低 50%关键踩坑点：自愈误操作的防护机制4. 实践二：从“专家经验”到“智能诊断”——核心组件故障如何让 AI 真正理解？痛点还原组件种类多，问题现象分散，诊断依赖资深专家工具设计思路诊断知识的结构化沉淀，包含案例库、规则库AI辅助分析：日志理解加指标关联工具化设计：诊断能力作为可调用服务效果与经验新人上手时间缩短，on-call 压力下降踩坑点：AI 给出错误诊断建议的处理机制5. 实践三：从“资源监控”到“成本治理”——AI 如何参与存储优化决策？痛点还原存储成本持续膨胀，人工治理效率低工具建设思路数据访问特征采集与冷热识别模型自动化分级存储策略推荐与业务方的协作闭环效果存储单价下降 20%踩坑点：冷热判断误判对业务的影响及补救措施6. 总结：从 AI 辅助走向 AI 原生运维AISRE ≠ AI + SRE 的简单叠加三个实践背后的共同基础演进路径与未来展望实践痛点1. 自动化执行的信任建立需要过程告警自愈闭环上线初期，工程师对"AI自动操作生产环境"普遍存在顾虑。需要经历"只看不动→人工确认后执行→低风险操作自动执行"的渐进式信任建立过程，不能一步到位2. 知识沉淀是需要建立闭环机制而非一次性工程智能诊断工具的核心是知识库，但故障经验高度依赖老专家，提炼和结构化的过程阻力大、耗时长，且随着组件版本迭代需要持续维护，容易出现"知识库上线即过时"的问题。3. 效果评估的量化存在难度目前虽然通过 MTTR 可以进行一定程度的量化，但 MTTR 的影响因素不能完全归因于AISRE的相关实践演讲亮点SRE 相关实践具有普适性，对其他 SRE 团队有参考价值，不只是晒成果，而是给同行一套可复用的方法论听众收益1. 一个可复用的方法论框架“数据友好→开发友好→运维友好”三层递进模型，帮助听众评估自身团队的 AI 落地成熟度，避免跳步建设的陷阱2. 三个可落地的工程实践告警+自愈闭环的设计思路与防误操作机制大数据组件智能诊断工具的知识结构化方法Storage Insight 冷热数据识别的实现路径每个实践均来自携程生产环境，有具体踩坑经验可借鉴。3. 一个清醒的认知校准明确“AISRE ≠ AI + SRE 简单叠加"，帮助听众识别团队当前瓶颈到底是 AI 能力不足还是基础设施不够成熟，避免在错误的层面投入资源4. 真实的效果数据参照MTTR 降低 50%、存储单价下降 20%，为听众在内部推动类似项目时提供可引用的行业参照数据

查看更多详情可扫码或联系票务经理 18514549229进行咨询。

一边是 WebGPU 视觉革命，一边是浏览器垄断争议：Canvas UI 发布 35 个组件

作者：Daniel Curtis — Tue, 06 Oct 2026 02:00:00 GMT

Canvas UI" 是由 React Bits" 作者 David Haz 推出的一款开源组件库。它是首个基于实验性 HTML-in-Canvas API" 构建的组件库，可以在真实、可交互的页面内容上运行 GPU 特效。

该组件库提供了 35 个组件"，包括由指针驱动的流体、火焰、玻璃透镜、ASCII 滤镜、VHS 颗粒和粒子显现效果。每种效果都提供使用 GLSL 实现的 WebGL 版本，以及通过 vgpu" 使用 WGSL 实现的 WebGPU 版本"，并为 React、Solid、Preact、Vue 和 Svelte 提供封装，同时还支持无依赖的原生 TypeScript。

大多数组件并不是绘制一张静态位图，而是使用 Chrome 的 html-in-canvas API，在 Canvas 中布局实时 DOM，通过 drawElementImage 捕获内容，将其上传为纹理，再利用着色器进行变形处理。文本仍然可以选择，链接依旧能够点击，内容也会保留在无障碍树"中。这些组件并非以软件包形式发布，而是通过一个兼容 shadcn 的注册表，以源代码形式分发：

npx shadcn@latest add @canvas-ui/liquid-react

要获得完整体验，需要在 Chrome 中启用 canvas-draw-element 标志，或者使用一个源试用"令牌。该源试用从 Chrome 148 持续到 Chrome 150，并且令牌只能绑定到一个域名。在其他环境中，html-in-canvas 特效会回退为普通 GPU 叠加层，或者保持被包裹内容的原样渲染；3D 对象组件则可以在所有环境中运行。

由于代码会被直接复制到项目仓库中，升级时需要重新运行安装命令，并处理本地修改。切换渲染器通常只需将已安装的文件替换为注册表中带有 -webgpu 后缀的版本，同时添加 vgpu 和 @webgpu/types。项目文档"还指出，Chrome 150 对 texElementImage2D 和 copyElementImageToTexture 的修改不需要迁移，因为内容捕获通过 2D API 完成，纹理上传则使用标准的 texImage2D 或 copyExternalImageToTexture。

shadcn 称这是他们见过的最令人印象深刻的注册表之一"，Chrome for Developers" 账号也表示，很高兴看到 html-in-canvas 为新框架赋能。Flavio Copes 在一篇详细拆解文章"中称赞了那些并不华丽但十分扎实的工程实现：Liquid 组件离开屏幕可视区域时，会通过 IntersectionObserver 停止动画循环；它会遵循 prefers-reduced-motion 设置，并在组件卸载时释放纹理、程序和事件监听器。他建议使用一个足够亮眼的特效，而不是同时堆上六个，并避免在仪表盘、结账流程和文档网站中使用这些效果。

在 Hacker News" 上，一名评论者看到演示页面中的提示横幅后，对这种仅限 Google 浏览器使用的能力表示怀疑：

使用 Chrome……但我们不是应该抵制这种可能让 Google“拥抱、扩展再消灭”其他技术的做法吗？尽管有这种遗憾而又冷门的担忧——真希望它不是冷门问题——还是要向作者致敬。

另一名用户回应：

标准化流程要求先有实现，之后才能制定标准。WHATWG 相关议题中最近的评论分别来自 Jake Archibald（Mozilla）和 Anne van Kesteren（Apple）。这不是 Google 单方面推动的项目。

WICG 说明文档"中关于无障碍访问的讨论仍在继续，其中包括如何暴露几何信息尚未更新的可绘制子树。

Paper Shaders" 提供从 npm 安装的零依赖 Canvas 着色器，但这些着色器只能以纹理形式位于内容后方或周围。同一作者开发的 React Bits 则直接为 DOM 添加动画。Canvas UI 是唯一将页面本身作为着色器输入的方案，这也正是它依赖 Safari 和 Firefox 尚未实现的功能的原因。

该项目采用 MIT 许可证加 Commons Clause，允许商业使用，但不允许转售这些组件。代码仓库"的 Star 数已经超过 4600，组件注册表也已支持 MCP"，允许智能助手通过 shadcn MCP 服务器浏览并安装组件。

原文链接：https://www.infoq.com/news/2026/09/canvas-ui-webgl/"

InfoQ 推荐

黄仁勋为微软站台：没有 Windows 就不会有英伟达，Satya 当场“讨市值”

Windows 不只 AI PC

本地支持更大规模模型

Copilot中的“混合智能”

黄仁勋与 Satya：第一次重构个人电脑

Agent 为什么需要操作系统级安全原语

“混合智能”意味着什么

黄仁勋：第一次真正“重做”个人电脑

Agent 代表用户行动后，谁来承担责任？

Codex 和 Claude Code 都跑偏了，前 OpenAI 研究员称 Jev 出现前 AI 世界是个悲剧

太长不看版：

Jev发布的第一周，创始人的情绪糟糕透了

从模式坍塌到校准失真：RLHF 的另一面

Jev 的开发理念：AI 做决定时，不能突然拒答

“最苦涩的教训”：先选对任务，再谈模型和数据

“Jev 出现之前的 AI 世界，是个悲剧”

爆红之后，Jev 更在意什么

模型不能说变就变：Jev 如何兑现“可靠”？

不追 Benchmark，追极致的“每美元智能”

别让 AI 一口气干完：把任务拆小，出错才好查

“决策模型早就有了”，Jev 到底想做什么？

发布前没人看懂，发布后用户开始教他们怎么用

从暗数据到智能软件：Jev瞄准四类核心场景

“放慢前沿进展”之外，还有别的研究路线吗？

从 InstructGPT 到 TypeSafe AI 创业

别再复制前沿实验室：先找到你的 North Star

OpenAI 高管亲述：我们是怎么在一周内做出 Jev 竞品的

太长不看版：

当 AI 有了自己的电脑，哪些事可以交给它？

计算机操作迈过新阶段：更会看懂界面，也更能排错提速

工具调用不再干等：OpenAI API 如何让模型边执行、边推理

受 Jev 启发？却不止于结构化输出：OpenAI 的 Decisions API 如何追求更快决策

从 API 到智能体产品：性能、缓存与上下文管理

@ 一下就能派活？谷歌推出办公 Agent，拥有独立账号、能够创建子 Agent，还能调用 Claude

一个 Agent，就能完成跨应用办公任务

能创建子 Agent，还能拥有自己的企业邮箱

不只使用 Gemini，Google 的 Agent 还能调用 Claude

Agent 拥有独立身份后，如何管理权限？

与 Meta Muse 相比，Google Agent 有什么不同？

Modal 破解 Kubernetes 限制，在几秒内扩展 100 万个并发沙箱

AI 落地，此刻发生 ｜1024 模力工场 AI 社区日，首批报名开启

为什么叫“AI落地，此刻发生”？

上午主论坛：AI落地，此刻发生

下午开启：玩转四大空间

造物市集：全天的自由展示区

扫码报名，这场活动我们一起办

乱序 HTML 流技术从 JavaScript 框架转移到浏览器中

全球最大独立 AI 原生影视公司，开始打破工具与制片厂的边界

成为技术供应商还不够，Utopai 要做新一代制片厂

影视行业，需要怎样的 AI 生产基础设施

Utopai X：面向影视制作定制的专业模型

PAI：把模型能力组织进完整影视制作流程

结语

Cloudflare 通过测量源站 TLS 偏好将握手重试率从 52% 降至 3.7%

从 Demo 到生产：AI Agent 缺的到底是什么？

Agent = Model + Harness

Harness 分成哪两部分？

两条路线：托管还是自己管？

该选托管，还是自己搭？

用 FinBot 看看生产级 Agent 真正缺什么

构建 Agent

统一模型访问

成本控制

可观测性

先看两套方案分别长什么样

构建 FinBot：工具、MCP、记忆与检索

模型访问

在 AgentCore 上

自主管理

成本控制：别等账单来了才发现 Agent 跑疯了

在 AgentCore 上

自主管理

可观测性：出了问题，至少要知道发生了什么

在 AgentCore 上

自主管理

最后：生产级 Agent，本质上还是架构问题

全球扩散语言模型最大融资诞生：经纬、顺为、君联数亿元押注扩散智能DiffuSpace

打造下一代通用模型，扩散语言模型进入Scaling加速期

从源头创新到持续领先，DiffuSpace四年押注dLLM

AI 落地，此刻发生｜1024 模力工场 AI 社区日，首批报名开启

主持人：那解决方案也许就是不要让这些能力过度保密，而是适度展示，让更多人参与。我自己的看法是，你希望有很多人都在用智能去挑战各类系统，而不是让某一个小团体秘密掌握所有能力。