一句话：智能体跑在隔离的 MicroVM 里，内存怎么收是个被忽视的工程难题
arXiv 2609.40082 提出的 Tide，盯上了一个智能体平台工程师天天碰到、却很少有人系统研究的细节：云上智能体通常每个任务跑在一个隔离的 MicroVM 里，而负责编排的 harness 循环在等待模型推理时几乎空闲，等到真正执行某个工具时，内存需求才在运行时才暴露出来。这种「一会儿闲、一会儿猛」的节奏，让宿主机很难判断该回收哪块内存。Tide 的解法是让客户机主动把每个阶段的内存意图上报给宿主机，由后者精确回收——在不改变客户机容量的前提下，把内存管理从「猜」变成「知会」。
传统回收为什么在智能体场景会选错页
现有的内存回收思路，大多根据访问频率和内存占用 footprint 来推断该回收什么。但问题是，客户机内的分配器会把「空闲的 harness」和「短命的工具」放在同一批物理页上。于是回收器要么选错页（回收了工具正要用的），要么锁定一个不合适的容量，要么只回收了大页的一部分、把它拆成了碎片。论文用一句话点出根因：回收器在「猜」内存会怎么被用，而真正知道每一步意图的，是跑在客户机里的 harness 自己。让不知道的人去猜，自然容易猜错。
Tide 的做法：让客户机自己上报内存意图
Tide 的核心洞察是，harness 其实清楚每个阶段的内存意图——哪块内存、什么时候用、内容是否必须跨阶段存活。既然如此，不如让客户机把这份意图作为一块「独占的客户机物理区域」上报给宿主机，由宿主机直接回收。为此，论文引入了一个叫 arena 的抽象，配合一套用户态接口来管理带独占意图的内存；客户机内核的分配器则把这类独占分配聚拢到按大页对齐的区段里；再往上，一层 hypervisor 扩展把这些区段解析回宿主机的后备内存并应用上报的动作，而客户机容量保持不变。简单说，客户机不再被动等回收，而是主动告诉宿主机「这块我现在用完了，你收走吧，且不会动到我还活着的那部分」。
实验怎么说：在真实轨迹上优于已有方案
论文在录制的智能体执行轨迹上做了实验，结论是 Tide 优于当前先进的回收机制，同时开销很低。它的优势不靠堆复杂度，而靠「信息在正确的位置」——内存意图本来就只有客户机知道，把它显式传递出来，回收就不再是猜谜。对跑大量长任务、并发任务多的智能体平台，这类底层优化直接影响单台宿主机能稳定承载多少智能体，也就是平台的成本结构。在模型调用之外，运行时效率正成为智能体基建的另一条利润线。
它和「记忆」类研究不在一个层面
同一时期关于智能体记忆的工作很多，但 Tide 和他们不在同一层。Mem++、PoS、BudgetPM 关心的是「智能体该记什么、何时去核验」，属于算法与认知层面；Tide 关心的是「智能体运行时占的那块内存怎么高效管」，属于系统与虚拟化层面。一个在想「脑子怎么用」，一个在想「身子怎么养」。两者都对长期运行智能体至关重要，只是解决的问题相隔了一个抽象层级。对平台方，Tide 这类工作往往比单个记忆算法更能直接撬动成本和稳定性。
增量认知：智能体的效率瓶颈正在下沉到系统层
Tide 透露出一个会被反复验证的判断：当智能体从演示走向规模化生产，性能瓶颈会一路下沉——从模型能力，到编排与记忆，再到运行时与虚拟化。谁能把每一层都理顺，谁就能用更低的成本跑更多的智能体。过去我们谈智能体优化，眼睛总盯着 prompt 与模型；未来，arena、回收器、调度器这些「看不见的 plumbing」，会越来越多地决定一个智能体平台的生死线。
边界与展望
需要标注：Tide 的评估基于录制的智能体轨迹，其收益在所给负载特征下成立；面对形态差异极大的任务混合或极端短任务，回收策略的边际收益可能变化。此外，arena 抽象要真正落地，需要客户机内核与 hypervisor 协同改造，工程成本不低。后续值得跟踪的，是这类机制能否被主流智能体运行时采纳为标准能力，以及它和容器、函数计算的既有内存管理如何共存。
结语
智能体的「聪明」常被归功于模型，但能不能便宜又稳地跑起来，往往取决于 Tide 这类底层细节。当行业开始认真研究「MicroVM 里那块内存该怎么收」，恰恰说明智能体已经从玩具，长成了需要被当成系统来精心养护的基础设施。