用 Bedrock AgentCore Browser Tool 自动化遗留 Web 系统

医疗、制造、零售和金融服务业的企业在自动化遗留 Web 应用方面面临挑战——这些应用需要类人交互，而标准 RPA 在规模化时无法提供。Amazon Bedrock AgentCore Browser Tool 与 Strands Agents 相结合，通过完全托管的浏览器服务填补了这一空白，让 AI 智能体能够在安全隔离的会话中驱动这些遗留界面。由于大多数企业仍在关键工作负载上运行遗留技术，且这些系统大多只暴露由服务端中间件渲染的 HTML 而非现代 API，大规模手动数据录入仍是主要成本中心，也是数字化转型的障碍。

以各行业企业熟悉的一个场景为例：一家大型保险公司每年处理数万笔遗留保单管理系统中的运营变更，包括计划修改、理赔调整、保险范围更新和背书。由于需要配备专人通过复杂 Web 界面操作服务端中间件生成的遗留保单系统，该组织仅手动错误每年就造成重大损失。每项变更都需要浏览多步工作流、在多个屏幕中录入数据，并依据业务规则进行验证。这些任务消耗了数千小时。这一模式在各行业反复出现——只要遗留 Web 应用仍是关键业务运营的支柱。

Amazon Bedrock AgentCore Browser Tool 通过提供完全托管的云端浏览器服务来解决这些限制，AI 智能体通过安全隔离的浏览器会话与遗留 Web 界面交互。Browser Tool 通过基于 WebSocket 的 Chrome DevTools Protocol（CDP）连接集成 Playwright，使 AI 智能体能够与任何技术栈的遗留 Web 应用交互。Browser Tool 在云端运行托管的 Chromium 实例。目标遗留应用只需可通过 HTTP 或 HTTPS 访问，无需考虑其最初针对哪种浏览器设计。

结合用于模型驱动编排的 Strands Agents，组织可以实施从单步自动化到复杂多智能体工作流的精细自动化工作流。该解决方案通过 Amazon Bedrock AgentCore 运行时与 Amazon Bedrock 基础模型（FM）集成，提供基于 AWS Identity and Access Management（IAM）控制的会话隔离安全性和完整审计跟踪。这可以帮助公司在支持监管合规要求并保留人工监督的同时，实现关键工作流的现代化。

在本文中，我们将详细介绍基于 Amazon Bedrock AgentCore Browser Tool 和 Strands Agents 构建的 AI 驱动数字员工的参考实现。我们将涵盖架构、关键设计决策以及使用 Terraform 部署的企业蓝图。完整源代码可在 GitHub 上获取。

理解业务和技术挑战

企业 RPA 实现通常面临三个传统自动化方法难以解决的技术挑战：遗留 Web 应用集成复杂性、受监管行业的监管合规要求，以及阻碍成功生产部署的可扩展性限制。

遗留 Web 应用的复杂性

回到我们的保险公司场景，保单管理系统与各行业的许多遗留应用一样，是数十年前建立在服务端中间件上的，为浏览器生成 HTML、CSS 和 JavaScript。这些系统缺乏现代 REST API，要求自动化解决方案通过最初为人类用户设计的 Web 界面进行交互。这些应用具有传统 RPA 机器人无法可靠浏览的复杂多步工作流、动态表单验证和会话相关状态管理。经历数十年修改后的文档缺口带来了额外的复杂性，关键业务逻辑仅存在于机构知识中，而非可访问的系统规范中。

身份验证机制使问题更加复杂。一些遗留应用需要多因素身份验证（MFA），一些使用专有单点登录（SSO），许多依赖会话令牌且过期规则不可预测。基于规则的 RPA 机器人在此举步维艰，这就是为什么生产部署最终存在大量手动干预的长尾。在我们的保险场景中，操作员需要浏览复杂的 Web 界面来进行计划修改。他们更新保险金额、调整受益人、处理背书，每项操作都需要多个屏幕和验证步骤——当 UI 渲染与预期不同时，基于规则的脆弱机器人无法可靠处理这些操作。

合规与审计要求

受监管行业必须实施全面的审计跟踪，捕获用户身份、时间戳、数据修改和系统交互，以满足 GDPR、HIPAA 和金融法规要求。技术实现需要不可变日志系统、加密数据传输，以及传统 RPA 系统无法在不进行大量定制开发的情况下提供的基于角色的访问控制。金融法规要求保留六年防篡改记录，且最近 90 天必须可立即访问。这些要求需要大多数 RPA 系统缺乏的复杂日志架构。

在此场景中，每项保单修改都必须可追溯。这意味着要捕获谁发起变更、变更了什么、何时变更，以及是否经过审批。AI 驱动的数字员工必须提供与人工操作员同等甚至更高的可审计性。

可扩展性与脆弱性

传统 RPA 解决方案面临阻碍企业级成功的根本架构约束。基于 UI 的自动化对屏幕布局、元素定位和应用计时的依赖非常脆弱，微小的系统更新就会导致失败。传统 RPA 的基于规则特性无法处理复杂业务流程所需的异常、动态内容或认知决策。性能限制加剧了这些问题。传统 RPA 机器人需要专用虚拟机或物理系统，造成资源开销和扩展约束。会话管理在处理多个并发流程时变得复杂，错误恢复机制仅限于预定义场景而非自适应问题解决。

对于我们的保险公司而言，该组织每年处理数万项计划变更。将传统 RPA 扩展到处理高峰期（如注册期、监管变更、年终处理）的海量请求同时保持可靠性，被证明是不切实际的。该组织需要一种能够弹性扩展并在页面以意外状态渲染时智能恢复的方法。

解决方案架构

应对这些挑战需要能够处理 JavaScript 重度 Web 界面、在流程之间隔离会话、通过 API 暴露编程控制、不可变记录每次交互、在置信度低时向人求助、以及弹性扩展的自动化。该参考实现通过一组职责范围明确的少量组件来满足这些要求。这些组件包括：面向操作员的 React 单页应用、解决特定浏览器限制的 TLS 终止代理、在 Amazon Bedrock AgentCore 运行时上运行 Strands Agents 的 Python Worker，以及 Amazon Bedrock AgentCore Browser Tool 提供的托管浏览器环境。Amazon Cognito 为操作员签名登录并颁发流经整个技术栈的 JWT。该架构旨在帮助提高自动化投资回报率，同时保持安全性、合规性和人工监督。

图 1：解决方案架构

图中的编号步骤追踪了端到端流程：

1. 加载 UI。用户浏览器从 Amazon CloudFront 加载 React 聊天界面，后端是托管静态 UI 资产的个人 Amazon Simple Storage Service（Amazon S3）存储桶。

2. OIDC 登录。用户通过 Amazon Cognito（配置了 SPA 和机器对机器应用客户端）通过标准 OpenID Connect（OIDC）登录流程进行身份验证。

3. WSS。浏览器通过 AWS Application Load Balancer（ALB）打开 WebSocket 连接，ALB 使用 AWS Certificate Manager（ACM）证书终止 TLS。

4. 纯 HTTP。ALB 将 WebSocket 连接转发到在私有子网中作为 AWS Fargate 任务运行的 NGINX 反向代理。代理从查询字符串中提取 JWT 并为其下一跳做准备。

WSS Auth Bearer。NGINX 代理将连接连同 JWT 一起通过 Authorization 头转发给 Amazon Bedrock AgentCore 运行时。AgentCore 运行时通过其 JWT 授权器验证令牌，并路由到运行 Strands Agents、VisualBrowserTool 和人在环（human-in-the-loop）处理器的浏览器代理容器。

InvokeModel。代理调用 Amazon Bedrock 上支持视觉的基础模型来分析截图并确定下一个浏览器操作。

CDP / WSS (Playwright)。代理通过 Chrome DevTools Protocol 在 Amazon Bedrock AgentCore Browser Tool 上驱动隔离的 Chrome 实例。浏览器在客户网络内导航目标遗留 Web 应用程序。

PutObject。代理将会话记录和截图存储到 Amazon S3 存储桶，为每个截图生成预签名 URL，并通过现有 WebSocket 连接将 URL 流式传输回用户浏览器。

Pre-Signed URL Get。用户浏览器使用预签名 URL 直接从 S3 获取截图图像，在聊天界面中与代理的推理轨迹一起渲染。图像字节不通过 WebSocket 传输，只传输短寿命 URL。

支持基础设施包括 Amazon Elastic Container Registry (Amazon ECR)（托管 NGINX 网关和浏览器代理容器镜像）和 Amazon CloudWatch（审计日志和可观测性）。

AgentCore Browser Tool

Amazon Bedrock AgentCore Browser Tool 提供完全托管的基于云的浏览器服务。AI 智能体通过安全、隔离的浏览器会话与遗留 Web 界面交互。每个会话在独立的环境中运行，拥有自己的 CPU、内存和文件系统。当会话完成时，环境被终止，状态被清理。

智能体通过基于 WebSocket 的 CDP 连接 Playwright，对 Web 应用程序进行编程控制，包括 JavaScript 重度界面、动态表单和多步骤工作流，无论底层技术栈是什么。

三个能力直接解决了前面描述的挑战：

浏览器配置文件跨会话持久化认证状态。进行一次认证，或让人工操作员通过实时视图执行初始登录，随后的会话将恢复已登录状态，减轻重复的 SSO 和 MFA 流程。

代理配置通过域路由和 AWS Secrets Manager 上的凭据将流量路由到企业代理基础设施，使企业网络后方或 IP 白名单门户背后的内部遗留应用程序可访问。

会话录制捕获浏览器交互，包括点击、表单输入和页面导航，并存储到 Amazon S3。结合 AWS CloudTrail 日志记录，这支持金融法规的审计跟踪要求。

回到我们的保险示例，Browser Tool 像人工操作员一样导航策略管理系统。它使用配置文件持久化的会话状态登录，跨多个屏幕输入修改，并提交更改，所有操作都在一个产生完整、可回放的审计记录的安全隔离会话中完成。

Amazon Bedrock 基础模型和 Strands Agents 编排

Amazon Bedrock 提供驱动代理决策循环的多模态基础模型。参考实现使用 Amazon Bedrock 上支持视觉的基础模型，通过跨区域推理来分析浏览器当前状态的截图，并决定下一步采取什么行动。这是使解决方案区别于传统 RPA 的核心能力。模型查看页面，推理屏幕上的内容，确定下一个浏览器操作，无论是点击、填写、滚动还是暂停等待人工确认。

Strands Agents 是将模型决策转化为具体工具调用的编排框架。模型不是遵循固定脚本，而是通过 ReAct（Reason + Act）循环驱动自己的行为。模型捕获截图，从视觉上分析页面，决定调用哪个工具，执行它，观察结果，然后重复。该框架支持多种编排模式，包括用于分层委托的 Agents-as-Tools、用于结构化工作流的 Graphs，以及用于复杂多步骤流程的协作模式。

当操作员提供自然语言指令（如"打开策略 #12345，将保额更新为 500,000 美元，并提交审批"）时，模型将这些分解为顺序的浏览器操作。每个操作之后，模型拍摄截图，从视觉上解释新页面状态，并决定下一步。如果出现意外确认对话框或字段验证与预期不同，模型会推理新状态而不是失败。这减轻了使传统 RPA 无法大规模运行脆弱性。

应用于我们的保险场景，一条自然语言指令可以驱动完整的计划修改工作流。模型直观地导航到正确的策略，从截图中识别表单字段，跨多个屏幕输入更改，处理意外的验证提示，并提交审批。无需人工编写每个步骤的脚本或随着 UI 演变维护脆弱的选择器。

人在环集成

操作员实时查看自动化过程。代理将推理轨迹和截图流式传输到聊天界面。当模型确定需要人工输入时——例如在提交更改之前确认打开了正确的策略——它调用 handoff_to_user 工具，这会暂停自动化，并向操作员展示问题及当前截图。

浏览器会话在代理等待响应时保持活动状态（默认最长 300 秒）。操作员可以批准、拒绝、提供额外指令，或要求代理尝试不同方法。收到响应后，模型使用操作员的输入恢复 ReAct 循环。它拍摄新截图以评估当前状态，并从那里继续。如果操作员在超时窗口内未响应，模型决定是重试、尝试替代方案还是正常中止。

在我们的保险工作流中，这意味着数字工作者在关键操作之前暂停，例如提交计划修改、确认受益人更改或处理超过阈值的批单。这让操作员有机会在更改永久生效之前在屏幕上验证准确性。操作员保持控制权，而无需手动驱动每个步骤。

安全与合规

该架构提供会话隔离、IAM 访问控制，以及每次使用后状态被清除的临时会话。参考实现使用 Amazon Cognito 作为身份提供者，通过交换 OIDC 发现 URL 支持 Microsoft Entra ID 和 Okta。符合标准 OIDC 提供者使用相同的配置界面。

对于我们的保险公司，这意味着数字工作者执行的每个策略修改都是完全可追踪的，会话录制存储在 Amazon S3 中，操作通过 Amazon CloudWatch 记录。这支持金融法规的保留要求。

实现演练

参考实现作为基于 Strands Agents 构建的 Python 工作线程提供，部署在 Amazon Bedrock AgentCore 运行时上。代理使用 AgentCore Browser Tool SDK 通过 Strands AgentCoreBrowser 基类创建隔离的浏览器会话。完整源代码可在 GitHub 仓库中获取。

代理如何驱动浏览器

下图追踪单个操作员指令通过完整自动化循环的过程。操作员发出自然语言命令，代理启动浏览器会话，基础模型进入 ReAct 循环。它捕获截图，从视觉上分析页面状态，决定下一步操作，通过 Playwright 执行它，然后重复，直到任务完成。

图 2：从操作员指令到 ReAct 循环的聊天流程

当模型确定在提交表单或确认记录选择等关键步骤之前需要人工确认时，它会暂停自动化，并向操作员展示当前截图和问题。操作员响应后，模型恢复。

图 3：人在环，代理暂停等待操作员决策

有两个实现选择值得特别指出，因为它们直接影响生产可靠性：

Event loop 隔离。浏览器智能体与一个 WebSocket 服务器并行运行，后者向操作员推送更新。上游浏览器工具的线程模型会干扰服务器的事件循环，导致连接约 15 秒后断开。参考实现覆盖了这一行为，让浏览器操作运行在独立的隔离循环上，使操作员的连接在整个会话期间保持稳定。完整实现见 visual_browser_tool.py。

语义定位器替代 CSS 选择器。传统 RPA 机器人当 UI 元素移动或重命名就会崩溃。semantic_action 工具采用了一种不同的方式：模型描述它所看到的内容（"点击标有 Submit 的按钮"），工具再借助大小写不敏感的模糊匹配将其映射到 Playwright 的语义 Locator API。这使得自动化能够应对传统应用程序中常见的小幅 UI 变化。这正是该解决方案要解决的脆弱性问题。完整实现见 semantic_action_tool.py。

部署与测试

整个解决方案通过一个 Terraform 栈完成部署。以下步骤将带你从 git clone 到一个可用的聊天 URL。

你需要准备以下条件：

一个 AWS 账户，已为支持视觉的基础模型启用 Amazon Bedrock 模型访问。

已配置凭证的 AWS Command Line Interface（AWS CLI）v2。

git clone <repo-url> && cd <repo>
cp deployment/terraform/stacks/all/terraform.tfvars.sample \
deployment/terraform/stacks/all/terraform.tfvars
# Edit terraform.tfvars - set aws_region, project_name, cognito_domain_prefix

terraform -chdir=deployment/terraform/stacks/all init
terraform -chdir=deployment/terraform/stacks/all apply

该栈配置了 Cognito User Pool、CloudFront 分发、ECR 仓库、ECS 代理服务、带 JWT 授权器的 AgentCore 运行时，以及 S3 会话存储。Terraform provisioner 构建并推送两个容器镜像、编译 React UI、同步到 S3 并使 CloudFront 失效，全部一步完成。首次 apply 约需 20–30 分钟，其中大部分时间是 CloudFront 传播和容器镜像构建。

部署完成后，Terraform 输出 CloudFront URL。在浏览器中打开它，使用 Cognito 用户登录，然后尝试如下提示词：

"Open https://httpbin.org/forms/post, fill the customer name with John Smith, pick medium pizza, check bacon topping, and submit the form."

你应该会看到推理过程流入聊天，每个步骤旁边出现截图，并在最终提交前出现人工介入提示。关于更多测试场景、示例提示词以及 UI 实际运行截图，请参阅仓库 README。

为避免持续产生费用，完成后请销毁基础设施：

terraform -chdir=deployment/terraform/stacks/all destroy

这将移除已配置的资源，包括 Cognito User Pool、CloudFront 分发、ECR 仓库、ECS 服务、AgentCore 运行时和 S3 存储桶。

结论与后续步骤

本文描述的 AI 驱动的数字工作者使上述目标变得可实现。传统 RPA 因耦合到精确的 UI 布局而脆弱，而 Amazon Bedrock 中支持视觉的基础模型、Strands Agents 的模型驱动编排，以及 AgentCore Browser Tool 的隔离浏览器会话相结合，产生了能够推理页面状态、从意外分支中恢复、在置信度低时求助于人类的自动化。整个过程不牺牲监管行业所需的审计跟踪。

参考实现留有扩展空间。如果你的工作流需要跨会话上下文，Amazon Bedrock AgentCore memory 提供了托管的短期和长期召回能力。如果需要将现有 REST API 作为工具集成，使智能体能够在其浏览器操作旁边调用，Amazon Bedrock AgentCore Gateway 无需编写自定义 Strands 工具即可处理。对于需要自定义浏览器行为的门户，可以在创建时将 Chrome 扩展加载到 AgentCore Browser Tool 会话中。完整源代码可在 GitHub 上获取。