AI时代的技术架构升级与行业落地

7月18日，我作为腾讯云架构师成都同盟成员参加了同盟组织的“走进新华三 & 海光”线下活动，并做了《AI时代的技术架构升级与行业落地》的分享。现场时间有限，一些内容没法完整展开，故而撰写本文，作为本次分享的补充和完整呈现。

AI原生分层架构的定义

所谓“AI时代的技术架构”，从本质讲，可以将其定义为“AI原生架构（AI Native Architecture）”。在理解何为AI原生时，常常有三个词容易让人混淆：AI Enable、AI First和AI Native。

AI Enable（AI赋能），通常是在既有系统上加AI功能，例如ERP里挂聊天窗口。抽掉模型，核心业务照旧跑，只是少一块辅助能力。AI First（AI优先），即在产品与业务策略上优先考虑 AI能力的应用与落地，但未必对底层技术架构进行深度重构。这是一种战略层面的思维转变。AI Native（AI原生）会以AI作为基础底座和骨架，模型或智能体作为架构的主路径，一旦抽掉AI，业务明显降级，甚至走不通。

根据我个人在AI领域的项目经验和咨询经验，我把企业的AI原生架构提炼为五个层次。

基础设施层仍建立在云原生IaaS上：计算、网络、存储、容器和控制面。需要调整的是GPU与加速卡调度、Agent长会话带来的连接与状态管理，以及可观测指标。对于建立在云设施之上的传统软件应用，运维层面主要观察CPU、内存和磁盘的资源利用情况，当然也包括应用本身的运行情况和服务调用链路；到了AI原生应用，考虑到大模型和Agent的运行特征，还需要考虑推理延迟、队列等待、token消耗、会话时长和失败原因，对算力资源的调度也不能只按“几张卡”分配，还要考虑拓扑、亲和和设备健康状态。

AI平台层分三个中心：模型中心、上下文中心和评测中心。

模型中心是AI平台的大脑，负责模型接入、版本、路由和成本控制。上下文中心为AI平台提供有价值的知识，负责企业知识、语义和运行时上下文。评测中心确保AI平台的运行是可信的，负责质量、安全和合规度量。AI平台缺任何一块，企业各项目组就可能各自对接模型API，对模型的管理和调用就会出现重复建设，很快陷入失控。

智能编排层处理Agent如何干活，包括单Agent尤其是多Agent的协作与编排，这其中牵涉到A2A的通信协议，以及多角色的分工协作机制。还需要管理长程工作流、状态机以及人机协作流程的Session，并考虑人机协作机制。智能编排层是AI平台与业务场景的结合点，它既能有效地利用大模型的能力，又能感知和分析业务场景的任务要求。此外，通过MCP，可以建立系统内部与外部环境的安全的标准通道。

MCP（Model Context Protocol）是一种开放协议，用Host/Client/Server和JSON-RPC把应用接到外部数据、工具和工作流，引入MCP，可以明显减少私有插件的堆叠。MCP是智能层与业务系统间的标准插座，通过对MCP的监管和控制，例如在Tool Gateway层强制执行权限裁剪，要求写操作必须经由dry-run，即在不实际修改系统状态、不写入数据、不产生真实副作用的前提下，完整模拟一遍程序或命令的执行流程，可以避免因为Agent自行判断带来的安全隐患和误操作。

业务能力层的设计目标是把AI原生技术支持的业务功能做成可复用能力，它是AI+Scenario的组合。倘若传统软件架构难以改造为AI原生架构，也可以采用旁路增强方式，将其封装为一个单独的微服务，运行在AI平台层和智能编排层之上。若此单独的AI原生业务能力需要与存量系统协作，则可通过MCP封装存量系统对外公开的接口，形成AI原生能力与传统业务能力的协作机制。

交互层是业务系统的入口，可以是GUI、LUI（语言界面）、多模态，以及现场可能出现的穿戴设备。同一能力可以出现在大屏、平板或语音入口。这一层负责降低使用成本，并把人的确认和纠正送回平台；智能逻辑不应全部堆在界面上。

五层不必一次建齐。多数企业是旧系统继续跑，按继承、扩展、新建逐步加能力。

技术架构的升级路线

要实现传统软件架构向AI原生架构的升级，重点考虑五层架构的最下面三层：基础设施、AI平台和智能编排。

对于基础设施的升级，可以结合云原生架构和AI原生架构的异同点，选择不同的升级策略，包括继承、扩展和新建。

云原生适合微服务弹性、无状态扩缩和常规监控，而AI工作负载则额外要求加速器利用率、拓扑感知调度、训练/推理排队、长会话状态，以及与token相关的成本信号。但是，这些差异并不构成推倒Kubernetes的理由。控制面、发布流水线、网络策略、密钥和基础监控可以继承。调度与可观测需要扩展：更细的设备资源声明、AI作业配额、成组调度（gang scheduling），把GPU利用率和会话存活纳入监控。推理资源池、模型镜像分发、加速器池化等可以新建，先旁路接入，核心交易不停，验证后再扩大范围。

AI平台需要三大中心协同运转。

模型中心通常先上模型网关，它负责统一鉴权、路由、限流、审计和缓存，并按任务类型、时延和成本做多模型路由与故障切换。相较于云原生架构，AI原生架构面向的对象会从算力转变为意图（intent），模型网关可以建立针对意图的三种路由，即规则路由、语义路由和学习型路由。为了更好地管理token的利用率，需要为模型中心建立FinOps。为此需定义可归因指标：按团队、应用、场景统计token、调用次数、缓存命中和重试成本，再设预算。

当然，FinOps监控的实现是与评测中心配合，由它对模型算力进行监控，为节省算力提供数据支撑。

上下文中心的前提是数据治理。文档丢进向量库（或markdown等非结构数据构成的文档型知识库）不等于可用知识。来源、时效、权限、责任人，以及入库和下线流程需要固化并严格执行。可以引入企业级本体（Ontology）统一对象、关系和可执行动作的语义，由此形成知识库的统一语言，不仅是团队各个角色，人和Agent也要共用这一套标准语言。本体涉及到领域知识的六个核心要素，包括实体、属性、关系、操作、事件和业务规则。抽象出来的这六个要素可以组成表达领域知识的知识图谱。

上下文中心管理的知识除了企业主动治理的数据和知识文档之外，也包括AI原生业务能力在运行过程中产生的有价值的数据。这需要在评测中心增强AI原生可观测能力。

如此一来，上下文中心才能建立由输入层、策展层和进化层构成的知识飞轮：

要让知识飞轮跑起来，当然离不开评测中心。它首先会决定Agent能不能进生产，通过建立黄金集和对抗集，从正反两个方面为Agent带来规范和约束。黄金集是带期望结果、可版本化的基线用例，用于回归，不是用于训练的标记数据。对抗集覆盖越狱、提示注入、越权调用等压力场景。评测中心建立的Guardrails是运行时控制：限制工具白名单、拦截未授权写操作、必要时要求人确认。评测中心还需要引入一键Kill Switch，它是一种运营熔断手段，能够决定出问题后 “关多快”（秒级切断 AI 副作用，回退规则/人工流程），对于高敏感安全场景尤其有效。

上下文中心要求的反哺知识来自评测中心提供的Trajectory级可观测性追踪。所谓Trajectory，是指一次Agent或LLM应用从接收意图到产出结果的完整执行路径记录，通常包含：意图、规划步骤、每次 LLM 调用、工具调用、RAG检索文档ID与业务执行结果。把轨迹里的有效过程和业务结果清洗后回灌知识库或评测集，后续Agent才有可复用的经验，而不是每次从零猜测。

智能编排层以多Agent协作、长程工作流/状态机、MCP协作和Skill为主要建设内容。多Agent协作的内容自不待言，它已经成为发挥大模型能力的重要锚点。对于长程会话，工作流适合固定步骤，状态机适合审批和异常分支。至于人机协作的节点或门禁，则可放在低置信度或高风险环节。MCP把外部系统收成统一调用面，便于在入口施加策略。Skill用来沉淀领域执行规范与过程，允许Agent按需加载Skill，减少每次从头教Agent。当然，一些确定性的功能还应该进一步编写为脚本（Script），这其实是AI原生能力的一个重要设计原则，即解耦不确定性和确定性功能，采用不同的技术手段完成，然后统一由Agent发起调用。

AI原生架构升级的行业实践

就我个人的经验，对制造行业和金融行业的AI原生应用了解较多。当然，我并没有全量和全维度的参与，结合前面提到的五层架构，在不同行业，升级的侧重点有所不同。

制造行业的AI原生架构升级，有一个重要突破点，即在上下文中心建立统一企业级本体语义。

譬如说，产线夜间告警时，如果助手只能搜PDF，经常答不到点上。同一设备在MES是工位码，在EAM是资产号，在点表里又是另一套标识；“停机”在质量域和计划域含义也不同。要让排障Agent能指到具体对象和动作，需要把设备、工艺段、工单、缺陷、备件、资质和可执行操作纳入统一本体，检索和推理沿关系走到权限边界内的对象。成功排障的Trajectory治理后把知识回灌，现场经验才留得住。

建立统一企业级本体语义势在必行，它可以消除ERP/MES等系统的信息孤岛、语义不一致和OT生产现场风险：

金融行业因其特殊性，尤其强调合规性，金融安全更是重中之重，因此，在升级技术架构过程中，需要重视如何建立私有化物理边界，并通过评测中心的观测能力与防护边界与校验能力守护交易等业务安全：

例如，当某个金融交易能力通过Agent执行，一旦Agent调用内部工具修改草稿或触发下游任务时，权限、举证和熔断就必须进评测中心。黄金集覆盖常见准驳情形，对抗集打注入和越权，Guardrails卡住工具写操作，高风险环节强制人审，异常时Kill Switch切断会话。这是一个安全防护的系统工程，缺少任何一环，都可能出现安全漏斗，那就不能轻易启用AI原生业务能力。

当然，不管是什么行业，只要正在实施AI原生架构的升级，都离不开基础设施层和AI平台层的支持。它们的升级从就绪到全量自治，需要经历相对漫长的持续改造和演进过程。下图展现了一个可行的进化过程：

整个升级的持续时间和改造内容受到行业和产品复杂度与成熟度的影响，也与企业的改造决心和团队能力直接有关。当然，在这个过程中，不必追求一次到位。常见顺序是先稳住继承面，再扩平台和观测，最后补编排与治理。上线演示容易，把责任边界画清楚更难。这就牵涉到组织层面的内容了，自然也不在本次分享的范围之内。