StateGen → 如何生成高質(zhì)量多輪Agent訓(xùn)練數(shù)據(jù) DLawBench → 如何評價(jià)真實(shí)的多輪咨詢能力 C-DIC → 如何讓模型記住超長對話 ISE → 如何生成真實(shí)執(zhí)行環(huán)境中的多輪Agent軌跡 LANTERN → 上下文壓縮后如何找回丟失的信息 WRIT → 如何生成更“難”的多輪Agent訓(xùn)練軌跡最近閱讀了 6 篇與Multi-Turn Dialogue、User Simulation、Agent Trajectory、Long-Term Memory高度相關(guān)的論文。第一篇做合成多輪Agent訓(xùn)練數(shù)據(jù)第二篇做法律 LLM Benchmark第三篇長程任務(wù)的長期memory研究一、StateGen如何生成真正“有狀態(tài)”的多輪Agent訓(xùn)練數(shù)據(jù)論文State-Grounded Multi-Agent Synthetic Data Generation for Tool-Augmented LLMs1. 解決的問題現(xiàn)有的方法能夠 “生成對話”也能夠 “模擬工具”甚至能夠 “模擬多智能體”但是很難同時(shí)保證多輪 工具調(diào)用 后端狀態(tài)一致 多智能體協(xié)作 用戶個(gè)性變化 自動(dòng)評價(jià)。Tool Simulator 本身也是 LLM很容易產(chǎn)生錯(cuò)誤。如何在大規(guī)模合成多輪Agent數(shù)據(jù)時(shí)讓所有工具調(diào)用都與真實(shí)世界狀態(tài)保持一致論文將問題歸結(jié)為1tool-call hallucination。一個(gè) hallucination 會污染整個(gè)多輪 trajectory。2multi-turn state inconsistency。方法主要解決ToolformerLLM 如何學(xué)習(xí)調(diào)用 ToolReActReasoning Tool ActionStateGen如何生成可靠的 Tool-Agent-User 多輪訓(xùn)練數(shù)據(jù)2. 方法論文figure11State Manager。它建立一個(gè)唯一可信的后端狀態(tài)。Tool Simulator 必須根據(jù)當(dāng)前真實(shí)狀態(tài)回答。Tool Response 之后還要更新 State這樣LLM看到的是而不是瞎猜。2User Simulator。使用一個(gè)23維Persona Vector6 個(gè)demographic traits12 個(gè)behavioral traits5 個(gè)emotional states還加入了 Query Complexity用戶請求還會分成SimpleMediumComplexVague更加符合真實(shí)生產(chǎn)環(huán)境vague query 可以迫使 Agent 在 Tool Selection 前進(jìn)行多輪 clarification。38-Axis Judge。Goal AchievementTool UsageTool-call HallucinationReasoning QualityReasoning HallucinationCommunication QualityConsistencyError HandlingTool Hallucination 和任務(wù)成功之間相關(guān)性很弱。“任務(wù)做成功”≠“Agent 行為正確”。說明 hallucination 本身形成一個(gè)比較獨(dú)立的 failure mode。所以拆成8個(gè)維度進(jìn)行打分。原有方法能做什么核心缺點(diǎn)StateGen 怎么解決Self-Instruct大規(guī)模生成 Instruction單輪、Text-onlyMulti-turn loopAlpacaInstruction → Response沒有真實(shí) Tool StateState ManagerWizardLM復(fù)雜 Instruction沒有 Tool GroundingTool Simulator StateToolformer學(xué)會調(diào)用 Tool重點(diǎn)是 Tool Use不是訓(xùn)練數(shù)據(jù)生成Synthetic trajectory generationReActReasoning Action沒有解決大規(guī)模可靠數(shù)據(jù)生成User-Agent-Tool-Judge loopτ-benchTool-Agent-User Benchmark主要用于 Evaluation狀態(tài)人工設(shè)計(jì)自動(dòng)生成訓(xùn)練軌跡AutoGenMulti-Agent Runtime主要是運(yùn)行時(shí)編排Multi-Agent Data GenerationLangGraphAgent WorkflowRuntime不是 Training Data GeneratorSub-agent-as-toolMatrixMulti-turn Multi-Agent Data缺少明確 Shared StateAuthoritative Shared StateStateGenMulti-turn Tool Multi-Agent Judge—統(tǒng)一解決StateGen解決的是“如何批量生成可信的多輪Tool-Agent訓(xùn)練數(shù)據(jù)”核心創(chuàng)新是讓所有Tool Response都受到統(tǒng)一World State約束。二、DLawBench如何評價(jià)模型真正的“多輪咨詢能力”論文DLawBench: Evaluating LLMs Through Multi-Turn Legal ConsultationQwen Team, Alibaba Group1. 解決的問題現(xiàn)有法律 LLM Benchmark 大多假設(shè)“案件事實(shí)已經(jīng)完整給模型”只測試模型能不能回答法律問題。但真實(shí)律師咨詢中事實(shí)是不完整的、客戶可能理解錯(cuò)誤而且律師必須通過多輪追問主動(dòng)把關(guān)鍵事實(shí)問出來再基于事實(shí)進(jìn)行法律推理。1no information gather。傳統(tǒng)的bench的路線是Complete Facts → Legal Reasoning現(xiàn)實(shí)咨詢卻是Incomplete Facts → Information Gathering → Legal Reasoning這之間就存在了gap。2legal sycophancy。無法評價(jià) “問什么問題”“下一句話應(yīng)該問客戶什么” 是一個(gè)很重要的測評。因?yàn)榭蛻艨赡軙峁╁e(cuò)誤的法律觀點(diǎn)。模型可能會出現(xiàn)諂媚現(xiàn)象。論文figure13no User-side Variation。現(xiàn)實(shí)中的客戶是不同類型的不是只有單一畫像。維度Traditional Legal BenchmarksInteractive BenchmarksDLawBench法律推理???多輪交互???主動(dòng)詢問事實(shí)?部分?客戶信息不完整?部分?客戶存在錯(cuò)誤認(rèn)知?不強(qiáng)調(diào)?客戶性格變化?部分?Client Belief???Court Record通常直接提供通常環(huán)境狀態(tài)?Perspective Separation???事實(shí)發(fā)現(xiàn)評價(jià)?有限?法律問題解決評價(jià)???Claim Support有限有限?Legal Sycophancy難發(fā)現(xiàn)難發(fā)現(xiàn)可以診斷2. 方法1把同一個(gè)案件拆成兩套信息A.Client Belief模擬用戶知道和相信的事情。B.Court Record真正的、經(jīng)過法律判斷的事實(shí)。模型能看到Client Belief但是不知道Court Record就會一直追問模型必須通過多輪提問發(fā)現(xiàn)關(guān)鍵事實(shí)。2User Profile。論文設(shè)計(jì)了四種Client Narrative Styles論文figure4類型客戶行為Cooperative主動(dòng)提供信息Dependent等律師引導(dǎo)Withdrawn不愿透露信息Adversarial防御、質(zhì)疑律師DLawBench把多輪對話評估從“回答正確”推進(jìn)到了“能否主動(dòng)獲取解決任務(wù)所需的信息”。三、C-DIC對話越來越長之后模型怎么“記住”論文Context-Driven Incremental Compression for Multi-Turn Dialogue Generation1. 解決的問題最直接的方法Turn 1 Turn 2 ... Turn 100每一輪都把全部歷史放進(jìn) Context。問題Context越來越長 ↓ Attention成本越來越高 ↓ 大量歷史信息其實(shí)沒有用于是有人采用截?cái)嗷蛘逽ummarization但又產(chǎn)生重要細(xì)節(jié)丟失 舊信息無法修改 多輪壓縮誤差不斷累積論文認(rèn)為真正的問題是對話不是一個(gè)不斷增長的文本而是多個(gè)不斷變化的Context Threads。2. 方法論文提出C-DICContext-Driven Incremental Compression核心流程當(dāng)前User Query ↓ Retrieve ↓ 找到相關(guān)Memory Thread ↓ Generate Response ↓ Compress當(dāng)前Turn ↓ Revision / Write-back ↓ 更新Memory也就是Retrieve ↓ Generate ↓ Compress ↓ Write Back最關(guān)鍵Memory可以修改如果Query與舊Memory高度相關(guān)就Revision如果發(fā)現(xiàn)新Topic就Insert New Memory因此不是Memory不斷append而是Memory ├── Thread A ├── Thread B └── Thread C每個(gè)Thread都可以不斷更新。同時(shí)論文引入Retrieval-aware TBPTT只沿著真正被檢索、被更新的Memory路徑傳播訓(xùn)練信號而不是對完整歷史做BPTT。3. 和其他方法不同在哪里傳統(tǒng)Full Context問題計(jì)算量隨對話增長。Truncation只保留最近幾輪問題舊信息直接消失。Summarization全文 ↓ Summary問題不可避免的信息壓縮損失。RAGQuery ↓ Retrieve歷史文本問題檢索的是原始文本沒有學(xué)習(xí)一個(gè)適合長期對話的可更新Memory。C-DICDialogue ↓ Latent Thread Memory ↓ Retrieve ↓ Revision所以它的關(guān)鍵區(qū)別是“壓縮 檢索 可修改Memory”三者結(jié)合。4. 怎么實(shí)驗(yàn)驗(yàn)證主要使用MSC REALTALK LongMemEval其中 REALTALK 非常長21.9 sessions 894.4 utterances / conversation主要比較Full Prompting Truncation Summarization RAG LLMLingua InfLLM AutoCompressor ICAE C-DIC結(jié)果MSC PPL 8.431 BLEU 0.023 ROUGE-L 0.160 REALTALK PPL 9.789 BLEU 0.035 ROUGE-L 0.134整體優(yōu)于主要baseline。更重要的是在數(shù)百輪對話中C-DIC的推理延遲和PPL保持穩(wěn)定。一句話總結(jié)C-DIC不是簡單壓縮歷史而是把長對話拆成可檢索、可修改的Context Threads讓Memory隨著對話不斷更新。四、ISE為什么Agent訓(xùn)練數(shù)據(jù)一定要“真的執(zhí)行一次”論文ISE: An Execution-Grounded Recipe for Multi-Turn OS-Agent Trajectories論文原文arXiv:2606.115201. 解決什么問題以前生成Agent訓(xùn)練數(shù)據(jù)通常LLM生成User ↓ LLM生成Agent ↓ LLM模擬Tool問題是訓(xùn)練數(shù)據(jù)中的Tool Execution可能根本不是真的。例如Agent 創(chuàng)建文件 test.py Tool Simulator 創(chuàng)建成功但真實(shí)環(huán)境中權(quán)限不足 文件已存在 路徑錯(cuò)誤 命令執(zhí)行失敗這些真正重要的Failure → Recovery訓(xùn)練數(shù)據(jù)里卻很少。論文認(rèn)為OS Agent數(shù)據(jù)存在三個(gè)問題1. Intent覆蓋不足 2. User Simulator容易role drift 3. Tool Execution是模擬的而不是真實(shí)執(zhí)行2. 怎么解決ISE Intent → Simulate → ExecuteStage 1Intent構(gòu)造Persona × Domain × Task × Complexity生成約50,000 intents去重后43,956 unique intentsStage 2Simulate使用Role-Locked User Simulator用戶模擬器必須遵守Perspective Lock Register Matching Incremental Advancement Responsive Conditioning避免出現(xiàn)User I can help you with...這種明顯的User → Assistant角色漂移同時(shí)下一輪User必須基于上一輪真實(shí)執(zhí)行結(jié)果。Stage 3Execute最重要的一步所有Tool Call直接在真實(shí)隔離OS環(huán)境中執(zhí)行。因此Agent ↓ 真實(shí)Shell ↓ 真實(shí)文件 ↓ 真實(shí)Command ↓ 真實(shí)Error ↓ User Simulator ↓ 下一輪而不是讓另一個(gè)LLM告訴你“這個(gè)命令應(yīng)該成功?！?. 和其他方法不同在哪里最核心的區(qū)別普通Synthetic Data LLM ↓ 模擬ExecutionISELLM ↓ Real OS ↓ 真實(shí)Execution Result ↓ 下一輪User因此它生成的數(shù)據(jù)天然包含成功 失敗 恢復(fù) 狀態(tài)變化而且 User Simulator 也不是固定腳本而是根據(jù)真實(shí)執(zhí)行結(jié)果動(dòng)態(tài)改變下一輪用戶行為。因此真正形成User ? Agent ? Real Environment三方閉環(huán)。4. 怎么實(shí)驗(yàn)驗(yàn)證最終得到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 類任務(wù)上提升尤其明顯。一句話總結(jié)ISE最大的貢獻(xiàn)不是“生成更多數(shù)據(jù)”而是讓每一輪用戶行為都建立在真實(shí)OS執(zhí)行結(jié)果上從而生成真正具有Failure-Recovery的多輪Agent軌跡。五、LANTERN上下文壓縮后丟掉的信息怎么找回來論文LANTERN: Layered Archival and Temporal Episodic Retrieval Network for Long-Context LLM Conversations論文原文arXiv:2606.051821. 解決什么問題長對話系統(tǒng)經(jīng)常需要Conversation ↓ Context Compaction例如“服務(wù)器運(yùn)行在8080端口”壓縮后變成“服務(wù)器配置完成”那么8080這個(gè)具體事實(shí)就消失了。論文把這個(gè)問題稱為Context Cliff即Compaction之前 大量事實(shí) Compaction之后 摘要保留語義 但具體事實(shí)丟失2. 怎么解決LANTERN的思路非常直接壓縮Context但不要?jiǎng)h除原始?xì)v史。每一輪對話都主動(dòng)ArchiveTurn 1 Turn 2 Turn 3 ... Turn N然后建立Lexical Retrieval Semantic Retrieval Temporal Retrieval最后使用Reciprocal Rank FusionRRF將多個(gè)檢索結(jié)果融合。所以Compaction ↓ Context變短 用戶突然問 “之前那個(gè)錯(cuò)誤碼是多少” ↓ Hybrid Retrieval ↓ 找到原始Turn ↓ 恢復(fù)到當(dāng)前Context3. 和其他方法不同在哪里傳統(tǒng)Summarization歷史 ↓ 摘要 ↓ 舊細(xì)節(jié)永久消失Neural RAGEmbedding ↓ Semantic Retrieval但可能找不到具體數(shù)字 錯(cuò)誤碼 文件名 函數(shù)名 端口號MemGPT通過LLM決定什么應(yīng)該存 什么時(shí)候存但是LLM calls 成本 延遲都比較高。LANTERN則采用Extractive Archival Hybrid Retrieval基礎(chǔ)版本甚至不需要LLM調(diào)用。4. 怎么實(shí)驗(yàn)驗(yàn)證論文使用94 real conversations 1,894 ground-truth facts并與Summarization Neural RAG MemGPT-Faithful比較。核心結(jié)果LANTERN-Rerank 78.3% fact recovery MemGPT-Faithful 72.4%而且Base LANTERN 76.3%已經(jīng)超過 MemGPT baseline。進(jìn)一步讓 4 個(gè)生產(chǎn)級LLM回答事實(shí)問題加入 LANTERN 恢復(fù)的Context后平均準(zhǔn)確率提升8.4個(gè)百分點(diǎn)。一句話總結(jié)LANTERN的核心不是“更聰明地壓縮”而是“壓縮以后仍然保留原始事實(shí)并在需要時(shí)重新檢索回來”。六、WRIT為什么Agent訓(xùn)練數(shù)據(jù)不能只讓任務(wù)“變長”論文WRIT: Write-Read Intensive Trajectory Synthesis for Multi-Turn User-Facing Agents論文原文arXiv:2606.029081. 解決什么問題現(xiàn)有Agent訓(xùn)練數(shù)據(jù)通常通過增加Task數(shù)量 增加Tool Call 增加Write Action把任務(wù)變得更復(fù)雜。例如搜索航班 ↓ 預(yù)訂航班 ↓ 修改訂單 ↓ 取消訂單這種方法訓(xùn)練的是Long-Horizon Sequential Execution但現(xiàn)實(shí)任務(wù)還有另外一種難度真正執(zhí)行一個(gè)Write之前需要讀很多信息。例如用戶說“幫我訂所有日期和機(jī)場組合中最快的航班?！盇gent不能直接book(...)必須Search Airport A Search Date 1 Search Date 2 Search Airport B Search Date 1 Search Date 2 ... ↓ 比較所有結(jié)果 ↓ 找到最快航班 ↓ 獲得flight_number ↓ Book因此一次Write Decision本身也可能非常困難。2. 怎么解決WRIT提出兩個(gè)獨(dú)立的復(fù)雜度軸Axis 1Write ComplexityWrite 1 ↓ Write 2 ↓ Write 3 ↓ ...控制一個(gè)任務(wù)需要多少次狀態(tài)改變。Axis 2Read ComplexityRead Read Read Read ↓ Compare ↓ Ground Arguments ↓ Write控制做一次Write之前需要讀取多少證據(jù)。所以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等用戶行為變化。最后在可執(zhí)行環(huán)境中模擬User Simulator ? Agent ? Environment只保留成功完成的軌跡。3. 和其他方法不同在哪里傳統(tǒng)軌跡生成讓Agent“做更多”。WRIT不僅讓Agent做更多還要求Agent在做之前“知道更多”。因此傳統(tǒng) Longer Task ↓ More Writes ↓ Longer TrajectoryWRITLonger Task More Writes More Reads Evidence Comparison User Behavior Variation特別是Read-heavy trajectory這是WRIT最核心的創(chuàng)新。因?yàn)楹芏郃gent數(shù)據(jù)讓模型Search once ↓ Immediately Write容易形成premature action而WRIT訓(xùn)練模型Search ↓ Search ↓ Compare ↓ Verify ↓ Act4. 怎么實(shí)驗(yàn)驗(yàn)證論文只使用2K synthesized trajectories訓(xùn)練模型然后在τ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而且論文發(fā)現(xiàn)僅僅2K條經(jīng)過結(jié)構(gòu)化設(shè)計(jì)的WRIT軌跡就可以讓4B模型超過GPT-5.1 no-think。消融實(shí)驗(yàn)進(jìn)一步證明Read-heavy synthesis User behavior diversification兩部分都獨(dú)立貢獻(xiàn)性能。一句話總結(jié)WRIT解決的是“Agent訓(xùn)練數(shù)據(jù)雖然越來越長但沒有真正增加決策難度”的問題通過Write-heavy Read-heavy兩個(gè)維度構(gòu)造更有價(jià)值的多輪軌跡。七、總結(jié)論文解決的問題核心方法與其他方法最大的區(qū)別實(shí)驗(yàn)StateGen合成數(shù)據(jù)中的Tool狀態(tài)會亂State Manager Multi-roleBackend is Truth64K conversationsDLawBench傳統(tǒng)Benchmark不會測“主動(dòng)詢問”Client Simulator Expert Rubrics評價(jià)信息獲取策略461 cases / 26 LLMC-DIC超長對話Context越來越大Retrieve Compress ReviseMemory可修改MSC / REALTALKISEAgent軌跡缺少真實(shí)執(zhí)行Intent → Simulate → Execute真OS執(zhí)行23K trajectoriesLANTERNContext壓縮導(dǎo)致事實(shí)丟失Archive Hybrid Retrieval不依賴LLM做基礎(chǔ)Memory1,894 factsWRIT訓(xùn)練軌跡只是“變長”而不是“變難”Write Read Complexity顯式建模Evidence Burdenτ2-Bench八、這6篇論文其實(shí)可以串成一個(gè)完整的“多輪Agent數(shù)據(jù)閉環(huán)”把它們放到一起看會發(fā)現(xiàn)非常明顯User Simulator │ ↓ Multi-Turn Task │ ┌────────────┼────────────┐ ↓ ↓ ↓ StateGen ISE WRIT │ │ │ 狀態(tài)一致性 真實(shí)執(zhí)行 任務(wù)難度 │ │ │ └────────────┼────────────┘ ↓ Trajectory │ ↓ Multi-Turn Agent │ ┌────────────┼────────────┐ ↓ ↓ ↓ Memory Information Action │ Gathering Policy ↓ ↓ ↓ C-DIC / DLawBench WRIT LANTERN │ ↓ Evaluation │ ↓ Better Agent因此這一批論文和上一批論文相比一個(gè)非常明顯的變化是研究重點(diǎn)已經(jīng)從“如何評價(jià)一個(gè)多輪模型”進(jìn)一步轉(zhuǎn)向“如何構(gòu)造一個(gè)完整的多輪Agent訓(xùn)練與評估環(huán)境”。