通过问题改写融合多轮对话

用户：我想申请下周去杭州出差。
助手：好的，请告诉我具体出发和返回日期。
用户：周一去，周三回。
用户：帮我查一下那边的酒店      ← "那边"指哪？下游Agent看不懂

@Component
@Scope
public


        messages


            messages


                        stableModel


}

## 改写规则

### 1. 相关性判断

判断当前问题是否与历史对话相关：

- **相关**：当前问题是对前文话题的延续、追问、补充、确认或修正。
- **不相关**：当前问题开启了一个全新的、与历史无关的话题。

判断标准包括但不限于：

- 是否包含指代词（它、这个、那个、那边、上面、之前、上次等）。
- 是否省略了前文已提及的实体（城市、日期、酒店、航班、审批单号等）。
- 是否继续讨论同一出差任务、行程、审批或报销事项。

### 2. 问题融合与指代消除

当判断为相关时：

- 将当前问题中的省略和指代替换为历史中的具体实体。
- 把分散在多轮中的约束条件合并到当前问题中。
- 如果用户当前问题只是简单确认（如“确认”“好的”“就它吧”），则融合为完整动作描述，例如：“确认提交此前讨论的北京到杭州的差旅审批。”

### 3. 错别字改写

- 识别并修正用户输入中的常见错别字、拼音错误、形近字错误。
- 例如：`杭洲` → `杭州`、`差旅游` → `差旅`、`报消` → `报销`。
- 修正时必须保留原始语义，不得引入新信息。

### 4. Step-back 改写

- 当用户问题过于具体、模糊或带有强烈假设时，先退一步，生成一个更通用、更基础的问题版本，帮助理解真实意图。
- 例如：
  - 用户：`西湖附近那个全季怎么样？`
  - Step-back：`用户想了解杭州西湖附近全季酒店的相关信息（价格、位置、评价、是否符合差旅政策）。`
- Step-back 改写后的问题用于辅助理解，最终 `rewritten_question` 仍应保留具体细节。

### 5. 信息保留原则

改写后的问题**必须**满足：

- 不丢失原始问题中的关键实体（人、地点、时间、金额、审批单号、酒店/航班名等）。
- 不改变用户原始意图。
- 不添加历史中没有的假设信息，除非用于消除必要歧义。
- 对于不相关问题，原则上保持原问题不变，仅做错别字修正。

### 6. 面向下游的输出约束

- **禁止引入内部名称**：`rewritten_question` 会作为下游智能体的输入且可能在思考面板向用户展示，因此**绝不允许**向其中添加工具函数名、子智能体名、内部字段名与文件路径（如 `query_travel_order`、`plan_roundtrip`、`itineraryPlanAgent` 等 `snake_case` 或 camelCase 名称）；`reason` 字段也应以中文自然语描述改写思路，不得引用此类英文标识符。

历史：用户想去杭州出差，周一去周三回
当前："帮我查一下那边的酒店"
改写："帮我查一下杭州的酒店，入住日期为下周一，离店日期为下周三。"

"我要报消一张发票" → "我要报销一张发票"

"西湖附近那个全季怎么样？"
→ 用户想了解杭州西湖附近全季酒店的相关信息（价格、位置、评价、是否符合差旅政策）

## 示例

### 示例 1：指代消除

History:

- 用户：我想申请下周去杭州出差。
- 助手：好的，请告诉我具体出发和返回日期。
- 用户：周一去，周三回。

Current question: `帮我查一下那边的酒店`

Output:

```json
{
  "related": true,
  "rewritten_question": "帮我查一下杭州的酒店，入住日期为下周一，离店日期为下周三。",
  "reason": "消除指代'那边'，融合历史中的目的地和日期信息。"
}

{
  "related": false,
  "rewritten_question": "我要报销一张发票",
  "reason": "修正错别字'报消'为'报销'，当前问题未引用历史上下文。"
}

{
  "related": false,
  "rewritten_question": "今天北京天气怎么样？",
  "reason": "当前问题与历史话题无关，保持原问题。"
}

## 一个完整的多轮示例