当一家公司在架构上做调整，可能是战术选择。当四家同时做出同一个方向的改动，那就是趋势在敲门。过去几个月，AWS、微软、谷歌和 Anthropic 几乎在同一时间更新了各自的 Agent 运行时——不是推出新的推理模型，不是发布更聪明的开发工具，而是围绕同一个抽象重构了整个执行层：会话（Session）。Session 正在替代单个请求，成为 Agent 基础设施调度的新计算单元。这件事的影响，可能比 GPT-5.6 的发布更深远。
开篇：当一个请求不再是独立的
理解这个转变，需要回看传统云架构的底层逻辑。
过去二十年，几乎所有的 Web 服务和微服务体系都建立在两个假设之上：请求之间相互独立，任何后端节点都可以服务任何请求。负载均衡器（NGINX、HAProxy）把每个进来的请求发给下一个空闲的 worker，状态小心翼翼地外置到 Redis 或数据库里，从而实现了弹性伸缩和容错替换。这套模型支撑了人类历史上规模最大的在线系统。
但 Agent 的出现同时打破了两个假设。
Agent 不是普通的 API 调用。它是一个长运行、有状态、会调用外部工具的进程，更关键的是——它会执行由用户输入驱动的代码。想象一个企业客服 Agent 在处理退款：它读取订单、调用工具、等待模型回复、再追问澄清。如果这个追问被路由到另一个没有前序上下文的节点，整个工作流就断了。
更危险的是隔离问题。当 Agent 执行的代码来自用户输入时，计算后端不再是一个通用的运算目标，而是一个需要严格隔离的安全边界。共享内核无法给这类不可信代码提供企业安全团队要求的租户级隔离。Session Affinity（会话粘性）可以解决路由连续性，但解决不了跨租户的数据泄露。
这不是理论推演。2025 年 6 月 Asana 曝出的 MCP 服务器漏洞就是活生生的案例：一个身份验证通过但未在缓存后台一致检查 Agent 和租户上下文的服务器，导致约 1000 个组织能看到其他客户的项目数据——没有外部攻击者，数据还是跨了边界。
四巨头解法：隔离原语大不同
四家公司的解法在路由层惊人地一致：用 Session 作为新的调度单元，并围绕它建立隔离、生命周期和计费体系。区别主要在底层的隔离原语上。
AWS AgentCore：最重的方案
每个 Session 获得一个独立的 Firecracker 微虚拟机，分配独享的算力、内存和文件系统。携带相同runtimeSessionId的请求通过 Session Header 被路由回同一个微 VM。Session 结束时，微 VM 被销毁，内存被清理。核心参数：15 分钟空闲超时，8 小时最大生命周期。
微软 Foundry：更长周期的 VM 沙箱
它为每个 Agent 创建按需的 VM 隔离沙箱，运行后即销毁，没有副本计数，没有预热池。每个 Agent 有独立的 Entra 身份。超时参数更宽松：15 分钟空闲超时，30 天最大生命周期——明显为长运行 Agent 设计。
谷歌 Agent Engine：最有趣的混合方案
它在推理循环内部保留请求级伸缩能力，提供可配置的实例数和 container_concurrency 参数（默认 9）。但谷歌干了一件关键的事情：把不可信代码执行放到隔离的 Code Execution Sandbox 里，把对话状态外置到 Sessions 和 Memory Bank。它保留了负载均衡器在循环中，但拒绝让负载均衡器直接触碰有状态的不可信工作负载。
Anthropic Managed Agents：最清晰的架构
Anthropic 给出了最清晰的三层分解：Session（记录一切）、Harness（运行循环、路由工具调用）、Sandbox（执行代码）。Harness 变成近乎无状态的控制面，Sandbox 则是可随时重组的可调用资源。和 Cloudflare 的集成展示了这种分解的弹性：Agent 循环跑在 Anthropic，每次工具调用跑在 Cloudflare 的沙箱里——可以是完整的微 VM，也可以是更轻量的 V8 Isolate。
| 维度 | AWS AgentCore | Microsoft Foundry | Google Agent Engine | Anthropic Managed Agents |
|---|---|---|---|---|
| 隔离原语 | Firecracker 微VM | VM 沙箱 | 代码执行沙箱（循环内保留请求级） | Harness（Stateless）+ Sandbox |
| Session 生命周期 | Active → Idle(15min) → Terminated(8h max) | 按需创建/销毁，空闲 15min，最长 30 天 | 会话状态外置 + 沙箱隔离 | 三层虚拟化，Harness 可配合 Cloudflare 沙箱 |
| 身份绑定 | 不强制执行 Session-User 映射 | 每个 Agent 独立 Entra 身份 | 应用层自行管理 | 应用层自行管理 |
| 核心差异 | 最重隔离，最适合高安全场景 | 最长生命周期，适合多日研究型 Agent | 保留弹性伸缩，适合高吞吐量自动化 | 架构最清晰，Harness-Sandbox 可灵活组合 |
更深层的变化：从调度到控制面
仔细看这四家方案的共性，会看到一个更深层的趋势：Session 不再仅仅是路由的单元，它成了控制面的核心抽象。
传统上，Session Affinity 只是一种性能优化——把请求粘到同一台机器上减少缓存未命中。但在 Agent 运行时里，Session 绑定变成了正确性和安全性的要求。新的控制面在第一次见到 Session Key 时创建执行环境，路由工作到它，在空闲超时或生命周期结束时销毁它。它不是负载均衡器的进化，而是一个全新的调度层。
AWS 2018 年开源的 Firecracker 微 VM 当年就被认为是颠覆性的：微 VM 级别隔离 + 容器级别速度。如今同样 5MB 大小的微 VM 支撑着 Lambda 和 Fargate 每月数万亿次执行。Session 时代的到来，本质上是云基础设施在 Agent 这个新工作负载驱动下，对现有原语的重新组合。Firecracker 这个七年前奠定的底层能力，终于等到了它的原生场景。
计费模型也在同步进化。当计费与 Active Session 绑定，并发度、空闲时间和 Agent 规格就成了成本驱动因素——而不是请求量。对平台团队和财务部门来说，这意味着一个全新的成本模型。更恰当的心智模型不再是传统负载均衡器，而是更接近虚拟 Actor 运行时：一个可寻址的身份按需实例化，活跃时保持运行，空闲时回收，每个 Key 只有一个活跃实例。
三个问题，每一个构建 Agent 的企业都要想清楚
1. 成本模型的重构
按 Session 计费意味着并发度成了直接的成本变量。如果你的 Agent 有大量空闲等待的 Session，成本会比预想的上升更快。平台团队需要重新理解 Agent 的计费模式，从"按调用付费"切换到"按活跃会话付费"。
2. 身份绑定的责任归属
AWS AgentCore 明确声明不强制执行 Session 到用户的映射——平台层解决隔离和生命周期，把身份映射、授权和租户上下文交还给应用层。Asana 事件说明，平台层的隔离做对了，但如果应用层的用户-Session 绑定没做好，数据依然会泄露。企业买家需要问自己：这个绑定归谁管，在多租户并发负载下如何测试？
3. 隔离原语的选择
微 VM 还是轻量 Isolate？这取决于你的工作负载类型。多日研究型 Agent 需要 Azure 那样长生命周期的 Session；代码密集型 Agent 需要 AWS 那样微 VM 级别的隔离；高吞吐自动化则适合更轻量级的方案。多数企业最终会组合使用多种模式。
归根结底，Agent 不再只是模型能力的竞争。Agent 正在成为云基础设施的一等公民，Session 就是它的新计算单元。那些早期在这个维度上做出正确架构选择的企业，将在 Agent 大规模落地时拥有真正的竞争力——不是因为他们有更好的模型，而是因为他们有更合理的运行时基础设施。
当 AWS、微软、谷歌和 Anthropic 在同一件事上达成共识，开发者应该认真对待这个消息。这不是某个产品的升级公告，而是下一代计算范式的路标。
封面图：信息图解风，展示四大云厂商 Session 架构对比
