如何在 DevOps 中使用 LangSmith

上个月，我们团队把一个智能客服 Agent 推上了生产环境。测试的时候它表现得很棒——回答准确，数据拉取正确，响应时间不到两秒。结果工单接踵而至。用户收到了莫名其妙的截断回复，有些请求还超时了。我们传统的监控面板上一片绿：CPU 正常，内存正常，API 全返回 200。但这个 Agent 显然在它的工具调用和 LLM 请求链路中出了岔子。

那一刻我才意识到，我们标准的 DevOps 工具栈对 LLM 应用真正关键的东西完全是瞎的。我们有基础设施的可观测性，但对 Agent 实际的决策过程，我们完全没有应用层面的可观测性。我开始寻找解决方案，最终选定了 LangSmith。下面是我如何配置它的，以及把它当作 LLM 工作负载的 DevOps 工具来用时，我都学到了什么。

配置链路追踪：基础设施

用 LangSmith 首先要搞定链路追踪（Tracing）。这是它的核心能力——Agent 处理的每个请求都会被记录为一条 Trace，它是一棵嵌套树，包含了所有独立的操作（LLM 调用、工具执行、检索器查询等）。

配置起来出乎意料地简单。在 smith.langchain.com 注册账号，从 Settings → API Keys → Create API Key 生成一个 API 密钥后，只需设置环境变量就行了：

export LANGSMITH_API_KEY="your-api-key-here"
export LANGSMITH_TRACING="true"
export LANGSMITH_PROJECT="prod-support-agent"

搞定。如果你用的是 LangChain 或 LangGraph，完全不需要改代码——SDK 会自动读取这些环境变量，并开始上报 Trace。第一批 Trace 跑通时的顺畅度，真的让我挺惊讶的。

对于我们的 FastAPI 服务，我把这些环境变量加到了 docker-compose 文件的容器环境配置里。重新部署后没几分钟，LangSmith 界面上就出现 Trace 了。

Trace 到底能让你看到什么

这就是 LangSmith 发挥威力的时候了。用户向我们的客服 Agent 发起一个请求，在 Trace 视图里会触发这样一串流程：

输入解析（2ms）
检索器调用，获取相关文档（340ms）
第一次 LLM 调用，对查询进行分类（1.2s）
工具调用，查询订单状态（890ms）
第二次 LLM 调用，格式化响应（980ms）
输出校验（5ms）

总共大概 3.4 秒。但重点来了——当用户反馈超时时，我能精准看到卡在哪里了。在一条 Trace 里，检索器调用花了 8 秒，因为向量库在限流；在另一条里，第二次 LLM 调用花了 4 秒，因为模型负载太高。Trace 视图向你展示了完整的执行路径、每一步的耗时、每个阶段精确的输入输出，以及出现的任何报错。

至于截断响应的问题，我几分钟就定位到了：我们的输出校验步骤把超过 Token 限制的响应悄悄截断了，而这个限制我们设得太狠了。LLM 本来生成了完整的答案，却被我们的校验器给砍了。要是看不到每一步的实际输入输出，我绝对查不出这个问题。

搭建生产监控看板

跑起 Tracing 后，我就开始搭正规的监控看板了。LangSmith 可以让你构建自定义看板，追踪 Trace 的各项指标。我建了这些面板：

平均请求延迟（以及 p50/p95/p99 分位数）
各组件错误率（检索器失败 vs. LLM 失败 vs. 工具失败）
Token 用量和成本追踪（这个真让人大开眼界）
工具调用成功率

光靠成本追踪这一项，这工具就回本了。在分类步骤中，我们消耗 Token 的速度远超预期，原因就是 Prompt 写得太啰嗦了。我精简了一下，直接把这一步的 Token 用量砍了 40%。

你还可以设置告警。我配了一个 PagerDuty 告警，当 10 分钟内错误率超过 5% 就触发；还配了一个 Slack Webhook，当 p95 延迟超过 5 秒就报警。这些不只是基础设施层面的告警——它们是针对 Agent 行为实际质量和性能的告警。

使用自动化功能处理运维工作流

LangSmith 最强大的 DevOps 功能之一是自动化（Automations）。你可以根据 Trace 数据定义触发动作的规则。以下是我设置的规则：

规则 1：自动标记长 Trace。 任何超过 10 秒的 Trace 都会被打上 "performance-review" 的标签，并加入标注队列。这样我就能直接复查慢请求，不用再手动去捞了。

规则 2：错误路由。 任何包含报错的 Trace 都会被送到特定的标注队列，并触发一个 Webhook 推送到我们的故障频道。这直接替代了我们之前瞎拼凑的错误处理器。

规则 3：在线评估。 LangSmith 支持在生产环境的 Trace 上自动运行“LLM 作为评判者（LLM-as-judge）”的评估。我设了一个评估，按 1-5 分给响应的完整度打分。任何低于 3 分的 Trace 都会被标记待查。这样我们就有了持续的质量反馈信号，不用人工去查每一条输出。

通过界面配置这些非常简单——选个触发条件，定义动作，开启就行。完全不用写代码。

洞察：发现你意想不到的模式

洞察（Insights）功能是个意外之喜。它能自动对 Trace 进行聚类，帮你发现模式——比如常见用户话题、反复出现的故障模式、意料之外的 Agent 行为。

在我们的场景中，Insights 发现大约 15% 的客服请求走了一条不寻常的路径：Agent 会先调用订单查询工具，拿到结果后，又用稍微不同的参数再查一次。原来我们的 Prompt 在处理不完整订单号时存在歧义，导致 Agent 不断用各种变体重试。这种行为我手动绝对看不出来，但它不仅在大量请求中浪费了 Token，还增加了延迟。

SmithDB 在查询 Trace 时的优势

在规模化场景下，有个很实际的细节：LangSmith 使用了一个专门构建的数据库 SmithDB 来存储和查询 Trace。Agent 的 Trace 嵌套非常深——一次对话就能在几十次运行和工具调用中产生好几兆的数据。我一开始试着用标准工具查我们的 Trace 数据，那些 JSON 负载简直让人抓狂。SmithDB 支持 JSON 键路径过滤、全文搜索和轨迹查询（寻找 Agent 执行了特定操作路径的 Trace）。在数百万条 Trace 中，查询能在亚秒级完成，这在你排查故障、急需答案的时候简直太关键了。

实用技巧与坦诚的局限性

技巧：

开发、测试（staging）和生产环境要用不同的项目。LANGSMITH_PROJECT 这个环境变量让这事儿变得很简单。
别跳过标注队列。有一个结构化的方式来复查和标记有问题的输出，能形成一个反馈闭环，随着时间推移不断优化你的 Agent。
尽早配置在线评估。哪怕只是跑一个简单的“响应是否相关？”的评估，哪怕只覆盖 10% 的生产 Trace，也能给你提供平时根本拿不到的质量信号。
基于环境变量的配置意味着你可以不改代码就随时开关 Tracing——这在特定环境调试时非常有用。

局限性：

LangSmith 是专门为 LLM/Agent 可观测性打造的。它替代不了你的基础设施监控（Datadog、Grafana 等）。这两样你都需要。
免费版有 Trace 额度限制，在生产环境很快就会用光。如果你要跑真实业务，得为付费版做个预算。
虽然它支持 OpenTelemetry 和多种 SDK（Python、TypeScript、Go、Java），但最深的集成还是在 LangChain/LangGraph 生态里。如果你用的是纯自研技术栈，就需要做更多手动的埋点工作。
Trace 数据量可能很大。记录日志时要有的放矢——除非你真的需要，否则别把整个文档内容都塞进 Trace 的元数据里。

LangSmith 填补了我们 DevOps 工具栈中的一个关键空白：让我们能看清 Agent 到底在干嘛。传统监控告诉我们服务器很健康；LangSmith 告诉我们 Agent 在做错误的决定。对于任何在生产环境跑 LLM 应用的团队来说，这两者的区别就在于：你是“觉得一切正常”，还是“确知一切正常”。