阿里云推出《AI 原生应用架构白皮书》

不同于传统软件开发通过编程与算法构建的确定性逻辑，AI 时代的应用构建以面对自然语言编程、上下文工程为核心特征，将复杂业务逻辑与决策过程下沉至模型推理环节，从而实现业务的智能化自适应。

然而，AI 应用开发过程中仍面临诸多挑战，例如开发阶段强依赖模型黑盒特性，导致结果可控性不足、幻觉问题频发，从原型验证（PoC）到生产部署往往需要数月调优，核心痛点集中在调试效率与业务适配；上线后则面临推理延迟、稳定性波动、问题排查困难、安全风险凸显、输出不可靠及成本过高等问题，折射出企业级 AI 应用在稳定性、性能、安全与成本控制上的系统性挑战。

针对此，阿里云联合阿里巴巴爱橙科技，共同发布《AI 原生应用架构白皮书》，围绕 AI 原生应用的 DevOps 全生命周期，从架构设计、技术选型、工程实践到运维优化，对概念和重难点进行系统的拆解，并尝试提供一些解题思路。

进入链接或点击阅读原文即可下载：developer.aliyun.com/ebook/8479

白皮书覆盖 AI 原生应用的 11 大关键要素，获得 15 位业界专家联名推荐，来自 40 多位一线工程师实践心的，全书合计超 20w 字，分为 11 章。

第 1 章 AI 原生应用及其架构

从大模型技术发展的回顾开始，正因为其技术上的突破，带来了应用上的繁荣，并对应用架构的演进历程进行了梳理，对AI 原生应用需要具备的核心能力给出了解释，以及定义了AI 原生应用架构成熟度，作为企业综合衡量 AI 原生应用在技术实现、业务融合与安全可信等方面所达到的水平的一个参考标准。

应用架构是指导如何系统性地构建应用。在 AI 原生应用架构下，其目标是在满足可扩展、可观测、安全合规的同时，最大化释放大模型的智能潜力。以下是典型的 AI 原生应用架构，涵盖了模型、应用开发框架、提示词、RAG、记忆、工具、网关、运行时、可观测、评估和安全等关键要素。

在此架构之上，构建的 AI 原生应用，是以大模型为认知基础，以 Agent 为编排和执行单元，以数据作为决策和个性化基础，通过工具感知和执行的智能应用。AI 原生应用的出现，标志着智能软件形态的根本性转变，其核心能力包括大模型推理决策、Agent 编排和执行、数据优化决策、工具调用与环境连接。

第 2 章 AI 原生应用的关键要素

本章介绍了构建一个 AI 原生应用所需要的 11 个关键要素，并在每一节描述了各个要素所扮演的角色和功能，给读者提供一个全貌的了解。

• 大模型：扮演着大脑的角色，负责核心的理解、推理与生成任务。大模型的引入，赋予了应用灵活的思考与决策能力，使其真正具备智能。
• AI 开发框架：天然就很难收敛，不同的框架都有自己的设计模式哲学，只要定位清晰，都能获得一部分开发者群体的青睐，一家独大的情况很难出现。
• 提示词：在 AI 领域，有一句经典的话 “Garbage In, Garbage Out”（垃圾进，垃圾出）。这句话在提示词工程中也同样适用，Prompt 的质量直接决定了 AI 生成内容的质量、相关性和准确性。
• RAG：其价值正在从解决幻觉这一技术问题，向赋能业务的更高层面演进。例如，媒体娱乐领域，多模态 RAG 正帮助从海量音频视频内容中检索出特定的片段，从而服务于音视频内容分发以及新兴的 AI 视频创作场景。
• 记忆：记忆实现了模型跨越会话的连贯性、高度自适应的个性化，以及基于历史信息的深度推理。但是长期记忆存储的通常是信息的摘要或切片，而非原始对话，因此必然存在一定程度的信息保真度损失，从而干扰模型的判断。同时，记忆的引入也带来了更高的系统复杂度和额外的处理延迟。
• 工具：主流模型供应商都已经将工具调用能力作为其大模型的原生功能进行内置，并且在模型预训练阶段对工具调用进行了特定增强。但也面临着诸如工具调用时延、工具提取参数准确性、安全鉴权等问题。
• 网关：AI 应用正在快速演进，企业需要在安全、合规、成本、效率四重约束下交付稳定业务。AI 网关解决了传统 API 网关无法处理的模型切换、Token 经济、语义缓存和内容风控等 AI 原生的需求，为整个系统带来秩序、可靠与安全。
• 运行时：AI 应用的业务流程往往由大模型根据用户实时意图动态生成。这意味着运行时处理的是充满不确定性的执行计划。因此提出了新的要求，即不仅要能理解和执行模型生成的动态任务，还要为整个过程提供稳定、高效和安全的保障。
• 可观测：传统监控主要关注基础设施的性能指标与日志，难以应对 AI 应用特有的行为不可预测、输出质量波动和成本结构复杂等挑战。AI 可观测需要具备端到端全链路追踪、全栈可观测和自动化评估的功能。
• 评估：AI 应用的行为本质上是非确定性的概率输出，即使输入相同，模型的输出也可能因上下文、训练数据分布或随机性而千差万别。有必要引入全新的评估范式 LLM-as-a-Judge，并构建一个高效的自动化评估系统，以推动 AI 应用的持续优化与可靠性提升。
• 安全：AI 原生应用的开放性、自主性和多模态交互特性显著扩大了系统的安全风险敞口，给应用安全防护体系带来了新的挑战。应从应用安全、模型安全、数据安全、身份安全、系统和网络安全 5 方面来构建全栈的安全保护框架。

第 3 章 AI 应用开发框架

本章从开发一个简单的 Agent 开始，介绍了标准的智能体开发流程，以及业内主流的智能体开发范式，并围绕工作流模式、对话模式进行展开。随后，介绍了业内讨论较多的多智能体、A2A 协议，以及一些实践，我们认为多智能体是智能体发展的必然形态，这是由企业组织结构、业务需求、成本考量等多方面因素共同决定的。

以 Spring AI Alibaba 的多智能体类型为例，它和 Agent 定义与类继承关系可以分为以下3类：

• ReactAgent：框架中对于 Agent 的基本定义，多智能体通常是指如何编排多个 ReactAgent 互相协作解决复杂问题。

• FlowAgent：FlowAgent 中包含有多个 ReactAgent，它们按照特定的流程相互协作。

  • SequentialAgent，串行依次执行的多个智能体的流程
  • ParallelAgent，可并行执行的多个智能体的流程
  • LoopAgent，循环执行多个智能体的流程，直到满足某个特定条件退出
  • LlmRoutingAgent，由大模型决策的执行哪个智能体

• A2RemoteAgent：由于 A2ARemoteAgent 属于分布式 Agent 范畴，本章节会有独立段落展开。

以下是 LlmRoutingAgent 模式的基本架构图和工作原理，它的特点是通过模型决策下一个子智能体走向。

如上图所示，RoutingAgent 内置的 Prompt 定义如下，它会根据当前 RoutingAgent 的职责、所有可用子 Agent 的能力、当前用户的请求，来使用 LLM 智能决策下一个流程节点。

第 4 章 上下文工程

上下文工程是提升输出效果的重要手段，白皮书介绍了提示词、RAG、Memory 的定义、功能和业内主流技术方案，以及未来的演进方向，同时，提供了我们的一线实践，例如提示词调优、RAG 检索构建和检索流程优化、多级记忆系统构建等。

上下文工程通过协同工作的一系列核心组件，为 LLM 构建其动态认知环境。

• 外部知识库的动态供给：为解决 LLM 知识陈旧和领域知识缺乏的问题，上下文工程的核心是为其接入外部知识库。通过检索增强生成 RAG 技术，系统能够在接收到用户请求时，首先从企业的私有数据库、实时信息流或互联网等外部来源检索相关信息，再将这些检索到的信息与提示词一同组合成最终的上下文，引导 LLM 基于准确、实时的知识进行回答。
• 长期与短期记忆系统：为了实现连贯且个性化的交互，上下文工程引入了记忆系统。短期记忆负责管理当前对话的上下文，确保多轮对话的流畅性。长期记忆则负责存储跨对话周期的关键信息，如用户偏好、历史决策、重要事实等，使 AI 能够记住用户，提供真正个性化的服务。
• 运行时的上下文管理：面对有限且昂贵的上下文窗口，特别是在长对话或复杂任务中，如何高效管理上下文至关重要。这包括一系列运行时策略，如上下文压缩与摘要，用于在保留关键信息的同时减少 Token 消耗；以及上下文重排（Re-ranking），用于解决中间遗忘问题，将最重要的信息放置在模型最关注的位置，从而提升长上下文处理的可靠性。

通过对这些关键组件的系统性设计与优化，上下文工程为构建高效、可靠且具备深度认知能力的 AI 原生应用提供了坚实的基础。

第 5 章 AI 工具

工具是大模型向物理世界进行延伸的载体，也是上下文工程的一部分。我们单独成章，因为已经具备了相对较成熟的工程实践。这一章介绍了 Function Calling 和 MCP 这两个主流的技术实现方式，并重点围绕 MCP 介绍了从零构建和基于存量资源改造（即 HTTP 转 MCP）两种实践路径。

Function Calling 出现的更早，但因其规格碎片化、工程治理缺位、厂商锁定与迁移成本等问题，导致生态效应不强。而 MCP 因其使用统一协议取代碎片化集成，把大模型获取外部数据与工具的方式从 N×N 适配转为“一次对接、处处可用”，显著简化并提升可靠性，而广受开发者们欢迎。

但是，MCP 也遇到了新的问题，导致其热度有所降低。例如当 MCP 服务或工具的数量过多时，模型可能会出现选择困难症，因为大量的上下文输入让模型难以区分和回忆每个工具的能力，也就无法有效的选择与目标问题关联度最高的工具。而且，由于模型在每次对话中都需要接收全量的工具描述信息，对话内容很容易超出模型支持的上下文窗口的长度限制。更关键的是，过长的提示词信息也会加剧 Token 的消耗速度，尤其是在多轮对话中，工具列表被重复传递，造成 Token 资源的浪费，拉高调用成本。

我们在白皮书中提供了一些具备可行性的应对方案，例如：

• 基于 Nacos MCP Registry，用户将已有的 MCP 服务统一注册到 Nacos 上，通过 Nacos MCP Router 根据用户任务的语义描述和关键词，从 MCP Registry 中筛选出最匹配的 MCP 服务，然后将这些服务提供给模型进行决策。
• 模型请求在经过 AI 网关调用 LLM 时，携带含有大量工具的 tool_calls 数组，基于阿里云 AI 网关的工具精选能力后，将 tool_calls 的数量压缩至目标数量，提升模型响应速度与工具选择精确性。
• 阿里云的 AI 网关通过创建一个"All-in-One" 的 MCP Server，将用户在网关实例中注册的所有 MCP 工具进行统一聚合和管理，并提供智能的语义化检索能力，实现统一、高效的工具发现和调用体验。

第 6 章 AI 网关

AI 网关是大模型最重要的集成能力之一。本章完整地介绍了网关的演进历程，并解释了为什么 AI 原生应用架构中，网关的地位如此重要。随后，介绍了基于 AI 网关来构建一个 AI 应用的实践，以及探讨了 API 和 Agent 货币化所需要的基础设施建设。

无论是 Single 模式还是 Sub Agent、甚至 Multi Agent，AI 网关作为入口中间件，都发挥着更关键的作用：

• 多模型袋里：AI 网关是流量的统一入口，用来接收用户端请求，并负载均衡到后端模型，还能实现同一个接口对接多种模型，这个袋里层不仅解决了调用不同模型 API 的复杂性，还通过动态路由实现了成本与性能的最佳平衡，更是提升了模型服务的可用性。
• 多模型回退/容灾：依赖单一模型存在单点故障风险，API 的不稳定或性能下降都可能导致服务中断。AI 网关能同时对接多个模型，当单个模型出现调用失败、超时或返回质量不佳的结果时，可以自动 Fallover 到备选模型多模型，以确保服务的连续性和高可用性。
• 消费者认证：当一个袋里服务需要为多个用户或应用提供支持时，身份认证变得至关重要。通过 AI 网关清晰地识别每一个请求的来源，以便进行后续的计费、权限管理和个性化服务，确保按权限分类提供服务。
• 内容安全防护：不同的模型拥有各自的安全策略，标准不一。在一个多模型系统中，必须建立一个统一、前置的内容安全防护层。AI 网关能通过内容安全插件，在请求送达模型之前和模型返回结果之后，对内容进行审查，过滤有害信息，确保整个应用输出的内容始终符合安全规范和合规性。
• Token 限流：大模型调用按 Token 计费，且单位成本远高于 CPU 计费，因此有效控制成本是高优先级需求。AI 网关提供的 Token 限流机制可以从控制单个用户的调用频率和总量，以及对服务总流量进行调控两个维度进行管理，防止滥用导致费用激增，并保障服务的稳定性。
• 语义缓存：AI 网关提供了扩展点，可接入 Redis 实现内容缓存。一能提高效率，如果相同的输入反复出现，缓存可以避免重复运行模型，从而加快响应速度，特别是在处理常见问题时。二是降低成本，大模型 API 计费因是否命中缓存，而有所不同，缓存机制可以减少模型调用次数，以节省计算资源。三是保持一致性，缓存可以确保相同输入产生相同输出，有助于测试和合规性场景。
• 可观测性：在一个由多个开发平台、多个模型、多个组件构成的复杂系统中，统一的可观测性是运维和优化的基石。AI 网关能提供包括对每一次调用的详细日志记录（请求内容、选择的模型、响应结果、耗时）、关键性能指标（如延迟、Token 消耗、错误率）的监控，以及端到端的链路追踪。通过可观测性，企业可以快速定位问题、分析成本构成、洞察用户行为，并为模型的选择策略提供数据驱动的优化依据。
• MCP 袋里：面向 MCP Server，提供 MCP Server 袋里、安全认证，以及统一观测、限流等治理能力，同时支持将 REST API 直接转化成 MCP Server，提供协议卸载能力，将 SSE 转换为 Streamable HTTP，避免无状态应用也要使用 SSE。
• 工具的动态组装和智能路由：当请求携带大量工具通过 AI 网关时，通过 Query 改写及Rerank 模型将大量工具进行压缩，再转发给 LLM，可大幅降低调用耗时，并在一定程度上增加工具选取的准确性。
• 工具的智能路由：将用户注册在 AI 网关的大量 MCP Server、工具进行集合，以 MCP 或其他形态提供语义搜索能力，客户端只需要集成这个工具即可基于用户 Query，动态搜索出最符合需求的 N 个工具。

第 7 章 AI 应用运行时

Agent 运行时具有丰富的资源供给形态，不同的供给形态各有优势，如何选型取决于具体的业务场景。本章详细介绍了 Serverless 运行时的演进历程，围绕智能体、工具、沙箱三类运行时方案，以及运行时降本的实践。

阿里云上已经落地了诸多企业级的 AI 业务场景，包括AI 开放平台 MCP Server 托管、交互式智能内容创作助手、个性化 AI 客服、通用 Agent 平台+病毒式传播的 AIGC 创意应用。从这些真实的用例中，我们可以清晰地勾勒出 AI 应用的共同画像：它们是会话式的、工具增强的、事件驱动的、精益成本的。这最终汇聚成了对理想运行时的 7 大核心诉求：

• 会话管理：支持会话亲和调度，能够低成本、高效率地管理长程会话和状态。
• 流程编排：内建或无缝集成复杂任务流的编排能力。
• 安全沙箱：默认提供轻量、快速、强隔离的安全执行环境，尤其是存储隔离。
• 极致弹性：能对 CPU 和 GPU 等异构资源实现按需伸缩，尤其对于 CPU 有从零到万的瞬时弹性。
• 应用管理：能够管理十万至百万级的应用，应用创建没有额外费用。
• 一直在线：一种逻辑上的长时运行，上下文持久化，有请求时快速恢复执行，无请求时自动缩 0。
• 成本效益：能够完美匹配 AI 应用稀疏、不确定、脉冲式的调用模式，实现真正的按价值付费。

白皮书将详细描述Serverless 运行时应对以上诉求时的一些解题思路。

第 8 章 AI 观测

大模型驱动的AI 应用，更加复杂。AI 应用可观测是一系列能够让工程师全面洞察基于大型语言模型构建的应用的实践与工具。本章全面介绍了 AI 应用可观测的挑战和应对方式，并围绕 Agent 可观测、AI 网关可观测、推理引擎可观测，以及架构端到端全链路追踪的技术实现方式和实践。

AI 应用面临着一系列传统软件所没有的独特挑战，总结来讲有 3 大类：

• 性能与可靠性问题：大模型是资源密集型的，延迟峰值和瓶颈时有发生。可观测将所有组件的数据关联起来，使工程师能够精确定位延迟的根源，是模型本身、外部 API 调用还是数据库查询。它还能追踪多步骤流程中的每一步，简化了复杂系统中的调试过程。
• 成本问题：许多大模型服务按 Token 使用量收费，若无控制，成本可能意外飙升。可观测工具追踪每个请求的 Token 数、每日总用量等指标，当使用量出现异常高峰时发出警报，帮助团队在收到天价账单前优化提示或设置限制。
• 质量问题：大模型的可能输出从训练数据中继承偏见或有害内容，也很有可能产生幻觉，导致输出的内容完全不符合预期，可观测通过提供评估等工具，针对采集的 AI 应用执行过程中各个阶段的输入输出，检测是否含有不当、不准确和危险的内容，通过自动分析和评分帮助工程师及时采取行动。

一个高效的 AI 可观测解决方案应具备端到端全链路追踪、全栈可观测和自动化评估功能。其中，端到端全链路追踪、全栈可观测将在第 8 章中展开，自动化评估将在第 9 章系统化的提供可行性方案。

第 9 章 AI 评估

相比由代码决定软件运行逻辑的经典应用，大模型应用具有黑盒和不确定性的特征。因此 AI 评估成为构建 AI 原生应用中的必备要素之一。本章介绍了评估体系中的基础二分法，探讨从静态到动态评估的演进，并给出了自动化评估的一些实践。

AI 应用，其行为本质上是非确定性和概率性的，这意味着对于相同的输入，它们可能会产生不同的输出。尤其在医疗、金融等高风险领域，缺乏本地化评估可能导致模型失效或加剧不平等，带来严重后果。理解 AI 评估可以从两个基本的维度开始：评估的对象（内在与外在），评估的执行者（自动化与人工）。

• 内在评估：此方法侧重于孤立地评估模型输出的固有质量，而不考虑其在特定任务中的应用效果。评估的维度通常包括流畅性（Fluency）、连贯性（Coherence）、语法正确性以及事实准确性等。
• 外在评估：与内在评估相反，外在评估通过衡量模型在特定下游任务或应用中的表现来评估其质量。例如，通过评估一个由AI驱动的邮件助手是否能有效提升用户的办公效率，来判断该 AI 模型的价值。
• 自动化评估：此方法利用计算指标（如用于机器翻译的 BLEU 分数或用于文本摘要的 ROUGE 分数）或利用其他 AI 模型（如 LLM-as-a-Judge）来对模型输出进行打分。
• 人工评估：此方法依赖人类评估员的判断来评估AI系统的输出质量，特别是在衡量帮助性、创造力、用户满意度等主观维度时。

在实践中，最佳的评估策略通常是自动化和人工评估的混合模式，利用自动化的效率进行大规模初步筛选，并结合人工的深度洞察力对关键或模糊的案例进行精细评估。

第 10 章 AI 安全

AI 与生俱来的非预期行为以及输出的不可预测性风险，加剧了内部治理和合规的挑战。安全成为个人和企业采用 AI 的重要顾虑。本章介绍了常见的安全风险，包括：

• 系统风险：AI 模型软件的供应链风险、暴露面风险以及算力劫持风险。
• 网络风险：面向公网的入侵攻击，以及内网的隔离风险。
• 身份风险：对非人类身份（NHI）的管控，越权访问，身份冒充等。
• 数据风险：Agent 模型训练时的数据投毒，以及输入/输出阶段的敏感信息泄漏等。
• 模型风险：Agent 模型输入输出内容的恶意诱导、提示词攻击等风险。
• 应用风险：当 AI 在线上提供服务时，会面面临 Web 入侵、DDoS 攻击导致服务不可用等风险。

白皮书将从应用、模型、数据、身份、系统和网络视角全方位的阐述防护思路、防护框架和解决方案。

第 11 章 通向 ASI 之路

ASI 的到来不是一蹴而就的，而是技术、场景、治理、社会持续协同进化的结果。本章节从技术架构、应用场景、治理体系、社会形态 4 个视角总结了 AI 的发展历程，并对未来的发展趋势进行展望。以技术架构为例，其发展趋势分为：

• 模型能力进化：从大语言模型到世界模型，AI 模型将突破静态训练的局限，通过强化学习和动态反馈机制实现持续进化，逐步构建对物理世界的完整感知和理解能力，能够模拟复杂环境。
• 数据飞轮升级：从静态积累到动态进化，包括上下文工程的突破和合成数据的广泛应用。
• AI 原生应用架构：从通用 Agent 发展到多 Agent 协同，复杂任务由大模型主导，简单重复任务由小模型执行，AI 中台沉淀基础模型能力和 Agent 服务。

写在最后

我们曾经参与编写过《云原生应用架构白皮书2022》、《云原生应用架构白皮书2023》、《Nacos 架构与原理》、《微服务治理技术白皮书》等电子书，也参与编写过《面向 LLM 应用的可观测性能力要求》、《人工智能云 AI 网关能力要求》等标准，具有一定的编写经验。但是在发起这本《AI 原生应用架构白皮书》之初，便深刻感受到 AI 时代，产品创新的速度之快、架构的复杂度之高、学科的交叉度之广，都远超以往，技术成熟度也仍处于行业发展初期。单个团队已经很难系统、全面的去解构 AI 原生应用架构。因此，我们邀请了阿里云内的上下游兄弟团队、阿里巴巴爱橙科技等联合编写该白皮书，在此表示诚挚的谢意。编写过程中，我们借助 AI 提升了内容的结构化程度和完整度，并逐字进行了人工校对。

我们期望以抛砖引玉的姿态，为 AI 原生应用的标准化、体系化发展提供参考框架，并计划不定期对白皮书进行更新，持续呈现 AI 原生应用架构的前沿思考。我们非常欢迎业内各方一道，无论您是学者、开发者、或是用户等，参与进来共同更新白皮书，共同定义行业共识、破解技术瓶颈，加速推动 AI 从概念走向产业、从潜力转化为价值，让 AI 真正成为驱动全球产业升级与社会进步的核心力量。

若白皮书能对个人学习和企业落地 AI 原生应用架构起到一点点的促进作用，将是我们莫大的荣幸。

谨以此书，献给参与 AI 建设的所有同行者们。

点击此处，下载《AI 原生应用架构白皮书》。