声明： 本文内容基于作者与 Jeff Dean 的真实对话整理，稿件经 Jeff Dean 本人审阅并授权发布，转载请注明出处。

过去我们追求五个九 (99.999%) 的高可用性，建立在一个不可动摇的前提上：代码的逻辑是确定的。但现在，当越来越多代码由 Agent 生成，系统底层的基本执行单元 (Building Block) 本身变成了概率性的。

那 Infra 这层到底要怎么适配和重构？

最近和 Google DeepMind 首席科学家 Jeff Dean 探讨这个话题时，我们得出了一致的判断：Agent 对 Infra 最深的冲击，是引入了一种全新的执行语义。

Jeff 是 TensorFlow、MapReduce、TPU 背后的核心作者和领导者。对一个长期做 Infra 的人来说，能和这样一位塑造了上一代计算范式的传奇讨论下一代 Infra 系统该如何承载 Agent，本身就是件很有意思的事。

当系统的基本执行单元不再是确定的

我最近跟一些头部科技公司和前沿 AI Lab 交流：AI 生成代码的体量，正在快速逼近，甚至已经超过人类直接编写的代码量。有些团队已经在用一个模型 review 另一个模型写的代码，测试也越来越多交给 Agent。

这让我下意识感觉到整个系统会变得极不可控。Jeff 的原话也是："It can work, but it makes me a little uncomfortable."

经历过 Cloudflare 和 Kong 的超大规模工程实践后，我对系统边界形成了一种近乎肌肉记忆的敬畏。在那些承载核心业务的系统里，高可用从来不是靠运气，而是靠极其严苛的变更铁律和确定性的回滚机制堆叠出来的。

因为线上真的出事时，坏掉的通常是那些大家平时懒得细想的边界条件、跨系统接口和默认前提。也正因为踩过太多这种坑，我会坚决地认为：只要一个系统里存在不可见的中间状态、不可审计的副作用，或者语义含糊的 retry，我就默认它迟早会出事，区别只是时间问题。

当执行者本身开始变成概率性的，很多过去默认成立的基础设施假设将会受到严峻挑战。当越来越多代码由 Agent 生成、越来越多流程由 Agent 执行时，我们要靠什么来保证系统仍然可控？

Agent 时代的可靠性，可能要靠更重的手段来换

如果执行单元本身不再稳定，那高可靠性的设计可能就不能沿用人类写代码时代那套默认取舍了，很多地方甚至得用更重、更笨、但更稳的办法。

一种解法是，让独立的模型把同一个算法写两遍再做投票，或者同时跑三个副本。这当然是一种 heavy hammer（重锤），但在生成质量还不够稳定的时候，这种笨办法可能反而最现实。长期看，工程师的重心大概率会继续上移，不再执着于手写每一行代码，而是更多去设计约束、校验和编排，把具体实现交给 Agent 去完成。

今天，当代码的生成和执行都开始带有概率性时，可靠性将越来越依赖于冗余、约束、隔离和可恢复性。

未来高可靠系统可能在很多地方变得更重、更保守。

AI 让生成代码变得言出法随，却让执行的边界变得异常模糊。它没有减轻基础设施的责任，而是把更多责任重新压回了 Infra 执行层。

计算图 (Computation Graph) 和可恢复性 (Resumability)

当模型真正进入系统内部，而不是只在边上做一次性 API 调用时，整个 Infra 系统的形态就会发生改变。它不再是一个主程序调一个模型，而是多个子模型、多个工具、多个判断节点拼出来的执行网络。里面会有 speculative execution、有筛选、有分支、有回退，最后越来越像一张真正的 computation graph。

这种 Infra 系统追求的目标和过去一致，还是那几个老问题：延迟、可靠性、扩展性、成本。这也是为什么我会觉得它和上一代大规模系统之间并不是完全割裂，而是换了执行单元之后，很多老问题以新形式重新出现。

但底层约束已经不一样了。传统 Infra 系统里，让一台机器吃很多任务、必要时做 shed 或 replication，是很自然的设计。AI workload 不一样，一次推理可能就要绑住几十张紧耦合芯片，attention state 又大，上下文切换和跨节点调度都很贵。所以不是老原则错了，而是它依赖的物理前提已经变了。

ML 研究者普遍喜欢同步训练：整个系统执行完一步，所有行为对齐，再进下一步。Jeff 认为，他们真正想要的其实不是同步本身，而是 Reproducibility（可重现性）。同步只是为了换来可重现的一种很贵的办法。这个点跟我一直在想的 Resumability（可恢复性）原语很接近，因为两者本质上都在解决同一件事：系统能不能回到一个有定义的状态，再继续往前走。

他的依据，是 Google Brain 训练系统演进的经验：从早期 messy 但能 scale 的异步训练，到后来为了可重现性转向同步架构，核心都不是去记录 packet 级别的网络状态，而是记录 ML 计算层面的因果顺序。比如哪些节点参与了同一次 all-reduce、步调如何对齐。这类状态量不大，却足以帮助系统回到一个可定义的计算状态。

这对 Agent 系统是直接相关的。一个任务跑了八个小时，如果在第八个小时出错，你能不能回到前一个 checkpoint？能不能从那里分叉出去试另一条路？能不能在人类介入、调整约束之后再继续跑？

Jeff 的长期直觉，是希望从硬件层重新定义这套系统约束。但我认为，至少在今天，Agent 最紧迫的很多问题其实并不需要等下一代硬件才能动手解决，Infra 这一层已经有很大的发挥空间。

现有 Agent Stack 缺少统一的恢复模型

主流 Agent stack 到今天为止，很多仍然像是在把过去 Infra 里的局部经验拼接起来：workflow engine 加一点 memory，tool calling 加一点 retry，checkpoint 加一点 snapshot，然后希望它能拼凑出一个可靠的 Agent runtime。

问题在于，把 Agent 当成更复杂的 request handler，或者带一点随机性的脚本引擎，都会走偏。因为它不是一次性调用的包装层，而是一个会持续运行、持续形成判断、持续改写外部世界的执行体。一旦失败，简单的进程重启肯定是不够用的，它需要的是语义级的恢复。

继续沿用确定性程序时代的默认抽象，很明显已经不够了。只不过到现在，这套东西最终会更像数据库里的事务语义、分布式系统里的工作流恢复，还是需要定义一种新的 runtime abstraction，行业里其实还没有形成定论。

如果还把那些围绕确定性程序建立起来的设计取舍，原封不动套到 Agent 身上，最后做出来的东西大概率只能跑 demo，离真正托住生产系统还差得很远。

语义化工作区 (Scratch Space)

想象一个工程师在处理复杂问题。他同时开着几十个浏览器标签页，记了一堆笔记，还画了一张架构草图。到了晚上准备下班，第二天再继续。这时候他真正需要保留下来的是那张草图和那些关键笔记，以及已经形成的中间判断和结果。

很多东西丢了都还能补，页面可以重新搜，日志可以再抓，临时结果可以再跑一遍。真正缺失的，是那个任务跑到一半时已经形成但还没固化下来的判断：它为什么排除了前两条路，接下来准备试什么，哪些约束已经被它确认过。

一个长时间运行的 Agent 会积累大量状态。有些是它主动形成的关键判断，有些只是执行过程里的临时数据。如果你只是用 VM Paging 或者进程快照的方式把所有内存一股脑存下来，表面上像是什么都保住了，实际上既低效浪费资源，又缺乏语义。因为你根本不知道哪些状态真正值得保留，哪些只是过程噪声。

我觉得更好的方向是一个类似 KV Store 的语义化工作区。它的价值不只是轻量，更重要的是它天然带语义：每一个 Key 都是 Agent 主动写进去的，代表它认为重要的状态；Value 则随着任务推进被不断更新。

这样做 Checkpoint 时，留下来的就是一个有意义的 working set，而不是整块内存的无差别转储。背后其实是一个很朴素的系统原则：只保存 Root State（根状态），Derived State （派生状态）能重算的就不要硬存。

系统得明确区分哪些是 Root State，哪些操作产生了副作用，哪些只是纯计算，即使丢了也能安全重建。容器和 VM 这套抽象很擅长做资源隔离，但它们并不知道哪些状态重要、哪些写入有语义后果。

无限上下文真有那么关键吗？其实缺的是可重入的状态模型

今天大家都在谈长上下文。几百万 token，甚至更大的 context window，当然都有它的价值。

但从系统设计的角度看，真正稀缺的不是更大的窗口，而是能不能把不同类型的信息分层组织好：哪些值得沉淀，哪些按需再查，哪些中间结论应该跨阶段保留，哪些只是过程噪声。

如果系统分不清这些，context 再大也没用。

所以我现在越来越少把 memory 理解成一个无限扩张的 context window，而更愿意把它看成一个可重入的状态模型。它应该支持恢复、分叉和续跑，也应该清楚地区分哪些判断已经沉淀下来，哪些只是过程里的临时痕迹。这样看，memory 的核心就不是存得多少，而是状态组织得对不对。

传统 SaaS 软件的可靠性建立在确定性执行和单元测试上，状态靠内存快照保存，Infra 的核心工作是资源虚拟化。而 Agent 原生软件的执行单元本身就是概率性的，可靠性要靠冗余和约束来兜，状态变成了语义化的工作集。

抛弃简单沙盒：我们需要真正的语义级恢复

传统的 VM 和 Container 擅长隔离资源，但它们根本不了解 Agent 的执行进度，也不理解状态的意义和副作用边界。Agent 原生软件需要的，是一个能把状态、副作用和执行意图放进同一个恢复模型里的全新 Runtime。

这正是我们当下最紧迫的系统工程问题，也是我们动手构建 Runta 的直接原因：简单的沙盒隔离已经远远不够，缺乏是真正在底层提供 Agent 时代缺失的语义级恢复，以及执行层的虚拟化能力。

如果说上一次 Infra 的代际变化，核心是把资源虚拟化出来，让开发者不用再关心物理机在哪里，那么这一次更值得被虚拟化的，可能是执行本身，也就是把恢复、隔离、分叉、续跑这些复杂性压到 runtime 下面。

执行层 Infra 正在重新变成系统工程里最核心的问题。

而今天，我们连一个长时间运行、带真实权限、已经产生外部副作用的 Agent，在跑崩之后到底应该如何恢复，都还没有形成广泛共识。只要这一点没解决，很多看起来已经能跑的 Agent system，本质上都还只是 demo。