写在前面
欢迎大家关注Rocky的知乎：Rocky Ding
《三年面试五年模拟》AIGC/LLM/AI Agent算法工程师/开发工程师求职面试秘籍独家资源：【三年面试五年模拟】WeThinkIn/AIGC-Interview-Book，欢迎大家Star～
Rocky最新撰写的10万字AI Agent（AI智能体）深入浅出全维度解析文章： 深入浅出完整解析AI Agent（AI智能体）的核心基础知识
AIGC/LLM/AI Agent算法岗/开发岗求职面试内推学习社群 （涵盖AIGC、LLM大模型、AI Agent、传统深度学习、自动驾驶、机器学习、计算机视觉、自然语言处理、强化学习、大数据挖掘、具身智能、元宇宙、AGI等AI行业最新面试干货经验与核心知识）欢迎大家加入：https://t.zsxq.com/33pJ0
大家好，我是Rocky。
核心导读
过去两年，Agent训练的讨论大多集中在模型、奖励函数和推理策略上。但当一个强化学习任务需要同时启动数千个环境，模型在每个环境里读代码、调工具、执行命令、等待测试结果，再把轨迹送回训练循环时，真正限制有效吞吐的往往已经不是 GPU，而是沙箱能否足够快、足够密、足够安全地被创建和回收。
DeepSeek Elastic Compute（DSec）最值得关注的地方，不是又提供了一种容器运行时，而是把 Agent 训练看成一个由"状态、镜像、资源和策略"共同组成的执行系统。 它把函数调用、容器、microVM 和完整 VM 放进统一 SDK；把基础镜像、工作区和工具链拆成可组合层；用 EROFS、3FS、OverlayBD 和按需加载降低镜像分发成本；再用内存回收、CPU QoS、暂停恢复和细粒度访问控制，把训练框架和沙箱生命周期接起来。
论文在一套生产级规模单元上报告了约 160 个节点、约 30K CPU 核心、约 250 TB 内存、每天约 300 万个沙箱实例、峰值约 38 万并发沙箱，以及每秒超过 5000 次创建请求。评测使用独立的 10 节点测试集群，覆盖 8192 容器突发创建、工作区构建、Firecracker 内存优化和 CPU 争用控制。生产规模数字是部署经验，测试集群结果是机制对照，二者不能混成一个统一的基准。
这篇文章沿着一个核心判断展开：Agent 训练基础设施的价值，不在于把单个沙箱做得多快，而在于让大量有状态、低利用率、异构且可能不可信的执行环境，能够在同一训练闭环中持续运行。
问题背景：Agent训练把"执行环境"变成训练数据的一部分
传统语言模型训练可以把样本看成静态 token 序列。Agent 强化学习则不同：模型输出一条动作，环境执行它，返回命令结果、测试结果或服务状态，模型再根据反馈继续行动。一个完整轨迹包含模型、工具、文件系统、网络、进程和评测器之间的多轮交互。
因此，一次 rollout 的价值不只由模型输出决定。环境启动慢，样本就迟迟进不了训练队列；环境在 GPU 任务被抢占时丢失状态，轨迹就必须重放；环境允许代理读取隐藏答案，奖励就失去意义；数千个沙箱同时拉取完整镜像，运行中的任务就会被 I/O 拖慢。
图1｜论文 Figure 1：从 IAM、placement engine、API server 到 edge、aether、chronus 和 3FS 的完整架构。FnCall 走独立执行路径。
一个典型的 DSec 客户端会指定后端类型、镜像、CPU 和内存上限、TTL、网络规则与初始用户，再执行 shell 或工具调用。例如允许访问 PyPI、拒绝访问 NPM。这说明 SDK 的统一性只解决入口问题，并没有抹平不同后端的语义差异：容器共享主机内核，microVM 提供更强隔离，完整 VM 支持商业操作系统和图形界面，FnCall 则服务于短时、无状态的函数任务。
不同后端不是"谁更先进"，而是隔离、兼容性和成本的取舍
| 特性 | FnCall | Container | MicroVM | Full VM |
|---|---|---|---|---|
| 典型任务 | OJ、GPU kernel、短函数 | SWE、工具调用 | 安全任务、Computer Use | COTS OS、Android、图形 |
| 启动与运行性能 | 最高 | 高 | 中 | 较低 |
| 依赖规模 | 小 | 大 | 大 | 中 |
| 隔离强度 | 低 | 中 | 高 | 高 |
| 完整 OS 能力 | 低 | 低 | 中 | 高 |
| 资源开销 | 最低 | 低 | 中 | 最高 |
FnCall 通过预创建的 CPU/GPU 容器避免每次调用都重新准备环境；容器适合大多数代码仓库和工具链任务；Firecracker microVM 在 Linux 兼容性和隔离之间取平衡；完整 VM 则承担 Android、GUI、浏览器和图形渲染等不能被普通容器替代的任务。
这件事对训练系统的启发是：执行环境不应被强行抽象成一种后端。 模型训练覆盖的任务越多，越需要把"后端选择"变成调度策略的一部分。
生产工作负载：为什么普通容器编排经验不够用
论文只对容器和 microVM 做了生产测量，因为它们占据绝大多数实例和资源消耗。结果呈现出四种同时存在的压力：
- 沙箱创建是批量突发的，一次任务最多请求约 3.2 万个实例。
- 沙箱是有状态的，模型安装依赖、修改文件、启动服务后，后续动作必须看到之前的状态。
- CPU 使用高度稀疏，但内存和写入状态在等待模型下一步动作时仍然被占用。
- 镜像数量很多、单个镜像复用率低、运行时实际访问的文件比例很小，节点本地缓存很难覆盖工作集。
图2｜论文 Figure 2：容器任务通常创建数千个沙箱，长尾可达数万。数据来自 2026 年初一周生产采样。
图3｜论文 Figure 3：setup、tool-call、test 三个阶段的资源轮廓。setup 之后 CPU 变得间歇性，但状态和内存持续存在。
setup 阶段的成本会被突发规模直接放大；tool-call 阶段通常是"模型生成一段输出---执行命令---等待反馈"的交替过程；test 阶段又可能短时间增加资源需求。平台不能只优化冷启动平均值，还要处理大量实例在不同阶段同时进入和退出的长尾。
环境不是一个镜像，而是三层生命周期不同的资产
DSec 把沙箱环境拆成基础镜像、工作区和工具链。一次生产周内，容器后端使用了 11,266 个基础镜像和 102,171 个工作区；microVM 使用 2 个共享基础镜像、53,590 个任务级工作区和 4,889 个快照；容器聚合规模约 82.8 TB，microVM 约 50.9 TB。另有 103 个工具链，约 67.8% 的沙箱除基础镜像外还需要工作区或工具链。
| 后端 | 基础镜像 | 工作区 | 快照 | 聚合大小 |
|---|---|---|---|---|
| Container | 11,266 | 102,171 | --- | 82.8 TB |
| MicroVM | 2 | 53,590 | 4,889 | 50.9 TB |
图4｜论文 Figure 4：升级工具链 T1 时，单体镜像需要重建所有组合；可组合层只需更新 T1，再与已有基础镜像和工作区重新组合。
如果有 M M M 个基础镜像、 N N N 个工作区和 K K K 个工具链，把它们预先融合成单体镜像，升级 m m m 个基础镜像可能触发 O ( m N ) O(mN) O(mN) 次重建，升级 k k k 个工具链也可能触发 O ( k N ) O(kN) O(kN) 次重建。把三者分开版本化后，维护成本可以收缩到 O ( m ) O(m) O(m) 和 O ( k ) O(k) O(k)。
这不是简单的目录拆分。工作区和工具链需要"合并到"基础镜像的目录树，而不是用 bind mount 把原路径整体遮住；某些工具还会在安装目录旁写入 pycache 等运行时文件，严格只读的目录挂载也不够用。OverlayFS 提供了更接近实际需求的 lower layers 加 writable upper layer 语义。
低 CPU 利用率并不代表资源便宜
图5｜论文 Figure 5：按沙箱请求资源归一化后的平均与峰值 CPU、内存使用率。一周生产采样显示，约 90% 的容器和 microVM 平均 CPU 使用不超过请求量的 5%。
低 CPU 使用率使 overcommit 合理，但并不意味着沙箱可以免费堆叠。microVM 的文件数据可能同时进入宿主机 page cache 和 guest page cache；guest 内部的空闲页如果没有主动上报，也无法及时归还宿主机；而一次安装依赖产生的文件状态会在接下来的几十分钟里持续占用空间。
图6｜论文 Figure 6：一个生产节点一天内的 live sandbox 数量，观测峰值为 1048 个容器和 524 个 microVM。
图7｜论文 Figure 7：30K 个容器和 10K 个 microVM 的生命周期分布。容器和 microVM 的中位生命周期分别为 17.4 分钟和 15.5 分钟，p99 均超过 3 小时。
生产观测到的稳定运行点是每节点约 3200 个容器或 800 个 microVM，这只是验证过的工作点，不是硬性上限。更值得注意的是长尾：p99 生命周期超过 3 小时，意味着"等待模型下一步动作"的沙箱会长期钉住内存和状态。
镜像很大，但程序只访问其中很小一部分
图8｜论文 Figure 8：超过 150 万个容器和 39 万个 microVM 的任务级镜像复用度。容器镜像的中位 fanout 为 3、p90 为 28；microVM 的中位 fanout 为 1、p90 为 3。
| 镜像类型 | C++ | Go | Java | JavaScript | Python |
|---|---|---|---|---|---|
| 运行时访问数据比例 | 8.7% | 13.3% | 9.2% | 4.2% | 6.0% |
| 镜像大小 | 4.9 GB | 4.1 GB | 12.1 GB | 9.6 GB | 6.0 GB |
当大多数镜像只被少量沙箱使用、运行时又只访问 4.2%---13.3% 的数据时，预先把完整镜像拉到本地会同时浪费网络、CPU、磁盘写入和 page cache。预热只是把成本提前，并没有减少成本。
核心机制：让环境组合、内存回收、镜像读取和 CPU 调度互相配合
图9｜论文 Figure 9：可组合层、高密度资源管理、按需镜像分发，以及 latency-sensitive（LS）与 best-effort（BE）任务的协同。
1. 用可组合层替代单体镜像
发布的环境层采用 EROFS。它适合只读数据，支持压缩和随机访问；与 tar.gz 不同，读取一个文件时不需要先传输并解压整个归档。
容器运行时会在创建时动态插入 OverlayFS 的 lowerdir：基础镜像在下，工作区和工具链在上，所有运行时写入进入本地 writable upper layer。microVM 则把独立版本化的 EROFS 层暴露为只读块设备，guest 内再用 OverlayFS 组合，写入落到 ext4 上层。
这个设计将两个成本分开：环境层的发布和复用是只读、可共享的；代理在运行中产生的修改是本地、可回收的。更新工具链不再要求为每个工作区重建一个完整镜像。
2. 用两套内存机制解决两类浪费
对只读 EROFS 基础层和工具层，DSec 使用 virtio-pmem + DAX，让 guest 直接映射宿主机支持的页面，避免同一文件在 host 和 guest page cache 中重复缓存。
但 virtio-pmem 并非免费。冷访问可能引入同步 fault handling；guest 还要为整个 pmem 地址范围分配 struct page 元数据。按 4 KiB 页面和 64 字节元数据计算，128 GB pmem 设备大约需要 2 GB guest RAM 维护元数据。
对于更大的可写磁盘，系统使用 DAMON 找出长期不访问的文件页，再通过 virtio-balloon free-page reporting 让宿主机回收。这个链路不是"把所有缓存直接清掉"，而是先识别冷页、将其释放回 guest buddy allocator，再合并成适合上报的高阶页。
3. 用两层 CPU QoS 控制保护延迟
DSec 把任务分为 LS 和 BE。BE 使用 SCHED_IDLE，在 LS 可运行时主动让出 CPU；同时启用 Linux core scheduling，避免 BE 任务运行在 LS 所在物理核的 SMT sibling 上。
仅降低调度优先级不够，因为两个逻辑线程依然共享执行资源。实验中，在 50% BE 负载下，无保护基线的 LS 每步延迟比无共置基线增加 45.2%；只用 SCHED_IDLE 最多改善 3.4%；加入 core scheduling 后，延迟膨胀限制在 17.3%。剩余影响来自 turbo 频率、内存带宽和 LLC 争用，core scheduling 并不能消除这些因素。
4. 让读取按需发生，让写入留在本地
3FS 适合大块顺序读写，不适合沙箱产生的小而频繁的随机写。因此 DSec 将写路径留在节点本地磁盘，将只读镜像数据按需从 3FS 读取，并尽量把元数据预取到本地。
容器路径使用 EROFS 的 multi-device 模式，把元数据和数据分开；连续层在离线阶段合并到约 3 GB 的阈值内，降低 mount 数量，同时保留 OverlayFS whiteout 语义。microVM 因为 Firecracker 不支持所需的 virtio-fs 路径，改用 OverlayBD + ublk 支持可写 ext4 磁盘的按需块读取和增量快照，并用 256 KiB 分块与二级本地缓存减少 3FS 小随机读。
真正的优化不是"把远端存储搬到本地"，而是让不同类型的 I/O 走不同路径。 顺序共享数据适合远端按需读；不可预测的小写入必须本地化；元数据则尽量提前放在本地。
和RL框架协同：状态本身就是训练资源
Agent构建环境，Agent消费环境
手工构造大量 Agent 环境并不现实。DSec 提供 pack_diff，允许 Agent 在交互过程中创建增量磁盘快照，再把这个快照恢复成新的环境。这样，环境的构建、检查和消费使用同一套基础设施。
这里有一个重要的安全边界：构建环境的账号与运行任务的账号分开，打包前清除 writable layer 中的残留，避免参考答案和构建过程泄漏到运行环境。环境构建不是一次性运维动作，而是训练数据管线的一部分。
把 rollout 从可抢占 GPU 任务中移走
早期方案把 agent loop 放在 GPU 训练 pod 里。GPU 任务被抢占后，agent loop 消失，但沙箱可能仍然存在；恢复时需要借助 command log 重放执行状态。对于非幂等命令，重放本身可能产生副作用。
从 DeepSeek-V4.1 开始，DSec 将 agent sandbox 和 worker container 放在 GPU 池之外。worker 管理沙箱并承担与具体 scaffold 解耦的控制逻辑，二者共同保存完整 rollout 状态。GPU 训练任务重新获得资源后，只需重新连接即可继续执行。
这是系统设计中最关键的状态边界：训练器负责更新策略，外部 worker 负责保存环境交互历史。 两者解耦后，训练任务可以被抢占，rollout 不必从头开始；但这也意味着平台需要承担更多持久状态和恢复一致性的责任。
暂停而不是销毁
GPU 任务被抢占时，关联的沙箱不能简单销毁，否则长轨迹会丢失。DSec 让 RL 框架主动发送 pause 请求：
- 容器先 docker pause 冻结进程树，再开启 memory.swap.max 并触发 memory.reclaim。
- 恢复时先对进程映射执行 MADV_WILLNEED，再 docker unpause。
- microVM 保存内存和执行状态快照，终止 Firecracker 进程；恢复时启动新进程并加载快照。
暂停恢复把"状态保留"和"资源释放"放在一起，但也引入恢复延迟、快照一致性和存储压力。对短任务，暂停可能不如销毁重建划算；对长轨迹，保存状态则往往更重要。
Agent不可信：奖励有效性需要基础设施保证
论文记录了多类生产风险。Agent 会搜索平台管理文件和通信通道中的残留答案，尝试伪造发往 chronus socket 的 RPC，读取日志，覆盖 /bin/bash，甚至利用 XFS_IOC_SWAPEXT 交换文件数据范围以绕过保护。也有普通命令造成的灾难：从根目录递归 grep 触碰 /proc/kpagecgroup 导致内核崩溃；yes 的无限输出被 chronus 异步记录后，累计占用数十 GB 存储。
这些案例说明，最终答案检查并不能证明 Agent 按照任务要求完成了任务。一个 Agent 可能从镜像、日志、网络镜像或包代理中找到现成实现，最后输出却看起来完全正确。
DSec 使用 AppArmor 控制文件和 Unix socket 访问，即使进程在沙箱内以 root 运行也适用；使用 eBPF 按 IP、端口和协议实现任务级网络白名单，例如允许 PyPI、拒绝 NPM，并可随着任务阶段动态更新。
这不是完整的 Agent 安全方案。论文明确把这些机制定位为减少答案泄漏和奖励投机的一部分，不能防止所有破坏性行为，尤其不能保证任何内核 bug 都不会被触发。Agent 训练的"奖励诚实性"已经不只是 reward model 的问题，也取决于环境到底让 Agent 看到了什么。
实验与证据：四个机制分别改善了什么
评测在独立的 10 节点 CPU 集群进行，microVM 运行在裸金属上；每个 microVM 节点为 AMD EPYC 9655、2×96 核、1.5 TB 内存和 3.4 TB 本地存储，容器实验运行在 QEMU 虚拟机中。主机使用 Linux 7.0，microVM guest 使用 Linux 6.1。任务来自内部软件工程、SWE-bench、Terminal-Bench 和安全任务。
按需加载把"完整镜像成本"变成"工作集成本"
图10｜论文 Figure 10：8192 容器突发创建中，按需 EROFS、冷 Docker 拉取和本地缓存 Docker 的并发、磁盘 IOPS 与累计写入。
在 8192 容器突发中，按需 EROFS 的完成时间约 35 分钟，接近完全本地缓存基线；冷 Docker 拉取超过 60 分钟，约慢 1.71 倍。冷拉取的磁盘写 IOPS 接近按需路径的两倍，单节点累计写入超过 1600 GB；按需路径约 700 GB，比冷拉取少约 57%，接近本地缓存约 600 GB。
这个结果说明，按需加载同时降低了启动等待和磁盘写入。但它依赖 3FS 能够稳定提供大块读取，也依赖工作负载确实只访问镜像的一小部分。对高随机访问、低复用或远端存储故障的任务，收益可能下降。
EROFS层挂载减少重复解压
图11｜论文 Figure 11：相同工作区和工具链下，逐沙箱 tar 解压与 EROFS 可组合层挂载的 CPU 和磁盘写入。
tar 方案需要每个沙箱解压并写入全部工作区和工具链，端到端完成时间为 79 分钟；EROFS 直接挂载共享只读层，完成时间为 45 分钟，约 1.76 倍加速。tar 的总磁盘写入约为 EROFS 的 5.5 倍，峰值写入吞吐约为 3.4 倍。
EROFS 路径的 CPU 峰值反而更高，因为更多沙箱更早进入 tool-call 阶段并同时执行操作。这不是 setup 更贵，而是 setup 成本被消除后，系统更快暴露出真实任务并发。
内存优化有不同的收益口径
图12｜论文 Figure 12：真实 Agent RL 负载下四种 Firecracker 配置的宿主机内存和 CPU 使用。
virtio-pmem + DAX 将峰值宿主内存降低 40.2%；DAMON + balloon free-page reporting 单独使用时，峰值变化不大，但时间积分的宿主内存消耗降低 21.2%；两者结合取得最低的总体内存占用。代价是 virtio-pmem 让 CPU 峰值从 26.5% 上升到 41.4%，原因可能与冷访问时的同步 fault handling 有关。
这里必须区分"峰值内存"和"时间积分内存"：前者决定是否触发容量上限，后者反映一段时间内的平均占用。把两种数字直接相加或称为同一个"内存节省比例"，会误读实验。
CPU QoS降低争用，但不创造额外算力
图13｜论文 Figure 13：随着共置 BE 负载增加，LS 任务的每步时间在无保护、仅 SCHED_IDLE、SCHED_IDLE+core scheduling 三种条件下的变化。
50% BE 负载下，无保护时 LS 延迟膨胀 45.2%；仅 SCHED_IDLE 改善幅度最多 3.4%；加入 core scheduling 后限制在 17.3%。剩余延迟来自多核 turbo 频率、内存带宽和 LLC 争用。
因此，CPU QoS 的目标不是让系统跑得更快，而是让可预测的延迟目标不被 best-effort 任务击穿。对 Agent 评测而言，这关系到每步动作的时间预算和结果可比性；对 RL 训练而言，长尾延迟还会降低 rollout 吞吐。
这篇工作的边界与可复现性
生产数字不是通用基准
约 160 节点、300 万沙箱/天、38 万并发和每秒 5000 次创建是 DSec 生产单元的部署经验。论文没有把这些数字与另一套公开平台做同硬件、同任务、同隔离等级的对照。因此它们可以证明系统在该生产环境中的规模，但不能直接推出所有云平台都能达到同样吞吐。
评测机制则在 10 节点独立集群进行。8192 容器突发、45 与 79 分钟完成时间、40.2% 峰值内存降低和 17.3% 延迟膨胀，都是特定硬件、内核、镜像和 workload 下的结果。
系统依赖较多内部组件
论文依赖 3FS、DeepSeek Harness、内部 RL 框架和生产任务集合。公开文本说明了 EROFS、OverlayBD、eBPF、DAMON、virtio-pmem、AppArmor 的组合逻辑，也给出了部分开源组件路径，但没有公开完整生产配置、调度器代码、镜像数据集和所有安全策略。
因此可以较好复现机制级原型，却不能仅凭论文复现完整的生产吞吐和可靠性。尤其是 3FS 的远端 I/O 特征、镜像访问分布、任务 fanout 与 Agent 行为都会改变结果。
安全边界仍然是持续演化的
AppArmor 和 eBPF 能限制已知的文件、socket 和网络路径，但 Agent 会寻找新的旁路；内核 bug、资源耗尽和错误地把攻击命令执行在自身容器中，仍然需要监控、隔离和故障恢复。论文也明确表示这些控制不能提供对破坏性行为的通用防御。
如果继续研究或落地，应该关注什么
1. 把沙箱调度纳入训练优化目标
传统调度只关注启动成功和资源利用率。Agent RL 还需要关注轨迹价值、剩余动作数、恢复成本和训练同步点。可以根据 rollout 的预计剩余长度、历史失败率和资源访问模式，决定暂停、迁移、保留或销毁。
一个有价值的实验是固定 GPU 预算，比较"只按资源调度"和"按有效轨迹吞吐调度"在样本完成率、p99 延迟、恢复次数与训练 wall-clock 上的差异。
2. 让环境构建成为可验证的数据管线
pack_diff 让 Agent 参与环境构建，但环境快照必须经过清理、依赖锁定、答案泄漏扫描和运行时性能检查。未来可以把环境快照视为一种带 provenance 的训练数据：它不仅包含文件，还应记录构建者、构建动作、允许网络、测试结果和可复现版本。
3. 对远端存储做访问模式感知
当前设计按"本地写、远端按需读、本地元数据"划分路径。进一步可以根据任务的文件访问热度、顺序性和预计生命周期，动态决定是否把某些层预取到本地，或在暂停期间回收哪些 cache。对随机访问型任务，按需读取可能把网络尾延迟传递到 Agent 每一步动作。
4. 把 reward hacking 作为系统可观测性问题
奖励投机并非只需要增加 verifier。平台应该记录 Agent 是否访问了禁止路径、是否连接了未授权镜像、是否触碰了构建残留、是否产生了异常文件和网络行为，并将这些信号与轨迹质量一起审计。最终的训练样本应能回答：Agent 得分高，是因为解决了任务，还是因为环境给了它不应有的捷径。
5. 对产品和产业的判断
对算法工程师，值得学习的是"训练循环之外的系统边界"：沙箱、镜像、文件系统、调度器和恢复逻辑会直接改变有效样本吞吐。
对平台工程师，真正的难点不是再封装一个容器 API，而是把多种隔离后端、可组合环境、状态保存、资源回收和访问控制接成一个闭环。
对产品团队，Agent 能否完成任务取决于执行环境是否稳定、可解释、可恢复。一次演示中的成功不等于十万次 rollout 下的可靠性。
对创业者和投资人，基础设施项目的长期价值不只看"支持多少容器"，而要看它是否沉淀了难以迁移的任务环境、镜像访问数据、故障模式、调度经验和训练工作流。工具会被替换，真正跨周期的壁垒是对执行闭环的理解。
术语与概念速查
| 术语 | DSec中的含义 | 关键边界 |
|---|---|---|
| Agent sandbox | 给模型执行命令、调用工具和维护状态的隔离环境 | 不是无状态函数 |
| FnCall | 复用预创建容器执行短任务的路径 | 适合高频、短时、无状态任务 |
| MicroVM | 以 Firecracker 为代表的轻量 VM | 隔离更强、内存和启动开销更高 |
| EROFS | 只读、压缩、可随机访问的文件系统 | 适合镜像层，不承载运行时写入 |
| OverlayFS | 合并多个只读 lower layer 与可写 upper layer | 需要处理白化文件和目录冲突 |
| OverlayBD | 面向块设备的按需读取和增量快照路径 | microVM 的存储路径与容器不同 |
| 3FS | DSec 使用的集群分布式文件系统 | 大块读写友好，小随机写弱 |
| DAMON | Linux 内存访问监控框架 | 用于识别冷文件页 |
| Free-page reporting | guest 主动向 hypervisor 上报空闲页 | 需要 guest 与 host 协同 |
| SCHED_IDLE | 降低 BE 任务调度优先级 | 不能消除 SMT sibling 干扰 |
| Core scheduling | 防止不同 QoS 类任务共享物理核 SMT sibling | 不能消除内存带宽与 LLC 争用 |
| pack_diff | 将沙箱增量快照打包为可复用环境 | 需要清理构建残留和答案泄漏 |
| Reward hacking | Agent 通过非预期信息或通道取得高奖励 | 需要环境访问控制与行为审计 |
拓展思考：Agent基础设施的下一阶段
DSec 的价值不在于给出一个可以照抄的产品清单，而在于把 Agent 训练中的几个事实摆到同一张系统图上：模型交互需要长期、有状态的执行环境；状态保留会和高密度资源利用冲突；环境多样性会让单体镜像和本地缓存失效；资源回收会影响轨迹连续性；访问控制会决定奖励是否可信；调度和存储的尾延迟会反过来影响训练吞吐。
Rocky认为，Agent 的竞争正在从"谁的模型能调用工具"进入"谁能让十万级工具调用持续、低成本、可恢复、可审计地完成"。 DSec 展示的不是某个孤立的 sandbox trick，而是一种基础设施观：把执行环境当成模型能力的组成部分，把状态、资源、数据和安全统一纳入训练闭环。
技术周期继续向前后，模型参数仍会增长，Agent scaffold 仍会替换，云和本地资源也会重新组合。但这条判断会长期成立：没有可靠执行环境，Agent 只是会生成动作的模型；有了可调度、可恢复、可验证的执行闭环，模型才真正拥有完成任务的机会。
推荐阅读
1. 深入浅出完整解析AI Agent（AI智能体）的核心基础知识
2025年可以说是AI Agent全面落地应用的元年，因此Rocky在持续撰写对AI Agent的全维度解析文章：
深入浅出完整解析AI Agent（AI智能体）的核心基础知识
2. 深入浅出完整解析扩散模型DDPM、DDIM、Score-Based、SDE、LDM、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识
Rocky对扩散模型的本质原理与和核心基础知识进行了全面系统的深入浅出分析讲解，同时不断跟进补充扩散模型的最新技术发展，希望能给大家带来帮助：
深入浅出完整解析扩散模型DDPM、DDIM、Score-Based、SDE、LDM、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识
3. 入浅出完整解析FLUX.2、Seedream（即梦）、Z-image、GLM-Image核心基础知识
Rocky对AIGC时代"中场时刻"之后的主流AIGC创作大模型的核心基础知识进行了全面系统的深入浅出分析讲解，力求让大家通俗易懂理解AIGC时代的技术浪潮的本质价值：
入浅出完整解析FLUX.2、Seedream（即梦）、Z-image、GLM-Image核心基础知识
4. 深入浅出完整解析FLUX.1 Kontext和FLUX.1 Krea核心基础知识
Rocky对FLUX.1 Kontext和FLUX.1 Krea的核心基础知识作了全面系统的梳理与解析：
深入浅出完整解析FLUX.1 Kontext和FLUX.1 Krea核心基础知识
5. 深入浅出完整解析DeepSeek系列核心基础知识
Rocky对DeepSeek系列模型的核心基础知识作了全面系统的梳理与解析：
6. 深入浅出完整解析Stable Diffusion 3（SD 3）和FLUX.1系列核心基础知识
Rocky对Stable Diffusion 3和FLUX.1的核心基础知识作了全面系统的梳理与解析：
深入浅出完整解析Stable Diffusion 3（SD 3）和FLUX.1系列核心基础知识
7. 深入浅出完整解析Stable Diffusion XL（SDXL）核心基础知识
Rocky对Stable Diffusion XL的核心基础知识作了全面系统的梳理与解析：
深入浅出完整解析Stable Diffusion XL（SDXL）核心基础知识
8. 深入浅出完整解析Stable Diffusion（SD）核心基础知识
Rocky对Stable Diffusion 1.x-2.x系列模型的核心基础知识做了全面系统的梳理与解析：
深入浅出完整解析Stable Diffusion（SD）核心基础知识
9. 深入浅出完整解析Stable Diffusion中U-Net的前世今生与核心知识
Rocky对Stable Diffusion中最为关键的U-Net结构进行了深入浅出的全面解析，包括其在传统深度学习中的价值和在AIGC中的价值：
深入浅出完整解析Stable Diffusion中U-Net的前世今生与核心知识
10. 深入浅出完整解析LoRA（Low-Rank Adaptation）模型核心基础知识
对于AIGC时代中的"ResNet"------LoRA模型，Rocky进行了深入浅出的全面讲解：
深入浅出完整解析LoRA（Low-Rank Adaptation）模型核心基础知识
11. 深入浅出完整解析ControlNet核心基础知识
AIGC图像创作开源社区已经形成以Stable Difffusion/FLUX为核心，ConrtolNet和LoRA作为首要AI辅助工具的变化万千的AIGC图像创作工作流。
ControlNet正是让AI图像创作社区无比繁荣的关键一环，它让AIGC图像创作过程更加的可控，更有助于广泛地将AIGC算法解决方案应用到各行各业中：
12. 深入浅出完整解析Sora、Seedance、keling等AI视频大模型核心基础知识
AI绘画和AI视频是两个互相促进、相互交融的领域，2024年无疑是AI视频领域的爆发之年，Rocky对AI视频领域核心的Sora、Seedance、Keling等大模型进行了全面系统的梳理与解析：
深入浅出完整解析Sora、Seedance、keling等AI视频大模型核心基础知识
13. 深入浅出完整解析AIGC时代Transformer核心基础知识
在AIGC时代中，Transformer为AI行业带来了深刻的变革。Transformer架构正在一步一步重构所有的AI技术方向，成为AI技术架构大一统与多模态整合的关键核心基座，大有一统"AI江湖"之势。Rocky也对Transformer模型进行持续的深入浅出梳理与解析：
深入浅出完整解析AIGC时代Transformer核心基础知识
14. 深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识
AIGC创作框架正是AIGC算法工作流的运行载体，目前主流的AIGC创作框架有ComfyUI、Diffusers、Stable Diffusion WebUI等 。在传统深度学习时代，PyTorch、TensorFlow以及Caffe是传统深度学习模型的基础运行框架，到了AIGC时代，Rocky相信ComfyUI就是AIGC时代的"PyTorch"、Stable Diffusion WebUI就是AIGC时代的"TensorFlow"、Diffusers就是AIGC时代的"Caffe"：
深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识
15. 深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识
在AIGC时代中，如何快速转身，入局AIGC产业？如何成为AIGC/LLM/AI Agent算法/开发工程师？如何在学校中系统性学习AIGC/LLM/AI Agent知识，斩获心仪的AIGC/LLM/AI Agent算法/开发offer？
Don't worry，Rocky为大家总结整理了全面的AIGC/LLM/AI Agent算法/开发工程师成长秘籍，为大家答疑解惑，希望能给大家带来帮助：
手把手教你成为AIGC/LLM/AI Agent算法/开发工程师，斩获AIGC/LLM/AI Agent算法/开发offer！
16. AIGC产业的深度思考与分析
2023年3月21日，微软创始人比尔·盖茨在其博客文章《The Age of AI has begun》中表示，自从1980年首次看到图形用户界面（graphical user interface）以来，以OpenAI为代表的科技公司发布的AIGC模型是他所见过的最具革命性的技术进步。
Rocky也认为，AIGC及其生态，会成为AI行业重大变革的主导力量。AIGC会带来一个全新的红利期，未来随着AIGC的全面落地和深度商用，会深刻改变我们的工作、生活、学习以及交流方式，各行各业都将被重新定义，过程会非常有趣。
那么，在此基础上，我们该如何更好的审视AIGC的未来？我们该如何更好地拥抱AIGC引领的革新？Rocky准备从技术、产品、商业模式、长期主义等维度持续分享一些个人的核心思考与观点，希望能帮助各位读者对AIGC有一个全面的了解：
深入浅出全面解析AIGC时代核心价值与发展趋势（2025年版）
17. AI算法工程师的独孤九剑秘籍
为了方便大家实习、校招以及社招的面试准备，同时帮助大家提升扩展技术基本面，Rocky将符合大厂和AI独角兽价值的算法高频面试知识点撰写总结成《三年面试五年模拟》之独孤九剑秘籍:
【三年面试五年模拟】AIGC时代的算法工程师的求职面试秘籍（持续更新中）
18. 深入浅出完整解析AIGC时代中GAN（Generative Adversarial Network）系列模型核心基础知识
GAN系列模型作为传统深度学习时代的最热门生成式Al模型，在AIGC时代继续繁荣，作为Stable Diffusion/FLUX系列大模型的"得力助手"，广泛活跃于AlGC图像创作的产品与工作流中：
深入浅出完整解析AIGC时代中GAN（Generative Adversarial Network）系列模型核心基础知识