跳到主要内容

LangSmith：Observability、Evals 与 Deployment 指南

如果已经开始做 LLM App 或 Agent，很快会遇到几个很现实的问题：

  • 这次回答为什么错了
  • 是 prompt 有问题，还是工具调用有问题
  • 这次改动到底让系统变好了，还是只是碰巧看起来不错
  • 本地能跑，为什么一上线就开始出现奇怪问题

LangSmith 想解决的，就是这类“从开发到上线”的工程化问题。

基于官方文档，LangSmith 的定位可以概括成一句话：

它是一个与框架无关的平台，用来构建、调试、评估和部署 AI Agent 与 LLM 应用。

官方文档把它的主线能力分成几块：

  • Observability：看清系统每一步是怎么跑的
  • Evaluation：系统化判断质量有没有变好
  • Deployment：把 Agent 作为可运行服务部署到生产环境
  • Platform setup：决定你用云托管、混合部署还是自托管

这篇文档重点放在 Observability / Evaluation / Deployment，因为这三块最容易和本专题现有的 Evals / Harness / Observability 体系形成对应关系。

1. 定位​

LangSmith 不是单一 SDK，也不只是 trace 可视化工具。

它更准确的定位，是一层围绕 AI 应用运行、调试、评估、发布 的平台能力。

按照官方首页的说法，它支持：

  • trace request
  • evaluate outputs
  • test prompts
  • manage deployments

并且它是 framework-agnostic 的。

这一点很重要，因为它并不要求必须使用 LangChain 才能接入。官方文档明确支持多种 provider 和 framework，也支持手动埋点：

  • 可以拿它观察 LangChain / LangGraph
  • 也可以拿它观察 OpenAI、Anthropic、CrewAI 一类集成
  • 如果是自研 runtime，也可以手动把 trace 送进去

所以不要把 LangSmith 理解成“LangChain 的附属工具”。

更合适的理解是，它是一套偏平台层的 AI 工程基础设施。

2. Observability、Evaluation、Deployment 各自负责什么​

LangSmith 可以看成三层连续能力。

2.1 Observability：先看清发生了什么​

这一层解决的是：

  • 每次请求经过了哪些步骤
  • 哪一步调用了模型
  • 哪一步调用了工具
  • 输入、输出、耗时、元数据分别是什么
  • 线上问题到底卡在什么地方

官方文档把这一层描述为：

  • instrument your LLM application
  • investigate traces
  • monitor performance in production

Observability 不只是日志存储，而是：

  • Tracing：记录执行轨迹
  • Trace inspection：在 UI 或 API 里查、过滤、对比轨迹
  • Monitoring：做 dashboard、alert、insights
  • Automation：规则、webhook、在线评估
  • Feedback collection：把人工反馈和 trace 关联起来

2.2 Evaluation：再判断系统有没有变好​

这一层解决的是：

  • 新 prompt 是否优于旧 prompt
  • 新 agent 版本是否退化了
  • 某类任务是否稳定改善
  • 线上真实流量里有没有持续出现质量问题

LangSmith 官方把评估分成两类：

  • Offline Evaluation：上线前，用数据集做离线实验
  • Online Evaluation：上线后，对真实运行流量做实时评估

官方给出的离线评估流程很清楚：

  1. 创建数据集
  2. 定义 evaluators
  3. 跑 experiment
  4. 分析结果

而线上评估更接近：

  1. 应用已部署并产生真实 run
  2. 在生产 trace 上自动执行 evaluators
  3. 实时监控异常
  4. 把失败案例回流进数据集

所以它不是“做一次打分”而已，而是一整套闭环。

2.3 Deployment：把 agent 运行时带到生产环境​

这一层解决的是：

  • Agent 不是普通无状态接口时，怎么稳定上线
  • 长时运行、流式输出、并发执行怎么托管
  • 怎么把本地开发、调试、部署串成同一条链路

官方把 LangSmith Deployment 定位为：

一个面向 agent workload 的 workflow orchestration runtime。

它强调的不是“帮你找个地方把 Python 服务挂起来”，而是针对 Agent 场景提供：

  • durable execution
  • real-time streaming
  • horizontal scaling
  • 从本地开发到部署的完整生命周期支持

如果系统只是一个很简单的短请求文本接口，这一层可能还不是最先需要的。

但如果已经进入：

  • 多步 agent
  • 持久状态
  • 长任务执行
  • 人工中断 / 恢复
  • 多轮线程管理

那 Deployment 才会开始体现出价值。

3. Trace 是什么，为什么重要​

这是理解 LangSmith 的关键。

很多人第一次看 LangSmith，会觉得它只是“把一次调用记录下来”。

但在官方概念里，它有一套比较清楚的数据结构：

  • Project：某个应用或服务的轨迹容器
  • Trace：一次 operation 的完整执行轨迹
  • Run：轨迹中的单个工作单元，类似一个 span
  • Thread：把多轮对话中的多个 trace 串起来

3.1 Trace 记录的是“一次任务从输入到输出经历了什么”​

比如一个请求经过：

  1. 接收用户问题
  2. 改写查询
  3. 检索知识库
  4. 调模型总结
  5. 调工具补信息
  6. 生成最终答案

那这些步骤不应该只体现在零散日志里，而应该被组织成一条可回放、可比较、可过滤的执行链。

这条链，就是 trace。

3.2 Run 记录的是“其中某一个具体动作”​

官方把 run 解释为单个工作单元，可能是：

  • 一次 LLM 调用
  • 一次 prompt format
  • 一次 retrieval
  • 一次工具执行
  • 任何离散的应用步骤

如果把 trace 理解成整场比赛，run 更接近其中每一个回合。

3.3 Thread 解决的是“多轮对话怎么串起来看”​

在多轮 agent 或 assistant 场景里，单看某一轮往往不够。

通常还会想知道：

  • 这轮错误是不是前几轮状态污染导致的
  • 用户是不是前面已经给过关键信息
  • 某个坏结果是不是长期累积出来的

这时 thread 就很有用。官方做法是用共享标识把多条 trace 连成一个会话序列。

4. Trace 能解决什么问题​

如果只看最终输出，很多问题其实定位不到。

而 trace 的价值，就在于把“失败发生在哪里”暴露出来。

4.1 定位工具调用问题​

例如：

  • 工具选错了
  • 工具参数错了
  • 工具返回值为空
  • 工具报错后被静默吞掉
  • 拿到工具结果后模型没真正使用

这些问题只看最终回答，往往只能看到“答案不太对”。

看 trace 才能知道到底是：

  • decision 错
  • action 错
  • observation 错
  • synthesis 错

4.2 定位 RAG 问题​

例如：

  • 检索召回不准
  • 检索到了正确信息但回答没引用
  • query rewrite 把问题改偏了
  • rerank 逻辑反而把好文档压掉了

如果没有 trace，你只能猜。

有 trace 之后，可以逐步看：

  • 改写后的 query 是什么
  • 返回了哪些文档
  • 模型最终看到了哪些上下文
  • 最终答案和上下文之间有没有脱节

4.3 定位 Agent 轨迹问题​

例如：

  • 第一步目标理解就错了
  • 中间进入重复循环
  • 提前停止
  • 明明已经完成还继续多跑
  • 多轮状态丢失

这些都属于典型的 agent runtime 问题，而不是单纯的模型问答问题。

4.4 让评估更可解释​

很多评估系统只能告诉你：

  • 这条样本得分低

但它不一定告诉你：

  • 为什么低
  • 低在哪一步
  • 是检索问题、工具问题还是推理问题

有 trace 之后，eval 不再只是分数，还能回到具体执行过程做复盘。

4.5 让线上监控不只是看接口成功率​

普通接口监控大多只看：

  • 是否 200
  • 延迟是否变高
  • 错误率是否上升

但 AI 系统很多时候“接口成功”不代表“任务成功”。

trace 加上在线评估后，你才更有机会看到：

  • 格式对了，但内容质量在退化
  • 安全问题在某类输入上变多
  • 某个工具集成最近开始频繁拖慢整体链路

5. LangSmith 里的 Observability 应该怎么理解​

不宜把这个概念理解得太窄。

在传统软件里，observability 常常围绕 log、metric、trace。

到了 LangSmith 这里，它当然也有 trace 思维，但会更贴近 AI 应用本身，重点包括：

  • 请求级可见性：一条请求到底怎么走
  • 步骤级可见性：模型、工具、检索各跑了什么
  • 语义级可见性：输出质量与反馈能不能挂到具体轨迹上
  • 生产监控：dashboard、alerts、insights、automation

LangSmith 的 observability 不是单纯的 infra 监控，而是带 AI 语义的 observability。

它既关注：

  • latency
  • cost
  • error

也关注：

  • answer quality
  • tool behavior
  • retrieval quality
  • user feedback

6. LangSmith 里的 Evaluation 应该怎么理解​

如果只把 LangSmith 当 trace 平台，其实只用到了它的一半。

因为官方很强调 evaluation workflow，而且它和 observability 是连起来的。

6.1 离线评估适合开发阶段​

当还在反复试：

  • prompt 版本
  • 模型版本
  • tool strategy
  • retrieval 配置
  • agent policy

这时最适合用 offline evaluation。

核心动作是：

  • 建数据集
  • 设计 evaluator
  • 跑实验
  • 比较实验结果

官方列出的 evaluator 类型包括：

  • Human review
  • Code rules
  • LLM-as-judge
  • Pairwise comparison

这和很多团队自己做的 eval harness 很像，只是 LangSmith 把这套流程产品化了。

6.2 在线评估适合生产阶段​

当系统已经上线，问题就会从“实验室效果”变成“真实流量下是否稳定”。

这时 online evaluation 的意义会变得更大。

它更适合：

  • 安全检查
  • 输出格式检查
  • 无参考答案的质量启发式评分
  • 实时发现某类输入的异常退化

官方明确把它和 trace、thread、alerting 放在一起。线上评估不是独立于 observability 的旁支，而是生产观测的一部分。

6.3 真正有价值的是离线和线上打通​

一个成熟流程通常不是只做其中之一，而是：

  • 线上发现坏例子
  • 回流成 dataset
  • 离线复现并验证修复
  • 再重新部署
  • 继续在线观察

这才是 LangSmith 想提供的工程闭环。

7. LangSmith 里的 Deployment 应该怎么理解​

这里要特别注意一个边界：

LangSmith 不只是开发期工具，它还试图覆盖 agent 的生产运行。

官方把 Deployment 单独拉出来，是因为 Agent 的部署和普通 web 服务并不完全一样。

它更强调这些能力：

  • 持久执行
  • 流式输出
  • 长时任务
  • 水平扩展
  • 本地到云端的一致开发体验

因此它适合的是“agent runtime 问题已经变成真正生产问题”的阶段。

如果团队还在：

  • 写 prompt
  • 手动点几个样本
  • 偶尔本地跑一下脚本

那 Deployment 可能还不是第一优先级。

但如果已经在处理：

  • 多用户并发
  • 会话线程
  • 长任务可靠性
  • 可恢复执行
  • 生产排障

那它就不再是“锦上添花”，而是在补运行时基础设施。

8. 它和本专题已有 Evals / Harness / Observability 文档怎么对应​

这是这篇文档需要讲清楚的一部分。

因为 LangSmith 不是在替代这些概念，而是在把它们平台化。

8.1 对应 Evaluation / Evals​

本专题里的 Evals 文档更偏方法论：

  • 为什么需要评估
  • 常见评估维度是什么
  • 不同评估方式怎么选

LangSmith 对应的是其中的“平台实现层”：

  • dataset 管理
  • evaluator 定义
  • experiment 执行
  • result 分析
  • online eval 接生产流量

可以理解成：

  • Evals 文档 讲的是“为什么评、评什么、怎么设计”
  • LangSmith Evaluation 讲的是“这套评估流程如何落到工具和平台里”

8.2 对应 Harness Engineering​

Harness 属于工程支架概念。

它关注的是：

  • 任务怎么批量运行
  • 配置怎么固化
  • 轨迹怎么记录
  • 结果怎么比较
  • 回归怎么做

LangSmith 在很多场景里，正好可以充当这层 harness 的重要组成部分，尤其是：

  • trace 采集
  • experiment 运行
  • dataset / evaluator 管理
  • 线上到离线的问题回流

但它不等于 harness 的全部。

因为完整 harness 还可能包括：

  • 自己的任务编排器
  • CI 流程
  • 自定义回归门禁
  • 团队内部数据处理链路

所以更准确的说法是：

LangSmith 常常是 Harness 的核心平台之一，但 Harness 这个概念本身更宽。

8.3 对应 Agent Observability and Debugging​

现有 Observability 文档讲的是思维方式：

  • 为什么 agent 要看轨迹
  • 调试时重点看什么
  • 常见失败类型有哪些

LangSmith 则更接近这套思维方式在实际工具中的落地对象。

比如文档里提到要看：

  • step trace
  • tool call trace
  • state transition
  • stop reason

LangSmith 正是用 trace / run / thread / metadata / feedback / dashboards 这些能力，去把这些东西变成可以查看、过滤、对比和监控的对象。

所以二者关系可以理解成：

  • Observability 文档 负责建立调试视角
  • LangSmith Observability 负责提供具体平台抓手

9. LangSmith 最适合什么阶段引入​

不是所有团队都要一开始就全量上 LangSmith。

更现实的方式是按阶段看。

9.1 早期原型阶段​

适合先引入：

  • 基础 tracing
  • 手工查看几条关键 trace
  • 少量离线 eval

这个阶段最重要的不是“平台全开”，而是先建立：

  • 轨迹意识
  • 样本意识
  • 对比意识

9.2 从 demo 到可迭代系统阶段​

这是最适合 LangSmith 发挥价值的阶段。

因为这时团队通常已经开始遇到：

  • 版本越来越多
  • 样本越来越多
  • 不同人对质量判断不一致
  • 线上问题无法稳定复现

通常应优先引入：

  • 项目化 trace 管理
  • dataset 与 evaluator
  • experiment 对比
  • 反馈回流

9.3 生产化阶段​

当系统已经承担真实业务流量时，重点会转向：

  • 在线评估
  • dashboard / alert
  • 线程级排障
  • 成本与性能跟踪
  • 生产部署与运行可靠性

这时 LangSmith 的 observability 和 deployment 才会真正连起来。

10. 引入时机​

当系统出现下面这些问题时，通常就已经到了需要认真引入 LangSmith 的阶段：

  • 系统出错时，你只能看最终答案，无法看中间过程
  • 团队经常在“感觉这版更好”上争论
  • 改 prompt 或策略后，很难确认是否退化
  • 线上坏例子很多，但回不到离线验证流程
  • agent 已经不只是简单问答，而是多步、多工具、多轮状态系统

如果还没到这个阶段，也不用强行把它全上齐。

一个很自然的引入顺序通常是：

  1. 先开 tracing
  2. 再做 dataset 和 offline eval
  3. 再接 production monitoring 和 online eval
  4. 最后在需要时引入 deployment runtime

11. 一个简化判断​

如果只用一句话总结：

  • 想知道系统每一步怎么跑的，看 Observability
  • 想知道系统到底有没有变好，看 Evaluation
  • 想把 agent 稳定带到生产环境，看 Deployment

而 trace 是这三者之间最关键的连接点。

因为没有 trace：

  • 调试会变盲
  • eval 会变得不可解释
  • 线上监控也只剩接口层指标

所以对大多数团队来说，理解 LangSmith 最好的切入点不是“它能不能部署 agent”，而是：

先把 trace 当成 AI 系统的运行事实层。

从这层事实出发，再往上接评估、监控和部署，整条工程链路才会开始变得清晰。

12. 参考资料​

本文基于 LangSmith 官方文档整理，可直接配合原文阅读：