一句话结论
AWS 发布基于 Nova Act 与 Bedrock AgentCore 的合成监控架构，利用多模态大语言模型自动化模拟用户旅程，实现无脚本维护的 UI 异常检测。
关键要点
- 该方案采用多模态大语言模型处理 UI 截图而非传统 DOM 定位器，对界面变化具有更强韧性，早期企业案例显示关键工作流准确率超过 90%。
- 典型六步用户旅程执行耗时为 2 至 4 分钟，具体时长取决于页面加载速度；部署前需通过 Nova Act CLI 打包代码并推送镜像至 Amazon ECR。
- 系统通过 Amazon EventBridge Scheduler 定期触发 InvokeAgentRuntime，端点 ARN 保持恒定，更新时仅创建新版本，无需修改调度器目标配置。
- 成本结构中，每 5 分钟运行一次的六步电子商务旅程月均产生 8,640 次调用及约 207,360 次 Nova Act 操作，涵盖推理、浏览器会话及通知等五个计费组件。
- AgentCore Runtime 采用 Firecracker 微虚拟机技术，实施“一会话-一微虚拟机”隔离模型，默认在会话结束时执行完整内存清洗，防止 Cookie 和缓存泄露。
背景与事实
亚马逊云科技（AWS）在机器学习博客中详细阐述了如何利用 Amazon Nova Act 结合 Amazon Bedrock AgentCore 实现代理驱动的合成监控。这一架构旨在解决传统浏览器脚本易因 UI 变化而失效的问题，通过自动化模拟真实用户旅程（如登录、购买、表单提交），在关键工作流性能降级或交互中断时快速检测问题。该方案适用于电商、金融服务、旅行酒店、SaaS 及医疗等多个行业，核心优势在于利用多模态大语言模型直接分析 UI 截图，替代了脆弱的 DOM 定位器。
在技术实现层面，该方案通过 Amazon EventBridge Scheduler 调用 InvokeAgentRuntime，避免了持续维护脆弱的浏览器脚本。实施流程要求首先定义关键客户旅程（例如主页加载、搜索、加购、结账），并明确验证结果（如搜索结果正确性、购物车内容完整性、无错误横幅出现），以减少误报和漏报。代码部署至 AgentCore Runtime 后，通过浏览器工具管理会话生命周期。测试数据显示，典型的六步旅程耗时在 2 至 4 分钟之间。部署前，开发者需使用 Nova Act CLI 的 act workflow 命令打包代码、推送镜像至 Amazon ECR 并置备运行时。部署后，端点 ARN 保持恒定，后续更新仅创建新版本，无需修改 Scheduler 目标，确保了架构的稳定性。
官方示例仓库提供了 deploy.py 脚本，集成 Docker 及 AWS 凭证检查，并自动创建 SNS 警报主题及配置 EventBridge 计划，实现端到端部署。同时，仓库提供 CDK 堆栈作为替代方案，配置最小权限 IAM、SNS 主题及捕获调用失败的 SQS 死信队列。堆栈创建两个 CloudWatch 警报：监控死信队列深度及计划运行缺失（基于 AWS/Scheduler InvocationAttemptCount 指标）。这些警报主要检测基础设施故障，而功能故障则通过 Agent 的 SNS 发布体现。建议监控 3 至 5 个关键工作流程（如登录、结账），避免过度监控及断言导致成本飙升。
影响分析
对于中文开发者与企业技术负责人而言，此方案标志着监控模式从“代码维护”向“意图定义”的范式转移。传统合成监控依赖精确的 CSS 选择器或 XPath，一旦前端框架升级或 UI 微调，大量脚本即刻失效，维护成本极高。基于 Nova Act 的方案利用大语言模型理解自然语言指令，显著降低了对前端实现的耦合度。分析认为，这将迫使企业重新评估 QA 团队与 DevOps 团队的职责边界：QA 更专注于定义“用户旅程”与“成功标准”，而 DevOps 则负责 AgentCore 基础设施的稳定性。然而，这种高韧性也带来了新的成本复杂度，企业需精细平衡监控频率与模型推理成本，避免在低流量应用上过度使用高算力资源。
适用边界
该结论不适用于对实时性要求极高（如毫秒级延迟监控）或网络环境极度受限的场景。由于每个会话运行在独立的 Firecracker 微虚拟机中且需加载完整浏览器，单次旅程耗时固定为分钟级，无法替代传统的轻量级健康检查探针。此外，该方案强烈依赖 AWS 生态内的 EventBridge、SNS、CloudWatch 及 Secrets Manager 服务，对于混合云架构或非 AWS 基础设施环境，迁移成本与集成难度将大幅上升，并非即插即用方案。
孤本观察
编辑观察到，AWS 将“监控”重新定义为“代理行为”，通过隔离的虚拟机内存清洗机制从架构层面解决了状态污染问题，但这也意味着监控成本与计算资源呈线性刚性关联，难以像传统脚本那样通过缓存优化降低成本。
常见问题
该方案采用什么技术替代传统DOM定位器，其早期企业案例的关键工作流准确率是多少？
采用多模态大语言模型处理UI截图，早期企业案例显示关键工作流准确率超过90%。
典型的六步用户旅程执行耗时是多少？部署前需用什么工具打包代码并推送镜像？
耗时为2至4分钟，取决于页面加载速度；部署前需通过Nova Act CLI打包代码并推送镜像至Amazon ECR。
每5分钟运行一次六步电子商务旅程的月均调用次数及Nova Act操作次数是多少？
月均产生8,640次调用及约207,360次Nova Act操作，涵盖推理、浏览器会话等五个计费组件。
AgentCore Runtime采用什么隔离模型，以及默认在何时执行完整内存清洗？
采用“一会话-一微虚拟机”隔离模型，默认在会话结束时执行完整内存清洗，防止Cookie和缓存泄露。
该方案单次旅程耗时为何无法替代传统轻量级健康检查探针？
因为每个会话运行在独立Firecracker微虚拟机中且需加载完整浏览器，单次旅程耗时固定为分钟级。