【发布实录】云原生+AI，助力企业全球化业务创新

5 月 22 日，在最新一期阿里云「飞天发布时刻」，阿里云云原生应用平台产品负责人李国强重磅揭晓面向 AI 场景的云原生产品体系升级，通过弹性智能的一体化架构、开箱即用的云原生 AI 能力，为中国企业出海提供新一代技术引擎。

发布会回看：https://summit.aliyun.com/apsaramoment

今天我们将和大家分享阿里云云原生 + AI 的最新产品发布，围绕云原生助力 AI 应用构建、云原生可观测 + AI、通义灵码加速应用开发三部分探讨，AI 时代下企业如何使用云原生产品加速全球化业务创新。

云原生助力 AI 应用构建

过去几年，云上应用架构一直在持续演进。

从互联网时代开始，互联网分布式应用架构成为在线业务的标准架构，其典型技术包括分布式微服务、分布式消息队列、分布式数据库以及网关等。随着过去几年云产品逐渐向 Serverless 化演进，Serverless 应用架构也变得越来越流行，典型场景包括 ETL 数据处理、API 服务、音视频处理、事件驱动架构等等。包括最新的 AI 应用，也常常选择 Serverless 基础设施作为运行环境。在这样的架构下，应用被分解成为更小的、原子化的、可复用的粒度，这些原子化的模块可以进行联通和编排，而且借助智能化的手段，这些原子化的能力是可以自动生成的。

过去两年，最火的还要说是 AI 应用架构。像智能体应用、工作流应用，以及对存量应用如何进行智能化、智能体的编排应用等，都属于我们常见的 AI 应用。

下面我们来看一个最简单的 AI 应用架构大致构成，它的中间可能是一个智能体 Agent，围绕它的有像提示词工程，大语言模型，短长期记忆、工具等等一系列能力。下图尝试去描绘一个最典型的 AI 应用架构，以及云原生相关的产品在这个应用架构中，如何帮助大家去构建这样一个好的 AI 应用。

上图最中间展示的是一个 AI Agent 的构建过程。目前市场上一般有两种方式进行 AI 智能体的构建：

一种是完全无代码的流程式方式，比如使用阿里云的 CloudFlow 流程编排实现，或基于阿里云百炼构建智能体工作流和编排。还有些用户会选择在容器服务 ACK 上部署 Dify，在 Dify 里完成一个智能体的整体构建。

另外一种是用编码式的方式去构建。比如在阿里云函数计算 FC 上选择合适 AI 的应用框架后，包括 Spring AI Alibaba，LangChain 等，用代码去实现一个 Agent，并且把它运行到函数计算的算力之上。

智能体构建完成之后，往往还需要一些外部的能力，最常见的包括模型调用和工具调用。

在模型调用方面，今天模型部署的方式和提供服务的方式多种多样。比如在阿里云上，用户可以把自己的大模型，比如说满血版 DeepSeek 部署到 PAI 里面，也可以通过 API 调用的方式到百炼里获取相应服务，或是在 FC 里快速部署一些小的模型。如果是在企业内部，往往需要对这些不同的模型调用进行全局管理，包括流量负载、权限管理、用量管理等方面。这时就需要 AI 网关发挥作用。

另外一类非常重要的调用是工具调用。它就像大模型的一只手，帮助用户获取外面更多的知识，或是完成更多的动作。这个领域过去几个月最受关注的就是 MCP 协议了。对于企业来说，可能需要把自身原有的能力快速变成一个 MCP Server 给到构建的智能体，或是把服务商提供的 MCP Server 给到智能体。同样，随着对 MCP Server 调用量越来越大，这里往往也需要一个 MCP 的网关，能够对整个工具链的调用进行统一管理。当整个 AI 应用构建起来后，来到对外发布环节，在南北向流量管理上也需要一个网关对企业智能体的调用进行管理和保护。

当了解这样的架构和企业需求之后，我们分为几部分为大家展开介绍。

FC AI 应用开发平台 Function AI 全新发布

首先在 AI 应用开发方面，阿里云函数计算 FC 最新推出了 Function AI 能力，可以为用户提供一个简洁易用、弹性开放、企业特性增强的一站式的 AI 应用开发、构建和部署平台。

前面讲到两类 AI 应用的构建方式，第一类是当我已经有一个存量应用，我希望对它进行一些智能化的升级。在这个原有应用的工作流中，可能会增加一些 AI 对模型的调用。这时可能这个原有的存量业务的整个部署运行是没有发生变化的，它更多的是需要模型服务。另外一类是基于模型去构建一个全新的应用，这时它依赖的应用会更多。对于一些初创企业来说，如何快速获得一些最流行的 AI 应用的模板以及依赖的 MCP 服务，能够把应用快速运行起来，如何快速搭建模型服务，都会成为企业最迫切需要的一些能力。因此，在 Function AI 里，我们提供了几个核心能力，就是去解决一些初创企业在初期构建 AI 应用时，快速进行开发、构建和部署的问题。

在开发阶段，Function AI 提供了一系列热门应用模板，帮助用户将创新场景快速落地。比如说 ComfyUI ，这是现在非常流行的一个图片生成的开源项目。在 Function AI 里面，我们对 ComfyUI 进行了一系列增强，既保持了原生开发体验，还提供了专属工作空间、自定义流程模板插件等一系列能力。同时，借助函数计算底层的 Serverless 弹性算力，也可以让整个 ComfyUI 使用的成本能够做到更低。对于应用所依赖的模型服务，Function AI 也提供了非常便捷的部署方式。我们和魔搭社区进行了打通，用户在魔搭社区中选择模型之后，可以一键部署到 Function AI 中，并且借助 FC 底层的 GPU 弹性算力，可以使用户在初期 AI 应用开发时以弹性的方式使用 GPU 资源，部署更简单，成本更优。

前面提到的 MCP 也是一样。大家都知道，应用构建起来需要调用一些外部的服务。在 Function AI 中也提供了 MCP 市场，让用户既可以去开发自己的 MCP Server，也可以 Host 其他的 MCP Server，然后为整个 AI 应用构建丰富各种各样的能力。

可以看到，借助 Function AI 这样一个开发平台，及其提供的各种组件和底层的 FC 算力，用户可以快速落地一个 AI 应用。我们展开介绍其中最核心的几个能力。

FC 弹性算力 GPU 极速模式全新发布

第一个就是 AI 应用中最核心的资源 GPU。今天来讲，GPU 仍然是一种比较稀缺和昂贵的资源。很多企业在初创期上线一些新业务的时候，往往没有很大的流量。这时候去购置一台 GPU 服务器，利用率是不够高的，成本也会比较浪费。阿里云 FC 针对这类用户的痛点，全新推出了 GPU 极速模式。它可以用快照的方式实现秒级甚至毫秒级的整个推理服务启动，从而能够让用户只有在请求存在的时候，才为 GPU 付费。一旦请求到低峰期或消失，即可快速释放 GPU 资源，大大降低用户成本。

如图所示，以 Qwen-14B 举例，一个标准模式下的模型启动可能需要 20 多秒。在这样的一个响应之下，用户往往是需要常驻的。但是借助秒级快照能力，一个 Qwen-14B 模型的拉起速度可以降低到只有 1.3 秒，这时在使用模型时就能够实现弹性、降低成本、按需使用的要求。在一些极致场景下，我们还可以提供毫秒级的快照。在这个模式下，模型启动速度可以达到毫秒级别，可以满足所有延迟敏感类业务的诉求。

这个场景下，我们还结合了 Serverless 的免运维体验。因为对于很多企业来说，之前可能没有模型部署和管理的经验，甚至从来没有运维过 GPU 服务器。函数计算的 Serverless 体验，可以让业务人员直接快速将一个热门的 AI 应用拉起后使用，实现自己的业务目标，而不需要去关心环境使用、容量管理、资源是否有浪费等等一系列运维的事情，帮助用户真正实现 AI 应用的快速落地和上线。

FC MCP Server 开发与托管

MCP 市场也是一样。今天，函数计算不仅自己提供 MCP 市场，还是阿里云百炼平台和魔搭社区 MCP Server 的 Hoster。以百炼平台为例，一方面提供 MCP Server 的托管服务，同时也支持用户在函数计算中开发一个 MCP Server，并且把它一键发布到百炼中，供百炼的应用使用。

具体到函数计算来看，有几个重要的特征。首先，今天的 MCP Server 一个普遍的特点是，非常多的 MCP Server 采用的是本地运行的 STDIO 模式，函数计算提供了一键将 STDIO 模式改造成 SSE 模式的架构，更加符合企业 Client 端和 Server 端分开部署的诉求。同时，今天函数计算中的 MCP 市场，也为阿里云云产品提供官方 MCP 托管，目前已支持 OSS、RDS、PolarDB、Hologres 等一系列热门云产品的 MCP 服务，帮助用户一键获取需要的阿里云上云产品 MCP Server。借助 FC 积累已久的企业级特性，MCP 这个新事物在一开始就可以具备很多企业的能力，包括快速的弹性能力、伸缩能力、降低成本等等。

AI 网关全新发布

第二部分我想和大家分享的是 AI 网关。前面讲到，当一个 AI 应用构建完成之后，实际上是需要做很多外部调用的，最典型的就是模型调用。然而今天，模型调用在 SLA、响应时间等方面的表现参差不齐，所以很多用户会选择不同的模型供应商，这时对大模型调用的负载均衡、异常处理等，需要能够有一个集中式的位置去进行处理。为了解决这些问题，AI 网关就成为了企业级大规模使用模型调用的不二之选。

此外，如何快速把企业已有资产一键转化成 MCP 协议，也是今天在 AI 网关里非常受到用户欢迎的一个功能，它可以大大加速用户智能体应用和存量系统对接的速度。

再有，当一个企业内部的 MCP Server 比较多的时候，如何进行集中式的管理也成为了一个常见的诉求。在 AI 网关这种集中式的架构之下，它可以作为大模型和工具的统一出口，解决客户在这两个调用下的流量管理、安全、协议转换等一系列问题，并和原有的可观测能力、缓存能力、限流能力进行非常好的集成。同时，也可以在企业内部做进行统一的管理，如不同部门对模型调用是否需要不同的使用权限、不同的使用额度，是否需要对 Token 进行一些限流等等，这些企业级能力都可以在 AI 网关中提供，使得 AI 网关成为构建企业级 AI 应用的必备选择。

云原生可观测+AI

前面我们讲了 AI 应用的构建。那么构建完成之后，如何保证 AI 应用的稳定运行，就成为了可观测产品要解决的问题。

今年早些时候，阿里云全新推出的全栈智能可观测平台云监控 2.0 正式发布。过去，很多可观测系统在构建时都存在数据孤岛的问题，比如日志、指标、链路等不同可观测数据存储在不同的平台或系统。一旦企业需要对多种可观测数据进行联合分析去查找问题时，就会非常复杂。针对这样的问题，云监控 2.0 致力于实现一站式的数据接入、采集、存储和使用体系。

为了达成这样的目标，我们实现了多个统一。首先，是统一的接入。过去为了采集不同系统需要的数据，往往需要多种探针，这就为系统稳定性带来了风险。阿里云可观测集成了开源 LoongCollector，通过一个探针对云服务、应用、容器等进行可观测数据采集。相较于传统开源方案，LoongCollector 在资源开销、吞吐量方面都实现了大幅优化，帮助企业通过一个采集器，就可以完成从应用到网关，到服务端、中间件等一系列的全栈可观测数据采集。

第二，是统一的存储。当可观测三大核心数据，即日志、指标、链路，以及相应的 Event、Profiling 等数据通过统一的接入采集后，我们希望实现统一的存储，以便在后续分析中，企业可以非常便捷地构建统一的数据模型，实现数据联动与关系关联。而这也是阿里云可观测体系的重要基石。

基于统一存储，我们提供统一的界面与统一的分析能力，以 SPL、SQL 等标准方式对数据进行分析，并支持用 Grafana 等可视化工具去对数据进行展示。

在云监控 2.0 提供的能力之上，企业也可以更快捷的拥有面向 AI 应用稳定性可观测的能力。

上图右侧为大家展示了今天 AI 应用从可观测角度出发，有哪些组件是需要被观测与关注的。从最下层开始的计算服务器 IaaS 层，包括灵骏、网络、高速存储等；容器层包括 GPU 资源的使用情况、负载调度能力等；再往上到 PaaS 层，包括模型推理的效率、相应的服务组件、向量数据库、AI 网关是否运行正常、模型训练的效率如何等；再往上到 MaaS 层，需要关心 AI 应用以及模型服务的效率如何。

基于云监控 2.0，企业面向不同层级的 AI 基础设施、服务可以构建统一的可观测采集与存储体系，完整覆盖整个 AI 应用，实现全栈的智能可观测，进而实现端到端的故障定位与诊断。

举例来说，如果一个 AI 应用发布之后有用户反馈运行速度很慢，它的问题可能发生在任何一层。可能是 AI 应用本身有问题，可能是模型推理变慢了，可能是资源调度有问题，也可能是最底下的服务器出了问题。那如何以提出问题的调用方为切入点，迅速把整条链路串接起来，找到其中的问题点，就是云监控 2.0 的 AI 应用可观测为企业提供的能力。在这之上，由于目前模型的使用还是比较高的，所以很多用户会关注 Token 消耗量、GPU 使用率等信息，结合上述提到的 AI 网关限流能力，我们为企业提供一个完整的成本管理优化方案，帮助企业看清楚不同 AI 应用使用的 Token 量、GPU 量，并进行相应干预。

此外，针对行业关注的如何评估模型效果到底如何等问题。基于可观测的模型输入输出信息，我们提供了自动化评测能力，帮助企业判断模型当前输入输出的效果是否符合业务预期。

除了观测 AI 应用之外，众多企业也在积极探索 AI 能否帮助我们进行问题诊断。今天，借助云监控 2.0 的统一存储以及模型能力的提升，我们认为 AIOps 真正落地的时间点已经到来，打造全场景的 AIOps 能力。如下图所示，我们把 AI 能力进行了拆解。

从最左侧开始，可观测的统一存储能力使得我们有机会从各种各样的模型和算法中，去挖掘业务所需的数据。在云监控 2.0 中，我们沉淀了一系列可观测领域模型和算法。比如异常检测预测算法、日志的分析模型等等能力。在这些能力之上，我们构建了可观测智能体，这个智能体会嵌入到我们使用可观测产品的方方面面。比如说当用户想进行日志分析或调用链异常分析，或是告警治理，甚至是出现问题之后的根因诊断和应急手段，都可以植入这个智能体的能力。借助前面提到的算法与模型能力，以及数据的统一存储，我们可以帮助企业大大提升可观测场景下的问题诊断能力及问题发现的时效性。

同时，我们构建的整个 AIOps 体系具备非常强的开放性。因为在企业内部，除了可观测产品体系采集到的数据之外，企业还拥有自己的知识库，比如整个应用架构、运维体系、运维工具等。通过 RAG 知识库及 MCP 的方式，企业可以将这些内容和阿里云构建的 AIOps 体系进行打通，实现针对客户自有的知识库和自有工具的对接，真正实践 AI 驱动运维与业务增长。

通义灵码加速应用开发

第三部分是通义灵码加速应用开发。通义灵码是阿里云发布的基于通义大模型的智能编码工具，以 IDE 插件的形态帮助程序员实现智能的代码生成、研发智能问答、编程智能体等能力，从而提升个体开发效率，加速企业软件交付进程。

下图展示了通义灵码的整体结构，它的最下层依赖通义大模型的能力，同时与通义大模型的专项模型进行协同，如代码补全模型和研发问答模型。在上层 IDE 侧我们也构建了一系列能力，帮助用户借助 AI 能力快速开发。

五月，我们最新发布了通义灵码的 2.5 版本，新增一系列强大功能，包括智能体模式、支持 MCP 工具调用和通义千问 3 模型选择。今天，通义灵码已经具备了多种能力和场景的覆盖。比如在智能问答场景下，用户可以针对研发领域和自己的工程提出各种各样的问题，并快速得到响应。在 Edit（文件编辑）模式下，用户可以精准控制上下文和修改的范围，实现自然语言对话方式提升研发效能。

在智能体模式下，由于智能体具有更强的自主决策和工具使用能力，用户可以授权智能体自动获取更多信息，包括自动的上下文感知、自动的工具调用等，真正成为开发者的伙伴。开发者交给通义灵码的任务，经过几轮执行之后就可以自动完成，编程智能体也是目前我们认为在效率提升方面最佳的模式。

此外，通义灵码 2.5 几乎是在第一时间就支持了通义千问 3，各项评测结果显示，通义千问 3 在复杂任务处理、编程能力、任务准确度方面均有大幅提升。

通义灵码还新增了全自动的记忆感知能力，大家都知道，每个人在开发代码的过程中都有自己的开发习惯和工程特征，在开发者与通义灵码的对话过程中，会逐渐形成针对开发者的个人、工程、问题等相关的丰富记忆，并自动进行记忆的整理、更新，甚至是遗忘。在下一次智能代码推荐的时候，通义灵码会把这些记忆作为上下文给到模型，真正让用户感受到通义灵码是越用越懂自己的智能编码工具。

同时，新升级的通义灵码还集成了 MCP 广场，与最大的 MCP 中文社区魔搭进行打通，让开发者可以非常便捷地在 IDE 里一键将魔搭中的 MCP 服务部署到用户的本地端，实现和工具的集成。典型的场景包括 CI/CD 的打通，支持对接 Github、Gitlab、云效，以及可以和搜索打通从而获取最新的技术知识。MCP 广场的接入，全面拓宽 AI 编码助手能力边界，更加贴合开发者工作流程。

通义灵码 2.5 全新能力已同时在 Jetbrains 和 VS Code 两大主流 IDE 端进行同步发布，实现最广泛的开发者用户覆盖，个人版免费使用，欢迎各位程序员体验反馈。

我今天的分享就到这里，谢谢大家。