StateGen → 如何生成高质量多轮Agent训练数据 DLawBench → 如何评价真实的多轮咨询能力 C-DIC → 如何让模型记住超长对话 ISE → 如何生成真实执行环境中的多轮Agent轨迹 LANTERN → 上下文压缩后如何找回丢失的信息 WRIT → 如何生成更“难”的多轮Agent训练轨迹最近阅读了 6 篇与Multi-Turn Dialogue、User Simulation、Agent Trajectory、Long-Term Memory高度相关的论文。第一篇做合成多轮Agent训练数据第二篇做法律 LLM Benchmark第三篇长程任务的长期memory研究一、StateGen如何生成真正“有状态”的多轮Agent训练数据论文State-Grounded Multi-Agent Synthetic Data Generation for Tool-Augmented LLMs1. 解决的问题现有的方法能够 “生成对话”也能够 “模拟工具”甚至能够 “模拟多智能体”但是很难同时保证多轮 工具调用 后端状态一致 多智能体协作 用户个性变化 自动评价。Tool Simulator 本身也是 LLM很容易产生错误。如何在大规模合成多轮Agent数据时让所有工具调用都与真实世界状态保持一致论文将问题归结为1tool-call hallucination。一个 hallucination 会污染整个多轮 trajectory。2multi-turn state inconsistency。方法主要解决ToolformerLLM 如何学习调用 ToolReActReasoning Tool ActionStateGen如何生成可靠的 Tool-Agent-User 多轮训练数据2. 方法论文figure11State Manager。它建立一个唯一可信的后端状态。Tool Simulator 必须根据当前真实状态回答。Tool Response 之后还要更新 State这样LLM看到的是而不是瞎猜。2User Simulator。使用一个23维Persona Vector6 个demographic traits12 个behavioral traits5 个emotional states还加入了 Query Complexity用户请求还会分成SimpleMediumComplexVague更加符合真实生产环境vague query 可以迫使 Agent 在 Tool Selection 前进行多轮 clarification。38-Axis Judge。Goal AchievementTool UsageTool-call HallucinationReasoning QualityReasoning HallucinationCommunication QualityConsistencyError HandlingTool Hallucination 和任务成功之间相关性很弱。“任务做成功”≠“Agent 行为正确”。说明 hallucination 本身形成一个比较独立的 failure mode。所以拆成8个维度进行打分。原有方法能做什么核心缺点StateGen 怎么解决Self-Instruct大规模生成 Instruction单轮、Text-onlyMulti-turn loopAlpacaInstruction → Response没有真实 Tool StateState ManagerWizardLM复杂 Instruction没有 Tool GroundingTool Simulator StateToolformer学会调用 Tool重点是 Tool Use不是训练数据生成Synthetic trajectory generationReActReasoning Action没有解决大规模可靠数据生成User-Agent-Tool-Judge loopτ-benchTool-Agent-User Benchmark主要用于 Evaluation状态人工设计自动生成训练轨迹AutoGenMulti-Agent Runtime主要是运行时编排Multi-Agent Data GenerationLangGraphAgent WorkflowRuntime不是 Training Data GeneratorSub-agent-as-toolMatrixMulti-turn Multi-Agent Data缺少明确 Shared StateAuthoritative Shared StateStateGenMulti-turn Tool Multi-Agent Judge—统一解决StateGen解决的是“如何批量生成可信的多轮Tool-Agent训练数据”核心创新是让所有Tool Response都受到统一World State约束。二、DLawBench如何评价模型真正的“多轮咨询能力”论文DLawBench: Evaluating LLMs Through Multi-Turn Legal ConsultationQwen Team, Alibaba Group1. 解决的问题现有法律 LLM Benchmark 大多假设“案件事实已经完整给模型”只测试模型能不能回答法律问题。但真实律师咨询中事实是不完整的、客户可能理解错误而且律师必须通过多轮追问主动把关键事实问出来再基于事实进行法律推理。1no information gather。传统的bench的路线是Complete Facts → Legal Reasoning现实咨询却是Incomplete Facts → Information Gathering → Legal Reasoning这之间就存在了gap。2legal sycophancy。无法评价 “问什么问题”“下一句话应该问客户什么” 是一个很重要的测评。因为客户可能会提供错误的法律观点。模型可能会出现谄媚现象。论文figure13no User-side Variation。现实中的客户是不同类型的不是只有单一画像。维度Traditional Legal BenchmarksInteractive BenchmarksDLawBench法律推理✓✓✓多轮交互✗✓✓主动询问事实✗部分✓客户信息不完整✗部分✓客户存在错误认知✗不强调✓客户性格变化✗部分✓Client Belief✗✗✓Court Record通常直接提供通常环境状态✓Perspective Separation✗✗✓事实发现评价✗有限✓法律问题解决评价✓✓✓Claim Support有限有限✓Legal Sycophancy难发现难发现可以诊断2. 方法1把同一个案件拆成两套信息A.Client Belief模拟用户知道和相信的事情。B.Court Record真正的、经过法律判断的事实。模型能看到Client Belief但是不知道Court Record就会一直追问模型必须通过多轮提问发现关键事实。2User Profile。论文设计了四种Client Narrative Styles论文figure4类型客户行为Cooperative主动提供信息Dependent等律师引导Withdrawn不愿透露信息Adversarial防御、质疑律师DLawBench把多轮对话评估从“回答正确”推进到了“能否主动获取解决任务所需的信息”。三、C-DIC对话越来越长之后模型怎么“记住”论文Context-Driven Incremental Compression for Multi-Turn Dialogue Generation1. 解决的问题最直接的方法Turn 1 Turn 2 ... Turn 100每一轮都把全部历史放进 Context。问题Context越来越长 ↓ Attention成本越来越高 ↓ 大量历史信息其实没有用于是有人采用截断或者Summarization但又产生重要细节丢失 旧信息无法修改 多轮压缩误差不断累积论文认为真正的问题是对话不是一个不断增长的文本而是多个不断变化的Context Threads。2. 方法论文提出C-DICContext-Driven Incremental Compression核心流程当前User Query ↓ Retrieve ↓ 找到相关Memory Thread ↓ Generate Response ↓ Compress当前Turn ↓ Revision / Write-back ↓ 更新Memory也就是Retrieve ↓ Generate ↓ Compress ↓ Write Back最关键Memory可以修改如果Query与旧Memory高度相关就Revision如果发现新Topic就Insert New Memory因此不是Memory不断append而是Memory ├── Thread A ├── Thread B └── Thread C每个Thread都可以不断更新。同时论文引入Retrieval-aware TBPTT只沿着真正被检索、被更新的Memory路径传播训练信号而不是对完整历史做BPTT。3. 和其他方法不同在哪里传统Full Context问题计算量随对话增长。Truncation只保留最近几轮问题旧信息直接消失。Summarization全文 ↓ Summary问题不可避免的信息压缩损失。RAGQuery ↓ Retrieve历史文本问题检索的是原始文本没有学习一个适合长期对话的可更新Memory。C-DICDialogue ↓ Latent Thread Memory ↓ Retrieve ↓ Revision所以它的关键区别是“压缩 检索 可修改Memory”三者结合。4. 怎么实验验证主要使用MSC REALTALK LongMemEval其中 REALTALK 非常长21.9 sessions 894.4 utterances / conversation主要比较Full Prompting Truncation Summarization RAG LLMLingua InfLLM AutoCompressor ICAE C-DIC结果MSC PPL 8.431 BLEU 0.023 ROUGE-L 0.160 REALTALK PPL 9.789 BLEU 0.035 ROUGE-L 0.134整体优于主要baseline。更重要的是在数百轮对话中C-DIC的推理延迟和PPL保持稳定。一句话总结C-DIC不是简单压缩历史而是把长对话拆成可检索、可修改的Context Threads让Memory随着对话不断更新。四、ISE为什么Agent训练数据一定要“真的执行一次”论文ISE: An Execution-Grounded Recipe for Multi-Turn OS-Agent Trajectories论文原文arXiv:2606.115201. 解决什么问题以前生成Agent训练数据通常LLM生成User ↓ LLM生成Agent ↓ LLM模拟Tool问题是训练数据中的Tool Execution可能根本不是真的。例如Agent 创建文件 test.py Tool Simulator 创建成功但真实环境中权限不足 文件已存在 路径错误 命令执行失败这些真正重要的Failure → Recovery训练数据里却很少。论文认为OS Agent数据存在三个问题1. Intent覆盖不足 2. User Simulator容易role drift 3. Tool Execution是模拟的而不是真实执行2. 怎么解决ISE Intent → Simulate → ExecuteStage 1Intent构造Persona × Domain × Task × Complexity生成约50,000 intents去重后43,956 unique intentsStage 2Simulate使用Role-Locked User Simulator用户模拟器必须遵守Perspective Lock Register Matching Incremental Advancement Responsive Conditioning避免出现User I can help you with...这种明显的User → Assistant角色漂移同时下一轮User必须基于上一轮真实执行结果。Stage 3Execute最重要的一步所有Tool Call直接在真实隔离OS环境中执行。因此Agent ↓ 真实Shell ↓ 真实文件 ↓ 真实Command ↓ 真实Error ↓ User Simulator ↓ 下一轮而不是让另一个LLM告诉你“这个命令应该成功。”3. 和其他方法不同在哪里最核心的区别普通Synthetic Data LLM ↓ 模拟ExecutionISELLM ↓ Real OS ↓ 真实Execution Result ↓ 下一轮User因此它生成的数据天然包含成功 失败 恢复 状态变化而且 User Simulator 也不是固定脚本而是根据真实执行结果动态改变下一轮用户行为。因此真正形成User ↕ Agent ↕ Real Environment三方闭环。4. 怎么实验验证最终得到43,956 unique intents 23,132 complete trajectories 965 personas 10 domains平均8.12 user turns 68.24 total dialogue turns 29.26 tool calls然后用 ISETrace 做 SFT。Qwen3-8BClawEval Pass1 Base 19.3 ISETrace SFT 37.7接近翻倍。更重要的是Qwen3-8B ISETrace甚至超过Qwen3-32B Base GPT-4o Zero-shot在 BFCL 的 Stateful Web Search / Memory 类任务上提升尤其明显。一句话总结ISE最大的贡献不是“生成更多数据”而是让每一轮用户行为都建立在真实OS执行结果上从而生成真正具有Failure-Recovery的多轮Agent轨迹。五、LANTERN上下文压缩后丢掉的信息怎么找回来论文LANTERN: Layered Archival and Temporal Episodic Retrieval Network for Long-Context LLM Conversations论文原文arXiv:2606.051821. 解决什么问题长对话系统经常需要Conversation ↓ Context Compaction例如“服务器运行在8080端口”压缩后变成“服务器配置完成”那么8080这个具体事实就消失了。论文把这个问题称为Context Cliff即Compaction之前 大量事实 Compaction之后 摘要保留语义 但具体事实丢失2. 怎么解决LANTERN的思路非常直接压缩Context但不要删除原始历史。每一轮对话都主动ArchiveTurn 1 Turn 2 Turn 3 ... Turn N然后建立Lexical Retrieval Semantic Retrieval Temporal Retrieval最后使用Reciprocal Rank FusionRRF将多个检索结果融合。所以Compaction ↓ Context变短 用户突然问 “之前那个错误码是多少” ↓ Hybrid Retrieval ↓ 找到原始Turn ↓ 恢复到当前Context3. 和其他方法不同在哪里传统Summarization历史 ↓ 摘要 ↓ 旧细节永久消失Neural RAGEmbedding ↓ Semantic Retrieval但可能找不到具体数字 错误码 文件名 函数名 端口号MemGPT通过LLM决定什么应该存 什么时候存但是LLM calls 成本 延迟都比较高。LANTERN则采用Extractive Archival Hybrid Retrieval基础版本甚至不需要LLM调用。4. 怎么实验验证论文使用94 real conversations 1,894 ground-truth facts并与Summarization Neural RAG MemGPT-Faithful比较。核心结果LANTERN-Rerank 78.3% fact recovery MemGPT-Faithful 72.4%而且Base LANTERN 76.3%已经超过 MemGPT baseline。进一步让 4 个生产级LLM回答事实问题加入 LANTERN 恢复的Context后平均准确率提升8.4个百分点。一句话总结LANTERN的核心不是“更聪明地压缩”而是“压缩以后仍然保留原始事实并在需要时重新检索回来”。六、WRIT为什么Agent训练数据不能只让任务“变长”论文WRIT: Write-Read Intensive Trajectory Synthesis for Multi-Turn User-Facing Agents论文原文arXiv:2606.029081. 解决什么问题现有Agent训练数据通常通过增加Task数量 增加Tool Call 增加Write Action把任务变得更复杂。例如搜索航班 ↓ 预订航班 ↓ 修改订单 ↓ 取消订单这种方法训练的是Long-Horizon Sequential Execution但现实任务还有另外一种难度真正执行一个Write之前需要读很多信息。例如用户说“帮我订所有日期和机场组合中最快的航班。”Agent不能直接book(...)必须Search Airport A Search Date 1 Search Date 2 Search Airport B Search Date 1 Search Date 2 ... ↓ 比较所有结果 ↓ 找到最快航班 ↓ 获得flight_number ↓ Book因此一次Write Decision本身也可能非常困难。2. 怎么解决WRIT提出两个独立的复杂度轴Axis 1Write ComplexityWrite 1 ↓ Write 2 ↓ Write 3 ↓ ...控制一个任务需要多少次状态改变。Axis 2Read ComplexityRead Read Read Read ↓ Compare ↓ Ground Arguments ↓ Write控制做一次Write之前需要读取多少证据。所以Task Complexity │ ┌─────────┴─────────┐ ↓ ↓ Write-heavy Read-heavy │ │ 多次Action 大量Evidence │ │ Long Horizon Grounding Difficulty然后再加入Progressive Disclosure Self Correction Confirmation Hesitation Emotion Irrelevant Aside False Premise Social Pressure等用户行为变化。最后在可执行环境中模拟User Simulator ↕ Agent ↕ Environment只保留成功完成的轨迹。3. 和其他方法不同在哪里传统轨迹生成让Agent“做更多”。WRIT不仅让Agent做更多还要求Agent在做之前“知道更多”。因此传统 Longer Task ↓ More Writes ↓ Longer TrajectoryWRITLonger Task More Writes More Reads Evidence Comparison User Behavior Variation特别是Read-heavy trajectory这是WRIT最核心的创新。因为很多Agent数据让模型Search once ↓ Immediately Write容易形成premature action而WRIT训练模型Search ↓ Search ↓ Compare ↓ Verify ↓ Act4. 怎么实验验证论文只使用2K synthesized trajectories训练模型然后在τ²-Bench Retail τ²-Bench Airline上测试。以 Qwen3-4B 为例APIGen-MT Average Pass1 40.85 Simia 46.80 CoVe 52.90 AReaL 55.64 WRIT 67.99Hard subsetRetail-Hard 66.13 Airline-Hard 57.50而且论文发现仅仅2K条经过结构化设计的WRIT轨迹就可以让4B模型超过GPT-5.1 no-think。消融实验进一步证明Read-heavy synthesis User behavior diversification两部分都独立贡献性能。一句话总结WRIT解决的是“Agent训练数据虽然越来越长但没有真正增加决策难度”的问题通过Write-heavy Read-heavy两个维度构造更有价值的多轮轨迹。七、总结论文解决的问题核心方法与其他方法最大的区别实验StateGen合成数据中的Tool状态会乱State Manager Multi-roleBackend is Truth64K conversationsDLawBench传统Benchmark不会测“主动询问”Client Simulator Expert Rubrics评价信息获取策略461 cases / 26 LLMC-DIC超长对话Context越来越大Retrieve Compress ReviseMemory可修改MSC / REALTALKISEAgent轨迹缺少真实执行Intent → Simulate → Execute真OS执行23K trajectoriesLANTERNContext压缩导致事实丢失Archive Hybrid Retrieval不依赖LLM做基础Memory1,894 factsWRIT训练轨迹只是“变长”而不是“变难”Write Read Complexity显式建模Evidence Burdenτ²-Bench八、这6篇论文其实可以串成一个完整的“多轮Agent数据闭环”把它们放到一起看会发现非常明显User Simulator │ ↓ Multi-Turn Task │ ┌────────────┼────────────┐ ↓ ↓ ↓ StateGen ISE WRIT │ │ │ 状态一致性 真实执行 任务难度 │ │ │ └────────────┼────────────┘ ↓ Trajectory │ ↓ Multi-Turn Agent │ ┌────────────┼────────────┐ ↓ ↓ ↓ Memory Information Action │ Gathering Policy ↓ ↓ ↓ C-DIC / DLawBench WRIT LANTERN │ ↓ Evaluation │ ↓ Better Agent因此这一批论文和上一批论文相比一个非常明显的变化是研究重点已经从“如何评价一个多轮模型”进一步转向“如何构造一个完整的多轮Agent训练与评估环境”。