Agent Mesh for Enterprise Agents

Source | HN Comments

文章提出了“agent mesh”的概念，旨在解决企业级agent在安全性、可观察性、发现和治理等方面的挑战。 agent mesh通过agent gateway实现，该网关作为数据平面，支持agent到LLM、agent到工具以及agent之间的通信，并提供身份验证、授权、细粒度访问控制、端到端可观察性等功能。文章强调了agent mesh在构建智能、自治的企业系统中的重要性，并介绍了其组件的可组合性以及对各种agent和云环境的支持。

企业级 Agent 的 Agent Mesh 方案

从大型机到微服务，企业不断演进其软件架构，以满足日益增长的可扩展性、灵活性和适应性需求。如今的现实要求不仅仅是分布或分解。在一个实时市场变化和不断提高的客户期望的世界中，企业需要能够自行推理、适应和行动的系统。这就是 agentic systems 的承诺。这个承诺带来了对基础设施，特别是网络基础设施的期望的深刻转变。

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

什么是 Agent Mesh

我们相信，构建和部署 agentic 系统的企业将需要解决常见的安全性、可观察性、租户隔离和防护措施问题。 Agent mesh 利用 agent gateway（一种专为这些用例定制的数据平面），为企业 agent 部署（自建、SaaS、开发者工具，如 Cursor 等）一致地解决这些挑战。

Agent mesh 在以下三个主要交互中一致地解决了 AI 特定的网络挑战：

Agent 到 LLM 通信
Agent 到工具 / MCP
Agent 到 Agent / A2A

一个 agent mesh 具有以下属性：

默认安全：Agent 身份、mTLS 和可插拔身份验证（OIDC、API keys 等）
Layer 7 原生：支持 agent-to-agent (A2A) 和 model control plane (MCP) 通信
细粒度访问控制：所有 agent 和工具交互的授权控制
端到端可观察性：LLM、agent 和工具的统一跟踪
注册和发现：运行时 agent/工具注册和查找
弹性和安全性：防护措施、工具投毒防护和租户隔离
现代运维模型：声明式配置和 GitOps 工作流程

Agent mesh 使用专门的、高性能的数据平面，即 agent gateway，该数据平面已经过调整和优化，以适应 AI 通信模式。

让我们深入了解 agent mesh 的细节。

控制 Agent 到 LLM 的通信

Agent 经常与 LLM 交换敏感的 prompt 和 payload——客户数据、访问令牌、内部文档——并且这些流量不应直接通过网络传输或绕过企业策略。这就是 agent gateway 必须充当“LLM gateway”的地方。它可以根据对 prompt 的语义理解来强制执行策略，例如防护措施、缓存和故障转移。它还可以按用户、租户或 agent 进行基于令牌的速率限制和使用情况跟踪。跟踪哪些调用被发送到 LLM（以及返回了哪些响应）至关重要。跟踪诸如消耗的令牌数量、触发的防护措施和检测到的故障转移之类的指标对于支持企业可观察性是必要的。

‍

对于由 GPU 支持的自托管推理后端（即，AI 模型），agent gateway 也可以做出明智的决策。它可以使用实时遥测数据将 prompt 路由到最佳可用模型，同时考虑诸如 GPU KV 缓存、工作队列深度、adapter 部署和关键性之类的指标。 Gateway API 的推理扩展指定了一个用于执行此操作的 API。

使用企业工具启用 Agent

如果没有访问工具，Agent 个体无法做有趣的事情。将 LLM 连接到工具是一个非常开放的问题，最近已通过 Model Context Protocol (MCP) 解决。 MCP 解决了描述工具、将其暴露给 agent 以及允许以一致的方式（协议）调用它们（无论支持工具是什么——数据库、API、文件系统、SaaS 等）的问题。 MCP 的挑战在于，它是 RPC 通信的一个很好的基础，但它缺乏企业就绪性。安全性、发现、注册、租户隔离和可观察性都被排除在协议之外。由于 agent 根据工具的名称和描述选择工具，因此对这些工具的语义理解和防护至关重要。忽略这一事实可能会导致严重的安全问题。

‍

基于 Multi-Agent 任务的工作流程

构建 agent 的挑战不仅仅在于使它们变得聪明——还在于针对它们要处理的特定工作流程进行合理调整。赋予单个、单体的 agent 访问过多工具或职责的权限通常会导致 agent 混乱。 Agent 将产生幻觉、偏离任务或完全失败。相反，我们发现组织从与明确界定的目标或任务对齐的更小、更专注的 agent 中获益更多。但是，增加 agent 的数量会带来复杂性。 Agent 可能需要通信。我们如何确保可观察性、可追溯性和安全交互——诸如身份验证、授权和行为防护措施之类的事情？

Google 最近宣布了一项用于 agent-to-agent 通信的新规范，称为 A2A 协议。该规范定义了 agent 如何声明其能力和技能来协调任务、获取任务更新以及执行任务，而无论用于构建它们的基础框架如何。该协议通过 Agent Cards 发布 agent 的技能和能力，这些 Agent Cards 在运行时可被发现，并且包含用于调用特定 agent 的技术和语义细节。虽然该规范提到了传输安全性和可观察性，但它有意将这些内容保留在核心协议之外。注册、发现和路由也被排除在外。

‍

深入研究细节：保护基础

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

Agent 身份应与用户身份相结合，以强制执行细粒度的授权。所有这些流量都应通过 mTLS 进行加密保护，并植根于企业的 PKI 中。除了在 agentic 系统的防护措施中明确允许的那些通信路径之外，所有流量都应为“全部拒绝”。换句话说，agentic 系统应该建立在零信任架构之上。为了实现这一点，我们可以部署 Istio ambient mode (ztunnel)。这将为我们在 agent 和工具之间的所有调用提供基于 mTLS 的 agent 身份（无需任何特殊的库或 sidecar）。从那里，我们可以将复合身份分层以包含用户，以构建细粒度的授权。

‍

企业可能会有许多 agent，并且每个 agent 都需要访问工具。他们将需要一种以安全、可观察的方式通过防护措施注册、发现和访问这些 agent 或工具的方式。 Agent 将需要发布批准的 AgentCards 以指定其功能。

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

为了将一致的身份验证、授权和可观察性策略应用于这些协议，我们将需要一个专用的 agent 数据平面，该数据平面了解这些类型的协议。这就是 agent gateway 发挥作用的地方。 Agent gateway 的构建是为了本机理解 MCP 和 A2A 并提供以下内容：

虚拟 MCP 工具端点
身份验证
细粒度的授权（用户、机器、agent、组合等）
跟踪、可观察性（基于语义 OTeL）
Agent 路由 / 任务状态可观察性
跨多个后端 MCP 服务器的多路复用
版本管理和解耦
防护措施、防止工具投毒攻击等
管理后端 MCP 服务器或 agent 的健康状况和故障转移

‍

注册

在动态 agent 生态系统中，管理 agent 和工具的注册对于防止诸如名称冲突和工具投毒之类的问题至关重要。 Agent mesh 支持精选的注册过程，其中 agent 和工具注册有唯一的标识符和元数据，例如 AgentCards。这些 AgentCards 提供了能力的语义描述，从而促进了发现和互操作性。我们需要一种检测工具或 agent 语义能力或描述漂移的方法，以防止 prompt 注入或语义投毒。该 mesh 还必须实施验证机制来检测和防止恶意注册，从而确保系统的完整性和安全性。

跨任何云的任何 Agent

agent mesh 的一个显着优势是它能够支持各种各样的 agent——无论是自建的、现成的还是托管的——跨任何云环境。与与特定云提供商紧密集成的解决方案不同，agent mesh 提供了灵活性和互操作性，从而使企业可以集成各种 agent 类型，而无需供应商锁定。这种开放性加速了创新，使组织能够采用最适合其特定需求的工具和模型，而无论其来源或托管环境如何。

组件是可组合的

Agent mesh 的设计考虑了可组合性，从而使企业可以组装满足其独特需求的定制基础架构。它的架构支持对模型、工具和 agent 的统一和一致的访问，从而确保了无缝的集成和通信。策略实施、可观察性和防护措施在所有组件中统一应用，从而增强了安全性和合规性。专用数据平面经过了性能优化，专注于 AI 特定的通信模式。从入口到东西向流量和出口，语义理解都嵌入在每一层，从而提供智能的路由和决策能力。这种可组合的方法使企业能够构建可扩展、适应性强且安全的 agentic 系统。

结论

企业软件架构的演进需要不仅可扩展和灵活，而且智能和自治的系统。 Agentic 系统满足了这一需求，但是它们在网络、安全性和可观察性方面引入了新的挑战。 Agent mesh 通过提供强大的基础架构来解决这些挑战，该基础架构支持 agent、工具和模型之间的安全、可观察和受控的交互。借助诸如 Kagent 之类的组件以及对诸如 MCP 和 A2A 之类的协议的支持，agent mesh 使企业能够跨任何云环境利用 agentic AI 的全部潜力。通过采用 agent mesh，组织可以构建智能系统，以满足当今动态业务环境的需求。

查看 Agent Gateway 网站以了解更多信息，并加入 Discord 上的 Agent Gateway 对话。

Christian Posta

全球现场 CTO 副总裁

Christian Posta (@christianposta) 是 Solo.io 的全球现场 CTO，支持客户和最终用户采用云原生技术。他是 Manning 和 O'Reilly 出版物的作者、开源贡献者、博客作者，并且是 Envoy Proxy 和 Kubernetes 技术的追捧演讲者。在加入 Solo.io 之前，Chrisitan 曾担任 Red Hat、FuseSource 的首席架构师，并在 Wells Fargo、Apollo Group、Intel 等组织中担任工程职位。

Idit Levine

创始人兼首席执行官

Idit Levine 是 Solo.io 的创始人兼首席执行官。她创立 Solo.io 的想法是创建工具，以帮助组织在其现有 IT 投资之外有意义地采用云原生技术。 Idit 在初创公司和大型企业公司中都有着悠久的云、基础设施和开源历史。在加入 Solo.io 之前，她是 EMC 云管理部门的 CTO、全球 CTO 办公室的成员，并在 Dynamic Ops、VMware、CloudSwitch 和 Verizon 担任技术领导职务。