> **来源：[研报客](https://pc.yanbaoke.cn)** # AI应用开发新范式 计缘 阿里云智能云原生应用平台 # 01 AI 应用架构新范式 # AI Agent 架构和发展趋势 AI Agent 架构 AI Agent 趋势 Level Of Intelligence # AI 应用架构 # MCP 是什么 模型上下文协议（Model Context Protocol）是一个开源协议，由Anthropic（Claude开发公司）开发，旨在让大型语言模型（LLM）能够以标准化的方式连接到外部数据源和工具。它就像AI应用的通用接口，帮助开发者构建更灵活、更具上下文感知能力的AI应用，而无需为每个AI模型和外部系统组合进行定制集成。MCP被设计为一个通用接口，类似于USB-C端口，允许LLM应用以一致的方式连接到各种数据源和工具，如文件、数据库、API等。 # 标准化 MCP标准化了LLM访问外部数据的方式，简化了不同数据源和工具的集成。 # 模块化 MCP促进了模块化设计，允许独立开发和维护不同组件。 # 可扩展性 MCP使得添加新数据源或工具变得简单，无需大幅修改现有系统。 # 安全性 MCP提供结构化的访问模式，内置验证，确保数据交互安全且受控。 # MCP协议的运作机制 # MCP 协议的核心 MCP不像传统的协议定义，它没有一个确定的数据结构。它的核心是通过自然语言描述清楚有哪些MCP Server，承担什么作用，有哪些MCP Tool，承担什么作用，然后让大语言模型通过推理去选择最合适的MCP Server以及MCP Tool。所以它的核心本质上还是提示词工程。 # Cline 给 LLM 的系统提示词，以及 DeepSeek 的响应 > 告诉LLM你有一堆工具可以用。 > 告诉LLM每次你只能选一个工具用。 > 告诉LLM工具是通过XML描述定义的。并详细描述了XML Tag的定义。并给出了样例。本质就是告诉LLM你选择完后该返回什么样的格式。 将用户的问题和系统提示词一起输入给LLM。 向LLM解释了什么是MCP。 对每个MCP Server和 MCP Tool做了详细描述。包括传参格式。 > LLM得到用户的问题和MCP的一大堆信息后开始推理。 最后选择了可以解决用户问题最合适的MCP Server和MCP Tool，并以XML格式返回给Client/Agent。 # MCP 和 Function Calling 之间的区别 > MCP 是通用协议层的标准，类似于 “AI 领域的 USB-C 接口”，定义了 LLM 与外部工具 / 数据源的通信格式，但不绑定任何特定模型或厂商，将复杂的函数调用抽象为客户端-服务器架构。 > Function Calling 是大模型厂商提供的专有能力，由大模型厂商定义，不同大模型厂商之间在接口定义和开发文档上存在差异；允许模型直接生成调用函数，触发外部 API，依赖模型自身的上下文理解和结构化输出能力。 Function Calling Git 服务 数据服务 SaaS服务 业务服务 需要为每个外部函数编写一个 JSON Schema 格式的功能说明，精心设计一个提示词模版，才能提高 Function Calling 响应的准确率，如果一个需求涉及到几十个外部系统，那设计成本是巨大，产品化成本极高。 统一MCP客户端和服务器的运行规范，并且要求MCP客户端和服务器之间，也统一按照某个既定的提示词模板进行通信，这样就能通过MCPServer加强全球开发者的协作，复用全球的开发成果。 # MCP 的本质和挑战 模型上下文协议（Model Context Protocol）并不是一个确定的数据格式或数据结构，它是描述MCP信息的系统提示词和MCP Server和LLM之间的协同关系的结合。 # 描述MCP信息的系统提示词 延伸出值得思考的点： 系统提示词被污染后怎么办？ 系统提示词如何管理？ 系统提示词的安全性如何保障？ 系统提示词是否有标准定义？ > 每个企业是不是可以定义自己的系统提示词模板？ 如果MCP Server很多，那么系统提示词会非常长，岂不是很消耗Token？ # MCP Server与LLM之间的协同关系 延伸出值得思考的点： 目前负责协同的工具很少，比如Cline，Claude，且都是C/S工具，如何和企业级的AI应用结合？能不能结合？ MCP Server 会很多，如何管理？ > 现存业务能快速转成MCP Server吗？ 在这个新的协同关系下，AI应用该怎么开发？ > 企业级AI应用中，身份认证、数据权限、安全这些如何做？ # AI 应用架构新范式 # AI 应用架构新范式创析 原有的AI应用架构结合MCP，我们定义了AI应用架构的新范式。 > 一个云原生API网关三种角色，具备统一的管控底座，同时又实现各角色的协同调度。 > MSE Nacos发挥注册中心优势，增加MCP Server的注册能力，实现普通服务和MCP Server的统一管理，结合网关实现现存业务0改造转换为MCP Server。 > SAE托管Dify，一键部署Dify，解决自建部署高可用，稳定性，性能问题，使AI Agent的运行引擎更稳定。 > FC具备丰富的触发器和各语言运行环境，支持流程编排，可快速开发AI Agent，并且提供MCP SDK，实现快速开发、封装MCP Server。 # 调用链路说明 (1) 用户向AI应用发起请求, 请求流量进入流量网关 (云原生API网关)。 (2) 云原生API网关侧维护管理了不同类型的AI Agent的API或路由规则，将用户请求转发至对应的AI Agent。 AI Agent无论以哪种方式实现，只要其中的节点需要获取数据，便向MCP网关（云原生API网关）请求获取可用的MCP Server及MCP Tool的信息。 (4) 因为MCP网关处可能维护了很多 MCP信息，可以借助LLM缩小MCP范围，减少Token消耗，所以向AI网关（云原生API网关）发请求和LLM交互。（这一步可选） ⑤ MCP网关将确定好范围的MCP Server及MCP Tool的信息List返回给AI Agent。 AI Agent将用户的请求信息及从MCP网关拿到的所有MCP信息通过AI网关发送给LLM。 (7) 经过LLM推理后，返回解决问题的唯一MCP Server和MCP Tool信息。 AI Agent拿到确定的MCP Server和 MCP Tool信息后通过MCP网关对该 MCP Tool做请求。 实际生产中 ③ - ⑧ 步会多次循环交互 # 02 云原生API网关介绍 # 云原生API网关简介 安全防护 流量防护开放平台 服务发现服务治理 传统网关模式 > 流量网关、API网关，微服务网关、AI网关、MCP网关多合一 统一东西南北向流量 $\succ$ 集成 WAF，内容安全数据面 $\succ$ 集成AI领域LLM，MCP 南北向流量 东西向流量 - - - - AI 流程 新一代网关模式 # 云原生API网关在应用架构的核心作用 - 链接生态 # 云原生API网关 - 流量网关 # 服务发现 支持K8s/Nacos等主流服务发现 > 深度集成函数计算FC $\succ$ 兼容DNS/ECS老的模式 # 服务清洗 > 安全防护 流量防护 # 服务热更新 > 路由/策略更热更新 证书热更新 插件热更新 # 服务灰度 支持灰度，且支持全链路灰度 支持蓝绿 支持灰度观测能力 # 服务优雅上下线 > 服务下线前提前隔离流量，再停应用 > 服务上线打10%流量预热 # 服务健康检查 $\succ$ 隔离异常节点 # 云原生API网关 - API 网关 API First（前后端分离并发开发）/ API 防护（默认安全/高可用）/ API 货币化（扩大生态做营收） # API货币化（开放平台） APP管理 权限管理 额度管理 API 计量 API计费 # API防护（策略管理） 安全防护 流控 跨域 超时重试 重写 # API First（并发提效） API设计 API 文档 API Mock 端代码生成 API 测试 # 核心优势 # 智能化 > AI 辅助API设计 AI Mock 数据 AI生成端代码 AI测试/诊断 # 策略丰富 > 内置 $10+$ 系统策略 支持 $30+$ 插件策略 支持 自定义策略（多语言） # 开源开放 支持Swagger（OAS标准） 支持 Ingress / Gateway API > 开源Higress无厂商锁定 # 云原生API网关-AI网关 # AI插件 提示词+请求转换缓存+向量检索RAG增强 # AI防护 集成绿网 Token 限流/限额 # AI Proxy 统一协议统一身份统一容错 # AI观测 LLM访问日志 Token大盘 # 云原生API网关 - MCP 网关 # 云原生API网关 - MCP 网关 秉承着自己吃自己狗粮的原则，云原生API网关在阿里集团内部已经有很多业务在深度使用，在企业级产品能力，稳定性，性能方面已经有多个大体量业务的背书。 # 云原生API网关作为流量网关，白屏操作 支持长连接SSE/WebSocket，热更新对长连接流量无损 支持流式传输，满足AI大带宽/高延时特性诉求 支持多种安全认证与限流防护 # AI应用 # 云原生API网关作为流量网关，白屏操作 支持长连接SSE/WebSocket，热更新对长连接流量无损 支持流式传输，满足AI大带宽/高延时特性诉求 高可用，99.999% SLA # AI模型服务平台 # 云原生API网关作为AI网关，通过Ingress集成PAI的管控 支持1W+ 超大路由/域名规模场景，多租共享集群模式，切换到Higgs后路由配置生效RT从原10分钟降到30秒内 构建完善可观测体系 # AI模型 无影 AI网关 钉钉 流量/AI网关 优酷 流量网关 通义灵码 MCP网关 # 03 云原生API网关底座核心优势 # 云原生API网关 - 高性能（比自建性能高1-5倍） # 1、Nginx Ingress高出约 $90\%$ 网关规格：16C32G*4节点 ECS型号：七代机（ecs.c7.8xlarge） # 2、硬件加速HTTPS QPS 提升约112%，RT下降50% # 加速前： # 加速后： 注：测试采用HTTPS短连接且关闭session ticket复用。 网关规格：1核 $2 \mathrm{G} * 1$ 节点 # 3、硬件加速压缩/解压缩提升 $300\%$ 网关规格：2C4G * 1 节点 ECS型号：八代机 4、结合阿里大规模生产经验从操作系统/网络/内核深度调优，性能提升 $40\%$ # 云原生API网关 - 高可用（SLA: 99.99%） # 高可用 # 研发时 内存异常检测 多线程竞争检测 静态代码分析检测 单元与集成测试 混沌测试 # 运行时 过载保护 本地文件缓存 推空保护机制 多可用区容灾 异常自动重启 > CI/CD保障 $\succ$ 故障与容灾演练 $\succ$ 压力测试 大盘监控与报警 # 变更时 配置合法性校验 配置变更Drain机制 优雅升级 监控报警 $\succ$ 灰度与回滚机制 > 大盘监控与报警 > 网关自内部2020.5上线，已在支付宝、钉钉、淘宝、天猫、优酷、飞猪、口碑等阿里各业务系统中使用，数年以来可用率100%，无任何故障。 $\succ$ 历经多年双11海量请求的考验，大促日可轻松承载每秒承载数10万笔请求，日请求量达到百亿级别。 # 云原生API网关-安全能力 # 核心优势 消费者鉴权 支持消费者认证&鉴权 > mTLS双向认证 集成阿里云证书服务自动更新 支持mTLS双向认证，零信任 支持硬件加速 登录认证 支持JWT/OIDC/自定义多种认证登录机制 $\succ$ 集成IDaaS对接支付宝，淘宝等三放认证 支持黑白名单 $\succ$ 流量防护 支持应用级和服务级流量控制 Web应用防火墙（WAF） 更短用户的请求链路 支持路由级防护能力 $\succ$ 自定义插件 > 提供默认安全增加组件 支持多语言自定义扩展 > 内核优势 > 采用数据面+控制面分离架构，防止控制面风险外溢到数据面 采用WASM扩展机制，控制操作范围 > 采用Envoy内核安全规则热更新 # 云原生API网关 - 插件机制（灵活扩展） # 核心优势 > 借助WASM特性支持多语言扩展 > 提供在线 IDE，AIGC生成插件，降低编写插件门槛 > 网关Wasm插件与开源Envoy $100\%$ 兼容，不存在锁定 > 提供插件市场，网关的二次扩展功能均通过插件提供给用户按需使用 > 插件采用热更新机制，在沙盒中执行，对网关自身稳定性无影响 # 04流量网关最佳实践 # 统一接入层 支持ACK/ACS集群内服务的自动同步 支持多ACK/ACS集群复用一个网关实例 支持 K8s Ingress / Gateway API 规范 支持 Nginx Ingress 核心注解扩展 支持 ACK One 多 K8s 集群容灾 # 全链路灰度 # 方案优势 网域（CLB/NLB）层和网关服务层解耦，网域层具备逃逸机制 云原生API网关多可用区部署，对跨可用区的多个业务集群的请求实现高效负载均衡分配，单可用区集群故障时，科实现秒级故障转移。 一套注册中心，多可用区部署，可实现故障节点秒级自动剔除 接入微服务治理，可根据不同场景，在控制台上一键开启同可用区调用，支持设置节点数阀值，如可用区节点数超过 $50\%$ 时同可用区调用生效。 # 05 AI网关代理LLM最佳实践 # LLM生产项目中客户必然遇到的问题 # 1 成本平衡问题 部署DeepSeek R1 671B满血版模型，至少需要2台8卡H20机器，列表价年度超过100W，但2台的TPS有限，无法满足生产部署中多个用户的并发请求，需要有方案找到TPS和成本之间的平衡点 # 2 模型幻觉问题 即使是671B的DS R1，如果没有联网搜索，依然有很严重的幻觉问题。 # 3 多模型切换问题 单一模型服务有较大的风险和局限性，比如稳定性风险，比如无法根据业务（消费者）选择最优模型。目前也没有开源组件和框架解决这类问题。 # 4 安全合规问题 企业客户需要对问答过程做审计，确保合规，减少使用风险。 # 5 模型服务高可用问题 自建平台性能达到瓶颈时需要有一个大模型兜底方案，提升客户大模型使用体验。 # 6 闭源模型QPS/Token限制问题 商业大模型都有基于API Key维度的QPS/Token配额限制，需要一个好的方式能够做到快速扩展配额限制。 # 云原生AI网关代理LLMs方案 # 云原生AI网关代理LLMs方案的核心收益 # 解决用户管理失控问题 核心问题1：我以什么样的方式将LLM服务和能力暴露给大家呢？ 解法：OpenAI API的协议基本已经是标准协议，目前市场上几乎所有的LLM都支持OpenAI API协议。所以提供遵循OpenAI API协议的HTTP接口就可以让企业员工通过各种方式使用LLM服务和能力。 核心问题2：企业内部部署DeepSeek R1 满血版，公司好几千人，但GPU资源有限，如何限制用户？ 解法：AI接口一旦暴露出去，基本上不可能只让一小部分人知道，所以需要对访问LLM服务的用户做以限制，只让能访问的人访问，不能访问的人即便知道了接口也无法访问。 # 1 # 创建消费者 > 一个消费者可以对应一个个人，也可以对应一个团队、一个组织等。 > 每个消费者会有对应的API Key。 # 建议 > 可以通过云原生API网关的OpenAPI，将申请消费者的流程接入企业的审批流 > API Key的分发也可以通过审批流分发 # 2 # 消费者授权 > 给消费者分配可以访问哪些LLM服务接口。 # 建议 可以将一个消费者对应到一个团队或一个项目组，根据具体业务分配不同的LLM服务接口权限。 # 3 # API Key 管理 > 一个消费者可以生成多个API Key。 > 根据不同的情况管理API Key，比如新增或重置。 # 建议 定期重置API Key，并通知到使用方，避免API Key泄漏后造成损失。 # 消费者鉴权认证 云原生API网关支持全局认证、路由配置认证和消费者鉴权，以实现对API访问的控制、安全性和策略管理，确保只有授权的请求才能访问服务。 # 生成APIKey 支持系统签发。 支持自定义。 支持多种来源： > Authorization > HTTP Header >Query参数 1 2 3 4 5 # 分发APIKey > 需客户通过安全通道交付消费者 # 授权APIKey > 给API Key授权可以访问的接口。 > 授权范围不局限在AI接口，可以是网关上管理的所有接口/路由。 # 验证APIKey 基于API Key来源方式，请求验证API Key有效性。 # 消费者鉴权认证的核心价值 身份可信：确保请求方为注册/授权用户或系统。 风险拦截：防止恶意攻击、非法调用与资源滥用。 > 合规保障：满足数据安全法规及企业审计要求。 > 成本控制：基于鉴权实现精准计费与API配额管理。 # 典型鉴权场景与API Key应用 # 第三方应用接入： > 挑战：开发者身份混杂，权限难隔离。 > 解决方案：为每个应用分配独立API Key，绑定细粒度权限策略。 # 企业内部服务调用： > 挑战：内网环境仍需防越权访问。 > 解决方案：API Key + IP白名单双重验证，限制访问范围。 # 付费用户API访问： > 挑战：防止Key泄露导致超额调用。 > 解决方案：针对API Key限流。 # 跨云/混合部署： > 挑战：异构环境统一身份管理。 > 解决方案：集中式API Key管理平台，支持多集群同步鉴权。 # 解决同一域名访问不同模型的问题 核心问题1：公司GPU资源有限，部署了满血版DeepSeek R1，还有其他一些小模型以及使用百炼的模型服务，现在域名都不统一，分发、管理、集成的成本都很高，如何使用同一个域名来访问不同的模型？ # 解法： > 满血DS R1和其他模型或者闭源LLM API服务共存，保持同一个API接口，不同业务通过请求中的模型名称，切换不同的模型。 > 满血DS R1和其他模型或者闭源LLM API服务共存，保持同一个API接口，不同业务通过请求中（Header，Cookie等）携带的业务标识，匹配到不同的模型。 1 # 维护多个模型服务 无论是PAI上部署的，IDC部署的，还是闭源LLM API，都可以作为模型服务被维护在AI网关。 2 # AI API代理多个模型服务 $\succ$ 使用多模型服务类型创建AI API，在一个AI API中可以添加多个模型服务。 > 模型名称通过Glob语法进行匹配。 3 # 同一个API请求 # 不同模型 >同一个API，不同业务传入不同的model name，即可实现模型切换。 # 建议 优先推荐使用模型名称匹配切换的模式，更遵循OpenAI协议。 云原生API网关支持基于模型名称做不同后端模型的切换，实现同一个接口对接多种LLM服务（百炼，PAI，IDC）。 # 模型切换的核心价值 > 业务需求适配：根据业务复杂性或性能要求选择不同模型。 > 数据隐私与合规性：在处理敏感数据时，可能需要切换到符合特定法规的模型，确保数据处理的安全性。 性能优化：根据实时性能需求，可能会切换到更快的模型以减少延迟。 成本与性能平衡：根据预算动态选择性价比最优的模型 $\succ$ 领域特定需求：针对特定领域（如法律、医学），可能需要切换到在相关领域微调过的模型，以提高推理准确性。 > 容灾与故障转移：主模型服务异常时快速切换备用模型。 # 解决LLM托管平台/闭源LLM QPM-Token限制的问题 核心问题：我们使用LLM托管平台上提供的DS R1 671B 模型的API，但是有QPM和TPM的配额限制，不能满足业务需求，但是每次升配很麻烦。 # 解法： > 目前所有的模型托管平台都有QPM和TPM的限制，并且有些平台是很难升配这个限制的，所以大多数用户都会选择申请多个帐号（API Key），变相的撑大这个配额限制，但缺点是在业务里管理多个API Key是一件很麻烦的事。 > 对输入/输出内容做缓存，减少对模型服务的请求次数以及Token消耗，从而提升业务侧的请求性能。 1 # 模型服务支持多 # API Key > AI网关，每个模型服务都可以配置多个API Key。 每次请求会轮询拿API Key，对模型服务做请求。 2 # API Key可实时维护 当监控到API Key配额水位较高时，可以实时动态添加模型服务的API Key。 # 建议 通过AI网关OpenAPI将添加API Key的行为集成到客户自己的自动化平台中。 3 # AI API维度结果缓存 AI API维度支持将输入和输出缓存到Redis，只需要配置Redis地址即可 支持精确匹配 支持向量化检索匹配 # 建议 在非常垂直类的应用场景下适合开启结果缓存，但建议开向量化检索匹配 在非常垂直类，问题和答案非常固定的应用场景下可以开精确匹配 在泛业务场景下开启结果缓存可能会降低推理精度或准确性，需要结合业务判断和考量 云原生API网关支持管理多个不同LLM托管平台，闭源LLM的API Key，突破LLM托管平台，闭源LLM的QPS限制。 # 多API Key管理的核心价值 像ChatGPT，豆包这类闭源LLM，或者百炼这种托管LLM平台，都是以提供API的方式供大家使用LLM的能力，但是受限底层GPU资源的压力，以及整体平台的稳定性，每个用户都有请求QPS的最大限制（基于平台的API Key的维度），且上调比较困难。 > 突破QPS上限：通过管理闭源LLM或LLM托管平台的多个API Key，变相提升QPS上限，提升业务性能。 云原生API网关提供了扩展点，可以将请求和响应的内容缓存到Redis，提升推理效率。 # 结果缓存的核心价值 提高效率：如果相同的输入反复出现，缓存可以避免重复运行模型，从而加快响应速度，特别是在处理常见问题时。 $\succ$ 降低成本：减少模型调用次数可以节省计算资源，尤其对大型模型来说成本较高。 > 保持一致性：缓存确保相同输入产生相同输出，有助于测试和合规性场景。 # 一键开启结果缓存 # 解决模型服务高可用的问题 核心问题：我们公司的主力模型是PAI上部署的DS R1 671B，但GPU资源并不是基于流量峰值储备的，所以当高峰期时，DS服务会请求失败，有什么办法可以保证业务健壮性？ 解法：有两种做法，并且可以搭配使用： > 可以构建多个个兜底模型服务，如果要保证模型一致，可以主力使用PAI上部署的，兜底使用百炼平台提供的。实现当PAI上部署的DS服务请求失败时，Fallback到百炼平台托管的DS R1 服务。从而保证业务的连续性和健壮性。 通过基于Tokens的限流策略，解决Burst流量，保护后端模型服务。 1 # 维护多个模型服务 无论是PAI上部署的，IDC部署的，还是百炼LLM API服务，都可以作为模型服务被维护在AI网关。 2 # 开启AI API限流策略 > AI API限流策略需要配合Redis实现，但是只需要开通Redis和在AI网关侧配置即可。 支持多种限流判断条件：Header，Query参数，Cookie，消费者，客户端IP 3 # 开启AI API # Fallback策略 AI API一键开启Fallback策略。 当主LLM服务出现异常后Fallback到指定的其他LLM服务。 支持配置多个Fallback模型服务。 # LLM服务Fallback 云原生API网关支持当某LLM服务请求失败后，Fallback到指定的其他LLM服务，以保证服务的健壮性和连续性。 # LLM服务Fallback的核心价值 当主LLM服务因为各种原因出现异常，不能提供服务时，网关侧可以快速将请求Fallback到配置的其他LLM服务，虽然可能推理质量有所下降，但是保证了业务的持续性，争取了排查主LLM服务的时间。 配置多个Fallback LLM服务：通过管理闭源LLM或LLM托管平台的多个API Key，变相提升QPS上限，提升业务性能。 # 基于Token维度的限流降级 除了传统的QPS限流降级以外，云原生API网关支持更贴合LLM推理场景的Token维度的限流能力。 # 基于Token维度限流的核心价值 > 成本管理：LLM的费用通常基于Token数量计算，限流帮助用户避免超支。例如，服务提供商可能按Token使用量提供不同定价层。 > 资源管理：LLM需要大量计算资源，限流防止系统过载，确保所有用户都能获得稳定性能，尤其在高峰期。 用户分层：可以基于ConsumerId或者API Key进行Token限流。 $\succ$ 防止恶意使用：通过限制Token数量来减少垃圾请求或攻击。 # 限流策略 判断条件： 支持按请求Header判断。 支持按请求Query参数判断。 支持按请求Cookie判断。 支持按客户端IP判断。 $\succ$ 限流规则： $\succ$ 精确匹配。 前缀匹配。 正则匹配。 $\succ$ 任意匹配。 $\succ$ 限流范围：每秒、每分钟、每小时、每天。 # 解决安全合规的问题 核心问题：模型托管平台自带好几层内容安全审核机制，但是我们在IDC部署或者在PAI部署的，如何能方便的接入内容安全审核服务？ 解法：AI网关中的AI API集成了阿里云的内容安全防护服务，可以一键开启。安全防护的规则还是要在内容安全服务侧配置。 支持请求内容检测。 支持响应内容检测。 云原生API网关和内容安全集成，在网关侧实现基于阿里云内容安全检测大模型的输入输出，保障AI应用内容合法合规。 # 内容安全的核心价值 防止攻击：验证输入可以阻止恶意提示注入，防止模型生成有害内容。 > 维护模型完整性：避免输入操纵模型，导致错误或偏见输出。 用户安全：确保输出没有有害或误导性内容，保护用户免受不良影响。 > 内容适度：过滤掉不适当的内容，如仇恨言论或不雅语言，特别是在公共应用中。 法律合规：确保输出符合法律和伦理标准，尤其在医疗或金融领域。 # 一键开启内容安全防护 ← bailian-ds-r1 # 解决大语言模型幻觉的问题 核心问题：公司部署了DeepSeek R1 671B的模型，但推理的结果和DS官网推理的结果有差距，似乎不满血？ 解法：推理的结果和DS官网推理的结果有差距大概率是因为DS官网开启了联网搜索。DeepSeek R1 671B的模型推理能力是很强，但训练的数据也是有限的，所以要解决幻觉还需是要在推理前先搜索和处理出比较确切的信息后，再由DS R1推理，所以联网搜索是非常关键的。目前模型托管平台提供的DS R1 API和自己部署的DS R1都需要自己实现联网搜索。 # 1 # 支持夸克/必应联网搜索 云原生API网关在AI API维度集成了夸克和必应的联网搜索能力 > AI API策略中一键开启，快速配置 # 2 # 搜索结果自动融合 > 搜索策略有多种配置项。 > 搜索结果自动融合进输入的 Prompt，无需用户额外处理。 # 3 # 问题意图识别 默认使用小模型对用户的问题做意图识别，避免无效的联网搜索 云原生API网关提供插件机制，可以快速对接联网搜索Tool（API）。大幅优化LLM的推理幻觉问题。 # 联网搜索的重要性 虽然DS是开源的，但是大家可能忽略了一个问题，那就是联网搜索。当不开联网搜索时，DS的推理结果会大打折扣，所以真正意义上的满血版DS R1应该是开了联网搜索的671B R1模型。而目前各个托管DS满血模型的平台都不支持联网搜索，比如百炼提供的，Ollama提供的所谓满血版DeepSeek R1。所以单纯的使用DS满血推理效果也是很一般的，有很大幻觉。即便像我们的AI Studio自己实现了联网搜索能力，效果也不及DS官网实现的。 参考：https://mp.weixin.qq.com/s/Q99LtM7wxgMCIHln6a8otg # 搜索增强核心思路 > LLM 重写 Query : 基于 LLM 识别用户意图，生成搜索命令，可以大幅提升搜索增强效果。 > 关键词提炼：针对不同的引擎，需要生成不同的提示词，例如 Arxiv 里英文论文居多，关键词需要用英文。 $\succ$ 领域识别：仍以 Arxiv 举例，Arxiv 划分了计算机科学/物理学/数学/生物学等等不同学科下的细分领域，指定领域进行搜索，可以提升搜索准确度。 长查询拆分：长查询可以拆分为多个短查询，提高搜索效率。 > 高质量数据：Google/Bing/Arxiv 搜索都只能输出文章摘要，而基于阿里云信息检索对接 Quark 搜索，可以获取全文，可以提高 LLM 生成内容的质量。 云原生API网关支持在应用、网关、后端LLM服务上开启OT服务来进行全链路的跟踪，通过TraceId来串联各个地方的日志、请求参数等信息。 # LLM推理服务日志采集 # 云原生API网关默认集成SLS日志服务基于日志服务提供 $\succ$ 访问日志，其中的ai_log字段可以自动打印大语言模型的输入、输出。 > 大语言模型的metrics信息：首字延时（TTFT-Time To First Token），tokens per second。 传统指标：QPS( request per second), RT(延时 )，错误率。 网关功能指标： $\succ$ 基于consumer的token消耗统计(需要把consumer的header信息加到ssl的日志里） 基于模型的token消耗统计。 $\succ$ 限流指标: 每单位时间内有多少次请求因为限流被拦截; 限流消费者统计（是哪些消费者在被限流）。 > 缓存命中情况。 安全统计：风险类型统计、风险消费者统计。 # LLM可观测大盘 # 基于CADT可视化部署LLMs业务 # Aliyun-PAI-H20部署模版 PAI灵骏智算资源（如H20）需要开通白名单使用，请提前联系销售经理或提交工单。 PAI工作空间命名、SLS的Project、OSS的Bucket命名，均全局唯一，需要修改。 针对分布式推理场景，登录PAI控制台，在Model Gallery选择对应模型，如DeepSeek-R1，点击"部署" 1、基于模版，先保存为应用 2、点击节点图标，调整节点数量、规格、付费方式 3、检查NAT、EIP等配置，按需调整，包括命名规范等。 4、分别点击VPC和交换机，默认新建，也可以选择导入已有的VPC、交换机 5、点击保存，如果有导入保有的资源，请点击导入已保有 6、部署应用，经过校验、计价和批量部署 7、资源部署完成，可以点击跳转到控制台核对配置 # 架构要点 $\succ$ 整体架构根据业务需求，部署在阿里云乌兰察布，可用区C。 > 网络规划：VPC：10.10.0.0/16，可用区C：10.10.0.0/24（可用IP数252个） > NAT+EIP 复用现有资源，单独配置，统一给VPC内服务配置公网访问能力。 > 开通人工智能平台PAI，灵骏智算资源规划在配额（pai_quota_h20）中，并将资源配额绑定到指定的工作空间(ai.ai_h20.ws)。 H20对应规格：ml.gu8tf.8.40xlarge，开通2台。扩容需提前报备锁定。 > 人工智能平台PAI的日志投递到日志存储SLS，包括DSW、DLC等日志。 > 开通ARMS-Prometheus，提供AI资源全链路可观测和多维度分析，开箱即用的内置大盘和告警规则。 > 基于云原生API网关提供统一网关服务，提供AI内容安全保障和模型灰度调度等。 > 架构参考CADT大模型标准模版，完成设计和参数调整，并整体校验和批量部署。 # 云产品列表 专有网络VPC，交换机、弹性公网EIP，NAT网关，机器学习PAI，PAI工作空间，资源配额，PAI资源组，GPU节点，对象存储OSS，日志SLS，灵骏安全组、 Prometheus、云原生API网关、云速搭CADT。 # 06MCP网关最佳实践 # 云原生API网关 - MCP 网关架构 # 传统业务0代码改造转换为MCP Server # 将SSE转换为Streamable HTTP # 后端服务 三方服务 Git服务 邮件服务 天气服务 地图服务 搜索服务 ·· # 企业服务 HTTP Service gPRC Service 企业MCP Server MCP Server # 解决客户痛点 MCP范式默认的传输协议是SSE（Server Sent Event），本质上是一种长连接，有状态的传输协议。这种协议在企业级应用中有很多弊端： > 不支持可恢复性（Resumability）：连接断开后，客户端必须重新开始整个会话。 $\succ$ 服务器需要维持长期连接（High Availability Requirement）：服务器必须保持高可用性，以支持持续的 SSE 连接。 > SSE仅支持服务器 $\rightarrow$ 客户端消息，无法灵活进行双向通信。 > 目前只有少数几个C/S架构的客户端和MCP提供的用于测试验证的Web客户端支持MCP范式和SSE协议。无法用在企业级的生产应用中。 # Streamable HTTP 优势 更灵活：支持流式传输，但不强制。 更易用：支持无状态服务器。 > 更兼容：适用于标准 HTTP 基础设施。 简单来说，原来的MCP传输方式就像是你和客服通话时必须一直保持在线（SSE需要长连接），而新的方式更像是你随时可以发消息，然后等回复（普通HTTP请求，但可以流式传输）。 # MCP模式下的身份认证和权限管控 # MCP模式下数据权限管控方案示例 # 07 MSE Nacos MCP Server 注册中心最佳实践 # Nacos开源社区发展情况 2018年孵化并开源以来，共收获28.4K的star数，12.4K的Fork数，Nacos被评为2021GitHub年度全国社区活跃度第六，在开源中国发布的2021年度OSC中国开源项目评选中，Nacos被评为云原生领域人气指数Top5的项目、InfoQ2022年度十大开源新锐项目、2023开放原子基金年度生态开源项目、2023开源创新榜“优秀开源项目”、编程夏令营GLCC2023优秀社区。《Nacos架构与原理》20w+阅读，5.5w+下载，阿里云藏经阁累计下载第四名。 国内首选， $50\%$ +国内市场份额，被头部企业广泛使用！ 中国活跃度排名 Top30 <table><tr><td></td><td>repo_name</td><td>activity_score</td><td>actor_num</td><td>IssueCommen</td></tr><tr><td>0</td><td>PaddlePaddle/Paddle</td><td>6490.893754947870</td><td>5756</td><td>18979</td></tr><tr><td>1</td><td>ant-design/ant-design</td><td>6429.396422527120</td><td>86368</td><td>13139</td></tr><tr><td>2</td><td>pingcap/tidb</td><td>4504.277250498670</td><td>4807</td><td>60968</td></tr><tr><td>3</td><td>apache/flink</td><td>3812.1036709421400</td><td>4724</td><td>13676</td></tr><tr><td>4</td><td>PaddlePaddle/PaddleOCR</td><td>3461.304851224500</td><td>12519</td><td>8103</td></tr><tr><td>5</td><td>alibaba/nacos</td><td>3340.324913238220</td><td>9188</td><td>6504</td></tr></table> Nacos作为中国开源，在领域内github收藏超过Consul、Eureka，社区在持续壮大。 # Google Analytics（分析）首页 用户 会记 会话时长 158万 436万 40.98% 5分02秒 ↑52,700,200.0% ↑62,347,142.9% . ↓65.4% 2018年7月1日-2022年3月23日 受众群体概览 $\frac{1 + u}{7} = {70}\%$ Star History # Nacos 适用场景 AI领域-MCP Server 统一管控 MSE Nacos 常见的使用场景 # Nacos - MCP Register 应用0代码改动，Nacos提供服务Endpoint以及服务Tools Prompt，基于MCP网关（云原生API网关）转换MCP协议。 # AI配置实践（Nacos：动态更新提示词数据） # MCP 安全性保障 MCP范式下有多个环节需要做安全性保障。 # MCP 效果验证体系 MCP Server 被 AI Agent 集成后，Agent 是否能精准触发工具需要验证，需要一套调用验证体系。 # 08 SAE 部署 Dify 最佳实践 # Serverless应用引擎 SAE 产品架构 集成融合云原生：K8s、Serverless、ARMS、MSE等优势技术，对用户提供全托管、简化维护、面向应用的容器使用平台。 极简体验：秒级创建应用、0改造迁移完成容器化 弹性效率优化：百毫秒级资源弹性，WEB应用支持缩容到0 业务场景 Web应用 PHP Python Go # 微服务应用 SpringCloud Dubbo SpringBoot # Job任务 XXL-Job Elastic-Job K8s Job # 集成&开发者工具 端云联调 Jenkins 云效 Terraform Cloud Toolkit CLI Serverless 应用引擎 (SAE) 应用管理 > 生命周期管理：创建、部署、启停、回滚、升级、HPA 扩缩容+定时 多发布策略：单批、分批、金丝雀 $\succ$ 多种部署源：源代码、代码包、镜像 全套微服务治理 > 服务注册发现、分布式配置管理 无损上下线、限流降级 全链路灰度、服务鉴权 同可用区路由优先 运维配套&企业级增强 百毫秒--秒级自动弹性、闲置计费 > 一键启停环境、端云联调 > 事件中心、应用可观测 > 权限隔离/审批 平台提供的 K8s 集群（全托管、高可用、弹性扩缩） 阿里云安全沙箱容器 2.0 IaaS资源层（神龙+ECI+VPC+...） Kubectl-sae SDK/OpenAPI # SAE托管Dify的核心价值 # Serverless 应用引擎（SAE）托管 Dify 方案优势 # 简单易用 > 一分钟创建Dify应用，无需任何额外配置 默认集成全链路监控，保证系统稳定性 无需关系底层资源，按需弹缩资源 # 稳定高可用 配置化，支持三AZ部署，默认支持智能化可用区，实例粒度的自动化迁移 默认支持负载均衡与健康检查联动保证无损上下线 # 低成本 按需按量付费，潮汐流量弹性使用，无需冗余保证资源 支持多种规格资源，并提供闲时计量资源类型，提供更低成本的算力 # 安全保障 > 全链路提供防护策略：Ddos防护，Web防护墙，流量防护，云安全中心。 VPC 内独立部署，数据不出安全域，保证数据绝对安全 # 持续迭代 SAE 默认具备灰度发布，分批发布，镜像加速，Pod粒度监控，保证Dify进行安全二次开发 Dify 版本更新快，通过SAE可安全兼容升级。 # 基于SAE快速部署Dify SAE 提供了 Dify 应用模板，可以一键拉起 Dify 应用，并且提供可视化构建的能力，可以对 Dify 里的每一个环节进行单独调整。 终端用户浏览器 $\succ$ 定时调度 > 监控告警 执行记录保留2个月，且无性能影响 支持时间区间、状态等多种查询条件 > 操作级别精细化权限管理 支持应用限流、Token限流 支持失败自动重试 # 开源Dify调度方面的痛点 > 执行记录过多会导致慢查询。执行历史记录存储在数据库中，数量太多会影响Dify性能，导致慢查询。 > 执行记录查询不支持条件过滤。比如通过时间区间查询，通过任务状态查询，这些都是通用的需求，但开源Dify都不支持。 $\succ$ 没有报警监控。任务调度系统需要监控工作流的执行状态，工作流运行失败，需要报警给对应的负责人，开源无报警监控能力。 # MSE 任务调度方案的优势 用户在MSE任务调度中配置Dify的Endpoint，MSE任务调度通过Dify API拉取工作流应用。 用户通过MSE任务调度配置定时调度和报警监控。 Dify工作流定时调度的时候，MSE任务调度通过Dify提供的API调度用户的Dify应用，并且实时拉取执行结果和详情，存储在MSE的AI任务调度中。 > 通过AI任务调度做报警监控、可观测增强。 # 09 函数计算 FC 快速构建 MCP Server # 函数计算FC产品架构 函数计算 业务侧关注 平台侧提供 业务代码 开发者工具 NEXT.Js django Express JS Flask springVue.js ThinkPHP 触发器 HTTP触发器 Open API/SDK 定时触发器 Event Bridge MNS Kafka MQTT Dev Ops RocketMQ ALB OSS SLS Table Store CDN 运行时 Python .Net Core Node.js Go Java PHP MCP运行时 自定义镜像 实例类型 CPU实例(百毫秒弹性) GPU实例秒级弹性） 资源调度 弹性伸缩 负载均衡 流量控制 消息缓存 高可用部署 跨集群容灾 多租户隔离 基础设施 神龙服务器 安全容器 网络通信 OSS存储 安全 应用中心 经典案例库 应用模板库 快速上生产 任务编排 CloudFlow 可观测 标准日志（SLS） 监控告警（云监控） 性能监控（ARMS） 成本管家 操作审计 # MCP Server on FC 复用高性能能力 # 云原生 API 网关 + 函数计算 > 深度集成：云原生API网关和函数计算做了深度集成，在云原生API网关侧可以快捷选择函数作为网关后端服务。 > 更高保障的流量入口：云原生API网关默认3AZ部署架构，具备多AZ高可用能力。CLB，NLB支持动态绑定，增加面对网络故障时的逃逸能力。 > 更强的管控能力：云原生API网关具备路由级别的管控能力，灰度策略，流控策略，安全策略，权限策略，灵活的插件机制等。 使用场景：对流量入口稳定性要求高，对请求有更细粒度的管控需求场景。 # 函数计算 HTTP 触发器 > 最快捷路径：使用函数计算HTTP触发器是构建HTTP请求场景的最快捷路径。 $\succ$ 较低时延：因为少了一跳，所以使用函数计算HTTP触发器的请求时延相对比较低。 成本较低：函数计算HTTP触发器本身是没有额外费用的，不需要引入额外的组件。 $\succ$ 使用场景：对请求控管要求不高，成本相对比较敏感的场景。 # MCP Server on FC 可观测体系 # Tracing # 代码链路 Java语言：借助ARMS能力，在ARMS控制台查看业务代码级链路 非Java语言：借助链路追踪能力，在链路追踪控制台查看业务代码级链路 # 牛周刊 实例初始化耗时 实例冷启动 代码初始化 代码执行 实例释放 深度集成链路追踪 链路追踪（XTrace） # 代码链路 Java语言：借助ARMS能力，在ARMS控制台查看业务代码级链路 非Java语言：借助链路追踪能力，在链路追踪控制台查看业务代码级链路 调用链总次数 Timeline视图 调用链响应时间 各接口耗时 方法栈剖析 方法类型占比分析 线程剖析 # 深度集成阿里云应用监控 应用监控（ARMS） # Metrics # 函数指标 调用次数 错误次数 流控次数 执行耗时 执行时延 内存情况 按量实例量 预留实例量 请求积压 # # Logging # 实例指标 单实例多请求数 内存使用情况 vCPU使用情况 内存使用率 vCPU利用率 实例运行状态 网络流量 深度集成云监控 云监控 # 基础监控 CPU使用率 内存使用率 系统负载 网络流量 # 应用监控 总请求量 应用实例数 FullGC 上下游服务 平均RT 异常数 慢SQL . 深度集成阿里云应用监控 应用监控（ARMS） 云监控 深度集成云监控 Java函数 Python函数 NodeJS函数 Go函数 微服务应用 单体应用 Web应用 多语言应用 内置日志标准输出SDK 在控制台查看实时日志 自动采集进SLS 使用高级查询方式查看日志 自动采集进SLS 高级查询方式查看日志 日志投递到阿里云Kafka 结合ELK套件管理日志 控制台查看临时日志 （最新500条日志） 深度集成SLS 日志服务（SLS） 深度集成SLS 阿里云Kafka ELK套件 # 10 AI应用可观测体系 # AI 应用可观测体系 # 为 GenAI 应用可观测而生 # 阿里云 ARMS LlamaIndex LangChain # 可观测链路追踪 OpenTelemetry 版 Dify Spring AI Alibaba # Open AI # 通义干问 # OpenTelemetry GenAI 语义约定 # 持续剖析 # 阿里云OTelPython发行版 # 稳定性 # 阿里云OTel Java发行版 # LLM SDK # 阿里云 Go 探针 遵循最新OpenTelemetry社区GenAI语义约定。 > 支持常见的AI框架和AI模型，包括Spring AI Alibaba / LLamaIndex / Langchain / 通义千问2 / OpenAI / PromptFlow等。 相比社区规范提供更加精细化的埋点和属性。 支持在不同的调用链中传播会话信息。 # 大模型应用专属分析视图 RAG过程观测 提示词输入、输出观测 > Token 消耗观测 # 11 AI 应用开发新范式对企业的影响 # 高德业务投放平台 Serverless 实践（API First架构） 上一代架构 客户端太重 业务紧耦合 研发迭代慢 资源成本高 Serverless 架构 # MCP Server First 奥运会官方云服务合作伙伴