Agent Infra：一个新基础设施类别的诞生

KADC 2026 系列分析 · 第 3 篇 · Agent 基础设施 / 通算+智算协同

2026 年 5 月 22 日，北京中关村国际创新中心，鲲鹏昇腾开发者大会（KADC 2026）上，华为抛出一个没有多少人在讨论的问题：Agent 需要什么样的基础设施？

不是"AI 需要什么算力"——这个问题已经有无数人在回答。而是更具体的：当一个 LLM 从单轮对话变成多步执行、工具调用、状态管理的 Agent 时，跑在它下面的那一层 OS、沙箱、网络、安全、记忆服务，到底需要发生什么变化？

华为给出的答案是"Agent Infra"——一个他们认为独立于 AI Infra 的新基础设施类别。与此同时，openEuler 的架构师在另一场演讲中提出了更激进的概念：Agent POSIX——面向 Agentic AI 的可移植性原语。

这是营销包装，还是真问题？让我们从 Agent 的 workload 反推。

为什么 Agent 需要新的基础设施

先说清楚一件事：Agent 不是更快的 Chatbot。

Chatbot 的执行模型是单次请求-响应。用户发一条消息，LLM 生成回复，结束。基础设施只需要做好两件事：推理加速（GPU 侧）和请求调度（API 层）。

Agent 的执行模型完全不同。它是一个有状态的多步控制流：任务分解 → 工具选择 → 工具执行 → 观察结果 → 状态更新 → 下一步决策。这个循环可能执行几十次，每次都可能调用外部工具、修改环境状态、创建子任务。

这个区别对基础设施意味着什么？华为给出了一组数据：

• Token 消耗量半年增长 6 倍——不是因为模型更大，而是 Agent 的多轮交互让 Token 消耗指数级上升
• Agent 调用频次暴涨 50-100 倍——一个复杂任务可能触发上百次工具调用
• 控制流复杂度爆炸——Tokenization、上下文拼接、记忆管理、数据拷贝同步持续发生

更关键的是网络拓扑和安全边界的变化：

网络拓扑从星型辐射（人机交互，一个用户一个请求）变成全互联网格（Agent 之间、Agent 与工具之间密集并发通信）。传统基础设施为前者设计，对后者缺乏优化。

安全边界从静态 API 调用变成动态调用链——Agent 在运行时会动态选择并调用不可信的外部工具，每次调用的权限、数据流向、隔离需求都不同。这不是 WAF（Web Application Firewall）和 API Gateway 能覆盖的场景。

这些变化的直接后果：延迟高、吞吐受限、能耗高。为 Web 和微服务设计的传统 IT 基础设施，在面对 Agent 的 workload 特征时系统性地失配。

这不是华为的独家观察。上海交大和华为在 2025 年发表的 DeltaBox 论文中，对 Agent 沙箱的 workload 做了系统量化：在 SWE-bench 的 MCTS（Monte Carlo Tree Search）Agent 场景中，状态管理开销占轨迹总时间的 47%-77%。也就是说，Agent 把大部分时间花在了等待沙箱 checkpoint 和 rollback 上，而不是在做有用的推理。

这个数字是整个 Agent Infra 命题的锚点。

CPU 在 Agent 时代的角色跃迁

过去三年，基础设施行业的主旋律是"GPU 为王"。训练需要 GPU，推理需要 GPU，一切围绕 GPU。CPU 是配角——负责 I/O 调度、数据搬运、网络协议处理。

Agent 改变了这个等式。原因不是 GPU 变得不重要，而是 Agent 的控制流天然运行在 CPU 上，而且这些控制流的复杂度正在爆炸。

Agent 控制流是什么

一个 Agent 执行"帮我修复这个 bug"的任务，大致经历以下步骤：

1. 任务分解：将"修复 bug"拆成子任务（读取代码 → 定位问题 → 生成 patch → 运行测试 → 分析失败 → 修改 patch → 重试）
2. 工具选择：每一步决定用哪个工具（文件读取、代码搜索、终端执行、LSP 调用）
3. 上下文管理：维护对话历史、工具执行结果、中间状态，在 Token 预算内裁剪和拼接
4. 状态机管理：跟踪任务进度、管理子任务依赖、处理超时和重试

每一步都是 CPU 密集型操作。Tokenization 本质是字符串处理，上下文拼接是内存拷贝和排序，记忆管理涉及图数据库查询和向量检索，工具调用涉及 API 编排和 JSON 序列化/反序列化。

为什么这些操作集中在 CPU 上

Agent 调用的工具——数据库查询、文件操作、API 请求、代码执行——天然运行在 CPU、网络和存储之上。GPU 在这个过程中承担的是推理调用（LLM 生成下一步决策），但两次推理调用之间的所有工作都在 CPU 上执行。

随着 Agent 任务复杂度增加，推理调用之间的间隔越来越长，CPU 上的累积开销成为端到端时延的主要组成部分。

华为鲲鹏计算产品部部长刘林超在 KADC 2026 上的判断值得注意："从'智算为中心'到'通算+智算协同'是最大的架构范式转变。"

这不是华为的营销话术。它描述的是一个事实：当 Agent 负载占据算力消耗的更大比例时，CPU 和 GPU 的关系从"CPU 服务 GPU"变成"CPU 和 GPU 协同执行"。

一个定量的说明

假设一个 Agent 执行一次完整的 bug 修复流程：

• 10 次 LLM 推理调用，每次平均 2 秒（GPU 侧）= 20 秒
• 每次推理之间：Tokenization（50ms）+ 上下文拼接（100ms）+ 工具执行（500ms）+ 状态管理（200ms）= 850ms × 10 = 8.5 秒（CPU 侧）

GPU 占比 ≈ 70%，CPU 占比 ≈ 30%。看起来 GPU 仍然主导。

但如果 Agent 使用 MCTS 进行多路径探索（当前 SOTA Agent 的标准做法），每个推理步骤可能 fork 出 5-10 个并行沙箱：

• 10 次推理 × 2 秒 = 20 秒（GPU）
• 10 次推理 × 5 个并行沙箱 ×（沙箱 fork 50ms + 工具执行 500ms + 状态管理 200ms）= 37.5 秒（CPU）

CPU 侧开销反超 GPU。这正是"通算+智算协同"的工程依据。

鲲鹏超节点的三层智能体架构

华为在 KADC 2026 上展示的不是一个单一产品，而是一个从芯片到 OS 到运行时的三层架构。这是 Agent Infra 作为独立类别最重要的技术支撑。

底层：鲲鹏超节点 + 灵衢互联

鲲鹏超节点的核心参数：

• TB 级互联带宽
• 百纳秒时延（100ns 级别，对比传统以太网的微秒级）
• 24TB 统一内存池——全局内存统一编址，所有 CPU 核心共享同一个地址空间
• 与昇腾超节点的异构融合——智算（GPU）和通算（CPU）共享同一个互联协议

这些数字意味着什么？

传统服务器集群中，两台机器之间的内存访问要走网络协议栈，时延在微秒到毫秒级。鲲鹏超节点通过灵衢（UnifiedBus）协议，让多个 CPU 节点之间的内存访问时延压到百纳秒级，并通过统一编址让软件无需区分本地内存和远程内存。

这不是 incremental 优化。这是在改变 CPU 之间协作的基本模型——从"通过网络通信"变成"像共享内存一样工作"。

灵衢协议的三项关键技术进一步放大了这个优势：

值得注意的数字是"透明 UBSocket"的 40% 时延下降——它意味着现有应用不需要修改代码就能获得性能提升，这是大规模迁移的前提条件。

中间层：openEuler 异构融合 OS

如果说灵衢是硬件层的胶水，openEuler 就是软件层的胶水。

KADC 2026 上，openEuler 展示了其超节点 OS 的三个关键能力：

1. 全局资源抽象：将超节点内的所有 CPU、内存、加速器统一抽象为单一资源池，上层应用看到的是一个"大机器"而非集群
2. 异构算力平等互联：打破 CPU 和 GPU 的联接壁垒，通过灵衢协议实现内存池化和算力一体化
3. 高效兼容的调度接口：保持 POSIX 兼容性的同时提供超节点感知的调度能力

即将发布的 openEuler 24.03 LTS SP4 优化了三个维度：一键安装部署（易用性）、跨节点故障感知时间压到 500ms 以内（可靠性）、基于 UMDK 的大规模容器低时延通信（低时延）。

与 OpenCloudOS 的联创也值得关注：虚机极速热迁移、超大规格云主机、内存语义高性能通信。这些能力的共同指向是——让云上的 Agent 运行时获得接近裸金属的性能。

上层：Agent Infra

这是整个架构中最有意思的部分。华为把 Agent Infra 定义为三个核心服务：

轻量沙箱：Agent 的工具执行需要隔离环境。传统容器启动时间在秒级（Docker 冷启动 275ms 到数秒，Firecracker microVM 约 125ms），Agent 的 fork 需求在毫秒级。鲲鹏超节点通过多级缓存共享 + 增量快照 + 任意状态快速 fork，将回滚性能推到十毫秒级。实测数据：Agent 任务成功率提升 10% 以上。

记忆服务：Agent 的长期记忆需要持久化存储，但访问延迟必须接近内存。鲲鹏超节点的方案包括：共享内存 Buffer Pool 预热/快速加载（热数据常驻内存）、分布式全局图索引（多模态检索性能翻倍）、上下文缓存减少重复注入（Token 开销 -50%）。

全链路安全：CCA（Confidential Computing Architecture，ARM 的机密计算标准）机密 Agent 方案、eBPF 容器级可信授权、内生密码模块 + openGauss 秒级恢复。三层防御分别覆盖运行时隔离、策略执行、数据保护。

这三层服务的组合，构成了华为所说的"Agent Infra"。关键不在于单个组件的技术指标，而在于这是第一次有厂商从芯片到 OS 到运行时全栈设计 Agent 专用基础设施。

沙箱：Agent 时代的第一性需求

沙箱为什么对 Agent 如此重要？值得展开讲。

问题本质

Agent 的核心能力是"使用工具"。但工具执行是危险的——Agent 可能生成并执行不可信代码、修改关键文件、发起意外的网络请求。每次工具执行都需要在一个隔离环境中进行。

更关键的是，Agent 经常需要"探索-回退"：尝试一个方案，如果失败，回退到之前的状态，尝试另一个方案。在 MCTS 等搜索策略中，这种 fork-explore-rollback 的频率极高。

现有方案的瓶颈

上海交大和华为联合发表的 DeltaBox 论文给出了详实的量化数据：

DeltaBox 的关键洞察是：Agent 连续两次 checkpoint 之间的状态变化很小——可能只是修改了几个文件、改动了少量内存页。与其全量复制，不如只记录变化。

这个思路并不新鲜（OverlayFS、CRIU 增量转储都有类似思想），但 DeltaBox 将其系统化地应用到 Agent 场景，并通过两个 OS 级机制实现了毫秒级 C/R：

• DeltaFS：基于 OverlayFS 的运行时热层切换，不需要 unmount 就能冻结当前层、插入新层，将文件操作降为 CoW（Copy-on-Write）
• DeltaCR：增量 CRIU 转储 + 模板 fork() 恢复，绕过传统管道直接从冻结的模板进程 fork

结果：在 SWE-bench MCTS 场景中，状态管理开销从 47%-77% 降到 3%-6%。 Agent 有更多时间做有用的推理，而不是等沙箱。

鲲鹏超节点的沙箱方案与 DeltaBox 的思路一脉相承：多级缓存共享 + 增量快照 + 快速 fork，十毫秒级回滚。区别在于鲲鹏通过硬件层（灵衢互联 + 统一内存编址）进一步加速了跨节点的沙箱分发。

为什么 10ms 级回滚如此重要

假设一个 Agent 使用 Best-of-N 采样，N=10：

• 如果每次 fork+rollback 需要 1 秒：10 个并行轨迹的状态管理开销 = 10 秒 × 每次迭代 = 严重影响吞吐
• 如果每次 fork+rollback 需要 10ms：10 个并行轨迹的状态管理开销 = 100ms × 每次迭代 = 几乎可忽略

这不是"快一点"的区别，而是从"不可行"到"可行"的质变。华为给出的数据——Agent 任务成功率提升 10%——很可能低估了在更深搜索树上的收益。

记忆服务的架构挑战

Agent 的记忆不是简单的"存下来下次用"。它需要同时满足三个互相矛盾的需求：

1. 低延迟访问：Agent 在推理过程中需要实时检索记忆，延迟必须接近内存访问（微秒级）
2. 持久化存储：记忆不能因为 Agent 重启而丢失，需要落盘
3. 语义检索：Agent 需要按语义（而非精确匹配）检索记忆，需要向量索引和图索引

传统方案的矛盾

向量数据库（如 Pinecone、Milvus）解决了语义检索，但延迟在毫秒到数十毫秒级，且不支持 Agent 运行时的高频实时访问。

Redis 等内存数据库解决了低延迟，但缺乏语义检索能力，且大规模 Agent 的记忆容量会快速膨胀。

LangChain Memory、Zep、Mem0 等 Agent 框架层的记忆方案，本质是在应用层做胶水——把 LLM 对话历史、工具执行结果、用户偏好等信息组织成上下文，注入到 prompt 中。它们不解决基础设施层的性能问题。

鲲鹏超节点的记忆架构

鲲鹏的方案从硬件层开始设计：

共享内存 Buffer Pool：利用超节点的 24TB 统一内存池，将 Agent 的热记忆常驻内存。Buffer Pool 支持预热（新 Agent 启动时自动加载常用记忆）和快速加载（从远端内存按需拉取，走灵衢协议百纳秒时延）。

分布式全局图索引：Agent 的知识图谱可能跨越多个节点（例如一个企业的多个 Agent 共享知识库）。全局图索引让多模态检索不需要在多个节点间跳转，直接在全局索引上完成。华为声称多模态检索性能翻倍。

上下文缓存：这是成本最直观的优化。Agent 在多轮交互中频繁注入相同的系统提示、工具描述、历史上下文。通过缓存这些重复内容，避免每次都重新 tokenization 和传输。实测：Token 开销降低 50%。

天翼云 AgentDesk 的实测数据也佐证了记忆服务的价值：LoCoMo 长序列任务准确率 +37%，输入 Token 消耗 -68%。准确率提升和成本下降同时发生——这意味着记忆不是"锦上添花"，而是 Agent 能力的乘数。

安全：从 API 网关到动态调用链防护

Agent 安全与传统应用安全的根本区别在于：Agent 的调用链是动态生成的，而非预先定义的。

一个传统 Web 应用调用数据库的模式是固定的——ORM 生成 SQL → 连接池 → 数据库 → 返回结果。安全策略可以针对这个固定模式设计。

一个 Agent 可能执行：读取文件 → 发现需要安装依赖 → pip install → 发现依赖有安全漏洞 → 搜索替代方案 → 下载替代包 → 执行测试 → 发现测试失败 → 修改配置 → 重试……

每一步的权限需求、数据流向、安全边界都不同。而且这些步骤是 Agent 在运行时自主决定的，开发者无法预知完整调用链。

鲲鹏的安全方案

鲲鹏在 KADC 2026 上推出的 Agent 安全方案覆盖了三个阶段：

事前：Prompt 注入检测 + 硬件可信根绑定意图与行为。确保 Agent 在执行前已经被验证为合法实例。

事中：三级动态沙箱（Conch/Session/Tool 沙箱）+ eBPF 容器级可信授权 + CCA 机密计算架构。每一级沙箱对应不同粒度的隔离：Conch 级别隔离整个 Agent 会话，Session 级别隔离单次交互，Tool 级别隔离单个工具调用。eBPF（Extended Berkeley Packet Filter，Linux 内核级的可编程安全策略引擎）允许在不修改内核的情况下动态定义安全策略，CCA（Confidential Computing Architecture，ARM 的机密计算标准）通过硬件级内存加密防止内存 dump 攻击。

事后：内生密码模块 + openGauss 秒级恢复。Agent 的关键数据加密存储，即使被攻破也能快速恢复到已知安全状态。

这些技术选择不是随意的。CCA 选择了 ARM 的开放标准（而非自研封闭方案），eBPF 选择了 Linux 社区的主流技术栈（而非自研内核模块）。这说明华为在安全层选择了生态兼容而非技术独占的策略。

与海外 Agent 生态的对比

要理解鲲鹏 Agent Infra 的定位，需要把它放到全球 Agent 生态的版图里看。

生态分层对比

关键差距和机会

差距一：编排层空白。 华为没有自己的 Agent 编排框架，也没有参与 MCP、A2A 等工具协议的标准化。这意味着鲲鹏的 Agent Infra 需要依赖上层的 LangGraph、Dify 等框架来"发现"它。如果这些框架不主动适配鲲鹏，Agent Infra 的价值很难被开发者感知。

差距二：海外生态的路径依赖。 海外的 Agent 生态（LangGraph、CrewAI、OpenAI Agents SDK）专注于编排逻辑和开发者体验，对底层基础设施的思考停留在"给我一个足够快的 Docker"或"给我一个 Firecracker sandbox"。没有人从 CPU 互联、OS 调度、内存架构的角度系统思考 Agent 运行时。

机会：全栈设计的独特价值。 华为是唯一从芯片到 OS 到运行时全栈设计 Agent Infra 的厂商。海外生态在编排层很繁荣，但在基础设施层几乎空白。如果鲲鹏能证明"在 Agent POSIX 上跑的 LangGraph 比在普通 Linux 上跑的快 3 倍"，生态适配的问题会自然解决。

一个值得关注的信号： MCP 在 2026 年初爆出了系统性安全漏洞——CSA（Cloud Security Alliance）的研究指出，MCP SDK 的 STDIO 设计缺陷影响了约 20 万个实例，涉及超过 1.5 亿次包下载。这恰恰说明，Agent 的工具协议层需要基础设施级的安全支撑，不能只靠应用层协议解决。鲲鹏的 CCA + eBPF 方案在这个问题上有结构性优势。

"新 POSIX"：标准之争的野心与风险

openEuler 在 KADC 2026 上提出了一个极具野心的概念：Agent POSIX。

在 openEuler 的架构中，Agent Infra 软件栈分为三层：

• 底层 Agent Kernel：在超节点内核中实现原生调度与安全
• 中间层 Agent Service：将安全、记忆、沙箱等抽象为 Agent POSIX 原语，让开发从"造轮子"变成"拼积木"
• 上层：支持各类智能体应用

"Agent POSIX"这个命名有明确的指向。POSIX（Portable Operating System Interface，可移植操作系统接口）定义了 Unix/Linux 应用的可移植性标准，是 40 年来软件生态的基础。任何符合 POSIX 标准的程序，都可以在任何 POSIX 兼容的操作系统上运行。

华为想在 Agent 时代做类似的事：定义 Agent 运行时的可移植性标准。如果一个 Agent 框架（比如 LangGraph）调用的是 Agent POSIX 原语而非直接操作 Docker API 或文件系统，那么它就可以在任何符合 Agent POSIX 标准的基础设施上运行——不管是鲲鹏超节点、AWS 还是本地集群。

如果成功

所有 Agent 框架都可以在符合"Agent POSIX"的基础设施上运行，无需针对特定硬件或 OS 做适配。开发者的 Agent 代码可以在鲲鹏、AWS、阿里云之间无缝迁移。

这将是 Agent 时代的"Linux 时刻"——操作系统标准化带来的生态爆发。

如果失败

又一个华为自己的封闭标准。历史上，华为多次尝试定义行业标准（如鸿蒙的分布式能力、HMS Core），但真正获得行业广泛采纳的案例不多。标准的形成需要多方参与，不是一家能定的。

判断

鲲鹏 415 万开发者、7000+ 生态伙伴、openEuler 的开源基础（2100+ 企业、2.7 万贡献者、1600 万套装机量）提供了可能性。但关键看两点：

1. 是否有非华为系的重要参与者加入。如果 Agent POSIX 只在鲲鹏生态内流通，它就是事实上的封闭标准。只有当阿里云、腾讯云、甚至海外厂商基于这个标准实现自己的 Agent Infra，它才可能成为真正的行业标准。
2. MCP/A2A 等已有协议的兼容性。Agent POSIX 不能和现有的工具协议竞争，而应该成为它们的底层支撑。如果 Agent POSIX 和 MCP 是替代关系而非互补关系，开发者不会买账。

目前来看，Agent POSIX 更像是 openEuler 的架构理念而非成熟的标准化提案。但它提出的问题是对的：Agent 需要一个标准化的运行时接口层，正如 40 年前 Unix 应用需要 POSIX。

判断

Agent Infra 作为独立类别的确立条件

三个条件，逐一检验：

1. Agent 负载持续增长。 几乎确定。从 ChatGPT 的 function calling 到 OpenAI 的 Codex，从 Anthropic 的 computer use 到 Google 的 A2A 协议，行业方向已经明确：LLM 的下一步是 Agent。DeltaBox 论文揭示的 47%-77% 状态管理开销，证明了 Agent 对基础设施的压强是真实的。

2. CPU 成为 Agent 瓶颈。 正在发生。Agent 的控制流密集集中在 CPU 上执行，多路径探索使 CPU 侧开销可能反超 GPU。鲲鹏超节点的统一内存编址和百纳秒互联直接回应了这个瓶颈。

3. 通用基础设施无法有效承载。 已有数据支撑。Docker 冷启动数百毫秒、E2B checkpoint 数秒、Firecracker snapshot 数百毫秒——这些方案在 Agent 的毫秒级 fork 需求面前力不从心。专门为 Agent 设计的沙箱（如 DeltaBox 的 14ms checkpoint / 6ms restore）才能满足需求。

三个条件中两个已经确认，第三个趋势明确。Agent Infra 作为独立基础设施类别的确立只是时间问题。

鲲鹏方案的核心优势

唯一从芯片层系统化设计 Agent Infra 的方案。 海外方案要么专注编排（LangGraph、CrewAI），要么专注单点优化（E2B 做沙箱、Zep 做记忆），没有人从 CPU 互联、OS 调度、内存架构、安全隔离的全栈角度思考 Agent 运行时。

通算+智算协同的架构在 Agent 场景有天然优势。 24TB 统一内存池让 Agent 的记忆服务不需要在持久化和低延迟之间做取舍。灵衢协议的百纳秒互联让跨节点沙箱 fork 的代价接近本地操作。

核心风险

"新 POSIX"能否获得行业共识。 这是最大的不确定性。标准之争不是技术之争，是生态之争。鲲鹏有 415 万开发者，但中国市场的开发者数量不等于全球标准的合法性。

海外 Agent 生态是否愿意适配鲲鹏。 MCP 已有 9700 万次下载，A2A 有 50+ 合作伙伴。这些协议的运行时假设是"标准 Linux + Docker/Firecracker"。让它们适配 Agent POSIX 需要强有力的性能证据和经济激励。

交付能力。 KADC 2026 展示的是架构蓝图和部分实测数据。从蓝图到大规模商用部署之间，还有工程实现、生态适配、客户教育等漫长的路径。华为在企业级市场的交付能力经历过验证（运营商、金融），但在 Agent 这个新兴市场的交付速度仍有待观察。

一个更深的观察

Agent Infra 的命题，本质上是中国 AI 基础设施产业的一个独特机会窗口。

在 GPU/AI Infra 层，NVIDIA 的 CUDA 生态壁垒极高，中国厂商追赶了五年仍在追赶。但在 Agent Infra 层，全球范围内没有 NVIDIA 级别的垄断者——E2B 还在种子期，LangGraph 是个 Python 框架，MCP 只是个协议。这个领域的"操作系统"位置是空的。

华为是第一个认真争夺这个位置的玩家。鲲鹏超节点的全栈设计、openEuler 的开源基础、Agent POSIX 的标准野心，都指向同一个目标：成为 Agent 时代的 Linux。

能不能做到，取决于两件事：生态的开放程度，和交付的速度。不是技术能力——华为的技术能力已经被反复验证——而是让非华为系的开发者和厂商觉得这个生态值得加入的能力。

这是 Agent Infra 之战的核心，也是最难的部分。

---

本文为 KADC 2026 系列分析第 3 篇。数据来源包括 KADC 2026 官方发布、openEuler 社区文档、DeltaBox 论文（上海交大 & 华为，arXiv 2605.22781）、CSA MCP 安全研究报告、各 Agent 框架官方文档。