Agent 一接导出中心就开始把旧报表当新结果：从 Export Job Claim 到 Artifact Freshness Fence 的工程实战

很多团队把 Agent 接进导出中心后，最危险的不是点不到按钮，而是导出成功却拿到旧报表。⚠️ 页面提示“任务完成”，目录里也出现了report.xlsx，但它可能来自上一轮筛选、上一位租户，甚至上一个标签页的异步任务。

这类事故难复盘，因为每个环节都像成功。🧠 点击成功、任务完成、文件也下载了；真正出错的是执行器把“最后落盘的文件”当成“本次查询的结果”，却没有证明文件归属。

导出中心为什么总把旧报表冒充新结果

第一层根因是任务身份没有闭合。📌 很多后台点完导出后，只留下 toast 或列表刷新，没有把export_job_id带到下载步骤。Agent 只能按文件名或修改时间猜归属，而export.xlsx、report.csv恰好最容易撞名。

第二层根因是新鲜度判断过于粗糙。🧩 有些系统会复用历史导出任务，也有对象存储会延迟覆盖同名文件。页面显示“刚刚完成”，不代表内容对应这次筛选；如果不回读筛选哈希、统计行数和生成时间，旧产物就会混进审批和归档。

一组回放把问题暴露得很直接

这次回放了51条真实导出任务，覆盖财务对账、商家结算和运营日报。🧪 基线方案在“下载完成”后直接读取最新文件；改进方案先 claim 导出任务，再核对job_id、query_fingerprint、ready_at和artifact_etag。📊 问题并不在失败率，而在错绑会被后续链路继续放大。

数据说明，导出链路真正缺的不是重试，而是把“哪个任务产出了哪个文件”证明清楚。✅ Agent 如果在进入导出中心前记录 claim，在下载后再校验生成时间和对象摘要，很多旧报表会在最后一步被拦下。

defaccept_export_artifact(job_claim,artifact_meta):same_job=artifact_meta["job_id"]==job_claim["job_id"]same_query=artifact_meta["query_fingerprint"]==job_claim["query_fingerprint"]fresh_enough=artifact_meta["ready_at"]>=job_claim["claimed_at"]same_tenant=artifact_meta["tenant_id"]==job_claim["tenant_id"]ifnot(same_jobandsame_queryandfresh_enoughandsame_tenant):raiseValueError("stale_artifact")returnTrue

这段逻辑的关键不是多轮询几次，而是把下载动作从“取最新文件”改成“取属于当前任务的文件”。🔍 只要job_id对不上、生成时间早于 claim，或对象摘要不符，就宁可重查，也不要默认成功。

Export Job Claim 和 Artifact Freshness Fence 应该怎么落地

Export Job Claim更像一张任务凭证。🛠️ 点击导出时，同时记录租户 ID、筛选条件哈希、排序方式、导出任务 ID 和触发时间；进入导出中心后，只允许当前 claim 对应的任务进入“可下载”状态。

Artifact Freshness Fence负责挡住缓存和复用带来的假成功。🚨 更稳的做法，是在消费文件前核对ready_at >= claimed_at、表头是否匹配、关键行数是否落在预期区间。任一条件漂移，就标记为stale_artifact并重新导出或人工确认。

深度思考与趋势判断

笔者认为，导出中心频繁出事，不是因为 Agent 不会下载文件，而是很多系统把“产物存在”误当成“产物属于当前任务”。📎 在异步工作流里，真正要治理的是任务身份、新鲜度和对象一致性。

未来3到6个月，更值得投入的不是继续堆下载重试，而是让导出平台默认暴露job_claim、结果摘要和对象存储版本信息。📈 当执行层能回答“这份文件是谁生成的、何时生成、对应哪组筛选条件”，导出链路才算可审计。

一句话总结：导出中心最怕的不是没文件，而是拿到一份看起来没问题的旧文件。⭐ 把Export Job Claim和Artifact Freshness Fence接起来后，Agent 才能证明“这就是本次任务的新结果”。你们现在会在消费文件前验证任务归属和生成时间吗？