企业官网建设流程全解析

宛城区网站制作,wordpress 不发邮件,部门定制网站建设公司,免费技能培训在哪里报名本文提供了一个全面的视角#xff0c;来看待如何利用模型上下文协议#xff08;MCP#xff09;实现 AI 应用新架构设计体系的落地实现#xff0c;核心内容主要是以下5点#xff1a; MCP 概念与机制。MCP 与 Function Calling 区别。MCP 本质与挑战#xff1a;挑战包括系统…本文提供了一个全面的视角来看待如何利用模型上下文协议MCP实现 AI 应用新架构设计体系的落地实现核心内容主要是以下5点MCP 概念与机制。MCP 与 Function Calling 区别。MCP 本质与挑战挑战包括系统提示词的准确性、Client 与 Server 协同、快速构建 Server、自建 Dify 的痛点等。解决 MCP 挑战的方法通过 MCP Register、统一管理 Server 和 Prompt、建立效果验证体系与安全保障、设置 MCP 网关、动态服务发现、Streamable HTTP、弹性效率、可观测等手段解决。AI 应用架构设计新范式MCP 推动 AI 应用架构向新范式发展并通过 Server First 理念提升应用性能和用户体验。下面详细介绍之。—1—AI Agent 现状与架构AI 大模型在商业领域的应用正成为推动创新和效率提升的核心力量。其关键在于多个AI Agent 的协作这些 AI Agent 通过分工与合作共同承载 AI 应用所支持的业务需求。这种协作模式不仅优化了企业运营还展现了 AI 在解决高影响力挑战中的潜力。目前 AI Agent 与各种 Tools业务服务接口、Memory存储服务接口以及 LLMs大语言模型的交互主要通过 HTTP 协议实现。除了 LLMs 基本遵循 OpenAI 范式外与其他 Tools 和 Memory 的交互需要逐一了解它们的返回格式进行解析和适配这增加了开发的复杂性。当一个 AI 应用包含多个 AI Agent或者需要与多个业务服务接口和存储服务接口交互时开发工作量显著增加主要体现在以下三个方面第一、寻找合适的接口寻找三方服务接口。在公司内部寻找合适的服务接口。如果找不到就需要自行开发接口。第二、解析接口返回格式无论是三方服务接口还是公司内部的服务接口返回格式可能千差万别需要逐一了解和解析。第三、编排多个 AI Agent使用如 Dify 这类流程可视化的工具辅助编排虽然减轻了一些工作量但复杂度依然较高且在运行效率和性能方面存在瓶颈。通过编码方式编排比如使用 Spring AI Alibaba 或 LangChain 等虽然性能更优但复杂度更高编排效率和灵活性不足。因此目前许多 AI应用只包含少数几个 AI Agent甚至很多应用背后只有一个 AI Agent。这也是目前 AI 应用背后的 AI Agent 仍处于第一阶段Siloed, Single-Purpose Agents的原因。为了使 AI Agent 进入第二阶段Platform-Level Agents我们使用云原生 API 网关作为统一的接入层通过网关的三种不同角色解决了部分复杂度问题第一、作为南北向流量网关统一管理 AI Agent 的入口流量核心功能包括转发、负载均衡、鉴权认证、安全和流控等。第二、作为 AI 网关代理各类 LLMs向 AI Agent 屏蔽了繁杂的接入并解决了许多生产级问题比如多模型切换、模型 Fallback、多 API Key 管理、安全和联网搜索等。第三、作为东西向网关统一管理来自不同源ACK、ECS、函数计算FC、SAE、三方服务的各类服务供 AI Agent 使用。然而上述方法仅解决了部分复杂度问题更核心的寻找接口和解析接口的问题仍未得到解决。直到 MCPModel Context Protocol的出现我们看到了真正通往第二阶段Platform-Level Agents的道路甚至有望触及第三阶段Universal Agents, Multi-Agents。—2—MCP 架构设计剖析1、MCP 是什么MCP模型上下文协议Model Context Protocol是由AnthropicClaude 的开发公司开发的开源协议旨在为大语言模型LLM提供一种标准化的方式以便它们能够连接到外部数据源和工具。它就像是 AI 应用的“通用接口”帮助开发者构建更灵活、更具上下文感知能力的 AI 应用而无需为每个 AI 模型和外部系统组合进行定制集成。MCP 的设计理念类似于 USB-C 端口允许 AI 应用以一致的方式连接到各种数据源和工具如文件、数据库、API 等。MCP 包含三个核心概念第一、MCP Server基于各语言的 MCP SDK 开发的程序或服务。它通过某种机制将现有的程序或服务转换为 MCP Server使其能够与 AI 应进行交互。第二、MCP ToolMCP Tool 属于 MCP Server一个 MCP Server 可以有多个 MCP Tool。可以将其理解为一个类中有多个方法或者一个服务中有多个接口。第二、MCP Client当一段代码、一个 AI Agent 或一个客户端基于 MCP 的规范去使用或调用 MCP Server 中的 MCP Tool 时它就被称为 MCP Client。2、MCP 的运作机制要真正理解 MCP我们需要深入其运作机制这不仅能揭示 MCP 调用方式与传统 HTTP 调用方式的差异还能让你明白为何 MCP 能够助力 AI Agent 迈向第二阶段。以开发一个获取时间的 AI Agent 为例用户只需提问“现在几点了”即可。假设我们已有一个处理时间的 MCP Server其中包含两个 MCP Tool一个用于获取当前时区另一个用于获取当前时间。基于 MCP 的调用过程分为六个核心步骤第一、用户提问用户向 AI Agent 提问“现在几点了”。此时AI Agent 作为 MCP Client将用户问题连同处理时间的 MCP Server 及 MCP Tool 信息一并发送给 LLM。第二、LLM 推理LLM 接收到信息后根据用户问题和 MCP Server 信息筛选出最合适的 MCP Server 和 MCP Tool 来解决问题并将结果反馈给 AI AgentMCP Client。LLM 返回的信息可能是“使用 time MCP Server 中的 get_current_time MCP Tool它能解决用户的问题。”第三、调用 MCP ToolAI AgentMCP Client依据 LLM 的建议调用 time MCP Server 中的 get_current_time MCP Tool获取当前时间。第四、返回结果time MCP Server 将当前时间的结果返回给 AI AgentMCP Client。第五、内容规整AI AgentMCP Client将用户问题和从 time MCP Server 获取的结果再次提交给 LLM请求 LLM 结合问题和答案规整内容。第六、最终反馈LLM 将规整后的内容返回给 AI AgentMCP ClientAI Agent 再将结果原封不动地返回给用户。在整个 MCP 调用过程中MCP Server 及 MCP Tool 的信息至关重要。从第一步和第二步可以看出这些信息为 LLM 提供了解决问题的关键线索。这些信息本质上就是 MCP 中的 System Prompt其核心作用是为 LLM 提供清晰的指导帮助其更好地理解用户需求并选择合适的工具来解决问题。3、MCP System PromptMCP模型上下文协议与传统协议定义不同它并没有固定的数据结构。其核心在于通过自然语言清晰地描述 MCP Serve r和 MCP Tool 的功能及作用让大语言模型LLM通过推理来选择最合适的 MCP Server 和 MCP Tool。因此MCP 的本质仍然是提示词工程Prompt Engineering。以下是一些关键的示例和步骤解析第一、 MCP ClientCline中的 System PromptCline 是一个 MCP Client其 System Prompt 对 MCP Server 和 MCP Tool 都有明确的描述。比如它会详细说明每个 MCP Server 的功能以及其中包含的 MCP Tool 的作用。这种描述为 LLM 提供了足够的上下文使其能够理解每个工具的用途。上图告诉 LLM告诉 LLM 你有一堆工 具可以用。告诉 LLM 每次你只能选一个工具用。告诉 LLM 工具是通过 XML 描述定义的。并详细描述了 XML Tag 的定义。并给出了样例。本质就是告诉 LLM 你选择完后该返回什么样的格式。上图告诉 LLM向 LLM 解释了什么是 MCP。对每个 MCP Server 和 MCP Tool 做了详细描 述。包括传参格式。第二、流程第一步发送问题和 System Prompt在调用流程的第一步用户的问题如“现在几点了”和 System Prompt 一起被发送给 LLM。System Prompt 的作用是为 LLM 提供清晰的指导帮助其理解用户问题的背景和可用的工具。第三、流程第二步LLM 返回解决方案在第二步LLM 根据用户问题和 System Prompt 中的信息推理出最合适的 MCP Server 和 MCP Tool并返回明确的解决方案。比如LLM 可能会返回“使用 time MCP Serve r中的 get_current_time MCP Tool 来解决用户的问题。”并以 XML 格式 返回给 Client/Agent。通过这种方式MCP 利用自然语言描述和 LLM 的推理能力动态地选择和调用最适合的工具从而实现灵活且高效的 AI 应用开发。4、MCP 与 Function Calling 区别通过前面的介绍相信大家对 MCP 有了清晰的认识。MCP 是否解决了找接口和解析接口的问题呢答案是肯定的。因为这两个任务都交给了 LLM大语言模型来完成。第一、LLM 负责为 AI Agent 找到最合适的接口。第二、AI Agent 调用接口时无需解析返回结果而是将结果原封不动地交给LLM。第三、LLM 结合用户问题和接口返回的结果进行内容规整处理。那么MCP 与 LLM 的 Function Calling 有什么区别呢核心区别在于是否绑定特定的模型或模型厂商第一、MCP 是通用协议层的标准类似于“AI 领域的 USB-C 接口”定义了 LLM 与外部工具/数据源的通信格式但不绑定任何特定模型或厂商。它将复杂的函数调用抽象为客户端-服务器架构使得不同模型和工具之间的交互更加灵活和通用。第二、Function Calling 是大模型厂商提供的专有能力由大模型厂商定义不同厂商在接口定义和开发文档上存在差异。它允许模型直接生成调用函数触发外部 API依赖模型自身的上下文理解和结构化输出能力。例如LLM Function Calling 需要为每个外部函数编写一个 JSON Schema 格式的功能说明并精心设计一个提示词模板才能提高 Function Calling 响应的准确率。如果一个需求涉及几十个外部系统那么设计成本将是巨大的产品化成本极高。而 MCP 统一了客户端和服务器的运行规范并且要求 MCP 客户端和服务器之间也统一按照某个既定的提示词模板进行通信。这样通过 MCP 可以加强全球开发者的协作复用全球的开发成果降低开发成本提高开发效率。5、MCP 的本质与挑战通过前面的讨论我们可以总结 MCP模型上下文协议的本质MCP 并非一个固定的数据格式或结构而是系统提示词与 MCP Server 和 LLM 之间协同关系的结合。它通过自然语言描述 MCP Server 和 MCP Tool 的功能让 LLM 能够推理出最适合的工具来解决问题从而解决了找接口和解析接口的问题。然而将 MCP 引入企业级生产应用时会面临诸多挑战第一、描述 MCP 信息的系统提示词的挑战系统提示词的安全性系统提示词是 MCP 的核心如果被污染LLM 可能会被误导选择错误甚至存在安全漏洞的 MCP Server 和 MCP Tool从而导致整个 MCP 流程瘫痪给 AI 应用带来巨大风险。系统提示词的管理当 MCP Server 或 MCP Tool 更新时系统提示词也需要相应地进行版本管理以确保 LLM 能够获取最新的工具信息。系统提示词的调试与实时生效系统提示词没有标准定义每个企业都可以自定义模板。由于提示词需要反复调试因此需要一种机制能够快速调整并实时生效。系统提示词的 Token 消耗如果 MCP Server 和 MCP Tool 数量众多系统提示词会变得非常长消耗大量 Token增加成本。因此需要一种机制基于用户问题预筛选 MCP Server 和 MCP Tool 的范围减少 Token 消耗提高效率。第二、MCP Client 与 MCP Server 之间协同关系的挑战MCP Client 的稀缺性目前市面上的 MCP Client比如Cline、Claude、Cursor 等数量有限且大多基于 C/S 架构仅支持 SSE 协议。这种有状态的协议存在诸多弊端比如不支持可恢复性、服务器需维持长期连接、仅支持单向通信等难以与企业级 AI 应用结合。现存业务的转换难题开发 MCP Server 依赖于特定语言的 MCP SDK 目前仅支持 Python、Java、TS、Kotlin、C#。对于使用 Go 或 PHP 等其他技术栈的企业转换为 MCP Server 的工作量巨大且不现实。MCP Server 的统一管理企业可能拥有自建的 MCP Server、第三方的 MCP Server 以及通过某种机制转换而来的 MCP Server。需要一个类似 MCP Hub 或 MCP 市场的平台来统一管理这些 Server方便 MCP Client 使用。企业级应用中的安全与权限问题在企业级应用中身份认证、数据权限和安全防护是关键问题。在 MCP 的协同模式下如何实现这些功能是亟待解决的挑战。总之尽管 MCP 为 AI 应用开发带来了灵活性和效率提升但在企业级应用中仍需克服系统提示词的安全性、管理、调试以及 MCP Client 与 MCP Server 之间的协同关系等多方面的挑战。—3—AI 应用架构设计新范式为了解决 MCP 在企业级应用中面临的诸多挑战对 AI Agent 的架构进行了深度重构。通过在云原生 API 网关和注册配置中心 Nacos 中引入 MCP 增强能力成功解决了大部分挑战点。同时分别针对快速开发 MCP Server 和提升开源 Dify 性能的问题提供了有效解决方案。这些举措共同构建了一个基于 MCP 的 AI 应用开发新范式推动了 AI 应用的高效开发与部署。云原生 API 网关与 Nacos 的 MCP 增强通过这两个产品的增强能力解决了系统提示词的安全性、管理、调试以及 MCP Client 与 MCP Server 之间的协同关系等核心挑战。云原生 API 网关提供了强大的流量管理和安全防护功能而 Nacos 则在服务发现和配置管理方面发挥了关键作用确保了 MCP Server 和 LLM 之间的高效协同。通过这些增强能力的实现解决了 MCP 在企业级应用中的关键挑战。3.1、AI 应用架构新范式剖析AI 应用架构结合 MCP我们定义了 AI 应用架构的新范式。一个云原生 API 网关三种角色具备统一的管控底座同时又实现各角色的协同调度。Nacos 发挥注册中心优势增加 MCP Server 的注册能力实现普通服务和 MCP Server 的统一管理结合网关实现现存业务0改造转换为 MCP Server。以下是对图中8步核心调用链路的解析第一步用户请求用户向 AI 应用发起请求请求流量首先进入流量网关云原生 API 网关。第二步请求转发云原生 API 网关维护管理不同类型的 AI Agent 的 API 或路由规则将用户请求转发至对应的 AI Agent。第三步获取 MCP 信息AI Agent 在需要获取数据时向 MCP 网关云原生 API 网关请求获取可用的 MCP Server 及 MCP Tool 信息。第四步 LLM 交互可选MCP 网关可能维护大量 MCP 信息借助 LLM 缩小 MCP 范围减少 Token 消耗向 AI 网关云原生 API 网关发请求与 LLM 交互。第五步返回 MCP 信息MCP 网关将确定范围的 MCP Server 及 MCP Tool 信息列表返回给 AI Agent。第六步发送至 LLMAI Agent 将用户请求信息及从 MCP 网关获取的所有 MCP 信息通过 AI 网关发送给 LLM。第七步 LLM 推理LLM 经过推理返回解决问题的一个或多个 MCP Server 和 MCP Tool 信息。第八步调用 MCP ToolAI Agent 拿到确定的 MCP Server 和 MCP Tool 信息后通过 MCP 网关对该 MCP Tool 发起请求。在实际生产中步骤3至8会多次循环交互。基于 MCP 的两个本质——系统提示词和 MCP Server 与 LLM 之间的协同关系我们可以深入剖析这个新架构。3.1.1、MCP RegisterMCP Server 注册中心在 MCP Server 和 MCP 提示词的统一管理方面借鉴了微服务领域中 Nacos 的服务注册发现和配置统一管理的模式并将其应用于 MCP 范式。以下是这些概念之间的对应关系SpringCloud 服务/Dubbo 服务/Go 服务 → 各类 MCP ServerSpringCloud 服务/Dubbo 服务/Go 服务暴露的接口 → 各类 MCP Server 提供的 MCP ToolSpringCloud 服务/Dubbo 服务/Go 服务暴露的接口描述 → 各类 MCP Server 提供的 MCP Tool 的描述SpringCloud 服务/Dubbo 服务/Go 服务的配置文件 → 各类 MCP Server 的系统提示词基于这些对应关系在 Nacos 产品中实现了一系列增强 MCP 的能力。通过这些增强Nacos 成为了统一管理 MCP Server 的 MCP RegisterMCP Server 注册/配置中心成为 AI 应用开发新范式的核心组件。第一、MCP Server 统一管理MCP Server 注册到 Nacos 有两种方式手动创建在 Nacos 控制台手动创建将 MCP Server 的 Endpoint 配置到 Nacos 中。自动注册通过 Nacos SDK 自动将 MCP Server 注册到 Nacos逻辑与当前 Java SpringCloud、Java Dubbo 服务类似。在 Nacos 中对 MCP Server 进行统一管理可以实现以下功能健康检查监控 MCP Server 的健康状态。负载均衡合理分配流量提高系统稳定性。描述信息转换支持从 JSON 到 XML 的格式转换。上下线管控灵活控制 MCP Server 的上线和下线。第二、MCP Prompt 统一管理在 Nacos 中维护 MCP Server 的 Prompt 有两种方式手动创建手动创建 MCP Server 的配置信息配置文件的 Data ID 命名格式为 [MCP Server name]-mcp-tools.json。在配置文件中管理 MCP Tool 的提示词信息比如整体作用描述、入参描述等。自动感知结合治理能力如果是Java或Go语言可以自动感知服务的 Schema自动生成 MCP Server 和 MCP Tool 的提示词信息。通过 Nacos 对 MCP Server 提示词进行统一管理可以实现以下功能版本管理支持版本回滚确保系统稳定运行。灰度管理支持灰度发布逐步推广新版本。安全管理确保提示词的安全性防止被污染或篡改。动态调优支持动态调整提示词实时生效提高系统灵活性。第三、MCP 效果验证体系当 MCP Server 数量较多时描述信息会变得复杂导致 Prompt 过长消耗大量 Token降低 LLM 推理效率。因此需要一种机制基于用户输入缩小 MCP Server 范围减少 Token 消耗提高推理效率。此外提示词的好坏需要多次调试MCP 流程强依赖提示词工程。如果提示词调整不当LLM 无法返回准确的 MCP Server 和 MCP Tool整个流程将无法使用。在 Nacos 中构建一个 MCP 效果验证体系。核心原理是提供一个基于 Spring AI Alibaba 开发的 AI Agent通过用户配置的业务输入、LLM、圈定的 MCP Server 和 MCP Tool 集合进行验证并将结果以视图形式展示如成功率等。用户可以在 Nacos 中动态调整成功率低的 MCP Server 的提示词进行优化。第四、MCP 安全性保障在企业生产中安全性始终是第一位的MCP 领域也不例外。需要考虑的环节更多包括敏感信息安全管理注册到 Nacos 的 MCP Server 可能包含 API Key、AK/SK、密钥、登录密码等敏感信息。Nacos 与阿里云 KMS 深度集成对这些敏感信息进行加密处理。Prompt 安全管理同样依托于 Nacos 与 KMS 的深度集成对 MCP Server 和 MCP Tool 的完整 Prompt描述信息进行加密处理防止 Prompt 被污染。Prompt 安全校验结合验证体系和内容安全集成实现 Nacos 对 MCP Server Prompt 的合法性校验确保系统安全运行。通过以上措施Nacos 不仅实现了 MCP Server 和 MCP Prompt 的统一管理还构建了效果验证体系和安全保障体系为 AI 应用开发提供了高效、灵活、安全的开发环境。3.1.2、如何解决 MCP Client 与 MCP Server 之间协同关系的挑战在 MCP 范式中主要涉及三个角色之间的协同工作MCP Client与 LLM 交互发起请求并接收响应。LLM处理 MCP Client 的请求推理并选择合适的 MCP Server 和 MCP Tool。MCP Server提供具体的工具和功能执行实际的任务。MCP Client 与 LLM以及MCP Client 与 MCP Server之间的协同关系本质上是服务提供方与服务消费方之间的关系。这涉及到两个核心点代理协作和流量管控。在传统的开发范式中这些功能通常由网关来负责。因此我们在云原生 API 网关中增强了 LLM 代理和 MCP Server 代理的能力使其具备了流量网关、AI 网关LLM 代理和 MCP 网关的功能。这使得云原生 API 网关成为 AI 应用开发新范式的核心组件。在企业的整体系统架构中通过使用云原生 API 网关可以实现流量网关、API 网关、微服务网关、AI 网关和 MCP 网关的功能。这不仅在代理和流量管控层面实现了传统业务和 AI 业务的统一还通过结合 AI 应用开发的新范式平滑地将 AI 业务与传统业务相结合。这种整合方式极大地简化了企业的技术栈提高了系统的灵活性和可维护性同时也降低了开发和运维的复杂性。第一、云原生 API 网关云原生 API 网关在业界得到了广泛应用众多业务深度依赖其强大的企业级产品能力、稳定性和性能。因此云原生 API 网关的可靠性和高效性就变得极其重要。第二、AI 网关MCP Client 与 LLM 之间的交互以及传统业务与 LLM 之间的交互本质上都面临一系列共性问题。这些问题在应用生产环境中尤为突出具体如下成本平衡问题部署大语言模型比如DeepSeek R1 671B 满血版需要高昂的成本至少需要2台8卡 H20 机器年度费用超过100万元且其 TPS 有限难以满足多用户并发请求。即使是 Meta 新发布的 Llama4也需要至少一张 H100 显卡来运行。因此需要找到 TPS 与成本之间的平衡点。模型幻觉问题即使是性能强大的 DeepSeek R1 671B 满血版模型在没有联网搜索的情况下也会出现严重的幻觉问题。多模型切换问题单一模型服务存在较大风险和局限性比如稳定性风险以及无法根据不同业务消费者需求选择最优模型。目前缺乏开源组件和框架来解决这类问题。安全合规问题企业客户需要对问答过程进行审计以确保合规并降低使用风险。模型服务高可用问题当自建平台性能达到瓶颈时需要一个大模型兜底方案以提升客户对大模型的使用体验。闭源模型 QPS/Token 限制问题商业大模型通常基于 API Key 维度设置 QPS/Token 配额限制需要一种有效方式快速扩展配额限制。这些问题都是客户在实际使用过程中遇到的有些源于大模型自身特性有些则是部署架构导致。如果让客户逐一解决这些问题不仅复杂度高而且时间成本也很大。因此需要 AI 网关的介入以快速、统一地解决这些核心问题。云原生 API 网关的 AI 网关增强能力主要体现在以下四个方面多模型适配能够代理市面上所有主流的模型托管服务以及兼容 OpenAI 协议的 AI 服务。该模块包括协议转换、多 API Key 管理、Fallback、多模型切换等多个核心功能。AI 安全防护安全防护涵盖三个层面输入输出的内容安全防护、保护下游 LLM 服务的稳定以及管控 AI 接口消费者。该模块包括内容审核、基于 Token 的限流降级、消费者认证等多个核心功能。AI 插件AI 网关的灵活扩展机制通过插件形式实现目前提供许多预置插件用户也可以开发自定义插件来丰富 AI 场景流量的管控。比如基于 AI 插件机制实现了结果缓存、提示词装饰器、向量检索等能力。AI 可观测AI 场景的可观测性与传统场景有很大区别监控和关注的指标也不同。云原生 AI 网关结合阿里云日志服务和可观测产品实现了贴合 AI 应用业务语义的可观测模块和 AI 观测大盘支持 Tokens 消费观测、流式/非流式的 RT、首包 RT、缓存命中等可观指标。同时所有输入输出 Tokens 都记录在日志服务 SLS中可供用户进行更详细的分析。第三、MCP 网关在 MCP 范式下MCP Client 与 MCP Server 之间的交互模式与传统的服务提供者和服务消费者模式有所不同。为了更好地支持这种交互模式在云原生 API 网关中增加了 MCP 相关的能力。尽管从产品版本划分层面这些能力仍然属于 AI 网关的范畴但它们专门针对 MCP 场景进行了优化。MCP Server 动态发现在前面的内容中提到 Nacos 作为 MCP Server 的注册和配置中心。那么MCP Client 如何发现这些注册的 MCP Server 呢如果让 MCP Client 直接与 Nacos 交互就需要在 MCP Client 中引入 Nacos SDK这无疑会增加编码的复杂度。鉴于云原生 API 网关和 Nacos 在传统服务领域已经实现了深度集成能够自动发现注册在 Nacos 中的服务我们在 MCP 范式下也实现了云原生 API 网关自动发现注册在 Nacos 中的 MCP Server 的能力。通过这种方式MCP Client 只需使用云原生 API 网关的接入点即可自动、动态地获取所有注册在 Nacos 中的 MCP Server。云原生 API 网关MCP 网关变成了一个 MCP Hub无论 MCP Server 如何更新或变更只需在 Nacos 中操作即可MCP Client 无需做任何修改。传统服务零代码改造为 MCP Server在 AI 时代最有价值的是使用 AI 增强和提升客户的现有业务而不是完全重新开发一套 AI 应用。因此在开发 AI 应用或进行现有业务的 AI 增强时AI Agent 需要与大量现有业务进行交互。虽然 MCP 提供了统一的协议但将现有业务重构为 MCP Server 的成本非常高且目前支持的开发语言有限像 Go 和 PHP 都没有对应的 MCP SDK。这使得许多企业虽然想拥抱 MCP但却无从下手。网关最擅长的是协议转换。Nacos 在传统微服务场景下已经注册了许多现有服务因此我们将两者结合起来通过网关将注册在 Nacos 中的现有服务零代码改造为 MCP Server。注册在 Nacos 中的现有业务服务比如SpringCloud 服务、Dubbo 服务、Go 服务无需做任何改变。在 Nacos 中新增 [Server Name]-mcp-tools.json 命名规范的配置文件在配置文件中使用 MCP 规范对现有业务的接口进行描述。通过云原生 API 网关MCP 网关MCP Client 侧自动发现由传统服务转换而来的 MCP Server。将 SSE 转换为 Streamable HTTPMCP 范式默认的传输协议是 SSEServer Sent Event本质上是一种长连接、有状态的传输协议。这种协议在企业级应用中存在许多弊端不支持可恢复性Resumability连接断开后客户端必须重新开始整个会话。服务器需要维持长期连接High Availability Requirement服务器必须保持高可用性以支持持续的 SSE 连接。SSE 仅支持服务器→客户端消息无法灵活进行双向通信。目前只有少数几个C/S架构的客户端和 MCP 提供的用于测试验证的 Web 客户端支持 MCP 范式和 SSE 协议无法应用于企业级的生产应用中。幸运的是MCP官方也意识到了这个问题并在3月下旬发布了新的 Streamable HTTP 协议。Streamable HTTP 改变了 MCP 的数据传输方式使协议更加灵活、易用和兼容更灵活支持流式传输但不强制。更易用支持无状态服务器。更兼容适用于标准 HTTP 基础设施。简单来说原来的 MCP 传输方式就像你和客服通话时必须一直保持在线SSE 需要长连接而新的方式就像你随时可以发消息然后等待回复普通 HTTP 请求但可以流式传输。这里可以思考一下Streamable HTTP 打破了目前几个 C 端 MCP Client 的壁垒意味着任何请求方甚至是一段简单的 HTTP Request 代码都可以像请求标准 HTTP API 一样与 MCP Server 交互。换句话说当可以使用标准 HTTP API 的方式与 MCP Server 交互时所谓的 MCP Client 可能就不存在了。尽管 Streamable HTTP 仍在草案阶段但云原生 API 网关作为 MCP 网关已经支持将 SSE 传输协议自动转换为 Streamable HTTP 传输协议。也就是说通过云原生 API 网关MCP 网关代理的 MCP Server 同时支持 SSE 和 Streamable HTTP 两种传输协议供 Client 使用。MCP 模式下的身份认证和权限管控身份认证和权限管控在任何架构和业务场景下都是刚需MCP 范式也不例外。这里有两个层面的权限管控Client 有权使用哪些 MCP ServerClient 有权使用哪些 MCP Server以及有权使用某 MCP Server 中的哪些 MCP Tool。Client 通过 MCP Tool 有权获取哪些数据当 MCP Server 是数据类服务时权限会下探到库级别、表级别。MCP Server 和 MCP Tool 的使用权限当传统业务可以零代码转换为 MCP Server 后注册在 Nacos 中的 MCP Server 和 MCP Tool 肯定会有很多。从业务领域来说可能有与财务相关的 MCP Server、与销售相关的 MCP Server、与售后服务相关的 MCP Server等。在返回 MCP Server 和 MCP Tool 信息时不可能将所有信息都返回只能返回 Client 身份有权使用的 MCP Server 信息。云原生 API 网关作为 MCP 网关通过成熟的插件机制提供了 HTTP Basic Auth、OAuth2.0、JWT、API Key、外部认证等多种认证方式以及基于消费者认证功能让用户可以灵活地管理和控制 Client 的身份认证和 MCP Server/MCP Tool 的使用权限。MCP Server 和 MCP Tool 的数据权限当 MCP Server 是数据类服务时权限会下探到库级别、表级别。在这种场景下云原生 API 网关作为 MCP 网关可以通过插件机制改写或增加 Request Header 的值结合治理将 Header 的值透传下去然后在服务内部进一步做数据权限管控。比如通过这种方式可以实现如下图的数据库读写分离的场景。3.1.3、如何快速构建 MCP Server在 AI 应用中涉及 LLM 推理的场景通常调用频率较低属于稀疏调用场景。由于 MCP 范式强依赖 LLM 推理无论是基于 HTTP API 的传统 AI 应用开发架构还是基于 MCP 的新架构目前都主要应用于这些稀疏调用场景。这引发了两个关键问题在稀疏调用场景下如何优化运行 MCP Server 的计算资源利用率实现成本最优在新的业务中如何快速构建 MCP Server在所有计算产品中函数计算FC这种 Serverless FaaS 类型的计算产品在资源粒度、弹性策略、弹性效率方面最适合稀疏调用场景。第一、函数计算FC支持 MCP 运行环境阿里云函数计算FC目前支持 Python 和 NodeJS 两种语言的 MCP 运行环境其他语言的 MCP 运行环境也将很快支持。用户选择 MCP 运行环境创建函数后只需编写 MCP Tool 的业务逻辑无需考虑如何使用 MCP SDK。此外云原生 API 网关与函数计算FC深度集成天然适配 AI 应用开发的新范式。第二、MCP Server 的弹性效率基于函数计算FC构建的 MCP Server 在弹性效率方面有显著优势主要体现在两个维度1、资源规格细粒度管控函数计算FC提供从 0.05C 128MB 到 16C 32GB 的多种实例规格用户可以根据不同 MCP Server 承载的业务灵活选择合适的资源规格。在 AI 应用中尤其是流程式构建的模式中大多数 AI Agent 的职责单一计算逻辑简单因此可以用较小资源规格的函数承载。较小的资源规格在资源调度和弹性效率方面具有天然优势。2、完全按请求弹性函数计算FC的弹性机制完全基于请求根据 QPS 自动拉起对应数量的实例且实例可以复用。当 QPS 下降时空闲实例会自动释放整个过程无需用户介入。此外用户还可以设置按时间定时弹性或按指标阈值弹性策略进一步满足复杂多变的业务场景实现资源成本最优。第三、MCP Server 的可观测性函数计算FC具备完善的可观测体系这意味着基于函数计算FC构建的 MCP Server 同样具备指标、链路、日志三个维度的可观测能力。通过这套可观测体系用户可以清晰地了解每个 MCP Server 的各类运行状态从而更好地管理和优化 MCP Server 的性能和成本。通过函数计算FC的这些特性企业可以高效地构建和管理 MCP Server优化资源利用率降低成本同时快速响应业务需求提升 AI 应用的开发和部署效率。3.1.4、AI 应用可观测体系结合阿里云可观测产品 ARMS 和链路追踪 OpenTelemetry我们构建了覆盖 AI 应用全环节的可观测体系。这一体系的构建主要围绕两个核心部分展开数据采集和数据串联与分析。第一、观测数据采集数据采集的核心是覆盖足够广泛的范围这主要体现在两个层面1、编程语言和开发框架的支持支持范围广支持 AI 应用开发的主流编程语言比如Python、Java、Go并且相比社区规范提供更加精细化的埋点和属性。框架支持支持常见的 AI 框架和模型包括 Spring AI Alibaba、LLamaIndex、Langchain、通义千问2、OpenAI、PromptFlow 等。2、云产品数据上报标准统一AI 应用架构新范式中涉及的云产品需要以相同的标准上报数据。网关支持云原生 API 网关支持 OpenTelemetry 协议网关自身和插件都会基于 OpenTelemetry 上报观测数据。深度集成函数计算 FC 和 Serverless 应用引擎 SAE 均与应用监控 ARMS 以及链路追踪 OpenTelemetry 产品深度集成。通过以上措施我们实现了数据采集的全覆盖确保了可观测体系的完整性。第二、数据串联与分析在应用监控 ARMS 中专门构建了 LLM 应用监控模块为 AI 应用场景提供了完善的可观测体系。这一模块从纵向和横向两个维度提供了丰富的监控指标和分析功能。1、纵向指标在线 AI 应用数Trace 数Span 数大模型数Token 使用情况会话数用户数模型调用次数Token 消耗情况模型调用耗时Token 消耗排行2、横向链路分析Span 列表展示每个 Span 的详细信息。Trace 列表提供完整的 Trace 记录。散点图通过散点图分析性能分布。全链路聚合对整个调用链进行聚合分析。全链路拓扑展示调用链的拓扑结构。错/慢 Trace 分析分析错误和慢 Trace 的原因。调用链展示在调用链的每个环节展示输入、输出和 Token 消耗情况。通过这些功能用户可以清晰地了解 AI 应用的运行状态快速定位问题优化性能确保 AI 应用的稳定运行。—4—AI 应用架构设计新范式对企业的影响随着企业级 AI 应用架构新范式的逐步成熟企业的运营、产品、研发、运维团队之间的组织结构和协作关系以及应用或系统的开发模式都将迎来一系列变革。以下是我的一些畅想第一、MCP Server First 理念的兴起API First 与前后端分离API First 和前后端分离的概念在海外企业中得到了较好的实践但在国内的应用相对较少。这可能是因为国内企业面临着较重的历史包袱难以快速转型。Serverless 架构的实践在 Serverless 计算领域AWS Lambda、Azure Functions、Azure App Service、GCP CloudFunction 和 GCP CloudRun 等架构方案已被广泛研究和应用。然而在国内除了高德等少数企业通过函数计算重构系统实现了 API First 和前后端分离模式外大多数企业仍处于探索阶段。第二、AI 应用时代的变革API 调用的本质在 AI 应用时代尽管本质上依然是对各种 API 的调用但将 HTTP API 改为 REST API 的改造成本巨大。MCP 的出现为这一问题提供了新的解决方案使得企业能够以0代码的方式快速转型到 AI 应用架构新范式。MCP Server First 的可能性MCP Server First 理念的提出意味着企业可以将更多的精力放在构建和维护 MCP Server 上而无需过多关注统一返回格式和开发语言的统一。第三、团队角色的重新定义运维团队负责云产品的维护比如云原生 API 网关、Nacos、Serverless 应用引擎、PAI 等产品的开通和升配以及可观测体系的维护。运维团队还将与云厂商保持持续沟通确保系统的稳定运行。研发团队专注于理解公司业务的原子化能力负责构建 MCP Server 池。研发团队将更加专注于后端服务的开发和优化而无需过多关注前端展示逻辑。运营/市场/产品团队通过低代码可视化方式构建业务流程业务编排用大白话描述业务需求快速完成业务流程的搭建或 AI 应用的构建。这些团队将更加专注于业务逻辑的梳理和需求的快速实现。第四、未来展望企业级 MCP Server市场未来每个企业都可能拥有自己的 MCP Server 市场。在这个市场中MCP Server 将被分门别类每类 MCP Server 由专门的研发团队负责。这种模式将极大地提高开发效率减少重复工作。业务需求的快速实现当运营、市场、产品等业务方有新的业务需求或产品功能需求时可以通过统一界面快速构建 AI 应用。MCP 和 LLM 的结合将实现业务编排推动“PRD 即产品”PRD as a Product的新开发模式。第五、总结企业级 AI 应用架构新范式的出现不仅为企业的技术转型提供了新的思路也为团队协作和开发模式带来了新的变革。通过 MCP Server First 理念的实践企业可以更加高效地构建和维护 AI 应用提升整体运营效率。未来随着技术的不断发展和成熟企业级 AI 应用架构将更加灵活、高效和智能。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线互联网企业工作十余年里指导过不少同行后辈。帮助很多人得到了学习和成长。我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限很多互联网行业朋友无法获得正确的资料得到学习提升故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…学习是一个过程只要学习就会有挑战。天道酬勤你越努力就会成为越优秀的自己。如果你能在15天内完成所有的任务那你堪称天才。然而如果你能完成 60-70% 的内容你就已经开始具备成为一名大模型 AI 的正确特征了。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】