Agent Systems 研究笔记

1. Inference Foundations

1.1 学习入口

CS336：补充模型、训练和系统基础，重点连接资源核算、GPU、kernel 与并行。
All About Transformer Inference：建立 Prefill、Decode、计算、访存、容量与推理引擎之间的联系。阅读主线：生成怎样进行 → 计算与带宽瓶颈 → 显存容量 → 优化技巧 → 多设备执行 → 推理引擎。

1.2 Transformer 与 KV cache

模型把 token 转成向量，经 Attention 与 FFN 逐层处理，最后得到词表分数 logits，再由采样器选出下一个 token。中间向量称为隐藏状态；FFN 是逐位置处理这些向量的前馈网络。

对单个注意力头，基本计算为：

Q=XW_Q,\qquad K=XW_K,\qquad V=XW_V

\operatorname{Attention}(Q,K,V) =\operatorname{softmax}\!\left(\frac{QK^\top}{\sqrt{d_h}}+M\right)V

$M$ 表示因果等掩码。后续位置需要历史 K、V；历史 Q 主要用于计算历史位置自身的输出。因果注意力下，追加 token 不改变已有位置的 K、V，因此可以缓存复用。

缓存避免历史投影与前向的重复计算，但新 query 仍要访问有效历史。Attention 输出是向量，经后续网络和词表投影得到 logits；生成的 token 可以从整个词表选择。

FFN 对每个位置分别进行非线性变换。MoE 层包含多套专家 FFN，由 router 按 token 选择少数专家；专家和 router 的参数都通过训练学习。专家总数及 Top-k 中的 k 通常是模型配置。EP 将专家分布到设备，EPLB 通过专家放置、副本等机制平衡设备负载。

1.3 Prefill 与 Decode

阶段	做什么	典型系统特点
Prefill	处理已知输入，建立生成所需的 KV 和状态	多个输入 token 可以并行；长输入通常更容易利用算力
Decode	根据已有状态持续生成新 token	普通自回归具有逐步依赖；小 batch 容易受到带宽和执行开销限制

Prefill 与 Decode 的瓶颈取决于模型、上下文、batch、精度和硬件。增加并发可以分摊权重读取，也会增加 KV 占用、读取量和排队压力。

1.4 计算、搬运与存储成本

对 $X\in\mathbb{R}^{B\times D}$ 、 $W\in\mathbb{R}^{D\times F}$ ，计算 $Y=XW$ ：

\mathrm{FLOPs}\approx 2BDF.

一个乘法和一次累加约计两个 FLOPs。这里的 $B$ 是本轮处理的 token 数。BF16 每个元素为两字节，若输入和权重各读一次、输出写一次，理想搬运量为：

\mathrm{Bytes}\approx 2(BD+DF+BF).

标准注意力布局中，单请求各层 KV 大小可估算为：

\mathrm{KVBytes}=2s\,N_{\mathrm{layers}}N_{\mathrm{KVheads}}d_hL,

其中 $s$ 是每个元素的字节数， $L$ 是缓存长度；前面的 2 对应 K、V。MLA、跨层共享、稀疏与混合架构需要按实际布局计算。

分析时先区分计算量、数据搬运量与存储容量，再判断哪项限制执行速度。

1.5 优化机制

机制	主要节省什么
GQA / MQA	减少 KV 头数，降低存储与读取需求
权重 / KV 量化	降低每个元素的存储和传输字节数
FlashAttention	减少 Attention 中间结果的显存读写
Ragged reads	减少对 padding 的无效读取
PagedAttention	按块管理 KV，减少空间浪费
Prefix caching	复用匹配前缀的已有计算，减少重复 Prefill
Continuous batching	随请求加入和结束，动态组织执行批次
Chunked prefill	将长输入分块，协调 Prefill 与 Decode 的执行
CUDA Graph	减少重复发起 GPU 操作的开销
Speculative decoding	起草并验证多个候选，尝试一次推进多个 token

2. Inference Engines

2.1 nano-vLLM：请求、调度、缓存与 GPU 的连接

nano-vLLM 是轻量推理引擎，适合沿一次请求追踪整个执行过程。

组件	核心职责
LLMEngine	接收请求、推进循环、收集结果
Sequence	保存 token、执行状态与 KV 块表
Scheduler	从等待和运行队列中选出本轮请求
BlockManager	分配、复用和回收 KV 块
ModelRunner	准备张量、执行模型、采样新 token
models / layers	实现模型结构与算子

核心循环：

seqs, is_prefill = scheduler.schedule()
token_ids = model_runner.call("run", seqs, is_prefill)
scheduler.postprocess(seqs, token_ids, is_prefill)

所读本地版本先安排 Prefill，选中后本轮即返回；没有 Prefill 时才安排 Decode，显存不足会抢占请求。Prefill 的首个请求可以分块处理。

BlockManager 维护逻辑 token 位置到物理 KV 块的映射，通过前缀哈希查找可复用块，用引用计数处理共享。引用归零后，块内容可以暂时保留，直到被重新分配覆盖。

2.2 vLLM：在多请求之间共享计算与显存

vLLM 将请求处理、逐轮调度、KV 管理、模型执行和输出连接起来。先记住几种机制各自节省什么：

机制	直观作用
Continuous batching	某个请求结束后，及时加入新的请求
PagedAttention	用分页方式管理 KV，减少显存碎片
Prefix caching	相同前缀复用已有 KV，减少重复 Prefill
Chunked prefill	拆分长输入，协调 Prefill 与 Decode

分页管理主要解决空间分配，前缀缓存主要避免重复计算。它们可以配合使用。

参考：架构、前缀缓存、分块 Prefill。

2.3 DeepInfer：结合模型结构优化推理与部署

所读 DeepInfer 版本支持 DeepSeek-V4.1-Flash，主要提供离线推理引擎。阅读入口是 examples/offline_inference.py → LLMEngine → Scheduler、BlockManager 与模型执行。

机制	需要记住什么
Optimized kernels	用专门算子提高计算与访存效率
Attention DP / CP	分配不同请求或不同上下文片段的工作
MoE EP / EPLB	分布专家，并平衡各设备的专家负载
DSpark	先起草多个 token，再按置信度和负载分配验证预算
SWA bounded replay	利用滑动窗口结构，只重放有限后缀来恢复相关状态
异步调度	CPU 准备下一批时，让 GPU 继续运行
Batch-invariant inference	控制批次组成变化引起的数值差异
Deterministic sampling	配合固定种子和相应配置复现采样
Structured outputs	用 JSON Schema、语法等约束生成格式

官方部署 Q&A进一步介绍视觉编码、Prefill、Decode 分离，以及共享 KV、负载均衡和容错。共享缓存可减轻“为了命中缓存而挤在同一台机器”的问题，连接到 Agentix 与 Vesta 的路由决策。

SWA 的有限后缀重放要结合多层依赖理解；它不能推出整个模型只依赖最后几个 token。完整生产缓存服务和集群组件也并非全部包含在开源引擎中。

2.4 DLite：草稿模型借用大模型的上下文表示

论文：DLite: History-Free Speculative Decoding for Agentic AI。代码。

主张与研究方法： DLite 改进的是投机解码中的“起草”环节。普通解码由大模型逐个生成 token；投机解码先用便宜的草稿模型提出候选，再让大模型一次计算多个候选位置的分布。候选前缀通过验证，就能一次推进多个 token。起草越便宜、被接受的候选越多，收益越大。

它要解决什么： 长程 Agent 的历史越来越长，草稿侧也要保存、更新和读取历史 KV。DLite 希望把“理解长历史”的工作交给目标大模型，让草稿侧只负责当前位置附近的预测。DSpark 也使用目标模型的特征；DLite 的关键变化是进一步取消草稿侧的历史 KV。

怎样工作：

复用目标模型的隐藏状态。 隐藏状态是模型读过上下文后形成的内部向量，包含有助于后续预测的信息。DLite 从目标模型提取这些表示，加上当前已确定的 anchor token（本轮起草的起点）和若干候选位置的占位符。它还用层来源标记区分来自不同层的表示。目标模型仍保留自己的 KV，历史信息通过这些表示传给草稿侧。
并行骨干先计算多个位置。 较重的 Transformer 骨干一次产生多个未来位置的表示 $h_1,h_2,\ldots$ ，并使用局部位置进行预测。这样大部分起草计算可以并行完成。
轻量顺序头补足依赖。 并行计算时，第二个位置还不知道第一个位置最后采样出了什么。DLite 用低秩 RNN 风格的小模块，逐步接收本轮前面起草的 token，再修正当前位置的表示。较重的上下文处理并行，少量顺序计算只负责草稿块内部的依赖。
修正后才投影到词表。 隐藏状态是内部特征，logits 是给词表中每个 token 的分数。DLite 先融合上下文与前面草稿的信息，再生成最终 logits，减少额外的中间全词表投影。
交给目标模型验证。 目标模型批量检查候选；接受有效前缀，在拒绝处按验证规则修正，再用最新的目标模型表示开始下一轮。每轮草稿局部重建，不累积自己的历史 KV。

信息流可简写为下面的形式；它用于解释计算顺序，不是实现的逐行公式：

s_j=g(s_{j-1},E(x_{j-1})),\qquad \widetilde h_j=f(h_j,s_j),\qquad \mathrm{logits}_j=W_{\mathrm{vocab}}\widetilde h_j.

其中， $h_j$ 是并行骨干给当前位置的表示； $s_j$ 记住本轮前面已经起草的 token； $\widetilde h_j$ 是融合后的表示。比如先起草了 of，后一个位置就应据此更倾向 course，而不是把两个位置各自猜出的词随意拼接。

为什么还需要训练： 直接拿目标模型的隐藏状态，并不会自动得到好草稿。DLite 先让无历史的草稿模型学习一个结构相近、能访问历史的教师，作为过渡；再移除这个教师，直接对齐最终目标模型的预测分布。这就是两阶段训练。蒸馏指用教师的预测指导学生学习，目标是让草稿与大模型的概率分布更接近。

与 DSpark 比较	DSpark	DLite
草稿侧历史	保留历史 KV	不维护历史 KV，每轮从目标表示起草
块内依赖修正	给基础 logits 加入顺序修正	先在隐藏空间修正，再投影到词表
重点	半自回归起草，以及置信度和负载感知的验证调度	减少历史维护与起草计算，并训练这种结构

主要结论：

核心是让大模型处理历史、草稿模型做局部预测；“无历史”指草稿侧不维护历史 KV。
并行负责较重计算，轻量顺序模块负责块内依赖，兼顾速度与候选连贯性。
最终输出仍受目标模型验证约束；收益还取决于候选接受情况与实际执行开销。

3. Measurement

这一组工作帮助判断“问题在哪里”。有的测完整工作流，有的细看搜索、缓存历史或记忆构建；共同要求是把最终任务结果与执行过程一起记录。

3.1 AgentSysBench：先找完整工作流的瓶颈

论文：From LLM Inference to Agentic Workloads: Characterization and Implications for Serving Systems。

主张与研究方法： 单次模型调用不能解释完整 Agent 的成本。作者用十类应用和生产轨迹，将模型、工具、环境、状态、通信与资源消耗放到同一条执行时间线上。

主要结论：

执行重且有状态：工具和环境可能主导耗时，沙箱还会占用大量内存。
不同组件需要不同资源：模型依赖 GPU，检索与沙箱还可能受内存、CPU 限制。
瓶颈随请求、模型与部署方式变化。
会话空闲时仍可能长期保留状态。
工具说明、观察和辅助模型调用会增加额外开销。
不同请求会重复搜索或获取网页，存在共享缓存机会。

作者分别探索任务感知服务、组件放置、空闲状态卸载和工具结果缓存，用来验证这些测量发现的优化价值。

3.2 OpenDS-World：测真实网页调查中的搜索、失败与停止

论文：Deep Search in Real-World Web Environments。

主张与研究方法： 构建 200 个真实网页调查任务，让 Agent 从视频线索出发，跨网页、文件和媒体搜集证据。用统一工具和预算评测 12 个模型，同时分析答案、耗时、工具调用与失败行为。

主要结论：

最好的模型准确率为 39%，多步证据搜集仍然困难。
更多工具调用和 token 消耗，不一定带来更高准确率。
失败调用次数占比小，却占用很大一部分工具执行时间。
Agent 主动结束搜索，不代表答案正确。
不同模型分别受时间上限或工具调用次数上限限制。

研究启发： 除了模型推理速度，还应关注慢失败恢复、工具选择、预算分配和停止判断，并同时衡量准确率与成本。

3.3 Request Order Matters：旧缓存会让同一输入得到不同答案

论文：Request Order Matters: Cache-History Sensitivity in Selective KV-Cache Reuse for Rolling Agents。

主张与研究方法： 当 Agent 删掉最早的一份文档、追加新文档时，保留下来的文字虽然没变，其位置和前面的上下文已经变了。原来的 KV 因而不再等同于对新输入完整计算得到的 KV。选择性重算尝试修补其中一部分，同时复用剩余状态。

作者比较两种选择方式：

零散 token top-k： 比较某个选择层上“当前计算的 K”和“缓存 K”的差距，把预算分给偏差最大的单个 token；选中的位置可能散落在很多地方。
连续片段： 先把 token 组织成文档或固定片段，按片段平均偏差选择；预算有剩余时，再选一段连续窗口，使实际重算 token 数一致。被选中的位置在后续层重新计算。

实验固定每条请求的文本、模型与贪心采样，只改变整条请求进入系统的先后顺序，并让缓存跨请求保留。这样测的是“之前的请求留下什么状态”，而不是把当前输入中的文档随意打乱。

主要结论：

同一个输入可能因缓存历史不同而得到不同答案；逐次请求的近似误差会成为系统状态的一部分。
正常时间顺序下两者差异不显著；乱序和倒序时，连续片段更接近完整 Prefill 的结果。
消融支持连续性这一共同因素，尚未发现文档边界或按偏差排序带来的额外显著优势；它没有完整解释连续性更稳的底层原因。

3.4 Agent Memory Characterization：查询快，可能是写入时已经付了成本

论文：Agent Memory: Characterization and System Implications of Stateful Long-Horizon Workloads。代码 · IISWC 2026。

主张与研究方法： 对十种记忆系统分阶段记录调用、耗时、能耗和存储，并改变构建模型大小与会话到达间隔。实验覆盖 MemoryAgentBench、MemoryArena 和 Qwen3-1.7B 至 32B 等设置。

主要结论：

查询快可能来自昂贵的提前构建。Qwen3-32B、300 次 LongMemEval 查询的设置中，每个正确答案的能耗相差约 45 倍。
构建时的大量输入处理、embedding 和细碎串行调用，决定了批处理与 GPU 利用率的优化空间。
构建模型过小，可能无法正确生成工具调用或结构化记忆，省下计算却破坏后续可用性。
异步写入要权衡新鲜度：等写完再回答会增加延迟，直接回答可能读到旧状态。

4. Context and Memory

历史越长，每轮输入越贵，但删掉信息又可能影响后续行动。这里的主要决策是：何时整理、保留什么、由谁决定，以及删出工作窗口的内容能否找回。

4.1 CoMem：小模型在后台整理记忆，主 Agent 继续执行

论文：CoMem: Context Management with A Decoupled Long-Context Model。代码。

主张与研究方法： 如果让主 Agent 停下来自己写摘要，后续执行就要等待摘要完成。CoMem 把这件事交给独立的小记忆模型，同时让主 Agent 继续工作。

它采用 k-step-off（滞后 k 步）的异步流水线：

记忆模型拿到此前历史，在后台生成新摘要。
主 Agent 用“最近完成的摘要 + 尚未纳入摘要的原始交互”继续推理和调用工具。摘要虽然滞后，近期信息仍通过原始缓冲区提供。
新摘要就绪后，在同步点替换旧摘要，并保留仍需携带的近期记录；新的摘要前缀需要重新 Prefill。
同一个摘要沿用期间，后续观察可以增量追加，继续复用前缀 KV。

这里的 k 决定两次整理之间隔多少步：间隔长可以摊薄摘要更新和重新 Prefill，但近期缓冲区会变长。记忆模型还经过专门训练，目标是让摘要支持主 Agent 后续决策，而不只是把原文写得简短流畅。

主要结论：

解耦让摘要计算与主任务重叠，有机会隐藏一部分压缩等待。
异步的关键是保留近期原始记录，不能只把旧摘要当作最新状态。
摘要替换会影响 KV 复用，k、摘要长度与质量共同决定取舍。

4.2 LongSeeker：让 Agent 学会保留、压缩、摘录与回退

论文：LongSeeker: Elastic Context Orchestration for Long-Horizon Search Agents。

主张与研究方法： 普通 ReAct 在“思考 → 调用工具 → 接收观察”中不断追加历史。LongSeeker 的 Context-ReAct 把编辑上下文也变成 Agent 的动作：每步一起生成思考、上下文操作和普通工具调用，运行环境再据此构造下一步输入。

五种操作承担不同工作：

操作	怎样改变下一轮上下文
Skip	保持当前内容，不进行编辑
Compress	将选定历史改写为简短总结
Rollback	回到此前的上下文位置，舍弃后续工作分支
Snippet	摘取要保留的原文片段，减少重写造成的信息变化
Delete	删除选定的无用历史

例如，搜索结果很多但只有一段相关时，可以摘录；一个分支已走不通时，可以回退；已经解决的子问题可以压成简短结论。作者用包含这些操作的合成轨迹微调模型，让“何时、对哪里、怎样编辑”成为可学习的策略。

主要结论：

上下文不必只有“全部保留”或“全部摘要”两种状态，可以按任务需要保留不同细节。
专门的摘录、删除与回退动作，让 Agent 更直接地控制信息，而不必每次都生成一份新摘要。
这里的回退作用于模型历史，环境中已经发生的修改需要另外恢复。

研究启发： 把资源管理决策暴露为 Agent 可调用的动作，是一种通用设计。与 ACM 比较操作集合，与 AgentRewind 区分上下文编辑和环境恢复。

4.3 ACM：Agent 自己决定何时压缩，并能找回原文

论文：ACM: Agentic Context Management for Long Horizon Tasks。

主张与研究方法： ACM 把上下文管理做成两类显式工具，让任务模型自己决定何时使用。

整理工作上下文。 调用 manage_context，把已有交互压成适合后续决策的内容，同时将原始消息保存在外部记忆中。
按需找回原文。 后续发现摘要不够用，再调用 query_memory 查询被移出工作窗口的细节。压缩后的窗口承担日常推理，外部原文承担恢复。
学习何时调用。 教师根据轨迹补入有必要的上下文管理动作，并纠正不必要的调用；用这些示范后训练任务模型。训练同时教“该调用”与“该克制”，避免每一步都整理记忆。

例如，Agent 可以把一轮排查压成“已排除配置错误”；后面需要核对具体参数时，再取回原始日志。“无损”主要来自原文仍被保存，并不是一段短摘要自动包含全部信息。

主要结论：

压缩时机和找回时机可以作为任务策略的一部分学习。
工作窗口与原文存档分工，允许保留简洁输入，同时保有回查途径。
原文可恢复还不够，模型必须能判断缺了什么，并正确查询、使用它。

4.4 Scroll：把历史放进可查询、可计算的会话环境

论文：Context as an Environment: Programmatic Context Management for Long-Horizon Agents。

主张与研究方法： Scroll 将会话历史做成一个可以编程访问的 Session Environment，由两部分组成：

Event Log（事件日志）： 原始交互只追加、不覆盖，每段内容有稳定地址。
持久 Python 环境： 变量跨模型调用保留，可绑定工具结果、取回的记录和计算结果。

Agent 通过 exec 写代码检索日志、展开片段、筛选数据和做计算，再用 print 决定哪些结果放进下一轮工作上下文。比如，工具返回一大张表时，可以把表保存在变量中，计算某一列的统计值，只打印统计值，而不是反复把整张表塞入 prompt。

工作窗口接近预算时，旧片段可以移出，但会留下与日志地址对应的紧凑导航索引。需要细节时，Agent 沿索引读取原文。日志负责保真存储，程序负责信息处理，打印结果负责控制模型本轮看到的内容。

主要结论：

上下文管理可以转化为程序任务：检索、计算和选择输入，不必总依靠提前写摘要。
“完整历史长期保存”和“本轮输入保持小”可以同时实现。
效果依赖模型写查询和处理证据的能力；持久变量也不等同于完整的系统故障恢复。

研究启发： 把大对象留在执行环境，把必要信息送给模型。这种思路也适用于表格、搜索结果和代码分析，而不仅是聊天历史。

4.5 ReCAP：保存历史重要性和依赖，等新请求来了再选

论文：Persistent Context Graphs for Efficient Memory Compaction in LLM Agents。

主张与研究方法： ReCAP 希望在下一条用户请求真正到来时再选历史，但又不想为选择而重新让模型读完整会话。它提前记录推理中产生的注意力信号，构建持久的上下文图。

记录用过什么。 历史消息块成为图节点；注意力形成的重要性分数，表示过去执行时哪些块经常被利用。
记录依赖谁。 图边连接一段记录与它需要的此前上下文。例如某段结论可能依赖更早的定义或工具结果。
新请求到来后选择。 将历史重要性与当前请求中的标识符等相关性线索结合，挑选消息，再沿依赖边补上支撑内容。
兼顾后续复用。 一个用户轮次内部尽量固定所选历史前缀，工具步骤只追加新内容；下一个用户请求可以重新选择，也可以找回上轮未选中的块。

图和文本独立于 KV 保存。即使 GPU 缓存过期，系统仍能先从图中选出较短文本，再对选中的输入建立新 KV；选择本身不需要额外模型调用。

主要结论：

历史重要性与当前相关性解决不同问题，二者结合还能适应任务方向变化。
保留结论时带上依赖，比只选孤立高分消息更能维护上下文完整性。
持久图把“选择历史”与“是否还留着 KV”解耦，但选中文本仍需相应的模型计算。

研究启发： 可以把昂贵执行过程中顺便得到的信号存下来，支持未来的廉价决策。

4.6 ACON：从压缩导致的任务失败中改进规则

论文：ACON: Optimizing Context Compression for Long-horizon LLM Agents。代码 · ICML 2026。

主张与研究方法： ACON 优化的是指导压缩器的自然语言规则，而不是先修改任务模型权重。

它通过任务反馈改进规则：

对同一任务比较两种轨迹：完整上下文能够成功，压缩上下文却失败。
让较强模型分析压缩后丢失了什么，例如关键标识符、尚未满足的约束或工具结果。
把这些失败原因写成更好的压缩指南，再运行任务、继续检查。优化先关注保住任务所需信息，再尝试进一步缩短表达。
将学到的指南用于历史或最新观察压缩。若额外压缩调用太贵，可以再把这个行为蒸馏到较小模型；蒸馏属于额外训练步骤。

例如，笼统的“保留重要信息”可以被任务反馈改成“保留文件路径、错误位置和未完成要求”。这只是说明规则如何具体化的例子，具体应保留什么由任务反馈决定。

主要结论：

压缩质量可以通过任务失败改进，而不是只凭摘要是否流畅、压缩比是否高来判断。
历史与最新工具观察都能压缩，但它们丢失信息的风险不同。
优化指南不要求更新主模型参数；压缩调用仍有计算成本，缩短输入未必缩短任务耗时。

研究启发： ACON 展示的是“用下游任务反馈优化上游表示”。与 CoMem 连起来看，一个研究怎样压缩，另一个研究压缩何时执行。

4.7 ContextPilot：重排与去重证据块，让输入更容易命中前缀缓存

论文：ContextPilot: Fast Long-Context Inference via Context Reuse。代码 · MLSys 2026 正式论文页。

主张与研究方法： 多轮检索经常拿回相同文档，但顺序不同，或者把此前已有内容再放一遍。ContextPilot 在输入组装和推理引擎之间增加上下文优化层，主动把输入组织成更容易精确命中缓存的形式。

输入与输出： 输入是用户问题、检索或记忆模块提供的 context blocks（上下文块），以及当前缓存信息；输出是对齐、去重并带有简短注释的新 prompt，再交给原推理引擎。

核心流程：

建 Context Index（上下文索引）。 记录各请求用了哪些块、哪些共同前缀仍在缓存中。树节点表示共享块或已有上下文路径；利用块的交集形成可共享部分，并随请求、缓存回收更新。这里只存块标识和元信息，不再训练一个语言模型。
按已有前缀对齐。 找到最合适的共享路径，把可复用块放到相同前缀，剩余块尽量维持原有顺序。请求调度也利用这些共享路径，增加已生成缓存被下一请求复用的机会。
补充顺序注释。 重排会改变检索结果的优先级。系统把原来的阅读优先级写成短注释，放在文档之后、问题之前，让共享文档前缀仍一致。
跨轮去重。 已经在会话历史中的块，或不同块中的重复片段，可以换成指向原位置的注释，只新增必要内容。被引用的信息仍需处于模型可访问的历史中；引用文字本身不能替代已经不可访问的证据。

一个示意：

缓存已有：[A, B, C]
新检索顺序：[B, A, D]

对齐后：[A, B, D] + “原阅读优先级 B > A > D” + 问题
        └─ A、B 与已有前缀一致 ─┘

主要结论：

在输入组装层发现和组织重叠，可以提高现有精确前缀缓存的使用机会。
物理排列与语义优先级可以通过注释分开表达，但注释并不提供数学上的答案不变保证。
精确复用保证的是改写后输入的对应计算；改写相对原输入是否保持任务含义，还需单独判断。因果相关的操作历史不宜直接当作可任意交换的证据块。

研究启发： 与 CacheBlend 的区别是改变哪一层：ContextPilot 改文本组织，CacheBlend 修补不完全匹配的 KV。可进一步讨论，在长程 Agent 中怎样区分可重排证据、版本约束和必须保持顺序的执行历史。

5. Scheduling and KV

跨轮调用之间会有工具等待。系统既要让任务及时继续，也要给其他任务腾出计算与显存。先区分整份 KV 的保留、放置和路由，再看一份 KV 内部的有损压缩。

5.1 Agentix：根据任务已获得的服务，决定谁先运行

论文：Agentix: An Efficient Serving Engine for LLM Agents as General Programs。

主张与研究方法： Agentix 把同一任务产生的多次模型调用关联起来，调度时考虑“这个任务已经获得多少计算服务”。

PLAS：串行任务的累计服务。 每个程序记录此前完成的模型调用实际执行时间。新调用继承这个历史，累计获得服务较少的程序倾向获得较高优先级。工具等待和排队时间不算模型服务。这样，一个已经运行很久的任务，不能只因为又发出一条短请求就重新获得“新任务”的待遇。

ATLAS：并行任务的服务路径。 并行分支的服务时间直接相加，可能过度惩罚并行程序。ATLAS 使用已观察到的累计服务路径。直观上，前面共享阶段花了 5 个单位，随后两条并行分支各花 3 和 8，最长路径是 13，而不是把所有工作相加为 16。实际调度根据已完成调用持续更新估计，不预知未来完整执行图。

怎样执行优先级： 将调用放进多级队列，结合运行配额和抢占控制连续占用；等待过久可以提升优先级，缓解饥饿。跨引擎路由还要考虑程序已有缓存在哪里。

主要结论：

任务级累计服务能暴露逐调用调度遗漏的信息，减少反复排队和队首阻塞。
串行累计与并行服务路径解决不同情形，不能统一按调用次数或 token 数相加。
这些都是基于历史的调度启发式，效果取决于历史服务与剩余工作之间的关系。

研究启发： 单次请求的优先级应继承任务信息。与 Continnum 比较，关键是工作负载更适合服务较少的任务优先，还是让已开始的任务连续推进。

5.2 Continnum：工具还没返回，KV 值得保留多久

论文：Continnum / Continuum: Efficient and Robust Multi-Turn LLM Agent Scheduling with KV Cache Time-to-Live。

主张与研究方法： 一个模型调用结束后，Agent 往往只是去执行工具，稍后还会带着同一段历史回来。Continnum 用 TTL（Time To Live，保留期限）保护这段等待中的 GPU KV。

它的决策过程是：

观察同类工具此前的耗时，估计它在不同期限内返回的可能性。
对每个候选期限，比较保留收益与占用成本。收益包括避免重算、从 CPU 加载以及返回后重新排队；成本是 GPU 显存被占着，其他任务可能更难进入。
选择预计净收益更好的 TTL，也允许选 0，表示不保护。
工具及时返回时尽量续用已有 KV；TTL 到期后解除保护，缓存进入可回收范围，并不要求到点立即删除。

系统用任务身份关联多轮请求，并结合程序级先来先服务，减少一个任务在每轮之间反复排队。

主要结论：

“请求结束”与“任务结束”不同，工具等待可以是值得保护的短暂停顿。
有期限的保护能利用跨轮局部性，同时限制长工具等待占用 GPU 的代价。
缓存在 CPU 中只能省一部分重算，重新获得 GPU 空间和调度机会也有成本。

研究启发： 把“保护多久”与“返回后何时运行”一起考虑。工具返回预测、任务优先级和显存机会成本共同决定保留价值。

5.3 MORI：把更快会用到的 KV 留在 GPU

论文：Idleness is Relative: Exploiting Tool-Call Idle Windows for Offloading in Agentic Systems with MORI。

主张与研究方法： MORI 管理整份会话 KV 在 GPU 与 CPU 之间的放置。它把空闲程度看成可比较的连续排序，而不是给每个程序贴一个固定的“忙”或“闲”标签。

运行时维护活动程序的相对忙闲顺序：密集进行短工具调用、经常返回模型的程序，KV 更适合留在 GPU；处于长等待的程序，更适合把 KV 卸载到 CPU。系统再根据两层容量移动分界，并控制各层准入和驱逐。

例如，有五个程序都被判断为“忙”，但 GPU 只能放两份 KV，二元标签就无法继续决策；相对排序仍能选出更值得留在 GPU 的两份。反过来，GPU 有富余时，也不必因为一个程序刚开始等工具，就立刻把它搬走。

主要结论：

缓存位置取决于相对复用需求与硬件容量，不能只看单个任务是否正在等待。
卸载能释放显存，但搬来搬去也有传输成本，应避免按每次短暂停顿机械迁移。
论文通过代码 Agent 轨迹回放研究服务性能，方法不直接改变模型的任务策略。

研究启发： MORI 展示了用全局排序连接工作负载与分层容量的方法。与 Continnum 的时间期限、Vesta 的跨机器路由一起看，可以分清三类不同的放置决策。

5.4 CacheScout：预测下一个 Agent，提前准备固定前缀

论文：Learning Agent Execution for KV-Cache Management in Agentic Serving。

主张与研究方法： 多 Agent 工作流会重复使用各角色的系统提示词、工具说明和示例。CacheScout 希望在真正调用该角色之前，就知道它的固定前缀是否值得保留。

它在线观察 Agent 调用转移，形成下一次调用的概率线索。例如，工作流中 A 后面经常调用 B，那么运行 A 时，B 的前缀可能比“最近访问过、但很久不会再调用”的 C 更有缓存价值。

这个执行模型用于两项决策：

驱逐： 显存不足时，结合预期复用选择更值得保留的前缀，而不只按最近访问时间排序。
预取或提前准备： 后台有空闲资源时，为可能即将执行的角色准备 KV，减少它真正到达后的 Prefill 工作。

调用关系从运行中学习，不要求用户事先交出完整工作流图，也不需要为这个预测器离线训练一个大模型。

主要结论：

执行结构可以提供缓存未来价值的线索，补足“最近用过”的局限。
提前准备也会消耗资源，需要与真正的前台需求协调。
这里主要复用固定角色前缀，与不断变化的会话历史是不同对象。

研究启发： 上层 Agent 框架知道的执行信息，可以成为下层缓存系统的决策依据。

5.5 Vesta：缓存在哪台机器，不必决定请求在哪台执行

论文：Vesta: Queueing-Aware LLM Scheduling for Real-World Workloads。

主张与研究方法： Vesta 将“谁保存权威 KV”与“这次请求在哪执行”分开。

Holder（保存者）： 每个会话有稳定的 KV 保存位置。
Executor（执行者）： 每轮请求可以选择另一个实例执行，所需 KV 通过传输获得，执行后把新增状态写回保存者。

调度比较留在原地与迁移的总成本：原地能复用多少前缀、还要排多久；迁移需要搬多少 KV、补多少计算；额外工作是否会进一步加重集群拥堵。它还考虑长度分桶之间的前缀迁移，避免切换执行配置时全部冷启动。

例如，A 机器缓存命中但排队很长，B 机器空闲。把 KV 搬到 B 可能更快；但如果网络和计算已经拥堵，这次搬运也可能让更多请求受影响。Vesta 将这种额外排队代价纳入选择。

主要结论：

缓存命中只是总成本的一项，高命中率不能单独决定执行位置。
请求执行可以移动，缓存身份保持稳定，使局部性与负载均衡有更多选择。
迁移价值随拥堵状态变化，应从整个集群而非单个请求看收益。

5.6 AgentKV：按不同执行阶段的需求保留 KV

论文：AgentKV: Phase-Aware KV Eviction for Agentic LLMs。代码。

主张与研究方法： AgentKV 研究一份会话缓存内部应该留下哪些 token 的 KV。它的出发点是：Agent 思考、生成动作和读取工具结果时，注意力查询向量 Query 的分布不同。

只用最近几个 Query 选缓存，容易偏向当前阶段。比如正在长篇思考时，某些用于下一次工具动作的参数暂时没被关注，却仍然重要。

AgentKV 按 think、act、tool、others 分别保存少量代表 Query，用它们的合集给历史 Key 打分，保留预算内更有用的 KV。随后把保留项紧凑存储，并把空出的页面交还内存管理器；压缩后的状态跨多轮调用继续使用。

主要结论：

未来需求可能是多个阶段的混合，最近的需求不总是最好的代表。
分阶段保存少量查询信号，可以减少一种阶段“盖过”其他阶段的问题。
逻辑上删掉条目，还要物理整理和释放页面，才能兑现显存与吞吐收益；过小预算仍会丢失必要信息。

5.7 ActKV：优先保留有助于正确行动的 KV

论文：ActKV: Efficient LLM Agents through Action-Guided KV Cache Management。

主张与研究方法： ActKV 把“是否支持正确行动”作为缓存保留的中心。因为决定调用哪个工具、传什么参数的动作，会直接影响外部任务进展。

方法由三部分连接起来：

动作导向驱逐。 观察动作 token 生成时访问哪些历史 KV，形成保留分数；跨轮积累重要访问，并让长期不再使用的条目逐渐失去优先级，避免只看当前一小段推理。
置信度驱动预算。 从模型预测分布提取置信度并监测趋势，发现退化后调整缓存容量，而不是为所有任务固定同一预算。置信度是控制信号，不能直接证明问题一定来自压缩。
分页实现。 将过程落实为注意力计算、条目选择、缓存紧凑化三个环节。专门内核把分散的保留项整理到可用位置，减少仅删除“逻辑条目”却没有释放物理块的浪费。

例如，动作需要文件路径和目标行号，即使它们在此前思考中很少出现，也应比无关的冗长推理更值得保留。

主要结论：

缓存重要性可以围绕任务真正使用的动作来定义，而不必把所有输出 token 视为同等重要。
“留下哪些内容”与“总共留多少”是两项不同决策，方法同时处理它们。
算法选择与分页内存实现必须连接，实际节省才会进入服务系统；更激进压缩也可能让轨迹变长。

研究启发： ActKV 展示从任务目标到打分信号，再到控制反馈和内核实现的完整链条。需要理解每一层怎样把上一层的意图变成可执行决策。

5.8 CacheBlend：复用文档 KV，再用少量计算修补跨文档关系

论文：CacheBlend: Fast Large Language Model Serving for RAG with Cached Knowledge Fusion。代码：LMCache。

主张与研究方法： 同一篇文档会被不同问题反复检索到，但不一定出现在相同前缀。CacheBlend 希望复用各文档已经算好的 KV，再用少量计算修补它们拼接后的上下文影响。

为什么不能直接拼缓存： 假设文档 A 定义了一个项目术语，文档 B 随后使用这个术语。B 单独预计算时没有读过 A；把 B 的 KV 搬到 A 后面，位置虽然能校正，内部表示仍缺少此前跨文档的信息。修正位置编码与恢复跨文档关系是两件事。

方法按层运行：

取回已有 KV。 根据文本块身份加载缓存，并校正其位置相关的表示。
选择要修补的 token。 原论文观察到高偏差位置在相邻层有相关性，因此从较早层的比较开始，逐层筛选候选，而不先完整重算所有层来获得“正确答案”。具体 LMCache 版本的选择层与筛选配置应和原论文区分。
只更新选中位置。 选中 token 重新计算 Q、K、V；把新 K、V 与其他位置的旧缓存合在一起。选中位置仍要对有效历史 K、V 做注意力，因而“少重算”不等于“不读取旧缓存”。
让搬运与计算重叠。 一层正在修补时，后台加载下一层的 KV。控制器根据加载速度、计算代价与质量要求选择重算比例，争取把部分修补时间藏在数据加载过程中。

文本块已有 KV → 按层加载
                   ↓
              少量位置重新计算
                   ↓
            新 KV + 其余旧 KV → 下一层

主要结论：

跨块复用可以扩大缓存机会，但复用的状态需要适应新的前文。
选择性重算连接“全部复用”和“全部重算”，提供可调的近似修补路径。
算法节省还要与缓存搬运、流水线一起设计；原论文的任务质量结果不代表所有持续运行场景都保持输出不变。

6. Reliability and Training

长程任务会积累错误。这里分别研究当前理解是否一致、训练是否适应执行过程、环境怎样回退，以及第一次错误在哪里。

6.1 PoS：检查当前理解是否一致，避免一直行动却没有进展

论文：Beyond Memory: Harnessing Long-Horizon Agents with Explicit Belief States。

主张与研究方法： PoS 将“发生过什么”的历史，转成“现在认为世界是什么样、还有什么没完成”的显式 belief state（当前判断状态）。

它维护一个循环：

整理状态。 用实体、属性、关系描述当前世界，再列出未解决需求。例如任务要求“把热杯子放进柜子”，状态中不仅要有杯子位置，还要有是否加热。
检查一致性。 Belief Sentinel 将当前判断与新工具观察比较，也检查状态内部是否矛盾。
检查进展。 即使动作合法，也要看未完成要求是否减少；反复查看同一柜子而没有加热杯子，就可能陷入 Belief Trapping（判断和行动停滞）。
按问题恢复。 根据停滞与未解决需求，重新寻找证据或调整后续行动，再更新状态。

这里的额外状态是提供给 Agent 的决策上下文，不是修改模型权重，也不是自动保存整个操作系统。

主要结论：

历史完整与当前判断正确是两件事，后者需要持续更新和检查。
合法动作也可能没有任务进展，终止和恢复需要参考目标是否真正被满足。
状态维护与检查会产生额外调用，应理解它带来的可靠性与执行开销取舍。

研究启发： 可以把任务要求变成可检查的状态条件。与 Scout 的错误定位、AgentRewind 的环境回退结合思考，分别解决判断、检测和执行恢复。

6.2 Glasseek：让训练适应压缩，并排除搜索评测中的答案泄漏

论文：Glasseek: A Transparent Recipe for Training and Trustworthy Evaluation of DeepSearch Agents。

主张与研究方法： Glasseek 同时处理数据构造、压缩感知训练和评测泄漏，其中最需要理解的新机制是 CM-GSPO。

压缩怎样改变训练： Agent 生成一段执行轨迹后，把旧历史换成摘要；后面的动作实际上是在“摘要 + 新观察”的条件下产生的。如果训练时又假装这些动作看到了完整原历史，计算的概率就不对应当时的决策条件。

CM-GSPO 将这件事显式化：

按压缩事件分段。 一条任务轨迹切成多个执行子轨迹，并记录每段真正看到的上下文。
在相同条件下比较策略。 计算新旧策略的执行 token 概率时，都使用记录下来的实际上下文，不重新生成另一份摘要。
修正分段权重。 所有片段仍属于同一个任务、共享最终奖励。按片段有效长度占整条轨迹的比例调整权重，避免仅因为一条轨迹被切成更多段，就在训练中获得额外总权重。
只优化执行部分。 提示词、工具观察和摘要生成 token 不进入该执行策略目标；已生成的摘要作为条件输入保留。搜索与摘要可以共享模型，但不代表摘要 token 也被这个目标直接训练。

评测时，另用搜索和网页访问规则过滤测试集答案、镜像数据等泄漏来源，减少“搜到参考答案”对能力分数的污染。

主要结论：

上下文管理会改变动作生成的条件，训练必须保留这种真实条件。
一条轨迹怎样分段、怎样合并损失，会改变学习权重，是算法的一部分。
搜索能力评测要区分正常证据获取与直接获得基准答案。

研究启发： 理解一个 Agent 系统时，要把训练与推理连接起来。推理侧新增压缩、恢复或其他状态操作后，应检查训练概率和奖励分配是否仍然对应真实执行。

6.3 AgentRewind：把模型上下文和工作区一起退回检查点

论文：AgentRewind: Recoverable Execution for Long-Horizon LLM Agents。代码 · MettleBench。

主张与研究方法： AgentRewind 为长程 Agent 提供可恢复执行：在同一检查点同时记录模型上下文与受控工作区，出错后两者一起退回。

流程是：

记录交互日志，以及与各步骤对应的文件状态变化，形成可定位的检查点。
当 Agent 判断当前路径难以继续时，选择一个此前的位置。
提炼这次失败得到的经验，形成 rewind memory，避免恢复后盲目重复同一路径。
恢复那个位置的上下文和工作区；此前已记录的模型输出、工具结果从日志读取，不重新触发旧工具调用。
在恢复状态上加入失败经验，生成新的执行分支。

例如，Agent 改坏配置文件后，只删除聊天中的错误步骤，会留下坏文件；只恢复文件而保留“配置已经修改成功”的判断，也会不一致。对齐恢复正是这项技术的中心。

主要结论：

错误会同时改变模型看到的记录与外部环境，恢复需要明确覆盖哪些状态。
失败经验可以保留，失败造成的工作区修改可以回退，两者承担不同作用。
受控文件恢复不等于能撤销网络请求、外部服务或任意进程副作用。

研究启发： 检查点不是一份聊天备份，而是 Agent 和环境的共同恢复点。与 Scout 连接时，错误检测信号还要转成合适的回退位置。

6.4 Traverse / Scout：找出长轨迹第一次在哪里走错

论文：Locating Hidden Failures Makes Long-Horizon Agents More Reliable。

主张与研究方法： Traverse 和 Scout 将一个只有最终成败的任务，变成可以研究逐步错误的过程。

Traverse 是标注基准。 人工检查真实执行轨迹，判断是否出现错误，并标出第一次错误的位置。这样可以区分“最后没完成”和“从哪一步开始偏离”。
Scout 是专门的验证器。 以 Qwen3-4B-Thinking-2507 为基础，先通过监督微调学习这些逐步标注，再用强化学习进一步优化错误定位。
测试时用于候选选择。 当任务模型生成多条候选执行轨迹时，让 Scout 检查它们，再选择较可靠的结果。任务模型本身不必重新训练。

例如，最终测试失败可能是后面多次错误的共同结果；定位最早那次错误，才有可能确定哪些后续步骤已经建立在错误前提上。这个位置也可成为后续研究恢复策略的输入。

主要结论：

通用模型会评价答案，不代表它能准确定位长执行过程的第一次错误。
更细的过程标注，为专门验证器提供了不同于最终奖励的学习信号。
论文中的候选选择与实时检测、自动回滚是不同使用方式；后两者还需要新的执行机制。

研究启发： 从“给最终结果打分”转向“提供可行动的错误位置”。与 AgentRewind 联合思考时，要判断定位信息怎样真正减少重做。

7. Survey

论文分类对照

论文	任务类型	单/多用户设置	Agent 形态	长程/短程设置	优化对象	训练要求	评测方式	优化目标	主要评估指标
DLite	生成 / 编码 / 工具	单用户型（含 batch）	主模型＋草稿	兼有	解码 / 草稿 KV	草稿模型训练	固定提示＋BFCL 闭环	延迟↓	生成加速比；接受长度
AgentSysBench	混合 Agent 工作流	兼有	混合工作流	兼有	全栈测量	无需（测量）	工作流实测＋生产观察	瓶颈测量	任务耗时；Util；内存；token/费用
OpenDS-World	开放网页搜索	单用户型	单 Agent	长程	工具 / 评测	无需（基准）	开放 Web 闭环	质量 / 成本评测	Acc.；工具调用；搜索成本
Request Order Matters	滚动文档 QA	未明确（串行请求）	固定请求，无行动闭环	单轮 + 持久缓存	KV 复用 / 重算	无需	固定请求序列	一致性↑；延迟↓	输出变化率；fidelity；TTFT
Agent Memory Characterization	记忆 QA / 跨会话任务	兼有	依记忆系统而异	单轮 QA + 跨会话	记忆构建 / 检索	无需（测量）	记忆 QA＋时序回放/共置	成本 / 新鲜度测量	构建/查询耗时；Acc.；J/correct；更新滞后
CoMem	编码	单用户型（含 batch）	主 Agent＋记忆模型	长程	上下文 / 记忆流水线	辅助模型训练	编码闭环＋batch 实测	延迟↓；质量保持	任务延迟；成功率；上下文/内存
LongSeeker	搜索	单用户型	单 Agent	长程	上下文编辑	任务模型 SFT	搜索闭环	质量↑；上下文↓	Acc.；上下文/生成 token
ACM	搜索 / 编码	单用户型	主 Agent＋辅助 LLM	长程	上下文 / 外部记忆	可选；增强版蒸馏	搜索/编码闭环	质量↑；上下文↓	pass@1；峰值 token；工具调用
Scroll	记忆 QA / 环境操作	单用户型	单 Agent＋运行时	单轮 QA + 长程	日志 / 程序运行时	无需	记忆 QA＋LOCA 闭环	质量↑；输入规模↓	Acc./任务分数；输入输出 token
ReCAP	编码 / 多轮反馈	单用户型	单 Agent	长程 / 多轮	历史选择 / 依赖图	无需	编码闭环＋开销估算	质量保持；开销↓	任务分数/Acc.；历史 token；冷恢复开销（含估算）
ACON	办公 / 工具 / QA	单用户型	主 Agent＋压缩器	兼有	历史 / 观察压缩	无需；可选蒸馏	工具闭环＋QA	质量保持；成本↓	成功率；峰值 token；API 费用
ContextPilot	RAG / 记忆 / 多 Agent	兼有	混合，含协作多 Agent	兼有	输入组织 / 前缀 KV	无需	RAG/Agent 应用/edge 实测	延迟↓；质量保持	Prefill/TTFT；任务质量；复用率
Agentix	对话 / 工具 / 树搜索	多用户型	串行/并行 Agent 程序	兼有	程序调度 / 路由	无需	程序实验，含对话回放	延迟↓；吞吐↑	程序时延/token；program/s；p95/p99
Continnum	编码 / 工具	多用户型	独立 Agent 程序	长程	KV 驻留 / 续接调度	无需	轨迹回放＋SWE 闭环	延迟↓；吞吐↑	任务完成时间；job/s；尾延迟
MORI	编码轨迹	多用户型（回放）	独立 Agent 程序	长程（轨迹）	KV 驻留 / 卸载	无需	轨迹回放	吞吐↑；延迟↓	token/s、step/s；TTFT；Util
CacheScout	QA / 对话 / 搜索 / 编码	未明确（多 Agent 服务）	多 Agent（六角色）	兼有	固定前缀 KV / 预取	无需；在线统计	多 Agent 服务实验	延迟↓；吞吐↑	TTFT；每轮延迟；turn/s；命中率
Vesta	在线 Agent 服务轨迹	多用户型（回放）	未明确（会话轨迹）	长程（轨迹）	路由 / KV 迁移	无需	生产轨迹回放	延迟↓；吞吐↑	平均/p99 TTFT；吞吐；排队时间
AgentKV	工具交互	单用户型（含 batch）	单 Agent	长程 / 多轮	token KV 淘汰 / 页回收	无需	工具闭环＋服务实测	容量↓；质量保持；吞吐↑	固定 KV 预算下任务分数；token/s
ActKV	环境操作 / QA / 购物	单用户型（离线 batch）	单 Agent	长程	KV 淘汰 / 预算 / 页回收	无需	工具闭环＋离线 batch	容量↓；质量保持；吞吐↑	峰值 KV；Acc.；token/s、task/s
CacheBlend	RAG / QA / 摘要	多用户型（请求服务）	固定请求，无行动闭环	单轮（长输入）	非前缀 KV 复用 / 重算	无需	QA/摘要＋请求服务实测	延迟↓；吞吐↑；质量保持	TTFT；推理吞吐；F1 / ROUGE-L
PoS	环境操作 / 诊断	单用户型	主 Agent＋检查模块	长程	任务状态 / 检查	无需	执行/诊断闭环	质量↑；可靠性↑	成功率/诊断指标；token 成本
Glasseek	开放网页搜索	单用户型	单 Agent，兼搜索/摘要	长程	策略训练 / 评测	任务模型 SFT＋RL	搜索闭环＋训练/泄漏审计	质量↑；评测可信度↑	Acc./pass@1；泄漏分析
AgentRewind	编码 / 工程任务	单用户型	主 Agent＋恢复模块	长程	检查点 / 环境恢复	无需	工程闭环＋恢复比较	质量↑；可恢复性↑	成功率；验收进度；轨迹长度
Traverse / Scout	编码 / 终端 / 科学任务	单用户型（多候选）	任务 Agent＋验证器	长程（轨迹）	验证器 / 轨迹选择	验证器 SFT＋RL	离线轨迹＋候选选择	检测质量↑；任务质量↑	首错定位准确率；检测 F1；best-of-N 成功率

分类口径： 单用户型指主要研究一个用户任务内部的能力或效率；多用户型指多个独立会话/程序共享推理资源的服务设置，实验可能用合成请求或回放代替真人；兼有指同时包含两类设置。多 Agent、多个候选或 batch 本身不构成多用户证据，无法判定的保留“未明确”。这列描述研究设置，不声称论文报告了真实用户人数。

时域口径： 单轮/短程与持续多步反馈的长程任务分开；一次请求可以有很长输入。跨会话记忆与长程执行也分别标注。包含短任务和长程子实验的写“兼有”，不强行二选一。

指标口径： 延迟区分 TTFT（首 token 等待）、生成耗时和任务完成时间；吞吐注明 token/s、turn/s、task/s 或 program/s。Acc. 是准确率，pass@1 是一次尝试的通过率，Util 是资源利用率；fidelity 是相对参考输出的一致程度。峰值 token、KV 容量、接受长度和命中率用于解释机制，不自动等于任务加速或质量提高。表中列主要指标，不罗列全部实验数字。

新增列口径： Agent 形态描述任务内部角色，和单/多用户服务设置独立；辅助草稿、摘要或验证模型不自动算协作多 Agent。训练要求指是否需要新的参数训练，使用已发布配套权重仍归为需配套训练，提示词优化和在线转移统计不算梯度训练。“闭环”表示行动影响后续观察，可发生在模拟环境中；“生产轨迹回放”表示数据来自生产，但不是在线生产部署的证明。

可补充关注的数值指标：

Goodput / SLO 达标率： 关注满足规定 TTFT、TPOT 或任务时限的有效服务能力；应同时说明阈值与达标口径。总吞吐很高但请求普遍超时，服务价值仍可能有限。参见 Taming the Titans §2.3。
每个成功任务的成本/能耗： 总费用或能耗除以成功任务数，把失败尝试、记忆构建、辅助调用和重试计入，注明核算范围。Agent Memory 的 Table 3 实际报告 J/correct（每个正确答案的焦耳数），已补入对应行；不能把它直接当作所有 Agent 的已测指标。
任务进度、恢复与过程质量： 最终成功率之外，可看验收进度、首错定位、恢复后的成功及额外开销；避免失败任务全部记零而看不到过程差异。指标需与真实验收条件对应，参见 Agent Evaluation Survey Table 1。
状态新鲜度与尾延迟： 分别记录查询时尚未提交的旧会话更新，以及 p95/p99 等慢请求；均值可能掩盖更新积压和少数任务长时间等待。新鲜度口径见 Agent Memory §4.6，服务延迟口径见 Taming the Titans Table 1。

这些是后续阅读时值得检查的指标，只有原文确实测过才填入论文行；没有测量结果不能由方法描述推断。模态、部署规模和存储层级可在相关论文正文补充，不再给所有论文增加大量专用列。

其他研究者怎样组织 survey：

Memory in the Age of AI Agents，Table 1、Table 2：先按记忆形式分组，再用 Task、Type、Memory Form 等列横向比较；Table 2 的 Optimization 列标 SFT、FT、PE 等接入/训练策略。借鉴其训练策略单列的做法，不把 Optimization 误读成 latency/吞吐目标。Table 1 的 Multi 表示多模态，不表示多用户。
Evaluation and Benchmarking of LLM Agents，Figure 1、Table 1、§4：Figure 1 区分“评什么”和“怎么评”；Table 1 按目标类别列 SR、F1、pass@k、Progress Rate、Latency/Token/Cost 等指标；§4 再区分静态与交互评测。借鉴其目标、指标、评测方式分别记录的做法。
Taming the Titans，Table 1、§2.3、§3–4：按单实例与集群层次组织系统工作，Table 1 定义 TTFT、TBT、TPOT、吞吐、容量、归一化延迟和百分位；§2.3 补充 Goodput。借鉴其统一服务指标和计量范围的做法，不把单请求加速与集群能力混比。
A survey on LLM-based multi-agent systems，§3、Table 1、§3.4.2：围绕 profile、perception、self-action、mutual interaction、evolution 五个模块组织工作；交互结构区分层级、去中心、中心和共享消息池。借鉴其任务内部角色/协作结构视角，用单独 Agent 形态列与用户并发区分。
Agent Memory Characterization，Table 1、Table 3 是系统测量论文：Table 1 比较构建、数据库、检索与可变性，Table 3 同时列准确率、总耗时、调用数、总能耗和 J/correct。它说明同一个质量分数背后可能是不同写读成本，借鉴其全生命周期成本归因；专用于记忆的细项保留在正文。

8. Materials Index

基础与实现

材料	主要内容	本文位置
CS336	连接模型训练、算法与系统基础	§1
All About Transformer Inference	算清 FLOPs、搬运量、容量与推理瓶颈	§1
nano-vLLM	看请求怎样经过调度、块管理与 GPU 执行	§2.1
vLLM	多请求共享计算与 KV 显存的通用服务框架	§2.2
DeepInfer	将模型结构、算子和部署一起优化	§2.3

论文

论文（原文）	主要内容	本文位置
DLite	借用目标表示，无历史草稿 + 隐藏空间顺序修正	§2.4
AgentSysBench	联合测模型、工具、环境、状态与通信	§3.1
OpenDS-World	真实网页多步取证，分析工具成本与停止行为	§3.2
Request Order Matters	持续 KV 复用对前序请求敏感，连续重算更稳	§3.3
Agent Memory Characterization	分开测记忆构建、检索、生成与更新等待	§3.4
CoMem	将摘要与执行拆开，异步重叠两者耗时	§4.1
LongSeeker	把上下文编辑变成可学习的动作	§4.2
ACM	主动压缩 + 外部保留原文 + 按需查询	§4.3
Scroll	完整日志与持久变量在外部，按需读取并 print	§4.4
ReCAP	历史注意力 + 当前请求 + 依赖图选择上下文	§4.5
ACON	用成功／失败轨迹对照优化自然语言压缩指南	§4.6
Agentix	PLAS / ATLAS 把逐次调用调度提升到任务级	§5.1
Continnum	用 TTL 临时保护 GPU KV，减少跨轮恢复与排队	§5.2
MORI	按相对忙闲排序，在 GPU 与 CPU 间放置整份 KV	§5.3
CacheScout	学习调用转移，指导固定前缀的驱逐与预取	§5.4
Vesta	联合权衡缓存命中、排队与 KV 迁移	§5.5
AgentKV	保存各阶段代表 Query，避免只照顾最近的需求	§5.6
ActKV	按动作价值压缩，并用置信度调整预算	§5.7
PoS	显式记录当前世界判断与未完成要求，检测停滞	§6.1
Glasseek	可审查数据 + 压缩感知训练 + 防泄漏评测	§6.2
AgentRewind	对齐保存上下文与文件状态，失败后换一条路径	§6.3
Traverse / Scout	人工标注首错位置，训练小验证器辅助选择轨迹	§6.4
CacheBlend	独立块 KV + 选择性重算 + 加载计算流水线	§5.8
ContextPilot（MLSys）	上下文索引 + 共同前缀对齐 + 去重与语义注释	§4.7

1. Inference Foundations

1.1 学习入口

1.2 Transformer 与 KV cache

1.3 Prefill 与 Decode

1.4 计算、搬运与存储成本

1.5 优化机制

2. Inference Engines

2.1 nano-vLLM：请求、调度、缓存与 GPU 的连接

2.2 vLLM：在多请求之间共享计算与显存

2.3 DeepInfer：结合模型结构优化推理与部署

2.4 DLite：草稿模型借用大模型的上下文表示

3. Measurement

3.1 AgentSysBench：先找完整工作流的瓶颈

3.2 OpenDS-World：测真实网页调查中的搜索、失败与停止

3.3 Request Order Matters：旧缓存会让同一输入得到不同答案

3.4 Agent Memory Characterization：查询快，可能是写入时已经付了成本

4. Context and Memory

4.1 CoMem：小模型在后台整理记忆，主 Agent 继续执行

4.2 LongSeeker：让 Agent 学会保留、压缩、摘录与回退

4.3 ACM：Agent 自己决定何时压缩，并能找回原文

4.4 Scroll：把历史放进可查询、可计算的会话环境

4.5 ReCAP：保存历史重要性和依赖，等新请求来了再选

4.6 ACON：从压缩导致的任务失败中改进规则

4.7 ContextPilot：重排与去重证据块，让输入更容易命中前缀缓存

5. Scheduling and KV

5.1 Agentix：根据任务已获得的服务，决定谁先运行

5.2 Continnum：工具还没返回，KV 值得保留多久

5.3 MORI：把更快会用到的 KV 留在 GPU

5.4 CacheScout：预测下一个 Agent，提前准备固定前缀

5.5 Vesta：缓存在哪台机器，不必决定请求在哪台执行

5.6 AgentKV：按不同执行阶段的需求保留 KV

5.7 ActKV：优先保留有助于正确行动的 KV

5.8 CacheBlend：复用文档 KV，再用少量计算修补跨文档关系

6. Reliability and Training

6.1 PoS：检查当前理解是否一致，避免一直行动却没有进展

6.2 Glasseek：让训练适应压缩，并排除搜索评测中的答案泄漏

6.3 AgentRewind：把模型上下文和工作区一起退回检查点

6.4 Traverse / Scout：找出长轨迹第一次在哪里走错

7. Survey

论文分类对照

8. Materials Index

基础与实现

论文

Comments