很多团队把浏览器Agent接进运营后台后最容易低估的不是按钮而是下拉选择器。⚠️ 页面上明明看到了“华东一区”或“标准版”提交后落库的却是另一个同名选项最后一路传导到权限和审批流配置。人类在选下拉项时会顺手核对输入词、候选列表和提交后的回填值。 可执行器如果只把“点击到了目标文本”当作成功就会忽略远程搜索和默认值覆盖这些副作用。 真正危险的不是找不到选项而是没有证明这次提交的值仍然属于原来的业务意图。图 1下拉框最麻烦的不是样式复杂而是“显示文本”和“真实提交值”常常不是同一个对象下拉选择器为什么会让 Agent 持续选错项第一层根因是下拉组件的身份信号太弱。 很多后台只把可见文案暴露给前台却把真正提交的value、id和租户上下文藏在数据层。执行器若只按文本命中遇到两个“默认仓”或两个“市场部”时无法确认它们是否属于同一业务域。第二层根因是候选列表经常异步变化。 搜索型下拉在输入sha后首批返回的是“上海分部”下一拍可能又补进“沙特区服”。只要系统没有把输入词、接口批次和最终回填值绑成证据链就会出现“点的时候对提交后错”的回放假稳定。⚙️[外链图片转存中…(img-1RUc4cKb-1777792714449)]图 2真正失真的是选项身份和提交结果脱钩而不是单纯的文本匹配失败一组回放实验把“命中文案”和“提交正确值”分开看这次回放了58条真实任务覆盖地址选择、角色授予、规格切换和审批模板配置。 基线方案只按可见文本点击改进方案增加Option Grounding、回填校验和Commit Fence。 结果说明下拉框事故的核心不是识别率而是提交前有没有证明“这个选项等于业务里的那个值”。✅方案任务成功率串值率平均重试次数人工接管率文本命中 立即点击61%15%2.918%Option Grounding Commit Fence91%2%1.15%很多团队此前把问题归因到视觉模型不稳其实更贵的成本来自“默认回填覆盖”。️ 有些组件在点击后还会触发二次规范化把“上海”自动映射成最近一次保存的“上海总部”。 如果系统不核对隐藏值和表单序列化结果日志会显示流程顺利业务侧却已写错正式配置。defchoose_option(intent,candidates,field_state):matched[itemforitemincandidatesifitem.labelintent.labelanditem.domainintent.domain]iflen(matched)!1:raiseRuntimeError(option not uniquely grounded)pickedmatched[0]iffield_state.pending_keyword!intent.keyword:raiseRuntimeError(stale dropdown result)returnpicked.value图 3下拉框要单独建模因为它的成功标准是“写对值”不是“点到字”工程上真正要补的是 Option Grounding 和 Commit Fence更稳的做法是给每次下拉交互维护一份Option Ledger。️ 账本里至少记录字段名、输入关键词、候选批次号、目标选项label/value、所属租户和最终回填文本。这样执行器在点击前判断当前列表是不是同一次搜索结果在点击后也能核对页面提交值有没有被组件改写。Commit Fence负责拦住“看起来已经选完其实还没提交对”的最后一步。 一旦回填值、隐藏值或接口确认结果不一致系统先冻结提交、重拉候选、必要时转人工而不是继续点“保存”。⏱️ 下拉框真正需要的不是更快点击而是更晚提交。图 4字段身份、候选批次和最终提交值必须作为同一条证据链维护未来 3 到 6 个月 浏览器 Agent 会先学会“先核值再提交”一句话总结下拉选择器不是普通点击控件而是一次异步值绑定。⭐ 把Option Grounding、回填核验和Commit Fence接起来后浏览器Agent才能先证明值对不对再决定能不能提交。 你们现在的自动化链路会把下拉框的隐藏值和最终回填值单独记账吗