2026 年生产团队最佳 AI Agent 评估与可观测性 Harness

生产环境中的 AI agent，其失败方式不同于演示中的失败。

演示失败，通常是模型给出了一个较弱的答案。生产环境中的 agent 失败，则可能是它调用了错误工具、静默跳过某个步骤、循环 14 分钟、烧掉预算、错误处理交接、检索到过期上下文，或者某个工作流测试今天通过、第二天又回归。因此，2026 年的生产团队需要的不只是提示词日志。他们需要 评估与可观测性 harness：能够捕获 trace、为行为评分、比较版本、暴露回归，并把人工审查重新连接到开发流程中的系统。

本文对 2026 年面向生产团队的领先 AI agent 评估与可观测性 harness 进行排名：

1. LangSmith
2. Braintrust
3. Langfuse
4. Arize Phoenix / Arize AX
5. Galileo
6. DeepEval / Confident AI
7. OpenAI Agent Evals
8. Helicone
9. Ragas

MCPlato 会单独讨论：它不是直接的可观测性厂商，而是围绕 eval harness 的互补型 本地优先 AI 工作空间 harness。

什么算 AI Agent Eval / 可观测性 Harness？

在本次对比中，AI agent eval 与可观测性 harness 指的是能帮助团队回答五个生产问题的平台或框架：

• 发生了什么？ 追踪 agent 步骤、工具调用、模型调用、检索、交接、会话、成本、延迟和错误。
• 结果好吗？ 使用代码评估器、LLM-as-judge、人工审查、反馈或领域指标，对输出和轨迹评分。
• 是否回归？ 在部署前基于数据集运行可重复 eval，并在部署后监控线上行为。
• 能否调试？ 检查失败 trace，比较提示词 / 模型 / 工具版本，并把生产失败转化为测试用例。
• 能否适配我们的技术栈？ 与 SDK、CI/CD、OpenTelemetry、现有可观测性系统和治理要求集成。

最好的 harness 会结合 trace + eval 数据集 + 实验 + 生产监控 + 人工反馈。较弱的工具也有价值，但范围更窄：可能只是日志代理、测试库，或 RAG 指标工具包，而不是完整的生产控制闭环。

方法论

本排名优先考虑正在构建多步骤 LLM 与 agent 系统的生产团队。评分是定性的，依据截至 2026 年 5 月 14 日可公开获取的产品页面、文档、定价页面、集成、开源仓库以及公开公司 / 客户信息。

主要评分维度：

我们避免编造指标。如果定价、增长、收入、客户数量或基准测试数字没有公开披露，我们会明确说明。

1. LangSmith — 生产 Agent 团队的最佳综合选择

最适合： 使用 LangChain、LangGraph 或相邻 Python / JavaScript 技术栈构建 agent，并需要一个成熟一体化系统来完成 tracing、评估、数据集、监控和部署信心建设的团队。

LangSmith 排名第一，因为它是面向 agent 构建者最完整的生产 harness 之一。其可观测性产品强调对 LLM 应用和 agent 的 tracing、监控、调试与运营可见性。¹ 其评估文档覆盖数据集、实验、自动评估器，以及随时间比较系统行为的工作流。²

核心能力

• 面向多步骤工作流的 agent 与 LLM tracing。
• 评估数据集和实验运行。
• 自动评估器和人工审查工作流。
• 面向延迟、成本、错误和质量信号的生产监控。
• 与 LangChain 和 LangGraph 项目高度契合。
• 公开定价页面，提供基于用量和团队导向的计划。³

优势

LangSmith 最大的优势是完整性。许多团队从 LangChain 或 LangGraph 起步，随后需要围绕它的运营层。LangSmith 为这些团队提供了从本地调试到 trace 检查、eval 数据集和生产监控的最短路径。

它对 agent 团队尤其强，因为 agent 失败往往发生在轨迹层，而不是输出层。最终答案可能看起来可以接受，但中间工具调用会暴露浪费成本、不安全操作或脆弱规划。LangSmith 的 tracing 与 eval 工作流正是为这类检查而设计。

局限

LangSmith 在 LangChain / LangGraph 生态内最有吸引力。希望获得完全厂商中立、开源或自托管优先控制平面的团队，可能更偏好 Langfuse 或 Phoenix。定价是公开的，但最终成本取决于用量规模和计划细节，而不是单一固定数字。

定价 / 公开指标

LangChain 公开发布 LangSmith 定价。³ 在所需来源中未找到 LangSmith 专属的公开客户数量或收入指标。

2. Braintrust — 最佳评估优先平台

最适合： 将 eval 视为核心开发工作流的产品和工程团队：数据集、实验、回归、人工审查，以及生产 trace 反馈闭环。

Braintrust 是本排名中最以评估为中心的平台。其首页围绕实验、数据集、日志、提示词、playground 和人工审查，定位为用于评估、发布和改进 AI 产品的工具。⁴ 它还记录了 OpenTelemetry 集成，这对正在标准化更广泛可观测性基础设施的团队很重要。⁵

核心能力

• 用于可重复评估的数据集和实验。
• 线上和离线评分工作流。
• 人工审查和标注循环。
• 提示词和模型对比。
• 生产日志与 trace 反馈进入 eval。
• OpenTelemetry 集成。⁵
• 公开客户页面和案例研究。⁶

优势

当 eval 不是事后补救时，Braintrust 最强。它鼓励团队把样例、trace、反馈和边界案例转化为持久数据集。这正是生产 agent 所需的思维模型：每一次失败都应成为未来的回归测试。

它也有很强的可信度信号。Braintrust 公开宣布了 A 轮融资，并在网站上列出客户故事。⁷⁶ 这些不是产品性能指标，但显示了市场采用度和投资人信心。

局限

相比 Langfuse、Phoenix、DeepEval 或 Ragas，Braintrust 不那么开源优先。希望自托管整个可观测性层，或检查完整 OSS 服务端的团队，可能会觉得 Langfuse 或 Phoenix 更有吸引力。它也以评估为先：如果你的即时痛点是网关级请求日志和成本分析，Helicone 可能部署更快。

定价 / 公开指标

Braintrust 公开发布定价。⁸ 在所需来源中，其精确客户数量、收入和使用量未公开披露。

3. Langfuse — 最佳开源 / 自托管全能 Harness

最适合： 想要一个开源、可自托管平台来完成 LLM 可观测性、tracing、提示词管理、eval、数据集和实验的团队。

Langfuse 是最强的开源全能选项。Langfuse GitHub 仓库是公开的，⁹ 产品有公开定价，¹⁰ 自托管文档明确说明部署选项。¹¹ 它还具备原生 OpenTelemetry 集成；随着 agent 可观测性与标准 telemetry 汇合，这一点越来越重要。¹²

核心能力

• 开源 LLM 可观测性平台。
• Trace、会话、用户追踪和分数。
• 提示词管理、数据集和实验。
• 自动评估和 LLM-as-judge 工作流。¹³
• 原生 OpenTelemetry 集成。¹²
• 自托管支持。¹¹

优势

Langfuse 提供了一种少见组合：开源透明度、自托管、现代 eval 工作流，以及广泛的可观测性覆盖面。这使它对注重安全的团队、受监管行业，以及希望避免立即陷入厂商锁定的工程组织具有吸引力。

它也适合异构技术栈。如果你的 agent 并非完全建立在某一个框架上，Langfuse 仍可作为 trace 与 eval 层居中运行。

局限

自托管很强大，但运营上并非免费。团队必须运行、保护、升级和扩展部署。对于高级治理、告警或跨团队采用，Langfuse 也可能比完全托管的企业平台需要更多组装工作。

定价 / 公开指标

Langfuse 公开发布定价和自托管信息。¹⁰¹¹ 在所需来源中未找到公开收入或客户数量指标。

4. Arize Phoenix / Arize AX — 最佳 OpenTelemetry 与 OpenInference 导向技术栈

最适合： 希望通过 Phoenix 获得开源开发可观测性，并通过 Arize AX 获得企业级生产 AI 可观测性的团队，尤其适合采用 OpenTelemetry 和 OpenInference 风格 instrumentation 的团队。

Arize 是严肃的生产可观测性玩家，而 Phoenix 是 LLM 可观测性生态中最重要的开源项目之一。Phoenix 定位于 AI 可观测性和评估，¹⁴ Arize 的 agent 可观测性材料则聚焦 trace、工具调用、agent 步骤和生产监控。¹⁵ Phoenix GitHub 仓库是公开的。¹⁶

核心能力

• Phoenix 开源可观测性和评估工作流。¹⁴¹⁶
• Arize AX 企业级 AI 可观测性。
• 面向工具调用、trace 和多步骤行为的 agent 可观测性。¹⁵
• OpenTelemetry 集成。¹⁷
• OpenInference 与 OTel instrumentation 叙事。¹⁸
• 通过 Arize 公开融资公告体现企业可信度。¹⁹

优势

Arize 的优势在于可观测性深度。它源自机器学习可观测性背景，并积极进入 LLM 与 agent 可观测性领域。Phoenix 为团队提供开源入口，而 AX 提供生产级企业路径。

OpenTelemetry 叙事也很强。随着公司在服务间标准化 trace 和指标，agent telemetry 不能存在于孤立黑盒中。Arize 的 OTel 与 OpenInference 取向契合这一趋势。

局限

Phoenix / AX 的分工可能比单一 SaaS 优先产品需要更清晰的架构决策。Phoenix 对开发和开源工作流很有吸引力；AX 是企业生产层。团队必须决定二者在生命周期中的位置。

定价 / 公开指标

Phoenix 是开源的。在所需来源中，Arize AX 企业定价未公开披露。Arize 公开宣布完成 7000 万美元 C 轮融资，用于构建 AI 评估和可观测性基础设施。¹⁹

5. Galileo — 最佳企业 Agentic 评估平台

最适合： 希望获得托管式 agentic evaluations、工作流可见性、guardrails、仪表盘和监控，而不想从开源组件自建评估平台的企业团队。

Galileo 将自身定位为企业 AI 评估与可观测性平台。²⁰ 它有公开定价信息、²¹ 公开案例研究、²² 以及 Google Cloud 客户故事。²³ 其 agentic evaluations 发布公告专门聚焦帮助开发者构建可靠 AI agents。²⁴

核心能力

• 面向多步骤 agent 工作流的 agentic evaluations。²⁴
• AI 系统可观测性仪表盘。
• 质量、成本、延迟和错误监控。
• Guardrails 与评估工作流。
• 企业案例研究和托管部署取向。²²²³

优势

Galileo 的定位很清晰：为生产 AI 提供企业级评估和可观测性。它尤其适合希望获得 agent 专用评估工作流，但不想自行组装 OSS tracing、自定义指标和仪表盘的团队。

Google Cloud 客户故事是有用的可信度信号，因为企业买家通常同样看重运营成熟度、合作伙伴关系和功能清单。²³

局限

相比 Langfuse、Phoenix、DeepEval、Helicone 或 Ragas，Galileo 不那么以开源为中心。希望获得本地优先控制、自托管透明度或框架级测试代码的团队，可能更偏好其他选项。公开技术细节因产品领域而异，部分企业条款需要销售沟通。

定价 / 公开指标

Galileo 公开发布定价信息。²¹ 在所需来源中未找到详细客户数量、收入或平台使用量指标。

6. DeepEval / Confident AI — 最佳代码优先 Agent 测试框架

最适合： 希望为 LLM 应用和 agent 编写 pytest 风格 eval，并可选择托管平台用于仪表盘、协作和可观测性的开发者。

DeepEval 是 Confident AI 推出的代码优先评估框架。其首页和 GitHub 仓库将开源框架置于核心位置，²⁵²⁶ Confident AI 则提供更完整的平台、文档和定价。²⁷²⁸²⁹

核心能力

• 开源 LLM 评估框架。
• 面向 LLM 应用的类单元测试 eval。
• 覆盖答案正确性、幻觉、RAG 和 agent 行为的指标。
• CI 友好的开发者工作流。
• 用于仪表盘和协作的 Confident AI 平台。²⁸

优势

对于希望把 eval 写进代码的工程团队，DeepEval 是最容易推荐的选择之一。它自然映射到开发者已经理解的心智模型：写测试、跑测试、让构建失败、修复回归。

这使它非常适合生产前验证。如果团队希望每一次提示词、agent 工作流或检索变更在合并前通过 eval 套件，DeepEval 应进入候选名单。

局限

DeepEval 本身并不等同于完整的生产可观测性平台。对于生产 trace 摄取、告警、长会话分析和组织级监控，团队可能需要 Confident AI 或另一个可观测性层。

定价 / 公开指标

DeepEval 在 GitHub 上开源。²⁶ Confident AI 公开发布其平台定价。²⁹ 在所需来源中未找到公开客户数量或使用量指标。

7. OpenAI Agent Evals — OpenAI 原生 Agent 构建者的最佳选择

最适合： 主要使用 OpenAI Agents 技术栈构建，并希望在靠近模型和 agent runtime 的位置获得评估、tracing、trace grading 和可观测性集成的团队。

OpenAI 的 Agent Evals 指南聚焦于使用 trace、grader、数据集和 eval run 来评估 agent 工作流。³⁰ Agents 指南、可观测性集成和 trace grading 文档展示了一个更广泛的系统，用于构建和检查 OpenAI 原生 agents。³¹³²³³

核心能力

• 基于 trace、数据集和 grader 的 agent eval 工作流。³⁰
• Agent 构建文档和 runtime 指引。³¹
• 面向 agent trace 的可观测性集成。³²
• 面向工作流级评估的 trace grading。³³
• 开源 openai/evals 仓库。³⁴

优势

最大的优势是靠近 OpenAI agent 技术栈。如果你的生产 agent 围绕 OpenAI API 和 Agents 工具构建，OpenAI Agent Evals 能以更少转换来评估该技术栈的原生产物。

Trace grading 对 agent 尤其相关，因为过程和最终文本同样重要。工作流可能因为工具选择、交接、缺失 guardrail 或中间推理步骤而出错。

局限

取舍在于厂商中立性。OpenAI Agent Evals 在其余技术栈也 OpenAI 原生时最合适。正在比较多个模型提供商、框架或托管环境的团队，可能更偏好 Braintrust、Langfuse、Phoenix 或 LangSmith。

定价 / 公开指标

OpenAI 公开发布 API 定价。³⁵ 更广泛 eval 工作流的定价取决于模型用量和 API 调用。在所需来源中未找到 Agent Evals 专属的公开采用指标。

8. Helicone — 最佳轻量网关与成本可观测性层

最适合： 需要快速获得请求级可观测性、成本追踪、延迟分析、缓存、路由、反馈和分数，而不想在第一天就采用更重 eval 平台的团队。

Helicone 是实用的网关式可观测性层。其定价公开，³⁶ 分数功能有文档说明，³⁷ GitHub 仓库也是公开的。³⁸ 它还出现在 Vercel AI SDK 可观测性 provider 文档中。³⁹

核心能力

• LLM 请求日志和分析。
• 成本、延迟和使用量追踪。
• 分数和反馈工作流。³⁷
• 缓存和路由等网关功能。
• 开源仓库。³⁸
• AI SDK provider 集成。³⁹

优势

Helicone 的优势是速度。许多团队一开始并没有完整 eval 纪律；他们首先会问：“我们花了多少钱，哪些请求很慢，用户哪里不满意？”Helicone 能快速回答这些问题。

它也适合作为更深 eval 工具的补充。团队可以用 Helicone 做网关分析，同时使用另一个框架做离线 eval 或 CI 回归套件。

局限

Helicone 不是本排名中最深入的 agent 轨迹评估平台。它自己的博客覆盖更广泛的 LLM 可观测性和提示词评估框架，⁴⁰⁴¹ 但需要复杂多步骤 agent 评分、数据集管理和 CI 门禁的团队，可能会超出网关优先方案的能力范围。

定价 / 公开指标

Helicone 公开发布定价。³⁶ 在所需来源中未找到公开收入、客户数量或请求量指标。

9. Ragas — 最佳专用 RAG 评估框架

最适合： 关注 RAG 质量、检索指标、合成测试集生成和评估实验，而非完整生产可观测性仪表盘的团队。

Ragas 是最知名的开源 RAG 评估框架之一。其文档覆盖评估工作流，⁴² 网站解释了该项目，⁴³ 集成有文档说明，⁴⁴ 也提供了面向评估应用的成本相关指引。⁴⁵

核心能力

• RAG 评估指标。
• 测试集生成和实验。
• 与更广泛 LLM 工具的集成。⁴⁴
• 成本感知的评估指引。⁴⁵
• 适用于检索质量和答案 grounding 分析。

优势

当核心生产风险是检索质量时，Ragas 非常出色：上下文不完整、grounding 不佳、答案忠实度弱或检索召回差。它提供的指标和工作流比通用文本评分更专门。

它也能与可观测性平台良好配合。例如，团队可以在 Langfuse 或 Phoenix 中捕获 trace，并使用 Ragas 风格指标进行 RAG 专项评估。

局限

Ragas 不是独立的生产可观测性仪表盘。它不能替代 trace 摄取、告警、会话分析、成本监控或企业审查工作流。它属于评估工具箱，而不是生产 agent 的唯一 harness。

定价 / 公开指标

Ragas 文档和网站是公开的。⁴²⁴³ 在所需来源中未找到托管 Ragas 平台的公开定价或收入指标。

对比矩阵

MCPlato 的定位：Eval Harness 外围的工作空间 Harness

MCPlato 不应在这个类别中被列为直接 eval 或可观测性厂商。它不是专用 eval 仪表盘，不是 OpenTelemetry pipeline，不是生产 trace 仓库，也不是 LangSmith、Braintrust、Langfuse、Phoenix / AX、Galileo、DeepEval、OpenAI Agent Evals、Helicone 或 Ragas 的替代品。

它的角色不同：MCPlato 是一个 本地优先 AI Partner 和工作空间 harness。⁴⁶ 它帮助团队协调正式生产评估之前、周围和之后发生的人类与 AI 工作：

• 研究 agent 失败和用户痛点；
• 跨文件、浏览器会话和工具原型化 agent 工作流；
• 从本地文档、笔记、日志和研究中准备 eval 数据集；
• 使用持久本地上下文运行多会话 AI 工作；
• 在调试和审查期间让人类保持在环；
• 围绕项目组织工作空间记忆、产物和连接材料。

这使 MCPlato 成为 eval 技术栈的补充。一个实用工作流可能是：

1. 使用 MCPlato 调查失败报告、收集示例、检查本地文件、协调研究会话并起草 eval cases。
2. 使用 LangSmith、Braintrust、Langfuse、Phoenix / AX、Galileo、DeepEval、OpenAI Agent Evals、Helicone 或 Ragas 运行 telemetry、trace 摄取、仪表盘、eval 评分、告警和 CI/CD 回归。
3. 将失败和洞察带回 MCPlato，用于人工审查、文档、原型迭代和工作空间级协作。

MCPlato 的 changelog 显示它是一个持续演进的桌面 AI 工作空间产品，⁴⁷ 但团队应将其视为 eval harness 外围的协作与编排环境，而不是 eval harness 本身。

按团队类型选择指南

如果你是重度 LangChain 或 LangGraph 团队

从 LangSmith 开始。它提供了从框架原生 trace 到生产监控和 eval 的最直接路径。

如果你的组织正在建立 eval 纪律

如果数据集、实验、人工审查和回归工作流是 AI 质量流程的中心，请选择 Braintrust。

如果你需要开源或自托管

优先考虑 Langfuse、Arize Phoenix、DeepEval、Helicone 和 Ragas。Langfuse 是最强的全能自托管可观测性选项；Phoenix 在开放可观测性和 OpenInference 方面很强；DeepEval 和 Ragas 更偏框架。

如果 OpenTelemetry 对齐是优先事项

重点关注 Arize Phoenix / AX、Langfuse 和 Braintrust。OpenTelemetry 很重要，因为 agent trace 最终应与服务 trace、基础设施指标和事故工作流共存。

如果你需要企业托管评估

评估 Galileo、Arize AX、Braintrust 和 LangSmith。正确选择取决于治理、支持、部署、集成，以及你希望自己拥有多少评估逻辑。

如果你是 OpenAI 原生团队

尽早使用 OpenAI Agent Evals，尤其是在使用 OpenAI Agents 构建并希望获得原生 trace grading 时。如果预计会扩展到多模型或多框架，请考虑厂商中立层。

如果你需要快速请求 / 成本可见性

从 Helicone 开始。它是了解支出、延迟和请求行为最快的方式之一。

如果 RAG 质量是主要风险

将 Ragas 与更广泛的可观测性工具一起使用。它是指标框架，不是完整生产仪表盘。

如果你的瓶颈是工作空间编排

当团队需要本地优先 AI 工作空间来进行研究、原型开发、调试、数据集准备和人类协作时，使用 MCPlato。然后把生成的 eval cases 和运营洞察连接到专用 eval / 可观测性平台。

更大的图景：Evals + Traces + OTel + 人工审查 + 工作空间编排

市场方向很清晰。生产 agent 质量正在成为一个闭环：

1. 为一切建立 instrumentation。 捕获模型调用、工具调用、检索、交接、用户反馈、成本、延迟和错误。
2. 把 trace 转化为 eval。 每一次严重失败都应成为数据集行、回归测试或人工审查项。
3. 部署前运行 eval。 CI/CD 门禁应捕获提示词、模型、工具和工作流回归。
4. 部署后监控。 线上分数、告警和仪表盘应暴露漂移和静默失败。
5. 让人类保持在环。 对于模糊任务、政策决策、边界案例和信任校准，审查者仍然重要。
6. 使用工作空间编排。 像 MCPlato 这样的工具帮助团队组织周边工作：研究、上下文、文件、记忆、协作和调试产物。

没有任何单一工具能完美覆盖整个闭环。LangSmith、Braintrust、Langfuse、Phoenix / AX、Galileo、DeepEval、OpenAI Agent Evals、Helicone 和 Ragas 各自覆盖不同部分。MCPlato 覆盖的是另一个不同但日益重要的层：本地工作空间，人类和 AI agents 在其中准备、检查和迭代，随后由生产质量系统执行规则。

对于 2026 年的大多数生产团队，胜出的技术栈不会是一个仪表盘。它会是 agent trace、可重复 eval、OpenTelemetry 兼容可观测性、人工审查，以及能让工作保持连贯的工作空间 harness 的组合。

References

Footnotes

1. LangSmith Observability — https://www.langchain.com/langsmith/observability ↩

2. LangSmith Evaluation Docs — https://docs.langchain.com/langsmith/evaluation ↩

3. LangChain Pricing — https://www.langchain.com/pricing ↩ ↩²

4. Braintrust Homepage — https://www.braintrust.dev/ ↩

5. Braintrust OpenTelemetry Integration — https://www.braintrust.dev/docs/integrations/sdk-integrations/opentelemetry ↩ ↩²

6. Braintrust Customers — https://www.braintrust.dev/customers ↩ ↩²

7. Braintrust Series A Announcement — https://www.braintrust.dev/blog/announcing-series-a ↩

8. Braintrust Pricing — https://www.braintrust.dev/pricing ↩

9. Langfuse GitHub — https://github.com/langfuse/langfuse ↩

10. Langfuse Pricing — https://langfuse.com/pricing ↩ ↩²

11. Langfuse Self-hosting — https://langfuse.com/self-hosting ↩ ↩² ↩³

12. Langfuse OpenTelemetry Integration — https://langfuse.com/integrations/native/opentelemetry ↩ ↩²

13. Langfuse Automated Evaluations — https://langfuse.com/blog/2025-09-05-automated-evaluations ↩

14. Arize Phoenix — https://arize.com/phoenix/ ↩ ↩²

15. Arize Agent Observability — https://arize.com/ai-agents/agent-observability/ ↩ ↩²

16. Arize Phoenix GitHub — https://github.com/arize-ai/phoenix ↩ ↩²

17. Arize AX OpenTelemetry Integration — https://arize.com/docs/ax/integrations/opentelemetry/opentelemetry-arize-otel ↩

18. Arize OTel / OpenInference Blog — https://arize.com/blog/zero-to-a-million-instrumenting-llms-with-otel/ ↩

19. Arize Series C Announcement — https://arize.com/blog/arize-ai-raises-70m-series-c-to-build-the-gold-standard-for-ai-evaluation-observability/ ↩ ↩²

20. Galileo Homepage — https://galileo.ai/ ↩

21. Galileo Pricing — https://galileo.ai/pricing ↩ ↩²

22. Galileo Case Studies — https://galileo.ai/case-studies ↩ ↩²

23. Google Cloud Customer Story: Galileo — https://cloud.google.com/customers/galileo ↩ ↩² ↩³

24. Galileo Agentic Evaluations Announcement — https://www.prnewswire.com/news-releases/galileo-launches-agentic-evaluations-to-empower-developers-to-build-reliable-ai-agents-302358451.html ↩ ↩²

25. DeepEval Homepage — https://deepeval.com/ ↩

26. DeepEval GitHub — https://github.com/confident-ai/deepeval ↩ ↩²

27. Confident AI DeepEval Framework — https://www.confident-ai.com/frameworks/deepeval ↩

28. Confident AI Docs — https://www.confident-ai.com/docs ↩ ↩²

29. Confident AI Pricing — https://www.confident-ai.com/pricing ↩ ↩²

30. OpenAI Agent Evals Guide — https://developers.openai.com/api/docs/guides/agent-evals ↩ ↩²

31. OpenAI Agents Guide — https://developers.openai.com/api/docs/guides/agents ↩ ↩²

32. OpenAI Agents Observability Integrations — https://developers.openai.com/api/docs/guides/agents/integrations-observability ↩ ↩²

33. OpenAI Trace Grading — https://developers.openai.com/api/docs/guides/trace-grading ↩ ↩²

34. OpenAI Evals GitHub — https://github.com/openai/evals ↩

35. OpenAI Pricing — https://developers.openai.com/api/docs/pricing ↩

36. Helicone Pricing — https://www.helicone.ai/pricing ↩ ↩²

37. Helicone Scores Docs — https://docs.helicone.ai/features/advanced-usage/scores ↩ ↩²

38. Helicone GitHub — https://github.com/Helicone/helicone ↩ ↩²

39. AI SDK Helicone Observability Provider — https://ai-sdk.dev/providers/observability/helicone ↩ ↩²

40. Helicone LLM Observability Platforms Guide — https://www.helicone.ai/blog/the-complete-guide-to-LLM-observability-platforms ↩

41. Helicone Prompt Evaluation Frameworks Guide — https://www.helicone.ai/blog/prompt-evaluation-frameworks ↩

42. Ragas Docs — https://docs.ragas.io/en/stable/ ↩ ↩²

43. Ragas Website — https://www.ragas.io/ ↩ ↩²

44. Ragas Integrations — https://docs.ragas.io/en/stable/howtos/integrations/ ↩ ↩²

45. Ragas Cost Docs — https://docs.ragas.io/en/v0.2.5/howtos/applications/_cost/ ↩ ↩²

46. MCPlato Homepage — https://mcplato.com/en/ ↩

47. MCPlato Changelog — https://mcplato.com/en/changelog/ ↩