⚠️ 下载链路最危险的错不是按钮点不动而是拿到了“看起来像对的文件”很多团队把 Browser Agent 接到报表导出、合同归档和工单附件流转后最隐蔽的事故不是下载失败而是下载成功却拿错了对象。⚠️ 用户明明在客户 A 的页面点了导出落盘的却是上一次任务遗留的客户 B 报表或者下载目录里同时冒出report(7).xlsx、export.zip和浏览器自动重命名文件执行器只按“最新文件”取件结果把错误附件传进后续审批。图 1下载任务的真正难点是把点击、下载事件和最终文件绑定成同一条证据链 真正出问题的往往不是浏览器下载慢而是下载归属没有绑定根因通常集中在三处。 第一处是执行器把“点击下载”和“拿到文件”拆成了两个松散步骤没有给这次点击分配唯一下载意图第二处是浏览器下载目录被多个任务复用只凭最新修改时间取文件天然会被并发任务和残留文件污染第三处是文件名、MIME 和业务对象没有二次核对系统只要看见某个新文件出现就误判为本次任务成功。某报表 Agent 在4个并发任务下回放8,000次导出流程浏览器层下载完成率仍有98.6%但附件归属抽检准确率只有93.8%。 主要损耗不在网络而在“下载事件到落盘文件”的最后一跳没有绑定任务身份。图 2下载归属、目录隔离和文件验真缺一项错文件就会悄悄混进来方案文件归属方式错文件率常见问题只扫最新文件按时间戳取目录最新文件3.4%并发任务和旧文件污染绑定下载事件click 与 browser download 事件关联1.1%文件落盘后仍缺业务验真download_id Artifact Ledger事件、文件和任务三向绑定0.2%主要剩异常重试与服务端脏数据️ 更稳的做法是让每次下载都带着download_id进入 Artifact Ledger更稳的设计是在点击前生成本次任务的download_id把页面上下文、业务对象键、预期 MIME 和目标任务 ID 写入Artifact Ledger。️ 浏览器监听到download事件后不把“新文件出现”直接视为成功而是把建议文件名、落盘路径、哈希和文件大小回填到账本再确认它确实属于刚才那次点击。✅ 三向绑定闭合后后续上传、解析和归档才允许继续。defbind_download(task_id,page,expected):download_idnew_id()ledger.reserve(download_id,task_idtask_id,pagepage.url,expectedexpected)eventpage.wait_for_download()pathevent.path()ledger.commit(download_id,pathpath,sha256file_sha256(path),mimesniff_mime(path),suggested_nameevent.suggested_filename,)verify_artifact(download_id)某合同归档 Agent 加上账本后每百次任务平均多出0.9次验真重试但错误附件进入后续上传链路的比例下降了82%。 这个开销很值因为最贵的不是多做一次哈希而是把错误文件带入审批、签约或对账系统。图 3把下载事件、落盘文件和业务对象全部登记到账本才能真正避免串单 发布门禁别只看下载成功率还要看归属正确率和验真失败率运行时至少要盯住artifact_binding_success_rate、wrong_artifact_rate、download_verification_retry_rate和orphan_file_count。 如果只看下载成功率团队会误以为链路很稳但只要孤儿文件变多、验真重试升高或者错误附件率开始抬头就说明账本与执行层已经脱节。 真正成熟的下载型 Agent不是“能把文件存下来”而是“任何一个文件都能证明自己属于哪次点击和哪条任务”。图 4绑定成功率、错误附件率和孤儿文件数应一起成为发布门禁 接下来 3 到 6 个月下载型 Agent 会从“取文件”转向“可证明交付”接下来3到6个月浏览器下载自动化的分水岭不会是谁能点更多导出按钮而是谁先把下载意图、文件身份和后续交付做成默认约束。 笔者认为下载型 Agent 会从“把文件拿下来”升级成“证明这份文件属于这次任务”而Artifact Ledger会成为上传、解析、归档前的标准中间层。 你们的下载链路里更常见的是目录残留污染还是文件名相似导致的串单