2026 年最流行的 14 个 Agent Eval 框架调研：排名、出处与优缺点
2026 年最流行的 14 个 Agent Eval 框架调研：排名、出处与优缺点
评测工具比 Agent 框架还卷——这篇帮你省掉一周的调研时间。
Agent 框架的卷是明面上的，评测（Eval）赛道的卷是暗地里的：过去一年，几乎所有观测平台都长出了 eval 能力，所有 eval 框架都长出了 tracing，AI 安全研究所下场做评测框架，连决策模型都有了专门的 judge。这篇文章基于 2026 年 9 月 27 日的 GitHub 实时数据，调研 14 个最主流的 Agent Eval 框架——给出来源、数据、分层排名和优缺点，帮你按自己的栈快速选型。
本文提纲
- 排名方法论：数据从哪来、怎么排
- 客观数据总表
- 第一梯队：全能观测平台（Langfuse / Opik / Phoenix / MLflow）
- 第二梯队：评测框架原生派（DeepEval / Inspect AI / promptfoo / OpenAI Evals）
- 第三梯队：专项型（Ragas / AgentOps / OpenLLMetry / NeMo Guardrails）
- 第四梯队：商业 SaaS 与大厂套件（LangSmith / W&B Weave / Helicone / Promptflow）
- 选型决策树
- 三个趋势观察
排名方法论：数据从哪来、怎么排
数据来源：所有 stars、语言、最近 push 时间均来自 GitHub API 在 2026-09-27 的实时查询，不是转述。排名方式：stars 是流行度的代理指标（不是质量指标），我按"流行度 + Agent 评测能力完整度"分成四个梯队，梯队内按 stars 排序。选型决策在第 7 节，那里的建议比排名重要。
一个诚实的声明：stars 数每天在变，本文的价值在于分层逻辑和优缺点分析，数据请以查询时点为准。
客观数据总表
| # | 框架 | Stars | 语言 | 最近 push | 定位 |
|---|---|---|---|---|---|
| 1 | Langfuse | 35,102 | TypeScript | 2026-09-27 | 开源 Agent evals + observability |
| 2 | promptfoo | 25,495 | TypeScript | 2026-09-27 | 测 prompt/agent/RAG + 红队 |
| 3 | Opik | 22,257 | Python | 2026-09-27 | Debug、评估、监控 LLM/Agent/RAG |
| 4 | MLflow | 28,149 | Python | 2026-09-27 | AI 工程平台（含 agent eval） |
| 5 | OpenAI Evals | 19,512 | Python | 2026-04-14 | LLM/系统评测框架（OpenAI 官方） |
| 6 | DeepEval | 18,464 | Python | 2026-09-25 | pytest 风格 LLM 评测框架 |
| 7 | Ragas | 15,859 | Python | 2026-02-24 | RAG 评测专用 |
| 8 | Arize Phoenix | 11,631 | Python | 2026-09-27 | AI observability + evaluation |
| 9 | Promptflow | 11,240 | Python | 2026-08-26 | LLM 应用全流程（微软） |
| 10 | OpenLLMetry | 7,454 | Python | 2026-09-27 | OpenTelemetry 观测 |
| 11 | NeMo Guardrails | 7,204 | Python | 2026-09-26 | 护栏工具包（含 eval） |
| 12 | Helicone | 6,180 | TypeScript | 2026-09-16 | LLM observability 平台 |
| 13 | AgentOps | 5,845 | Python | 2026-06-25 | Agent 监控/benchmark/replay |
| 14 | Inspect AI | 2,864 | Python | 2026-09-27 | LLM 评测框架（UK AI 安全研究所） |
注：LangSmith（langchain-ai/langsmith-sdk，1,064 stars）和 W&B Weave（wandb/weave，1,131 stars）的 SDK 仓库 stars 低是因为主体是闭源 SaaS，单列在第四梯队讨论。
第一梯队：全能观测平台
特点：tracing + evals + 监控一条龙，平台化。适合认真做生产的团队。
Langfuse（35,102 ⭐）
出处：langfuse/langfuse，MIT/核心开源 + 云托管，Foss（原柏林）团队。
优点：
- 生态集成最广：LangChain/LlamaIndex/OpenAI SDK/OpenTelemetry 等 40+ 集成，trace 采集零阻力。
- eval 与 trace 咬合：评测直接跑在 trace 上（用户反馈、LLM judge、人工标注三类），配 annotation queue 给人审。
- 开源可自托管：数据不出门，这是它对 Opik 之外大多数对手的核心优势。
- prompt 管理内建：版本化 prompt + 实验对比。
缺点：
- 平台功能多而全，深度使用有学习成本；eval 的"断言式测试"体验不如 DeepEval 的 pytest 直感。
- 自托管部署链路（数据库、队列、对象存储）对中小团队偏重。
Opik（22,257 ⭐）
出处：comet-ml/opik，Apache-2.0，Comet 出品（老牌 ML 实验跟踪公司转型）。
优点：
- LLM judge 库丰富：内置幻觉、相关性、答案正确性等开箱即用指标，也支持自定义。
- Python 优先的 API 设计舒服，
evaluate()一行跑批量评测。 - Agent 评测原生：对 LangGraph、CrewAI 等多步 agent 的 trace 评测支持好。
- 我们之前拆过它的完整能力（2.2 万星时的状态），近半年仍在高速迭代。
缺点：
- 云免费档有额度限制；自托管相对 Langfuse 较新，部署模板少一些。
- UI/生态集成数量略逊 Langfuse。
Arize Phoenix（11,631 ⭐）
出处：Arize-ai/phoenix，Apache-2.0（部分 MIT），Arize AI 出品。
优点：
- OpenTelemetry 标准派：OTel 原生，instrumentation 最规范，不锁定自家 SDK。
- 评测的学术底子好：RAG triad（context relevance / groundedness / answer relevance）等指标定义清晰，LLM judge 提示词公开可审计。
- 轻量自托管体验好（单容器可跑）。
缺点：
- 产品面偏"观测+评测"，prompt 管理、数据集管理等配套不如 Langfuse 全。
- 商业版（Arize AX）与开源版功能边界需要留意。
MLflow（28,149 ⭐）
出处：mlflow/mlflow，Apache-2.0，Databricks 主导。
优点：
- 企业 ML 事实标准：如果团队已有 MLflow（实验跟踪、模型注册），agent eval 是自然延伸，
mlflow.evaluate()支持 LLM judge 指标。 - Tracing（v3 起）对 agent 工作流的记录很规范。
缺点：
- LLM/Agent 部分的体验明显比原生框架"重"：UI 和工作流都带着传统 ML 平台的包袱。
- Agent 评测的新特性迭代速度慢于 Langfuse/Opik 这类原生玩家。
第二梯队：评测框架原生派
特点：eval 是本体，测试体验第一，适合把评测写进代码和 CI 的团队。
DeepEval（18,464 ⭐）
出处：confident-ai/deepeval，Apache-2.0，Confident AI 出品。
优点：
- pytest 原生：goldens + metrics +
assert_test()，评测写起来就是单元测试，deepeval test run直进 CI。 - Agent 指标体系最完整：PlanQuality/PlanAdherence/ToolCorrectness/ArgumentCorrectness/TaskCompletion/StepEfficiency 六指标，每个指标盯一种失败模式（我们昨天刚拆过它的六指标体系）。
- GEval 自定义标准 + JevEval（决策模型 judge）跟上最新方向。
缺点：
- 无自托管服务端——trace 数据要么本地要么上 Confident AI 云，平台化监控不如第一梯队。
- LLM judge 指标的提示词工程黑盒度偏高，调优要进源码。
Inspect AI（2,864 ⭐）
出处：UKGovernmentBEIS/inspect_ai，MIT，英国政府 AI 安全研究所（AI Safety Institute）出品。
优点：
- 权威血统：政府 AI 安全研究所维护，评测方法论严谨，学术和监管场景的默认选择。
- Agent 框架（Scaffold）设计好：solver/plan/scorer 分层，可组合的 agent 架构跑基准。
- 纯 Python、依赖少、可复现性强。
缺点：
- 偏"研究型评测"（benchmark、安全评估），没有商业平台的观测/UI 补全。
- 社区规模小，遇到问题可参考的资料少。
promptfoo（25,495 ⭐）
出处：promptfoo/promptfoo，MIT，promptfoo 公司出品。
优点：
- 声明式测试：YAML 写测试用例和断言，model-agnostic（OpenAI/Anthropic/本地模型随便切），矩阵对比体验最好。
- 红队能力独特：越狱、注入、PII 泄露的红队测试内建，这在 eval 工具里是差异化的（我们写的 MCP 安全检查清单里就提过这类需求）。
- 全 TypeScript，Web viewer 体验好。
缺点：
- 对复杂多 agent 轨迹的评测（计划/工具序列）不如 DeepEval 六指标体系那么体系化。
- Python 生态的集成（LangGraph trace 直读等）相对弱。
OpenAI Evals（19,512 ⭐）
出处：openai/evals，MIT，OpenAI 官方。
优点：
- 历史地位重要：LLM eval 框架的开山之作，registry 格式影响了后来者。
- 官方维护、格式简单（YAML 定义 eval）。
缺点：
- 事实上的停滞：最后 push 停在 2026-04，社区活跃度下降，OpenAI 的重心已转向 Agent SDK 生态。
- 主要面向 OpenAI 模型，框架无关性一般。
第三梯队：专项型
特点：只做一件事，但在那一件事上做到位。
Ragas（15,859 ⭐）
出处：explodinggradients/ragas，Apache-2.0。
优点：RAG 评测事实标准——faithfulness、answer relevancy、context precision/recall 这套指标定义成了行业词汇；合成测试数据生成省时间。 缺点：2026 年 2 月后更新明显放缓；只覆盖 RAG，Agent 工具调用评测不归它管。
AgentOps（5,845 ⭐）
出处：AgentOps-AI/agentops，MIT。
优点：Agent 专用视角——session 回放、agent 成本跟踪、benchmark 集成，对多 agent 系统的监控做得细。 缺点：2026 年 6 月后 push 放缓，eval 能力偏薄，更像监控工具而非评测框架。
OpenLLMetry（7,454 ⭐）
出处：traceloop/openllmetry，Apache-2.0，Traceloop 出品。
优点：基于 OpenTelemetry 的标准观测方案，instrumentation 库覆盖广，配 traceloop 平台用很顺。 缺点：本体是观测不是评测——eval 能力要配 Traceloop 平台（商业）或其他框架。
NeMo Guardrails（7,204 ⭐）
出处：NVIDIA/NeMo-Guardrails，Apache-2.0。
优点：可编程护栏（Colang 语言）的事实标准，rails 内建的 eval 流程适合"护栏效果验证"。 缺点：定位是护栏不是 eval 框架，列在这里是因为很多团队的"评测需求"其实是护栏需求。
第四梯队：商业 SaaS 与大厂套件
特点：闭源 SaaS 为主，SDK 开源。适合预算充足、不想自建的团队。
LangSmith（LangChain 官方）
出处：langchain-ai/langsmith-sdk（SDK 1,064 ⭐），SaaS 主体闭源。
优点：与 LangChain/LangGraph 深度咬合；eval 数据集、judge、experiment 管理一体化；我们翻译过它的 Jev 评测实验，工程完成度高。 缺点：闭源 SaaS、按量计费；非 LangChain 栈的集成体验明显下降。
W&B Weave
出处：wandb/weave（SDK 1,131 ⭐），SaaS 主体闭源，Weights & Biases 出品。
优点：W&B 生态的延续——如果团队已在用 W&B 跟踪训练，Weave 是零摩擦延伸；对比视图和 leaderboard 体验好。 缺点：同上闭源 SaaS；Agent 深度评测功能还在追赶第一梯队。
Helicone（6,180 ⭐）
出处：Helicone/helicone，Apache-2.0。
优点：网关式设计（一行代码接入）、成本/延迟监控出色、自托管友好。 缺点：评测能力偏基础，定位在 observability 而非 eval 框架。
Promptflow（11,240 ⭐）
出处：microsoft/promptflow，MIT，微软出品。
优点：DAG 式 LLM 应用编排 + 评测一体，Azure 生态内顺滑。 缺点：更新放缓（8 月后无 push），社区热度被 Azure AI Foundry 系产品稀释。
选型决策树
按你的情况对号入座：
你的团队数据不能出门？
├─ 是 → Langfuse（要全功能）或 Phoenix（要 OTel 标准）
│ 纯 RAG 场景 → + Ragas
└─ 否（可用云 SaaS）
├─ 在 LangChain 栈 → LangSmith
├─ 已在用 W&B → Weave
├─ 在 Azure/Foundry → ai-agent-evals + Promptflow
└─ 其他
├─ 评测要进 CI/pytest → DeepEval（+ Opik 做平台）
├─ 要红队/安全测试 → promptfoo
├─ 学术/监管 benchmark → Inspect AI
└─ 只要成本监控 → Helicone三个务实建议：
- 别选"一个全家桶解决一切"。主流做法是组合：一个观测平台（Langfuse/Opik/Phoenix）+ 一个 CI 评测框架（DeepEval/promptfoo），trace 归前者、断言归后者。
- 先定"评测集维护流程"，再选工具。工具都差不多，真正的分水岭是有没有人持续维护 goldens 数据集——没有的团队用什么框架都是摆设。
- 盯紧 OpenTelemetry。GenAI 语义约定正在成为标准，选 OTel 原生的工具（Phoenix/OpenLLMetry/Langfuse）能降低未来换栈的成本。
三个趋势观察
趋势一：观测与评测正在合流。 两前的格局是 tracing 工具（LangSmith）和 eval 框架（DeepEval）分开，现在所有观测平台都内建 eval，所有 eval 框架都内建 tracing——今天这个榜单上一半的条目是"平台"而不是"框架"。
趋势二：judge 正在专业化。 从 LLM-as-a-judge 到 GEval 式自定义 judge，再到 JevEval 用 System One 决策模型当 judge（低成本高一致性），judge 本身成了一个可插拔组件。
趋势三：CI 化是下一个战场。 微软 ai-agent-evals、DeepEval 的 pytest 模式、promptfoo 的 CI 集成都在指向同一件事：Agent 评测正在从"上线前人工跑一次"变成"每次 push 自动跑"，和单元测试二十年前走过的路一样。
参考链接
- Langfuse | promptfoo | Opik | MLflow
- OpenAI Evals | DeepEval | Ragas | Phoenix
- Promptflow | OpenLLMetry | NeMo Guardrails | Helicone
- AgentOps | Inspect AI | LangSmith SDK | W&B Weave
- 我的 DeepEval 六指标拆解 | 我的微软 ai-agent-evals 拆解 | 我的 Agent 上生产四关
你的团队用哪个组合？踩过哪些坑？评论区聊聊你的选型，觉得有用点个赞让更多做 Agent 的人少走弯路。
作者: itech001 来源: 公众号：AI人工智能时代(the-ai-era) 网站: https://www.theaiera.top/ 关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top
本文首发于 AI人工智能时代，转载请注明出处。
