阿里云发布《AI 原生应用架构白皮书》

传统软件与AI应用在构建逻辑上，从根儿上就不太一样了。前者靠的是程序员精确无误的代码逻辑，一切尽在掌控；而到了AI时代，应用构建更多是跟自然语言打交道，核心变成了上下文工程。开发者的关注点，从“如何写死逻辑”转变为“如何引导模型推理”，把复杂的业务决策权下沉到模型内部，让应用自己去“思考”和“适应”。

听起来很美好，但理想与现实之间总是隔着几条“天堑”。开发阶段，模型像个黑盒子，结果可控性差，幻觉问题就像幽灵一样挥之不去。从想法验证（PoC）到真正上线生产，往往需要团队耗费数月时间去反复调优，核心卡点就在于“调试效率”和“业务适配度”这两件事上。好不容易上线了，新的问题又接踵而至：推理延迟、服务稳定性像过山车、问题排查如同大海捞针、安全风险暗流涌动、输出结果时好时坏，还有那让人心惊肉跳的成本账单。这一系列问题，本质上都是企业级AI应用在稳定性、性能、安全与成本控制这四重压力下，交出的“血泪账本”。

阿里云与阿里巴巴爱橙科技近期联合发布的《AI原生应用架构白皮书》，就是试图在这片混沌中画出一张清晰的地图。这份白皮书没有停留在概念层面，而是围绕AI原生应用的完整生命周期，从架构设计、技术选型、工程实践到运维优化，对其中各种难点和痛点进行了系统性的拆解，并给出了许多经过一线验证的解题思路。

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

开篇从大模型的技术演进说起。正因技术的突破，才催生了应用层的百花齐放。白皮书梳理了应用架构的演进路径，清晰地定义了AI原生应用应具备的核心能力，并提出了一个“AI原生应用架构成熟度”模型，作为企业衡量自身在技术实现、业务融合与安全可信方面所处阶段的一个标尺。

应用架构是指导系统化构建工程的蓝图。在AI原生架构下，目标不只是可扩展、可观测和安全合规，更要最大化地激发大模型的智能潜力。书中给出了一张典型的AI原生应用架构图，涵盖了模型、应用开发框架、提示词、RAG、记忆、工具、网关、运行时、可观测、评估和安全等关键要素。

基于这套架构构建的应用，以“大模型”为认知核心，以“Agent”为编排执行单元，以“数据”作为决策和个性化的基础，通过工具调用与环境连接，最终形成真正的智能体。这标志着智能软件形态的根本性转变——从“执行指令”到“理解意图并自主决策”。

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

这一章详细拆解了构建一个AI原生应用所需的11个关键要素，每个要素都像乐高积木的某个关键模块，下面来逐一看看它们各自扮演什么角色：

• 大模型：毋庸置疑的系统大脑，负责理解、推理与生成。正是它的引入，赋予了应用思考与决策的能力，让“智能”二字名副其实。
• AI开发框架：这个领域天然就难以统一，各家都有自己的哲学和设计模式。只要定位清晰，总能找到自己的拥趸，一家独大的格局很难形成。
• 提示词：AI领域有句经典老话，“Garbage In, Garbage Out”。在提示词工程里这是铁律，Prompt的质量直接决定了最终生成内容的质量、相关性和准确性。
• RAG：它的价值正在从最初的“解决模型幻觉”这一技术痛点，向赋能实际业务场景的更高层面演进。比如在媒体娱乐领域，多模态RAG已经开始帮助从海量音视频内容中精准检索出特定片段，服务于内容分发和AI视频创作。
• 记忆：这是实现跨会话连贯性、深度个性化的关键。但长期记忆通常存储的是信息的摘要或切片，而非原始对话，这就不可避免地会带来信息保真度的损失，从而干扰模型判断。同时，引入记忆层也会增加系统复杂度和处理延迟，这是需要权衡的代价。
• 工具：主流模型厂商都已将工具调用作为原生功能内置，甚至在预训练阶段就做了特定增强。但目前依然面临调用时延、参数提取准确性、安全鉴权等一系列工程难题。
• 网关：AI应用迭代飞快，企业需要在安全、成本、效率之间走钢丝。传统API网关搞不定的模型切换、Token经济、语义缓存和内容风控等AI原生需求，AI网关都能搞定，为整个系统带来了秩序、可靠和安全。
• 运行时：AI应用的业务流程常由模型根据用户实时意图动态生成，这意味着运行时面对的是充满不确定性的执行计划。这要求运行时不仅要能理解和执行模型生成的动态任务，还要为整个过程提供稳定、高效和安全的保障。
• 可观测：传统监控主要盯着服务器的CPU和内存，对付AI应用那种行为不可预测、输出质量波动和成本结构复杂的情况，基本束手无策。真正的AI可观测需要端到端全链路追踪、全栈可见性和自动化评估功能。
• 评估：AI应用的行为本质上是非确定性的概率输出。同样的输入，结果可能大相径庭。必须引入“LLM-as-a-Judge”这种新评估范式，并构建高效的自动化评估系统，才能推动应用的持续优化和可靠性提升。
• 安全：AI原生应用的开放性、自主性和多模态特性，无疑放大了系统的攻击面。必须从应用、模型、数据、身份、系统和网络五个维度，构筑一个全栈的安全防护框架。

第3章 AI应用开发框架

本章从一个简单的Agent开发入手，介绍了标准开发流程，以及业内主流的开发范式，涵盖了工作流模式和对话模式。随后，重点讨论了多智能体、A2A协议等业界热点。多智能体是智能体发展的必然形态，这背后是企业组织结构、业务复杂度和成本考量共同作用的结果。

以Spring AI Alibaba中的多智能体类型为例，它大致分为三类：基本ReactAgent、流程编排式的FlowAgent（包含串行、并行、循环和LLM路由等模式），以及用于分布式场景的A2RemoteAgent。

书中以LlmRoutingAgent模式为例，展示了其工作原理：路由Agent内置的Prompt让它根据自身职责、所有子Agent的能力以及用户请求，用LLM来智能决策下一步该调用哪个子智能体。

第4章 上下文工程

上下文工程是提升模型输出质量的“魔法棒”。本章详细介绍了提示词、RAG、Memory的定义、功能、业内主流方案和演进方向，并分享了一线实践经验，如提示词调优、RAG检索构建与流程优化、多级记忆系统构建等。

上下文工程本质上是通过协同工作的核心组件，为LLM构建一个动态的认知环境：

• 外部知识库的动态供给：为了解决模型知识陈旧和领域知识缺乏的问题，通过RAG技术，系统能在接到请求时，先从企业私库、实时信息流等外部源检索相关信息，然后将这些信息与提示词一同打包给模型，引导其基于准确、实时的知识作答。
• 长期与短期记忆系统：为了实现连贯且个性化的交互，记忆系统被引入。短期记忆管理当前对话，保证流畅；长期记忆则存储跨会话周期的关键信息，让AI记住你是谁、你喜欢什么。
• 运行时的上下文管理：上下文窗口有限又昂贵，尤其是在长对话或复杂任务中，如何高效管理至关重要。这包括上下文压缩与摘要（减少Token消耗），以及上下文重排（解决“中间遗忘”问题，把关键信息放在模型最关注的位置）。

通过系统性地设计与优化这些组件，上下文工程为构建高效、可靠的AI原生应用打下了坚实基础。

第5章 AI工具

工具是大模型向物理世界延伸的“手脚”，也是上下文工程的一部分。之所以单独成章，是因为它已经积累了相对成熟的工程实践。本章重点介绍了Function Calling和MCP这两个主流实现方式，并给出了从零构建和基于存量资源改造（HTTP转MCP）两种实践路径。

Function Calling问世更早，但受限于规格碎片化、工程治理缺位和厂商锁定等问题，生态效应并不强。而MCP的出现，用统一协议取代了碎片化集成，将模型获取外部数据与工具的方式从N×N适配变成了“一次对接、处处可用”，显著提升了可靠性和开发效率，深受开发者欢迎。

不过，MCP也遇到了新的麻烦。当MCP服务或工具数量过多时，模型可能会出现“选择困难症”。大量的上下文输入让模型难以区分和回忆每个工具的能力，也就无法有效选择与目标问题最相关的工具。同时，每次对话都要传输全量工具描述信息，很容易超出上下文窗口长度限制。更关键的是，过长的提示词会加剧Token消耗，导致成本飙升。

白皮书中提供了一些极具可行性的应对方案：通过Nacos MCP Registry对工具进行统一注册和路由，基于语义自动匹配；或者通过AI网关的“工具精选”能力，在请求到达模型前压缩工具数量；还可以创建一个“All-in-One”的MCP Server，实现统一聚合和智能语义检索。

第6章 AI网关

AI网关是目前大模型集成中最重要的基础设施之一。本章完整介绍了网关的演进历程，解释了为什么它在AI原生应用架构中如此重要，并给出了具体实践，甚至探讨了API和Agent货币化所需的基础设施。

无论是单体Agent、子Agent还是多智能体协同，AI网关作为入口中间件，都发挥着关键作用：

• 多模型袋里：作为流量的统一入口，负载均衡到后端不同模型，实现同接口对接多种模型，在成本与性能之间寻求最佳平衡。
• 多模型回退/容灾：当单一模型出问题时，能自动切换到备用模型，保障服务高可用。
• 消费者认证：清晰识别每个请求来源，为计费、权限管理提供基础。
• 内容安全防护：在请求发送前和模型返回后，对内容进行审查，统一过滤有害信息。
• Token限流：从用户调用频率和总流量两个维度进行管控，防止因滥用导致成本失控。
• 语义缓存：通过Redis接入内容缓存，相同输入反复出现时，能避免重复调用模型，既加快响应速度，又降低成本。
• 可观测性：记录每次调用的细节、监控关键性能指标，提供端到端链路追踪，是优化模型选择策略的数据基础。
• MCP袋里：为MCP Server提供袋里、安全认证和统一治理，支持将REST API转为MCP Server。
• 工具的动态组装和智能路由：通过Query改写和Rerank模型压缩大量工具，降低调用耗时，提升工具选择准确性。

第7章 AI应用运行时

Agent运行时的资源供给形态非常丰富，各有优势，如何选型取决于具体业务场景。本章详细介绍了Serverless运行时的演进，并围绕智能体、工具、沙箱三类运行时方案，分享了降本经验。

从阿里云上已经落地的大量企业级AI业务中，我们可以清晰地看到AI应用的共同画像：会话式、工具增强、事件驱动、精益成本。这最终汇聚成了对理想运行时的7大核心诉求：会话亲和调度、流程编排、安全沙箱、极致弹性、应用大规模管理、逻辑长时在线、以及对AI应用脉冲式调用模式的完美成本匹配。白皮书将详细描述Serverless运行时应对这些诉求的思路。

第8章 AI观测

大模型驱动的AI应用，复杂度远超传统软件。本章全面介绍了AI应用可观测面临的独特挑战和应对策略，并围绕Agent、AI网关、推理引擎的可观测性，以及端到端全链路追踪的实现方式做了详细阐述。

AI应用面临的挑战有三类：

• 性能与可靠性：大模型是资源消耗大户，延迟峰值和瓶颈时有发生。可观测将所有组件数据关联，让工程师能精确定位延迟根源。
• 成本问题：大模型按Token计费，若无控制，成本可能意外飙升。可观测工具追踪Token用量等指标，及时预警异常高峰。
• 质量问题：大模型可能会输出偏见、有害内容或产生幻觉。可观测通过评估工具，对输入输出进行分析和自动评分，帮助工程师及时干预。

高效的AI可观测方案，应同时具备端到端全链路追踪、全栈可观测和自动化评估三大功能。

第9章 AI评估

相比代码逻辑确定的应用，大模型应用充满黑盒和不确定性，因此评估成为构建AI原生应用的必备要素。本章介绍了评估体系的基础二分法，探讨了从静态到动态评估的演进，并给出了自动化评估的实践。

AI应用的行为本质上是非确定性的，尤其在高风险领域，缺乏本地化评估可能导致严重后果。理解AI评估可以从两个维度开始：评估的对象（内在与外在）和评估的执行者（自动化与人工）。

• 内在评估：孤立评估模型输出的固有质量，如流畅性、连贯性、语法正确性和事实准确性。
• 外在评估：通过衡量模型在特定任务中的表现来评估质量，例如评估一个AI邮件助手是否真的提升了办公效率。
• 自动化评估：利用计算指标或其他AI模型（如LLM-as-a-Judge）对输出打分。
• 人工评估：依赖人类评估员的判断，尤其适用于衡量帮助性、创造力等主观维度。

在实践中，最佳策略通常是自动化与人工评估的混合模式，用效率进行大规模筛选，用人类洞察力处理细微和模糊问题。

第10章 AI安全

AI与生俱来的非预期行为和输出不可预测性，加剧了内部治理和合规的难度。安全已经成为个人和企业采用AI的首要顾虑。本章介绍了常见的安全风险：系统风险、网络风险、身份风险、数据风险、模型风险和应用风险。白皮书将从应用、模型、数据、身份、系统和网络六个视角，全方位阐述防护思路和框架。

第11章 通向ASI之路

ASI的到来并非一蹴而就，是技术、场景、治理、社会持续协同进化的结果。本章从技术架构、应用场景、治理体系、社会形态四个视角总结了AI的发展历程并展望未来。以技术架构为例，其演进趋势主要围绕：模型能力从大语言模型迈向世界模型；数据飞轮从静态积累转向动态进化；以及AI原生应用架构从通用Agent发展到多Agent协同，由大模型主导复杂任务，小模型执行简单任务。

写在最后

编写团队之前参与过不少技术白皮书的撰写工作，比如《云原生应用架构白皮书》系列、《Nacos架构与原理》等，也参与过一些行业标准的制定。但在发起这本《AI原生应用架构白皮书》时，大家深刻感受到AI时代产品创新之快、架构复杂度之高、学科交叉之广，已经完全超出了过去任何一个单点技术的演进速度。技术成熟度本身也还处于行业发展初期，单个团队很难系统、全面地解构整个AI原生应用架构。因此，团队邀请了阿里云内外的上下游兄弟团队和合作伙伴联合编写。编写过程中，借助AI提升了内容的结构化程度，但每个字都经过了人工逐句校对。

团队期望以抛砖引玉的姿态，为AI原生应用的标准化、体系化提供一个可参考的框架，并计划根据行业发展不断更新这本白皮书。非常欢迎学界、产业界的朋友们一起参与，共同定义行业共识，破解技术瓶颈，加速推动AI从概念走向产业、从潜力转化为价值。

如果这本白皮书能对个人学习或企业落地AI原生应用起到一点点促进作用，那便是团队莫大的荣幸。