支持人员处理工单时，经常需要追问入口、错误提示和发生时间。Agent 可以把追问整理得更快，但也可能让用户重复提供系统已经知道的信息，或者索要一大堆与当前判断无关的材料。

补充信息建议的目标应该很窄：找到阻碍下一步判断的缺口，生成最少的问题。问题是否发送、发送给谁、是否涉及敏感资料，由已有工作流负责。

先整理已有事实

读取当前授权工单的原始描述和历史回复，区分用户陈述、系统观测和支持人员判断。用户说“我点过了”证明有这个陈述，不证明系统成功收到请求；工具返回任务成功，也不证明输出符合用户需要。

对已经出现的信息保留来源和时间。入口、版本、对象标识如果能从当前会话或受控系统读取，就不要再让用户手工填写。反过来，系统记录无法证明用户看到的页面提示，仍可能需要追问。

工具范围应受当前任务约束。租户和工单标识由服务端确定，模型不能为了补齐材料扩大到其他客户记录。工具返回也尽量使用必要字段，避免读取整份用户资料来生成几个问题。

每个问题对应一个决定

先写出缺口会影响什么判断。例如，错误码区分权限拒绝与状态冲突，发生时间帮助定位日志，操作入口用于核对版本。若一个问题的答案不会改变下一步，就不应优先询问。

可以为候选问题保留内部理由：

{
  "missing_field": "error_message",
  "question": "操作后出现了什么提示文字？",
  "decision_affected": "选择权限排查或状态排查",
  "already_available": false
}

内部理由帮助人工审核，不必原样发给用户。真实系统可以使用不同字段，但需要保留问题与决策的关系，而不是只输出一段客气的追问。

选择最少的一组问题

不要固定要求每次生成五个问题。一个关键字段足够决定路径时，只问一个。多个问题可以一起问，但尽量一问一事，避免用户回答“是”以后无法确定对应哪一项。

问题要具体，减少让用户猜测的空间。“请提供更多信息”不如“请说明点击后的提示文字和大致发生时间”。如果必须提供截图，提醒遮挡无关个人信息，并使用既有安全上传渠道；不要求用户发送密码、验证码或完整客户清单。

对用户已经表达无法提供的材料，记录原因并考虑替代路径。反复生成同一个问题不会增加证据，只会增加沟通成本。需要人工判断或内部排查时，应把责任转回团队。

缺口不是猜测空间

模型可能根据描述推测浏览器、版本或权限，把这些值写进追问。例如“请确认你使用的是旧版浏览器”会暗示未经核实的原因。更合适的问法是“当前使用的浏览器与版本是什么”，前提是确实需要这个信息。

同样，不要把工具超时当成“用户尚未操作”。读取不可用和事实不存在是两个状态。输入里明确区分，候选问题才能避免不合理归因。

发送后保留问题与回答的关联

确认后的问题应关联到对应缺口。用户回复后，更新的是该字段的证据状态，并记录原话或受控引用，不直接把自然语言回答改成“问题已解决”。如果答案仍含糊，可以说明尚缺哪一部分，再决定是否需要继续问。

发送系统使用稳定任务标识去重，避免重试时重复通知用户。若发送结果未知，先查询已有记录，不立即再次发送。

验收可以检查重复信息、多个意图、工具失败、用户无法补材料和敏感内容等场景。真正有用的补充信息建议，是让下一步变得可判断。Agent 负责整理缺口，人工与流程负责沟通责任，用户就不必为系统的混乱反复填表。