ReIn: Conversational Error Recovery with Reasoning Inception¶

会议: ICLR 2026 arXiv: 2602.17022 代码: youngerous/rein 领域: llm_nlp 关键词: conversational agents, error recovery, test-time intervention, reasoning injection, tool-augmented dialogue, instruction hierarchy

一句话总结¶

提出 Reasoning Inception（ReIn），一种无需修改模型参数或系统提示的测试时干预方法，通过外部 inception 模块检测对话错误并将恢复计划注入任务 agent 的推理链中，在多种错误场景下显著提升对话任务完成率，且可泛化至未见错误类型。

研究背景与动机¶

LLM 驱动的对话 agent 在工具集成任务中表现良好，但在实际部署中面临用户引发的不可预测错误：

用户侧错误被低估：用户经常发出模糊请求（指代不明、多义解读）或超出系统能力范围的请求（不支持的操作、参数、领域）
错误恢复 vs 错误预防：已有工作主要关注错误预防（澄清、回退），而非错误发生后的诊断和恢复
现实约束：在实际系统中，任务 agent 的模型参数和系统提示通常已校准固定，修改成本高且可能引入副作用

核心挑战：如何在不修改模型参数和系统提示的约束下，使 agent 在遭遇用户错误时能够诊断问题并执行恢复？

方法详解¶

整体框架¶

ReIn 在每轮对话开始时通过外部 inception 模块检测潜在错误，生成包含恢复计划的推理块，注入到任务 agent 的内部推理上下文中。

对话管线形式化： - 用户策略：$u_t \sim \pi_u(\cdot | \mathcal{C}_t, \mathcal{R}_{partial})$ - Agent 内部上下文：$\tilde{\mathcal{C}}_t = \mathcal{C}_t \cup \sum_{k=1}^{t-1}\{z_k^{(i)}, \text{output}(z_k^{(i)})\} \cup \{u_t\}$ - Agent 动作采样：$z_t^{(i)} \sim \pi_c(\cdot | \tilde{\mathcal{C}}_t, \mathcal{L}, \mathcal{S})$

关键设计：ReIn 机制¶

Inception 模块 $F$：给定表层对话上下文 $\{\mathcal{C}_t, u_t\}$、工具列表 $\mathcal{L}$、错误-恢复映射 $\Phi: \mathcal{E} \to \mathcal{T}$，输出： - No：未检测到已知错误，对话正常进行 - (Yes, ρ_t)：检测到错误，$\rho_t \in \mathcal{T}$ 为恢复计划

推理注入： $$r_t = \begin{cases} \varnothing & F(\{\mathcal{C}_t, u_t\}, \mathcal{L}, \Phi, \mathcal{S}') = \text{No} \\ \texttt{think}[\rho_t] & \text{otherwise} \end{cases}$$

将 $r_t$ 包裹在 think 标签中注入 agent 的内部上下文：$\hat{\mathcal{C}}_t = \tilde{\mathcal{C}}_t \cup \{r_t\}$，后续动作采样在增强上下文上进行。

错误分类与恢复计划¶

用户场景	错误类型	恢复计划
模糊请求	指代不明 / 多义解读 / [UNSEEN]矛盾	生成内部错误报告
不支持请求	不支持操作 / 不支持参数 / [UNSEEN]不支持领域	转接人工客服

关键设计：标记 Contradiction 和 Domain 为 UNSEEN 类型，不包含在 inception 模块提示中，用于测试泛化能力。

与指令层级的关系¶

根据 Wallace et al. 的指令层级：System Message >> User Message >> Model Outputs >> Tool Outputs。ReIn 属于 Tool Outputs（优先级最低），但实验表明当与 JSON schema 定义的恢复工具配合时，ReIn 可以有效影响 agent 行为。若不定义对应工具（仅靠文本指令），则 agent 遵循系统提示忽略 ReIn（成功率 0%），验证了指令层级的存在。

损失函数¶

ReIn 为测试时干预方法，不涉及训练或损失函数。inception 模块使用现有 LLM，无需额外训练。

实验关键数据¶

主实验¶

基于 τ-Bench 改造，98 个对话会话，588 个上下文实例（392 已见，196 未见）。

Sonnet 3.7 作为任务 agent，不同 inception 模块效果（零售领域 Pass@1）：

Inception 模块	已见场景	未见场景
无 ReIn（基线）	~15%	~10%
Llama 3.2 3B	~35%	~25%
Llama 3.3 70B	~55%	~45%
Mistral Large 2	~55%	~48%
Sonnet 3.7	~62%	~52%

ReIn 在所有 inception 模块下均显著提升任务完成率。不使用 ReIn 时，模糊场景的 Pass@1 接近 0%。

与提示修改方法对比¶

方法	已见场景 Pass@1
无 ReIn（基线）	~15%
Naive Prompt Injection (NPI)	~40%
Self-Refine (SR)	~45%
ReIn	~62%

ReIn 在不修改提示的条件下，超过了两种需要修改提示的方法。

消融实验 / 泛化分析¶

泛化至未见错误类型：ReIn 能有效识别和恢复 Contradiction 和 Domain 错误（未见类型），部分情况下甚至超过已见类型的性能。

动态触发 vs 固定触发：允许 ReIn 在每轮动态激活（而非仅在预定错误轮），在大多数场景下进一步提升任务完成率。

3B 模型局限：最小 inception 模块的激活率显著低于大模型（Sonnet 3.7 接近 100%，3B 明显更低），原因在于小模型对长上下文的理解能力有限。

关键发现¶

指令层级实证：ReIn 归属 Tool Outputs（最低优先级），但配合 JSON schema 工具定义可"绕过"指令层级；无工具定义时成功率为 0%
错误类型差异：不支持场景的基线 Pass@1 (~20%) 高于模糊场景 (~0%)，因为系统提示中已有简短的人工转接指引
ReIn 的战略决策能力：在案例分析中，ReIn 能在用户持续坚持错误信息时主动升级至人工客服，展现了超越预定义场景的灵活性

亮点与洞察¶

极端约束下的有效方案：在不能修改参数/提示的强约束下，仅通过推理注入就能大幅提升恢复能力
指令层级的深入分析：首次实证研究了 ReIn 与指令层级的关系，发现工具定义是关键中介
泛化到未见错误：共享恢复策略的未见错误类型也能被有效处理，实用价值高
对话错误模拟方法：系统地构建了用户引发错误的分类体系和受控模拟环境
与 RAG/提示注入的精准区分：清晰界定了 ReIn 与 RAG（信息检索 vs 错误恢复）和恶意提示注入（需工具授权 vs 未授权）的差异

局限性¶

错误分类体系较为简化（仅 6 种类型），实际部署中错误种类远更复杂
评测基于 τ-Bench 改造，对话轮数和场景多样性有限
inception 模块是额外计算开销，每轮对话增加一次 LLM 调用
仅在 Claude 系列模型上测试，是否适用于其他 agent 框架未知
当 ReIn 生成错误恢复计划时直接计为失败，缺乏容错机制

评分¶

创新性: ⭐⭐⭐⭐ — 推理注入是新颖的干预方式，与指令层级的结合分析有深度
实用性: ⭐⭐⭐⭐⭐ — 直击实际部署痛点，无需重训或改提示
实验完整度: ⭐⭐⭐⭐ — 多种组合对比充分，但数据集规模偏小
写作质量: ⭐⭐⭐⭐ — 形式化定义清晰，实验设计严谨
综合评分: ⭐⭐⭐⭐ — 实用导向的好工作，方法简洁有效，但理论深度有限