- 一、先给一个一句话总览
- 二、图的上下结构：Offline vs Online
- 上半部分：Offline（离线）
- 下半部分：Online（线上）
- 三、逐块解释（从左到右、从上到下）
- ① Datasets（评测数据集）【Offline 起点】
- ② Dataset Runs（离线跑评测）
- ③ Offline Evals（离线评估）
- ④ Deploy（上线）
- ⑤ Observability（线上可观测）
- ⑥ Online Evals（在线评估）
- ⑦ 回流：Online → Offline
- A. Add test cases from real data
- B. Fix Issues
- 四、这张图真正想传达的工程思想
- ❌ 错误认知
- ✅ Langfuse 的正确姿势
- 五、结合你用 LangGraph 的落地建议（非常关键）
- 最省力的接入顺序（现实可行）
- 六、一句话总结
这张图本质上展示的是 Langfuse 围绕「智能体（Agent）/ LLM 应用」构建的一套完整评测与改进闭环，把 离线评测（Offline） 和 在线观测（Online） 串成一个可持续迭代的工程体系，而不是一次性的 Benchmark。
我按 层次 + 流向 + 你做 Agent / LangGraph 时该如何用 三个角度来解释。
一、先给一个一句话总览
Langfuse = 用线上真实 Trace 驱动离线评测集，用离线评测反推模型 / Prompt / Agent 结构改进，再回到线上验证的闭环系统。
二、图的上下结构：Offline vs Online
上半部分：Offline（离线）
用于 可控、可重复、可对比 的评测与回归测试。
下半部分：Online（线上）
用于 真实用户流量、真实复杂性 下的观测、诊断与反馈采集。
三、逐块解释（从左到右、从上到下）
① Datasets（评测数据集）【Offline 起点】
这是 评测用的标准输入集合，来源有三类：
- Happy path
正常、理想的用户输入 - Edge cases
边界情况（歧义、多意图、异常参数） - Adversarial input
对抗输入（诱导、越权、注入、刁钻问法）
👉 本质：“Agent 应该被考什么题”
② Dataset Runs（离线跑评测）
把你的 应用 / Agent / LangGraph 跑在 Dataset 上：
-
同一批输入
-
不同版本的：
- 模型
- Prompt
- Tool
- Agent 编排逻辑
- 代码实现
👉 本质：离线 A/B Test + 回归测试
例如：
- Prompt v1 vs v2
- 单 Agent vs Multi-Agent
- 新 Router 是否引入退化
③ Offline Evals（离线评估）
对 Dataset Runs 的输出进行“打分”：
- Manual Annotation
人工标注（是否正确 / 是否合规） - LLM-as-a-Judge
用 LLM 当裁判（评分、分类、对比） - Custom via API / SDK
自定义规则（JSON schema、数值阈值、正则）
👉 本质：“好不好”要被结构化定义
评测结果 → Fix Issues → 回到 Dataset Runs / Prompt / 代码修改。
④ Deploy（上线）
当离线结果可接受后：
- 部署到生产环境
- 开始接收真实用户请求
⑤ Observability（线上可观测）
这是 Langfuse 最基础、也是你现在最该先接的部分：
- Capture Traces
Trace / Span / LLM 调用链 - Debugging
看每一步为什么走到这个结果 - Manual Review
人工 review 失败样本
👉 本质：Agent 的“黑盒”被拆开
对于 LangGraph 来说：
- 每个 node
- 每次 routing
- 每次 tool 调用
都可以被看到。
⑥ Online Evals（在线评估）
基于线上真实数据做评估：
- Manual Annotation
运营 / 标注 - LLM-as-a-Judge
自动评估真实对话 - Custom via API / SDK
业务规则 - User Feedback
👍 / 👎 / 投诉 / 转人工
👉 本质：真实世界下 Agent 是否真的有用
⑦ 回流：Online → Offline
图中有两条关键“回流箭头”：
A. Add test cases from real data
线上失败 / 高价值样本 → 加入 Datasets
B. Fix Issues
在线 / 离线评估发现问题 → 改 Prompt / 模型 / Agent 结构
这一步是 “评测体系活起来” 的关键。
四、这张图真正想传达的工程思想
❌ 错误认知
- 评测 = 离线跑一次
- 上线后靠感觉
✅ Langfuse 的正确姿势
- 线上 Trace 是黄金资产
- Dataset 是不断生长的
- Eval 是持续自动化的
- Agent 改动必须可回归
五、结合你用 LangGraph 的落地建议（非常关键）
最省力的接入顺序（现实可行）
Step 1｜先做 Observability
- LangGraph + Langfuse
- 全量 Trace
- 先别急着 Eval
Step 2｜从 Trace 里捞失败样本
- 典型误判
- Router 错路
- Tool 误用
Step 3｜把这些样本变成 Dataset
- 少量但高价值
- 覆盖关键 Agent 决策点
Step 4｜LLM-as-a-Judge 自动化 Eval
-
判断：
- 是否答非所问
- 是否越权
- 是否调用了错误工具
六、一句话总结
这张图不是“评测功能介绍图”，而是 一个 Agent 工程化成熟度模型：
从可观测 → 可评测 → 可回归 → 可持续优化。
如果你愿意，我可以下一步帮你：
- 把这张图 映射成 LangGraph 的具体工程模块
- 给你一份 “LangGraph + Langfuse 评测闭环最小实践”
- 或者直接 拆解一个销售 / 客服 Agent 的 Eval 设计
你更想往哪一步深入？