中文精炼导读
核心观点
- LangChain 发布 LangSmith LLM Gateway（先是私有 beta，2026 年 7 月 30 日起公开 beta）：一个运行时的治理层，位于 agent 与 LLM 提供商之间，在请求到达模型之前就执行成本上限与敏感数据脱敏。
- 核心差异是"从源头拦截而非事后记录"：可观测性告诉你发生了什么，而 Gateway 在问题发生前于请求层强制策略——补上了从观察到执行的缺口。
- 治理与你已有的工作流同处一地：策略违规以"可追踪事件"的形式进入 LangSmith，你可以从一条被拦截的请求点击跳转到触发它的那条 trace，再直接改 prompt 或工具配置并重新跑测试集，全程无需切换工具。
- 落地成本被刻意做得很低：把 base_url 换成 LangSmith Gateway 端点、把提供商 key 放进工作区密钥、在 UI 里设置策略，三件事就完成接入，无需单独的基础设施。
- 现有 beta 能力包括：组织/工作区/用户/API key 四级限额（超限返回 402）、实时成本聚合、PII 与密钥检测脱敏、trace 连续性、LangSmith Engine 集成、审计日志；路线图还覆盖工具与 MCP 网关、模型回退等更灵活的治理。
内容精讲
文章用两个场景点出现实痛点。第一个是成本失控：一个编码 agent 在夜间陷入重试循环，到第二天早上已经打了 10,000 次 LLM 调用，账单成了四位数。第二个是数据泄露：一个客服 agent 处理退款请求，请求里带着社保号（SSN），这个号码从此躺在 LLM 提供商的日志里、trace 数据里，还可能进了任何消费响应的下游系统。作者强调这些不是边缘案例，而是生产环境里运行 agent 的日常。可观测性只能告诉你"发生了什么"，要想在问题发生前阻止它，必须在请求层强制执行策略。
这就是 LangSmith LLM Gateway 填补的"可观测性与执行之间的缺口"。在它出现之前，团队要把独立的网关、护栏平台和可观测性栈拼在一起，出问题时还要跨三套系统去关联信号。LLM Gateway 把两者放进同一个产品：它站在 agent 与 LLM 提供商之间，在请求到达模型前就强制成本限制、脱敏敏感数据；当策略触发时，事件直接流入 LangSmith，无需单独的控制台、审计日志或工具。
beta 版本提供企业最迫切需要的控制。花费限额：在组织、工作区、用户或 API key 四个层级设置硬性上限，命中上限时 agent 收到一个带清晰错误信息的 402 响应。花费可见性：按工作区、用户和 API key 实时汇总成本，消除月底的账单惊吓。PII 与密钥检测：敏感数据在到达模型或写入 trace 之前就从请求和响应里被脱敏，agent 继续运行，而敏感数据不会继续传播。Trace 连续性：所有经网关代理的调用都出现在与 agent 其他 trace 相同的 LangSmith 工作区里，路由不碎片化你的可观测性。LangSmith Engine 集成：策略事件在 Engine 里浮现供分诊，从违规点进产生它的 trace 不用离开产品。审计日志：网关里的每次管理动作都被记录，合规与安全团队无需另建审计管道即可获得完整记录。分层执行让团队可以把策略聚焦在最需要的地方。
设置被刻意设计得"无聊"：把你的 agent 指向 LangSmith Gateway 端点（用 LangSmith API key）、把提供商 API key 加进工作区密钥、在 LangSmith UI 里设置策略——仅此而已。换掉 base_url，保留你的代码。这一点对"治理工具用不起来"的问题对症下药：大多数治理工具都有自己的配置与消费界面，如果团队的主要工作已经在别处进行，单独维护一套治理界面是额外负担。而 LLM Gateway 配置在 LangSmith 里，一条被拦截的请求就是一个可追踪事件，一处 PII 命中就是一个能点击跳转到产生它的那条 trace 的信号——从那里你能看到 agent 当时在做什么、更新系统 prompt 或工具配置、再对现有测试集重新评估，全程不离开产品。
文章还梳理了 agent 治理市场的几种形态并解释了自己的定位选择。网络层网关（network-layer gateways）：提供速率限制、路由与流量治理这类基础设施级控制，适合把 LLM 调用当普通 API 流量对待的团队，代价是策略触发时没有 trace 上下文可调试、策略调整也不"懂 AI"。独立护栏平台（standalone guardrails platforms）：提供成熟的评估与策略（通常基于小型评估模型），适合愿意整体采纳其生态的团队，代价是你的 agent、trace 与评估会分散在两个地方，还要维护第二套可观测性界面。数据平台治理层：把数据目录或湖仓扩展覆盖 AI 工作负载，适合已深度嵌入该平台的团队，否则采纳它就是一次迁移而非功能新增。LLM Gateway 的选择是锚定 agent 框架本身——agent 真正被构建和运行的地方。这种锚定让策略事件流入与 trace、评估、仪表板相同的工作区，也让团队能基于真实生产 agent 行为调优策略，无需单独微调循环或盯着评估模型保持准确。
文章预告了演进方向：今天的版本覆盖 LLM 调用，但 agent 做的事情更多。路线图包括更深入的安全控制（超越 PII 与密钥检测，覆盖 agent 调用外部模型、触碰生产系统的完整风险面）、更灵活的强制方式（先软性灰度再硬阻断、模型回退与替换、速率限制）、以及工具与 MCP 网关——把相同的强制原语扩展到工具调用、agent 间调用与 MCP 服务器交互。文章的立场很鲜明：agent 治理不该是加在智能体系统之上的附加层，构建、观察与评估 agent 的产品，就该是执行它们运行规则的产品。
阅读价值
适合正在生产环境运行 agent、需要成本管控与数据合规的工程团队和平台负责人：文章清晰对比了网络层网关、护栏平台、数据平台治理三种现有方案及其代价，并完整列出了"请求层强制策略"这套思路需要的能力清单；对如何在自己团队里选择治理落点、治理该长在哪一层，有直接的决策参考价值。
本文为中文精炼导读,由 AI 基于原文整理,内容与图片版权归原作者所有。原文: https://www.langchain.com/blog/introducing-llm-gateway