AgentCore Runtime Instances 详解
AWS Bedrock AgentCore Runtime Instances 提供持久化 EC2 托管基础设施，支持 14 天会话、GPU 加速和多 Agent 协作。详解架构、定价与使用场景。
TL;DR — Amazon Bedrock AgentCore 新增 Runtime Instances：持久化的 AWS 托管 EC2 基础设施，多个 agent 共享主机、在最长 14 天的会话中协作，支持 GPU 加速。它是现有 microVM（最长 8 小时）的互补选项，面向需要长时间运行状态、多 agent 协调或重型计算的工作负载。定价为标准 EC2 费用加管理费。今天起在 8 个区域可用。
做过多 agent 系统的人都踩过同一个坑：框架搞定了编排，模型 API 搞定了推理，但底下没有一个持久化的、托管的主机让 agent 们住在一起、共享状态、跑上几天不丢上下文。要么自己管 EC2，要么接受 serverless 的时间限制。两头都不舒服。
昨天（2026 年 8 月 6 日），AWS 发布了 Runtime Instances——Amazon Bedrock AgentCore Runtime 的新计算选项。这不是取代现有 microVM，而是一个互补的计算层级，专为需要持久性、协作能力和 GPU 的工作负载设计。
Runtime Instances 是什么
Runtime Instances 是通过 AgentCore Runtime API 配置的 AWS 托管 EC2 基础设施。你把一个或多个 agent 部署到同一个 Runtime Instance 上，这些 agent 共享主机的文件系统、内存和（可选的）GPU，会话最长持续 14 天。
和现有 microVM 的核心区别：
| microVM | Runtime Instances | |
|---|---|---|
| 会话时长 | 最长 8 小时 | 最长 14 天 |
| 计算模型 | 临时的、按调用 | 持久的、托管 EC2 |
| 多 Agent | 每个 agent 独立隔离 | 多个 agent 同一主机 |
| GPU 支持 | 否 | 是 |
| 状态持久化 | 无（无状态） | EBS + AgentCore Memory |
| 费用模型 | 按使用量（调用时间） | EC2 实例小时 + 管理费 |
| 停止/重启 | 不适用（执行后终止） | 支持，保留会话状态 |
| 适合场景 | 短任务、突发执行 | 长工作流、协作、GPU |
microVM 仍然是短时间、强隔离任务的最佳选择——跑几分钟的工具调用、一次性代码执行、单次生成。Runtime Instances 是为不适合 8 小时窗口、或者需要 agent 之间共享上下文的场景准备的。
部署方式
部署很直接。打包你的 agent 代码，部署到 Runtime Instance。实例运行 Linux（ARM64 或 x86_64），支持 Python 3.11 到 3.14，接受两种打包格式：
- Zip 部署 — 代码加 manifest，直接上传
- 容器部署 — Docker 镜像推送到 ECR 或任何 OCI 兼容的 registry
两种方式用同样的入口模式。用一个装饰器暴露 agent 端点：
from agentcore import app
@app.entrypoint
def code_writer(session, task: str):
"""负责根据任务描述编写代码的 agent。"""
workspace = session.filesystem("/workspace")
# 访问共享会话状态
context = session.memory.recall(task)
# 写入共享文件系统
code = generate_code(task, context=context)
workspace.write("solution.py", code)
# 通知 reviewer agent
session.notify("code_reviewer", {
"file": "/workspace/solution.py",
"task": task
})
return {"status": "written", "path": "/workspace/solution.py"}
@app.entrypoint
def code_reviewer(session, notification: dict):
"""负责审查 code_writer 产出的代码的 agent。"""
workspace = session.filesystem("/workspace")
# 从共享文件系统读取
code = workspace.read(notification["file"])
# 执行审查
review = review_code(code, criteria=["correctness", "style", "security"])
if review.needs_changes:
session.notify("code_writer", {
"task": f"根据反馈修改: {review.summary}",
"original_file": notification["file"]
})
return {"status": "reviewed", "passed": not review.needs_changes}两个 agent——一个写代码、一个做 review——部署在同一个 Runtime Instance 上。它们共享文件系统、通过通知互相协调、可以反复迭代而不需要外部协调层。会话保持它们的状态，一个 agent 空闲时另一个在工作，上下文不会丢失。
@app.entrypoint 装饰器是 AgentCore 发现和路由 agent 的全部接口。不锁定框架：内部代码可以用 CrewAI、LangGraph、LlamaIndex、Strands，或者直接裸调 API。AgentCore 管基础设施，你的框架管编排。
多 Agent 协作：共享主机模型
Runtime Instances 的核心特性是 co-location。多个 agent 运行在同一主机上，共享：
- 文件系统 — agent 读写相同路径，不需要经过 S3 传递中间产物
- 会话记忆 — AgentCore Memory 在整个会话生命周期提供长期回忆
- 通知 — agent 在会话内互相发信号
- GPU — 如果实例类型含 GPU，所有 agent 都能访问
这和 microVM 的隔离模型根本不同。Runtime Instances 用严格隔离换来了协作效率。安全边界从 per-agent 移到了 per-instance——同一个 instance 上的 agent 互相信任，不同 instance 之间保持隔离。
对于多 agent 模式——supervisor/worker、pipeline、辩论、集成——co-location 去掉了序列化和网络开销，让这些模式在规模化时不再痛苦。agent 通过共享内存和文件系统通信，而不是 API 调用和队列。
会话生命周期与成本管理
Runtime Instances 的会话最长持续 14 天。在此期间，你可以停止和重启实例，在空闲时节省费用。停止时保留会话状态（EBS 卷、AgentCore Memory），不产生计算费用。
适合有不规则活动模式的工作负载：
- 研究 agent 跑 6 小时，等人工审核，第二天再跑 4 小时
- CI/CD agent 流水线在 commit 时激活，中间休眠
- 数据处理工作流每晚运行，但跨运行保持状态
停止/重启意味着空闲时不为 EC2 实例付费。只付 EBS 存储费（每 GB 每月几分钱），恢复时从上次位置继续。
GPU 加速
Runtime Instances 支持 GPU 加速实例类型，打开了之前在 AgentCore 里做不到的场景：
- 本地模型推理 — 在实例上跑小模型，减少调用外部 API 的延迟和成本
- Embedding 生成 — 在本地为 RAG 管线生成 embedding，不走网络
- 带 GPU 的代码执行 — 跑 CUDA 工作负载、ML 训练、图片/视频生成
- 混合推理 — 简单任务用本地模型，复杂推理用 Bedrock API
GPU 支持是和 microVM 最明确的差异化点。如果你的 agent 需要跑 fine-tuned 模型或执行 GPU 加速代码，Runtime Instances 是 AgentCore 内唯一的路径。
存储与记忆
Runtime Instances 集成两个持久化层：
Amazon EBS — 标准块存储，挂载到实例。停止/重启后仍在。用于工作文件、agent 产出物、数据库，或任何需要文件系统持久性的东西。
AgentCore Memory — 托管记忆服务，为 agent 提供长期回忆。agent 可以跨会话存储和检索上下文，让跨多个会话生命周期的工作流成为可能。把它理解为 agent 的长期记忆——即使 14 天的会话窗口过期后仍然存在。
两者结合，agent 同时拥有短期工作存储（EBS）和无限期回忆（Memory）——这正是需要在数周或数月间歇性运行中保持上下文的 agent 所需要的组合。
定价模型
Runtime Instances 的定价很透明：
- 标准 EC2 定价 — 按你选择的实例类型收取 on-demand 费率
- 管理费 — 在 EC2 费用基础上加收，覆盖 AgentCore 编排、会话管理、健康监控和托管部署基础设施
这比在规模化时估算 serverless 调用成本简单得多，对长时间运行的工作负载也更可预测。如果你的 agent 跑几个小时或几天，microVM 的按调用计费可能比一个专用实例还贵——Runtime Instances 给你一个固定的小时费率。
停止/重启是核心的成本杠杆。一个实例每天跑 8 小时，费用大约是 24/7 运行的三分之一。对有空闲期的工作负载，这比保持 microVM 会话存活便宜得多。
什么时候用 microVM，什么时候用 Runtime Instances
用 microVM：
- 任务在几分钟到几小时内完成
- 每个 agent 需要严格的互相隔离
- 想要纯按使用量付费、无空闲成本
- 工作负载无状态，或状态装得进调用 payload
用 Runtime Instances：
- 工作流跨越数小时到数天（最长 14 天）
- 多个 agent 需要在共享状态上协作
- 需要 GPU 加速
- 费用可预测性比按秒计费更重要
- agent 需要跨停止/重启周期的持久存储（EBS）
两个选项在同一个 AgentCore 部署中互补。你可以用 microVM 跑工具调用和短任务，把复杂的多 agent 工作流路由到 Runtime Instances。AgentCore 通过同一套 API 管理两者。
框架支持
Runtime Instances 不绑定框架。@app.entrypoint 模式不管内部跑什么都适用：
- CrewAI — 把 crew 定义部署为 entrypoint，同一实例上的 crew 之间共享上下文
- LangGraph — 跑基于图的工作流，checkpoint 持久化到 EBS
- LlamaIndex — 部署 RAG 管线，在 GPU 实例上本地生成 embedding
- Strands — 轻量 agent 循环，通过共享文件系统协调
不会被锁定到 AWS 特定框架。你现有的 agent 代码只需最小改动就能部署——加装饰器、打包成 zip 或容器、部署。
区域可用性
Runtime Instances 于 2026 年 8 月 6 日在以下区域上线：
- 美国东部：Ohio (us-east-2)、N. Virginia (us-east-1)
- 美国西部：Oregon (us-west-2)
- 亚太：Mumbai (ap-south-1)、Singapore (ap-southeast-1)、Sydney (ap-southeast-2)、Tokyo (ap-northeast-1)
- 欧洲：Frankfurt (eu-central-1)、Ireland (eu-west-1)
技术规格
| 规格 | 详情 |
|---|---|
| 操作系统 | Linux |
| 架构 | ARM64、x86_64 |
| Python 版本 | 3.11、3.12、3.13、3.14 |
| 最长会话时长 | 14 天 |
| 部署格式 | Zip、Container (OCI) |
| GPU 支持 | 是（GPU 实例类型） |
| 存储 | Amazon EBS、AgentCore Memory |
| 网络 | VPC 集成、安全组 |
对 Agent 基础设施领域的意义
Runtime Instances 代表 AWS 承认了一个事实：agent 需要的不只是临时计算。Agent runtime 层正在成为一个一级基础设施类别，AWS 把它直接建进了 Bedrock，而不是让团队自己用 EC2 搭配自定义编排来凑合。
对于正在评估agent 沙箱和 runtime 的团队，Runtime Instances 给版图增加了一个选项——一个深度集成 AWS 生态（IAM、VPC、CloudWatch、Bedrock 模型）、由 EC2 成熟基础设施支撑的选项。
14 天会话限制和多 agent co-location 是最重要的特性。它们让之前只有自管基础设施才能实现的工作流模式成为可能：持久的研究助手、长期运行的开发环境、跨天的数据管线、以及共享上下文而不需要外部协调的协作 agent 团队。
常见问题
能在同一个应用中混用 microVM 和 Runtime Instances 吗？
可以。两者都是 AgentCore Runtime 的计算选项。你可以根据时长、隔离要求或 GPU 需求把不同任务路由到不同计算层。同一份 agent 代码用 @app.entrypoint 模式部署到两者。
14 天会话到期后会怎样？ 会话终止，实例被回收。AgentCore Memory 在会话之外持续存在，所以 agent 在新会话启动时可以回忆之前的上下文。EBS 卷可以配置为保留或在终止时快照。
有冷启动延迟吗？ 启动一个已停止的实例和启动一个 EC2 实例耗时相同（通常 30–90 秒，取决于实例类型）。这比 microVM 冷启动（亚秒级）慢，但对长时间运行的工作负载来说可以接受——启动时间被摊到数小时或数天的执行中。
能 SSH 进 Runtime Instance 吗？ 不能。Runtime Instances 是托管基础设施。你通过 AgentCore API、日志（CloudWatch）和部署接口与它们交互。不提供底层 EC2 实例的 shell 访问。
支持哪些实例类型？ 标准 EC2 实例系列，包括计算优化、内存优化和 GPU 实例。具体可用性因区域而异。查看 AgentCore 定价页面获取当前列表。
和直接在 EC2 上跑 agent 比有什么区别？
Runtime Instances 增加了托管的会话生命周期（14 天持久化、停止/重启）、AgentCore 部署模型（@app.entrypoint）、集成记忆、多 agent 路由和健康监控。你获得相同的 EC2 性能，不用自己管编排。代价是管理费和对实例配置更少的控制。
能用自定义 Docker 镜像吗？ 可以。容器部署接受任何 OCI 兼容镜像。你可以安装任意依赖、系统包和 Python 之外的 runtime。唯一要求是你的镜像暴露 AgentCore entrypoint 接口。
