深入理解 Agent Runtime：模型、执行环境、工具调用与沙盒安全

同样接入 GPT，为什么一个应用只能回答问题，Codex 却能读取仓库、改文件和运行命令？差异不只在模型。模型生成内容或工具调用请求；把请求变成可执行、可限制、可追踪的行动，需要另一层软件。我把这层称为 Agent Runtime，也可叫 Harness。

上一篇从操作系统角度说明“模型不是进程”。这次向上看一层：Runtime 如何连接推理服务、任务状态、工具与真实环境，以及为何安全策略必须落在可执行的软件边界上。下文的组件图是教学划分，不是任何厂商公开的完整生产部署图。

01｜为什么强模型仍需要 Runtime#

让模型回答“如何运行测试”，它可以生成命令文本；让 Agent 真正运行测试，还要知道工作目录、可用工具、参数格式、文件权限、超时和失败后的处理方式。模型无法仅凭权重取得仓库访问权。OpenAI 的 Function Calling 文档区分模型返回的调用请求和应用侧执行；Codex Harness 文章公开描述了 Agent Loop、线程持久化、工具执行、认证与沙盒等软件职责。

这给我一个判断标准：研究 Agent 能力时，既要看模型能提出什么动作，也要看系统能否正确、可控地完成动作。

02｜Model Runtime 与 Agent Runtime 是两层系统#

Model Inference Runtime负责把模型权重加载到计算环境，处理 Token、推理计算、KV Cache 和批处理等。vLLM 的 Paged Attention 设计及 SGLang 文档展示了推理服务在吞吐、缓存与调度上的典型关注点。这里说的是这类公开框架的一般机制，不能反推 OpenAI 的未公开生产推理架构。

Agent Runtime消费模型服务的输出，组织多轮交互、工具调用、状态、权限与恢复。OpenAI 公开提供不同集成层次：使用 Responses API 的工具调用时，开发者可自行组织应用侧循环；Agents SDK提供运行 Agent 的框架；Agents API 架构则公开托管 Agent 会话、环境和工具等概念。Codex 还有其公开介绍的 Harness 与 App Server。这些接口与产品并非同一个实现的不同名字。

GPT 模型可以被 ChatGPT、Codex 或开发者应用接入，但工具清单和运行机制由各应用提供。某个 GPT 能在 Codex 中执行终端工具，不意味着同一模型在所有应用里都天然拥有终端、浏览器或文件权限。

03｜Runtime 的关键职责#

为了分析，我把常见职责拆成八组；实际系统可以合并、外包或省略某些模块。

Agent Loop / Runner接收用户目标，发起模型请求，判断回复是最终答案还是工具调用；工具返回后决定继续、结束、超时或交还人工。它需要限制迭代次数与资源使用，否则一次失败可能变成无界重试。

Model Client / Adapter把上下文、工具定义和参数 Schema 转成模型接口的请求，并把模型返回的文本、调用项、错误和调用标识转成 Runtime 可处理的对象。更换模型服务时，这层隔离接口差异；它并不负责实际运行 shell。

Context / State Manager保存对话、已完成动作、工具反馈和当前目标。Context 是本轮送入模型的材料；Session 是一段可继续的交互生命周期；Memory 是跨轮或跨会话保存并按需检索的事实；Checkpoint 是为了中断后恢复而持久化的执行位置。四者可能重叠，却不能都叫“聊天记录”。Codex 公开文档中的 thread 是会话与事件历史，不是 OS Thread。

Tool Registry / Dispatcher维护工具名、描述、参数 Schema 和处理器映射。收到模型的工具名后，它还要校验参数，定位执行器，记录调用标识。Schema 能约束输入形状，却不能替代业务校验与权限判断。不存在的工具或越界参数应返回可解释的错误。

Execution Environment承接真正的动作：进程内函数、子进程、远程 API、MCP Server，或容器、虚拟机里的沙盒工具。它决定工作目录、文件挂载、网络与资源限制。Runtime 与执行环境可以在同一机器，也可以隔着网络。

Orchestrator / Scheduler处理多步依赖、并发和子 Agent 分工。有些系统把它写在 Loop 中；另一些系统单独调度。可并行的只读步骤可以并发，依赖前一步结果的写入必须等待；“多个 Agent”也不自动等于多个 OS 线程。Agents SDK 编排文档提供了公开的 handoff 与编排例子。

Anthropic 在 Building effective agents 中区分预定义代码路径的 workflow 与由模型动态决定工具使用的 agent。这种区分提醒我：调度器不必把每一步都交给模型；已确定的依赖关系交给代码，往往更容易检验。该文发表于 2024 年，其页面也提示部分工具生态描述已有变化，本文只借用这一结构性区分。

Security / Policy根据身份、目标资源、工具风险和环境能力判断能否执行，必要时要求人工审批，并在执行环境施加隔离。Tracing / Recovery记录调用、输入摘要、结果、耗时与错误，供排障、评测及中断恢复使用；恢复前必须判断操作是否已经产生副作用，不能机械重试。OpenAI 的 Agents API 错误与恢复文档特别要求先检查已完成动作。

这八组职责之间有一条容易忽略的依赖：可恢复性需要先有可辨认的执行记录。假如一次外部 API 写入在网络超时前已经成功，Runtime 仅凭“没收到响应”重放同一写入，可能造成重复副作用。调用标识、幂等键、状态回读和有界重试因此属于执行设计的一部分，而不是日志系统的装饰功能。

Agent Runtime 的逻辑组件与外部模型推理服务、工具服务及执行环境的关系图。

图 1：蓝色区域是本文的教学用 Runtime 职责划分；紫色服务和绿色执行环境在边界外。箭头只示意主要连接，组件可以在具体系统中合并。

04｜GPT 的一次工具调用如何落地#

设用户要求“运行这个仓库的 pytest，告诉我失败原因”。Runtime 先构造模型输入：用户目标、相关上下文以及它允许使用的终端工具定义。工具 Schema 说明名称、参数类型和必填字段，例如 command 是字符串、timeout 是受限整数。模型可能返回一个包含工具名、参数和调用标识的结构化请求。这一步只是请求，命令尚未执行。

Runtime 接着解析参数、检查工具是否注册、验证命令与目录是否落在策略允许的范围；高风险动作可能进入人工审批。获准后，执行器才在指定环境里运行命令。标准输出、标准错误、退出码和超时状态构成工具结果。Runtime 用调用标识把结果关联到原请求，再送入下一轮模型输入。模型据此分析失败，或提出下一步。OpenAI Responses API 的函数调用示例使用 call_id 关联 function_call 与 function_call_output；其他框架可能使用不同字段，但关联关系不可省略。

用户、Agent Runtime、模型服务、工具执行器与操作系统或外部服务之间的工具调用时序图。

图 2：步骤 3 只产生调用请求；步骤 4 检查策略并在需要时审批；步骤 6 才触及操作系统或外部服务；步骤 7、8 将结果交还模型。

用极简伪代码表达，基本循环是：

1
while within_budget:                 # 教学示意，非某 SDK 可运行代码
2
    response = model(context, tools)
3
    if response.is_final: return response.answer
4
    call = parse_and_validate(response.tool_call)
5
    policy.authorize_or_ask(call)
6
    result = dispatcher.execute(call)
7
    context.add_tool_result(call.id, result)

“工具”还覆盖不同供给方式：Shell 和 File Tool 接触本地环境；Web Search、File Search 或托管代码工具可能由平台执行；开发者自定义 Function 可在应用侧运行；Computer Use 操作受控界面；Handoff 把任务交给另一 Agent。不能假设所有工具都在开发者电脑上跑。

MCP 是 Host/Client 与 Server 之间交换 tools、resources、prompts 的协议，不是某个工具本身；官方 MCP 架构文档也明确它不规定应用怎样管理模型与上下文。Skill 则是特定平台组织任务规则或流程的机制，形式随产品变化；读取 Skill 不会凭空增加文件或网络权限。Tool 承担具体动作，MCP 提供连接方式，Skill 指导怎样使用能力。

05｜工具执行与操作系统怎样相接#

一段工具处理代码可能直接在 Runtime 进程内运行函数；subprocess 可创建子进程并通过管道收集输出；远程工具通过 HTTP/RPC 到另一台机器；容器或沙盒则在受限环境中运行代码。托管工具的执行位置由平台决定。模型服务、Runtime 和工具甚至可以分布在三处。

这对应 408 的进程、线程、系统调用、IPC、网络和调度。运行命令会涉及进程创建与等待；读取文件会触及文件系统接口；远程调用会产生网络 I/O；异步 Runtime 可以在等待结果时处理其他工作。“Agent 调用一次工具”不意味着“一定新建一个进程”，也不意味着模型推理服务与工具共享一个地址空间。

06｜为什么沙盒是重要边界#

工具一旦能够改文件、执行命令或访问网络，错误参数、恶意仓库内容和提示注入就可能转化为真实操作。普通子进程不是安全沙盒：它通常继承运行用户的一部分文件、网络与环境权限。隔离必须落在真实执行环境和权限系统上，例如限定可读写目录、限制出站网络、收紧凭据、限制资源与独立工作负载。OpenAI Agents API 的沙盒安全文档明确讨论工作负载隔离、网络限制和凭据分离。

几层防线职责不同：Tool Policy决定哪些调用可进入执行器；Guardrails检查输入输出或流程条件；Sandbox限制代码运行时能接触的资源；Human Approval把特定风险动作交给人确认。它们可以组合，不能互相替代。容器是一种打包与隔离技术，沙盒是安全目标及其约束集合，Runtime 是组织整个过程的软件层；三者不是同义词。提示词可以指导模型，却无法替代 OS 权限、服务端授权和执行器校验。

最小权限的实际含义是：只给当前任务必要的文件、网络和工具能力，凭据尽量留在执行环境之外，并让写操作有可检查的边界。隔离也不是绝对保证，具体强度要看部署配置与威胁模型。本文不把任何一项框架配置称作“安全已解决”。

07｜从 Runtime 到 Agent Infra 与算法#

一个 while 循环足以解释最小闭环，却无法独自处理长任务恢复、并发、工具副作用、审批、追踪与成本上限。Agent Infra 更关心这些执行机制的可靠性、延迟、资源与观测；Agent 算法更关心任务分解、策略选择、反馈利用和评测方法。边界并非职位划分，而是观察系统的两个角度。

执行轨迹记录了“模型看到什么、请求了什么、工具实际返回什么”，因此可以用于定位失败、构造评测和研究训练信号。但推理时得到一次工具反馈，只改变当前输入与状态；只有后续确实发生参数优化，才谈得上训练或强化学习。

我更愿意把 Agent 的可靠性写成一条责任链：模型提供候选能力，Runtime 组织执行，真实环境返回反馈，权限机制约束可发生的动作。 更强的模型能改善判断，却不能替代健全的执行和授权系统。

资料来源#

OpenAI，Function Calling、Using tools：函数调用、调用标识和工具类别。
OpenAI，Unlocking the Codex Harness，2026-02-04；Agents SDK：Running agents；Agents API：Architecture：公开的运行层选择。
OpenAI，Guardrails and human review、Sandbox security、Errors and recovery：权限、隔离与恢复。
MCP，Architecture overview：协议参与者与职责边界。
Python，subprocess 文档；vLLM，Paged Attention；SGLang 文档：工具进程和推理服务的一般机制。
Anthropic，Building effective agents，2024-12-19：工作流与 Agent 的常见结构对照；该页面注明部分工具生态描述已随时间变化。

JaisonG1n