Agent 执行基础设施¶

pVisor 可以作为 Agent 推理、评测和 RL 后训练的执行层：接收工具或任务请求，在选定环境中执行，并把结果与状态交还给调用方。先在单机验证一个完整任务，再根据负载选择并发、状态复用和资源管理方式。

从执行基础设施快速开始运行 SWE 工具执行片段，了解如何通过 CLI 适配函数提交任务并收集反馈。

Agent-native sandbox 解决什么问题¶

Agent 的一次任务通常交替经历模型请求与工具执行。工具修改工作区，后续调用依赖前面的文件或进程状态；模型等待期间环境仍可能占用内存。评测和训练还需要区分基础设施失败与任务得分，并将结果对应回具体样本。

这里的 agent-native sandbox 指围绕这些执行阶段组织环境、状态和证据。pVisor 的不同入口提供不同能力；先用接入方式矩阵选择 CLI、嵌入式 Runtime、daemon API 或 containerd shim，再设计上层服务。

一次任务的责任划分¶

1. 准备输入：调用方固定任务、Agent/模型版本、工作区基线、镜像身份和资源预算。
2. 创建并执行：通过选定入口启动环境，检查准入和实际控制，运行工作负载。
3. 等待或保存：依据所需状态选择保留运行环境、文件分支或受支持的执行检查点。
4. 交付结果：将退出结果、候选文件和可用记录关联到上层任务与 attempt。
5. 释放资源：确认操作结果，保留所需产物，再按该入口的生命周期清理环境。

任务队列、模型采样、奖励计算、重试策略和跨节点放置由上层系统管理。pVisor 的执行成功只说明相应操作完成；任务是否正确、是否产生有效训练样本，需要 evaluator 或业务规则判断。

为推理服务保留上下文¶

推理请求可能需要连续运行多个工具，并在同一工作区中积累结果。先明确会话需要保留什么，再选择支持相应调用方式的入口；宿主进程的内存、guest 文件、Agent 历史和外部服务数据有各自的所有者。

文件分支见工作区检查点，执行恢复见CLI 合同，轨迹续跑见回放指南。这些方式不能互相替代所保存的状态。

轨迹记录与回放也可用于本地 Agent 工作流。先用单个任务验证捕获与回放，再将同一流程接入推理或评测服务。

为评测与 RL 交付样本¶

从单次 rollout 示例验证“执行 → 读取候选 → 评分 → 保存样本 → 清理”。它通过原生 Job 收集结果，可以先在一台机器上接入现有 evaluator。

扩展样本数时，为每次尝试保留独立工作区和身份，将任务 ID、执行身份、输入版本、轨迹位置与评分关联起来。分别记录执行失败、访问拒绝、记录失败和任务得分，避免把运行环境故障当作模型能力判断。

需要模型通信记录时显式启用捕获。多节点任务的交接与集中证据仍由外部编排集成负责，当前设计与缺口见执行与编排研究。

按生命周期管理资源¶

环境准备阶段可使用共享镜像缓存复用内容；工具执行阶段核对资源限制和实际占用；模型等待阶段再评估内存共享、压缩或卸载是否适合负载。

这些内存机制的可用平台、互斥条件和恢复语义不同，按内存子系统选择。短时等待、写密集或难压缩的内容可能无法抵消扫描、保存与恢复的成本。

容量评估应覆盖有效完成量、工具延迟、宿主与共享服务总内存，以及失败和回收路径。密度实验与VM 内存实验分别描述自己的负载和制品，不能直接作为所有部署的并发承诺。

从当前接口开始¶

需要文件结果与原生 Job 记录时，先验证 CLI 或 Rust Runtime；需要 HTTP 沙箱生命周期时，按daemon 部署条件准备服务。已有 containerd 调用链则检查shim 的接口范围。

daemon 的 bootstrap、端到端 SDK 验证及能力缺口在接入矩阵中单列。完整 RL 训练吞吐、reward 和跨主机规模收益仍需上层工作负载实验；已有成本分析见RL 场景比较。