Amazon Bedrock AgentCore 浏览器新增代理、配置文件及扩展支持

基本信息

摘要/简介

今天，我们要宣布三项满足这些需求的新能力：代理配置、浏览器配置文件和浏览器扩展。这些功能共同赋予你对 AI 智能体与 Web 交互方式的细粒度控制。本文将逐一介绍每项能力，并提供配置示例和实际用例，助你快速上手。

导语

随着 AI 智能体与 Web 交互的场景日益复杂，如何确保其在复杂网络环境下的合规性与稳定性成为开发者关注的重点。本文介绍了 Amazon Bedrock AgentCore Browser 推出的代理配置、浏览器配置文件及扩展支持三项新功能，旨在赋予开发者对智能体浏览行为的细粒度控制。通过阅读本文，你将了解这些能力的具体实现方式，并掌握相应的配置示例与实际用例，从而构建更可控、更智能的自动化浏览方案。

摘要

标题：Amazon Bedrock AgentCore Browser 浏览功能升级

总结：

Amazon Bedrock 的 AgentCore Browser 今日宣布推出三项新功能，旨在实现对 AI 智能体网络浏览行为的精细化控制。

这三项核心功能包括：

  1. 代理配置：允许用户自定义网络路由。
  2. 浏览器配置文件：支持管理特定的浏览器状态和设置。
  3. 浏览器扩展：支持加载扩展以增强浏览器功能。

这些功能共同赋予了用户对 AI 智能体与网络交互方式更细致的管控能力。官方文章将提供具体的配置示例和实际用例，以帮助用户快速上手。

评论

中心观点 文章的核心观点是：通过引入代理配置、浏览器配置文件和扩展程序，Amazon Bedrock AgentCore Browser 将 AI 智能体从被动的信息抓取工具升级为具备身份管理、网络合规性和功能可定制性的企业级自动化操作平台。

支撑理由与评价

  1. 从“匿名爬虫”向“数字员工”的身份跨越（技术与内容深度）

    • 事实陈述：文章强调了“Browser Profiles”（浏览器配置文件）功能，允许 Agent 保存 Cookies、Session 和指纹信息。
    • 深度评价：这是 AI Agent 技术落地的关键一跃。传统的 LLM 调用浏览器往往是“无状态”的，每次交互都像是一个新用户。 Profiles 的引入赋予了 Agent “长期记忆”和“身份认证”能力。这意味着 Agent 可以登录 SaaS 平台（如 Salesforce、ServiceNow）执行跨页面的复杂事务，而不仅仅是读取公开网页。这解决了企业级应用中最大的痛点——身份鉴权与权限维持。

  2. 合规性是企业级落地的“护城河”（行业影响与实用性）

    • 事实陈述：文章详细介绍了“Proxy Configuration”（代理配置），支持对 Agent 的出口 IP 进行精细化管理。
    • 你的推断：这直接响应了 B2B 行业对数据主权的严苛要求。许多企业通过防火墙白名单限制数据访问，或者需要通过特定地区的 IP 访问本地化服务（如各国的电商数据）。没有代理支持，AI Agent 在企业内网几乎是“残废”的；有了它，Agent 才能真正融入企业现有的网络安全架构，而不是被视为一个需要被封锁的外部威胁。

  3. 通过“扩展程序”实现能力的非线形扩展（创新性）

    • 事实陈述：文章提到支持安装 Browser Extensions。
    • 作者观点：这是最具想象空间的功能。与其让 LLM 重新造轮子去学习如何解析复杂的验证码、特定的 DOM 结构或处理特殊的认证协议，不如直接调用现成的浏览器插件生态（如广告拦截器、密码管理器、自定义脚本）。这类似于给 AI Agent 配备了“外挂”，使其能够利用人类已有的软件生态，极大地降低了开发特定功能的边际成本。

反例与边界条件

  1. 架构复杂度与成本的激增（反例）

    • 你的推断：虽然功能强大，但维护成千上万个带有独立 Profile 和特定 Proxy IP 的 Agent 实例，其运维成本将呈指数级上升。Profile 的 Session 管理本身就是一场噩梦（例如：如何处理 Session 过期？如何处理并发登录冲突？）。对于简单的数据抓取任务，这种架构显得过于重量级。

  2. “扩展程序”的安全黑洞（争议点）

    • 作者观点：允许 AI Agent 安装和运行扩展程序是巨大的安全风险。浏览器扩展拥有极高的权限，恶意扩展可能会窃取 Agent 正在处理的敏感数据。在 RAG（检索增强生成）场景下，Agent 浏览的内容可能包含企业机密，如果扩展程序将数据回传给第三方，将导致严重的数据泄露。AWS 必须对此建立严格的扩展程序审核机制。

可验证的检查方式

  1. 状态保持测试

    • 指标：在开启 Browser Profile 的情况下，让 Agent 执行“登录 -> 添加购物车 -> 关闭浏览器 -> 重新打开 -> 验证购物车商品是否仍在”的流程。
    • 预期结果：如果 Profile 功能生效，Agent 应能恢复之前的会话状态，无需二次登录。

  2. IP 归属地验证

    • 指标：配置指向特定国家（如新加坡或日本）的出口代理，让 Agent 访问 ipinfo.io 或类似的 IP 检测服务。
    • 预期结果：Agent 返回的内容中应准确显示配置的代理 IP，而非 AWS 数据中心的默认 IP 段。

  3. 扩展功能调用测试

    • 实验：安装一个自定义扩展（例如一个修改页面 DOM 结构的脚本，或者一个提取特定 JSON 数据的插件），让 Agent 读取经过扩展处理后的页面数据。
    • 预期结果：Agent 的输出应包含扩展处理后的数据，证明其不仅仅是渲染页面，还能与扩展环境交互。

实际应用建议

  1. 用于企业知识库的实时同步：利用 Profiles 功能，配置一个拥有只读权限的“机器人账号”，定期让 Agent 登录企业内部 Wiki 或 Confluence，抓取最新更新并注入向量数据库。这比传统的 API 对接更灵活，尤其适用于没有 API 的老旧系统。
  2. 竞品监控与合规采集：结合代理配置，让 Agent 模拟真实用户从不同地区访问竞品网站，收集价格或库存信息。注意配置合理的请求头和 IP 轮换策略，避免触发反爬虫机制。
  3. 自动化审计：安装安全审计类的浏览器扩展，让 Agent 自动浏览公司内部网页，通过扩展发现的漏洞结合 LLM 的理解能力，生成可视化的安全审计报告。

总结 这篇文章虽然披着技术更新的外衣，实际上揭示了 AWS 在 AI Agent 基础设施层的一次重要战略升级。它不再仅仅追求模型的智商，而是开始构建模型的“手脚”和“身份证”。尽管在运维复杂度和安全性上存在挑战，但这无疑是 AI 走向企业级大规模应用的必经之路。

技术分析

深度分析：Amazon Bedrock AgentCore Browser 的定制化能力

基于您提供的文章标题和摘要，以下是对 Amazon Bedrock AgentCore Browser 新增的代理配置、浏览器配置文件和扩展功能这三个核心能力的深入分析。

1. 核心观点深度解读

主要观点

文章的核心观点在于：企业级 AI 智能体在访问互联网时，不能仅仅满足于“能访问”，必须具备“可控、安全且符合上下文”的浏览能力。

核心思想

作者传达的核心思想是，AI 智能体正在从简单的“聊天机器人”向复杂的“数字员工”转变。正如人类员工需要特定的网络权限、工作环境和辅助工具才能高效工作一样，AI 智能体也需要通过 Proxy（代理） 来满足合规与安全要求，通过 Profiles（配置文件） 来维持会话状态和个性化设置，以及通过 Extensions（扩展） 来增强特定场景下的功能。这三者共同构成了 AI 智能体与 Web 交互的“治理层”。

观点的创新性与深度

这一观点的深度在于它跳出了“大模型能力”本身，聚焦于系统工程与企业级集成。过去业界关注较多的是如何让 LLM 理解网页内容（RAG），而较少关注 LLM 访问网页时的网络身份、权限控制和环境隔离。这一更新标志着 AI Agent 基础设施正从“玩具级”向“生产级”迈进。

重要性

这一点至关重要，因为缺乏控制的 AI 浏览行为会带来巨大的风险（如数据泄露、IP 封禁、合规审计失败）。这三大功能解决了 AI 落地企业最后一公里的“管控”难题。

2. 关键技术要点

涉及的关键技术

  1. 代理配置：支持 HTTP/HTTPS 代理，包括认证（Basic Auth）。
  2. 浏览器配置文件：类似于 Chrome 的 User Profile，支持 Cookie、缓存、历史记录和插件设置的持久化。
  3. 浏览器扩展：支持加载标准的 Chrome 扩展程序。

技术原理与实现方式

  • 代理：在 AgentCore Browser 的网络层通过标准代理协议进行流量转发。这意味着企业可以将 AI 流量导向自己的安全网关，进行 SSL 检查、数据防泄漏（DLP）扫描或伪装出口 IP。
  • 配置文件：基于 Chromium 的多用户架构。每次启动浏览器实例时，挂载特定的用户数据目录。这使得 Agent 可以在多次对话中保持登录状态（例如登录了 LinkedIn 或内部 Wiki），无需每次都重新验证。
  • 扩展：利用 Chromium 的扩展 API。这意味着开发者可以用 JavaScript 编写自定义逻辑，注入到网页中，辅助 LLM 读取那些难以通过纯文本解析的复杂 Web 内容（如 Canvas 绘制的图表、特定的 SPA 应用）。

技术难点与解决方案

  • 难点：状态管理的隔离性。 如果多个 Agent 同时运行，如何避免 Cookie 污染？
    • 方案： 通过独立的 Profile 实例化，确保每个 Agent 拥有独立的浏览器指纹和存储空间。
  • 难点：动态内容的捕获。
    • 方案： 通过安装特定的扩展（如广告拦截器或自定义脚本提取器），在页面加载到 LLM 视野之前进行预处理，提高信号质量。

技术创新点

最大的创新点在于将“浏览器工程”的能力赋予了 AI Agent。它允许开发者利用现有的庞大浏览器生态（Chrome 插件库）来增强 AI，而不是从头编写所有逻辑。

3. 实际应用价值

对实际工作的指导意义

这意味着我们可以构建更加专业的垂直领域 Agent。例如，一个“市场调研 Agent”不再只能抓取公开静态页面，它可以登录付费数据库（Profile），通过企业代理访问（Proxy），并使用专门的插件来格式化数据。

应用场景

  1. 企业内网知识检索： Agent 通过 Proxy 访问内网，利用已登录的 Profile（SSO）访问受保护的 Wiki 或 Confluence 页面。
  2. 电商价格监控： Agent 通过不同地区的 Proxy 模拟不同地理位置的用户，查看 localized 价格，并使用扩展来绕过反爬虫验证。
  3. 合规性自动化： 在金融或医疗领域，强制所有 Agent 流量经过 Proxy 进行审计和记录。

需要注意的问题

  • 成本与延迟： 启动完整的浏览器实例比简单的 HTTP 请求消耗更多资源，延迟也更高。
  • 扩展兼容性： 并非所有 Chrome 扩展都能在无头模式下完美运行。

实施建议

在开发初期，仅在必须处理复杂认证或需要特定网络拓扑的 Agent 中启用这些功能。对于简单的静态网页抓取，继续使用轻量级的 HTTP 工具。

4. 行业影响分析

对行业的启示

这一举措表明，AI Agent 的竞争壁垒正在从“模型智商”转向“工具生态”。AWS 并没有直接修改模型，而是通过改善 Agent 的运行环境来提升最终效果。这启示行业：解决 AI 落地问题，往往需要解决工程化、运维和安全问题，而不仅仅是算法问题。

可能带来的变革

  • RAG 架构的演进： 未来的 RAG 系统将不再仅仅是“向量数据库 + LLM”，而是“向量数据库 + 有状态的浏览器 + LLM”。
  • SaaS 交互的重构： 企业可能会开发专门的 Agent 扩展，让 AI 直接通过 UI 操作 SaaS 软件（如 Salesforce、ServiceNow），而不是完全依赖 API 集成。

发展趋势

我们预计未来会出现**“Agent 专用浏览器”**的概念，浏览器将针对 AI 的视觉和交互模式进行优化（例如自动移除广告、优化 DOM 结构以供 LLM 解析）。

5. 延伸思考

拓展方向

  • 指纹识别与反检测： 既然 Agent 可以使用 Profile，那么它是否能完全模拟人类行为（鼠标轨迹、字体列表）？这将开启“高级仿真”的研究方向。
  • 多 Agent 协作： 多个 Agent 是否可以共享一个 Profile？一个 Agent 负责登录，另一个负责分析？这涉及到权限隔离的新挑战。

需进一步研究的问题

  • 如何防止 Agent 在拥有扩展能力后执行恶意脚本？
  • Profile 的生命周期管理：何时销毁？如何处理敏感数据残留？

6. 实践建议

如何应用到自己的项目

  1. 评估需求： 检查你的 Agent 是否因为登录失败或 IP 封禁而无法完成任务。如果是，引入 Profile 和 Proxy。
  2. 开发自定义扩展： 针对你的目标网站（如复杂的 Dashboard），编写一个简单的 JS 扩展，将核心数据提取为 JSON，注入到页面的 DOM 中，方便 LLM 读取。
  3. 网络架构： 部署一个专用的代理服务器池，用于管理和监控 AI 的出站流量。

具体行动建议

  • 安全第一： 始终通过 Proxy 路由流量，不要让 Agent 直接访问公网，以便在出口处进行熔断保护。
  • 隔离环境： 为不同客户的 Agent 使用不同的 Profile，防止数据混淆。

补充知识

开发者需要熟悉 Puppeteer 或 Playwright 的概念，以及 Chrome 扩展的 Manifest V3 规范。

7. 案例分析

成功案例（假设场景）

场景：跨境电商竞品分析

  • 挑战： 竞品网站对非登录用户限制查看，且对高频访问 IP 进行封禁。
  • 解决方案：
    • Profile： Agent 使用预登录的账号，保持 Session 活跃。
    • Proxy： 轮换住宅 IP，模拟真实用户从不同地区访问。
    • Extension： 安装“JSON View”扩展，将 API 返回的数据直接格式化，绕过复杂的 HTML 解析。
  • 结果： 数据获取成功率从 40% 提升至 99%。

失败案例反思

  • 教训： 某团队让 Agent 通过代理访问高敏感内网，但未限制扩展权限。Agent 被诱导安装了恶意扩展，导致凭证泄露。
  • 总结： 权力越大，风险越大。必须对可安装的扩展进行白名单管理。

8. 哲学与逻辑：论证地图

中心命题

为了构建企业级、生产可用的 AI Agent，必须赋予其精细化的网络管控能力、持久化的会话状态以及可扩展的功能接口。

支撑理由

  1. 安全与合规： 企业网络环境通常要求流量经过审计，且不能暴露源 IP（事实）。
  2. 状态依赖： 现代互联网应用大量依赖 Cookie 和 Session，无状态浏览器无法完成复杂任务（事实）。
  3. 环境异构性： Web 内容极其复杂，标准浏览器内核无法完美解析所有特定格式，需要扩展辅助（技术限制）。

反例与边界条件

  1. 简单场景的冗余： 对于仅仅查询公开新闻或天气的 Agent，引入 Profile 和 Extension 会显著增加延迟和资源消耗，是不必要的（边界条件）。
  2. 静态 API 的存在： 如果目标服务提供了完善的 API，Agent 应优先调用 API 而不是使用浏览器模拟，因为浏览器更不稳定（反例）。

事实与价值判断

  • 事实： Bedrock 引入了这三项功能。
  • 事实： 浏览器是访问 Web 的主要界面。
  • 价值判断： “精细控制”比“无限制访问”对企业更重要。

立场与验证

立场： 支持。这是 AI Agent 走向成熟的必经之路。 可证伪验证： 观察未来 6 个月内，企业级 AI 应用的采用率是否会因为“安全/合规”问题的解决而显著提升；或者观察是否会出现专门针对 Agent 优化的浏览器扩展市场。如果这些功能无人使用，则说明“模型能力”仍是唯一瓶颈，工程化控制并非刚需。

最佳实践

最佳实践指南

实践 1：利用 Profiles 管理会话状态与隔离

说明: Bedrock AgentCore Browser 中的 Profiles（配置文件）类似于浏览器的用户配置。通过为不同的 AI Agent 任务或会话创建独立的 Profile，可以有效地隔离 Cookie、缓存、浏览历史和本地存储。这对于需要登录特定网站或保持上下文状态的复杂任务至关重要，能够防止不同任务之间的数据污染。

实施步骤:

  1. 在初始化 Browser 实例时，配置 Profile 参数。为每个特定的 Agent 工作流分配唯一的 Profile 名称。
  2. 如果 Agent 需要访问需要认证的网站，首先在特定的 Profile 中手动或通过脚本完成登录流程，保存状态。
  3. 在后续的调用中，指定该 Profile，以便 Agent 能够继承登录状态和会话上下文。

注意事项:

  • 定期清理或轮换未使用的 Profiles，以避免占用过多的存储空间。
  • 确保敏感信息（如认证 Token）在 Profile 存储中得到加密保护。

实践 2：通过代理访问地理受限或内部资源

说明: 配置代理允许 AI Agent 通过特定的中间服务器路由流量。这对于访问具有地理位置限制的内容、绕过速率限制，或者允许安全地访问企业内部网络资源至关重要。

实施步骤:

  1. 准备好代理服务器的地址（主机名/IP）、端口以及认证凭据（用户名/密码）。
  2. 在 Bedrock AgentCore Browser 的配置中，设置 Proxy 设置。确保使用安全的协议（如 HTTPS 或 SOCKS5）。
  3. 测试连接以确保 Agent 能够通过代理成功请求目标 URL，并验证 IP 地址是否已正确代理。

注意事项:

  • 始终验证代理服务器的可靠性和延迟，高延迟代理会显著降低 Agent 的响应速度。
  • 确保代理链符合数据隐私和合规性要求，避免敏感数据经过不受信任的第三方节点。

实践 3：使用浏览器扩展增强数据抓取能力

说明: 虽然 AgentCore 具备强大的内置解析能力，但加载特定的浏览器扩展可以显著增强其功能。例如，安装自定义的 XPath 辅助工具、Cookie 管理器或特定的网页结构化数据提取插件，可以帮助 Agent 更准确地处理复杂的现代 Web 应用（如 SPA 单页应用）。

实施步骤:

  1. 开发或获取符合目标浏览器标准的扩展包。
  2. 将扩展文件上传到可访问的存储位置（如 S3 存储桶）。
  3. 在启动 Browser 配置时，指定 Extensions 参数，加载必要的扩展文件路径。

注意事项:

  • 仅加载经过审核的必要扩展，避免安装来源不明的插件以防止安全风险。
  • 扩展可能会增加页面的加载时间和内存消耗，需在性能和功能之间取得平衡。

实践 4：实施严格的超时与重试策略

说明: 网络波动或目标网站响应缓慢可能导致 Agent 无限期挂起。配置合理的超时和重试机制可以确保 Agent 的鲁棒性，防止任务阻塞，并优化资源利用率。

实施步骤:

  1. 根据目标网页的平均加载时间，为 Browser 操作设置 NavigationTimeout（例如 30 秒）。
  2. 实施指数退避算法进行重试。如果请求失败，等待 2 秒重试，然后是 4 秒，依此类推，直到达到最大重试次数（如 3 次）。
  3. 区分不同类型的错误（如 4xx 客户端错误不应重试，5xx 服务器错误应重试）。

注意事项:

  • 不要设置过短的超时时间，以免在加载内容丰富的页面时产生误报。
  • 监控重试频率，避免对目标服务器造成过大压力（DDoS 风险）。

实践 5：优化浏览器指纹以避免被检测

说明: 当 AI Agent 访问某些网站时，可能会被反爬虫系统识别为机器人。通过自定义 Browser 的 User-Agent、视口大小和其他指纹特征，可以模拟真实用户行为，提高访问的成功率。

实施步骤:

  1. 设置常见的桌面端或移动端 User-Agent 字符串。
  2. 配置 Viewport（视口）参数，设置标准的屏幕分辨率（如 1920x1080）。
  3. 考虑通过扩展或配置修改 Navigator 属性，使其看起来更像普通浏览器。

注意事项:

  • 遵守目标网站的 robots.txt 和服务条款，仅在授权范围内进行优化。
  • 定期更新 User-Agent 字符串，以跟上浏览器版本的更新。

实践 6：确保安全的凭证管理

说明: 如果 Agent 需要通过代理或登录网站进行身份验证，必须安全地管理这些凭证。硬编码凭证在代码中是极其危险的。

实施步骤:

  1. 使用 AWS Secrets Manager 或 Parameter Store 来存储代理密码、API 密钥或网站登录

学习要点

  • Amazon Bedrock 的 AgentCore Browser 允许通过集成代理服务器、自定义浏览器配置文件及第三方浏览器扩展，显著增强 AI 智能体在浏览过程中的网络访问能力、环境隔离性与功能扩展性。
  • 通过配置代理服务器，用户可以控制 AI 智能体的网络流量路由，从而有效绕过地域限制、访问受地理封锁的内容或通过内部网关安全地抓取数据。
  • 利用浏览器配置文件，可以为 AI 智能体设定独立的浏览环境（包括 Cookie、缓存和会话状态），这对于模拟真实用户行为或维持多账号登录状态至关重要。
  • 支持加载浏览器扩展插件使得 AI 智能体能够突破原生浏览器的功能限制，执行验证码识别、广告拦截或复杂的数据提取等高级任务。
  • 该功能通过精细化的控制手段，有效解决了 AI 智能体在访问现代网站时常见的反爬虫检测和动态内容加载难题，提升了数据采集的稳定性。
  • 企业可以利用此功能在隔离的浏览器会话中执行自动化操作，确保不同任务之间的数据安全和环境互不干扰。

引用

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

相关文章