Agent Eval 与 Observability 框架调研

摘要

2025–2026 年的共识很明确：评估 agent 不能只看最终文本。我们记录五个事实：

1. (1) 正确的最终答案可能来自错误路径——绕路、幻觉工具、reward hacking。Agent 会规划、调工具、改环境、失败后重试，因此 eval 平台必须把 dataset → harness → environment → trajectory → grader → experiment → report 做成可复现流水线，而不是一次性跑分脚本。
2. (2) 市场分成四层，很少有仓库同时覆盖：① 离线 harness（YAML/pytest 跑固定集）· ② 实验产品（dataset 快照、不可变 experiment、按 case 对比）· ③ 观测平台（trace → 在线评分）· ④ 指标库/基准套件（RAG、轨迹、SWE）。[E17]
3. (3) 头部集中且已被收购：Langfuse（35.2k）2026-01 归入 ClickHouse，Promptfoo（25.6k）归入 OpenAI——头部框架的控制权在向数据基础设施厂商与模型厂商两端集中。[E01,E02]
4. (4) agent 原生层仍是空档：四层里最成熟的指标在 RAG 与 completion 级（Ragas、OpenAI Evals）；对「长程轨迹 + 环境隔离 + 多 adapter」完整覆盖的只有 Harbor 与 Inspect AI 两类框架，且都无企业控制面。[E11,E13]
5. (5) 正确的建法是组合而非自研全部：①+② 做成自己的控制面，③ 只借鉴部署拓扑，④ 当 grader 插件而不是产品本身。[E17]

16 个框架的逐个对比见第 3 章全景；四层归属与选型决策见第 2、4 章。

1 为什么 agent 评测这么难

传统 ML 评测是「一个输入对一个输出」：跑一遍测试集，算个分数。Agent 打破了这三个前提。

所以 2025–2026 年的工具收敛到了同一条流水线形状：

每个环节都要可版本化、可重放：dataset 要有快照（改了用例不污染历史实验），environment 要可重建（容器或 sandbox），trajectory 要落盘（事后能重新评分），experiment 要不可变（同一 run 永远指向同一份数据）。

评测的对象不是「分数」，是「分数 + 它诞生的那条完整链路」。

2 四层格局：没有全能选手

把 16 个框架按能力构成放到四层里看，格局一目了然：

为什么会分层：机制的解释是「评测的三个时刻对应三类买家」——写代码的开发者要 harness（CLI 就够），跑实验的团队要实验产品（要 UI 和对比），管生产的 SRE 要观测平台（要 trace 和告警）。三类买家的工作流差异大到没有一家能把三层都做到 80 分以上：Langfuse 的观测最强但没有 harness 原语，DeepEval 的 grader 最全但没有实验产品，Harbor 的环境隔离最好但只服务 coding 场景。[E01,E05,E11]

对自建平台（①+② 控制面）的含义：③ 只借鉴部署拓扑（Langfuse 的 Web/Worker/Postgres/Redis/对象存储拆分已在 K8s 验证），④ 全部当 grader 插件（Ragas 的 RAG 指标、DeepEval 的轨迹指标、Giskard 的安全扫描都通过统一 grader 接口接入），不重复造任何一个。

3 框架全景：16 个仓库逐个看

左上象限（自托管友好 + agent 原生）只有三个框架：Inspect AI、Harbor、Promptfoo。这个象限是「拿来自建控制面」的候选池——下面逐个说清楚它们各自能借鉴什么、缺什么。

3.1 五个重点框架

3.2 其余框架速览

star 数为 2026-09-29 GitHub API 实测读数 [E01–E15]；Ragas 已迁至 vibrantlabsai/ragas、Giskard 已迁至 giskard-oss，读数取迁移后仓库。AgentCompass 为论文基础设施（arXiv:2607.13705），无公开仓库。[E16]

3.3 收购改变了两件事

Langfuse → ClickHouse（2026-01）：trace 数据天然是 ClickHouse 的主场，收购逻辑是「观测数据落在查询引擎里」。对使用者的直接影响是 K8s 拓扑会更紧密地绑 ClickHouse 生态，长期协议宽松度（MIT → 是否变化）值得盯。[E01]

Promptfoo → OpenAI（2026）：模型厂商收下最流行的声明式 eval 工具，对非 OpenAI 用户的中立性预期下降——用 Promptfoo 跑 Claude/Gemini 的断言时，对「报告是否对竞品模型公平」要多留一个心眼。仓库仍开源（MIT），fork 自托管的成本不高。[E02]

两起收购共同指向一个趋势：eval 基础设施的控制权在向「数据基础设施」和「模型厂商」两端集中，独立中立的 eval 层正在变少。这让「核心控制面自建、外围当插件」的策略从可选项变成了稳妥项。

4 选型建议：按你要建什么分

4.1 自建控制面的组合拳

如果要建的是「dataset → experiment」可控、评测逻辑不被任何厂商锁定的平台，2026-09 时点最自洽的组合是四步：

1. 抽象层抄 Inspect AI：Task = Dataset + Solver + Scorer 三件套。Solver 可替换即是 agent adapter（一套任务评多个 agent），Scorer 独立注册即可重打分（换 judge 不用重跑任务）。[E13]
2. 环境层抄 Harbor：容器隔离 + 环境快照与 harness 正交。coding 场景直接复用它的任务格式。[E11]
3. 存储拓扑抄 Langfuse：轨迹进对象存储、元数据进 Postgres、查询走列存——这套拆分已在 K8s 验证，不用自己试错。[E01]
4. grader 全部插件化：Ragas（RAG）、DeepEval/OpenEvals（轨迹与 completion）、Giskard（安全）、LLM-as-judge 自定义——统一 grader 接口，缺哪个接哪个，不把任何一个当产品内核。[E06,E05,E15,E09]

为什么不全用 Langfuse：它的实验原语（pass@k、按 case 对比、dataset 快照）弱于观测能力，且收购后与 ClickHouse 的绑定会加深。把它当 ③ 层的部署参考和在线评分入口是合适的，当控制面内核会在 trace schema 和实验语义上被它牵着走。[E01,E17]

为什么不用 Promptfoo 当内核：YAML 声明式对固定集很高效，但长程轨迹的实验对比与团队 Dashboard 是它的弱项；加上 OpenAI 收购后的中立性问题，它更适合当 CI 门禁而不是平台内核。[E02]

5 方法、数据来源与局限性

5.1 方法

选样。16 个系统：开源框架 15 个（GitHub 可检索、2026 年仍活跃维护）+ 论文基础设施 1 个（AgentCompass）。覆盖四层中的全部四层，含观测平台 5 个、harness/框架 5 个、指标库 4 个、实验产品 3 个（有重叠按主要能力归层）。

事实采集。star 数以 2026-09-29 GitHub API 实测读数为准（Ragas 取迁移后仓库 vibrantlabsai/ragas，Giskard 取 giskard-oss）；功能与形态描述以各官方仓库 README 与文档为准逐条核对。16 条数据点均标注在正文 [E01–E16]。

四层归属与象限定位。Figure 2.1 的能力构成与 Figure 3.2 的象限是定性估计（依据公开功能列表），用于看格局，不用于打分排名。

5.2 局限性与替代解释

能力构成为定性估计。四层占比（Figure 2.1）没有公开的量化依据，是基于 README 功能列表的判断——两个框架占比相差 10 个百分点不具有统计含义，只有「主层/副层」的档位含义。

star 数不等于生产使用量。Langfuse 35.2k star 不代表它部署量第一；star 衡量开发者关注度，企业内部自托管部署没有公开数据。用 star 排序时，我们论证的是社区热度不是渗透率。

收购影响是预期判断。Promptfoo 中立性下降是推断不是实测——目前没有公开的评测偏差证据。这一条属于风险提示，属于「值得盯」而非「已发生」。

样本偏差。16 个样本偏开源与英文社区；闭源平台（Arize AX、LangSmith、Braintrust、W&B Weave 的商业面）只在形态描述中提及，不参与能力对比——它们没有可核对的公开功能清单。国内厂商的 eval 平台不在本报告样本内。

时效。这个领域发版极快（收购、许可变更、新仓库迁移都在 90 天内发生）。本报告数据截至 2026-09-29，引用时建议先复核 star 与许可证。

数据速查表

16 个框架的关键属性一页汇总。

star 为 2026-09-29 GitHub API 实测 [E01–E15]；AgentCompass 无公开仓库。