AWS 于 2026 年 8 月 6 日宣布 Amazon Bedrock AgentCore Runtime Instances，作为原有 microVM runtime 以外的另一种 production compute 选项。它由 AWS 管理背后的 EC2 infrastructure，让 agent 可以在更持久的执行环境中保留 session 和计算资源，而不只是在每次请求时启动一个短生命周期的 sandbox。
Runtime Instances 可以在同一个 runtime 内运行多个 agents，并支持最长 14 天的 shared sessions。AWS 也列出 stop 和 restart、GPU、container deployments 等能力。这种设计适合需要长时间处理任务、保留工作目录，或在多个 agent 之间传递中间状态的 workflow，但 session 寿命越长，权限、数据清理和资源隔离也越重要。
AWS 表示，Runtime Instances 可以和 EBS 及 AgentCore Memory 配合。EBS 提供持久存储，Memory 则用于跨 session 的长期 recall；两者处理的是不同层次的状态。企业如果把两者一起使用，就要清楚界定哪些数据只是临时工作文件，哪些数据可以进入长期记忆，以及数据保留多久。
这个新选项仍沿用 AgentCore 的 API、identity controls 和 observability。AWS 将它定位为同一套 agent 平台内的 compute 取舍，而不是另起一个部署模型。Runtime Instances 也支持 agent-to-agent communication：一个 agent 可以把另一个 agent 当作 tool 调用，并共享文件系统和 session context。
在开发框架方面，AWS 表示它不绑定单一 framework 或 model，可配合 CrewAI、LangGraph、LlamaIndex 和 Strands 等工具。平台支持 Linux ARM64 和 x86_64、Python 3.11 至 3.14、container，以及 GPU workloads。AWS 公告列出的 launch regions 包括美国东部 Ohio、Virginia、Oregon，以及 Mumbai、Singapore、Sydney、Tokyo、Frankfurt 和 Ireland。
成本模型也和短生命周期的 invocation 不同。AWS 表示 Runtime Instances 按标准 EC2 pricing 加上 AgentCore management fee 计算；实际费用会受 instance type、GPU、运行时间、存储、流量和地区影响。这些是 AWS 公布的产品和价格说明，采用前仍应按最新区域文档及自己的 load pattern 计算，不能只用一次请求的 token 成本估算。
对于 production agent 而言，Runtime Instances 的价值在于把 session、工具、文件和 agent-to-agent 协作放进同一个可管理的计算边界。相对地，团队需要处理长 session 的 stale credentials、跨 agent 的数据权限、重启后的 idempotency、GPU 利用率和租户隔离。持久计算减少启动摩擦，但不会自动解决 workflow reliability。
这次更新反映 agent infrastructure 正由「每次调用一个 runtime」走向「按工作类型选择持久或短暂的 execution」。短任务可以维持轻量 sandbox，长任务或需要本地状态的流程则可考虑 Runtime Instances。真正的选择仍应由 session 生命周期、数据治理、可观察性、失败恢复和总成本共同决定。
