Agent 是否实现用户意图改写、纠错和澄清？

核心回答

可以把这项能力实现为“保留原问，理解上下文，生成候选改写与结构化参数，再决定执行还是澄清”。纠错处理明显错字与别名；改写补回对话中已经明确的对象、拆解复合问题；缺少会改变结果的关键条件时，向用户确认，不让改写模型自行补造。

下面以门店问数助手的设计示例说明：用户先问“上海店本月销售额”，接着问“退款也扣掉呢”。门店和月份已确定时，我会保留原始消息，把第二问理解为沿用这些条件、改算净销售额。本例已有业务定义：净销售额为本期实收减本期实际退款，退款按发生时间归属，因此直接采用该定义，不再次询问退款归属。只有仍然缺失或有歧义的关键条件才需要澄清。

我会怎样实现这一层

输入包含原始消息、相关对话历史、业务词典和允许使用的指标定义。输出分开保存：规范化问题、任务意图、已确定参数、缺失参数、歧义项和用于检索的候选表达。原问一直保留，避免只剩改写后的文本而无法检查偏差。

第二问的示例输出可表示为：原问是“退款也扣掉呢”，指标为 net_sales，门店 ID 和日期范围沿用已确认值，退款时间口径为“发生时间”，缺失字段为空，状态为“可查询”。这是该设计的输出示意；如果门店尚未确定，就应保留候选门店和待补字段，状态改为“等待澄清”。

纠错先区分普通错字和实体名。把“销受额”归一为销售额通常容易判断；把陌生商品或门店名改成另一个熟悉名字，则可能改变对象，需要词典、搜索结果或用户确认。

改写也要区分检索表达与业务参数：可以为了召回同义表达扩展关键词，但不能因此扩大查询门店、日期或权限范围。原始问法可保留为一条召回通道；多查询融合是否有收益，按检索集验证，而不是默认每轮都扩展。

多轮澄清怎样接回流程

例如，若“上海店”在当前用户允许范围内对应两家门店，且上下文没有指定哪一家，就询问具体门店，并保存候选门店、待补字段及当前任务标识。若门店已唯一确定，或指标词典已有适用定义，就直接采用，不把已知条件重新交给用户选择。

用户回答后，将回复与待补字段合并，检查是否解决歧义；若只回答了部分条件，继续问尚缺的关键项。用户改了月份或门店，还要更新相应参数及依赖结果，不能沿用旧查询。

在 LangGraph 中，可以用持久化状态配合 interrupt() 返回澄清问题，再用同一 thread_id 和 Command(resume=...) 继续。恢复时节点会重新执行，所以澄清之前适合做可重复的理解与准备，实际写入等副作用应另设执行步骤。也可以自行实现“等待输入—补全状态—继续”的状态机，不必绑定框架。

如何验证改写没有改变意图

准备包含错字、代词、同名实体、否定条件、缺日期和用户中途改条件的样例，对照原问与结构化参数。重点检查实体是否被改错、否定和范围是否保留、关键条件是否凭空增加。

再测多轮澄清是否收敛：问题有没有问到真正影响结果的条件，补充后能否继续，同一字段会不会反复询问。改写失败时可以回退原问或请求补充；需要分别评估错误改写、无谓澄清、最终查询正确率和额外延迟，不只看向量相似度。

追问

如何决定直接默认还是反问？

看该条件是否明显影响答案或动作。可从已有上下文、业务定义或工具可靠取得的，不必再问；存在多个合理解释且结果不同的，需要澄清。可默认的偏好也应和关键业务条件区分。

多查询改写就是多轮澄清吗？

不是。多查询在系统内部生成不同检索表达；多轮澄清是向用户取得缺失信息。前者不能替代用户决定业务口径。

改写层可以修正用户的权限范围吗？

它只能识别用户表达的条件，不能授予权限。最终数据范围由身份和执行端规则约束，不能相信模型生成的任意门店标识。

对应教程

参考资料