过去两年，行业几乎把全部注意力都投向“大模型能力跃迁”和“Agent 应用爆发”——GPT 参数竞赛、Claude 工具调用、MCP 协议横空出世、Manus / AutoGPT 类产品刷屏，却集体忽略了一个更底层、更致命的问题：企业级 Agent，到底跑在什么上面？
答案令人不安：现阶段绝大多数企业 Agent 直接被塞进为微服务设计的存量 K8s 集群，或干脆跑在裸金属 + Python 进程里。
Linux Foundation 预测，2026 年 AI 算力投向中推理占比将从 2023 年的 33% 跃升到 67%；CNCF 在 KubeCon EU 2026 主论坛上首次将 “Agentic AI Infrastructure” 写入议程；Anthropic、OpenAI、Block 与所有超大规模云厂联合发起 Agentic AI Foundation（AAIF）——一切都指向同一个事实：Agent 不是应用，是全新算力运行范式，需要一套全新底座。
图 1 · 算力结构拐点：推理占比 33% → 67%（2023–2026）
一、时代变革：从云原生 1.0 到 Agentic AI 2.0
过去十年，云原生 1.0 的成功建立在一组高度收敛的设计目标之上。K8s 的整个抽象体系，本质是为“无状态微服务”这一类业务量身打造的：Pod 是进程级隔离、Deployment 是声明式副本、Service 是 L4 负载均衡、Ingress 是 L7 入口——所有 API 都在回答同一个问题：如何让一组短生命周期、无状态、被动响应请求的进程，被稳定、可弹性、可观测地调度到一台 Linux 上。
这是一组被极致优化过的工程目标。它在 Web、电商、SaaS、API 网关等场景几乎无往不利。但当我们把视角切换到企业级 Agent 业务，会发现两者的运行范式存在底层维度的不兼容：
| | Agentic AI 2.0（企业级 Agent） |
|---|
| | 小时级 / 天级 / 周级长任务 |
| | 主动规划、自主决策、循环迭代 |
| | GPU / 显存 / KV Cache 动态抢占 |
| | 多智能体动态组队、并发、接力 |
| | 长上下文、记忆、Checkpoint、KV Cache |
| | 运行时工具发现 + 非人类身份治理 |
| | 上下文溢出、推理死循环、状态污染 |
| | Token 速率 / 循环耗尽 / 工具错误率 |
KubeCon EU 2026 上，CNCF CTO Chris Aniszczyk 把这种范式跃迁讲得非常直白：过去十年我们帮 Uber、Booking.com、航空公司在 Web-scale 分布式系统上拿到极致弹性；下一个十年的主战场，是把大规模 AI 推理和 Agent 在 Kubernetes 上跑稳、跑省、跑安全。Google Keynote 甚至把 K8s 重新定义为 “autonomous infrastructure 的神经系统”——这意味着 K8s 不再只是“应用运行平台”，而是要成为 承载模型、算力、数据、安全、应用的 AI 基础设施。
所以真正的问题不是“K8s 能不能跑 Agent”——它当然能跑，但跑起来会不断踩到调度、生命周期、状态、协作、工具治理五大维度的天花板。这就是为什么 From Cloud Native to Agentic AI 不是升级，而是范式重构。
图 2 · 范式差异：传统云原生 vs Agentic AI（六维能力对比）
二、核心辨析：企业级 Agent 到底缺什么基础设施？
把行业现状摊开看，会发现一个尴尬的结构性矛盾：应用层 Agent 已经热到发红，底座层 Agent 基础设施却冷到冰点。大量企业一边宣称“全员 Agent 化”，一边把 Agent 进程塞进一台 16C64G 的开发机、把多智能体协作写在一个 Python 单体工程里、把工具调用硬编码进 prompt 模板。这种“应用热、底座冷”的核心瓶颈，可以拆解为以下六大不适配点：
| | | |
|---|
| 任务调度模型 | Pod + Deployment + HPA，面向副本数伸缩 | 面向长任务、动态推理负载、Gang 调度、乐观并发的调度器 |
| 生命周期管理 | | 长会话保活、检查点恢复、上下文瘦身、KV Cache 主动协同 |
| 资源抢占机制 | | GPU 共享、显存切片、KV Cache 池化、Token 预算治理 |
| 多智能体协同 | | 多 Agent 动态组队、任务分发、成果接力、Swarm Skills 自演进 |
| Agent 状态持久化 | | Durable Execution、Checkpoint、事件溯源、跨节点 rehydrate |
| 工具调用治理 | | MCP 协议注册发现 + 非人类身份治理 + 实时策略拦截 |
六大不适配不是六个孤立问题，而是一个互为因果的恶性循环：状态没有持久化，长任务一断就丢上下文，Agent 被迫全部塞进单进程，又反过来加剧了资源抢占和无调度能力的痛；没有工具治理，多智能体一旦并发调用，权限边界立即失守；没有多智能体编排，再大的 GPU 集群也只能服务单 Agent 的串行循环——存量 K8s 在任何一条上失守，都会让 Agent 业务整体不可用。
图 4 · 存量云原生底座六大不适配点严重度评估
值得警觉的是，“Agent 状态无持久化”在六个维度中评估为最高严重度。这并非主观感受，而是行业普遍规律：企业一旦把 Agent 跑上生产，几乎 100% 会撞上“上下文窗口溢出”、“节点重启导致任务回到原点”、“KV Cache 失效重算”这三类问题，并且没有任何传统运维工具能定位。这是 Agentic AI 时代特有的“状态失忆症”。
三、新基建定义：Agentic AI 专属基础设施核心能力框架
从 Cloud Native 到 Agentic AI 不是一个“加几个 Agent 插件”的工程，而是一套全新的能力框架。基于 KubeCon 官方演进思路与企业级 Agent 落地实践，我们提炼出 Agentic AI 专属基础设施必须具备的七大核心能力：
| | | |
|---|
| 智能任务调度 | 面向 Agent 短生命周期、高并发、动态负载的通智一体调度器 | |
| 多 Agent 集群编排 | 多智能体动态组队、任务分发、并发接力、Swarm Skills 沉淀 | |
| 长任务容错恢复 | Durable Execution、Checkpoint、事件溯源、跨节点 rehydrate | |
| Agent 状态治理 | 长上下文瘦身、分层记忆、KV Cache 主动协同、token 预算 | |
| 工具生态注册与发现 | MCP / A2A / A2X Registry 标准化注册、安全桥接、运行时发现 | |
| AI 资源弹性调度 | GPU 共享 / 显存切片 / 异构池化 / 拓扑感知 | |
| 推理 / 训练混合负载管理 | 训推一体资源池、PD 分离、自动扩缩容、Serverless 弹性 | |
这七项能力之间存在严格的依赖关系：没有 ① 就撑不住 ②；没有 ③ 就跑不长 ②；没有 ④ ③ 就无法 scale；没有 ⑤ ② 就无法对接企业系统；没有 ⑥ ⑦，整个集群的算力成本结构就不成立。换言之，Agentic AI 基础设施不是能力堆叠，而是能力闭环。任何一个能力缺位，整条链都会被打回原形——这正是为什么传统云原生厂商“加几个插件”式的修修补补，本质上解决不了 Agent 规模化的问题。
四、技术落地解读：开源生态如何补齐 Agent 基础设施短板
值得庆幸的是，过去两年国内外开源生态已经从“单点修补”快速演进出完整的四层架构：编排层 / 调度层 / 协议层 / 执行层。以华为云系为代表的开源栈已经基本完成从“批量调度引擎”到“Agentic AI 全栈基础设施”的跃迁。下面这张分层图，是我们结合 KubeCon EU 2026 / China 2026 公开演进做的全景映射：
图 3 · Agentic AI 基础设施分层架构（编排 / 调度 / 协议 / 执行）
各层分工与代表项目，做一次清晰的责任切分：
| | | |
|---|
| 编排层 | | openJiuwen · WorkSwarm · AgentCube | 从“单 Agent 对话框”跃迁至多 Agent 蜂群协同 |
| 调度层 | | Volcano · Agent Scheduler · Karmada | 把 Agent 短任务塞进训推一体资源池，集群利用率从 30% 拉到 70%+ |
| 协议层 | | | 让 Agent 工具调用从硬编码函数 → 标准化协议 |
| 执行层 | 毫秒级冷启、会话级隔离、Serverless 弹性 | Agent Sandbox · CCE Turbo · CCI | |
4.1 编排层：openJiuwen / WorkSwarm 的协同工程范式
由华为 2012 实验室 + 华为云 AgentArts 团队共建的开源 Agent 平台 openJiuwen，把“多智能体协同”从概念工程化为一套可落地的 Coordination Engineering 协同工程范式。
其旗舰产品 WorkSwarm（蜂群办公智能体）提出了三个在 Agent 基础设施领域非常关键的能力：
一是 Agent Swarm + HOTS / HITS 协同——支持“人在集群之上指挥”与“人在集群之中参与”两种模式；
二是 Swarm Skills + Skills Hub 自演进——把协作流程沉淀为可复用的标准化技能包，并形成社区共享；
三是 KV Cache 主动协同 + 算力亲和——和昇腾 / 鲲鹏底层算力深度优化，使多智能体并发场景首 token 时延减半、推理存储峰值下降约 25%。
更关键的是 AgentArts 与 openJiuwen 内核同源度超过 90%——这意味着企业今天基于开源 openJiuwen 构建的 Agent 平台，未来可以平滑迁移到商用 AgentArts，避免被单一厂商锁定。
4.2 调度层：Volcano + AgentCube + Karmada 的通智一体
Volcano 在 2025–2026 完成了一次关键进化：从“AI 批处理调度引擎”升级为“通智融合调度系统”。三个新能力尤其值得架构师关注——Agent Scheduler 面向高并发、短生命周期的 Agent 任务，通过多 Worker 并行调度 + 乐观并发控制，把调度吞吐拉高一个数量级；AgentCube 提供专为 Agent 打造的轻量级有状态运行时，Warm Pool 技术让隔离容器实现毫秒级拉起；Kthena 面向 LLM 推理服务，支持 PD 分离部署和自动扩缩容，在复杂对话场景下可降低 20%+ 全局延迟。
Karmada 则把视野抬到多集群联邦层面：通过 Karmada + Volcano Global 协同，企业可以把一个超大 LLM 任务拆解后跨云分发，让算力跟随任务而不是任务迁就集群——这是 Agentic AI 时代的“超算联邦”。B 站已经基于这套组合，把 GPU 利用率提升 40%+、故障恢复时间缩短 70%；科大讯飞则把训练资源干扰率压低 50%。这不是 PPT 数据，而是已经在中国生产环境跑出来的工程结果。
4.3 协议层：MCP / A2A / A2X Registry
如果说前面两层是“引擎”，那么协议层是“**总线**”。MCP（Model Context Protocol） 已经被 Anthropic / OpenAI / Block 和所有超大规模云厂联合推为 Agent-to-Tool 的事实标准；A2A（Agent-to-Agent） 解决多智能体协作的通信问题；openJiuwen A2X Registry 进一步把 MCP 服务的注册与发现工程化，让企业能够以集中方式管理成百上千个 MCP 工具，避免工具散落在 N 个 Agent 进程里。
在协议之上，行业正在快速形成 “Governance-as-Code” 的非人类身份治理体系：把 Agent 视为拥有特权凭证的 NHI（Non-Human Identity），通过 Governance Sidecar 实时拦截越权操作，结合 OPA 之类的策略引擎实现 Policy-as-Code。这一点直接决定 Agent 能不能进入企业的核心生产系统。
4.4 执行层：Agent Sandbox 与 Serverless 弹性
Agent 每一次工具调用都可能是一段不可信的代码执行，没有安全沙箱的 Agent 平台不配叫企业级。执行层的核心使命是：每一次 Agent 调用都跑在一个隔离、轻量、可毫秒级冷启的运行时里。CCE Turbo + CCI + Agent Sandbox 的组合，让企业能在共享 GPU 集群上同时支撑上万次 Agent 工具调用而互不污染，配合昇腾、鲲鹏的算力亲和，把单次调用的边际成本压到极致。
这四层组合起来，才构成一个能跑企业级 Agent 的完整闭环。任何一层缺位，企业 Agent 规模化就一定会撞墙。
五、落地痛点与客观批判（必须有，不吹捧）
把上面四层架构写得很漂亮并不难，难的是承认它现在还不成熟。作为架构师，我们必须在企业决策时保持冷峻，避免被生态叙事裹挟。当前 Agentic AI 基础设施的六大真实痛点：
| | |
|---|
| 标准未统一 | MCP / A2A / ACP 各自为战；各厂商 Agent 协议不互通 | |
| Agent 运维体系空白 | 没有 APM 能看清 Agent 内部状态、token 流向、循环耗尽 | |
| 长任务稳定性差 | 节点重启 / 网卡抖动 / 推理超时 → 任务回到原点 | |
| 多 Agent 协同调试难 | | |
| 资源浪费严重 | 没有合理池化的 Agent 任务，GPU 空转 / 显存碎片 | |
| 企业落地成本高 | 需要打通存量大数据 / 安全 / IAM 体系，改造面巨大 | 试点期投入 vs 全业务替换收益 ROI 难以测算 |
客观结论：现阶段 Agentic AI 基础设施仍然适合“试点场景”，尚不适合全业务规模化替换。我们给出的建议是——优先在知识检索、研发辅助、客服辅助、文档自动化这类容错边界宽、价值可验证的场景落地，不要在核心交易、关键合规、严格 SLA 场景大规模替换存量系统。但同时，底座建设必须今天就开始——因为基础设施不是买来的，是堆出来的，等到核心业务要用时再启动，已经来不及了。
六、产业趋势预判
趋势不是预测出来的，是从今天已经被验证的工程实践中归纳出来的。基于 KubeCon EU/China 2026 的产业共识与我们的实战观察，给出三个明确判断：
| |
|---|
| 什么样的企业需要自建 Agent 基础设施？ | 三类：①AI 原生业务占比 30%+ 的企业；②数据合规要求本地化的金融 / 制造 / 政企；③已有规模化 K8s 平台但 GPU 利用率低于 40% 的企业。其他场景优先用云上 Agent 平台，避免过早投入底座建设。 |
| 未来云原生架构的核心迭代方向？ | 未来三年的主线是“从编排应用 → 编排算力 → 编排智能体”。具体表现为：调度层 Agent Scheduler 成为默认；Kueue / Volcano / Karmada 在 GPU 多租户上深度协同；DRA 成为资源抽象标准；MCP / A2A 成为 Agent 间通信默认协议。 |
| Agent 底座会不会成为下一代算力平台的核心壁垒？ | 会，而且是决定性的壁垒。未来 18–24 个月，没有 Agent 底座的算力平台将被结构性边缘化。判断依据：模型能力会商品化、Agent 框架会趋同、唯独底座（含 GPU 共享、KV Cache 池化、长任务容错、多 Agent 编排、工具治理）是需要规模化业务反哺才能沉淀的工程壁垒。谁先把底座跑稳，谁就拿到下一代 AI Infra 的船票。 |
战略视角：Agent 业务的胜负，不再取决于模型选型或 Prompt 工程，而取决于底座工程。CNCF 已将 Agent Infrastructure 列入主论坛议程，AAIF 已有 146 家成员；开源生态在 18 个月内就完成了从“单点修补”到“四层闭环”的跃迁。今天不投底座，明天就要为每一次 Agent 试错买单。
结语：基础设施才是真正的护城河
把视角拉回全篇——从 Cloud Native 到 Agentic AI，不是一次工具升级，而是一次算力范式的跃迁。Kubernetes 不再只是“容器编排系统”，它正在向“连接模型、算力、数据、安全、应用的 AI 基础设施”演进；而企业级 Agent 的真正护城河，不在模型、不在框架，在底座——在调度器、在沙箱、在协议、在长任务容错、在多智能体编排、在每一次工具调用的安全治理。
凡是仍然相信“把 Agent 跑在 Docker 里就够用”的团队，注定会在 2026–2028 这一轮 AI Infra 重构期被边缘化。凡是今天开始认真投入 Agentic AI 基础设施建设的团队，都将拿到下一代企业级算力平台的入场券。
范式跃迁不会等任何人。基础设施的厚度，决定 Agent 业务的高度
粤ICP备14082021号
免费POC，
零成本试错
