为什么 LLM 追踪工具如今开始构建 AI 网关

2026 年，LangSmith、Langfuse、Opik 和 Braintrust 都在模型服务商前端新增了网关。主要原因在于控制能力：追踪工具只能记录模型调用，而网关则可以拦截调用。

各司其职的两种工具

过去两年，许多团队使用两种独立工具来运行大语言模型（LLM）应用。网关位于应用与模型服务商之间，负责保存服务商的 API 密钥、转换不同服务商的 API 调用，并重试失败的请求。LiteLLM是一款开源代理，逐渐成为这项工作的常用选择。应用旁边则运行着 LangSmith 或 Langfuse 之类的追踪工具，记录每次模型调用、工具调用和检索步骤，让工程师了解智能体执行过哪些操作。

这种分工合情合理：网关必须运行迅速，并支持每家服务商的 API；追踪工具则需要良好的界面、用于存储大型负载的空间，以及能够封装应用代码的 SDK。Langfuse 仍在文档中介绍这种双工具配置，其中的 LiteLLM Proxy 集成会将每次调用先发送到代理，再传入 Langfuse。2026 年，各家追踪工具供应商开始自行构建网关。

六个月内推出四款产品

LangChain 于 2026 年 5 月宣布推出 LangSmith LLM Gateway 私有测试版，并于 7 月 30 日开放公测，此后还将其纳入 LangSmith 的自带云部署。Braintrust 弃用了先前的 AI 代理，并引导用户改用一款新网关；该网关目前处于预览阶段，在正式推出前免费使用。Comet 发布了 Opik LLM Gateway 测试版端点，可接收 OpenAI 格式的请求。11 月 4 日，Langfuse 在 Langfuse Cloud 和自托管部署环境中开放了其 AI Gateway公测。该网关采用 MIT 许可证，并以 Rust 编写。

MLflow最初是一款机器学习生命周期工具，而非追踪工具；它推出 AI 网关的时间更早，并提供预算预警和限额功能。

网关早已存在多年，运行网关所涉及的风险也有充分记录。如今推出网关的这些公司，过去的业务是记录模型调用，而现在，它们希望每次调用都先经过自己的网关。

预算管控为何需要介入请求链路

追踪工具只能在服务商作出响应、相关令牌费用已经支付后，才记录模型调用。这些记录足以绘制支出图表，但追踪工具无法阻止支出。要执行团队预算、屏蔽某个模型，或从提示中移除机密信息，都必须在请求到达服务商之前进行检查。只有位于请求链路中的组件才能做到这一点。

LangChain 在其发布公告中阐述了这一观点。公告提到，团队会将独立网关、护栏产品和可观测性工具组合使用，并指出，要防止问题，就必须在请求层执行策略。对于可能导致超出预算的调用，其网关会返回 HTTP 状态码 402，而不是将请求转发给服务商。

通过一个入口记录每次调用

第二个原因是覆盖范围。SDK 只能记录有人添加了监测代码的执行路径。智能体的故障往往会在这些路径之外悄然发生。笔记本电脑上的脚本、笔记本环境，或使用复制来的 API 密钥的编程智能体，都不会留下任何追踪记录。持有服务商密钥的网关能够看到每次调用，因为请求没有其他途径可以到达服务商。

Langfuse 围绕这一理念构建网关。根据其网关文档，每个网关密钥都归属于某位用户或某个服务账号，并可附带团队或成本中心等元数据。只有网关持有服务商凭据，管理员则负责批准每个凭据可以调用哪些模型。LangSmith 发布了配置指南，介绍如何将 Claude Code、Codex 和 Gemini CLI 的请求路由到其网关。这些智能体会在开发者的机器上调用模型，不经过任何应用的追踪代码。

追踪工具内置网关的额外价值

追踪工具供应商也提出了相反的观点：独立网关本身并不足够。Langfuse 在发布公告中表示，独立网关只能统计令牌用量和成本，而其自有网关能将每次调用纳入完整的追踪记录。Langfuse 的网关可接收 W3C traceparent 标头，因此，经由网关发出的调用会加入应用已经启动的追踪链路。默认情况下，它会记录用量和成本，而不记录提示和响应内容。

这正是将网关集成到追踪工具中的最有力技术论据。独立网关看到的只是扁平的补全结果列表。追踪工具已经通过 SDK 获取了智能体的工具调用和检索步骤，因此可以将每次经由网关的调用纳入这一结构。

这其中还存在一种商业层面的解读，只是供应商自己不会这么说。谁来运行网关，谁就掌握服务提供商密钥和支出报告，而财务团队和平台团队关注的正是支出报告。因此，网关比链路追踪查看器更难被替换。LangSmith 和 Langfuse 已经以不同方式利用了这一优势：LangSmith 销售 Gateway Credits，客户无需提供自己的服务商密钥，就能调用 Kimi 等托管模型；而 Langfuse 的常见问题解答称，它不会转售令牌。

测试版网关目前还做不到什么

这些网关问世不久，供应商也在文档中说明了各自的不足。目前，Langfuse 的网关仅支持 OpenAI 和 Anthropic；Amazon Bedrock、Google Vertex AI 和 Google AI Studio 则列在其路线图中。跨服务提供商故障切换，以及按团队、用户或密钥设置硬性支出上限，都已列入计划，但尚未推出。目前，网关提供支出仪表板和告警功能。其文档没有提及速率限制或响应缓存。

Langfuse 网关无法在不同 API 格式之间转换，因此 OpenAI 客户端只能调用 OpenAI 模型。自托管版本只能调用服务提供商的官方 URL，因此目前无法使用 Azure OpenAI、Bedrock 或内部代理。Comet 将 Opik 网关描述为专为开发和测试而设计。Braintrust 尚未公布其网关的定价。

LangSmith 的网关目前已具备比其他网关更多的功能。其文档将故障切换、支出限额、速率限制和数据策略列为现有功能，并支持 OpenAI Chat Completions、OpenAI Responses 和 Anthropic Messages 格式。5 月时，故障切换和速率限制还被列为未来计划，因此它们是在测试期间推出的。整个产品目前仍标注为测试版。

负载测试揭示了另一类不足。一项针对 Langfuse 网关、LiteLLM 和 AcruxCore 的自托管基准测试发现，Langfuse 网关每次调用增加的延迟低于 LiteLLM。不过，使用默认 Docker 设置时，它在 1,000 条并发流中有 739 条失败，因为其进程沿用了 Docker 默认的 1,024 个打开文件限制。只需在 Langfuse 的 Compose 文件中添加一行，就解决了这个问题。

与这些测试版网关相比，多年来一直作为独立网关运行的 LiteLLM 支持 100 多家服务提供商，并已具备虚拟密钥、支出跟踪、护栏、负载均衡和管理仪表板。LiteLLM 也正在将请求处理路径从 Python 迁移到 Rust。其Rust AI 网关目前处于测试阶段，LiteLLM 团队预计，到 12 月 1 日，Anthropic 风格的 /v1/messages 请求将能够全程以 Rust 处理，延迟约降至原来的二十分之一。一些开源平台，例如 MLflow 和 AcruxCore，已经在同一款产品中同时提供网关和链路追踪功能。

将两者分开保留的理由

将网关并入链路追踪器也有代价，其中最大的问题是耦合。使用独立网关时，团队只需更换日志回调，就能更换链路追踪供应商。如果链路追踪器同时也是网关，那么每项服务的基础 URL、密钥和模型标识符也都要一并更改。例如，Langfuse 会以 credential:model 的形式写入模型标识符。

链路追踪器也会成为运行时依赖。如果链路追踪后端发生故障，团队就会丢失链路追踪数据；如果网关发生故障，模型调用就会失败。运行网关的链路追踪供应商因此必须达到关键基础设施所需的正常运行时间。

安全供应商也希望占据请求处理路径中的同一位置。Palo Alto Networks 于 2026 年 5 月完成了对独立网关 Portkey 的收购，并将其打造为 Prisma AIRS 平台的 AI 网关。安全团队可能希望由自己掌控网关，而不是将其置于可观测性工具之中。网关也已成为攻击者的目标，3 月发生的LiteLLM 供应链泄露事件便印证了这一点。

团队如何做出选择

团队可以先列出模型调用发生前必须完成的事项。如果只需要可见性，在请求处理路径之外部署链路追踪器就足够了，也不会增加运行时依赖。如果还需要预算、密钥策略或模型审批，就需要某种网关。

接下来要考虑服务提供商覆盖范围。团队应列出生产环境中调用的每一家服务提供商和每种 API 格式，包括 Azure OpenAI 和 Bedrock，并将这份清单与各网关目前实际支持的内容进行对比，而不是只看路线图。

已经在运行 LiteLLM 的团队，除非测试版网关能提供他们目前缺少的功能，否则几乎没有理由迁移。链路追踪器的网关主要增加了这样一项能力：将网关调用纳入智能体链路追踪；这必须足以证明迁移的价值。刚开始搭建系统的团队，即使由同一家供应商同时提供网关和链路追踪器，也可以将网关保留为独立层。把基础 URL 和密钥放在同一个配置模块中，意味着日后迁移时只需更改配置，无须改动代码。

这些网关大多标注为测试版或预览版，因此其不足清单很快就会缩短。尚待明确的问题是，在一般企业中，谁将负责管理请求处理路径：可观测性团队、运行独立网关的平台团队，还是安全团队？今年，LangSmith 和 Langfuse 各自构建了网关，Palo Alto Networks 也收购了一家网关厂商，但在许多技术栈中，请求处理路径仍经过 LiteLLM。