Amazon Nova Act 正在围绕用户意图重塑合成监控

Amazon 发布了一套六步参考实现，用于使用 Amazon Nova Act 实施合成监控，以自然语言浏览器操作取代固定的 UI 选择器。9 月 28 日发布的方案结合了 Nova Act、Amazon Bedrock AgentCore、EventBridge Scheduler、CloudWatch 和 SNS。其核心主张是：即使常规界面变更会导致传统脚本失效，智能体仍可持续检查重要的客户旅程。

这一承诺改变了关于合成监控的讨论。问题不再仅限于脚本化浏览器能否点击一个按钮，而在于 AI 智能体能否识别目标按钮、完成整个旅程、验证结果，并区分应用故障与自身的不确定性。

Selenium 和 Playwright 仍是具备确定性控制能力的成熟自动化框架。AWS 并非要在软件测试中全面取代这些工具，而是为周期性生产检查提出另一种运行模式：在这一模式中，降低定位器维护成本与控制每一次交互同样重要。

AWS 将浏览器智能体变成定时监控器

该发布将浏览器推理、隔离执行、调度和告警整合为一条托管监控路径。

合成监控会在真实客户报告问题前，针对应用运行自动化交易流程。一个监控器可能会登录、搜索商品、打开商品页面、将商品加入购物车，并确认结账流程仍然可用。

基础设施指标并不总能揭示这条完整旅程是否正常。即便后端返回健康状态码，禁用的按钮、损坏的覆盖层、延迟加载的第三方组件或前端回归问题，仍可能阻碍客户操作。

新的监控架构使用 EventBridge Scheduler 调用托管在 AgentCore Runtime 上的 Nova Act 工作流。随后，Nova Act 操作 AgentCore Browser 会话；当旅程失败时，SNS 会分发告警。

AWS 建议根据旅程的重要性，将执行频率设为每五分钟一次至每小时一次。其示例聚焦于六步电商流程，并称执行时间介于两到四分钟之间，具体取决于页面加载行为。

该发布之所以重要，是因为它涵盖的不只是浏览器操作本身。示例包括智能体代码、部署自动化、基础设施即代码选项、告警路由、死信处理以及针对缺失运行的告警。

AWS 提供两种部署路径。Python 部署脚本会执行前置条件检查、创建 SNS 主题、部署工作流并连接调度任务。另一套 AWS Cloud Development Kit 堆栈则负责可重复的基础设施配置。

CDK 路径为失败的调度器调用增加了 Amazon SQS 死信队列，同时还会为死信队列深度和缺失的定时运行创建 CloudWatch 告警。

这一区别很重要。监控器可能因调度器从未触达智能体而失败，也可能因智能体已触达应用、却发现用户旅程损坏而失败。基础设施告警覆盖前一类情况，智能体的 SNS 消息则覆盖后一类。

因此，示例实现将监控视为一条由可独立观测组件构成的链路。这比把浏览器智能化描述成完整解决方案更具可信度。

这条链路也带来了新的依赖关系。有效结果如今取决于 EventBridge、AgentCore Runtime、AgentCore Browser、Nova Act 推理、目标应用以及告警路径。团队必须监控监控器本身，而不能只信任其最终状态。

用户旅程故障让选择器维护承受压力

AWS 正在挑战这样一种假设：生产环境中的浏览器检查必须预先编码每一项界面细节。

传统浏览器自动化通过角色、标签、测试 ID、CSS 选择器或 XPath 表达式等契约识别元素。这种方法具有精确性，但其持久性取决于所选契约。

Selenium 提供多种在文档对象模型（DOM）中查找元素的方式；DOM 是浏览器对页面的结构化表示。其定位器指南建议在可用时使用稳定的 ID，否则使用简洁的 CSS 选择器。

Playwright 通过自动等待、重试以及基于面向用户属性的定位器完善了这一模型。其官方定位器文档建议优先使用角色、文本、标签和明确的测试 ID，而不是冗长的 CSS 或 XPath 链。

这些能力使得比较远比“AI 有效、脚本会失效”更加微妙。设计良好的 Playwright 测试能够容忍重新渲染和许多时序变化。稳定的无障碍角色或测试 ID 也可以在视觉重设计后继续有效。

当团队监控无法完全控制的页面时，维护负担会更加突出。第三方身份提供商、支付界面、同意对话框、嵌入式预订服务以及频繁测试的生产变体，可能不会提供稳定的契约。

即使是内部可控的页面也可能造成频繁变动。标签更改、结账组件移动，或实验提供不同布局后，测试都可能失败。工程师随后必须判断：是产品失效了，还是监控器已经过时。

Amazon Nova Act 采用视觉路线。它利用多模态模型处理截图，并根据“点击结账按钮”这类自然语言指令执行操作。该指令描述的是意图，而非 CSS 类或元素 ID。

这种抽象正是对基于选择器监控的核心压力所在。产品团队可以改变样式或内部标记，而不一定改变用户可见的任务。如果 Nova Act 仍能识别该任务，监控器便可继续运行，无需更新选择器。

AWS 表示，早期企业用例中的浏览器工作流准确率超过 90%。这一数字来自 AWS，不能证明其适用于每个网站、用户旅程或界面条件。

不过，这一数字揭示了预期的取舍。智能体接受一定的概率性行为，以减少与紧密耦合选择器相关的确定性维护工作。

这种压力主要落在拥有大量周期性监控器且界面频繁发布的团队身上。每次修复单个选择器的工作量或许不大，但当其覆盖众多旅程、设备、变体和区域时，这些修复便会成为持续的运营负担。

这一变化也影响了职责归属。传统检查通常要求测试工程师理解应用结构。基于意图的操作让运营人员可以更直接地描述业务旅程，但工程师仍需设计断言、权限、重试和可观测性。

AWS 建议从三到五条关键工作流开始，而不是试图实现穷尽式覆盖。登录、结账、账户访问、预订和订阅变更，比影响较低的导航路径更适合作为候选场景。

这一建议让该方案保持务实。智能体驱动的监控在用户旅程中断会带来显著业务后果，且维护大量脆弱检查具有可衡量成本的场景中最具价值。

使用 Amazon Nova Act 实施合成监控改变了控制层

关键机制不仅是自然语言提示，而是将智能体交互与明确的结果验证分离。

示例将浏览器操作组织为旅程步骤。Nova Act 的 act() 方法执行以自然语言描述的操作，其 act_get() 方法返回结构化信息，工作流可以依据 Boolean schema 对其进行评估。

这种分离很重要，因为在页面中点击操作并不能证明成功。监控器必须确认客户真正关心的结果。

对于零售旅程，完成状态可能要求显示搜索结果、购物车中包含正确商品，并且存在可用的结账路径。仅凭页面跳转，可能掩盖空结果集、错误横幅或不正确的购物车状态。

因此，AWS 建议在有意义的检查点设置断言。该设计在不检查每个视觉元素的前提下验证业务结果。这种平衡降低了外观变化引发告警、而功能故障仍不可见的可能性。

当某一步骤失败时，示例可以发布旅程类型、目标 URL、总耗时、已完成步骤和失败步骤。详细异常会保留在运行时日志中，供运营人员调查执行情况。

AgentCore Runtime 提供托管执行层。工作流会获得一个稳定的运行时端点，使 EventBridge Scheduler 能够直接调用它。更新部署时可创建新的运行时版本，而无需更改调度器目标。

Nova Act 命令行界面会打包本地工作流代码、将其容器镜像推送至 Amazon Elastic Container Registry，并配置运行时。Nova Act 接口还包括 Python SDK、IDE 扩展、浏览器 playground 以及用于查看执行跟踪的 AWS 控制台。

AgentCore Browser 提供隔离的远程浏览器，无需团队维护浏览器集群。每次定时运行都会获得独立环境，用于存放 Cookie、缓存、本地存储和中间状态。

AWS 建议在合成监控中使用临时会话。临时会话会以干净状态启动，并在运行结束后消失，从而避免此前成功的登录或缓存页面掩盖新的故障。

AgentCore Runtime 使用专用 microVM，即用于隔离 CPU、内存和文件系统资源的轻量级虚拟机。根据会话架构，会话结束时，microVM 会终止，其内存也会被清理。

隔离既提升安全性，也提高测试有效性。一个监控器不应继承另一个监控器的认证状态、购物车、实验分配或浏览器存储。

该架构也支持内部应用。AgentCore Browser 默认使用公共网络访问，而 VPC 配置可以限制私有环境的出口流量。IAM 策略决定工作流可使用哪些浏览器、运行时和通知资源。

经过身份验证的旅程需要额外的规范。凭据应来自 AWS Secrets Manager，而非提示词、源文件或嵌入部署工件中的环境值。访问权限应仅限于监控器所需的特定账户和交易范围。

使用 Amazon Nova Act 实施合成监控仍然需要编排代码。智能体不会决定哪些旅程重要、应以何种频率运行、哪些结果能够证明成功，或何时应由不确定的结果触发对运营人员的呼叫。

正是这一由人工设计的控制层，将浏览器自动化转化为监控。Nova Act 改变了步骤的执行方式，但可靠性仍取决于周边系统。

真正的竞争是意图与确定性之间的较量

Nova Act 减少了与页面结构的耦合，但也以概率性解释取代了可预测的定位器故障。

基于选择器的检查通常会因可检视的原因失败：元素未匹配、未变为可操作状态，或未在超时前达到预期状态。工程师可以检查 DOM 并更新契约。

基于智能体的检查则可能因应用损坏、模型误读界面，或指令存在歧义而失败。从外部看，这些情况可能十分相似。

这正是 AWS 提案中的核心张力。基于意图的自动化可能经受住会破坏脆弱选择器的常规界面改动；而当页面提供稳定契约时，确定性自动化仍然更易于理解和推理。

最强的实现方案不会将这两种方法视为互斥。团队可以保留低层 API 检查、组件测试和确定性浏览器测试套件，同时为选定的生产环境用户旅程加入智能体驱动的监控。

每一层回答的问题不同。API 检查用于确定服务是否正确响应；确定性端到端测试用于验证既定的应用契约；智能体驱动的监控则询问浏览器是否仍能完成用户可见的目标。

在重新设计期间，这种差异会变得清晰。如果无障碍语义保持稳定，基于角色的 Playwright 定位器可能继续有效；CSS 链可能立即失效。Nova Act 可能凭借视觉判断成功，也可能因为多个元素看起来相似而选择错误的控件。

这种不确定性使旅程措辞成为测试设计的一部分。“完成结账”比“选择可见的结账控件，确认出现审核页面，并且不要下单”留下了更多裁量空间。

指令应明确边界，尤其是涉及破坏性交易时。生产监控不得意外提交真实付款、发送消息、修改客户数据，或造成库存压力。

结果断言同样需要谨慎。仅检查购物车图标的监控器，即使添加了错误商品也可能报告成功；而验证每个标签和布局细节的监控器，又会重建它本应减轻的维护负担。

团队还需要针对不确定性制定策略。一次模型失败不应自动具有与反复出现的面向客户故障相同的严重性。反过来，过多重试可能掩盖真实用户仍会遇到的间歇性缺陷。

AWS 的示例为每个步骤选择一次尝试。这能限制浏览器时长和推理使用量，但 AWS 也承认，当 Nova Act 未能找到实际存在的元素时，这种做法可能产生误报。

步骤级重试可以减少此类告警，但也会延长会话，并引入新的解释性问题：第二次尝试成功，是代表应用健康，还是代表体验已经降级？

答案取决于旅程本身。在低风险搜索检查中进行一次重试或许可以接受；认证或结账期间反复犹豫，本身可能就值得调查。

智能体驱动的监控也改变了测试审查方式。工程师必须检查提示词、断言模式、截图、追踪记录、重试行为和模型结果。DOM 选择器不再是唯一的可执行规范。

这并不意味着维护工作消失，而是将维护转向意图定义、评估规则、访问控制和故障分类。这种转变仍然可能很有价值，但团队应进行衡量，而非想当然地认定如此。

因此，对 Selenium 和 Playwright 的压力是有限且具体的。Nova Act 挑战的是它们作为生产用户旅程监控唯一机制的地位；它并未取代它们在精确、可重复工程测试中的作用。

90% 的智能体尚不足以成为可信赖的寻呼系统

最大的未决问题在于：团队能否在不掩盖真实故障的前提下，将误报维持在较低水平。

AWS 报告的超过 90% 准确率令人鼓舞，但这并不是单个监控器的服务级目标。跨各类工作流的准确率，并不能揭示其在某一特定站点、发布模式、认证流程或地理区域中的表现。

剩余的错误率在监控频率下尤为重要。每五分钟运行一次的检查，在一个 30 天的月份中大约执行 8,640 次。即使智能体源头的失败率很低，在这一规模下也可能产生令人分心的告警。

AWS 的示例估计，每个六步旅程需要大约 24 次操作和断言调用。按每五分钟一次的频率计算，每月约会达到 207,360 次 Nova Act 操作。

这些数字并非对每次部署的预测。它们说明了为什么团队在扩大覆盖范围前，必须评估每步可靠性、会话时长和告警质量。

合理的推广应从影子模式开始。智能体可以在不呼叫值班团队的情况下运行，让运维人员将其结果与确定性检查、应用遥测和人工复现进行比较。

团队应按原因标注故障。可用类别包括：已确认的应用缺陷、预期的应用变更、智能体解释错误、认证问题、基础设施调用失败，以及结果不确定。

这种分类能提供调整指令和重试策略所需的证据，也能揭示智能体究竟是在减少维护，还是仅仅创建了另一条审查队列。

对监控器本身的监控仍然必不可少。CloudWatch 调用指标可以显示智能体是否按预期频率运行，以及每次执行耗时多久。SQS 死信队列则能暴露从未抵达运行时环境的调度投递。

这些信号不能替代旅程告警。运行时可能在发现结账功能损坏后正常返回；反之，即使应用仍然健康，调度器、运行时、浏览器或通知路径也可能发生故障。

安全性带来了另一个压力点。浏览器智能体会看到可能包含不可信文本的页面内容。团队应限制允许访问的域名、授予的权限、可用工具和允许执行的交易。

凭证也需要遵循最小权限原则。合成账户不应继承真实客户或员工的访问权限。其数据应可识别、可移除，并在适当情况下排除在业务报告之外。

地理监控需要谨慎解读。在多个 AWS Regions 部署工作流可以揭示区域性访问或延迟问题，但云端浏览器无法复现每一种住宅网络、设备或客户环境。

CAPTCHA、机器人检测、同意系统和反欺诈控制也可能以不同于真实用户的方式对待合成浏览器。一次成功的智能体会话，并不保证每位客户都会经历相同路径。

模型本身也可能随时间变化。团队需要回归旅程和版本记录，以便将应用变化与智能体行为变化区分开来。

AWS 通过 Nova Act 控制台公开执行追踪信息，包括运行、会话、操作和步骤。这些记录有助于调查故障，但组织必须决定应保留多久包含截图或敏感页面数据的工件。

正确的门槛并非完美准确率。传统监控器也会产生不稳定故障。真正相关的问题是：新系统是否能在不压垮响应人员的前提下，改善故障检测并减少维护工作。

在独立的生产数据出现之前，AWS 的准确率声明应当仍被视为起始假设。每个团队都必须根据自身的旅程和故障容忍度验证这一主张。

三个信号将表明智能体监控能否经受考验

下一阶段应依据告警精度、工作流耐久性，以及可重复的生产环境采用证据来评判。

第一个信号是已确认应用故障与智能体源头告警的比例。团队应追踪有多少寻呼对应可复现缺陷，又有多少源于解释错误、时序问题或模糊指令。

如果经过有限的重试和提示词调优后，这一比例得到改善，那么使用 Amazon Nova Act 实现合成监控的理由就会更充分。如果运维人员经常忽略告警，系统将重建 AWS 希望避免的告警疲劳问题。

第二个信号是在真实界面变更中的存活能力。一项有说服力的评估应将 Nova Act 与构建良好的 Playwright 检查进行比较，而不是与刻意脆弱的 XPath 脚本相比。

团队应记录哪些监控器能够经受标签变更、布局调整、组件重新渲染和实验，同时也应记录确定性的角色或测试 ID 定位器仍能工作、而智能体却陷入困惑的情况。

这种比较将显示视觉推理在哪些方面带来了持久价值，也将识别出那些应保持确定性的旅程：因为其契约稳定，且操作要求精确控制。

第三个信号是参考架构之外更广泛的证据。案例研究应报告监控器数量、运行频率、误报率、平均检测时间、维护时间和故障类别。

独立结果之所以重要，是因为当前的实现及其性能主张均来自 AWS。生产经验将决定这种方法能否在电商、金融、旅行、医疗保健和软件服务领域普遍适用。

组织无需等待最终结论。它们可以选择一个高价值、可逆的旅程，让智能体与现有监控器并行运行。登录就绪性、商品搜索或结账可用性，都可以提供一个边界明确的试验。

该试验应包括明确的成功标准。衡量已确认缺陷检测、误报、维护工作量、会话时长，以及解释每次故障所需的时间。

在对比期间保留现有遥测。应用日志、API 检查、追踪记录、前端错误报告和确定性测试，能够提供评估智能体结论所需的证据。

使用 Amazon Nova Act 实现合成监控，作为额外的可观测性层最具可信度，而不是作为通用替代方案。它的价值在于：当页面结构变化速度快于监控代码应有的变化速度时，验证用户意图。

实际问题很直接：哪一段客户旅程在发生故障时损失足够大，变化又足够频繁以至于脚本化检查负担沉重，同时仍足够安全，能让智能体持续执行？从那里开始，衡量每一条告警，并让生产证据决定模型应走多远。