Nova Act合成监控：从选择器脚本转向结果断言
内容提要
Nova Act 合成监控使用多模态模型按真实用户路径完成任务，替代易误报的选择器脚本。需分离动作与结果断言，连续两次失败才告警，并使用新会话、最小权限和脱敏证据。它适合视觉频繁变动且结果可断言的流程，是继指标、日志、追踪后的第四层证据，但不替代传统脚本。
延伸解读
动作与结果断言分离：避免模型自评
文章强调必须把“动作”和“结果断言”分开。Agent 可能看错、点错，若断言只复述 Agent 自己的动作说明，监控就变成模型给自己打分。每个关键步骤应有独立结果断言，例如搜索成功是出现相关结果，加购成功是购物车数量、商品标识与价格一致，结账就绪是到达安全停止点而非真正付款。
告警门槛需匹配业务损失速度
连续两次失败才告警可减少模型抖动误报，但门槛并非越低越好。支付页面可每五分钟检查并连续两次失败告警，而每日执行的报表流程连续两次意味着24小时延迟。门槛应结合业务损失速度、模型单次失败概率和执行成本定义。高价值旅程可在首次失败后用另一地域或账号复核，而非无上限重试。
成本与安全：容易被忽视的落地约束
成本不只有 EventBridge 调度费，还包括 Runtime 会话、Browser 会话、Nova Act 操作、通知、重试、多地域倍数、证据存储和人工处置。安全上，每次旅程应使用新会话，身份凭据放 Secrets Manager，运行角色只给最小权限，监控账号不应有真实支付能力，证据需对账号、地址和支付信息脱敏。
适用边界：第四层证据而非替代品
该方法适合视觉改动频繁、选择器维护成本高且业务结果可明确断言的流程。对于稳定 API、简单健康检查或每秒高频探测，传统脚本更快、更便宜、更可预测。Agent 监控不替代指标、日志和追踪，而是第四层证据：证明用户真的能完成任务。上线前应做人为故障演练，并定期回放已知成功与失败录像，防止断言漂移。
Q&A
Nova Act合成监控和传统Selenium脚本监控有什么本质区别？
传统Selenium脚本依赖class或XPath等选择器，界面重构容易导致大面积误报；Nova Act使用多模态大模型处理截图，按真实用户路径完成任务，不依赖固定选择器，因此更适合视觉频繁变动的流程。
Nova Act合成监控如何避免因模型抖动而误报？
需要将“动作”和“结果断言”分开，并设置连续两次失败才告警。例如代码示例中要求三个关键结果全部出现且总时间小于10秒，并且最近两次运行都失败才触发告警。
使用Nova Act做合成监控时，在安全和会话管理上要注意什么？
每次旅程应使用新会话，避免cookie、LocalStorage或购物车残留导致假通过；身份凭据放Secrets Manager，运行角色只给打开浏览器和发告警的最小权限，监控账号不应有真实支付能力；证据需对账号、地址和支付信息脱敏。
Nova Act合成监控适合哪些场景？不适合哪些？
适合视觉改动频繁、选择器维护成本高且业务结果可明确断言的流程；不适合稳定API、简单健康检查或每秒高频探测，这些场景传统脚本更快、更便宜、更可预测。
如何为Nova Act合成监控设计有效的告警策略？
告警门槛要根据业务损失速度、模型单次失败概率和执行成本共同定义。例如支付页面可每五分钟检查并在连续两次失败后告警；每日报表流程连续两次失败则意味着24小时延迟。高价值旅程可在第一次失败后立即用另一地域或不同测试账号复核，而不是无上限原地重试。
Nova Act合成监控的成本需要考虑哪些方面？
不能只看EventBridge调度费用，还需计入Runtime会话、Browser会话、Nova Act操作、通知、每次旅程平均步数、重试次数、多地域倍数、证据存储和人工处置。一个月运行数千次的任务，重试与视频证据可能累积出不小账单。
上线Nova Act合成监控前为什么要做人为故障演练？
通过临时隐藏购物车按钮、让价格接口返回错误币种、制造缓慢加载等，检查Agent是否在正确步骤停止、告警是否附带足够证据、值班人能否不登录生产账号就确认问题。如果Agent在首个关键断言失败后仍尝试后续结账，说明流程将“完成任务”错误地置于“可安全失败”之上。
Nova Act合成监控在整体监控体系中处于什么位置？
它是继指标、日志、追踪之后的第四层证据，用来证明用户真的能完成任务，但不替代传统脚本、指标、日志和追踪。
