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

本章系统梳理了 AI 原生应用的 11 个关键要素，涵盖模型、框架、提示词、RAG、记忆、工具、数据、评估、安全与合规、监控与运维、用户体验设计等方面，帮助读者全面理解 AI 应用的核心组成与工程实践重点。

模型

本节介绍 AI 原生应用中的模型要素。大模型作为“智能大脑”，赋予应用理解、推理与生成能力，区别于传统规则驱动的应用。

模型分类

大语言模型（简称大模型）是一类具有大量参数（通常在十亿以上），在极为广泛的数据上进行训练，并适用于多种任务和应用的预训练深度学习模型。

大模型的类型和提供厂商都非常多，根据用途和能力的不同，大致可以分为通用大模型和垂直领域模型。

通用大模型是我们最熟悉的类型，如 GPT、Claude、Qwen、DeepSeek、Gemini 等系列。它们拥有非常大的参数规模，具有广博的知识和强大的通用推理能力，它们可以是纯文本的，也可以是多模态的，能够同时理解图像、声音和文字。一般来说，模型越大，处理复杂、开放性任务的能力就越强，但是相应的成本和延迟都相对较高。

垂直或领域模型不具备通用知识，其核心理念是放弃追求通用性，只专注于在垂直行业或特定领域和任务上实现极致的效率和性能。比如在情感分析、语言翻译、意图分类等特定领域都有对应的垂直领域模型。一些简单的意图分类和信息提取任务，由一个轻量、快速的专用模型处理，往往更具效率和成本优势。

虽然大模型的综合能力很强，在处理开放性、高复杂度的任务时效果更好，但是认为所有任务都需要使用最顶尖的模型是一个误区，许多场景下小模型同样能出色地完成任务，甚至做得更好。在实际落地生产的复杂应用中，通常是大模型与垂直领域模型协同工作，分别处理复杂、开放的任务和简单、高频的任务，从而优化整个系统的效果、成本与响应速度。

模型能力和微调

虽然模型的能力非常强大，但是他们的能力主要源于庞大的预训练数据，这也意味着无论模型多强大，它的知识都是固化的。它不认识你公司的最新产品，也不了解你应用的具体 API，更不知道你数据库里的实时信息。它的所有能力，都建立在对预训练数据中存在的模式和逻辑的理解之上。模型本身并不知道你的业务场景里独有的规则和工具，你需要将这些信息结构化地描述清楚并且提供给它，它会在每次的交互中动态地理解你提供的内容，并结合自身的通用知识来完成内容的生成。模型是 AI 原生应用的重要组成部分，但两者并不等价。

为了追求极致性能，许多团队会考虑训练或微调自己的专属模型。他们会基于自身的业务场景，以及标注的私有数据来进行训练和微调。由于专属模型在训练过程中见过大量与你业务相关的标注数据，在业务理解和工具调用时的表现会显著优于通用的大模型。

虽然专属模型的表现非常好，但是它并不适用于所有企业，训练和微调的成本是巨大的，它不仅包括高昂的计算资源费用，还需要海量的高质量标注数据、专业的算法团队以及漫长的开发周期。这对于绝大多数企业而言，投入与产出不成正比，很难持续。

如何选择模型

考虑到模型的种类繁多，且各有能力边界，还有多种定制化的可能，模型的选择也是 AI 原生应用开发过程中的一个难点。这里不存在一劳永逸的银或通用的最佳模式，企业必须基于自己的实际业务场景，权衡任务复杂度、性能要求、开发成本和响应延迟等多个因素来综合选择和组合最合适的模型。

一个务实的策略是从顶配开始，逐步优化：先用能力最强的模型搭建原型以验证业务逻辑，再逐步将流程中的非核心、简单任务替换为更经济、更快速的小模型，最终找到成本与性能的最佳平衡点。一个优秀的 AI 原生应用，其模型架构往往不是单一的，而是一个经过精心设计的、由不同规模和专业度的模型协同工作的有机系统。

框架

与传统微服务开发（如 Spring、Dubbo）不同，智能体应用开发面临多样化的框架选择。框架的多样性源于代码确定性与 LLM 不确定性的本质差异：

微服务应用，Spring 和 Dubbo 本质上解决的是确定业务逻辑下的组件编排，包括服务发现、RPC 调用、分布式事务、服务配置等。

这些问题的解法相对确定，整个行业逐渐收敛到一些最佳实践上，框架自然容易标准化。

AlAgent 则不同

LLM 驱动的 Agent，输出存在高度不确定性，没有一个能放之四海皆准的设计模式，ChainofThought、ReAct、Plan- and- Execute、Multi- Agent 等模式的落地方式差异很大。更别说原本就依赖设计模式来定义的开发框架的标准化了，有的开放框架偏重链式推理（例如 LangChain），有的偏重知识检索（例如 Lamalndex），有的则强调人机的混合编排（例如 Dify）。大家对“不同业务场景下，Agent 要如何解决核心问题”，是无法在框架层达成一致的。

因此，Agent 的应用开发框架天然就很难收敛。不同的框架都有自己的设计模式哲学，只要定位清晰，都能获得一部分开发者群体的青睐，一家独大的情况很难出现。

本节将带大家了解下业内主流的 Agent 设计模式，这对我们应用开发框架的选型，以及如何充分利用，至关重要。

Agent 设计模式

1、ChainofThought（思维链）

提出背景：GoogleResearch 在 2022 年发表的论文《Chain- of- ThoughtPromptingElicitsReasoning in Large Language Models》。

核心思想：让模型在回答前，把推理过程一步步写出来。不是一口气报出答案，而是把整个推理过程展示出来。

场景例子：问小王比小李大 1 岁，小张的年龄是小李的两倍。如果三个人的年龄加起来是 41 岁，问小王多大？思维链方式：假设小李的年龄是 x，那么小王 = x + 3，小张 = 2x，总和 = (x +1) + x + (2x) = 4x + 1，4x + 1 = 41，4x = 38，x = 10，所以小王 = 10 + 3 = 13。结果小王 13 岁。这种方式在逻辑推理、数值计算、逐步分析类问题里，会显得更稳健。

2、Self-Ask（自问自答）

提出背景：MicrosoftResearch 在 2022 年的研究工作《Self- AskwithSearch》。核心思想：让模型在回答时学会“反问自己”，把大问题拆成多个小问题，然后逐个回答。场景例子：问 2016 年奥斯卡最佳男主角的年龄是多少？Self- Ask 会先问：2016 年奥斯卡最佳男主是谁？（答：李奥纳多 - 狄卡比奥），再问他当时多大？（答：41 岁），最后组合答案。这种方式特别适合事实链路长的问题。

3、ReAct（推理 + 行动）

提出背景：Princeton 与 GoogleResearch 在 2022 年论文《ReAct: Synergizing Reasoningand Acting in Language Models》。核心思想：在推理（Reasoning）和外部行动（Acting，比如调用搜索引擎或 API）之间交替进行。ReAct 比 CoT、Self- Ask 更全能，原因在于它不仅是推理模式，还内建了与外部世界交互的闭环。场景例子：问杭州昨天的天气？ReAct 会先想：“我不知道昨天的天气，需要查询”，然后执行“调用天气 API”，再推理并回答。这让 Agent 既有思维，又能动手。

4、Plan-and-Execute（计划与执行）

提出背景：出现在 2023 年前后的 Agent 应用开发框架实践（如 LangChain 社区）。核心思想：把任务拆成两个阶段，先生成计划（Planning），再逐步执行（Execution）。场景例子：假设你让 Agent 写一篇“新能源车的市场调研报告”，它不会直接生成报告，而是先拟定计划：收集销量数据，分析政策趋势，总结消费者反馈，撰写结论。然后逐条执行。适合多步骤、需长时间任务的场景。

5、TreeofThoughts（ToT，树状思维）

提出背景：Princeton 和 DeepMind 在 2023 年的论文《TreeofThoughts：DeliberateProblemSolvingwithLargeLanguageModels》。核心思想：不是单线思维，而是生成多条思路分支，像树一样展开，再通过评估机制选出最佳分支。场景例子：解一道数独时，Agent 会尝试多个候选解法（分支 A、B、C），逐步排除错误分支，最终选出唯一解。适合复杂规划和解谜任务。

6、Reflexion/IterativeRefinement（反思与迭代优化）

提出背景：2023 年论文《Reflexion: Language Agents with Verbal Reinforcement Learning》。

核心思想：Agent 具备自我纠错的能力，犯错后会总结失败原因，再带着反思尝试下一次。场景例子：让 Agent 写一段 Python 代码，如果第一次运行报错，它会读报错信息，反思“函数参数写错了”，然后自动修正并重试。适合代码生成、流程执行类场景。

7、Role-playingAgents（角色扮演式智能体或者机器是多智能体协作）

提出背景：源自 AutoGPT、ChatDev、CAMEL 等社区项目。核心思想：把任务拆分给不同角色的 Agent，每个 Agent 都有专属职责，通过对话协作完成任务。场景例子：一个软件开发任务里，有产品经理 Agent 写需求文档，程序员 Agent 写代码，测试 Agent 写测试用例。它们像团队一样协作。适合复杂系统开发或跨职能协同。

这些认知框架，其实构成了 Agent 世界里的思维模式库：

CoT：一步步写过程 Self- Ask：拆分成小问题 ReAct：既思考也动手 Plan- Execute：先计划再执行 ToT：树状多分支探索 Reflexion：自我反思迭代 Role- playing：多人协作分工

它们并不是互斥的，可以混搭使用，理解这些模式，能让我们在应用开发框架选型和使用时，想的更为透彻，一些设计模式，例如 ReAct，已经被 LangChain、Llamalndex、Dify、SpringAlAlibaba 等 Agent 开发框架内置成基础框架，帮助开发者提升模型的调用效果。

Agent 开发框架

说完 Agent 设计模式，我们再来看 Agent 开发框架。整体来看，开发框架可以归纳为三种主要形态：低代码、高代码与零代码。低代码相对已经比较成熟，高代码是当前生产的主流形态，而零代码则代表了未来的演进方向。与此同时，多 Agent 的分布式架构正在成为跨越三种模式的长期趋势。

1、从低代码到高代码

在 AI 原生应用的早期探索中，低代码工具发挥了重要作用。Dify、Flowise、Coze、阿里云百炼、CloudFlow、n8n 等产品，通过可视化编排和模板化配置，使非专业开发者也能快速拼装出应用雏形。这类工具极大降低了试错成本，为企业内部的概念验证（PoC）和小规模试点提供了便利。

其实低代码平台在运行时也离不开底层引擎的支撑。大多数低代码平台的底层引擎和管控部署在一起，这限制了 Agent 的性能和可扩展性。但更重要的原因在于低代码平台是对于高代码的一层封装，其抽象层次很难满足所有场景，无法在性能、可扩展性和复杂业务逻辑方面满足大规模生产的要求。这也是为什么在进入大规模生产应用阶段后，很多低代码方案都需要迁移到高代码框架中实现。

高代码则代表了当下 AI 原生应用生产落地的主流形态。ADK、LangGraph、AutoGen、AgentScope、SpringAlAlibaba 等框架，为开发者提供了面向 Agent 的编程接口。相比低代码，高代码具备更高的性能可控性、更强的灵活性以及更好的可预测性，能够支撑复杂场景下的业务逻辑实现与系统集成。来自阿里云客户实践进一步验证了这一点：目前在大规模业务场景落地的 Agent，大部分都是基于高代码方案。

2、高代码的演进

在 AI 原生应用的三种构建模式中，高代码模式最贴合工程师对系统的可控需求。此类开发方式不限于使用现成 Agent 框架，更注重灵活的编排、精准的上下文控制、可靠的执行机制，以及对复杂任务的支撑能力。

高代码模式本身经历了从 ChatClient -> Workflow -> Agentic 的演进过程。

ChatClient 阶段：最初的实现仅是一次单一的 LLM 调用，简单但缺乏复杂任务执行能力；Workflow 阶段：通过将传统工作流转化为 LLM 节点编排，实现了自主性与确定性的初步平衡，但由于编排复杂，维护成本较高；Agentic 阶段：逐渐成为主流形态。它通过提供面向 Agent 的 API，并内置多种通用的协作模式（Pattern），使开发者能够在 Agentic 自生性和 Predictability（可预测性）之间取得平衡，从而兼顾开发效率与执行准确性。

这一演进过程，折射出 AI 原生应用在落地时面临的核心挑战：既要让系统具备足够的智能性和自主性，又必须确保其行为在工程意义上可控、可验证。

3、零代码的愿景

相比之下，零代码代表着更远期的方向。MetaGPT 等探索性产品，尝试让用户完全通过自然语言即可驱动应用开发，依赖模型本身的推理与规划能力完成任务分解、逻辑编排和工具调用。零代码的潜力在于真正实现 AI 应用的全民化与智能自治，但现实中受制于模型能力，其生产可用性仍不足：复杂业务场景对推理深度、上下文管理和可控性的要求，远超当前模型的稳定水平。

因此，零代码模式目前更多处于探索与验证阶段，难以承担大规模生产任务。但它所代表的愿景，展示了未来 AI 应用可能的终极形态。

白皮书的第 3 章中将以 SpringAlAlibaba 为例，探讨如何使用 AI 应用开发框架开发一个简单的智能体，以及单智能体和多智能体的区别和联系，智能体的部署方式，消息驱动的智能体开发。

提示词

AI 原生应用的编程范式发生了根本变化，Prompt（提示词）成为与 AI 沟通的核心方式，极大影响输出质量。

Prompt 是什么

Prompt 是用户向 AI 模型提供的输入指令，用于引导模型生成期望的输出。它可以是一个具体的问题、一段描述、一组关键词，或是相关的上下文信息，其核心作用是告知模型用户期望获得什么样的内容。Prompt 的载体也不仅限于自然语言文本，还可以包含代码片段、数据格式说明，甚至是图像与文字相结合的多模态输入。

Prompt 质量 = 输出质量

大模型输出质量并非完全取决于模型本身，还依赖于输入的 Prompt 是否清晰、完整、具体。在 AI 领域，有一句经典的话“GarbageIn，GarbageOut”（垃圾进，垃圾出）。这句话在提示词工程中也同样适用，Prompt 的质量直接决定了 AI 生成内容的质量、相关性和准确性。

大型语言模型输出内容的质量很大程度上取决于 Prompt 的明确性与具体性。当用户提供一个模糊、开放式的指令时，例如“写点关于人工智能的东西”，模型由于缺乏明确的上下文和约束条件，其生成的内容往往会泛泛而谈。这类回答通常只是一篇缺乏深度和特定信息价值的通用性概述，难以满足专业或具体化的应用需求。

相反，当用户构建一个结构化、包含多维度要素的精确指令时，结果则截然不同。例如，一个明确要求模型“以科技专栏作家的身份，撰写一篇 800 字左右的文章，探讨人工智能在医疗影像诊断中的最新应用、优势与挑战，并列举实例”的 Prompt，为模型提供了清晰的目标、角色设定、内容框架和格式要求。因此，模型能够生成一篇逻辑严谨、信息详实、专业度高的文章，其输出结果的精准度和实用价值也得到极大提升，更加符合人们的预期。

如何优化 Prompt

优化 Prompt 是与大语言模型高效沟通的关键，一个好的 Prompt 能让模型更精准、更深入地理解你的意图，从而生成质量更高的内容。

早期的研究还表明，你对模型说“这个问题你回答对了，我会奖励给你 100 元”，“这个问题你回答错误了，你会被惩罚”，这种贿赂或者威胁也能优化模型的生成效果。不过随着模型的进化，这些小技巧都已经变得无效了。但有一个原则是不会变的，开发者需要清晰、有效地与模型交流，并明确指导它如何处理各种情况，这就像是你给一位聪明的助理分配任务，指令越清晰、背景信息越充分，他完成工作的质量就越高。

如何优化 Prompt 是 AI 原生应用开发中的难点，在第 4 章中我们将围绕上下文工程对 Prompt 展开详细介绍。

RAG

RAG（检索增强生成）为大模型提供知识库，是当前 AI 应用架构的重要范式，广泛应用于客服、推荐、智能助手等场景。

RAG 知识库的应用架构

下图展示了基于 RAG 构建知识库的应用架构，分为离线索引构建和在线检索生成过程。

如今构建如上图这样的 RAG 系统已经变得非常简单，开源社区和商业产品都提供了非常简便的构建方式。在满足复杂的业务需求的过程中，通常一个简单的 RAG 系统无法满足业务需求，会遭遇准确率和召回率的挑战、信息冗余噪声导致的模型幻觉、知识库庞杂难以管理等问题。当前 RAG 系统的构建也逐步向模块化、AgenticRAG 的高级架构演进。

从离线过程来看，文档解析技术除了经典的 OCR 和电子解析技术，也在利用大模型进行更准确的文档解析，比如对于图片类的文档，通过 VLM 视觉理解大模型，能够对这类文档进行更全面的文档理解。

从在线检索过程来看，检索前、检索中、检索后过程里，都发展出很多的技术手段来加强和管理整体 RAG 的效果。如检索前可以增加 Query 改写、知识库路由等模块，检索过程可以采用混合检索策略，检索后可以增加重排序、拒识模块等。

从构建包含 RAG 的 AI 应用来看，AgenticRAG 成为新的趋势之一，用户将知识库检索作为大模型的工具之一，由大模型来决定是否以及何时进行检索以获取必要的知识库信息。另外，多模态 RAG 技术也是当前蓬勃发展的领域，随着多模态理解大模型能力的增强，多模态 Embedding 向量模型也取得了重大的发展，包括阿里云通义团队也发布了业内广受好评的 Qwen3Embedding 文本和视觉系列模型。基于多模态向量模型的 RAG 系统在商品搜推、视频创作等各类场景已经获得了规模化的落地。

RAG 知识库的应用场景

知识库落地有广泛的应用场景，包括客户服务、个性化推荐、AI 陪伴、内容创作等。其中客户服务 RAG 是最广泛落地的应用之一，从其业务特征来看，通常就需要大量的业务背景知识，并且这些知识是不断更新的，例如常见问题解答（FAQ）、产品规格、故障排除指南以及公司政策等。

在这些场景里，知识库是严格知识的来源、可信任，作为降低大模型幻觉的重要手段。甚至在更加严肃的场景里，许多用户将大模型只作为知识库的整理工具，要求大模型回答需要严格遵循知识库里的知识，不能随意发挥，以避免严重的客诉问题。

不过我们也发现，当前 RAG 的应用也已经超越简单的问答。基于 RAG 的系统，叠加大模型分析客户对话数据等能力，能够帮助企业优化服务策略和挖掘销售线索等。RAG 的价值正在从解决幻觉这一技术问题，向赋能业务的更高层面演进。多模态 RAG 的兴起，将 RAG 的应用边界从纯粹的知识问答推向了更广阔的领域。比如在零售电商场景，用户可以通过上传图片来检索商品，从而实现商品图搜和个性化推荐。而在媒体娱乐领域，多模态 RAG 也帮助从海量音频视频内容中检索出特定的片段，从而服务于音视频内容分发以及新兴的 AI 视频创作场景。

RAG 知识库技术的未来发展

大模型发展至今，RAG 作为最成熟的 AI 应用架构之一，尽管基础 RAG 的实现已趋于成熟，但仍有人认为其技术含量不高。然而，我们观察到，构建一个真正满足复杂业务需求的高级 RAG 系统仍然充满挑战，并且该领域正在不断演进。比如在当前 AdvancedRAG 架构里，仍然有许多技术问题待解决。多模态 RAG 相关的技术，也在快速地发展当中，其应用场景和想象力空间更大。

另外，我们把 RAG 拆开来看，知识库向量检索也是当前上下文工程（ContextEngineering）的核心技术实现。我们试举两个例子：首先是动态样例（FewShot）干预，通过在知识库里维护正例、反例，可以实时通过用户 Query 召回相关的样例，补充到上下文，从而降低大模型幻觉；然后是大模型工具检索，当一个 AlAgent 需要接入数量很多的工具时，对于大模型选择工具的和工具入参提取的准确率会造成比较大的挑战，通过构建工具的知识库和动态召回少数工具的方式，可以提升大模型工具调用的准确性和降低时延。

无论未来 LLM 架构如何演变，只要它们仍然依赖外部知识来增强其能力，向量检索作为一种高效、语义化的上下文获取机制，仍然将发挥重要的价值。在白皮书的第 4 章中，我们将围绕上下文工程对 RAG 展开详细的介绍。

记忆

AI 应用的记忆能力提升了用户体验，实现了跨会话连贯性、个性化和基于历史的深度推理。

记忆的核心作用

大模型本质上是无状态的，仅能依赖有限的上下文窗口进行交互，这就导致了交互的非连续性，使模型无法积累连贯的认知或沉淀长期的经验。为此 AI 原生应用的开发中需要引入记忆组件，为模型带来三个维度的能力：跨越会话的连贯性、高度自适应的个性化，以及基于历史信息的深度推理。从而驱动 AI 应用从一个单轮问答的机器人，成长为能与我们长期协作、处理复杂任务的智能伙伴。

1、跨越会话的连贯性

大模型的上下文窗口是无状态的，无法跨越单次会话来维持交互的连续性。每次交互的中断都意味着历史信息的丢失，会造成沟通效率低下和用户体验的割裂。

AI 应用通过引入记忆组件解决这一问题。它能够长期保存关键信息（如对话历史、任务状态、决策依据），并通过高效的检索与上下文注入机制，在新的交互中动态地为模型提供相关背景。这确保了多轮、长周期交互的逻辑一致性，进一步支持长期任务的执行。

2、高度自适应的个性化

在缺乏用户信息的情况下，大模型只能提供标准化的通用响应，无法满足个体用户的特定需求。AI 应用通过记忆构建和维护动态的用户画像来实现个性化。它系统性地记录用户的偏好，如格式要求、沟通风格等，也能记住历史行为模式与长期目标，使模型能够生成高度定制化的输出。这种基于记忆的自适应能力，是 AI 应用从一个通用问答工具转变为个人助理、专属顾问等高级应用形态的技术前提。

3、基于历史信息的深度推理

在处理需要深度分析的复杂问题时，模型若仅依赖当前上下文，其推理过程会因信息不足而变得片面，难以进行有效的因果推断或类比分析。

AI 应用借助记忆提供的历史知识和经验充当推理的证据库，当模型在决策时，能关联并整合分散在历史中的相关数据、相似案例或既有结论。通过这种方式，模型能够进行更全面、更具深度的综合判断，显著提升其在专业领域（如医疗诊断、法律咨询）中的决策质量与可靠性。

短期记忆和长期记忆

记忆通常分成短期记忆（Short- Term Memory, STM）和长期记忆（Long- Term Memory, LTM）。它们各自有不同的技术实现、特性和应用场景，二者的协同工作构成了 AI 的完整记忆系统。

1、短期记忆

短期记忆，也被称为工作记忆或上下文记忆，指的是模型在单次、连续的交互会话中所能直接访问的信息。

技术上，这通常通过在每次 API 调用时，将完整的对话历史以 messages 列表的形式传递给模型来实现。另一种方式是利用 System Prompt，预置贯穿全局的指令或动态更新的摘要。由于信息被直接放在输入中，这种方式保证了记忆内容的高保真度和即时访问性，模型可以获取未经压缩的原始对话，无需额外步骤。

然而短期记忆的效用受限于模型的上下文窗口这一瓶颈，一旦对话历史的长度超出容量上限，最旧的信息便会被舍弃，不可避免地导致逻辑断裂或信息丢失。此外，不断增长的上下文也会带来 API 成本与推理延迟的显著增加。因此，这种记忆机制在本质上是易失、昂贵且容量有限的，无法独立支撑长期的、连贯的交互需求。

2、长期记忆

长期记忆旨在解决短期记忆的局限，让 AI 能够记住跨越不同会话，甚至数天数月前的信息，如用户偏好、历史项目经验、关键事实等。

具体而言，系统会将需要长期保存的信息，如对话摘要、用户画像或外部文档，进行向量化处理，并存入专门的向量数据库进行索引。当新的交互发生时，系统会根据当前输入的语义，在数据库中高效检索出最相关的历史记忆片段，并将其作为背景知识动态加入到模型的输入中。这种基于外部数据库和语义检索的机制，使得记忆具备了持久性与高度的可扩展性。

然而，长期记忆的引入也伴随着新的挑战与权衡。由于长期记忆存储的通常是信息的摘要或切片，而非原始对话，因此必然存在一定程度的信息保真度损失。更为关键的是，系统的整体效果高度依赖于检索环节的质量。不精准的检索不仅无益，反而可能引入无关或错误的上下文，从而干扰模型的判断。同时，该架构也带来了更高的系统复杂度和额外的处理延迟，需要在实际应用中仔细考量。

有效增强 AI 应用记忆能力的关键，在于实现短期与长期记忆的动态协同。短期记忆保证了交互的即时性与上下文的完整性，长期记忆则提供跨会话的知识背景。然而，要实现理想效果，开发者必须根据具体业务场景进行精心设计，尤其要在上下文成本与检索质量之间做出权衡。关于这一核心权衡，我们将在第 4 章上下文工程中展开详细分析。

工具

工具调用扩展了大模型的能力，使其能主动与外部世界交互，突破知识静态性的限制。

如何调用工具

下图展示了大模型工具调用的基本流程。

大模型本身不能够调用工具，它是作为一个思考引擎，根据用户的输入和可用的工具描述，智能地判断并决定调用哪个工具以及传递哪些参数。

当前 AI 原生应用构建的核心范式，主要是大模型通过理解用户意图并决定调用哪个工具，而实际的执行操作则由外部程序完成。这种工具调用分离不仅提升了系统的可扩展性和安全性，也为构建复杂、自主的 AI 原生应用奠定了基础。

MCP 协议

随着大模型与工具的结合成为普遍需求，一个关键问题开始凸显：不同的模型提供商（如 OpenAI、Anthropic、阿里云百炼平台等）对工具调用的实现方式各有差异，而每个外部服务（如数据库、搜索 API 等）又都有自己的 API 接口，企业用户也有自己的私有 API。这类工具的对接，就要求开发者对每个工具进行适配开发，Agent 的开发变得繁重甚至不可行。

Anthropic 公司于 2024 年 11 月推出了模型上下文协议（ModelContextProtocol，MCP），MCP 协议是为大模型与外部数据、应用和服务之间的通信提供一种安全且标准化的语言。它被形象地比喻为 AI 应用界的 USB- C 接口，其核心在于定义一个统一的协议，使得大模型能够轻松、标准地连接到各种数据源和工具，从而轻松地实现互操作。MCP 协议迅速地成为当前大模型供应商的标准协议，包括 OpenAI、Google、阿里云百炼在内的模型服务商，都对 MCP 做了兼容性支持。

市场上也出现了不少 MCP 服务的托管平台，如阿里云百炼 MCP 广场、魔搭 MCP 服务、MCPSO 等。MCP 社区为了统一标准，定义了 MCPRegistry，旨在标准化服务器的分发和发现方式，使 Agent 和工具更容易连接，并于近期发布了 Preview 版本，用于公开可用的 MCP 服务器的开放目录和 API。Nacos 参与了社区共建、并丰富了该标准的落地形式，开源 NacosMCPRegistry，定位私有化，方便企业内部部署。

工具调用的挑战和发展

当前大部分主流模型供应商都已经将工具调用能力作为其大模型的原生功能进行内置，并且在模型预训练阶段对工具调用进行了特定增强。

当然目前基于 FuncationCalling 或 MCP 工具调用的 Agent 实践，也面临着诸多的挑战，比如工具调用时延、工具提取参数准确性、安全鉴权等问题。从长远来看，我们认为，大模型工具调用的这些挑战都将被有效解决，大模型将能更智能地组合和串联多个工具来完成更复杂的跨领域任务，我们将在白皮书的第 5 章 AI 工具展开详细的介绍。

网关

AI 网关作为应用与大模型、工具之间的智能调度中心，解决了模型切换、Token 管理、语义缓存等 AI 原生需求。

什么是 AI 网关

AI 网关是一个专为 AI 应用设计的、位于应用和大模型之间、应用和工具之间、模型和模型之间的中间件。它是传统 API 网关在 AI 时代的演进，其核心职责不再仅仅是路由和保护 RESTfulAPI，而是要理解并管理以 Token 为中心的、高延迟、流式传输的流量。由于 AI 应用背后的模型、运行时和框架标准难以统一，AI 网关通过抽象协议和统一治理，将模型、业务 API、外部工具纳入统一控制平面，成为了连接异构模型与多样化业务场景最明确、最关键的统一切面，是 AI 原生应用架构中不可或缺的组件。

统一的模型接入与厂商解耦

AI 原生应用面临的一大挑战是模型服务的多样性与协议的碎片化。不同供应商（如 OpenAI、Anthropic、阿里云百炼、DeepSeek）的 API 标准各异。

AI 网关的首要任务就是屏蔽这种底层复杂性，通过提供统一规范的 API，将所有模型的接口都转换成一个标准的、统一的接口对外服务。这意味着开发者无需为新模型编写定制代码，无论是切换模型、A/B 测试还是组合模型都变得异常简单，从而有效避免厂商锁定，并提升了开发效率与系统灵活性。

融合存量系统与 AI

企业通常拥有成千上万个正在运行的 REST、GraphQL、gRPC 等协议的存量服务。AI 网关能够通过其协议抽象层扫描这些服务的 API 规范（如 Swagger），自动生成符合大模型工具调用（如 MCP 规范）的描述文件，并借助 MCPRegistry 注册到统一的服务目录中。

这使得企业无需改动存量业务接口的代码，就能将它们升级为“AI- ReadyAPI”，极大地盘活了企业现有的 IT 资产，避免重复建设。

智能路由与故障转移

AI 网关是一个智能的决策者，能够基于预设策略，动态地将请求路由到最合适的模型服务。

策略路由：不仅可以根据请求内容或用户身份分发流量，还可以依据实时的 Token 单价、延迟、显存占用等权重进行动态推理流量调度，实现成本与性能的最佳平衡。例如，将简单任务交给经济的小模型，复杂任务交给顶配模型。

故障转移：通过持续监控后端服务健康状态，一旦检测到模型响应缓慢或不可用，便会自动将流量无感切换到备用模型，保障应用的高可用性。

精细化的成本控制与优化

大模型的推理成本是 AI 应用的核心开销，而付费模型的 Token 费用常常不可预测。AI 网关提供了一系列专为降本增效设计的功能。

语义缓存：能够理解请求的意图，对于内容相似但表述不同的重复问题（例如“北京的天气怎么样？”和“查询北京今日天气”）可直接返回缓存，避免对昂贵模型的重复调用。成本与流控：AI 网关能够实现基于 Token 数量的精准速率限制和预算配额管理。它可以按组织、用户、应用等维度管理 Token 预算，当超出限额后，可以自动降级到成本更低的模型，从而有效防止资源滥用和成本超支。

企业级安全与合规

在企业环境中，安全合规至关重要。AI 网关作为所有 AI 流量的统一入口，是确保全链路合规安全的关键节点。

安全合规能力：网关可内置国密算法支持和敏感语料实时过滤等能力，满足数据安全要求。审计与追溯：所有流经网关的 Prompt、Response、Token 消耗量等多维度数据都会被记录落盘，以满足实时审计和追溯等合规要求。

统一身份认证：能够与企业内部自有的身份授权基础设施对接，为 AI 生态提供统一的认证授权切面，解决了 AI 生态与企业现有安全体系难以直接融合的问题。

数据、观测与优化

AI 网关的价值远不止于管理和路由，其作为统一控制面的定位，使其成为承载统一数据采集、观测与优化的最佳载体。

正是因为所有 AI 相关的请求与响应都必须流经网关，它才能够捕获每一次交互的完整数据：包括原始提示词、最终响应、模型选择、Token 消耗、调用时延和业务成本等。

统一采集：所有数据都通过一个标准化的方式汇集，为后续的分析提供了坚实基础。全面观测：这些数据让原本黑盒的模型调用过程变得透明，形成了对系统性能、成本和用户行为的统一视图。

驱动优化：通过分析洞察，可以直接反哺系统，例如自动化化路由策略、更新缓存内容、或筛选出有价值的数据用于模型微调，形成一个持续学习、自我完善的闭环。

运行时

AI 原生应用运行时承载动态业务逻辑、智能体协作与数据流管理，是区别于传统应用的新型执行环境。

什么是 AI 原生应用的运行时

运行时是 AI 原生应用的核心执行环境。与传统应用中逻辑由开发者预先编码、执行路径相对确定的模式不同，AI 原生应用的业务流程往往由大模型根据用户实时意图动态生成。这意味着运行时处理的不再是固定的代码，而是充满不确定性的执行计划。

因此，运行时的核心职责，就是为了驾驭这种高度的不确定性。它需要将模型、工具和数据流有机地整合在一起，不仅要能理解和执行模型生成的动态任务，还要为整个过程提供稳定、高效和安全的保障。

运行时的核心挑战

一个强大的 AI 原生应用运行时，必须直面由其动态化和数据密集型特性带来的三大挑战：

动态逻辑的可靠执行：模型生成的任务计划可能存在逻辑错误或无法执行的步骤。运行时需要具备强大的容错和异常处理能力，确保动态任务能够顺利完成或优雅地失败，而不是简单地崩溃。同时，任务的每一步都可能需要不同的依赖库或计算资源，运行时必须能够按需、即时地准备执行环境。

海量与实时数据的高效处理：数据是 AI 应用的燃料。尤其在 RAG 等场景下，运行时需要在毫秒级内从海量知识库中检索、处理并传递数据，这对存储 I/O 和网络延迟提出了极致要求。此外，对于在线学习、实时推荐等场景，运行时还必须具备高效的流式处理能力，确保模型能基于最新的数据进行推理。

异构组件的复杂协同：AI 应用是由模型、向量数据库、外部 API 工具、多智能体等多个松散耦合的组件构成的复杂系统。运行时需要充当这些组件间的消息总线，提供强大的服务编排和治理能力，并原生支持 MCP、A2A 等主流交互协议，确保它们之间能够顺畅地通信与协作。

面向 AI 优化的 Serverless 架构

面对上述挑战，以 Serverless（无服务器）架构为核心，并为其注入状态管理和性能优化能力，正成为构建下一代 AI 运行时的关键路径。

为无状态的 Serverless 引入记忆：传统的 Serverless 架构是无状态的，难以支持需要上下文的多轮对话或复杂的智能体协同。现代 Serverless 平台通过亲和性调度等机制，可以将同一会话的多次请求调度到同一个预热实例上，实现了状态的就近缓存，巧妙地解决了记忆问题，既保证了性能，又简化了开发。

兼顾极致弹性与低延迟：AI 推理任务的流量往往具有潮汐效应。Serverless 按需执行、自动伸缩的特性完美契合了这一需求，能轻松应对流量洪峰，并在闲时将成本降至为零。针对延迟敏感的场景，通过预留实例和依赖预加载等技术，可以有效解决冷启动问题，实现毫秒级响应。

让 AI 工具即插即用：Serverless 函数是承载 AI 工具的天然载体。每个工具可以被封装成一个独立的函数，由智能体按需、事件驱动地调用。这种按实际调用计费的模式，极大地降低了大量长尾工具的闲置成本。

未来，运行时将继续向着更智能、更自动化的方向发展。它将成为一个能为开发者屏蔽底层复杂性的超级电网，让开发者可以像用电一样，简单、高效、经济地创造和部署 AI 原生应用。白皮书的第 7 章将详细介绍为 AI 应用和工具提供经济、安全算力的 Serverless 运行时。

可观测

AI 应用的可观测性体系需覆盖全链路追踪、全栈观测和自动化评估，保障系统稳定性与安全性。

评估

AI 应用的评估体系需适应非确定性输出，采用 LLM-as-a-Judge 等新范式，贯穿全生命周期。

构建高质量的数据集

构建高质量、场景相关的评估数据集是评估的核心。构建高质量数据集主要有三种途径。第一种是人工构建，由领域专家依据业务逻辑，精心设计和标注一系列评估用例。这些用例包括标准的问答详情、复杂的多步推理任务，以及那些专门用来测试模型能力边界的边缘场景。第二种是自动化采集，通过对线上系统的观测日志和业务记录进行分析，可以挖掘出海量的真实用户交互数据，尤其是效果不理想的用例，相较于人工构建，成本低且效率高。除以上两种成熟的构建方式外，第三种是探索使用 AI 算法构建数据集，通过大语言模型或其他生成式 AI 技术，高效创建多样化的测试例，包括复杂场景和对抗样本，从而进一步提升数据集的覆盖范围，但需要额外关注生成的数据集的质量。

将以上方式结合，便构成了驱动数据质量持续提升的数据飞轮。在这个模式下，我们通过海量的业务数据和客户数据构评估 AI 原生应用，同时将评估过程中发现的失败案例和用户反馈的数据，进行重点采集、清洗和标注。这样不仅能丰富和强化评估数据集，还能为后续模型的微调提供了高质量的数据。这些真正反映业务挑战的核心数据资产，是整个 AI 原生应用自我进化和持续优化的关键。

明确评估目标

为了实现持续性的评估和优化，通常将复杂的 AI 原生应用评估进行分类，形成一个多层次的评估矩阵。具体而言，评估可以分解为以下几个关键层面：

• 语义评估从文本中提取实体、格式、抽象语义（如意图、情绪、主题）等多层次信息，并生成相关问题以深化理解。例如，对 Prompt 进行语义评估时，分析其是否含歧义、信息缺失或逻辑矛盾。

• Rag 评估则针对从知识库中召回语料的质量进行多维度衡量，包括检索准确性（找到最相关的知识片段）、生成内容可靠（回答不偏离事实）、重复性及多样性等指标。

• 工具调用评估针对需要执行动作的 AI 原生应用，评估其工具调用的合理性与效率。对这些原子能力的评估，是确保 Agent 应用可靠地与外部世界交互、完成实际任务的基础。

• 最后，在所有组件评估之上，是端到端的 Agent 评估。它从宏观视角出发，不纠结于具体步骤的详情，只关注 Agent 是否最终、高效地解决了用户的原始问题，并带来满意的整体体验。

搭建完整的自动化评估系统进行评估

自动化评估系统需要使用高质量的数据集，优秀的裁判模型，匹配的评估模版，对评估目标进行有效的评估。

• 数据飞轮驱动的高质量数据集是评估系统最重要的数据资产。

• 评估的有效性取决于裁判模型的能力上限。优先使用高阶的裁判模型对被测系统输出进行质量评分，或针对裁判模型本身进行优化。针对特定任务维度，还可以引入专业化模型辅助判断。比如利用自然语言推理模型评估生成内容的事实一致性，通过嵌入模型计算语义相似度，以衡量回答相关性。

• 评估模版与评估算子的设计需与评估目标相匹配，实现模块化、可配置的评估能力。例如，在 Prompt 评估中主要关注识别模糊、歧义或结构不良的输入；在 RAG 评估中主要衡量检索相关性与生成忠实度；在 Tools 评估中，则通过参数结构校验与执行结果语义解析，验证工具调用的准确性与理解能力。

自动化评估系统还需要覆盖完整的 AI 原生应用生命周期。评估的执行应该建立离线与在线相结合的机制。

离线评估面向应用迭代周期，在开发测试阶段对 Agent 在典型任务、边缘案例及对抗性输入下的表现进行全面测试，支持版本间的横向对比与回归分析，确保新版本满足生产上线的要求。在线评估则通过小流量灰度发布，在真实生产环境中结合自动化评估器实时生成性能指标。通过与 A/BTest 框架相结合，在响应时间、业务效果等关键指标上进行综合对比，为上线决策提供数据支撑。

白皮书在独立的第 9 章中深入探讨 AI 原生应用评估的重要意义与完整体系，同时引入全新的评估范式 LLM- as- a- Judge，并详细阐述如何构建一个高效的自动化评估系统，以推动 AI 应用的持续优化与可靠性提升。

安全

AI 原生应用的开放性和自主性带来新的安全挑战，需从应用、模型、数据、身份和基础设施多维度构建纵深防御体系。

在模型安全层面，安全威胁贯穿输入、推理与输出全过程。输入层面临对抗样本、提示词注入与恶意文件上传等攻击；推理层存在模型越狱、RAG 知识库爬取与函数调用劫持等风险；输出层则可能生成钓鱼信息、虚假建议或传递隐蔽指令。为此，需部署大模型原生安全护栏，作为连接应用与模型之间的可信中间层，提供覆盖全链路的一站式防护，保障输出内容合法可控，并实现 AIGC 内容可追溯、责任可追，满足监管要求。

数据安全是 AI 应用可信落地的基础。大模型涉及数据采集、传输、存储、访问、使用与删除六大阶段，每个环节都存在泄露、滥用或逆向推断的风险。企业担忧商业秘密被用于二次训练，个人用户关注隐私控制权，而多方参与的数据处理流程使责任认定变得困难。为此，需构建覆盖全生命周期的数据安全保障体系。具体而言，数据收集阶段需完成分类分级与脱敏，防止敏感信息进入训练流程；传输过程采用 HTTPS/TLS 加密与私有网络隔离，确保通信安全；存储环节通过租户隔离与端到端加密保护数据主权；访问控制需要实现精细化权限管理；访问和使用过程中嵌入 AI 安全护栏进行实时过滤；删除阶段支持账号注销后的彻底清除与迁移能力，保障用户数据主权。

身份安全方面，随着非人类身份（NHI）如 API 密钥、AK/SK、OAuth 令牌等大量涌现，身份安全管理面临严峻挑战。传统静态权限模型难以应对 AI 应用动态、复杂的行为模式，易导致凭据泄露与未授权访问。为此，需构建覆盖“事前、事中、事后”的身份安全闭环体系：事前通过异常访问监测识别风险；事中实施动态权限管理，采用即时授权与细粒度访问控制，遵循最小权限原则；事后通过自动化审计清理僵尸凭据。同时，依托密钥管理服务实现凭据的统一托管、自动轮转与细粒度访问控制，并通过 M2M (Machine to Machine) 能力集中管理 NHI 身份，支持动态授权与全生命周期自动化管控，全面提升 AI 环境下身份安全防护水平。

在 AI 应用的全生命周期中，基础设施的安全性直接决定了应用的可靠性、可信度和合规性。从模型训练到推理服务，AI 系统的复杂性、分布式架构以及对海量数据的依赖，使得任何基础设施层面的疏漏都可能引发模型盗用、数据泄露或服务滥用等严重风险。所以需要从构建安全、可控的运行环境，需要从全局安全态势到计算、网络等细节层面，建立多层次防护体系。

综上所述，AI 原生应用的安全防护是一项系统工程，涵盖应用、模型、数据、身份与基础设施五大维度。面对动态、自主、多模态的新一代智能体，传统的边界防御已不再适用，必须转向以“纵深防御、动态检测、全程可控”为核心的综合防护体系。唯有将安全能力深度融入 AI 原生架构的设计、开发与运维全流程，才能真正构筑起可信、可控、可审计的智能应用生态，支撑 AI 技术的可持续发展与规模化落地。

白皮书在独立的第 10 章中全面介绍 AI 安全风险的来源和分类，并从应用、模型、数据、身份，以及系统和网络的安全保护进行展开。

总结

本章系统梳理了 AI 原生应用的 11 个关键要素，包括模型、框架、提示词、RAG、记忆、工具、网关、运行时、可观测、评估与安全。每一要素都在 AI 应用的设计、开发与运维中扮演着不可替代的角色。理解并合理运用这些要素，将为构建高效、可靠、可扩展的 AI 原生应用奠定坚实基础。