Pysolate 面向云端大规模 Agent 执行，将短时 Python 计算和工具编排放在可嵌入、低驻留成本的隔离层中。任务状态独立保存，完整工具链按需使用。目标是在相同 CPU、内存预算下推进更多任务，并保持可接受的完成时间。
这是当前的项目定位。本文中的云端负载是设计假设；轻重环境交接是后续方案。现有实现与实验依据见第五节。
1. 部署假设与工作负载
我们假设大量自主 Agent 在云端运行，本地设备主要负责交互。任务可能持续数小时，平台统一提供模型、工作区、工具与执行资源。
一个任务反复经历模型推理、文件读写、外部查询、结果处理、构建与测试。各阶段需要的能力不同，所需资源也会变化。我们优先面向大量轻操作、夹杂重执行的任务群，保留数据处理较重和长驻服务的情况作为能力与成本边界。
值得覆盖的操作包括：
- 文件与文本操作：读取局部文件、搜索、应用 patch、批量修改、整理 JSON 配置、比较输出。通常短小、一次性，状态主要在文件里。本地读取很快时，执行准备、文本处理和数据复制可能比等待更贵。
- 远程工具编排：查询多个 API、获取搜索结果、等待远端执行后合并结果。Host I/O 等待期间，Python 栈和局部对象可能仍需驻留；大响应返回后会出现解析与分配突发。
- 完整环境执行：Node 测试、编译、浏览器检查、依赖原生扩展的程序。它们需要工具链、子进程或更完整的 OS 能力。
- 长驻服务：开发服务器、数据库、浏览器会话及 watch 进程。持续保留环境有实际用途，不能按一次性脚本处理。
负载比例、响应大小和重复执行间隔要从任务轨迹中测量。小计算加固定等待可用于机制实验，真实任务评价还需覆盖多文件操作、缓存复用、集中唤醒和少量重请求。
2. 任务状态与执行实例分开
拟议的组织方式如下：
任务状态：工作区、进度、调用记录、授权
│
├─ 模型推理：保留任务状态，已结束的 Guest 释放
│
├─ Pysolate：短 Python 计算、文件操作组合、工具编排
│ ├─ 等待 Host I/O：保留必要的执行状态
│ └─ 本轮结束：释放 Guest 私有状态
│
├─ 容器 / VM：构建、测试、原生依赖、应用运行
│ └─ 结果与文件变更回到任务工作区
│
└─ 长驻服务：按任务需要保留，并单独计账例如，Agent 修改一个 Node 项目：几轮 Pysolate 执行完成文件读取和批量编辑；随后通过显式 Host 工具申请完整环境运行测试；测试返回日志、退出码和文件变更，Agent 再继续编辑。模型在两轮操作之间思考时，通常只需保留任务状态和工作区。
依赖镜像、包缓存和构建缓存可以独立于容器进程保留。连续验证可复用环境，较长空闲期再回收。具体保留时间由启动成本和调用间隔决定。
Pysolate 也不需要接管每个简单工具。固定的 read_file、apply_patch 可直接由 Host 提供；一段 Python 需要组合多文件、多步骤或多个工具时，受限执行层更有用。第一版可由调用方明确选择轻重执行入口，暂不推断任意 shell 命令能否迁移，也不在失败后自动换环境重跑。
3. 资源收益怎样发生
我们关注两种驻留成本。
操作之间的驻留。 执行结束后释放 Guest，重环境在适合时回收，任务状态继续保存。省下多少取决于环境实际保留的进程、缓存和空闲时间；空容器与运行着工具链服务的容器要分别计量。
操作内部的驻留。 Python 调用 Host 工具并等待时，通常需要保留栈和对象。共享初始化页、减少实例元数据和降低 COW 写放大，可以让同一内存预算容纳更多在途请求。
一个用于判断瓶颈的近似模型：每请求 CPU 时间为 c，外部等待时间为 w，平均驻留增量内存为 m，可供 Guest 使用的内存预算为 M，CPU 核数为 P。在请求同质、等待可重叠且尚未出现明显排队时：
内存允许的并发 ≈ M / m
填满 CPU 所需的并发 ≈ P × (c + w) / c
吞吐容量估计 ≈ min(P / c, M / [m × (c + w)])M 需要先扣除共享底座、Host、任务工作区和其他服务的占用。实际内存随执行阶段变化，评价时还要测量并发峰值。
希望验证的因果链是：每 Guest 内存下降，在同预算下容纳更多 I/O 请求，填补 CPU 空隙，提高有效吞吐。CPU 已饱和时，继续增加并发可能只增加排队。模型等待发生在 Guest 外部时，应计算任务状态的成本，不能算作 Guest 驻留收益。
主要评价指标为固定资源下按时、正确完成的任务数，辅以任务完成时间、全服务 CPU、峰值物理内存和内存时间积分（MiB·秒）。Guest 内存斜率是其中一项机制指标。
4. 轻重执行交接的必要约定
工作区交接决定混合方案能否成立。每次复制整个仓库或重新安装依赖，可能抵消驻留收益。
- 版本一致：重环境明确读取哪个工作区版本，结果绑定该版本。最小方案先串行编辑与验证；并发修改和合并留待实际需求。
- 文件变更：保留路径、内容及操作需要的文件元数据，区分应回传的修改、缓存和临时产物。源码快照不能代替应用进程状态。
- 权限与资源：Host 按当前任务授权文件、网络和重执行能力。Wasm 的隔离收益取决于这些工具实际暴露的能力。
- 失败语义：执行停止、文件变更和远端副作用分别记录。结果未知时先核对，避免自动重试造成重复写入。
- 完整计账：工作区存储、Host 缓冲、容器准备、缓存、数据搬运和回收峰值均纳入比较。
当前不扩展 Pysolate 去兼容 Node 或任意原生工具链，也不先实现透明容器迁移、通用挂起恢复或固定计算信号量。Go 调度、请求边界让出和现有取消路径先作为执行基线；新增调度策略需要明确的瓶颈证据。
5. 现有工作如何支撑这个定位
Spine 当前实现
Go/wazero 承载真实 CPython Wasm。每次 Run 有独立 Guest 与运行状态，Python 通过 Host ABI 调工具；Runner 复用编译产物。Prepared full-copy 与 Linux COW 提供初始化状态复用。入口见 执行流程、Prepared 和 COW。
PLM 尝试在明确依赖与工具约定下提前发起独立读取，是计算与等待重组的已有例子。其机制可供后续设计参考，收益按具体工作负载判断。Prefix 保留在教学实现中，当前不继续扩展。
独立实验与原版能力
内存优化历程 记录引擎元数据共享、INIT/EXEC 分配、pymalloc 与物理页粒度的实验。这些优化使用独立 runtime，集成状态以对应报告为准。
运行成本实验 包含请求生命周期、Host ABI、调度公平性、稀疏取消检查与服务恢复证据。已有数据回答局部成本与取舍；云端混合任务容量仍需端到端实验。
原版 Pysolate 的 Workspace 快照、diff 与变更导出已有演示。它们可以作为工作区交接基础；Spine 尚无完整的容器生命周期与交接实现。
生成代码复用保留为旁支探索。当前投入优先放在执行成本、内存密度、Host 扩展与计算重组。
6. 接下来的验证顺序
先完成已有统一 Native/Pysolate 基准，固定版本、工作量和统计口径，明确内存、CPU 与尾延迟的基本成本。该基准的短请求结果与完整 Agent 任务评价分别报告。
然后收集或执行一条可重复的自动编码任务轨迹：读文件、编辑、查询、运行测试、读取结果、再次修改。记录操作间隔、数据量、工具链需求与工作区变更。合成到达模型用于改变负载强度，保持每个任务的依赖和原有工作量。
在固定 CPU、内存预算下比较：
- 每任务常驻完整环境。
- 按需启动并可回收的容器池，保留依赖与构建缓存。
- Pysolate 完成轻操作，完整环境承担重执行，并采用同样的缓存与合理空闲回收策略。
三组执行相同工作，校验最终文件、测试结果和副作用。测量任务完成率与 p50/p95/p99、全服务 CPU、内存时间积分、峰值内存、准备与交接时间、传输字节数及同时推进的任务数量。等待型路径另外记录工具完成到 Python 恢复的延迟。
扩展负载时改变重执行频率、I/O 时长、响应大小和到达突发，观察收益在哪些条件下消失。完整环境频繁使用、依赖热状态难以复用或交接成本过高时，保留重环境可能更划算。
只有发现具体瓶颈后，再选择下一项实现：等待中 Guest 的冗余内存、工作区增量交接、大结果的重复表示、Host 批量处理，或集中唤醒后的调度问题。优先交付一个能测出净收益的小机制。