Bedrock AgentCore Browser Tool 浏览器工具上手使用

一、什么是 AgentCore Browser Tool

Amazon Bedrock AgentCore Browser Tool（浏览器工具）是 AgentCore 提供的内置工具之一，它为 AI Agent 提供一个安全、隔离的云端托管 Chrome 浏览器环境。Agent 可以像人类用户一样在这个浏览器中导航网站、点击按钮、填写表单、解析动态内容，从而完成传统 API 无法覆盖的网页交互任务。需要说明的是，业界常提到的 Computer Use 通常指 Anthropic 模型直接操作屏幕的能力，其操作范围是电脑本机，而 AgentCore Browser Tool 是 AWS 提供的托管浏览器服务，操作范围限制浏览器且是云端沙盒方式运行，二者属于不同层面的产品，本文介绍 AgentCore Browser Tool 的使用。

Browser Tool 的核心能力包括以下几点：

会话隔离：每个浏览器会话运行在独立的容器化环境中，网页活动与本地系统完全隔离，支持多会话并发运行。会话默认超时为 15 分钟，最长可配置为 8 小时。
流式交互接口：会话启动后，通过基于 WebSocket 的 Automation 端点（CDP 协议）执行导航、点击、截图等浏览器动作，可配合 Strands Agents、Nova Act 或 Playwright 等框架简化开发。
内置可观测性：提供 Live View 实时观看浏览器画面，操作记录写入 CloudTrail，自定义浏览器还支持将会话录制（DOM 变更、用户动作、控制台日志、网络事件）存储到 S3 并在控制台回放。
无服务器架构：基础设施由 AWS 托管并自动扩缩，AWS 托管浏览器（aws.browser.v1）开箱即用，无需预先创建任何资源。

典型应用场景包括：网页信息提取与摘要（如本文示例中读取博客页面内容）、需要多步点击和表单填写的业务流程自动化、对没有开放 API 的遗留 Web 系统进行集成、以及电商比价和竞品监控等需要真实浏览器渲染的任务。

应用局限方面需要注意：Browser Tool 本身只提供浏览器运行环境，页面理解与操作决策依赖大语言模型，因此任务的成功率受模型能力影响，复杂页面可能需要多轮工具调用，产生相应的模型推理成本；会话有超时上限，不适合长期驻留的爬虫类任务；对于有验证码、强反爬机制或需要多因素登录的网站，自动化操作可能受阻；此外应遵守目标网站的服务条款，避免对生产站点造成压力。

下边开始配置。

二、配置 IAM Policy 和 Role

1、如何选择 AWS 托管浏览器和自定义浏览器

AWS 托管浏览器与自定义浏览器的主要差异如下：

对比项	AWS 托管浏览器	自定义浏览器
浏览器标识	使用 AWS 预置标识 `aws.browser.v1`	创建后由服务返回专属的 Browser ID 和 ARN
资源准备	无需预先创建浏览器资源，可以直接启动会话	需要通过 AgentCore 控制台、AWS CLI 或 AWS SDK 创建和管理浏览器资源
网络配置	使用 AWS 预置的托管网络环境，无需单独配置	创建时必须指定网络配置，可以选择 `PUBLIC` 或 `VPC` 模式
会话录制与回放	不支持 S3 会话录制与回放	可以启用会话录制，并将录制数据保存到指定的 S3 桶
Execution Role	无需为浏览器单独配置 Execution Role	`executionRoleArn` 本身为可选配置；浏览器需要访问 AWS 服务时使用，启用 S3 会话录制时必须配置相应权限
调用身份权限	运行代码的 IAM User 或 Role 需要具备启动会话、连接自动化流等 AgentCore Browser Tool 权限	除会话和数据流权限外，负责创建与管理资源的 IAM 身份还需要相应的 `CreateBrowser`、`GetBrowser`、`DeleteBrowser` 等权限
运维复杂度	AWS 负责浏览器资源管理，配置较少，适合快速验证和常规公共网页访问	需要维护浏览器、网络、Execution Role 和录制存储等配置，适合需要网络隔离、审计回放或精细化管理的生产场景

本文选用 AWS 托管浏览器（aws.browser.v1），因此无需创建自定义浏览器资源，也无需为浏览器配置 Execution Role，只需要为运行代码的 IAM 身份（User 或 Role）附加调用 AgentCore Browser Tool 和 Bedrock 模型的权限。仅当使用自定义浏览器并启用 S3 会话录制时，才必须额外创建具备 S3 写入权限的 Execution Role，本章第 3 节会作简要说明。

2、IAM Policy 创建

为运行测试代码的 IAM 身份附加如下内联策略（Inline policy）。在 IAM 控制台中找到对应的 User 或 Role，选择 Add permissions，然后选择 Create inline policy，切换到 JSON 视图并粘贴以下内容，注意替换里边的 <account-id> 为当前 AWS 账户的 12 位 ID。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "BedrockAgentCoreBrowserFullAccess",
            "Effect": "Allow",
            "Action": [
                "bedrock-agentcore:CreateBrowser",
                "bedrock-agentcore:ListBrowsers",
                "bedrock-agentcore:GetBrowser",
                "bedrock-agentcore:DeleteBrowser",
                "bedrock-agentcore:StartBrowserSession",
                "bedrock-agentcore:ListBrowserSessions",
                "bedrock-agentcore:GetBrowserSession",
                "bedrock-agentcore:StopBrowserSession",
                "bedrock-agentcore:UpdateBrowserStream",
                "bedrock-agentcore:ConnectBrowserAutomationStream",
                "bedrock-agentcore:ConnectBrowserLiveViewStream"
            ],
            "Resource": "arn:aws:bedrock-agentcore:us-west-2:<account-id>:browser/*"
        },
        {
            "Sid": "BedrockModelAccess",
            "Effect": "Allow",
            "Action": [
                "bedrock:InvokeModel",
                "bedrock:InvokeModelWithResponseStream"
            ],
            "Resource": "*"
        }
    ]
}

注意：将 <account-id> 替换为您的 AWS 账号 ID。本例区域为 us-west-2，如使用其他区域请同步修改 ARN。

另外，由于本文使用 Claude Sonnet 5 的全球（Global）跨区域推理配置，模型调用可能被路由到多个区域执行，因此 BedrockModelAccess 部分的 Resource 使用通配符以覆盖推理配置及各目的区域的基础模型；生产环境中建议按最小权限原则收敛到具体的 inference-profile 和 foundation-model ARN。

3、IAM Role 创建（仅自定义浏览器场景需要）

使用 AWS 托管浏览器时本节可以跳过。如果需要将浏览器会话录制到 S3 进行回放审计，则必须创建自定义浏览器（Custom Browser）并为其指定 Execution Role，该 Role 需要满足两个条件：

其一，附加允许写入录制目标 S3 桶的权限策略（注意替换其中的存储桶名称和 Prefix 路径）：

{
    "Sid": "BedrockAgentCoreBuiltInToolsS3Policy",
    "Effect": "Allow",
    "Action": [
        "s3:PutObject",
        "s3:ListMultipartUploadParts",
        "s3:AbortMultipartUpload"
    ],
    "Resource": "arn:aws:s3:::<your-bucket-name>/<your-prefix>/*"
}

其二，配置信任策略允许 AgentCore 服务代入该 Role（注意替换其中的 12 位数字格式的 AWS Account ID）：

{
    "Version": "2012-10-17",
    "Statement": [{
        "Sid": "BedrockAgentCoreBuiltInTools",
        "Effect": "Allow",
        "Principal": {
            "Service": "bedrock-agentcore.amazonaws.com"
        },
        "Action": "sts:AssumeRole",
        "Condition": {
            "StringEquals": {
                "aws:SourceAccount": "<account-id>"
            },
            "ArnLike": {
                "aws:SourceArn": "arn:aws:bedrock-agentcore:us-west-2:<account-id>:*"
            }
        }
    }]
}

权限准备就绪后，接下来编写并运行测试代码。

三、AgentCore Browser Tool 测试代码

1、场景和关键架构

本章使用 Python 构建一个包含网页导航、文章识别和图片分析的测试场景：调用浏览器访问 https://blog.bitipcman.com/，在首页找到并打开最新发布的一篇博客，阅读文章内容，然后判断文章中的网页截图是否使用红色标注框提示读者应当点击的位置，最终用中文返回判断结论和依据。

这个场景不仅要求 Agent 读取 DOM（Document Object Model，文档对象模型）内容，还可能需要分析文章图片，因此比单纯提取网页文本更能体现 AgentCore Browser Tool 的动态操作能力。需要注意，目标网站的“最新文章”会随时间变化，文章标题、图片数量、浏览器动作序列和模型回答均不是固定值。

本例的关键架构如下：、

Agent 框架采用 Strands Agents，浏览器工具采用 strands-agents-tools 提供的 AgentCoreBrowser。
浏览器使用 AWS 托管资源 aws.browser.v1，无需预先创建自定义浏览器。
运行区域为 us-west-2，模型使用 Claude Sonnet 5 的全球（Global）跨区域推理配置 global.anthropic.claude-sonnet-5。
AgentCoreBrowser 的 session_timeout 显式设置为 900 秒，用于在主动清理失效时限制空闲会话的最长保留时间。
BrowserActionLogger 通过 Strands Hook 监听 BeforeToolCallEvent，在每次调用 browser 工具前打印实际动作类型。
脚本默认启用主动回收：任务开始前记录已有的 READY 会话，任务结束后仅停止本次运行新产生的会话，避免直接清理测试环境中原有的共享会话。

整体执行流程如下：

记录任务开始前已有的 READY 会话
                │
                ▼
创建 Strands Agent 并挂载 browser 工具
                │
                ▼
模型自主执行导航、读取 DOM、截图或 JavaScript 分析
                │
                ▼
输出中文结论、token 用量、模型延迟和端到端耗时
                │
                ▼
关闭本地 Playwright/CDP 连接
                │
                ▼
停止本次任务新增的远端浏览器会话

其中，截图和图片像素分析不是脚本硬编码的固定步骤，而是模型根据当前网页内容自主选择的工具动作。当前脚本也不会把浏览器截图保存到本地 screenshots/ 目录。下面转向项目环境准备。

2、获取代码并使用 uv 初始化项目

本文使用 uv 管理 Python 版本、虚拟环境和依赖。仓库已经包含 pyproject.toml 与 uv.lock，因此克隆后不需要再次执行 uv init，直接按照锁文件同步环境即可。

执行如下命令获取代码并进入项目目录：

git clone git@github.com:aobao32/bedrock-agentcore-browser-tool-demo.git
cd bedrock-agentcore-browser-tool-demo

返回结果如下：

Cloning into 'bedrock-agentcore-browser-tool-demo'...

继续执行如下命令创建虚拟环境并按照 uv.lock 安装依赖：

uv sync --locked

本文环境中的实际返回结果如下：

Resolved 84 packages in 22ms
Checked 81 packages in 24ms

执行如下命令检查项目的直接依赖版本：

uv tree --depth 1 --locked

返回结果如下：

agentcore-browser-use v0.1.0
├── bedrock-agentcore v1.19.0
├── nest-asyncio v1.6.0
├── playwright v1.62.0
├── strands-agents v1.50.2
└── strands-agents-tools v0.8.5

注意：上述版本来自当前 uv.lock。如果修改 pyproject.toml 或重新解析锁文件，实际版本和包数量可能变化。脚本还直接导入了 Boto3，当前环境通过依赖树安装的版本为 1.43.62；生产项目应将直接导入的库显式声明为项目直接依赖，避免依赖其他软件包的传递依赖关系。环境准备完成后，下面解析当前测试脚本。

3、测试代码解析

测试脚本位于项目根目录的 browser_agent.py。当前实现不只包含 Agent 与浏览器工具的基础接线，还加入了动作日志、运行指标以及本地和远端资源清理。以下代码展示与业务场景直接相关的核心配置，完整实现以仓库中的 browser_agent.py 为准：

import json
import os
import time

import boto3
from strands import Agent
from strands.hooks import BeforeToolCallEvent, HookProvider, HookRegistry
from strands.models import BedrockModel
from strands_tools.browser import AgentCoreBrowser

# 下方仅展示核心配置；BrowserActionLogger 类、会话查询函数和清理函数的
# 完整实现请查看仓库中的 browser_agent.py。

REGION = "us-west-2"
MODEL_ID = "global.anthropic.claude-sonnet-5"
BROWSER_ID = "aws.browser.v1"

# 将空闲会话超时设置为 900 秒，限制主动清理失效时的资源占用时间。
browser_tool = AgentCoreBrowser(region=REGION, session_timeout=900)
model = BedrockModel(model_id=MODEL_ID, region_name=REGION)

agent = Agent(
    model=model,
    tools=[browser_tool.browser],
    hooks=[BrowserActionLogger()],
)

prompt = (
    "请使用浏览器完成以下任务："
    "1. 打开网页 https://blog.bitipcman.com/ ；"
    "2. 在首页上找到并点击最新一片博客；"
    "3. 阅读其中的内容，确认文章中使用的网页截图中，是否有红色标注框告知用户应该操作点击哪里"
    "请用中文回答。"
)

当前源码中的“最新一片博客”语义上是指“最新一篇博客”。该 Prompt 将任务目标交给模型，代码没有固定文章 URL、CSS 选择器或图片文件名，因此网站更新后仍会从首页重新识别最新文章。

browser 对 Agent 表现为一个工具，但工具内部通过 action 参数分发不同浏览器动作。以当前锁定的 strands-agents-tools 0.8.5 为例，脚本注释中记录了 22 种动作：

会话与标签页管理：init_session、list_local_sessions、new_tab、switch_tab、close_tab、list_tabs、close。
页面操作：navigate、click、type、press_key、back、forward、refresh。
内容读取与高级操作：get_text、get_html、screenshot、evaluate、get_cookies、set_cookies、network_intercept、execute_cdp。

动作数量与名称属于具体依赖版本的实现细节，升级 strands-agents-tools 后应以对应版本的工具定义为准。模型通常先通过 get_text 或 get_html 读取 DOM；当任务涉及网页截图时，模型还可能使用 screenshot 获取当前页面画面，或者通过 evaluate 在页面上下文执行 JavaScript，对图片元素和像素数据进行分析。实际动作由模型动态规划，并不保证每次运行顺序相同。

为便于将终端日志与 Live View 对照，BrowserActionLogger 在 BeforeToolCallEvent 中解析动作类型。它兼容标准嵌套对象、JSON 字符串和顶层 action 三种输入结构；如果无法识别，则只记录解析失败状态，不输出完整原始入参，避免 URL、Cookie、表单内容或其他潜在敏感信息进入终端与 CI 日志：

Tool #4: browser
[工具动作] browser -> screenshot

当前脚本还增加了以下工程化处理：

AGENTCORE_AUTO_CLEANUP 默认值为 true，支持 true/false、1/0、yes/no、on/off 和 enable/disable 等布尔值；非法值会直接抛出 ValueError，避免因配置错误而关闭资源回收。
主动回收开启时，脚本在任务开始前分页查询 aws.browser.v1 下已有的 READY 会话，并将这些会话记录为保护集合。
Agent 完成任务后，脚本遍历最终消息中的全部 content 块，只拼接包含 text 的内容，同时输出输入 token、输出 token、总 token 和模型累计延迟。
finally 块始终统计本地端到端耗时，并先调用 browser_tool._cleanup() 关闭本地 Playwright 与 CDP（Chrome DevTools Protocol）连接，再通过 StopBrowserSession 停止“当前 READY 会话集合减去保护集合”得到的新增会话。
如果 Agent 执行失败，最终回答和模型指标可能无法输出，但 finally 中的本地连接清理与远端会话回收仍会执行。

注意：browser_tool._cleanup() 是依赖包的私有方法，未来版本可能发生变化；通过 READY 会话集合差值识别新增会话也只适合单用户测试环境。生产环境应在创建会话时记录本任务的 sessionId，并在收尾阶段定向调用 StopBrowserSession，避免并发任务之间产生竞态条件或误停止其他任务的会话。下面运行脚本并观察动态结果。

4、运行测试并查看结果

默认模式会在任务结束后主动停止本次新增的远端会话。执行如下命令：

uv run python browser_agent.py

如果需要在 AgentCore 控制台中持续观察 Live View，可以临时关闭主动回收。为了使运行命令与下方历史回显保持一致，本节使用如下命令：

AGENTCORE_AUTO_CLEANUP=false uv run python browser_agent.py

注意：关闭主动回收仅适用于调试和演示。远端 READY 会话会保留至空闲 900 秒后由服务端回收，在此期间可能继续产生内存费用并占用并发会话配额。

以下是一次真实运行的关键回显。该结果反映采集时网站的最新文章；后续运行的文章标题、图片数量、动作次数、token 消耗和耗时可能不同：

===== Prompt =====
请使用浏览器完成以下任务：1. 打开网页 https://blog.bitipcman.com/ ；2. 在首页上找到并点击最新一片博客；3. 阅读其中的内容，确认文章中使用的网页截图中，是否有红色标注框告知用户应该操作点击哪里请用中文回答。

Tool #1: browser
[工具动作] browser -> init_session

Tool #2: browser
[工具动作] browser -> navigate

Tool #3: browser
[工具动作] browser -> get_html

Tool #4: browser
[工具动作] browser -> screenshot

Tool #5: browser
[工具动作] browser -> evaluate

最新的文章是"以 Kiro 支持 Kiro：飞书机器人通过 ACP 协议调用 Kiro-CLI 解答用户问题"（2026-07-23）。让我点击进入该文章。

Tool #7: browser
[工具动作] browser -> navigate

Tool #9: browser
[工具动作] browser -> screenshot

Tool #11: browser
[工具动作] browser -> evaluate

## 任务完成情况总结

1. 成功访问 https://blog.bitipcman.com/ 并打开当时的最新文章。
2. 文章中的网页截图确实使用了红色矩形标注框提示读者应当点击或关注的位置。
3. Agent 通过浏览器脚本分析图片中的红色像素分布，并识别出多个规则的空心矩形边框。

===== 执行指标 =====
输入 token: 318753
输出 token: 11080
总 token:   329833
模型累计延迟: 146.3 秒
本地测量任务总耗时: 171.9 秒
主动回收已关闭：跳过 StopBrowserSession，远端 READY 会话将在空闲 900 秒后由服务端自动回收（TERMINATED）。如需观察 Live View，请在该窗口期内到控制台查看。

从回显可以看到，同一个 browser 工具先后承担会话初始化、页面导航、DOM 读取、截图和 JavaScript 分析等职责。截图分析显著增加了模型推理轮次和 token 消耗，因此生产环境应根据任务准确率要求限制最大步骤数，并评估 Bedrock 模型费用与 Browser Tool 资源费用。

保持默认主动回收时，脚本会在结尾输出以下两类结果之一：如果检测到本次新增的 READY 会话，则逐个调用 StopBrowserSession 并打印会话 ID；如果会话已由工具正常停止，则说明没有需要主动回收的新增会话。

已停止本次任务产生的浏览器会话: <session-id>

或者：

没有需要主动回收的新增 READY 会话，清理完成。

任务运行期间，可以在 AgentCore 控制台的 Built-in tools 页面找到处于 READY 状态的浏览器会话，并通过 Live View 实时观察操作画面。需要注意，get_text、get_html 和部分 evaluate 动作主要读取或计算页面数据，未必产生明显的画面变化，因此 Live View 中观察到的点击次数通常少于终端中的工具调用次数。

5、小结

本章验证了通过 Strands Agents 调用 AgentCore Browser Tool 完成动态网页与图片分析任务的流程。核心 Agent 接线代码较少，但为了提升可观测性和资源安全，当前示例还实现了动作日志、执行指标、超时保护、本地连接清理和远端会话主动回收。

AWS 托管浏览器降低了浏览器基础设施管理成本，但任务稳定性仍受目标网页变化、模型规划能力、图片分析复杂度和会话生命周期管理影响。对于允许模型动态规划的探索性任务，可以继续采用自然语言 Prompt 驱动 Browser Tool；对于操作路径固定、需要严格控制选择器和执行结果的生产流程，可以进一步使用 Playwright 直连 CDP 端点，并为关键步骤增加确定性校验。下一章将结合本次测试产生的资源消耗说明 Browser Tool 的计费方式。

四、Browser Tool 的计费

上一章运行结束时出现了会话清理挂起、依赖超时自动回收的现象，由此引出一个实际问题：Browser Tool 如何计费，空闲会话是否产生额外费用，以及如何主动回收会话。本章逐一说明。

1、计费模型

AgentCore Browser 采用基于实际资源消耗（Active Consumption Based）的按量计费模型，区别于传统计算服务按预分配资源（固定实例规格乘以运行时长）收费的方式。计费依据是会话生命周期内的 CPU 和内存消耗，按秒计算，最低计费 1 秒。当前费率如下：

计费维度	计费方式	价格
CPU	按实际消耗的 vCPU 时长计费，I/O 等待和空闲期间若无后台进程运行则不产生 CPU 费用	每 vCPU 小时 0.0895 美元
内存	按截至当前秒的峰值内存计费，最低按 128 MB 计	每 GB 小时 0.00945 美元

需要注意的几个细节：会话生命周期从 microVM 启动、初始化、活跃处理、空闲期间直到会话终止（microVM 关闭）为止，整个区间都属于计费范围；计费包含系统开销，不仅是应用自身的资源占用；网络数据传输按标准 EC2 费率另行收取；如使用 Browser Profile 持久化功能（存储 Cookie、Local Storage 等），相关构件按 S3 标准存储费率计费。此外，Bedrock 模型推理的 token 费用独立于 Browser Tool 计费，按所选模型的费率另行结算。

2、空闲等待超时是否产生额外费用

对于本文遇到的"任务已完成但会话未关闭、等待 15 分钟超时自动回收"的情况，费用影响可以从 CPU 和内存两个维度分析：

CPU 维度：AgentCore Browser 的定价模型明确规定，I/O 等待和空闲时间若无后台进程消耗 CPU，则不产生 CPU 费用。任务结束后浏览器处于空闲状态，CPU 费用基本为零。
内存维度：会话处于 READY 状态期间 microVM 并未关闭，内存持续计费直到会话终止。以峰值内存 1 GB 估算，空闲等待 15 分钟的额外内存费用约为 0.25 小时 × 1 GB × 0.00945 美元 ≈ 0.0024 美元。访问一般的网页，实际浏览器可能消耗 3～4 GB。

结论是：空闲等待超时会产生额外费用，但主要来自内存维度，单次金额很小。不过在高频调用或多会话并发的生产场景下，这类费用会随会话数量线性累积，且悬挂的会话还会占用账户的并发会话配额，因此建议养成主动回收会话的习惯。

3、如何主动回收会话

主动回收的核心是 StopBrowserSession API，调用时需要同时指定浏览器标识符和会话 ID。会话一经停止即不可重启，再次使用需通过 StartBrowserSession 创建新会话。以下演示通过 AWS CLI 完成排查与回收的完整过程，本节回显基于真实操作结果，并已对浏览器会话标识与精确时间戳进行脱敏。

首先执行如下命令，列出托管浏览器下的活跃会话：

aws bedrock-agentcore list-browser-sessions \
    --browser-identifier aws.browser.v1 \
    --region us-west-2

返回结果如下，可以看到上一章测试遗留的会话仍处于 READY 状态：

{
    "items": [
        {
            "browserIdentifier": "aws.browser.v1",
            "sessionId": "<session-id>",
            "name": "<session-name>",
            "status": "READY",
            "createdAt": "<created-at>",
            "lastUpdatedAt": "<created-at>"
        }
    ]
}

执行如下命令停止该会话：

aws bedrock-agentcore stop-browser-session \
    --browser-identifier aws.browser.v1 \
    --session-id <session-id> \
    --region us-west-2

返回结果如下：

{
    "browserIdentifier": "aws.browser.v1",
    "sessionId": "<session-id>",
    "lastUpdatedAt": "<last-updated-at>"
}

再次查询 READY 状态的会话，返回空列表，确认会话已回收：

aws bedrock-agentcore list-browser-sessions \
    --browser-identifier aws.browser.v1 \
    --region us-west-2 --status READY

返回结果如下：

{
    "items": []
}

在 Python 代码中也可以通过 Boto3 的 bedrock-agentcore 数据平面客户端完成同样的操作：

import boto3

client = boto3.client("bedrock-agentcore", region_name="us-west-2")

# 停止指定会话
client.stop_browser_session(
    browserIdentifier="aws.browser.v1",
    sessionId="<session-id>",
)

备注：在脚本收尾阶段（如 finally 块）显式调用会话停止逻辑，或在任务提示词中明确要求 Agent 完成任务后关闭浏览器，都可以降低会话悬挂的概率。即使遗漏，托管会话也会在超时后由服务端自动回收，形成兜底。

前文已说明主动回收方式，下面通过 CloudWatch 实测资源用量与费用差异。

4、调试模式下不回收会话而是等待其自行超时

增加环境变量再运行脚本，此时不会自动回收会话，方便调试。

AGENTCORE_AUTO_CLEANUP=false uv run python browser_agent.py

正在进行中的会话，可以通过 AWS 控制台查看。登陆到 Bedrock AgentCore 服务，查看 Browser Tool，查看 Session，即可看到当前工具调用状态。如下截图。

点击查看详情。如下截图。

其中只有页面操作类动作会在 Live View 上产生可见的画面变化。模型理解页面内容时优先调用 get_text、get_html 等动作直接读取 DOM 文本，这比截图后再做视觉识别更高效，token 消耗也更低，因此并不是每次工具调用都需要截图和点击。

5、实测用量与费用

CloudWatch 的 AWS/Bedrock-AgentCore 命名空间下提供计费级的用量指标，其中 CPUUsed-vCPUHours 和 MemoryUsed-GBHours（维度 Service=AgentCore.Browser）直接对应计费公式中的两个乘数，Duration（维度 Operation=BrowserSession）记录会话存续时长。执行如下命令查询指定时间窗口内的 CPU 用量：

aws cloudwatch get-metric-statistics \
    --namespace AWS/Bedrock-AgentCore \
    --metric-name CPUUsed-vCPUHours \
    --dimensions Name=Service,Value=AgentCore.Browser \
    --start-time 2026-08-03T13:35:00Z --end-time 2026-08-03T14:15:00Z \
    --period 60 --statistics Sum --region us-west-2

注意：实测该指标存在约 15 至 25 分钟的上报延迟，任务刚结束时查询可能返回空数据点，需等待后重试。

基于该指标取得的真实数据，两次测试的消耗与费用对比如下：

对比	挂起遗留的会话（修复前）	即时回收的会话（修复后）
会话存续时长	632,839 毫秒，约 10.5 分钟（实际执行任务约 2 分钟，空闲等待约 8.5 分钟）	约 40 秒
CPU 用量	0.01209 vCPU-小时，约 0.00108 美元	0.00148 vCPU-小时，约 0.00013 美元
内存用量	0.53758 GB-小时（稳定占用约 3 GB），约 0.00508 美元	0.02556 GB-小时，约 0.00024 美元
浏览器费用合计	约 0.0062 美元	约 0.0004 美元

从数据中可以得到两个结论。其一，修复前约 80% 的浏览器费用产生于任务完成后的空闲等待期，即时回收将浏览器费用降低到原来的约 6%。其二，空闲期间 CPU 消耗并非完全为零（每分钟仍有约 0.001 vCPU-小时的后台消耗），这与定价页"空闲期无后台进程则 CPU 免费"的表述并不矛盾——保持运行的 Chrome 进程本身就是那个后台进程，因此浏览器会话的空闲期始终存在少量 CPU 计费。

费用结构上还需要指出：本测试的费用大头是模型推理而非浏览器。修复后一次运行消耗输入 67,549 token、输出 1,098 token，按 Claude Sonnet 5 的促销价（2026 年 8 月 31 日前每百万输入 token 2 美元、输出 token 10 美元）计算约 0.146 美元，是浏览器费用的三百多倍；2026 年 9 月 1 日恢复标准价（每百万输入 3 美元、输出 15 美元）后约为 0.22 美元。浏览器工具调用次数越多、页面内容越大，输入 token 累积越快，控制模型费用的关键在于减少不必要的工具调用轮次。

在代码中获取实际消耗有三个层面的手段：Strands 框架的 response.metrics.accumulated_usage 提供精确的 token 用量，accumulated_metrics["latencyMs"] 提供模型累计延迟（本次实测 24.6 秒）；用 time.monotonic() 可测得端到端任务耗时（本次实测 38.7 秒）；而计费级的 CPU 和内存数据只能从 CloudWatch 指标获取，进程内无法直接读取。browser_agent.py 修复版已包含前两个层面的指标打印，实测回显如下：

===== 执行指标 =====
输入 token: 67549
输出 token: 1098
总 token:   68647
模型累计延迟: 24.6 秒
本地测量任务总耗时: 38.7 秒
已停止遗留的浏览器会话: <session-id>

计费、根因与实测数据说明完毕。前面的测试访问的都是公网站点，下一章讨论访问内网资源时的网络配置。

五、访问内网或特定网络环境的配置

AgentCore Browser Tool 支持访问 VPC 内的私有资源。浏览器的网络配置（BrowserNetworkConfiguration）中 networkMode 字段支持 PUBLIC 和 VPC 两种取值，本章说明两种模式的差异与 VPC 模式的配置方法。

1、两种网络模式的对比

对比	PUBLIC 模式	VPC 模式
可访问范围	仅公网资源	VPC 内私有资源（内网站点、内部 API、数据库等），出网路径可控
适用浏览器类型	托管浏览器（aws.browser.v1）与自定义浏览器	仅自定义浏览器（Custom Browser）
网络控制手段	无	安全组、子网路由表、网络 ACL、VPC Flow Logs
典型场景	公开网站信息提取、公网业务流程自动化	企业内部系统集成、内网遗留 Web 系统自动化

本文前几章使用的 AWS 托管浏览器 aws.browser.v1 固定为 PUBLIC 模式，不可更改。需要访问内网时，必须创建自定义浏览器并配置 VPC 模式。

2、VPC 模式的配置方法

通过控制平面 CreateBrowser API 创建自定义浏览器时，在 networkConfiguration 中设置 networkMode 为 VPC，并提供 vpcConfig（子网 ID 列表与安全组 ID 列表，网络模式为 VPC 时该字段必填）。使用 AWS CLI 的示例命令如下：

aws bedrock-agentcore-control create-browser \
    --region us-west-2 \
    --name "my-vpc-browser" \
    --network-configuration '{
        "networkMode": "VPC",
        "vpcConfig": {
            "subnets": ["<subnet-id-1>", "<subnet-id-2>"],
            "securityGroups": ["<security-group-id>"]
        }
    }' \
    --execution-role-arn "arn:aws:iam::<account-id>:role/<execution-role>"

配置时需要注意以下几点：

浏览器的网络接口置入指定的子网，出方向流量由安全组和子网路由表控制。若浏览器在访问内网的同时还需访问公网，所在子网需具备 NAT 网关等出网路径。
使用 CDK 时有现成构造 BrowserNetworkMode.usingVpc()，其中 VPC 为必填项，子网与安全组为可选项（不指定时由 CDK 自动选择子网、自动创建默认安全组）。Browser 构造还暴露 connections 属性，可用 allowTo() 等方法以声明方式管理安全组规则。
代码侧的改动很小：将 AgentCoreBrowser(identifier=...) 的标识符从 aws.browser.v1 替换为自定义浏览器的 ID 即可，Strands Agent 的其余用法不变。

3、安全合规视角

从安全基线的角度，AWS Security Hub CSPM 提供了控制项 BedrockAgentCore.5（严重性为 High），检查自定义浏览器是否使用了 PUBLIC 网络模式：使用 PUBLIC 模式会将浏览器会话直接暴露于互联网，扩大攻击面；配置为 VPC 模式则可将浏览器流量约束在私有网络内，并施加安全组、网络 ACL、VPC Flow Logs 等网络层控制。对安全要求较高的生产环境，建议将自定义浏览器统一配置为 VPC 模式以满足该合规基线。

注意：本章内容基于控制平面 API 参考与 CDK 官方文档核实，笔者未实际创建 VPC 模式的浏览器进行验证；VPC 模式下 Live View、会话录制等功能的可用性，以及目标区域是否支持 VPC 模式，建议在实施前查阅官方文档确认。

网络配置说明完毕，最后列出本文引用的参考资料。