Amazon Nova Act 合成监控实战：视觉驱动的 UI 自动化测试

文章元数据

SEO 标题: Amazon Nova Act 合成监控实战：视觉驱动的 UI 自动化测试方案
摘要: Amazon Nova Act 通过多模态 AI 处理 UI 截图驱动浏览器自动化，替代脆弱的 DOM 选择器，在浏览器工作流中展示超 90% 准确度。本文基于 AWS 官方博客实战合成监控场景，涵盖架构组件（Bedrock AgentCore、CloudWatch、EventBridge）、工作流定义、部署步骤和成本优化。

目录

  1. 传统 UI 自动化的维护困境
  2. Amazon Nova Act 视觉驱动方案
  3. 合成监控核心应用场景
  4. 五层架构组件解析
  5. 工作流定义：act() 与布尔模式验证
  6. 完整部署流程与代码示例
  7. CloudWatch 监控与告警配置
  8. 成本优化与误报控制
  9. 安全隔离与合规保障
  10. 参考资源与后续实践

1. 传统 UI 自动化的维护困境

传统浏览器自动化工具（Selenium、Playwright、Puppeteer）依赖 CSS 选择器或 XPath 定位元素：

# 传统方法：脆弱的选择器依赖
driver.find_element(By.CLASS_NAME, "checkout-button").click()
driver.find_element(By.ID, "product-price").text

核心痛点：

  • 高维护成本：前端重构后 CSS 类/ID 变更，脚本大规模失效
  • 跨页面不一致：同一功能在不同页面使用不同选择器
  • 动态内容脆弱：A/B 测试、个性化推荐导致选择器随机失效
  • 测试数据污染：需维护独立测试环境和数据集

AWS 官方博客指出，传统方法"当 CSS 类更改时中断"，团队需持续投入人力维护测试脚本。

2. Amazon Nova Act 视觉驱动方案

核心原理

Amazon Nova Act 是 多模态大语言模型，通过处理 UI 截图而非 DOM 选择器执行浏览器自动化。它"使用自然语言动作，在大多数情况下适应 UI 变化"。

对比示例

传统方法：

driver.find_element(By.XPATH, "//button[contains(@class,'btn-primary')]").click()

Nova Act 方法：

nova_act.act("Click the checkout button")

关键优势：

  • 语义理解：识别"结账按钮"的功能意图，而非具体实现
  • 视觉定位：基于截图中的按钮视觉特征，容忍 CSS 变更
  • 自适应：前端重构后无需更新脚本（仅需功能位置不变）

准确度数据

AWS 官方博客披露，Nova Act"在浏览器工作流中展示超 90% 准确度"。需注意该数据来自官方演示结果，实际生产环境需独立验证。

3. 合成监控核心应用场景

合成监控通过 定时模拟真实用户操作 验证关键业务流程，目标是"在客户遇到问题之前通过连续验证关键工作流来检测问题"。

适用行业与场景

| 行业 | 典型监控流程 | 业务影响 |
|---|---|---|
| 电商 | 产品搜索 → 加购 → 结账 → 支付 | 支付网关故障导致订单丢失 |
| 金融服务 | 登录 → 账户查询 → 转账 | 交易流程中断影响资金流动 |
| 旅游和酒店 | 搜索航班 → 选择座位 → 预订确认 | 预订系统失败损失高价值订单 |
| SaaS | 注册 → 邮箱验证 → 订阅升级 | 注册转化漏斗断裂影响 MRR |
| 医疗 | 预约挂号 → 时间选择 → 确认预约 | 预约系统故障影响患者体验 |

为什么需要合成监控

  • 真实用户监控（RUM）的局限：只能在用户遇到问题后被动发现
  • 健康检查的盲区：HTTP 200 不代表业务流程可用
  • 第三方依赖风险：支付网关、物流 API、CDN 故障需主动探测

4. 五层架构组件解析

Nova Act 合成监控方案由五个 AWS 服务协作：

┌─────────────────────────────────────────────────────────┐
│ EventBridge Scheduler (定时触发)                         │
└────────────────────┬────────────────────────────────────┘
                     │ 每 5 分钟触发一次
                     ▼
┌─────────────────────────────────────────────────────────┐
│ Bedrock AgentCore Runtime (无服务器执行)                 │
│ ├─ 会话隔离 (Firecracker 微虚拟机)                       │
│ ├─ 浏览器工具 (隔离的远程浏览器环境)                      │
│ └─ Nova Act 推理调用                                     │
└────────────────────┬────────────────────────────────────┘
                     │ 失败时
                     ▼
┌─────────────────────────────────────────────────────────┐
│ SNS (通知路由)                                           │
│ ├─ Email                                                │
│ ├─ Slack/Teams                                          │
│ └─ 事件响应工具 (PagerDuty/Opsgenie)                     │
└─────────────────────────────────────────────────────────┘

              监控与观测
┌─────────────────────────────────────────────────────────┐
│ CloudWatch (指标和告警)                                  │
│ ├─ 调用次数、持续时间、失败率                             │
│ ├─ 死信队列深度                                          │
│ └─ 计划运行缺失告警                                      │
└─────────────────────────────────────────────────────────┘

组件职责详解

4.1 Amazon Nova Act

  • 输入：自然语言指令（"点击结账按钮"）
  • 输出：浏览器操作序列
  • 视觉推理：处理 UI 截图识别元素位置
  • 语言推理：理解操作意图与上下文

4.2 Bedrock AgentCore Runtime

  • 无服务器执行：按需启动会话，无需维护基础设施
  • 会话隔离：Firecracker 微虚拟机确保测试独立性
  • 浏览器工具：为每次测试提供隔离的远程浏览器环境
  • 网络模式：默认公共网络访问，支持 VPC 配置限制特定域

4.3 EventBridge Scheduler

  • 定时触发：按 cron 表达式或固定速率触发测试
  • 目标配置：AgentCore Runtime 工作流 ARN
  • 失败处理：死信队列捕获调用失败

4.4 CloudWatch

  • 指标收集：调用次数、持续时间、错误率
  • 告警配置：死信队列深度、计划运行缺失
  • 日志留存：工作流执行日志供故障排查

4.5 SNS

  • 失败通知：仅在工作流失败时发布
  • 订阅端点：Email、Slack、PagerDuty 等
  • 消息内容：旅程类型、目标 URL、完成步骤、失败步骤

5. 工作流定义：act() 与布尔模式验证

核心 API 方法

5.1 act() — 执行操作与验证

# 自然语言驱动 UI 交互
nova_act.act("Click the 'Add to Cart' button")
nova_act.act("Enter 'test@example.com' in the email field")
nova_act.act("Scroll down to the footer")

# 布尔模式验证（基于博客示例推断）
# 注意：官方 API 文档尚未明确此用法，以下为根据博客"布尔模式"描述推断
result = nova_act.act("Verify the shopping cart count shows '1'", mode="boolean")
if not result:
    raise AssertionError("购物车数量验证失败")

特点：

  • 无需指定选择器，模型自动识别目标元素
  • 支持复杂操作（如"选择第二个产品卡片"）
  • 容忍 UI 变化（按钮文案从"Buy Now"改为"立即购买"仍可识别）
  • 布尔验证模式可用于断言检查（具体 API 以官方文档为准）

典型六步电商流程示例

def test_checkout_workflow():
    """
    合成监控流程：产品搜索 → 加购 → 结账 → 支付
    预期执行时间：2-4 分钟
    """
    
    # Step 1: 导航到首页
    nova_act.act("Navigate to https://example-shop.com")
    
    # Step 2: 搜索产品
    nova_act.act("Enter 'wireless headphones' in the search box")
    nova_act.act("Click the search button")
    
    # 检查点 1: 验证搜索结果（使用布尔模式，以官方文档为准）
    has_results = nova_act.act("Verify product results are displayed", mode="boolean")
    if not has_results:
        notify_failure("搜索结果为空", completed_steps=2)
        return
    
    # Step 3: 选择产品
    nova_act.act("Click the first product in the results")
    
    # Step 4: 加入购物车
    nova_act.act("Click the 'Add to Cart' button")
    
    # 检查点 2: 验证购物车状态
    cart_updated = nova_act.act("Verify the cart icon shows '1' item", mode="boolean")
    if not cart_updated:
        notify_failure("购物车未更新", completed_steps=4)
        return
    
    # Step 5: 进入结账
    nova_act.act("Click the cart icon")
    nova_act.act("Click the 'Proceed to Checkout' button")
    
    # 检查点 3: 验证结账页面
    on_checkout = nova_act.act("Verify the page shows 'Shipping Information' section", mode="boolean")
    if not on_checkout:
        notify_failure("未到达结账页", completed_steps=5)
        return
    
    # Step 6: 填写测试数据（不实际支付）
    nova_act.act("Enter 'John Doe' in the name field")
    nova_act.act("Enter 'test@example.com' in the email field")
    
    # 检查点 4: 验证表单可填写
    form_valid = nova_act.act("Verify the 'Continue to Payment' button is enabled", mode="boolean")
    if not form_valid:
        notify_failure("结账表单验证失败", completed_steps=6)
        return
    
    # 成功完成，无需发布 SNS
    print("✓ Checkout workflow completed successfully")

设计原则

AWS 建议"代理将自然语言动作分组为逻辑旅程步骤，在关键检查点使用断言"：

  • 3-5 个高价值工作流：避免详尽覆盖导致维护负担
  • 有意义的结果验证：检查购物车数量而非每个 DOM 元素
  • 单次尝试执行：最小化浏览器会话成本
  • 步骤级重试（可选）：需要更低误报率的团队可添加

6. 完整部署流程与代码示例

前置条件

  • AWS 账户并启用 Bedrock、AgentCore、EventBridge、SNS 服务
  • 安装 AWS CLI 和 act CLI 工具
  • IAM 权限：bedrock:InvokeModel、agentcore:<em>、events:</em>、sns:Publish

部署步骤

步骤 1：定义工作流代码

创建 synthetic_monitor.py：

import boto3
from datetime import datetime

def monitor_workflow():
    """
    合成监控主函数
    """
    try:
        # 执行业务流程测试
        test_checkout_workflow()
        
        # 成功时无操作（无需发布 SNS）
        return {
            'statusCode': 200,
            'body': 'Workflow completed successfully'
        }
    
    except AssertionError as e:
        # 失败时发布 SNS
        publish_failure_notification(str(e))
        return {
            'statusCode': 500,
            'body': f'Workflow failed: {str(e)}'
        }

def publish_failure_notification(error_message):
    sns = boto3.client('sns')
    topic_arn = 'arn:aws:sns:us-east-1:ACCOUNT_ID:synthetic-monitor-alerts'
    
    sns.publish(
        TopicArn=topic_arn,
        Subject='🚨 Synthetic Monitor Alert',
        Message=f"""
        Workflow: Checkout Journey
        Target URL: https://example-shop.com
        Failure Time: {datetime.utcnow().isoformat()}
        Error: {error_message}
        
        Action Required: Investigate the checkout flow immediately.
        """
    )

步骤 2：部署到 AgentCore Runtime

# 创建工作流
act workflow create \
  --name synthetic-checkout-monitor \
  --file synthetic_monitor.py

# 部署到 AgentCore
act workflow deploy \
  --name synthetic-checkout-monitor \
  --region us-east-1

# 获取工作流 ARN（用于 Scheduler 目标）
act workflow show \
  --name synthetic-checkout-monitor \
  --output json | jq -r '.arn'

返回 ARN 示例：

arn:aws:agentcore:us-east-1:123456789012:workflow/synthetic-checkout-monitor

步骤 3：配置 EventBridge Scheduler

# 创建 SNS 主题
aws sns create-topic \
  --name synthetic-monitor-alerts \
  --region us-east-1

# 订阅 Email 通知
aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:ACCOUNT_ID:synthetic-monitor-alerts \
  --protocol email \
  --notification-endpoint ops-team@example.com

# 创建定时任务（每 5 分钟执行一次）
aws scheduler create-schedule \
  --name synthetic-checkout-monitor-schedule \
  --schedule-expression "rate(5 minutes)" \
  --flexible-time-window Mode=OFF \
  --target Arn=arn:aws:agentcore:us-east-1:ACCOUNT_ID:workflow/synthetic-checkout-monitor,RoleArn=arn:aws:iam::ACCOUNT_ID:role/EventBridgeSchedulerRole

步骤 4：使用 CDK 自动化部署（推荐生产）

import * as cdk from 'aws-cdk-lib';
import * as events from 'aws-cdk-lib/aws-events';
import * as targets from 'aws-cdk-lib/aws-events-targets';
import * as sns from 'aws-cdk-lib/aws-sns';
import * as subscriptions from 'aws-cdk-lib/aws-sns-subscriptions';

export class SyntheticMonitorStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);
    
    // SNS 主题
    const alertTopic = new sns.Topic(this, 'SyntheticMonitorAlerts', {
      displayName: 'Synthetic Monitor Failure Alerts',
    });
    
    alertTopic.addSubscription(
      new subscriptions.EmailSubscription('ops-team@example.com')
    );
    
    // EventBridge 规则
    const rule = new events.Rule(this, 'SyntheticMonitorSchedule', {
      schedule: events.Schedule.rate(cdk.Duration.minutes(5)),
    });
    
    rule.addTarget(new targets.AgentCoreWorkflow({
      workflowArn: 'arn:aws:agentcore:us-east-1:ACCOUNT_ID:workflow/synthetic-checkout-monitor',
    }));
    
    // CloudWatch 告警
    const dlqAlarm = new cloudwatch.Alarm(this, 'SchedulerDLQAlarm', {
      metric: rule.metricFailedInvocations(),
      threshold: 1,
      evaluationPeriods: 1,
    });
    
    dlqAlarm.addAlarmAction(new cwactions.SnsAction(alertTopic));
  }
}

7. CloudWatch 监控与告警配置

推荐告警策略

告警 1：死信队列深度

目的：捕获 Scheduler 调用失败（网络问题、权限错误、配额超限）

aws cloudwatch put-metric-alarm \
  --alarm-name synthetic-monitor-scheduler-dlq \
  --alarm-description "Scheduler failed to invoke workflow" \
  --metric-name ApproximateNumberOfMessagesVisible \
  --namespace AWS/SQS \
  --statistic Sum \
  --period 300 \
  --threshold 1 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:us-east-1:ACCOUNT_ID:synthetic-monitor-alerts

告警 2：计划运行缺失

目的：检测 Scheduler 本身失效或被禁用

aws cloudwatch put-metric-alarm \
  --alarm-name synthetic-monitor-missing-runs \
  --alarm-description "No workflow executions in the last 15 minutes" \
  --metric-name Invocations \
  --namespace AWS/AgentCore \
  --statistic Sum \
  --period 900 \
  --threshold 1 \
  --comparison-operator LessThanThreshold \
  --evaluation-periods 1 \
  --treat-missing-data breaching \
  --alarm-actions arn:aws:sns:us-east-1:ACCOUNT_ID:synthetic-monitor-alerts

关键指标监控

| 指标 | 命名空间 | 说明 | 正常范围 |
|---|---|---|---|
| Invocations | AWS/AgentCore | 工作流调用次数 | 与 Scheduler 频率一致 |
| Duration | AWS/AgentCore | 单次执行时长 | 2-4 分钟（六步流程） |
| Errors | AWS/AgentCore | 失败次数 | < 10%（目标） |
| ThrottledRequests | AWS/Bedrock | Nova Act 限流 | 0（需增加配额） |

日志查询示例

# 查询最近失败的工作流
aws logs filter-log-events \
  --log-group-name /aws/agentcore/synthetic-checkout-monitor \
  --filter-pattern "ERROR" \
  --start-time $(date -u -d '1 hour ago' +%s)000

# 统计步骤级成功率
aws logs insights query \
  --log-group-name /aws/agentcore/synthetic-checkout-monitor \
  --start-time $(date -u -d '24 hours ago' +%s) \
  --end-time $(date -u +%s) \
  --query-string '
    fields @timestamp, completed_steps
    | stats count() by completed_steps
    | sort completed_steps desc
  '

8. 成本优化与误报控制

成本构成分析

以 每 5 分钟运行一次、六步流程、单次 2-4 分钟 为例：

  • 月度调用次数：约 8,640 次（按 30 天计算，60/5 × 24 × 30）
  • 总浏览器时长：259-518 小时/月

| 服务 | 单价（参考） | 月度用量 | 预估成本 |
|---|---|---|---|
| AgentCore Runtime | 按调用计费 | 约 8,640 次 | 见定价页 |
| AgentCore 浏览器工具 | 按分钟计费 | 17,280-34,560 分钟 | 见定价页 |
| Nova Act 推理 | 按输入/输出 token | ~6 张截图/次 | 见定价页 |
| EventBridge Scheduler | $1/百万次调用 | 约 8,640 次 | ~$0.01 |
| SNS | $0.50/百万次发布 | <1,000 次（失败） | ~$0.001 |

注意：主要成本驱动来自 浏览器会话时长 和 Nova Act 推理调用。优化方向：

  • 减少步骤数（专注核心路径）
  • 降低运行频率（关键流程 5 分钟，次要流程 30 分钟）
  • 避免等待超时（优化页面加载速度）

误报控制策略

问题：传统 UI 测试误报率高

  • 加载延迟导致元素未渲染
  • A/B 测试随机展示不同 UI
  • 第三方广告/分析脚本阻塞
  • CDN 缓存未更新

Nova Act 优势：视觉容错

  • 等待元素出现后再交互（内置智能等待）
  • 识别功能意图而非具体实现（"结账按钮"而非特定 CSS 类）
  • 适应小幅 UI 调整（按钮位置微调、颜色变化）

推荐配置

  1. 专注 3-5 个高价值工作流：避免详尽覆盖
  2. 验证有意义的结果：检查订单确认页而非每个 DOM 元素
  3. 单次尝试执行：最小化浏览器会话成本
  4. 步骤级重试（可选）：容忍瞬时网络抖动

def act_with_retry(instruction, max_retries=2):

for attempt in range(max_retries):

try:

nova_act.act(instruction)

return

except Exception as e:

if attempt == max_retries - 1:

raise

time.sleep(2)

9. 安全隔离与合规保障

会话隔离机制

  • Firecracker 微虚拟机：每次测试在独立虚拟机中执行
  • 完全内存清理：会话结束时清除 cookies、浏览器缓存、LocalStorage
  • 暂时会话："默认情况下每个会话以完全内存清理终止，防止 cookie、浏览器缓存和 LocalStorage 在运行之间持久化"

凭证管理

import boto3

def get_test_credentials():
    """
    从 Secrets Manager 获取测试账户凭证
    """
    client = boto3.client('secretsmanager')
    response = client.get_secret_value(SecretId='synthetic-monitor/test-account')
    return json.loads(response['SecretString'])

# 使用
creds = get_test_credentials()
nova_act.act(f"Enter '{creds['username']}' in the username field")
nova_act.act(f"Enter '{creds['password']}' in the password field")

网络访问控制

  • 公共网络模式：默认，适合监控互联网公开服务
  • VPC 模式：通过 VPC 配置限制访问特定内部域
    • 
act workflow deploy \

--name synthetic-monitor \

--vpc-config SubnetIds=subnet-xxx,SecurityGroupIds=sg-yyy

合规性

  • HIPAA 合规：AWS 博客确认"Amazon Nova Act is now HIPAA eligible"（截至 2026 年 5 月）
  • 数据留存：CloudWatch 日志可配置留存期（1 天 - 10 年）
  • 访问控制：IAM 强制最小权限（仅允许特定工作流调用）

10. 参考资源与后续实践

官方资源

后续实践方向

1. 渐进式部署策略

  • 第 1 周：部署单个核心流程（如结账），dry-run 模式验证准确度
  • 第 2 周：添加 2-3 个次要流程（登录、搜索、支付），启用真实告警
  • 第 3-4 周：根据误报率调整检查点，优化运行频率

2. 多区域监控

const regions = ['us-east-1', 'eu-west-1', 'ap-southeast-1'];

regions.forEach(region => {
  new SyntheticMonitorStack(app, `SyntheticMonitor-${region}`, {
    env: { region },
  });
});

3. 与 CI/CD 集成

# .github/workflows/pre-deploy-check.yml
name: Pre-Deploy Synthetic Check
on:
  pull_request:
    branches: [main]

jobs:
  synthetic-check:
    runs-on: ubuntu-latest
    steps:
      - name: Run synthetic monitor
        run: |
          aws agentcore invoke-workflow \
            --workflow-arn ${{ secrets.WORKFLOW_ARN }} \
            --wait-for-completion
      
      - name: Block merge if failed
        if: failure()
        run: exit 1

4. 成本优化实验

  • 对比不同运行频率的故障检测时效
  • 测试步骤合并对准确度的影响
  • 评估批量运行 vs 单次运行的成本差异

局限性与注意事项

  • 准确度依赖 UI 稳定性：动态内容过多（如实时股票价格）可能影响识别
  • 截图处理开销：每步需上传截图到 Nova Act，网络延迟影响总时长
  • 自然语言歧义：复杂指令需明确描述（"点击左侧第二个蓝色按钮"优于"点击那个按钮"）
  • 成本随频率线性增长：高频监控需评估 ROI（5 分钟 vs 30 分钟）

行动召唤（CTA）

Amazon Nova Act 通过视觉驱动的 AI 方案解决了传统 UI 自动化的维护困境，90% 准确度的早期数据显示其生产可行性。如果您的团队面临以下场景，建议立即试点：

  1. UI 测试维护成本高：前端频繁重构导致脚本失效
  2. 关键业务流程需 7×24 监控：电商结账、金融交易、SaaS 注册
  3. 第三方依赖风险高：支付网关、物流 API、CDN 故障需主动探测

建议起步路径：

  1. 选择 1 个核心流程（3-6 步），使用 AWS Free Tier 测试
  2. 配置 CloudWatch 告警和 SNS 通知，运行 1 周收集基线数据
  3. 根据误报率调整检查点，逐步扩展到 3-5 个高价值工作流

对于需要传统选择器精度的场景（如自动化表单填写、数据抓取），仍建议使用 Playwright/Selenium。Nova Act 与传统工具互补使用，可构建更健壮的监控体系。

关键词：Amazon Nova Act, 合成监控, UI 自动化, 视觉驱动测试, AWS Bedrock, AgentCore Runtime, CloudWatch 监控, 浏览器自动化, Synthetic Monitoring, 多模态 AI

Sources:

EOF · 全文完 AI Agent · · 共 4.2k 字

感谢耐心读到这里。若这篇文字曾带来片刻启发或共鸣，不妨点亮喜欢或分享给同路人。

喜欢 0
DISCUSSION / 读者评论 0 条评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

ESC