Browser 节点
浏览器型 workflow 里的打开、填写、上传、提交、截图和高风险点。
Browser 节点本质上不是一个单独按钮，而是一组 capability route。
当前在真实预设里，浏览器提交流最典型的一组动作是：
browser.navigatebrowser.typebrowser.upload_filebrowser.submit_formbrowser.screenshot
最推荐的顺序
浏览器型 workflow 最稳的顺序通常是：
- 打开页面
- 填写字段
- 上传文件
- Review / Approval
- 提交
- 截图取证
这个顺序不是形式主义。
如果把审批放到提交后面，它就不再是审批，只是事后查看。
每一步最该关心什么
| 步骤 | 关键输入 | 最容易错的地方 |
|---|---|---|
| navigate | url | 页面地址不对，或者没真正打开到目标页 |
| type | pageUrl、字段内容 | 不是在正确页面上继续填写 |
| upload_file | pageUrl、fileRefs | 文件为空、文件路径没传下来 |
| submit_form | pageUrl、最终确认信息 | 没审批就提交，或重复提交 |
| screenshot | pageUrl、回执信息 | 提交后页面变了，没截到有效证据 |
浏览器节点最常见的坑
| 现象 | 常见原因 | 更稳的处理方式 |
|---|---|---|
| 填写节点失败 | 上一步 pageUrl 没传下来 | 检查节点之间的引用链 |
| 上传节点失败 | uploadFileRefs 为空，或文件不可用 | 先用测试文件跑最小路径 |
| 提交后失败，不知道到底有没有提交成功 | 外部状态已变化，但回执不稳定 | 先查目标系统和截图证据，不要立刻重跑 |
| 提交成功但没有可审计证据 | 提交后没接 screenshot | 把截图或回执节点放进主干 |
为什么提交节点一定要谨慎
在真实预设里，browser.submit_form 是高风险动作，而且通常要求审批。
原因很简单：
- 它会改变外部世界；
- 有可能重复提交；
- 一旦提交成功，后果不一定能自动回滚。
所以浏览器型 workflow 里最重要的纪律就是：
- 提交前审批；
- 提交后取证；
- 不确定状态时先查证，不要盲目重跑。
更好的使用方法
- 第一次先用测试地址或测试账号跑；
- 尽量把“填写”和“提交”拆开；
- 能截证据就截证据，不要只相信一句成功提示；
- 同一条流程里只保留一个真正提交外部状态的节点。