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訓練模型然后在τ2-Bench Retail τ2-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τ2-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訓練與評估環境”。