AWS发布用Amazon Nova Act做合成监控的方案
AWS机器学习博客介绍了一套用Amazon Nova Act配合Amazon Bedrock AgentCore实现合成监控的架构，用自然语言动作替代Selenium、Playwright的选择器脚本，官方称Nova Act在浏览器工作流上早期企业客户用例的准确率超过 90%。
AI解读：这套方案要解决的是传统UI自动化脚本太脆的问题。Selenium、Playwright依赖DOM选择器，CSS类名或元素ID一改，测试就断，团队花在维护选择器上的时间往往超过写新自动化。Nova Act改为处理界面截图，从屏幕上看到的内容推理，因此对常规UI改动更有韧性。
对做电商、金融、旅游、SaaS、医疗这类有登录、下单、预约、注册流程的团队来说，合成监控的意义是把故障发现时间从“客户投诉后”提前到“部署后几分钟内”。样本里的事件调度器最短每 5 分钟跑一次，六步流程一次耗时 2 到 4 分钟。
但要注意两个限制。一是准确率不是 100%，AWS自己建议团队在自己的站点上测试，并给监控加重试逻辑；样本默认每步只尝试一次，是为了省浏览器会话成本，代价是偶尔会出现元素明明在、Nova Act没找到的误报。二是这条新闻来自AWS官方博客，成本和准确率数字都出自AWS自己，缺少第三方验证。
成本方面，样本给出的六步电商流程每 5 分钟跑一次、每月约 8640 次调用，主要开销在浏览器会话时长和Nova Act每步的推理调用，博客没有给出具体金额，只让读者看定价页。这意味着要不要用，取决于团队自己算这笔账，而不是看一个宣传数字。
普通用户不需要为此做什么。真正相关的是负责关键业务流程可用性的工程和运维团队，他们可以照着AWS提供的示例仓库部署一套，但需要先确认自己的AWS账号有Nova Act和AgentCore的访问权限，并想清楚要监控哪 3 到 5 条最关键的客户旅程，避免监控过多导致告警疲劳。
AWS机器学习博客发布了一篇由Sarath Krishnan撰写的文章，介绍如何用Amazon Nova Act和Amazon Bedrock AgentCore实现“智能体驱动”的合成监控。合成监控指按计划自动模拟真实用户操作，持续验证登录、购买、表单提交等关键流程，而不是等客户先遇到问题。
文章对比了两种做法。传统浏览器自动化框架如Selenium和Playwright依赖显式的DOM定位器和选择器，示例中每个工作流要写 10 行以上选择器代码，CSS类名一变就断。Nova Act的做法是用自然语言动作，示例中 3 行代码完成结账、支付、确认订单，不需要维护选择器。
AWS称，因为Nova Act使用多模态大语言模型处理UI截图而非DOM选择器，它对界面改动“显著更有韧性”。在早期企业客户用例中，Nova Act在浏览器工作流上表现出超过 90% 的准确率。文章同时建议团队在自己的站点上测试，并为适配不成功的情况设计重试逻辑。
方案由几个AWS服务分工组成：Nova Act用自然语言动作定义和执行UI工作流；Amazon Bedrock AgentCore Runtime提供无服务器执行、会话隔离和稳定调用端点；AgentCore Browser工具为每次测试提供隔离的远程浏览器环境；Amazon EventBridge Scheduler和Amazon Simple Notification Service（Amazon SNS）分别负责定时调度和告警。
流程是：EventBridge Scheduler按计划（每 5 分钟到每小时，取决于工作流关键性）触发运行，通过通用目标直接调用InvokeAgentRuntime；智能体在AgentCore Runtime中执行，调用Nova Act在Browser会话里驱动UI；任何一步失败就通过SNS发布通知，推送到订阅的邮件、聊天工具或事件响应系统。
前提条件包括：有权限访问Nova Act、AgentCore（Runtime和Browser工具）、Amazon ECR、IAM、EventBridge Scheduler和SNS的AWS账号；Python 3.11或更高版本、Docker、配置好凭证的AWS CLI v2；生产基础设施路径还需要Node.js 18或更高版本和AWS CDK，另外也提供独立的deploy.py脚本；如果要创建SNS邮件告警订阅，需要一个邮箱地址。
六步旅程耗时 2 到 4 分钟，样本用单次尝试控制浏览器成本
定义旅程时，文章建议先确定最关键的客户旅程。以电商为例，通常包括首页加载、产品搜索、商品详情导航、加入购物车验证和结账就绪。监控不应只看流程是否走完，而要显式验证结果：搜索结果是否正确出现、购物车是否包含商品、有没有显示错误横幅。文章认为显式结果验证能减少检查不完整造成的误报和断言过于宽松造成的漏报。
智能体把自然语言动作分组成逻辑旅程步骤，并在关键检查点使用断言：动作通过act() 用自然语言驱动UI，断言通过act_get() 配合布尔schema验证结果。旅程失败时，智能体发布旅程类型、目标URL、时长、已完成步骤和失败步骤，详细的异常信息留在运行时日志里。
文章称测试中一个典型的六步旅程根据页面加载时间需要 2 到 4 分钟完成。样本代码使用每次步骤单次尝试执行，目的是最小化Browser会话成本；由于Nova Act的自然语言适配约 90% 的情况下能成功，单次尝试偶尔会在元素实际存在时产生误报。需要更低误报率的团队可以加入步骤级重试（失败步骤重跑一次再判定失败），代价是会话时长变长。
- 动作使用act()，断言使用act_get() 加布尔schema
- 失败通知包含旅程类型、目标URL、时长、已完成和失败步骤
- 详细异常信息保留在运行时日志
- 六步旅程典型耗时 2 到 4 分钟，取决于页面加载时间
- 默认每步单次尝试，可加步骤级重试降低误报但拉长会话
部署走Nova Act CLI或CDK，运行时ARN保持不变
在EventBridge调度能调用智能体之前，需要用Nova Act CLI把它部署到AgentCore Runtime。act workflow命令会打包智能体代码、把容器镜像推送到Amazon ECR并配置运行时。部署完成后，端点ARN保持不变，更新会创建新的运行时版本，不需要更新Scheduler目标。
样本仓库的deploy.py脚本封装了这些命令，并加入前置检查（Docker、AWS凭证），创建SNS告警主题并接好EventBridge调度，一条python deploy.py就能完成端到端部署。文章说明，AgentCore也提供自己的agentcore CLI用于智能体开发，但这个样本统一使用Nova Act的act workflow命令。
对于生产级、可重复的部署，样本还提供一个CDK堆栈作为deploy.py的替代方案。它配置带最小权限IAM的EventBridge调度、SNS告警主题，以及一个捕获Scheduler调用InvokeAgentRuntime失败的SQS死信队列。堆栈还创建两个Amazon CloudWatch告警：一个针对死信队列深度，一个针对计划运行缺失（使用AWS/Scheduler的InvocationAttemptCount指标，把数据缺失视为违反）。
文章特别说明，这两个告警检测的是基础设施故障，比如向智能体投递失败或调度没触发。功能上坏掉、但HTTP层仍返回正常的客户旅程，会通过智能体向SNS发布通知暴露出来，而不是通过这两个CloudWatch告警。
- 部署命令：act workflow create、act workflow deploy、act workflow show
- act workflow show返回用作Scheduler目标的AgentCore Runtime ARN
- deploy.py一条命令完成端到端部署
- CDK堆栈包含EventBridge调度、SNS主题和SQS死信队列
- 两个CloudWatch告警针对死信队列深度和计划运行缺失
- CDK堆栈不拥有AgentCore Runtime，需另行用act workflow delete删除
会话隔离默认清理内存，凭证建议放Secrets Manager
安全方面，AgentCore Runtime为每次测试执行提供会话隔离，采用基于Firecracker微虚拟机的严格“一会话一微虚拟机”模型。默认情况下每个会话结束时进行完整内存清理，防止cookie、浏览器缓存和LocalStorage在运行之间残留，从而避免状态泄漏导致的误报。文章建议合成监控始终使用临时会话；AgentCore虽通过SaveBrowserSessionProfile API为其他用例提供持久浏览器配置，但合成监控不应使用。
网络访问上，Browser工具默认运行在公共网络模式，提供适合验证面向客户网站的互联网访问。需要外联控制的团队可以使用带Amazon VPC配置的Browser，把网络访问限制到特定域名，用于监控内部应用。
权限方面，文章建议结合AWS Identity and Access Management（IAM）执行最小权限，IAM角色定义智能体可以访问哪些资源，包括SNS发布权限和Browser工具调用权限。合成测试需要认证时，应把凭证存储在AWS Secrets Manager中，敏感信息保持加密，访问可通过AWS CloudTrail审计。
- 每次测试执行使用一会话一Firecracker微虚拟机
- 默认会话终止时完整内存清理，防止cookie、缓存、LocalStorage残留
- 合成监控推荐使用临时会话，不使用持久浏览器配置
- Browser工具默认公共网络模式，可用Amazon VPC限制到特定域名
- 凭证存入AWS Secrets Manager，访问经AWS CloudTrail审计
每月约 8640 次调用，主要成本在浏览器会话和推理
文章列出成本的五个组成部分：AgentCore Runtime调用、Browser工具会话、Nova Act推理、EventBridge Scheduler调用和SNS通知。主要成本驱动因素是浏览器会话时长和每个旅程步骤的Nova Act推理调用。
以样本的六步电商旅程每 5 分钟运行一次、每月约 8640 次调用为例，文章给出的用量是：8640 次会话、每次约 2 到 4 分钟的AgentCore Runtime调用和Browser工具会话；约 207,360 次动作和断言调用（每旅程 24 次）的Nova Act操作；EventBridge Scheduler 8640次调用约 0.009 美元；SNS通知仅在配置告警时产生，可忽略不计。其余各项文章让读者查看对应定价页，没有给出具体金额。
运维上，文章提出两个关注点：观察监控系统自身和管理成本。AgentCore Runtime向CloudWatch发布智能体调用指标，可跟踪执行频率和时长；成功时智能体不发SNS，旅程失败通过SNS发布暴露；建议为SNS主题配置死信队列以检测失败的智能体调用。
- 成本五部分：Runtime调用、Browser会话、Nova Act推理、Scheduler调用、SNS通知
- 样本六步旅程每 5 分钟一次，每月约 8640 次调用
- 每月约 207,360 次Nova Act动作和断言调用，按每旅程 24 次计算
- EventBridge Scheduler每月 8640 次调用约 0.009 美元
- SNS通知仅在配置告警时产生，成本可忽略
建议只监控 3 到 5 条关键旅程以避开告警疲劳
文章建议把合成监控集中在高价值客户旅程上，而不是覆盖每个页面。过度监控会产生噪音，让团队对真实故障麻木。起步时选择 3 到 5 个关键工作流（登录、结账、账户访问），再根据实际故障模式和业务影响扩展。应该监控直接影响收入或客户信任的旅程，而不是所有可能的用户路径。
断言也不应过度。文章建议验证有意义的结果，比如搜索结果是否出现、购物车是否包含商品，而不是检查页面上每个DOM元素；过于细粒度的断言会增加误报，却不会提升故障检测能力。
多区域方面，用户分布在全球的组织可以在多个AWS区域部署Nova Act合成监控，从不同地理位置测试用户体验，并用基础设施即代码在各支持区域一致、可重复地部署。文章让读者查看Amazon Bedrock AgentCore和Amazon Nova Act产品页了解当前区域可用性。清理时，deploy.py路径可运行python deploy.py --cleanup停止调度并移除工作流和相关样本资源；CDK路径运行cdk destroy移除CDK管理的调度、SQS死信队列、CloudWatch告警、SNS主题和IAM角色，但CDK堆栈不拥有AgentCore Runtime，需另行用act workflow delete --name synthetic-monitoring-workflow删除。
- 起步建议 3 到 5 个关键工作流，再按实际故障模式扩展
- 验证结果而非遍历DOM元素，减少误报
- 可在多个AWS区域部署，用基础设施即代码保持一致
- deploy.py路径用python deploy.py --cleanup清理
- CDK路径用cdk destroy，AgentCore Runtime需单独删除