AWS、微软、谷歌和 Anthropic 悄悄做了同一件事：Session 正在取代请求，成为 Agent 的新计算单元

当一家公司在架构上做调整可能是战术选择。当四家同时做出同一个方向的改动那就是趋势在敲门。过去几个月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 AgentCoreMicrosoft FoundryGoogle Agent EngineAnthropic Managed Agents隔离原语Firecracker 微VMVM 沙箱代码执行沙箱循环内保留请求级HarnessStateless SandboxSession 生命周期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 架构对比