表单自动化最危险的错不是按钮点不到而是字段看起来都填了真正提交的却不是那组值。很多团队把问题归因于视觉识别不准线上排障后才发现真正失控点往往在字段 grounding、异步回填和提交前确认。⚠️ 当 Agent 进入 CRM、报销或开户流程时一次错填就可能变成权限事故、金额事故甚至合规事故。图 1表单类任务最怕的不是不会填而是填得很像对的问题为什么会集中爆发页面结构稳定不代表字段语义稳定很多前端表单复用了相同的input组件但label、placeholder、帮助文案和校验提示来自不同数据源。Agent 若只靠“离哪个文本最近”来绑定字段很容易把“公司名称”写进“开户行”把“联系人邮箱”写进抄送输入框。 尤其在弹窗、折叠区和分步表单里视觉邻近关系会频繁失真。[外链图片转存中…(img-I2UJLvCs-1777507973969)]图 2多列布局和弹窗回填会放大字段歧义真正的错误常发生在提交前 3 秒工程上最常见的事故链是字段初填正确前端异步校验后重置值联动脚本自动改写默认选项浏览器补全再插入旧数据。Agent 如果只验证“输入动作成功”没有验证“提交瞬间的最终值”就会把整个任务误判为成功。 这也是为什么很多 demo 很顺线上却频繁翻车。一组可复现的最小实验测试环境选了 24 个企业后台常见字段故意加入同名label、隐藏控件和延迟校验。对比三种策略后差距很明显。✅策略字段绑定依据提交成功率典型问题邻近文本匹配只看视觉附近文案71%容易跨列串字段DOM 语义绑定label/for、aria-*、name86%遇到自定义组件仍会漏判语义绑定 Submit Guardrail提交前二次比对快照96%需要额外状态管理最有效的改进不是换更大的模型而是在提交前多做一次“字段名—目标值—页面最终值”的三向核对。️ 只要发现任一关键字段漂移就禁止点击提交转入重新定位或人工确认。critical_fields[company_name,bank_name,contact_email,tax_id]forkeyincritical_fields:plannedtask_payload[key]observedpage_snapshot[key]ifnormalize(planned)!normalize(observed):raiseSubmitBlocked(f{key}drift:{planned}-{observed})click_submit()真正值得投入的 Guardrail 设计先做字段账本再做动作编排稳定方案不是让 Agent 边看边猜而是先生成字段账本目标字段名、候选 selector、预期值、是否关键字段、允许的格式约束。 这样浏览器动作层只负责执行提交层只负责验收排障时也能直接定位是哪一层失真。图 3提交守卫的核心是把“动作成功”改成“结果验收”把提交按钮当成高风险动作笔者更推荐把submit单独建成高风险工具提交前必须拿到最新 DOM 快照、关键字段 diff 和页面校验状态。 如果存在红框报错、禁用按钮、字段回滚或必填项缺失直接熔断不要让 Agent 自作主张“再试一次”。很多重复提交事故恰恰就是无条件重试造成的。这类能力接下来会怎么演进未来 3 到 6 个月表单 Agent 的竞争点不会是“能不能填”而是“能不能证明自己填对了”。 企业更愿意为可审计轨迹、字段级回放和提交前证明买单而不是为一次华丽的自动演示买单。对团队来说优先级应该是字段 grounding、最终值校验、幂等提交再考虑多模态理解和复杂推理。一句话总结表单自动化的门槛不在输入在提交前的证据闭环。 如果没有 submit guardrailAgent 只是把人工失误换成了机器批量失误。你们在真实业务里最怕 Agent 填错哪一类字段