Agent 任务的生命周期成本¶
pVisor 的目标是让 Agent 保持原有的顺序执行方式，由共享执行引擎接管可代理的 I/O，在等待期间回收资源，事件就绪后从原来的位置继续执行。
沙箱启动更快，可以缩短每次任务的准备时间。对于大量有状态的 Agent，还可以进一步减少等待期间的资源占用，避免为每个任务从头到尾保留一份完整驻留环境。
Agent 的时间线连续，资源需求却是间歇的¶
一个 Coding Agent 通常沿着自己的时间线工作：读取仓库、请求模型、修改代码、运行测试，再根据结果决定下一步。工具、子进程和后台服务可能并行运行，整个任务仍需要保留跨轮次的状态。
计算与等待在这条时间线上反复交替。等待模型回答时，推理发生在外部服务，沙箱却可能继续持有内存、缓存和进程状态。
DeepSeek 的 DSec（DeepSeek Elastic Compute） 报告给出了生产证据：2026 年初一周的样本中，容器与 microVM 两类后端约 90% 的沙箱，平均 CPU 使用量不超过申请量的 5%。生命周期中位数分别为 17.4 和 15.5 分钟，P99 均超过 3 小时。报告也明确指出，沙箱会等待模型生成下一步动作，而状态和缓存仍然保留。DSec §1、§4.3，图 5、图 7
这些观察说明，长生命周期的任务中，计算与等待会随交互轮次反复出现，但没有固定周期。图中的阶段时间线是示意，并非 DSec 的实测曲线。
并发任务越多，等待期间积累的驻留开销越大。保留任务进度所需的状态，同时减少等待时的物理资源占用，需要考察 Agent 从拿到环境到交付结果的完整生命周期。
从 I/O 执行模型看这次转变¶
高并发服务器经历过类似的资源组织变化。一条线程按顺序处理请求时，一个请求等待 I/O，会推迟后续请求。为每个连接安排一个线程，就能保留顺序写法并让多条时间线并发；但大量连接等待 I/O 时，线程栈和执行上下文仍然存在。
事件驱动把等待集中起来，用更少的线程处理大量连接。Reactor 等待 epoll 这类就绪通知；Proactor 提交操作后等待完成通知，IOCP 就是这种模型。直接采用这些模型，往往要把顺序代码拆成状态机或回调，并管理更多执行状态。epoll、IOCP
透明协程进一步把这种改造集中到运行时：程序继续按顺序表达逻辑，运行时通过系统调用挂钩或标准库适配，把支持的阻塞 I/O 交给事件引擎；等待时挂起协程，就绪后从原来的调用位置继续。例如 libco 通过 socket 函数挂钩和 epoll / kqueue，让业务保留同步写法、异步执行。libco、Go 的运行时调度
图中用一个工作线程说明复用关系，实际可以扩展为多个。Reactor 通知“可以尝试读写”，Proactor 通知“已提交的操作完成”；协程则让应用不必直接围绕这些事件拆分状态。透明只覆盖已适配的 I/O 路径，并在那里保留调用语义；任意多线程程序仍需要显式迁移。
pVisor 希望在执行层完成类似的适配：Agent 继续使用已有的代码和 Linux 工具，由运行时在可接管的等待处挂起执行、推进 I/O，再按事件恢复，无需 Agent 重写并发结构。
用虚拟机承载 Agent 的执行上下文¶
沿着协程的思路，pVisor 把调度单位扩展到整个 Agent 执行环境。协程保存调用栈和局部变量；VM 则承载 Agent 的进程、内存与 Linux 内核状态，让运行时能够在应用之外保存和恢复它的执行上下文。
在目标设计中，Agent 继续运行原来的代码，使用原来的 Linux 工具和阻塞调用。文件和网络 I/O 经过 Linux 与虚拟设备进入宿主，pVisor 在已适配的设备与协议路径接管请求。适配工作集中在 guest 内核、VMM 和宿主服务，Agent 无需改写成异步程序，也无需调用专用的挂起、卸载或恢复接口。VM 执行路径
Agent 看到连续执行，宿主按事件调度¶
以一次可代理的模型请求为例：Agent 发起请求后照常等待。pVisor 把请求交给宿主，由宿主推进；在整个 guest 可以安全等待时保存上下文、回收可卸载内存，让可复用的资源服务其他 Agent。响应到达后，pVisor 恢复这份上下文，让原来的调用返回，Agent 接着处理结果。
共享执行引擎管理多个 Agent 的物理资源占用，每个 Agent 保留自己的执行进度。恢复后继续的是同一个进程与同一次执行：VM 保存跨越等待所需的机器上下文，宿主保存等待期间仍须推进的 I/O 状态。
透明性的边界是原有调用语义：结果、错误、文件顺序和同步要求都要保留。宿主必须先持有独立的请求和数据，才能解除 I/O 对 guest RAM 的依赖；模型请求还需要协议适配，普通 TCP 转发无法自动接管 guest 内的 TLS 会话。后台仍有可运行工作时，guest 继续执行。
大批量写入也需要这种所有权转移。宿主取得独立的待写数据后，可以负责排队、合并和落盘；在保留写入顺序、错误及同步语义的前提下，当整个 guest 只剩对这些操作的等待，就有机会卸载它。较小的宿主缓冲有可能释放更大的 guest 驻留内存。队列背压、同步操作和仍在运行的后台任务都会影响可卸载窗口，缓冲本身也必须计入资源成本。Agent I/O 完成机制
阻塞的 vCPU 本来就允许宿主调度其他工作。这里进一步追求的容量收益，主要来自回收等待中的 guest 仍然持有的物理内存。
容量收益可以先算清楚¶
对于等待占比较高、承载量受内存限制的 Agent 负载，可以把约 2 倍的稳态承载能力作为立项目标，高等待情景上探约 2.7 倍。 这个目标来自公开原型、现有卸载测量与明确的参数假设；完整 I/O 接管路径尚未测得这样的生产容量。
公开结果与现有测量分别支持什么¶
| 证据 | 实际观察 | 对测算的作用与边界 |
|---|---|---|
| The Cost of Dynamic Reasoning，v2，§IV-A、图 5 | 四类 benchmark、多种 Agent 工作流中，LLM 推理平均占总延迟 69.4%，工具执行占 30.2%；默认模型为 Llama-3.1-8B，使用 vLLM 0.6.6 | 支持模型阶段可能占据多数时间；LLM 阶段仍可能与工具重叠，不能直接当作整个 guest 的可卸载比例 |
| AgentSysBench，v1，§8.3、图 25(c,d) | Mini-SWE 原型在模型规划调用超过固定时间阈值后卸载 sandbox，下一工具步骤前恢复；平均／峰值驻留内存降至基线的 1/4.6、1/2.1，延迟增加不超过 0.5% | 直接支持等待期卸载的收益潜力；指标是该次运行中全部并发 sandbox 进程的合计驻留内存，尚未证明整节点密度或整 VM 卸载 |
| pVisor 历史静态内存测量及其归档读数 | Linux x86_64/KVM，512 MiB guest、64 MiB 应用工作集；完整产品进程 PSS 约 179–181 MiB → 36 MiB，下降约 80%；含缓存的产品组 cgroup 约 224 MiB → 19 MiB | 给卸载后残留量提供参考；每条件 N=1、5 秒窗口，属于历史批次，不能代替真实 Agent 或整节点容量测量 |
AgentSysBench 未披露该卸载实验的阈值数值、并发数和底层卸载机制，足以说明方向可行，但不能给出下面的参数取值。pVisor 的 PSS 与 cgroup 是不同口径，不能相加，也都不能直接替代整节点净回收量。
负载差异同样有公开证据。AgentCgroup，v2，§3.2 的 SWE-rebench 实验中，LLM 推理仅占端到端时间的 26–44%，其余包含工具执行与初始化。因此，可卸载比例需要按目标负载设定；DSec 的低平均 CPU 使用率也不能换算成“95% 的时间可以卸载”。
从可卸载窗口推导承载量¶
先选定同一种负载和同一种物理内存计量口径，定义四个量：
m0：原方案每个 Agent 的平均驻留内存，使用实际物理占用，不使用 guest 配置容量。f：有效卸载窗口所覆盖的原有“内存 × 时间”份额。原驻留近似不变时，它就是可安全卸载的时间占比；后台工作、未接管的 I/O、短等待及卸载和恢复过程均须扣除。r：有效窗口内实际释放的原驻留比例，按窗口内原驻留的“内存 × 时间”加权；卸载后的 VM 残留已在这里扣除。h：新增宿主驻留的全程平均值除以m0，包含请求／响应缓冲、完成队列、未映射页缓存及交接时的额外副本。固定共享服务单独计入节点预算。
在可比观察窗口内，模型为：
采用 r = 80% 作为参考假设，并为新增宿主驻留设定 h = 5% 的预算目标，可得到下面三档情景。这些是参数假设与算术结果，尚非 pVisor 的 Agent 容量实测。
| 情景 | 有效卸载份额 f | 窗口内回收比例 r | 新增宿主开销 h | 新平均驻留 m1 / m0 | 内存受限的稳态承载倍率 |
|---|---|---|---|---|---|
| 保守 | 40% | 80% | 5% | 73% | 1.37 倍 |
| 中性目标负载 | 70% | 80% | 5% | 49% | 2.04 倍 |
| 高等待负载 | 85% | 80% | 5% | 37% | 2.70 倍 |
例如中性情景是 1 - 70% × 80% + 5% = 49%。若原来每个 Agent 平均占用 1 GiB，相同口径下预计变为约 0.49 GiB。扣除系统、共享引擎与恢复余量后，同样的 100 GiB Agent 内存预算，对应约 100 → 204 个执行上下文的平均驻留预算。
f = 70% 假设大部分相关等待都能安全接管。它是设计假设，不是把公开研究的 69.4% 四舍五入得到的实测参数。r = 80% 借鉴小工作集卸载的量级，实际还受工作集、共享和缓存影响。h = 5% 则是待实现验证的预算：对于 1 GiB 原驻留，它允许平均新增约 51 MiB；原驻留较小或同时积压大量响应时，需要重新估算。
宿主缓冲值得投入多少内存，也可以用这个模型判断。固定 f = 70%、r = 80%，若 h 从 5% 增至 15% 或 30%，倍率会从 2.04 降到 1.69 或 1.35。现有实验性宿主写缓存的单连接 payload 上限为 64 MiB，上限并不等于平均占用；多连接、元数据与响应暂存仍要共同受预算约束。缓冲预算与当前限制
把恢复和峰值计入成本¶
节点上的平均驻留规划量可写为：
S_fixed 包含系统和共享服务，P_headroom 为活动峰值、同时恢复及临时复制保留空间。前后的可用预算相同时，才得到表中的倍率；共享引擎或恢复余量增加时，还要乘以前后可用预算之比。等待阶段错开、恢复准入和硬预算共同决定实际可部署容量。
卸载与恢复也会增加任务时间。现有同一历史静态批次中，raw 卸载操作为约 44–98 ms；随后包含恢复、64 MiB 数据摘要及写入／fsync／读回校验的完整任务，相比不卸载增加约 156–178 ms。这是后台编译环境中的单次观察差值；它既不是独立 resume 延迟，也不是尾延迟保证。计时定义与数据
若端到端任务时间增加比例为 delta，分别按原方案与新方案的完整任务计算平均驻留，每次完成任务的内存时间成本比例为：
m1 必须包含恢复和排队期间的驻留；延迟改变阶段占比时，需要重新计算 f、r、h。例如再假设中性情景的全程平均驻留比仍为 49%，任务慢 5%，成本比例为 49% × 1.05 = 51.45%，约节省 48.6% 的内存时间。这只估算 Agent 执行侧的内存成本；节点数能否同比减少，还取决于 CPU、存储、网络和模型配额等约束，模型 token 费用另计。
恢复带宽也要满足“每秒唤醒次数 × 每次实际读回字节数 ≤ 可用恢复带宽”，卸载写出有同样约束。集中完成的 I/O 需要排队恢复，排队延迟进入端到端统计。因此，稳态承载倍率、任务吞吐与恢复尾延迟需要分别报告。
与已有 VM 优化如何比较¶
现成的 VM 路线本身也有内存优化。DSec 在真实 agentic-RL 负载上，使用 virtio-pmem + DAX 使宿主峰值内存降低 40.2%；DAMON + balloon 空闲页报告单独使时间积分内存降低 21.2%，峰值基本不变。DSec，v1，§8.4、图 12
这些机制分别减少重复缓存和空闲页；pVisor 的核心攻关，是让宿主接管仍需推进的 I/O，从而扩大整个 guest 可卸载的有效窗口 f，同时控制新增开销 h。microVM 可以提供底层暂停、卸载和恢复原语，这条路径还需要 I/O 所有权转移、完成事件与恢复调度。
后续对照需要保留已有共享与回收能力，在同硬件、同镜像、同负载、同正确性与延迟约束下比较增量收益。DSec 的两项收益、pVisor 的静态卸载比例和上面的容量估算，各自有不同基线，不能直接相加或相乘。
从一次透明等待跑通整条路径¶
先选定一种 I/O，验证“接管请求 → 安全卸载 → 宿主继续推进 → 事件唤醒 → 原调用返回”的完整路径，再扩展到流式响应和更多工具。验证同时看调用语义是否保持，以及计入宿主缓冲、卸载和恢复成本后，固定资源能否支撑更多有效执行。
原型需要逐项收敛已有测算中的假设：
| 需要记录的数据 | 用来确认什么 |
|---|---|
| 原方案的驻留曲线、共享服务与整节点缓存 | m0 和实际可用节点预算；共享页面只计一次 |
| I/O 交接、RAM 引用排空、实际回收、开始恢复的时间 | 有效窗口 f；转换过程不计为已回收时间 |
| 卸载残留、宿主缓冲、队列、页缓存及临时副本 | 原驻留释放比例 r 与新增开销 h，避免内存只是换了位置 |
| 同时唤醒数、读写字节、活动／恢复峰值和恢复至首次有效执行的延迟分布 | 恢复余量、带宽及排队是否允许预计承载量；尾延迟需要足够样本 |
| 原调用的输出、错误、顺序、同步、取消，以及任务完成数和端到端延迟 | 增加的执行上下文能否保持正确并完成有效工作 |
现有基础包括受控文件与网络路径、暂停与内存卸载原语，以及实验性的宿主写缓存；自动识别等待、接管 I/O、完成唤醒与恢复调度仍需贯通验证。等待与卸载实验、Agent I/O 完成机制