同一周里发生了两件事。分开看，都是各自公司的产品发布；放在一起看，就很不一样。
9 月 22 日，2026 云栖大会在杭州开幕，阿里云智能集团 CTO 李飞飞系统阐述了「Agentic Cloud」战略，一口气拿出 AgentCore、Agent Sandbox、Context Engine，以及新的算力与存储底座。而就在两天前，Google 的 Agent Executor（简称 AX）发布 v0.3.0，随后冲上 Hacker News 首页第一。
两家的表达方式完全不同——一个在讲「企业级 Agent 的生产力底座」，一个在讲「Agent 是一种新的工作负载」。但它们做的是同一件事：把「怎么让 Agent 稳定地跑起来」这件事，做成产品。
这篇先把两件事的事实摆清楚，再说它们为什么撞在同一个点上，以及这对做 Agent 的人意味着什么。
事实梳理一：阿里云发布 Agentic Cloud
（来源：2026 云栖大会现场，新华网、上海证券报·中国证券网、潮新闻等媒体报道）
先看会议本身：2026 云栖大会 9 月 22 日在杭州国际博览中心开幕，会期三天，主题「智以致用」，以 Agentic AI 为核心，设三大主论坛、140 余场分论坛，联合超 1000 家企业，参展企业数量较去年翻倍。
李飞飞给出的框架可以拆成三层加四柱：
- 三个核心构建场景：Model、Harness、Context。分别对应「模型生产」「自主运行与持续进化」「实时智能决策」。技术栈的表述是从 AI Native Cloud，到 Agent Native Cloud，再到 Context Engine。
- 四大能力支柱：以全面、统一、持续更新的上下文形成全域认知；支持自主运行与持续进化；融入安全、控制、信任与身份认证，实现人与 Agent、Agent 之间的可信协作；从静态规则走向实时感知、动态推理和自主行动。
- 新产品：企业级 Agent 构建治理平台 AgentCore（把企业级 Agent 基础设施标准化、托管化，明确支持长任务、失败重试、断点恢复和异步执行）、Agent Sandbox、新一代全栈自研高性能存储 CPFS，以及大模型 KVCache 管理和调度系统 Tair KVCM。人工智能平台 PAI 新增支持异步 Agentic RL 训练框架。
- Context Engine：被描述为「存储—计算处理—上下文工程」三位一体的引擎，把企业全域数据转化成实时上下文。官方表述是让 Agent 从「知道什么」，走向「此刻应该做什么」。
- 算力侧：灵骏真武 M890 国产十万卡超节点，支撑 Qwen3.8 Max、Kimi K3 等超 2T 参数模型对外提供商业服务；明年推出真武 V900，性能提升三倍，单集群可扩展到 50 万卡。
- 给出的目标数字：整套方案目标是把智能体运行成本降低 70%。存储方面，CPFS 提供百 TB/s 级吞吐和亿级 IOPS，单文件系统规模提升 5 倍到 100PiB；官方称实际训练中模型启动平均耗时降低 50%、峰值算力利用率提升 30%、AI 存储成本降低 69%。
同一天的另一个发布更贴近企业的日常使用：千问办公发布企业级 Agent 基础设施「企业上下文」（Enterprise Context），配套 Agent 托管能力，并上线协作空间、应用接入和安全中心。其中安全中心的做法是沙箱划定运行边界、高风险操作拦截、操作审计回溯，再结合既有安全体系落实最小权限与敏感信息识别，目标是让数字员工具备完整身份、明确授权边界和全流程可追溯记录。
官方给出的落地案例里有两个比较具体：古茗茶饮把文档和知识库资料搭成门店运营知识空间，一线店员提问时 Agent 精准调取对应资料，覆盖近万名门店人员；物流企业富立卡部署了查询、报价、合同三类数字员工，共享同一份企业上下文，分工完成从询盘、报价到合同审批的全链路流转。接入企业名单里还包括益海嘉里金龙鱼、一汽丰田、中国数联、方达律师事务所、传化集团、横店东磁、国邦医药等。
阿里巴巴集团 CEO 吴泳铭在开幕式上给出的判断是：机器正在成为思考的主力，智能正在成为一种规模化的商品，「未来机器思考的总量将达到人类的 1000 倍以上」。同时他也承认机器智能时代的代表性产品尚未出现——「今天的 AI Coding 就像 1882 年的电灯，替代的是现有工作，还不足以创造一个新的时代」。他把机器智能时代的三大基石概括为 AI 模型、AI 芯片和 AI 云，并提到 Qwen 团队在递归式自我改进方面取得进展，未来模型将扩展到 5 万亿至 10 万亿参数规模。
事实梳理二：Google 开源 Agent 运行时 AX
（来源：github.com/google/ax、项目站点 agentexecutor.io、Google Cloud 博客、Hacker News 讨论）
- 它是什么：AX（Agent Executor），Apache-2.0 开源的分布式 Agent 运行时，用来执行、挂起、恢复和审计长时间运行的 Agent 任务。仓库 2026 年 3 月创建，5 月由 Google Cloud 博客公开预览版，README 当时就明确警告后续会有破坏性变更。
- 这一周发生了什么：9 月 20 日发布 v0.3.0，随后在 Hacker News 上冲到首页第一，讨论热度六百来分、两百多条评论。
- v0.3.0 的关键改动：项目拆成三个二进制——ax-server（gRPC 接口）、ax-controller（消费 Redis Streams 的水平扩展协调器）、ax-task-runner（在沙箱 worker 里执行任务）；任务状态从 Kubernetes 的自定义资源搬到了 Redis Streams，理由是当短生命周期的 Agent 任务达到百万级时，原来那套状态存储扛不住。同时移除了旧版 Python harness、事件日志和示例。
- 四个声明式原语：Task（在隔离沙箱里跑不受信任的 Agent 代码，有 CPU 和内存限制，可挂起与恢复以保存状态）、Workspace（一次声明好 Git 仓库、MCP server 和技能包，让任务热启动）、Gateway（声明任务对外暴露的监听端口，并把出站流量限制在显式白名单的主机与端口上）、Model（命名化的模型配置：供应商、模型标识、生成参数，凭证统一放 Kubernetes secret，便于集中轮换）。
- 命令行故意做得像 kubectl：ax apply、get、describe、watch、ssh、suspend、resume、delete。
- 底层是 Agent Substrate：一个独立的沙箱执行项目，官方宣称支持亚秒级恢复、密集多路复用，单集群可运行数十亿轻量任务。另一个被讨论得最多的能力是轨迹分叉——从内核快照把运行中 Agent 的完整状态复制一份，同时探索两条不同的未来路径。
- 它给出的理由值得原文引用：README 里写着「Agent 是一种新的工作负载。它既不是无状态微服务，也不是跑完就退出的批处理任务。它会累积状态、需要严格隔离、会调用模型 API 和工具服务，而且如果没人盯着，它可以在一个循环里把钱烧光。」
- 部署门槛不低：需要 Kubernetes 集群、ko 构建工具、容器镜像仓库，以及对 Agent Substrate 控制 API 的访问权限。
顺带说一句，AX 里 Workspace、Gateway、Model 这三个原语的思路，和站内讨论过的 Model + Harness 的分层 是同一套逻辑——只是这次有人把 Harness 那一层做成了基础设施产品。
为什么两家会撞在同一个点上
把两件事的关键词并排放：阿里云这边是「长任务、失败重试、断点恢复、异步执行、沙箱边界、上下文引擎」；Google 那边是「长时运行、挂起恢复、沙箱隔离、网络白名单、集中模型配置」。几乎一一对应。
这不是巧合，而是同一个工程现实逼出来的。真正的 Agent 负载有几个特征，传统基础设施一个都接不住：
- 它大量时间在等。等模型返回、等工具调用、等人工确认。有分析给出的估算是，Agent 一生中 90% 到 95% 的墙钟时间处于空闲。传统做法给它一个常驻容器，等于为闲置时间长期付费。
- 它是有状态的，而且状态很值钱。一次跑了四十分钟的任务，进程一重启就全丢——这才是很多团队真正被卡住的地方，卡点往往不是模型不够聪明。
- 它必须被隔离。Agent 会执行代码、会调外部服务，权限边界一旦没划清，就是安全事故的起点。这一点站内 沙箱要隔离哪四样东西 讲得很具体。
- 它可能失控烧钱。没人盯着的循环可以一直转下去，这和 限流与配额要怎么做 是同一类问题。
于是就出现了同一时间点上的两条路线：一条卖「省心」，一条卖「可移植」。阿里云的 AgentCore 是托管平台，把长任务、重试、恢复、审计、身份、权限打包成服务，企业不需要自己造；Google 的 AX 是开源控制平面，把原语和接口定义清楚，谁都能在自己或任何人的 Kubernetes 上跑起来。一个把复杂度收进产品里，一个把复杂度摊给生态去解决。这两条路会长期并存。
顺便说一句，这个位置其实早就排上队了——更早还有 AWS Bedrock AgentCore，只是当时那轮讨论的重点在检索和治理边界，站内 此前写过一次。三家陆续进场，说明这不是某一家的判断，而是行业共识。
影响分析：四个方向
（1）Agent 的成本结构正在从「模型费」转向「运行时费」。过去一算 Agent 成本，算的都是 token；现在的讨论开始变成「空闲时间要不要付钱」「状态存在哪里」「恢复一次要多久」。阿里云直接给出运行成本降低 70% 这种目标数字，Google 则把「为闲置付费」当成要解决的核心经济问题。这意味着省钱的空间正在从模型选型转移到调度和状态管理上。想省钱的团队该看看 成本怎么算怎么省 里那套拆分口径，把运行时那部分单列出来。
（2）「控制平面」这条线从概念讨论进入了产品化阶段。站内此前有一篇资讯讨论过 Agent 控制平面正在成形，那时的落点在权限、连接器和审计。现在补上了更硬的一层：调度、状态、恢复、隔离。也就是说，控制平面不只是「管得住」，还要「跑得稳」。国内另一条可对照的线，是几周前 华为全联接大会 上企业级 Agent 底座的全面开源——同一个月内，两家国内大厂在同一个位置上落子。
（3）企业选型的比较维度要重写。过去比的是「模型强不强、Agent 聪明不聪明」，现在要比的是长任务能不能恢复、断点在哪、审计记录全不全、能不能按最小权限约束 权限边界、多团队共用时隔离到什么粒度（参考 多租户怎么做）。「能不能跑得住」正在变成比「能不能跑」更重要的问题。
（4）对工程师技能的影响。如果运行时被托管或开源标准化，那接下来值钱的能力就不是「写一个 Agent 循环」，而是把任务拆解到能被恢复的粒度、把状态设计成可检查点、把权限划到最小。这些是分布式系统的老功夫，只是换了应用场景。反过来，那些把 Agent 编排跟队列、重试、定时器一起手搓的团队，应该认真评估一下继续维护那套胶水代码是否划算。
老达点评
第一，这周真正被验证的不是某家的产品，而是一个判断：Agent 的稀缺资源不是模型，是运行时。两边的发布里，模型都不是主角——阿里云讲的是底座和上下文，Google 干脆只讲调度和隔离。回想一下，几个月前行业还在比谁的模型在某个榜单上高几分；现在两朵云在同一天花大力气讲「怎么让 Agent 别死、别乱花钱、别越权」。这说明瓶颈已经从「能力」挪到了「可靠性」。对做产品的人来说这个信号很值钱：用户已经在问「能不能稳定跑通」，而不是「能不能做到」。
第二，我对「运行成本降 70%」这类目标数字保持谨慎乐观。方向肯定是对的——把空闲时间从计费里拿掉、把状态存到更便宜的地方、把冷启动压下去，能省的钱是实打实的。但降本幅度取决于你的负载形状：如果任务大部分时间都在调模型、等模型返回，那省的主要是调度开销，撑不起这种量级；如果场景是大量长任务挂着等外部事件，收益可能比这个数字还大。别把厂商的目标当成你的预算。
第三，Google 把 AX 开源，短期看是「给社区送工具」，长期看是在改写竞争的地基。把调度层开源、让任何人的 Kubernetes 都能跑，等于把编排这一层商品化——这话不好听，但很现实：一旦运行时不再是壁垒，竞争就会回到模型推理和云资源消耗上。这是很典型的云厂商打法，和十年前的容器编排战场是一个路数。对用户来说短期是好事：你有了一条不用被单一厂商锁死的路。只不过 AX 目前还是预览版、README 自己承认还会有破坏性变更，现在重仓投入要谨慎，先理解它的原语设计比急着上生产更实际。
第四，企业侧真正的门槛从来不在技术那一层。这次一堆头部企业宣布接入，案例里最有价值的细节其实不是「用了哪个平台」，而是「三个数字员工共享同一份企业上下文」。信息能不能被打通、权限能不能被划清、操作能不能被追溯，这些都是老问题，Agent 只是让它们变得更紧迫。买一个平台解决不了数据本身散在几十个系统里的事实。这一点上，站内关于 企业内部知识库怎么搭 的讨论比发布会本身更接近真实工作量——包括今天另一篇 知识图谱那一层怎么选，讲的都是同一个前提：Agent 的上限，取决于你能给它喂进什么样的结构，而不是你买了多贵的底座。
给做 Agent 的人的三条实在建议
- 先量一遍你的空闲占比。统计一个典型任务从开始到结束，真正在算的时间占多少。如果空闲占大头，说明钱主要花在「等着」，那优化方向就是调度和状态存储，而不是换更便宜的模型。这个数字花半天就能测出来，但它决定你接下来该往哪花钱。
- 把「能不能恢复」当成硬指标。设计任务时先问三句：进程挂了这个任务能不能接着跑？状态存在哪里？重跑会不会重复产生副作用？这类问题在自建系统里就是幂等与检查点设计。现在云厂商已经把「断点恢复」写进产品说明，说明它确实是最疼的地方。站内 OpenAI 把 Agent 循环做成托管服务 那篇里有类似的产品化对照，可以一起看；上下文怎么组织，上下文管理怎么做 里有更细的拆解。
- 别急着押注，先把原语学明白。无论是 AgentCore 这样的托管平台，还是 AX 这样的开源控制平面，值得先理解的不是 API 怎么调，而是它把哪几样东西定义成了一等公民——任务、工作区、网络边界、模型配置。理解这层抽象之后，你在任何平台上都不会从零开始；反过来，只学某家 API 的用法，换个平台就得重学。
总结
这周的两条消息可以压成一句话：Agent 的竞争焦点，从「模型有多强」移到了「运行时有多稳」，而且两朵云同时开始卖这一层。阿里云用托管平台把长任务、恢复、审计、身份打包成服务，Google 用开源控制平面把调度和隔离定义成原语——方向一致，路径相反。
对使用者来说，变化比发布会本身更重要：「Agent 跑不住」终于可以被当成一个有成熟解法的工程问题，而不是一个只能忍耐的现状。但也要清楚，底座解决的是「跑得稳」，解决不了「喂得对」。上下文从哪来、知识怎么组织、权限怎么划，仍然是每家自己要做完的功课。
