多轮 Agent 中的 KV 状态管理

一次 Agent 任务通常包含多次模型调用。模型输出工具调用，工具执行后返回结果，模型再读取新增上下文，决定下一步。一次生成结束，并不意味着整个任务结束。

请求结束与会话结束

对单次请求而言，返回停止 token 后可以释放状态。但对于多轮任务，后续请求可能沿用相同历史。如果每轮都从头计算，那么历史越长，重复 prefill 的成本就越高。

会话级 KV 管理把这两个生命周期分开。模型暂停生成时，会话仍可保留状态；工具返回后，满足前缀一致性条件的请求可以增量恢复。

执行槽位与 KV 存储是两类资源。等待工具时可以释放执行槽位，让其他请求运行；保留 KV 则继续占用显存。随着并发会话增加，这个取舍会从计算问题变成容量问题。

因此，暂停、恢复和真正结束需要显式区分。结束或中止的轨迹应该及时清理，避免把不再使用的缓存继续保留，甚至搬到 CPU 上。

CPU 内存可以扩展缓存容量，但保存和恢复都要付出传输成本。只有避免重算的收益能够覆盖这些成本，offload 才可能有效。

在 Qwen3 Runtime 的后续实验里，固定 GPU KV 容量下的高并发回放观察到了收益；低压力或更大的 GPU KV 池没有可信的加速。这说明容量条件和实际恢复量，应当与耗时数字一起记录。

缓存恢复还需要处理前缀校验、版本变化、容量准入与失败回滚。模型权重变化后，旧 KV 不能继续作为有效状态使用。

关于具体实现、实验条件与当前限制，见 Qwen3 Runtime 项目记录。