历史消息截断后，模型忘了用户已经给过的信息

[小林]

这个是状态管理问题，不是单纯模型问题。订单号这种槽位应该进会话状态，不能只躺在聊天历史里。

[何必呢]

我之前偷懒全靠历史，窗口大时没问题，一上线用户连续追问就露馅。

[melo]

截断策略要认业务字段。订单号、姓名、城市、产品版本、已尝试步骤，都是“关键事实”，不能按时间删。

[青菜]

摘要要有版本。用户后来改口，旧摘要必须覆盖，不然状态里同时有两个订单号。

[小谢]

我们有 summary，但模型还是忘，因为 summary 太像自然语言：“用户提到了一些订单信息”。

[zeroOne]

那不行。写成结构化更稳：order_id=xxx、confirmed=true、source_turn=2。模型看得懂，系统也能校验。

[周五下午]

还有一种是工具结果丢了。模型查过订单，但下一轮工具返回不在上下文里，它就又查。

[陈一]

工具结果也分长期和短期。订单状态这种会变，别永久写死；用户已授权查询这种可以保留。

[小傅]

历史截断前是不是要让模型自己决定保留什么？

[林小北]

可以让模型参与摘要，但最终要有程序规则兜底关键槽位。完全让模型决定，出错时很难复盘。

[别问问就是缓存]

我们后来每轮都跑“状态抽取”，模型输出 JSON，后端校验字段，失败就不用。稳定很多。

[葡萄冰]

前端也能帮一点，用户已填写信息放在表单态，不要都混在聊天里。

[小谢]

我回去改：聊天历史截断前先抽关键事实，摘要结构化，订单号进入会话状态。

[何必呢]

记得加回放测试。截断 bug 靠人工聊天很难稳定复现。