两核、2 GiB 预算能同时完成多少个工具任务？¶

主要结论¶

在两核、2 GiB、禁用 swap 的共同预算下，stage 与 Podman 都在 32 路 Python/Git 任务中通过全部五轮；pVisor VM 在 16 路通过全部五轮，32 路只有三轮全部通过。stage 的空闲探针达到 128 路，Podman 达到 64 路；空闲容量不能代替活跃任务容量。

Motivation¶

多个 Agent 同时执行时，成功完成多少任务比创建多少环境更有用。容量规划还要计入运行时、辅助进程、页缓存和 VM backing，不能用单个进程 RSS 或配置内存推算。

实验设计¶

Linux/x86_64 上比较原生进程、pVisor stage、pVisor VM 和 Podman 5.8.7。每批使用独立 cgroup：共同两核配额、CPU 0/1 亲和性、2 GiB 内存上限、零 swap；协调器、payload 和辅助进程包含在预算内，Podman payload/conmon 的归属经过检查。VM 每个配置 2 vCPU/256 MiB，仍受共同总预算限制。

并发扫描 1、2、4、8、16、32、64、128，每格五个新批次，无预热；每轮随机交替条件。所有任务先到 stdin readiness barrier，再共同释放。空闲组使用同一 Python 环境但不分配数据或改文件；工具组每任务触碰并校验全部 32 MiB 私有数据，在 64 文件 Git 仓库修改四个文件，执行 git status 并校验全部文件。stage/VM 的原工作区保持不变，结果与独立 Run 记录匹配。

主指标为整个 cgroup 的物理内存计费，包括已计费页缓存、内核内存和私有 backing。预先准备的共享工具/镜像缓存可能在父 cgroup 计费，因此这不是整机净内存排名。每批都记录失败、未知结果和 OOM；只有全部任务校验通过且没有 OOM 的批次进入内存/耗时摘要，保留所有慢样本。五轮不能建立长期可靠性或尾延迟保证。负载不包含模型推理、大型编译或真实 Agent CLI。

实验数据和分析¶

测量日期 2026-10-06（本地时间）。共 320 个批次，其中 263 个记录为全部通过，57 个失败；所有批次进入容量统计。内存为 readiness barrier 时 memory.current 的 P50，单位 MiB，仅由完整、无 OOM 批次计算；不足完整批次标为“—”。

Python/Git 工具任务¶

stage 和 Podman 在 32 路均完成 160/160 个任务；它们在 64/128 路都有 OOM，不能凭部分完成任务宣称达到该并发容量。VM 在 32 路完成 138/160 个任务，只有 3/5 完整批次；更高并发的启动或完成失败同样保留，不能都归因为 OOM。结果未知表示没有保留到可校验的完成证据，不视为成功或零耗时。

空闲环境¶

stage 在空闲 128 路通过五轮，但相同环境加入私有数据和 Git 工作后，最高全部通过的已测级别是 32 路。两种负载分开规划；测量的离散级别也不是精确最大容量。

暂停后的压缩快照与容器 pause 容量尚未完成验证，不能由快照文件大小或单 VM 回收量推算。Firecracker/QEMU 的同预算密度未测；它们的单任务延迟见端到端任务。macOS 的对应容量未测。

数据下载与复现¶

完整并发扫描 CSV · 制品、预算和证据摘要 · 比较方法 · 复现手册

整理表保留每个条件的尝试数、完整批次数、失败原因、未知数、OOM、观察范围和来源摘要。原始报告、日志、输入清单及源码/二进制留在本地 .data/；没有将失败批次移出容量统计。