工单到了最后一轮，模型往往很容易写出“问题已解决，可以关闭”。但用户表示感谢、监控暂时正常、处理人员完成了一次操作，都不一定意味着约定的解决条件已经满足。

关闭工单会改变后续跟进、统计和责任状态。让 Agent 起草关单建议是合理的，让一段总结直接成为关单依据，则需要额外的事实与规则。产品应明确哪些内容可以自动整理，哪些判断必须由负责人员作出。

把解决条件放在任务开始时

如果开始时没有定义什么算完成，结束时就容易用语气代替验收。账号访问问题可能需要用户确认目标入口可用，数据更正可能需要核对指定字段及同步结果，咨询工单可能只需要给出适用说明。具体条件由业务流程决定。

模型可以从记录中整理已完成项与缺失项，但不能临时降低标准。比如原目标是恢复指定应用访问，后来用户能登录另一个入口，并不自动满足原目标。

关闭原因也应区分已解决、重复合并、用户撤回、超出服务范围和按规则超时关闭。把它们全部记成“解决”，会误导质量统计，也可能让用户不知道问题为何结束。

三类决定应保留人工责任

第一类是事实仍有争议的判断。用户认为问题持续存在，系统记录却看似正常，需要负责人核对，不由模型选一方作为结论。

第二类是影响权益或承诺的决定，例如补偿是否兑现、费用是否调整、访问权限是否恢复。这些结论要有业务记录与必要批准，不能从聊天摘要推断。

第三类是例外处理。服务规则之外的提前关闭、拒绝继续处理、跨团队争议，都需要有权限的角色判断并记录理由。把例外藏进一个“模型置信度足够高”的阈值，会让责任变得难以解释。

图中保留争议分支，是因为关单不是生成一段结束语。还有未决问题，就应写清下一步与负责人；如果按规则关闭，也应说明真实关闭原因和后续可用路径。

不把沉默当作解决证据

用户没有回复，可能是没有看到通知，也可能是问题暂时不再发生。它能否触发关闭，取决于明确的超时规则、通知记录和重新打开渠道。模型不能自行把“几天没说话”解释成满意。

若产品采用超时关闭，应在规则中定义计时起点、暂停条件、提醒方式及适用类别。等待内部人员处理的时间，不应误算为等待用户。对高风险或持续故障任务，可能还需要不同流程。

生成器只读取已生效规则与实际事件。没有有效期限，就不补一个“若无回复将自动关闭”；还没有发出提醒，也不能写“已多次联系”。

建议与执行保持两条记录

关单建议包含拟关闭原因、已满足条件、证据引用、未决事项和需要确认的角色。执行记录则保存实际确认人、时间、规则版本与最终状态。建议被拒绝时保留原因，帮助改进系统。

执行前再次读取状态，可以避免生成期间工单出现新回复或新故障后仍被关闭。服务端使用版本检查或其他并发控制，防止过期确认覆盖最新进展。模型不能承担这层一致性保证。

如果关单动作结果不确定，先查记录，再决定是否重试。关闭通知也应对应真实状态，不能因为文案生成成功就发送“已关闭”。

验收看关闭后发生了什么

可以观察因未解决而重开的任务、关闭后重复提交的同类问题、人工拒绝建议的原因，以及必要确认是否缺失。不要只追求关闭数量，快速清空队列可能只是把工作转移到下一个入口。

模型能做好的，是把冗长过程整理成一份可审核的关单依据。最后由有权限的人或经过明确授权的规则确认，才能让工单状态真实反映业务结果。