上个月，我部署了一个客服聊天机器人，当时觉得它运行得还挺正常。用户提问，它回答，我那基础错误日志显示零崩溃。后来我手动抽查了对话记录，才发现不对劲：这机器人有大概 20% 的时间在自信满满地胡说八道，某些查询要卡 15 秒以上，偶尔还会凭空捏造根本不存在的政策。我的错误日志干干净净，因为应用确实没崩溃——它只是在正事上悄无声息地掉链子。
那一刻我意识到，我需要的是对 LLM 应用真正的可观测性（observability），而不仅仅是基础设施监控。我需要知道模型在想什么，检索花了多长时间，以及整个链路到底是在哪一步跑偏的。研究了一番后，我选择了 LangSmith。下面是我搞定它的过程，以及这一路上踩过的坑。
痛点：LLM 应用就像在“盲飞”
如果你用 LLM 开发过东西，肯定懂这种感觉。你写好提示词，在 notebook 里测了几次，效果看起来棒极了。可一旦部署上去，你就两眼一抹黑了。像 Datadog 这种传统的 APM 工具能告诉你 API 调用发生了、花了多长时间，但它们没法告诉你：
- 到底发给模型的是什么提示词
- 消耗了多少 token
- 在模型生成答案之前，检索步骤返回了什么
- 在多步链路中，到底哪一步出了问题
LangSmith 解决了这个问题，它让你能看到 LLM 应用每一步的链路追踪（trace）细节。我来带你一步步搞定设置。
第一步：账号和 API Key 设置
打开 smith.langchain.com 注册。不需要绑信用卡，这点我很喜欢——你可以先试用再决定入不入坑。我用 GitHub 账号注册的，大概 10 秒就搞定了。
注册好之后，你需要一个 API key。进入 Settings → API Keys → Create API Key。立马复制保存好，因为之后再也看不到了。我之前就没保存，结果只能重新生成一个。虽然不是什么大问题，但挺烦人的。
第二步：配置环境变量
我本来以为这步会很复杂，但 LangSmith 把它弄得特别简单。你只需要设置环境变量，如果你用的是 LangChain，链路追踪就会自动开启。你需要配置这些：
export LANGSMITH_API_KEY="your-api-key-here"
export LANGSMITH_TRACING="true"
export LANGSMITH_PROJECT="my-customer-support-bot"
LANGSMITH_PROJECT 这个变量是可选的，但非常重要。它能把你的追踪记录按项目分组，不然你面对的就是一堆乱七八糟、毫无分类的数据。真希望我第一天就设好这个，而不是把所有东西都扔进默认项目，之后再痛苦地去分类。
如果你用的是 .env 文件（强烈建议用）：
LANGSMITH_API_KEY=lsv2_pt_your_key_here
LANGSMITH_TRACING=true
LANGSMITH_PROJECT=customer-support-bot
第三步：看到你的第一条追踪记录
这部分真的惊到我了。如果你用的是 LangChain，你完全不需要改哪怕一行代码。环境变量会自动接入 LangChain 的回调系统。我直接跑了我现有的 RAG 链路：
from langchain_openai import ChatOpenAI
from langchain.chains import RetrievalQA
llm = ChatOpenAI(model="gpt-4", temperature=0)
chain = RetrievalQA.from_chain_type(llm, retriever=my_retriever)
result = chain.invoke("What is your return policy for electronics?")
就这——当我去 LangSmith 的 UI 界面一看，一条完整的追踪记录已经躺在那了，展示了每一步：初始查询、检索步骤及抓取到的真实文档、发给 GPT-4 的提示词，还有最终的回复。我能清楚地看到检索到了哪些文档，以及每一步花了多长时间。
第一个让我“顿悟”的时刻是，我发现我的检索器在大概 30% 的查询中返回的都是不相关的文档。模型其实是在拿糟糕的输入尽力而为，检索环节才是真正的软肋。如果没有链路追踪级别的可见性，我绝对发现不了这个问题。
第四步：不用 LangChain 也能用 LangSmith
文档里有一件事强调得不够：你不需要非得用 LangChain 才能用 LangSmith。我有些代码是直接调用 OpenAI SDK 的，我也想给它们加上追踪。你可以直接使用 LangSmith SDK：
from langsmith import traceable
from openai import OpenAI
client = OpenAI()
@traceable(name="generate_response")
def generate_response(user_query: str):
response = client.chat.completions.create(
model="gpt-4",
messages=[
{"role": "system", "content": "You are a helpful support agent."},
{"role": "user", "content": user_query}
]
)
return response.choices[0].message.content
result = generate_response("What is your return policy?")
只需要加一个 @traceable 装饰器就行。它会自动把输入、输出和耗时记录到 LangSmith。你还可以嵌套使用——所以如果你有一个多步流水线，每一步都会在父运行下生成自己的追踪记录：
@traceable(name="retrieve_docs")
def retrieve_docs(query: str):
# 你的检索逻辑写在这里
return documents
@traceable(name="generate_response")
def generate_response(query: str, docs: list):
# 你的生成逻辑写在这里
return response
@traceable(name="full_pipeline")
def rag_pipeline(query: str):
docs = retrieve_docs(query)
response = generate_response(query, docs)
return response
这样在 UI 界面里，你就能看到同样的嵌套追踪视图，数据在流水线里是怎么流转的，一目了然。
第五步：真正开始排查问题
追踪设置好之后，我就用 LangSmith 来诊断我聊天机器人的毛病了。以下是我在 UI 里过滤追踪记录后的发现：
查询慢： 我按延迟排序，发现耗时超过 10 秒的查询都有一个共同点——检索器返回了太多文档（我之前设的是 top-k=10），GPT-4 得处理所有这些内容。把 top-k 降到 4 后，延迟直接砍了 60%，而且回答质量没有任何损失。
幻觉： 我过滤出那些模型提到了具体政策细节的追踪记录，然后和检索到的文档做对比。好几次，文档里根本没有模型引用的那些信息。模型是在用听起来很合理的虚构内容填补空白。修复方法：我在提示词里加了明确指令：“如果检索到的文档不包含答案，就说你不知道。”
Token 浪费： 追踪视图会显示每一步的 token 数量。我才发现我的系统提示词有 800 个 token 的废话，其实可以精简到 300 个。日积月累跑上几千条请求，这省下来的量可就大了。
第六步：设置监控和报警
修完这些火烧眉毛的问题后，我想做到防患于未然。LangSmith 支持搭建仪表盘和设置自动化规则。我设了一条简单的规则：如果 10 分钟内项目的平均延迟超过 5 秒，或者错误率超过 5%，就给我发报警。
你还可以设置在线评估（online evaluations）来自动给追踪记录打分——比如检查回复是否包含特定关键词，或者跑一个更便宜的模型来给回复质量打分。这块我还没深入研究，但已经在我的待办清单上了。
实用建议与客观局限
建议：
- 从一开始就设好
LANGSMITH_PROJECT。开发、预发布和生产环境要分开建项目。未来的你会感谢现在的自己的。 - 即使是数据库查询或 API 调用这类非 LLM 步骤，也加上
@traceable装饰器。能看到完整流水线的全貌，这才是它真正的价值所在。 - 追踪记录的对比功能绝对被低估了。把两条记录并排选中对比，你就能确切知道为什么一个管用、一个不管用。
- 给追踪记录打上元数据标签，比如
user_tier（用户等级）或query_type（查询类型）——这会让后期的过滤功能变得异常强大。
局限：
- 免费版有追踪次数限制。如果你跑的是高流量的生产环境，达到上限的速度会比你想象的快得多。我测试的时候，大概两天就把免费额度烧光了。
- 当加载提示词特别长或检索到的文档集特别大的追踪记录时，UI 界面偶尔会卡顿。需要点耐心。
- 如果你没用 LangChain，
@traceable装饰器虽然很好用，但你会失去 LangChain 提供的那种自动嵌套功能。你需要更刻意地去设计可追踪函数的结构。 - 有些地方的文档还没跟上。有几次为了搞懂高级配置选项，我不得不去翻 SDK 的源码。
总结： 传统监控工具覆盖不到的盲区，LangSmith 填补上了。如果你在生产环境中跑 LLM 应用，你需要这种级别的可见性。它的设置过程出乎意料地无痛，而且能让你立刻获得洞察。只是随着规模扩大，要注意一下价格问题，并且从一开始就要规划好项目和标签的结构。