Agent 已不再只是实验。它们处理理赔申请、编写和审查代码、协调跨系统任务，并可在无人监督的情况下持续运行数小时。随着 Agent 承担更复杂、运行时间更长的工作，其底层基础设施也必须以同样快的速度演进。

我们构建 Amazon Bedrock AgentCore，旨在帮助开发者以安全且可扩展的方式构建、连接和优化 Agent。作为 Amazon Bedrock AgentCore 的一项能力，AgentCore runtime 是一层托管计算层，为开发者提供完全托管的环境，用于部署和运行 Agent，而无需自行构建或维护基础设施。

自发布以来，已有数千个团队使用它来运行生产级 Agent。每一次与这些团队的交流，都让我们进一步了解 Agent 接下来所需要的能力：随着工作负载扩展实现更快的响应速度，对资源分配进行更精细的控制，以及能够精确反映实际使用量的成本模型。

今天，我们宣布推出全新的 AgentCore runtime，它专为满足生产级 Agent 对速度、灵活性和成本效率的需求而构建。

它带来了更好的内存管理：会话释放内存后即可回收，而不再始终维持在峰值水平。无论容器大小或 Agent 并发度如何，它还可提供一致的冷启动时间。您将获得此前已熟悉的无服务器模式，但具备更强的弹性：会话结束时，内存立即被释放回系统；无论规模或并发度如何，启动时间都保持一致；费用则随您的 Agent 实际完成的工作而变化。

从对话到工作负载

许多 Agent 最初是聊天机器人：您提问，它回答，交互在几秒内结束。随后出现了编码 Agent，它们可工作数分钟到数小时，在多个步骤中保持上下文，并在您观看或离开时继续运行。如今，Agent 正变得无处不在、始终在线：由事件触发、无人值守地运行，只有在任务完成或遇到需要人工决策的情况时才会出现。而且它们的数量远远更多：不再是新奇事物，而是在各处运行。它们嵌入产品之中，支撑日常功能，并且越来越多地由其他 Agent 发起。

第一版 AgentCore runtime 为覆盖这一完整范围的 Agent 奠定了坚实基础：无服务器、会话隔离、可缩容至零，以及仅按实际使用量付费。今天发布的新版 runtime 将这一基础扩展至整个 Agent 范围：为交互式 Agent 保持快速且一致的体验，同时为长时间运行、更具自主性的 Agent 提供持久性和经济性。

AgentCore runtime 提供什么

借助 AgentCore runtime，您可以专注于 Agent 本身，而不必担心其底层所需的可扩展基础设施。有两项能力使这成为可能，也是客户选择它的原因：

1. 您仅为实际消耗的资源付费，而无需为等待 I/O 的空闲 CPU 付费。计费跟随资源使用情况，因此无需为“以防万一”预留的容量支付固定费用。
2. 平台可一路扩缩至零。当 Agent 不处理工作时，没有任何资源在运行，也无需支付任何费用。当工作到来时，平台会提供您所需的容量。

二者结合后，无论是让大量 Agent 大部分时间保持空闲，还是运行一个持续繁忙的 Agent，成本都可以很低。该按量消费模式会适应工作负载，而不是迫使工作负载去适应它。

随着 Agent 从短暂的问答会话转向无处不在、始终在线的工作模式，这一模式也面临两项挑战。

内存成本高，而如今您需要为峰值付费。 会话从分配内存的那一刻起，直到会话结束都会占用该内存，因为期间没有机制将其回收。当分配的内存用于服务后续资源请求，从而避免再次获取资源的延迟时，这种方式是有效的。然而，长时间运行或流量突发的 Agent，即便在停止使用这些内存后，仍会在整个运行期间持续为其峰值内存付费。对于一个偶尔出现内存峰值、但一天中大多数时间都处于空闲状态的 Agent，这意味着全天按峰值付费与按实际使用量付费之间的巨大差异。

启动时间存在波动。 每个新会话在开始任何工作之前都必须启动，因此快速、可预测的启动对于良好体验至关重要。当用户正在等待一个因等待输入而暂停、现在需要恢复的 Agent 时，这一点尤为重要。问题在于这些会话所依赖的硬件强制隔离：落在已初始化环境中的会话可在 100 毫秒内启动，但为了保证这一点，需要持续保留足够多的热环境，也就是预留计算资源。因此，大多数会话都会以冷启动开始：启动一个全新的环境、拉取镜像，并在首次请求运行前初始化 Agent。随着镜像大小和并发度增加，这种延迟代价也会增长；而在突发流量下情况最严重——恰恰是在多数会话到达、可用环境最少的时候。这种不一致性正是等待中的用户所能感受到的。

变通方案负担沉重。 为解决这两项挑战，客户通常需要自行构建相关机制：保留备用环境以避免请求发生冷启动、优化内存分配，并在之后将其全部拆除以控制账单。提前为需求准备容量，对于任何团队而言都既昂贵又复杂。无论这些计算资源是否在工作，它都会占用稀缺的计算能力；当突发流量超过预留容量时，它仍然会失效。这些工作并没有差异化价值，而且没有一项是 Agent 本身。

新版 AgentCore runtime 的优势

增强版 AgentCore runtime 会为您处理这两项挑战，首先是降低内存消耗，并将资源使用精确追踪到实际用量。新版 runtime 现在会以小型、高效的内存配置启动每个会话，而不是使用完整的预置资源占用。随着工作负载需要，系统将按需分配并调入额外内存。基于对数十亿次会话分配模式的分析，我们对新版 runtime 进行了调优：当内存变冷且不太可能再次被访问时，系统会将其回收。它不再一直持有这些内存直到会话结束。在原版 runtime 中，即使后续请求不再使用已分配的内存，内存仍会被占用，因此资源使用量会跟随高水位线。使用新版 runtime 后，被释放或变冷的内存将被回收，账单也会在整个会话生命周期内反映这些变化。

图 1：原版 runtime 与新版 runtime 的会话内存使用情况对比

更快、更一致的冷启动是更小启动配置直接带来的收益。增强版 runtime 会预先准备一次环境、创建快照，并为每个新实例恢复该快照。由于快照始终保持较小且一致，启动时间也同样如此，无论镜像大小或运行的并发量如何。平台不再在每次冷启动时重复执行引导和初始化工作，而是恢复一个已完成启动的环境。runtime 现在可在一个较小且可预测的区间内提供一致的启动时间。

我们的测量方法。 为隔离平台本身对冷启动增加的时间，我们测试了一个空的回显 Agent：它返回输入内容，且不调用任何模型或工具。计时结果反映的是 runtime 的启动路径，而不是任何应用程序工作。位于 us-west-2 的 Amazon Elastic Compute Cloud（Amazon EC2）实例上的 Python 客户端，通过公网调用 us-east-1 中的 Agent，未使用虚拟私有云（VPC）对等连接，并使用 boto3 SDK。这些都是客户端侧数据，因此每个数据均包含两个 AWS 区域之间的往返时间，以及平台自身的启动时间。我们在默认账户配额内，针对两个版本和五种镜像大小的每个 Agent 发送了 5,000 次冷调用。

按照这一测量方法，新版 runtime 对从 200 MB 到 2 GB 的镜像均可提供约 2 秒的 P75 冷启动延迟，因为镜像大小不会对其产生影响。相比之下，原版 runtime 的延迟会随镜像大小增长，从约 5.4 秒上升至接近 30 秒。

为理解这一延迟的实际意义，有必要将冷启动延迟与用户等待时间区分开来。启动时间是指在您的 Agent 代码处理第一个请求之前，获取一个就绪环境所需的时间。它并不是 Agent 完成工作所花费的时间。在生产级 Agent 中，用户感知到的大部分实际耗时来自 Agent 循环及其模型调用，而每次模型调用通常就需要数秒。在我们的回显测试中，Agent 自身代码在 P75 下的运行时间约为 34 毫秒，因此此处几乎所有时间都是平台启动时间。新版 runtime 让启动时间中的平台部分变得快速且可预测，这在用户等待交互式 Agent 时尤为重要。

面向交互式 Agent 的实用建议。 您几乎可以完全隐藏启动时间：在用户开始交互时便启动会话，例如在其打开聊天窗口时，而不是等到其在输入框中提交内容之后。会话会在用户看到欢迎信息和输入第一个请求的过程中完成预热，因此等到他们发送消息时，环境已经准备就绪。

图 2：原版和新版 runtime 在不同镜像大小下的 P75 冷启动延迟

新版 runtime 的工作原理

下一代 runtime 重新设计了会话使用内存的方式、Agent 的加载方式，以及您的付费方式。

1. 按需调入内存，并在其被释放时回收。 新版 runtime 不再在分配后持续保留会话的峰值内存，而是以更小的常驻资源占用来支撑会话，并在工作负载触及更多内存时再将其调入。当您的 Agent 释放内存，例如释放每请求缓冲区，以及让请求间缓存数据过期时，平台会将其收回，而不会让它一直处于占用状态直到会话结束。
2. 仅加载一次 Agent，然后创建快照。 当您创建或更新新版 runtime 的实例时，AgentCore 会启动您的容器并等待其报告健康状态，随后捕获运行环境的快照。此时，您的一次性初始化工作已经完成，因此加载模型工件、获取静态配置等工作都将被固化到快照中。随后，每个新实例都会通过恢复这一快照启动，而不是从头初始化。昂贵的启动工作只需支付一次成本，每个实例都会立即继承其结果。
3. 保持快照精简且大小稳定。 对运行中进程进行朴素的快照会捕获远超恢复实例所需的内容，包括缓存和瞬态内存；这些内容会使快照膨胀，并导致恢复时间随镜像大小增长。新版 runtime 会剔除这些冗余内容，使快照仅保留实例恢复运行所需的工作状态，而不是其完整的常驻内存占用。因此，即使容器镜像不断增大，快照大小仍大致保持稳定，这也是恢复延迟能在广泛镜像尺寸范围内保持稳定的原因。
4. 更高费率，更低账单。 新版 runtime 按您的 Agent 实际使用的内存计费：内存按需加载，并在空闲时回收；系统不再按会话期间将整个容器镜像保存在内存中的成本收费。虽然单位费率更高，但计费 GB 小时显著减少；对大多数 Agent 而言，资源占用的降幅超过费率的升幅，因此账单会下降。

下一步计划（即将推出）

除今天发布的内容外，还有多项能力即将推出，以便让您在定价、计算资源、兼容性和控制能力方面拥有更多选择。

承诺基线折扣。 当前按量计费模式将继续保留，并且非常适合流量突发和可缩容至零的工作负载。在此基础上，新版 runtime 将增加基线定价选项：您可为一个会话预留最低内存额度，并在需要时按需突发扩展。基线定价适合希望获得可预测成本、持续活跃的稳定 Agent 会话；按量计费则继续提供更强的弹性。

更大的计算和存储资源。 通过更多 RAM、vCPU 和会话存储空间扩展您的 Agent 环境。

x86 支持。 使用 x86 microVM 运行您现有的 Agent、工具或环境。其代码或依赖项面向 x86 的团队，可以原样将 Agent、工具或执行环境迁移至 AgentCore。

更强的生命周期控制。 通过内存快照挂起和恢复会话。在活动会话终止前连接 runtime 钩子以序列化状态，使会话能够无限期恢复。

面向无人值守 Agent 的范围限定身份。 无人值守 Agent 带来了聊天轮次从未提出过的问题：当没有人监督其行为时，这个 Agent 被允许做什么？会话上下文密钥将赋予每个会话独立的范围限定身份，使无人值守的 Agent、工具或环境仅以为其定义的权限行事，不会拥有额外权限。

开始使用

要开始使用新版 runtime，请在创建或更新 runtime 时将 platformVersion 参数设置为 V2。有关使用 runtime 的更多详细信息，请参阅 AgentCore 开发者指南。

您可在 AgentCore GitHub 示例仓库中找到示例。配套的负载测试示例展示了新版 runtime 的一致性

Agents are no longer experiments. They process claims, write and review code, coordinate across systems, and run for hours without supervision. As agents take on more complex, longer-running work, the infrastructure underneath them must evolve just as fast.

We built Amazon Bedrock AgentCore to help developers build, connect, and optimize agents securely at scale. AgentCore runtime, a capability of Amazon Bedrock AgentCore, is the managed compute layer that gives developers a fully managed environment to deploy and run agents without building or maintaining infrastructure.

Since launch, thousands of teams have used it to run production agents. Every conversation with those teams teaches us something about what agents need next: faster responsiveness as workloads scale, finer control over resource allocation, and economics that track actual usage precisely.

Today, we are announcing the new AgentCore runtime, purpose-built for the speed, flexibility, and cost efficiency that production agents demand.

It brings better memory management, reclaiming memory as a session releases it instead of holding it at the peak. It also delivers consistent cold start times regardless of container size or agent concurrency. You get the serverless model you already liked, now more elastic. Memory is released back the instant a session ends, startup times stay consistent regardless of size or concurrency, and the bill tracks the work your agent does.

From conversation to workload

Many agents started as chat bots: you asked, it answered, and the exchange ended in seconds. Then came coding agents that work for minutes to hours, holding context across many steps, running while you watch or step away. Now agents are becoming ambient, always on, triggered by events, running unattended, surfacing only when a job finishes or hits a decision that needs a person. And there are far more of them: no longer novelties but running everywhere. They are embedded in products, behind everyday features, and increasingly launched by other agents.

The first version of AgentCore runtime built a strong foundation for this spectrum of agents: serverless, session isolation, scale to zero, and pay only for what you use. Today’s launch of the new runtime extends that foundation across the full spectrum, staying fast and consistent for interactive agents, and durable and affordable for long-running, more autonomous agents.

What AgentCore runtime provides

With AgentCore runtime, you can focus on the agent instead of worrying about the scalable infrastructure needed underneath it. Two things make that possible, and they’re the reasons customers reach for it:

1. You pay only for what you consume, and not for idle CPU waiting for I/O. Billing follows resource usage, so there’s no standing charge for capacity you provisioned “just in case.”
2. The platform scales all the way down to zero. When an agent isn’t handling work, there’s nothing running and nothing to pay for. When work arrives, the platform gets you the capacity you need.

Together they make it cheap to keep many agents idle most of the time and even cheap to run one that stays busy. The consumption model bends to the workload instead of forcing the workload to bend to it.

As agents move from short question-and-answer sessions to ambient, always-on work, that same model runs into two challenges.

Memory is expensive, and today you pay the peak. A session holds on to memory from the moment it allocates it until the session ends, because nothing reclaims it along the way. This works when the allocated memory is used to serve subsequent resources without incurring the latency to fetch it again. However, a long-running or bursty agent keeps paying for its high point the whole time it runs, well after it has stopped using that memory. For an agent that spikes now and then but sits idle most of the day, that is the gap between paying for the peak around the clock and paying for the real usage.

Startup times vary. Every new session has to start before it can do any work, so fast, predictable startup is central to a good experience. It matters most when a person is waiting on an agent that paused for input and needs to resume. The catch is the hardware-enforced isolation these sessions depend on: a session that lands on an already-initialized environment starts in under 100 milliseconds, but keeping environments hot enough to guarantee that means holding compute in reserve. So most sessions begin with a cold start: booting a fresh environment, pulling the image, and initializing the agent before the first request runs. That latency penalty grows with image size and concurrency, and it’s worst under bursty traffic, exactly when most sessions arrive and the fewest ready environments remain. That inconsistency is what a waiting user feels.

The workarounds are heavy. To cover both challenges, customers often build the machinery themselves: holding spare environments ready so requests avoid a cold start, optimizing memory allocation, and tearing it all down again to keep the bill in check. Keeping capacity ready ahead of demand is costly and complex for anyone to run. It reserves scarce compute whether or not that compute is working, and it still gives way when a burst outruns what was set aside. This is undifferentiated work, and none of it is the agent itself.

Benefits of the new AgentCore runtime

The enhanced AgentCore runtime takes care of both challenges for you, starting with lower memory consumption tracked to what you use. The new runtime now starts each session from a small, efficient memory profile rather than a full provisioned footprint. Additional memory is allocated and paged in on demand as the workload needs it. Based on an analysis of allocation patterns across billions of sessions, we tuned the new runtime to reclaim memory when it goes cold and is unlikely to be accessed again. It no longer holds that memory until the session ends. With the original runtime, allocated memory remained held even if it wasn’t used by subsequent requests, so the usage tracked the high watermark. With the new runtime, memory that is released or goes cold is reclaimed, and the bill tracks those changes over the lifetime of the session.

Figure 1: Session memory usage for the original runtime compared to the new runtime

Faster, more consistent cold starts come as a direct benefit of smaller profiles at startup. The enhanced runtime prepares the environment once, snapshots it, and restores that snapshot for each new instance. Because the snapshot stays small and consistent, so do the starts, no matter the image size or how much concurrency you run. Rather than repeating the boot-and-initialize work on every cold start, the platform restores an environment that is already up. The runtime now delivers consistent starts in a tight, predictable range.

What we measured. To isolate what the platform itself adds to a cold start, we tested an empty echo agent that returns its input and calls no model and no tools. The timing reflects the runtime’s start path rather than any application work. A Python client on an Amazon Elastic Compute Cloud (Amazon EC2) instance in us-west-2 called agents in us-east-1 over the public internet with no virtual private cloud (VPC) peering, using the boto3 SDK. These are client-side numbers, so each one includes the round trip between the two AWS Regions on top of the platform’s own start time. We sent 5,000 cold invocations per agent across both versions and five image sizes, within default account quotas.

Measured this way, the new runtime delivers a P75 cold start latency of about 2 seconds from a 200 MB image all the way to 2 GB, because image size has no effect on it. The original runtime’s latency, by contrast, rises with image size, from roughly 5.4 seconds to nearly 30 seconds.

To put this latency in perspective, it helps to separate cold start latency from what a user waits on. Start time is how long it takes to get a ready environment before your agent code handles its first request. It is not the time the agent spends working. In a production agent, most of the wall-clock time a user experiences comes from the agent loop and its model calls, often several seconds each. In our echo test, the agent’s own code ran in about 34 milliseconds at P75, so nearly everything here is platform start time. The new runtime makes the platform’s portion of the start time fast and predictable, which matters most when a person is waiting on an interactive agent.

A practical tip for interactive agents. You can hide the start time almost entirely by beginning the session as soon as the user engages, for example when they open a chat, even before they type in the input box, rather than waiting for them to submit. The session warms while they are greeted and while they type their first request, so by the time they send that message, the environment is ready.

Figure 2: P75 cold start latency across image sizes for the original and new runtime

How the new runtime works

The next generation of the runtime reworks how sessions use memory, how agents load, and what you pay for.

1. Page memory in on demand and reclaim it when it is freed. Instead of holding on to a session’s peak memory after it’s allocated, the new runtime now backs the session with a smaller resident footprint and brings in more memory as the workload touches it. When your agent lets memory go, by releasing per-request buffers and by letting cached data expire between requests, the platform takes it back rather than letting it stay claimed until the session ends.
2. Load the agent once, then snapshot it. When you create or update an instance of the new runtime, AgentCore launches your container and waits for it to report healthy, then captures a snapshot of the running environment. By that point, your one-time initialization has already run, so work such as loading model artifacts and fetching static config is baked into the snapshot. Every new instance then starts by restoring that snapshot rather than initializing from scratch. The expensive startup work is paid once, and each instance inherits it instantly.
3. Keep the snapshot small and its size steady. A naive snapshot of a running process captures far more than a restored instance needs, including caches and transient memory that pad the snapshot and make restore time grow with image size. The new runtime strips that excess, so the snapshot holds only the working state an instance needs to resume, not its full resident footprint. The result is a snapshot whose size stays roughly flat as the container image grows, and that is what holds restore latency steady across a wide range of image sizes.
4. Higher rate, lower bill. The new runtime bills you for the memory that your agent uses, loaded on demand and reclaimed when idle, not for holding your whole container image in memory all session. You pay a higher rate but on far fewer GB-hours, and for most agents the footprint drops more than the rate rises, so the bill goes down.

What’s next (coming soon)

Beyond what we shipped today, several capabilities are on the way to give you more choice over pricing, compute, compatibility, and control.

Committed baseline discounts. Today’s consumption-based pricing stays and works well for spiky and scale-to-zero workloads. Alongside it, the new runtime will add a baseline pricing option: you reserve a memory floor for a session and burst above it on demand. Baseline pricing suits steady, always-active agent sessions that want predictable cost, while consumption pricing continues to provide greater elasticity.

Larger compute and storage. Expand your agent’s environment with more RAM, vCPU, and session storage.

x86 support. Run the agent, tool, or environment you already have with x86 microVMs. Teams whose code or dependencies target x86 can move an agent, a tool, or an execution environment to AgentCore as-is.

Greater lifecycle control. Suspend and resume sessions with memory snapshotting. Attach to runtime hooks to serialize state before an active session terminates, so sessions can resume indefinitely.

Scoped identity for unattended agents. Unattended agents raise a question a chat turn never did: what is this agent allowed to do when no one is watching it act? Session context keys will give each session its own scoped identity, so an unattended agent, tool, or environment acts with exactly the permissions defined for it and nothing more.

Getting started

To get started with the new runtime, set the platformVersion parameter to V2 when you create or update a runtime. See the AgentCore Developer Guide for more details on using the runtime.

You can find samples in the AgentCore GitHub samples repo. An accompanying load test example shows the new runtime’s consistent cold start latency in your own AWS account.

---

About the authors

Evandro Franco

Evandro is a Sr. Data Scientist working on Amazon Web Services. He is part of the Global GTM team that helps AWS customers overcome business challenges related to AI/ML on top of AWS, mainly on Amazon Bedrock AgentCore and Strands Agents. He has more than 18 years of experience working with technology, from software development, infrastructure, serverless, to machine learning. In his free time, Evandro enjoys playing with his son, mainly building some funny Lego bricks.

Mark Roy

Mark is a Principal AI Architect for AWS, helping customers design and build agentic AI solutions. Mark’s work covers a wide range of use cases, with a primary interest in AI agents at enterprise scale. He is a worldwide tech lead for Agentic AI, including Bedrock AgentCore. Mark has helped companies in insurance, financial services, media and entertainment, healthcare, utilities, and manufacturing. Prior to joining AWS, Mark was an architect, developer, and technology leader for over 25 years, including 19 years in financial services.

Shishir Bharathi

Shishir is a Principal Engineer in AWS, currently building Amazon Bedrock AgentCore Runtime. His experience spans the full agentic stack, drawing on deep work across AI systems, from developing conversational agents in Alexa and LLM post-training and customization to recommender systems in Prime Video. He now focuses on making the infrastructure that powers production agentic systems more reliable, efficient, and scalable.

Abhishek Singh

Abhishek is a Senior Software Development Engineer at AWS on the Bedrock AgentCore team. He is the tech lead for AgentCore Runtime and has led the design and development of multiple AgentCore services from the ground up, including Runtime, Code Interpreter, and Browser. He has 12 years of experience building distributed systems, previously on Bedrock and SageMaker. Outside of work, he likes playing soccer and tennis, and spending quality time with family.

Aniketh Manjunath

Aniketh is a Software Development Engineer at AWS on the Amazon Bedrock AgentCore team, working on AgentCore Runtime with a focus on the performance and efficiency of agent execution at scale. He has over five years of experience building large-scale distributed systems at Amazon, previously on Amazon SageMaker, and now works on making the infrastructure behind production agentic systems faster and more reliable as it scales to meet growing demand. Outside of work, he enjoys hiking, watching movies, and playing cricket.

Rahul Nama

Rahul is a Software Development Engineer at AWS, where he builds AgentCore Runtime systems that enable AI agents to run reliably at scale. He is passionate about building distributed systems and optimizing infrastructure to simplify the lifecycle of AI agents. Outside of work, he plays semi professional cricket and enjoys exploring the outdoors.