为什么必须从算力治理出发，而不是 API 设计

算力与治理边界，才是 AI 原生基础设施架构的真正底线。

上一章给出了“三平面 + 一闭环”的一页参考架构。本章将进一步聚焦一个 CTO/CEO 级别的核心问题：

AI 原生基础设施到底应当如何分层？哪些属于 API/Agent 的“控制面”，哪些属于 runtime 的“执行面”，哪些必须下沉到“治理面（算力与经济约束）”？

这个问题之所以关键，是因为过去一年大量“转向 AI”的平台公司，常见的误区是：把 AI 当成 API 形态变化，而不是系统约束变化。当你的系统从“服务请求”转向“模型行为”（Agent 的多步行动与副作用），真正决定系统边界的，往往不是 API 设计是否优雅，而是：算力、上下文与经济约束是否被制度化为可执行的治理边界。

本章的核心观点可以归纳为：

AI 原生基础设施必须从“后果（Consequence）”出发设计，而不是从“意图（Intent）”出发堆叠能力；控制面负责表达意图，但治理面负责限定后果。

分层的目的：将“意图”与“资源后果”用工程结构绑定

在 AI 原生基础设施中，MCP、Agent、Tool Calling 等机制让系统能力增强的同时，也带来了更高的风险。这里的风险并非抽象意义上的“不可控”，而是工程意义上的“后果不可预算”：

• 行为路径爆炸、长上下文与多轮推理带来资源消耗的长尾；
• 同样的“意图”，可能导致数量级不同的 token、GPU 时间，以及网络/存储压力；
• 若缺乏治理闭环，系统会在“功能更强”的同时走向“成本与风险失控”。

因此，分层的根本目的不是抽象美学，而是实现一个硬约束目标：

确保每一层都能把上层“意图”翻译成可执行计划，并产生可计量、可归因、可约束的资源后果。

换句话说，分层不是为了让架构图更清晰，而是为了把“谁在表达意图、谁在执行、谁在承担后果”写进系统结构里。

AI 原生基础设施五层结构与“三平面”映射

为了帮助理解分层逻辑，下图细化了上一章“三平面”架构，提出了更具落地性的“五层结构”：

• 上两层 = 意图平面（Intent Plane）
• 中间两层 = 执行平面（Execution Plane）
• 最底层 = 治理平面（Governance Plane）

下方为五层架构的详细展开，展示了每一层的主要职责和典型能力：

需要特别指出，MCP 属于 Layer 4（意图与编排层），而非 Layer 1。原因在于：MCP 主要定义“能力如何暴露给模型/Agent 以及如何被调用”，解决的是控制面的一致性与可组合性，但并不直接负责“能力调用的资源后果如何被计量、约束与追责”。

MCP/Agent 是“新控制面”，但必须被治理层约束

MCP/Agent 之所以被称为“新控制面”，是因为它们将系统的“决策”从静态代码迁移到动态过程：

• “工具目录 + schema + 调用”构成可组合的能力面（capability surface）；
• Agent 通过选择工具、调用工具、迭代推理来完成任务；
• “策略”不再仅存在于代码分支，而以路由、优先级、预算与合规意图的形式被表达。

但需要强调一条基础设施立场，也是本章的立论基点：

MCP/Agent 能表达意图，但 AI 原生的关键在于：意图必须被翻译为可治理的执行计划，并被计量与约束到经济可行的边界内。

这句话旨在纠正两个常见误区：

• 控制面不是起点：将 MCP/Agent 视为“AI 平台升级的入口”，容易导致系统走向“能力优先”路径；
• 治理面是底线：当算力与 token 成为产能单位，任何不受约束的“意图表达”都会以成本、延迟或风险的形式泄漏。

因此，系统分层应明确：Layer 4 负责“表达”，Layer 1/2/3 负责“兑现并承担后果”，而治理闭环负责“纠偏”。

“上下文”正在上升为新的基础设施层

在传统云原生系统中，请求状态大多短命，更多依赖应用层状态管理，基础设施通常只负责“运算与网络”，无需理解“请求上下文”的经济价值。

AI 原生基础设施则不同。long-context、多轮对话、multi-agent 推理让 推理状态（inference state）经常跨请求存活，并直接决定吞吐与成本。尤其是 KV cache 与上下文复用，正从“性能优化技巧”演变为“平台产能结构”。

可以总结为一条基础设施规律：

当某种状态资产（context/state）成为系统成本与吞吐的决定变量，它就会从应用细节上升为基础设施层级。

这一趋势已在行业中逐步显现：推理上下文与 KV 复用被明确上升为“基础设施层”能力建设方向。未来还将扩展到分布式 KV、参数缓存、推理路由状态、Agent 记忆等一系列“状态资产”。

AI 原生基础设施的底座：参考设计与交付体系

AI 原生基础设施远不止“买几台 GPU”那么简单。与传统互联网服务相比，AI 工作负载有三大特征，使得“底座”必须更工程化、更产品化：

• 拓扑依赖更强：网络 fabric、互联、存储层级与 GPU 亲和性决定可用吞吐；
• 稀缺资源更硬：GPU 与 token 吞吐的边界比 CPU/内存更“不可弹性化”；
• 交付复杂度更高：多集群、多租户、多模型/多框架并存，只有“可复制交付”才可能规模化。

因此，AI Infra 不只是组件列表，更必须包含“可规模化交付与可重复运行”的体系能力：

参考设计（validated designs）

• 将“正确的拓扑与配比”固化为可复用方案。

自动化交付

• 将部署、升级、扩缩、回滚与容量规划制度化。

治理落地

• 将预算、隔离、计量与审计作为默认能力，而非事后补丁。

从 CTO/CEO 视角，这意味着：你买到的不是“硬件”，而是“可预期产能的交付体系”。

CTO/CEO 视角下的“分层责任边界”

为便于企业内部对齐“谁负责什么、失败的代价是什么”，下表将“技术分层”映射到“组织责任”，避免平台团队只做控制面、却无人承担后果边界。

可以看到，AI-native 的组织难点不在“有没有 agent”，而在“层间闭环是否建立”。当模型驱动放大后果，组织必须将治理机制制度化为平台能力：预算可执行、后果可解释、异常可追责、策略可回写。这才是“从算力治理出发”而非“从 API 设计出发”的真实含义。

总结

AI 原生基础设施的分层设计，核心在于将“意图”与“资源后果”工程化绑定。控制面负责表达意图，治理面负责限定后果。只有将治理机制制度化为平台能力，才能在能力提升的同时，确保成本、风险与产能可控。未来，随着上下文、状态资产等新变量的基础设施化，AI Infra 的交付体系也将持续演进，成为企业可持续创新的底座。

参考文献

• Google SRE - Capacity Planning - sre.google
• AWS Well-Architected - Cost Optimization - aws.amazon.com
• Microsoft FinOps for AI - learn.microsoft.com