论文分析

Aries 论文解读

这篇论文的全称是 Rethinking AI Cloud Infrastructure for Agentic Serving Systems with the Aries Experimentation Framework。它不是一篇给出新调度算法或新推理引擎的系统论文，而是一篇 测量 + 问题重构 的论文：先造一个能看清智能体全栈行为的实验框架 Aries，再用生产轨迹和开源 harness 证明——今天这套以请求为中心的云 AI 基础设施，从指标、上下文、沙箱弹性到隔离模型，都不适合智能体服务。

一句话概括其主张：智能体服务的基本执行单元已经从“一次模型调用”变成了“一条跨模型、harness、持久上下文和工具沙箱的轨迹”；继续用 TTFT / TPOT / Token 吞吐去优化，会把真正决定任务进度的瓶颈优化掉。

图 1 是全文的坐标系。左边是传统 LLM 服务：提示词进、Token 出，调度和显存管理都围着当前这一次调用转。右边是智能体服务：harness 反复调模型、把工具打进沙箱、把结果写回后续提示词，并决定任务何时结束。一次用户请求可以跨越许多相互依赖的模型步与工具步。后文所有测量，都是在问：如果观测单元从请求换成轨迹，现有云基础设施会在哪些地方失效。

1. 它站在哪一层，回答哪一类问题

先把 Aries 放到栈上，避免把它理解成生产调度器或沙箱产品。

任务规格（做什么、何谓成功）          ← 与执行解耦
执行规格（harness / 模型 / 沙箱 / 遥测）
        ↓
Aries 运行器
  → LLM 后端适配器（如 SGLang）
  → harness（OpenHands / Hermes / OpenClaw）
  → 沙箱适配器（异构基底上的有状态工具执行）
        ↓
遥测收集器：把跨组件事件合成一条轨迹

Aries 的位置是 实验与测量层。它不替代 vLLM / SGLang，也不替代 AWS Lambda MicroVM 或 Google Agent Sandbox。它要补的是这些组件各自为政之后消失的那张图：任务有没有在推进、延迟和资源压力到底出在轨迹的哪一段。

论文认为现有评测正好切在这条缝的两边，谁也连不上：

于是出现测量鸿沟：语义上的任务进度，和跨层的系统执行，没有共同的观测对象。Aries 把这个对象定义为 智能体轨迹（agent trajectory）——服务单个用户请求过程中，LLM 调用、工具调用、工具结果与 harness 决策的有序序列。单个模型请求只是这条更大执行单元里的一步，不是独立事务。

这一点看起来像定义游戏，实际上决定了后面所有结论能不能成立。如果还按“一次 generate”计费、调度、评测，第 4 节测到的 harness 延迟、KV 占用膨胀、沙箱空闲突发，都会被当成应用层噪音而不是服务系统的一等问题。

2. Aries 框架：三刀切开测量鸿沟

图 2 里蓝色组件是专门为弥合测量鸿沟插进去的。框架本身有三项设计，对应三项挑战。

第一刀：任务规格与执行规格分离。
智能体框架常把“这道题怎么算成功”写进某个 harness 的逻辑里。换一个运行时组件，评测的任务可能在不知不觉中被换掉。Aries 把工作负载及其成功语义做成任务规格，把 harness、模型后端、沙箱、遥测栈做成执行规格，两边独立校验、再由适配器绑到具体栈。没有这一刀，就无法做“同一任务、不同沙箱/不同模型”的受控对比——而智能体系统研究最缺的就是这种对比。

第二刀：跨组件轨迹重建。
一次智能体运行会跨过模型、harness、沙箱这些独立管理的组件，重叠、失败、重试都有。组件本地日志和时间戳不够用来归因。Aries 在模型和工具边界传播轨迹与事件标识符，用统一事件模式记录因果和顺序，再把组件指标挂到这些事件上。没有这一刀，就只能说“这次任务慢”，说不清是解码慢、harness 编排慢，还是某个工具沙箱堵了。

第三刀：有状态工具执行的可移植观测。
工具作用在持久环境上，环境状态会影响后续轨迹；不同沙箱基底的生命周期和遥测接口又不一样。Aries 对环境设置、工具调用、状态连续性、结果收集和遥测挂钩做标准化，由适配器映射到具体基底。工具执行因此成为轨迹里一等公民的阶段，而不是“一次 RPC 返回了什么”。

这三刀合在一起，Aries 更像智能体系统研究的 实验操作系统：先保证任务没被偷偷换掉，再保证事件能串成因果链，最后保证工具阶段在不同基底上可比。第 4 节的四条结论，都建立在这个前提上。若没有 Aries，生产轨迹只能给出分钟级、匿名化的宏观画像，开源实验也无法把延迟拆到 harness / 工具 / 模型。

3. 四条结论分别在否定什么

第 4 节的标题是直白的：Why Is Modern Cloud AI Infrastructure a Poor Fit for Agents? 方法分两段：先看一条八小时工作日的生产轨迹（十个 LLM 服务实例的请求长度，100 个智能体沙箱的每分钟 CPU/内存），建立规模感；因为运维轨迹没有同步的跨层事件，再用 OpenHands、Hermes、OpenClaw，在 SWE-Bench Pro、Terminal-Bench 2、DeepResearch Bench 上各抽 20 个任务、重复五次，用 Aries 做受控拆解。默认模型是本地 SGLang 上的 Qwen3.6-35B-A3B-FP8，单机 96 核 + 一块 94 GB HBM 的 H100。

下面四条 Takeaway，最好读成对现有四个隐含假设的否定，而不是四条互不相关的经验数字。

3.1 否定“把模型调快，任务就快”

图 3 显示工具执行可占总延迟的 13%–48%，Hermes 在 Terminal-Bench 2 上到 48%；harness 编排还可再占端到端时间的最多 9%。图 4 更关键：LLM 延迟固然重要，工具调用却有跨越多个数量级的长尾。智能体在工具返回之前无法前进一步，所以这段主机侧时间不是“应用开销”，而是关键路径。

Takeaway 1 因此不是“工具也挺慢的”，而是：端到端任务时长在很大程度上取决于 harness 与工具沙箱，而不仅仅是模型推理。 继续把优化预算全部砸进 GPU 内核与 KV 缓存，会优化一个越来越不主导任务完成时间的子系统。

读这条时要注意口径：逐步计时在商业集群里过敏、拿不到，这条拆解来自开源数据集与 harness。生产轨迹只提供了“智能体上下文比对话请求大得多”这类宏观证据，并没有直接给出 48% 这个比例。把开源拆解外推到生产是合理假设，但不是同一张图上的同一组数。

3.2 否定“上下文越长越好，KV 留下即可”

传统 LLM 服务里，上下文寿命通常等于请求–响应循环，查询结束后可以回收 KV 页。长时程智能体则生成单调增长的历史，并贯穿整条轨迹。生产侧（图 5）已经看到：智能体每请求 KV 占用显著大于普通对话；在 Qwen3.6、固定 25 GB 预算下，最大驻留容量从超过 176 个并发请求掉到 40 个，约 4.4×。

受控扫描（图 6）把“更长是否更准”拆开了，这是本节最有信息量的结果：

• OpenClaw 在 DeepResearch Bench 上于 160K 达到 95% 峰值成功率，这一点恰好对应上下文溢出被消除。
• Terminal-Bench 2 与 SWE-Bench Pro 在溢出压力消失后趋于平缓甚至下降，最佳窗口是中小上下文，不是最大窗口。

也就是说，存在任务相关的上下文充分性阈值。超过阈值后，多留的历史主要在锁 GPU Token 池，而不是在买精度。32 个并发、256K 上下文的压力测试进一步显示：积压存在，但 Token 池利用率冲到 97%，引擎中位数只能维持 22 个并发，调度器开始抢占，p95 内部排队 7.9 秒。

Takeaway 2 的系统含义是：上下文管理不能再是引擎里被动的“能留就留、满了再压”。它必须变成轨迹感知的控制面决策——估计这段历史对后续步骤的效用，决定压缩、分层放置还是迁移。论文在第 5.2 节把处方写出来了，但 没有给出如何估计“未来效用”的方法。那才是把这条结论做成系统时最硬的问题。

另一个容易被忽略的点：他们为了做精度研究，把 OpenClaw 的任务成功率标定在 50% 附近再采样。这能让上下文扫描看得到上升和平台，但也意味着结论对“已经很强、很少溢出”的模型/harness 组合，幅度会变小。

3.3 否定“有状态缩至零已经能回收沙箱空闲”

智能体把 CPU 处理引进了关键路径：模型推理时沙箱往往空转，工具一来又出现短促的 CPU/内存尖峰。静态按峰值供给会在大部分时间里把资源闲置在那里。AWS Lambda MicroVM、Google Agent Sandbox 等用快照捕获/恢复（C/R）做有状态缩至零，看起来正好对上这种空闲–突发模式。论文要证明的是：模式对上了，经济账没对上。

生产侧每分钟采样已经呈尖峰；开源侧每秒采样把形状画得更清楚：轨迹的大部分时间里 CPU 空闲超过 80%、内存空闲超过 50%；一旦条件限制在“正在进行工具调用”，空闲比例都降到 20% 以下。沙箱不是低利用率的常驻服务，是 大部分时间闲着、一工作就突发 的执行器。

然后他们对记录的工具调用轨迹，按 AWS Lambda MicroVM 计费模型做解析式重放，扫描不同保活超时：

• 每次工具调用后拆掉沙箱：实例成本可降 65%，但反复快照 C/R 把客户总成本推到持久基线的 4.9×。
• 保活更久：C/R 下降，空闲时间上升。
• 理想系统（能回收空闲、又不付今天这种 C/R 税）相对持久沙箱，总成本有约 3× 的下降空间。

Takeaway 3 因此是一个定价与机制的指控，而不只是利用率画像：用户和云厂商都有缩短保活的动机，但当前快照机制把人逼进“为闲置付费 vs 为反复快照付费”的假选择。弹性是必要的，今天的 C/R 不是那条弹性该走的路。

读这条时必须记住：3× 和 4.9× 来自计费模型上的解析重放，不是他们真的实现了一个理想弹性系统再测出来的。DeepResearch 因工具 CPU 低被排除，说明结论对“重执行型工具”（终端、代码、浏览器）更强，对“轻查询型工具”更弱。

3.4 否定“沿用现有不可信代码沙箱就够了”

第 4.4 节的论证链和其他三节不同。前三节是 Aries 测出来的；这一节主要用外部证据做代理：Linux 内核 CVE 中明确写了用 AI 工具发现/修复的比例，2026 年 Q2 相对历史纪录约 3.5×，并引用“智能体花几美元就能写出利用”。前沿模型已在内核、VMM 里找到高级漏洞，于是推断智能体具备突破云隔离的可能性。

Takeaway 4 本身作为方向是对的：工具沙箱应缩小攻击面，并按任务裁剪权限（深度研究不必给 bash，给客户机内沙箱化的 JS 运行时即可），长期甚至要走向 seL4 这类形式化验证。但作为论文里的测量结论，这一节是最弱的一环：

• “提交信息里提到 AI 工具”≠“智能体在云租户环境里自主攻破隔离”。
• 补丁审查系统 Sashiko 推高 CVE 发现，说明的是防御侧/审计侧能力，不能直接等于进攻性租户风险。
• 没有 Aries 轨迹级的攻击面测量，也没有在 OpenClaw / Hermes 的工具权限集上做消融。

把它读成 愿景动机 比读成 与前三条同等级的实证 更合适。第 5.4 节的处方（主机 VM 隔离 + 客户机内核沙箱、按任务最小权限、减少侧信道暴露）仍然值得做，只是证据类型不同。

4. 愿景层：诊断开出的四张处方

第 5 节不再报数，而是把四条否定翻译成智能体原生服务系统的四个协同方向。图 12 把它们画在 Runtime / Control / Execution 三层上。

轨迹捕获指标。
不要只用 Token 吞吐。图 13 表明：Token 吞吐可以和“每小时解决的任务数”“每百万生成 Token 解决的任务数”背离——模型在忙，任务不一定在推进。终点指标（任务成功率、有效吞吐）要等轨迹结束才有，不能指导在线决策。真正缺的是从轨迹事件里推导 在线效用信号：这一次模型调用、这一次 harness 决策、这一次工具交互，到底贡献了多少增量进度，花了多少时间和资源，是有效动作还是原地打转。

轨迹感知的上下文控制面。
监视任务状态与内存状态，决定上下文保留、压缩还是分层放置。当预期精度收益不再抵偿 KV 成本时请求压缩；当释放的加速器容量超过迁移开销时，把长生命周期状态迁到更便宜的层级。这是 Takeaway 2 的系统化。

智能体感知的弹性控制面。
主机侧需求高度间歇，水平自动扩缩在这个粒度上太贵。需要的是 垂直的、模型感知的 单沙箱扩缩：用模型/harness/运行时信号预测即将到来的核数与内存尖峰。同时必须把执行状态从物理放置里解耦——哪些状态必须驻留，哪些可以外置或重建，挂起、迁移、改大小时如何保持一致。这是 Takeaway 3 的系统化，而且明确拒绝“再做一次传统 HPA”。

攻击面最小的沙箱。
按任务裁剪工具、网络、文件系统；主机侧 VM 隔离与客户机侧内核沙箱叠在一起；长期用形式化验证面对越来越强的进攻性模型。这是 Takeaway 4 的系统化。

把第 5 节读成论文的“未来工作”会低估它。这篇论文的贡献分配其实是：Aries 让问题可测，第 4 节证明旧抽象失效，第 5 节给出新抽象应该长什么样。 它故意不在本文实现那套控制面。这是定位，也是边界——读者若期待一套可部署的 Agent OS，会觉得后半段偏宣言。

5. 实验与论证该打的折扣

这篇论文的说服力主要来自“生产画像 + 开源受控拆解”的双轨，而不是来自某个 2.9× 的加速比。双轨有 complementary 的力量，也有对不上的缝：

1. 生产轨迹没有同步跨层事件。 八小时、十个实例、一百个沙箱的分钟级采样，足以说“智能体 KV 更大、沙箱更尖峰”，不足以把延迟拆到 harness 或某类工具。48%、9%、7.9 秒这些细数，全部来自开源复现。
2. 开源样本不小但也不大。 三套基准各 20 题、五次重复，且为精度研究把 OpenClaw 调到约 50% 成功率。对“上下文阈值随工作负载而变”这种定性结论是够的；对给出普适百分比则偏紧。
3. 单机单卡。 96 核 + 一块 H100 能把 KV 池打满、把排队打出来，但看不到多租户集群里的干扰、跨节点沙箱、网络存储。弹性控制面若要在生产成立，还缺这一层。
4. 沙箱成本是计费模型重放。 4.9× 与 3× 依赖 AWS Lambda MicroVM 的价格结构。换 Google / 自建快照栈，绝对值会变；“C/R 税抵消了缩至零收益”这个方向更可能稳住。
5. 安全节是代理指标。 见 3.4。
6. 正文有整理痕迹。 英文稿里出现 “Fig. and Fig.” 这类未填完的引用，个别图注和 HTML 粘贴残留。不影响主结论，但说明测量论文的文本完成度不如其问题意识。

这些折扣不推翻主线。它们说明：Aries 已经能把“旧基础设施不适合智能体”说到可辩护，但还不能把第 5 节的控制面设计参数标定出来。

6. 和 SpecBox 怎么对齐

同目录下的 SpecBox 正好是这篇诊断的一种运行时处方，两篇不宜混成一篇，但对着读很有帮助。

Aries 的 Takeaway 3 解释了为什么 SpecBox 那种“只准备、不常驻、不靠反复 C/R”的路值得走：永久预留浪费，激进挂起又太贵。SpecBox 则没有回答 Aries 的另外两半——轨迹级指标、上下文控制面、以及按任务收缩攻击面。把两篇合在一起，智能体云基础设施缺的其实是三块控制面：上下文、沙箱弹性、安全策略；SpecBox 只在弹性这一块里做了“预测性预热”这一种机制。

7. 对工程实践真正可搬走的东西

不必实现完整 Aries，下面几条已经能改现有平台的优先级：

1. 把一次用户请求记成轨迹，而不是记成多次 LLM API 调用。 没有共享的轨迹 ID，就无法回答“这次任务慢在哪”。这是可观测性改造，不是模型改造。
2. 在端到端延迟里单独列出 harness 与工具。 若工具已经接近或超过模型时间，下一季度的优化对象就不应再只是引擎。
3. 不要默认“最大上下文 = 最好”。 按任务类型扫一遍充分性阈值。深度研究类可能需要去溢出；终端/修代码类可能在中等窗口更好。超过阈值的历史应被压缩或下沉，而不是继续占 HBM。
4. 沙箱按峰值静态供给，和每次调用都做快照，都可能是错的。 先画自己的空闲–突发曲线，再决定保活。若空闲超过 80%，钱不该花在更大的常驻池，而该花在更便宜的状态外置/预测性准备上。
5. 工具权限按任务裁剪，而不是给一个万能 bash 沙箱。 即便不谈形式化验证，深度研究、浏览器、代码修改对攻击面的需求也完全不同。
6. 评测任务与执行栈解耦。 换模型或换沙箱时如果任务定义跟着变，对比没有意义。哪怕只在内部把“成功语义”写成独立配置，也比绑死在某个 harness 里强。

8. 局限，以及读完之后还该问的问题

Aries 把智能体服务从“更快的 generate”重新定义为“可持续的轨迹”，并且用生产与开源两条线把失效模式钉住。它留下的缺口，和它打开的问题一样明确：

• 在线效用信号怎么造？ 第 5.1 节指出 Token 吞吐会与任务进度背离，但没有给出可计算的增量进度估计。没有这个信号，轨迹感知调度只是事后分析，不能闭环。
• 上下文未来效用怎么估？ 充分性阈值是离线扫出来的。生产控制面需要在轨迹进行中做保守估计，估错就会伤成功率。这是系统问题，也是模型问题。
• 垂直弹性的预测信号是什么？ 论文问了，没有答。是下一个工具的类型、参数大小、历史 CPU 曲线，还是模型自己的计划文本？SpecBox 用的是工具转移图与流式意图，恰好是这个方向上的一个具体答案，但覆盖的是启动时机，不是核数/内存的垂直扩缩。
• 状态与放置如何解耦？ 文件、进程、缓存、网络连接，哪些必须随沙箱迁，哪些可以重建，决定了弹性的真实成本。Aries 只证明今天的整卷快照太贵。
• 安全论证需要轨迹级实验。 最小权限、双层隔离、侧信道，都还停留在方向。要对 OpenClaw 一类真实工具集做攻击面消融，才配得上前三节的测量标准。

如果只用一个判断收束：Aries 证明了智能体云基础设施的危机不在某一层的性能数字，而在抽象用错了——用请求级指标和服务原语，去支撑轨迹级、有状态、带工具的工作负载。 它给出的不是可上线的控制面，而是一张必须改抽象的地图。对正在把 OpenClaw / Claude / Codex 类智能体接到现有 LLM 集群上的人来说，这篇论文最有用的不是 48% 或 4.4× 这些数字本身，而是它强迫你改问的三个问题：任务有没有在推进、这段上下文还值不值得占着 GPU、这个沙箱此刻到底该驻留、挂起还是按任务缩小权限。