devgo.cn核心观点
- LangSmith LLM Gateway 是运行在 Agent 与 LLM 供应商之间的治理层：在请求到达模型之前强制执行成本上限、脱敏敏感数据，从源头止损而不是事后记录。
- 两个典型事故是设计靶子：编码 Agent 夜间陷入重试循环产生上万次调用；客服 Agent 处理退款时把社保号送进了供应商日志与追踪数据。
- 治理与观察在同一界面：被拦截的请求就是一条可追踪事件，从违规一键点到触发它的 trace，再改提示词/工具配置，无需切换工具。
- 接入是「无聊式」的一行改动：base_url 换成 Gateway 端点、把供应商 key 放进 workspace secrets、UI 里配策略，无独立基础设施。
内容精讲
生产 Agent 的日常里，两类事故正在反复发生。一是成本失控：一个编码 Agent 在夜间陷入重试循环，到早上已经打出 10,000 次 LLM 调用，账单四位数字。二是数据泄露：客服 Agent 处理退款请求时带上了一个社保号，于是这个号码进了 LLM 供应商的日志、进了 trace 数据、还可能进了任何消费响应的下游系统。这都不是边缘案例，而是生产 Agent 的日常现实。
**可观测不等于可阻止。** 观测（observability）告诉你发生了什么，但要在发生之前拦住它，需要在请求层强制执行策略。过去的做法是把一个独立 Gateway、一个 guardrails 平台、一套可观测栈拼在一起，出问题时再跨三个系统手工关联信号。LangSmith LLM Gateway 的做法是把这层治理直接放进 Agent 生命周期里——它位于 Agent 与供应商之间，请求到达模型之前就做两件事：强制费用上限、脱敏敏感数据。
**公测提供的控制项。** 支出上限：按组织、workspace、用户或 API key 设置硬上限，触发时 Agent 收到 402 响应和清晰报错。支出可见性：按 workspace/用户/key 实时汇总成本，告别月底的账单惊吓。PII 与密钥检测：敏感数据在到达模型或被写入 trace 之前就被脱敏——Agent 继续运行，敏感数据不再扩散。追踪连续性：所有经 Gateway 代理的调用出现在同一个 LangSmith workspace，路由不割裂可观测性。Engine 集成：策略事件进 LangSmith Engine 供分诊，违规 → 对应 trace → 修复全程不离开产品。审计日志：Gateway 的每个管理动作都被记录，合规与安全团队无需另搭审计管线。分层执行：策略可落在组织/workspace/用户/API key 不同粒度。
**「无聊」的接入是最重要的设计。** 把 Agent 指向 Gateway 端点（用 LangSmith API key）、把供应商 key 加到 workspace secrets、在 UI 里配置策略——这就是全部设置。swap the base_url, keep your code。没有新基建、没有新的运维负担。对已经在 LangSmith 上构建、观测、评估 Agent 的团队，策略配置、违规事件、调查流程都发生在同一个界面上：被拦截的请求是可追踪事件，被脱敏的 PII 匹配是能点进对应 trace 的信号，然后直接改系统提示词或工具配置、对着现有测试集重评估。
**治理层应该长在哪，是当前市场争论点。** 网络层网关给出强基础设施控制（限流、路由、流量治理），但策略触发后拿不到 trace 上下文，策略调优也不懂 AI。独立 guardrails 平台有精密的评估与策略（常基于小评估模型），但要全盘接受其生态，Agent、trace、评估被拆到两个地方。数据平台层把 AI 负载纳入数据目录，但同样把治理从开发面切开。Gateway 的选择是把治理下沉到请求层的同时，保持与构建/观察/评估同一表面——检测、调查、修复都在 Agent 出生的地方完成。
阅读价值
对正在运营 Agent 的团队，这是「运行时治理」的第一份完整清单：上限、脱敏、审计、分层四类控制项可直接对照需求；对平台选型者，它梳理了网络层网关、guardrails 平台、数据平台三种治理形态的取舍，方便按团队现状定位。
内容与图片版权归原作者所有 · 原文: https://www.langchain.com/blog/introducing-llm-gateway