Agent 报告已生成但通知没送到，怎样分开核对计算完成和结果投递

Agent报告已经生成但通知没送到，应先查投递链路，不能直接重跑报告。计算完成、渠道受理、送达某个地址以及用户实际查看，是四个不同事实。将结果台账与投递尝试分开，才能重新通知而不重复原任务，也能避免把送达未知说成用户已经收到。

两张台账各自保存什么

合成结果台账记录任务号、结果标识、输入版本、生成时刻和可领取期限。投递台账另记接收对象别名、渠道、尝试号、渠道回执及当前状态。结果可以没有成功通知，通知也可能指向已经到期的结果，不能让一张成功标记代替整条链路。

通知只带最少摘要与受控领取入口，不把完整敏感报告直接发到未经确认的地址。接收对象来自服务端批准的映射，不从模型生成的一串地址直接投递。渠道权限、对方是否可见结果与任务请求人是否同意分享，仍需按业务规则检查。

Amazon SES模拟器说明提供成功投递、退信等测试场景，可用于区分投递结果。邮件服务接受不等于用户已读，其他消息平台的回执也不能直接套用邮件语义。真实渠道能证明到哪一层，就记录到哪一层。

渠道没有已读能力时，保持未确认查看，而不是通过模型推断对方应该看到了。页面领取可以记录一次经过授权的打开事件，但预览机器人、自动扫描或重复刷新可能影响口径，应按产品合同定义有效领取。没有明确证据时只说入口被访问，不说报告已被采用。

通知重试仍引用同一结果标识和版本，不调用报告生成器。每次投递保存独立尝试号，同时关联同一通知目标，便于核对渠道是否可能重复发送。渠道受理响应丢失时，先按可用查询能力核实，不能立即无限重发，让用户收到多份完全一样的通知。

结果过期后，不继续投递旧下载地址。先判断是否还有有效领取方式，必要时提示结果不可领取并走业务支持流程。若用户要求新报告，作为新的生成决定处理；不能借修通知故障再执行原任务里的建单、发消息或其他动作。

下载结果与投递双台账样例。三条合成报告分别为生成成功但投递失败、渠道已受理但送达未知、已送达且用户尚未领取。另有明确退信、结果到期、接收人撤权和改用任务入口领取的路径，真实渠道标识均未填写。

测试使用模拟收件端，不向真实客户试发。先固定报告生成次数，再让模拟渠道返回成功、拒绝和未知，预期结果台账不被改成计算失败。恢复投递以后仍保持相同结果版本，生成器计数不增加，才证明没有把通知错误当成重算入口。

通知是提醒方式，受控任务列表才是可查的事实入口之一。用户自行登录能找到已经生成的结果时，可以在通知暂不可用期间领取；列表仍按当前权限返回，不能因为通知曾发给某人就永久保留其访问。入口不可用与渠道不可用应分别排查，避免两个环节互相掩盖。

接收人映射错误时，先阻止后续投递并核对已发送范围，再按客户流程处理。不要自动换另一个看似相似的联系人，也不把失败消息转发到任意公共群。支持记录仅保存必要别名与回执关联，完整地址与报告受控访问。

最后核对每个已生成结果是否有领取去向，每个投递未知项是否有责任人和后续决定。没有渠道证据的项保持未知，不能手动改绿为了结案。测试报告区分模拟预期与目标环境实测，所有已读或送达声明都应有对应来源。

故障通知路由可参考工作流告警分派，本题是流程自动化中的用户结果交付。通过定制咨询提供渠道回执、结果服务期限与接收人规则，可评估双台账、重新投递和受控领取入口。