# Agent 黑盒拆解术：基于 Langfuse 的 Trace、Token、Tool Call 可观测

> **合规声明（生成式 AI 服务）**：前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。
> 
> **完整资料：如果想了解更多内容可以访问:https://events.amazoncloud.cn/china-summit-on-demand/
> 
> **免责声明**：本摘要仅为便于您了解峰会内容而提供，我们不对其完整性及准确性作出任何保证，且不构成任何建议或结论。相关内容仅供参考，实际内容以峰会回放视频为准。

## 一、基础信息

- **会议类型**：专题演讲
- **Persona**：数据团队
- **时间信息**：6月23日 | 15:30 - 16:00
- **标题**：Agent 黑盒拆解术：基于 Langfuse 的 Trace、Token、Tool Call 可观测
- **PDF 资料**：有
- **视频回放**：有

## 演讲人信息

### 会议信息
- **地点**：上海世博中心（2026 亚马逊云科技中国峰会）
- **日期**：2026年6月23日（Day 1）
- **时间**：15:30 - 16:00
- **会议类型**：专题演讲
- **面向 Persona**：数据团队

### 客户 / 合作伙伴演讲人
- **王天宜**（ClickHouse Inc.）：资深解决方案架构师

## 二、会议资料 PDF 转录内容

--- Page 1 ---
2026年6月23日-24日 上海·世博中心

--- Page 2 ---
Agent 黑盒拆解术：
基于 Langfuse 的
Trace、Token、Tool Call 可观测
ClickHouse 王天宜 Senior Solution Architect

--- Page 3 ---
Agent 使用是大势所趋，管控迫在眉睫

--- Page 4 ---
A g e n d a
01
Agent 可观测的挑战
目录
02
Langfuse 可观测能力
ClickHouse × Langfuse · Agent Observability
03
ClickHouse 数据底座
04
客户实践

--- Page 5 ---
Agent 上线那天，
你的可观测体系悄悄失效了
01 月底账单来了：模型费用是预估的 3 倍。
02 你打开可观测系统：延迟正常，错误率正常，一切绿灯。
03 但没有一个工具能告诉你：钱花在哪里了，为什么。

--- Page 6 ---
一次机器巡检，四个阶段全程不可见
目标 完成服务器全面巡检，发现潜在问题并给出处理建议
阶段 01 阶段 02 阶段 03 阶段 04
提出需求 修改意见 多工具执行 质疑结果
构思方案 确认方案 完成巡检 深入探索
用户 → AGENT 用户 → AGENT AGENT → 执行 用户 → AGENT
• 提出巡检需求 • 调整巡检重点 • 调用多工具巡检 • 用户对结果提问
• 确定巡检范围 • 明确执行顺序 • 发现异常自主扩展 • 结合上下文深入分析
• 共同制定方案 • 确认后开始执行 • 输出巡检结果 • 给出修复建议

--- Page 7 ---
传统工具不是「不够好」，
而是为另一种系统设计的。
把 APM 套在 Agent 上，就像用温度计量体温。
动态路径 成本不透明 静默偏差 多轮交互
执行路径运行时生成， 每次模型决策都在消耗 成功返回，但结论是错 多轮对话都在累积上下
无法提前埋点，每次运 预算，上下文滚雪球， 的，用户已被误导，系 文，长文本、海量数据，
行都是一条新路 但你看不到钱花在哪 统浑然不知 传统工具根本撑不住

--- Page 8 ---
Agent 可观测策略
Agent 三步策略，形成闭环
01 02 03
发现 排查 沉淀
报警 Trace 下钻 知识库
Dashboard Trace 评估 Agent

--- Page 9 ---
Langfuse
01
宏观看链路，微观看调用
链路追踪
宏观 + 微观，Token 多层汇总
不仅是更好的 APM,
更是一套专为 Agent 设计的
可观测体系。
02
AI 比人更了解 AI
质量评估
基于 Langfuse，三大能力打通 Agent 可观测 LLM + 人工 双轨评分，识别静默偏差
02
03
开发与用户提示词解耦
提示词管理
版本独立 · A/B 测试 · 业务热更新

--- Page 10 ---
Langfuse，三个核心能力
动态链路难以追踪 静默偏差 提示词依赖研发
成本无法衡量 质量难以衡量 业务无法自主迭代
↓ ↓ ↓
链路追踪 AI 质量评估 提示词管理
看见链路全貌 AI 比人更了解 AI 开发与用户提示词解耦
宏观：User → Session → Trace LLM 与人工标注双轨评分 Prompt 与代码分离，版本独立管理
微观：Trace → Generation → Span 识别静默偏差，量化输出质量 A/B 测试驱动，效果数据说话
Token 多层汇总，成本一目了然 多维评估：完整性 · 正确性 · 有害性 业务自主热更新，无需研发介入

--- Page 11 ---
看见故事全貌
机器巡检案例 · User → Session → Trace → Span
宏观视角 User · Session · Trace 微观视角 Trace 3 · 内部解剖
User James Gen 1 理解指令，拆解 7 个执行步骤 $0.002
↳ SPAN - 执行身份确认
Session 下午巡检工作
Gen 2 确认当前用户身份 $0.0007
Trace 1 「我想巡检这台机器」
↳SPAN - 扫描可登录用户列表
Trace 2 「公网可达，无备份，均衡模式」
Gen 3 检查各用户文件数量 $0.004
Trace 3 「一步步安全审计（7 步骤）」
↳SPAN - 遍历用户目录文件
Token 雪球：3 次对话从14.8K 滚到30.6K，成本翻5×
14.8K Gen … 综合所有步骤，生成完整安全风险报告 $0.060
22.2K
↳ SPAN - 最后一步 token 爆发至 30,571，花费 $0.060
30.6K
3 次对话，用户意图逐渐清晰，Agent 执行质量随之提升
11 个 Generation，每步 span 可追溯，token 逐步累积

--- Page 13 ---
Trace 质量评估，传统 vs Agent
请求有没有完成 Agent 做得对不对
传统 Trace 质量评估 Agent Trace 质量评估
• 状态码：200 = 成功，500 = 失败 • 执行完整性：Agent 是否真正完成每一步
• 延迟：响应时间是否超阈值 • 推理正确性：结论是否有逻辑支撑
• 关键词搜索：日志里有没有 error • 工具调用质量：工具结果是否被正确使用
• 指标告警：错误率、P99 超线报警 • 语义相关性：输出是否真正回答了问题
轨迹检测、幻觉检测、有害性检测、简洁性、一致性、
帮助性、上下文利用率、合规、效率、越界检测、情感一致性

--- Page 14 ---
用 AI 评估 AI Agent
LLM as a Judge · Langfuse
难以定量 双轨评估
Agent 输出质量评估 LLM as a Judge & Human Annotation· Langfuse
LLM 自动评估
• 维度繁多，难以全面覆盖
阅读完整 Trace，按维度自动打分，多维度评估
• 语义判断，规则无法穷举
• 没有标准答案，对错难界定 人工标注
• 人工标注成本高，无法规模化 审阅关键样本，纠偏校准，保证准确性
同样是 HTTP 200，完整性评分从 0.20 到 0.95 —— 只有 LLM 才能看出这个差距
Trace 2 质量偏低 Trace 1 部分完成 Trace 3 高质量完成
发现漏洞，建议不完整 0.20 规划了方案，未执行工具 0.65 多步执行，完整风险报告 0.95

--- Page 18 ---
提示词管理，让业务自主迭代
Agent
VIBECODING.md
SKILL.MD RAG.MD
# 1. 角色定义 通过 HTTP 拉取
你是{{department}}的工程助手，服务对象工程师。 production 版本
SOUL.MD PLANNER.MD 默认使用我们的技术栈与内部约定作答，不必每次重新解释。
# 2. 部门知识库
回答前参考以下检索到的部门资料：{{retrieved_context}}
VIBECODING.md ToolRouter - 仅依据知识库和用户提供的信息作答
- 涉及指标口径、接口规范时，以知识库为准。
# 3. 回答风格
- 先给结论，再给理由。
- 涉及代码必须给出可运行示例，并标注文件路径。
Langfuse Prompt 管理中心
- 默认中文；专有名词、命令、报错保留英文原文。
- 不确定就直说不确定。
# 4. 单测回归流程
VIBECODING.md
当涉及代码改动时，按以下流程提醒并给出命令：
版本管理
1. 角色定义 - 改动 src/ 下代码后：运行`npm run test:unit`
标签管理
2. 部门知识库 - 提交前执行全量回归：`npm run test:regression`
上线管理
- 新增功能必须配套单测，覆盖率不得低于现状
3. 回答风格
A/B Test
- 测试失败时先修复，不要绕过用例
4. 单测回归流程

--- Page 20 ---
01
成本管控
列存 + LZ4/ZSTD，对象存储
压缩
10x+ 压缩比 · 存储成本骤降
ClickHouse 引擎能力，
天然降低可观测成本。
02
向量化引擎，大数据集秒级响应
压缩 · 查询 · 宽表，三大引擎能力联动降 TCO 查询
SIMD 并行 · 列裁剪 · 节省查询资源
03
03
原生 MCP 协议，Agent 框架
Agent
协议标准 · 框架无关 · 自然语言分析

--- Page 21 ---
ClickHouse 为查询提供极致性能
37x faster 20x faster Data analytics
loading data querying data on JSON
• Results are publicly available at benchmark.clickhouse.com and https://jsonbench.com/

--- Page 22 ---
ClickHouse 存储成本降低至 5%
100% 去掉行存冗余（_source） 稀疏索引 ZSTD + 列编码 TTL 冷热分层
不存_source 冗余 每8192 行一个点 LZ4 / ZSTD 压缩 热→SSD
只保留列式数据 替代传统倒排索引 Delta · Gorilla 编码 冷→OSS 低至1/50
行存冗余（_source）
节省~40% 空间 索引体积↓80% LowCardinality 字典
60% ↓
50% ↓
列式存储
列式存储
ZSTD 压缩
ZSTD 压缩
列式存储
ZSTD · Delta · 字典
10% ↓
倒排索引
倒排索引 5% ↓
去掉行存冗余（_source） 列式+ ZSTD
► 稀疏索引替代 ► ► Delta · LowCardinality ►
稀疏索引
冷热数据分层
传统行存数据库 去掉行存冗余（_source） 稀疏索引替代 ZSTD · Delta · 字典编码 冷热分层存储
降低存储空间占用 降低单位空间成本

--- Page 23 ---
数据模型演进
Langfuse v3 → v4 从双表 JOIN 到单一不可变宽表
v3 v4
Mutable · 双表 + JOIN Immutable · 单一宽表
Traces (mutable) Observations (immutable)
user_id name
Observations (mutable)
session_id start_time
name
metadata end_time
start_time →
input input
end_time
output output
input
... ...
output
user_id formerly on trace
...
session_id formerly on trace
trace_metadata formerly on trace
... more from traces
JOIN required

--- Page 24 ---
ClickHouse 原生支持 AI Agent 集成
三种方式，让 AI Agent 直接访问和分析数据
MCP Server 12 种 Agent 框架 Ask AI Agent
Agent 原生接入 完整生态覆盖 Claude 开箱即用
• MCP 协议：列表、Schema、查询 • LangChain · Claude Agent SDK • 自然语言描述分析需求
• Remote：Cloud 托管，零基础设施 • OpenAI Agents SDK · CrewAI • 自动生成 SQL 查询
• Self-managed：PyPI 安装，本地部署 • 均通过 MCP Server 连接 • 自动生成可视化图表或摘要
• Claude · ChatGPT • 完整 Agent 集成指南 • 无需编写任何代码

--- Page 27 ---
04 01 国内一线新能源车企
内部 Agent 中台
规模化 AI 治理
8000+ Agent · 1 万员工日活
02 国内头部手机厂商
Claude Code
研发效能可量化
Token 节省 20%+ · 效能 +30%
客户实践
03 国际头部交易所
Agent 钱包 / 客服
三个场景 · 三种业务价值 · 同一套观测底座
金融级合规与诊断
规模化治理 · 研发效能 · 金融合规 百万 spans/s · 全链路回溯

--- Page 28 ---
C U S T O M E R C A S E B U S I N E S S V A L U E
内部 Agent 中台
平台治理可量化
看清每个 Agent 的使用、质量、投入产出
使用率监控 · 质量评分 · ROI 排名
国内一线新能源车企 · Langfuse 监控 内部 Agent 中台 平台
上万 Agent 同时在跑，可观测是规模化 AI 的业务底座 低价值 Agent 及时下线，资源向高价值倾斜
8000+ 1 万+ PB+
成本可分摊可解释
Token 消耗精确归集到部门 / Agent / 用户
内部 Agent 平台治理 员工日活渗透 累计 trace 数据沉淀
部门归因 · 项目预算 · 月度对账
从「平台烧钱」到「业务部门买单」
内部 Agent 中台 跑得动是技术挑战，跑得明白是管理挑战。
Langfuse 让我们能向 CEO 解释 AI 投入产出。
LANGFUSE × 内部 Agent 中台 · 让 AI 平台从黑盒到透明
— 内部 Agent 中台技术负责人
Tracing · Cost Attribution · Evaluation

--- Page 29 ---
C U S T O M E R C A S E B U S I N E S S V A L U E
Claude Code
续费扩容有据可依
每位工程师、每个团队的真实使用画像
人均产出 · 接受率 · 团队对比
国内头部手机厂商 · Langfuse 监控 Claude Code 使用
续费谈判、资源调配、最佳实践沉淀
万名工程师 Seat 每年百万级支出，没有数据就没有决策
提示词工程可优化
500+ 20%+ 30%+
把个人最佳 Prompt 变成组织资产
单研发日均 trace Token 成本节省 研发效能提升
模板沉淀 · A/B 测试 · 效果回流
高效 Prompt 模式快速推广，整体接受率提升
给工程师买 Seat 是支出，看清 Seat 的回报才是投资。
Langfuse 让 CFO 信任研发投入。 LANGFUSE × CLAUDE CODE · 把研发支出变成投资决策
Tracing · Prompt Eval · Usage Insights
— 研发效能平台负责人

--- Page 30 ---
C U S T O M E R C A S E B U S I N E S S V A L U E
Agent 钱包 / 客服 合规与审计就绪
每次 Agent 决策可追溯、可解释、可呈送
操作留痕 · 决策回放 · 监管报告
国际头部交易所 · Langfuse 监控 客服 + 钱包 Agent
满足金融监管要求，规避天价合规罚单
金融场景下，Agent 不能是黑盒，可观测就是合规
百万+/s 分钟级 全链路 用户信任可量化
客服质量与异常案例持续监控
Trace 写入吞吐 异常 trace 回溯 细粒度诊断维度
质量评分 · 多语言对比 · 投诉溯源
“投诉处理从天到秒，用户留存与口碑提升
金融监管要求 AI 决策可解释、可追溯。
Langfuse 把 Agent 风险从「看不见」变成「可治理」。 LANGFUSE OBSERVABILITY · 金融级合规与可信赖 AI 基础设施
Tracing · Audit Trail · Quality Eval
— 平台 SRE 负责人

--- Page 31 ---
Thank you

## 三、会议回放视频转录内容

大家好，我叫王天宜来自于 ClickHouse
很高兴能在亚马逊云科技峰会上和大家一起来讨论 Agent 可观测的话题
我相信在过去的一年中很多团队已经把 Agent 应用到生产环境中了
那我今天要讲的不是怎么让 Agent 跑起来
而是在 Agent 跑起来之后，我们怎么让 Agent 跑得更好
我们要看清楚 Agent 的内部都做了什么样的工作
那我们先来看一组新闻
左边的是 Uber 和 Microsoft 都在使用 Claude
但仅仅半年的时间就已经花光了全年的 Quota
中间是业界某 AI 平台创始人在一次访谈上提到的
他们一个三个人的团队在一个月就花光了1.3M 的 Token
那右面这个是 Vibe Coding 的一些安全漏洞
我们都知道现在通过一些 Vibe Coding 的工具
我们没有办法再对每一行代码都掌握得非常清晰
所以或多或少的都有一些未知的逻辑
或者是有一些安全的隐患
那如何避免这些问题呢
所以今天我来总结一个话题
Agent 的使用已经是大势所趋
但是对 Agent 的管控却迫在眉睫
那今天我主要会从四个方面来展开介绍
我们如何构建一个健壮的可观测系统
首先我们来看一下 Agent 可观测它的挑战
它与传统的 APM 可观测有什么不同的地方
为什么说我们不能拿传统的可观测
这一套系统套在 Agent 可观测上面
第二章我会来讲一下 Langfuse 这款产品
它是如何帮助我们去构建一个健壮的可观测系统的
那再下探一层的话 ClickHouse 作为 Langfuse 的底座
它是如何帮我们去降低存储的成本的
最后我也很开心的能和大家一起来分享一下
国内的一些知名的公司在使用 ClickHouse 和 Langfuse
去做 Agent 可观测的案例
我们先来看第一个话题
我们先讲挑战
我把它总结成一句话就是
当我们 Agent 上线的那一天
可观测系统悄悄的失效了
给大家描述一个场景
大家应该都感同身受
就是当我们月底的账单来的时候
我们发现模型的使用费用是预估的三倍
我打开了我的可观测系统
我看到延迟是正常的
错误率也是正常的
一切都是正常的
但是并没有一个系统能够告诉我们
钱花在哪了
为什么花在这
所以今天我会使用一个案例贯穿始终
我让 Agent 去帮我做一次机器的巡检
那总体来总结的话
会分成四个阶段
首先我会和 Agent 提出我要巡检的需求
Agent 帮我去给出一个草拟的方案
在第二个阶段中
我会针对于 Agent 的草拟的方案
去进行一些修改
我告诉他要调整一些巡检的重点
调整一些巡检的顺序
那 OK 在第三个阶段我告诉他
你按照我们确定的这个方案
就一步一步的执行就好了
Agent 他执行了半个小时
那最后 Agent 他给我产生了一个报告
在第四个阶段的时候我拿到这个报告
我看到今天下午三点钟的时候
我的 SSH 端口遭受了3000多次的攻击
为什么是这样的
我在跟 Agent 他有一轮交互
我不确定是什么原因
我希望 Agent 能给我一个解释
那我们可以看到在这样的一个流程中
其实传统的可观测漏掉了很多内容
传统的可观测更多的是会关注
会看一个请求进来了
一个响应出去了
响应了多长时间
但是其中最重要的大模型是怎么推理的
大模型调用了什么工具
这半个小时当中
第一分钟第二分钟都在干了什么事情
花了多少 token
这个事情是我们不知道的
所以其实并不是说传统的
APM 这一套可观测不够好
而是说当我们把 APM 可观测套用在
Agent 的可观测上面就好像说
我们在用温度计去量体温
这完全就是两套独立的系统
差别在哪呢
我总结了四个点
首先是我们面临的第一个问题
动态路径的问题
在 Agent 的执行的过程中
路径是动态生成的
我们是没有办法提前去预知
哪些地方要去埋点
所以每一次 Agent 的执行
都是一条新的路径
那第二个问题就是成本不透明
每一次 Agent 的决策的时候
他都要消耗我们的预算
上下文像雪球一样不停的翻滚
但是我们却看不到钱花在哪了
第三个问题也是静默偏差的问题
Agent 的请求给我们返回成功了
但是 Agent 的返回对不对
好不好呢
其实我们都不知道
如果说用户因为一个错误的返回
被误导了
传统的可观测对这个事情也是浑然不知的
最后也是多轮交互的一个问题
因为多轮的交互
所以累积了大量的上下文
长文本
海量的数据
这对于数据存储
这套系统来说是一个巨大的挑战
那应该如何去做呢
其实总结下来就是三步
首先第一步我们要去发现
通过一些 dashboard
通过一些告警
我们去了解到哪出现了问题
什么时候出现了问题
第二步是排查
我们通过各种手段
比如说像 trace 的下钻
或者是 trace 的评估
去知道哪一个环节出现的问题
到底是什么原因出现的问题
第三步是沉淀
基于前两步我们总结出来的方法论
我们希望能够沉淀到知识库里面
并且反哺 Agent 他
让他下一次不要再产生同样的错误
所以在第二个章节中
我会和大家一起来看一下
Langfuse 的核心能力
如何通过 Langfuse 去构建一个
成熟的
可靠的可观测系统
那我们可以说 Langfuse 是
专门为 Agent 设计的可观测系统
它主要有三个核心的能力
链路追踪
质量评估和提示词管理
我们先来看
一张全景图
我们把 Langfuse 的能力和它
解决的问题
以及我们遇到的痛点对应起来了
针对于链路追踪困难
成本没法核算的问题
我们可以在 Langfuse 中
使用 Trace 跟踪的相应的能力
在 Langfuse 中
我们提供两条 Trace 跟踪的链路
从宏观视角上
我们可以看到 User, Session, Trace 的这条链路
清晰的了解到谁什么时间
做了什么事情
从微观的视角上
我们可以下钻 Trace generation
到 Span 的这条维度
把 Trace 拆解开来
我们能够清晰地掌握到
在什么环节
做了什么样的操作
花了多少钱
延迟是多少
针对于静默偏差
质量难以评估的问题
我们可以使用 Langfuse 中的评估器来解决
在 Langfuse 中
我们通过大模型打分
和人工打分两条路径
去为每一条 Trace 进行一个评估
这样的话
我就可以明确的知道这条 Trace
对不对
好不好完不完整
同时我们在研发的过程中
Agent 的研发的过程中
经常会遇到提示调整的问题
提示调整
大部分的时候
我们都要依赖于研发
业务方没有办法自主迭代的
那我们可以使用 Langfuse 提示管理的能力
将 Prompt 与我们的代码
去解耦独立管控这个 Prompt 的版本
我们先来看第一个话题
Trace 链路的追踪
还是以刚才巡检的这样的一个案例
我们可以看到从宏观视角上
我们要看清楚的是谁什么时间
做了什么事情
在这个案例中
我与 Agent 去进行了三轮的沟通
希望 Agent 能帮我去做一次机器的巡检
我们也可以看到在这个请求当中
Token 像雪球一样滚动
尤其是在第三次交互的时候
Token 花费最多
响应时间也是最久的
那所以我们在微观视角上
对第三条 Trace 进行进一步的下钻
我希望能把第三条 Trace 拆解开
我打开 Langfuse 的 Trace 跟踪的页面
我会发现在这个 Trace 中
我们有11个 Generations
在它的第一个 Generations 中
把整个的 Trace 指令拆解开
我们知道每一步都做了什么事情
在中间的步骤
我们可以看到有身份确认的 Span
有用户扫描的 Span
有遍历文件的 Span
每一步花费了多少 Token
花费了多少时间都是可以追溯的
再到最后一步我们可以看到
一共消耗了约 30.6K Token
帮我生成了一个完整的报告
那微观视角的价值就在于
我们能够清晰的洞察
每一个环节做了什么事情
这是 Langfuse 的一个演示的页面
那我们可以看到在这个页面里面
我们能够清晰的看到右半部分
这个我和 Agent 的交互的时候
我的 Input Output
我问了什么样的问题
Agent 给我什么样的反馈
同时我们也可以在左面 Trace 的时间线上面
看到 Trace 在 15-30 分钟的这样一个思考的过程中
他都想了什么事情
他做了什么样的决策
他调用了什么样的工具花费了多少钱
同时在左下角也是我最喜欢的一个功能
我可以看到 Agent 的调用流程图
我可以看到 Span 的调用关系
我可以清晰的了解到
在执行的过程中
他是串行的还是并行的
我是否能够把串行的一个任务
去通过提示词优化
或者是通过一些子 Agent 的方式
去给他变成一个并行的方式
帮助我们把一个半小时的问答
变成一个几分钟的问答
那看完了 Trace 的追踪
我们再来看 Trace 的评估
在传统可观测的体系当中
我们一般都是围绕 Trace 有没有执行展开的
我们比如说通过一些状态码
是200 还是500
或者是我们看 P99、P95 的详细时间
也或者是我们通过一些 Full-text Search 的能力
我们到日志里面看
有没有 error / fatal / exception 这类关键字
去来完成
我们对于 Trace
是否有正常响应的这一个事情
但是这一套方法论
在 Agent 的可观测上面是远远不够的
因为我们不仅要了解 Agent 有没有执行
我们还要了解 Agent 执行的对不对
Agent 执行的好不好
所以在 Agent 的可观测这个场景下
我们对 Trace 进行评估的话
可能有几十个甚至是几百种维度
比如说我们要去看 Trace 执行的完整性
看推理的正确性
看工具的调用质量或者是看 Trace 在执行过程中
它的语义相关性
在 Langfuse 中我们预置了几十种 Trace 的评估器
同时我们也可以根据自己的业务
通过写提示词的方式
去自定义创建我们业务的评估器
那么维度这么多
标准评估的标准又不统一
我们去如何更好的评估呢
在 Langfuse 中
我们提供了两种评估的方案
我们可以通过大模型去阅读 Trace 的输出
根据我们预先在提示词里头创建的规则
给每一条 Trace 进行打分
同时如果我们企业内部有一个
比较复杂的评估的流程
那我们也可以基于我们企业内部
已经成熟的代码或者成熟的脚本
去创建一个 workflow
在 SDK 里面调用这个 Workflow
给我们的 Trace 进行打分
我们可以看到同样都是 HTTP200 的返回
其实在 APM 的可观测里面是一模一样的
但是在 Agent 的可观测里面
我们可以看到不同的视角
我们针对于完整性的话
可以有不同的评分
比如说我们发现了一些漏洞
我们看到 Agent 给我返回的结果
是不太完整的
我可以给它打一个0.2 的分数
这是一个偏低的分数
当我们像刚才一样
把整个的巡检的流程拆成了7步
每一步都有明确的指令
最后也生成了一个非常完整的报告的时候
我会给它一个比较高的分数
0.95 的这样的一个高分
可以看到在这个配置页面里面
就是 Langfuse 的评估页面
我们通过写提示词的方式
去给 Trace 定义了一个评估器
在这里面我写了一个完整性的评估器
在最开始的地方
我定义了用户的 Input 和 Output 的输出是什么
在中间的部分我去定义了
我是怎么去打分的
我打分有四个步骤
第一个 第二个 第三个 第四个步骤
是什么样子的
在最后的过程中
我在提示词里写清楚了
我打分的标准是什么样子的
提示词的评估器定义清晰了以后
我可以在 Trace 的详情页面里面看到
基于提示词的打分
我们可以看到在这个页面里面
有两个提示词的打分结果
一个是我刚才定义的
完整性的提示词评估器
因为在这个过程中
它被在这个巡检的过程中
它被拆成了
11个 Span 总共分成7步来进行巡检
所以它是一个非常完善的巡检过程
它有一个0.95 的分数
同时我也基于内置的
危害性的评估器去进行了一个打分
我发现
整体上的巡检过程
没有访问一些敏感的文件
同时也没有一些
比如说`rm -rf`这样的一些危险的操作
所以它的危害性是0
我们也可以在 Langfuse 的 Dashboard 里面
去看一个综合的
巡检的指标
评估的指标
我们可以看到
这是不同的评估器的一个结果
当然我们在 Langfuse 里面
也定义了十几种
甚至是几十种评估器
我们也可以把不同评估器串起来
去看到打分的一个
交叉的分析的结果
那讲完了 Agent 的质量评估
我们来开始看第三个话题
在 Langfuse 中
我们是如何做提示词管理的
当我们的业务
比如说我们的 PM
我们的运营
发现一个提示词要改的时候
他们是动不了手的
他们要给研发提需求
这样的一个发版迭代
一般来说
至少得数天或者是数周
在 Langfuse 中
我们就提供了提示词管理的能力
这本质上是一个注册中心
我们把我们的提示词的版本放在里面
同时我们也可以在这个注册中心里面
去做一些 A/B Test 的
热更新的一些操作
比如说我们在 Agent 使用过程中
我们需要定义不同的提示词
像一些 Skill 文件（SKILL.md）
或者是某 AI 平台的 SOUL.md
或者是在 Vibe Coding 中
比如说 Claude Code
我要定义`CLAUDE.md`的文件
等等我们都可以使用 Langfuse 的提示词管理中心
去托管这些文件
右面是我真实的
我的 Claude Code 定义的 Md 的文件
我们可以看到在这个文件里头
我为我的 Claude Code 去定义了
它的角色是什么
我们部门的知识库是什么
我的回答的风格是什么
当我用我的 Claude Code
去生成一些代码的时候
我也定义了
我的单测还有回归的流程是什么
这些事情都可以在 Langfuse 中
去进行托管
同时我们也当我去把这个文件
放在 Langfuse Agent 的
这些 Md 文件管理中心的时候
我可已经过 A/B Test 反复的测试
我选择到一个最优的提示词
在这里面
我对我的提示词做了一个 A/B Test
基于不同的属性
基于不同的变量
还有不同的提示词回答的流程
我针对于同样的一个问题输入
我可以看到两个截然不同的回答
我们可以基于完整的 A/B Test 的测试
挑出来一个我最满意的提示词
定义成上线的版本
这样我们就在 Langfuse 完成了
整个提示词的修改测试
以及发版的完整闭环
再往下沉一层
我们可以看一下
Langfuse 的底座 ClickHouse
在可观测的场景中
其实我们最大的隐性成本
就是数据本身
Agent 会产生海量的数据
这些数据大多数都是高基数的
底座如果不行的话
我们就可能发现
数据存储的成本往往要比 Agent 的消耗贵
在 ClickHouse 中
我们提供了超过10倍的压缩比
同时我们也提供了
极致的查询性能以及
原生 Agent 接入的能力
通过这样的一些能力
我们把 Agent 的可观测的成本
一步一步降了下来
我们先来看性能的问题
这是 ClickHouse 公开的 ClickBench
宽表测试以及 JSONBench
Json 的性能压测
而 ClickHouse 邀请了
全球超过100多家数据库厂商
去进行测试
我们一直是长期占据榜首的
相比于传统的数仓
ClickHouse 在宽表测试的场景中
无论是查询还是导入
都有十几倍
甚至是几十倍的性能提升
在 Json 分析的场景下
对应 JSONBench
这也刚好就是 Trace 查询应用场景
ClickHouse 也为 Langfuse 提供了
秒级甚至亚秒级的 Trace 下钻
以及指标聚合的能力
存储层面上
ClickHouse 也通过各种手段
一步一步的把存储空间压下来
比如说我们通过一些
减除非必要的行索引
通过稀疏索引去进行加速
在 ClickHouse 中
我们也默认使用 ZSTD
高压缩比的方式
对列的数据去进行压缩
同时我们对于一些长 JSON
长文本的方式
我们也使用
字典编码的方式
能把压缩比降到0.1
在云上的话
我们是基于 S3 做数据存储的
避免了数据的多副本存储
进一步的降低了数据的存储成本
至高的话
可以相比于传统的数仓
我们提升了50多倍的存储成本的优势
配合 ClickHouse 的宽表演进
Langfuse 自己的数据模型
也是在迭代的
如果我们之前用过 Langfuse 的话
应该了解到 Langfuse 中
其实是有两张主要的表
一张是 Trace 表
一张是 Observation 表
在我们 Langfuse 查询的页面里面
这两张表是要做 JOIN 的
但在 ClickHouse 的使用过程中
其实 JOIN 是一个比较昂贵的事情
在 LangfuseV4 的版本中
我们直接把这两张表去
打成了一张宽表
原来我们在 Trace
还有 Observation 上面的一些 JOIN 的操作
一些更新的操作
就可以完全的消除掉
这也是专门为 ClickHouse 宽表模型
量身定做的一个修改
那接下来我们来看 ClickHouse
作为 Langfuse 底座的最后一个特点
就是我们原生的去支持 Agent 的集成
ClickHouse 在 Agent 的集成上面
有三种方式
第一种我们是有原生的 MCP 的协议
那如果我们协议内部
有一些自定义的 Agent
我们可以基于 ClickHouse 的 MCP 协议
去做比如说像 Schema 的查询
Query 的查询
那同时 ClickHouse 也对接了
超过12种的 Agent 的框架
比如说像 LangChain
比如说像 Claude 的 Agent
SDK 或者是 OpenAI 的 SDK
那如果我们在云上的话
使用全托管的 ClickHouse
我们也有开箱即用的 Agent AI 的能力
我们直接使用自然语言去
描述我们的输入
我们可以直接将自然语言生成 SQL
并且基于我们 SQL 返回的结果
去生成图表和摘要
整个流程中
一行代码都不需要写
给大家来看一个这样的体验
我直接在 ClickHouse 里面
去通过我们原生的 MCP 接口
我们原生的 Agent
去跟 ClickHouse 去做对话
我希望能够帮我看一下
在某一个数据库里面
都有什么样的数据
它存在一些什么样的业务洞察
是我们可以分析的
那可以看到
ClickHouse 的 Agent
它直接给我告诉我
这样的数据库
都有什么样的信息
它下面有什么样的表
这些表都存储什么样的数据
经过这样的分析
我可以再跟 Agent
去进行一轮交互
我说你刚的分析结果还不错
我希望按照
三种方式
就是我们基于 ClickHouse 的基于 Agent 的 Behavior
再基于 Security
这三个不同的维度
帮我去整理出来一张 Dashboard
那我们可以看到
我们的 Agent 马上就去
一分钟
就帮我们把 Dashboard 展示出来
那在最后的一个章节中
我很开心能跟大家一起来分享学习
三个真实的用户场景
那我们总结了一下
Langfuse 在三个比较大的 Agent 的业务使用场景中
有着广泛的应用
第一个场景是像内部 Agent 中台
像 Hermes 或者像 Boot 这样的
接入的使用场景
那第二个场景是 Vibe Coding 的场景
现在头部的互联网公司
比如说他们使用 Claude Code
比如说他们使用 Cursor
还有像 Codex 都可以接入到 Langfuse 当中
那第三个也是
如果企业内部他们有自定义的 Agent
比如说像一些客服钱包
他们也都可以基于原生的 OpenTelemetry 的协议
把这一部分可观测数据
导入到 Langfuse 中去做 Agent 的洞察
我们先来看第一个案例
这是一个国内一线的新能源车企
他们有上万个 Agent 在同时跑
在这家车企里面
我们有8000多个内部 Agent 中台的 Agent 需要治理
员工日活的话大概有超过1万的渗透
同时在 ClickHouse 中
我们累计的 Trace 的数量是 PB 级别的
那基于 Langfuse 去给他们做内部 Agent 中台的治理的话
我们可以清晰的感知到
每一个内部 Agent 中台 每一个 Agent
他在做什么样的应用
他反馈的质量是什么样的
他回答的对不对好不好
并且我们可以基于我们的 Token 的分析
我们基于我们 Trace 的分析
清晰的了解到投入产出比 ROI 是什么样子的
同时我们也可以基于 ClickHouse 内部成熟的数据
去做一些综合的 Dashboard
我们能够清晰的去归因到
每一个部门它的成本消耗
它的月度结算
它的账单是什么样子的
这个案例是国内某家头部的手机厂商
他们接入 Claude Code 的一个应用案例
在这个厂商他们大概有数万名的工程师
在使用 Claude Code 的
这些 Seat 的话
一年大概有数百万的支出
没有数据的话就没有办法继续在做
我们的 Vibe Coding 的决策
到底我们的这一部分投入是不是值得的
我们要不要进一步的在 Vibe Coding 上面
去做更多的投入
给出这样的一组数据
一个研发每天要跟 Claude Code 的
或者是 Vibe Coding 的工具交互大概500多次
每一次交互的话
可能十几分钟到几十分钟
它会产生基本上是100个 Span
我们通过 Langfuse 去对这500多个
Trace 去进行监控的话
成功的帮这家手机厂商
节省了超过20% 的 Token 成本
并且我们帮助他们去提升了
30% 的研发的效率
比如说在成本节省的这个角度上
我们通过监控每一个人 Cache 的使用率
我们去监控每一个 Seat
它的 Context 切分的程度
我们能够将整个 Token 的成本打下来
同时我们也去监控
它整个 Trace 在 Session 的过程中
是不是并行去调用一些子 Agent 的帮我们
去进行开发
我们将研发的效率提升上去
在第三个案例中
是国内某一家头部的 Web3 交易所
他们把 Langfuse 应用在了 Agent 的客服
Agent 的钱包上面
这家交易所已经全线的使用 Agent
去进行链上的交易
在金融场景里面有一句话说的是
Agent 它不是一个黑盒
Agent 本身它的可观测
就等同于合规
数据也是相对来说比较硬核的
在这家交易所里面
我们每秒钟大概有超过百万条的 Trace 产生
针对于整个链上交易的异常分析
我们可以达到分钟级别
对于整个链上的比如说交易套利
这样的一些分析
我们可以实现全链路的监控
所以从合规上面我们做到了
操作留痕决策回放
同时基于这样的一个质量评分
也获得了用户的信任
以上是我今天的分享
还是回到最开始的那句话
Agent 用起来已经是大势所趋
但其实管控是迫在眉睫的
今天我其实讲完了
我们的挑战是什么
为什么说传统的 APM 可观测
是不能放在 Agent 可观测的场景中的
从能力上我也来描述了
Langfuse 提供了三个核心的能力
链路追踪质量评估
还有提示词管理
在底座上面我也清晰的去分析了
为什么说 ClickHouse 能把我们的成本打下来
如果大家对 Langfuse 和 ClickHouse 的解决方案
更感兴趣的话
我们在一楼大厅里面有一个站台
大家也可以跟我去交流
谢谢大家