成熟工程师1天完成调试,AI工程实践被MCP彻底颠覆?: 去年 11 月,Anthropic 发布了模型上下文协议 (MCP),这是 AI 应用程序组件与外部系统或工具之间通信的新标准。开……
哈喽!伙伴们,我是小智,你们的AI向导。欢迎来到每日的AI学习时间。今天,我们将一起深入AI的奇妙世界,探索“成熟工程师1天完成调试,AI工程实践被MCP彻底颠覆?”,并学会本篇文章中所讲的全部知识点。还是那句话“不必远征未知,只需唤醒你的潜能!”跟着小智的步伐,我们终将学有所成,学以致用,并发现自身的更多可能性。话不多说,现在就让我们开始这场激发潜能的AI学习之旅吧。
成熟工程师1天完成调试,AI工程实践被MCP彻底颠覆?:
去年 11 月,Anthropic 发布了模型上下文协议 (MCP),这是 AI 应用程序组件与外部系统或工具之间通信的新标准。开发者社区迅速采用了该协议,并部署了超过 1000 个 MCP 服务器。如今,随着 AWS、GitHub 等巨头公司,甚至 Anthropic 的“竞争对手”OpenAI 也正式采用 MCP,MCP 在商业领域也获得了越来越多的关注。
MCP 标准化了数据和工具与 AI 代理的集成,这对于更快地构建 AI 应用程序非常有价值,并解释了为什么 MCP 迅速成为基于代理的 AI 系统中通信上下文的新标准。
那么,到底什么是大模型上下文协议?
为了使 AI 模型能够在编码助手、制造控制或财务报告等生产环境中提供可靠的价值,它们需要合适的环境。有效的 AI 系统能够在模型功能与相关、准确的信息(无论是来自各种企业系统的专有数据,还是来自网络搜索的最新洞察)以及能够进一步处理数据并自动化企业工作流程的代理工具之间取得平衡。
以前,这是以一种临时的、非标准化的方式完成的——但现在 MCP 提供了一种一致的结构化格式,用于与大型语言模型和其他 AI 模型进行交互,从而大大简化了构建定制化 AI 应用程序的过程。它类似于 REST API 曾经标准化 Web 服务通信方式的方式,从而实现了跨不同系统和平台的无缝集成和互操作性。
MCP 定义了清晰的模式来为模型提供上下文、管理工具使用和处理响应,使开发人员能够更快地构建更易于维护的 AI 应用程序,而无需为每个新用例重新设计实现模式。
如此重要的协议,它是如何工作的?
MCP 采用简单的客户端 – 服务器模型。像 Cursor、Claude 或 Haystack Agent 这样的 AI 应用程序充当连接到 MCP 服务器的客户端,每个服务器都通过标准化接口提供对特定工具或数据源的访问。
当 AI 应用程序需要信息或想要执行操作时,它会向相应的 MCP 服务器发送请求,该服务器处理与底层数据源或工具的交互并返回结果。这种标准化意味着任何兼容 MCP 的客户端都可以与任何兼容 MCP 的服务器协同工作,而无需任何自定义集成工作。
虽然实际文档区分了 Host 主机(AI 应用程序)和 Client 客户端(主机端一对一连接到服务器的协议适配器),但在大多数 MCP 实际讨论中,AI 应用程序本身被简称为可以连接到多个服务器的“MCP 客户端”。
在大模型技术迅猛发展的今天,MCP(Model Context Protocol) 作为一项具有里程碑意义的协议工具,正逐渐成为企业 AI 战略布局的核心。它重新定义了人机交互的方式,通过高效的架构设计,实现了高并发、低延迟的实时数据访问,为 AI 应用的落地提供了强大支撑。
那么,MCP 的核心组件有哪些?它们如何协同工作? 从 Claude 等 AI 助手、桌面端到开发工具(IDE),MCP 客户端如何与服务器高效交互?其背后的 Server 架构又是如何支撑海量请求的?更重要的是,MCP 将如何重塑行业生态,释放怎样的商业价值?
本次采访我们很容幸请到了著名的 AI 专家,华院计算智算平台负责人、技术总监杨小东先生,他将带我们深入解析 MCP 的技术架构与行业影响,帮助开发者把握 AI 时代的核心机遇。
InfoQ:MCP 的核心组件都包括什么?各个组件之间的关系是什么?(Claude 等 AI 助手、Claude 桌面端、开发工具(IDE)以及 AI 工具。它们作为 MCP 客户端,与外部服务器进行交互。
杨小东:MCP 的核心组件包括 HOST,Client 和 Server。HOST 就是我们自己要开发的 AI 应用,目前广大程序员在用的 Cursor 等,就是 HOST。它运行 LLM 并装载多个 Client 的宿主程序,如 Claude Desktop、Cursor IDE。它负责把用户请求转交给适当的 Client。Client 由 HOST 集成,与 MCP Server 建立连接,处理 JSON-RPC 2.0 消息的序列化、传输和状态管理。MCP Server 是轻量级的服务程序,一般可以暴露三类核心能力:资源、工具和提示词模板。协议层基于 JSON-RPC 2.0 定义消息格式,支持请求、通知和错误规范。传输层提供三种通信格式:Stdio、HTTP+SSE 和 Streamable HTTP。
InfoQ:MCP Server 的核心架构是怎样的,如何实现高并发、低延迟的实时数据访问?
杨小东:MCP 是典型的 CS 架构,从 HOST 与 MCP Server 的连接方式来看,又可以分为直连模式、Proxy 模式、直连 Local Server 模式等等。在 CS 架构的产品中,高并发、低延迟其实是工程师们始终面临的问题。就技术架构而言,使用线程池、异步非阻塞通信库、无锁数据结构、分布式处理等都是比较通用的处理方式。也有开发者使用 nacos 相关工具与 MCP 深度结合,解决部分易用性以及效率问题,效果也不错。MCP Server 在协议层自带并发弹性设计(无状态事件驱动、流式协议协商、工具粒度隔离等)使得它具有“协议先天友好 + 工程弹性扩展”的特性。在生产环境中,现在一般使用云原生架构,对于部署在云中的 Server,根据其实现功能的不同,配置不同的硬件资源并且通过 HPA 来应对突发流量的冲击。
InfoQ:MCP 的协议层设计是否支持跨平台(如 Web、移动端、嵌入式系统)?如何解决兼容性问题?又如何保证数据在传输和处理过程中的安全性?是否支持端到端加密?
杨小东:MCP 协议层的设计本身是支持跨平台的。在 WEB、移动端、嵌入式系统中,略微麻烦一些的应该是嵌入式系统了。移动端本身有成熟且丰富的开发库支持开发 MCP。嵌入式系统一般要采集底层的 TCP 协议来实现,带来的问题就是开发工作量大一些,处理的底层数据多一些,但实现是没有问题的。通过提供不同嵌入式系统的 SDK,可以很大程度上解决开发效率问题。
目前针对 MCP 的工具的攻击主要是 TPA(Tool Poisoning Attack),但其实本质上是利用了大模型目前的缺陷,而不是 MCP 自身的问题。为确保安全,选择安全可靠的 MCP Server 至关重要。另外,防 DNS 重绑定等方面的攻击也是重要的问题。社区正在推进 MCP-TLS 扩展草案,引入工具指纹与签名,防止恶意替换 。
对于加密,MCP 协议本身并没有强行限制,用户自己可以灵活进行扩展,采用加密算法对通信数据进行加密。
InfoQ:MCP Server 的工作之一是从相关数据源中获取所需信息,并将其返回给 AI,那 MCP 目前支持哪些类型的数据源(如 SQL/NoSQL 数据库、API、文件系统)?未来计划扩展哪些新数据源?
杨小东: 我们一直非常重要数据的采集与处理工作,目前我们的平台通过 MCP 基本可以从任意数据源中获取数据,不限于数据库、API、文件系统等,甚至可以与数仓打通。数据的获取只是解决打通问题,接下来我们会重点研究解决数据的分析问题,在打通数据源的基础上,更好地组织数据源的各类元数据,以便更好地与 LLM 配合,完成数据的高效、智能分析,目前这部分还是行业的痛点,有很大的提升空间。
InfoQ:但我们的数据源往往是形态各异的,如何解决不同数据源的协议差异(如 RESTful API vs. gRPC vs. WebSocket)?是否有统一的适配层?
杨小东: 由于各种原因,不同数据源之间存在协议差异是没法避免的事情,目前工业界常用的 IoT 数采平台也一样是要适配不同传感器的协议。对于我们而言,统一构建适配层可能是最佳实践,方便我们在过程中构建并实施自己内部的数据标准。
InfoQ:目前 MCP Server 如何处理实时数据流的增量更新(如数据库的 CDC 变更)?它在面对大规模、海量数据请求时,是否会出现性能瓶颈?有没有缓存机制或分布式部署方案?是否支持动态上下文切换,例如,根据用户请求自动选择数据源?
杨小东:处理实时数据流增量更新时 ,MCP Server 利用 subscribe 通道把 Debezium/Flink CDC 日志流封装为 JSON-RPC 通知,通过 SSE / Streamable HTTP 推送给 Host,实现毫秒级数据刷新;同时,Server 设计为无状态协程模型,前端启用 Redis 边缓存,后端通过 K8s HPA 或 FaaS 横向扩展;rate_limit 元数据确保热点资源不拖慢整体,从而保证服务器的高并发。 实际应用中,目前需要通过 MCP 来处理数据库级别的实时数据更新的情况还没有遇到,能够获取数据的实时更新,一般已经具备了很好的访问权限,解决问题的可选方式也会很多。如果需要选择 MCP 的话,可以通过与 CDC 工具、消息队列配合完成。
缓存机制或分布式部署方案:可选用 IDistributedCache 接口把 Redis/SQL Server 作为共享缓存,数据在多实例间保持一致,并能在重启后存活的方式实现分布式缓存;同时,社区已有 Redis MCP Server 与 Elasticsearch MCP Server 等专用缓存 MCP Server,把缓存命中也暴露成工具,供 LLM 显式选择读取热数据或回源查询 。关于分布式部署环节,建议 Server 保持无状态,把会话/偏移存入外部 KV 或流处理状态,便于跨可用区滚动升级 。
需要大规模、海量数据请求时,或者请求需要扫描处理后台海量数据时,性能瓶颈必然出现,这其实也是设计过程中需要尽可能规避的点。
动态上下文切换支持运行时注册工具 / 资源;Host 可根据用户意图调用 Router Tool 或自动切换到携带特定数据源的 Agent Preset,从而做到 “请求到哪、数据跟到哪”。实际应用中,更多地还是需要依赖应用端协助处理,把 MCP Server 看成一个无状态服务会更好,可以更好地将 MCP Server 与系统解耦。
与不同 AI 模型如何协作?
InfoQ:在与 AI 集成方面,MCP 如何与不同 AI 模型(如大语言模型、推理模型、多模态模型)的输入输出格式对齐?是否需要预处理器来把这些输出输入格式对齐?
杨小东: 在输入输出格式方面,目前的大模型都或多或少会出现不稳定的情况。在要求比较严格的场景中,最好通过添加预处理器来进行格式对齐,这个预处理器一般也可以使用微调好的专有大模型,可以更加稳定和准确。
InfoQ:其实我想从开发者角度问一个问题,开发者集成 MCP 的平均成本(如代码量、调试时间)是多少?
杨小东: 就拿华院计算来说,目前华院在自己的系统重也集成了 MCP,在 AI 的辅助下,集成 MCP 到现有系统重的开发成本对我们而言已经很低了,在工具的加持下,熟练的工程师 1 天就可以完成开发调试。
InfoQ:据我们了解,目前国内布局 MCP Server 的企业还是主要集中在大厂上,您对这种现状是如何看待的?
杨小东: 大厂在发展过程中集聚了大量资源,包括客户资源、技术资源等等,在行业内有足够的影响力、号召力,更有机会和能力开发出优秀的 MCP Server 并推广给全行业使用。但也不代表小企业就没有机会,小企业可以基于自身的垂类业务优势,开发细分领域的产品,华院目前就是再走垂类路线,做实际解决问题的 MCP Server,哪怕是很小的点,也是有价值的,客户也比较认可。
InfoQ:MCP 这种协议是否要满足一些合规要求?比如审计和数据隐私方面?那它在强监管的行业是否也适用?
杨小东: 如果行业本身有非常高的安全、合规等方面的要求,那么开发过程中还需要开发周边扩展的,比如为满足审计需求,开发更完善的日志系统、权限控制系统、风险管控系统等等。MCP 不是一个完全不依赖数字技术积淀的产物,所有信息化、数字化过程中积累下来的技术栈,其实都是他的助力,即便是强监管的行业,也一样是适用的。
与 LongChain 的区别是什么?
InfoQ:其实在 MCP 概念出来以前,大模型的通讯更多是靠 LangChain、LlamaIndex 等工具,那么,与 LangChain、LlamaIndex 等现有 AI 数据连接工具相比,MCP 的差异化优势是什么?
杨小东:LangChain 和 LlamaIndex 是开发人员广泛使用的 AI 应用开发库,通过他们开始快速开发 RAG 类应用、Agent 等等,能够方便地实现工具调用,但是,他们仅在 同一进程 内通过函数包装工具;并不提供 Host-Server-Tool 三层分离或互操作标准。LangChain / LlamaIndex 是 “应用内” 编排库所有的工具是集成在整个 AI 应用进程当中的,中间很重要的工具这一层其实没有被很好的单独解耦出来,实现跨进程复用。相比较而言,MCP 是跨进程的开放协议,具有开放标准、跨客户端互操作、权限模型、官方 SDK 与现有框架协同等优势。能够实现工具层彻底解耦,同时它也有着更好的安全和治理方案。这些特性使得 MCP 更轻量、更聚焦、更简单。
InfoQ: 接下来想聊聊商业化方向的问题,MCP Server 的盈利模式是什么?(如按调用次数收费、企业订阅制)?它的目标客户是 AI 开发者、企业 IT 团队还是 ISV(独立软件开发商)?
杨小东: 使用 MCP Server 跟传统的从应用市场下载 APP 有个很大的区别,就是 MCP Server 的功能相对是单一的、无法自运行的,需要一个 AI 应用,也就是 HOST 来取调用。一般强依赖提示词而无核心数据的 MCP Serve 门槛过低,变现难度比较大。具有核心能力支撑的 MCP Server,按调用次数也好、企业订阅也好,都是没有问题的,所以关键是核心能力,这是盈利的前提。
目前我们看到的 MCP Server 的主要客户还是 AI 开发者居多,需要 AI 开发者统一集成 MCP Server 到自己的应用系统中,然后提供给客户使用。
MCP 未来发展发向
InfoQ:MCP 现在基本默认为成了大模型与外部数据交互的通用协议,在技术生态上,您认为我们该如何推动其他厂商的协议兼容?
杨小东: 就技术生态而言,一种新的协议或技术能否被广泛采用,主要看两点:首先,生态是否足够健壮;其次,可用性、易用性、流行度如何。这两点基本也是相辅相成的,如果有行业的顶级玩家支持,会有效地吸引更多玩家参与,更多玩家的参与使得新技术更加完善,相关工具越来越丰富和好用,如此良性循环,带来了技术的蓬勃发展。
就 MCP 而言,核心在与能够持续推出高质量工具,这是保证其可用性、易用性的核心。推动各类传统工具、现有工具更高质量地 MCP 化,我认为是推动 MCP 发展的关键。
InfoQ:就华院计算而言,是否有计划基于 MCP 构建数据服务市场(如第三方插件生态)?
杨小东: 华院本身在基于认知智能引擎平台开发 AI 时代的数据工具,华院本身是以算法为核心的,我们同时也高度重视数据本身的价值。在大量业务的实践中,我们深刻体会到将 AI 与数据结合将会带来更多价值的涌现。所以,我们会整合不同的技术,包括 MCP,来构建我们自己的数据工具,但是否会成为数据服务市场,还需要看我们推进的节奏和效果。
嘿,伙伴们,今天我们的AI探索之旅已经圆满结束。关于“成熟工程师1天完成调试,AI工程实践被MCP彻底颠覆?”的内容已经分享给大家了。感谢你们的陪伴,希望这次旅程让你对AI能够更了解、更喜欢。谨记,精准提问是解锁AI潜能的钥匙哦!如果有小伙伴想要了解学习更多的AI知识,请关注我们的官网“AI智研社”,保证让你收获满满呦!
还没有评论呢,快来抢沙发~