Agent Eval 调研报告

调研日期：2026-03-25 目标：系统梳理 Agent 评测方法论与工具生态，为自建评测平台提供设计参考

目录

• 第一部分：Agent Eval 方法论综述
  • 1.1 为什么需要 Agent Eval
  • 1.2 Hamel 方法论精要
  • 1.3 Anthropic 方法论精要
  • 1.4 Anthropic Harness Design 实践
  • 1.5 方法论对比与互补
  • 1.6 Agent Eval 核心原则
• 第二部分：评测平台深度分析
  • 2.1 Scale Nucleus — AI 1.0 范式
  • 2.2 LangSmith — LangChain 生态中心
  • 2.3 BrainTrust — 观测+评测+优化闭环
  • 2.4 Arize Phoenix — OpenTelemetry 原生开源
  • 2.5 DeepEval — 代码优先评测框架
  • 2.6 Langfuse — 一体化 LLM 工程平台
• 第三部分：平台横向对比矩阵
  • 3.1 功能对比表
  • 3.2 架构对比表
  • 3.3 核心概念映射表
• 第四部分：自建平台设计启示
  • 4.1 核心概念抽象
  • 4.2 必备能力清单
  • 4.3 架构设计建议
  • 4.4 值得借鉴的设计模式
  • 4.5 技术选型建议

第一部分：Agent Eval 方法论综述

1.1 为什么需要 Agent Eval

传统 LLM eval 与 Agent eval 存在本质区别：

Agent 的三大评测挑战：

1. 非确定性 — 同一任务的成功率在多次执行间波动，需要概率性指标（pass@k, pass^k）而非单次判定
2. 状态传播与错误级联 — 一个步骤的失误会在后续步骤中放大，评测需要追踪完整执行链
3. 创造性解法 — Agent 可能找到超出预设 grading 范围的合理解法，过度刚性的 grader 会误判

1.2 Hamel 方法论精要

来源：Hamel Husain & Shreya Shankar — LLM Evals: Everything You Need to Know (2026-01)

核心哲学

Error Analysis 驱动一切 — 不是先定义指标再评测，而是先观察真实失败再构建评测。你的独特失败模式、领域约束和用户需求，无法被通用工具解决。

四步流程

┌─────────────────────────────────────────────────────────┐
│  Step 1: 创建数据集                                      │
│  收集真实用户交互 traces（或合成数据）                      │
├─────────────────────────────────────────────────────────┤
│  Step 2: Open Coding（开放编码）                          │
│  领域专家逐条审阅 traces，自由记录观察到的问题              │
│  聚焦每条 trace 的「第一个上游失败」                       │
│  ⚠ 此步骤绝不可外包或自动化                               │
├─────────────────────────────────────────────────────────┤
│  Step 3: Axial Coding（轴向编码）                         │
│  将开放笔记分类为失败分类体系                              │
│  统计每个类别的失败数量                                    │
│  LLM 可辅助分组，但人工必须验证                            │
├─────────────────────────────────────────────────────────┤
│  Step 4: 迭代至饱和                                      │
│  持续直到新 traces 不再揭示新的失败模式                     │
│  目标：审阅至少 100 条 traces                             │
└─────────────────────────────────────────────────────────┘

关键主张

二元评分（Binary Pass/Fail） — 强烈反对 Likert 量表（1-5 分），理由：

• 相邻分数主观性过强（3 分 vs 4 分因人而异）
• 检测统计显著性需要更大样本量
• 标注者倾向选中间值
• 二元标签迫使更清晰的决策

LLM-as-Judge 的正确用法：

• 需要 100+ 人工标注的样本来校准
• 必须测量 True Positive Rate 和 True Negative Rate
• 每周维护更新
• 应该输出 pass/fail 判定 + 理由，而非数字评分
• 若简单的代码检查（regex、格式验证）能解决，就不要用 LLM-as-Judge

反对 Eval-Driven Development — 认为不应在构建功能前就写 evaluator（与 Anthropic 相反），因为 LLM 的失败表面无限大，无法预判哪里会出问题。

Agent 评测的两阶段模型：

• Phase 1: 黑盒 — 端到端任务成功率，Agent 作为整体评估
• Phase 2: 白盒 — 步骤级诊断（工具选择、参数提取、错误恢复、上下文保持、效率）

最低可行实践

每次变更时花 30 分钟手动审阅 20-50 条输出。指定一位领域专家作为 "benevolent dictator"（质量仲裁者）。用 Notebook 做 trace 审阅。这比购买任何平台都更有效。

1.3 Anthropic 方法论精要

来源：Anthropic Engineering — Demystifying Evals for AI Agents (2026)

核心哲学

Eval-Driven Development (EDD) — 类比 TDD：先写 eval 定义期望能力，再迭代 Agent 直到通过。没有 eval 的团队 "陷入被动循环 — 只在生产中发现问题，修一个导致另一个"。

关键指标：pass@k 与 pass^k

示例：若单次成功率 75%，k=3 时 pass@3 ≈ 98.4%，pass^3 ≈ 42.2%。两者在 k=1 时相同，k 增大后急剧分化。

八步路线图

三类 Grader

CORE-Bench 警示

Opus 4.5 初始得分 42%，研究者发现刚性 grader 在数字精度上误判（期望完整字符串 "96.124991..." 但 agent 输出 "96.12"），修复 grader 后得分跳升至 95%。教训：永远检查 transcripts 验证 grader 行为。

瑞士奶酪模型

没有单一评估层能捕获所有问题。组合使用：自动化 eval + 生产监控 + A/B 测试 + 用户反馈 + transcript 审查 + 人工研究。

1.4 Anthropic Harness Design 实践 — 长时运行 Agent 的评测架构

来源：Prithvi Rajasekaran (Anthropic Labs) — Harness Design for Long-Running Application Development (2026-03-24)

核心问题：朴素实现为何失败

长时运行的 Agentic Coding 存在两个持续性失败模式：

1. 上下文窗口退化（Context Window Degradation）

模型在上下文填满时丧失连贯性，并表现出"上下文焦虑"（context anxiety）— 在接近感知极限时过早结束工作。虽然压缩（compaction，即对早期对话做摘要）能保持连续性，但无法提供 agent 所需的"干净白板"。上下文重置（context reset）是必要的，但增加了编排复杂度和 token 开销。

2. 自评偏差（Self-Evaluation Bias）

"Agents tend to respond by confidently praising the work—even when, to a human observer, the quality is obviously mediocre."

Agent 倾向于自信地赞美自己的工作 — 即使在人类观察者看来质量明显平庸。将评测与生成分离使评估更可靠。调教一个独立的 evaluator 使其保持怀疑态度，比让 generator 自我批判更可行。

三 Agent 架构：Planner → Generator → Evaluator

┌─────────────────────────────────────────────────────────┐
│  Planner Agent（规划者）                                  │
│  将简短 prompt（1-4 句话）扩展为完整产品规格              │
│  聚焦范围与高层技术设计，非逐行实现细节                    │
│  主动识别 AI 功能集成机会                                  │
├─────────────────────────────────────────────────────────┤
│  Generator Agent（生成者）                                │
│  增量实现功能（React + Vite + FastAPI + PostgreSQL）      │
│  自评后交付给 QA，维护版本控制                             │
├─────────────────────────────────────────────────────────┤
│  Evaluator Agent（评测者）                                │
│  使用 Playwright MCP 像用户一样测试应用                    │
│  主动导航、截图、检查 UI / API / 数据库状态                │
│  与 Generator 协商 sprint 合约，定义成功标准                │
└─────────────────────────────────────────────────────────┘

Agent 间通过文件化交接（file-based handoffs）通信 — 一个 agent 写入结构化文件，下一个 agent 读取并响应。这种方式在跨会话时保持上下文保真度，无需直接 API 链。

Sprint 合约机制

Generator 在实现前提出可交付物和成功标准，Evaluator 审核提案确保正确性后才开始编码。每个合约包含 27+ 个具体验收标准（如："矩形填充工具允许点击拖拽，用选中的 tile 填充矩形区域"）。

硬阈值判定： 任何单个标准的失败导致整个 sprint 失败，触发详细反馈驱动 Generator 迭代。

前端设计评测：让主观质量可评分

受 GAN（生成对抗网络）启发，建立了 generator-evaluator 循环，四个具体评分维度：

校准方法： 使用 few-shot 示例 + 详细评分分解来校准 evaluator，确保判断对齐并减少跨迭代的评分漂移。

迭代行为： 5-15 轮迭代中评分持续改善后趋于平台期。Generator 在每轮评测后做策略性决策 — 趋势良好则继续优化，表现不佳则彻底转向。部分设计在第 10 轮迭代时出现意外的创造性飞跃。

实验结果

完整 Harness 产出了跨 10 个 sprint 的 16 项功能规格，而单次运行范围有限。Evaluator 捕获了单次运行完全遗漏的关键问题（如实体到运行时的连线断裂、动画系统缺失）。

关键洞察：Harness 的简化与演进

"Every component in a harness encodes an assumption about what the model can't do on its own, and those assumptions are worth stress testing." — Harness 中的每个组件都编码了关于模型无法独立完成的假设，这些假设值得压力测试。

模型能力与 Harness 复杂度的反比关系：

• Opus 4.5 → 需要 context reset、sprint 分解、多轮协商
• Opus 4.6 → 原生消除上下文焦虑，可连续工作两小时以上无需分解；Sprint 构造被成功移除，从逐 sprint 评测转为单次最终 QA

实践原则： 每次新模型发布时重新审视 harness — 系统性移除不必要的脚手架组件，同时为新出现的能力缺口添加专门 agent。

对评测方法论的启示

1.5 方法论对比与互补

三方互补关系： Hamel 告诉你"发现什么问题"（Error Analysis），Anthropic EDD 告诉你"如何系统化评测"（pass@k + grader 层级），Harness Design 告诉你"如何在长时运行中保持评测有效"（分离生成/评测 + 上下文管理 + 可退化架构）。三者组合覆盖了从问题发现到系统化评测再到工程化运行的完整链路。

1.6 Agent Eval 核心原则

从三篇文章中提炼出 9 条核心原则：

原则 1: Error Analysis 是基础，不是可选项

无论采用何种方法论，手动审阅真实 traces 是不可替代的第一步。只有看到真实失败，才能构建有意义的 eval。

原则 2: 评判结果（Outcome），而非路径（Trajectory）

Agent 可能找到意想不到但完全合理的解法。Grader 应验证环境最终状态（如：数据库中是否存在预期记录），而非检查是否执行了预设步骤序列。

原则 3: 确定性 Grader 优先，LLM Grader 为必要补充

成本-可靠性阶梯：代码断言 > 规则匹配 > LLM-as-Judge > 人工评审。每层都有用武之地，但从最便宜最可靠的开始。

原则 4: 非确定性是本质属性，必须用概率视角

Agent 的成功率在运行间波动。必须多次运行同一任务，用 pass@k / pass^k 等概率指标描述能力。

原则 5: 环境隔离是刚需

每次 eval trial 必须从干净状态启动。共享状态（残留文件、缓存、资源耗尽）会导致与 agent 能力无关的相关性失败。

原则 6: 永远检查 Transcripts

再好的自动化 grader 也可能误判。定期审阅 agent 实际输出 + grader 判定，是发现 grader 缺陷的唯一方式。CORE-Bench 事件（42%→95%）是最佳警示。

原则 7: Eval 是活的系统，不是一次性设置

Eval 需要持续维护：添加新任务、修复 grader、应对能力饱和、追踪标准漂移。像对待生产代码一样对待 eval 代码。

原则 8: 生成与评测必须分离

Agent 存在系统性的自评偏差 — 即使输出质量明显平庸也会自信地赞美自己的工作。将 evaluator 独立为专职角色，调教其保持怀疑态度，比让 generator 自我批判更可行、更可靠。这是 GAN 思想在工程评测中的应用。

原则 9: Harness 是可退化的脚手架

Harness 中的每个组件都编码了关于模型无法独立完成的假设。随着模型能力提升（如 Opus 4.5→4.6），应系统性地压力测试这些假设并移除不必要的复杂度。过度脚手架与不足脚手架同样有害。

第二部分：评测平台深度分析

2.1 Scale Nucleus — AI 1.0 范式

定位与设计哲学

Scale AI（2016 年创立）以数据标注起家，核心信念是 AI 质量 = 数据质量。这种"数据中心主义"渗透到其评测产品中：与 LLM 原生平台（从 prompt 工程和 trace 观测出发）不同，Scale 从 策展数据集、专家人工标注、ground-truth 对比 的角度切入评测。

产品演进线：

• Scale Nucleus（2020）— CV/ML 数据集管理与调试
• Scale GenAI Platform (SGP)（2023）— 企业级 GenAI 构建平台（RAG、微调、评测）
• SEAL / Scale Labs（2023-2026）— 公开排行榜与基准测试研究
• Scale Agentex（2025-2026）— 开源 Agent 执行框架

关键哲学： Human-in-the-Loop（HiTL）评测是不可谈判的底线。自动化指标必要但不够充分。

核心概念

评测能力

• Rubric 评分体系： no_issues / minor_issues / major_issues，标准分为 objective 和 implicit
• SEAL 排行榜方法论（研究级）：
  • 私有数据集防止污染/刷榜
  • 专家筛选评估员（面试 + 已知答案准确性测试）
  • 多轮 QA（审查层→二次求解→独立审计）
  • 成对比较（每个模型每个 prompt 比较 50+ 次）
  • 所有分数配置置信区间

Agent 评测支持

• ToolComp 基准： 485 个 prompt 测试依赖性工具使用（链式工具调用）
• SGP Agent Evaluation： 专用任务类型 + span 级追踪 + 分布式追踪
• Scale Agentex： 开源（Apache 2.0）Agent 执行框架，Kubernetes 原生
• 过程监督标签： 步骤级评测（不仅是最终答案）

开源与商业模式

商业模式：企业优先，定制定价（通常六位数年费）。

架构亮点

1. Trust Feedback Loop — 测量→设标准→HiTL 验证→迭代→监控
2. 私有数据集防污染 — SEAL 的数据集从不公开发布
3. 多分辨率评测 — 数据集级→切片级→条目级→span 级
4. Rubric 作为一等公民 — 动态、贡献者定义的 rubric（非硬编码指标函数）
5. QueryAST — 结构化查询语言用于切片评测数据

2.2 LangSmith — LangChain 生态中心

定位与设计哲学

LangChain Inc. 的商业观测、评测与部署平台。定位为 LangChain 生态的运营控制平面，覆盖完整应用生命周期：开发调试→评测测试→生产监控→Agent 部署。

核心定位决策：

• 声称框架无关，但最深度集成仍在 LangChain/LangGraph
• 观测优先、评测其次（架构痕迹：评测结果不在 trace 视图中内联显示）
• 闭源商业 SaaS（自托管需 Enterprise 合同）

核心概念

评测能力

离线评测： 对策展数据集运行，用于基准测试、回归测试、单元测试

在线评测： 实时评分生产流量，失败案例自动导入离线数据集

评测器类型：

• 人工评测：标注队列 + 结构化 rubric + 成对比较
• 代码评测器：确定性规则检查
• LLM-as-Judge：有参考/无参考两种模式
• 成对评测：两个版本 side-by-side 比较

预构建评测器（openevals + agentevals，MIT 开源）：

• 质量：Correctness, Conciseness, Helpfulness
• 安全：Safety, Security vulnerability
• RAG：Groundedness, Retrieval relevance, Hallucination
• 代码：Pyright, MyPy, TypeScript 类型检查, 沙箱执行
• 结构化输出：Exact match, Tool call 验证, JSON schema
• 相似度：Levenshtein, Embedding similarity

Agent 评测支持（最突出领域之一）

轨迹评测（agentevals 库）：

• Trajectory Match Evaluator（确定性，无需 LLM）：
  • Strict：完全相同的消息序列和工具调用顺序
  • Unordered：相同工具调用，任意顺序
  • Superset：Agent 至少调用了参考工具，可额外调用
  • Subset：Agent 只能调用参考中出现的工具
• Trajectory LLM-as-Judge： 用 rubric prompt 评估轨迹质量

多轮评测： 基于 Thread 抽象的语义意图、语义结果、Agent 轨迹评估

Insights Agent： AI 驱动的生产 trace 自动分析，聚类使用模式和失败模式

开源与商业模式

定价：

• Developer: 免费，1 座席，5K traces/月
• Plus: $39/座席/月，10K traces/月
• Enterprise: 定制价格
• Trace 超额：$2.50-$5.00/1K traces

架构亮点

1. Trace-as-a-Tree 模型 — 带类型的 span（llm/chain/tool/retriever/embedding）
2. 离线/在线评测双用 — 相同 evaluator 函数在两种上下文中工作
3. 轨迹评测四种匹配模式 — Strict/Unordered/Subset/Superset
4. Thread 抽象 — 优雅地支持多轮评测
5. 标注队列工作流 — 结构化人工评测→直接转入数据集

优劣势

优势： Agent 轨迹评测最佳、LangChain 零配置集成、全生命周期覆盖、OpenTelemetry 支持

劣势： 闭源（自托管需企业合同）、LangChain 生态耦合、评测-观测视图分离、无内置红队测试、按座席+按 trace 定价

2.3 BrainTrust — 观测+评测+优化闭环

定位与设计哲学

核心论点：AI 的失败模式不同于传统软件 — 模型漂移、幻觉、静默回归。BrainTrust 的目标是将 "凭感觉发布" 变为系统化、可测量的迭代。

Observe-Evaluate-Optimize 三支柱：

• Observe — 检查每条 trace，钻入工具调用，实时追踪延迟/成本/质量
• Evaluate — 开发阶段的结构化实验 + 生产环境的实时评分
• Optimize — Loop AI Agent 从自然语言自动生成更好的 prompt、scorer、dataset

核心概念

关键架构选择： 统一数据结构 — instrumentation 代码在 logging 和 evaluation 中完全相同。生产 trace 一键转为 eval 用例。

评测能力

离线评测（Experiments）：

• Eval() 函数 / CLI / UI 运行结构化实验
• trialCount 参数支持多次运行同一输入以测量方差
• Side-by-side 实验比较，测试用例粒度的回归检测
• CI/CD 集成：braintrustdata/eval-action GitHub Action

在线评测（Production Scoring）：

• 实时评分生产请求，使用与离线相同的 scorer
• 低分 trace 自动反馈到离线数据集

内置 Scorer（autoevals 库，开源）：

• LLM-as-Judge：Battle, Closed QA, Factuality, Moderation, Security, Summarization, SQL, Translation
• RAG：Context precision/relevancy/recall/entity recall, Faithfulness, Answer relevancy/similarity/correctness
• 启发式：Levenshtein, Exact match, Numeric difference, JSON diff
• Embedding：Embedding similarity
• 统计：BLEU
• 共 25+ 内置 scorer

Agent 评测支持

多层评测架构：

• Reasoning Layer： 规划质量、规划遵守度、工具选择准确性
• Action Layer： 工具正确性、参数有效性、执行路径质量、冗余循环检测
• End-to-End： 任务完成率、步骤效率、资源消耗

框架支持（10+）： OpenAI Agents SDK, Claude Agent SDK, LangGraph, CrewAI, Autogen, Google ADK, LiveKit Agents, Mastra, Pydantic AI, Strands Agent SDK

开源与商业模式

定价：

• Starter: 免费，1GB/月，10K scores/月，14 天保留
• Pro: $249/月，5GB/月，50K scores/月，30 天保留
• Enterprise: 定制

自托管数据平面（Enterprise）： Lambda + Postgres 部署在客户 AWS/GCP/Azure 环境，数据不离开客户账户。

架构亮点

1. Brainstore（专用数据库） — 针对 AI trace 特性（每 span 数十 KB）设计的 Rust 流式引擎 + 对象存储
2. 统一数据模型 — eval 和 production 使用完全相同的 instrumentation 代码和数据结构
3. DAG 追踪模型 — Trace 是 DAG（非仅树），span 通过 async context 自动嵌套
4. 生产→评测飞轮 — 一键将生产 trace 转为数据集条目，低分 trace 自动反馈
5. Gateway（战略入口） — 单一 OpenAI 兼容端点覆盖 100+ 模型，请求自动进入追踪/评测管线
6. Loop AI Co-pilot — 从自然语言生成 dataset/scorer/prompt 优化，让非工程师也能参与评测

优劣势

优势： 最紧密的 observe-eval 闭环、优秀的 Agent 评测支持、Gateway 战略入口、Loop AI（独特差异化）、6 种语言 SDK、CI/CD 原生

劣势： 核心平台闭源、低层级定价的短数据保留期（14/30天）、Gateway 供应商锁定风险、无成熟的人工标注管线

2.4 Arize Phoenix — OpenTelemetry 原生开源

定位与设计哲学

Phoenix 是 Arize AI 构建的开源 AI 观测与评测平台。核心押注在 OpenTelemetry 原生、供应商中立。

设计哲学：

• 开放标准优先 — 基于 OTel + OpenInference（AI 特定的 OTel 语义约定扩展）
• 框架/供应商无关 — 平等对待所有集成
• 零特性门控 — 所有功能在开源版本中可用
• "玻璃箱"透明 — 包括 GTM tickets 在内的所有开发过程在 GitHub 上公开

GitHub： ~9,000 stars，774 forks。PyPI 月下载量 250 万+。

核心概念

评测能力

三种评测模式：

• 客户端（SDK）： Python/TypeScript SDK 对 trace、dataset、自定义数据运行评测
• 服务端（UI）： 在 Phoenix 界面配置评测器，无需代码
• 在线（生产）： 每 2 分钟自动对生产 trace 运行评测器

预构建 LLM 评测器： Faithfulness, Conciseness, Correctness, Document Relevance, Tool Selection, Tool Invocation, Tool Response Handling, Refusal, Toxicity, Q&A, Summarization, SQL Generation

代码评测器： Exact Match, Matches Regex, Precision/Recall/F-Score

关键设计：

• 使用 Function Calling 提取结构化评判（非正则解析自由文本）
• 评测器自身通过 OTel 自动 instrument — 可追踪和调试评测过程本身（evals-of-evals）
• 输入映射支持 Key mapping / JSONPath / Callable

Agent 评测支持

• Agent Span Kind — 一等公民概念，表示包含 LLM + Tool 调用的推理块
• 多步轨迹评测 — LLM-as-Judge 评估 agent 完整工具调用序列
• Path Convergence Metric — 量化 agent 效率（最小步骤 / 实际步骤）
• 三个工具评测器： Tool Selection / Tool Invocation / Tool Response Handling
• 多 Agent 系统追踪： 跨框架（Agno, Autogen, CrewAI, LangGraph, SmolAgents）可视化
• MCP 集成： OTel instrumentation 桥接客户端-服务端可见性

集成模式

40+ 自动 instrumentation（via OpenInference）： OpenAI, OpenAI Agents SDK, Claude Agent SDK, LangChain, LangGraph, LlamaIndex, DSPy, CrewAI, Haystack, Vercel AI SDK, Mastra, Anthropic, AWS Bedrock, Google GenAI, Google ADK, MistralAI, Groq, LiteLLM 等

第三方评测集成： Ragas, DeepEval, Cleanlab

开源与商业模式

ELv2 注意： 非 MIT/Apache 许可。法律团队可能标记此许可。它专门保护 Arize 的云业务。

架构亮点

1. OTel-Native 设计（最大洞察） — 基于 OTel 原语构建，trace 可移植到任何 OTel 兼容后端
2. OpenInference 语义约定 — AI 特定语义约定作为 OTel 扩展（非替代）
3. 评测器标准化接口 — Score 对象（name, kind, direction, score, label, explanation, metadata）
4. 评测可观测性 — 自动 instrument 评测器本身，可追踪和调试评测过程
5. Function Calling 提取结构化输出 — 消除脆弱的 "解析 LLM 文本输出" 步骤

优劣势

优势： 最强 OTel 集成、40+ 框架 auto-instrumentation、零特性门控、Agent 评测深度好、在线评测能力、评测过程可观测

劣势： ELv2 许可（非真正开源）、OTel 配置复杂度、SQLite 默认不可扩展、TypeScript 评测 SDK 仍为 alpha、开源是商业平台入口

2.5 DeepEval — 代码优先评测框架

定位与设计哲学

开源（Apache 2.0）Python 评测框架，定位为 "Pytest for LLMs"。GitHub 14,200+ stars。由 Confident AI Inc. 创建。

核心设计哲学：

• 代码优先、pytest 原生 — 评测 = 单元测试。assert_test() 镜像 assert 语义
• 受约束的 LLM-as-Judge — 将 judge LLM 限制在极其受限的评测任务中（QAG, G-Eval CoT, DAG 决策树）
• 研究背书 — 指标明确引用发表论文（G-Eval NeurIPS 2023, Evol-Instruct 等）

核心概念

评测能力（50+ 指标）

全能/自定义（2）：

• G-Eval — CoT 生成评测步骤 + 评分（支持自定义 rubric）
• DAG（有向无环图） — 确定性决策树指标构建器（TaskNode → BinaryJudgementNode → VerdictNode）

Agent 指标（8）： Task Completion, Tool Correctness, Goal Accuracy, Step Efficiency, Plan Adherence, Plan Quality, Tool Use, Argument Correctness

RAG 指标（6）： Answer Relevancy, Faithfulness, Contextual Recall/Precision/Relevancy, RAGAS 复合

多轮/聊天指标（5）： Knowledge Retention, Conversation Completeness, Turn Relevancy, Turn Faithfulness, Role Adherence

MCP 指标（3）： MCP Task Completion, MCP Use, Multi-Turn MCP Use

多模态指标（5）： Text to Image, Image Editing, Image Coherence, Image Helpfulness, Image Reference

安全指标（6+）： Bias, Toxicity, Non-Advice, Misuse, PII Leakage, Role Violation

通用指标（4+）： Hallucination, Summarization, JSON Correctness, Prompt Alignment

Agent 评测支持（最强领域之一）

@observe 装饰器追踪：

@observe(type="agent")
def travel_agent(user_input):
    @observe(type="tool")
    def search_flights(origin, destination, date): ...
    @observe(type="llm")
    def call_openai(messages): ...

框架集成： OpenAI Agents SDK, LangGraph, CrewAI, Pydantic AI, AWS AgentCore, Anthropic

组件级 vs 端到端： 指标可附加到 agent 级（端到端）或单个组件 span（通过 @observe(metrics=[...])）

开源与商业模式

架构亮点

1. Golden→TestCase 分离 — Golden 存储期望，TestCase 在运行时生成（干净分离 "测什么" vs "发生了什么"）
2. DAG 指标构建器 — 唯一的有向无环图方法构建确定性自定义指标，比纯 G-Eval 更可控
3. @observe 装饰器 — 轻量级、基于装饰器的追踪，指标直接附加到装饰函数
4. 异步优先执行 — 指标默认并发运行，内部操作也并发（LLM-as-judge 场景下关键）
5. DeepEvalBaseLLM 抽象 — 干净接口解耦指标与具体 LLM provider
6. Prompt 优化闭环 — 内置 prompt 精炼（GEPA 遗传搜索 / MIPROv2 代理搜索）

优劣势

优势： 最全指标库（50+）、Agent 评测最佳（8 个专用指标 + 追踪）、真正的 pytest 集成、DAG 指标构建器（独特）、Provider 无关、MCP 专用指标（市场首创）

劣势： 仅 Python、LLM-as-judge 成本高、文档分散混乱、OSS/商业边界有压力感、红队功能拆分到独立包、OSS 中无 trace 可视化

2.6 Langfuse — 一体化 LLM 工程平台

定位与设计哲学

开源（MIT）一体化 LLM 工程平台。三大设计支柱：

1. Open Source First — 核心 MIT 许可（/ee 文件夹外的一切），无使用限制
2. Self-Hostable — 自托管与云版本完全对等
3. OpenTelemetry 可扩展 — 接受 OTLP over HTTP（JSON + protobuf）

哲学： "观测中心化评测" — 评测不是独立活动，而是从全面追踪中自然涌现。先追踪一切，再在 trace 上层叠评分。

核心概念

评测能力

三种评分方法：

1. 模型评测（LLM-as-a-Judge）：

   • Managed 评测器： 预构建目录（幻觉、上下文相关性、毒性、有用性等）
   • Custom 评测器： 用户定义的评测 prompt + 变量占位符
   • JSONPath 变量映射，可配置采样百分比

2. 人工标注：

   • 标注队列（Annotation Queues）用于批量审查
   • 标准化 score 配置确保一致性
   • 人工评分作为校准自动评测器的金标准

3. 自定义/编程评测：

   • SDK create_score() 和基于上下文的 score_current_span() / score_current_trace()
   • REST API 用于语言无关集成
   • Score Configs 强制标准化

在线 vs 离线评测：

• 在线： 实时评测器自动处理匹配过滤器的新 observation/trace，可配置采样百分比
• 离线： 通过 SDK/API 获取 trace，在外部服务中运行评测，推送 score 回 Langfuse

实验： 对 Dataset 运行应用 → 捕获输出 → 应用评分 → Side-by-side 比较

Agent 评测支持（2025-2026 重点投入）

• Agent Graphs（GA）： 框架无关的可视化，从 observation 时序和嵌套推断执行流
• 工具调用渲染： 所有可用工具在每个 generation 顶部展示
• 三种评测策略：
  1. 最终响应（黑盒）： 输入→输出分析
  2. 轨迹（玻璃盒）： 完整工具调用和推理序列评测
  3. 单步（白盒）： 单个步骤级粒度
• 技能级评测方法论： 定义每个技能的代表性 prompt 数据集 → 运行实验 → 追踪所有行为 → LLM judge 评分

框架集成： LangGraph, Pydantic AI, CrewAI, OpenAI Agents SDK, AutoGen, smolagents, Strands Agents

集成模式

• 原生 SDK： Python（@observe 装饰器）+ JS/TS
• OpenTelemetry： OTLP 端点 /api/public/otel，四种集成路径
• 框架集成： OpenAI SDK, Anthropic SDK, LangChain, LlamaIndex, LangGraph, Pydantic AI, CrewAI, Vercel AI SDK
• REST API： 所有操作

开源与商业模式

关键差异化：所有付费层无限用户（无按座席定价）。

架构亮点

1. 双数据库策略：

   • PostgreSQL：事务数据（用户、组织、项目、API 密钥、prompt、dataset、eval 配置）
   • ClickHouse：观测/分析数据（trace、observation、score），ReplacingMergeTree 引擎
   • 效果：Prompts API p99 从 7s 降至 100ms，dashboard 查询 <1s p99

2. 异步摄入管线：

   • 轻量 API 接收事件 → 立即持久化到 S3
   • Redis 队列解耦处理
   • Worker 容器异步处理（tokenization, 成本计算, 去重）
   • 应用响应时间不受影响

3. S3 先于数据库写入 — 事件恢复能力

4. 全开源基础设施栈 — PostgreSQL + ClickHouse + Redis/Valkey + S3 兼容存储

优劣势

优势： 真正 MIT 开源（同类最强开源故事）、一体化内聚（追踪+评测+prompt管理）、OTel 原生架构、Agent 评测一等公民、生产级架构（ClickHouse 迁移证明工程成熟度）、无按座席定价、自托管完全对等

劣势： 评测耦合于追踪模型（纯离线 eval 不如专用工具方便）、无内置断言库、实验运行器基础（无参数网格搜索/并行执行）、ClickHouse 运维复杂度（自托管需 PG+CH+Redis+S3）、无原生 CI/CD 集成、Playground 限制

第三部分：平台横向对比矩阵

3.1 功能对比表

3.2 架构对比表

3.3 核心概念映射表

命名差异洞察：

• "评分" 在各平台含义相似但粒度不同：BrainTrust 的 Score 是 [0,1] 浮点数，Langfuse 的 Score 支持三种数据类型，DeepEval 强制 0-1 归一化
• "Span" 在 BrainTrust 中是 DAG 节点，在 Phoenix 中是 OTel Span，在 Langfuse 中是 Observation 的子类型
• "Evaluator" vs "Scorer" vs "Metric" vs "Grader" — 本质相同，命名反映设计哲学（测试 vs 评分 vs 测量 vs 评判）

第四部分：自建平台设计启示

4.1 核心概念抽象

从 6 个平台的数据模型中提炼出评测平台的最小公共抽象：

┌─────────────────────────────────────────────────────────┐
│                    Project（项目）                        │
│  顶层组织单元，隔离不同应用/环境                           │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  ┌─── Tracing Layer ──────────────────────────────┐     │
│  │  Trace    → 完整请求生命周期                     │     │
│  │  ├─ Span  → 工作单元（typed: llm/tool/agent/..）│     │
│  │  ├─ Span  → 可嵌套（树或 DAG）                   │     │
│  │  └─ ...                                        │     │
│  │  Session  → 多轮对话中的 Trace 分组              │     │
│  └────────────────────────────────────────────────┘     │
│                                                         │
│  ┌─── Evaluation Layer ───────────────────────────┐     │
│  │  Dataset     → 版本化测试用例集合               │     │
│  │  ├─ Example  → 单个测试用例(input + expected)   │     │
│  │  Evaluator   → 评分逻辑(code/llm/human)        │     │
│  │  Score       → 标准化评分结果                    │     │
│  │  Experiment  → Dataset × App Version × Evaluator │    │
│  └────────────────────────────────────────────────┘     │
│                                                         │
│  ┌─── Management Layer ───────────────────────────┐     │
│  │  Prompt       → 版本化模板 + 标签部署           │     │
│  │  Annotation   → 人工评审工作流                   │     │
│  └────────────────────────────────────────────────┘     │
└─────────────────────────────────────────────────────────┘

Score（评分结果）标准化设计

借鉴 Phoenix 的 Score 定义，建议自建平台的 Score 包含：

Score {
  name: string        // 指标名称
  kind: enum          // CODE | LLM | HUMAN
  data_type: enum     // NUMERIC | CATEGORICAL | BOOLEAN
  direction: enum     // MAXIMIZE | MINIMIZE | NONE
  value: number       // 数值结果
  label: string       // 分类标签（categorical 时）
  explanation: string // 评分理由（尤其 LLM judge 时）
  metadata: dict      // 扩展信息
}

Evaluator（评分函数）统一接口

class Evaluator:
    name: str
    kind: Literal["code", "llm", "human"]

    def evaluate(self, input, output, expected=None, trace=None) -> Score:
        """同步评测"""
        ...

    async def a_evaluate(self, input, output, expected=None, trace=None) -> Score:
        """异步评测"""
        ...

4.2 必备能力清单

MVP（第一阶段）

增强（第二阶段）

高级（第三阶段）

4.3 架构设计建议

存储层：双数据库策略

推荐：PostgreSQL + ClickHouse（借鉴 Langfuse v3）

关键模式： 写入路径 = API → S3 持久化 → Redis 队列 → Worker 异步处理 → ClickHouse 插入。应用响应时间不受观测数据处理影响。

摄入层：OTel-First

推荐：OpenTelemetry 原生 + 轻量私有 SDK

• OTLP 端点接收标准 OTel trace（供已有 OTel 基础设施的团队使用）
• 私有 SDK 提供 LLM 特定的高级封装（@observe 装饰器、token 计数、成本计算）
• 借鉴 OpenInference 的 AI 语义约定扩展 OTel（而非替代）

评测层：三级 Evaluator 架构

Level 1: Code Evaluator（确定性）
  → Exact match, regex, JSON schema, 代码执行测试
  → 快、便宜、可复现

Level 2: LLM Evaluator（模型驱动）
  → Function Calling 提取结构化判定（非自由文本解析）
  → 可配置 judge 模型、rubric、采样率
  → 评测器自身可追踪（evals-of-evals）

Level 3: Human Evaluator（金标准）
  → 标注队列、结构化 rubric
  → 用于校准 Level 2 的 LLM 评测器

API 设计：统一数据模型

关键原则（借鉴 BrainTrust）： 评测代码和生产 instrumentation 使用完全相同的数据结构。不要为 "eval 模式" 和 "production 模式" 构建两套系统。

4.4 值得借鉴的设计模式

模式 1: 生产→评测飞轮（BrainTrust）

生产 Trace → 低分检测 → 自动添加到 Dataset → 离线评测 → 改进 → 部署 → ...

一键将生产 trace 转为测试用例。低分 trace 自动反馈。闭环加速迭代。

模式 2: Function Calling 提取结构化 Judge 输出（Phoenix）

不要让 LLM judge 输出自由文本再正则解析。使用 tool use / function calling 强制结构化输出。消除脆弱的文本解析步骤，更鲁棒、更可移植。

模式 3: DAG 指标构建器（DeepEval）

TaskNode("extract_key_facts")
  → BinaryJudgementNode("all_facts_present?")
    → Yes → VerdictNode(score=1.0)
    → No → TaskNode("count_missing")
      → VerdictNode(score=missing/total)

将确定性逻辑路径与 LLM 判断节点组合，比纯 G-Eval 更可控，比纯代码更灵活。

模式 4: Golden→TestCase 分离（DeepEval）

Golden（期望数据）与 TestCase（运行时结果）明确分离。Golden 存储 "测什么"，TestCase 在评测时通过调用实际应用生成。干净分离、版本无关。

模式 5: 评测可观测性 — Evals-of-Evals（Phoenix）

自动 instrument 评测器本身的执行过程。当 LLM judge 给出可疑结果时，可以检查它收到了什么 prompt、如何推理。这是调试评测质量的必要基础设施。

模式 6: 异步摄入 + S3 优先持久化（Langfuse）

事件先写 S3 再异步处理入库。即使数据库短暂不可用也不丢失事件。应用侧零延迟影响。

模式 7: 轨迹匹配四种模式（LangSmith）

Strict:   [search, filter, book] == [search, filter, book]     ✅
Unordered: {search, filter, book} == {filter, search, book}    ✅
Superset:  [search, filter, book, verify] ⊇ [search, book]    ✅
Subset:    [search, book] ⊆ [search, filter, book]            ✅

不同场景需要不同严格度的轨迹评测。四种模式覆盖从严格到宽松的连续光谱。

模式 8: 标签部署的 Prompt 管理（Langfuse）

Prompt "summarizer" v1 [staging]
Prompt "summarizer" v2 [production]  ← SDK 默认获取
Prompt "summarizer" v3 [experimental]

版本管理 + 标签部署 = 无需改代码即可切换生产 prompt。与 trace 自动关联 = 按版本分析性能。

模式 9: Generator-Evaluator 对抗循环（Anthropic Harness Design）

Generator → 生成/修改代码
     ↓
Evaluator → Playwright MCP 测试 + 多维评分
     ↓
评分趋势良好？── 是 → 继续优化当前方向
     │
     否 → 彻底转向（pivot）
     ↓
5-15 轮迭代后趋于平台期

受 GAN 启发的对抗循环。关键：evaluator 必须经过多轮开发循环校准（few-shot 示例 + 评分分解），开箱即用的 LLM 评测无效 — agent 会合理化批准平庸工作。

模式 10: Sprint 合约 + 硬阈值判定（Anthropic Harness Design）

Generator 提议: "本 sprint 交付 5 项功能，27 个验收标准"
     ↓
Evaluator 审核: 确保标准正确且可验证
     ↓
协商达成 → 开始实现
     ↓
验收: 任一标准失败 → 整个 sprint 失败 + 详细反馈

将主观质量拆解为具体可验证的合约条款。硬阈值消除"差不多就行"的模糊判定。

模式 11: 可退化 Harness 架构（Anthropic Harness Design）

模型能力弱时: Planner → Sprint 分解 → Generator ⟷ Evaluator（逐 sprint 对抗）
     ↓ 模型升级
模型能力强时: Planner → Generator → Evaluator（单次最终 QA）
     ↓ 模型继续升级
理论极限:    Generator（自身能力足够，无需外部评测）

Harness 组件是模型能力假设的编码。每次新模型发布时应压力测试假设、移除多余组件。过度脚手架浪费成本（$200 vs $9），不足脚手架遗漏缺陷。

模式 12: 文件化状态交接（Anthropic Harness Design）

Agent 间通过结构化文件（而非直接 API 链）传递状态。上下文重置时，前一个 agent 将关键状态写入文件，下一个 agent 从干净上下文开始读取。这种方式：

• 保持跨会话的上下文保真度
• 允许人工审查和干预交接点
• 消除上下文焦虑（context anxiety）的根因

4.5 技术选型建议

OpenTelemetry 策略

存储层

SDK 设计

推荐技术栈总览

┌─────────────────────────────────────────────────────────┐
│  Client Layer                                           │
│  ├─ Python SDK (@observe + evaluate())                  │
│  ├─ TypeScript SDK                                      │
│  ├─ REST API                                            │
│  └─ OTLP Endpoint (HTTP JSON/protobuf)                  │
├─────────────────────────────────────────────────────────┤
│  Ingestion Layer                                        │
│  ├─ Lightweight API → S3 持久化                         │
│  ├─ Redis/Valkey 消息队列                                │
│  └─ Worker（异步处理：tokenization, 成本计算, 去重）      │
├─────────────────────────────────────────────────────────┤
│  Storage Layer                                          │
│  ├─ PostgreSQL — 事务数据                                │
│  ├─ ClickHouse — 观测/分析数据                           │
│  └─ S3/MinIO — 大体积 payload                           │
├─────────────────────────────────────────────────────────┤
│  Evaluation Engine                                      │
│  ├─ Code Evaluator（确定性）                             │
│  ├─ LLM Evaluator（Function Calling + 结构化输出）       │
│  ├─ Human Evaluator（标注队列）                          │
│  └─ Experiment Runner（Dataset × Task × Evaluators）    │
├─────────────────────────────────────────────────────────┤
│  Application Layer                                      │
│  ├─ Web UI（Trace 视图 + 实验比较 + 标注队列）           │
│  ├─ Prompt Manager（版本 + 标签部署）                    │
│  └─ Dashboard（指标聚合 + 时序趋势）                     │
└─────────────────────────────────────────────────────────┘

附录：参考资料

方法论

• Hamel Husain & Shreya Shankar — LLM Evals: Everything You Need to Know (2026-01) — https://hamel.dev/blog/posts/evals-faq/
• Anthropic Engineering — Demystifying Evals for AI Agents (2026) — https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
• Prithvi Rajasekaran (Anthropic Labs) — Harness Design for Long-Running Application Development (2026-03-24) — https://www.anthropic.com/engineering/harness-design-long-running-apps

Scale AI / Nucleus

• Scale AI Evaluation (Enterprise): https://scale.com/evaluation/enterprise
• Scale GenAI Platform: https://scale.com/genai-platform
• Scale GenAI Platform Blog: https://scale.com/blog/genai-platform
• Scale AI Docs Overview: https://scale.com/docs/overview
• Scale Nucleus Docs - Getting Started: https://nucleus.scale.com/docs/getting-started
• Scale Nucleus - Datasets: https://nucleus.scale.com/docs/datasets-in-nucleus
• Scale Nucleus - Evaluation Metrics: https://nucleus.scale.com/docs/calculate-evaluation-metrics
• Scale Nucleus Python SDK (GitHub): https://github.com/scaleapi/nucleus-python-client
• Scale Agentex (GitHub): https://github.com/scaleapi/scale-agentex
• Scale Labs Leaderboards: https://labs.scale.com/leaderboard
• Scale Labs - Agentic Tool Use Enterprise: https://labs.scale.com/leaderboard/tool_use_enterprise
• Scale SEAL Leaderboard Blog: https://scale.com/blog/leaderboard
• Scale GenAI Platform - Rubrics: https://docs.genai.scale.com/project-archetypes/rubrics
• Scale GP Documentation: https://docs.gp.scale.com/llms.txt
• Scale GP AgentOps Quick Start: https://docs.gp.scale.com/docs/v5/next-gen-evaluation/getting-started
• Contrary Research - Scale Business Breakdown: https://research.contrary.com/company/scale

LangSmith

• LangSmith Docs: https://docs.smith.langchain.com/
• openevals (GitHub, MIT): https://github.com/langchain-ai/openevals
• agentevals (GitHub, MIT): https://github.com/langchain-ai/agentevals

BrainTrust

• BrainTrust Home: https://www.braintrust.dev/
• BrainTrust Docs - Evaluate: https://www.braintrust.dev/docs/evaluate
• BrainTrust Docs - Run Evaluations: https://www.braintrust.dev/docs/core/experiments/write
• BrainTrust Docs - AI Proxy/Gateway: https://www.braintrust.dev/docs/guides/proxy
• BrainTrust Docs - SDK Integrations: https://www.braintrust.dev/docs/integrations/sdk-integrations
• BrainTrust Docs - Experiments: https://www.braintrust.dev/docs/platform/experiments
• BrainTrust Docs - Architecture: https://www.braintrust.dev/docs/reference/platform/architecture
• BrainTrust Docs - Advanced Tracing: https://www.braintrust.dev/docs/instrument/advanced-tracing
• BrainTrust Docs - Autoevals: https://www.braintrust.dev/docs/reference/autoevals
• BrainTrust Docs - Loop: https://www.braintrust.dev/docs/observe/loop
• BrainTrust Pricing: https://www.braintrust.dev/pricing
• How to Eval: The Braintrust Way: https://www.braintrust.dev/articles/how-to-eval
• AI Agent Evaluation Framework: https://www.braintrust.dev/articles/ai-agent-evaluation-framework
• BrainTrust Proxy (GitHub, MIT): https://github.com/braintrustdata/braintrust-proxy
• AutoEvals (GitHub): https://github.com/braintrustdata/autoevals
• AI Observability Tools 2026: https://www.braintrust.dev/articles/best-ai-observability-tools-2026

Arize Phoenix

• Arize Phoenix GitHub: https://github.com/Arize-ai/phoenix
• Phoenix Docs - What is Phoenix: https://arize.com/docs/phoenix
• Phoenix Evaluation: https://arize.com/docs/phoenix/evaluation/llm-evals
• Phoenix Pre-Built Evaluators: https://arize.com/docs/phoenix/evaluation/running-pre-tested-evals
• Phoenix Self-Hosting: https://arize.com/docs/phoenix/self-hosting
• Phoenix Datasets & Experiments Quickstart: https://arize.com/docs/phoenix/datasets-and-experiments/quickstart-datasets
• Phoenix Run Experiments: https://arize.com/docs/phoenix/datasets-and-experiments/how-to-experiments/run-experiments
• Phoenix Evaluating Traces: https://arize.com/docs/phoenix/tracing/how-to-tracing/feedback-and-annotations/evaluating-phoenix-traces
• Phoenix License: https://arize.com/docs/phoenix/self-hosting/license
• Agent Observability - Arize: https://arize.com/ai-agents/agent-observability/
• Why Phoenix: https://phoenix.arize.com/why/
• OpenInference GitHub: https://github.com/Arize-ai/openinference
• arize-phoenix-evals (PyPI): https://pypi.org/project/arize-phoenix-evals/
• Arize LLM Evaluation Platforms Comparison: https://arize.com/llm-evaluation-platforms-top-frameworks/
• Langfuse vs Phoenix - ZenML: https://www.zenml.io/blog/langfuse-vs-phoenix
• Arize Phoenix vs Braintrust: https://www.braintrust.dev/articles/arize-phoenix-vs-braintrust

DeepEval

• DeepEval Docs: https://docs.confident-ai.com/
• DeepEval GitHub: https://github.com/confident-ai/deepeval
• Confident AI Platform: https://confident-ai.com/

Langfuse

• Langfuse Docs: https://langfuse.com/docs
• Langfuse Tracing: https://langfuse.com/docs/tracing
• Langfuse Scores Overview: https://langfuse.com/docs/scores/overview
• Langfuse Model-Based Evals: https://langfuse.com/docs/scores/model-based-evals
• Langfuse Custom Scores: https://langfuse.com/docs/scores/custom
• Langfuse Human Annotation: https://langfuse.com/docs/scores/annotation
• Langfuse External Evaluation Pipelines: https://langfuse.com/docs/scores/external-evaluation-pipelines
• Langfuse Datasets Overview: https://langfuse.com/docs/datasets/overview
• Langfuse Experimentation: https://langfuse.com/docs/experimentation
• Langfuse Prompt Management: https://langfuse.com/docs/prompts/get-started
• Langfuse Integrations Overview: https://langfuse.com/docs/integrations/overview
• Langfuse OpenTelemetry Integration: https://langfuse.com/docs/integrations/opentelemetry
• Langfuse Open Source: https://langfuse.com/docs/open-source
• Langfuse Self-Hosting: https://langfuse.com/docs/deployment/self-host
• Langfuse Playground: https://langfuse.com/docs/playground
• Langfuse Pricing: https://langfuse.com/pricing
• AI Agent Observability with Langfuse: https://langfuse.com/blog/2024-07-ai-agent-observability-with-langfuse
• Langfuse for Agents Changelog: https://langfuse.com/changelog/2025-11-05-langfuse-for-agents
• Evaluating AI Agent Skills: https://langfuse.com/blog/2026-02-26-evaluate-ai-agent-skills
• Langfuse v3 Infrastructure Evolution: https://langfuse.com/blog/2024-12-langfuse-v3-infrastructure-evolution
• Langfuse and ClickHouse: https://clickhouse.com/blog/langfuse-and-clickhouse-a-new-data-stack-for-modern-llm-applications
• Langfuse Architecture Handbook: https://langfuse.com/handbook/product-engineering/architecture