【多轮对话论文导读（二）】多轮对话与LLM Agent论文阅读：长期记忆、多轮评估与Agent训练

最近多轮对话研究的一个明显趋势是研究重点正在从“单轮回答质量”转向长期交互过程中的状态跟踪、用户意图理解、澄清决策、记忆和Agent训练。本文整理 6 篇 2026 年最新论文第一篇做多轮多步任务的信用分配第二篇是memory检索第三~五篇是多轮benchmark第六篇做RL的reward sparse的研究。目录一、CrEST多轮Agent训练中Reward到底应该分给谁1. 解决的问题2. 方法3. 实验验证二、TrajWiki长期对话中的Memory不能只是一个“记忆列表”1. 解决的问题2. 方法3. 实验验证三、Hy-MultiTurn现有Benchmark为什么测不出真正的深层多轮理解1. 解决的问题2. 方法四、RegretBench模型“会提问”不等于“会澄清”1. 解决的问题2. 方法五、EYT-Bench如何真正模拟“人与模型连续聊天”1. 解决的问题2. 方法六、RSPODense Reward和Outcome Reward到底应该怎么用1. 解决的问题2. 方法3. 实验验证七、总结一、CrEST多轮Agent训练中Reward到底应该分给谁Teach the Magnitude, Not the Direction: Verifier-Bounded Credit Assignment for Multi-Turn Multi-step LLM Agents1. 解决的问题1Inter-turn credit dilution。不同 turn 的贡献被混在一起。传统 RLVR 往往只在整个 trajectory 最后得到一个 reward如图中例子论文 Figure 1在这张图中第二轮获得了0分会导致整个trajectory的得分为0。传统方法容易把同一个 reward 传播给整个 trajectory。2Intra-turn credit ambiguity。同一个 turn 内不同 token 的贡献也不同但也被混在了一起。这里真正重要的可能是图中红框的token而像绿框这种格式相关的token其实并不重要如图中的例子论文 Figure 1所以像MT-GRPO这种方法在一个 Turn 内部的所有 Token 还是被认为同样重要。这种Turn-level credit解决了“哪个 Turn 有功/有过”但没有解决“这个 Turn 里的哪个 Token 最值得学习”。3Dense token-level credit。这正是RL所缺少的东西。论文也明确将OPD定义为能够提供 dense per-token supervision 的方法。但是 OPD 有一个非常严重的问题Teacher Ceiling。也就是学生模型的能力容易被教师模型的能力所限制。那不用外部的教师模型比如OPSD方法“自己生成答案 privileged information/ground truth”去构造Self-Teacher。也就是Teacher 和 Student 是同一个模型但 Teacher 可以看到 privileged information。但是OPSD也有个问题Gradient Concentration Collapse也就是论文图中提到的Gradient concentrated onfew low-entropytokens论文 Figure 1这种low-entropy的token就是概率特别确定的比如标点符号。但是 Self-Distillation 的梯度却可能大量集中在这些 token 上导致模型没能学习到重要的信息。这就是 OPSD 的“梯度集中崩溃”4总结现有的方法方法Credit 粒度Ceiling主要问题GRPOTrajectory-levelVerifier-bounded太粗所有 Token 同样 creditMT-GRPOTurn-levelVerifier-boundedTurn 内 Token 仍然同质OPDToken-levelTeacher-bounded学生被 Teacher 限制OPSDToken-levelTeacher/self bounded梯度集中、训练不稳定CrESTTurn Token hierarchicalVerifier-bounded兼顾两者RL / GRPO奖励太粗—— 一个 trajectory reward 被广播给所有 Turn 和所有 Token。OPD / OPSD奖励很细但教师太强势—— 要么被 Teacher 的能力上限限制要么出现梯度集中崩溃。2. 方法CrEST 的核心不是简单地将RL 和 Distillation 拼起来。通过Teacher 不再决定 Direction而是只决定Magnitude来实现。也就是由Verifier决定是奖励/惩罚Self-Teacher决定这个token该更新多少来实现。1Turn-segmented verified advantage。解决跨 Turn 的credit dilution问题。论文 Figure 2对于group中的每个 Turn独立计算advantage论文公式(3)Sample i 表示第 i 条 rollout。对于固定的 Turn k会收集同一个 group 中 I 条 rollout 在这个 Turn 的 reward然后跨这 I 条 rollout 做归一化得到每条 rollout 在 Turn k 上的 advantage。这个advantage 的正负号决定这个 Turn 是奖励还是惩罚。2Privileged Self-Teacher。解决 Turn 内 Token 都一样的问题。论文 Figure 2Self-Teacher 可以看到 privileged / ground-truth context。对于 token t论文公式(5)表示第个Token表示当前正在训练的模型表示同一个模型 privileged 表示student的历史上下文表示Teacher的历史上下文表示Student 对 token的 log-probability是温度系数控制modulation 强弱。这个公式可以简单理解成Teacher认为这个Token应该多大概率和Student现在给了多大概率之间的差值差得越明显那么这个 Token 越值得调整。但是这样又成了Teacher去决定更新方向了所以论文引入了Direction Gate论文公式(7)就是这个turn的RL方向。也就是Teacher 只有在和 Verifier 的方向一致时才有资格放大更新。但是即使 Teacher 只负责 magnitude它可能还是把 gradient 集中到低熵 Token所以又加入Entropy Gate对于每个 Token计算 Student 的 surprisal。论文具体使用 normalized surprisal再通过 sigmoid 得到entropy gate并用它调节 teacher modulation strength。让低熵的少更新高熵的多更新。概率高 - 越确定 - 熵越低。3. 实验验证论文在BFCL V3 multi-turnWildToolBench这两个bench上进行主要实验并比较 RL 和 distillation 类 baseline。1BFCL V3 Multi-Turn一共800个样本包含以下4类。Category数量主要考察Base Multi-Turn200基础多轮Missing Function200缺失工具Missing Parameter200缺失参数Long Context200长上下文对于每一个 Turn进行检查两种 EvaluationState-based Evaluation和Response-based Evaluation既要检查执行后 backend 的真实状态又要检查执行路径。计算多轮准确率全部turn正确的样本的占比。一个多轮样本只要某一 Turn 出错整个 entry 就会失败。2WildToolBench相比于BFCL V3 的“设计好的多轮 Tool-Use 环境”WildToolBench 更关注真实用户行为中的“混乱、多任务、多轮切换”。这个bench把真实用户行为总结为三个维度A.Compositional Tasks一个用户请求里面有多个子需求。B.Implicit Intent用户意图并不总是完整说出来。C.Instruction Transition用户会在这个bench定义的“单 Tool多Tool询问澄清普通聊天”间切换。这个bench有256个session每个session有4个任务覆盖1600的API。计算任务准确率一个session中的任务完成率衡量模型平均能不能把一个任务完成。计算会话准确率一个session中所有任务都完成的占比。计算完成进度率调用正确的 Tool 节点的占比衡量模型到底完成了多少正确的 Tool 节点。计算最优路径率WildToolBench 会枚举所有合法执行路径然后比较模型实际执行的路径。衡量Tool 调用路径是否合理、接近最优。论文结果表明 CrEST 在两个模型规模上都超过 baseline尤其在长轨迹和严格 session-level 指标上提升更加明显。CrEST解决的是“多轮Agent最终reward无法准确分配到具体turn/token”的问题通过Turn-level verifier Token-level teacher实现更细粒度的credit assignment。二、TrajWiki长期对话中的Memory不能只是一个“记忆列表”论文TrajWiki: Source-Grounded Memory Trajectories for Long-Horizon Dialogue Agents1. 解决的问题1lack source-grounded memory evolution。很多 memory-augmented agent 基本采用Write → Store → Retrieve → Generate的流程。传统的memory记住了变化的结果却丢失了变化的过程不能解释为什么会这么变比如后续询问这个信息从哪来中间发生了什么哪些信息失效了为什么当前状态是这样等类似问题无法回答。论文figure12retrieval fragmentation。大量细粒度 memory会造成检索碎片化。论文figure1如何让长期对话Memory具有来源、演化历史和可追溯性。2. 方法1Memory Trajectory。把memory建模成一条状态轨迹而不是一个状态节点论文公式(3)是第条 memory trajectory是第个 episodic snapshot每一个 snapshot 都保留对应的 source message。2Immutable Episodic Snapshot。每次发生新的对话就生成snapshot。这些snapshot是immutable的也就是不能被删除、覆盖但可以追加。3operator modeling。重新建模“修改”操作原本的新增记忆就是插入删除记忆就是删除检索不到。现在“修改”操作被定义如下论文公式(5)ADD为新增事实REVISE为修改事实DEPRECATE为事实失效也就是旧事实仍然存在只是被标记为已经失效。传统 MemoryTrajWiki保存当前状态保存状态演化overwriteappend-only删除旧事实DEPRECATE只知道结果知道过程source 不透明source-grounded无法追踪 revisionclaim-level revision难以解释冲突可以保留冲突历史不知道 memory 为什么变化能追踪变化原因TrajWiki 不是简单让 Memory“记得更多”而是让 Memory 从“状态” 变成“历史轨迹”。4Memory Wiki。传统方法是Query - embedding - top-k Memory这样一个问题的答案可能被分散在多个分散的memory中。论文采用给memory建立个维基百科定义了四种 page论文公式(6)IndexPage相当于网站首页 / 总目录帮助找到相关领域。EntityPage围绕一个实体组织信息TopicPage围绕一个主题InventoryPage组织列表/数量/项目集合。实际把检索变成Hierarchical Retrieval不像传统RAG找最相似 query 的 memory而是先找到属于哪个知识区域再找到相关 memory trajectory再定位到具体历史证据所以也能解决“多跳问题”。如果每次查询都搜索所有历史 memory成本会非常高。先用Wiki进行粗粒度路由再回到原始证据。这样既提高检索效率又保留 source grounding。其它方法的问题根本原因TrajWiki 的解决方案Full Context 太长直接保存全部历史Trajectory WikiNaive RAG 检索碎片化flat Top-K retrievalHierarchical RetrievalLangMem 只保存 salient memory缺乏显式演化轨迹Memory TrajectoryA-MEM 有动态链接link ≠ temporal evolutionTrajectory claim operationsMem0 做 memory consolidation更关注 current stateimmutable snapshots旧 memory 被覆盖overwriteADD / REVISE / DEPRECATE无法解释 memory 来源provenance 丢失Source-grounded Snapshot多跳问题容易漏信息memory 分散Memory Wiki时间问题困难没有显式 temporal structuretimestamp trajectory冲突难处理只保存当前 belief保留 historical claims检索结果不可诊断只有 retrieved textWiki → trajectory → snapshot → source3. 实验验证论文在LoCoMoMedMT上进行长程对话实验并与多种 Memory baseline 比较。Long-horizon dialogue、Memory retrieval、Temporal reasoning 以及 Memory evolution同时分析Memory为什么检索失败哪一次更新出了问题最终回答使用了哪条证据论文table1部分实验结果实验表明TrajWiki在不同开源和闭源模型上都能提升长期对话表现同时提供更好的 memory evolution 可解释性。TrajWiki 把Memory从 “静态知识库” 变成 “有来源、可更新、可追溯的长期记忆轨迹”。三、Hy-MultiTurn现有Benchmark为什么测不出真正的深层多轮理解论文Hy-MultiTurn: A Six-Dimensional Benchmark for Deep Multi-Turn Dialogue Understanding1. 解决的问题很多 Multi-Turn Benchmark 实际上只有几轮但这个benchmark的轮次很多。长对话真正困难的不是“生成一句自然的话”而是记住早期约束处理后续修改找到正确对象解决指代判断是否应该行动Hy-MultiTurn直接从真实 chatbot failure 中总结出六种典型问题1. Constraint Memory2. Precise Execution3. Constraint Synthesis4. Object Localization5. Action Suppression6. Reference Resolution2. 方法论文不是简单生成一批多轮问题而是引入Action Suppression测试模型知道什么时候不能执行任务真实对话失败 ↓ 分析Failure Mode ↓ 总结6种机制 ↓ 设计Controlled Task ↓ 加入 长对话 无关信息 口语表达 ↓ BenchmarkHy-MultiTurn不是单纯把对话变长而是从真实失败案例出发把“深层多轮理解”拆成6种可控failure mode进行评估。四、RegretBench模型“会提问”不等于“会澄清”论文One More Turn, Less Regret: A Regret-Based Multi-Turn Benchmark for LLMs Clarification Policies1. 解决的问题用户说“帮我推荐一台电脑。”模型当然可以问“你预算多少”但真正的问题不是这个问题看起来是否合理而是现在应该不应该问应该问什么问几个问题什么时候停止什么时候直接回答所以论文认为Clarification本质上是一个Sequential Decision Problem。2. 方法论文提出RegretBench。给定一个存在歧义的用户请求User Query ↓ 多个Hidden Intent ↓ 模型选择 Ask / Answer / Stop ↓ User Response ↓ 更新Intent State ↓ 继续交互因此模型不能只生成“好问题”还必须决定什么时候问、问什么、什么时候停。同时设计 regret最终任务价值 - 交互成本 - 无效提问惩罚最终评价整个 clarification policy。RegretBench把“澄清问题质量”升级为“澄清策略质量”评价模型是否在正确的时间提出正确的问题并及时停止。五、EYT-Bench如何真正模拟“人与模型连续聊天”论文Enjoy Your Talk: A Human-Centered Benchmark for Multi-Turn Dialogue with Decoupled User Simulation, Target Modeling, and Judging1. 解决的问题传统对话Benchmark固定user - 固定问题然后模型回答这种循环模式问题就是User不会根据模型的回答动态变化。而现实用户会改变目标改变情绪补充信息隐藏意图继续追问2. 方法1三个模块完全解耦。构建User Simulator、Target Model 以及 Judge Model。A. User SimulatorPersonaGoalExplicit IntentLatent IntentEmotion负责根据模型回答动态产生下一轮用户输入。B. Target Model同时评价当前用户的Intent以及Emotion并生成 response。C. Judge Model从外部评价EmpathyPersona AlignmentAnthropomorphic InteractionFinal Intent Completion也就是User负责“演”Agent负责“答”Judge负责“评”EYT-Bench的核心贡献不是又做了一个聊天数据集而是构建了User Simulator–Target Model–Judge三方解耦的动态多轮评估环境。六、RSPODense Reward和Outcome Reward到底应该怎么用论文RSPO: Reward-Swap Policy Optimization for Multi-Turn LLM Agents1. 解决的问题1Sparse Outcome Reward。直接使用 outcome reward 会因为 reward sparsity 和缺少 fine-grained feedback 而导致收敛缓慢。更严重的是对于 GRPO 这类方法如果成功轨迹根本没有被采样出来模型就无法从这些成功行为中学习。2Reward Misalignment。现有方法的Dense Reward 不一定等于真实目标。如果 dense reward与真实 outcome reward 不一致直接优化 dense reward 会使训练方向产生偏差最终降低模型性能。2. 方法方法优点缺点Outcome Reward和真正任务目标一致稀疏、探索差、收敛慢Dense Reward信号丰富、探索能力强、收敛快可能与真正目标不一致RSPODense Reward 负责探索 Outcome Reward 负责优化需要 replay buffer 和 off-policy correction1Decoupling exploration and optimization signals。根本不让 Dense Reward 决定最终的 policy optimization。把训练过程拆成两个角色Agent A和Agent BAgent B已经因为 Dense Reward 学会了去探索哪些方向。Agent B与 environment 交互产生 trajectory这些 trajectory 是 Dense Reward 引导出来的其中可能包含很多原来 Outcome Reward policy 根本采不到的 trajectory。但是 RSPO 不直接拿这些 dense reward 来训练最终 policy。也就是轨迹保留但是把 reward 换掉。2Generalized Clipping Mechanism。这些是Agent B产生的off-policy的数据 trajectory 并不是当前Agent A产生的。所以RSPO 做了 Clipping-center Shift论文公式(4)的部分clipping center 不再固定在 1而是根据behavior policy​ 和 old policy​​的关系移动。普通 PPO是1±而 RSPO是±。RSPO 最终优化目标把两类数据和结合起来Agent A自己生成的从 replay buffer 中采样On-policy和Off-policy论文中​以当前 policy 自己产生的数据为主只加入少量 replay data。3. 实验验证论文主要实验在ALFWorldWebShop上测试并与GRPO、PPO、GiGPO以及SPEAR等方法比较。实验结果显示 RSPO 在多个环境和模型规模上取得更好的任务成功表现尤其对较小模型收益更明显。可能是小模型探索能力弱Dense Reward帮助寻找有效trajectory。RSPO 不直接相信Dense Reward而是让Dense Reward负责探索、Outcome Reward负责最终优化从而同时解决Sparse Reward 和 Reward Misalignment问题。七、总结论文解决的问题方法最大区别实验验证CrEST多轮RL的credit分配不准确Turn Token层级creditTeacher只控制更新幅度BFCL V3、WildToolBenchTrajWiki长期Memory无法追踪演化Memory Trajectory WikiMemory有来源、有历史LoCoMo、MedMTHy-MultiTurn传统Benchmark测不出深层多轮理解6种failure modes从真实失败机制设计Benchmark209任务、12–76轮、22模型RegretBench不知道什么时候该澄清Hidden Intent Regret从问题质量转向策略质量QA、推荐任务EYT-Bench静态Benchmark缺乏真实交互User–Agent–Judge解耦User Simulator动态参与3400 dialogues、17模型RSPOMulti-turn RL reward太稀疏Dense探索 Outcome训练Dense reward不直接用于最终优化ALFWorld、WebShop