很多团队把 Agent 接进下载中心后第一反应是盯住“有没有点到下载按钮”。⚠️ 真正危险的却是按钮点到了文件也拿到了但那份产物并不是这次任务新生成的结果而是列表里遗留的旧报表。[外链图片转存中…(img-lAfafMRz-1778206939644)]图 1下载任务最难防的不是失败而是成功拿到旧文件对人来说下载前会顺手看一眼生成时间和文件状态。 但很多执行器只要看到“下载成功”就默认闭环没有继续确认这份文件属于哪个任务。 一旦下载中心长期保留同名附件Agent 就可能把历史产物误判成新结果。下载中心为什么特别容易让 Agent 拿错旧产物第一层根因在于很多后台把“任务触发”和“产物领取”拆成两个弱绑定步骤。 用户点了导出后真正的文件可能几秒后才落到列表如果列表里本来就有同名 CSV、Excel 或 PDF执行器只按文件名领取就会天然偏向旧文件。第二层根因在于下载中心经常缺少强任务标识。 页面上常见的字段只有文件名、状态和模糊时间却缺少 request id 或筛选快照。这样一来Agent 即使点击路径完全正确也无法证明“这份附件就是这次查询条件导出的结果”。 问题在于产物归属没有被显式声明。图 2同名文件、异步生成和列表复用正是误拿旧产物的典型组合一组回放数据说明 Artifact Claim 比“点中下载”更关键这次回放了46条真实任务覆盖销售报表导出、风控名单下载和结算单归档。 基线方案只等待“下载按钮可点击”改进方案增加Artifact Claim要求导出前先写入任务时间窗和筛选摘要再在下载前执行Freshness Fence验真。方案任务成功率误拿旧文件率人工复核占比平均完成时长仅点下载按钮68%18%24%21 sClaim Freshness Fence94%2%7%24 s结果很直接真正决定可靠性的不是 Agent 会不会点下载而是它会不会在下载前证明“这份文件就是当前任务的产物”。✅ 只要把导出请求的筛选条件、触发时间和生成状态冻结成一条账本很多“表面成功、结果过期”的事故都会提前暴露。defverify_artifact_claim(job,artifact):ifartifact[status]!ready:returnFalse,artifact_not_readyifartifact[created_at]job[submitted_at]:returnFalse,stale_artifactifartifact[query_hash]!job[query_hash]:returnFalse,query_mismatchreturnTrue,fresh_artifact这段校验的意义是把“下载成功”改造成“领取成功且来源正确”。️Artifact Claim负责先声明这次任务应当产出什么Freshness Fence负责在真正点击下载前拦住旧时间戳、旧查询条件和旧状态文件。[外链图片转存中…(img-7wSL68Yo-1778206939652)]图 3没有产物认领和新鲜度围栏下载成功并不等于任务成功真正该补的是产物账本而不是更多点击重试很多团队遇到下载错文件后会继续补等待时间、补点击重试。❗ 这些办法只能缓解表面症状治不了“旧产物依然合法可见”这个根因。更稳的做法是把导出动作拆成受控阶段先生成任务账本再轮询目标产物最后在下载前做新鲜度闸门。笔者认为浏览器 Agent 接入下载中心后最需要学习的不是更快点到链接而是先学会认领产物再学会拒绝旧产物。 当执行层把 request id、提交时间窗与查询摘要纳入校验链路后Agent 才不会把“列表里最像的那个文件”当成“这次真正想要的那个文件”。一句话总结下载中心里最危险的失败不是拿不到文件而是太顺利地拿到了旧文件。 如果现在的链路仍然默认相信同名附件和列表第一项它依赖的就不是自动化而是侥幸。你们现在的下载自动化验证的是“文件下载了”还是“正确的新文件被认领了”