Epsilon 如何用 Amazon Nova Act 构建意图驱动的 UI 测试

为了在其产品团队中大规模推广意图驱动的 UI 测试，Epsilon 选择了 Amazon Nova Act。Epsilon 是一家数据、技术和营销服务公司，隶属于 Publicis Groupe。Epsilon 拥有数亿消费者画像和数千个品牌关系，因此需要能够跟上应用快速变化的 UI 测试。该解决方案不能给每个产品团队带来维护开销。

在 Epsilon 内部，Agentic Platform 团队（50 名工程师）构建共享基础设施，使其他产品团队能够安全地构建、部署、治理和运行 AI 代理。借助这一共享平台，团队可以获得基于技能的代理构建器。他们还能获得联合身份和预检授权、模型上下文协议（MCP）集成以及跨账户配置。当产品团队想要采用 AI 工具时，他们无需额外配置即可获得相应能力，也无需自行重新解决身份、安全、浏览器基础设施或模型集成问题。

其中一项托管能力是UI 测试。借助 Amazon Nova Act 和 Amazon Bedrock AgentCore Browser（Amazon Bedrock AgentCore 的一项能力），Epsilon 的平台团队能够以服务形式向平台上的团队提供弹性、意图驱动的测试。

在本文中，我们将介绍 Epsilon 将 UI 测试作为托管平台服务交付的架构，展示 Nova Act 与 Amazon Bedrock AgentCore Browser Tool 的核心集成代码，重点介绍一个具体的 18 步测试工作流，并分享最佳实践和实测结果。

挑战：提升覆盖率，而非取代行之有效的方案

Epsilon 现有的 UI 测试实践并没有问题。该团队维护着一套基于 Playwright 的回归测试套件，用于验证其 Web 应用的功能，并且运行良好。Playwright 至今仍是他们的回归测试骨干。

Epsilon 发现的机会是增量式的，而非纠错式的：

脚本化的 Playwright 测试对于确定性的回归检查很有效。然而，它们与选择器和页面结构紧密耦合。即使底层功能完好，外观性的 UI 变更也可能导致测试失败。
多个产品团队需要针对各自应用实现完整的测试覆盖。为每个团队搭建浏览器基础设施、管理依赖项并集成身份系统，会造成重复工作。
平台团队希望 UI 测试成为一项托管能力，契合他们现有的代理模型，而不是一个每个新加入团队都必须操作的定制 CLI。

目标是：在现有 Playwright 回归测试套件之上叠加基于意图的测试。将其作为多租户平台服务交付，使每个 Epsilon 产品团队都能通过他们用于其他所有代理能力的同一 API 接口来使用。

Epsilon 为何选择 Amazon Nova Act 和 Amazon Bedrock AgentCore Browser Tool

Epsilon 根据两项要求评估了各种方案：自然语言测试编写（以补充基于选择器的 Playwright 测试）和托管浏览器基础设施（以契合其多租户平台模型）。通过将 Amazon Nova Act 与 Amazon Bedrock AgentCore Browser Tool 相结合，Epsilon 能够同时满足这两项要求。

自然语言步骤。测试步骤是由 Nova Act 执行的纯英文指令。它们对界面外观变化具有韧性，且非工程师也能读懂。像“确认奖励余额可见”这样的步骤，比脆弱的 CSS 选择器经久耐用得多。
AWS 托管、临时的浏览器会话。借助 Amazon Bedrock AgentCore Browser Tool，团队可获得隔离的浏览器实例，无需分发二进制文件，也无需维护显示服务器。Amazon Bedrock AgentCore Browser Tool 还提供实时视图，供人工观察或接管（适用于 CAPTCHA 或多因素认证）、将会话录制到 Amazon Simple Storage Service（Amazon S3），以及 AWS CloudTrail 审计，所有这些都无需额外配置。
基于 AWS Identity and Access Management（AWS IAM）的认证。借助 Nova Act，你可以通过标准 AWS 凭证链（任务角色）进行认证。这契合 Epsilon 现有的安全模型，无需分发单独的 API 密钥。
跨账户友好。借助 Nova Act 和 Amazon Bedrock AgentCore Browser Tool，你可以接入现有的 AWS Security Token Service（AWS STS）AssumeRole 配置。每个接入的团队都可以在受限角色下，在自己的 AWS 账户内运行测试。这保持了隔离性和可审计性。

Epsilon 选择 Amazon Bedrock AgentCore Browser Tool，正是因为它消除了管理浏览器二进制文件、显示服务器和会话生命周期的运维负担。Agentic Platform 团队无意承担这些基础设施。

解决方案：架构与实现

Epsilon 的解决方案包含三个主要组件：用于创建工作流的平台 API、用于执行工作流的后台任务运行器，以及驱动浏览器的 Nova Act 与 Amazon Bedrock AgentCore Browser Tool 集成。

平台架构

Epsilon 的 UI 测试能力遵循一条清晰的流水线：

用户通过平台 API 创建工作流，指定一个 target_url 和一组自然语言步骤。
创建时，平台在 AWS 上注册一个 Nova Act 工作流定义。
执行时，后台任务运行器（Celery，一个用于异步作业处理的 Python 框架）打开一个 Amazon Bedrock AgentCore Browser Tool 浏览器会话。它通过 Chrome DevTools Protocol（CDP） WebSocket（以编程方式控制 Chromium 浏览器的标准接口）让 Nova Act 运行每个步骤，包括条件逻辑（例如，“如果出现导览框，就跳过它”）。
系统为每个步骤截取屏幕截图，跟踪每个步骤的通过/失败情况，计算总体通过率，并存储所有内容（结果 JSON、Amazon S3 中的截图、会话 ID）。
触发完成钩子，以便将结果记录回平台。

图 1：Epsilon 的 UI 测试服务架构

图 1 展示了 Epsilon UI Testing Service 的分层架构。用户请求从 Agent Cloud Frontend 流出，经过带有身份验证和权限检查的 API Gateway。API 层（Django REST）暴露了工作流、执行、自动化套件和统计的端点。业务逻辑层包括 Workflow Manager、Execution Orchestrator 和 Suite Coordinator。测试作业在 Amazon Simple Queue Service（Amazon SQS）中排队，并由运行在 Amazon Elastic Container Service（Amazon ECS）上的 Runner Service 拾取，该服务包含 Nova Act 引擎和无头 Chromium 浏览器。结果、截图、轨迹和 HTML 报告存储在 Amazon S3 中。

该能力以标准 agent（ui-test-agent）的形式暴露，包含两项技能：

ui-test-recorder：以交互方式探索场景并记录自然语言步骤。
ui-test-executor：运行已记录的步骤并返回结构化结果。

已接入的团队使用 UI 测试的方式与他们使用任何其他平台 agent 的方式相同。无需管理额外的基础设施。接入过程很直接。平台团队为新团队配置跨账户 IAM 角色，注册其目标应用程序 URL，并通过现有平台 API 授予对 ui-test-agent 的访问权限。从那时起，团队通过他们已用于其他平台能力的同一接口创建工作流、触发执行并检索结果。

核心集成

Nova Act + Amazon Bedrock AgentCore Browser Tool 集成非常简洁：

import boto3
from bedrock_agentcore.tools.browser_client import browser_session
from nova_act import NovaAct

boto_session = boto3.Session(region_name=region)

with browser_session(region) as client:
    ws_url, headers = client.generate_ws_headers()
    with NovaAct(
        cdp_endpoint_url=ws_url,
        cdp_headers=headers,
        boto_session=boto_session,
        starting_page=url
    ) as nova_act:
        result = nova_act.act(instruction)

这种模式（打开托管浏览器会话、通过 CDP WebSocket 连接、用自然语言驱动操作）是基础。Epsilon 用其平台的多租户编排、结果捕获和可观测性层对其进行了封装。

示例：自动化“Create an agent”流程

为了说明基于意图的测试，这里给出 Epsilon 平台的一个代表性工作流。它演练了登录、表单输入、条件处理、滚动和验证。以下步骤突出了 Nova Act 的差异化模式：

步骤	指令
1	输入用户名并选择 Next
2	输入密码并选择 Verify
3	导航到 Create Agent 并选择 Design a new specification 卡片
4	如果出现入门导览框，选择 Skip Tour，然后验证加载了正确的页面
5	填写 agent 名称和描述字段
6	向下滚动直到 Goal Statement 字段可见，然后填写它
7	如果技能搜索框不可见，滚动直到它出现。然后搜索并添加一项技能
8	选择 Save，确认成功提示，导航返回，并验证新 agent 出现在列表中

步骤 4 和 7 演示了条件逻辑：“如果某个元素出现，就处理它”以及“如果目标不可见，就滚动直到它可见。”这些模式在传统框架中需要显式分支。Nova Act 通过语言理解自然地处理它们。

运行时隔离

Epsilon 在一个专用运行器服务（FastAPI sidecar）中运行 UI 测试，该服务固定使用支持 Workflow 和 IAM 身份验证的 nova-act 3.x，以及 Amazon Bedrock AgentCore Browser Tool 客户端。这样可将依赖与主后端分离，避免与 Strands agent 技术栈发生冲突。如果运行器被禁用，worker 会回退到进程内执行，从而在部署期间提供弹性。

最佳实践

基于将 UI 测试构建为平台能力的经验，Epsilon 团队建议：

1. 将步骤编写为意图，而非机械操作

GOOD: "Confirm the rewards balance is visible"
BAD: await page.locator('#rewards-balance-container > span.amount').toBeVisible()

基于意图的步骤能够在 UI 重新设计后继续使用。可能不编写代码的产品经理和质量保证（QA）负责人可以直接审查这些步骤。

2. 隔离 Nova Act 运行时

将 Nova Act 和 Amazon Bedrock AgentCore Browser Tool 的依赖固定在一个专用服务或容器中。Epsilon 了解到，无论浏览器会话位于哪个区域，Nova Act 的签名端点都指向 us-east-1。将其运行在具有独立依赖锁定文件的单独服务中，可防止难以调试的冲突。

3. 复用录制的轨迹以降低成本

Epsilon 在草稿状态下使用轨迹重试，保存成功的轨迹，并在活动状态下重放它。重复运行会跳过冗余的大语言模型（LLM）“思考”，从而降低回归式重复执行的延迟和成本。

4. 从第一天起就为多租户设计

使用带作用域 IAM 策略的跨账户 AssumeRole。每个租户的测试都在其自己的账户中、以其自己的角色运行。这提供了隔离性、可审计性和故障范围控制，而无需为每个团队构建自定义基础设施。

5. 依托托管可观测性

借助 Amazon Bedrock AgentCore Browser Tool，团队可以获得实时视图、会话录制和 AWS CloudTrail 集成。Epsilon 使用这些内置能力，而不是构建自定义可观测性，从而减少维护工作，并为合规团队提供熟悉的审计界面。

6. 考虑 Amazon Bedrock AgentCore Browser Tool 的视口行为

在提示 Nova Act 步骤时，要考虑 Amazon Bedrock AgentCore Browser Tool 的浏览器视口默认值。涉及滚动的步骤（例如“向下滚动直到 Goal Statement 文本框可见”）会验证 Nova Act 是否正确处理页面下部的内容。

结果与影响

Epsilon 的 UI 测试能力已在多个团队中投入运行，多租户架构已在生产环境中得到验证。

维度	Amazon Nova Act	Playwright（等效）
编写行数	18 个自然语言步骤	约 80-150 行代码
选择器/DOM 检查	无	每个交互步骤都需要
编写时间（每个工作流）	约 5-10 分钟	约 30-90 分钟
工作量比率	基准	工作量多 4-6 倍

以下是实测结果：

测试编写速度提升 4-6 倍（基于 Epsilon 的内部基准测试）。一个具有代表性的 18 步工作流使用 Nova Act 编写耗时 5–10 分钟，而等效的 Playwright 脚本（80–150 行代码）则需要 30–90 分钟。Playwright 脚本中的每个交互步骤都需要检查 DOM、选择稳定的选择器，并为条件情况编写显式等待、断言和分支。Nova Act 用 18 条自然语言指令和零选择器或 DOM 检查取代了这种逐步开销，条件逻辑（例如 tour-box 和滚动直到可见的步骤）用通俗英语表达。
轨迹回放的通过率达到 100%（基于 Epsilon 的内部 基准测试）。 工作流通过初始探索阶段（通常为 4–5 次提示词迭代）后，Epsilon 会保存成功的轨迹并以确定性方式回放。保存的轨迹在重复运行中均达到 100% 的通过率。
降低测试编写的门槛。 步骤读起来就像通俗英语。核心测试工程师之外的团队成员也能阅读、审查并提出测试，从而扩大质量的责任归属。
内置审计追踪。 AWS CloudTrail 集成和 Amazon Bedrock AgentCore Browser Tool 会话录制让调试和合规沟通变得更加容易。这是团队最初并未打算实现的一项收益。
每个团队零基础设施开销。 接入的团队通过与其他所有平台代理相同的 API 接口获得 UI 测试能力。无需浏览器二进制文件，无需 Selenium grid，无需管理显示服务器。
每个步骤的通过/失败可见性。 每个步骤的截图捕获提供细粒度的调试上下文，缩短诊断失败的平均时间。

“Nova Act 让我们将 UI 测试从一项脆弱、追逐选择器的苦差事转变为一项受管理的平台能力。我们的测试现在用通俗英语描述意图，在 AWS 托管浏览器上运行，我们接入的每个产品团队都能获得可靠的测试，而无需额外配置。”

— Epsilon Agentic Platform 团队

了解更多

Epsilon 的 Agentic Platform 团队演示了如何使用 Amazon Nova Act 和 Amazon Bedrock AgentCore Browser Tool 将弹性、意图驱动的 UI 测试作为托管服务交付。你可以将同样的模式应用到自己的多租户平台，以消除浏览器基础设施开销，并让非工程师也能编写测试。

如果你想使用 Amazon Nova Act 和 Amazon Bedrock AgentCore Browser Tool 构建类似的意图驱动 UI 测试能力，以下资源可供入门：

要了解更多关于你的组织如何使用基于意图的浏览器自动化进行测试的信息，请访问 Amazon Nova Act 产品页面。

Epsilon 是 Publicis Groupe 旗下公司。了解更多请访问 epsilon.com。

关于作者

Sakthivel Chellapparimanam

Sakthivel 是 Amazon Web Services 驻印度金奈的解决方案架构师。他与企业客户合作，推进 AI/ML 采用、代理式架构和云原生现代化。

Sidhartha Kotha

Sidhartha 是 AWS 的技术客户经理。他与企业客户合作开发 AI 驱动的解决方案，专注于采用生成式 AI 提升运营效率。工作之余，他喜欢探索开源自动化框架并指导有志成为云工程师的人。

Manik Sahu

Manik 是 Epsilon 的高级软件工程经理，专长于数据工程、代理式 AI 和云架构。他常驻班加罗尔，在使用 FastAPI、Amazon Bedrock 和 LangGraph 等框架设计高级技术系统方面拥有丰富经验。

Swastika Sinha

Swastika 是 Epsilon 的一名软件工程师，在印度班加罗尔的 Agentic Platform 团队工作。她的工作重点是架构和构建生成式 AI 平台与服务，以支持构建和托管 AI 智能体、知识图谱、MCP 服务器、智能体工作流以及其他下一代 GenAI 技术。

Sekh Mohammad Warish

Sekh 是 AWS 驻达拉斯的高级技术客户经理，拥有 22 年 IT 经验，涵盖 GenAI、SAP 和云现代化领域。他帮助企业客户采用智能体 AI 和 Amazon Nova 等新兴技术，并将其转化为可投入生产的解决方案。他拥有最多 IT 认证的世界纪录和印度纪录，将终身学习的热情带入每一次合作。

Sudeesh Veetti

Sudeesh Veettil

Sudeesh 是 AWS 驻德克萨斯州达拉斯地区的高级技术客户经理，在科技行业拥有超过 20 年的经验。他帮助企业客户在 AWS 上设计、构建和运营安全、弹性且高效的解决方案，专长于 AI 工作负载的运营卓越和弹性工程。