主题
LangSmith vs Langfuse：Agent 观测工具怎么选
1. 从一个真实场景开始
你的 Agent 项目已经跑通了：LangGraph 把资料召回、结构生成、审稿、改写串成一条链路，本地测试时产物质量也不错。但一上线，问题开始冒头：
- 某个 Prompt 版本上线后，产物返工率突然升高，你猜是检索环节变了，却拿不出 trace。
- 一次交付被阻断，团队争论是资料来源不够官方，还是审稿规则太严。
- 客户问"这次为什么给出这个结论"，你只能回一句"模型这么生成的"。
这些问题的根因不是模型，而是没有留下可检查的过程证据。Agent 系统需要观测：不是看一次输出漂不漂亮，而是能回溯每个节点、每个版本、每个判断的来龙去脉。
这正是 LangSmith、Langfuse 和自建 tracing 要解决的问题。它们不是互相替代，而是分别负责不同的观测深度。
一句话判断：LangSmith 更偏向"开发调试台"，Langfuse 更偏向"产品运营台"，自建 tracing 是"生产主账本"。三者可以组合使用。
2. 比较工具前，先定义 Agent trace
上一篇文章拆过 Trace、Span、Metrics、Logs。落到工具选择时，常见候选会变成 LangSmith、Langfuse，或者自建 tracing。只比较界面和功能清单，很容易忽略 Agent 项目的业务字段。
一条任务 trace 至少要回答几个问题：
- 本次产物用了哪些资料来源，官方来源和二手资料各占多少。
- 结构、产物、审稿、改写、交付检查分别由哪个节点完成。
- 每个节点使用的 Prompt 版本、模型版本和检索配置是什么。
- 审稿节点提出了哪些 P0 / P1 / P2 问题，哪些被后续改写节点处理。
- 任务是否进入人工复核、降级策略或交付阻断状态。
这些字段决定了后续能否排障和复盘。一次失败的任务，根因可能落在资料召回、审稿规则、改写继承或交付检查上，而不一定是模型调用报错。工具选择要先服务这组问题。
3. LangSmith：开发期调试和评估更顺手
LangSmith 来自 LangChain 体系，和 LangChain / LangGraph 的开发体验贴得更近。官方文档把 observability、evaluation、prompt engineering 放在同一套工作流中，并提供面向 trace、监控指标和 eval 的能力。
在 Agent 项目里，LangSmith 更适合放在开发和实验阶段：
- 调试 LangGraph 节点：资料召回、结构生成、审稿、改写、交付检查各自的输入输出可以按运行链路查看。
- 对比 Prompt 版本：同一批任务样例可以反复跑，观察审稿命中率、改写质量和事实核验失败类型。
- 定位失败节点：当产物没有通过交付检查时，开发者可以沿 trace 回看是检索、规划、生成、审稿还是改写环节出了问题。
- 组织评估集：把典型场景、典型资料类型、典型审稿问题整理成 dataset，用于回归 Prompt 和模型版本。
需要收紧的是数据边界。任务 trace 里可能包含未发布产物、内部资料、客户需求、审稿意见和 Prompt。若生产流量直接写入第三方平台，团队需要先判断哪些字段可以外发，哪些字段只能保留摘要、脱敏值或内部 ID。
4. Langfuse：多框架和产品级观测更完整
Langfuse 的定位更偏开源 AI engineering / LLM observability 平台。它支持 trace、prompt、score、dataset、experiment、用户反馈和成本延迟等观测维度，也提供自托管路径。对于同时使用多种框架、多个模型供应商或多条业务线的团队，这种组织方式更容易沉到产品运营和质量分析里。
在 Agent 项目里，Langfuse 适合承载这些问题：
- 某个 Prompt 版本上线后，产物采纳率、返工率和人工复核率是否变化。
- 哪些场景更容易触发事实核验失败，失败集中在资料来源、数字引用还是案例归因。
- 用户反馈、人工评分、模型成本、延迟和 trace 能否放在同一处观察。
- 多个 Agent 实现并存时，是否还能用统一的 trace 和 score 模型比较质量。
Langfuse 的优势包括调用链查看，也包括把 LLM 应用中的 trace、score、feedback 和 prompt 管理放进同一套分析对象。对 Agent 系统来说，这更接近线上质量运营：看单次失败，也看一批产物、一类场景、一个 Prompt 版本的长期趋势。
5. 自建 tracing：生产主账本要贴近业务字段
如果系统已经承载真实产物，尤其涉及内部知识库、客户资料、未发布内容或敏感 Prompt，自建 tracing 仍然有必要。它的价值来自对任务一等字段的直接建模，而不只是少接一个平台。
一个任务 trace 可以显式记录：
typescript
type AgentTrace = {
taskId: string;
productId: string;
sceneId: string;
planVersion: string;
promptVersion: string;
model: string;
sourceIds: string[];
officialSourceRatio: number;
reviewBlockingCount: number;
rewriteCount: number;
deliveryCheckStatus: "passed" | "blocked" | "needs_review";
degradedReasons: string[];
};这些字段如果只塞进通用平台的 metadata，后续查询、告警和权限控制都会受平台模型影响。自建时，它们可以成为数据库列、指标维度和告警条件：
officialSourceRatio低于阈值时，交付检查直接阻断。reviewBlockingCount连续升高时，回看审稿 Prompt 或场景资料质量。rewriteCount过高时，定位结构、产物和审稿之间的指令冲突。degradedReasons集中出现时，评估是否需要切换模型、检索源或人工复核策略。
OpenTelemetry 的 trace 模型适合描述请求里的 span 关系；Agent 系统还需要补上业务维度。更稳妥的做法是让通用 span 负责运行链路，让业务 trace 负责产物质量和交付治理。
6. 组合策略
对 Agent 项目，可以按阶段分层：
| 阶段 | 推荐方案 | 关注问题 |
|---|---|---|
| 本地开发 | LangSmith | LangGraph 节点输入输出、Prompt 调试、失败链路定位 |
| 实验评估 | LangSmith / Langfuse | Prompt、Retriever、模型版本和审稿规则的对比 |
| 线上观测 | Langfuse 或自建 tracing | 用户反馈、人工评分、成本、延迟和质量趋势 |
| 生产主账本 | 自建 tracing | 敏感数据、采样策略、业务字段、权限和告警 |
这个分层能减少两个风险。第一，开发者不必从零搭建所有调试工具，早期可以借助平台快速看到 Agent 链路。第二，生产数据不会完全锁在工具模型里，关键字段仍然留在自己的数据库、指标系统和告警策略中。
7. 小结
LangSmith、Langfuse 和自建 tracing 对应的是三类工作：研发调试、产品级 LLM 观测、生产数据治理。Agent 项目要同时面对节点调试、质量评估、用户反馈、成本控制和敏感数据管理，单一工具很难覆盖全部边界。
更实际的起点是先定义自己的任务 trace：资料来源、结构版本、Prompt 版本、审稿问题、改写次数、降级原因和交付检查状态。工具可以替换，业务字段需要尽早稳定下来。只要这些字段稳定，LangSmith 或 Langfuse 都可以作为观察和实验工具接入；生产主账本则继续承载长期排障、合规和质量改进。
一句话总结：先定义任务 trace 的业务字段，再让 LangSmith 管开发调试、Langfuse 管线上观测、自建 tracing 管生产主账本。