AI 原生工程栈，正在从“模型中心”转向“执行系统中心”

AI 原生工程栈，正在从“模型中心”转向“执行系统中心”

当代码生成越来越便宜，新的主战场就不再只是“谁写代码更快”，而会转向“谁能设计出一个让 Agent 持续、可靠、可恢复地执行的系统”。

1. 引子：为什么 2026 年最重要的工程问题，已经不是代码生成

过去两年，AI 工程最显眼的变化来自模型：更会写代码、更会调工具、更像能干活的同事。但把视角再往前推一步，真正被重写的往往不是“模型能不能做”，而是系统如何承接一个会长时间运行、会触碰外部世界、会失败、会产生副作用的执行过程。4

OpenAI 的 Harness engineering 给了一个非常强的信号：当 Codex 能持续产出大量代码后，团队最稀缺的资源很快就不再是“继续写更多代码”，而是环境清晰度、验证吞吐、可观测性和合并流程。4 也就是说，生成能力一旦足够强，工程瓶颈会自然暴露到别处。

这篇文章想说的其实只有一句：

AI 原生工程栈，正在从“模型中心”转向“执行系统中心”。

这里的“转向”不是说模型突然不重要了，而是说一旦工作流开始变长、开始触碰外部系统、开始需要恢复、验证和多实例接手，真正拉开差距的就会越来越不是“谁能多生成一点代码”，而是“谁能更稳定地承接 Agent 生成并执行的结果”。1 4 6

2. 什么叫“从模型中心转向执行系统中心”

过去很多工程系统优化的是“模型如何给出一个更好的答案”。这是一种典型的“模型中心”视角：更强的推理、更好的工具调用、更快的代码生成、更长的上下文。它当然重要，但它默认系统面对的对象主要还是一次次请求和一次次回答。

而“执行系统中心”的视角面对的不是答案，而是过程。它关心的是：状态放在哪里、失败后从哪里继续、哪些副作用已经发生、哪些实例可以接手、日志和验证是否足够自动化。

如果把两者压缩成一张对照表，大概是这样：

  • 模型中心：答案质量、工具调用、代码生成、响应表现
  • 执行系统中心：状态、恢复、副作用、边界、验证、观测

所以我对“AI 原生工程”的定义是：

AI 原生工程，不是给传统软件工程流程加一个 Copilot 或 Agent；而是从系统设计一开始，就把 Agent 视为一等执行者和一等读者，据此重构代码组织、知识管理、执行语义、状态持久化、sandbox 边界、可观测性和验证流程的一套工程方法。

这里最关键的是两个“一等公民”。第一，Agent 是一等执行者：它会读仓库、改代码、跑测试、调工具、等待反馈，再继续决策。第二，Agent 是一等读者：代码、文档、日志、指标和运行时状态不再只给人看，也必须能被 Agent 直接消费。4

3. 为什么这个迁移偏偏发生在现在

这个迁移不是一句抽象趋势判断，而是几条演化线叠在一起后的结果。

第一条线，是代码生成开始变便宜。OpenAI 展示的不是“模型多会写代码”，而是当代码吞吐上来后，系统的短板迅速从生成切到 QA、环境规范和反馈回路。4

第二条线，是工作流变长了。模型不再只是在一个 prompt 里“想一想再回答”，而是开始读取仓库、调浏览器、调用工具、等待 API 结果、处理失败、接受人类确认，再继续推进。这时系统面对的对象已经不再像一次请求，而更像一个长期任务。

第三条线，是 RL 和 Agent 把“执行问题”显性化了。OpenRLHF 等工作已经明确指出，后训练里的 rollout / inference 会成为主要运行时瓶颈；而 Justin Lin 在《From “Reasoning” Thinking to “Agentic” Thinking》里进一步把这个变化说得很清楚：接下来的主线不再只是“模型能不能想更久”，而是“模型能不能在与环境交互时持续推进，并根据世界反馈更新计划”。2 14

这也是我觉得这轮迁移特别关键的地方。过去我们讨论 reasoning，核心问题常常还是“想得够不够长”；一旦进入 agentic thinking，核心问题就变成了“这种思考能不能支撑有效行动”。而只要问题切到“行动”，系统就必须开始回答状态、恢复、副作用、隔离和验证这些事。14

4. Agent 系统和传统 LLM 应用到底差在哪

很多团队误判 Agent 基础设施，是因为他们仍然在用“传统 LLM 应用”的抽象去理解它。

传统 LLM 应用更像一次请求式系统：用户给输入，模型给输出，最多中间插几个工具调用。链路虽然可以复杂一点，但默认仍然是短程、同步、低副作用的。

而生产级 Agent 系统面对的是另一种对象：

  • 它往往是长程执行，而不是一次回答
  • 它会触碰外部世界，而不仅是生成文本
  • 它会失败、会等待、会被中断、会被接手
  • 它会留下真实副作用，而不只是返回一段字符串

也正因为如此，我很认同一个判断：现在很多 Agent Infra 其实还停留在“把提示循环包装得更方便”的阶段，而没有真正解决生产系统需要的执行语义。5 一旦场景进入真实权限、真实状态和真实副作用世界，问题就不再是“框架调度得顺不顺”，而是“系统有没有足够明确的状态语义、恢复语义和边界语义”。

更直白一点说：

生产级 Agent Infra，本质上是一套围绕长程执行、状态外部化、副作用管理、恢复语义和环境边界的执行系统。

5. 执行系统的第一个原语：状态外部化与 durable execution

一旦执行变成长程过程，工作流状态就必须被持久化和外部化。这几乎是整篇文章最重要的分水岭。

DBOS 在架构文档里说得非常直白：传统工作流系统里，工作流由运行时内存驱动，服务挂掉后状态会丢；他们的做法是把 workflow 状态和 step checkpoint 落到 Postgres，让数据库成为 durable execution 的底层记录系统。1 这件事的重要性不在于“又用了一次 Postgres”，而在于它把执行状态从进程私有内存里拿出来，变成了系统级对象。

Pydantic AI + DBOS 的结合，本质上也说明了同一方向。他们不是把 Agent 包成一个“更复杂的提示循环”，而是把 Agent 的工作流和执行步骤明确接进 durable workflow 语义里，让 Agent 的轨迹天然带上恢复点、重试点和持久化边界。7

Microsoft Durable Agents 则把另一个关键点说得非常清楚：any worker can resume a session。6 这句话看起来像实现细节，实际上是生产系统的分水岭。因为生产环境里的 Agent 几乎不可能一直被同一个进程、同一台机器、同一个 Pod 持有到底。只要会重启、会升级、会等待人类输入、会等待外部系统反馈，会话就必须能被别的实例接住。

所以，durable execution 的真正意义并不是“故障后自动重试”，而是：

  • 状态不再只存在于进程
  • 任务不再等价于一次请求
  • 恢复不再是例外，而是默认能力

6. 执行系统的第二个原语：副作用、恢复与执行语义

状态外部化之后，问题不会自动结束。系统还得回答另一组更棘手的问题：哪些副作用已经发生、哪些操作可以重放、哪些必须幂等、哪些需要补偿。

这也是为什么我越来越不愿意把 Agent Infra 理解成“模型编排层”。很多框架在 demo 阶段看起来已经够用，因为它们能把多步决策串起来；但一旦进入生产，真正致命的往往不是推理不够聪明，而是缺少执行语义：

  • 任务中断后从哪里继续
  • 副作用已经做过没有
  • 人机交互等待期间状态怎么保存
  • rollback 回滚的是模型状态、环境状态，还是业务状态

这时候，恢复点、补偿点、幂等边界、副作用日志、验证回路就不再是“工程细节”，而会变成系统语义本身。5

这也是我为什么觉得“session recovery”不能只被理解成一个更方便的 resume 功能。它真正逼系统显式回答的是：当前执行究竟处在哪个阶段，已经对世界做过什么，接下来还能安全做什么。

7. 执行系统的第三个原语：sandbox 不是隔离工具，而是运行时边界

Luis Cardoso 那篇 A field guide to sandboxes for AI 最有价值的地方，是把所有 sandbox 讨论都压成了一个极简框架：

Sandbox = boundary + policy + lifecycle.8

这个框架之所以重要，是因为它把很多经常被混在一起说的概念拆开了。

首先是 boundary。容器、gVisor、microVM、runtime sandbox 的差别，不是“名字不一样”，而是你到底把哪条线当作攻击者跨不过去的边界。8

其次是 policy。文件系统、网络、设备、进程、syscall、quota，哪些被允许、哪些被限制，这决定的不是“好不好用”，而是 Agent 到底拥有什么能力面。8

最后是 lifecycle。fresh run、workspace、snapshot/restore 面向的是完全不同的工作负载。敌意代码、agent workspace、RL fast reset，本来就不该用同一种生命周期去承接。8

从这个角度看，很多争论其实都争错了焦点。问题不是“容器好还是 microVM 好”，而是：你到底在服务什么工作负载？你要的生命周期是什么？你的边界和策略是否匹配这个工作负载？

8. 为什么 Agentic RL 会把这些问题进一步放大

如果说普通 Agent 应用已经会暴露执行系统问题，那么 Agentic RL 会把这些问题进一步推到系统底层。

OpenRLHF 已经明确指出，随着后训练重点从监督学习转向 RLHF / RLVR，rollout / inference 会成为主要运行时瓶颈。2 Justin Lin 那篇文章则把这个问题往前推进了一步：当优化目标从“解出基准题”转向“解决交互式任务”后，环境就不再只是一个验证器，而成为训练系统的一部分；此时工具服务器、浏览器、终端、执行沙箱、记忆系统和编排框架都进入了 RL 栈本身。14

这会直接带来新的系统级要求：

  • rollout 不是短请求，而是长轨迹
  • 推理端会等待环境反馈，训练端会等待已完成轨迹
  • 环境状态需要保存、回放、分叉和重启
  • 沙箱供给、镜像分发、快照恢复、全链路观测都会变成硬约束

MiniMax 那篇 Agent Runtime 案例展示的，也是同一个方向：一旦场景进入大规模 Agentic RL，沙箱不再是附属工具，而会变成直接决定吞吐、稳定性和成本的底座。11

这也是为什么我会说，RL 先在训练里把“执行问题”显影，Agent 再把它带进现实世界。前者让 rollout、environment、checkpoint 成为核心问题；后者让 durable execution、sandbox 边界、副作用日志和验证系统成为生产问题。2 3 11 14

9. 一个真正可用的 AI 原生工程栈分层

如果把前面的内容收成一张图，我会把 AI 原生工程栈分成四层。这个分层不是为了再发明一套术语，而是为了把问题空间压成一个可操作的坐标系。

第一层：模型与工具层

这一层负责推理、规划、工具调用、代码生成、多模态交互。它决定 Agent “会不会做”。OpenAI 的 Codex、各种 Skills、浏览器操作、代码修复都属于这一层。4

第二层：durable execution / workflow 层

这一层负责把一次次模型输出组织成可持久化、可恢复、可调度的执行过程。DBOS 的 durable workflows、Pydantic AI + DBOS 的 agent workflow wrapping、Microsoft Durable Agents 的 session recovery 都在这里。它解决的不是“模型怎么想”，而是“执行到哪里、失败怎么接着跑、别的实例怎么接手”。1 6 7

第三层：sandbox / runtime 层

这一层解决的是“在哪里执行”和“以什么边界执行”。Luis 的 boundary/policy/lifecycle 框架、Firecracker / gVisor / Wasm 这类隔离底座、ROCK 的环境控制面、Zeroboot 的 CoW VM fork，以及 MiniMax 案例里那类面向 Agentic RL 的沙箱平台，都属于这一层。8 10 11 12

第四层：observability / validation / experiment loop 层

这一层最容易被低估，却会越来越关键。OpenAI 让日志、指标和 UI 成为 Codex 的直接输入；Karpathy 的 autoresearch 把 keep/discard、固定预算和统一指标做成最小实验闭环；MiniMax 则把 checkpoint、快照回滚、轨迹记录和 VNC 观测提升成训练基础设施的一部分。4 11 13

这四层里，第一层决定能力上限；后面三层决定能力能否被稳定兑现。

10. 评估一套 Agent Infra，我现在只问这 10 个问题

如果把上面的分层再压缩成一个能直接拿去评估系统的框架，我现在基本只问这 10 个问题。关键不在“问题本身”，而在你怎么回答它们。

  1. 状态是在进程内存里，还是持久化在外部存储？
    这一问在区分：你的系统到底是在跑一次请求，还是在承接一个长期任务。
    如果状态只活在内存里，那么进程一挂、实例一漂移、任务一等待，会话就等于消失；这类系统本质上还是 request/response 的延长线。
    真正像执行系统的回答应该是：关键状态、step 进度、会话上下文和必要元数据都在外部可恢复存储里，进程只是临时执行者。1

  2. 失败后是从头重来，还是从上一个完成 step 恢复？
    这一问在区分：你的系统有没有明确的恢复点。
    “失败了就重跑一次”在短链路 demo 里还勉强可用，但一旦任务跨分钟、跨小时、跨多个工具和外部系统，整条链重跑往往既昂贵又不安全。
    更成熟的回答应该是：系统知道哪些 step 已完成、哪些未完成、哪些可重试、哪些必须补偿，因此恢复是沿着执行语义发生的，而不是把整条轨迹冲掉重来。1

  3. 有没有 checkpoint、快照回滚和分叉实验能力？
    这一问在区分：你的环境状态是不是可操作对象。
    对 Agentic RL、浏览器自动化、终端任务、复杂工具工作流来说，环境不是背景板，而是成本中心。不能保存、回放、分叉环境状态，就意味着每次调试都要重新搭环境、重新走轨迹、重新付延迟。
    所以这一问真正要看的不是“有没有快照”这三个字，而是：你能不能低成本复现实验、比较分支、回到某个已知状态继续跑。11

  4. 隔离边界是什么？
    这一问在区分：你到底把哪一层当作安全假设。
    容器、gVisor、microVM、Wasm 的差别，不是品牌偏好，而是边界强度不同；不同边界对应的攻击面、兼容性、启动速度和运维成本都不一样。
    如果回答只停留在“我们用容器”或者“我们上了 Firecracker”，那其实还没回答问题；真正清楚的回答是：我们押注哪条边界，为什么这条边界适配当前工作负载和风险模型。8

  5. Policy 到底收紧了什么？
    这一问在区分：你的 Agent 到底拥有什么能力面。
    很多团队会说“我们有 sandbox”，但没有说清文件系统能写哪、网络能打到哪、能不能起子进程、能不能碰设备、有没有 CPU 和时间配额。
    边界决定“隔不隔得住”，policy 决定“放进去以后它到底能做什么”；边界强但 policy 很松，或者 policy 很紧但边界很弱，都会留下结构性风险。8

  6. Lifecycle 是什么：fresh、workspace，还是 snapshot/restore？
    这一问在区分：你的运行时是不是按工作负载来设计的。
    敌意代码更适合 fresh run；长生命周期 agent workspace 需要保留文件系统和会话；RL rollout 和需要快速 reset 的系统天然更偏向 snapshot/restore。
    如果生命周期模型和工作负载不匹配，系统就会在安全性、成本、速度三头都吃亏。8

  7. 实例切换时，会不会丢失会话和任务状态？
    这一问在区分：你的会话是“绑定某个实例”，还是“独立于实例存在”。
    真正的生产系统默认实例会重启、缩扩容会发生、人工确认会等待、外部系统会延迟；如果一换实例 session 就丢，那整套系统其实还没有跨过生产门槛。
    所以这一问真正要看的，是能不能做到 any worker can resume a session，而不是“理论上可以重连”。6

  8. 日志、指标、trace 是只给人看，还是 Agent 也能直接消费？
    这一问在区分：你的可观测性到底是运维面板，还是执行接口。
    当 Agent 参与调试和修复时，日志、指标、DOM 快照、trace 不再只是人类值班工程师的工具，而应该成为 Agent 的直接输入。
    如果这些信号只能人读，调试吞吐很快会被人工分析卡死；如果 Agent 也能直接消费，它才可能闭环地复现、定位、修复和再验证。4

  9. 验证体系是事后兜底，还是前置设计？
    这一问在区分：你到底是在“生成结果”，还是在“生产可验证结果”。
    事后兜底的系统常见特征是：先让 Agent 大量生成，再靠人工慢慢看；而前置设计的系统会先定义测试、指标、预算、验收门槛和 keep/discard 规则。
    真正可持续的 Agent 系统，验证不是最后一道防线，而是执行流程本身的一部分；没有这层设计，自我迭代很容易退化成自我漂移。4 13

  10. 这套系统支撑的是 demo，还是能承受真实权限、长程执行和真实副作用的生产环境？
    这一问其实是在收束前面九问。
    demo 系统通常可以容忍：状态丢了就重来、失败了靠人工补、边界模糊也先跑通；生产系统不行，因为它面对的是权限、成本、SLA、审计、幂等和事故责任。
    所以这最后一问真正要看的，是你的答案在现实系统约束下能不能闭合，而不是能不能做出一次漂亮演示。5 12

这 10 个问题几乎都不直接问“模型多强”。不是因为模型不重要，而是因为当模型足够强之后，真正会卡住你的，往往是执行系统本身。

11. 对研发团队的 5 个直接动作

如果把前面的“十问”翻成研发团队今天就能执行的动作，我觉得至少有五条。

1）文档要为 Agent 而写

OpenAI 的经验说明，Agent 真正需要的是一张地图，而不是一大坨说明。文档系统至少要做到三件事：结构化、可导航、可验证新鲜度。否则模型上下文很快就会被过期说明和模糊规则占满。4

2）验证体系要前置

当生成成本下降之后，验证会迅速成为瓶颈。团队越早把测试、回归、验收标准和运行时检查前置进系统，越能把 Agent 吞吐变成真实产能。若还希望 Agent 真能自己迭代，这一步还得继续前移：固定预算、统一指标、清晰的 keep/discard 规则，都要先写进系统。4 13

3）可观测性要同时服务 Human 和 Agent

日志、指标、追踪信息不应只给人类值班工程师看，也应该成为 Agent 的直接输入。让 Agent 能读 LogQL、PromQL、UI 运行时信号，这件事的重要性会越来越接近今天“能不能自动化跑测试”这种基础能力。4

4）状态不能只放在进程里

只要你在做多步 Agent、长程工作流、工具调用或人机混合执行，就应该默认进程会挂、实例会漂移、任务会等待。状态必须外部化，才能恢复；如果状态只能靠进程内存续命，那系统离生产还差得很远。1 6

5）先按工作负载选 runtime，而不是先按偏好选底座

任何 sandbox 选型都应该先回答三件事：它和 host 共享什么、代码能碰什么、哪些东西会跨运行保留。如果这三个问题答不清，运行时边界其实就还没有被真正设计出来。8

12. 结语：从“写代码”到“设计执行系统”

如果把 2023 年以前的大模型工程叙事概括成“拼参数、拼训练、拼模型能力”，那么 2024–2026 年更像是在沿另一条线演化：先是 reasoning RL 暴露出 rollout 和环境问题，再是 agentic thinking 把“与环境交互地思考和行动”推到台前，最后 durable execution、sandbox lifecycle、checkpoint / snapshot、环境供给和 observability 逐渐变成新的基础设施前提。2 3 11 14

所以，我对未来两年的判断很简单：模型能力会继续进步，但真正拉开差距的，会是执行系统。

更直白一点，未来团队之间的差异，会更多体现在：

  • 谁能把代码库组织成 Agent 可读的记录系统
  • 谁能把执行状态外部化，并把恢复做成默认能力
  • 谁能把 sandbox 的边界、策略和生命周期设计清楚
  • 谁能把 checkpoint、验证和可观测性前置成系统原语，而不是事后补丁

谁先把这几件事做出来，谁就更接近真正的 AI 原生工程栈。

13. 参考阅读（按主题分组）

Durable Execution / Workflow

  1. DBOS Architecture：把 workflow / step checkpoint 到 Postgres 的 durable execution 设计。1
  2. Durable Agents：会话恢复、多实例接管、human-in-the-loop 持久等待。6
  3. Pydantic AI + DBOS：把 Agent workflow 明确接到 durable execution 上。7

Harness / Eval / Self-Iteration

  1. Harness engineering：OpenAI 如何把代码库、验证和可观测性重写成 Agent 可消费的执行系统。4
  2. autoresearch：最小化自我迭代闭环，强调统一指标、固定预算与 keep/discard 规则。13

Production Agent Infra / Runtime

  1. 为什么现有的 Agent Infra 无法支撑生产级应用？：执行语义错位、语义原语缺失与生产级 Agent Infra 的结构性问题。5
  2. 百万级吞吐，十万级并发：揭秘 MiniMax 大模型 Agentic RL 训练背后的沙箱底座：Agentic RL 对沙箱底座的四类诉求，以及腾讯云 Agent Runtime 的实现路径。11
  3. Zeroboot：sub-millisecond VM sandbox 原语与 snapshot / CoW fork 方向。12

RL / Agentic Post-training / Environment

  1. OpenRLHF：RLHF / RLVR 中 rollout / inference 成为主要运行时瓶颈。2
  2. Let It Flow：把 rollout 环境、上下文工程和后训练优化一起设计的 agentic learning ecosystem。3
  3. ROCK：面向 agentic reinforcement learning 的环境控制面与管理框架。10

Sandbox / Boundary / Runtime Base

  1. A field guide to sandboxes for AI：boundary / policy / lifecycle 三分法。8
  2. Agent sandbox 可能的选型以及 unikernel 的机会：Firecracker、gVisor、Wasm、unikernel 的现实权衡。9

Reasoning / Agentic Thinking

  1. Justin Lin，From “Reasoning” Thinking to “Agentic” Thinking：从“能思考更久”转向“能在与环境交互时持续推进”的判断，以及 agentic RL 对环境、工具、sandbox、memory 和 orchestration 的系统要求。14