使用 agentgateway 在 Solo.io 上协调 MCP和 LLM流量

来源: 未知
作者: Lin Sun
原文链接: https://aaif.io/blog/use-agentgateway-to-mediate-mcp-and-llm-traffic-at-solo-io/

（注：原文链接标题可译为“使用 AgentGateway 在 Solo.io 中介 MCP 与 LLM 流量”，但链接本身不翻译。）

  • Lin Sun

    Head of Open Source, Solo.io

    Lin is Head of Open Source at Solo.io and co-chair of KubeCon + CloudNativeCon 2026. She is an active contributor to AAIF working groups and CNCF projects. She is the author of the books Sidecar-less Istio Explained and AI Agents in Kubernetes and holds more than 200 patents.

*

Since last year, we have created several open source projects: agentgateway, kagent, agentregistry, and agentevals. We also donated agentgateway, kagent, and agentregistry to vendor-neutral foundations under the Linux Foundation. These projects were not built for experimentation alone. They were driven by real internal needs as we improved operational efficiency with agentic AI at Solo.io and for our users.

In this blog, I share how we use the gateway pattern to govern, secure, and observe traffic from our AI agents to MCP servers and LLMs using agentgateway, without requiring modifications to the agents or MCP servers.

Governing Traffic from Internal Agents to MCP Servers

We have developed multiple MCP servers to support our internal AI agents. For example, our support agent allows employees to ask questions in our corporate Slack by mentioning @Support. The agent can access MCP tools to search our internal Slack conversations,  query our codebase, interact with internal tools, and retrieve information from documentation and GitHub issues. It returns answers along with confidence estimates.

As the number of MCP servers grows, we needed a simple way to aggregate them behind a single interface. Agentgateway enables this through configuration alone, without requiring code changes or redeployments.

Multiplexing MCP Servers

Multiplexing is achieved by configuring multiple MCP backends behind a single listener. For example, the configuration below exposes multiple stateless MCP services as a unified virtual MCP server on port 3000:– 

</a>

<a href="https://aaif.io/author/lin-sun/ "Lin Sun"">Lin Sun</a>

Solo.io 开源负责人

Lin 是 Solo.io 的开源负责人，也是 KubeCon + CloudNativeCon 2026 的联合主席。她是 AAIF 工作组和 CNCF 项目的活跃贡献者。她著有《Sidecar-less Istio Explained》和《AI Agents in Kubernetes》两本书，并拥有 200 多项专利。

*

自去年以来，我们创建了几个开源项目：agentgateway、kagent、agentregistry 和 agentevals。我们还将 agentgateway、kagent 和 agentregistry 捐赠给了 Linux 基金会下的供应商中立基金会。这些项目并非仅为实验而构建。它们源于我们在 Solo.io 及为用户提升运营效率时，使用 agentic AI（智能体 AI）所面临的真实内部需求。

在这篇博客中，我将分享我们如何使用网关模式，通过 agentgateway 来治理、保护和观测从 AI 智能体到 MCP 服务器（MCP servers）和 LLM（大语言模型）的流量，而无需修改智能体或 MCP 服务器。

治理从内部智能体到 MCP 服务器的流量

我们开发了多个 MCP 服务器来支持内部 AI 智能体。例如，我们的支持智能体允许员工在企业 Slack 中通过提及 @Support 来提问。该智能体可以访问 MCP 工具，搜索内部 Slack 对话、查询代码库、与内部工具交互，并从文档和 GitHub issues 中检索信息。它会返回答案以及置信度估计。

随着 MCP 服务器数量的增长，我们需要一种简单的方法将它们聚合在单个接口之后。Agentgateway 仅通过配置即可实现这一点，无需代码更改或重新部署。

多路复用 MCP 服务器

多路复用是通过在单个监听器后面配置多个 MCP 后端来实现的。例如，下面的配置将多个无状态 MCP 服务暴露为端口 3000 上的统一虚拟 MCP 服务器：

`
config:
 port: 3000
binds:
– listeners:
 – routes:
   – backends:
     – mcp:
         statefulMode: stateless
         targets:
         – mcp:
             host: http://docs.mcp.svc.cluster.local:3003/mcp
           name: knowledge-base
         – mcp:
             host: http://slack.mcp.svc.cluster.local:8000/mcp
           name: slack-conversations
         …
     matches:
     – path:
          exact: /mcp
`

Auth and Policy Enforcement（认证与策略执行）

添加身份验证或超时策略无需修改每个 MCP 后端服务器，也无需在应用程序代码中配置超时、JWKS、受众或资源元数据，更无需重新构建或重新部署服务。

借助 agentgateway，这些关注点通过配置集中处理，而 MCP 服务器保持不变。以下示例为 support agent 的 MCP 后端配置了超时以及 MCP 身份验证策略：

`
policies:
timeout:
requestTimeout: 300s
backendRequestTimeout: 300s
mcpAuthentication:
mode: strict
issuer: https://auth-mcp.example.com
jwks:
url: https://auth-mcp.example.com/.well-known/jwks.json
audiences:
– https://agent-tools.example.com/mcp
resourceMetadata:
resource: https://agent-tools.example.com/mcp
scopesSupported:
– read:all
bearerMethodsSupported:
– header
– body
– query
resourceDocumentation: https://agent-tools.example.com/docs
resourcePolicyUri: https://agent-tools.example.com/policies
`

通过这种设置，我们的内部代理（agents）和工程师都可以通过指向多路复用端点（multiplexed endpoint），经由 Claude 或 Cursor 安全地访问 MCP 服务器。例如，Cursor 中一个简单的 mcp.json 文件即可用于配置对所有 MCP 服务器的访问：

`
{
“mcpServers”: {
“soloio-mcp”: {
“url”: “https://agent-tools.example.com/mcp”
}
}
}
`

可观测性（Observability）：日志与指标（Logs and Metrics）

我们还使用 agentgateway 在不修改 MCP 后端（MCP backends）的情况下增加可观测性。例如，我们丰富指标（metrics）以识别每个工具调用关联的用户和产品：

`
config:
metrics:
fields:
add:
product: ‘default(json(request.body).params.arguments.product, “not-applicable”)’
`

这使我们能够分析工具使用分布（tool usage distribution），并更好地理解我们的内部代理（internal agents）随时间推移如何使用工具。以下是支持代理（support agent）的工具使用示例：

可观测性中日志与指标统计图

Govern Traffic to LLMs（管理LLM流量）

Our internal AI usage has grown rapidly, especially with coding agents like Claude Code and Cursor.

我们内部AI的使用量增长迅速，尤其是像Claude Code和Cursor这样的编码代理（coding agents）。

Initially, engineers accessed Anthropic models through Vertex AI, but we lacked visibility into usage patterns and per-user, per-model costs. By routing LLM traffic through agentgateway, we gained the ability to track usage and spending at both individual and organization levels. This helps us decide when subscription models make more sense than pay-as-you-go usage models.

最初，工程师通过Vertex AI访问Anthropic模型，但我们缺乏对使用模式以及每个用户、每个模型成本的可见性。通过将LLM流量路由到agentgateway，我们获得了在个人和组织层面追踪使用情况和支出的能力。这有助于我们判断何时订阅模式比按需付费模式更合理。

Track Usage and Cost for Each Person（追踪每个人的使用情况和成本）

模型路由与转换流程示意图

模型路由与转换关系示意图

By adding metrics and logs in agentgateway configuration, we can correlate telemetry with each user’s email to understand LLM model usage and cost per user:

通过在agentgateway配置中添加指标和日志，我们可以将遥测数据与每个用户的电子邮件关联起来，从而了解每个用户的LLM模型使用情况和成本。

`
config:
 metrics:
   fields:
     add:
       user_email: “jwt.email”
       solo_org: ‘request.headers[“x-solo-org”]’
frontendPolicies:
 accessLog:
   add:
      user_email: “jwt.email”
`

Authentication（身份验证） and Authorization（授权） for LLM（Large Language Model） Access

我们严格执行身份验证，并仅允许经过验证的Solo.io用户访问大语言模型。

`
llm:
policies:
jwtAuth:
mode: strict
issuer: https://accounts.google.com
audiences:
– “111111111.apps.googleusercontent.com”
jwks:
url: https://www.googleapis.com/oauth2/v3/certs
authorization:
rules:
– ‘jwt.email.endsWith(“@solo.io”) && jwt.email_verified == true’
`

这些策略适用于通过 Vertex AI 访问的所有 LLM 模型。

模型路由与转换（Model Routing and Transformation）

Agentgateway 还支持动态模型选择与转换。例如，以下是一个简单的路由配置，适用于通过 Vertex AI 使用模型的工程组织。在此配置中，agentgateway 会根据请求确定实际使用的模型，无论是 Google 模型还是合作伙伴模型（如 Opus 4.7 或 Sonnet 4.6）。

`
models:
# Sepparate orgs with different projects and headers
– name: “*”
provider: vertex
matches:
– headers:
– name: “X-Solo-Org”
value:
exact: “engineering”
transformation:
model: |
request.path.endsWith(“:streamRawPredict”) || request.path.endsWith(“:rawPredict”) ?
request.path.regexReplace(“^./publishers/anthropic/models/(.+?):.“, “$${1}”) :
llmRequest.model
params:
vertexProject: developers-369321
`

通过 agentgateway（代理网关）提供的指标，我们可以在 Grafana 仪表板中可视化按组织划分的 token 使用量（token usage），以及每个模型的 token 使用量。

我们还可以轻松查看每个用户在任何时间窗口内每个模型的 token（代币）使用量。

模型路由与转换机制说明图

最终思考

在 Solo.io，我们专注于效率与持续创新，并坚信智能体 AI（agentic AI）在改变工作方式中扮演着关键角色。Agentgateway 帮助我们以对智能体（agent）和后端服务透明的方式治理并优化 MCP 与 LLM 流量，无需对 MCP 服务器或 LLM 进行任何修改。这种关注点分离为我们提供了一条更清晰的路径，能够安全且可预测地扩展智能体工作负载。

展望未来，我们期待进一步推动这一网关模式，并探索：

  • MCP 工具的细粒度授权，实现对智能体可访问和执行内容的更精确控制
  • 通过搜索与执行逐步暴露 MCP 服务器，使智能体能够动态发现能力，而非依赖静态配置
  • 代码执行模式，减少智能体与 MCP 工具之间的来回交互，提升效率与响应质量

如果你已经采用了智能体网关，我很想听听你的经验。如果你尚未采用但正计划引入，我鼓励你探索 agentgateway 项目，并随时向社区提问！

标签

相关文章

实时焦点

软件供应链安全：开源生态的隐形防线（2025年度“上海硅巷创新说 ”）
会员喜讯｜睿赛德科技RT-Thread操作系统成功入选上海市重点推荐目录
上海开源信息技术协会受邀成为“中华武数”科创集市战略合作伙伴
『开源开放·上海声音』2020开源技术开源商业学术研讨会成功举办