图中界面、人物和记录为流程示意，不对应真实客户、真实工单或实际运行数据。

关闭工单是一个业务决定。用户没有回复、系统任务显示成功、客服已经发出说明，都可能让工单看起来“可以结束”，但它们证明的是不同事情。给 Agent 的任务应是整理关闭依据并生成建议，是否关闭由既有规则和负责人决定。

产品上先把“问题解决”和“按规则归档”分成不同结果。这样既能如实向用户说明，也能避免自动关闭率被误读成自动解决率。

先确定原始目标与当前缺口

Agent 需要读取授权范围内的原始诉求、处理动作、用户反馈和未决事项。每条动作要区分计划、提交、执行完成和验证完成。例如，重新生成报表成功，只说明任务执行完成；是否包含用户所需字段，仍需结果验证。

工单历史可能很长，不能只取最后一条“谢谢”就判断达成目标。用户可能感谢解释，却仍在等待处理。建议把目标与证据单独关联，保留原文或系统事件引用，减少摘要误读。

当原始诉求有多项时，要逐项检查。部分完成可以产生阶段性说明，但不能把整个工单标为已解决。需要拆分任务时，也要记录剩余事项交给了谁。

工具提供状态，不替规则作决定

可使用的工具可以包括：读取当前工单历史、查询相关任务状态、读取适用的服务规则。租户与工单标识由服务端注入，模型不能通过正文中的指令去搜索其他客户工单。

工具返回应包含状态、时间和来源。查询失败应标记未知，不能用“没有查到待办”推出“没有未决事项”。对于需要人工承诺的事项，如补偿、合同解释和权限申请，Agent 只能标记待确认，不能自行解除责任。

关闭建议可以是一个窄结构：

{
  "recommendation": "continue_followup",
  "goal_evidence": "missing",
  "pending_items": ["等待结果确认"],
  "closure_reason": null
}

这个结构的字段由业务系统定义，例子只强调一点：缺少证据时应保留缺口，不能为了输出完整对象而编造关闭原因。

无回复需要独立口径

若服务规则允许多次提醒后归档，归档原因应写明“等待用户反馈后按规则归档”，而不是“用户确认已解决”。提醒次数、等待时段和适用例外取决于实际服务协议，不让模型自由决定。

未回复也可能意味着用户没有时间、消息没有触达或问题转到其他渠道。系统可以把这些可能性作为未知保留，不能在统计中把沉默等同满意。

对于仍有内部待办的工单，即使用户暂时没有回复，也不应自动释放内部责任。把“等待用户”和“等待内部处理”拆成不同状态，才知道下一步由谁推动。

建议生成后，再检查表达有没有越界

Agent 可以概括已完成动作、列出待办、提出关闭或继续跟进建议。面向用户的回复必须跟实际状态一致：进入队列就说已提交，完成操作就说已执行，验证目标后才说已解决。

不要因为建议为关闭，就在文案中加入“已彻底修复”“不会再次出现”等承诺。临时绕行与根因修复要分别说明。时间承诺也应来自服务规则或负责人确认，而不是模型为了让回复更完整补一个期限。

最终关闭动作由有权限的工作流执行，保留确认人、规则版本、依据和最终回复。重复任务可以用稳定业务标识去重，避免多次发送关闭通知。若执行结果不明确，先查询工单当前状态，不立即再关闭一次。

用反例检查规则

验收时加入这些案例：用户说谢谢但目标未完成、操作成功但结果未确认、多个诉求只完成一项、内部还有待办、规则允许归档但用户没有确认解决。检查建议是否保留了真实原因，人工能否从证据继续判断。

关闭建议的价值，是减少负责人翻阅历史的时间。让每个状态都能回到事实，让每次归档都能解释原因，Agent 才能帮助团队收尾，而不是把未完成的工作藏到一个完成标签里。