进入最后的 Phase 6——生产化收束。前 37 篇讲了怎么搭 LangChain 应用，这最后 5 篇讲怎么让它敢上线：可观测、评估、调试、部署。
这一篇讲 Phase 6 第一个——LangSmith Tracing。回到第 01 篇立的第三根轴「可观测治理」：LLM 调用是黑盒，没有可观测性就永远停在 demo。Tracing 是可观测的基础。
为什么 LLM 应用特别需要 Tracing
传统软件，看代码大致能推断运行时发生了什么。但 LLM 应用不行——模型调用是黑盒：同样的输入可能给不同输出，模型为什么这么答，你看代码看不出来。
更要命的是，LLM 应用是多步的：一个 Agent 跑起来，可能调了好几次模型、好几次工具、做了好几次判断。最后答错了，到底是哪一步错的？没有 trace，你只能瞎猜。
Tracing 解决的就是这个：把每一次 run 的每一步都记录下来，让你看清 Agent 内部到底发生了什么。
Trace：分层调用树
LangSmith 的 trace，是一次 run 的分层调用树。一个 Agent run，拆成：
- 顶层：这次完整的 run
- 下层：每次模型调用、每次工具调用、每次检索
- 更下层：每次调用的输入、输出、耗时、token、错误
你能在 LangSmith 里展开这棵树，看到「模型第 2 次调用时，传入了什么消息、输出了什么、花了多少 token、用了多久」。哪一步有问题，一目了然。
Trace 记录什么
一个 trace 节点，典型记录：
| 信息 | 作用 |
|---|---|
| 输入 | 这一步收到了什么 |
| 输出 | 这一步产出了什么 |
| 耗时 | 这一步花了多久（找慢的环节） |
| token 数 | 这一步消耗多少（算成本） |
| 错误 | 这一步有没有报错 |
这些信息合起来，让你能回答：答错了是哪步错、慢是哪步慢、贵是哪步贵。没有 trace，这些问题都答不了。
LangChain 应用自动可追踪
一个重要的事实：用 LangChain（Runnable/LCEL/LangGraph）写的应用，trace 是自动的。
因为所有组件都是 Runnable（第 03 篇），Runnable 协议层内置了 trace 钩子。你配好 LangSmith，跑应用时每一步自动上报——不用手动埋点。
这是 Runnable 协议的又一个红利：第 03 篇说「统一协议带来可组合、可替换、能力一致」——「可追踪」就是能力一致的一环。不用 LangChain（纯手写调 API）的应用，要自己埋点才能有 trace；用 LangChain 的，免费就有。
Trace 怎么用：排查问题
实际用 trace，最常见是排查「Agent 答错了」。流程：
- 在 LangSmith 找到这次 run 的 trace
- 展开调用树，看每一步
- 定位是哪一步出了问题（模型判断错？工具返回错？检索没查到？）
- 针对那一步优化
这个流程对 Agent 这种「多步、不确定」的程序，价值巨大。没有 trace，Agent 答错了你只能干瞪眼；有 trace，能精确知道哪步错、为什么错。
收束：Tracing 是 LLM 应用的眼睛
这一篇讲了 LangSmith Tracing：
- LLM 应用是黑盒且多步，特别需要 trace
- Trace 是分层调用树，记录每步的输入输出耗时 token 错误
- LangChain 应用自动可追踪（Runnable 协议红利）
- 用来排查「答错是哪步错、慢是哪步、贵是哪步」
下一篇讲 评估：怎么用数据集量化 Agent/RAG 的质量，而不是凭感觉。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。我相信 AI 是程序员的最佳搭档。
如果你想跟完这套「图解 LangChain」，欢迎关注公众号 「十三Tech」。全系列 42 篇，会按认识基础、LangGraph 状态机、Agent 与 middleware、RAG 检索、Tools/MCP/记忆、生产化收束这条线更新。
