AgentCore Runtime V2 上线前，先问清隔离与生命周期的六个问题

托管运行时的迁移成本，通常不在于“能不能跑起来”，而在于跑起来之后，隔离边界和生命周期责任落在谁身上。AgentCore Runtime V2 这次改动的两件事恰好都在这一条线上：会话内存改为按需分页、变冷时归还；新实例改为从预先生成的环境快照恢复。前者决定“一段会话占用多少资源、占多久”，后者决定“一台新实例从哪个状态开始”。把这两件事拆开，隔离与生命周期该问什么就清楚了。

需要先说明材料边界：以下事实来自 AWS 于 2026 年 11 月 9 日发布的周报，本文转述其中的描述，未独立核验；周报之外的细节，本文一律标为待核实。

先确认 V2 究竟改了什么#

按该周报的描述，接入方式是创建或更新运行时时设置 platformVersion 为 V2，改动只在原有运行时的一个字段上（AWS Weekly Roundup，2026-11-09）。行为上有两处变化：

• 内存：会话从小规格起步，按需调入更多内存，变冷时归还，而不是一直持有峰值，因此按实际使用量计费。
• 冷启动：运行时把环境准备一次并生成快照，每个新实例从该快照恢复。团队测试中，镜像从 200 MB 到 2 GB，P75 冷启动保持在约 2 秒；原运行时在同一区间从约 5.4 秒升到接近 30 秒。

同一份材料还给出三条工程约束：创建和更新需要数分钟来准备快照；容器必须在 120 秒内在 /ping 上报告健康，并且只应在初始化完成后才报告健康；V2 在 10 个区域可用，承诺基线定价尚未发布。

这里有一个容易被读错的点：材料描述的快照是环境快照，作用对象是“新实例的启动”。它不能反过来推断会话状态会被持久化、会在实例之间迁移，或会在缩容后保留。会话状态的归属，本次材料没有涉及。

隔离：四个需要单独确认的边界#

一、会话与实例是什么对应关系

这个问题决定故障半径。若一个实例严格承载一个会话，某个会话把内存打满，影响面就是它自己；若一个实例承载多个会话，内存归还与分页就变成同一实例内多会话之间的资源竞争问题。V2 让内存“按需调入、变冷归还”，本质上是把内存从“实例属性”推向“会话属性”，这会让多会话共置的调度策略更值得追问。

本材料是否回答：没有。需查官方文档中关于并发会话数、实例复用与资源上限的说明。

二、内存归还之后，状态去哪

“变冷时归还内存”是一句关于资源的话，不是一句关于状态的话。会话在归还后是被挂起、被销毁，还是下次触达时重建，直接决定你的应用要不要自己做外部状态存储。如果你的 agent 在内存里累积对话上下文、检索缓存或工具调用中间结果，这条必须在上线前有明确答案，而不是靠观测发现。

本材料是否回答：没有。属于必须核实项，不要默认“会话会被保留”。

三、快照的作用域

既然每个新实例都从快照恢复，快照就是隔离面上的一块新拼图。至少有三问：快照按什么粒度生成（按运行时版本，还是按租户）？更新运行时生成新快照后，旧快照何时失效？快照中是否包含任何来自实际请求的数据？

需要强调，这是基于材料措辞提出的问题，不是结论。材料只说“准备环境、生成快照、为新实例恢复”，并未描述快照的内容构成与保留策略。

四、网络、凭据与日志

这三项在任何托管运行时上都要问，但在 V2 下有一个额外理由：启动路径变了。实例从快照恢复而非从零初始化，意味着“实例启动时会执行哪些初始化代码”这件事本身需要重新确认。如果你的凭据获取、证书加载或日志上报依赖启动阶段的某段逻辑，就要验证它在恢复路径上是否同样被执行。

本材料是否回答：没有。

生命周期：把三段分开算#

准备段

创建和更新运行时需要数分钟准备快照。这段窗口对发布流程有直接影响：它不是一个瞬时操作，滚动更新、回滚和容量变更都要把这几分钟计入。灰度期间新旧版本能否并行、并行多久，材料未涉及。

恢复段

恢复是 V2 的收益来源，也是不确定性最集中的一段。团队测试给出的约 2 秒是 P75，意味着仍有四分之一的启动慢于该值；材料没有给出 P99 或尾部最大值。做超时与重试设计时，P75 不是合适的输入。

回收段

回收段对应“变冷归还内存”。它影响的不只是账单，还有延迟分布：一个刚被回收的会话，下一次请求可能落在冷路径上。如果你的接口有严格的尾延迟目标，需要把“冷会话首次触达”的延迟单独测量，而不是混在整体平均值里。

健康检查是接口约定，不是形式#

材料给的约束很具体：容器须在 120 秒内在 /ping 上报告健康，并且只应在初始化完成后报告健康。这两句合起来的意思是，健康检查表达的是“可服务”，不是“进程活着”。

下面是一个示意骨架，未执行，端口与路径均为占位，不代表真实契约：

# 未执行的示例：仅示意“初始化完成后才报健康”的状态机
# 路径与语义以官方文档为准
from http.server import BaseHTTPRequestHandler, HTTPServer

_state = {"ready": False}

def warm_up():
    # 加载模型、建连接池、预热缓存等
    ...
    _state["ready"] = True

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        if self.path != "/ping":
            self.send_error(404)
            return
        self.send_response(200 if _state["ready"] else 503)
        self.end_headers()

代码里的 503 只是示意“尚未就绪”，平台是否把它当作“未就绪”而非“启动失败”，材料未说明，需核实。同样待核实的还有：初始化超过 120 秒会怎样、健康检查失败后的重试与摘流策略是什么。

成本口径变了，容量规划的方法也要跟着变#

材料明确写了三点：单位价格更高；GB-hours 大幅减少；团队预计多数 agent 的账单会更低，但“并不保证”。这三句话合在一起，说明旧的估算方法已经失效——不能再拿“峰值内存 × 运行时长”去乘单价。

可以自测的输入至少有三个：单会话的内存随时间曲线（用来估 GB-hours）、并发会话数与冷热比例（用来估回收频率）、以及冷启动的尾部延迟。需要注意，团队测试的约 2 秒只覆盖 200 MB 到 2 GB 的镜像区间，且是 P75；把镜像做得更小是否继续获益、超出该区间的表现如何，材料都没有给出。

交给架构评审的核对表#

V2 的切换动作确实只有一个字段，但评估不是。把上表里“未提供”的几行先在官方文档或支持渠道问出答案，再决定切换窗口，比先切过去再观测要便宜得多。