TL;DR

  1. 架构组成：Responses API（决策）+ Shell Tool（执行接口）+ Hosted Containers（隔离执行环境）三层体系。
  2. 核心价值：将 AI 执行从”裸调用模型”升级为”安全、可控、生产级”的完整 Runtime。
  3. 安全机制：命令白名单 + 资源限制 + 容器隔离 + Seccomp 系统调用过滤，多层纵深防御。
  4. 工程挑战：冷启动延迟、容器成本、状态管理是规模化三大难题，OpenAI 通过热容器池、分层文件系统、挂载卷等方案应对。

为什么需要 Agent Runtime？

大语言模型（LLM）可以生成代码，但生成代码和执行代码是两回事。

从模型到 Agent 的鸿沟

能力 LLM 模型 生产级 Agent
代码生成 ✅ 可以生成 ✅ 可以生成
代码执行 ❌ 不能执行 ✅ 需要执行环境
文件操作 ❌ 不能操作 ✅ 需要读写文件
工具调用 ❌ 不能调用 ✅ 需要调用 API
状态管理 ❌ 无状态 ✅ 需要会话状态
安全隔离 ❌ 无关 ✅ 必须隔离

核心问题：如何让 AI 安全、可控、可扩展地执行代码？

💡 Key Insight：LLM 本身无法执行代码——”能生成”和”能运行”之间隔着一整个执行环境。Agent Runtime 的本质，就是弥合这一鸿沟的基础设施层。

现有方案的局限

方案 1：本地执行

  • 问题：安全风险高，AI 可能执行恶意代码
  • 问题：环境不一致，”在我机器上能跑”
  • 问题：难以扩展，受限于单机资源

方案 2：云服务器

  • 问题：启动慢，不适合交互式场景
  • 问题：成本高，需要长期运行
  • 问题：资源浪费，大部分时间空闲

方案 3：无服务器函数

  • 问题：冷启动延迟
  • 问题：状态管理复杂
  • 问题：执行时间限制

OpenAI 的解决方案：Hosted Containers——快速启动的隔离执行环境。

💡 Key Insight

三种现有方案失败的原因可以归结为一个词：隔离。本地执行不隔离、云服务器隔离但启动慢、无服务器函数隔离但有状态限制——Agent Runtime 的任务，就是提供一个同时满足”快速启动”和”安全隔离”的执行环境。

架构概览：三层设计

OpenAI 的 Agent Runtime 采用三层架构：

架构概览：三层设计

设计哲学

每一层都有明确的职责边界：

层级 职责 关键设计
Responses API 智能编排 让模型决定”做什么”
Shell Tool 执行接口 定义”怎么做”的标准
Containers 资源提供 安全、隔离的”在哪里做”

Responses API：Agent 的神经系统

Responses API 是 Agent 的决策中心——它负责理解任务、规划步骤、调用工具。

💡 Key Insight：Responses API 不仅是”调用模型的接口”，更是 Agent 的编排引擎——模型在每次响应中决定下一步行动，而非简单返回文本。这种内生的工具调用能力是 Agent 与普通 LLM 调用的本质区别。

1. 结构化输出：不是简单的文本生成，而是结构化的行动指令，每次响应中包含工具名、参数列表和条件判断逻辑。模型输出的不再是”文本”，而是一个可执行的决策指令集——这让 Responses API 成为 Agent 的决策中心，而非单纯的语言模型调用接口。

2. 工具调用协议：Agent 通过统一协议调用文件读写、命令执行、网络请求等能力。这个协议是标准化的——不同 Agent 只要遵循同一套协议定义，就可以互操作，开发者不需要为每个 Agent 重新发明接口规范。

3. 状态与会话管理：Agent 需要”记忆”之前的操作——关键设计是会话隔离 + 持久化状态。每个会话有独立的上下文空间，会话之间互不干扰；同时通过持久化存储让状态在容器重启后得以恢复。这是 Agent 与普通 LLM 调用的本质区别：普通 LLM 调用是无状态的，而 Agent 的每次交互都建立在历史上下文之上。

Shell Tool：安全的执行边界

Shell Tool 是 Agent 与执行环境的接口层。它不是一个简单的 os.system()，而是一个受控的执行网关。

💡 Key Insight：Shell Tool 的核心价值不是”执行命令”，而是将危险操作转化为安全、可审计的 API 调用——每次命令执行都被白名单检查、资源计量、输出捕获，安全边界在执行前就已确立。

功能边界

功能边界

安全设计

1. 命令白名单：不是所有命令都能执行——Shell Tool 维护一个许可列表，拦截未授权操作（如 rm -rf /）。这个白名单在容器创建时由 Hosted Containers 层注入，Agent 运行时无法修改。这意味着即使 Agent 被恶意prompt注入攻击，它的权限边界也已经由基础设施预先锁定，攻击者无法通过越权命令突破执行边界。

2. 资源限制：CPU、内存、进程数均被 cgroups 约束，防止单个 Agent 耗尽容器资源。每个容器有独立的 cgroup 命名空间，宿主机操作系统对每个容器的资源使用设有硬上限。当 Agent 执行一个消耗大量资源的操作时，受限的是该容器自身，不会影响同一宿主机上的其他容器或宿主机的稳定性。

3. 输出捕获与流式传输：Agent 需要实时看到执行结果——stdout/stderr 被流式捕获并传回模型。流式传输（Streaming）在这里尤为重要：Agent 的决策依赖实时反馈，执行结果需要尽快回到模型手中，而不是等到命令完全结束才返回。Shell Tool 在命令执行期间持续捕获输出流，通过 Responses API 的流式机制传回，让 Agent 能够在执行过程中观察中间状态、发现错误并及时调整策略。

Hosted Containers：隔离与扩展

Hosted Containers 是 Agent 的执行沙箱——每个 Agent 会话运行在独立的容器中。

💡 Key Insight：Hosted Containers 的关键创新在于按需创建、用完即毁的无状态设计——每次任务从干净环境出发，彻底规避了状态污染和会话残留风险。这与长期运行的 VM 或传统容器有本质区别。

容器生命周期

容器按需创建，用完即毁——无状态设计确保每次请求都从干净环境出发，避免状态污染。这个设计有重要的安全含义：每次任务都从一个已知的干净状态开始，不会受到上一个任务的残留状态影响，也不会污染下一个任务的环境。

冷启动优化

容器启动慢是主要挑战。OpenAI 的解决方案：

1. 预置镜像

常用环境（Python、Node.js、Bash 等）的容器镜像预先构建并缓存，无需在每次请求时从头拉取基础层镜像。镜像中只包含必要依赖，精简到最小体积，进一步缩短启动时间。

2. 热容器池

在容器空闲时预先启动一批”热”容器，保存在内存中等待调度。当新请求到达时，直接分配一个热容器而不是启动新容器，冷启动延迟从 1-5 秒降低到毫秒级。热容器池的大小根据负载动态调整，在低峰期缩容以节省资源，高峰期扩容以保证响应速度。

3. 分层文件系统

每个容器镜像由只读基础层和可写工作层组成。基础层包含操作系统和运行时库，所有容器共享同一份只读基础层；工作层是容器的可写层，容器销毁时工作层随之清理。由于基础层只需下载一次，容器启动变成只是”分配一个可写层 + 启动进程”，极大缩短了启动时间。

冷启动优化

安全隔离

1. 命名空间隔离（Linux Namespaces）：容器内的进程、网络、挂载点与宿主机及其他容器各自拥有独立的命名空间。这意味着容器内的进程看不到宿主机上的进程，容器内的网络栈与宿主机网络隔离，挂载点也各自独立。攻击者即使通过 Agent 漏洞获得容器内root权限，他的”视野”也只限于该容器内部，无法直接影响到宿主机或其他容器。

2. Cgroups 资源限制（Control Groups）：CPU、内存、IOPS 均受 cgroups 控制，单个容器无法耗尽宿主机资源。cgroups 在操作系统层面为每个容器设置了资源使用的硬上限——内存超限会被 OOM Killer 强制终止，CPU 超限会被 throttled，IOPS 超限会被限流。这保证了即使某个容器内的 Agent 进入死循环或内存泄漏，也不会拖垮整台宿主机。

3. Seccomp 系统调用过滤（Seccomp BPF）：通过白名单过滤危险系统调用（如 ptrace、mount、syslog），进一步缩小内核攻击面。默认情况下容器内的进程可以调用数千种系统调用，但 Seccomp BPF 允许只开放执行所需的几百种——攻击者即使完成了容器内提权，也无法通过危险 syscall 突破容器边界。

安全模型：纵深防御

OpenAI 的 Agent Runtime 采用纵深防御策略——多层安全措施，即使一层被突破，还有其他层保护。

💡 Key Insight：纵深防御的核心不是”让攻击不可能”，而是让攻击代价极高——攻击者需要同时绕过命令白名单、资源限制、容器隔离、Seccomp 过滤、网络隔离五道防线，这在实际上几乎不可行。

这七道防线从外到内分别是：L1 请求限流（API 网关层的请求速率限制，阻止 DDoS 和暴力枚举）、L2 身份认证（每个 Agent 会话持有独立凭证，凭证失效即失去访问权限）、L3 网络隔离（VPC 划分 + 防火墙规则，容器只能访问白名单内的网络目标）、L4 容器沙箱（Hosted Containers 层，容器是 Agent 的执行边界）、L5 文件系统隔离（每个容器有独立的文件系统视图，容器之间无法互相读写文件）、L6 进程与资源隔离（cgroups + Linux 命名空间，单个容器的资源消耗有硬上限）、L7 监控与审计（所有操作记录日志，异常行为触发实时告警）。这七层覆盖了从网络入口到内核调用的完整链路——攻击者必须同时突破所有七层才能完成一次完整的数据泄露，这在实际中几乎不可能。

安全层次

安全层次

威胁模型与防护

威胁 防护层级 防护措施
恶意代码执行 L4-L6 容器隔离 + 命令白名单
资源耗尽攻击 L2, L6 Cgroups + 请求限流
数据泄露 L4, L5 文件系统隔离 + 网络限制
权限提升 L3, L4 Seccomp + 命名空间
供应链攻击 L7 操作审计 + 异常检测

规模化挑战与解决方案

Agent Runtime 的规模化面临独特挑战：

💡 Key Insight

规模化的核心矛盾是”隔离”与”效率”的对抗——每个 Agent 需要独立容器保证安全，但独立容器意味着冷启动、内存占用和成本压力。OpenAI 的答案是热容器池 + 分层文件系统 + 容器复用，在安全边界内尽可能共享资源。

挑战 1：冷启动延迟

问题：新容器启动需要 1-5 秒，用户体验差。

容器冷启动的核心耗时在镜像拉取和进程启动。OpenAI 的解法是热容器池 + 镜像预热：常用语言的运行时镜像（Python、Node、Bash 等）预先缓存在每个计算节点，容器启动时省去镜像拉取时间；热容器池始终保持一批空闲容器处于就绪状态，新请求到达时直接分配，无需创建。两种策略叠加，冷启动延迟从秒级压缩到毫秒级，用户无感知。

挑战 2：资源成本

问题：每个 Agent 需要独立容器，成本高。

独立容器意味着独立资源配额，而大多数 Agent 实际上只在执行时才消耗资源，空闲时并不需要预留容量。OpenAI 的解法是容器复用 + 自动扩缩容：同一会话内的多个请求尽可能复用同一个容器，减少容器创建次数；空闲容器进入休眠状态（冻结进程，释放内存但不释放容器），当新请求到达时快速唤醒。整体资源利用率提升，成本随之下降。

挑战 3：状态管理

问题：Agent 需要持久化状态（文件、数据库）。

容器的无状态设计带来一个问题：容器销毁后，内部文件系统也随之消失，Agent 的工作成果如何保存？OpenAI 的解法是挂载卷 + 状态快照：容器通过挂载卷将关键目录（工作目录、数据库文件等）映射到持久化存储层，容器销毁后数据不丢失；同时对运行状态做周期性快照，支持从最近快照恢复会话，即使容器因故障重启，Agent 也能从中断点继续工作。

挑战 4：网络隔离与连通

问题：Agent 需要访问特定外部服务，但必须隔离风险。

允许 Agent 自由访问互联网会引入数据泄露和供应链攻击风险；完全禁止网络又会限制 Agent 的能力。OpenAI 的解法是出口代理 + 域名白名单：Agent 的出站流量统一经过出口代理，代理按域名白名单放行未经授权的请求；内部服务网格处理安全的容器间通信，外部 API 调用则通过受控的代理路由——Agent 能完成工作，但它的网络视野被限制在白名单范围内。

对开发者的启示

OpenAI 的 Agent Runtime 架构对构建 AI-Native 应用的开发者有重要启示：

分层设计的重要性

不要将智能、执行、资源混在一起。清晰的层次边界让系统更易维护、更安全。

2. 安全是架构问题，不是功能问题

纵深防御需要在架构设计的每个层级考虑，不能事后补丁。

3. 性能与安全的权衡

热容器池牺牲了一些资源效率，换取了用户体验。这种权衡需要根据场景调整。

4. 标准化的价值

Responses API 定义了标准化的工具调用协议，让不同 Agent 可以互操作。

结尾：Agent 基础设施的成熟

OpenAI 公开的 Agent Runtime 架构标志着一个重要趋势：Agent 基础设施正在成熟。

从简单的 API 调用，到完整的执行环境，再到安全、可扩展、生产级的 Runtime——这是 AI 应用从 demo 走向 production 的关键一步。

对于开发者来说，这意味着：

  • 可以更专注于业务逻辑，而非基础设施
  • 可以构建更复杂、更强大的 Agent 应用
  • 需要在设计时就考虑安全、隔离、可扩展性

Agent 时代的基础设施战争刚刚开始，OpenAI 已经展示了一个可能的蓝图。

参考与延伸阅读

深度阅读时间：约 14 分钟

本文基于 OpenAI Engineering 博客文章分析。

发布于 aazh2026.github.io