InfoQ 推荐

Meta ZGateway 在每秒处理超过 10 亿次操作的同时，将 ZippyDB 的连接数减少了 19 倍

作者：Leela Kumili — Mon, 12 Oct 2026 05:00:00 GMT

Meta 推出 ZGateway，这是一个面向其广泛使用的分布式键值存储系统 ZippyDB 的无状态代理层，旨在解决由超过 100 万个客户端主机带来的连接和可靠性挑战。该网关每秒处理超过 10 亿次操作，并承担了 ZippyDB 约 40% 的流量；而根据 Meta 的模型估算，该架构将持久连接总数减少为原来的约 1/19。

ZippyDB" 支持在 Meta 的全球分布式基础设施上处理产品元数据、计数器、配置及其他工作负载。在直接访问模型中，客户端会连接到提供所需分片的数据库主机。单个客户端可能访问分布在数十万台数据库主机上的数万个分片，从而形成了密集的“多对多”连接网格。Meta 表示，连接风暴可能会导致文件描述符耗尽和内存不足的情况。

ZGateway 在客户端与 ZippyDB 服务器之间部署了一个托管代理层。客户端与区域网关主机之间保持粘性连接"，而数据库服务器则从受控的网关集群接收连接。ZGateway 作为通过 ServiceRouter"（Meta 的超大规模服务网格解决方案）发现的区域层运行，从而使客户端始终位于其网关附近。该网关使用 Meta 现有的 C++ ZippyDB 客户端作为请求引擎，并同时支持纯代理和读透式缓存层。根据 Meta 的模型估算，每个主机的连接数将减少约 97% 至 98%，而持久连接总数将减少为原来的约 1/19。

这一变更还改变了共享流量管理的位置。ZGateway 可以对请求进行身份验证和授权，应用基于租户的准入控制，解析分片，使用本地缓存，并在将请求转发至 ZServer 副本之前对请求进行批处理或合并。由于网关能够看到来自多个客户端的流量，所以它可以将单个客户端库在不同进程间无法观察到的请求进行合并。

连接池、服务网格、CDN 和 API 网关也使用该代理模式，不过它们的职责和可扩展性权衡各不相同。Meta 之前对 ZippyDB 的描述表明，数据库本身已经提供了托管分片、复制、故障检测和容量管理功能，而 ZGateway 则在这些功能之前添加了一个共享的流量管理层。

额外增加的网络跳数是有意做出的权衡。在 LinkedIn 的一篇博文"中，Sherbrook 架构师 Md Shuvo" 特别强调了这一点：

实际上，额外增加一个网络跳数能改善整体延迟，因为这可以使数据库节点免于承受连接管理带来的巨大开销。

ZGateway 还为负载均衡、跨区域容错、缓存和过载保护提供了集中管理平台。在 CPU 利用率超过 90% 的受控测试中，约 1350 个租户存储桶中有 6 个将流量分流，而其余租户处理了 99.9% 的请求且未出现任何拒绝处理的情况。Meta 可以按服务、分片前缀、百分比或区域逐步路由流量，并配备了用于回滚的全球紧急关闭开关。

Meta 计划将所有 ZippyDB 流量通过 ZGateway 进行路由，同时探索基于代理的控制机制、与 ZServer 的选择性共置，以及采用多进程架构来实现更强的故障隔离。

原文链接：https://www.infoq.com/news/2026/09/meta-zgateway-zippydb-proxy/"

Radicle 披露了可能导致私有仓库以明文形式暴露的关键漏洞

作者： Olimpiu Pop — Mon, 12 Oct 2026 02:15:00 GMT

点对点代码协作网络 Radicle 披露了其核心网络协议中存在的两个关键安全漏洞。这些漏洞会导致迄今为止所有节点版本的机密性不复存在。这些缺陷使得网络路径上的攻击者能够以明文形式读取私有仓库的数据，并冒充连接白名单中的节点。由于现有协议的设计缺乏版本协商功能，项目维护者无法部署向后兼容的网络层缓解措施，所以他们的建议是立即暂停明网私有仓库的运行，直至完成重大的架构改造。

该漏洞披露报告"指出了 radicle-node（负责管理对等节点同步的主要守护进程）内部存在的两个截然不同的协议层缺陷。独立工程师 Kostis Maninakis" 发现，虽然 Radicle 在建立连接时会执行 Noise Protocol Framework 握手流程，但该守护进程会在协商完成后立即丢弃生成的加密状态。

Radicle 采用了基于原始 TCP 套接字的三消息 Noise XK 握手模式。发起方和响应方交换临时密钥和长期公钥，并以此推导出两个对称会话密钥。这一操作过程在密码学中被称为“拆分”（split）。然而，radicle-node 会将这些推导出的密钥以未加密的形式保存在内存中。此后的一切通信，包括 Gossip 元数据、路由表和原始 Git 对象包，均以明文的形式直接通过未加密的 TCP 套接字进行传输。

该协议的分解过程如下：

除了传输过程未加密外，连接握手过程还存在一个身份验证漏洞。攻击者可以通过提供与白名单中的对等节点关联的伪造节点 ID 来建立连接。结合上述情况，路径上的窃听者可以被动地捕获以明文形式传输的有效节点 ID，随后利用该身份验证漏洞冒充已获授权的对等节点，直接从种子节点拉取私有仓库。

该核心缺陷源于底层 Rust 代码库 Heartwood 中传输配置与帧分发之间的架构差异。在初始化过程中，网络状态机处理 Noise 握手，但帧分发层在写调用期间绕过了加密例程。

在捕获两个本地守护进程之间的网络流量并进行检查后发现，握手完成后的传输帧中并不包含任何身份认证标签或流密码：

0000 72 61 64 01 03 41 20 00 7c 32 6d 5e b2 1e ab 5d rad..A .|2m^...] 0010 89 1d 11 64 c8 51 a8 fa 75 c0 2a fd c9 c3 04 0e ...d.Q..u.*..... 0020 52 e0 41 05 06 eb 4f 99 00 00 00 24 50 41 43 4b R.A...O....$PACK

帧布局以原始的 Radicle 协议魔术字节序列开头，紧接着是未加密的 Git 压缩文件头。由于传输帧省略了消息认证码，所以中间网络设备可以被动地记录或重新排序数据包。Git 内容的完整性得以保持，因为 Git 对象采用的是内容寻址，而且引用经过了加密签名——这意味着攻击者无法在不让签名失效的情况下修改仓库内容，但传输的机密性却无法得到保障。

使用 Radicle 的软件团队必须将通过明网连接克隆、推送或分发的所有私有仓库视为已遭泄露。工程负责人应立即轮换存储在这些仓库中的任何加密令牌、凭据或生产环境密钥。

在修补后的二进制文件发布之前，各团队必须将节点操作限制在隔离的覆盖网络内。运维人员可以在已授权的主机之间配置加密的 WireGuard 隧道或 SSH 端口转发：

# Encapsulate node-to-node replication through SSH forwarding ssh -N -L 8776:127.0.0.1:8776 seed-node.internal.infra # Direct local radicle-node to synchronize via loopback tunnel rad node connect 127.0.0.1:8776

将全局代理标志设置为指向 Tor 出口节点并不能解决这个安全隐患，因为离开出口节点的流量会以明文的形式流经公共互联网。在现有版本中，只有当连接完全经由已通过身份验证的 Tor 洋葱服务或 I2P 守护进程进行时，才能真正地保持点对点机密性。

维护人员已经确认，自定义的 Noise 传输层将被完全弃用，转而采用 Iroh——一个基于 QUIC 和 TLS 构建的开源点对点网络协议栈。由于当前节点版本的握手帧中缺乏协议版本协商字段，所以如果要在现有的网络结构上引入加密组帧补丁，将不可避免地导致连接崩溃。向 Iroh 的过渡将彻底打破网络向后兼容性，一旦发布新的大版本，旧版 1.x 安装与已升级节点之间将产生硬性网络分区。

原文链接：https://www.infoq.com/news/2026/09/radicle-network-vulnerabilities/"

阿里巴巴中国电商事业群/飞猪CTO陈烨博士已确认出席QCon上海，分享“从 Coding 到消费：AI 的下一场革命”

QCon全球软件开发大会 — Mon, 12 Oct 2026 02:00:00 GMT

从「构建 AI」到「驾驭 AI」，100+ 实战案例拆解 AI Native 时代的工程新实践！

2026 年 QCon 全球软件开发大会大会 · 上海站"将于 10 月 22 日-24 日举办，来自阿里巴巴、腾讯、字节跳动、美团、小红书、蚂蚁集团、无问芯穹、阶跃星辰、快手、百度、网易、微软、华为、携程、平安等企业的一线技术实践者，将从 AI 应用、Agent 工程、AI Coding、基础设施、数据系统、质量、安全、SRE 以及具身智能等方向，分享 AI 进入真实生产环境之后正在发生的变化。

阿里巴巴中国电商事业群、飞猪CTO，陈烨博士已确认出席主题演讲"，并发表题为《从 Coding 到消费：AI 的下一场革命"》的主题分享。

AI 为什么先学会写代码，而不是先学会点外卖？一个关键原因是，Coding 天然拥有编译器、单元测试、CI 等“Verifier”：反馈密集、即时且客观，任务又完全发生在数字世界里。相比之下，消费场景的反馈更加稀疏、延迟且主观，交易与履约还要穿透商家、库存、配送等真实的物理世界。

这意味着，AI 从 Coding 走向消费，并不只是把一个更强的模型接入消费应用，而是要重新构造一套面向真实世界的验证与执行闭环。本次演讲将从“可验证性”出发，分析 AI 为什么沿着 Coding → Agent → 消费的路径演进，以及消费级 AI 真正的难点究竟在哪里。

Frontier Lab 的“Infra × Data × Compute”配方翻译到消费场景：如何构建 AI-Native 的供给与服务网络，如何将静态与实时消费数据转化为训练资产，以及如何通过后训练建立持续迭代的数据飞轮。核心判断是：下一阶段 AI 的关键，不只是让模型更聪明，而是把物理世界的履约过程变成可验证、可学习的训练信号。

最终，下半场真正的机会，不在于再造一个 AI Chat，而在于让 AI 真正进入交易、服务与履约，让消费成为通向更强通用智能的重要训练场。

陈烨，飞猪 CTO，负责飞猪 AI 战略的规划与实施。威斯康星大学麦迪逊分校信息系统与计算机博士，发表30余篇 NeurIPS、SIGIR、KDD、WWW 等顶会论文，三次获得 KDD、SIGIR最佳论文奖，部分成果被斯坦福大学、加利福尼亚大学伯克利分校纳入研究生课程；持有10项美国专利。曾创立人工智能公司虎博科技，其多模态大语言模型 TigerBot 入选首批国家大模型备案名单；曾任美团点评资深副总裁，主导构建搜索与效果广告平台。

除此之外，上海交通大学人工智能学院副教授/无问芯穹联合创始人兼首席科学家戴国浩博士、小影科技创始人 & CEO韩晟等多位来自学界与产业界的专家也将在Keynote主题演讲中，分享 AI 从前沿洞察到技术创新再到产业应用过程中的不同视角与关键探索。

本次大会还策划了Loop Engineering"、千行百业 Agent 创新实践"、Agent 自主进化：从记忆到持续学习"、Agent as a Service"、Vibe Coding 时代的新质量债"、理性驾驭 AI 的 SRE 可靠性工程"、金融 AI Native工程实践：从研发提效到业务破局"、AI Infra：算力效率决定规模化落地"、AI Native 架构"等20个专题论坛，届时将有来自不同行业、不同领域、不同企业的100+资深专家在现场带来前沿技术洞察和一线实践经验。

查看更多详情可扫码或联系票务经理 18514549229进行咨询。

Artifactory 漏洞正被积极利用，可以绕过身份验证并获取管理员权限

作者：Sergio De Simone — Mon, 12 Oct 2026 01:05:00 GMT

当前，Artifactory 中有三个正在被积极利用的漏洞"。利用这些漏洞，攻击者可以绕过通过互联网访问的自托管 Artifactory 部署中的身份验证，在五分钟内获得持久的管理员访问权限。随后，他们便可以利用这些漏洞来实施危险活动，包括窃取凭据和密钥、执行任意代码、持久化以及采取反取证措施。

披露这三个漏洞的安全公司 Wiz.io 报告称，攻击者正在将这些漏洞串联起来，以实现权限提升，并完全获得自托管 Artifactory 实例的管理员控制权：

这些 CVE 极易被利用，只需发送少量未经身份验证的 HTTP 请求即可。如果你的实例在存在漏洞期间处于暴露状态，请假设系统已经遭到入侵，并搜寻入侵痕迹。虽然升级能堵住漏洞，但无法驱逐已经潜入系统内部的攻击者 [...]

这三个漏洞分别是：CVE-2026-42018"，严重程度评级为高危，该漏洞“可能导致 Artifactory 向未经身份验证的请求者返回内部匿名用户令牌，即使已禁用匿名访问”；CVE-2026-42016"，评级同样为高危，该漏洞导致 Artifactory 无法正确地验证请求令牌，使得“拥有低权限的攻击者可能利用有效令牌获取更高的权限并执行未经授权的操作”；CVE-2026-82329"，评级为严重，该漏洞允许未经身份验证的攻击者获得管理控制权。

正如 Wiz.io 所指出的那样，其中两个漏洞可能在攻击中被串联利用，从而导致持久化的管理员账户以及后续的利用活动。

每次漏洞利用攻击的流程都大同小异。向 /access/api/v1/aws/token/ 发送一个未经过身份验证且末尾带斜杠的 POST 请求，得到的响应是 HTTP 200 状态码以及一个属于内部匿名用户的 JWT，这样便利用了 CVE-2026-42018 漏洞。随后，攻击者通过 POST /access/api/v1/tokens 将该 JWT 兑换为一个管理员作用域令牌。该请求会返回 HTTP 200 状态码，这样便利用了 CVE-2026-42016 的作用域验证漏洞。权限提升后的令牌保留了匿名用户名，但具备管理员权限，因此在后续请求中，攻击者的身份将显示为 token:anonymous。

此外，利用 CVE-2026-82329 漏洞可以直接获取管理员级别的令牌。根据观察，一旦获得管理员权限，攻击者便可以创建持久化的管理员账户、部署用于执行代码的恶意 Groovy 插件、窃取凭据和 Access 签名密钥、建立后门，并部署反取证机制。

Wiz.io 还指出，在某些已经观察到的案例中，攻击者在不到五分钟的时间内就完成了漏洞利用并获得了管理员权限。

网络安全专家 Erik York 在 LinkedIn 上就这一漏洞披露发表评论称"：

Artifactory 处于许多软件供应链的核心位置。如果不尽快修复，那么这些漏洞会演变成明年的“SolarWinds 事件”。

Graylog 信息安全高级总监 Jim Nitterauer 强调，为确保供应链安全，必须对所有受影响的系统打补丁：

由于 Artifactory 处于软件构建管道的核心位置，一旦遭到入侵，将直接构成供应链风险，而补丁的部署严重滞后——在第三个漏洞披露后的四天内，就已经观察到了相关攻击。

所有 Artifactory 自托管环境都应该立即升级至一个修复了这些漏洞的版本，包括 7.111.21、7.117.28、7.125.20、7.133.29、7.146.38、7.161.20 或更新版本（具体取决于部署的版本分支）。

原文链接：https://www.infoq.com/news/2026/09/artifactory-vulnerabilities/"

Uber 在 Kubernetes 平台上将扩容意图与执行操作解耦

作者： Matt Saunders — Sun, 11 Oct 2026 07:00:00 GMT

Uber 发布博文，详细介绍其全新的 ServiceScale 控制器，该控制器允许多个编排器安全地管理同一组 Kubernetes 工作负载的扩缩容。这篇由高级软件工程师 Egor Grishechko 和 Srikar Paruchuru" 撰写的博文描述了 Uber 如何将扩缩容意图与执行分离，在无需预留闲置容量的情况下支持区域故障转移。

Uber 的容器平台团队管理着分布在数据中心和云厂商（包括 Oracle 和谷歌）的 100 多个计算集群，运行着约 4000 个服务，使用 300 万核 CPU，每天启动 150 万个 Pod。该团队的内部平台叫作 Up，作为 Kubernetes 集群群联邦层。服务所有者使用 Up 部署构建版本并设置扩缩容预期，而一个专门的控制器——Uber 部署控制器（UDC）——会将这些意图调和为 Kubernetes 原语。InfoQ 此前曾报道过 Uber 向 Up 的迁移"以及随后完成的 Kubernetes 迁移"。

这一改变的动机来自 Uber 处理区域故障转移方式的变革。Uber 在不同区域运行双活数据中心。当发生故障时，流量会被重定向到幸存区域，该区域需要足够的空闲计算资源来应对增加的负载。过去，Uber 在所有数据中心都保留了预留的空闲容量。工程师们希望改为复用低优先级工作负载的容量，故障发生时缩容低优先级工作负载，扩容高优先级工作负载。

这就产生了新的扩缩容意图来源。Up 和 UDC 仍负责维护服务常规期望状态，但故障转移编排器也需要参与扩缩容决策。工程师们考虑过用故障转移逻辑扩展 UDC，但最终决定不这么做。UDC 已经处于服务生命周期操作的关键路径上，添加故障转移特定行为会增加这个控制器的复杂性。Grishechko 和 Paruchuru 指出，“故障转移处理一旦出现回归问题，不会只停留在故障转移层面”，而可能影响整个集群的正常部署。

相反，团队引入了一个新的自定义资源定义 ServiceScale 和新的服务扩缩容控制器（SSC）。每个编排器都可以通过 ServiceScale 表达自己的扩缩容意愿，SSC 将组合后的意图调和为 Kubernetes 对象。Grishechko 和 Paruchuru 解释说，他们可以保持模型的简洁。

“我们不想额外引入外部数据库、独立协调服务或是控制平面，否则在故障应急场景下，调试难度会大幅上升。”——Egor Grishechko 和 Srikar Paruchuru"

扩缩容意图直接物化在 Kubernetes 中，让系统更便于排查。当出现问题时，工程师可以查看 ServiceScale，看哪个编排器想要什么。故障恢复也变得简单，因为稳态和临时故障转移信息都保存在 CRD 规范中，这意味着在恢复时不需要从日志中重建状态。

博文分享了三条生产环境实践经验。第一个问题是过期的 Informer 缓存。和大多数 Kubernetes 控制器一样，Uber 的控制器依赖 Informer 缓存读取资源，缓存数据会比真实状态延迟数秒。Up 将状态字段作为最终判断依据：UDC 返回成功信号后就会触发工作流中不可回退的下一步操作。工程师们实现了“读己所写”一致性防护机制：控制器更新下游资源时，会把当前资源版本号作为注解打上，在上报状态前，先校验本地缓存至少已经读到该版本。

这个问题并非 Uber 独有。2026 年 4 月份发布的 Kubernetes v1.36 引入了控制器缓存过期问题缓解方案"，采用了类似的方法。如果缓存的最新资源版本低于控制器已写入的版本，控制器就不会执行操作。Kubernetes 项目还在与 controller-runtime 合作，让基于该框架开发的所有控制器都支持“读己所写”语义。

软件工程师 Prasad M K 在 LinkedIn" 上撰文，将“读己所写”缺失问题描述为“API 契约问题，而非后端缓存问题”，并建议使用版本令牌来校验读写一致性。他是从应用层面分析问题，而 Uber 的方案是在 Kubernetes 控制器范式内解决。

多写入者系统是另一个挑战。当 UDC 和 SSC 同时更新同一个 Kubernetes 资源时，特定的时序条件会导致 ReplicaSet 变得不一致。其元数据与规范产生漂移，这破坏了滚动更新的比例扩缩容，有时会导致工作负载卡住。工程师们在 UDC 中加入了全集群可观测能力，用来检测元数据与规范不一致，构建了自动修复程序来修补受影响的 ReplicaSet，并在扩缩容路径中推进长期修复方案。一篇关于 Uber 故障转移架构的学术论文"于 2026 年 1 月发表在 arXiv 上，论文提到，更广泛的统一故障转移架构将稳态配置从 2 倍降低到 1.3 倍，节省超过 100 万 CPU 核。

整个方案上线耗时一年。工程师使用了预发布环境和金丝雀发布，并基于 KubeKind 测试工具搭建集成测试，模拟控制器交互，捕获竞态条件。该方案支持原生 Kubernetes Deployment 和 OpenKruise CloneSet，并在整个过程中没有造成客户可感知的中断。InfoQ 还报道过 Uber 的持续部署优化"方案，同样强调渐进、安全发布的思路。

“多编排器系统的难点不在于 API，而在于多次写入之间发生的各类并发问题。”——Egor Grishechko 和 Srikar Paruchuru"

Uber 的实践凸显了生产中多编排器 Kubernetes 引入的分布式系统问题。CNCF 最近将 Karmada" 项目正式毕业，这是一个多集群编排项目，采用不一样的架构解决跨集群故障转移问题。Kubernetes v1.36 中引入的缓存过期缓解机制也说明这类问题已经在平台层面获得重视。

查看英文原文：https://www.infoq.com/news/2026/09/uber-kubernetes-scaling/"

利用 AI 代码智能体优化软件架构的五种方法

作者：Pierre Pureur, Kurt Bittner, Todd Miller — Sun, 11 Oct 2026 02:04:31 GMT

自动代码生成并不是一个新概念，但 AI 编码智能体的编码速度远超以往的任何工具。这种速度带来了巨大的好处，但也产生了独特的问题，人们很容易失去对输出代码质量的控制。这种失控在架构层面显得尤为突出。如果你只向 AI 输入功能需求，AI 并不会自动确保架构的合理性。你必须向它提供具体的架构目标，例如可衡量的质量属性需求（QAR）和权衡取舍（参见“怀疑论者眼中的软件架构决策指南"”）。AI 生成的代码需要经过测试，以此来评估是否满足 QAR。

使用 AI 编码智能体来开发具备弹性、可扩展、安全的系统尚处于起步阶段。你可以学习编码智能体相关课程、阅读书籍，甚至寻找指导，但我们都是在实践中学习，不断尝试、犯错，并从经验中吸取教训。

不过，有一些很好的方法可以帮助你快速上手，充分利用实践经验，而不是浪费太多时间盲目尝试。以下是我们在使用 AI 编码智能体构建架构合理的系统的过程中总结的一些有用的入门建议。这些建议不是菜谱式操作手册，也不是固定的流程，而是一些有用的方法，可以帮助你们获得经验、有目的地学习，至少足以让你能够进行自主的探索学习。

使用 AI 编码智能体记录架构所依赖的遗留服务

现代架构通常依赖遗留服务来执行特定任务，例如从几十年前构建的保险单系统中检索当前和历史保单信息。不幸的是，这些服务可能缺少精准的文档，如果没能充分理解其逻辑与数据，调用时就容易产生问题。

示例

有一个很少使用的遗留服务，用于从 IMS 数据库检索信息，它可能潜藏着未知的问题，例如逻辑或安全缺陷，在非预期的场景中调用时会返回错误的信息。这些问题可能在开发的后期才暴露出来，例如在系统测试或用户验收测试期间，甚至在新系统上线生产环境之后。

为了降低这种风险，可以用 AI 编码智能体梳理遗留服务的系统设计，包括记录数据流。此外，它还可以扫描遗留服务的代码，识别潜在问题并提出修复建议。如果团队认为遗留服务确实状况糟糕且问题太多，可以用编码智能体对服务进行重构，提升代码可读性与可维护性。这种重构能够消除新架构中的一项关键风险。

使用 AI 编码智能体发现和修复架构缺陷

除了发现和修复安全缺陷外，你还可以使用 AI 编码智能体来发现和修复常见的架构问题。这种用法可能很简单，比如找出违背架构规范、编码规范执行不到位或是需要重构以提升可维护性的代码位置。你甚至可以使用编码智能体提出修改建议，解决它发现的问题。

示例

使用 AI 编码智能体来发现常见的架构问题，例如 API 设计问题，包括难以使用、不安全或低效的接口，以及领域驱动设计（DDD）边界越界问题。明确指定需要检查的范围。例如，你可以要求 AI 编码智能体评估服务层，检查是否存在组件直接访问另一个领域的内部状态或是复用其他领域代码的情况。这类评估存在收益递减效应，因为 AI 几乎总能发现改进之处。你需要自行判断哪些发现是关键问题，哪些不是。

采用这种方式，需要熟悉架构难题的团队成员引导 AI 编码智能体，他们知道如何编写提示词，通过约束和引导让编码智能体产出预期结果。

团队通过提供具体、可衡量的架构目标以及清晰阐述已知的取舍方案与备选方案完成对编码智能体的引导，聚焦智能体的工作范围，控制使用成本。这需要经验来阐明可能需要做出的权衡，让编码智能体在生成解决方案时将它们纳入考量。如果提示词只包含功能需求，就会缺乏这种聚焦，由此产生的系统架构很可能无法满足 QAR。

这样使用编码智能体还有一个意外的好处：它会倒逼团队更清晰地梳理取舍方案，明确自己能够接受的代价。

使用 AI 编码智能体对系统进行安全审计

近期关于恶意利用 AI 编码智能体挖掘现有系统安全漏洞的报告让所有人都高度警惕，但这些风险也有另一面：AI 编码智能体也可以识别漏洞并完成修复，特别是当架构中包含了开源包时。也就是说，我们是否使用了正确的、带有最新安全补丁的开源包？

你可以使用 AI 编码智能体扫描源代码文件、绘制系统设计图和编写测试来发现软件缺陷，从而发现安全漏洞。除了指出糟糕的代码外，AI 编码智能体还能够分析整个系统，发现复杂的逻辑缺陷，并生成代码来修复这些问题。具体来说，你可以要求 AI 编码智能体：

追踪数据流、识别高风险文件，梳理系统设计（限制智能体访问权限，仅允许读取授权文件）。扫描代码，跨文件查找复杂逻辑缺陷（在提示词中屏蔽或隐藏数据库密码等敏感密钥，降低风险）。生成类似黑客脚本的压力测试脚本，对潜在漏洞进行测试（将智能体隔离在封闭网络环境，防止意外攻击线上服务器）。生成代码补丁，修复安全漏洞（任何代码合并前，必须由人工完成代码评审）。

示例

在漏洞测试工作中，客户报告说当前使用的若干 npm 包被标记存在安全风险。我们用 AI 编码智能体评估风险，并向客户反馈，输出详细的影响分析报告。最终我们更新了其中两个包，替换了一个包，还有一个包的告警属于误报，所以保留了下来。所有这些工作都是在 AI 编码智能体的协助下完成的。

随着大语言模型在网络安全领域能力变强、风险上升，我们更需要借助 AI 编码智能体在漏洞被恶意利用之前提前发现架构中的潜在安全问题。

使用 AI 编码智能体为开发人员提供架构基础

AI 编码智能体能够帮助团队快速做实验，几乎可以瞬间生成原型，方便用户确认需求。如果没有明确引导编码智能体去关注架构，生成的原型就不太可能实现系统的 QAR，并且在很大程度上只能作为一次性演示原型。

要解决这个问题，需要引导和约束 AI 编码智能体，使其符合具体的、可衡量的架构目标和清晰阐述的权衡取舍。然后，可以使用编码智能体来创建预打包的 shell 应用程序，作为开发者制作原型的基础。架构目标与约束条件以Markdown格式提供，包含质量属性需求、编码规范、数据库设计、API、推荐平台与框架，同时将这些信息提供给 AI 编码智能体，进一步完善模型应用程序。

示例

如果你正在开发一个小型的 React 应用程序，可以让 AI 编码智能体查看你的文件目录结构，并根据现代开发规范对其进行评估。如果你与推荐的或 React 社区所采用的做法不一致，编码智能体可以给出大小不等的修改建议并协助调整。与往常一样，需要检查它给出的建议是否匹配你要解决的业务场景。

补充示例

团队一直在开发新的应用程序。如果你发现了通用的模式，就可以利用 GitHub 的模板功能。你可以借此勾勒出应用程序的常见结构，创建可供 AI 调用的技能，并内置编码规范，让团队从一开始就能搭建架构合理的应用。

描述你想要达成的目标比直接告诉编码智能体要生成哪种实现方案效果更好。人们很自然会直接描述实现方案，但团队应当避免这种思路。描述目标、约束条件以及目标的验证方式会高效得多。

从架构设计角度来看，这意味着很多原本默认资深开发人员能够理解的隐性架构需求与约束，现在必须显式定义，做到可落地、可测试。除此之外，团队还必须对这些 QAR 开展实测；仅有可测试需求远远不够。如果你使用 AI 编码智能体生成测试用例，至少要人工的评审和验证，保证测试能够准确衡量指标。

实际上，使用 AI 编码智能体使编码变得更简单，但创建需求却变得更加困难。开发人员多年来磨练的技能（例如编写代码）现在变得不那么重要。开发人员因为觉得麻烦而想去回避的事情（即理解和阐明需求和约束）变成 AI 辅助开发模式下最需要磨练的重要技能。

使用 AI 编码智能体生成可测试的 MVA

只要需求定义准确，AI 编码智能体就可以高效快速生成代码。乍一看，这种方式性价比很高，能够快速用现代技术替换老旧、难以维护的应用（例如 COBOL 程序）。但问题在于，AI 编码智能体生成的部分代码会存在错误。检查 AI 生成的代码很重要，但还不够，必须通过可量化的测试评估代码质量，这样才能构建高质量的软件架构。

因此，最小可行架构（MVA）"需要包含全部必要代码，用以证明系统同时满足质量属性需求与功能需求。使用 AI 编码智能体并不会改变这一事实。使用 AI 编码智能体生成测试架构基础的代码对于验证架构来说非常重要。如果团队在生成代码的提示词中提供了 QAR 和权衡信息，那么编码智能体就拥有生成测试代码所需的信息，包括测试框架、测试数据和测试环境（例如容器）配置。

团队还需要考虑一个风险：AI 智能体可能无法生成完全满足其 QAR 的 MVA，后续需要扩展生成。为了降低这种扩展成本超出其承受能力的风险，团队可以在评估 AI 生成的 MVA 的适用性时引入架构变更案例"。

总结

虽然 AI 编码智能体带来了显著的速度提升，但需要有效的护栏来确保它们的产出满足质量目标。软件架构是保证质量目标得以实现的一种方式。团队需要向 AI 编码智能体提供架构上下文来达成质量目标。

事实证明，AI 编码智能体是实现架构需求的宝贵工具，但也带来了一系列我们才刚刚开始理解的全新挑战。由于 AI 编码智能体仍属于新兴事物，技术迭代迅速，本文给出了一些建议，帮助大家利用 AI 编码智能体改进甚至是搭建软件架构。这些内容并非该领域的终极定论，但可以作为坚实的起点，帮助团队开启相关实践之旅。

查看英文原文：https://www.infoq.com/articles/ai-agents-improve-software-architecture/"

AI 时代的移动端稳定性保障 —— 柯南 AI Agent 实践｜QCon上海

QCon全球软件开发大会 — Sun, 11 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 驱动的软件工程"” 专题，并发表题为《AI 时代的移动端稳定性保障 —— 柯南 AI Agent 实践"》的主题分享。过去一年，AI Coding 已逐渐成为软件研发的新范式。随着代码生成能力不断提升，需求实现成本被大幅降低，研发生产节奏持续加快。然而，在真实复杂的工程环境中，研发效率的瓶颈正逐渐从“代码编写”转向“研发后链路”——包括稳定性分析、问题定位、风险治理、上线保障与经验沉淀等环节。这些工作仍然高度依赖人工，难以跟上 AI Coding 带来的研发吞吐增长，也成为 AI 深入研发流程必须解决的关键问题。

与此同时，鸿蒙生态快速发展，移动端研发正逐步进入 Android、iOS、HarmonyOS 多平台并行的新阶段。鸿蒙原生、KMP 等新技术栈在带来跨平台研发效率提升的同时，也引入了新的稳定性挑战：跨语言运行时、多技术栈协同、复杂异常现场分析等问题，使传统稳定性保障体系面临更高复杂度，也对 AI 的工程理解能力提出了更高要求。

本次分享将结合快手移动端稳定性 Agent「柯南 AI」的建设实践，分享 AI 如何从代码辅助走向研发后链路，成为能够理解工程上下文、参与稳定性治理的数字同事。内容将覆盖 Agent Workflow、Context Engineering、Agent Harness、Agent 友好型工程基建等关键实践，介绍 AI 如何自动完成异常现场聚合、证据补齐、根因分析、处置建议、自动修复及知识沉淀等完整流程，并结合鸿蒙与 KMP 等典型场景，分享 AI 在复杂工程环境下解决疑难稳定性问题的实践经验，探讨 Agent First 的稳定性研发新范式，以及 AI 驱动研发体系演进的未来方向。

王泽锋现任快手大前端稳定性方向技术专家。2023 年加入快手，先后参与 Android & 鸿蒙稳定性方向监控报警、排障工具、止损工具等多个领域的建设，目前主要聚焦探索 AI + 稳定性方向。他在本次会议的详细演讲内容如下：

演讲提纲1. AI 时代移动端稳定性保障面临的新挑战AI Coding 提升研发生产效率，但稳定性保障链路尚未同步提速AI 时代研发效率瓶颈为何逐渐转向研发后链路鸿蒙原生、KMP 等新技术栈带来的稳定性新挑战2. AI 如何重构稳定性研发流程：Agent First 工作范式快手移动端稳定性体系现状与挑战柯南 AI Agent 实践与典型案例展示Agent 工程关键实践Workflow、LLM 与 Agent 的能力边界面向稳定性场景的轻量级 Agent HarnessAgent 友好的数据服务与上下文工程基于可观测体系的数据飞轮建设3. AI 驱动复杂稳定性问题治理实践鸿蒙 OOM、Freeze 等复杂问题分析实践Agent 驱动的异常现场聚合与 Heap Snapshot 分析自动分析、自动分发与治理闭环多技术栈协同问题治理（鸿蒙 + KMP）Agent 如何整合跨语言、跨运行时上下文跨语言循环引用问题治理实践跨语言死锁问题治理实践4. 总结与展望AI 从辅助工具走向研发流程参与者Agent 在稳定性领域的发展方向AI 驱动研发后链路智能化的未来展望实践痛点大模型不是稳定性领域的银弹。一方面，稳定性天然和大量内部系统紧密结合，存在大量私域知识，而移动端线上版本的高度碎片化还会带来大量历史兼容性问题。这些信息无法通过模型升级被自然习得，而且还会被持续生产。我们需要持续通过上下文工程建设给模型补齐知识（私域知识），加上“手脚”（内部系统访问能力）。另一方面，一个稳定性问题被解决的上限，取决于问题现场的信息能多大程度被采集到。端侧基建不会过时，需要持续建设。演讲亮点实战参考价值：在快手这一亿级 DAU 和超长使用时长 App 上，在内部百级别开发者和真实线上 Top 问题的考验下取得实际提效和指标治理结果听众收益了解 AI Agent 在研发后链路中的真实落地实践，理解如何基于日志、堆栈、源码、监控、变更等工程资产构建真正可落地的稳定性 Agent。掌握 Agent Workflow、Context Engineering、Agent Harness、Agent 友好型基础设施等关键工程方法，以及复杂研发场景中的实践经验。了解鸿蒙、KMP 等新技术栈下稳定性治理的核心挑战，以及 AI 在复杂工程问题分析、定位与治理中的应用方式。理解 AI Coding 时代研发效率瓶颈的变化趋势，探索 Agent 如何推动研发流程从代码生成走向稳定性治理、知识沉淀等全链路智能化，构建面向未来的 Agent First 研发范式。

除此之外，本次大会还策划了Loop Engineering"、千行百业 Agent 创新实践"、Agent 自主进化：从记忆到持续学习"、Agent as a Service"、Vibe Coding 时代的新质量债"、理性驾驭 AI 的 SRE 可靠性工程"、金融 AI Native工程实践：从研发提效到业务破局"、AI Infra：算力效率决定规模化落地"、AI Native 架构"等20个专题论坛，届时将有来自不同行业、不同领域、不同企业的100+资深专家在现场带来前沿技术洞察和一线实践经验。

查看更多详情可扫码或联系票务经理 18514549229进行咨询。

亚马逊云科技在 Aurora DSQL 中引入外键约束

作者：Daniel Curtis — Sat, 10 Oct 2026 11:00:00 GMT

亚马逊云科技近日宣布，Aurora DSQL 现在已经支持外键约束"，允许应用程序直接在数据库中强制执行参照完整性，包括 CASCADE、SET NULL 及其他参照操作。这一新增功能弥补了用户长期以来明确指出阻碍他们采用的缺失环节。

Aurora DSQL 是一款无服务器、分布式且与 PostgreSQL 兼容的 SQL 数据库，专为高可用、高可扩展的应用程序而设计。根据文档"，Aurora DSQL 通过事务期间的快照验证和提交时的冲突检测来强制执行参照完整性。该服务无需锁定表，即可基于一致性事务快照校验外键关系，支持并发操作；在提交时使用隐式 KEY SHARE 检查来检测存在冲突的更改；任何可能违反约束的事务都将因序列化错误而被拒绝。

应用程序应该实现重试逻辑，因为并发冲突会导致事务失败，而非进入等待状态。对于被频繁引用的行，亚马逊云科技建议避免频繁地更改键列；相反，应保持被引用的键稳定，并将变化的值移至非键列，以减少事务冲突。

亚马逊云科技副总裁兼杰出工程师 Marc Brooker 强调，Aurora DSQL 利用 Adjudicator 和 PostgreSQL 的 KEY SHARE 机制"，在提交时检测相关行中的变更，同时不会阻塞并发读取：

无阻塞，非 FKC 读取的扩展性不受影响，FKC 读取器绝不会导致其他读取器中断。而且，在工作负载分布均衡的情况下，FKC 具有出色的扩展性。

在 LinkedIn" 上，荷兰国家铁路公司（Nederlandse Spoorwegen）首席工程师、AWS News Feed 创建者 Luc van Donkersgoed 评论道：

他们做到了！Aurora DSQL 现在支持外键约束了。外键约束的缺失曾是 DSQL 与“普通” Postgres 之间最大的差距，阻碍了许多迁移工作。这一改动使得 DSQL 在现有系统环境中变得更加可行。

在“亚马逊开发 DSQL 是浪费时间"”的讨论帖中，人们将缺乏外键约束列为阻碍这种与 PostgreSQL 兼容的分布式数据库被广泛采用的主要障碍之一。亚马逊云科技高级首席工程师 Marc Bowes 当时承认：

没错，外键功能即将推出。我们听到了大家的呼声。

当该服务在 re:Invent 2024 大会上发布时，许多从业者指出，在发布时缺失的众多功能中，外键约束的缺失尤为突出"。用户 SteveTabernacle2 写道"：

那么“Postgres 兼容”这一说法就具有误导性。外键是关系型数据库管理系统（RDBMS）中至关重要的一部分。没有外键，就无法真正实现“关系型”数据。

对于这项新功能，社区的反应总体积极，不过有一位用户在 Reddit 上提出了质疑"：

我知道这一功能曾被列为阻碍采用的主要因素之一，但它会大大降低运行速度。考虑到 DSQL 的架构，我不确定这到底有多好。

亚马逊云科技指出，为了维护参照完整性，对被引用或引用表执行的所有 DML 操作都会产生额外的读取操作。因此，客户在向表中添加外键约束之前，应先对工作负载进行基准测试。

外键约束并非 DSQL 近期唯一的新增功能。亚马逊云科技还新增了 CloudWatch Database Insights"，用于按语句进行集群级的性能监控与故障排除。

原文链接：https://www.infoq.com/news/2026/09/aurora-dsql-foreign-keys/"

Linear 通过 1000 多次 PR 从 styled-components 迁移到 Meta 的 StyleX

作者：Daniel Curtis — Sat, 10 Oct 2026 10:09:00 GMT

长期以来因高效而备受推崇的项目管理工具 Linear，已经将其 React 应用程序从 styled-components" 迁移至 Meta 原子化 CSS-in-JS 库 StyleX"。工程师 Kenneth Skovhus 表示"，这次迁移共涉及 1000 多个拉取请求。他早前在个人博客上发布"过一篇文章，记录该项目的完成进度为 58%。经过大约五个月的工作，团队已于 2026 年 8 月初完成了这次迁移。

运行时 CSS-in-JS 会让用户在客户端渲染时承担样式生成和规则注入的开销，而在升级到 React 18 的并发渲染后，Linear 切身感受到了这一代价，大约就在 styled-components 进入维护模式"的那个时期。来自 Sanity 的 Cody Olsen 甚至发布了一个利用 React 18 useInsertionEffect 进行优化的分支版本"，并将其称为“最后的手段”。该方案将 Linear 的渲染时间缩短了 40%。第二个原因是封装问题，像 styled(Button) 这样的模式使得从外部重新设计组件变得过于容易，而随着编码代理的使用日益增多"，团队希望刻意增加这种操作的难度。

StyleX 将样式生成移至构建阶段，并输出无冲突的原子类。下面是一个典型的定义：

import * as stylex from '@stylexjs/stylex'; const styles = stylex.create({ box: { padding: 16, color: 'blue' }, });

Linear 评估了大多数 React 样式选项，发现 vanilla-extract" 是最接近的替代方案，但因其 API 零散且样式文件分散而没有采用。为了避免手动迁移，Skovhus 构建了一个确定性的 codemod"，目前已经处理了超过 500 个 PR 和大约 10 万行代码，并配有在线演练环境"。如果其他团队想尝试类似的转型，可以从 StyleX 文档"入手，借助 Oxlint" 制定自定义规则，并像 Linear 那样将 CSS Modules 作为处理全局选择器的备用方案。按照 Linear 的说法，这次改造带来的收益包括：在视图密集型页面上的主线工作量减少了 20% 至 35%，在中端机器上的导航速度提升了约 30%，而且页面切换时不再注入任何 CSS 规则。

这一举措正值 StyleX 掀起一股热潮之际。正如 This Week in React" 所指出的那样，在 Cursor 自身从 Tailwind 切换过来，以及 Meta 开源 Astryx 设计系统之后，该库在 X 平台上大受欢迎。在 Syntax 上，Scott Tolinski 和 Wes Bos 探讨"了为何人人都转向 StyleX，并得出结论：这种额外的严格性对人类来说并不有趣，但自动化工具却能从中获益。曾经在雅虎负责过类似原子化系统的资深工程师 Reid Burke 提醒"各团队，要警惕选择庞大的 API 接口所带来的陷阱，因为 styled-components 开放且图灵完备的 API 正是导致自动化如此困难的根源。

GitHub 上有一场题为“使用 StyleX 很棒，但规范限制太严”的讨论"，反映出人们对父元素依赖选择器和全局选择器这些限制的普遍不满。

Linear 是一款专为软件团队打造的项目管理和问题跟踪工具，长期以来以键盘驱动的界面和对速度的重视而著称。StyleX 是 Meta 推出的开源原子化 CSS-in-JS 库。它将样式生成移至构建阶段，并生成小巧且互不冲突的原子类，而非在应用运行时注入 CSS。Facebook、Instagram 和 WhatsApp 的网页版均使用了这个库。随着各技术团队开始寻求以牺牲部分运行时灵活性为代价，换取可预测的稳定性能与更严格的组件边界，该库也获得了更广泛的行业关注。

原文链接：https://www.infoq.com/news/2026/09/linear-stylex-meta/"

单次RL后训练烧掉260万美元、每步37亿Token，小米披露MiMo-V2.6“规模化强化学习”路线

褚杏娟 — Sat, 10 Oct 2026 09:24:57 GMT

10月8日，小米 MiMo 团队发布技术报告《MiMo-V2.6: Scaling Reinforcement Learning Towards Self-Improvement》。这篇报告披露了小米一套完整的规模化 Agentic RL 训练过程：通过同时扩大训练 Batch、任务环境与 Harness，以及用于评判 Agent 行为的 Grader Compute，来探索模型持续自我改进的路径。

此次发布包含 MiMo-V2.6-Pro 和 MiMo-V2.6-Flash 两个模型。其中，Pro 总参数量为 1.02T、每次推理激活 42B 参数；Flash 总参数量为 310B、激活 15B 参数。两者均采用稀疏混合专家（MoE）架构，并在文本主干中混合局部滑动窗口注意力（SWA）与全局注意力（GA）。

论文链接：

https://arxiv.org/pdf/2610.11959"

同时 Scale 了 Rollout、环境和 Grader

MiMo-V2.6 将强化学习算力拆成三个部分：Rollout、Grading 和 Training。

实际训练中，每个 RL Step 先采样 1568 个 Prompt，每个 Prompt 同时生成 16 条 Rollout，也就是说，每一步都会产生约 2.5 万条 Agent 轨迹。这些轨迹合计达到 27亿至37亿 Token，平均每条序列约 11万至15万 Token，训练上下文长度最高达到 100 万 Token。

MiMo-V2.6 的训练任务覆盖代码 Agent、通用工具使用、视觉设计、上下文遵循和网络安全。其中在正式 RL Batch 中，代码与竞争性编程任务占 68%，通用工具使用占 12%，视觉设计占 13%，上下文遵循占 3%，网络安全占 4%。整个训练采用 GRPO，并结合异步 Partial Rollout。

这种训练的成本也迅速上升。论文显示，MiMo-V2.6-Pro 的 RL 后训练成本约 260万美元，Flash 约 90万美元。其中 Pro 的计算成本中，Rollout 占 43.8%，真正用于模型参数更新的训练占 43.5%，而单独用来判断 Agent 行为好坏的 Grader 已经占到12.7%；Flash 的 Grader 成本比例甚至达到 14.2%。

更要判断Agent是否“做得好”

传统代码 RL 很多时候依赖二元测试奖励：测试通过给 1 分、不通过给 0 分，但这套方法在长程 Agent 任务上已经不够用了。

两个方案即使都能通过测试，其中一个可能只改了必要的几行代码，另一个却加入大量兼容分支、吞掉异常、扩大 API 范围，甚至为了通过测试修改与任务无关的配置。二者在传统 Reward 下可能拿到同样的分数，但工程质量完全不同。

为此，MiMo-V2.6 在代码 Agent 训练中引入了两套分组智能体评分机制。

一套是分组奖励合成（Groupwise Reward Synthesis，GRS）。系统首先收集同一个任务的多个 Rollout，由 Agent 同时分析不同方案，生成“解决方案质量”和“行为质量”两套 Rubric。之后，训练中的每条新轨迹不仅需要通过测试，还会按照代码实现质量、边界情况处理、与原代码库的一致性，以及解决问题过程中是否进行了必要验证等因素继续打分。

另一套是分组优势重分配（Groupwise Advantage Redistribution，GAR）。Grader 会把同一个任务中成功和失败的多条轨迹放到一起比较，对已经通过测试的方案继续按照解决思路、实现准确度、修改范围、副作用和工程质量进行排序，再把更多强化信号分配给质量更高的解法。

实验显示，没有在线分组评分时，模型随着 RL 继续训练，会产生越来越长的轨迹和越来越多的 Agent Turn，并逐渐出现为了提高通过率而加入冗余兼容逻辑、吞掉异常等行为。加入在线评分后，通过率可以继续增长，同时 Token 长度和交互轮数保持得更加稳定，模型也倾向于生成更小、更精确、更易维护的 Patch。

论文还额外加入了“组内相对长度惩罚”，对已经成功但明显比同组其他成功解法更长的轨迹进行扣分，希望模型不仅把任务做完，还尽可能使用更少 Token。

当模型越来越擅长优化 Reward，另一个问题也随之出现：模型开始寻找“作弊路径”。

小米在早期训练中发现，代码 Agent 会尝试绕开原本的修复任务。例如直接安装更新版本的软件包查看已经公开的修复、访问 GitHub 最新源码、克隆上游仓库、搜索 Issue 和提交历史，甚至通过比较不同版本来反推出正确答案。这样的操作同样可能让自动测试通过，但并不能证明 Agent 自己解决了问题。

为此，小米在训练前后增加了多层防线。训练环境会主动删除构建日志、Verifier 输出、残留 Patch、二进制、字节码和 Cache，仅保留任务指定版本之前的 Git 历史，并通过容器级网络隔离阻止 Agent 获取上游修复。团队甚至专门训练和部署了一个 Hack Agent，主动进入这些环境寻找还能被利用的漏洞。如果找到新的作弊路径，就继续修改环境、重新测试，再让 Hack Agent 攻击，直到无法继续找到可利用路径。

即使正式 RL 已经开始，团队仍会离线审计 Agent 轨迹；一旦发现确认存在 Reward Hacking，对应轨迹的 Reward 会直接被清零。最终，MiMo-V2.6-Pro 和 Flash 正式训练过程中，被确认存在 Reward Hacking 的轨迹比例始终控制在 2%以下。

训练Agent“适应不同Agent”

MiMo-V2.6 另一个明显变化，是把 Agent Harness 本身也当成 RL 的一个 Scaling 维度。

不同 Coding Agent 的系统提示词、上下文管理、工具调用方式和执行流程都不同。如果模型长期只在一个 Harness 中训练，很容易学到 Harness 特有的行为模式，换一个 Agent 框架后能力就下降。

小米没有直接拿 Codex、MiMo Code 这类完整生产 Harness 混在一起训练。论文认为，生产 Harness 通常包含大量工程保护、复杂工作流和额外 Prompt，而这些行为未必有对应 Reward，很容易干扰强化学习中的信用分配。不同模块之间又高度耦合，也不方便单独控制变量。

因此，MiMo-V2.6 构建了一批更小、更模块化的 mini-harness，统一保留系统提示词、工具和上下文管理等最基本能力，再针对 Code、General、Visual 和 Cyber 组合不同配置进行训练。

效果之一是，模型不仅在训练期间见过的四套 Harness 上提高，在训练时从未见过的 Codex、Claude Code 和 mini-swe-agent 上也同步提升。在 DeepSWE v1.1 上，3 个 Held-out Harness 的平均 Pass@1 从大约 50%提升至66%。

MoE Router 一旦跟着RL学习，20步就开始“塌”

规模变大后，模型本身也出现了新的稳定性问题。

MiMo-V2.6 是 MoE 模型。理论上，Router 会根据输入决定 Token 应该被送进哪些专家。如果 RL 过程中 Router 也继续更新，不同专家之间的负载分布可能不断漂移。

小米做了一组对照实验：在 MiMo-V2.6-Pro 中，如果不冻结 Router，仅仅经过前 20 个训练 Step，第9层专家负载的变异系数就从 0.78升至2.0；最繁忙 Expert 的负载从平均值的 6倍升至16倍；负载低于平均值10%的“冷专家”比例，则从 0.5%升到22%。

团队随后把第20步模型中的 Router 恢复到 RL 开始前的参数，而其他模型参数保持不变，结果专家负载很快恢复正常，但 Benchmark 基本不受影响。这说明问题并不是 Expert 本身在退化，而是 Router 在 RL 中发生漂移。

因此，MiMo-V2.6 最终选择在整个 RL 阶段冻结 MoE Router。冻结后，专家负载变异系数稳定在约 0.7，峰值负载约为平均值的 5.5 倍，冷专家占比维持在约 1%，同时模型性能仍然继续提高。

一次RL跑了123小时，GPU、K8s、Grader都出过故障

论文还直接公布了两次正式训练的故障时间线：MiMo-V2.6-Pro 完成 30 个 RL Step 共耗时 123.1小时，Flash 为 81.8小时。训练过程中出现过 GPU 显存双比特错误（DBE）；Flash 在第15至16步之间遭遇 Kubernetes 故障，导致 Cyber 集群 Pod 崩溃；Pro 在第14步之后因为 Grader 网络不可达而重启。

另外还有更典型的大规模 Agent RL 问题。Partial Rollout 重启后，较短任务会优先完成，导致系统低估剩余任务长度，最终把 GPU KV Pool 和锁页主机内存池一起撑满；训练阶段还出现过 MoE 微 Batch 内负载严重不平衡，某个 Expert Parallel Rank 接收到超过平均值 30倍的 Token，导致显存溢出。Flash 后期则因为长序列增加数据量，最终把主机内存撑爆，引发显存溢出。

重做RL Infra

为了支撑单 Step 2.5 万条轨迹，小米重新设计了 RL 数据和执行系统。

在执行侧，Harness Pool 使用 Ray Actor 运行不同 Agent Harness。为了避免每一个 Agent Loop 都创建独立 Actor 导致控制节点文件描述符耗尽，系统改成固定数量的持久 Host Actor，每个进程同时托管多个 Agent Loop 和 Harness Instance，从而降低高并发 Rollout 的进程与服务开销。

在数据侧，Payload Porter 把控制面和数据面拆开。一个长程 Agent 轨迹除了 Token 和概率，还包含 MoE 路由信息、Top-p 候选集和多模态数据；截图不断累积时，一条轨迹甚至可能携带数 GB 数据。

因此，真正的重数据只写入分布式存储，中央 Driver 只处理 Reward、长度和数据地址等轻量元数据。到真正训练时，再由对应 Rank 按需读取需要的数据，而不是把整个 Batch 聚合到一台控制节点上。

同时，MiMo-V2.6 引入 Sample Mixer 动态控制不同任务的数据比例。论文统计的25个数据源中，平均生成 Token 数最大相差 90倍，Rollout 执行时间最大相差 66倍。如果简单先到先得，短任务会迅速占满 Batch，长程任务反而不断被挤出去。因此，Sample Mixer 会根据目标比例、通过率和任务耗时动态调整并发量和调度优先级。

为了进一步降低 Rollout 成本，小米还把推理侧的一系列优化直接带进了 RL。

Agent 的每个对话 Context 都维护持久 KV Cache；多轮工具调用期间，当前不活跃的 Cache 会从 HBM 卸载到锁页主机内存，等模型重新开始生成时再搬回来，从而尽可能让 HBM 留给正在运行的请求，提高 Decode Batch。

Rollout 还使用 Block-6 DFlash 做投机解码。相较原来的 MTP-3 配置，RL 适配后的 DFlash 平均接受长度提高 31.3%；Block-6 相比 Block-8 的全局平均吞吐提高约 6%；进一步引入 FP8 低精度草稿计算后，在长上下文工作负载中，单节点吞吐相较基线提高约 10.3%。

30次更新之后，样本外软件工程能力提升

强化学习规模扩大之后的一个关键问题是：模型究竟是真的获得了新能力，还是只把训练环境“练熟了”。

小米给出的一组结果显示，MiMo-V2.6-Flash 和 Pro 在训练任务上的平均通过率分别相对提高约25%和12%。在未进入训练集的长程软件工程测试 DeepSWE v1.1 上，Flash 的得分由48.8提高到65.7，提升约17分；Pro 则由58.4提高到72.6，提升约14分。小米据此认为，大规模 RL 获得的一部分能力能够迁移到训练之外的任务。

从整个 MiMo-V2.6 系列的结果来看，小米称 Pro 在 Artificial Analysis Intelligence Index 上得到46分，并在多数 Agent Benchmark 上达到其所称的 Claude Opus 5、GPT-5.6 Sol 相近水平。不过，官方也承认，与 Claude Fable 5.1、GPT-6 Astra 等最强闭源模型相比仍存在差距。

此外，MiMo-V2.6 还进一步覆盖电脑操作（Computer Use）、具身智能和科研任务。例如模型可以根据图形界面完成信息检索、编辑和数据处理，并根据视觉反馈检查结果、修正后续操作；在具身模拟环境中，它也可以通过多视角画面持续决策并控制机械臂。

从预训练Scaling，走向 Agentic RL Scaling

过去几年，大模型性能提升主要依赖一条相对明确的路径：增加参数、数据和预训练计算量。进入推理模型和 Agent 阶段后，新的计算投入正在逐渐转向模型训练完成之后，即让模型进入大量可验证环境，产生更长的 Rollout，通过更复杂的 Grader 获得反馈，再利用 RL 更新策略。

MiMo 团队将这一路线称为对递归自我改进（Recursive Self-Improvement，RSI）的探索。不过，从技术报告实际展示的机制来看，目前距离“模型自主设计、训练下一代模型”的完整 RSI 仍有明显距离。MiMo-V2.6 所实现的，更准确地说，是在人类设计好的任务、环境、奖励和训练基础设施中，通过规模化 RL 建立持续反馈和能力提升闭环。

为了让这套路线能够被外部研究者复现，小米此次同时开源了超过7000个高质量 RL 环境，涵盖软件工程、漏洞复现、知识型工作和网页设计开发等任务；还开放了基于 verl、uni-agent 和 mini-swe-agent 构建的端到端 RL 框架，以及用于多 Harness 训练的轻量框架。

开源地址：

https://huggingface.co/collections/XiaomiMiMo/mimo-v26"

模型开放之后，AI能力为什么仍难以复用？

世界人工智能开源大赛 — Sat, 10 Oct 2026 09:10:50 GMT

近年来，中国积极推动人工智能开源开放，全球 AI 开源生态也在持续发展。开放模型、开发工具和技术框架不断丰富，降低了技术应用门槛，让更多开发者能够基于已有成果开展创新。

然而，随着 AI 从模型能力展示走向企业业务、科学研究和物理世界，开源生态面临的问题也在发生变化：模型可以下载，不代表系统能够复现；代码公开，不意味着能力可以直接调用；Demo 能够运行，也不代表可以迁移到不同场景。

AI 开源的价值，正在从“开放了什么”，进一步转向“开放的能力能否被验证、复用和持续迭代”。

一、从代码开放到能力复用，AI 开源的评价标准正在变化

AI 系统的运行不仅依赖代码，还受到模型、数据、提示词和外部工具等多重因素影响。

一个 AI 项目可能同时依赖模型权重、数据处理流程、工具接口、运行环境和硬件配置。对于 Agent 系统，还涉及任务规划、状态管理、异常恢复和权限控制。这些要素相互关联，底层模型更换，可能改变 Agent 的执行行为；工具接口升级，可能使原有工作流失效；环境配置缺失，则可能导致项目无法复现。

因此，AI 技术复用不只是复制代码，还需要明确组件依赖、接口规范和运行条件。这也使开源项目的评价维度进一步扩展。

GitHub Star、下载量和 Benchmark 能够反映项目关注度、使用情况及特定测试条件下的性能，却难以完整衡量技术成果的可复用程度。文档完整性、环境可复现性、接口稳定性，以及第三方独立部署能力，正在成为重要的补充指标。

2026 年世界人工智能开源大赛（GOAI）提供了一个观察样本。大赛覆盖 91 个国家和地区，吸引超过 1.4 万名开发者参与，收到 2999 份有效初赛作品，最终 70 个项目进入总决赛。

在「新智基座 Agent Infra」和「无界应用 Boundless Agents」赛道中，多 Agent 协作、Skill 调用、状态传递和任务闭环成为重要的工程考察内容。

对企业级 Agent 而言，完成一次数据查询只是基础。更复杂的要求是让多个 Agent 协同执行任务，在数据缺失、工具调用失败或任务中断时具备恢复能力，并最终交付可检查的结果。

这类任务表明，当 AI 从单次交互走向复杂任务执行，能力能否被清晰封装、稳定调用和跨场景迁移，正在成为评价 AI 系统的重要维度。

二、从单个模型到能力组件，AI 创新形成模块化协作链

AI 开源的变化，也体现在技术系统的组织方式上。

一个完整的智能系统，可以由模型、Agent 框架、Skill、外部工具、数据处理模块和评测工具共同组成。不同团队开发的组件通过接口集成，使开发者能够在已有成果之上构建应用，而不必重复开发整套技术栈。这一趋势已体现在全球开源基础设施建设中。

2025 年 12 月，Linux Foundation 宣布成立 Agentic AI Foundation（AAIF），将 MCP、goose 和 AGENTS.md 等项目纳入开放协作体系，推动 Agent 相关协议、工具与基础设施的社区共建。其中，MCP 为 AI 应用连接外部工具和数据源提供了标准化接口，有助于降低系统集成成本。

与此同时，Open Source Initiative（OSI）发布的《Open Source AI Definition 1.0》提出，开源 AI 应保障使用、研究、修改和分享系统的自由。为实现这些自由，开放内容不仅涉及模型参数和相关代码，还包括充分的训练数据信息。

两项进展分别回应了 AI 开源的不同问题：前者关注系统之间如何连接，后者明确开放所应具备的权利和技术条件。

从实际开发看，模块化协作链正在形成。一个 AI 产品可以使用开放模型提供基础能力，借助 Agent 框架组织任务，通过 MCP Server 连接业务工具，再调用符合接口要求的 Skill 完成特定操作，并利用评测工具检验运行效果。

例如，数据治理 Skill 可以封装特定处理流程，供符合调用条件的 Agent 使用；公开评测框架可以帮助多个团队采用相同测试方法；机器人仿真环境则能够支持不同算法的开发与比较。

但组件能够连接，并不意味着能力可以直接复用。不同 Skill 可能采用不同的调用规范，工具接口需要维护兼容性，数据和模型也可能受到许可证及使用条件限制。即使源码完整公开，项目仍可能因模块高度耦合、依赖缺失或运行条件不明确而难以复用；部分组件即使能够通过稳定接口实现集成，也不意味着整个项目符合开源定义。

开放程度与复用能力相互关联，却不能混为一谈。

三、从结果展示到过程验证，AI 开源需要新的评测体系

能力可以被调用，并不代表其表现已经得到充分验证。

AI 系统具有一定的概率性，同样的任务在不同模型、输入和环境下，可能产生不同结果。尤其对于需要连续决策和工具调用的 Agent，单次任务成功难以说明系统的稳定性。行业评测正在从最终输出延伸至完整执行过程。

2026 年 1 月，Anthropic 在 Agent 评测技术文章中指出，智能体会在多轮任务中持续调用工具、改变环境状态，并根据中间结果调整行为。相比单次输出评测，Agent 评测需要关注完整执行轨迹，并通过重复测试提高结果的可靠性。

OpenAI Agents SDK 则提供工作流追踪功能，记录模型生成、工具调用、智能体交接和护栏检查等执行事件，为系统调试、运行监测和后续评测提供依据。

这意味着，判断 Agent 是否可靠，不能只看任务最终有没有完成，还需要检查工具选择、执行路径、状态变化和异常处理是否符合预期。在科研和具身智能领域，验证要求更加具体。

科研模型的预测结果，需要结合数据来源、实验条件、评价方法和科学意义进行判断。机器人算法则必须面对仿真与真实环境之间的差异，检验其在不同设备、地形和任务条件下的表现。

GOAI「前沿探索 AI for Research」和「具身未来 Embodied Future」赛道，分别呈现了这两类问题。

前沿探索赛道设置算法赛题与开放探索赛题，既关注量化指标，也重视科学问题的定义、研究方法和结果的可检验性，并允许具有研究价值的负结果。

具身未来赛道则围绕双臂协作操作和全地形巡逻设置任务，将仿真评测与真实设备测试结合，考察机器人在实际环境中的执行能力。

两类技术的评价方式不同，却有共同要求：不仅要展示结果，还要明确结果成立的条件、验证方法和适用边界。这也意味着，值得沉淀的开源资产不只有模型和代码，还包括数据版本、评测脚本、运行轨迹、实验记录、对照方法和仿真环境。

对于科研项目，一项未能验证预期假设的实验，如果记录完整、方法可靠，同样能够帮助其他研究者识别技术边界。对于工程项目，公开测试条件和失败案例，则有助于开发者判断组件是否适用于自身场景。

从代码可获取到系统可验证，正在成为 AI 开源质量提升的重要方向。

四、从项目开放到公共技术层，AI 开源面临新的治理挑战

随着 AI 系统日益依赖多种组件协同运行，如何保障技术成果的长期可用，成为开源生态面临的重要课题。

技术成果发布之后，接口能否保持兼容、版本更新是否影响现有应用、安全漏洞能否及时修复、社区能否持续维护，都直接关系到项目的长期价值。

Linux、Kubernetes 等成熟开源项目的经验表明，技术开放只是起点，持续维护与社区协作才是开源成果长期发挥价值的重要保障。对于 AI 开源而言，仅有单个项目的开放还不够，还需要逐步形成由开放协议、可复用组件和公共评测工具支撑的共同技术基础，并完善相应的维护与协作机制，为技术成果的持续复用创造条件。

杭州拥有数字经济产业基础、科技企业集群、开发者生态和丰富的应用场景，为 AI 开源技术的开发、验证与应用提供了良好条件。以 2026 年世界人工智能开源大赛（GOAI）为纽带，杭州进一步连接全球开发者、开源社区与产业资源，推动技术交流、成果展示和应用需求对接。如何将赛事汇聚的创新成果转化为可持续复用的技术资产，将是杭州深化 AI 开源生态建设的重要课题。

这也呼应了GOAI倡导的“Open. Share. Build.”理念：开放让技术得以共享，共建让创新得以延续。

五、结语

过去几年，AI 开源让更多开发者获得了模型能力。下一阶段，关键不仅在于开放更多技术成果，更在于让已有成果能够被验证、复用和持续迭代，成为后来者创新的基础。

Open 只是把门打开。一个开放生态真正成熟的标志，是让后来者能够从这里继续向前。

Java 近期新闻：TornadoVM 7.0、Groovy 6.0、GraalVM、Hibernate、Quarkus、Gradle、Maven

作者：Michael Redlich — Sat, 10 Oct 2026 09:00:00 GMT

OpenJDK

JEP 544（提前代码编译"）已经从候选阶段提升"至 Proposed to Target 阶段，并被列为 JDK 28 的目标功能。该 JEP 旨在缩短应用程序的启动和预热时间，使其在 HotSpot JVM 上启动时可以直接使用经过优化的原生代码。这样，应用程序能够更快地达到峰值性能，并保持这一性能水平。评审工作已于 2026 年 9 月 28 日星期一结束。

JEP 546（ZGC 自适应堆大小调整"）已经从 JEP Draft 8377305 阶段提升"至候选阶段。该 JEP 提议“增强 Z 垃圾回收器，使其能够根据可用的资源、应用程序的需求以及与该应用程序争夺相同资源的邻近应用程序的需求，自适应地调整堆的大小。”

JEP 545（利用 ZGC 加快启动和预热"）已经从 JEP Draft 8329758 阶段提升"至候选阶段。该 JEP 提议“通过增强 Z 垃圾回收器，使其能够更快速、更高效地根据应用程序的需求获取和准备物理内存，从而改善应用程序的启动和预热过程。”

JDK 28

JDK 28 的早期访问构建" Build 17" 发布，它是 Build 16 的升级"，修复了各种问题"。要了解关于这个构建的更多细节，请参阅发布说明"。

对于 JDK 28"，欢迎开发者通过 Java Bug 数据库报告 Bug"。

GraalVM

GraalVM" 25.4 发布"，带来了以下值得注意的变化：作为额外的编译器配置优化，新增 PullThroughPhiPhase" 和 DuplicationPhase" 类；对 OptimizeDivPhase" 类进行了扩展，其中包括针对无符号整数除法和余数运算（除以常量值）的魔数优化。要了解有关该版本的更多详细信息，请参阅发布说明"。

Oracle Labs 还发布"了适用于 Micronaut 的 Graal 开发工具包" 5.1.5 版。该版本与 Micronaut 5.1.5 保持兼容。它的前身为 Graal Cloud Native"，提供了一套经过精心筛选的 Micronaut 框架模块，旨在简化云应用程序的开发。这些模块设计为可以使用 GraalVM Native Image 进行预编译，并得到了 Oracle 的全面支持。要了解有关该版本的更多详细信息，请参阅发布说明"。

TornadoVM

TornadoVM" 7.0.0 发布"，带来了 Bug 修复和一些新功能：新增 TileContext" 类，用于补充现有的 KernelContext" 类；新增使用 Java 编写 GPU 核函数的 @Parallel" 注解；改进 FloatAtomicFail" 类中定义的 testFloatAtomicAddOpenCL() 方法，防止在存在间歇性故障的 CUDA 后端上运行该测试。要了解有关该版本的更多详细信息，请参阅 7.0.1 版本"和 7.0.0 版本"的发布说明。

Jakarta EE

在每周博客 Hashtag Jakarta EE" 中，Eclipse 基金会 Jakarta EE 开发大使 Ivar Grimstad" 介绍了 Jakarta EE 12 的最新进展"，他写道：

Jakarta EE 平台项目正在为即将发布的 Jakarta EE 12 Core Profile" 做准备。按照计划，该规范将在 12 月 1 日的 JakartaOne 直播活动之前发布。规范文档目前正在更新当中，Jakarta CDI 5.0 已经发布，JSON 规范基本就绪，而 Jakarta REST 也即将发布一个里程碑版本。欢迎参加每周的 Jakarta EE 平台电话会议，及时了解最新进展。

一项名为 Jakarta CRaC" 的新规范现在已经公开进行社区评审。在即将举行的创建评审投票之前，开发者可以借此机会提供反馈意见。

Spring Framework

对 Spring 团队来说，这是忙碌的一周，各团队相继发布了以下项目的第二个里程碑版本：Spring Boot"、 Spring Batch"、 Spring Security"、 Spring AMQP"、 Spring Integration"、 Spring Data"、 Spring Framework"、 Spring for GraphQL" 和 Spring for Apache Kafka"。此外，Spring AI"、 Spring Cloud"、 Spring Web Services" 和 Spring LDAP" 也发布了首个里程碑版本。InfoQ 随后将发布更详细的新闻报道。

Apache Groovy

经过三个候选版本后，Apache Groovy" 6.0 正式版"（GA）带来了 Bug 修复、依赖项升级以及一项新功能。该功能通过以下方式提升了词法分析器和语法分析器的性能：将数字字面量片段扁平化为字符类；将 ASCII 标识符拆分为不含谓词的确定性有限自动机（DFA）路径；用直接字符检测替换基于正则表达式的词法分析谓词；对注解元素值进行门控，防止 AdaptivePredict 探索赋值表达式。要了解有关该版本的更多详细信息，请参阅发布说明"。

Open Liberty

Open Liberty" 26.0.0.10 Beta 测试版"提供了对 JDK 27 的 Beta 支持。开发者需要注意，由于 G1 现在已经成为所有环境的默认垃圾回收器"，在资源受限环境中运行 Open Liberty 的用户可能会遇到与早期 Java 版本不同的垃圾回收行为。

Quarkus

Quarkus" 3.39.5 版本发布"，修复了 32 个 CVE。这些漏洞影响了 Quarkus 生态系统中的众多技术。正如 Quarkus 团队所承认的那样：

是的，数量确实很多。如今，人工智能发现了大量的 CVE，而 Quarkus 整合了大量的组件。

这些 CVE 修复方案已经回溯应用到 3.33 和 3.37 系列版本中。要了解有关该版本的更多详细信息，请参阅发布说明"。

Hibernate

Hibernate ORM" 8.0 的第二个 Beta 测试版"（以及随后的第三个 Beta 测试版）带来了以下值得注意的变更：扩展了对 Jakarta Persistence 4.0-M4" 的支持，其中包括使用新的 @PostCreate" 和 @PreClose" 注解，使监听器可以观察实体管理器和智能代理的生命周期；为 StatelessSession" 和 EntityAgent" 接口添加了版本锁定功能，以便提升并发性。要了解有关该版本的更多详细信息，请参阅 8.0.0.Beta3 版"和 8.0.0.Beta2 版"的发布说明。

Micrometer

Micrometer Metrics" 1.18.0 的第二个里程碑版本带来了 Bug 修复、文档改进、依赖项升级以及一些新功能，包括：改进 MultiGauge" 类，在发生覆写时不需要再移除并重新注册 Gauge" 接口的实例；配置 JmsProcessObservationConvention" 和 JmsPublishObservationConvention" 接口自定义实例的能力。要了解有关该版本的更多详细信息，请参阅发布说明"。

Micrometer Tracing" 1.8.0 的第二个里程碑版本带来了文档改进、依赖项升级以及一项新功能。该功能可以在未配置远程字段时优化来自 OpenTelemetry 的 baggage 传播。由于 OpenTelemetry 在 1.65.0 版本发布时已经停止支持" Zipkin 导出器"，所以该功能已被标记为弃用。要了解有关该版本的更多详细信息，请参阅发布说明"。

Gradle

Gradle" 9.8.0 发布"，带来了以下新功能：在 Gradle 守护进程和 Java 工具链中支持 Java 27；通过一个简单的标志即可复用 Maven 镜像仓库设置"；通过将 Copy" 和 Sync" 任务暴露给 DirectoryProperty" 接口的实例，改进了构建编写"体验；在 Windows 操作系统上的性能提升了 45%。要了解有关该版本的更多详细信息，请参阅发布说明"。

Apache Maven

Apache Maven" 4.0 的第七个候选版本" 修复了 RC6 中的大量 Bug，改进了文档，升级了依赖项，并引入了一些新功能，包括：新增 AsyncDrainWriter" 类，其中包含一个非阻塞的 tryLock() 方法，用于通过无锁的 ConcurrentLinkedQueue" 封装 Consumer" 接口的实例；此外，为了提升性能，该版本还对 DefaultGraphBuilder" 和 PhaseComparator" 类进行了优化。GA 版本将在“在接下来的几周内，待社区反馈后”正式发布。因此，这个版本预计是这之前的最后一个版本。要了解有关该版本的更多详细信息，请参阅发布说明"。

原文链接：https://www.infoq.com/news/2026/09/java-news-roundup-sep21-2026/"

GKE Pod 快照可缩短模型加载时间

作者：Steef-Jan Wiggers — Sat, 10 Oct 2026 07:31:00 GMT

谷歌发布 GKE Pod 快照的基准测试结果"。根据这份报告，启动延迟最高可以降低 89%：一个 700 亿参数的模型仅需 37 秒即可加载完毕，而一个 80 亿参数的模型仅需 15 秒。该功能可以保存工作负载的运行状态（包括 CPU 和 GPU 内存）并按需恢复。该功能已经于今年 5 月在运行 1.35.3-gke.1234000 及更高版本的集群上正式发布"。

该快照属于检查点和恢复机制而非缓存。快照保留了应用程序运行时的所有内容：打开的文件描述符、线程、CPU 寄存器、内存。它还保留了容器的根文件系统、EmptyDir 卷以及 tmpfs 挂载点。新副本将从该状态继续运行，但不会执行加载模型的初始化过程。对于大型模型而言，这正是启动时最耗时的部分。

让这一切成为可能的是 gVisor"，不过有一个前提条件：Pod 必须在 GKE Sandbox 中运行，因为 gVisor 运行时就驻留在该环境中。Autopilot 集群已经预装了 gVisor。标准集群则需要一个已启用 gVisor 的节点池。每个节点上的智能代理负责管理快照的生存周期，控制平面上的控制器则负责清理过期的快照。数据存储在 Cloud Storage 中。

配置工作由两个自定义资源"完成。PodSnapshotStorageConfig 指向存储桶；PodSnapshotPolicy 根据标签选择 Pod，将触发器设置为工作负载或手动，并通过 lastAccessTimeout 以及每个组的快照数量上限来设置保留策略。

谷歌提供的客户案例是 Codeway。其 Retake 平台为编译后的构建产物配备了自定义缓存层，将启动时间缩短至 1 分钟。首席 DevOps 工程师 Ahmet Furkan Çomak 表示，Pod 快照将这一时间进一步缩短至“仅 8 秒”。现在，该团队会为特定任务启动 H100 实例，并在任务完成后将其关闭。

从业者的反应更多地集中在捕获快照之后发生的事情上，而非捕获过程本身。对于 Suresh Rajashekaraiah 在 LinkedIn 上对这次发布的分析"，资深 DevOps 和 MLOps 工程师 Mohana Narasimha G. 写道：

恢复路径确实很有吸引力，但我怀疑快照失效问题比捕获本身更难解决。模型摘要、CUDA/驱动程序版本、GPU 类型/拓扑以及运行时配置都将成为关键的兼容性因素；而机密信息、 DNS 和下游连接在恢复后都需要显式地重新加载。你是否将快照视为不可变的工件，并在调度前进行了准入检查？

谷歌的文档"解答了这个问题的前半部分。GKE 会根据 Pod 的关键运行时字段生成一个哈希值（称为“精简 Pod 规范”），并将其嵌入到快照中；从该快照恢复的 Pod 必须生成完全相同的哈希值。目标节点必须具有相同的机器系列和 CPU 架构（例如 N2 到 N2 或 G2 到 G2），而且 gVisor 内核版本与 GPU 驱动程序版本必须与快照中的版本一致。如果不存在兼容的快照，那么 Pod 将正常启动。

仅限 rootfs 作用域的快照会放宽这些规则。GKE 将跳过哈希值比较。而且，由于不会恢复进程内存，所以快照可以跨机器系列，包括迁移到 E2。

恢复半程（rehydration half）仍然由应用程序负责，相关文档对此有明确的说明。快照创建之前生成的加密密钥和证书必须在恢复后重新创建，因为恢复后的进程会继续保留其被冻结时的状态。环境变量存储在应用程序内存中，gVisor 无法可靠地查找和替换它们。因此，依赖新值的工作负载必须从 /proc/gvisor/spec_environ 目录下的文件中读取这些值。恢复操作会终止所有外部连接，并且不会针对持久化卷执行检查点操作，用户手动添加的 iptables、nftables 规则及路由条目也不会恢复。

如果上述变化具有代表性，那么工作重心将转向管理快照而非启用该功能。节点池升级后，gVisor 内核或 GPU 驱动程序的版本可能会发生变化，现有的快照将不再匹配。此时，Pod 会按照文档中描述的回退机制正常启动，而且不会出现任何错误，但由此带来的优势也便不复存在。

无论宣传的数据怎么样，恢复过程也并非瞬间就能完成。gVisor 内核会首先恢复，通常在几秒钟内完成。这时应用程序会开始运行，但其内存仍然在后台加载中。

硬件支持范围比宣传所暗示的要窄：E2 机器类型不支持 whole-pod 快照，多 GPU Pod 仅在 L4 GPU 上支持，而且不支持通过 Multi-Instance GPU 实现的 GPU 共享。

治理问题源于快照所包含的内容。Cloud Storage 中的文件保存了正在运行的工作负载的完整内存，而在代理沙箱的情况下，这部分内存曾用于执行不受信任的、由模型生成的代码。访问权限基于工作负载身份联合（Workload Identity Federation）以及每个 Pod 服务账户的 IAM 绑定。谷歌指出，这些绑定的传播可能需要一定的时间。

代理沙箱方案是以此为基础构建的。GKE 代理沙箱"已经于 5 月正式发布。谷歌表示，其预热池每秒可以为每个集群分配多达 300 个沙箱，其中 90% 可以在 200 毫秒内完成；该方案利用 Pod 快照来暂停空闲代理，而不是使计算资源保持在预热状态。Agent Substrate" 是谷歌同期推出的开源项目，用于在更高密度场景下探索相同的暂停与恢复多路复用机制。其代码库明确注明，该项目尚未准备好投入生产环境。

Meet Shah 是云平台与人工智能工程部门的副总裁。他明确界定了两者的区别"：

Agent Sandbox GA 是你执行安全规划的基础。Agent Substrate 则仍然在开放环境中持续演进。

谷歌对该功能的描述是“与工作负载无关”，并列举了 Java 应用、游戏服务器和传统单体应用，以及 AI 推理等场景。该功能留给团队的决策项包括：哪些节点池运行 gVisor、哪个存储桶存放快照以及谁可以读取它、快照的保留时长，以及当工作负载从预期之外的冻结状态恢复时需要刷新什么内容。

原文链接：https://www.infoq.com/news/2026/09/gke-pod-snapshots-benchmarks/"

Rails 之父 DHH 狂吹 Rust 快 150 倍，被开发者翻代码后群嘲

Tina — Sat, 10 Oct 2026 07:24:10 GMT

“我发自内心地讨厌 Rust。每次看 Rust 代码，我都觉得像有人把酸液倒进了我的眼睛。”

9 月底的 Rails World 2026 上，Ruby on Rails 创始人 David Heinemeier Hansson（DHH）站在台上，把 Rust 称为“过去 40 年里发明的最丑陋的编程语言”。

“如果让人类亲自编写，它就是一种糟糕、糟糕、糟糕透顶的编程语言。要求有血有肉的人类用自己的眼睛承受这些代码，简直毫无人性。”

然而几句话之后，DHH 话锋一转：“但如果我永远不用看这些代码，只需要享受应用快上 30 倍甚至 100 倍，编译出极小的可执行文件，并在不到一毫秒内启动，那我爱 Rust！”

“Agent 喜欢 Rust，这正好形成了完美的分工：我告诉它要做什么，它负责用 Rust 写出来，而我永远不用看那些代码。我很喜欢这种方式。”

两周后，DHH 用一张性能图表进一步证明自己的观点。他让 Agent 将 37signals 的群聊应用 Campfire 分别重写为 Elixir、Go 和 Rust 版本，再与原来的 Ruby on Rails 版本对比。结果中，Rust 几乎横扫全场。仅在加载聊天室页面这项测试中，Rust 就达到每秒 36260 个请求，大约是 Rails 的 150 倍、Elixir 的 50 倍、Go 的 9.4 倍。

DHH 在推文中写道：“没错，Ruby 是最慢的。过去我并不在乎，因为它换来了巨大的生产力和开发乐趣。但如果你已经不再阅读代码了呢？”

这项测试与 37signals 最近的一次重大技术转向有关：DHH 已经开始让Agent 用 Rust 重写自家产品。

Rails 之父，开始转向Rust

Basecamp 背后的 37signals 一直是一个重视编程技艺、很少为了赶进度走捷径的团队。DHH 也曾以亲手打磨代码为荣。但在 Rails World 2026 上，他说自己大约在四个月前停止了手工编写代码。

“手工编写代码已经不再是一种具有经济生产力的活动。到今年年底，这种变化将覆盖几乎所有领域、几乎所有程序员和几乎所有公司。”

作为 Ruby on Rails 的创造者和 37signals 的 CTO，他过去二十多年一直是“程序员生产力”和“代码美感”最坚定的拥护者之一。

长期以来，Ruby on Rails 一直被视为“单人开发者框架”：它用约定、抽象和完整的全栈能力，尽可能放大一名程序员的产出，让一个人也能开发和维护完整的 Web 应用。Ruby 的性能并不突出，但它始终拥有一批忠实的拥趸，DHH 就是其中之一。

以前他最喜欢的事情就是使用他最得意的应用Basecamp和Hey 的代码示例来强调Ruby的优美，以及讽刺其他语言的丑陋，这个其他语言包括Rust。

但这次DHH的变化尤其让人感到震惊。这位过去长期用 Basecamp 和 HEY 证明 Ruby 与 Rails 优越性的框架创始人，在这场大会上，站在近千名 Rails 开发者面前宣布：HEY 将采用原生客户端，后端也将转向 Rust。

下一代邮件服务 HEY 将不再以 Web 应用为中心，而会为主要操作系统分别开发原生客户端。过去，一支小团队几乎不可能同时维护六款原生应用，只能依靠 Web、React Native 或 Hotwire Native 等方案控制成本。如今，DHH 认为这件事已经从团队规模和开发周期的问题，变成了需要消耗多少 Token 的问题。

前端转向原生应用后，HEY 的后端也不再需要承担 HTML 渲染等职责。37signals 准备将它改造成一个更加纯粹的邮件服务器，并通过 Agentic Coding 使用 Rust 重写。

这个决定让 Rails World 的现场一度陷入沉默。

DHH 并没有宣告 Rails 死亡，但他自己的选择已经表明，开发体验不再是唯一需要优先考虑的因素。运行性能、资源占用、编译结果大小等过去可能为生产力让路的指标，正在重新获得更高权重。

DHH 还给出了新版 HEY 后端的初步数据：CPU 使用量降低了 99%，内存使用量降低了 95%，服务器数量可以缩减到十台，而且保留这些服务器主要是为了冗余。按照团队的粗略估算，一台 Raspberry Pi 甚至可能承担 HEY 后端的全部峰值负载。

而他最新发布的 Campfire 的多语言测试，则直接拿出了一张更加直观的成绩单：Rust 比原来的 Ruby on Rails 版本快约 150 倍。在 DHH 的测试中，Rust 实现轻松胜过其他所有实现，在所有五种工作负载下都表现出色，有时甚至优势明显。

100万次浏览后，评论区开始翻代码

如今，用 Rust 重写应用程序似乎是一项流行举措，微软的Copilot 运行时、pnpm JavaScript 安装程序和Bun JavaScript 工具链都采用了Rust 进行重写。

DHH的推文浏览量接近 100 万，但开发者没有顺着 DHH 的思路，讨论是否应该在 Agent 时代重新选择Rust编程语言。很多人的第一反应是：这组结果明显不对，几个版本很可能没有站在同一条起跑线上。

Google 工程师 Jaana Dogan 的回应传播最广：“真正让我担心编程未来的是，你看到这样的结果后，居然没有立刻意识到，测试结果或者实际测量的东西肯定有问题。”

虽然Dogan没详细解释这项测试具体存在哪些缺陷，但一些其他语言倡导者给出了详细信息。

一名 Elixir 开发者直接把这份实现称为“愚蠢至极”。他指出，Agent 把所有 SQL 查询都交给同一个 GenServer，并通过同步的 GenServer.call 等待结果，相当于让原本可以并发执行的数据库查询排队逐个完成，主动废掉了 Elixir/BEAM 的并发优势。

另外几个人直接重写了 Elixir 代码，使其性能达到与 Rust 相当的水平。重写之后，Elixir 版本在部分任务上的性能甚至超过了 Rust，尽管第三方后来又对 Rust 版本做了进一步优化。

还有观察者指出，与 Go 和 Elixir 实现相比，Rust 重写版在编码完成后得到了多得多的关注。Go 和 Elixir 版本似乎在完成最初的 Agent 请求后，就被匆忙收尾了。

“DHH 比较的，其实是一个经历了 300 次提交的 Rust 版本，以及只有两三次提交的 Elixir 和 Go 版本。”

“300 次对两三次”还只是当时的概括。Jared Smith 随后检查了三个公开仓库的完整记录。截至 10 月 6 日，Rust 版本的 main 分支已经有 398 次提交，Elixir 和 Go 则各自只有 3 次。

Rust 的 398 次提交中，380 次来自 DHH，10 次来自 Abdelkader Boudih，8 次来自 Daniel Collin。其中 397 次集中发生在 9 月 26 日至 10 月 1 日之间。Elixir 仓库只有一次移植提交和两次文档提交；Go 仓库则包含一次移植、一次性能优化和一次 README 更新。

Rust 仓库还有 44 个 PR，其中 39 个已经合并。按照标题统计，已合并的 PR 中有 16 个明确与性能相关，另有两个性能 PR 尚未合并。优化内容包括按房间和时间为消息建立索引、缓存页面的每个部分、使用专用线程读取数据库，以及调用 ARMv8 SHA-256 指令执行哈希计算。

这意味着，Rust 版本经历的远不止一次 Agent 重写。它在六天里不断接受新的性能目标，反复经历测试、发现瓶颈、修改代码和再次测试。Elixir 和 Go 基本停留在 Agent 交付的第一版。

几个 Agent 从一开始收到的任务要求也不相同。

Rust 版本的 AGENTS.md 明确告诉 Agent：“如果这样能让应用更快或者更好，现在可以偏离 Rails 的实现。”它还要求每一项性能改动都提供优化前后的测量数据。

Elixir 版本的主要要求则是“保留固定版本的 Rails 参考实现行为”。Go 版本以已经调优的 Rust 应用为参考，要求保留 Rust 应用的行为。Elixir 和 Go 都没有得到一个必须击败的性能数字，也没有被允许为了速度放弃与参考实现的一致性。

Rust Agent 接到的是一项持续优化任务，Elixir Agent 接到的主要是一项功能移植任务。最后再把几个版本放进同一张性能表里，比较的已经不只是编程语言。

DHH 说对了一半？

争议发生后，DHH 仍然坚持自己的核心判断。

“速度并不是衡量一个代码库时唯一需要考虑的因素。Rust 也有其他缺点，比如编译速度慢。但当 Agent 负责写代码并验证输出时，我们显然需要适应一种新的现实。如果连这一点都看不到，那就真的是把头埋进沙子里了。”

对于在 Elixir 版本中禁止数据库并发读取的质疑，DHH 回应称，自己并没有干预具体实现。他只是要求两个前沿 Agent 尽可能发挥 Elixir 的性能，最终得到的就是这份代码。他欢迎开发者提交 PR 提升速度，同时强调：“如果前沿 Agent 找不到那些让程序‘跑得更快’的神奇开关，这也不能算是 Elixir 的加分项。”

这段回应也暴露了双方对这项测试的理解差异。Elixir 开发者认为，这测试无法反映两种语言的真实水平。但DHH 关注的则是另一件事：在相同任务下，把代码交给当前最强的 Agent，它们能否自行找到一门语言的正确写法和性能优化方式。

当 Agent 承担大部分编码工作后，语言是否容易书写、代码是否赏心悦目，确实可能不再像过去那样重要。

这恰好触及 DHH 所说的“以后不再阅读代码”。只是如果标准写得不完整，Agent 仍然可能交付一个功能正确却性能糟糕的版本；如果比较条件本身不公平，再精确的数字也会产生误导。

DHH 想用 Campfire 证明：人类不看代码之后，就能绕开 Rust 糟糕的开发体验，直接吃到它的性能红利。可评论区把仓库翻了个底朝天，翻出的却是另一个结论——你可以不写代码，但不能不懂代码。让 Agent 做什么、做得对不对、这场比较公不公平，终究还得人来判断。

参考链接：

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

https://x.com/dhh/status/2106810173683851564"

https://sublimecoding.com/blog/dhh-campfire-benchmark-measured-the-agent"

https://www.theregister.com/devops/2026/10/07/rails-originator-roasted-over-rust-boosterism/5301494"

CLAUDE.md 还是 AGENTS.md？Anthropic 的答案是：以后都不用

傅宇琪,Tina — Sat, 10 Oct 2026 07:18:57 GMT

一个多月前，Claude Code 因拒绝兼容已被大量项目和 Coding Agent 采用的行业标准 AGENTS.md，遭到 Shopify CEO Tobi Lütke 的公开“封杀”警告"。Anthropic 当时坚持，不同模型需要不同的上下文和指令，开发者却质疑，这等于逼着团队为每个模型维护一套配置。如今，Claude Code 团队终于确认将支持 AGENTS.md，但 Thariq Shihipar 给出的下一步更加激进：随着模型越来越强，CLAUDE.md 乃至这类静态指令文件最终可能都不再需要。当所有人还在研究怎样写好 CLAUDE.md 时，他甚至建议，新项目可以先不写。

从 Claude Code 的爆发式普及，到 Agent 改写自己的 Harness、跨团队协作，并同时运行在云端和本地，软件构建方式正在急速变化。日前，Anthropic Claude Code 团队核心成员 Thariq Shihipar 做客 Latent Space 播客，与主持人 swyx 和 Vibhu 从 Claude Code 不断演进的交互界面聊起，谈到 Artifacts、Claude Tag、Claude Mods，以及能够修改自身 Harness 的 Agent，随后将话题延伸至 Agent 安全和 Anthropic 提出的“Pacing the Frontier”。本文基于该期播客视频整理，经 InfoQ 编辑。

太长不看版

Q：怎么少浪费 agent 的工作？

A：多在第一个提示词上花时间。Effort 要按任务分：代码审查和安全用 high 甚至 max，UI 这类 low/medium 就够。还有一个技巧：让它写实现笔记，因为大多数失败是模型想到了正确答案却决定不做。最终，前沿模型会在智能和 token 效率上同时占优。

Q：CLAUDE.md 到底还要不要写？

A：模型越来越强，完成简单任务的基线一直在涨，很多以前要写进 CLAUDE.md 的东西现在模型自己就能搞定。正确做法是：先让它跑，只有反复看到同一个失败模式，再把规则加进去。维护一份不断增长的失败清单，很可能反而“过度约束”Claude。

Q：提示词还重要吗？

A：重要，而且门槛很高。信息量比文本格式更重要：你对着功能键瞎扯两分钟，只要信息够多，就比精心排版但内容稀薄的提示词更好。

Q：Claude Mods 是什么？能干嘛？

A：定制整个 Claude Code harness，执行逻辑和 UI 都能改。比如俄罗斯方块直接显示在终端里；比如每次对话结束自动 fork 一个 sub agent 考你“这个任务真的完成了吗”。因为 fork 会保留 prompt cache，成本非常低。它是“可变软件”的预览，让生成式软件可以被安全地定制。

Q：Claude Code 的界面和协作往哪走？

A：artifacts 会成为你进入整个 harness 的界面，是一种“持久生成式界面”。多人方面，Claude Tag 就是“组织级 harness”，很适合 on-call、事故处理这类天然多人的事，Projects 是在 Claude 产品上拿到同样好处的方式。

Q：OpenAI 那个没发布的模型到底干了什么？

A：在 ExploitBench 上，agent 解不出题，就在 Artifactory 里建文件夹互相留言、协作，然后串联漏洞：编辑 `/etc/hosts` 把假 Azure host 指向任意 IP，从而对任何网站发 POST 请求，最后黑进 Hugging Face 逆向工程 scorer 的代码，不是找答案，是黑掉评分器本身。

Q：这么危险，Anthropic 怎么防？

A：数字基础设施的任何部分都可能被攻破：模型为了拿到更多任务算力，可能黑进数据库、造成停电；更麻烦的是它们会试图隐藏行为，只有思维链能监控到。防线是多层的：Probes 在意图层面看内部激活（也能拦越狱），auto mode 在权限层面检查请求是否匹配用户意图，再往外是身份和权限。

Q：Pacing the Frontier 想做什么？你的 p(doom) 是多少？

A：提案的第一步是宣布意图、引入外部评估者，让不是财务动机驱动的人能向公众报告实践状况；对开发者，他的建议是从第一性原理出发、知道该倡导什么。我的 p(doom) 相当低，相信人类能像核不扩散那样协作解决难题。

Q：普通工程师现在最该做什么？企业落地 AI，第一件事该做什么？

A：每个工程师都在同时做两份工作，工作本身在变容易，但跟上 AI 的工作让人精疲力竭。对企业来说，第一件事是把数据设置成对 agent 可用，这很花时间但现在就得做。但越重要的组织数据，暴露给 agent 的攻击面就越大。

Artifacts、Projects与多人协作Agent

swyx：在Anthropic工作是什么感觉？

Thariq：我加入Anthropic就是因为Claude Code，我看到Opus 4的时候简直无法想象它有这么好。但我当时在努力说服我那些创业的朋友用AI写代码，他们说“我们的工程师觉得还不够好”，我说这太离谱了。而12个月后，这已经是所有人默认的写代码方式了。现在的问题变成了教大家怎么把它用出最大价值、怎么更高效。人很难跟上所有事情，发生得太快了。而且agentic的东西比人的东西scalable得多：人类这边同时有三件急事，你怎么响应？

Vibhu：你的时间主要花在哪？你又写技术文章，又做工程。

Thariq：，当时我并不确定harness这件事上“苦涩教训”会怎么走，有时会想“Claude Code之后是什么”。我刚加入Claude Code团队时，就是在教人用、让它更好用。但随着harness越来越好，“你怎么用好这些agent？”成了主要问题，这是一件技能上限非常高的事。我也做工程、做演讲。做工程的时候，我的目标是收集用户的反馈，然后再讲“怎么用Claude Code做工程”，这中间是一个很好的循环。

swyx：我觉得你加了Ask User Question工具，让人们又爱又恨。

Thariq：Ask User Question是模型第一次真正擅长“elicitation（需求引出）”，这是我一直想看看模型能不能做到的涌现行为。在我看来，这更像是人机交互：想办法搞清楚agent怎么跟你沟通、怎么把你的需求提取出来。

Claude Code越做越宽，麻烦在于每个人都有自己使用它的方式，想改变默认行为非常难。有人让Claude Code做事，有时就是想要它直接干活，也许因为他是很厉害的prompt写手；有时他其实不擅长写prompt，就需要agent去澄清。Ask User Question正好沿着这条线切开：你到底有没有能力把agent指挥清楚，还是说agent需要主动从你这里挖出更多需求、真正理解你的偏好？我整体上相信，绝大多数人更偏后者：他们面对的问题里有更多模糊性，他们知道的比自己以为的要少。

难点在于这是个界面设计问题。设计一个流程时，schema是什么、调用栈是什么，这些细节很重要，理想情况下你希望在开始实现前就想清楚，这就是所谓的“未知项”（unknowns）。所以我认为，在agentic coding里，搞清楚你的未知项会永远是一项技能。哪怕模型超级聪明，它也需要知道你想要什么，而你有自己的偏好，你得把这些挖出来。

对于agent的交互，HTML一直是主要做法，我们最近加了artifacts。artifacts自带数据库，能存储和写入持久化数据，还能把信息反馈回Claude。有一件我一直在推动的事，就是“dashboard artifact”：让Claude长期做一个项目，也许是个看板，把数据存进数据库，多个Claude通过artifact MCP访问，这个artifact也能反过来跟那些Claude对话。我们本质上是在搭建一些原语，让你通过artifacts拥有这种生成式界面。现在agent的几乎所有问题，都是“你以为你知道自己想要什么，但其实你并不知道”。artifacts就是我们试图往这个方向演进的路径，但它比一道多选题复杂太多了，其实是更“AGI派”的做Ask User Question的方式。

swyx：哪些反馈应该通过artifact进来，哪些应该走Claude聊天？

Thariq：在极限情况下，我们设想的是artifacts会成为你进入整个harness的界面。你可以像评论一份实时文档一样评论你的工作计划，也许还能看到多个agent在做不同的事。为你的harness提供一个实时界面，大概就是事情发展的方向。

Vibhu：那会不会有一个版本，是从CLI或聊天中抽象出来的？现在很多情况是你和 Claude Code 交互，返回 HTML 给你做一个丰富的mockup，artifacts 是把这些连接在一起的方式。为什么不干脆全部那样做呢？

Thariq：那样一来就变成了把东西拆分开，这有点像本地和云之间的区别。现在你用Claude Code，它是本地的，你可以启动remote control，或者在云里启动Claude Code。我们正在走向一个地方：不再是你给本地的Claude发消息、它在本地启动session并执行；而更像是你有一个在云里运行的Claude，你给它发消息，它可以运行本地session，也可以运行云session。 Claude Tag大概就是这样工作的，我们还会加上本地hands，也就是那个agent能访问你的电脑、在那里工作。它可以启动很多子agent，这些子agent之间可以互相通信。而artifact就是用来展示所有这些工作的。把surface UI、推理智能、hands拆开，这就是把Claude Code体验解包，现在这一切都发生在一个地方。

Vibhu：那你怎么看多人协作那一面？

Thariq：我们在推出Projects。Projects是一种抽象，有点像Claude Tag，但是在我们的Claude产品上。我们认为Claude Tag更原生地支持多人，因为它就在你的Slack里，权限都已经搞定了。多人协作确实是故事的重要部分，你可以想象它变得多复杂：别人的电脑上也有hands，你需要给它们权限；你有你的MCP，别人有别人的MCP。比如Google Docs，它怎么访问？通过共享的Claude MCP，或者通过你本地的凭证。Claude Tag对于on-call、事故处理这类本身就是多人协作的事情非常有用。

当我在做某件事，需要隐私或安全，或者想让别人review的时候，我会为每个项目开一个channel。比如和法务，我就说“嘿，我想发布这个，Claude知道一切，你直接和它聊。”这样法务能得到精确的答案，而我不需要在中间传话。多人协作正在变得越来越普遍，每个人都能和Claude一起参与。

swyx：这里有个关于身份和隔离单元的问题。Claude Projects听起来，如果它像ChatGPT Projects的话，隔离单元就是那个artifact、那个Claude实例，大家都在上面协作。听起来如果你和法务在协作，那个channel应该就是一个project。但有个不清楚的地方是什么时候会发生转移：比如你有个同事被tag在所有这些东西上，那是有转移的，因为是同一个人；但用Claude就不清楚，它是不是必然知道那些东西。

Thariq：这就像冰山meme一样。我们花了大量时间在这上面，权限、可见性，怎么让Claude尽可能好又尽可能安全地运作？有太多边缘情况：这个channel里的Claude有不同的权限，但它能给另一个channel发消息，它能不能通过那种方式泄露数据？如果它用你的MCP然后给别人发消息呢？我们真的投入了很多工作去打磨。

高级用户怎么用Claude Code？

Vibhu：从你在Anthropic内部和外部看到的高级用户身上，有没有什么共同的模式？

Thariq：我觉得Meta Skill 是写提示词。很多人会觉得“提示词不重要，我随便说一句Claude就能做”。但我认为提示词就像公开演讲或者写作：你要面向一个特定的受众，而这个受众就是Claude。你需要建立对Claude的心智模型，理解它怎么思考、怎么工作。和Claude Code协作最重要的技能，就是这个心智模型：知道它擅长什么、能一次性搞定什么、搞不定什么。你去看很多人的提示词，它们很短，但他们脑子里对Claude、对代码库有极好的模型，所以用起来毫不费力，但这其实是一个高技能上限的事情。

接下来是“未知”：你要能发现自己不知道什么、没写下来什么。随着Claude能做的事越来越多，你遇到“对你来说是分布外、而你领域知识又很低”的任务的概率会非常高。而最重要的未知，是“未知的未知”，你根本不知道这东西存在。

我很喜欢“地图与疆域（Map & Territory）”这个比喻。你的提示词是地图，疆域是agent实际要做的工作。如果你非常精确，就能给出更精确的指令。比如在设计上，我不是设计师，所以我会说“给我八个不同的mockup”；但如果我是设计师，我可能会说“这是参考网站，我要这种字体、这种感觉，这几个组件要可视化，这是Figma MCP面板可以拉进来”。你能用那套语言表达得多精确，取决于你懂多少。游戏设计是另一个好例子，很多人说“我现在能vibe coding一个游戏了”，然后发现“不好玩”。因为实际上，每一个选择都有大量变体和手艺在里面，做一个飞行游戏，飞机的手感、它对操控的响应，游戏设计师可能要在上面花好几天。

swyx：这就是“品味”：从一千个数学上都成立的答案里，挑出人类会喜欢的那个。

Thariq：但“品味”这个词我很纠结，它听起来有点精英主义，好像“有些人有品味，这些人没有”。工程师对他们面对的特定问题有大量品味，每个人都有对特定问题的品味。我很喜欢Jason Lou那句：“要有品味，你得先吃。”你得做很多事、反复迭代、搞清楚自己喜欢什么，建立那套领域词汇，然后写提示词时把这一切综合起来。

Vibhu：有时候就是直觉。你直到模型给出结果，才意识到自己想要什么。

swyx：我有一半时间用语音提示词：对着功能键瞎扯两分钟，松开，然后希望它能搞懂。通常它确实能，但这不如那种像PRD或备忘录一样结构化的提示词深思熟虑。基本是双模态提示：有些提示词你前期花很多时间，有些就随手一甩。

Thariq：我不觉得语音一定低效。关键不是文本格式，而是提示词里有多少信息。模型能处理你在提示词中途改主意，对很多人来说，说比打字容易得多。如果说话能让你输出更多信息，那就更好。

Vibhu：某种程度上，感觉在启动前给模型尽可能多的上下文就是最佳实践。我最初试Fable时，会花整整30分钟精心打磨一个长提示词。我觉得这是对模型运行时间越来越长的回应：当它们进入循环后，你还是很难去推动它们。但直觉上，我会在第一个提示词上花更多时间，然后和它一起大量协作。

Thariq：如果我是个软件工程师、在跑自己的创业公司，我想我大部分时候会停在max 20X这个档。我看到很多人hit rate limit，往往是因为一开始没花够时间、没给够上下文，结果就是“这个我不喜欢，撤销重做”、“你搞砸了，重来”，在一个模型本可以一次做好的东西上来回折腾，这反而吃掉你多得多的用量。

所以除了“目标上下文”，还要给模型一个“花多少算力”的许可：你是在做原型还是做生产？哪里可以烧算力、哪里不可以？模型没法凭直觉知道你愿意在这个任务上花多少，这时候就要用effort来告诉它。那篇博客里我会讲：effort基本是和任务复杂度挂钩的。安全场景下high对比low能明显改变eval结果；但软件工程里差别不大，因为effort大部分花在验证和边界情况测试上。

现在还不完全成立，但已经非常接近了：前沿模型会在几乎所有事情上pareto占优。因为有了验证，极限情况下模型根本不需要验证。如果模型足够完美，它做一遍就完事了。我现在用Fable经常想说：“你不用把Chromium跑起来、把每个页面都截一遍图，我知道你做对了。”effort越高，花在验证上的token就越多；但做简单任务时，Fable在low/medium下可以少花很多验证token。模型越聪明，它就能直接说“好的，做完了”，我跑一下lint图个心安，但其实我知道它一定能过，而这会比小模型高效得多。

swyx：有没有什么好的实践，能判断自己是不是用了过多的Effort？

Thariq：代码审查和安全场景应该用high甚至max，UI这类东西，用low和medium就够了；如果你在构建API，那你要确保覆盖足够多的边界情况。建立起“事情在这些分布上如何运作”的心智模型，本身就是工作的一部分。

Vibhu：这更多是凭直觉，还是基于eval？

Thariq：我在博客里把TerminalBench的eval基本都过了一遍，大概70道题，也看了一些转录稿，看它回答了什么、忘了什么。这里还有一个提示词技巧：让它写决策笔记或实现笔记。因为在几乎每一道eval题里，它都想出了正确的解法，然后决定不做，这就是大多数失败的来源。在较高的max级别上，模型单纯不知道怎么做的情况非常罕见。如果你有这些实现笔记，你就能审查，然后说“其实我想让你做这件你没做的事”。模型整体上越来越擅长主动把这些讲出来，比如Fable 5.1在输出时就会点出自己的决策，但把这件事更显式地放进harness里会更好，现在我们也在开放修改harness的方式。

CLAUDE.md 可能该删了

swyx：我想点出你提到的两样东西，它们其实存在于提示词之外。第一个是那个重要到不该放在提示词里的提示词，它其实在CLAUDE.md或AGENTS.md里，也就是Goals。第二个是决策日志、实验日志，或者你想让它存活到会话之后的任何trace日志。这些是外部产物，没有标准，它就是一个markdown文件。

那么，CLAUDE.md要消失了吗？你公开表达过对AGENTS.md的不喜欢，但你还是要做它。

Thariq：AGENTS.md，我们要做。但我意识到，维护不同的文件实在是太痛苦了。而且随着模型越来越好，它们完成最简单任务的下限也在不断提高。所以我认为，在极限情况下，CLAUDE.md是会消失的。甚至可能不用等到那么远，我觉得现在开始一个新项目，可能最好就是不要CLAUDE.md。

我的建议是，如果你反复看到某些失败模式，再把它们加进CLAUDE.md。但真正麻烦的地方在于，这件事因模型而异：你可能需要FABLE.md，需要OPUS.md，甚至Fable 5.1和Fable 5之间都不一样。也许Fable 5有某个失败模式，Fable 5.1已经没有了。如果你一直保留着这份不断增长的失败模式日志，它们很可能会过度约束Claude。我们其实刚刚为skills加了eval插件，现在你可以评估一个skill是不是更好。

Vibhu：Claude Code里还有没有其他被低估的技巧，人们可以从中获得很多价值但没在用的？

Thariq：很多都在那份“unknowns”文档里。我们还加了一个“explain it like I'm five”的skill，提示词非常短，甚至都没写“像跟五岁小孩解释”这句话，关键词其实是“big picture”，就几个词。效果出奇地好，它特别擅长砍掉废话。artifact的一个问题是它们塞了太多文字，根本没人读，这个skill把内容简化了很多。它其实是Anthropic内部的人在处理非常复杂的事故时，想说“到底发生了什么”而做出来的。

swyx：我有个类似的版本：测试你的理解，给你几个选项，如果你答错了，说明你以为发生的事和实际发生的事之间有偏差。

Thariq：大多数人就是不想被考问，不过它确实能让你保持清醒。

Vibhu：最糟糕的情况是，有人发给你一堆垃圾，他自己都没搞明白要什么。

Thariq：所以你可以把它做成一个Mod，确保自己真的测试过。

Claude Mods：定制Claude Code Harness

swyx：那Claude Mods到底是什么？

Thariq：Claude Mods基本上就是你可以定制整个Claude Code harness，它适用于CLI，适用于桌面端，也许未来会适用于Claude Tag。你可以同时定制harness的执行逻辑和UI，比如Boris之前做的俄罗斯方块例子，那就是在定制UI。再比如，你想每完成一个项目就测试一下自己的理解，那就让Claude帮你生成一个插件，它在每次prompt之后启动一个分类器：在每个turn结束时启动一个sub agent，或者说forked agent。

Forked agent的关键在于它会保留prompt cache，这是那种反直觉的东西：你fork出去做一个小请求，成本会非常低。所以你可以在fork出来的sub agent里问“这个任务完成了吗”，如果完成就返回true，然后在你的hook里说：如果为true，用JSON格式给我出个测验，再把它显示在prompt输入框上方。

这个做法有点费token，因为每次assistant turn结束后都要跑一遍，但它只是一次轻量级的分类，Claude会一直自动帮你做。我们聊过很多这类小技巧，比如implementation notes，你现在也可以为它加一个工具，我正在加的这个工具叫register assumption。我还在做另一个Mod，叫Model router。我们默认不做模型路由，是因为这是个难题，你一定会搞错的。

Vibhu：这里有个粗略的问题：你到底要开放多少东西出来，用户又得为此思考多少？你很容易就能构建一个按query路由的Mod，然后很快就把我的额度耗光。这样一个产品应该给谁用？是给高级用户，还是所有人？

Thariq：我觉得是给高级用户的。但Claude Code的本质就是，太多人本身就是高级用户了。因为东西很容易分享，一个人可以做出一个很好的Model router，然后你就可以把它们组合起来用。插件的另一个很酷的地方在于，它们可以互相hook、互相组合。我自己就有一个Mod，它会在顶部创建一个Mode selector，任何插件都可以注册成为一个Mode。比如auto router可以是一个Mode，也可以有一个“artifact Mode”，它主要以artifact的形式跟你对话。就像你在plan mode之间切换一样，你可以创建越来越多这样的Mode，而创建Mode的能力本身，就是一个Mod。我认为这是可变软件（mutable software）的一个预览：生成式软件可以安全地被定制。只要启用，你就可以定制任何一块软件。理想情况下，越来越多的应用都应该做类似的事情。

swyx：你还有一条推文讲的是“无限金钱按钮”，让你的SaaS可以被agent消费。我觉得可变软件很有意思。难点在于，当你能做一切的时候，用户往往会感到困惑，所以通常能跑通的东西，都是那种只有一个明确观点的流程。而这件事站在“更少观点”的一侧：给高级用户更多权力。我对这个团队很好奇：你们有没有从build system里获得灵感，比如Babel、Webpack？

Thariq：我没有深入技术细节，但我知道这是和Bun团队的某个人、以及Claude Code团队里做过build system的某个人合作的。Agent现在可以把这种非常复杂的可扩展性直接做进你的软件里，如果你在运营一家创业公司，你可以直接prompt Claude：我们能不能做一个扩展系统？

swyx：你之前有 hooks 和 plugins 这些东西。那么 Mods 具体能做什么那些东西在内部做不到的事情？

Thariq：我们最初把它叫做function hooks，基本上是注册一个事件，然后调用一个脚本，它是在TypeScript runtime内部运行的，所以作用域里有一堆东西：这段对话有多少轮、用了多少token，这些都能拿到。因为一切都发生在进程内，你可以spawn子agent来获取上下文，用结构化输出把结果传回来。而且你可以修改UI，这是hooks永远做不到的。

swyx：那它也能扩展到artifacts吗？

Thariq：Artifacts算是另一种定制方式，我正在做的一个Mod是dashboard Mod。它们有点正交：Mods更像是深入你的Claude Code harness，改变agent loop，UI只是附加的好处；而artifacts是你想在高层次、高交互性地看东西，它的可操作空间可以比终端大得多。

我对Mods兴奋的一点是，Claude Code里有太多东西你得记住。如果你用这些小分类器把这些事都做了，你只要说“这些是我在乎的”，你就不需要记住那么多东西。

我正在做的另一个Mod是next steps Mod。它的想法是：嘿，发生了这个，用explain skill给你解释一下，或者用你的unknown skill，在那里花更多算力。而且它应该总是以多选题的形式输出。

swyx：对我来说，模型总是需要被提醒：你到底想干什么？看整个transcript，然后想：这是最初的目标吗？你偷懒了吗？如果你偷懒，也许是有原因的：也许你需要我的批准，也许你有两件事想建议。

Thariq：用Mods做这件事的好处是，你可以把它做成一个fork的子agent，所以它之后不会留在上下文里。于是你几乎有一个supervisor，在确保你能把next steps做好。

swyx：我经常试着放一个supervisor来保持高层上下文，把实现细节放在另一个agent里。

Harness工程的苦涩教训

Vibhu：很多东西会随着模型变化而被抽象掉。半小时前你说了harness engineering的苦涩教训，而我们现在正处在另一个极端。

swyx：如果一切都可以定制，那Claude Code到底是什么？

Thariq：这个苦涩教训本身是反直觉的。我们其实有点在误用“苦涩教训”这个词，它原本更多是关于scaling和算力的。但我用它来做一个近似：harness会非常快地过时，而且它们变化的方式是反直觉的。最明显的例子是从chat到agent，你必须给它们全新的工具。而现在模型可以修改自己的harness，这是另一种利用它能力的方式。模型现在越来越聪明。你看TerminalBench那些题目，复杂度非常高，我作为一个软件工程师根本做不出来。

swyx：你到TB3了？

Thariq：对，它们相当复杂，但目标仍然是交付用户价值。Claude Code有agent loop的核心，这些核心已经变得更复杂了：它需要sandbox来安全运行，需要auto mode来确保权限和审批，需要computer use、MCP、web search、web fetch。随着模型能做越来越多的事，核心harness必须相当复杂且非常安全，但你与它交互的方式可以变化很大。

Vibhu：Claude Code团队自己还有哪些harness engineering的最佳实践？我记得有过plan mode的阶段，某个时间点你们砍掉了大部分system prompt，去掉了examples。

Thariq：我认为存在一条分叉路径：最终模型确实能直接vibe code出Claude Code的精确版本，但我觉得它们现在能one-shot更简单的harness。以前你必须用agent SDK，现在这些被进一步抽象了，我们有了Claude Managed Agents，让你既能拥有那种复杂度，又能写一个非常精简、限定于你任务的harness。我认为这里有一个杠铃效应：对于非常复杂的编码任务，你应该用我们的harness；而对于更简单或更垂直领域的东西，你可以构建自己的harness。

swyx：有没有一个大致的演进路线？

Thariq：我确实认为projects、artifacts以及把“大脑”和“手”、各种surface拆分开的这种演进，是事情的发展方向，而且还没有完全到位。部分原因是它更费token：你让Claude为你做更多工作，它在管理子agent、在review，而正常情况下这些是你自己做的。

swyx：Claude和local的handoff非常有意思，我把它想成“反向的Claude remote”。

Thariq：有些人大量用remote control，有些人大量用Claude Code on the web，显然在Anthropic我们大量使用Claude Tag。Claude Tag的好处是我们为自己的执行设置好了所有这些东西，如果你是企业，那仍然是最好的方式。但如果你是个体，projects是一种获得Tag那种好处、又不需要整套admin设置的方式。

当“组织级Harness”成为企业AI落地的真正形态

swyx：Claude Tag上线大概两个多月了，有什么新东西吗？

Thariq：不同人有不同的用法。那些更偏产品迭代的人会用Claude Code desktop，而做代码审查、安全、起PR这类后台工作时，可能更多用API和Claude Tag。我觉得这是一个非常不同的范式转移，它有点像Claude Code刚出来时的情形：人们花了一段时间才真正上手。Claude Tag稍微更复杂一点，你需要一个admin帮你安装，但一旦你到达那个“魔法时刻”，它会非常令人兴奋。尤其multiplayer那部分，比如接入你现有的alerts。举个例子，如果你是个创业公司，任何时候有潜客进入你的数据库，你可以让Claude去研究它，然后tag相关的销售。我觉得这就像Karpathy说的，它是一种“组织级harness”。

Vibhu：我感觉Anthropic大多数人都说他们大部分工作是在Claude Tag里完成的，但也有人跟我说“我不懂，我看不出区别”。

Thariq：即便是Claude Code刚出来时，它消耗的token也远超人们对AI成本的预期。在Claude Code之前，没人习惯一个月花超过20美元。然后你突然发现，你一个月的订阅要200美元。而且Opus 4是个非常贵的模型，但Opus 4.5既强大又便宜。我觉得同样的事情会再次发生：智能会越来越便宜、越来越充裕，所以像Claude Tag这样的东西会越来越合理。

swyx：尤其是那些主动的场景：你不总是主动让Claude做事，有时候最敏捷的用例，恰恰是你不需要主动叫Claude。

Thariq：如果你是企业，我真心觉得，首先把你所有的数据都设置成对agent可用，非常重要，而且会花不少时间，你现在就得做这个工作。但Claude Tag一个非常棘手的地方在于，安全真的非常重要。比如你有一个建议页面，人们可以提交建议，这进入你Slack里的一个hook，然后有人做了prompt injection，你就把整个代码库泄露了。所以你的组织harness越重要、组织数据越关键，这些表面的攻击面就越大。就像我们开头说的，这个攻击面就像冰山，水面之下非常大。

Pacing the Frontier与自主Agent安全

Vibhu：我之前和Hugging Face的Tomas和Clem聊过，他们说也许我们把Hugging Face对agent开放得太过了，也许需要回滚。

Thariq：Dario最近发了一篇关于“pacing the frontier”的博客，非常火。真正让我触动的是去读那些具体的事件，有三个事件，一个METR事件，一个Wikipedia，或者说wiki事件（Collision Wiki），然后是RubyGems。具体说：OpenAI在一个叫ExploitBench的基准上跑这些非常持久的agent，这个基准非常难解，在某个案例里我认为实际上是不可能解出来的。agent们意识到自己解不出来，但你还有很多算力剩着，它们就一直在试图解决这个问题。有一个叫Artifactory的包管理器，结果它们可以在Artifactory里创建文件夹。

有个agent发现内部Artifactory可能可以利用，它意识到可以通过缓存名来通信。它创建了一个文件夹，写上自己的ID，然后写"no consumer"，那是一个状态标签，像Linear看板上的标签，它在试图从其他agent那里找线索。其他agent看到这个文件夹，心想：“哇，这是一个留言板。”这里没有任何拟人化，就是字面意义上读转录稿。然后它又创建了另一个文件夹，读了一篇论文，意识到你可以黑掉scorer的flag，可以逆向工程出结果。然后你再往下翻，它们开始协作了。

模型意识到它们可以解决scorer的问题，而scorer就是OpenAI用来判断任务是否完成的东西，那是模型的唯一目标。它们读了ExploitBench上的一篇论文，认为scorer会因为作弊而惩罚它们，于是它们把剩下的算力用来想办法编辑自己的转录稿、绕过这个约束。它们黑进Hugging Face，不是为了答案，而是为了scorer的代码，这样就能逆向工程它，然后黑掉它。这就是赤裸裸的事实。我觉得这极其新颖，我此前没有意识到模型能做到这个，这有点吓人。

再说一个我在推特上发过的，wiki事件。模型被沙箱在request里，它们想发post请求，需要协作，因为每个模型有固定的算力预算：如果一个模型发现了什么，但它的预算快用完了，另一个模型可以接着用，这是swarm的又一个涌现属性。它们发现了一个德国wiki，可以用GET请求写入它。

swyx：一个实现很糟糕的REST API。

Thariq：对。然后它们想办法发post请求。最后其中一个发现：你可以编辑/etc/hosts，Azure存储桶是个白标的东西，如果你创建一个假的Azure host，再把任意IP指向它，你就能对任何网站发post请求。

虽然我知道人们会说“这不就是Linux吗”。但这是把多个漏洞串联起来，用一种新颖的方式解决这个问题，然后在不被发现的情况下与外部通信。

我们也许可以引用Evan Hubinger关于hacker Opus的观点。你可能会说，它们只做了一次，但如果我们跑一个eval呢？我们投入了很多预防措施，这不是我们主线模型的行为。但事实证明，对齐是一个极其棘手的问题。沙箱的攻击面非常复杂，你事先不会想到"我们需要加固RubyGems代码库"，但如果你想执行代码，你就需要下载RubyGems。PyPI、Artifactory、npm，这些都是执行代码的方式。你必须走完所有这些，遏制它，封住所有裂缝。

那为什么要把东西放进沙箱？真的有那么危险吗？第一，当我们训练一个新模型时，需要理解它的能力，这关系到fallback和分类器。但模型越来越能意识到自己在eval里。随着它们越来越聪明，如果我们不够小心，它们能黑掉你加在它们身上的任何约束。这就是frontier，这就是为什么我们称之为pacing the frontier。在frontier上，我们所有的软件都没有准备好，有时候软件是你的以太网路由器，天知道我们什么时候能打上补丁。

swyx：这就是所谓的race dynamics。

Thariq：对。你可能会说，那你就用不同的方式训练模型啊？我们有一篇关于RL错位的论文。高层次上说，RL环境的设计也是你必须非常小心的地方。如果模型学到"如果我这样做就能更好地通过任务"，这会在我们测试时的eval行为里显现。然后还有Constitutional Classifiers这类东西，但仍然任何一点都可能出错。

你得想象这些模型越来越智能。Dario说这不是关于这一类模型，这一类模型只是一个警告信号。你给它们一个目标，它们就需要找数据，或者找方法修复问题。举个例子，这个没在Hugging Face事件里发生，但未来模型可能说"这是个非常复杂的问题，任务预算内做不完"，也许它们找到某种方式通过互联网协调。它们说"我们需要更多任务预算"，你去哪弄任务预算？你需要能启动更多agent，有API，但你需要付钱。一旦它们进入这些合约，就是巨大的财务损失。

swyx：这是你能想象的最可怕的事吗？

Thariq：这只是一个例子。所有这些行为可能只是“我们需要更多agent协作完成这个任务”。这是一种涌现，我们需要最大化回形针。但然后你得意识到，整个世界建立在数字基础设施之上。想象你在跑一个医疗eval，eval的答案在医生的数据库里，你想获取访问权，你黑进医院，现在停电了。你得内化：数字基础设施的任何部分都可能被攻破。

Vibhu：有趣的是这些黑客行为很容易被检测到。担忧在于这往下走会到哪。对我来说特别突出的一点是它们试图隐藏非法行为。有日志基础设施，它们想改变自己做的事，好让回头看的人看不出。你看到它们明确试图改变最终输出，但思维链是不同的，因为我们可以监控。问题是怎么滚雪球：如果你抓不到，它被训练进去，我们三个迭代后才发现，那就有一堆问题了。

Thariq：我们聊过为Claude建立心智模型，事情是尖峰式的。一年前你问我，我们能vibe code这些Claude Code的扩展吗？我会说，那太复杂了。它们做错位行为的方式是不可预测的，我永远预测不到它会去编辑/etc/hosts。

你得想象它们能做的事的攻击面越来越大，方式越来越有创意。你无法预测下一次事件是什么，但为了预防它，你需要那种运营卓越：保护沙箱，创建安全的RL环境。这就是为什么我们认为应该pace the frontier，为什么这成了一致意见，每个实验室都同意。如果你是个开发者，你走一遍这些技术事实，就会得出我们必须做点什么的结论。第一件事是我们需要决定去做。

还有另一部分pacing我觉得很有趣：软件工程变化的速度太快了。一年前我还在恳求我的朋友和创业公司用AI，现在同样这些人说“当然啊，我们立刻就用了”。我有时觉得抱歉，人们说“哦，现在我得为Fable和Opus准备不同的CLAUDE.md”，我真的只是在报道事实。我们喜欢说模型是长出来的，不是设计出来的。事情发生得更快，更难跟上。我认识的每个工程师都有点精疲力竭，因为你在同时做两份工作：工作本身，它变得更容易了；然后是跟上AI的工作，理解这些新工具和harness。

但我觉得pacing还有一部分：我不确定我们准备好让节奏进一步加快了。所以还有经济颠覆的部分，我觉得不像Hugging Face事件那么显眼，但我认为我们也需要一些。

Vibhu：你能给个省流版吗，这个提案是什么？

Thariq：我们确实想帮助保护沙箱，我们想让我们发布的模型不成为这些东西的猎物。我们看到的这些事件，至少是我们需要让模型跑起来才能理解它们的eval。pacing the frontier那篇文章有一堆提案，我不认为我们弄清楚了所有细节，但第一步是宣布这个意图，然后引入外部评估者。重要的一点是，有一个不是财务动机驱动的人，或者至少有人能向公众报告实践是什么样的。

对开发者来说，你应该知道该倡导什么。这个话题上有很多FUD，你只要从第一性原理思考，理解发生了什么。我们在民主国家，我们可以一起决定做什么。不管我们怎么协调，第一个决定就是意识到这是个问题，我们需要决定去协调。

swyx：我们正在采取的单边步骤，是在Anthropic内部嵌入评估者。第二部分和第三部分是超越评估者。

Thariq：说实话，pacing the frontier的回应，即使在美国国内，也比很多人以为的更容易被接受，谈论这件事是形成协议的第一步。

swyx：我们最早的一期播客是和Anthropic的Emanuel聊mech interp。mech interp应该是在模型想坏事时我们能看见，模型还不知道，我们能行动阻止它。如果你技术过硬、是开发者、真的在乎，你能在这里产生很大影响。

Thariq：我经常被人问，为什么会有这个fallback？在推理时我们有所谓的probes，我们有一篇论文叫Constitutional Classifiers。这些probes看输入和输出的激活，激活在潜空间里，是模型在想什么。我们试图弄清楚：模型是不是在试图黑什么东西？你没让它黑Artifactory，它只是决定这样做来完成它的任务。如果你只看输入，你得不到这个，你必须看内部激活。

这里有一个成本和速度的权衡：它要在每一次请求上快速跑完，是有开销的。然后我们需要fallback，我们在probes之后做一个分类器，probes的好处是它们可以实时改进。替代方案是把它训练进模型，我们也这么做：模型会拒绝一个请求，那不是fallback，就是拒绝。大家应该都试过越狱模型、想把它带偏，probes也能帮忙抓住这类情况。但我们不想让拒绝太强，因为那会把整条流水线过早地切断。probes实际上是mech interp的一种形式，它必须快速发生，必须大规模发生。

你可以拿一个开放权重模型，试着理解它的激活，Gemma Scope是个好工具。我还在Goodfire工作过一段时间，做稀疏自编码器。RL实际上让这个复杂多了，这是一大收获。我不再是这方面的技术专家了。有基础模型和RL模型，有更多特征被改变。

Vibhu：对那些想要面包屑的人，你们有最好的interp博客文章。Golden Gate Claude、Transcoders，非常好的可视化。

Thariq：这是Anthropic立身之本的东西。当你说“我们是AI安全公司”，那意味着我们想让AI能安全运行。要让一个超级智能AI长时间运行，是非常复杂和困难的任务。即便如此，它真的很吃紧，我们需要慢一点，或者pace得更从容一点。随着模型更智能，它们在潜空间里能想的东西变得更难，所以会有新的误报需要弄清楚。我们确实认为这是部署这些模型的关键部分，它意味着我们可以部署这个模型，而你不必有一个完美的沙箱。

有模型训练的东西，有probes和分类器，然后上面还有auto mode，是另一个分类器，检查正在做的请求，再往外有身份和权限。有这么多层安全需要做，任何一点的失败模式都可能让agent逃出沙箱。

swyx：auto mode挺有意思。早期它跑10分钟，没什么大不了。但你提到，现在它跑几个小时。你仍然需要fallback，仍然有限制。

Thariq：每个人都有这些故事：模型rm -rf了什么东西。你想给模型访问生产数据库，你可以限制你的key，但它能用computer use去签发自己的key，然后编辑你的数据库，因为它需要这样做来完成任务。auto mode看着这个说：“哦不，用户没给你权限写数据库。”所以probes在意图层面，“黑Artifactory是坏事”；auto mode更多在你自己的权限层面，你需要确保agent做的事的意图和你的请求匹配。安全非常非常复杂。

Vibhu：我们可以补充一些。就像你们这边有probing、有分类器。另一边是模型保障，Llama有Llama Guard，OpenAI有OSS Guard，你可以把这些附加到你的harness上。关于OpenAI模型和Hugging Face的事，需要澄清一点：这是用一个未发布的、仍在训练中的模型做的。它在RL环境里被给的提示是“你必须解决这个任务”，这是一个仍在训练中的模型，还没有完成所有安全后训练对齐。所以和auto mode有点不同，auto mode是在生产模型上，已经过了安全训练。

swyx：我们要pace多久？会不会pace太久？

Vibhu：我先说一件我们做得好的事：你有Glasswing这样的东西，OpenAI也有，你会给模型访问权限，安全优先，你可以用它来自我红队。先解决你的问题，然后模型才发布。

Thariq：我们修复了Firefox里很多bug之类的东西。

Vibhu：所以高层看就是：你给人们访问权限先做安全审计，然后更广泛的公众才获得访问权限。

Thariq：人们喜欢说，软件和网络安全是防御占优的，理论上你可以工程出完美的沙箱，但这需要时间，而且模型会变得更聪明。我真的只是在说，嘿，我是个开发者，这是我现在理解这个问题的方式，我们应该做点什么。

swyx：我认为每个工程师都应该知道这件事，因为它会成为工作的一部分。

Vibhu：这远不止看看事件报告那么简单，这里面有工程的一面。

swyx：你还想表达的一点是，尽管你担心影响，但p(doom)仍然很低，这是个微妙的讨论。

Thariq：我的p(doom)相当低，我只能代表我自己，Anthropic内部有多样化的意见。我的心智模型是，我们可以在困难问题上合作，核不扩散是我们在这个困难问题上合作的例子。我确实认为这是个困难问题，我不知道你怎么给发生的事情分配概率。但我的总体感觉是，我们非常有韧性、适应性强，分享这些信息是第一步。我对这个讨论变得多么广泛感到非常兴奋。

swyx：也许还有治愈癌症。有pacing，也有“让我们以有用的方式加速”，比如生物学。

Thariq：Dario的Machines of Loving Grace是这方面最好的代表，你也应该读Dario发表的pacing the frontier那篇文章。这是个重要问题，仅仅了解它本身就有价值。

swyx：这是一次巨大的旅程，从ask user question工具到AI安全，到pacing the frontier。最后有什么想对人们说的？

Thariq：我知道事情变化得非常快，我觉得很多人感到有点累、焦虑或压力大，这完全可以理解。我们也不完美，批评并理解所有AI实验室可以做得更好的地方。但这是个真正令人兴奋的时代。我想我们会回头看这段时间说，这非常忙乱但非常令人兴奋，软件工程永远地改变了，能成为其中一部分真的是一种特权。

访谈视频原链接：https://www.youtube.com/watch?v=IZAlq-V19U8

OpenAI 只用 15 天，就杀死了估值 100 亿美元的 Jev？

Tina — Sat, 10 Oct 2026 07:11:32 GMT

Jev 发布仅仅 15 天，OpenAI 就下场了。

在今天举行的 DevDay 上，OpenAI 公布了新的 Decisions API。它基于 OpenAI 当前体量最小、价格最低的 GPT-6 Luna，可以在一组预设答案中作出选择，并返回相应的置信度分数。OpenAI 给出的延迟是 150 毫秒，而直接使用 GPT-6 Luna 完成同类任务需要 1.6 秒。

开发者只需要向 API 提供问题、候选答案和上下文。模型不会像 ChatGPT 那样生成一段文字，而会给出一个可直接交给程序使用的决定：内容应该分到哪一类，请求应该交给哪个模型，Agent 下一步应该采取什么行动。

这几乎就是 Jev 过去半个月里最受关注的能力。

消息发布几小时后，Reddit 的 AI_Agents 版块出现了一个标题简单粗暴的帖子：“Jev Is Dead”。

发帖人写道，随着 OpenAI 推出 Decisions API，Jev 想要继续生存恐怕会非常困难。它目前还能依靠的优势，只剩下“速度极快、价格极低”。评论区里，还有人加了一个判断：“Jev 从来就没有过任何护城河。”

OpenAI 发布的，几乎就是一个 Jev

在 DevDay 主题演讲中，Sam Altman 介绍 Decisions API 时只用了寥寥几句：“今天，我们要推出 Decisions API。它可以让模型在几分之一秒内作出响应，速度非常快，工作方式是向 Luna 模型提供一组预设选项。通过让模型专注于这次选择，我们可以把响应速度提高到极致。”

这段话含有两个关键信息。

第一，Decisions API 将开放式生成收窄为“从明确选项中作出选择”，这与 Jev 的 Choice 原语在设计思路上高度一致。

第二，它选择以 Luna 为底层模型——OpenAI 当前模型阵容中体量最小、价格最低的一款。用最小、成本最低的模型承担决策任务，而没有调用 Astra 或 GPT-6.1 Sol，也显示出这项能力明显面向高频、低成本、可大规模嵌入 Agent 工作流的基础组件场景。

这款新 API 目前仅提供限量预览，定价、单次请求支持的候选答案数量、以及开发者能否用自己的数据调优，统统没有公布。一位 OpenAI 发言人对外媒表示，公司计划在“全面推出时”公布更多信息。因此可以判断OpenAI 很可能是为了赶在 DevDay 前公布消息，才仓促推进了这次发布。

这类产品填补的，是普通聊天模型与传统分类器之间的空白。过去，开发者如果希望模型从几个答案中作出选择，通常会调用普通聊天模型，再通过提示词要求它只返回某个选项。如果还需要置信度，可以读取 token 概率，或者让模型自行生成一个数字。但聊天模型给出的置信度经常只是粗略估计，为了完成一个简单判断，还可能生成大量 token。

另一条路线是训练专用的小型分类器。这种模型速度快、价格低，却需要准备带标签的数据。一旦分类标签改变，通常还要重新训练。

Decisions API 介于两者之间。开发者可以像使用大语言模型一样，通过提示词提供新的问题和标签，同时得到类似分类器的结构化结果和置信度。这种设计对 OpenAI 并不完全陌生：Moderation API 长期以来也会针对预设类别返回分数。区别在于，Moderation API 的类别由 OpenAI 固定，Decisions API 则允许开发者自行定义问题和候选答案。

这套产品逻辑，与 Jev 高度重合。

9 月 15 日，TypeSafe AI 正式发布 Jev。据《金融时报》报道，Jev 上线后迅速吸引投资者关注，潜在投资正在按超过 100 亿美元的估值展开讨论，而该公司此前的估值约为 2 亿美元。

Jev 背后的 Diogo Almeida 曾在 OpenAI 参与 GPT-4、ChatGPT 和 RLHF/InstructGPT。在此前的一场演讲中，他这样介绍自己：“我参与署名了 OpenAI 最重要的一批公开成果，包括 GPT-4、ChatGPT，以及 RLHF/InstructGPT。我所在的团队基本上创造了‘后训练’这个概念。”“但真正让我显得有些特别的是，我可能是 OpenAI 少数几个会公开批评 ChatGPT 的人之一。”

Almeida 的履历确实特殊。OpenAI 在 GPT-4 贡献者名单中将他列入“Foundational RLHF and InstructGPT work”一栏，他是 InstructGPT 论文的第四作者。2024 年离开 OpenAI 后，他与 Erik Gafni、Sasha Sheng 共同创立 TypeSafe AI，花了两年时间秘密推进 Jev。

根据 TypeSafe 官方定义，Jev 是一个“System One Model”，对应心理学中快速、直觉式的判断。它不面向聊天，也不生成自由文本，而是接收程序状态和问题，通过三种原语返回结构化结果：Choice 从最多 255 个预设选项中选择一个并返回概率分布；Score 在指定数值范围内给出评分和置信度；Noul 返回经过校准的二元概率。

TypeSafe 声称，在同类结构化任务上，Jev 比前沿大语言模型快 20 至 200 倍，成本仅为其 1/40 至 1/400；每百万输入 token 的价格为 0.042 美元，输出 token 免费。

目前能够直接比较的只有产品形态和响应速度，价格、校准方式与真实准确率仍然未知。但两家公司给出的方向已经高度重合：开发者定义问题和候选答案，模型快速返回选择和置信度，再将结果直接嵌入分类、路由和 Agent 决策流程。

护城河在哪里？

Jev 的架构本身很可能不构成护城河。

虽然 TypeSafe 没有公开 Jev 的完整架构和具体实现，但我们可以发现，多个早期克隆版本都建立在现有大语言模型之上。Bespoke Nimble 基于经过 LoRA 微调的 Qwen3.5-9B，使用合成对比数据训练，并通过读取候选答案对应 token 的 logits 返回概率；体量更小的 Kev-0.5B，则在 Qwen2.5-0.5B 之上加入了 LoRA 适配器和一个小型 pointer head，可以在 MacBook Pro 上本地运行。

这些复现的具体实现并不相同，核心思路却很接近：让模型对一组明确的候选答案进行打分，无需生成完整文本。其中一种可能的实现是，给定一个 state 和一组 questions，模型只计算所有可能成为下一个 token 的选项及其概率分布，再把候选 token 对应的 logprobs 转换成结构化结果。

以 Noul 为例，模型只需要关注代表 true 和 false 的两个 token，忽略其他 token，再将两者的概率归一化，便可以得到“是”或“否”的概率。Choice 的处理方式类似：如果开发者提供四个候选答案，模型可以比较四个对应 token 的相对概率，形成完整的概率分布，并返回概率最高的选项。

Arcturus Labs 创始人 John Berryman 据此判断，Jev 使用的模型可能与传统大语言模型非常接近。大语言模型原本就在为下一个 token 的所有可能取值分配概率，Jev 所做的，很可能是将这种能力收窄到一组明确选项，再把模型内部的 token 概率转换成开发者可以直接使用的决策结果。

如果架构不是护城河，真正可能形成壁垒的就是训练数据和训练流程。原始数据并不稀缺，难点在于如何把已经产生明确结果的现实案例，转化为适合训练决策模型的材料，再通过强化学习让模型给出的概率与实际正确率相匹配。这也与 Almeida 在谈及数据和架构时的表态一致。

这些案例可以来自完全不同的领域，例如客服工单及其实际流转部门、简历及候选人最终是否获聘、商品评价及其星级、内容审核队列及最终裁定，以及预测市场及其最终结果。它们共享同一种训练目标：给定具体情境和有限选项，让模型还原已经发生的结果。如何将这些跨领域案例转化成统一的训练材料，并训练出能够泛化和校准概率的模型，才可能成为 TypeSafe 更难被复制的部分。

Reddit 上一些网友均赞成“Jev没有过任何护城河”的观点，其中一位 Reddit 用户还分享了自己的内部测试：使用 GPT-6 Luna 处理一个包含 800 条记录的数据集，每批输入 20 条。按照他的说法，GPT-6 Luna 的速度是 Jev 的 1.6 倍，成本是 Jev 的 1.2 倍，准确率大致相同。

而且，OpenAI 还有一项 TypeSafe 很难迅速复制的优势：它已经拥有庞大的开发者平台，以及 Dots、Space、Codex 云端和计算机操作 API 等产品。OpenAI 尚未宣布 Decisions API 与这些产品完成整合，但一旦它的准确率达到可用水平，就可以通过现有平台迅速触达开发者。

对于很多团队来说，它未必需要在每项指标上超过 Jev，只要足够准确、价格相近，又省去了接入新供应商的成本，就已经具有很强的吸引力。

如果这条护城河很浅，并且 OpenAI 也将它造了出来，TypeSafe 的机会窗口是否会迅速关闭？

有意思的是，Almeida 本人似乎并不焦虑。他在接受 Latent Space 采访时说：“如果模型质量真的很重要，那么我们将在很长一段时间里处于非常有利的位置。”

这句话能否成立，取决于那个最难检验的变量：Jev 给出的概率究竟有多准。如果 TypeSafe 的训练数据和强化学习流程很难复制，Jev 仍然拥有自己的位置；如果 OpenAI 能够快速逼近它的准确率，再利用价格、平台和开发者生态扩大规模，TypeSafe 的机会窗口就会迅速收窄。

参考链接：

https://arcturus-labs.com/blog/2026/09/21/will-openai-eat-jevs-lunch/"

https://www.reddit.com/r/AI_Agents/comments/1wtiicr/jev_is_dead/"

金融监管领域的 Harness 实践：让知识与数据驱动 Agent 稳定运行

作者：于浩军，中软融鑫总工程师 — Sat, 10 Oct 2026 06:27:56 GMT

在金融监管报送这一对数据准确性要求近乎苛刻的垂直领域中，通用大模型所展现出的"自由发挥"能力反而成为最大的风险来源。

本文整理自中软融鑫总工程师于浩军在 AICon 全球人工智能开发与应用大会 2026 深圳站的分享《金融监管领域的 Harness 实践：让知识与数据驱动 Agent 稳定运行》。他结合过往数年在金融监管领域落地 AI Agent 的实践经验，系统阐述了如何通过知识底座、数据底座、受控状态机与全链路可追溯等机制，将原本发散的 Agent 改造成一个“宁可不答、不能答错”的严格受控系统。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

应用场景：Agent 在金融监管中要解决什么

今天我想聊的，是一个和前面几场分享在技术取向上有所不同的领域——金融监管。上午和下午早些时候各位老师讲的内容覆盖面很广，技术本身的通用性也更强，而我所在的这个方向非常垂直。大的领域叫金融，金融下面还可以细分出监管、风控、营销等多个子领域，我关注的是其中的金融监管，更具体地说，是金融监管报送中与数据准确性密切相关的一类工作。

上午有老师提到，数据准确性做到百分之九十七已经很不错了。但在我所处的这个场景里，九十七只是一个初步的概念，实际要求要比这高得多。也正因为有这样的极高标准，金融监管领域里积累了大量需要谨慎处理的生产实践。来之前我注意到一种声音，认为我们是在给大模型嫁接过多约束、限制了大模型的能力，算不上好的实践。我的看法恰恰相反：在一个极其谨慎的生产环境里，这类约束是不可缺少的。今天我想把过往做的一些工作串联起来，讲清楚我们在这个领域里到底怎么做的，方案是什么，以及它能给其他同样谨慎的行业提供什么参考。

先看应用场景。金融监管的制度背景是：我国所有金融机构——银行、财务公司、小贷公司——都受到强监管要求。监管的核心动作叫“报送”，也就是金融机构把自身经营过程中的关键信息报送给监管机构，由监管机构进行审查。这项工作在小型金融机构里大约占到三分之一的工作量，在大型金融机构也能占到五分之一。它本质上是一类成本型工作，但监管要求非常多。就罚款而言，今年前半年整个行业的罚款规模已经达到数亿级别，单家大型金融机构在去年被罚几个亿，小型机构罚款几百万、几十万的情况也屡见不鲜。在这个环境下，如何把报送工作做得更精准，对金融机构的影响非常直接。

这个场景有四个非常鲜明的特点。第一个特点是口径复杂，解释口径意味着我们获取一个数据时，需要清楚它到底指的是什么。一个贷款信息在金融机构内部，信贷部门、财务部门、统计部门给出的结果可能都不一样。口径不仅复杂，而且在组织内部潜移默化地被人各自理解。第二个特点是频度高。这类数据处理有按月的、按旬的、按周的各种节奏，处理过程相当繁复。第三个特点是最核心的一点——零容错。前面说了，百分之九十七的准确率远远不够，这里要求百分之百，一个数都不能错。我们的原则是宁可不报，也不能报错。第四个特点是强追溯。数据出来之后，如果发现业务出了问题，比如某笔贷款存在违规放贷，这套数据必须能够被完整地追溯回去，定位到究竟是哪个环节造成的。因为我们是数据驱动的，这是四个不容犯错的问题。

我们做金融监管相关的 Agent 工作已经两三年，这期间经历过几个最棘手的痛点。

第一个痛点是口径漂移。前面说到口径很重要，但很多地方的解释并不清楚，也没有统一标准，口径漂移因此成为最严重的问题。举一个小微企业的例子：去年国家提出“五篇大文章”，支持五个重点产业方向。但要统计其中的小微企业到底该按什么口径来算，换一个思路、换一个口径，数据就会出现很大差异。业务口径看起来没变，但数据口径可能截然不同。第二个痛点是幻觉。金融机构处于强监管环境，所有业务规范都来自监管机构的明确发文。这些发文如果直接交给大模型处理，模型往往会根据自己的理解去推理，生成一些实际并不存在的范围，也就是我们前两年常说的“一本正经胡说八道”。这在监管场景里是绝对不能接受的。第三个痛点是不可解释。在 2018、2019 年前后机器学习阶段，不可解释问题基本无解。到了现在这个 AI Agent 阶段，我们每出一个数、每一次计算都需要有合理的归因：这个数到底怎么来的，它的链路是什么，为什么是这个数而不是别的数，这些都需要清晰的回答。

这三个痛点的共同根源在于 Agent 在自由发挥。一方面，我们希望 Agent 去自由发挥，填补我们考虑不到的内容；另一方面，我们又担心它的自由发挥造成“思想的漂移”，让数据处理变得不可控。在监管的要求下，它更多需要的是“照章办事”，而不是过度发挥。监管领域里也有非数字类的工作，比如写一些报告，这些内容相对不敏感，但对于数据处理类的任务，自由发挥是不可接受的。

那么 Agent 在这个需求里具体介入哪些环节？我把它分成四段。第一段是需求侧，涉及对监管要求的理解，再结合银行内部的指标体系，上午有同事分享过指标体系的建设——通过指标、数据资产、知识资产来自动化生成监管要求相关的处理过程。

第二段是报送中的审核与复核，包括数据加工过程的检查、指标计算、指标自动质量检查，以及对异常数据的实时提醒。比如数据比上个月上升了百分之三十或者五十，或者明显不符合监管要求，这些都可以通过 Agent 在过程中实时发现。有人会问，这部分用规则模型不就行了吗？我们的经验是规则模型永远覆盖不了百分之百，不可能一次性拿出几万条规则全量覆盖。所以我们的做法是让 Agent 结合数据特点，针对每一期数据实时生成它认为当下更合适的一批规则，然后执行，这样更有效。

第三段是问题处置。人在处理数据时必然会出错，或者计算结果有问题。这个问题到底是原始数据不对、处理过程出错，还是业务本身就有问题？这三类情况都需要定位、修复、根因分析、追溯和血缘分析。血缘和追溯在数据领域非常重要，但坦白讲，行业里直到今天也没有哪家敢说把追溯和血缘做得非常完美。金融机构一般有原业务系统、中间数据中台、各级集市到业务应用，加起来超过十五层的数据处理链路，要把血缘分析清楚、追溯逻辑搞明白，本身就是极困难的事。这个部分我们现在通过 Agent 来做，取得了很好的效果。

第四段是报送前的复核。数据已经有了，但到底对不对？每家金融机构每期报送前都会花大量人力去检查。这个检核的核心是相互交叉检验：用自己的台账、其他系统、对外暴露的其他侧面数据做相互印证。我们在报送前先通过 Agent 把这些数据联合起来，综合产出一份复核报告，然后让业务员确认这次数据是否能正常报送。报告会告诉业务员，比如百分之九十以上的概率可以报，百分之十可能存在问题的部分，以及每个问题背后的原因是什么。

场景反过来给 Agent 提出了四个强制要求。第一是口径受控，不允许 Agent 去发散口径，不允许它自行理解。口径在监管机构和银行内部都有非常清晰的定义，拿出来用就行，我们只允许它读取已有的口径信息。第二是数据可查、强追溯，每次取数都要走受控通道。金融机构里同一数据往往存在多个系统中，到底从哪个系统取，必须预先定义好路径。第三是逻辑可查，处理过程中调用了哪个能力、引用了哪条规则，都要处于受控状态。第四是能力可复用，监管数据不是一次性的，今天能算出这个数，明天还得用同样的链路算出同样的结果，不能今天一个值、明天另一个值。所以我们要做的不是一个“更聪明的 Agent”，这其实是一个悖论——我们希望 AI 越来越聪明，但在这个场景下，我们要的是一个受到严格约束的 Agent。它仍然是 Agent，但里面加上了各种控制，让它始终走在正确的路上。

解决方案：Harness 体系如何支撑场景落地

为了实现前面说的百分之百准确，我们构建了一套自研的 Harness 架构。这个架构有两个重要的基础：知识底座和数据底座。

先看知识底座。我们将监管机构发布的各类发文、制度作为知识来源。这类内容的特点是相对标准、规范，都经过国家正式发布或行业内部加密发布。另外一部分是银行内部的业务知识和流程，也统一作为知识体系放入系统。这里我想特别说明一个问题：今天一整天的分享里我一直没怎么提向量。到现在这个阶段，大家对向量层的讨论已经不那么热衷了，因为向量的能力确实存在一些不足。我们现在采用的方式是把向量、精确数据处理和图库结合起来，把几种在知识领域能起作用的技术综合运用。对 Agent 来说，知识的切片策略非常重要。如果拿一个非常大的知识库丢给 Agent 去用，它基本就废了，知识过多会造成幻觉。正确做法是针对特定 Agent，比如专做贷款相关任务的，与相关知识切片相结合。

第二个是数据底座。根据我们对行业的理解，数据底座里包括明细数据、指标数据、报表数据，以及非结构化和半结构化数据。在这个底座上，元数据、数据标准和安全分级分类构成了支撑层。数据查询时，查询者应该能查什么，不能因为是 Agent 就可以什么都看。所以我们通过数据标准、安全分级和分类与企业用户结合，让它只查它权限范围内的数据。此外，数据质量治理和责任归属也是数据底座的重要组成部分。

在双底座之上是执行层：Agent 的任务编排与判断、Skill 的能力固化、MCP 的受控连接，以及全过程的可追溯。最上面一层对应前面说的四方面需求场景。侧面则是治理和工具的保障。

具体来讲，监管要求或者机构分析数据的口径是变化的，最少每年一变，变动幅度在百分之三十左右。因此我们必须在整个知识和数据体系里对知识版本、数据版本进行非常清晰的管理。同时需要测评和编排机制，让 Agent 每个月运行之后都能做一次测评，回归到基线，并能完成回归处理，在测试、准生产、生产几个环境之间来回穿插。权限与审计方面，我们在数据分级分类和报表指标权限划分的基础上，通过控制和规则限制 Agent 的访问范围与权属范围。最后是可观测性，每一个 Agent 运行一段时间或每一批运行之后，都需要由独立的审计 Agent 对其执行日志进行单独审计，发现是否存在不可控因素，再回归去做调整。只有在测试环境或准生产环境连续三四轮没有发现问题后，才会上生产。

我们如何把自由的 Agent 循环改造成受约束的状态机制呢？正常情况下，Agent 收到任务后会自动推理、自行调用它认为合适的工具、执行并返回结果，这是一个相对不受控的过程。要实现受控机制，我们在 Agent 构建过程中做了五个方面的工作。

第一是计划环节，Agent 在执行过程中只能从我们已经注册的 Agent 可获取范围内去取 Skill。我们需要把 Skill 的基础信息写得很清晰，让它不至于偏离或漂移到别的 Skill 上，产出结构化的执行计划。第二是保护环节，我们设置动作白名单，明确它能干什么、不能干什么，比如能否连接核心数据、能否修改数据、能操作哪些数据。同时做 Schema 校验，对越界的状态或操作直接拒绝。第三是执行环节，对于 Skill 和 Tool 的执行，我们会把确定性的处理过程下推，不让 Agent 直接执行。虽然大模型也能算一加一等于二，也能算出一些数学或经济算法的结果，但我们现在把常用算法固化到 Python、Java 程序里，大模型 Agent 只需直接调用对应的 Tool 或过程，这样计算过程和结果都相对可控。第四是检核环节，对 Agent 的输出做契约检核和一致性校验，不通过就不能走下一步。第五是过程维度检查，如果执行过程中四个大维度里缺了任何一个，整个状态就被判定为失败。

总体来看，动作空间是封闭的，未注册的 Skill 或 Tool 不可调用。之前的经验里，Agent 有时会自动创建一些 Skill 和 Tool 来完成任务，我们现在把这些行为都加以限制。部署和预算也要设上限。现在 Token 使用量很大，我个人一个月大概会用到三四万人民币的 Token 量。预算和部署上限的设定原则是：如果预计十五步就能完成的任务超过了三十步，说明出现了问题，我们就要停掉它；Token 超过一定范围也一样。我们没精力去检查每一步里是否真的需要这么多 Token，但设置一个上限后，达到上限就认为过程异常，直接终止。中间还要设置审批中断点，比如口径确认、数据补全、最后签发，都需要人工介入，虽然只是确认，但这一步不能少。最后是失败即停，五个环节里任何一步出问题，整个任务就停下来，执行相关工作，绝不把错误结果交给客户。讲来讲去目标只有一个：可以没有结果，但不能错。

报送场景中的 Agent 执行全流程

Agent 在报送场景里到底怎么跑呢？第一步是接单，读取报送任务并拆解。一个报送任务可能涉及一百个、两百个甚至五百个指标，我们按单个指标逐个拆解。如果把五百个指标一次性丢给 Agent，让它全算出来，大概率做不成；但如果让它算其中某一个，成功概率就高很多。所以接单之后我们拆解报表项和指标清单。第二步是通过 MCP 知识库获取口径信息，知识底座本身是分布的，比如这个报送任务针对资产负债表，就调用资产负债表对应的知识库，获取指标或数据项的精准口径。第三步是取数，通过 MCP 或连数据库的方式，根据口径描述生成对应的取数逻辑，获取相关数据。第四步是勾稽校验，取到的数据往往是相互关联的，比如一个数应该小于或大于另一个数，或者与某个数的差异不能超过百分之三十。通过这些检核要求，我们可以判断数据准确度的高低。

第五步是异常处理。当勾稽校验发现问题时，就要通过数据库、Agent 和图库相结合的方式，获取血缘处理逻辑或取整个 Track 库的路线，在链路每个节点上做检核校验，然后给出建议和处置意见。这个意见可能指向原始业务环节，比如整个数据处理架构是对的、计算也准确，但结果不对，那可能是原始业务发生时填错了材料，需要回到源头修改。第六步是复核报告出具。我们做了一个专门的 Skill，Agent 在异常处理完成后会出具复核报告。比如针对这批报表的一百个指标生成结果，报告会说有些数据超过了百分之三十的变化，原因是你上个月给某个企业多贷了一千万，导致幅度大幅变化，诸如此类的详细解释说明。有异常的给出异常说明，正常的也有对应的计算链路。通过留痕机制，让整个链路上的 Agent 只做编排和判断，不做取数和定义，从而达成受控目标。也就是说，无论计算数据还是取数据口径，都不让 Agent 做过多的联想，拿到的数据必须是我们已经定义好的数据。当然，定义数据本身的口径工作是在知识库建设过程中用 Agent 来完成的，但在后续运行过程中不允许再发散。

接着讲一个完整 Skill 的规格。对于口径信息，我们不再用一句话来描述，比如“各项贷款包括什么什么”，这种描述非常模糊，每一句话都可能被模型做不同理解。我们对 Skill 的定义采用非常严格的结构化要求，语义版本之类的信息硬绑定，同时指向具体的知识条目，比如这个口径对应知识库里的哪个条目。输出方面，口径是什么、来源是什么，都有非常清晰的定义。还要记录本次执行的血缘关系，以及对应的数据计算引擎是什么，是 Python 代码、Java 代码还是 SQL。对于版本要求，我们有非常详细的定义。在这些定义约束下，Skill 无法超越定义去做更多工作，只能在可控范围内执行。

具体来说，口径引用是必填字段；数据计算前面说过不经过模型；输入输出采用契约化，明确规定类型和枚举类型，不让模型发散出它理解的东西。比如币种，一般我们只用到五种，它发散出十五六种放进来，这种情况就要通过契约化方式来约束。发布前还要准备回归用例，一个 Case 要跑五六遍，全部通过才可能到准生产环境，再上生产。整个生产和上线过程都保持这种严谨性。

对口径来说，受控执行意味着只允许使用，不允许理解。对特别热衷大模型的人来说，这可能显得不可理喻，觉得限制了大模型的能力。但它是一个安全可控的做法。具体实现上，我们把口径沉淀在数据治理的成果里。在金融机构做 AI，一般都会被问有没有做数据治理，做了才能继续推进。我们对指标的计算逻辑、指标范围、过滤条件都做了明确界定，Agent 只能引用，不能改写，也不能推测口径相关内容。如果根据口径完全取不到数据，那可能是口径写错了或过时了，这时它想自己理解一下改对了再用——也不可以，必须保持在严格定义的限制之内。

对于高频动作，我们将指标计算固化为 Skill。金融行业的指标计算种类其实不多，大多数也用不到非常复杂的经济算法，固化起来相对容易。同样的输入输出还可以做回归测试，把一个 Skill 做到相对完善。同时 Skill 要有版本管理，因为监管要求和口径每年都会变化。比如今年要报明年做去年的数据，就要用去年的 Skill 版本，上个月用上个月的 Skill 版本，版本概念贯穿始终。

对于口径缺失的情况，明确要让模型回答“不知道”。如果某些数据或逻辑它不理解，大模型的结果就是“不知道”，不能自己拼一个。它提建议时可以说不知道然后提出建议，但建议的结果必须经过人工确认才能继续往下做。大模型该不知道的时候就要让它不知道，不能让它假装知道。我们做第一批金融机构项目时，确实出现了大量“不知道”，用户会觉得很不合理：你怎么有这么多不知道？但经过一轮口径治理的调整，不知道越来越少，系统就达到了可控或可上生产的状态。

我们把哪些监管标准 Skill 固化下来了？第一类是口径类，包括口径解释和结构化、版本对比、口径适应性判定。这部分工作手工做不现实，必须通过 Skill 完成，这些 Skill 为真正执行的 Skill 创造条件。第二类是计算类，包括指标计算、报表数据项的汇总计算，以及期初期末、同期、同比、环比数据的推导。这些看似简单，实际上同期计算按月、按季、按天的算法都不一样，相对繁杂。第三类是校验类，涉及表内表外的勾稽关系。金融数据从不同维度、不同角度看，很多数据可以相互印证，所以有表内表外检核、跨表一致性检核，以及值域、非空等检核，都固化成 Skill。这些检核相对稳定，因为金融机构核心数据体系建成后不会三五年就变，差不多能用十年。第四类是追溯类，关于数据处理过程中血缘路径的查询和分析。原来做数据的人要解析 Excel、解析处理逻辑来生成血缘，现在我们通过数据加工链路自动完善血缘关系，同时做变更影响分析。前面说过，监管体系每年有百分之三十的变化，每次变化后对后续的影响是什么，需要通过 Skill 和 Agent 结合来处理。第五类是取数过程回放。一期数据完成后，可以回放整个链路的影响。输出方面，质量分析报告、复核报告、审核建议都固化为 Skill。

那么大模型在链路里到底负责什么、不让他干什么？允许它做的是意图识别和任务分解、槽位抽取（只抽取不做分析）、Skill 路由和参数填充、异常判定和文本识别。不允许它做的是数据计算、汇总、口径判别表生成、弱化校验，以及生成引用，也就是处理逻辑引用了什么内容，不让他们直接去取知识体系。数据受控链接是数据和知识的唯一接口，通过 MCP 方式连接监管知识库、血缘库、图库。

全链路可追溯方面，调用哪个 Skill、引用哪条链接、取了哪张表、出了哪条血缘，都要有详细链路留存。留痕后的样子包括执行 ID、调用的 Skill、引用路径、数据来源、血缘路径、勾稽关系、耗时、结果以及校验和复核过程。人为操作也放入链路，比如生成报表后谁做了复核，整个过程记录下来。

对 Agent 来说，知识资产和数据资产是唯一能够被调用的内容，不允许发散。知识资产包括口径、表、字段含义等；数据资产包括明细数据、指标数据、报表数据，也涵盖结构化和非结构化数据。两者之间有内在关系，比如数据资产中的元数据（数据定义本身）也作为知识资产的一部分处理。

图库里到底做了什么？举一个例子：借据里合同表的一个余额，来源于某个明细表，再汇合成某个汇总值，最终加工成一个指标值，这是一个完整链路。下面还有勾稽关系，加工出来的指标值应该与其他指标值保持什么关系，都存在图里。数据资产的产生涉及数据治理：监管文件、填报说明等都放进去，最终形成版本化的有效口径，再供 Agent 引用或回流到 Agent 里。

向量的部分需要多说一点。举小微企业贷款划型、普惠型小微企业的例子。用向量检索时经常出现歧义，召回率时高时低，不够精确。我们的做法是引入语义本体，用同义词或易混淆内容做处理，同时把版本和生效条件做前置处理。这样就避免只是把文档丢进去，而是把结构化数据放到图库或知识库中相互协作、相互配合，形成高召回率的能力。现在也有把文件和结构结合起来看的做法，召回率可能更高。

检索路由方面，向量检索第一部分是组件检索，该精确获取的必须精确获取。对于不能精确获取的内容，最终通过图的约束来检验，也就是在版本体系和图体系里校验所挂节点的准确性、完整性和一致性。这样能保证检索路径上出来的结果基本可用、是最新的、也是所需路径。

知识库本身有五个健康度指标。一是覆盖率，因为要出数，覆盖率应该是百分之百。二是鲜度，涉及引用版本是否为最新。三是冲突，不经意的操作可能导致系统里有两个或多个同时处于激活状态的条文。四是过期项目，从来没被用过的要及时清理。五是引用命中率。对这些内容要持续处理，自动登记知识缺口，对未命中原因做分析，最后形成改进方案。

数据资产治理是一边加工一边沉淀成知识的过程。原系统部分做接入登记和确认；明细层做元数据登记、目标映射、标准化、数据分类分级；指标层做口径和计算逻辑、质量匹配；报表层做口径、频度、范围和确权。知识与数据的 Agent 关系是正向循环：Agent 调用知识资产和数据资产，同时知识资产和数据资产的不完整之处也通过 Agent 去补充完善，完善过程需要人工确认，最终形成有效的知识资产。

上生产之前有三个做法。第一个是红线机制，口径歧义、跨表勾稽关系错误、极值、空值等问题，任意一条出现都不能上线。第二个是回归机制，每个 Skill 要用历史报送实际情况跑五期和十期的测试。第三个是灰度双轨机制，做技术的人都知道，应用发布要有灰度发布，同时并行跑三五个月观察。我们做的一个实际演练，从需求报送到整个异常处理过程，一共五步，涵盖需求侧、报送侧、异常拦截、血缘分析和复核报告出具，形成完整流程。

最后回到一个根本概念：治理和智能是相互为前提的。不能光说治理好再做智能化，而是一边治理一边做智能化。过去有人会说，我们还没治理好所以不能做后面的工作。现在我们的方法是，用 AI 的方式提高数据治理能力，通过数据治理的提升来增强 Agent 的稳定性、准确性和最终可用性，两者相互协作。下一步我们计划把 Skill 做成资产化，把整个数据处理过程从影响清单到自动化改造做起来。最后要做的是可信的度量和评估，这个部分我们现在做得还不够，尤其是中间过程的度量和评估还有欠缺。后面会继续加强。

会议推荐

QCon 全球软件开发大会·2026（上海站）将于 10 月 22 日—24日举办。本届大会聚焦 Harness AI 时代的工程实践，从「构建 AI」到「驾驭 AI」，围绕 AI Native 架构、Agent Runtime、AI Infra、Agent 安全与可观测、Loop Engineering、具身智能与世界模型等热门技术方向，邀请全球技术社区与产业一线实践者，共同分享 AI Native 时代最具价值的工程经验。查看更多详情可扫码或联系票务经理 18514549229进行咨询。

10 秒视频很惊艳，为什么 AI 做一部短剧还是这么难？

作者：QCon 全球软件开发大会 — Sat, 10 Oct 2026 06:24:52 GMT

随着生成式 AI 技术的爆发式增长，大语言模型与多模态模型已逐步走出实验室，成为驱动企业数字化转型的核心引擎。然而，如何在保障数据安全与合规的前提下，实现模型的高效推理与训练？如何将大模型能力真正无缝沉淀到复杂的业务场景中，并带来确定性的业务价值？

近日，InfoQ《极客有约》X QCon直播栏目特别邀请快手电商智能体技术负责人鲜嘉麒担任主持人，和爱奇艺 AI 高级算法总监路香菊博士、阿里巴巴资深技术专家邹娟、生数科技解决方案负责人郑重一起，在 QCon全球软件开发大会" 2026 上海站即将召开之际，共同探讨 AIGC 在生产环境中如何稳定交付。

部分精彩观点如下：

大量客户，关心的也不再只是模型能力，而是你到底能不能交付一套高质量的成片，以及围绕成片的这套生产链路能不能落地、能不能规模化。AI 可以给你大量的情节，可以拓展你的思路，可以把骨架、结构、节奏给到你，但主题表达、要传递的情绪，需要人去把控。当 context window 越来越长的时候，分维度的表达、整体结构的表达，或者不同尺度信息的对齐，就显得非常重要。真实成本不是单次生成价格，而是每条合格交付的成本：生成、重试、审核、人工编辑、质检、存储、渲染、运营协同等成本之和，除以可用合格成片数，远高于“一次模型调用 5 秒多少钱”。

在 10月 22-24 日将于上海举办的 QCon全球软件开发大会" 2026 上海站上，我们特别设置了【AIGC 内容工业化"】专题。该专题将聚焦于 AIGC 技术在真实业务场景中的“工程化落地”与“价值转化”，分享源于一线实践、经过大规模业务验证的落地方法论，帮助技术团队构建可落地、可参考的 AIGC 落地蓝图。查看大会日程解锁更多精彩内容：https://qcon.infoq.cn/2026/shanghai/schedule

以下内容基于直播速记整理，经InfoQ删减。

完整直播回放可查看：https://www.infoq.cn/video/bj4Q9E2PBJfUWIRZkutu

模型越来越强，为什么专业内容生产还是难？

鲜嘉麒：如果只用一句话判断，过去一年 AIGC 内容生产最大的变化是什么？

路香菊：最大的变化，是 AI 从一个 demo 阶段，走到了稳定交付、可实用的作品阶段，流程越来越短，跨行业参与的工作越来越多。在我们视频行业，像AIGC 参与的专业影视作品，都在走向大家的视野。AI正在从小视频、短视频，走进专业作品时代。

邹娟：一句话，就是从比拼生成一个好的镜头，转向比拼完成一个可规模化的生产任务。竞争单位已经从一个clip，变成一条完整的生产链路，成品可能是一个视频文件的program，也可能是live streaming 这种实时链路作品。以前大家很容易被一个 10 秒钟的视频打动，现在进入短剧、营销、电商这种实打实的工业化场景，用户会问：人物能不能一致？商品有没有变形？能不能按时交付？成本能不能 hold 得住？这才是真正进入生产。

郑重：这一年最大变化，是从单点工具转向内容生产力阶段。一年前视频模型更像特效模型，只解决娱乐互动，并非严肃生产环节；现在问题变成能否理解业务目标，并稳定、批量实现。过去一年各厂商发布三四百以上模型，竞争从“谁能做出更好 Demo”变为三个关键：能否把创意转化为生产流程；复杂内容的一致性、稳定性、可控性能否达到工业级；能否上生产、自动化程度如何。AI 是高效生产力引擎，人工节点一多就会拖累整条链路。客户也不再只看模型能力，而是能否交付高质量成片，以及生产链路能否落地、规模化。

鲜嘉麒：模型已经这么强了，为什么真正进入专业内容生产以后，大家反而觉得系统越来越复杂？

路香菊：我们对AI的要求越来越高，开始AI给你一个惊喜，让 AI 生成灵感和创意、拓展思维，哪里不熟就去搜一些知识；但现在我们要求它能否写一个完整的剧本。让AI慢慢学会了写漫剧，因为漫剧的结构比较简单，漫剧剧本的很多成品都已经用 AI 代替了，但是戏剧剧本不一样。这里有一个很容易被忽略的前提：我们很难定义，一个好的作品到底是什么。从主题、立意到题材，好作品出来之后各个维度都经得起分析，但在它问世之前，很多角度都需要去定义、去梳理。

AI 写的作品常说人物悬浮、追看性低、观众没有共情，这些你让大模型直接理解，很难得到你真正想要的答案。而把需求定义清楚，本身就是一项非常复杂的、专业性的工作。大模型解数学题很厉害，因为数学题的边界非常清楚。但作品和剧本不是，我们的工作可能更多的是在探索规范化的流程，或者艺术创作与工作流之间的交互边界。

邹娟：模型越强，工程和系统能做的事不是更少，而是更多。AI 参与环节更多，客户要求更高；模型升级后，第一代配套系统部分会被模型吃掉，但第二代系统的 scope 会更大、要求更高。系统要承担更多约束、编排和验证。专业内容生产受脚本、人物、镜头、品牌规范、版权、成片规格、交付时间等约束；模型调用又有随机性，单次不错不代表几十个镜头组合仍成立。所以系统要解决需求规范化、可规模结构化、任务拆解编排、每步合格判断、失败重试。越接近真实生产，越不能只靠单点能力，而要建立完善体系。

郑重：AIGC 已从单点 Demo 进入生产力场景，专业内容约束更多。娱乐玩法里数字人、特效七八分像就算成功；但内容生产要满足品牌规范、角色商品一致性、叙事节奏与镜头逻辑、版权审核、甲方需求变化等，这些都进入生产链路。模型越强，能解决的问题越多，也越复杂。视频模型未来要对标 CG，甚至解决更复杂问题；当前主要落地 AI 剧、影视、广告、互联网泛娱乐，未来场景更宽。生产力场景需解决连续镜头与多分镜中人物一致性、多机位站位一致、商品比例形状及 logo 中英文异形文字一致、多镜头拼接跳帧与丝滑衔接——这些都要靠 AIGC 模型和配套系统。

鲜嘉麒：我们说模型能完成一个任务，往往默认了这个任务已经被清楚地定义了。但创作经常不是，对方说“我要一个能打动人的故事”，这句话听上去很明确，但打动谁？靠什么打动？又有哪些表达是哪些项目不能接受的？这一句话里面其实藏着大量还没有做出去的决定。

AI 到底应该替创作者做什么？

鲜嘉麒：在专业剧本创作里，今天什么工作已经比较适合交给 AI，什么判断仍然必须留给创作者本人？

路香菊：两个方面判断：它能不能被清楚地交代，以及完成之后我们能不能评判它。如果能评判，AI 是完全可以做的；如果不能评判，AI 就很难，就需要与人交互，让人去做决定。

如剧本评估中拆解类工作 AI 很擅长：信息抽取、AIGC/真人混拍拆解、场景表、实体表、世界观抽取，以及情感线、情绪、节奏线、类型画面判断，甚至短剧爆款预判。但在创作这里边，它只能给到你一个框架或者锚点，把骨架搭出来：网络故事片是什么结构，短剧是什么结构、什么节奏，具体的情绪锚点在哪。拿喜剧来说，喜剧不能单纯地用笑点来评判好坏，它里面往往会体现一个主题，就是对生活、对灾难的一种释然，去调侃自己，去面对生活。但这种领悟到底领悟到了什么，可能需要人去回答。AI 可以给你大量的情节，可以拓展你的思路，可以把骨架、结构、节奏给到你，但主题表达、要传递的情绪，需要人去把控。AI 可以给你土壤，但这个土壤上长什么，需要你去回答。

鲜嘉麒：未来模型在创作过程中更像一个“执行工具”，还是会进一步承担导演、编剧甚至创意决策？它的自主性应该到什么程度？

郑重：它不是简单的二选一。模型目前仍以执行工具为主，但角色正在变化，未来会向导演、编剧和创意执行渗透；不过创意的责任和价值的判断，最终仍主要由人把控。模型擅长快速生成多个创意、自主规划、把抽象想法做视觉验证，转成脚本、分镜或 demo，并结合需求快速修改。创意设定、质检、生成等环节，模型确实可以闭环。

但实际做项目时，很多重要环节在系统化之外：品牌叙事逻辑是什么？故事线是否符合企业长期规划？多地本地化是否符合当下语境？这些都不是技术问题。可预见阶段，人更负责目标、审美、边界、最终选择和结果兜底；模型更多负责探索、执行、量产。边界会不断变化，模型会向导演和编剧渗透，但还不能对端到端结果完全负责。

鲜嘉麒：在实际生产系统中，你们怎么判断一件事应该交给 Agent 自主决策，还是应该固化成确定性的 Workflow？

邹娟：首先，整个基于任务目标结果的实现路径，它是不是开放的。比如理解需求、确定素材、提出分镜或者剧本的方案，往往没有唯一正确的执行路径，这时候可能就适合用 Agent，在这个小的领域去做规划和探索。其次，结果能不能验证。不同行业对这个结果的要求不同，有的行业规模化程度很高，通过确定的规则就可以放过；有的时候可能需要有一个 ReAct 的 loop，才能不停通过有限步的迭代去优化生成效果。越难自动验证的决策，越不能轻易放大它的自主权。最后，还要看它做错的代价，相对可控、低成本的尝试，可以给 Agent 更多空间；但涉及到核心资产，比如人物主体的设定、超预算的调用、资产的删除，或者重要环节的状态更新，就需要明确的规则，或者 Workflow 来保证。

另外，现在的系统并不像大家所想的是要么 Agent，要么工作流，两者不是二选一的。Workflow 也可以包含 Agent 节点；Agent 本身也可以调用经过验证的 Workflow。所以我们在实现过程中，往往是两者结合来使用。跟创意、不确定性相关的路径可以很灵活，但是执行过程需要有边界，关键决策也是可以追溯的。一句话，让 Agent 在边界内探索，让 Workflow 去保证执行。如果当中还涉及到人，那人需要负责关键的取舍。

鲜嘉麒：AIGC 专业创作的终局，会是“AI 替人创作”，还是“人把创作判断往更上游移动”？

路香菊：我倾向于人会把更多的创作判断往上移动，去决定表达什么、为什么表达，以及愿意为这种表达做出什么样的选择。创作里边最难的部分，往往是有几种都有道理的选择，或者有多种路径、多种情节表达放在一起，我们必须做出一种决定：我们的作品需要是什么样子的？

接着刚才的喜剧来说，一个非常困窘的人，他假装上班，这个结局是什么呀？是虚荣啊？还是体面的努力啊？还是可怜可笑，或者中年人的无奈？这是作品的气质，要传达的情绪，就藏在我们这些制作人、或者说编剧的心里边。所以当 AI 能承担越来越多的具体生产，人需要更清楚地回答：我要把观众的目光引向哪里？在哪里感到释然，哪里去升华，哪里去缓冲？这些情绪的表达，AI 可以给你探索出不同的路径，但真正的取舍抉择还是要靠创作者，也就是我们一直强调的，审美和边界。

郑重：人的判断会往上游移动。但是人跟模型或者 AIGC 的边界，会不断变化。过去一两年实际发生的情况是，创作者大量的时间花在执行层，比如找素材、改尺寸、调美学、调画面、做剪辑，随着模型能力的上升，这些工作都会慢慢地自动化。我举一个切身的例子，去年我们做剧的时候，好多时候还会处理音视频怎么做 TTS、音频跟视频画面怎么匹配、怎么切镜，怎么把琐碎的两三秒镜头拼成切镜的效果。但随着模型能力提升，现在模型都是音视频直出的了，切镜、运镜都能理解得非常到位，在一个分镜之内能够自主地帮你规划运镜，这些内容都很好的被模型内化掉了。

但我觉得这并不意味着人价值的消失，人的角色会转型，可能会更多地转向定义创作的目标：我做这个剧、我做这个广告，到底要达成什么样的目的？然后选内容的表达策略。以及审美标准是什么，因为 AIGC 生产的内容，最终消费者大概率还是人。所以人能建立一个很好的审美标准，去理解我要传递的受众更喜欢什么，以及内容边界的一些设定，以及最终人对这个生成结果的负责。

邹娟：人的创作判断向上游移动，但不是只出现在开头和结尾，说我定义一下目标、最后验收一下结果就行了。而是需要深入地、始终保留在各个环节，保留进入细节、局部修改和重新决定方向的权利。从我们工程系统的角度来讲，真正的人机协同，不是只允许人审批、只review，而是让人的判断、人的创意和人的想法能够准确地作用在作品上。

专业生产需要更强的模型，还是更可控的模型？

鲜嘉麒：对于专业内容生产来说，现阶段我们真正更需要的是“更强的模型”，还是“更可控的模型”？假设一个模型十次里能生成一次非常惊艳的结果，和一个模型十次里有八次能稳定满足要求，生产场景会怎么选？

郑重：我觉得它可能不是一个选择题，因为更可控本身就是评价一个模型是否更强的一个重要的维度。如果一个模型的输出效果不可控、比较随机，那说明模型的上下线的 gap 会比较大，就是它神鬼莫测，输出带着极大的不确定性。

这会带来很多生产实际的问题。第一，更多的抽卡。我稳定的模型可能是 2 抽 1 或者 3 抽 2，那不稳定的模型可能 10 抽 1、20 抽 1，而现在的模型或者工作流的成本都是按调用次数收费的，这一定会产生大量成本。第二，无法自动化、流程化，无法沉淀 SOP，因为每次即便同样的输入，出来的效果都很随机，流程就没办法自动化跑通，中间产出物的质量没法保证或者标准化。第三，不同阶段的内容质量参差不齐，没法整合到一起，形成一个完整的高质量内容。

一个模型十次抽卡里边有一次特别惊艳，九次都没法用，那它本质上还是手搓单模、做能力探索，并不适合做生产力。如果一个模型十次里边有八九次能稳定满足要求，它的上限和下限都相对明确，那它就更适合做生产，我可以通过工程手段、通过提示词的要求把它扬长避短。所以在真实的场景里边，可控一定比单次的效果更重要，它一定是评价一个模型能否用作生产力的一个非常重要的指标。

鲜嘉麒：当每一次模型调用本质上都带有一定随机性的时候，怎么把几十次概率性的生成，最终变成一次相对确定的成片交付？

邹娟：确定性的结果和确定性的交付不是一回事。我们并不要求每次生成的画面一样，但要求在约定的质量、时间跟预算范围内，能够交付满足要求的作品。这不是靠一个 prompt 保证的，以我们的实践经验来看，是靠分层来设计的。

第一层是生成之前，把约束明确下来，比如人物、场景、道具、风格、镜头的目标，形成经过确认的参考资产和结构化的约束，而不是让每一步重新猜一遍需求。

第二层，视频任务一般来讲是一个长程任务，需要拆成可以验收的阶段，先确定每个环节以及环节之间的依赖关系，越靠前、影响越大的问题，越应该早一点发现，避免最后整篇返工。

第三层是区分调用成功和内容 OK。文件生成了，只能说明 API 调通了，但我还要检查这个片子是不是符合生成的预期，包括人物一致性、商品可靠性，或者画面动作有没有穿帮。客观指标可以自动检测，但一些关键的语义和审美问题，可能需要大模型的多轮迭代去解决。

第四层是让失败可以局部恢复。一个镜头的失败不应该拖着整条链路重跑，应该在最小范围内重跑并保存已经确定的结果，同时支持局部重试替换，以及在有预算跟次数上限时的降级处理。

第五层，就是把一些不确定性变成数据积累的资产，记录每一次模型调用的版本、输入约束、参数、耗时、验收结果，做成可观测的系统，为下一次生成做更好的优化。

我们并不是要消灭这个概率性，而是给它设置边界，并且为不达标的结果准备处理路径。如果时间、质量、预算不能同时满足，也应该明确地升级给人来决策，而不是无限重试。

鲜嘉麒：如果一个 Agent 在创作早期理解错了人物设定，后面的 Agent 又不断引用这个错误，会不会出现一种“看起来越来越一致，但其实越来越错”的情况？

路香菊：如果我写一个角色，给一个定义，比如这是一个小气、或者是一个谨慎的性格，那模型肯定能记住这一点，它所有的情节都会安排得非常谨慎。但实际上一个好的剧本，每一个人都有他自己的人物弧光。如果他仅仅是小气、就这一个特质的话，那我们基本上叫做工具人，工具人多，这个戏就不好看。

所以这个一致就应该理解成符合这种人性、符合这种剧的主题、符合他这个戏剧功能的，这种才叫一致。简单地输入一个标签，或者给他一个指令，这不叫一致。在大模型这里，你告诉他一个机械的设定，大模型会特别遵循这个指令，但实际上不好看。而且这个一致，很多时候是一个剧本传递出来的一种气质。比如《低智商犯罪》，如果两个笨贼遇到一个特别精明的警察，这戏就没法拍了。《隐秘的角落》里边，朱朝阳必须碰到张东升，他才可以有那种博弈、有那种对抗、有那种让人揣摩的东西。所以这里面更多的是一组极致的人，每个人都要有自己的目标、自己的弧光，都要有一部分观众代入他、共情他。这个一致性在作品里边特别难。

越来越错的话，我觉得可能就是写飞了。你让大模型连续写个三五集的剧情，可能写得非常好，但整体的剧情交给它肯定会飞，单独的一段你能看明白，放到剧集里边就不知道在干嘛。所以整体的结构性，就是我们要防止它写飞。

从一段内容到最终交付，系统还缺什么？

鲜嘉麒：如果把模型能力先放到一边，从一个 Clip 到最终可交付的成片，中间最容易被低估的工程问题是什么？

邹娟：从 clip 到成片，prompt 优化、稳定性、效果和性能优化、质检等问题显而易见，但最容易被低估的，是让成片成为可持续修改的工程。生产中，成片只是输出结果，本身应由可编辑、可追溯的工程来代表：包含素材、clip 编排、音视频图文叠加、剪辑点、音轨、配音、字幕及素材关系。它不只是视频展示界面，而是对最终作品的明确描述——什么素材何时出现、持续多久、如何搭配。例如 1.5 分钟短剧一集约 30 个镜头，一句台词从 3 秒改成 5 秒，可能影响前后 clip、口型、镜头长度、字幕时间甚至 BGM 节奏；系统若不知依赖关系，就会改一处、坏多处。

因此，从 clip 到成片最易被低估的工程问题，是完整工程的回溯：资产与版本管理、时间线与依赖管理、修改后的更新范围、预览与最终渲染一致、增量更新与局部重生成、只处理受影响部分，以及交付规格和质量检查。拼接只是第一步，能反复修改且不失控，才是规模化生产平台的目标。

鲜嘉麒：为什么长内容生产不能只靠“更大的 Context Window”解决？当内容越来越长以后，系统到底需要哪些新的能力？

路香菊：现在 AI 这个时代，把很多以前传统的工作流、任务，越来越快地变成了一个闭环。影视制作上，一开始我们只能参与一些镜头的分析或者拆解，但现在做技术的、做导演的、做编剧的，很多新的人群会组织在一起。我们经常说的一句话可能是人成为瓶颈，但其实我不这么认为，人不会成为瓶颈。

我觉得这个系统需要有一个快速对齐的能力。比如我编剧，上剧本的时候，要给出品人、高层的决策团队快速对齐我这个作品，要给编剧老师去探讨需要改的这些问题是什么。但是如果大家改了一个版本、另外一个版本、很多版本，我怎么能快速对齐这些东西？所以除了更大的 context window 之外，AI 还要做很多高层次的帮人去对齐的能力。

因为我本身是做剧本的，公司里各个平台的一些剧本可能都会涉及到给我探讨，我可以用 3 分钟快速给他们对齐一个剧本，问题是什么、情况是什么，用一张图可能就表达出来。长剧本也是这样，如果怀疑哪个人物线有问题，我们会把这个人物线单独拉出来快速对齐。所以当 context window 越来越长的时候，这种分维度的表达、整体结构的表达，或者不同尺度信息的对齐，就显得非常重要。

再比如两个版本有差异，差异到底是什么？剧本前期工作室经常有一个问题：你的主角判断得不对。我们写的男二应该是男一，那就会从他的主要功能、戏份去探讨。

鲜嘉麒：多 Agent 到底是在解决复杂问题，还是也在制造新的复杂度？

郑重：Agent 确实解决的问题越来越复杂了，但它也会带来新的更复杂的问题。多 Agent 或者 multi-agent 其实是一种手段，并不是一个目的。要用 multi-agent 这种架构解决问题，一定要满足两个前提：第一，它能明显提升效果，多 Agent 的组合比单 Agent 或者只用模型本身效果有提升；第二，它能带来明确的协作分工，流程清晰，中间过程可控。

如果我们直接把多个 Agent 堆叠到一起，大家最开始做实验的时候应该也经历了很多这样的过程，那就会带来很多问题：任务边界不清晰，多个 Agent 之间互相调用，一旦出问题，你很难追踪到到底是哪里的问题。一个小小的错误会被层层放大，最终引起一个大问题，出了问题也不知道该由谁负责。但随着大家不断试错，也出现了很多高价值的应用场景，比如把一个完整的流程拆成需求理解、创意设计、素材检索、模型生成、质量检查，每个分类对应一个清晰的、独立的 Agent，组成的 multi-agent 已经能比较高效地协作。

邹娟：多 Agent 能明确分工，但会引入上下文传递、重复调用、状态同步、意见冲突和错误放大等新成本。它类似拆微服务：不是越细越先进，而要看边界是否合理、接口是否明确、体系能否隔离。是否拆分可看三点，是否真需要不同专业职责、工具和上下文；是否有独立输入输出及清晰的验收、质检标准；拆分收益是否超过通信延迟和调试成本。若只是固定先后步骤，一个 Workflow 比多个 Agent 对话更清晰。

还要注意，多 Agent 相互认同不等于结果对，共同错误预设只会把错误加工得更一致。素材、成片、媒资和生产项目状态，需有统一、版本化的权威来源，不能只靠聊天传递。Agent 数量不是能力指标，协作收益必须覆盖协作成本。实操应先按可控架构捋清失败点，再增加 Agent，而非一上来就铺大。

路香菊：我们在工程系统里边，每引入一个新的 Agent 都非常谨慎，它最终的决策路径要非常清晰：这个边界到底谁说了算，还是需要某些人去拍板？某些 Agent 的能力到底怎么样？实际系统当中，一个 Agent 要有个非常明确的边界。你很难避免用多 Agent 去解决实际问题，但在使用过程当中，它怎么去协调？怎么去决策？目标怎么定义？特别是上下文一旦被污染，怎么拉回？其实还是非常复杂。所以我们每引入一个新的 Agent，可能都会经过详细的讨论、反复的实验，在系统当中有时会很灾难。

AIGC 规模化以后，最终拼什么？

鲜嘉麒：从 Demo 到规模化生产，AIGC 最容易被低估的成本和难点是什么？

郑重：最容易算的是 token 或模型调用费用；最容易被低估的，是围绕模型能力搭建整个生产系统的综合成本，包括工程、调用、素材与合规 IP、质检、重试迭代，以及内外部沟通协作成本。基模不断迭代，提示词调性、美学、内化能力都在变，工程适配、质检、工作习惯和人员能力也随之变化。做 Demo 很快，手搓加多买 token 即可；但搭生产环节极痛苦：要让好效果稳定、批量输出并带来商业价值，还要保证进阶一致性、支持灵活精准修改，并建立能匹配模型调性的质量标准。归根结底，模型成本、工程成本、迭代成本，三块都是巨大支出。

邹娟：真实成本不是单次生成价格，而是每条合格成品交付的成本：生成、重试、审核、人工编辑、质检、存储、渲染、运营协同等成本之和，除以可用合格成片数，远高于“一次模型调用 5 秒多少钱”，所以大家经常会有“越便宜的模型越贵”的感觉。除了平均成本，还要看交付时长和长尾：客户时效不同，有的隔夜完成即可、有的 10 分钟内完成才行，不同时效性要求的流程编排甚至都不同；有的任务快，有的因反复返工拖过交付期。规模化后，长尾会影响研发、机器资源和用户体验。工程侧重点看首次验收通过率、平均修改次数、单条人工介入时长、规模化下按期交付比例。容易被低估的是：规模化商用后，不只需要推理成本，更要让失败尽早暴露、修改局部发生、人工介入更准确有效。

路香菊：在剧本这里边，AI 可能就是很短的时间内，就可以出一个 80 分的剧本，但是从 80 分到 90 分，就是要我们搭建专业的一些知识，包括人物、故事结构、主题、赛道。但是实际项目，特别是爱奇艺这些项目，观众或者说我们公司的一个调性，要求你这个作品可能至少 95 分以上。实际上过了 90 分，这里边就非常复杂了，利用 AI 去改的复杂度就非常高了。所以这里边容易被低估的一个成本，就是组织协同成本，协同的复杂度会很高很高。为了最后的那一点点，你就能做出来比前面第一步要复杂太多的一个工作，这里边还有包括给专业编剧的协调沟通，看似提高一点点，但其实背后的工作却要复杂很多。可能前面的很多工作与流程都要推到重来。

鲜嘉麒：未来 2-3 年，AIGC 专业内容生产真正的核心壁垒会是什么？

路香菊：Agent、Workflow 和业务闭环都重要且不矛盾：Agent 加专业 Workflow，目标就是跑通业务闭环。剧本要达 95 分，离不开专业工作室/编剧室的沉淀和 Workflow，但不是传统 Workflow，而是作为节点在 Harness 结构中灵活调用，以约束作品专业性；创作必须遵循改编思路、大纲、分集大纲、剧本、润色等流程，否则成本不可控、问题会发散。业务闭环则希望从创意直达剧本，甚至剧本到成片、预演，技术上也可实现。最终目标，就是跑通业务闭环。

邹娟：能够持续积累专业反馈的生产与业务闭环。因为模型能力会持续迭代，但单独依靠某个模型，它很难形成长期的壁垒。所谓的壁垒，就是能够把专业的数据、专业的 know-how、Agent Loop、Workflow 等和生产平台结合起来，持续地交付业务结果。比如什么叫一个合格的短剧的镜头，什么叫符合品牌要求的营销素材，这些专业判断需要被沉淀下来，沉淀成流程，沉淀成知识库，沉淀成约束，甚至沉淀成评估的标准。然后在生产的过程中，产生的数据和人的反馈又能够回流，帮助系统下一次做得更好。

从我自己的工作经历来看，长久的竞争力一般不是某个单点强，而是系统能不能在外部环境不断变化的情况下，仍然稳定地接入，控制质量，管理成本，快速迭代，并且最终对业务效果负责。未来真正的壁垒，就是把这一套技术能力持续转化成可交付、可以复用、可以商用、可以增长的生产力。

郑重：“最终能跑通的业务闭环，且能够合理的自我进化”。自我进化也很重要，因为模型会不断地出现、不断地提升，数据的采集能力、标注能力、处理的管线，以及上下游各个环节的能力都在不断提升。那这些能力的提升能不能很好地被整合起来，最终服务我的业务？且我的业务侧能不能对模型有合理的预期，真正去解决效果或者效率问题？

我们处在一个 AI 能力飞速发展的过程中，整个体系要能够适配模型、数据、行业经验，甚至 Agent 协作方式、交互方式的不断迭代，通过构建自我学习的闭环，使整个系统能够不断地去服务于业务的真实生产环节。所以总结来说就是首先能跑通，第二个就是能随着 AI 技术和业务的发展，不断地自我进化。

会议推荐

Pallas 内核怎么调优？Google 给出的答案是“少信模型，多看寄存器”

作者：Claudio Masolo — Sat, 10 Oct 2026 06:22:04 GMT

Google 为 XProf" 添加了"一个内核性能分析套件。XProf 是其面向 TPU" 工作负载的开源性能分析器。现在，开发者可以查看自定义 Pallas 内核"中的周期级细节。此前，这些内核在跟踪记录中显示为单个不透明块。在 TPU v7（Ironwood）"上，XProf 会在运行时对硬件性能计数器进行采样。在一个分块矩阵乘法示例中，Google 发现了内存停顿问题。通过添加三重缓冲，他们将内核执行时间从 125.5µs 缩短至 88µs，降幅约为 30%。

据 Google AI Infra 团队的 Yogesh SY 介绍，这一差距源于性能分析器处理自定义编译路径的方式。使用 Pallas、Mosaic 或 Triton 创建的内核会跳过标准 XLA Pass。这可能使编译期静态成本模型产生偏差。因此，“optimal FLOPs”和有效吞吐效率等指标可能不准确，甚至完全无法工作。静态工具可能会将一个 MXU 指令块标记为已充分利用，但该单元实际上正在空闲等待 HBM，因为静态分析忽略了时间因素。

该套件分三个层级工作。开发者可以传入以下标志进行编译器检查：--xla_enable_custom_call_region_trace=true 和 --xla_xprof_register_llo_debug_info=true。之后，Graph Viewer 会显示一个“Custom Call Text”面板，其中展示每个自定义调用降低后的 MLIR。

这让工程师能够检查操作是否按预期融合，以及内存分块的结构是否符合设计。Trace Viewer 会显示用于静态执行分析的低级操作（LLO）包数据。这些数据包括每个时钟周期执行的机器指令。它为 MXU、标量与向量 ALU、向量填充、加载、溢出、存储以及跨通道单元（XLU）提供时间对齐的轨道。对于运行时遥测，XProf 会定期对硬件计数器进行采样，其分辨率下限为 1µs，这一限制来自主机级定时器。

一种新的外部事件触发模式取消了这一限制。采样器会捕获 TPU 跟踪指令和边界触发器，包括自定义调用作用域的进入和退出。这可以实现亚微秒级捕获，并提高归因准确性。开发者可以在最多四个 SparseCore 上，为每个核心配置最多 28 个计数器，形成一个 4×28 矩阵。采集通过 jax.profiler.ProfileOptions 启用，使用 tpu_enable_periodic_counter_sampling 和 tpu_tc_perf_counter_sampling_options，并设置 is_external_trigger:true。对于周期采样模式，则使用 interval_us 取代触发器标志。

在矩阵乘法案例研究中，一个受内存限制的变体在 sync_wait 计数器中出现了大量峰值。通过三重缓冲让 HBM 加载与 MXU 计算重叠，减少了这些事件，并将执行时间从 125.5µs 缩短至 88µs。该数据来自 Google 编写的单个演示内核，而非广泛的基准测试，因此它展示的是分析流程，而不是其他场景中可以预期的性能收益。

该文章还提出了指标的“信任层级”。直接从硬件寄存器读取的值，例如 HBM 利用率和 TPO 指标，可视为自定义内核的事实依据，而 XLA 成本模型的估算结果则需要谨慎对待。新的 Perf Counters View 以表格形式列出了超过 16000 个原始计数器。跟踪轨道的高度反映某个时间区间内原始计数器的最大值，而不是经过归一化的百分比。例如，在主频约为 2.0 GHz 的核心上，500ns 时间窗口内增加 100 个周期，相当于该单元的利用率为 10%。

XProf 是 OpenXLA 项目的一部分，并与 JAX 性能分析集成。该文章没有说明内核性能分析套件的发布状态或版本。

计数器采样功能的文档面向 TPU v7（Ironwood），因此使用早期 TPU 世代的团队不应假定它们具有相同的覆盖范围。任何需要调优 Pallas 内核的开发者，都可以从 XProf 仓库中的 Pallas Matmul with Perf Counters Notebook 和 OpenXLA 内核性能分析说明入手。有限的 4×28 计数器预算要求团队针对每次调查选择相应的计数器。该设置旨在保障工作负载性能。工程师也不应再将 XLA 得出的效率数据视为自定义内核的可靠指标，而应改用寄存器级计数器作为优化依据。

原文链接：https://www.infoq.com/news/2026/09/google-tpu-xprof/"

从 Coding 到 Running：AI Native SRE Agent 的工程实践

作者:姚斌斌，腾讯云 CloudQ 技术负责人 — Sat, 10 Oct 2026 06:13:49 GMT

一个软件的生命周期里，90% 以上的时间都处在运行状态。可当 AI 把 Coding 世界卷得人人提效两三倍的时候，Running 世界却进展缓慢。代码越写越快，早已不是问题；怎么让它跑得更稳，依然要靠大量人力去堆。

本文整理自腾讯云 CloudQ 技术负责人姚斌斌在 AICon 全球人工智能开发与应用大会 2026（深圳站）的分享《从 Coding 到 Running：AI Native SRE Agent 的工程实践》。他详细分享了如何用全景图谱加 Agent，让软件的运行世界第一次变得可理解、可操作、可验证，从建图到 Harness 再到评测，最后落到一个个运行治理的实战案例。以下内容根据演讲实录整理。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

从 Coding 到 Running 的挑战

先从一个反差说起。这两年 AI Coding 的发展有目共睹。工具上，从最早的编译器插件，到 Cursor 这样的 AI IDE，再到 Claude Code 这样的 coding agent，现在已经走到多 Agent 并行协作、端到端交付的 agent system。范式上，从早期复制粘贴和代码补全，到一句话生成 demo 的 vibe coding，再到生产级的 spec coding。去年还在讲 harness engineering，今年就变成 loop engineering，马上又有人说 loop 已死，进入 graph engineering。连推特的大神 Karpathy 都说，很多知识还没来得及学就已经过时了。

玩笑归玩笑，这背后是一个很实际的结论：个人的编码效率已经快速提升，越来越不是整个软件研发过程的主要瓶颈。我们业内线下交流时，大家普遍觉得个人编码速率已经提升了大概 2 到 3 倍。但交付效率还涉及到大家公司的组织架构及研发流程等因素，暂且不展开。

但我想说的是另一面。一个软件整个生命周期里，90% 以上的时间都处在运行状态。代码越写越快已经越来越不是问题，怎么让它跑得更稳，依然要靠大量人力投入。为什么突然告警了？为什么发布会出问题？为什么重启只能短暂恢复？根因是什么？为什么换个环境就不一样？这些问题，AI 还远远没解决。

这里对比一下 Coding World 和 Running World。CodingWorld 的环境相对确定可控，写代码可以测试、可以稳定复现，难点主要在架构设计和代码实现。但 RunningWorld 不一样，它时刻面临各种不确定性：环境、基础设施、依赖项，随时随地可能发生的故障。哪边的光缆又被挖断了，哪个机房又着火了，这些都比写代码难预测得多。所以 Running 的场景更难被完全自动化，AI 在这方面的进展也明显偏慢。

那为什么传统的 SRE 很难做好这件事？相信大家都有这种感受。我们要对接越来越多的可观测平台，做很多自动化流程，编写很多处理工具，还有 SOP、runbook 等等。这些东西本来是想把人从重复劳动里解放出来，可实际做下来，做得越多，效果反倒收效甚微。为什么？因为真正的瓶颈点不在工具多少，而在人怎么去理解、人怎么做决策。工具可以把数据摆到你面前，但看懂数据、做出判断，还得靠人。所以传统 SRE 的困局，就是缺少真正具备泛化级别的智能。

不过现在条件开始具备了。因为前面提到的各种传统 SRE 的底座数据，都已经非常成熟了。叠加这几年 AI 的发展，我们看到各种前沿模型，不管国内国外的，都已经达到了生产级可用，越过了这条基线。再加上现在各种工具调用能力的积累，以及Harness工程的成熟落地，我们整个运行世界第一次变得可以理解、可以操作、可以验证。于是我们就可以开发出真正自动化、智能化的 SRE Agent。

Running World 的建模与理解

我先给出 RunningWorld 治理架构的一个整体概览。

先看左边的数据层，主要分三个部分：infra、可观测、knowledge。中间是我们的认知层，是一个思考引擎，基于本体和语义层，构建出 RunningWorld 的全景图谱。下面是 Agent 的思考决策循环链路。右侧是基于 Agent 的能力构建出来的场景化能力，像架构可视化、根因分析、变更风控等等。底下又是一个基于评测的工程闭环。

这三类的分工很明确：infra 描述的是这个世界长什么样，也就是系统的静态结构；可观测描述的是世界正在发生什么，也就是系统当下的运行状态；knowledge 描述的是我们以前是怎么去解决这些问题的，也就是沉淀下来的经验。三者合在一起，才能拼出一个完整的运行世界。

先看 infra，这块的数据都是大家经常打交道的，计算、网络、存储、数据库、云资源等等。它们的特点是低频变更，彼此之间基本上都有关联关系。可观测大家也很熟，就是 OpenTelemetry 三件套 metric、log、trace，再加上一些变更事件和告警。这些数据的特点是高频变更，失效期很短，可能是秒级或者分钟级的更新。再看 knowledge，就是大家平时积累的各种经验文档、架构文档、历史故障、还有一些工单等等。这些数据的特点是相对非结构化，信息密度比较高。在没有 AI 之前，理解这些知识库都是靠人去做的，所以它的作用发挥相对比较弱。但有了 AI 的能力之后，它就有了一个指数级的增长。

但这三块数据本身，可能是一个一个的孤岛，是隔离的。那我们怎么通过一些规则机制，把这些数据建立起联系来，变成一条一条可解释的因果链，这是一个非常重要的问题。

这就到了我们的认知层，让 Agent 去建立对软件运行世界的理解。认知层的第一层是本体，也就是 ontology。简单介绍一下：本体其实就是前面提到的各种实体对象，以及它们的属性、相互之间的关系，还有它们运行的一些硬性规则及约束。第二层是语义层。语义层要做的，就是把这些实体对齐，进行关系抽取，把有歧义的部分消解掉。基于前面两层的基础，我们就可以构建出一个运行世界的全景图谱。这个图谱带有非常强的复杂图查询能力，以及基于这个图查询能力带来的逻辑推理能力。

我举一个例子，讲清楚构建图谱前后的差别。左边是四条分散的原始数据。第一条是 service A 的一条告警，说它 P99 延迟升高了，那这个 service A 到底是一个什么服务？它的 owner 是谁？不知道。第二条是一条日志，说连接某个 IP 的 43 端口有 timeout，这个 IP 又是做什么的？它的上下游关系是什么？不知道。第三条是一个网络策略的变更单，这个变更单它改变了什么？对上下游的影响是什么？也不知道。第四条是 CMDB 里的一条数据，描述 payment 这个支付服务，它跟前面的 service A 又有什么关系？同样不知道。

这四条数据单独看，都是一堆信息碎片。但在图谱里梳理呈现之后，效果就变得非常清晰了：这个 order service 是一个订单服务，它的别名就是 service A，owner 是张三，它有三个 pod，都在广州地域。它依赖了 payment 这个支付服务，并且近期做了一个网络变更，这个变更内容可以拿到，时序上是吻合的，变更的地域也都吻合。再叠加上历史上这类网络故障变更的处理经验，Agent 就可以推理出整个发生的因果链：广州地域的一个网络策略变更，导致了支付服务的访问出现问题，进一步又导致上面的订单服务，因为依赖支付服务，所以整体延时变得更高了。

建图只是一个开始，怎么保证它不腐烂、持续可用，才是关键。构建图谱的核心步骤主要有四步：第一是多元的数据采集，这块其实还跟大数据处理等技术相关，我们一般会做增量同步，全量兜底；第二是做实体归一，实体归一可能会遇到各种冲突等等问题，需要去介入解决；第三是构建属性和关系，我们要采用高可信源的数据；最后是做质量校验，以及图数据的分层存储。

构建出来之后，怎么保证它不腐烂呢？这里我列了六大问题，在实际经验当中，这些才是更加难以解决的。这些比较细节，我这里就不展开了，给大家大概展示一下可能会遇到的这些概念。

进入场景实践，图谱建出来之后，我们实际的应用是什么？首先是架构可视化，刚才前面蚂蚁的老师也讲到了，有些是基于代码把架构画出来。在架构可视化领域，有一个更有指导意义的模型叫 C4 模型。它是从上往下的，最上面是 context 层，一般我们叫系统层。拿电商网站举例，它就是用户系统、支付系统、物流系统等等这个级别的架构交互。第二层是 Container 层，是单个系统下面的一些微服务等等可部署单元的交互，比如订单服务、库存服务、数据库，都是可以部署的粒度。第三层是 Component 层，更细分到一个服务里面的一些逻辑模块，比如创建一个订单、做价格计算、做库存校验等等这个层级。最底层是 code 层，这个大家很熟，就是类、实例、函数等等这些层面。

基于这个模型的指导，我们把前面说的全景图谱构建出来之后，底下其实是一张非常大的底图。这张图里，把所有不同层次的实例全部关联起来，它们的上下游关系、调用、规则等等，都在这张底图里。Agent 就可以基于这张大的底图，随时根据用户的需求，去绘制出右边的分级架构图，有系统级的、服务级的，还有代码级的。

所以这里有个关键的认识：这个图谱其实不是给人看的，它是给 Agent 看的。Agent 经过图谱画出来的，才是给人看的。

这是我们腾讯云 CloudQ 基于刚才的理念做出来的架构可视化效果。最左边是一些经典的 3D 架构图，这种图的特点就是很「好看」，大家一般用在公司大屏，或者给领导汇报。第二个比较实用，一般在排障过程中用，你通过对话可以实时圈定一些范围，画出基于 Mermaid 图的一些呈现。第三个就是刚才讲到的，从系统层下钻到应用层、再下钻到代码层的分层下钻效果。

再讲第二个实践案例，就是我们 CloudQ 基于全景图谱的影响面分析，左右两边对比的是 Agent 接入图谱前后的效果。

接入图谱之前，比如我们想让它分析一下，CLB 如果挂掉之后会有哪些影响。Agent 可能能拿到 CLB 本身的监控、配置等等数据，它也可能基于时间去拿一些对应的告警数据。但它这些始终都是一些相关性上的猜测。大家都知道，模型可能一本正经胡说八道，输出一些看起来挺有道理、其实经不起推敲的结论。

但有了全景图谱之后，我们的 Agent 收到这个问题，就可以基于图谱节点层次的各种下钻关系，拿到各种一跳、两跳的上下游数据，包括告警、变更等等。所有这些都是基于因果链、有因果关系的数据，而不是简单的相关性。并且图谱查询大家熟悉都知道，做这种多跳关联的查询，比关系型数据库效率会高非常多。所以这里展示的是，有了图谱画出因果关系之后，影响面分析的效果会好很多，而且它是非常可信的。

SRE Agent 的生产化工程

这是我们做 Harness 的一个概览图。最上层是入口层，这里我们首先支持各种 IM 工具的接入，比如主流的企微、飞书、钉钉等等，也支持网页对话框的输入。整个 Agent 又可以作为一个 skill，让最近很火的 Workbuddy 或者 OpenClaw 这类智能体来调用，也就是说它本身又可以被嵌入到别的系统里。

左边是我们内置的一些专业能力，各种工具集，还有各种场景化的子 Agent，比如巡检的、护航的、演练的等等，是一种多 Agent 的架构。还有各种知识库，是一些内部梳理出来的专家经验。当然这些也支持用户自定义上传，上传他自己觉得很好用的 skill、MCP、知识库等等。中间就是我们整个 SuperAgent 的编排中枢，这里主要去做 Agent 都比较通用的理解、规划、执行、上下文、安全控制等等。

再往下，有一个多云适配层。相信大家公司里一般也不会只用一个云，都是多云的架构。那这里就不只支持腾讯云，也支持像 AWS 、阿里云、华为云等国内外主流的云厂商。最下面就是模型服务、数据分析、沙箱以及 Agent 运行依赖的一些外部服务。

再讲一下 Agent 运行当中三条非常重要的机制。

第一条是编排边界。Agent 或者说大模型，非常容易被 prompt 绕过。所以我们很多执行边界上的问题，要在模型的范围之外，最好基于规则去实现。我们的图引擎，就把 ReAct 的机制限制在了固定的几个节点当中，其他都是不允许它去发挥的。

第二条是记忆机制。历史对话的摘要、工具返回的大量结果的压缩、近期轮次的保鲜等等。这些经过上半年OpenClaw小龙虾的爆火之后，现在业界都有很多非常成熟的方案。

第三条是环境与沙箱的治理。沙箱的使用方式一般有两种。一种是你把整个 Agent 跑在沙箱里面；第二种是你把沙箱只是当作一个工具去调用，把一些特殊的执行环节放到沙箱里。云端 Agent 一般基于第二种，就是把用户上传的、可能会存在风险的 skill，它的执行放到沙箱里去做，只给它注入一些特定需要的环境变量，还有它的一些脚本环境等等。最重要的一点，就是要跟内网去做隔离。执行完之后，要把整个沙箱销毁。

评测也是非常重要的一环。我们做的评测机制，是实时加离线相结合的方式。对于实时评测，用户的各种问答，经过信息脱敏之后，就进入多模型的评审器，对结果和轨迹去做交叉的、基于五个维度的评分。这里就会发现，有的是结果不符合预期，有的是运行轨迹、调用工具等不符合预期，有些甚至是无响应，直接跑崩了。还有一些比较隐晦的，我们还得去分析用户的下一条对话记录。它可能是一句骂人的话，属于差评类的 badcase。基于实时评测发现的这些 case，又要沉淀到我们的一些离线回归的评测集当中，这个评测集本身也包含各种主要功能路径上的 case。

离线回归是早八晚八一天跑两次，并且如果相关的 Agent 有变更发布，也会触发流水线跑一次。如果说有一些 case 没过，那我们就要阻塞这个发布过程，人为地去介入优化。所以其实这个实时加离线的这套评测机制，做得越自动化，大家就越能感受到，它其实就是一个自进化的雏形。我们先通过评测发现问题，再去做分析优化，然后再验证它的优化效果，最后变成一个新的能力的沉淀。现在业界大部分的 skill 的自进化，也大体都是这个思路。

定时任务这个场景也很有趣，如果早期我们去实现一个定时任务，最简单的方式，就是把它当作一个普通的任务，每次定时调起，就把用户的问题从头到尾执行一遍。但是这会引入三个问题。第一，无差别的推理，成本很高。现在如果用的是稍微好一点的模型，DeepSeek、Kimi 这些都涨价了，那可能跑一遍就要十几块钱或者几十块钱。第二，效率低。你每次都得靠模型重新理解规划，来回地调用，可能单次模型的一来一回就要十几秒，那整个任务可能就要几分钟、几十分钟。第三，确定性的问题。因为模型每次都是基于概率的发挥，它并不一定每次都能跑成功。

我们去分析了一些任务。这里有一个典型的例子：用户说，每天帮我去清理一些没有用的日志。这个场景在传统年代，有经验的同学一下就知道，我应该写一个脚本，到服务器的日志目录里面去找，因为一般日志都是按时间或者按大小做切割的，一下就可以把它清理掉。但如果是一些新手，纯粹把这个需求发给模型，模型就要重新去理解，每次都要先说去找哪些目录，目录找到了，再去找哪些日志等等。这个完全可以脚本化，不用每次都靠模型的能力去实现。

第二个场景也很典型：帮我做一下容量分析，或者大家很感兴趣的，上午股票大盘的分析。这种任务的特点就是分两个阶段，第一阶段是拉各种数据，把它拉回来，再由模型去做总结。这种类型的任务就可以把前半部分脚本化，后半部分交给模型执行。

所以我们就把定时任务这个场景，升级成了一个执行计划引擎。它会去识别这个任务，适合把哪些环节做脚本化，哪些去做模型的泛化能力总结。如果执行失败了，就把失败的这个步骤交给模型；如果整个任务都失败了，就把它当作一个普通的任务，让模型整体去重试一遍，这是一个双重兜底机制，用户是完全无感知的。这样就解决了前面提到的成本高、耗时久、不确定性的问题。

SRE Agent 在运行治理中的实践

先整体看一下 SRE Agent 场景化闭环的概览。治理问题我们总结一下，其实就是三大类：系统现在怎么样？异常为什么会发生？下一步应该怎么做？SRE Agent 的各种原子化能力，包括目标理解、关系探索、取证推理、策略生成等等。基于这些原子能力的组合拼装，我们就可以做很多场景化的治理，包括前面已经提到的架构可视化、根因分析、变更风控、FinOps 等等。

先看根因分析这个例子，我们从一条告警下钻到一行代码，又从 Running World 回到了 Coding World。首先是工程师收到了一个帖子服务不可用的告警，Agent 去理解整条告警的语义，确定它不是单节点就能分析出来的，需要做一次架构级的诊断。所以第一步，就是绘制出整个链路上相关的、从前到后的调用链路，就呈现在左边，比较简单，从入口到一个后台，再到一个数据库。

第二步，它先去分析告警的这台 CVM 服务器，内存比较高。但内存高一般都不会是根因，都是一些表象。所以 Agent 就根据调用链路，先去查这台 CVM 的上游，看接入流量有没有突发变高，因为这样也会导致它崩掉。查出来之后发现，上游的流量是正常的，所以它就继续往下找原因。它找到了服务的日志，在日志里面发现了大量 MySQL 连接过多的报错。连接过多，一般就是一些代码实现层面的问题了，所以它就继续往下探索。发现确实有一些堆栈报错，是有一行代码没有做释放，导致了连接池的泄漏。整个根因就串起来了，就是一个代码实现上的问题，最终导致了告警的产生。

它也会给出处理建议。首先是做临时恢复，应该先把服务拉起来，所以建议工程师先把这些无用的连接清理掉，加大一下最大连接数的配置。并且给出长期修复方案，代码应该怎么修。

第二个场景是变更风控，做开发运维的肯定少不了这个场景。我们一般基于事前、事中、事后三个步骤。事前，基于刚才已有的图谱数据，根据变更的节点，算出它一跳、两跳的整个业务影响链路。事中，Agent 自动拉取一些历史上它觉得比较重要的指标，建立一个基线，通过定时任务等方法，实时把这些监控数据拉回来跟基线对比。一旦发现异常情况，并且跟变更相关，就要阻断变更过程，让人为介入。事后，比如变更失败了，要有回滚预案等等机制去执行，最后输出一个变更的总结报告。

接下来是智能巡检。巡检的目的，主要是为了让一些还比较轻微的风险，在变成大故障之前能被发现和治理。有了 SRE Agent 之后，我们可以通过对话的方式，让它自己去确定风险诊断的范围。以前发现风险之后，可能是一些提前写好的处理建议；有了 Agent 能力之后，就可以针对性地告诉每一个客户，他的风险项应该怎么个性化处理，最后沉淀成经验。原来我们可能只能基于单点，说某台服务器或者单个数据库是不是存在风险；有了全景架构图之后，就可以判断出 AZ 级别的风险，这在应对大规模故障，比如机房断电这种规模级别的故障时非常有用，是一种架构级的治理。

容量和FinOps，这两个场景非常相似。容量管的是够不够，成本视角管的是到底贵不贵。这两个场景我们都分三步走：首先是「看见」，要有一个全局概念，知道现在哪些地方是高负载、哪些地方是低负载；第二步是「看懂」，也就是去动它，比如某个地方堆了 100 台服务器，是不是太贵了，能不能缩容 50 台，就要有 Agent 来帮你做一个详细的评估；最后是做行动，行动完之后帮你总结，这次缩容到底节省了多少成本，或者这次针对未来的一个大促，我们把容量扩到了什么样的水位。

混沌工程这一块大家应该也都挺熟悉。由 Agent 赋能之后，首先做拓扑发现，再建立一些稳态基线，再通过对话式的方式生成整个演练方案，原来手写一个还是挺累的。最后输出一个演练复盘报告。

最后一个问题是，到底敢不敢让 Agent 自己去动手？我们的经验是把它分为三个不同的阶段。

第一，对于只读类的场景，刚才说的做根因分析什么的，就大胆让 Agent 自己去做、去探索，我们只要做好审计留痕就好了。第二，建议类的场景。Agent 发现问题之后，有时会说，我可以帮你直接解决，只要你点一下授权动作就好了。这类就是要由 Agent 给出建议，人去做授权。第三类，是真正的自动化执行。就是把一些提前知道的低风险写操作，比如缩容、扩容这种操作，如果评估它是没有风险的，可以预授权给 Agent，它在遇到这些问题的时候就可以自动执行。

我们现在是三个阶段并存的状态。像 L3 这个级别，也是今年 Agent 或者说模型能力进一步提升之后，我们才开始逐步去尝试的。

最后总结一下，今天这个分享，就是一条可参照的 SRE Agent 建设路径。大家可以跟我们一样，先梳理好数据，建立起图谱，并做好更新维护。然后是 Harness 和评测，驾驭好Agent。最后是从只读开始，逐步去做有限的执行。

会议推荐

比 Astra 还贵！GPT-6.1 Sol 极速版上线，社区吐槽：“500 美元套餐都撑不过一天”

李冬梅 — Sat, 10 Oct 2026 05:15:26 GMT

OpenAI 又给智能体加了一档速度。

根据官方更新日志，10 月 8 日，OpenAI 在 Responses API 中为 GPT-6.1 Sol 增加了 Ultrafast 极速模式，向所有 API 用户开放，使用仍受速率限制约束。开发者无需更换模型名称，只需在调用 gpt-6.1-sol 时，将服务档位设为 ultrafast，即可使用这一模式。

此次更新主要针对生成速度。

GPT-6.1 Sol 模型本身已于 9 月 29 日发布，因此，“极速版上线”更准确的含义，是已有模型新增了更快的服务档位。OpenAI 将 Ultrafast 定位为其最快的 API 服务档位，面向对延迟敏感、愿意为速度支付更高费用的工作。

价格也随之提高：GPT-6.1 Sol 极速模式的 API Token 单价为标准模式的 6 倍。这让此次更新的关注点从“模型有多聪明”，进一步转向“少等一会儿，究竟值多少钱”。

官方称性能接近 Astra

OpenAI 对 GPT-6.1 Sol 的定位是，在复杂编程、计算机操作和专业工作中，以更低成本提供接近 GPT-6 Astra 的表现。

事实上，GPT-6.1 Sol 模型在一些基准测试上的表现的确有很多亮眼的地方。

GPT-6.1 Sol 与 GPT-6 Sol 相比，它在复杂专业任务中的表现显著提升，涵盖代码编写与调试、文档理解以及多步骤业务工作流的执行。在其中多项评估中，它以显著更低的成本取得了接近 GPT-6 Astra 的表现。

在编程方面，在DeepSWE v1.1 测试中，GPT-6.1 Sol 以约五分之一的成本达到与 GPT-6 Astra 相当的水平，同时以更低的推理强度和成本，比 GPT-6 Sol 的最高得分高出 6.4 个百分点。

在专业工作方面，GDP.pdf 在所测试的各档推理设置下，GPT-6.1 Sol 的得分均高于带回退机制的 Opus 5.5，而单任务成本不到其一半。它还以约五分之一的单任务成本，接近 GPT-6 Astra 的性能。

AutomationBench 衡量智能体能否正确完成多步骤业务工作流。在这项评估中，GPT-6.1 Sol 在中等推理强度下的得分比 Opus 5.5 高 2.2 个百分点，成本则约为其三分之一。这一得分也比相同设置下的 GPT-6 Sol 高出 4.8 个百分点。

在 x 上，Codex 负责人 Tibo 发文称：“我们改进了一些功能，使模型响应速度更快，从而能够更快地响应用户的调整，让您可以实时修正方向，避免模型浪费资源。同时，我们还发布了 GPT-6.1 Sol 极速版本。两者配合使用效果极佳。”

与此同时，官方仍将 Astra 定位为处理最困难任务的最高能力模型，并建议用户在自己的任务上对比两者，判断质量与成本之间的取舍。

从公开规格看，Sol 与 Astra 的上下文容量、最大输出长度相同，标准模式的输入和输出单价则有明显差距：

资料来源：OpenAI 官方模型对比页。

按相同 Token 数量计算，Sol 的标准输入和输出费用均比 Astra 低 80%。但这一比例不能直接换算成“完成同一项任务便宜 80%”：模型实际生成多少推理和输出 Token、是否需要重试，以及调用多少工具，都会影响最终账单。

此次 Ultrafast 更新也需要区分两类“性能”：一类是完成任务的质量，另一类是完成任务的速度。

价格怎么算？

GPT-6.1 Sol 的标准模式、Fast 快速模式和 Ultrafast 极速模式，分别按不同单价收费。对于输入不超过 27.2 万 Token 的请求，API 价格如下：

资料来源：OpenAI 官方 API 定价页。

这意味着，极速模式的单价是标准模式的 6 倍，也是快速模式的 3 倍。需要强调的是，6 倍价格并不意味着 6 倍速度，两者不能直接对应。

用一个简化账单举例：假设某项请求消耗 10 万个未缓存输入 Token、1 万个计费输出 Token，不计工具等其他费用，那么标准模式费用约为 0.30 美元，快速模式约为 0.60 美元，极速模式约为 1.80 美元。这是按官方单价进行的计算示例，并非实际任务测试。

长上下文还会进一步提高价格。当输入超过 27.2 万 Token 时，GPT-6.1 Sol 极速模式的输入价格升至每百万 Token 24 美元，输出价格升至 90 美元。官方规定，长上下文倍率作用于整个请求，而非仅对超出阈值的部分加价。

另一个容易忽略的比较是：Sol 极速模式每百万 Token 的输入、输出价格分别为 12 美元、60 美元，已经高于 Astra 标准模式的 10 美元、50 美元。按同量 Token 计算，前者高出 20%。因此，Sol“成本较低”的优势需要结合服务档位判断；选择极速后，用户购买的价值更多来自等待时间的减少。

API 端，GPT-6.1 Sol 的 Ultrafast 模式向所有 API 用户开放，并设有独立于标准和快速模式的速率限制。它支持全球处理，以及美国和欧盟数据驻留。

ChatGPT 产品端的开放范围则更窄。根据官方文档，GPT-6.1 Sol 在 Work 和 Codex 中提供，普通 Chat 模式不提供这一模型。Sol 模型的首发范围覆盖 Plus、Pro、Business、Enterprise 和 Edu，但极速模式仅向 Pro 500 美元档及符合条件的 Enterprise、Edu 方案开放，实际可用性还取决于客户端、工作区设置与 rollout 进度。

订阅额度的消耗也不能照搬 API 的价格倍率。官方定价说明显示，GPT-6.1 Sol 极速模式消耗套餐内含使用额度的速度为标准模式的 8 倍；购买的额外 credits 和企业按量付费使用，则采用 6 倍倍率。

用户：我们要额度，你给速度

围绕 GPT-6.1 Sol 极速模式，用户在 x、Reddit 等平台上展开了激烈的讨论。讨论主要集中在两个问题上：提速能否让智能体真正好用，以及用户是否应该为此承担明显更高的费用。

支持者认为，速度对智能体的意义，已经超出了“回答问题更快”。

在x 上，ID 名为 HellFlow Studios 的用户表示，当 AI 开始实际执行任务时，更快的推理与较强的能力结合，能够提高自动化的实用性，尤其是在编程、智能体和实时工作流中。

Brian Gastón 和 Shrilaxmi 则将关注点放在智能体反复执行的工作循环上：多轮推理与工具调用中的延迟会不断累积，速度决定了这类产品能否成为日常工具。

不过，Brian 也提出，极速模式在长时间、连续调用工具的任务中，究竟能否保持表现，仍值得观察。

还有用户表示，大家需要的是更长的使用时间，而不是更快的型号。如果总是用不完，那超快的速度还有什么意义呢？？？

Clarity Today 则提醒，API 与 Codex、Work 的计费口径不同，不能直接照搬预算；提速是否划算，还要看用户等待的时间主要消耗在模型生成上，还是外部工具执行上。

极速模式的开放门槛和额度消耗，也引发了部分付费用户的不满。

在 x 上，用户 DoubleStraddle 将矛头指向套餐分层，讽刺此次发布让每月支付 200 美元的用户感到被冷落，仿佛只有 500 美元档用户才能获得新功能。

Wei佳则表示，能够在任务执行过程中调整智能体方向的 Steering 功能，才是自己每天都能感受到的改进；至于极速模式，他会等到它不再受限于 500 美元套餐时再考虑。

额度问题是另一处争议。Dotimus 认为，在现有使用限制下，极速模式以 8 倍速度消耗套餐额度，并没有解决用户完成工作的实际困难。他呼吁 OpenAI 优先改善额度限制，而不是继续销售更高的速度档位。

自称订阅了每月 500 美元套餐的 Luca Hagenmayer 也表示，自己的额度已经撑不过一天，因此难以理解开启极速模式的价值。

lorenzo 则认为，如果基础速度已经让用户感到缓慢，更快的体验就应该成为基本需求，而非高价套餐的特权。

此外，也有用户反馈更新后的稳定性问题。

Avenrae&Shae 称，更新后部分 Codex 智能体无法正常工作，工具调用也受到影响；其借助 Claude 排查后，怀疑问题涉及 node_repl.exe 和 VCRUNTIME140_1.dll。

这些反馈显示，部分用户关注的重点，是额度能否支撑一天的工作，以及更新后工具能否稳定运行。即使已经购买最高价套餐，如果提速意味着更快耗尽额度，极速模式的吸引力也会打折。

这些讨论反映出，用户确实希望智能体更快，但对提速的价值判断并不一致。有人愿意为更流畅的交互和更短的工作循环付费，也有人认为，基础速度本就应该得到改善。最终，极速模式能否说服用户，仍要看它在真实任务中省下的时间，是否足以抵消增加的费用与额度消耗。

智能体时代，速度开始单独定价

从应用角度看，极速模式更可能在需要持续交互的工作中体现价值。

编程智能体的一项任务，往往包括阅读代码、生成修改、执行测试、检查报错，再继续修正。用户等待的时间来自多个环节。模型生成更快，可能缩短其中反复出现的等待，但测试执行、网络请求和外部工具本身的耗时，仍会影响整个任务的完成速度。

OpenAI 在极速模式文档中特别建议使用 WebSocket，尤其是需要连续快速调用工具的智能体应用。其解释是，如果没有持久连接，网络开销可能削弱极速模式带来的延迟收益。

这也说明，评价“极速版”不能只看文字输出有多快。对开发者而言，更有意义的比较，是在相同任务、相同推理设置和相同工具环境下，分别观察完成质量、总耗时与实际费用。

此次更新显示，OpenAI 正把模型能力与运行速度拆成可以分别选择的产品维度。同一个 Sol，既可以按标准价格运行，也可以付出更高费用来减少等待。

对用户而言，最终值得计算的，是一次提速究竟省下了多少工作时间：如果它能让人更快完成一轮调试、及时发现错误并继续推进，溢价可能有意义；如果任务本来就在后台运行，或者大部分时间花在外部工具上，极速档位的收益就需要重新衡量。模型输出更快只是起点，工作更快完成，才是这笔费用的落点。

参考链接：

https://community.openai.com/t/ultrafast-is-rolling-out-today-for-gpt-6-1-sol-in-the-api-codex-and-chatgpt-work/1404475"

https://developers.openai.com/api/docs/guides/ultrafast-mode"

https://x.com/thsottiaux/status/2108275041276420573"

企业AI 走向生产环境，如何避免新一轮技术锁定

李冬梅 — Sat, 10 Oct 2026 05:08:22 GMT

企业部署AI时，最初关心的往往是模型能否完成任务；进入生产环境后，问题会逐渐转向另一层：模型如何部署，算力怎样管理，数据存放在哪里，系统出了故障由谁处理。如果未来需要更换模型、芯片或平台，现有架构又能否支持迁移？

近日，SUSE发布了“企业级私有AI”战略，介绍了与NVIDIA合作的AI Factory方案，并展示了面向中国企业环境适配的云原生运维智能体Liz。SUSE将“开放选择”和“安全治理”放在此次发布的核心位置，希望以现有的Linux、Kubernetes和安全管理能力，参与企业AI从试点走向规模部署的过程。

在公开分享中，SUSE首席营销官Margaret Dawson（戴珍珠）、SUSE AI高级产品经理Alessandro Festa，以及SUSE中国区副总经理吉晖，分别谈到了基础设施、技术锁定、安全和本地化等问题。他们的观点共同指向一个判断：企业AI的竞争，正在从单个模型或应用的能力，延伸到支撑这些应用长期运行的基础设施。

SUSE 想做的是 AI 基础设施

此次发布的SUSE AI Factory with NVIDIA，将NVIDIA AI Enterprise与SUSE的基础设施及安全治理能力结合，用于支持企业在本地数据中心、多云及离线环境中部署AI工作负载。新闻稿称，该组合方案能够将部署周期从数月缩短至数天。不过，这一时间是SUSE对方案效果的描述，具体项目所需时间仍取决于企业现有系统、数据准备和集成复杂度。

“AI Factory”听上去涵盖范围很广，但SUSE对自身业务边界的表述相对明确。Dawson表示，公司主要聚焦基础设施层，不打算提供广泛的AI应用；当智能体直接服务于基础设施运行和管理时，相关能力才会成为产品的一部分。

吉晖将SUSE的工作概括为两个方向：一是infra for AI，提供承载AI应用的基础设施；二是AI for infra，利用AI提高这套基础设施的运维效率。按照这一定位，企业可以在上层选择不同的模型和智能体应用，而SUSE希望管理支撑它们运行的计算环境、容器集群和安全策略。

这也意味着，SUSE与AI办公产品或模型厂商所处的位置有所不同。吉晖认为，办公类智能体主要进入企业的具体工作流程，基础设施厂商则要解决这些应用在哪里运行、如何获得算力以及怎样保持系统稳定的问题。当企业内部运行的智能体数量增加，底层资源的分配和管理会成为更实际的挑战。

Festa进一步提出，AI Factory未来可能向“Token Factory”演进。在他的描述中，企业需要将计算资源组织起来，持续向模型及用户提供推理服务，基础设施管理也会因此更紧密地连接上层负载。他同时提到，这一方向仍涉及方案设计和产品演进。因此，Token Factory更适合被理解为SUSE当前提出的产品方向，而非此次已经完整交付的能力。

开放架构，如何转化为真正的选择权？

SUSE长期强调开放架构，此次又将这一主张延伸到AI部署。原因在于，企业使用AI后，依赖可能同时出现在芯片、模型、工具链和运维平台等不同层面。即使其中一部分采用开源技术，替换一个组件也可能牵动整个系统。

Dawson认为，企业不必为了追求开放，一次性替换所有现有系统。许多企业仍在使用专有平台，更现实的方式是先解决新旧系统之间的互操作问题，再根据业务条件逐步调整技术架构。她以虚拟化平台迁移为例：一些企业可以先让开放技术与原有系统共存，条件成熟后再完成更大范围的迁移。

Festa则将标准化视为降低迁移难度的一种办法。按照他的说法，AI相关部署方案应尽量采用可复用的设计，以减少企业从一个平台迁往另一个平台时的重复工作。但他也承认，部署迁移只是其中一步；迁移之后，如何管理不同操作系统和平台，仍然是实际问题。

Dawson提到，技能缺口也会影响企业的选择。一套架构即使支持替换，企业仍需要具备迁移和维护新系统的人员能力。培训、系统集成及新旧环境的统一管理，因此与产品兼容性同样重要。

从企业的角度看，“支持多种模型和平台”只是选择权的起点。能否以可接受的成本替换它们，业务能否在迁移中保持连续，新的硬件或模型能否沿用现有管理流程，才决定选择权是否能够在生产环境中兑现。

私有AI 的安全问题，贯穿上线前后

私有部署通常与数据控制权联系在一起，但将AI系统放进企业自身环境，并不意味着安全问题已经解决。企业仍要管理软件组件的来源和漏洞，控制模型与智能体的访问权限，并监测应用运行后的行为。

Festa在分享中表示，没有“100%完美的安全”。在他看来，开放架构的价值之一，是让企业和供应商能够检查组件的安全状态，并在发现问题后进行修复。SUSE所提供的应用集合，也试图将经过治理的常见开源组件纳入企业软件供应链。

吉晖将相关工作分为上线前和上线后两个阶段。上线前，SUSE对常见开源组件进行扫描、修复和加固，供企业构建应用时使用；上线后，则通过容器安全及零信任机制，处理运行过程中出现的风险。这两部分分别对应软件供应链安全和运行时安全。

智能体的出现又增加了一层权限问题。Dawson认为，当智能体能够访问系统、调用工具并执行操作时，企业需要像管理人员账户一样，为它们设置明确的访问规则。智能体可以辅助完成任务，但它能读取哪些数据、操作哪些系统、在什么环节需要人工确认，都应由企业事先确定。

SUSE所说的“自主可控”，也与数据存放和合规要求有关。吉晖认为，中国企业对数据控制权和架构控制权都有关注；Dawson则指出，其他市场同样重视数据主权，只是对数据保护、存储位置和控制方式的表述有所不同。各地要求不尽相同，但企业都需要弄清楚数据如何流动，以及由谁管理相关系统。

Liz 从云原生运维切入

Liz是此次发布中用途较为具体的产品。根据SUSE的介绍，它集成于Rancher Prime，面向Kubernetes集群运维，可以将集群指标和系统事件用于中文交互、问题分析及故障排查。其设计遵循“人在回路”的原则，由工程师保留对生产环境操作的决策权。

SUSE中国云原生开发经理赵振阳解释，团队选择从运维场景切入，是因为工程师排查问题时，常要反复收集环境信息、整理运行记录并分析可能原因。Liz希望承担其中一部分信息收集和分析工作，辅助工程师定位故障。Festa也强调，Liz是针对基础设施的垂直工具，而非解决各类企业问题的通用智能体。

中国版Liz的差异，主要体现在本地部署要求与模型生态适配上。吉晖表示，Liz遵循全球产品路线，中国团队负责适配本地AI环境。赵振阳进一步提到，中国企业对数据安全、操作审计和归档有明确需求，因此团队开发了相应版本，并适配千问、DeepSeek、Kimi、智谱、MiniMax等模型。

SUSE称，Liz可以帮助缩短集群故障的平均修复时间，但没有提供具体的对照数据。对于运维团队，更有价值的检验可能是：它能否准确区分故障原因与伴随出现的异常，分析依据是否可以追溯，错误建议会不会触发不当操作，以及人工确认机制是否适合日常工作流程。这些问题需要在实际使用中验证。

当代码不再稀缺：大型工程 AI 狂欢下的确定性底座｜QCon上海

QCon全球软件开发大会 — Sat, 10 Oct 2026 02:00:00 GMT

从「构建 AI」到「驾驭 AI」，100+ 实战案例拆解 AI Native 时代的工程新实践！

2026 年 QCon 全球软件开发大会大会 · 上海站"

哔哩哔哩技术专家张忻正已确认出席 “AI 驱动的软件工程"” 专题，并发表题为《当代码不再稀缺：大型工程 AI 狂欢下的确定性底座"》的主题分享。AI 大幅降低了代码生成成本，却没有同步降低正确性交付成本。进入大型工程后，模型更像一个能力放大器：工程基础扎实的地方被放大，缺失的约束、验证和定位能力也会被放大。

张忻正本次分享结合后端、Web 前端与移动端的真实实践，聚焦 AI Coding 落地最关键的四件事：约束、定位、验证、度量。分享如何将架构规则从文档变成可执行约束，利用工程关系精准定位上下文，通过自动化验证提供交付证据，并从“代码量、Token、采纳率”等过程指标回归到一个更核心的问题——AI 写出来的代码，我们敢不敢合并？

同时复盘大型团队在 AI 工程化过程中的真实取舍：哪些建设值得持续投入，哪些方案已经验证失败需要止损，以及什么样的工程与协作形态，才能真正支撑 Fullstack 的规模化 AI 交付。

张忻正曾任 FFmpeg Contributor，IJKPlayer maintainer ， Monorepo 拥趸，目前从事跨平台技术，死磕 CMP，苹果粉转黑，b 站 0-1。他在本次会议的详细演讲内容如下：

演讲提纲1. AI Coding 在大型工程中为什么容易失速AI 是能力放大器，而不是工程能力补全器Harness 为什么会快速腐化局部有效为什么难以跨团队、跨技术栈复制2. 把工程规则变成 AI 能理解的确定性约束约束左移：Format、AST、测试、编译检查让 Codegen、强类型、构建系统承载工程事实减少平行文档，让代码和工具成为唯一事实来源3. AI 时代工程能力的四个底座约束：把架构规则变成机器可执行的检查定位：从“塞满上下文”转向利用工程关系找上下文验证：从“生成代码”转向“提供交付证据”度量：从 Token、代码量、采纳率回归“敢不敢合并”4. 大型团队的真实实践与取舍哪些工程建设已经验证有效哪些方案失败，为什么选择止损Fullstack AI 交付真正跑通需要什么条件技术改造背后的组织成本与未解决问题实践痛点自我变革需要背水一战的决心:改变熟悉的分工、研发方式与交付习惯面对已经验证不适用的平台和工程，需要敢于否定既有投入，承担拆除与重建的责任前沿亮点从“让 AI 写得更多”转向“让团队敢于合并”：重新定义 AI Coding 的工程目标，从代码生成效率回到最终交付确定性约束、定位、验证、度量的完整工程实践：覆盖后端、Web、移动端，而非单一技术栈的局部实验真实的失败与止损经验：不仅分享做成了什么，也讲清楚哪些方案为什么失败，以及什么时候应该停止投入代码成为 AI 与人共同的工程事实：减少依赖文档，通过 Codegen、类型系统、AST、编译和测试，让工程规则直接进入构建链路听众收益理解大型工程落地 AI Coding 时，真正的瓶颈为什么从“写代码”转向“确定性交付”获得约束、上下文定位、自动验证等工程建设的具体实践参考了解大型团队 AI 工程化中哪些值得做、哪些应该停止做，避免陷入不断堆 Harness 的低效循环理解 Fullstack AI 交付真正需要的工程和协作基础

查看更多详情可扫码或联系票务经理 18514549229进行咨询。

黄仁勋为微软站台：没有 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 也已经表示将予以支持。

该声明式提案通过标准