可观测平台

下面按 Skill / Agent / LLM 可观测平台 的角度，汇总最常用的 3 个开源平台：

平台	定位	核心能力	适合你的 skill 观测场景	优点	注意点
Langfuse	开源 LLM Engineering / Observability 平台	Trace、Session、Prompt 管理、Evaluation、Metrics、Dataset、Playground；支持 OpenTelemetry、LangChain、OpenAI SDK、LiteLLM 等集成。(github.com)	适合记录：谁调用 skill、哪个 session、skill 输入输出、LLM 调用、prompt 版本、token、cost、耗时、成功失败。	功能比较完整，既能做观测，也能做 prompt 管理和评测；适合平台化建设。	如果你们主要是纯后端链路监控，可能还需要配合 OpenTelemetry / APM 使用。
Arize Phoenix	开源 AI Observability & Evaluation 平台	基于 OpenTelemetry 的 tracing、LLM/RAG 评测、实验、排障、数据集和 prompt 相关能力。(github.com)	适合记录 skill 内部步骤：字段识别、意图解析、RAG 检索、工具调用、LLM 生成、评测结果。	对 RAG、Eval、Trace 分析比较友好；适合调试和质量分析。	更偏 AI 应用实验、评测和 trace 排障；如果要做业务报表统计，可能需要自己补充数据建模。
Opik	开源 LLM Observability / Evaluation / Agent Tracing 平台	Agent tracing、LLM evaluation、prompt management、production monitoring、dashboard。(github.com)	适合记录 agentic workflow：skill run、内部步骤、工具调用、评测、生产监控。	对 Agent、RAG、生产监控、评测支持比较直接；自托管和 SDK 生态也比较适合落地。	和 Langfuse 能力有重叠，选型时要看你们更偏 prompt 管理、eval，还是 agent workflow 监控。

简单选型建议

你的重点	推荐
想做完整 LLM/Agent 平台，包括 trace、prompt、eval、session、成本	Langfuse
想重点分析 RAG / LLM 质量、评测、trace 排障	Phoenix
想重点观测 Agent workflow、生产监控和评测	Opik

我的建议

如果你们是做 skill 平台级观测，建议优先考虑：

OpenTelemetry 作为底层标准
+
Langfuse / Phoenix / Opik 之一作为可视化和分析平台

其中最稳妥的组合是：

OpenTelemetry + Langfuse

因为 OpenTelemetry 负责统一 trace / span / attributes，Langfuse 负责 LLM、Prompt、Session、Eval 和可视化分析。

span 这个词怎么理解？

在可观测性 / OpenTelemetry 里，span 可以理解为：

一次链路追踪里的一小段执行过程。

如果把一次完整请求看成一条链路 trace，那么 span 就是这条链路里的一个步骤、一个阶段、一次函数调用、一次接口调用或一次工具调用。

比如用户调用一次 xxx skill：

用户请求：帮我生成销售看板

这整次请求可以叫一个：

trace

也就是完整链路，这个 trace 里面会包含多个步骤：

1. 解析用户意图
2. 识别数据字段
3. 调用数据接口
4. 生成看板配置
5. 返回结果

每一个步骤都可以记录成一个 span。

trace: 一次 skill 调用
├─ span: 解析用户意图
├─ span: 识别数据字段
├─ span: 调用数据接口
├─ span: 生成看板配置
└─ span: 返回结果

span 记录什么？

一个 span 通常会记录：

• 这个步骤叫什么；
• 什么时候开始；
• 什么时候结束；
• 跑了多久；
• 成功还是失败；
• 输入摘要；
• 输出摘要；
• 错误信息；
• 相关上下文字段。

例如：

{
  "span_name": "识别数据字段",
  "start_time": "2026-08-12T10:00:00+08:00",
  "end_time": "2026-08-12T10:00:02+08:00",
  "duration_ms": 2000,
  "status": "success",
  "attributes": {
    "skill.name": "ai-dashboard",
    "skill.version": "1.2.0",
    "session.id": "sess_123",
    "user.erp": "zhangsan"
  }
}

---

和日志有什么区别？

普通日志通常是这样：

10:00:00 开始识别字段
10:00:02 字段识别完成

span 更结构化，它天然包含：

开始时间 + 结束时间 + 耗时 + 父子关系 + 状态 + 属性

所以它更适合回答：

• 哪一步最慢？
• 哪一步失败了？
• 一个请求经过了哪些步骤？
• 这个接口调用是谁触发的？
• 这个 skill 的 P95 耗时是多少？
• 哪个版本的 skill 失败率高？

---

一个简单类比

可以这样记：

trace = 一整条流水线
span = 流水线上的一个工序

或者：

trace = 一次完整出差
span = 坐高铁 / 打车 / 入住酒店 / 开会 这些单段行程

---

在你的 skill 观测里

推荐这样建模：

trace_id：一次用户请求 / 一次 skill 调用的全链路 ID

span 1：skill.run
span 2：parse_input
span 3：load_dataset
span 4：generate_dashboard
span 5：save_dashboard

其中 skill.run 可以是父 span，其它步骤是子 span：

span: skill.run
├─ span: parse_input
├─ span: load_dataset
├─ span: generate_dashboard
└─ span: save_dashboard

这样你就能清楚看到一次 skill 调用内部经过了哪些步骤、每一步耗时多久、哪一步报错。

OpenTelemetry 可以理解为一套开源的“可观测性标准 + SDK + 工具链”。

它的作用是：
帮你的系统统一采集、传递和导出这些观测数据：

• Trace：一次请求经过了哪些服务、哪些步骤；
• Metric：调用量、耗时、成功率、失败率等指标；
• Log：普通日志；
• Context：一次请求的链路上下文，比如 trace_id。

一句话：

OpenTelemetry 是用来给系统做统一埋点和链路追踪的开源标准。

---

可监测平台

1. 它解决什么问题？

假设你有一个 skill 调用：

用户请求
  -> OpenClaw
  -> 调用 skill
  -> 调用 LLM
  -> 调用数据接口
  -> 生成结果

你想知道：

• 谁发起的？
• 这次请求的 trace_id 是什么？
• 调用了哪个 skill？
• 每一步耗时多久？
• 哪一步失败了？
• LLM 花了多少时间？
• 数据接口是不是慢？
• 这个 skill 的 P95 耗时是多少？

如果没有统一观测标准，可能每个系统都各记各的日志，很难串起来。

OpenTelemetry 就是用来统一这些数据格式和采集方式的。

---

2. 核心概念

Trace：一整条链路

一次完整请求就是一个 trace。

例如：

trace: 用户生成看板请求

Span：链路中的一个步骤

trace 里面的每个阶段叫 span。

trace: 用户生成看板请求
├─ span: skill.run
├─ span: 解析用户意图
├─ span: 识别字段
├─ span: 调用 LLM
├─ span: 调用数据接口
└─ span: 返回结果

每个 span 会记录：

• 名称；
  -开始时间；
• 结束时间；
• 耗时；
• 成功失败；
• 错误信息；
• 自定义属性。

Metric：聚合指标

例如：

skill 调用次数
skill 成功率
skill 平均耗时
skill P95 耗时
LLM token 消耗
接口错误率

Log：日志

就是普通日志，但可以和 trace_id 关联起来。

---

3. 为什么适合 skill 观测？

因为 skill 调用天然就是一条链路。

例如：

trace_id = 一次用户请求
skill_run span = 一次 skill 执行
step span = skill 内部步骤
tool span = 工具调用
llm span = 模型调用

这样你就能看到：

用户 zhangsan
在 OpenClaw
session_123
调用 bi-dashboard@1.2.0
耗时 18 秒
失败在“读取数据源”
错误原因是接口超时

---

4. OpenTelemetry 本身是不是一个平台？

不是严格意义上的“平台”。

它更像是：

标准协议 + SDK + 采集器 + 导出器

通常架构是：

你的应用
  -> OpenTelemetry SDK 埋点
  -> OpenTelemetry Collector 收集和转发
  -> 后端观测平台展示

后端平台可以是：

• Jaeger
• Grafana Tempo
• Prometheus
• Grafana
• Datadog
• New Relic
• Langfuse
• Phoenix
• Opik
• 自研平台

---

5. 一个简单例子

假设你用 Node.js 写 skill：

import { trace, SpanStatusCode } from '@opentelemetry/api';

const tracer = trace.getTracer('skill-runtime');

async function runSkill() {
  return tracer.startActiveSpan('skill.bi-dashboard', async (span) => {
    span.setAttribute('user.erp', 'zhangsan');
    span.setAttribute('framework.name', 'openclaw');
    span.setAttribute('session.id', 'session_123');
    span.setAttribute('skill.name', 'bi-dashboard');
    span.setAttribute('skill.version', '1.2.0');

    try {
      // 执行 skill 逻辑
      span.setStatus({ code: SpanStatusCode.OK });
    } catch (error) {
      span.recordException(error as Error);
      span.setStatus({ code: SpanStatusCode.ERROR });
      throw error;
    } finally {
      span.end();
    }
  });
}

这段代码会记录一次 skill 执行过程，包括：

• 谁调用；
• 哪个平台；
• 哪个 session；
• 哪个 skill；
• skill 版本；
• 开始时间；
• 结束时间；
• 成功失败。

---

6. 和 Langfuse / Phoenix / Opik 的关系

可以这样理解：

名称	角色
OpenTelemetry	观测数据标准和采集 SDK
Langfuse	LLM/Agent 观测平台
Phoenix	AI/RAG 评测和观测平台
Opik	LLM/Agent tracing 和评测平台

也就是说：

OpenTelemetry 负责采集和规范化数据
Langfuse / Phoenix / Opik 负责展示、分析、评测

它们不是互斥关系，而是可以组合使用。

---

7. 对你们 skill 观测的价值

你们可以统一规定：

每次 skill 调用创建一个 trace/span
每个内部步骤创建一个子 span
每个 span 统一打 attributes

比如：

user.erp
framework.name
session.id
skill.name
skill.version
skill.status
skill.duration_ms
skill.error_type

这样以后就能统一查询：

• 某个 ERP 调用了哪些 skill；
• 某个平台上的 skill 成功率；
• 某个 session 中发生过哪些 skill run；
• 某个 skill 版本失败率是否升高；
• 哪个内部步骤最耗时。

---

8. 一句话总结

OpenTelemetry 是一个开源可观测性标准和 SDK，用来统一采集 trace、metric、log。

在 skill 观测里，它可以帮你把：

用户 -> 平台 -> 会话 -> skill -> 内部步骤 -> 工具/LLM调用 -> 输出

串成一条完整链路，方便排查问题、统计耗时、分析成功率和做版本质量对比。

评测

评测（Evaluation / Eval），就是对 LLM、Agent、Skill 的输出质量做系统性判断。

简单说：

评测 = 判断一次模型/skill 的回答或产出“好不好、对不对、稳不稳、有没有风险”。

它回答的是：

• 结果是否正确？
• 是否满足用户需求？
• 有没有幻觉？
• 有没有格式错误？
• 有没有安全风险？
• 是否比上个版本更好？
• 哪类问题容易失败？
• Prompt 或 skill 改完后有没有退化？

---

1. 为什么需要评测？

只做可观测，通常能回答：

谁调用了？
耗时多久？
成功还是失败？
哪一步报错？

但它不能直接回答：

结果质量好不好？
生成的看板是否符合用户意图？
SQL 是否正确？
字段选择是否合理？
解释是否可信？
有没有胡编？

所以需要评测。

可以这样理解：

可观测：看系统运行过程
评测：看产出质量

---

2. 评测对象有哪些？

2.1 LLM 输出评测

评估模型回答是否好。

例如：

用户问：解释 GMV 是什么
模型回答是否准确、简洁、无幻觉？

---

2.2 Skill 产物评测

评估 skill 最终产出是否满足目标。

例如 BI 看板 skill：

• 指标选得对不对；
• 维度选得是否合理；
• 图表类型是否合适；
• 筛选条件是否缺失；
• 布局是否清晰；
• 输出 JSON 是否符合 schema。

---

2.3 Agent 过程评测

评估 Agent 内部执行路径是否合理。

例如：

• 有没有按步骤执行；
• 有没有调用错误工具；
• 是否重复调用；
• 是否绕过权限；
• 是否在信息不足时瞎猜；
• 是否正确处理失败。

---

3. 一般评测什么？

常见维度如下。

维度	说明
正确性	答案是否事实正确、计算正确、字段匹配正确
相关性	是否回答了用户真正的问题
完整性	是否覆盖了必要信息
格式合规	是否符合 JSON、SQL、Markdown、接口 schema
可执行性	生成的 SQL / 代码 / 配置是否能运行
安全性	是否泄露敏感信息、越权、产生危险操作
稳定性	同类输入多次运行是否稳定
鲁棒性	面对模糊、缺字段、异常数据时是否合理处理
业务合理性	是否符合业务规则和领域常识
用户体验	是否清晰、易懂、可调整

---

4. 评测一般怎么做？

通常有 5 种方式。

---

方法一：规则评测

用确定性规则检查输出。

适合检查：

• JSON 是否合法；
• 字段是否存在；
• SQL 是否能解析；
• 必填字段是否完整；
• 是否包含敏感词；
• 是否符合 schema；
• 是否调用了禁止工具；
• 是否超时。

例子：

function evaluateDashboardConfig(config) {
  if (!config.charts?.length) {
    return {
      pass: false,
      reason: '看板至少需要一个图表'
    };
  }

  if (!config.filters?.some(f => f.type === 'date')) {
    return {
      pass: false,
      reason: '缺少时间筛选器'
    };
  }

  return { pass: true };
}

优点：

• 稳定；
• 成本低；
• 可自动化；
• 适合上线门禁。

缺点：

• 只能评估明确规则；
• 很难判断“好不好”“是否优雅”。

---

方法二：人工评测

让业务专家、测试、运营、产品人工打分。

适合评估：

• 业务合理性；
• 图表选择是否合适；
• 回答是否符合预期；
• 用户体验；
• 复杂主观质量。

常见打分表：

维度	分数
指标选择正确性	1-5
图表类型合理性	1-5
输出完整性	1-5
业务解释清晰度	1-5
是否可直接使用	是 / 否

优点：

• 准确；
• 能评估复杂业务质量。

缺点：

• 慢；
• 成本高；
• 不适合高频自动化。

---

方法三：LLM-as-Judge

用另一个大模型当裁判，对输出打分或给结论。

例如：

请判断以下 skill 输出是否满足用户需求。
用户需求：……
skill 输出：……
评分标准：正确性、完整性、格式、业务合理性。
请输出 JSON：{score, pass, reasons}

适合评估：

• 回答质量；
• 摘要质量；
• 是否符合需求；
• 图表设计是否合理；
• Agent 步骤是否合规。

优点：

• 自动化；
• 适合语义判断；
• 比纯规则更灵活。

缺点：

• 裁判模型也会出错；
• 成本较高；
• 需要校准；
• 不适合做强安全门禁的唯一依据。

---

方法四：黄金数据集评测

准备一批标准问题和标准答案，改 prompt / skill / 模型后跑回归。

例如：

case 1:
输入：帮我看近 30 天销售额趋势
期望：
- 使用 sales_amount
- 使用 date 字段
- 生成折线图
- 包含时间筛选器

case 2:
输入：比较各地区订单量
期望：
- 使用 order_count
- 按 region 分组
- 使用柱状图

每次版本变更都跑：

skill v1.2.0 vs skill v1.3.0

看：

• 通过率有没有下降；
• 平均分有没有提升；
• 哪些 case 退化；
• 哪类问题失败。

优点：

• 适合版本回归；
• 可以量化质量；
• 能防止改坏。

缺点：

• 需要持续维护数据集；
• 覆盖不可能无限。

---

方法五：线上反馈评测

通过真实用户反馈做评估。

信号包括：

• 用户点赞 / 点踩；
• 用户是否继续追问修正；
• 是否采纳产物；
• 是否导出 / 保存 / 发布；
• 是否重新生成；
• 是否人工编辑很多；
• 会话是否很快结束。

例如：

生成看板后用户点击“保存并发布” => 正向信号
生成后用户马上说“不对，字段错了” => 负向信号

优点：

• 贴近真实业务；
• 能发现测试集覆盖不到的问题。

缺点：

• 反馈噪声大；
• 归因困难；
• 需要数据分析。

---

5. 一套完整评测流程

推荐流程：

1. 定义评测目标
2. 建立测试集 / 黄金集
3. 定义评分标准
4. 选择评测方法
5. 执行自动评测
6. 抽样人工复核
7. 分析失败样例
8. 迭代 prompt / skill / 工具
9. 上线后收集用户反馈

---

6. BI Skill 的评测例子

假设用户输入：

帮我生成一个销售看板，关注近 30 天 GMV、订单量、客单价，按地区和品类分析。

Skill 输出一个看板配置。

可以评测这些：

规则评测

• JSON 是否合法；
• 是否有至少 3 个图表；
• 是否包含时间筛选器；
• 是否包含 GMV、订单量、客单价；
• 图表字段是否在数据集中存在；
• 聚合方式是否正确。

LLM 评测

让裁判模型判断：

• 是否理解了“近 30 天”；
• 地区和品类是否作为维度；
• 图表布局是否符合业务分析逻辑；
• 是否有无关图表；
• 解释是否清晰。

人工评测

业务人员判断：

• 这个看板是否有用；
• 指标组合是否合理；
• 是否符合部门分析习惯；
• 是否需要补充漏斗、同比环比等。

线上反馈

观察：

• 用户是否保存；
• 是否二次编辑；
• 是否重新生成；
• 是否吐槽字段错了。

---

7. 评测结果怎么记录？

可以和可观测打通。

一次 skill run 之后附加 eval 结果：

{
  "skill_run_id": "skillrun_001",
  "eval_id": "eval_001",
  "eval_type": "rule",
  "score": 0.92,
  "pass": true,
  "dimensions": {
    "field_correctness": 1.0,
    "chart_suitability": 0.8,
    "format_validity": 1.0,
    "business_relevance": 0.9
  },
  "reasons": [
    "字段选择正确",
    "图表类型基本合理",
    "缺少同比分析"
  ]
}

---

8. 常见指标

指标	含义
Eval Pass Rate	评测通过率
Average Score	平均分
Regression Rate	版本回归率
Hallucination Rate	幻觉率
Format Error Rate	格式错误率
Tool Misuse Rate	工具误用率
Safety Violation Rate	安全违规率
User Acceptance Rate	用户采纳率
Re-generation Rate	重新生成率

---

9. 评测和可观测的关系

可以这样理解：

可观测回答：发生了什么？
评测回答：做得好不好？

能力	关注点
可观测	链路、耗时、错误、输入输出、步骤
评测	正确性、相关性、完整性、安全性、质量
反馈	用户是否满意、是否采纳
监控	指标趋势、告警、版本对比

最好把它们打通：

skill_run_id
  -> trace/span
  -> input/output
  -> eval_score
  -> user_feedback

这样你可以查：

skill v1.3.0 失败率没变，但 eval 分数下降

或者：

耗时变快了，但用户采纳率下降

---

10. 最小落地建议

如果你刚开始做，建议从这三件事开始：

1. 规则评测

先做确定性检查：

JSON 合法
字段存在
必填项完整
schema 合法
无敏感信息

2. 黄金集回归

准备 30-100 条典型 case：

常见问题
边界问题
失败问题
高价值业务问题

每次 prompt / skill / 模型升级都跑一遍。

3. LLM-as-Judge 辅助评分

对规则无法判断的语义质量，用裁判模型打分：

是否符合用户意图
是否完整
是否业务合理
是否清晰

然后抽样人工复核，校准裁判模型。

---

11. 一句话总结

评测就是用规则、人工、模型裁判、黄金数据集和线上反馈，系统性判断 LLM / Agent / Skill 的产出质量。

推荐你们这样做：

可观测记录过程
评测判断质量
反馈验证用户满意度

最小闭环是：

规则检查 + 黄金集回归 + LLM-as-Judge + 用户反馈

最终目标是能回答：

这个 skill 不只是跑成功了，它是真的做对了吗？比上个版本更好吗？线上用户真的满意吗？

---

有，常用的开源评测工具大致分两类：

1. 评测框架 / SDK：更适合接入 CI、单测、离线回归。
2. 观测 + 评测平台：更适合线上看 trace、prompt、输出、评分和用户反馈。

下面先列最常用的评测框架。

工具	定位	最适合评测什么	典型用法	适合你的 skill 场景
DeepEval	LLM 应用评测框架，类似 “pytest for LLM apps”	Agent、RAG、Chatbot、LLM 输出质量；支持 answer relevancy、hallucination、task completion、G-Eval 等指标	写测试用例，然后像单测一样跑评测	适合做 skill 的离线回归测试，比如“这个 skill 产出是否符合预期、有没有幻觉、是否完成任务” (github.com)
Ragas	面向 RAG / LLM 应用的评测框架	RAG 检索质量、回答相关性、上下文相关性、faithfulness、testset generation	对 RAG pipeline 的 question、answer、contexts、ground_truth 做评分	如果 skill 里有知识库检索、数据集解释、文档问答，Ragas 很适合 (ragas.io)
promptfoo	Prompt / Model / Agent / RAG 评测与红队测试工具	Prompt 对比、模型 A/B、Agent 行为、RAG、AI 安全红队、CI/CD 门禁	用 YAML/配置文件定义输入、期望、评分规则，然后 CLI 跑评测	适合做 prompt 版本对比、skill 输出格式检查、安全测试和上线前门禁 (github.com)

---

如果只选一个，怎么选？

你的目标	推荐
想像写单测一样评测 skill / agent 输出	DeepEval
主要评测 RAG、知识库问答、检索增强生成	Ragas
想做 prompt 对比、模型对比、CI/CD 门禁、安全红队	promptfoo

---

和 Langfuse / Opik 的关系

Langfuse、Opik 更偏 观测平台 + 评测平台，不是单纯的本地评测框架。

类型	代表工具	作用
评测框架	DeepEval、Ragas、promptfoo	本地/CI 跑评测用例，输出分数和通过失败
观测评测平台	Langfuse、Opik、Phoenix	线上记录 trace、prompt、completion、用户反馈、eval 结果，做分析看板

实际落地时可以组合：

DeepEval / Ragas / promptfoo
  -> 跑离线评测和回归测试

Langfuse / Opik / Phoenix
  -> 存线上 trace、评测结果、用户反馈、质量趋势

---

针对 skill 评测的推荐组合

如果你们要评测的是：

谁在什么 session 里调用哪个 skill，输入是什么，输出是否正确，内部步骤是否合理，版本升级有没有退化。

我建议这样搭：

最小组合

DeepEval + 自定义规则评测

适合先做：

• 输出是否满足用户需求；
• JSON / schema 是否正确；
• 是否完成任务；
• 是否有明显幻觉；
• skill 版本回归测试。

---

如果有 RAG / 知识库

DeepEval + Ragas

适合评测：

• 检索结果是否相关；
• 回答是否基于上下文；
• 有没有编造；
• context precision / recall。

---

如果要进 CI/CD

promptfoo + DeepEval

适合：

• prompt 改动自动跑评测；
• 模型切换前后对比；
• 输出格式门禁；
• 安全红队测试；
• PR 阶段阻断劣化版本。

---

一个简单落地流程

1. 建 30-100 条黄金测试集
2. 每条包含：输入、期望字段、期望产出、评分标准
3. 用 DeepEval / promptfoo 跑离线评测
4. 如果涉及 RAG，再用 Ragas 评检索和答案忠实度
5. 把评测结果写回 Langfuse / Opik / 自研平台
6. 每次 skill/prompt/model 升级都跑回归

---

一句话总结

有开源工具，最常用可以先看这三个：

DeepEval：通用 LLM / Agent / Skill 评测
Ragas：RAG / 检索增强生成评测
promptfoo：Prompt / 模型对比 / CI/CD / 红队测试

如果你们做 skill 平台，我建议优先从 DeepEval + promptfoo 开始；如果 skill 里有知识库/RAG，再补 Ragas。