我们如何使用 AWS Bedrock AgentCore 构建安全、可扩展的智能体基础设施

TL;DR：只需让你的智能体为你总结这篇文章。

在 Browser Use，我们在生产环境中运行数百万个不受信任的 AI 智能体，每个智能体都运行在一个零凭据的私有微 VM 中。所有出站调用都经过一个控制平面，整个系统随需求弹性扩缩。

架构

六个月前，我撰写了 我们如何为不受信任的智能体搭建沙箱：零密钥微 VM、持有所有凭据的控制平面、一个镜像在各处运行。这一抽象层仍然是保护整个集群的关键。底层发生变化的是运行时：AWS Bedrock AgentCore 现在负责配置和调度每个会话的微 VM，每个微 VM 都挂载一个与该会话作用域绑定的持久 /mnt/workspace 挂载点。

一个保护你的智能体凭据安全的沙箱

该 VM 位于一个私有 VPC 中，其执行角色只能从 ECR 拉取镜像并将日志写入 CloudWatch。它自身无法访问 S3、数据库或任何其他 AWS API。出站流量采用允许列表，仅限于控制平面和公共 HTTPS。

VM 中也没有内置任何密钥。运行时仅持有一个控制平面 URL，其他所有内容（会话令牌、会话 ID、每次运行的标志）都在每个请求的 /invocations 载荷中传入，因此运行之间 VM 上不会保留任何敏感信息。

每个会话还会获得自己的微 VM，并挂载一个与会话 ID 作用域绑定的 /mnt/workspace 挂载点，因此会话之间无法互相看到。

整个技术栈原生使用 AWS

我们技术栈的其余部分是 AWS 原生的（ECS、RDS、S3、IAM 等）。在 AgentCore 上运行沙箱意味着运行时层属于同一个体系。

• IAM 作用域的运行时执行角色。运行时使用 IAM 角色从 ECR 拉取镜像并将日志写入 CloudWatch，方式与任何 ECS 任务相同。
• 标准 VPC 网络。运行时位于我们的 VPC 内部，并配有专用安全组。无入站流量。出站流量采用允许列表，仅限于控制平面的内部 ALB（LLM 代理、回调）、ECR 和 CloudWatch 的 VPC 端点，以及用于浏览器 CDP URL 和预签名 URL 的公共 HTTPS。
• AgentCore 管理的会话存储。每个会话获得一个隔离的 1 GB 工作区，挂载在 /mnt/workspace，在停止/恢复之间持久保留。
• Terraform 管理。每个环境一个 aws_bedrockagentcore_agent_runtime 资源，外加一个标准执行角色。
• 按使用付费。没有闲置费用。

你的智能体永远看不到真实凭据

把控制平面想象成一个代理服务。沙箱无法直接访问外部世界。每个请求都必须经过控制平面。需要调用 LLM？经过控制平面。需要将文件上传到 S3？经过控制平面。这是智能体与其 VM 之外的任何事物通信的唯一方式。

它是一个无状态的 FastAPI 服务。来自沙箱的每个请求都携带一个包含会话令牌的标头。控制平面根据令牌查找会话，验证其是否仍然有效，并使用真实凭据执行操作。

LLM 代理

智能体的 SDK 调用其常规提供商端点，只是基础 URL 指向控制平面（/api/v4/llm/anthropic/v1、/api/v4/llm/openai/v1 等）。控制平面验证会话令牌，将其替换为真实的上游 API 密钥，计量使用量，然后转发给提供商。响应以相同方式返回，但不包含上游密钥。

沙箱从未见过真实的 API 密钥，也从不直接与提供商通信，费用上限和计费都在转发过程中完成。

Agent 安全的文件访问

每个会话在 /mnt/workspace 处都有一个隔离的 1 GB 工作区，由 AgentCore 的托管会话存储支持。它是按会话隔离的，在停止/恢复之间持久存在，且其他任何会话都无法看到它。

对于智能体需要移入或移出的文件（会话文件、工作区共享文件、浏览器下载），沙箱从不持有 AWS 凭证。它会向控制平面请求一个限定于该会话的预签名 URL：

1. 沙箱向 CP 请求一个预签名 URL（上传或下载，限定于会话）。
2. CP 使用自身的 S3 凭证生成该 URL。
3. 沙箱通过普通 HTTPS 使用该 URL。

智能体在运行期间生成的文件会在运行结束时通过控制平面提升到 S3，因此被清空的 VM 永远不会丢失它们。

会话状态在停止和恢复后依然保留

沙箱被设计为可丢弃的，但某些按会话的状态重建成本很高。Bcode 的 SQLite 状态（bcode.db）位于持久 /mnt/workspace 挂载上，因此它能存活于：

• 空闲停止（15 分钟空闲超时）。
• 会话回收（8 小时最长生命周期）。

它只会在运行时版本升级或会话空闲 14 天时被清空。在此之前，控制平面是冷恢复的事实来源。持久挂载是一个缓存，使热恢复成本低廉。

从零扩展到数千个并发智能体

我们的工作负载是突发性的。智能体运行高度集中，我们可以在短时间内从安静的一分钟变成数千个并发沙箱，然后再变回来。

面对这样的曲线，固定规模的集群是错误的形态。如果你按峰值来配置，你就要为大部分时间闲置的容量付费。如果你按平均值来配置，你就会在峰值时丢弃或排队流量。

AgentCore 将每个智能体会话视为其自身的原语。会话按需启动，空闲时停止，且仅按活跃会话时间计费。容量跟随需求曲线，而不是固定在曲线之上。

控制平面独立扩展。它运行在私有子网中的 ECS Fargate 上，位于 ALB 之后，并根据 CPU 自动扩缩。沙箱通过 AgentCore 独立扩展。每个会话获得自己的 VM，由 AgentCore 处理调度。

在 AgentCore 上运行它

对于好奇的读者，以下是 AgentCore 集成端到端的实际样子。

会话限定在我们自己的会话 id（runtimeSessionId = session_id）上，因此 AgentCore 的会话概念和我们的是同一回事。一个会话 id 给我们一个热 VM、一个工作区和一个生命周期。

运行时完全由针对 bedrock-agentcore 客户端的两次 boto3 调用驱动：

# Dispatch a task into an agent session.
client.invoke_agent_runtime(
    agentRuntimeArn=RUNTIME_ARN,
    runtimeSessionId=session_id,
    payload=json.dumps(invocation).encode(),
    contentType="application/json",
    accept="application/json",
)
 
# Kill an in-flight session.
client.stop_runtime_session(
    agentRuntimeArn=RUNTIME_ARN,
    runtimeSessionId=session_id,
)

会话上下文包含在 /invocations 负载中，而不是在 VM 的环境变量中。同一 VM 上的两次运行可以携带完全不同的上下文，并且在请求返回后都不会保留。

生产环境中有两个设置很重要：

• 空闲超时，15 分钟无活动。
• 最长生命周期，8 小时。每个会话的硬上限。

结论

我们在 sandbox 文章中押注的抽象依然成立。零密钥的微型 VM 和持有所有凭证的控制平面，这一部分没有改变。改变的是运行时层现在也是原生 AWS 了。

对我们来说，理由是：

• 弹性扩展，跟随突发的需求曲线，无需手动配置集群规模。
• IAM、VPC、S3、CloudWatch 技术栈一路到底。关键路径上少了一个外来概念。
• 一个按会话隔离的微型 VM，带有持久状态，位于私有 VPC 中，自身零凭证。

与原文相同的结论：你的智能体应该没有任何值得窃取的东西，也没有任何值得保留的东西。

如果你想在此架构上运行 Browser Use 代理而无需自行托管，这正是我们在 Browser Use Cloud 中提供的服务。