适用于企业智能体的智能体网格（翻译）-CSDN博客

适用于企业智能体的智能体网格

说明

本文介绍了一个智能体网络，并且通过监测智能体网络保证安全和可观测性，发现和治理。个人感觉还是挺有意思的一个产品。所以，记录在这里。

概述

从大型机到微服务，企业不断发展其软件架构，以满足对可扩展性、灵活性和适应性日益增长的需求。今天的现实要求不仅仅是分发或分解。在市场实时变化和客户期望不断提高的世界中，企业需要能够自行推理、适应和采取行动的系统。这就是智能体系统的承诺。这一承诺伴随着我们对基础设施（尤其是网络）的期望发生深刻变化。

传统网络是围绕确定性工作流构建的，包括静态 API、可预测的服务调用和预定义路径。另一方面，智能体系统是动态的和紧急的。他们以自然语言解释用户意图，实时编排智能体和工具链，并即时做出决策。安全性、可观察性和路由不再仅与标头或 URL 有关，还与语义和上下文有关。这种转变需要一种新型的网络，一种在运行时支持智能自适应策略，并在多跳工作流中提供可观察性的网络。我们应该通过支持标准协议来适应未来的投资。这种新范式需要一个“智能体网格”，即一个平台，无论这些智能体、LLM 或工具部署在何处，都可以在所有智能体交互中实现安全性、可观察性、发现和治理。本文阐述了这一愿景，以及我们 Solo.io 如何准备提供此基础设施。

An Agent Mesh 智能体网格

我们认为，构建和部署智能体系统的企业将需要解决常见的安全性、可观察性、租户和护栏问题。 智能体网格利用智能体网关 （为这些使用案例量身定制的数据平面）始终如一地解决了企业智能体部署（自建、SaaS、Cursor 等开发人员工具）的这些挑战。

在这里插入图片描述

智能体网格在三个主要交互中始终如一地解决特定于 AI 的网络挑战：

智能体和LLM 的通信
智能体和工具的通信/ MCP
智能体和智能体之间的通信/ A2A

智能体网格具有以下属性：

默认安全 ：智能体身份、mTLS 和可插拔身份验证（OIDC、API 密钥等）
第 7 层原生 ：支持智能体到智能体（A2A）和模型控制平面（MCP）通信
精细访问控制 ：对所有智能体和工具交互的授权控制
端到端可观测性 ：跨 LLM、智能体和工具的统一跟踪
注册和发现 ：运行时智能体/工具注册和查找
弹性和安全性 ：护栏、工具中毒保护和租户隔离
现代运营模型 ：声明式配置和 GitOps 工作流

智能体网格使用专用的高性能数据平面，即智能体网关 ，该网关已针对 AI 通信模式进行了优化和优化。
让我们深入了解智能体网格的详细信息。

控制智能体到 LLM 的通信

智能体经常与 LLM 交换敏感提示和有效负载（客户数据、访问令牌、内部文档），这些流量不应直接通过网络或绕过企业策略。这就是智能体网关必须充当“LLM 网关”的地方。它可以根据对提示的语义理解来实施防护机制、缓存和故障转移等策略。它还可以对每个用户、租户或智能体进行基于令牌的速率限制和使用情况跟踪。跟踪发送到 LLM 的调用（以及返回的响应）至关重要。跟踪消耗的令牌数量、触发的防护机制和检测到的故障转移等指标对于支持企业可观测性是必要的。

在这里插入图片描述

智能体网关还可以为由 GPU 支持的自托管推理后端（即 AI 模型）做出明智的决策。它可以使用实时遥测将提示路由到最佳可用模型，同时考虑 GPU KV 缓存、工作队列深度、适配器部署和关键性等指标。Inference Extension to Gateway API 指定了用于执行此作的 API。

使用 Enterprise Tools 启用智能体

如果没有工具，智能体个人就无法做有趣的事情。将 LLM 连接到工具是一个非常开放的问题，最近通过模型上下文协议（MCP）解决了这个问题。描述工具，将它们公开给智能体，并允许它们以一致的方式（协议）调用，而不管 MCP 处理什么后备工具（数据库、API、文件系统、SaaS 等）。MCP 的挑战在于，它是 RPC 通信的良好基础，但它缺乏企业就绪性。安全性、发现、注册、租赁和可观察性被排除在协议之外。由于智能体根据其名称和描述选择工具，因此这些工具的语义理解和护栏至关重要。忽视这一事实可能会导致严重的安全问题。

在这里插入图片描述

基于多智能体任务的工作流

构建智能体的挑战不仅在于使其更智能，还在于为他们要处理的特定工作流程合理调整其规模。让单个整体智能体访问太多工具或职责通常会导致智能体混淆。特工会产生幻觉，偏离任务，或完全失败。相反，我们发现，组织从规模较小、专注的智能体中受益更多，这些智能体与明确的目标或任务保持一致。但是，增加智能体数量会带来复杂性。智能体可能需要进行沟通。我们如何确保可观察性、可追溯性和安全交互 - 例如身份验证、授权和行为护栏？

Google 最近宣布了一项用于智能体到智能体通信的新规范，称为 A2A 协议。该规范定义了智能体如何声明其协调任务、获取任务更新和执行任务的能力和技能，而不管用于构建任务的底层框架如何。该协议通过智能体卡发布智能体的技能和功能，这些智能体卡可在运行时发现，并包含用于调用特定智能体的技术和语义详细信息。虽然该规范提到了传输安全性和可观察性，但它有意将它们排除在核心协议之外。注册、发现和路由也被排除在外。

在这里插入图片描述

深入了解细节：保护基础

为了完成分配的任务，智能体将传递敏感信息、从企业 API 检索数据，并可能与客户进行沟通。虽然用户可能具有用令牌和密钥表示的身份，但智能体没有任何特定身份。这就是非人类工作负载身份变得至关重要的地方。像 SPIFFE 这样的身份框架成为基础。

智能体身份应与用户身份相结合，以实施精细授权。所有这些流量都应该使用 mTLS 进行加密保护，并植根于企业的 PKI。所有流量都应该是 “deny-all” 的，除了在智能体系统的护栏内明确允许的那些通信路径。换句话说，智能体系统应该建立在 Zero Trust 架构之上。为此，我们可以部署 Istio 环境模式（ztunnel）。这将为我们提供基于 mTLS 的智能体身份，以透明方式（无需任何特殊库或 sidecar）用于智能体和工具之间的所有调用。从那里，我们可以在复合身份上分层，以包含用户以构建精细的授权。

在这里插入图片描述

企业可能有许多智能体，每个智能体都需要访问工具。他们将需要一种方法，通过护栏以安全、可观察的方式注册、发现和访问这些智能体或工具。智能体需要发布已批准的 AgentCard 以指定其功能。

企业应通过 MCP 智能体公开 MCP 工具的精选列表，但 MCP 协议不适合使用传统的反向智能体进行智能体。传统的反向智能体是使用无状态的“一个请求到一个后端”模型构建的。MCP 既是有状态的，又允许会话处理由客户端或服务器发起的流量。由于 MCP 是有状态的，并且需要多路复用和解多路复用到智能体中，因此我们不应该试图将其硬塞到反向智能体模型中。A2A 协议也属于类似的情况。

为了对这些协议应用一致的身份验证、授权和可观察性策略，我们需要一个能够理解这些类型协议的专用智能体数据平面。这就是 Agent Gateway 的用武之地。Agent Gateway 旨在原生理解 MCP 和 A2A，并提供以下功能：