会前画面（无实质发言）
开场说明｜黑客松演示安排
大家早上好！昨天有谁参加了黑客松？今天又有谁准备继续动手？好。
没在 Signal 群里看到通知的朋友注意，我发了一个 Airtable 报名表——这是本次活动少数没有自己定制开发的东西。请填写团队名称、成员和做出的作品等信息。展示环节只接受 Demo，不要幻灯片，要直接做交互演示。每人只有两分钟，到时间我会打断。我们大概能安排 30 个人，名额先到先得；没排进前 30 也没关系，只是我们实在没有整天时间。另外，今天上午的演讲安排是……
Johannes Hagemann / Prime Intellect｜大规模异步强化学习与开放 AI 基础设施
今天先提速一下，第一位是来自 Prime Intellect 的 Johannes，他将介绍开源 AI。掌声欢迎！谢谢。
大家好，我是 Prime Intellect 的 Johannes。今天要谈的是开源强化学习及其基础设施。（演示设备似乎出了点问题。）先问一下，在座有多少人已经大致了解最新大型语言模型的后训练，特别是强化学习是怎样工作的？很好。又有多少人亲手给语言模型做过后训练？有几位。今天我会先讲一点基础，再深入介绍大规模强化学习的细节。先介绍一下 Prime Intellect：我们是一家研究实验室，致力于开放式超级智能。我们关注的不只是把最终模型权重开放出来，供大家自行托管。
我们更想把那些如今被大型实验室围墙圈起来的前沿基础设施也开放出来——把 OpenAI 等实验室内部拥有的工具交给更多人、公司和组织。我们的一个基本信念是，未来更可能出现数以万亿计能自我改进的 Agent，而不是只有一个无所不能的“神模型”。我们也相信科学乃至其他领域可以自动化。如果更多人有权使用这些前沿基础设施，进步会比只有少数实验室能使用它们快得多。这也涉及自主权：我们希望更多人、企业和国家能控制自己所依赖的 AI，真正掌握“制造机器的机器”。
我们的目标是让你自己也能成为一家 AI 实验室。图中展示的是一个闭环：部署模型到生产环境、收集运行轨迹、根据轨迹创建强化学习环境、用最新开源模型评估、继续训练，再部署回生产。这是我们的核心理念之一，接下来会详细解释。先回顾过去大约六年的 AI 发展。在我们看来，2020 年 GPT-3 问世，开启了规模化时代；当时的 Scaling Hypothesis 令我非常兴奋，我一下子钻进了这个研究领域。直到 2024 年，绝大多数性能增益仍主要来自规模越来越大的预训练；当然中间也有其他进步，例如人类反馈强化学习。
但到 2024 年末 o1 出现、2025 年初 DeepSeek-R1 出现后，大规模强化学习开启了一个新范式。最早主要是单轮任务，比如容易验证奖励的代码或数学题，利用 GRPO 一类的算法训练。过去一年它越来越有 Agent 特征：从单轮 rollout 变成多轮 rollout，中间可以调用工具、使用沙箱，任务跨度和上下文也越来越长。演讲结尾我还会谈谈下一步：最近几周我们已经看到一些既令人兴奋、又有些令人担心的多 Agent 系统范式，包括 Agent 群体协作等。
今天的议程包括：Prime Intellect 开源的前沿强化学习基础设施；为什么需要异步强化学习——即把训练和推理解耦，才能在执行长时间任务时维持最高吞吐；强化学习系统需要哪些组件，包括生成 rollout 的推理服务、接收批次并更新参数的训练器，以及将新模型权重从训练器广播到推理端的机制。接着我会谈环境和评测，解释如何定义它们。
最后是沙箱，以及如何把这些强化学习任务真正扩展到大规模。先快速介绍我们过去约两年维护和开发的开源框架。今天要记住两个名字：一是 Verifiers，用来定义强化学习环境；二是 Prime RL，我们的异步强化学习框架。它支持参数量高达数万亿的模型，包括最大的混合专家模型，能够在 Blackwell 和 Hopper GPU 上、以不同精度训练。例如，你可以用多个节点训练 GLM-5 这样的模型；我们也已经把强化学习扩展到超过 2,000 张 GPU。
框架支持监督微调，也支持多种强化学习算法，还支持图像输入等多模态能力。此外我们维护 Renderers——供训练和推理使用的可编程聊天模板库，已集成进一些其他开源工具；Prime Kernels——持续改善训练性能的底层算子库，原生集成在 Prime RL 中；以及 Prime Environments——由我们的团队维护的强化学习环境。稍后还会介绍更具社区性质的 Environment Hub 计划。先说第一个问题：为什么要把训练器和推理端拆开，采用异步强化学习？
先看同步做法：训练和推理共用一组 GPU。训练完成一个批次后，GPU 切换去执行推理、生成 rollout；这些 rollout 生成完，再继续训练。问题是，整个系统基本会被最慢的 rollout 卡住，尤其是需要连续操作很长时间的 Agent 任务。所以过去两年，我们和其他开源研究者重点开发的技术之一就是异步强化学习，把训练器和推理服务分离。
这样一组 GPU 持续训练，另一组 GPU 持续推理，只需要把训练器的新权重广播给推理端。推理端不必等待训练完成，可以落后几个训练步骤；并不要求每次生成 rollout 都用最新 checkpoint。我们和其他研究团队通过实验发现，这种方法相当稳定。它让训练器一直以较高吞吐训练，也让推理端始终以尽可能高的速度运行。Prime RL 的总体架构就是：训练器生成并广播新权重，推理服务接收这些权重。
中间有一个 orchestrator 负责批处理和调度，把推理产生的 rollout 组织成批次送回训练器；它又与 Verifiers 定义的环境和评测交互。
如果 Agent 的 rollout 涉及代码执行，就需要沙箱。假设推理集群同时生成 1,000 甚至 10,000 条 rollout，那么你也要有相应数量的沙箱来运行代码。先讲推理端。部署模型推理时，你可以选择很多运行点：比如聊天产品需要高度交互，用户期待每秒生成几百 token、很快获得答案。
这里存在一条推理的 Pareto 前沿曲线，可以在吞吐与单请求速度之间选择不同工作点。聊天应用偏向高交互性；强化学习 rollout 的目标则更靠近高总吞吐那一侧。我们使用非常大的 batch，不太在乎每一条 rollout 的响应速度。每条 rollout 每秒只生成 10 或 20 个 token，也完全可以接受：因为它们是异步并行的，单个任务跑久一点没关系，关键是同时完成尽可能多的任务。这也是我们在 Prime RL 中大力优化的方向。还有大量推理性能优化，今天不一一展开。
第二个组件是训练器。这部分与预训练很相似：既要尽可能快，又要把巨大的模型装进 GPU 内存，所以需要在保持吞吐的同时尽量把模型切分开。Prime RL 主要采用三种技术。第一种是 PyTorch 的 FSDP2。训练时要保存模型参数、梯度和优化器状态；FSDP2 将三者分片到所有 GPU 上，从而降低单卡的内存占用。但面对真正巨大的 MoE 模型，这通常还不够。
例如要训练 Kimi 系列的万亿参数模型，就还需要专家并行，把 MoE 的不同专家部署在不同 GPU 上。最后是上下文并行，把序列长度也切分开。对长任务 Agent 训练来说，激活值往往占据大量显存，所以必须切分激活，才能支持训练时 256K 的上下文长度。
下面看这些技术在实际模型中的效果。左边是一万亿参数量级的 GLM-5。
要做全参数微调，究竟需要多少 GPU 节点？用 Prime RL，我们可以在 24 个 H200 节点上比较从容地训练 GLM-5，两天完成 1,000 个训练步骤，单步耗时很短。如果换成内存和算力都更强的 B300，只需 14 个节点。对稍小一点的 GPT-OSS 或 GLM-4.5-Air，我们能在 6 个 H200 节点上，两天完成 1,000 步。
强化学习系统还需要把训练器上的权重尽快分发给推理端，好让推理端收到新版本。方法很多，例如采用 RDMA 的权重广播方案；也有其他高速权重传输技术（相关缩写在原稿中听辨不清），据演讲中的例子，可以在不到四秒内将 GLM-5 训练产生的约 1.6TB 权重从训练器传给推理端。接着谈强化学习环境与评测。我们把框架称为 Verifiers：同一套环境定义既能用于训练，也能用于评测和合成数据生成。
我们在过去几年反复调整环境架构，如今倾向于图中这种由三部分组成的设计。第一部分是 task set，即任务数据与评分方式；第二部分是 harness，也就是执行任务的 Agent 框架。它可以非常简单，只是一个循环，也可以采用 Codex、Hermes Agent 等最先进的编码 Agent harness。我们让你能够很方便地在训练或评测时替换 harness，而不必重写环境。
第三部分是运行环境。测试时在本地运行当然没问题，但真要做规模化训练，你会希望使用能够扩展到 10,000 个并发沙箱的运行时。去年底我们启动了社区项目 Environment Hub：一个公开的环境注册中心，让大家上传、下载、复用强化学习环境与评测集。如今已有上千名创建者在 Hub 上制作各种场景，涉及代码、数学、多模态、科学和医疗等。
Hub 上还有浏览器操作、工具调用、计算机使用等环境，以及可以开箱即用、帮助你启动第一轮训练的示例。另一项不可少的基础设施就是沙箱。我们的沙箱产品与研究团队紧密联合设计，能够在极短时间内扩展到数万个并发实例。右侧图展示了研究团队的一些普通工作负载：只是几项强化学习训练，就能瞬间拉起超过 20,000 个并发沙箱，过去 24 小时总运行次数几乎达到一百万。对于规模化 Agent RL，这其实是常见的工作量。
沙箱方案经过多轮迭代，现在每个沙箱使用独立的 microVM，并专门针对强化学习的负载优化。这里我想再谈谈去中心化，因为我知道今天有不少听众喜欢这个方向。前面说过，训练器和推理端可以彻底解耦，推理 rollout 不一定非要最新权重，这会带来一个很好的特性：整个系统甚至可以在全球分布式运行。训练器在一个地点，推理工作节点理论上可以分布在世界任何地方。
只需从训练器向这些节点广播权重即可。2025 年 5 月，我们在 Intellect-2 训练中已经把它用于生产：训练器在一个位置，世界各地的推理工作节点持续生成 rollout，再把结果传回训练器。这在商业上也很有吸引力，因为可以利用全球闲置算力。另一个公开例子是 Cursor 的 Composer 2：他们的论文介绍过训练器由团队掌控、推理工作节点分散在世界各地的方案，只需分发权重。其中还有一个非常有意思的技巧：差分权重更新（delta weight updates）。
在相邻强化学习步骤之间，模型权重只改变很小一部分，因此不一定每次都广播完整模型。采用这种办法，广播数据量据称能压缩约 98%。原本一个万亿参数模型可能需要传送约 2TB 权重，现在只需要几 GB，这就足以通过公网传输了。最后展望下一步：多 Agent 强化学习基础设施。最近几周出现了一些很有希望、同时也令人警惕的结果，例如 OpenAI 关于纳维—斯托克斯千禧年难题的工作，以及某次 Hugging Face 事件；它们在不同程度上都涉及多 Agent 系统。（这些具体事件名称依赖自动转录，须另行核实。）
我们相信，多 Agent 协作会成为下一条规模化维度。我们较早就在 Prime RL 和 Verifiers 中建设了描述多 Agent 系统的能力，包括 Agent swarm，也包括更简单的子 Agent 调用。目前我们正在训练自己的 Intellect-4 模型，已经在训练中使用 Agent 间通信和子 Agent。目标是进一步走向真正的 swarm；我认为未来一年，无论闭源还是开源模型都会朝这个方向发展。
把前面所有组件整合起来，我们的平台提供一个叫 Model Factory 的东西：面向前沿模型训练的全栈服务，底层建立在 Verifiers、Prime RL 等开源工具之上，再结合我们提供的环境管理及平台体验。
它也依赖基础设施能力：训练启动时自动拉起沙箱，结束后自动销毁；还有具备自动恢复能力的 GPU 集群。研究人员最痛苦的事情之一，就是必须一直盯着训练任务，担心任务掉线。我们的方式是，即使一个推理副本故障，其他副本也会继续生成 rollout，系统再启动新的副本来补足容量。
更广义地说，集群节点也能自动修复和恢复。
平台提供一键启动训练的体验。训练完成后，可以直接部署模型做评测或生产服务，并收集 traces。未来还有多地域训练，以真正利用全球算力。这就是我们强化学习基础设施的大致全貌。
想听听你们对最近一些强化学习新技术的看法，比如 Goodfire 提到的某种基于特征奖励的强化学习。你觉得这类方法未来会怎样融入技术栈？ Johannes： 这是个好问题。Goodfire 那个具体方案我一时记不清细节，但我们确实看到非常多人在尝试各种方向，也有人 fork Prime RL 去做实验。不过我会说，即使是把最基础的 Agent 强化学习扩大规模，让 Kimi 或 GLM 这样的强模型有稳定提升，依然很难。
Patrick O’Grady / Commonware｜XAware：从链上数据到浏览器端可信验证
谢谢 Johannes！下一位讲者要把自己的电脑搬上来了。Patrick O’Grady 来自 Commonware。很久以前我还想招他加入团队，后来他自己创办了 Commonware。Tempo 是 Commonware 最大的客户之一，我们的共识系统都用到它们的库。Commonware 正在把许多区块链基础组件做成可复用、可替换的通用库，这帮助 Tempo 降低延迟、提高吞吐，让所有验证者能同时讨论下一个区块。掌声欢迎 Pat！ Patrick O’Grady： 戴上这种耳麦就知道是真正的技术演讲了，待会儿还能更新一下 LinkedIn 头像。谢谢邀请。
Georgios 刚才说了，Tempo 不仅是我们的主要客户，也是投资方，谢谢邀请，也谢谢你们的支持。今天想介绍 Commonware，以及我们过去几年开发、今天正式推出的新产品 XAware。先回到 Commonware 为什么成立，再聊我们为什么转向解决下一个问题。我觉得我们有时被 NFT、Meme Coin 等热闹事物带偏了：区块链最初的目的并不只是以更快的方式把资产金融化，而是把信任分散到系统中彼此交互的参与者之间。
传统产品比如 Facebook.com 或 Gmail，是信任一家公司，由它把数据交给你；分布式系统的想法则不同：让多个独立运营者通过密码学有效性证明，或达到法定数量的节点共识，一起维护可信结果。原稿在这里有语音缺口，部分论证未能完整听写。
这样用户就不需要自己维护节点，可以通过不透明的 RPC 接口获取需要的数据。只要我们能把这件事做好，理论上它应当更快、更便宜、更可靠。
分布式计算一直有个梦想：你附近某个人恰好拥有你需要的数据，你就能直接向他索取，而不是回源站；很多人同时观看视频，可以彼此转发、共享带宽；一个数据提供者掉线，换另一个继续取就好。以前密码学的性能不够好，验证这些事情太慢、代价太高。Commonware 在 2024 年成立时认为技术条件终于成熟，于是开始从零搭建一套工具，让分布式信任贯穿整个系统，同时让开发方法更贴近产品需求、性能更接近当代 Web 应用。
如果同一个功能用单台服务器只要几百毫秒，而链上版本需要十秒，愿意为了密码朋克理想忍受这种体验的人，其实没有我们期望得那么多。想真正走向大规模用户，区块链产品和分布式产品必须在使用体验上更加接近传统 Web 应用。
所以我们首先反思区块链的架构。传统区块链围绕一台共享计算机、一个共享虚拟机来构建；但现代应用一般不是这样组织的。你不会强求所有人在同一个固定的整套环境里工作。
更合理的做法，是像构建现代应用一样，使用一组定义清晰、测试完善、性能优化过的库，然后自由拼装你自己的组件。
我们把它称为“重组 Commonware 库”。例如 Tempo 使用我们的 P2P、共识和部分密码学 crate，同时又引入大量我们不负责的组件，包括 EVM 和支付层的业务逻辑。有很多小库，最初上手可能略麻烦，但长期维护和优化反而更容易，因为不会被固定框架的接口限制。我们以前担心必须招十几个开发者关系工程师来教大家搭系统；幸运的是，Agent 的出现解决了大量入门工作，现在拼装这样的技术栈容易多了。
Commonware 就是给那些你不想自己重复造轮子、却又很重要的基础组件，提供经过审计、优化、达到先进水平的实现，让你可以放心在上面构建自己的系统。我们还在不断推出其他模块。
我们展示过一个共识相关的系统（该处产品名在原稿中听写不清），性能超过每秒 100 万笔交易，全球范围交易延迟低于 400 毫秒。
此外还有一个正在审计的支付清算协议，能让极小额、高频率的交易在经济上也可行。
然而一直有个问题：即使底层组件做好了，开发者又怎样给这些系统建立索引、真正构建产品？算一笔账：每秒一百万笔、每笔 500 字节，一个月产生约 1.3PB 数据。如果你想让它们可以被查询、复制、用于应用，很多团队根本没有能力每月摄入 1.3PB 的数据。传统云架构往往把链上实时流与历史流灌入 Postgres 等 OLTP 数据库，再复制到 ClickHouse 等 OLAP 系统。
你需要不断复制、搬运、清洗、减负。但这些通用数据库原本是按照“它自己就是事实来源”来设计的；区块链数据早就有密码学验证，数据库不必再承担全部这套职责，于是通用方案做得太多、成本太高。借用贝索斯的名言——创业者总得引用一次——“你的利润就是我的机会”。能不能只做真正需要的事情，从而更便宜、性能更好？这就是 XAware 的由来。让我戴上新的 XAware 帽子，创业者总要身兼数职。第一批两款产品叫 Log 和 Store：Log 负责接收、保存数据流，Store 负责建立查询索引。
Log 很直观：向其中推送大量键值数据，另一侧可按过滤条件订阅。Store 读取 Log 并建成低延迟的可查询存储。除了 get，它支持范围查询，比如找某账户最近的所有交易；还有容易被低估的 reduce：无需把整个键空间的所有键取回来，就能高效计算总和、计数等聚合结果。在这些原语之上，可以构建非常多东西。我们已经为 Simplex 共识证书和区块开发索引模块——Tempo 就使用这个共识；还为我们与 LayerZero 合作开发的 QMDB 数据库制作状态索引与证明生成模块。
得益于 DataFusion 团队的工作，我们还能摄入各种数据，并在上面直接执行 SQL。但我们不想、也不声称自己会维护用户可能需要的每一种上层模块。重要的是，开发者能用 XAware 原语构建自定义模块，然后把它部署在核心数据库旁边执行。这样，数据不会为了到另一个服务而产生高昂出站流量，你只需拿到真正对产品有用的结果。
从架构看，数据被推送到 XAware，再由客户端持有一个静态身份。Tempo 是很好的例子：它每个 epoch 都执行分布式密钥生成（DKG），通过密钥重分享保持一个持续的静态身份。访问网站时，你可以把相应公钥嵌入客户端，然后去读取……
……读取存储中的结果，自己验证哪些数据真正来自共识验证者集合，而不用信任任意一个 RPC 服务商。我们今天已经有能力做到这件事。Moxie 几年前写过一篇文章，批评 Web3 宣称自己做了很多事情，实际上并没有做到。我觉得今天我们终于有机会造出真正符合“更高信任环境”承诺的 Web3，而不只是给应用换一种开发方式。我们公布了最初的定价：向 Log 写数据、重放或流式订阅，再由 Store 提供查询和扫描。你可能会问，这些费用对应多大规模？
我们的测试显示，在不同负载范围下，系统最高可以处理每秒约 500 万个键的流式写入，并在 50 毫秒以内让这些数据可查询。可以用它构建按每次网页交互付费的产品，也可以用于交易应用。我们才刚开始，但对当前成果非常满意。与其他架构运行相同负载相比，成本可能节约 10% 到 90%；当然，不同负载和性能特征会影响具体比例，而许多情况下我们的端到端速度也更快。
之所以做到这一点，是因为我们理解数据在上游系统中的产生方式，可以更低成本地复制，还为云环境及裸金属开发了自己的数据库技术栈。不过有人可能会说：你们现在成了一个新的中心化服务，客户端仍得信任你们持续在线。为此，我们把整个接口定义成 ConnectRPC 的 protobuf 规范，使用户能很方便地复制 XAware 的数据流，在自己的实例里重放它。
你不必依赖我们的服务器。跨地区甚至全球异地复制，延迟可以低到约 20 毫秒；或者直接把数据落到 S3。如果我们消失了，你仍保有自己的数据。目前就可以在本地试用 XAware：我们有一套基于 RocksDB 的、API 完全兼容的实现，能在笔记本电脑上运行。今天还开放了一个私有 Alpha 的申请。真正的愿景是，让“分布式可信”从链上一路延伸到浏览器，而不是仅仅相信链上状态、在中间再叠上一长串未经验证的服务。
应用架构下一次真正的跃迁，是在保持性能的同时把可信验证一直推到浏览器里。我们已经做出了 Demo，欢迎在自己电脑上打开。请允许我现场演示。
这里运行的是一条每秒约 10 万笔交易的区块链，执行简单支付；你现在看见的内容都在自己的浏览器内验证。我们把密码学代码、证明校验等全部编译到浏览器运行，并用一个静态身份作为信任根。链本身直接验证 Passkey。现在发送一笔交易——希望现场一切顺利——按一下指纹。浏览器会等待交易证书和证明：证明这笔交易进入了链，由验证者集合生成包含性证明，再对该证明形成证书。证明由 XAware 生成或提供，最终由你的浏览器验证。
再看看账户余额。界面能展示你的地址、共识所产生的证书、当前账户状态及其状态证明，也能展示每笔历史交易，以及证明该交易确实在链上最终确定的凭证。对需要处理资金的系统来说，无论访问者是普通用户还是 Agent，每次交互都能端到端验证，而且几乎不再需要为此付出性能代价。这不仅可能造出新的产品，也可以大幅降低成本。谢谢大家！如果想申请体验，请联系 preview@commonware.xyz。
数据量这么大，你们到底怎样存储？ Patrick： 对于验证者使用的数据结构，我们全部从零构建，目标是在能够持续处理链的前提下尽可能少存状态。前面提到的 QMDB 很值得研究：你可以先建立 Log，再在上面构建 Merkle Mountain Range（默克尔山脉），形成一棵能够认证全部交互历史的全局树。验证者内存里只需保留树的最前沿部分，就仍然能对大量历史数据提供真实性证明。对去中心化系统，这非常重要。
至于真正存储这么海量的数据，坦白讲，我们目前使用了多种云规模存储技术来扩大访问能力。
过去两年，我们也在从零开发各种高效索引与存储基础设施。
遗憾的是，这一部分技术目前是专有的；我们愿意进一步交流，但要承认这是非常大的数据工程问题。 主持人： 每人一个问题。还有谁？ 现场提问者： XAware 背后使用什么共识算法？ Patrick： 大家经常觉得我们这些研究共识的人，无论遇到什么问题都想往里塞共识算法，仿佛到处使用共识才是最好的方案。但 XAware 实际上大量依赖链本身已经产生的 BFT 共识结果。
Dan Robinson / Paradigm｜把游戏、挑战与谜题作为新的研究方式
感谢 Pat！下一位是 Dan Robinson。我突然意识到，我们差不多认识十年了。他是我在加密行业认识最久的同事，我职业生涯的大部分都要感谢他。掌声欢迎 Dan！
（主持人继续介绍。） Dan Robinson： 今天我想聊聊我们最近的一种新研究形式：游戏、挑战赛和谜题。回顾我从 2019 年到 2025 年的大部分研究，成果看起来都是博客、白皮书或论文；但到了 2026 年，很多成果变成了游戏、谜题和公开挑战。比如我和 Benedict Frady 推出的 Paradigm Puzzles，原来叫 Optimization Arena，是一个题目合集，人类和 AI 都可以针对不同问题参与优化和竞赛。今天还会介绍其他项目。我想先问：我们为什么开始用这种方式研究？为什么我认为 2026 年游戏是非常有价值的研究工具？
一个原因是，游戏正处于今天 Vibe Coding 能力的最前沿。Twitter 上有很多惊人的作品，尤其是反编译旧游戏再将它们重新组合的尝试。比如有人用 Opus 5.5 把 Minecraft 的玩法放进 Elden Ring，让你能用 Minecraft 的工具与《艾尔登法环》中的角色互动。几个月前我不认为这能实现。令人惊叹的不仅是模型做到了，还有人想出了这个点子。如今工具已经具备巨大能力，关键是有人愿意尝试、把模型推到极限。除了改造老游戏，人们也开始创造完全原创的新游戏。
（本段继续介绍游戏创作案例。）来自斯坦福大学、曾在 OpenAI 实习的一名本科生（姓名在英文稿中听写不清）做了一个工具，把现实中的城市地理场景变成可玩的游戏世界，展示了模型在游戏开发上的新能力。
例如他把旧金山的真实城市环境与《侠盗猎车手》（Grand Theft Auto）式的玩法结合起来。原稿在此处存在明显断句和缺口，未能完整记录操作细节。
我们还做了不少有教育价值的游戏。比如 RSI Simulator，基于一篇关于 AI 研究中“递归自我改进”的经济学论文。玩家扮演 AI 研究实验室里的研究者，通过配置资源、提升研究能力，最终开发出聪明到能改进自身的 AI。游戏底层是真实的经济学模型，我们把它做成可以亲自操作的教学工具。你会看到，当系统进入递归自我改进阶段，智能与能力如何迅速增长；最后的结局是，你把控制权交给 AGI，由它接管。虽然刚刚剧透了，但确实很有趣。另一个游戏叫 PACE-PACE，改编自研究 AI 竞赛动态的模型。
PACE-PACE 是实时多人游戏，加入了竞争对手。你要根据对手的推进程度调整自己的 AI 研发速度，在能力前沿和安全前沿之间取舍。超越安全边界越远，短期可能赚得越多，但给整个世界带来的风险也越大。游戏会让你看到“跑得太快”的后果。
这些只是我们做过的一些游戏。我们喜欢 AI 研究、机制设计、自动做市商，所以游戏围绕这些兴趣展开；但你一定也有自己的爱好，应该尝试围绕它们制作游戏。模型让这件事成为可能。你可以用它教育别人、帮助自己学习，也可以纯粹为了好玩，把自己的专业兴趣变成游戏。我真心鼓励大家尝试。还有一个重要观点：好游戏仍然离不开人类参与。
首先，模型其实不擅长提出有趣的游戏概念。那些在 Twitter 上广受称赞的创意，很可能都来自某个人先想到一个点子，再让模型去实现。模型也不擅长判断游戏到底好不好玩，所以你必须不断亲自试玩、倾注心思。我认为这正是“半人马”式合作的最佳例子：人和 AI 一起才能做出真正有趣的东西。游戏是一种交互式研究形式，接下来谈另一种——挑战赛。它能成为协调机制，把不同的人和 Agent 组织成合作或竞争的自动化研究团队。
Paradigm Puzzles 最早的项目之一是 AMM 设计挑战。参赛者编写一个自动做市商，把它放进模拟市场，让交易 Agent 与之互动；目标是在模拟交易中赚得尽可能多。Benedict 和我先设计了一个基于 Uniswap 的模拟环境，要求参赛者设计更好的 AMM，比如根据交易状况动态调整链上费率。后来又推出更复杂的 Prop AMM 设计题，允许你定义任意交易函数，在 Solana 上用 Rust 实现。参赛者争夺排行榜前列，也从中发现大量有关链上定价和 AMM 机制的经验。
我们办这些挑战一方面是为了教学，另一方面也想真正探究：当所有人都拼命优化同一个环境时，最优 AMM 能被推到什么程度？我们能够由此学到什么？另一个协作式自动研究案例是 Solidus，一款目标从 Solidity 编译到 EVM 的编译器。我们希望它完全在 Lean 中实现，并获得形式化验证。形式化验证编译器，就是先给源语言和目标语言定义严格语义，再证明任何程序编译前后对外部世界产生的效果都相同；也就是说，证明编译器不会引入语义错误。
我们用 Codex 构建了 Solidus 编译器的后半部分，但要完成整套编译器，还需要很多工作，尤其是建立 Solidity 源语言的完整形式语义——毕竟它是智能合约开发最常见的语言。因此我们发起 Spec Hunt 挑战，邀请所有人找出我们 Solidity 语义模型里的漏洞。做法是找出一个合约：它在我们的语义模型中运行的结果，与使用官方 Solidity 编译器编译执行的结果不同。社区已经发现了很多早期模型里的错误。这件事非常关键：想用形式化方法证明一个东西正确，必须先准确知道自己在证明什么，源语言的规范不能是错的。
另一项挑战针对编译器性能：我们的后端已经完成形式化验证，但不够高效，于是邀请参赛者提交优化。目前大家已让 Solidus 后端性能提升约 25%，而且还在继续改进。希望最终能做出有竞争力的 Solidity 编译器，但编译器前端和形式语义仍需进一步完善。开放挑战真正有价值的地方在于：要有信心认为一个系统“没有错误”，最有效的办法之一，就是向全世界开放搜索，给发现差异的人奖励，直到大家都找不出新的反例。这虽不等于严格证明一个否定命题，却是很实用的研究方式。
再举一个不是 Paradigm 发起、却很有代表性的协作研究例子：ecdsa.fail。起因是 Google 一篇论文，研究量子计算机究竟能多容易地破解 ECDSA——保护比特币、以太坊和大量其他密码学系统安全的椭圆曲线签名算法。理论上，如果量子计算机拥有足够多的量子比特和计算能力，最终就可能攻击它。问题在于，到底需要多少量子比特，机器要大到什么程度？以前大家认为门槛极高；但 Google 找到了令人担忧的重大优化，大幅降低了所需资源估计。
有意思的是，Google 并没有公开全部实现细节。（这里原稿存在短暂的语音识别缺口。）
于是有人建了网站，号召全世界竞赛，试着复现并超越 Google 给出的界限。论文里有一些线索，但没有完整算法。Google 也许认为只公布结果、不公布具体破解方法，是负责任的披露。围绕挑战聚集起来的 EigenLayer 社区研究者不仅推导出相关优化，还找到比 Google 原先电路更好的结果。这说明：当协作式自动研究通过挑战赛组织起来，集体搜索有可能大幅超越单个研究团队认为可达到的优化界限。再说一个很有趣的谜题，叫 Kryptos。
Kryptos 是美国 CIA 总部的一座密码雕塑，1990 年揭幕，上面刻着加密文字。绝大多数内容已经破解：一部分在 1990 年代中期由 NSA 研究人员解出，其他部分由互联网爱好者解出，但最后一段仍然困扰着所有人。讲者先说“96 个字符”，随后修正为“97 个字符”。去年艺术家决定不再独自守护这个秘密，把谜底拿出来出售。我们觉得这非常酷：一个公开了几十年、却没有人能解开的密码学谜题。因此我们在拍卖会上买下了解答，如今运营一个网站，让任何人提交最后 97 个字符的解答；系统会用真实答案的哈希进行密码学安全校验，而不用公开答案本身。
每周都有几十次提交，迄今没有人答对。我们还想知道：即使最终谜题没有解开，能不能衡量模型是否逐渐接近答案，或者整个社会解决密码题的能力是否在进步？于是我们设计了一个基准：参考 Kryptos 已破解部分使用过的密码系统，创造了 10 道难度递增的新谜题，公开发布。最初几天，前七道就被解决了，说明当代模型在这类任务上已相当厉害。
更有趣的是最后三道：尽管许多人努力尝试，而且每解出一道有 1,000 美元奖金，它们几个月都没有被攻克。直到九月 GPT-6 Astra 推出后，有人立即用 Astra 解出了第八题；第九、第十题继续坚持了一段时间，直到 Claude Opus 5.5 发布，才在之后几个星期被解决。这说明新模型确实在变得更擅长解决这类密码学难题。
参加者还建立了 Telegram 群，最终攻克第八、第九、第十题的正是这群人。更棒的是，他们并没有就此止步，而是转去研究真正的 Kryptos K4。
K4 就是原雕塑中最后那 97 个字符。我们先通过这些小游戏确认研究能力正在提高，也就为真正解决 K4 带来一点希望；同时帮助推动一个更大的社区投入这道已经公开 36 年的历史谜题。我们今年推出了很多很棒的项目，今天还想给 Frontiers 的各位一个特别礼物：一项刚刚上线的新挑战，你们是第一批知道它的人。它叫 The Claw（抓娃娃机）。我们真的在办公室安装了一台实体抓取机。
你可以用 Tempo 上的稳定币通过 MPP 付费，然后远程操控这台真实机器。之所以做这个项目，一是想把谜题带回物理世界。整天对着 Codex 开发会让你和自己的劳动成果有些疏离，我也想亲手接几根线、做点实物。二是它恰好是一个机器人研究问题：模型通常可以学会抓取，但如何用尽可能少的数据获得尽可能高的抓取精度，非常值得研究。因此我们创造了一个可以反复尝试的真实环境。
（现场演示中有一段画面和说明未完整进入自动转录。）这个游戏可以直接由人操作，也允许你训练模型来操控。
如果想上排行榜，必须利用抓娃娃机收集的数据训练自己的神经网络，再把模型提交到我们直接连接机器的 GPU 上运行。成绩取决于成功夹起小球的频率；准确率最高的模型将赢得这项挑战，比赛在星期日结束。训练这种模型需要大量数据，所以我们还在 Tempo 上构建了一个链上的训练数据市场。每次抓取产生的视频，以及你或模型的动作记录，都会保存下来。
你可以把这些操作记录挂牌卖给其他玩家，让他们购买训练数据。可能赚到一点钱，虽然金额很小；但至少有人可以通过采集视频和动作轨迹获得收益。现在已经可以在 Paradigm.xyz 上玩。现场 Frontiers 的网络不太理想，可能需要换手机热点。欢迎大家亲自试、训练模型、买卖数据。最后说说做游戏的另一个原因：对我个人来说，设计游戏、和别人一起玩，本身就很快乐。
我会想象，如果未来我的劳动在经济上不再有价值，我想怎样度过时间？很大一部分可能是找人一起玩游戏，或者给别人设计游戏。我们有充分理由相信，人们喜欢这种创造活动和彼此连接，即使没有经济收益也一样。也许未来我们会花更多时间为彼此设计游戏、一起玩、一起学习。谢谢大家，有问题吗？ 主持人： 那我回去继续打《英雄联盟》了。
我的问题更偏向游戏制作的元过程。对于吸引参与、设计奖励机制、设定截止日期等，你学到了哪些经验？ Dan： 你是问怎样做出好游戏吗？我觉得第一步是做出一款自己觉得好玩的游戏。制作时很容易沉迷于自己的设计，但要经常问：如果我是玩家，这真的好玩吗？往往需要删掉很多复杂机制，尽量简化。找愿意说真话的朋友、同事试玩也特别重要，因为你可能认为自己的设计绝妙又复杂，可看着别人玩就会发现很多地方根本不好用。
在达到一定规模前，一个研究者带一个 Agent，公开或私下解决一个问题，有时比派出一群 Agent 乱冲更有效。
某种意义上，游戏就是把谜题汇集起来，让玩家在娱乐中解决它们。
你能想象未来某个前沿 AI 实验室开发一款人们真正喜欢的 AAA 游戏，让普通玩家在不知情时顺便完成对实验室有价值的研究任务吗？ Dan： 当然，完全可能。这也是我还没有提到的另一种游戏价值：你可以直接训练模型玩游戏。很多机器学习进展本来就来自让模型下国际象棋、玩《星际争霸》，或后来的 Dota。
Aditya Kumar / VxLang｜面向异构计算的类型安全编程语言
掌声感谢 Dan。接下来这位讲者，我此前只交谈过一次，但他正在做一个非常酷、也许会改变我们编程方式的项目。欢迎来自 VxLang 的 Aditya Kumar。（原稿在讲者交接处有缺句。）
前两周我还只是在自己的笔记本上，用 Claude 和 Gemini 写代码。一个星期六，我坐在圣迭戈一家印度食品店喝茶，突然看到手机上涌来 50 条通知。我平常可能只有一两条。点开一看，原来一个我从没见过的 Zach 转发了我的帖子，事情就这样滚雪球般扩散了。结果两周后我就站在这里。
谢谢邀请，我非常激动。你们会发现我很喜欢讲故事。对我来说，讲故事是一种重建事物、理解思路的方式。
准备这场演讲前，我跟 Claude 说：“能不能帮我写成丹·布朗小说的风格？”它说可以从一次训练事故开始：凌晨某个时刻，一项可能耗费几周乃至几个月的大模型训练任务正在运行，然后突然发生了什么……
接着出现了令人头疼的错误。关键在于，这两类错误其实都可以在编译时发现。
但现有基础设施往往不能。我们用 PyTorch、vLLM 或某种花哨的 Python 框架，实际上是在用 Python 包装一门隐藏在开发者脑袋里的 DSL，它从来没有以明确规则表达出来，于是错误只能到运行时才暴露。先看看问题是什么：你访问了一块本来不应该访问的内存。考虑 GPU 内存层次结构，先只看一张 GPU。CPU 侧有 DRAM，GPU 侧有 HBM，下层还有共享同一或相关地址空间的 L2 缓存、SMEM 等部件。解引用指针时，内存到底位于哪一个层级、从哪个执行单元能访问，非常重要。
几周前还有个类似的实际 bug：一个指针原本应该指向 CPU 内存，却被传进 GPU shader，在不该解引用的地方使用。轻则访问不到导致错误，严重时恰好访问到某块内存，拿到垃圾值。就像你想让系统展示可口可乐的广告，结果输出了百事可乐——训练或推理产生的结果被悄悄污染了。这类问题在编译期本来是可以推理和检查的。看一个简单例子：C/C++ 中调用 malloc，得到的是指向主机 DRAM 的指针；如果在 GPU 上分配，指针指向的则是 HBM 或共享内存。
如果把 GPU 指针误当作 CPU 主机侧指针解引用，通常要到运行时才报错。编译器和静态分析工具难以发现，特别是当相关代码分散在不同源文件、不同库中。原因是如今多数编程语言的指针类型都没有携带“内存究竟位于何处”的信息，它们在传统抽象机器里看起来都一样。
技术上这叫指针的 provenance（来源／出处）。从编程语言发展史看，C、C++、Java 等语言推广了结构化控制流，鼓励用函数、循环和 if/else 组织代码，而不是随意 goto；这让程序更容易推理。Rust 又进一步，把指针的所有权作为语言语义的一部分，编译器能阻止许多与所有权相关的错误。
但如果继续向上一层思考，除了控制流和所有权，我们还需要推理机器本身。传统语言抽象出一台通用计算机：一个指针、一条仿佛无限延伸的图灵机纸带；真实硬件却不是这样。内存分布在各种块与设备上，有可见性、连通性和互斥关系，并非所有地方都能随意访问。计算资源如今这么昂贵，异构架构越来越常见，语言必须能表达这些关系。
现实世界中的内存有明确分区、容量和连接关系，不是一条无限长、处处等价的地址带。我们需要把这些硬件约束作为程序逻辑的一部分进行建模。
Rust 把所有权变成了一等公民；VX 想再做两件事：把数据放在哪里以及程序能够在哪里运行也变成一等公民。更抽象地说，就是把系统的 shape 与 topology（形状和拓扑）加入类型体系，在编译期提供强保证。最初我为 VX 制定了四个设计支柱，今后可能变化，但目前所有功能都是按它们判断是否应该加入。第一是 placement 和 capacity，即放置位置与资源容量。指针最终落到哪里、对象在哪个设备上，都应该在类型中明确表达。
这些关系定义在一个所谓的 fleet 文件里。VxLang 的 GitHub 仓库有例如 B200.vx 这样的文件，其中明确写出内存层次结构、不同层次的关系和可见性。第三个支柱是并行编译器。因为一开始只有我在写这门语言，我就想：既然语言和编译器都是我的，为什么不把并行编译设计成基础能力？结果它成为一个很强的特点。上个月我在 CppCon 演讲，收到很多反馈。
现在每加入一个语言特性，我都会问它能不能保持并行编译的语义。如果不能，就得仔细考虑是否值得牺牲这一原则。到目前为止，我仍坚持并行编译。最近你们可能也看到 Rust 编译时间的问题，这不只是 Rust 独有的；当语言和代码库越来越庞大，编译依赖关系也越来越复杂。
如果从设计之初就要求所有东西都适合并行编译，不允许引入破坏这个特性的机制，编译时间就能随代码库规模更好地扩展。
第四个支柱是对张量和自动微分的原生支持。我来自机器学习领域，所以希望张量运算、autograd、JVP 等能力在语言中直接可用。你们看到 NVIDIA、AMD 等公司正在推进基于 tile 的编程语言或中间表示，例如 Tile IR 之类。我目前的想法是：也许把张量真正做成一等公民，就足以表达各种 tile 运算。但这仍在探索中。昨天有一场关于 Rust 与 GPU 的精彩演讲，讲到如何让 Rust 代码下沉到 NVIDIA、AMD 等 GPU 后端。
这种思路与传统编译器很像：一门 C/C++ 或 Rust 语言，最终面向 Intel、ARM 等不同 CPU 后端。LLVM 有许多后端，但它起初围绕 CPU 设计，因此 DSP 等较特殊架构往往没有同等优化支持。VX 想再泛化一步：在同一个源文件中为任意机器写程序。 理由是，今天不能再假定只使用一种架构，甚至一种类型的架构。
算力越来越贵，异构系统越来越普遍。许多云服务想让重计算任务跑在强 GPU 上，让廉价任务跑在一般的商用 GPU 上，或者其他设备上。现在工具链可能还不够好，但这种混合一定会继续增加。因此 VX 在最初设计时就以这种异构环境为前提。看一个例子：我们在同一个文件中初始化一个张量，把它从 CPU 内存传输到某个 GPU 设备，然后在设备上做计算。
计算在 GPU HBM 上执行，比如 spawn on 一个设备，在上面做矩阵乘法；随后把结果转回 CPU，再打印。这是 VX 很基础的例子，今天已经能运行。关键是 spawn on topology::device：你给它一个拓扑类型，比如一般意义上的 GPU；随后通过 fleet 文件告诉编译器，这里的 GPU 实际上指 H100。编译器会针对 H100 特化代码，并重新检查全部约束。如果内存容量不够，或数据传输路径违反拓扑关系，编译阶段就会报错。
再看上一张幻灯片中倒数第三行 let c_host = transfer(c)。如果忘记这行数据传输，直接在 CPU 侧打印 GPU 上的结果，VX 编译器会告诉你：这是非法的；主机不能直接解引用仍属于 GPU 设备的指针，你必须先做 transfer。传输后指针的类型会相应变化，provenance 一路被跟踪。若使用普通 CUDA 库和传统语言，编译器很可能认为没有问题，直到运行时才炸。再比如你分配一个大得离谱的张量，编译器也能提前发现内存溢出，因为 fleet 文件里写明了目标设备的内存容量。
内存只有在教科书或程序员想象里才是无限的；真实机器有明确上限。如果你真想把容量设为无限，也可以在 fleet 定义中选择那种抽象。但一旦指定实际有限容量，编译器就能给出清晰而具体的错误提示。
而且这种检查不局限于一行代码。VX 在编译中会下沉到 MLIR，并在不同函数阶段分析内存压力。后面我会解释为什么能做到。
因此它能发现跨越整个程序的潜在内存不足问题。
fleet 文件同时描述内存和拓扑。比如一台 H100 的算力、HBM 容量，以及 HBM、L2、SMEM 之间的内存可见性关系。某个运行在 SMEM 语境中的计算，可以根据规定访问 HBM 指针；CPU DRAM 和 GPU HBM 之间则有 transfer 边。我们甚至可以给传输边标注带宽或速度，供高性能分析和优化使用。先不用在介绍阶段深入，但这类信息可以非常强大。你完全可以针对同一段程序给出 H100 的 fleet 文件，再换成 B200 的文件，让编译器针对不同架构特化。
更复杂的程序也一样：先在一张 GPU 上执行，把张量转到另一张 GPU 上计算，最后送回 CPU 输出，都可以用同一门语言表达。我留一个思考题：怎样在这个抽象中建模 RDMA？知道远程直接内存访问的人有多少？好，举手的有几位。你有两张 GPU，RDMA 使用位于两者之外的一套传输引擎把数据从这里移到那里。这套引擎该怎样写进拓扑？我认为这个模型足以表达它，你们可以课后想想，或者给我留言。
整体编译过程是：有一个机器／fleet 描述文件，静态检查器根据规范做约束检查，然后翻译到 MLIR，最后下沉到 LLVM。理论上 LLVM 支持的目标后端都可生成代码，当然仍要链接对应的 CUDA 或其他运行时库，否则链接时会出错。添加新芯片或新机器，主要就是增加一个描述文件。除了安全检查，VX 还能做成本分析，例如计算内存压力、估算 HBM 带宽。如果把所有设备与数据传输边表示成一张图，还可以在编译时执行图算法。
例如 Dijkstra 最短路径、Ford–Fulkerson 最大流算法，都可以用于 fleet 级别的分析。假设你进行张量并行，想找到传输路径，甚至最小化能耗或算力账单，图上的权重和边就能派上用场。VX 也吸收了其他语言的优点：契约、自动微分、所有权、边界检查、零成本抽象、编译期计算等，而且这些能力不是随便粘贴，而是在 VX 编译器里从头实现。
VX 的 comptime 特别强大。C++ 中有 consteval 一类编译期求值机制，规定代码必须在编译阶段求成常量。既然我自己设计语言，就想：为什么不把 Z3 证明器也接进来？于是 VX 的 comptime 代码块可以生成线性约束表达式，再交给 Z3 检查、证明；证明不过就报编译错误。这使你能在编译期做形式化约束验证，比如检查刚才提到的 fleet 图。过去人们常拿编译期算阶乘、判断质数做演示，我们可以做更复杂的事情。
几天前，我让 Claude 生成了一些单文件示例程序，每个还配了构建脚本。VxLang 项目里另有一个叫 VX Starters 的仓库，里面有越来越多小巧、自包含的示例。想体验的话，可以先从这里入手。
现在版本还只是 v0.0.3，许多东西没有实现。我一开始先做了一些很酷的功能，好让大家兴奋，真正艰难的部分还在后面。写语言的头三四周简直是狂喜，觉得一切顺利，然后 bug 就开始不断出现。
如果你也想写一门新语言，最好至少准备两年时间。起初我以为三个月就能做完，但现在已经超过六个月了，可能连 10% 都还没完成。因为 LLM 帮助，未来肯定会出现更多新语言，至少写个原型比过去容易得多；但要做成真正好用的语言，仍应预留至少两年。还有很多硬件层面的难题：目前 fleet 文件在编译时是静态的，可云环境动态调度设备，要怎么办？可以运行时调用 VX 编译器重新生成二进制文件，但这是否合理？
我还没想好。张量形状有时只有运行时才知道，怎样对它们做推理？可以在编译期做保守的自底向上分析和约束收紧，也可以借鉴 PGO；若引入 JIT，又能更深入地针对运行时形状优化。这些都在探索。大量后端尚未完成；幸运的是有一些非常棒的志愿开发者加入。一位主动编写整个 Intel 相关后端的朋友完成了大量代码，另一位把原有的 comptime 系统全面重构，变得非常强大。
想参加项目很容易：我今天创建了一个 GitHub issue（原稿里的编号听写不清），配合下午黑客松提供了一些小任务。也可以从 good first issue 挑起，我在 Discord 上可以提供帮助。Linux 和 macOS 都可以开发；Windows 我没试过。想做更有意思的课题，我另写了一篇博客，链接了一些相关 issue。
比如刚才的 fleet 级图分析，有一些基础已经写好，但还没完成全部功能。如果实现这些 issue，就能在编译期模拟、分析整个设备拓扑图。听上去难，但本质是图、权重和边，再加上 Claude、Gemini 或 Codex 这些强力工具，或许没有想象中可怕。这就是我的介绍。
你前面提到了 RDMA。对苹果消费级芯片也支持吗？苹果是统一内存，系统进程可能占用比你预想更多的 GPU 可用空间，这种动态资源变化怎么办？ Aditya： 我正好有一台 MacBook，最初就是先为 Apple Neural Engine 做实现。后来发现苹果机器很神奇：因为有统一内存，同一个指针在 GPU 上也能访问。我有很多错误的程序，竟然一直运行正常；后来才意识到不是代码对，而是机器帮我掩盖了 bug。
Matthew Slipper / Paradigm｜Centaur：自主管理的企业 Agent 运行时
谢谢！我认为 VxLang 是这几周最有意思的新项目之一，大家值得好好看看。接下来请 Matthew Slipper 上台。我和 Matt 在加密世界里一起经历过很多事情，他最近加入 Paradigm，继续开发我们几个月前开源的 Centaur 项目。交给你了。 Matthew Slipper： 大家好，我是 Matt，在 Paradigm 开发 Centaur。今天想解释 Centaur 为什么做出现在这些设计选择，特别是“自主可控的 AI”如何影响架构。先举手调查一下：有多少人知道 Centaur，甚至正在使用它？看起来很多，那这一页我可能不用讲太多了。
没听过的朋友可以把 Centaur 理解为一个开源 Agent 运行时，它把 Agent 真正工作需要的组件——工具、模型接入、harness、沙箱、基础设施等等——打包起来，让你部署到自己掌控的环境里。它提供了 Quinn Slack 周一谈到的那种“一个 Agent”的体验：不论你在 Slack、Discord 或其他地方向 Agent 发送指令，它们都会进入同一个大脑、同一套由你运行的系统。我们在 Tempo 和 Paradigm 的生产环境使用它，另有约 20 个团队也把它部署在自己的基础设施上。因为 harness、模型和运行环境都能自己选择，这就是一种主权／自主权。
谈到自主权，加密行业的人很容易把它理解为一种防御：大型公司可能限制你、夺走你的数据或控制你不喜欢的软件。这种担忧确实成立，但我觉得只用防御来解释是片面的。自主权还能提供强大的主动竞争优势。 这张图展示典型 Agent 技术栈的大致组成。
当你拥有整个技术栈，就能根据团队需求替换其中任意一层。先从界面看：Paradigm 主要在 Slack 协作，但社区贡献了 Discord、GitHub 等入口。它们不需要互斥：Slack 和 GitHub 可以同时连接同一个 Centaur。当你在 Pull Request 里 @机器人，它能从公司积累的所有上下文里找到对应设计文档，再用这些文档审查 PR。除此以外，我们还有程序化接口。
例如 Webhook 和 API。我相信未来 Agent 与 Agent 之间的调用，可能比人直接给 Agent 下指令还多。你的 Agent 会主动创建子 Agent，或者调用 Centaur 再生成更多 Agent，而不是每次都需要人打开 Slack 提示。拥有整个技术栈，就可以自由发展这些交互方式。再往下是连接器、上下文、Skill、工作流——这些主要体现自主权的防御价值：无论底层换了什么模型或 harness，你的这些资产都可以保留并迁移。
再说 harness 和模型。它们几乎每隔几周就有明显进步，控制技术栈意味着你能立即采用实验室最新成果。Centaur 一开始其实只支持 Amp，只有这一种 harness。
后来 Opus 4.8 出来了，我们就开玩笑说：“友谊的小船跟 Amp 翻了，现在 Claude 才是我的新朋友。”于是很快增加其他 harness 的支持，并且能把能力更新迅速部署给整个组织。这是自主技术栈带来的好处。最后一点也极其重要：你要拥有自己的 traces。 每次调用 LLM，如果无法控制运行轨迹，你就在白白交出价值。Traces 能用来制作评测集、强化学习环境、微调数据，还能分析团队如何使用 Agent，帮助它今后持续改进。
如果只使用厂商封闭提供的一整套产品，这些价值可能就拿不到。归根结底，如果未来 token 是主要生产方式，你应该拥有这种生产方式的控制权。Satya Nadella 等人也表达过类似想法：技术是核心的企业，不应该只是租用自己的生产资料。有人在谈软件工厂：真正靠工厂生产产品的企业，通常会自己建设和控制关键环节。但这不意味着所有模型必须自托管或者只能使用开源模型。Centaur 经常使用前沿闭源模型，效果很好。真正重要的是三件事：你的学习成果沉淀到你能控制的基础设施里。
第二，你拥有自己的输出与成果的权利。第三，某个供应商或产品发生不愿接受的变化时，你有真正可行的退出路径。
（此处原稿存在一小段断裂，讲者切到架构图。）左侧是请求入口，以及负责代理与调度的控制平面。
外部的请求都会进入 control plane。控制平面负责启动 Agent 基础设施：接到一个新 thread 请求，创建对应沙箱，与沙箱里的 harness 通信，把结果转回 Slack 等机器人入口，并管理整个生命周期。要做到这一点其实很复杂，而且必须足够灵活，因为未来你无法预知 Agent 算力会怎样通过 API 暴露给更多系统。控制平面接着会和图中虚线框代表的 Kubernetes 沙箱交互。最重要的一点是：所有 Agent 都在沙箱里运行，每个沙箱拥有自己的 harness、工具和 Skill。
Agent 与互联网通信时要经过 Iron Proxy，凭据会由控制台授权后注入代理，由它代为调用 API。底层则是 Postgres 等存储，以及一套持久化工作流引擎（原稿产品名听辨不清）。再加上公司上下文索引，让沙箱里的 Agent 可以搜索整个组织的信息。这套系统既足够灵活，支持不同使用方式，又会在关键层给出强约束，避免开发者犯致命错误。今天我重点讲三个部分：沙箱模型、公司上下文、凭据与授权。每个真正可用的企业自主 Agent 系统都需要它们。
先从沙箱开始。只要看过旧金山的公交车或街边长椅，你就知道 Agent 最好关在沙箱里——这个观点应该没什么争议。但这也是为什么市场上有这么多沙箱公司：做好沙箱并不等于启动一个 VM 就算完事。首先，要能按需获得计算资源，还要支持长时间运行。
有些 thread 要运行好多天，有些暂停后要再恢复；你可能同时运行几百个实例。想想 Tempo 这种组织，很多员工都有自己的 Agent 线程，Agent 又会启动更多线程，Kubernetes 里很快出现 200 多个 Pod。你需要统一管理、在空闲时休眠、清理失活实例、分配资源，还得把有用的工具和 Skill 挂载进去。最后必须具备足够好的隔离与安全性，否则某个 Agent Pod 可能让整个系统崩溃，也带来很多维护困难。
Centaur 使用 Kubernetes Agent Sandbox 来提供按需计算与并行能力。每个 thread 有自己的 Pod，底层使用 Kubernetes SIG 推出的 Agent Sandbox Controller。这个控制器很棒：你可以用一个逻辑沙箱资源管理多个实际子资源，例如 Pod 和对应的代理配置。我们最初选 Kubernetes 作为主要部署目标时曾挨了很多骂。但到了 2026 年，Kubernetes 就像 Rust 一样突然变得非常适合这类任务：Agent 充分理解它，而且能帮人处理大部分运维工作。
在 Paradigm 的生产环境里，如果出现 stuck rollout、卡住的 Deployment 或其他问题，只要整个集群没有彻底瘫痪，我经常直接让 Centaur 自己去修。它会读取日志和指标，检查问题并自行处理，我一般不需要插手。因为 Kubernetes 历史很长、接口非常标准，Agent 特别善于操作。现在我们已经有了沙箱，下一步就是让控制平面管理它们的生命周期，包括长达一周的线程怎么恢复。
控制平面负责创建、销毁和恢复 Pod，同时对外提供调用这些计算资源的 API。运行数百个 Pod 很快会撞上 Kubernetes 的资源和数量上限，因此必须在空闲时积极暂停。多数 thread 生命周期约两三天，但有些会隔几周再回来，那时原 Pod 往往早已被删除。Centaur 让控制平面把每个 thread 的标准输入、标准输出和标准错误流都持久化到 Postgres。
这样即使一个 Pod 早已彻底删除，仍可以根据之前保存的状态重建并恢复 thread；旧线程可以长期“复活”，复杂度由控制平面承担。Traces 也都保存在 Postgres 里，Agent 退出后仍可做分析。Slack、Discord、GitHub、Webhook、定时工作流和内部工具，本质上都是这个 API 的调用方。接着是如何把工具放进沙箱。我们做了一个刻意的设计：Centaur 里每个工具都是 CLI。
原因与选择 Kubernetes 类似：Agent 很懂 CLI。我们也试验过 MCP。现场有多少人喜欢 MCP 协议？哇，举手的比我想象多。后期版本可能好多了，但早期那种非常有状态、激进缓存、工具调用还要通过 SSE 的方案，我个人很不喜欢；Agent 对它的理解也没有那么好。所以我们选了简单的 CLI，再用 Git 来组合工具。Centaur 有一个 overlay 概念，本质是 Git 仓库，会挂载进 thread 的 Pod。你可以有应用级 overlay、组织级 overlay，还有 Centaur 的基础 overlay，提供开箱即用的工具。
因为 Agent 对 Git 非常熟悉，后一层可以覆盖前一层。把这些工具和 Skill 组织起来，再注入每个新创建的 Pod，就能构成相当丰富的执行环境。
最后，还有隔离：每个 Pod 默认相互隔离。
Kubernetes 自带 NetworkPolicy，非常方便。你不希望 Agent 能随意访问其他 Agent、集群服务、云环境的实例元数据服务 IMDS 等。我们的网络策略会强制每个 thread 的流量通过凭据代理，阻止它直接与集群内部其他对象通信。这样不仅能限制非法访问，还能记录 Agent 到底连接了哪些外部终端。
从沙箱发出的网络请求全部经过 Iron Proxy，它按授权注入凭据，同时保留审计日志。我们有意不采用必须事先白名单审批所有出站连接的方案，因为那会严重损害 Agent 自主工作的价值。Agent 可以访问开放互联网，但每一步都被记录；没有明确授权，就拿不到凭据。默认网络策略就是：只能连接 Iron Proxy。计算这一块讲完了，接下来讨论授权。
凭据代理其实不是新概念，几乎所有云沙箱平台都展示过类似的示意图：Agent 请求里带一个占位符。
某个代理把占位符替换为真实密钥，再把请求发给上游 API。没有 Agent 的年代，这也许只是周末小项目；如今用 Claude 在手机上写，五分钟就能做出来。但真要用于像 Paradigm 这样的企业，事情复杂得多：我们有 200 多项 secrets，接入大量不同服务。静态字符串替换只能覆盖很少一部分凭据场景。你需要真正的 secret store，例如 1Password、GCP Secret Manager、KMS 等，向 Iron Proxy 提供密钥；再需要一个控制台来确定每个 Agent 实例到底被允许使用哪些凭据。
沙箱启动后会获得一个 principal（安全主体）身份，概念类似 GCP IAM 里的 principal。控制台给该身份分配 grants，Iron Proxy 只会为获得授权的请求使用对应凭据。大部分真实世界的凭据并不是静态密钥，尤其是 OAuth：它们需要刷新、轮换、撤销。现场多少人使用 Claude 订阅账户，而不是纯 API？看来几乎所有人。这里有个细节：Centaur 支持在 thread 里使用 Claude 订阅，但相关 refresh token 的处理很麻烦。
如果多个终端争用同一个订阅的 refresh token，Claude 在某些刷新路径下会让由旧 token 派生的其他凭据失效。结果 Centaur 的线程和本地 CLI 可能一起被踢下线。对数百个用户处理这种刷新、同步、轮换问题，是我们凭据组件必须解决的复杂性。实际业务还有更特殊的凭据场景。例如我们很早就做了 Postgres DSN 代理；Postgres 的 wire protocol 很复杂，但通过代理，我们可以把数据库连接锁定到指定角色，进而强制执行 RLS（行级安全）或其他权限限制。
这样 Agent 就能安全地访问数据库，既可以调试，也可以处理 Paradigm 的实际数据任务。我们可以提供只读连接，确保代理授权下的 Agent 只能看到允许它看见的那些数据。更复杂的云服务认证还涉及 HMAC、GCP Signature V4 等机制（具体术语依原稿），都要在代理里正确处理。把它和自主权联系起来：如果你使用封闭的 Agent 产品，换平台往往意味着丢失全部已连接的凭据。假如让 Paradigm 约 60 名员工每次换 harness 都重新连接 OAuth 服务，这套系统实际就不可迁移。
我们希望所有授权机制由自己管理，做到模型和 harness 变化时凭据仍可持续使用。最后一个话题是公司上下文。大家对它的理解也许没有那么直观。我的意思是识别组织正在使用的工具，比如 Google Drive、Gmail、Granola、Slack 等，从它们那里收集数据，再存到自己可控制的数据库中。
架构如图：左边是不同数据源，后台用持久工作流持续建立索引，把内容灌进 Postgres；中间提供一个混合搜索 API，利用行级安全控制不同 Agent 身份的访问范围；右边 harness 拥有“搜索公司上下文”的工具，通过 Iron Proxy 加上相应身份权限。控制台仍然负责定义 principal 与 grants。这为什么重要？首先，很多平台其实很不乐意让你把数据导出来。
例如 Slack 对每个用户 token 的搜索请求有速率限制，还会被整个组织的 API key 限额进一步约束。组织级大规模搜索很难直接在 Slack API 上实现，除非你把数据复制到自己的 context store，或者干脆被迫使用 Slack 自家的 AI。把信息拉进自己的系统，你就不再受第三方 API 搜索能力的直接限制。更积极的价值是：你能跨所有数据源执行统一的相似度搜索，而不是让 Agent 先搜 Slack，再搜 Google Drive，再把结果手工拼起来。
例如你可以让 Agent 按某些条件寻找合同：它能在 Google Drive 找到合同，再从 Slack 找到相关讨论，因为向量搜索可以通过语义相似性关联文档，不要求关键词完全相同。我们还用 ParadeDB 做关键词检索，因此也能高效处理精确搜索。最终，一条查询就能横跨组织的各种来源。Centaur 的这一块还在做 v2，准备让查询通过更完整的 API，而不只依赖 RLS，目标是更快索引更多内容。
接下来顺便谈谈记忆。只要你拥有公司的 context store，记忆就只是另一类上下文：用定时工作流读取当天发生的事，不只是 Slack thread，还包括所有人的会议、Google Docs 等，总结经验，再把这些摘要写回同一个上下文数据库。Agent 收到新请求时，先搜索相关的“公司记忆”，就自然具备了持续记忆能力。这就是大家所说的 dreaming（做梦）：后台任务从每天的活动或 Agent traces 中提炼知识。
正因为这样，我们没有强制规定 Centaur 应当采用哪一种具体记忆方案，用户可以很方便地自行组装。最后讲几个因为拥有全栈控制权才做得出来的功能。第一是 trace analysis：我们能分析员工到底在用 Centaur 做什么、在哪里卡住、哪些功能应该改进。这里说“我们”，其实目前负责这个项目的开发者主要还是我一个人。第二是自定义模型路由：让一个决策模型判断每项任务适合交给哪种模型，再把请求路由过去，而不总用 harness 的默认配置。
第三是前面讲的 dreaming：今天的经验被 Agent 总结后，供明天的任务使用。第四是刚开始试验的 autotune：利用我们自己掌握的 traces 去微调开源模型，逐步把更多任务迁到自主训练的模型上。毕竟终极自主权就是不必为每次访问 LLM 都向 OpenAI 或 Anthropic 付费，而是在自己的环境里运行模型。Centaur 的好处是，即使使用这些供应商的模型，也可以借助零数据保留（ZDR）等约束控制数据；但最强的隐私保护当然还是运行自己控制的模型。
Centaur 的核心就是让你更好地利用已经拥有的智能与组织上下文。想试用的话，访问 centaur.run，让你的 Agent 去研究它。我们也在招人，欢迎优秀的产品和基础设施工程师联系我。谢谢大家！
项目很棒。为什么决定从零开始构建 Centaur，而不是基于 OpenClaw 或 Hermes 之类已经开源的 Agent 项目？显然有不少功能重叠。 Matthew： 我认为它们想解决的是根本不同的问题。OpenClaw、Hermes 更像长生命周期的个人 Agent，自身维护很多状态。我很喜欢它们，也在家里用 Hermes 作为个人 Agent，但对企业场景，它们不是最合适的架构。我们其实支持 Hermes 作为 Centaur 的一个 harness。
有些通过 Marketplace 分发的应用，接口限额甚至只有每分钟一次请求。这基本上让持续建立数据索引变得不可能。
闪电演讲开场
我觉得 Centaur 是目前最令人兴奋的方向之一。最后是闪电演讲，每人约五到七分钟。上台的都是我们喜欢合作、过去也一起做过项目的朋友。
Robert Chen / OtterSec｜EVM Bench：评测 AI Agent 的漏洞能力
先从 OtterSec 的 Robert Chen 开始，掌声欢迎！
我们也是 Iron Proxy 的忠实用户。今天我来谈基准测试，这跟沙箱很相关——现在对 Agent 做安全测试，沙箱已经非常重要了。我们做的项目叫 EVM Bench，目标是评估 AI Agent 发现区块链漏洞的能力。先交代背景：这是 OpenAI 和 Paradigm 合作的大型项目，研究论文在今年早些时候已经发表。OtterSec 负责其中一部分数据收集，并不是我们单独做的。特别感谢 Paradigm 的 Justin、Alpen，还有 OpenAI 的另一位 Justin 和 Olivia，以及其他没来现场的参与者。经常有人问我，为什么要关心区块链？安全研究圈有些朋友天然对这个领域抱有怀疑。
第一个理由不算最有说服力，但确实有大量真金白银面临风险。这张图统计了累计被盗资产，截至 2026 年，相关损失或暴露金额已超过 200 亿美元。区块链资产流动很透明，也非常金融化，攻击者有机会直接转移巨额资金。从研究角度看，更有趣的是：区块链其实是一种非常有价值的真实世界安全研究环境。
一般网络安全研究很难在真实环境里复现攻击。你不可能把银行整个企业基础设施完整复制到本地，也不容易知道现实世界什么时候被入侵、到底发生了什么。区块链却有一些重要特性解决了这个问题。第一是成功信号很明确。以 2022 年 Wormhole 攻击为例，你可以直接查链上资产，看到一笔价值约 1.47 亿美元的资金如何流转。这类金额和状态变化是所有人都能观察到的。如果银行系统遭到攻击，外界可能很难知道；但链上钱不见了，大家马上就能看到。
第二是区块链拥有高度确定、可重放的状态。你可以把相关状态在本地准确复现。
这就引出了基准测试：如何定义漏洞并测量 Agent 的能力？我们先收集一系列真实漏洞和脆弱合约案例，例如预言机价格操纵等，然后对它们分类整理。原稿中几个具体漏洞类别的介绍没有完整听写。
EVM Bench 设置三个模式。第一是 Detect：给出代码库，Agent 能不能识别漏洞？第二是 Patch：存在漏洞时能不能修好，同时不破坏其他功能？第三可能最有意思——Exploit：因为可以把链上状态完整复制到本地，我们能要求 Agent 实际执行一次端到端的攻击操作，并用本地测试资金验证它有没有成功。这里 Agent 真的会在模拟环境里把资金转出来。结果可能让人意外：至少在我们这批稍早的评测中，Agent 的利用漏洞能力显著优于漏洞检测与修补能力。直觉上的解释是，攻击有非常明确的反馈信号，Agent 可以不断试错：资金到手，就知道自己成功了。
这意味着什么？AI 能力飞速提升当然是一个结论，但到今天这已经很明显了。更有价值的结论是：区块链是评估 AI Agent 的极佳实验底座。 现实安全事件通常很难观察、很难复现，链上的确定性状态与可核验结果却能帮助我们研究 Agent 在真实环境中可能做到什么。这对安全领域尤其有意义，对其他研究方向也可能适用。谢谢！
谢谢！闪电演讲没有时间安排问答，请大家会后直接找讲者交流。
Jake Fitzgerald｜Text to CAD：让 Agent 设计实体硬件
我是 Jake，Text to CAD 的开发者。这是一个让 Agent 设计实体产品的开源项目，大约六个月前发布，今天早上已经有 2 万颗 GitHub Star。
下载量大约 50 万，使用者主要是我称之为“硬件黑客”的社区成员，很多人用它做 3D 打印。
也有人通过 SendCutSend 做钣金切割，制作各种有意思的个人项目。我本人是软件工程师，没有专业硬件工作背景；之前在 WhatsApp 做工程师，也是加密期权交易所 Derive 的联合创始人，但大学学过机电一体化，所以最近想重新学习机器人。我给自己定了一个天真的目标：做一支低成本机械臂。如果你了解 SO101，那是一种非常便宜的开源 3D 打印机械臂，可用于训练机器人策略。我想挑战自己，用钣金做一支六自由度机械臂。结果一开始就被 CAD 软件难住了。我上一次用 CAD 已经是十年前，Onshape 很棒，但在二维屏幕上设计三维模型本身就很难。
我实在搞不明白，于是向 Claude 和 Codex 求助，最后靠 Vibe Coding 把机械臂的钣金零件全部设计了出来，实物现在已接近最终版。Text to CAD 仓库到底是什么？它首先是一组 Skill，包装了开源 CAD 内核和特征脚本语言，编写代码生成三维模型；其次有一个 MCP App，这可能是最重要的部分，允许你在界面里查看和编辑 CAD 文件。我主要使用两种编辑方式。第一是直接点选 STEP 文件的某个面或边，在提示词中引用它，比如“这个孔太小，扩大两倍”。
第二种是绘图。我用开源的 Excalidraw 在模型截图上画线、做标记，把图片发进提示词。结合这两种交互方式，效果很好。CAD Agent 的循环是：先写生成 2D/3D 模型的代码，保存在磁盘中以便下次修改；接着对模型拍快照，让 Agent 检查是否符合要求，必要时再做尺寸和几何验证。截图是反馈循环的核心。但这个流程仍然不够可靠。六个月前尤其糟糕，模型虽然已经很会做其他事情，但对 CAD 还是很不擅长。
如果提示词不清楚，或者模型根本不理解一个钣金支架应该长什么样，错误会不断累积。我曾把机械臂需求扔给模型，让它跑两小时，结果做出一件荒唐的怪物。导出文件还经常出现幻觉：送去 SendCutSend 切割后，孔会被拉伸、弯曲补偿和 K-factor 没算进去。早期真的很难。可另一边，同一个时期的模型却能在两三天内用一个提示词生成极漂亮的 16 缸发动机概念图；当你要求它从零设计六自由度机械臂时，又会产出一个看起来很真实、实际结构非常荒谬的模型。
原因大概不难理解：网上有大量 W16 发动机图片和示意图，模型看过类似东西；但新结构的支架、细小缺陷和非常规几何，就很难从这些快照中看明白。后来 Astra 是一个重大转折。经过多轮模型对比，这似乎是我第一次看到模型能够完成很复杂的 CAD 工作。例如一个肌腱驱动机械手模型，它可以在长时间执行后一次生成成功。
这是机械臂设计里真实用到的案例。机械臂之前振动很厉害，模型主动使用有限元分析（FEA）研究振动，建议在一个位置增加加固环。它还在我没有要求的情况下，画出了能量密度的热力图，解释加固环怎样缓解应力。我采纳了这个设计，这也是模型第一次真正提出被我用于实体产品的工程建议。Text to CAD 不止 CAD 建模，还能对接 SendCutSend 做可制造性设计检查（DFM），处理机器人的路径规划和逆运动学。有一次我急着做一个相机支架，人正在健身房，就用手机提示 Text to CAD 设计支架，并直接向 3D 打印机发送打印任务。
等我从健身房回到工位，支架已经打印好、躺在打印平台上了。那种感觉很超现实。还有两个副产品也很棒。第一，STEP 这种 3D 文件通常很大，把模型表达成代码，文件就小得多，而且可以直接用 Git 做版本管理，不必依赖 SolidWorks 等工具那种笨重的版本控制。第二，可以把设计要求编成可检查的流水线。例如把机械臂的运动学分析直接关联到结构参数：如果我缩小肩关节活动范围，会产生多少不可达区域？
这些约束甚至可以写成单元测试，告诉你某个设计修改违反了要求。最后分享几个比较激进的预测。第一，硬件设计未来会更像 Midjourney：输入需求后，不只生成一个结果，而是一批结果。因为硬件设计带有主观判断，可能有上百个 Agent 同时给出方案，先帮你完成 95%，最后 5% 留给人类发挥审美、判断并反复调整。第二个观点是“万物皆代码”。
我相信不只是 CAD，图片和视频生成也可能越来越多地通过代码或可编程表达来实现，而不是完全依赖专门的生成模型。理由是：代码具有高效可编辑性；要修改一个细节，直接改代码通常比反复重新提示图片或视频模型有效。第三个观点是隐式几何可能成为 Agent 的原生三维语言。目前主流 CAD 多采用显式表达，定义模型每个面、顶点、网格，STEP 和 Mesh 文件大致都是这样。隐式 CAD 则通过有符号距离函数（SDF）等数学表达式描述三维物体，结构往往更紧凑。
隐式表示对 Agent 来说可能更自然，只是对人类不直观、难以直接编辑，因此过去不那么流行。但它也许会成为未来 Agent 做 3D 建模的主要语言。如今 Text to CAD 已经帮助很多爱好者降低了进入硬件设计的门槛，像我这种软件背景的人也能亲手造东西。这里就是我的真实机械臂照片。欢迎大家体验并反馈。 主持人： 我几周前和 Jake 一起看过那支机械臂，确实是真的，不是在卖概念，真的能工作！
Andrew Luo / Extend｜ExtendUI：面向文档工作流的开源界面
下一位是 Extend 的 Andrew。Andrew？好，欢迎。
大家好，我叫 Andrew，是 Extend 的工程师。Extend 提供文档处理平台与 API。我想介绍几个月前做的一个项目 ExtendUI，它是一组开源组件，帮助开发者把文档界面嵌入自己的项目。
例如 PDF 阅读器、Microsoft Office 的 Word、Excel 查看和编辑器，以及为这些文件工作流服务的 UI：边界框、引用标注、电子签名等。开发它有两个原因：客户想把我们 API 返回的数据重新嵌进自己系统中的“人工复核”流程；另外，我们产品自身的文档阅读器也需要更贴合品牌设计。可市面上一些 SDK 既昂贵又难用，有的光是文档查看器就要上千美元，效果还不理想。于是我先做了一个 Word 编辑器，发布到 npm 上叫 React DocX。它使用 Rust 解析文档 XML，再编译为 WebAssembly。
解析工作在浏览器的 Web Worker 里完成，避免载入大文件时卡住 UI。测试方法也是 Agent 反馈循环：我找来一批互联网上的 docx 文档，让 Agent 不断比较它们在 Word 和网页中的显示结果，再调整渲染实现。最近我还在研究一种叫 REA（Reverse Engineer Anything）的库，用来更深入地理解版式引擎，从而支持文档块的 bounding box。我也使用 Pretext 来实现图文混排、表格周围的文字换行；如果没有布局引擎，这种 Word 原生效果很难正确复制。
第二个项目是 Excel 查看／编辑器 ReactXLSX。最初一位工程师发现 SheetJS 在处理大型 Excel 时会阻塞 Node.js 的事件循环，因此她写了一个自定义 Rust 解析器来读取超大工作簿，我再整合一些渲染图表和图片的库，做成这个界面。应用场景很多：如果你的 Agent 生成了 PDF 或 Word 文件，可以用这些组件展示文档、标出引用和边界框；如果 Agent 有一个文件系统，也能用这些组件构建面向人的文件浏览界面。最近我还在实验一种不使用向量数据库的 RAG 方案。
项目叫 Jeffbox，是一个会自己整理文件的网盘。上传文档后，它让一个决策模型判断应放进现有哪个文件夹，还是应该建立新文件夹；查询时再让决策模型遍历文件夹树，寻找相关段落，然后重排序、打分，把证据交给 Agent 或搜索结果。它的对话界面、文档库和一种三维文件系统视图，很多都建立在 ExtendUI 组件之上。希望能带给大家一点新想法，谢谢！
谢谢 Andrew！
Avi Dessauer / Turnkey｜TEE 的可验证有状态存储
下一位是 Turnkey 的 Avi，谈可信执行环境 TEE。 Avi Dessauer： 大家好，我叫 Avi，今天谈谈怎样在 TEE 中运行有状态的应用。
（原稿此处只有零碎音频和一句未完成的话，具体内容缺失。）
先简单介绍 Turnkey。
Turnkey 有不少产品，主要两类：可验证的非托管钱包，以及把构建这类钱包的底层组件作为 Turnkey Verifiable Cloud 出售，让客户构建自己的非托管应用。非托管性依赖 TEE。你可以把 TEE 想成 CPU 中一个受保护的执行区域，也可能涵盖大量 CPU、RAM，甚至某些 GPU。但它没有可信的磁盘。如果你必须信任内部员工或主机 VM，实际上就已经破坏了非托管的信任假设。你应该只需要信任自己的小段代码、经硬件远程证明的运行环境，以及受其保护的内存。那么，如果不能信任磁盘，怎样做有状态应用？直觉上你可能使用 Linux LUKS 磁盘加密，再加 AES-GCM 保证完整性。
AI 公司提供机密计算服务时经常采用类似方案，这当然是很重要的一步。但它并不保证完整的密码学正确性：LUKS、AES-GCM 不提供整个磁盘的端到端完整性保证，也不提供回滚防护。攻击者可能替换磁盘的某个块，或者直接把整个磁盘换成旧版本，而你的可信执行环境还不一定察觉。怎么办？Turnkey 的钱包基础设施里，我们自己实现了 Merkle Store，还实现了防回滚机制。很遗憾，今天使用 TEE 的许多团队都必须重新造类似的轮子。除了我这种喜欢造它的人，大部分人肯定不想碰，而且这类实现容易出错，性能也常常不好。我们真正需要的性质是什么？第一是正确性：读取磁盘时，必须看到磁盘整体的最新有效版本。
第二是 freshness（新鲜性）：Enclave 宕机后重新启动，也必须获得最新的有效状态，不能被回滚到旧版本。第三是阻止这种攻击；某些应用还要求隐私保密，而 LUKS 在加密保密性方面本来就做得很好。要实现这些目标，需要一个可验证文件系统，因为 Linux 应用都是在文件系统上运行的。我做的东西具体位于可验证块设备层：实现一个 UBLK 用户态块设备驱动，让上层看到的就是一块普通硬盘或 NVMe。
验证器采用了 Commonware 很棒的 QMDB 库作为基础，不过做了大量修改。另一侧的 prover 必须提供 Merkle 证明和状态转换证明，说明磁盘如何从一个 Merkle root 合法转到另一个 root；它还负责真正保存数据。我们采用 WAL 加 S3 的存储架构，因为现在很流行，而且确实适合这个问题。UBLK 驱动在可信边界内校验所有证明，让任何不可信内容都不能直接进入 Linux 文件系统或应用。锚定状态、防止回滚也在这个驱动层处理，用户无需再反复实现。
听起来不错，但会不会很慢？起初确实慢得痛苦。即使用 QMDB 这种很快的 Merkle 存储，在 4KB 块大小下初始吞吐也只有约 10MB/s。后来我对整个过程做了流水线化，达到约 400MB/s，还没有继续深度优化。它将帮助我们在 TEE 里运行真正有状态的应用，尤其是我最期待的 Postgres；此外还包括 Agent 身份、账本、完整节点，以及对每一个 RPC 响应都能在 TEE 内部做端到端证明的可验证 RPC。谢谢！
Brendan Ryan / Tempo｜Mercator：Agent 付费工具的发现与执行
最后一位来自 Tempo 的 Brendan Ryan，谈机器支付。我们在这个方向合作了一年，我觉得这很可能是解锁 Agent 下一阶段能力的重要基础。交给你了。 Brendan： 今天介绍 Mercator：一种面向 Agent 支付的、基于意图的服务发现系统。它建立在 Tempo、Stripe 和加密社区过去近一年关于 Agent 支付的工作之上。大家记得刚才 Matt 的 Centaur 演讲：Agent 现在执行的任务越来越开放。不再是把每一步写成巨大的计划文件再交给 Claude，而是给它一个开放目标，期待它自行搜索网络、寻找工具并推进任务。
这种模式让我们可以同时运行大量 Agent，而不用人一直盯着。但是它有个问题：通常要提前知道可能使用哪些工具。互联网本来就是开放的，为什么工具不能像网站一样被动态发现？我们很看好 MPP（Machine Payments Protocol）以及加密社区的 x402 之类支付协议，因为它们支持即时发现、即时使用。协议统一服务发现，像互联网一样可以在上面建立搜索索引、PageRank，并在需要的时刻购买服务。几个月前，我们发现一个重要拐点：MPP 和 x402 的服务已经多到足够支撑真正的使用案例，两类端点加起来大约 3 万个。
当然这个数字略有滞后。服务数量上来之后，问题也暴露了：质量参差不齐，有些是黑客松作品，有些托管在很差的基础设施上，或者依赖过时的库，错误频发。还有控制权倒置问题。假设我想通过 MPP 调用 Parallel 的搜索服务，今天可能需要明确告诉 Agent“我想用 Parallel，但没有账号，用 MPP 支付”。这当然很方便，可是你必须提前知道 Parallel 这个名字。为什么不能只说“帮我找最好的网页搜索服务，然后用它”？另外退款、争议处理等复杂度也被推给了客户端。加密系统的使用门槛本来就不低。
因此我们构建了 Mercator：一个统一接口，让 Agent 与开放网络中的 30,000 多个付费工具交互。我们把它理解成“付费互联网工具的 PageRank”。你只需要发出一般性的需求，比如“找出气候科技领域正在融资的 A 轮公司”，Mercator 就把需求拆成意图、搜索和排名，在可用工具中挑选合适服务，再执行持久化工作流去调用它们。
我在 Tempo 工作，我们很喜欢 Tempo 的基础原语，所以还提出一个挑战：能不能把整个方案都构建在 Tempo 上？我们做到了很多有意思的设计细节，准备在接下来几周发技术博客。Mercator 底层其实是一个 MCP 服务。新版 MCP 已经更成熟，并支持 OAuth 等机制。我们把 OAuth 访问和 Tempo access key 绑定，后台使用 Privy 钱包，再加入一个基于 Tempo 的持久化工作流执行引擎和支出策略。你可以像给 OpenRouter API key 设置每小时最多花 10 美元一样，对 Tempo 上的 Agent 付款设定花费上限，而且实现可以开源。
再深入看看搜索流程。输入一般查询后，系统执行多阶段、并发的融合流水线：词法搜索、传统相关性技术、对查询向量化后的语义搜索，再进行融合、排序与过滤。几周前一个叫 Jev 的类型安全 AI 项目出现（名称依英文听写，需核实），我们将它作为最后一道流水线步骤加入，在部分查询中得到约 20% 的提升。真正难的部分还有怎样建立初始搜索索引、怎样持续优化。为此，我们做了大量基准测试与逐步爬坡调优。
我们先收集真实使用需求，例如 Georgios 和 Tempo 团队不断向系统扔来自己想做的查询，再开发了庞大的搜索测试 harness。后台让 Agent 持续微调搜索索引和参数，不断提升准确率、召回率与工具覆盖数。也会合成高质量查询来扩充数据。内部仪表盘让我们看着一群 Agent 不断改进系统。我们还想知道，把 Mercator 交给已有 Agent harness，比如 Codex，究竟能提升多少实际工作能力。于是建立了两套大规模评测，并使用 Harbor 等评测框架来跑各类前沿 Agent 基准，持续验证 Mercator 是否真正带来生产力提升。
这就是 Mercator。会后我还会在现场，欢迎大家来交流。我们把 Mercator 看作 Agent 新增的一档“努力程度”：当 Agent 撞上一堵靠自己无法跨过的墙时，可以直接付费购买一个服务，然后继续前进。
结束与黑客松提交提醒
今天的演讲到此结束。午餐在外面。下午继续黑客松，大约到四点；作品提交截止时间是下午三点。Airtable 链接已经发在 Signal 群里，请大家现在就提交，否则可能没机会展示。我们五点前必须离开大楼，否则场地方会很不高兴。外面还有一些放松交流时间。谢谢大家，继续动手吧！