当人工智能从 “辅助工具” 演进为驱动应用创新的核心引擎，AI 原生应用应运而生 —— 它不再是传统软件的 “AI 附加版”，而是以大模型为智能中枢、以 Agent 为行为载体，深度融合记忆、工具、检索等能力，能自主理解、决策与行动的新一代应用形态。这种形态的变革，彻底重构了应用的开发逻辑、运行范式与价值边界，也催生了一套全新的技术体系与实践标准。

本文围绕 AI 原生应用的 11 个关键因素展开深度解析，从 “智能核心”（大模型）到 “架构骨架”（框架与 Agent 设计模式），从 “能力延伸”（RAG、工具、记忆）到 “运行保障”（网关、运行时、可观测、评估、安全），系统性梳理各要素的技术原理、应用场景与实践挑战。这些因素并非孤立存在：大模型提供认知基础，框架与设计模式规范智能行为，RAG 与工具打破知识与行动的边界，记忆赋予持续交互的连贯性，而网关、运行时、可观测等则为应用的稳定、高效、安全落地保驾护航。

无论是企业开发者探索 AI 原生应用的技术路径，还是从业者理解行业演进的底层逻辑，本文都将提供一套全面、实用的知识框架，助力把握 AI 原生时代的核心竞争力，推动智能应用从概念走向规模化落地。

模型

在AI原生应用中,大模型扮演着大脑的角色,负责核心的理解、推理与生成任务。这与传统应用截然不同。传统应用依赖固定的规则,难以应对复杂多变的场景;而大模型的引入,则赋予了应用灵活的思考与决策能力,使其真正具备智能。

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

围绕通用大模型、垂直或领域模型、专属模型展开介绍，阐述各类模型的特点、局限，以及在 AI 原生应用开发中的模型选择、协同与应用情况：

一、通用大模型

1. 常见类型：包括 GPT、Claude、Qwen、DeepSeek、Gemini 等系列，是大众较为熟悉的大模型类型。
2. 核心特征：拥有极大的参数规模，具备广博的知识储备和强大的通用推理能力；形态上既可以是纯文本模型，也可以是多模态模型，能够同时理解图像、声音和文字等多种信息形式。
3. 能力与局限：模型规模通常与处理复杂、开放性任务的能力正相关，规模越大，处理这类任务的能力越强，但相应地，其成本和延迟也相对更高。

二、垂直或领域模型

1. 核心理念：不追求通用知识与通用性，专注于在垂直行业、特定领域或特定任务上，实现极致的效率和性能。
2. 适用场景：适用于情感分析、语言翻译、意图分类等特定领域任务，尤其对于简单的意图分类和信息提取任务，轻量、快速的专用模型在效率和成本上更具优势。

三、模型的知识局限性与 AI 原生应用关系

1. 知识局限性：无论模型能力多强大，其知识都源于庞大的预训练数据，具有固化属性。它无法知晓企业最新产品、应用具体 API、数据库实时信息，所有能力均建立在对预训练数据中模式和逻辑的理解上，不了解业务场景独有的规则和工具。若要模型适配业务，需将这些信息结构化描述并提供，模型会在每次交互中动态理解，结合自身通用知识完成内容生成。
2. 与 AI 原生应用的关系：模型是 AI 原生应用的重要组成部分，但两者并不等价，不能将模型等同于完整的 AI 原生应用。

四、专属模型

1. 核心特点：许多团队为追求极致性能，会基于自身业务场景和标注的私有数据，训练或微调专属模型。由于专属模型在训练过程中接触大量与业务相关的标注数据，在业务理解和工具调用方面的表现，显著优于通用大模型。
2. 适用局限：专属模型并非适用于所有企业，其训练和微调成本极高，不仅需承担高昂的计算资源费用，还需要海量高质量标注数据、专业算法团队支持，且开发周期漫长。对绝大多数企业而言，这种投入与产出不成正比，难以持续推进。

五、AI 原生应用开发中的模型选择

1. 选择难点：因模型种类繁多、各有能力边界，且存在多种定制化可能，模型选择成为 AI 原生应用开发过程中的难点。此过程中不存在一劳永逸的 “银弹” 或通用的最佳模式，企业必须基于自身实际业务场景，权衡任务复杂度、性能要求、开发成本和响应延迟等多个因素，综合选择和组合最合适的模型。
2. 务实选择策略：可采用 “从顶配开始，逐步优化” 的策略：先用能力最强的模型搭建原型以验证业务逻辑，再逐步将流程中的非核心、简单任务替换为更经济、更快速的小模型，最终找到成本与性能的最佳平衡点。
3. 优秀 AI 原生应用的模型架构：一个优秀的 AI 原生应用，其模型架构往往不是单一的，而是经过精心设计的、由不同规模和专业度的模型协同工作的有机系统。

六、实际应用与选择总结

1. 认知误区规避：需避免两种认知误区，一是认为所有任务都需使用最顶尖的通用大模型，实际上许多场景下小模型（垂直或领域模型等）能出色完成任务甚至表现更优；二是盲目追求开发专属模型，并非所有企业都具备相应资源与需求，需理性评估。
2. 整体应用逻辑：在实际落地生产的复杂应用中，通常优先考虑通用大模型与垂直领域模型的协同工作模式 —— 通用大模型处理复杂、开放的任务，垂直领域模型处理简单、高频的任务，以此优化系统效果、成本与响应速度；对于有极致性能需求且具备充足资源（资金、数据、技术团队）的企业，可考虑开发专属模型；而多数企业需结合 “从顶配到优化” 的策略，在多种模型类型中权衡，构建适配自身业务的多模型协同有机系统。

框架

微服务框架（如 Spring、Dubbo）具有明确的特点，其对应的微服务应用聚焦于确定业务逻辑下的组件编排，需要解决服务发现、RPC 调用、分布式事务等问题，而这些问题的解法相对确定，行业内也已形成最佳实践，因此这类框架容易实现标准化。

与之不同的是，AI Agent 框架存在明显的核心差异与挑战，由于 AI Agent 由 LLM 驱动，其输出存在高度不确定性，且没有普适性的设计模式，像 Chain of Thought、ReAct、Plan-and-Execute、Multi-Agent 等模式的落地方式差异显著，这就导致依赖设计模式的开发框架难以实现标准化。同时，主流 AI Agent 框架呈现出定位分化的特点，不同开放框架基于不同的设计模式哲学，定位各有侧重，例如 LangChain 偏重链式推理、Llamalndex 偏重知识检索、Dify 强调人机混合编排，并且行业内无法在框架层就 “不同业务场景下 Agent 如何解决核心问题” 达成一致。

受上述特性影响，AI Agent 框架的市场格局也较为特殊，其应用开发框架天然难以收敛，不存在 “一家独大” 的情况，只要框架定位清晰，就能吸引有对应需求的开发者群体。此外，了解 Agent 设计模式具有重要意义，掌握业内主流 Agent 设计模式，对于 AI Agent 应用开发中的框架选型以及充分利用框架都发挥着关键作用。

Agent设计模式

1、Chain of Thought（思维链）

• 提出背景：Google Research 在 2022 年发表的论文《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》。
• 核心思想：让模型在回答前，把推理过程一步步写出来。不是一口气报出答案，而是把整个推理过程展示出来。
• 场景例子：问小王比小李大 1 岁，小张的年龄是小李的两倍。如果三个人的年龄加起来是 41 岁，问小王多大？思维链方式：假设小李的年龄是 x，那么小王 = x+1，小张 = 2x，总和 =(x+1)+x+(2x)=4x+1，4x+1=41，4x=40，x=10，所以小王 = 10+1=11。结果小王 11 岁。这种方式在逻辑推理、数值计算、逐步分析类问题里，会显得更稳健。

2、Self-Ask（自问自答）

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

3、ReAct（推理 + 行动）

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

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

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

5、Tree of Thoughts（ToT，树状思维）

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

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

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

7、Role-playing Agents（角色扮演式智能体 / 多智能体协作）

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

各模式总结

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

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

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

Agent开发框架

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

一、从低代码到高代码

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

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

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

二、高代码的演进

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

高代码模式自身经历了从 ChatClient→Workflow→Agentic 的演进过程。

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

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

三、零代码的愿景

与之相比，零代码代表着更远期的发展方向。MetaGPT 等探索性产品，尝试让用户完全通过自然语言就能驱动应用开发，依靠模型本身的推理与规划能力完成任务分解、逻辑编排和工具调用。

零代码的潜力在于能够真正实现 AI 应用的全民化与智能自治，但在现实中，由于受到模型能力的限制，其生产可用性仍显不足：复杂业务场景对推理深度、上下文管理和可控性的要求，远远超出了当前模型的稳定水平。

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

提示词

一、提示词（Prompt）的定义

Prompt 是用户向 AI 模型提供的输入指令，核心作用是告知模型用户期望获得什么样的内容，以此引导模型生成期望的输出。

从形式来看，Prompt 可以是一个具体的问题、一段描述、一组关键词，或是相关的上下文信息；其载体也不仅限于自然语言文本，还可以包含代码片段、数据格式说明，甚至是图像与文字相结合的多模态输入。

二、Prompt 质量与 AI 输出质量的关系

大模型输出质量并非完全取决于模型本身，还依赖于输入的 Prompt 是否清晰、完整、具体，即 “Prompt 质量 = AI 输出质量”。

在 AI 领域，“Garbage In, Garbage Out”（垃圾进，垃圾出）这一经典说法，在提示词工程中同样适用，Prompt 的质量直接决定了 AI 生成内容的质量、相关性和准确性。

具体而言，大型语言模型输出内容的质量很大程度上取决于 Prompt 的明确性与具体性：

1. 若用户提供模糊、开放式的指令，如 “写点关于人工智能的东西”，模型因缺乏明确的上下文和约束条件，生成的内容往往泛泛而谈，多为缺乏深度和特定信息价值的通用性概述，难以满足专业或具体化的应用需求。
2. 若用户构建结构化、包含多维度要素的精确指令，如 “以科技专栏作家的身份，撰写一篇 800 字左右的文章，探讨人工智能在医疗影像诊断中的最新应用、优势与挑战，并列举实例”，该 Prompt 为模型提供了清晰的目标、角色设定、内容框架和格式要求，模型能生成逻辑严谨、信息详实、专业度高的文章，输出结果的精准度和实用价值大幅提升，更符合人们的预期。

三、Prompt 的优化方法

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

早期研究发现，采用 “回答正确奖励 100 元”“回答错误会被惩罚” 这类贿赂或威胁的方式，能优化模型生成效果，但随着模型进化，这些技巧已失效。

不过，有一个原则始终不变：开发者需要清晰、有效地与模型交流，并明确指导它如何处理各种情况。这就如同给一位聪明的助理分配任务，指令越清晰、背景信息越充分，助理完成工作的质量就越高。

RAG(检索增强生成)

在之前的内容中我们提到过，大模型的知识都是固化的，它不认识你公司的最新产品，而 RAG 就是为模型提供知识库的一种有效方法。

基于 RAG（Retrieval Augmented Generation，检索增强生成）构建知识库，是大模型兴起之后最快被采纳接受的架构范式之一。当前，RAG 系统已经被广泛地应用在客服问答、个性化推荐、智能对话助手等场景当中。RAG 技术能够弥补大模型因知识截止而无法获取最新信息的问题，并有效降低其产生幻觉的风险，而且 RAG 技术相比于大模型后训练或微调方式，能以更低成本的方式与企业的专有数据作对接，以实现大模型快速技术验证和商业化尝试。

RAG 知识库的应用架构

基于 RAG 构建知识库的应用架构如下，可简单划分为离线索引构建和在线检索与生成过程。离线向量过程通过把用户上传的文档进行文档智能解析、切片，再进行向量化存储到向量数据库。在线过程则把用户的请求问题向量化之后，与向量库中的切片向量进行相似度比对，从而召回最接近用户问题的相关切片。

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

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

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

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

RAG 知识库的应用场景

知识库落地有广泛的应用场景，包括客户服务、个性化推荐、AI 陪伴、内容创作等。其中客户服务 RAG 是最广泛落地的应用之一，从其业务特征来看，通常需要大量的业务背景知识，并且这些知识是不断更新的，例如常见问题解答（FAQ）、产品规格、故障排除指南以及公司政策等。在这些场景里，知识库是严格的知识来源、具有可信任性，是降低大模型幻觉的重要手段。甚至在更加严肃的场景里，许多用户将大模型只作为知识库的整理工具，要求大模型回答需严格遵循知识库里的知识，不能随意发挥，以避免严重的客诉问题。

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

RAG 知识库技术的未来发展

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

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

无论未来 LLM 架构如何演变，只要它们仍然依赖外部知识来增强其能力，向量检索作为一种高效、语义化的上下文获取机制，仍然将发挥重要的价值。

记忆

提到 AI 应用的记忆，其实大家都不陌生，我们在使用 Qwen、Deepseek 等应用的时候，已经习惯了查看历史对话，也可以在历史对话中继续之前的话题，这就是记忆功能给 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 应用记忆能力的关键，在于实现短期与长期记忆的动态协同。短期记忆保证了交互的即时性与上下文的完整性，长期记忆则提供跨会话的知识背景。然而，要实现理想效果，开发者必须根据具体业务场景进行精心设计，尤其要在上下文成本与检索质量之间做出权衡。

工具

LLM 的知识是静态的，其知识内容截止于训练数据的最后更新日期。这使得它们无法直接回答关于实时、动态信息的问题，例如最新的天气、股票价格或突发新闻。此外，模型本身无法直接与外部系统交互，无法执行发送电子邮件、预订航班或执行数据库查询等实际操作。

正是由于这种内在限制，模型供应商推出了大模型工具调用功能。工具本质上是模型可调用的外部接口，能将模型的能力延伸至静态训练数据之外。工具的应用，让 AI 应用从被动的回答者转变为能够主动采取行动的智能体。

如何调用工具

大模型本身不具备调用工具的能力，它扮演着思考引擎的角色，会根据用户的输入和可用的工具描述，智能判断并决定调用哪个工具、传递哪些参数。

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

OpenAI 率先在其推理 API 接口中支持了 Function Calling（后续升级为 Tools）的工具形式，OpenAI 兼容接口也成为当下大部分大模型服务提供商的标准接口形式。函数调用（Function Calling）的核心，是让大模型生成调用外部 API 的结构化入参。开发者需预先向模型提供可用工具的详细描述，通常以 JSON Schema 的形式定义函数名称、功能描述和参数列表。当用户发起请求时，大模型会分析用户意图，判断是否需要调用工具及调用哪个工具，随后生成包含 tool_calls 字段的结构化 JSON 对象，该对象会精确指定需调用的工具名称及传递给工具的参数。应用程序获取到这个结构化入参后，即可解析并调用相应工具。

当然，也有不少用户会将工具描述配置在系统提示词中，此时大模型会生成一段遵循特定语法的文本，供外部应用程序解析调用。不过通常更推荐采用 Function Calling 方式，以获得更稳定的结构化输出。

MCP 协议

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

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

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

工具调用的挑战和发展

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

不过目前基于 Function Calling 或 MCP 工具调用的 Agent 实践，仍面临诸多挑战，例如工具调用时延、工具参数提取准确性、安全鉴权等问题。从长远来看，这些大模型工具调用相关的挑战有望被有效解决，未来大模型将能更智能地组合、串联多个工具，完成更复杂的跨领域任务。

网关

在 AI 原生应用中，如果说大模型是各具特长的专家团队，那么 AI 网关（AI Gateway）就是连接应用与这些专家的智能总调度中心。随着大模型以周为单位更新，AI 应用以天为单位演进，企业需要在安全、合规、成本、效率四重约束下交付稳定业务。AI 网关正是为应对这一挑战而生，它解决了传统 API 网关无法处理的模型切换、Token 经济、语义缓存和内容风控等 AI 原生需求，为整个系统带来秩序、可靠与安全。

什么是 AI 网关

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

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

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

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

融合存量系统与 AI

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

这使得企业无需改动存量业务接口的代码，就能将它们升级为 “AI-Ready API”，极大地盘活了企业现有的 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 原生应用。

可观测

AI 原生应用因其模型对话、工具调用和 RAG 等复杂的内部流程，决策路径充满了不确定性。这使得传统的监控方法力不从心 —— 传统监控主要关注基础设施的性能指标与日志，难以应对 AI 应用特有的行为不可预测、输出质量波动和成本结构复杂等挑战。因此，我们需要一套专为 AI 应用打造的可观测性体系，以保障其稳定性、可维护性和安全性。

可观测性与传统监控的核心区别

AI 应用可观测性与传统监控的核心区别在于：监控告诉你 “发生了什么问题”，而可观测性则要回答 “为什么会发生问题”。

监控系统通常聚焦于 API 响应时间、错误率等关键指标，主要起预警作用；可观测性则更进一步，通过整合链路追踪、上下文数据等，构建从用户输入到最终输出的完整视图，从而精准定位问题根因，实现系统的持续优化。

完整可观测体系的三大核心能力

一个完整的 AI 可观测体系，应具备以下三大核心能力：

• 端到端全链路追踪：提供端到端的日志采集和链路追踪功能，可可视化展示请求在整个 AI 应用中的执行路径。同时支持对历史对话的灵活查询与筛选，为调试和系统改进提供便利。
• 全栈可观测：涵盖应用、AI 网关、推理引擎三个维度的可观测能力，观测内容包括实时追踪响应延迟、请求吞吐量、Token 消耗、错误率以及资源使用情况（如 CPU、内存、API 令牌等）。当指标出现异常时，系统能触发警报，帮助团队在问题影响用户前快速响应，同时实现对成本的有效监控。
• 自动化评估功能：通过引入评估 Agent，对应用和模型的输入输出进行自动化评估，可检测幻觉、不一致性或答案质量下降等问题。高效的评估工具通常会集成评估模板，方便工程师快速应对常见的质量和安全问题。

可观测性的工程落地实践

在工程实践中，落地可观测性需兼顾技术集成与数据安全两大核心要点：

• 技术集成层面：OpenTelemetry 作为行业开放标准，为打通全链路数据提供了关键支持。它定义了统一的采集规范，使可观测系统能通过自动埋点等方式无缝接入主流 AI 框架，显著降低了集成成本。
• 数据安全层面：由于 AI 应用常处理敏感信息，可观测系统必须内置数据脱敏和访问控制等安全机制，确保数据处理过程符合合规要求。

评估

传统软件应用的评估测试基于确定性逻辑，其核心特点是固定输入必然产生稳定且可复现的输出。然而，AI 应用的行为本质上是非确定性的概率输出，即使输入相同，模型的输出也可能因上下文、训练数据分布或随机性而千差万别。这种非确定性行为使得传统的评估测试方法难以直接适用于 AI 应用。

这种差异使得 AI 原生应用的评估范式从传统的测试方法逐步转向以 LLM-as-a-judge 为代表的前沿评估范式，并发展出更加完善的评估体系。在测试环境中验证通过的 AI 应用，在真实生产环境中面对复杂多变的用户数据时，其表现和预期相差甚远。因此，我们必须重新定义评估：它是深度整合到 AI 应用设计、开发、部署和运维全生命周期中的持续过程，旨在保障系统的长期稳定性与可靠性。

构建高质量的数据集

构建高质量、场景相关的评估数据集是评估的核心。构建高质量数据集主要有三种途径：

第一种是人工构建，由领域专家依据业务逻辑，精心设计和标注一系列评估用例。这些用例包括标准的问答详情、复杂的多步推理任务，以及专门用来测试模型能力边界的边缘场景。

第二种是自动化采集，通过对线上系统的观测日志和业务记录进行分析，可挖掘出海量的真实用户交互数据，尤其是效果不理想的用例。相较于人工构建，这种方式成本低且效率高。

除以上两种成熟的构建方式外，第三种是探索使用 AI 算法构建数据集。通过大语言模型或其他生成式 AI 技术，高效创建多样化的测试例，包括复杂场景和对抗样本，从而进一步提升数据集的覆盖范围，但需额外关注生成数据集的质量。

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

明确评估目标

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

• 语义评估：从文本中提取实体、格式、抽象语义（如意图、情绪、主题）等多层次信息，并生成相关问题以深化理解。例如，对 Prompt 进行语义评估时，分析其是否含歧义、信息缺失或逻辑矛盾。
• RAG 评估：针对从知识库中召回语料的质量进行多维度衡量，包括检索准确性（找到最相关的知识片段）、生成内容可靠性（回答不偏离事实）、重复性及多样性等指标。
• 工具调用评估：针对需要执行动作的 AI 原生应用，评估其工具调用的合理性与效率。对这些原子能力的评估，是确保 Agent 应用可靠地与外部世界交互、完成实际任务的基础。
• 端到端的 Agent 评估：在所有组件评估之上，从宏观视角出发，不纠结于具体步骤的详情，只关注 Agent 是否最终、高效地解决了用户的原始问题，并带来满意的整体体验。

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

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

• 高质量数据集：数据飞轮驱动的高质量数据集是评估系统最重要的数据资产。
• 裁判模型：评估的有效性取决于裁判模型的能力上限。优先使用高阶的裁判模型对被测系统输出进行质量评分，或针对裁判模型本身进行优化。针对特定任务维度，还可引入专业化模型辅助判断，比如利用自然语言推理模型评估生成内容的事实一致性，通过嵌入模型计算语义相似度以衡量回答相关性。
• 评估模版与评估算子：评估模版与评估算子的设计需与评估目标相匹配，实现模块化、可配置的评估能力。例如，在 Prompt 评估中主要关注识别模糊、歧义或结构不良的输入；在 RAG 评估中主要衡量检索相关性与生成忠实度；在 Tools 评估中，则通过参数结构校验与执行结果语义解析，验证工具调用的准确性与理解能力。

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

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

安全

AI 原生应用的开放性、自主性和多模态交互特性，显著扩大了系统的安全风险敞口，给应用安全防护体系带来了新的挑战。AI 应用自主决策和执行任务的能力可能被攻击者恶意利用，例如通过提示词注入等手段操控 AI 应用行为，而越权访问操作则可能导致数据泄露。同时，若 AI 基础设施存在漏洞，还可能引发注入、逆向攻击和算力被滥用等威胁。最后，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 技术的可持续发展与规模化落地。