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

最近多轮对话研究的一个明显趋势是：研究重点正在从**"单轮回答质量"** 转向长期交互过程中的状态跟踪、用户意图理解、澄清决策、记忆和Agent训练。

本文整理 6 篇 2026 年最新论文，每篇都按照以下链路进行介绍：

解决的问题 → 解决方法 → 与其他方法的区别 → 实验验证

一、CrEST：多轮Agent训练中，Reward到底应该分给谁？

论文： Teach the Magnitude, Not the Direction: Verifier-Bounded Credit Assignment for Multi-Turn Multi-step LLM Agents

论文地址：arXiv:2608.13179

1. 解决什么问题？

多轮 Agent 通常是：

复制代码

User
 ↓
Agent
 ↓
Tool
 ↓
Agent
 ↓
Tool
 ↓
...
 ↓
最终成功/失败

传统 RLVR 往往只在整个 trajectory 最后得到一个 reward。

例如：

复制代码

Turn 1：做对
Turn 2：做对
Turn 3：做错
Turn 4：做对
              ↓
        Final Reward = 0

那么传统方法容易把同一个 reward 传播给整个 trajectory。

这导致两个问题：

Inter-turn credit dilution：不同 turn 的贡献被混在一起。
Intra-turn credit ambiguity：同一个 turn 内，不同 token 的贡献也不同，但也被混在了一起。

论文认为，多轮 Agent 的 credit assignment 应该进一步细化到：

复制代码

Trajectory
    ↓
Turn
    ↓
Token

2. 怎么解决？

论文提出 CrEST：

Hierarchical Credit Assignment

分成两层。

第一层：Turn-level Credit

把整个 trajectory 按 turn 切开：

复制代码

Turn 1 → Advantage 1
Turn 2 → Advantage 2
Turn 3 → Advantage 3
...

利用 verifier 分别判断不同 turn 的结果，从而避免最后一个失败把前面正确的 turn 一起"惩罚"。

第二层：Token-level Credit

同一个 turn 内进一步判断：

复制代码

Token 1 → importance
Token 2 → importance
Token 3 → importance
...

论文引入 privileged self-teacher，让 teacher 不直接决定更新方向，而是：

只调节 update magnitude。

同时加入 entropy gating，让模型更加关注高不确定性的关键 token。

所以 CrEST 的核心可以概括成：

复制代码

Verifier
   ↓
决定"往哪个方向更新"

Self-Teacher
   ↓
决定"更新多少"

Entropy Gate
   ↓
决定"哪些Token更值得更新"

3. 和其他方法有什么不同？

传统方法，例如GRPO：

复制代码

Trajectory
   ↓
一个Reward
   ↓
所有Token共享

Distillation：

复制代码

Teacher
   ↓
直接指导Student

CrEST：

复制代码

Verifier
   ↓
保证正确的RL方向
       +
Self-Teacher
   ↓
只提供dense magnitude signal

因此论文的核心思想就是标题：

Teach the Magnitude, Not the Direction

这样既保留 RLVR 的 verifier 上限，又获得 token-level dense supervision。

4. 怎么实验验证？

论文在：

BFCL V3
WildToolBench

上进行实验，并比较 RL 和 distillation 类 baseline。

重点观察：

复制代码

Average Success
Turn-level表现
Long-trajectory表现
Strict Session Accuracy

结果表明 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 Agents

论文地址：arXiv:2608.00967

1. 解决什么问题？

传统 Memory 系统通常把信息保存成：

复制代码

用户喜欢咖啡
用户住在北京
用户喜欢旅游

或者直接维护一个：

复制代码

Current User State

问题是：

用户信息会变化。

例如：

复制代码

1月：用户喜欢iPhone

3月：用户换成Pixel

6月：用户又换回iPhone

如果简单 overwrite：

复制代码

Memory = iPhone

模型就不知道：

这个信息从哪里来的？
中间发生了什么？
哪个信息已经过期？
为什么当前状态是这样？

TrajWiki要解决的就是：

如何让长期对话Memory具有来源、演化历史和可追溯性。

2. 怎么解决？

核心思想：

Memory不是静态Entry，而是一条Trajectory。

首先保存不可修改的：

复制代码

Episodic Snapshot

然后对事实进行：

复制代码

ADD
REVISE
DEPRECATE

三类操作。

例如：

复制代码

t1：
喜欢iPhone

t2：
改用Pixel
    ↓
REVISE

t3：
重新使用iPhone
    ↓
REVISE

所有历史信息都保留。

Memory Wiki

如果每次查询都搜索所有历史 memory，成本会非常高。

所以 TrajWiki增加：

复制代码

Dialogue History
      ↓
Memory Wiki
      ↓
Relevant Page
      ↓
Memory Trajectory
      ↓
Snapshot
      ↓
Original Message

也就是：

先用Wiki进行粗粒度路由，再回到原始证据。

这样既提高检索效率，又保留 source grounding。

3. 和其他方法有什么不同？

传统 Memory：

复制代码

Memory Entry
    ↓
当前状态

TrajWiki：

复制代码

Source Message
      ↓
Snapshot
      ↓
Claim
      ↓
Trajectory
      ↓
Memory Wiki

最大的区别不是"存得更多"，而是：

Memory具有时间演化和来源链。

因此不仅能回答：

"用户现在喜欢什么？"

还能够追踪：

"这个信息是怎么变化到现在的？"

4. 怎么实验验证？

论文在：

LoCoMo
MedMT

上进行长期对话实验，并与多种 Memory baseline 比较。

重点验证：

复制代码

Long-horizon dialogue
Memory retrieval
Temporal reasoning
Memory evolution

同时分析：

复制代码

Memory为什么检索失败？
哪一次更新出了问题？
最终回答使用了哪条证据？

实验表明，TrajWiki在不同开源和闭源模型上都能提升长期对话表现，同时提供更好的 memory evolution 可解释性。

一句话总结

TrajWiki把Memory从"静态知识库"变成"有来源、可更新、可追溯的长期记忆轨迹"。

三、Hy-MultiTurn：现有Benchmark为什么测不出真正的深层多轮理解？

论文： Hy-MultiTurn: A Six-Dimensional Benchmark for Deep Multi-Turn Dialogue Understanding

论文地址：arXiv:2607.29196

1. 解决什么问题？

很多 Multi-Turn Benchmark 实际上只有几轮：

复制代码

User → Assistant
User → Assistant
User → Assistant

但是现实中的 Agent 可能需要：

复制代码

20轮
30轮
50轮
甚至更长

长对话真正困难的不是"生成一句自然的话"，而是：

记住早期约束
处理后续修改
找到正确对象
解决指代
判断是否应该行动

Hy-MultiTurn直接从真实 chatbot failure 中总结出六种典型问题：

复制代码

1. Constraint Memory
2. Precise Execution
3. Constraint Synthesis
4. Object Localization
5. Action Suppression
6. Reference Resolution

2. 怎么解决？

论文不是简单生成一批多轮问题，而是：

复制代码

真实对话失败
      ↓
分析Failure Mode
      ↓
总结6种机制
      ↓
设计Controlled Task
      ↓
加入：
长对话
无关信息
口语表达
      ↓
Benchmark

最终：

复制代码

209 tasks
12～76 turns
6个evaluation dimensions

3. 和其他方法有什么不同？

普通 Multi-Turn Benchmark 更关注：

复制代码

Response Quality

Hy-MultiTurn关注：

复制代码

Dialogue State
      ↓
Constraint
      ↓
Object
      ↓
Reference
      ↓
Action

尤其值得注意的是：

Action Suppression

它不是测试：

模型会不会执行任务。

而是测试：

模型知道什么时候不能执行任务。

这对于 Agent 非常关键。

4. 怎么实验验证？

论文测试：

复制代码

22个模型配置
209个任务
12～76轮

采用严格的 requirement-level evaluation。

最重要的结果：

即使整体表现最好的 GPT-5.5，也只能在 41.1% 的响应中满足全部要求。

同时：

没有一个模型在六个维度上全部最好。

说明多轮理解并不是一个单一能力，而是：

复制代码

Memory
+
Constraint Reasoning
+
Reference
+
Action Control

多个能力的组合。

一句话总结

Hy-MultiTurn不是单纯把对话变长，而是从真实失败案例出发，把"深层多轮理解"拆成6种可控failure mode进行评估。

四、RegretBench：模型"会提问"不等于"会澄清"

论文： One More Turn, Less Regret: A Regret-Based Multi-Turn Benchmark for LLMs' Clarification Policies

论文地址：arXiv:2607.21143

1. 解决什么问题？

用户说：

"帮我推荐一台电脑。"

模型当然可以问：

"你预算多少？"

但真正的问题不是：

这个问题看起来是否合理？

而是：

复制代码

现在应该不应该问？
应该问什么？
问几个问题？
什么时候停止？
什么时候直接回答？

所以论文认为：

Clarification本质上是一个Sequential Decision Problem。

2. 怎么解决？

论文提出 RegretBench。

给定一个存在歧义的用户请求：

复制代码

User Query
      ↓
多个Hidden Intent
      ↓
模型选择：
Ask / Answer / Stop
      ↓
User Response
      ↓
更新Intent State
      ↓
继续交互

因此模型不能只生成"好问题"，还必须决定：

什么时候问、问什么、什么时候停。

同时设计 regret：

复制代码

最终任务价值
-
交互成本
-
无效提问惩罚

最终评价整个 clarification policy。

3. 和其他方法有什么不同？

传统方法：

复制代码

Question Quality

RegretBench：

复制代码

Clarification Policy

因此：

复制代码

模型A：
成功率80%
问2轮

模型B：
成功率82%
问8轮

传统 benchmark：

复制代码

B > A

RegretBench可能：

复制代码

A > B

因为 B 浪费了更多交互成本。

论文特别强调：

最终Success Rate不足以评价Clarification。

4. 怎么实验验证？

论文在：

复制代码

Open-domain QA
Product Recommendation

场景进行多轮实验。

主要观察：

复制代码

Intent Resolution
Success
Interaction Cost
Ineffective Clarification
Stopping
Regret

实验发现：

即使模型最终准确率相近，其效率、鲁棒性和停止策略也可能存在明显差异。

因此：

"问得像样"与"问得有效"是两回事。

一句话总结

RegretBench把"澄清问题质量"升级为"澄清策略质量"，评价模型是否在正确的时间提出正确的问题，并及时停止。

五、EYT-Bench：如何真正模拟"人与模型连续聊天"？

论文： Enjoy Your Talk: A Human-Centered Benchmark for Multi-Turn Dialogue with Decoupled User Simulation, Target Modeling, and Judging

论文地址：arXiv:2607.10428

1. 解决什么问题？

传统对话Benchmark：

复制代码

固定User
     ↓
固定问题
     ↓
模型回答

最大问题：

User不会根据模型的回答动态变化。

现实用户会：

复制代码

改变目标
改变情绪
补充信息
隐藏意图
继续追问

所以 EYT-Bench 希望建立真正的：

复制代码

User Simulator
      ↕
Target Model
      ↕
Judge

动态交互环境。

2. 怎么解决？

三个模块完全解耦。

User Simulator

负责：

复制代码

Persona
Goal
Explicit Intent
Latent Intent
Emotion

根据模型回答动态产生下一轮用户输入。

Target Model

同时评价：

复制代码

Intent
Emotion

并生成 response。

Judge

从外部评价：

复制代码

Empathy
Persona Alignment
Anthropomorphic Interaction
Final Intent Completion

也就是：

复制代码

User负责"演"
Agent负责"答"
Judge负责"评"

3. 和其他方法有什么不同？

最重要的区别：

把User Simulator、Target Model、Judge三个角色彻底分开。

避免：

复制代码

同一个模型
既生成用户
又生成Agent
又评价Agent

产生严重的 self-preference bias。

同时，评价也不只看：

复制代码

response自然不自然

而是同时看：

复制代码

Intent Tracking
+
Emotion
+
Persona
+
Final Goal Completion

4. 怎么实验验证？

论文构建：

复制代码

3400 dialogues
17 target models

并比较不同模型在：

复制代码

Objective：
Intent / Emotion / Goal

Subjective：
Empathy
Persona
Anthropomorphic Interaction

上的表现。

实验发现一个很重要的现象：

模型"聊得像真人"与"真正理解用户"并不是一回事。

模型在主观聊天体验上的差距可能不大，但 objective intent tracking 的差距非常明显。

这说明：

复制代码

"看起来会聊天"
        ≠
"真的理解用户"

一句话总结

EYT-Bench的核心贡献不是又做了一个聊天数据集，而是构建了User Simulator--Target Model--Judge三方解耦的动态多轮评估环境。

六、RSPO：Dense Reward和Outcome Reward到底应该怎么用？

论文： RSPO: Reward-Swap Policy Optimization for Multi-Turn LLM Agents

论文地址：arXiv:2607.04713

1. 解决什么问题？

多轮 Agent 经常是：

复制代码

Turn 1
 ↓
Turn 2
 ↓
...
 ↓
Turn 20
 ↓
Success / Failure

所以最终 reward 非常稀疏：

复制代码

0 / 1

这导致训练：

复制代码

探索困难
学习信号弱
训练效率低

于是很多方法引入 Dense Process Reward。

但 Dense Reward 又可能有问题：

模型学会了获得高过程分，而不一定真正完成任务。

2. 怎么解决？

RSPO把两个 reward 的职责彻底分开：

复制代码

Dense Reward
      ↓
只负责探索

Outcome Reward
      ↓
负责最终优化

具体流程：

复制代码

Dense Reward Agent
       ↓
探索环境
       ↓
产生更多trajectory
       ↓
把Dense Reward替换成Outcome Reward
       ↓
Replay Buffer
       ↓
用真实Outcome Reward训练

所以叫：

Reward-Swap Policy Optimization

核心就是：

复制代码

Dense Reward → Exploration

Outcome Reward → Learning

3. 和其他方法有什么不同？

普通 Outcome RL：

复制代码

Outcome Reward
 ↓
探索
 ↓
训练

问题：

复制代码

reward太稀疏

普通 Process Reward：

复制代码

Dense Reward
 ↓
训练

问题：

复制代码

可能Reward Hacking

RSPO：

复制代码

Dense Reward
 ↓
帮助Agent找到更多trajectory
 ↓
丢掉Dense Reward
 ↓
重新使用真实Outcome Reward
 ↓
训练

也就是：

用 Dense Reward 帮你"找到路"，但最终只相信任务是否真正完成。

4. 怎么实验验证？

论文在：

复制代码

ALFWorld
WebShop

上测试，并与：

复制代码

GRPO
PPO
GiGPO
SPEAR

等方法比较。

实验结果显示 RSPO 在多个环境和模型规模上取得更好的任务成功表现，尤其对较小模型收益更明显。

原因也很好理解：

复制代码

小模型
 ↓
探索能力弱
 ↓
Dense Reward帮助寻找有效trajectory
 ↓
RSPO收益更大

一句话总结

RSPO不直接相信Dense Reward，而是让Dense Reward负责探索、Outcome Reward负责最终优化，从而同时解决Sparse Reward和Reward Misalignment问题。

七、总结

论文	解决的问题	方法	最大区别	实验验证
CrEST	多轮RL的credit分配不准确	Turn + Token层级credit	Teacher只控制更新幅度	BFCL V3、WildToolBench
TrajWiki	长期Memory无法追踪演化	Memory Trajectory + Wiki	Memory有来源、有历史	LoCoMo、MedMT
Hy-MultiTurn	传统Benchmark测不出深层多轮理解	6种failure modes	从真实失败机制设计Benchmark	209任务、12--76轮、22模型
RegretBench	不知道什么时候该澄清	Hidden Intent + Regret	从问题质量转向策略质量	QA、推荐任务
EYT-Bench	静态Benchmark缺乏真实交互	User--Agent--Judge解耦	User Simulator动态参与	3400 dialogues、17模型
RSPO	Multi-turn RL reward太稀疏	Dense探索 + Outcome训练	Dense reward不直接用于最终优化	ALFWorld、WebShop

八、最值得注意的共同趋势

这6篇论文实际上可以串成一条完整路线：

复制代码

长期多轮Agent
      │
      ├── TrajWiki
      │     ↓
      │   如何记忆？
      │
      ├── Hy-MultiTurn
      │     ↓
      │   如何理解？
      │
      ├── RegretBench
      │     ↓
      │   什么时候澄清？
      │
      ├── EYT-Bench
      │     ↓
      │   如何真实交互和评估？
      │
      ├── RSPO
      │     ↓
      │   如何训练？
      │
      └── CrEST
            ↓
          如何把训练信号
          精确分配到每一轮？

所以这几篇论文共同体现了一个变化：

Multi-Turn Dialogue研究正在从"评价一条Response"，转向"评价和训练整个Interaction Trajectory"。

过去：

复制代码

User → Response → Score

现在：

复制代码

User
 ↓
Agent
 ↓
State Update
 ↓
User
 ↓
Agent
 ↓
State Update
 ↓
...
 ↓
Final Goal

最终评价的不是一句话，而是：

复制代码

Memory
+
Intent Tracking
+
Clarification
+
Action Control
+
Interaction Efficiency
+
Goal Completion
+
Trajectory Quality

这也是这几篇论文最值得关注的地方。