Buoyant 宣布 Linkerd 支持 MCP，服务网格首次接管智能体式 AI 流量

开源 Linkerd 服务网格 的幕后公司 Buoyant 宣布 Linkerd 现已支持 Model Context Protocol（MCP），成为首个原生管理、保护和观测 Kubernetes 环境中智能体式 AI 流量的服务网格。此举旨在为 AI 驱动的工作流提供稳定、安全、全程可观测的运行时，从而加速企业落地 AI——这类工作流的行为与传统 API 应用截然不同。

此次发布恰逢企业加速落地依赖 MCP 的 AI 智能体。MCP 是一种让模型通过长连接会话持续调用外部工具、数据源和上下文的协议。与传统的请求响应 API 不同，MCP 驱动的智能体式负载具有不可预测性、有状态性，并可能引发剧烈的资源消耗，给缺乏针对这种新型流量模式可视化或安全控制的组织带来了挑战。

Buoyant CEO William Morgan 指出，形势已刻不容缓：

企业渴望通过 AI 进行创新，但不能以牺牲安全态势和应用可靠性为代价。Linkerd 把沉淀多年的能力延伸到 MCP 流量……为组织提供了加速使用 AI 的信心。

Linkerd 即将推出的对 MCP 的支持将核心网格能力——包括可视化、访问控制和流量整形——引入智能体式 AI 工作流，无需额外的工具或架构变更。企业将获得关于提示词使用、延迟、失败率和资源消耗的指标，以及基于加密工作负载身份对所有 MCP 调用实施零信任访问控制。通过将这些能力嵌入网格，Buoyant 将 Linkerd 打造成传统微服务流量与新兴 AI 智能体通信的统一控制平面。

尝鲜用户表示，这填补了企业落地 AI 的缺口。Imagine Learning 高级工程师 Blake Romano 指出，最初对 MCP 安全的担忧拖慢了他们的内部推广速度。他补充说，Linkerd 现有的安全态势和可观测功能“消除了采用的主要障碍”，提供了对智能体行为的可视化，并增强了安全扩展 AI 计划的信心。

Buoyant 在最近举行的北美 KubeCon 大会（2025 年 11 月 10 至 13 日，亚特兰大）上展示了对 MCP 的支持能力。之后，该功能开始在开源 Linkerd 和 Buoyant 企业发行版中全面推出。尽管其他网格和 API 平台可以代理 MCP 流量，但目前无一将其视为一等协议，企业不得不依赖为传统无状态 API 构建的基础设施来协调 AI 智能体。

Istio 以及其他基于 Envoy 的网格（如 Kuma 和 Kong Mesh）为微服务提供了强大的安全和可观测性。然而，这些网格缺乏对 MCP 长生命周期、有状态会话的直接感知。为了管理 AI 智能体工作流，组织必须使用自定义 Envoy 过滤器或边车扩展，这增加了运维方面的复杂性，且仍无法获得对智能体行为（如提示流、会话生命周期或工具调用模式）的可视化。

理论上，Envoy 的可扩展性可以提供更深程度的 MCP 支持，但目前没有任何发行版提供开箱即用的 MCP 能力。这导致企业在安全和可观测性方面存在缺口，尤其是当 AI 工作负载生成这些网格无法处理的不可预测的流量峰值时。

HashiCorp 的 Consul 提供了强大的应用身份、服务发现和基于 ACL 的流量授权机制，但其网格功能仍以传统微服务为中心。MCP 流量被当作普通的 L4 或 L7 流量进行处理，缺少智能体状态跟踪、提示词行为测量或对模型与工具交互实施细粒度零信任策略所需的语义。因此，使用 Consul 的组织仍需使用额外的工具才能安全部署智能体式工作负载。

现代网关如 Kong、Apigee、NGINX 和 Ambassador 在管理 API 入口方面发挥着重要作用，但它们并非为 MCP 驱动的 AI 流量而设计。网关擅长保护和整形离散的 HTTP 请求，而 MCP 依赖持久会话、流式上下文和多步智能体工作流，这些可能完全绕过了网关，这限制了它们按工具授权、追踪智能体推理步骤或监控长生命周期交互中 Token 使用的能力。

通过将 MCP 直接集成到网格数据平面，Linkerd 引入了当前服务网络生态所缺失的能力，包括针对 AI 智能体调用的基于密码学的零信任机制、对提示词流和会话行为的深度可观测、针对智能体式负载突发特性设计的自适应流量整形。

【声明：本文由 InfoQ 翻译，未经许可禁止转载。】

查看英文原文：https://www.infoq.com/news/2025/11/buoyant-linkerd-mcp-support/