Agent 一接浏览器上传就开始传错附件：从 File Intent Binding 到 Upload Confirmation 的工程实战

⚠️ Agent 会上传文件，不等于它真的知道该上传哪一个

很多团队把Agent接进业务后台后，最先跑通的是input[type=file]。⚠️ 但真实流量里常出现更难复盘的问题：用户要上传本轮生成的PDF，Agent 却把上一次下载的截图、同名旧版本，甚至别的标签页附件送了出去。📎 这类错传一旦落到财务或法务场景，风险远高于一次点击失败。

有团队把“文件框已写入路径”当成成功条件，线下通过率在98%以上，线上人工回退却持续升高。📉 问题不在控件调用，而在任务意图、文件身份和页面上下文没有同时绑定；模型只看到“最近可用文件”，就会把局部正确执行成全局错误。🧠

🔍 真正出错的，通常不是上传 API，而是文件绑定链路先漂了

根因通常有三类。🔍 一是旧路径复用，上个任务的附件还留在工作区，本轮只按文件名匹配就会拿错；二是跨标签页串线，焦点漂移后文件被送进别的表单；三是DOM漂移，重渲染后控件换了节点，Agent 仍写给旧locator。📌 共同问题不是“不会上传”，而是“没有证明这次上传属于当前任务”。

某客服工单系统灰度后，附件提交成功率只掉了3个点，但“附件与工单不一致”的投诉涨了27%。🧪 深追日志才发现，同名invoice.pdf在90秒内被不同任务重复引用。🔒 只看上传成功率，会把最危险的错传完全埋掉。

🛠️ 更稳的办法，是把文件当成受控工件，再做页面回显确认

更稳的链路不是“拿到路径就立刻写入输入框”，而是先给附件分配task_id、哈希和时限，形成独立的artifact ledger。✅ 只有当任务命名空间、页面URL、表单字段和文件指纹同时匹配时，Agent 才能占用这份附件；写入后再读页面回显的文件名或摘要，确认浏览器收到同一文件，才允许提交。💡

defupload_ready(task,artifact,page_echo):returnall([artifact.task_id==task.id,artifact.sha256==page_echo.sha256,artifact.filename==page_echo.filename,page_echo.field_name==task.expected_field,artifact.lease_expire_at>task.now,])

某交易后台接入这套门禁后，上传平均时延只增加180 ms，错传附件工单两周内下降61%。📊 更关键的是，旧路径和跨页上传会在提交前被稳定拦截。🚦

📊 发布门禁别只盯成功率，还要盯意图匹配率和错传拒绝率

长期要盯住的指标，至少包括intent_match_rate、page_echo_confirm_rate、stale_artifact_reject_rate和post_submit_attachment_miss_rate。📈 如果只看“上传成功”，团队会误以为流程稳定；只要旧附件拒绝率长期为零、页面回显确认缺失，说明系统仍在盲传。🛡️ 对高风险业务，提交前再做一次哈希和任务编号比对，比再省几百毫秒更值钱。

🚀 接下来 3 到 6 个月，浏览器 Agent 会从“能传文件”走向“可证明没传错”

接下来3到6个月，浏览器Agent的分水岭不会是谁支持更多网站，而是谁先把附件上传做成可审计、可回滚的受控动作。🚀 笔者认为，真正重要的不是更敢点“提交”，而是每次提交前都能回答：这份文件为什么属于这个任务、这个页面和这个用户。🙂 如果你的Agent也在处理上传流程，更棘手的是旧文件复用，还是跨标签页串附件？