Agent Runtime：为什么 Agent 需要独立执行系统
传统模型服务把一次请求看成连续的 GPU 工作：输入进入，模型生成，响应返回。Agent 任务却在模型推理、CPU 工具、远程 API、沙箱、审批和等待之间反复切换。一次工具执行可能持续几毫秒，也可能卡住数分钟；模型恢复…
因此，Agent Runtime 不是普通队列外加几个工具回调。它需要同时解决两层问题：上层保存任务语义、依赖、权限和恢复点；下层协调 GPU、CPU、KV Cache 与工具并发。MARS 研究了第二层，并给出一个很重要的提醒：即使模型、权重和硬件完全不变，只要调度仍按传统 LLM Serving 的假设运行，Agent 的端到端尾延迟和有效吞吐就会崩溃。
Agent 负载为什么会击穿传统 Serving
第一种变化是时间碎片化。ReAct 循环在生成一段 Token 后切到工具，GPU 上的会话暂时休眠；工具返回后，同一任务又要恢复推理。KV Cache 由模型内部优化对象变成了工作流状态：立即释放会导致恢复时重新 Prefill，长期固定又会挤压其他活跃任务。
第二种变化是空间与资源耦合。仓库级上下文、搜索结果和日志使 KV 占用快速增长；与此同时，代码搜索、测试和容器执行消耗 CPU。CPU 工具拥塞会让大量会话同时保留 KV 等待，KV 压力又会阻塞新请求，最终形成跨资源背压。只看 GPU 利用率甚至会得出相反判断：设备很忙，但任务在 SLO 内完成的比例接近零。
MARS 因此使用 goodput，而非单纯 throughput：只有在动态 SLO 内完成的请求才计入有效吞吐。在重负载下，一些基线仍让 GPU 保持繁忙，goodput 却几乎归零；MARS 仍能保持约 0.015–0.018 req/s。这个指标更接近生产目标，因为用户关心的是任务是否及时完成，而不是算力是否被填满。
MARS 如何把跨资源状态送进调度决策
MARS 先建立 Unified Information Stream，把 GPU 与 CPU 阶段变成统一事件。GPU 侧上报预计 KV 块、首 Token 启动延迟和释放块数；CPU 侧上报活跃工具数量和执行时长。调度器由此看到的是完整 Agent 生命周期，而不是彼此隔离的模型请求与工具进程。
外部控制面由全局负载均衡与自适应准入组成。准入窗口使用类似 AIMD 的方式，根据 CPU 和 KV 双重压力增减，并加入迟滞避免频繁抖动。常态下优先小会话以提高周转；CPU 工具拥塞时偏向 GPU 密集型任务，避免继续制造更多等待工具的会话；KV 紧张时采用更保守的放置策略。关键不是某条固定优先级规则，而是让准入同时对两类瓶颈负责。
内部调度包含 Priority-Aware Coordinator 和 Opportunistic Co-Scheduler。前者用多级反馈队列综合初始占用、累计服务时间和等待时间，并设置有界晋升，防止长任务永久饥饿；优先级也决定发生内存压力时谁先被驱逐。后者动态缩小 Prefill Chunk，最低可到块粒度，从碎片间隙中插入恢复任务；只有当暖恢复收益高于占用机会成本时才固定 KV，必要时先回收休眠会话的固定上下文，再驱逐正在生成的任务。
这套设计把“公平”“成本”“恢复速度”暴露为明确取舍。永远保护长会话会拖慢整体完成率，永远偏爱短任务又会制造饥饿；保留全部 KV 能减少重算，却会压缩准入空间。Runtime 的职责不是隐藏这些冲突，而是依据 SLO 与工作负载把它们量化。
实验结果说明了什么，又没有说明什么
在 H100 与 Qwen3-Coder 配置上，MARS 将平均延迟改善 1.44–5.80 倍，P90 最多改善 3.37 倍，P95 最多改善 1.29 倍；H200 上平均延迟改善 1.90–5.94 倍，P95 最多 1.34 倍。换到 OpenHands 的真实仓库任务后，端到端任务完成时间改善为 1.20–1.87 倍，幅度明显收窄，因为框架、工具和沙箱阶段并不受 GPU 调度直接加速。
这个差距非常关键。它说明 Serving 层优化能够消除推理资源错配，却不能替代工作流 Runtime。若工具超时后整条任务重跑、写操作缺少幂等键、审批结果没有持久化，即使 GPU 阶段快五倍，最终任务仍可能失败或重复产生副作用。
消融进一步给出因果线索。移除优先级协调器在重负载下最差，可造成 2–5 倍延迟；移除外部控制面在高争用时慢 1.5–3 倍；移除机会式协同调度在内存突发时慢 1.5–2 倍。低到达率、低负载时，复杂调度偶尔略逊于简化版本，说明调度本身有开销，不应把重负载策略无条件套在所有环境。
论文也明确限定了边界：当前主要是节点内调度，多 GPU 的 KV 局部性、迁移和故障恢复仍待系统化解决；工作负载以顺序 ReAct 循环为主，具有并行分支和依赖关系的 DAG Agent 还需要新的调度语义；提高 goodput 可能牺牲个别长任务的公平性，运营方必须声明其服务政策。
一个完整 Runtime 还必须提供哪些语义
MARS 解决资源调度，但生产 Agent 还需要一个耐久执行层。任务应有不可变身份、预算、截止时间、权限范围和验收条件；每一步应记录输入引用、输出制品、状态迁移和副作用；重试策略应区分纯读取、幂等写入、可补偿写入和不可逆动作。模型上下文可以丢失并重建，任务事实却不能只存在于上下文窗口。
最实用的状态模型不是保存整段对话，而是事件日志加检查点。事件记录“发生过什么”，检查点保存“从哪里恢复最经济”。工具调用要携带幂等键与超时边界；写操作先进入策略门，根据用户授权、风险等级和目标对象判断是否执行；人工审批结果绑定具体动作摘要，不能被后来变更的参数复用。
观测指标也应沿任务而非单次请求聚合：端到端完成时间、工具等待占比、恢复成功率、重复副作用次数、P95 任务延迟、单位成功成本，以及因预算或策略门终止的比例。GPU Token 吞吐仍然有用，但它只是因果链中的一个局部指标。
最终可以把 Agent Runtime 看成两个互相约束的控制面：工作流控制面保证任务状态、授权和恢复正确；资源控制面决定何时运行、保留多少上下文、怎样跨 CPU 与 GPU 调度。前者缺失会让系统不可靠，后者缺失会让系统在规模化时失去经济性。Agent 需要独立执行系统，不是因为模型服务不够快，而是因为“完成一个任务”已经成为比“一次推理”更复杂的系统对象。