什么是AI平台架构师？模型、数据、运行时、安全与运维

AI 平台架构师设计可复用的 AI 基础，使多个应用、团队或租户上下文能够通过它访问模型、数据与检索、智能体与工具运行时、身份与权限、评估、可观测性、配额、密钥以及部署能力。该角色的范围比基础设施更广，但比拥有每一个 AI 赋能产品更窄：其核心职责是决定哪些应当共享、共享能力如何治理与隔离，以及哪些必须保持为解决方案专属。

AI 平台架构师实际上架构什么？

工作的对象是平台：一组共享能力，在减少重复集成工作的同时，保留明确的安全、数据和运营边界。平台可以向众多消费方解决方案暴露模型访问、提供商适配器、检索原语、智能体执行、工具代理、策略执行、评估、遥测和部署服务。

平台的价值并不只是因为组件被集中化。当消费方获得具有清晰契约、所有权、隔离、可观测性和生命周期规则的稳定能力时，平台才有价值。因此，关键的架构问题不是“每个人都应该使用哪个模型？”，而是“哪些职责可以被安全地标准化和复用，同时不抹去每个解决方案的需求？”。

解决方案架构与平台架构解决不同范围的问题

	AI 解决方案架构师	AI 平台架构师
主要范围	One concrete AI-enabled product, workflow or application.	Reusable AI capabilities consumed by multiple solutions, teams or tenant contexts.
核心问题	How should this solution meet its business, data, security, quality and operational requirements?	Which shared capabilities and controls should solutions consume, and where must solution-specific ownership remain?
数据权威	Defines which domain data is authoritative and how the solution may use it.	Provides storage, retrieval, provenance or access primitives without automatically becoming the authority for every domain.
评估	Defines task-specific quality and acceptance criteria.	Provides reusable evaluation, telemetry and release mechanisms; it cannot define every domain's success threshold.
生命周期	Owns the lifecycle of the specific workload.	Owns shared capability versions, compatibility, onboarding, quotas, policy and operational contracts.

最简单的例子

设想一个组织有五个 AI 赋能产品：一个内部文档助手、一个客户支持副驾驶、一个软件工程智能体、一个合同审查工作流和一个产品搜索助手。每个产品都可以独立集成模型 API、保存凭据、实现重试、收集令牌指标、创建检索代码并构建自己的工具权限。

当每个团队都发明不同的安全和运营模型时，这种重复既昂贵又危险。共享平台则可以提供经批准的提供商连接、模型发现、配额、凭据、租户感知访问、通用遥测、可复用检索服务以及智能体/工具运行时契约。

但平台必须在正确的边界处停止。合同审查解决方案可能需要法律文档权威和引用规则，而软件智能体不需要。产品搜索助手可能需要特定于商务的新鲜度和授权规则。可复用基础设施并不会让所有领域事实都变得可复用。

共享 AI 请求路径

1

1. 消费方标识自身

调用应用、用户、服务、团队或租户通过经过身份验证的身份和明确范围进入。

2

2. 平台策略生效

网关和策略层确定允许的提供商、模型、配额、数据路径、工具和执行模式。

3

3. 共享能力执行

请求可能使用推理、检索、智能体运行时、工具访问或其他可复用平台服务。

4

4. 解决方案专属上下文保持权威

消费方解决方案提供领域规则、用户意图、数据权威、任务特定约束和验收逻辑。

5

5. 遥测和证据被捕获

平台记录身份、路由、模型/提供商、延迟、成本、错误、工具活动以及其他允许的可观测性信号。

6

6. 结果在解决方案契约下返回

解决方案仍然负责判断输出对其用户和领域是否可接受。

简单例子止步之处

集中化并不自动等于架构。在多个模型 API 前放置一个端点是有用的，但它本身并不会创建 AI 平台。生产平台还需要身份边界、能力契约、提供商健康与生命周期处理、配额、密钥所有权、可观测性、兼容性规则、安全控制、发布纪律和明确的运营责任。

相反的失败也很常见：把每个提示词、向量索引、业务规则、智能体和应用工作流都放进一个“AI 后端”。这会创建一个单体，其共享状态是偶然的而非架构性的。平台应当标准化横切能力，而不是仅仅因为涉及 AI 就吸收领域所有权。

最重要的平台决策：共享与解决方案专属

架构职责映射

1. 模型与提供商访问

平台架构师定义消费者如何发现和调用模型，而不强迫每个应用硬编码某一个提供商。这包括提供商适配器、模型标识符、能力元数据、身份验证、健康检查、端点配置、请求规范化和兼容行为。

提供商抽象必须保持诚实。不同提供商暴露不同的上下文限制、工具语义、结构化输出行为、多模态能力、安全控制、缓存、定价和故障模式。好的抽象会创建稳定的平台契约，同时保留对无法被有意义地扁平化的能力的访问。

2. 网关、路由、配额与成本控制

共享 AI 网关可以集中处理身份验证、路由、限流、重试、令牌限制、使用归因和策略执行。Microsoft 当前的 AI Gateway 指南明确将每分钟令牌限制、配额和多项目隔离视为平台关注点；AWS 同样暴露账户和模型配额以及集中控制。

因此，当网关承载 AI 特定策略和运维语义时，它就不只是反向代理。但它不应静默地做出业务决策。路由策略可能偏好健康的本地模型、成本更低的提供商或符合区域合规的端点；该路由对特定任务是否可接受，仍然是平台与解决方案之间的契约。

路由还需要故障语义。如果首选模型不可用，平台必须知道是否允许回退、云路由是否需要明确同意、能力较低的模型是否有效，以及该决策如何暴露给可观测性。

3. 共享数据、检索与接地服务

检索服务是强有力的平台候选，因为解析、分块、索引、词法搜索、语义搜索、元数据过滤、来源和引用机制都可复用。然而，平台不能将共享检索引擎与共享事实来源混为一谈。

解决方案仍然拥有以下问题：哪个语料库是权威的？哪个版本有效？此用户能否看到此文档？数据必须有多新鲜？什么算作充分证据？检索失败时能否生成答案？即使平台提供检索机制，这些也是领域和解决方案需求。

这种边界在多租户系统中尤为重要。技术上共享的索引或向量服务并不证明跨租户可见性合理。授权上下文必须在检索过程中保留，而不是仅在搜索结果已经跨越边界之后才添加。

4. 智能体与工具运行时

智能体系统增加了可复用的运行时关注点：线程/会话生命周期、规划循环、工具注册、工具调用、取消、超时、人工审批、内存/状态接口、远程智能体协议和追踪关联。平台可以提供这些机制，使每个产品无需重新构建它们。

平台还必须将工具权限与模型能力分开。模型能够生成 shell 命令并不意味着运行时应允许 shell 执行。权限边界属于应用/运行时架构，并且必须独立于模型可执行。

当前 AWS Agentic AI 指南强调有界代理、明确授权、端到端追踪、版本化行为工件以及与后果相称的人类监督。这些都是平台赋能关注点，但消费方解决方案仍然定义其领域内哪些操作是合法的。

5. 身份、租户隔离与授权

AI 平台通常位于高价值模型、专有数据和具备操作能力的工具之前。因此，身份验证只是开始。架构必须在每个需要它的特权操作中携带用户、服务、应用和租户上下文。

RBAC 和租户隔离解决不同的问题。RBAC 回答一个身份可以做什么；租户隔离回答该身份可以对哪个租户的资源进行操作。一个检查角色但丢失租户上下文的平台仍然可能暴露错误的数据。

Microsoft 当前的 AI 工作负载指南明确建议身份分段和授权感知的内容访问。AWS 的多租户生成式 AI 平台指南同样将逻辑隔离、集中控制和可审计性视为平台关注点。

6. 密钥、凭证与信任边界

平台应定义谁拥有提供商密钥、远程持有者令牌、签名材料和工具凭证，它们存储在哪里，哪个进程可以访问它们，如何轮换它们，以及它们是否可能到达浏览器或不受信任的渲染器。

这是一个架构边界，而不是实现细节。如果每个消费方应用都将提供商凭证复制到自己的配置中，组织就重复了运营负担和爆炸半径。只有当平台本身具有更窄、可审计的访问路径时，集中化才能降低这种风险。

7. 评估、可观测性与可审计性

可复用平台可以提供评估工具、追踪 ID、模型/提供商元数据、令牌和成本指标、延迟、错误率、提示/模型版本关联、代理/工具追踪以及受控日志记录。AWS 和 Microsoft 都将可观测性和评估视为 AI 工作负载的核心生产关注点。

平台评估和解决方案评估必须保持分离。平台可以验证端点是否健康、模型版本是否通过通用回归套件以及追踪是否完整。如果没有领域特定的基准真相和验收标准，它无法判定法律答案、医疗工作流或产品推荐是否可接受。

日志记录还创建了隐私边界。提示和响应日志可能包含敏感或专有数据。因此，平台架构师必须决定记录什么、脱敏什么、采样什么、保留什么以及可访问什么，而不是假设更多遥测总是更安全。

8. 运行时、部署与位置

平台架构师决定共享 AI 能力如何部署和访问：托管云服务、自托管端点、本地推理、混合路由、容器化服务、桌面运行时、私有网络或气隙环境。重要的区别在于控制/运行时进程在哪里运行以及推理和数据处理实际发生在哪里。

本地客户端仍然可能调用云模型。云控制平面可能路由到本地模型。远程代理可能在客户网络内执行工具。因此，架构图必须显示信任和数据流边界，而不是将“本地”和“云”用作模糊的标签。

9. 平台生命周期、兼容性与入门

只有当消费方能够长期依赖可复用能力时，它才成为平台。这需要版本化契约、迁移规则、兼容性策略、弃用、发布测试、回滚、事件所有权、容量规划、文档以及新团队或应用的入门路径。

快速发展的 AI 生态系统使这一点尤为重要。模型名称、SDK、协议版本、提供商 API 和安全能力各自独立变化。平台必须吸收其中一些波动性，同时不隐藏对解决方案行为有重大影响的变更。

一个实用的控制平面/执行平面/解决方案平面模型

这种分离有助于诊断平台漂移。如果应用程序必须知道每个提供商特定的凭据和端点，那么平台契约就太薄弱了。如果平台决定哪个客户记录在法律上是权威的，或者某个领域答案是否可接受，那么平台就已经越界进入了解决方案所有权。

AI 平台架构师应该产出什么？

工作主要是权衡，而不是最大程度的集中化

常见的平台权衡

	压力 A	压力 B
提供商抽象	Stable portable platform API	Access to provider-specific capabilities and fast innovation
复用	Shared services reduce duplication	Isolation and domain autonomy prevent unsafe coupling
治理	Central policy and auditability	Team speed and local experimentation
可观测性	Rich traces for debugging and evaluation	Privacy, data minimization and logging cost
可用性	Fallback and multi-provider resilience	Predictable quality, compliance and data-location guarantees
平台范围	More reusable capabilities	Smaller blast radius and less platform lock-in

这与相邻角色有何不同？

这些边界是组织性的，不是普遍的。在小型团队中，一个人可能承担多项职责。在受监管的企业中，它们可能分散在架构、安全、平台、数据和运营组中。有用的区别是架构责任的范围，而不是组织图上印的职位名称。

实现证据：这些平台边界如何出现在我自己的工作中

Aaasaasa AI Client：提供商、运行时和权限分离

Aaasaasa AI Client 是一个使用 Nuxt 4、Electron 和 TypeScript 构建的本地优先桌面 AI 工作区。其 AI Hub 有意分离代理/客户端、提供商、模型、连接/运行时位置、权限和 Web 客户端，而不是将它们视为一个配置值。

该实现包括直接提供商适配器、Codex 代理运行时集成、本地 Ollama/LM Studio 路径、OpenAI 兼容服务、集中式工作区权限、主进程凭据存储、DuckDB、Qdrant/向量支持、PDF/可读性提取以及基于 MCP 的认证目录访问。

两个平台经验尤其相关。首先，本地运行时与本地推理不同：本地 Codex 进程仍然可以使用云模型。其次，自动路由不会静默地从本地回退到付费云推理。这使得路由策略和运行时局部性变得明确，而不是从 UI 标签推断。

Aaasaasa AI CMS：作为平台边界的租户范围授权

Aaasaasa AI CMS 代码库提供了一个独立的实现示例：租户范围的 RBAC 通过绑定到租户标识符的角色、权限和用户角色分配来表示。系统权限按能力分组，角色查找和更新保持租户范围。

这本身并不能证明一个完整的 AI 平台，但它与最困难的共享平台边界之一直接相关：可复用服务必须保留谁可以做什么以及针对哪个租户。在应用平台之上添加 AI 推理或检索并不会消除这一要求。

架构上的含义是，模型网关、检索服务和代理应使用已建立的身份/租户上下文，而不是发明一个并行的、仅限 AI 的授权体系。

真相源研究引擎：共享检索机制而不共享真相

真相源研究引擎提供了第三个实现示例。不同的研究模式共享一个共同的证据核心：来源、工件、溯源、主张、关系、矛盾、参考模型和审计追踪。该系统还提供本地词汇检索、可选的语义检索、提取、快照和基于 SHA-256 的溯源。

该项目明确将搜索和语义相似性视为发现信号而非证据。结果必须追溯到具体的来源和定位符，然后才能支持一项主张。这正是 AI 平台所需的区分：可复用的检索机制可以共享，而证据权威仍由消费方法和领域来治理。

该引擎还说明了为什么一个共享平台不需要一种共享解释。历史、科学/技术、市场情报和监控模式可以复用核心证据基础设施，同时保留特定模式的方法论。

当前架构指南如何支持这一平台范围

ISO/IEC/IEEE 42010:2022 为软件、系统、企业及相关实体的架构描述提供了一般性规范。它并未定义 AI 平台架构师，但它强化了表达架构关注点、关系和视角的必要性，而不是将架构简化为技术清单。

NIST AI RMF 1.0 和生成式 AI 配置文件将 AI 风险管理框定为贯穿生命周期，而不仅仅是在模型选择时。因此，治理、映射、测量和管理与一个平台架构兼容，该架构在许多消费工作负载中承载共享控制和证据。

微软当前的 AI 工作负载指南将应用程序设计、数据、安全、运营、测试/评估和 GenAIOps 视为相互关联的架构领域。其当前的 AI 网关指南还展示了实际的平台关注点，例如集中式模型访问、项目特定的令牌限制、配额和多团队隔离。

AWS 当前的生成式 AI 透镜和多租户平台场景同样将基础平台控制与消费应用程序所有权分开。AWS 明确指出，中央平台可以强制执行共享护栏和可审计性，而数据质量和工作负载特定的可观测性仍然是消费应用程序或数据生产者的责任。

供应商产品各不相同，但跨来源的模式是稳定的：生产 AI 平台必须协调身份、数据访问、模型、策略、评估、可观测性、容量、成本和生命周期。GPU 集群或模型端点仅覆盖该责任的一部分。

常见误解

AI 平台架构师应预防的故障模式

实用的平台架构决策序列

从平台需求到可操作的共享能力

1

1. 识别真实消费者

列出将消费该平台的解决方案、团队、租户和工作负载；避免为假设的复用构建平台。

2

2. 定义共享边界

将横切机制与解决方案特定的领域权限、工作流和验收分开。

3

3. 首先定义身份和隔离

在共享检索或工具能力之前，建立用户、服务、应用程序、租户、区域和数据分类。

4

4. 定义能力契约

指定模型/提供商、检索、代理/工具、网关和遥测API，并明确所有权和版本控制。

5

5. 决定提供商和运行时策略

选择托管、自托管、本地或混合执行，并记录回退、位置和能力语义。

6

6. 设计数据和检索边界

定义来源、授权传播、语料库所有权、索引和证据责任。

7

7. 添加配额、密钥和策略

控制成本、容量、凭证、工具权限、安全控制和影响范围。

8

8. 构建评估和可观测性契约

提供平台指标和追踪，同时将领域真实基准和验收留给解决方案。

9

9. 定义生命周期和运维

对能力进行版本控制、测试升级、记录弃用、回滚、事件、容量和消费者入门。

10

10. 用多个消费者验证

当共享能力实际上服务于不同的工作负载，而不强迫它们进入同一领域模型时，平台声明才变得可信。

边缘情况和角色限制

只有一个AI应用程序的小型组织可能不需要独立的AI平台或平台架构师。过早平台化可能产生比价值更多的抽象。正确的架构可能是一个设计良好的解决方案，带有几个可复用模块。

气隙或主权部署会显著改变提供商、更新和可观测性模型。模型托管、工件分发、身份集成和遥测导出可能都需要本地等效方案。

高度监管或高后果的工作负载可能需要更强的物理或组织隔离，而不是逻辑共享平台。复用从来不是削弱所需安全边界的充分理由。

托管云AI服务可以减轻实现负担，但不会消除架构责任。组织仍然决定身份、数据访问、日志记录、保留、配额、模型资格、回退、评估和解决方案验收。

平台边界也可能因模态而异。文本推理、多模态生成、语音、计算机使用和自主代理即使共享提供商和身份基础设施，也可能有不同的延迟、数据、权限和可观测性要求。

什么会改变这个答案？

如果组织范围发生变化，核心定义也会改变。如果架构师负责一个工作负载，角色就更接近AI解决方案架构师。如果职责扩展到组织范围内的能力战略、投资、标准和目标状态组合，则转向企业AI架构。

每当提供商、网关产品、代理协议、监管义务、模型能力或部署约束发生变化时，实施指南就会改变。这就是为什么平台架构应该将稳定的职责和契约与当前的供应商机制分开表达。

AI平台架构师检查清单

结论

AI平台架构师负责AI能力与消费它们的解决方案之间的可复用架构。该角色定义模型、提供商、检索、代理、工具、身份、租户、密钥、评估、可观测性、配额和运行时操作如何成为可靠的平台服务，而不是重复的一次性集成。

困难的部分不是最大化复用，而是选择正确的边界。强大的平台在多个消费者真正受益的地方标准化机制、策略和操作，同时保留解决方案特定的数据权限、业务逻辑、安全要求和验收标准。

这种区别也解释了与AI解决方案架构的关系：解决方案架构师使一个AI赋能的系统适合其目的；平台架构师使共享的AI能力在许多此类系统中安全、可复用、可操作和可演进。

相关规范知识

本文位于生成式AI组件、ADR与NFR、以及AI解决方案架构的规范基础之后。这些概念是前提条件，因为平台的存在是为了提供可复用的系统能力，并针对明确的质量和运营需求编码架构决策。

检索增强生成是可能通过平台提供的能力的一个例子，但平台不应将检索基础设施、领域知识和答案有效性混为一谈。

什么是RAG？其工作原理的最简解释

检索增强生成的规范介绍，以及模型生成与外部知识检索之间的边界。

代理协议、租户隔离、AI治理、模型路由、上下文工程和MLOps/LLMOps是下游或相邻的知识节点。一旦平台边界明确，它们就更容易推理。

常见问题

AI平台架构师FAQ

AI平台架构师与AI解决方案架构师相同吗？

不同。解决方案架构师专注于一个具体的AI赋能解决方案。平台架构师专注于可复用的AI能力、控制和运营契约，以支持多个解决方案。

AI平台需要托管自己的模型吗？

不需要。平台可以使用托管云模型、自托管模型、本地推理或混合策略。架构必须明确提供商、位置、身份、路由、数据和运营后果。

AI网关足以成为AI平台吗？

通常不够。网关可以是重要的平台组件，但完整的平台还需要身份、密钥、数据/检索、评估、可观测性、生命周期和运营所有权的契约。

检索应该集中化吗？

检索机制通常可以共享，但领域权威、授权、新鲜度、证据充分性和语料库所有权应保持明确。共享基础设施并不意味着共享真相。

平台评估能替代应用评估吗？

不能。平台评估可以测试共享能力和回归。每个解决方案仍然需要特定任务的真实基准、验收标准和领域质量阈值。

多租户只是RBAC吗？

不是。RBAC决定身份可以做什么。租户隔离决定身份可以对哪个租户的资源进行操作。平台通常需要两者。

术语表

关键AI平台架构术语

AI平台

由多个应用、团队或租户上下文消费的一组可复用的AI相关技术和运营能力。

AI网关

AI端点的网关层，可在基本代理之外添加认证、路由、配额、策略、重试、成本归属和AI特定遥测。

提供商适配器

将平台契约映射到模型提供商的API、能力、健康状况和故障语义的组件。

租户隔离

防止一个租户上下文访问另一个租户资源的边界，独立于角色权限。

能力契约

描述共享平台服务提供什么以及消费者必须提供或拥有什么的版本化接口和行为协议。

接地/检索服务

为AI工作负载查找和提供外部信息的共享机制；它不会自动定义哪些信息对某个领域是权威的。

评估工具

用于运行测试、数据集、模型/提示版本和指标的可复用基础设施；领域验收仍然特定于解决方案。

控制平面

管理平台能力、身份、策略、配额、版本和部署状态的配置和治理层。

主要来源和当前架构指南

以下来源支持一般架构和生产平台声明。Aaasaasa AI客户端、Aaasaasa AI CMS和真相源研究引擎部分明确为原创实现证据。当前状态的外部参考已于2026年10月8日检查。

ISO/IEC/IEEE 42010:2022 — 架构描述

当前发布的架构描述概念和关系的国际标准。

NIST AI风险管理框架

NIST的AI RMF资源和当前状态；截至2026年10月，AI RMF 1.0正在修订中。

NIST AI 600-1 — 生成式AI概况

在整个AI生命周期中应用AI风险管理考虑的生成式AI概况。

Microsoft Azure Well-Architected — AI工作负载

涵盖AI应用、数据、运营、评估、负责任AI和生命周期问题的当前架构指南。

Microsoft — AI工作负载设计原则

关于身份分段、安全边界、遥测、性能、数据和平台权衡的当前指南。

Microsoft Foundry — AI网关架构

关于共享项目访问、令牌遏制、配额和治理的当前AI网关指南。

Azure架构中心 — 通过网关访问模型

关于集中模型访问、路由、限流、故障转移和客户端/平台责任的架构指南。

AWS Well-Architected — 生成式 AI 透镜

面向生成式 AI 工作负载的当前生产架构指导，涵盖安全性、可靠性、运维、性能和成本。

AWS — 多租户生成式 AI 平台场景

当前示例，将中央平台控制与可审计性，同消费应用的数据质量及工作负载特定职责区分开来。

AWS Well-Architected — 代理式 AI 设计原则

关于受限代理权限、可追溯性、版本化行为、显式契约和人工监督的当前指导。

AWS CloudWatch — 生成式 AI 可观测性

针对模型、代理、知识库、工具以及成本/延迟/错误分析的当前可观测性能力和生产指标。