最近准备业务助手演示，从收到告警到生成处理报告，几步连起来很自然。真正做设计时，难的是每一步采用什么依据、哪些结论还不确定，以及动作失败后报告应该怎么写。
这里用设备能耗异常举例。设备与动作是通用示意，分析建议、创建工单和设备控制不能被当成同一种权限。
告警编号如何变成可查询事实
拿到编号，读取告警原始详情，固定设备、指标、触发区间和条件。自然语言描述可以辅助理解，但不替代对象身份。查错设备后，即使后续接口全部成功，结论也没有意义。
任务上下文保存资源引用、时间范围、单位和来源。相关查询沿这些事实展开，避免长对话中的摘要不断压缩，最后把告警发生时间与当前时间混在一起。
证据不足时不生成故障结论
能耗升高不一定是效率下降。负荷、运行模式、计量变化、缺测和对照基线都可能影响判断。查询没有数据、请求失败和数值正常，必须有不同状态。
Agent 可以维护候选解释和需要补查的证据，计算由确定性工具完成。每项发现关联查询、数据区间、单位、质量与计算结果。基线不具可比性，就降低结论强度并补查，不能靠一段解释把缺口补成事实。
例如确认一小时能耗增加，但有缺失采样，也不知道负荷是否变化，此时可以请求运行记录，不能直接给出设备效率故障。材料补齐后重新判断，保留之前的依据与变化原因。
建议在动作发生前有明确内容
可选结果包括继续观察、补查、创建工单或调整建议。用户看到每项依据、影响范围和未确定之处。读取数据可以连续推进，发控制指令则需要单独授权，不能因为来自同一轮对话就自动允许。
第一版范围是报告与待确认建议，不开放自动控制设备。这样仍能交付一条完整路径：告警被解释、证据可查、建议可决定，而不把高风险操作当成演示中的普通一步。
创建工单超时以后查什么
工单提议固定设备、级别、内容和目标系统，批准绑定提议版本与摘要。执行时检查当前权限，用告警与提议版本组成稳定业务操作键，重试不随意换键。
超时可能发生在对方已保存、响应尚未返回的时刻。支持操作键查询就读取实际结果，已存在则补齐本地记录，确定未创建才重试。不能可靠识别时，保留未确认状态，交给人工处理，不能不断多建同内容工单。
HTTP 方法名不能替业务保证幂等。具体能否重试，由这项动作和下游能力共同决定。
报告里的完成状态对应真实回执
发现、推测、建议、已提交动作和已确认结果分别记录。工单创建成功只说明工单存在，不代表故障已修复；调整提交后还需读取处理回执与业务指标，才能写已生效。
报告关联实际查询和动作结果，不只引用对话总结。用户追问时能回到对应版本与证据，后续处理也可以追加，而不是覆盖原判断。
检查时间范围错位、缺数据、无权限、重复请求和超时；每条路径都能生成与事实一致的报告。演示脚本说明流程能怎样衔接，这些检查要求则决定它何时可以继续、何时应停在未确认，不能用前者替代长期运行验证。