MCP 架构设计剖析：从 Service Mesh 演进到 Agentic Mesh 原创 精华

MCP 最近越来越火热，MCP 从架构设计的角度来看，它本质上是数据或者工具的代理层（Proxy），随着多 Agents 智能体应用在企业复杂业务场景中的落地，如何让自主 Agent 间能够相互发现、协作、互动和交易？Agentic Mesh 应运而生。而 MCP 架构正是 Agentic Mesh 的一种落地实现方式，下我详细剖析。

为了帮助大家理解 Mesh 架构的设计，我们先剖析下 Service Mesh。

1、Service Mesh 架构设计剖析

第一、Service Mesh 架构定义

微服务架构继续演进，就变成了 Service Mesh 架构（服务网格）。Servie Mesh 架构最早由开发 Linkerd 的 Buoyant 公司提出，并在内部使用。2016年09月29日第一次公开使用，2017年初进入国内技术社区视野。Service Mesh 到底是什么？我们来看看 Linerd 公司 CEO Willian Morgan 对 Service Mesh 的定义如下图所示：

Service Mesh 是一个基础设施层，用于处理服务间交互。云原生应用有着复杂的服务拓扑，Service Mesh 负责在这些拓扑中实现请求的可靠传递。在线上实践中，Service Mesh 通常实现为一组轻量级的网络代理（Sidecar 边车），它们与应用程序部署在一起，并且对应用程序透明。

如上图所示，应用程序A和应用程序B交互，请求调用关系如下：应用程序A调用本地的 Sidecar A，Sidecar A 在通过网络交互调用远端的 Sidecar B，再由 Sidecar B 把请求传递给应用程序B。请求回应关系也是类似：应用程序B调用 Sidecar B，Sidecar B 在通过网络交互调用远端的 Sidecar A，再由 Sidecar A 把请求回应传递给应用程序A。通过把服务治理功能从服务自身中物理剥离出来，下沉形成独立的进程，从而物理解耦。

在这样的架构模式下，业务应用程序再也不需要关注服务治理的功能，服务治理的功能升级也不要依赖于服务自身，从而能够让业务迭代更快速和高效。同时由于服务治理功能变成一个独立的进程，只需要使用一种语言打造即可，业务服务自身可以选择业务团队擅长的语言进行编写，从而能够真正达到马丁福勒对微服务的期望。

我们再深入分析下协议，在通信协议方面，业务应用程序和 Sidecar 的通信可以基于 TCP 长连接，也可以基于 HTTP 1.0 或者 2.0 的长连接（思考下：是否一定要使用长连接？），Sidecar 间的通信协议没有特殊要求；在数据传输协议方面，可以是 JSON／XML 等跨语言的文本协议，也可以选择 Protobuffers／MessagePack 等跨语言的二进制协议。

保证了通信协议和数据传输协议的跨语言，不同语言的应用程序就可以无缝地和 Sidecar 进行交互。在应用程序和对应的 Sidecar 部署层面，需要部署在同机（可以是同一台物理机／虚拟机，也可以是同一个Pod）。

思考下：如果部署在不同的机器上，就会又引入服务通信交互的问题，那么就会变成无解的难题：为了解决通信交互的问题，又引入新的通信交互的问题。

第二、Service Mesh 架构落地实践

在企业中落地 Service Mesh 的架构设计如下图所示：

Service Mesh 架构框架方面，业内陆续开源了不少的优秀框架，Istio 是集大成者，由 Google、IBM、Lyft 等三家公司联合打造，并已经开源，社区版本也已经发展到 Istio 1.25.0。IstioService Mesh 逻辑上分为数据面板（执行者）和控制面板（指挥者），数据面板由一组智能代理（Envoy）组成，代理部署为 Sidecar，调解和控制微服务之间所有的网络通信。控制面板负责管理和配置代理来路由流量，以及在运行时执行策略。如下图所示，控制面板（Pilot、Mixer、Citadel）加数据面板（Envoy Proxy）即是服务治理功能，svcA 和 svcB 是业务服务自身。

2、MCP：Agentic Mesh 架构设计剖析

第一、AI 大模型新时代的应用：Agent 智能体

Agent 智能体正逐渐成为企业 AI 的中流砥柱。这些数字化的“员工”能够独立完成任务、做出决策，并与其他 Agent 智能体协同工作，几乎不需要人工干预。目前面临的主要挑战包括：

• 如何构建可扩展的 Agent 系统；
• 确保 Agent 系统的安全性和可靠性；
• 实现不同 Agent 间的顺畅协作；
• 使 AI 决策与企业目标高度一致。

Agentic Mesh 被视作企业的“AI 协作平台”，它提供了一个标准化框架，使得：

• 不同功能的 Agent 能够安全高效地互联互通；
• 支持复杂业务流程的自动化处理；
• 确保整个 Agent 系统随着业务发展的灵活扩展。

这相当于为企业建立了一个“数字员工团队”，他们各司其职且紧密协作，显著提高运营效率和决策质量。

Agent 是一种能够感知环境、处理信息并执行行动以实现特定目标的系统，其主要特性包括：

• 自主性/自治性：无需直接人为干预即可运作的能力；
• 反应性：能够实时响应环境变化；
• 主动性：能够预测未来的需求并采取相应行动；
• 社交性：能够与其他个体、人类和系统进行互动与合作。

这些特性使得自治 Agent 能够推动企业环境中的自动化、优化流程和改进决策。

第二、MCP：Agentic Mesh 架构设计

Agentic Mesh 是让自主 Agent 能够相互发现、协作、互动和交易的互联生态系统。Agentic Mesh 生态系统组成包括：

• Marketplace：用户发现和使用 Agent 的主界面；
• Registry：Agent 元数据的中央存储库；
• DNS 系统：Agent 定位和连接服务；
• 自主 Agent：由 GenAI 驱动的执行实体

Agentic Mesh 包括3大核心流程：Agent 注册流程、Agent 发现流程、Agent 执行流程。

1.Agent 注册流程 

Agentic Mesh 的注册流程包括：通信 API、控制服务、元数据管理、运行时等4个模块层，详细如下：

2.Agent 发现流程

3.Agent 执行流程

为了打造一个具备弹性和可伸缩性的 Agentic Mesh，我们需要遵循以下关键原则来设计系统：

• 可发现性：Agent 必须能够动态注册、定位以及与其他相关节点进行交互。
• 互操作性：跨平台和跨 Agent 的通信必须无缝，利用开放标准，比如：API、语义本体和协议缓冲。
• 安全性和信任：必须嵌入加密方法、身份管理和访问控制，以防止未经授权的交互并确保 Agent 的完整性。
• 可伸缩性：体系结构应支持越来越多的 Agent 和任务，同时不降低性能。
• 治理和合规性：必须制定政策和执行机制，以规范 Agent 行为并确保遵从企业法规。

通过整合这些原则，组织可以构建一个模块化、有弹性的生态系统，Agentic Mesh 能够有效处理不同的企业工作负载。

AI Agent 不仅能执行预定义的任务，而且能够产生新见解、综合信息并自主地改进策略。Agentic Mesh 将在确保这些 AI 驱动的系统保持互操作性、安全性和与企业目标一致方面发挥关键作用。

为了构建 Agentic Mesh，需要实践：

• 开发标准化的 Agent协议：建立 Agent 到 Agent 通信的最佳实践。
• 实施 AI 治理框架：确保 AI 的道德使用和遵守监管准则。
• 采用混合 AI 部署策略：利用云部署、私有部署和边缘部署来实现最佳 Agent 性能。
• 多 Agent 仿真实验：在产品推出之前在沙箱环境中测试大规模的 Agent 交互。

设计这些生态系统时，首先考虑可伸缩性、安全性和治理，以确保可持续和有效的采用。通过拥抱 Agentic Mesh，企业可以释放新的效率，提高决策，并加速AI驱动的大规模创新。

然而，Agentic Mesh 的解决方案尚未经过大规模的实际考验，也未形成业界的最佳实践，需要我们去探索和实验。

最近兴起的 MCP（Model Context Protocol）是个不错的选择，本质是 Agentic Mesh 的一种架构设计和实现，它提供了一种连接 AI 应用与外部系统的开放标准，有助于推动 Agentic Mesh 的发展和实现。

总之，Data Mesh 面向的是数据产品， Servcie Mesh 面对的是服务的复杂性管理，而 Agentic Mesh 则是多 Agent 系统的一种实现方式 ，它们的架构设计理念是类似的，只不过 Agentic Mesh 仍然在实践探索之中，MCP 有望成为 Agentic Mesh 架构设计落地的一种优雅实现方案。

本文转载自公众号玄姐聊AGI  作者：玄姐

原文链接：​​https://mp.weixin.qq.com/s/AeA91tNdeRXYfjZzTqlW1g​​