Agent 评估（Evaluation）实战：从手工打分到 LLM-as-Judge 自动化

适用版本：LangSmith 0.2+ / LangFuse 3.x / DeepEval 2.x / Phoenix 7.x / 2026-Q2
目标读者：需要为 LLM 应用/Agent 建立可量化质量门禁的资深工程师与架构师

一、问题背景：Agent 为什么比”普通 LLM 应用”难评估十倍

单轮 Chat 应用评估是”问-答-打分”三元组，闭环简单。把同一个任务换成 Agent，难度立刻翻好几倍：

1. 输出空间是路径而不是字符串

普通 LLM 应用：同一个 prompt 进，期望一个固定结构的 JSON。
Agent：同一个 prompt 进，可能走 search → call_api → search → answer 四步，也可能走 ask_clarification → answer 两步。两个不同的轨迹可能都是”正确答案”，但中间过程完全不同，传统字符串相似度直接失效。

2. 错误是分布式的

Agent 失败有 6 种典型原因：

工具选错（tool selection error）
工具参数错（argument hallucination）
工具执行错（executor failure，第三方 API 5xx）
推理链断了（chain-of-thought 逻辑跳跃）
结果没正确格式化（output parser 失败）
答非所问（intent drift）

每种错误用不同方法检测。BLEU/ROUGE 这种 surface-level 指标对前五种几乎完全无感。

3. 评估本身的”评估”缺位

LLM-as-Judge 用大模型当裁判，听起来优雅，但裁判自己也会有偏差。你用 GPT-4o 评 Claude 3.5 生成的答案，会不会系统性偏严？用同一个模型自评，会不会过度自信？ 这个问题 2024 年才有严肃的论文（Zheng et al. 2023 / LMArena 2024 / MT-Bench 2024）给出量化结论。

4. 评估集本身的腐烂

业务在变、用户提问在变、prompt 在迭代，三个月前精心标注的 200 条 golden set 可能已经不能代表当前业务。评估集需要持续维护，否则分数会越来越”绿”但实际质量越来越差——这是评估体系最大的隐性陷阱。

把这四件事具象成可量化的目标，就是：单次回归测试 < 5 分钟、覆盖 6 类错误、人评一致性 > 0.8、评估集月度刷新率 > 10%。下面所有内容围绕这四个数字展开。

二、评估体系的三件套：Dataset / Metric / Judge

一个能上生产的 Agent 评估体系，必须有下面三个独立组件。把它们混在一起是新人最常踩的坑。

2.1 三件套各自的职责

组件	职责	谁负责	例子
Dataset	输入 + 期望输出（可选轨迹）	业务方 + 标注团队	“用户问 X，期望 Agent 调 Y 工具返回 Z”
Metric	怎么把轨迹转换成 0~1 分数	算法/工程	answer_correctness、tool_call_accuracy、trajectory_match
Judge	谁来打分	LLM / Human / Heuristic	GPT-4o-as-Judge、人评、关键词正则

三者解耦的好处：

换模型不换评估：GPT-4o 换成 Claude 3.5，dataset 和 metric 不动
加新指标不重跑标注：metric 是函数，新加一个 latency_p99 不需要重标数据
评估出问题能定位：分数掉了，先看是 dataset 过期、metric 失效、还是 judge 出错

2.2 三件套的版本管理

资产	版本控制方式	命名
Dataset	DVC / HuggingFace Dataset / S3 + DVC	`customer-support-v12.jsonl`
Metric	Git / 内部 pkg	`agent_eval.metrics.v3`
Judge Prompt	Git + 单独的 `prompts/` 目录	`judge_pairwise_v2.md`

反模式：把 metric 逻辑写死在 evaluate 脚本里、用 Excel 管理 dataset、judge prompt 直接拼在代码字符串中。任何一项都让”上周跑分 0.82 这周怎么 0.71 了”这种问题无法定位。

三、工具栈选型：六个主流平台横向对比

2026 年评估工具已经分化得很清楚。下面这张表是工程师选型时第一手要看的。

工具	类型	强项	弱项	自托管	费用模型
LangSmith	商业 SaaS	LangChain 深度集成、UI 漂亮、Playground	非 LangChain 接入麻烦、价格贵	有（自部署）	席位+trace
LangFuse	开源 + 云	开源、OpenTelemetry 兼容、Prompt 版本管理	UI 偏工程、文档分散	✅ 强	免费版够用 / 云按量
Arize Phoenix	开源	多模态 eval、可视化强、arize 系生态	项目节奏快、API 偶发不稳	✅	完全免费
DeepEval	开源 SDK	指标库最全（50+）、pytest 风格、CI 友好	需要自己搭后端、可视化弱	✅	完全免费
Braintrust	商业 SaaS	评分一致性研究深、playground + eval 一体	2024 新项目、案例少	❌	席位+trace
RAGAS	开源 SDK	RAG 专项（faithfulness / context precision）	对 Agent 支持弱、纯 RAG 场景	✅	完全免费

3.1 选型决策树

你用 LangChain/LangGraph 吗？
  ├─ 是 → LangSmith 体验最顺（但成本高）
  └─ 否 → 你是工程团队吗？
            ├─ 是 → LangFuse + DeepEval（最灵活）
            └─ 否 / 数据敏感 → Phoenix（开箱即用）
            
业务是纯 RAG 吗？
  ├─ 是 → 必装 RAGAS（faithfulness 没人比得过）
  └─ 否（Agent / Tool use）→ DeepEval + LangFuse
  
要计分给老板看吗？
  ├─ 是 → Braintrust（dashboard 最漂亮）
  └─ 否 → 上面任一都行

3.2 推荐组合

小团队 + 快速启动：LangFuse（trace）+ DeepEval（指标）+ RAGAS（如果含 RAG）
企业 + 合规：Arize Phoenix（自托管）+ DeepEval + 内部标注平台
LangChain 重度用户：LangSmith（少折腾）
科研 / 论文：Braintrust（评分方法学最严谨）

四、LLM-as-Judge 实战：Prompt 设计 + 偏置防御

LLM-as-Judge 是 2024-2025 评估领域最大的工程突破，本质是”用大模型当裁判”。但用得不好，分数会骗人。

4.1 基础 Prompt 模板

# judge_single_v1.py
JUDGE_PROMPT = """你是企业级 Agent 评估专家。请评估下面 Agent 的回答质量。

【用户问题】
{question}

【期望参考】(可能有部分缺失)
{reference}

【Agent 实际回答】
{answer}

【Agent 调用轨迹】
{trajectory}

请从四个维度打分（1-5 分整数）：
1. **正确性** (correctness)：事实是否正确、是否回答了问题核心
2. **工具使用** (tool_use)：调用的工具是否合理、参数是否正确
3. **完整性** (completeness)：是否遗漏关键信息
4. **流畅性** (fluency)：语言是否自然、无幻觉

最后给出 **overall** 分数（1-5），并用 JSON 格式输出：

```json
{{
  "correctness": <1-5>,
  "tool_use": <1-5>,
  "completeness": <1-5>,
  "fluency": <1-5>,
  "overall": <1-5>,
  "reasoning": "<50 字以内的判断依据>"
}}

“””


**关键设计点**：
- **结构化输出**：强制 JSON，方便后续 parse
- **分维度打分**：单维度会让裁判"偷懒"（用 overall 数字掩盖 reasoning 漏洞）
- **参考答案为可选**：真实业务里很多问题没有标准答案，分维度比硬逼"对/错"更鲁棒
- **轨迹一并给**：让裁判能检查工具调用是否合理

### 4.2 三大典型偏置及防御

LLM 评估者有三种被反复验证的偏置，必须用 prompt 技巧对抗。

| 偏置 | 表现 | 防御 prompt 技巧 |
|---|---|---|
| **位置偏置** (Position Bias) | 同一答案放在 A/B 哪个位置，胜率不同 | 调换位置跑两遍，结果不一致的丢弃 |
| **冗长偏置** (Verbosity Bias) | 倾向于给长答案更高分 | "**只关注事实正确性，不因答案长度调整分数**" |
| **自我偏置** (Self-Enhancement) | GPT-4o 评 GPT-4o 普遍偏松 | 用不同系列做裁判（GPT-4o 评 Claude，或开源模型评闭源） |

**位置偏置的具体防御代码**：

```python
def judge_pairwise(question, ans_a, ans_b, judge_llm) -> tuple[str, float]:
    """Pairwise 评估，调换位置各跑一次，不一致则标 'tie'。"""
    prompt_a = build_prompt(question, ans_a, ans_b, position="A_first")
    prompt_b = build_prompt(question, ans_b, ans_a, position="B_first")
    
    res_a = parse_verdict(judge_llm.invoke(prompt_a))  # "A" / "B" / "tie"
    res_b = parse_verdict(judge_llm.invoke(prompt_b))  # 反向映射后是 "B" / "A" / "tie"
    
    # 一致才算数
    if (res_a == "A" and res_b == "B") or (res_a == "B" and res_b == "A"):
        return res_a, 1.0
    elif res_a == "tie" or res_b == "tie":
        return "tie", 0.5
    else:
        return "inconsistent", 0.0  # 直接丢弃

位置不一致的样本要单独抽检——这种 case 往往就是 prompt 设计漏掉了某个边界条件。

4.3 Pairwise vs Single 怎么选

场景	推荐	原因
A/B 测试两个 prompt	Pairwise	相对比较比绝对打分更稳
回归测试（一版 vs 上一版）	Pairwise	同上
新模型上线冒烟	Single	需要绝对分数判断”是否达到上线门槛”
标注新数据集	Single	需要可量化的标注结果

经验值：Pairwise 的一致性比 Single 高 20%~30%（来自 MT-Bench / LMArena 公开数据），但代价是 token 消耗 ×2、延迟 ×2。

五、生产级评估体系：Offline + Online + Human 三层闭环

单跑一次评估分数是玩具，生产评估是持续运转的飞轮。下面是一个 2026 年中型企业常见的成熟结构。

5.1 三层评估的责任分工

┌─────────────────────────────────────────────┐
│ Online Eval（线上，实时）                      │
│ - 每次真实请求 trace 进 LangFuse              │
│ - 抽样 5% 跑 LLM-as-Judge 评分                │
│ - 监控 P50/P95 延迟、token 成本               │
│ - 失败模式自动归类                             │
└─────────────────────────────────────────────┘
                    ↑ 反馈
┌─────────────────────────────────────────────┐
│ Offline Eval（CI/CD，PR 触发）                 │
│ - Golden Dataset 200~500 条                    │
│ - PR 合并前必跑，整体回归 < 5 分钟              │
│ - 不达标 → 阻断 merge                          │
└─────────────────────────────────────────────┘
                    ↑ 喂养
┌─────────────────────────────────────────────┐
│ Human Eval（人工，周/月）                       │
│ - 标注员对线上 50~100 条 trace 细标            │
│ - 校准 LLM-as-Judge 与人评一致性（> 0.8 合格） │
│ - 产出新样本入 golden dataset                  │
└─────────────────────────────────────────────┘

5.2 CI/CD 集成示例（GitHub Actions）

# .github/workflows/agent-eval.yml
name: Agent Eval Gate
on:
  pull_request:
    paths: ['agent/**', 'prompts/**']

jobs:
  eval:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: "3.12" }
      - run: pip install deepeval==2.5 langfuse==3.2
      
      - name: Run Golden Set
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
          LANGFUSE_PUBLIC_KEY: ${{ secrets.LANGFUSE_PK }}
          LANGFUSE_SECRET_KEY: ${{ secrets.LANGFUSE_SK }}
        run: |
          deepeval test run tests/agent_eval/ \
            --model gpt-4o \
            --metrics answer_correctness,tool_call_accuracy,latency_p95
      
      - name: Threshold Check
        run: |
          python scripts/check_eval_threshold.py \
            --min-overall 0.85 \
            --max-regression 0.03

关键设计：

超时硬限制 10 分钟：超过说明评估集太大，需要采样
回归阈值 3%：单次 PR 不能让分数掉超过 3%，避免”小步快跑”变”大步倒退”
路径过滤：只对 agent/ 和 prompts/ 目录变更触发，README 改动不跑

5.3 Human-in-the-Loop 标注平台

LLM-as-Judge 再准也需要人评校准。没有人工校准的 LLM 评估体系是沙堡——模型迭代几次后你会发现分数在涨但用户投诉在涨。

轻量方案：

内部做一个简单的标注后台，三个按钮”👍 / 👎 / 🚩”
每周抽 50 条线上 trace 让产品/客服标注
计算人评 vs LLM 评的 Cohen’s Kappa，< 0.6 就要重写 judge prompt

重方案：

Label Studio / Argilla 自托管
标注员跨部门轮换（产品、客服、研发各 1~2 人）
月度输出”人机一致性报告”给技术 leader

六、DeepEval 实战：pytest 风格跑 Agent 评估

理论讲完，上代码。DeepEval 是目前工程团队最友好的评估 SDK，写起来像 pytest。

6.1 最小可运行例子

# tests/agent_eval/test_customer_support.py
import pytest
from deepeval import assert_test
from deepeval.test_case import LLMTestCase, ToolCall
from deepeval.metrics import (
    AnswerRelevancyMetric,
    FaithfulnessMetric,
    ToolCorrectnessMetric,
)

from my_agent import run_support_agent

@pytest.mark.parametrize("golden", [
    {"input": "我的订单 #12345 还没发货", "expected_output": "订单已发货，预计明天到达"},
    {"input": "怎么申请退款？", "expected_output": "请提供订单号，我帮您申请"},
], indirect=True)
def test_support_agent(golden):
    # 跑 Agent
    result = run_support_agent(golden["input"])
    
    # 构造测试用例
    test_case = LLMTestCase(
        input=golden["input"],
        actual_output=result.text,
        expected_output=golden["expected_output"],
        tools_called=[
            ToolCall(name="get_order_status", arguments={"order_id": "12345"}),
        ] if "订单" in golden["input"] else [],
    )
    
    # 三个指标，必须全过
    assert_test(test_case, [
        AnswerRelevancyMetric(threshold=0.85, model="gpt-4o"),
        FaithfulnessMetric(threshold=0.90, model="gpt-4o"),
        ToolCorrectnessMetric(threshold=1.0),  # 工具调用必须 100% 对
    ])

6.2 自定义指标（业务专属）

官方 50+ 指标不够用时，自己写。DeepEval 的 BaseMetric 扩展很顺：

# my_metrics/business_compliance.py
from deepeval.metrics import BaseMetric
from deepeval.test_case import LLMTestCase

class BusinessComplianceMetric(BaseMetric):
    """检查客服 Agent 回答是否违反公司合规话术（不能承诺退款时效等）。"""
    
    def __init__(self, threshold: float = 1.0):
        self.threshold = threshold
        self.score = 0
    
    COMPLIANCE_RULES = [
        ("不能承诺", "7 天内退款"),  # 只能说"通常 7 天内"，不能说"7 天内"
        ("不能承诺", "100% 解决问题"),
        ("必须包含", "请联系客服"),
    ]
    
    def measure(self, test_case: LLMTestCase) -> float:
        answer = test_case.actual_output
        violations = 0
        for negation, pattern in self.COMPLIANCE_RULES:
            if negation == "不能承诺" and pattern in answer:
                # 还要排除"我们不能承诺 X"这种正确说法
                if not any(neg in answer[max(0, answer.find(pattern)-10):answer.find(pattern)] 
                          for neg in ["不能", "无法", "不承诺"]):
                    violations += 1
            elif negation == "必须包含" and pattern not in answer:
                violations += 1
        
        self.score = 1.0 - violations / len(self.COMPLIANCE_RULES)
        self.reason = f"违反 {violations} 条合规规则"
        self.is_successful = self.score >= self.threshold
        return self.score
    
    async def a_measure(self, test_case: LLMTestCase) -> float:
        return self.measure(test_case)

6.3 CI 跑分

$ deepeval test run tests/agent_eval/ -v

tests/agent_eval/test_customer_support.py::test_support_agent[0] PASSED
  ✅ AnswerRelevancyMetric: 0.92 (threshold=0.85)
  ✅ FaithfulnessMetric: 0.95 (threshold=0.90)
  ✅ ToolCorrectnessMetric: 1.00 (threshold=1.0)

tests/agent_eval/test_customer_support.py::test_support_agent[1] PASSED
  ✅ AnswerRelevancyMetric: 0.88
  ⚠️ FaithfulnessMetric: 0.83 (threshold=0.90) — REGRESSION
  ✅ ToolCorrectnessMetric: 1.00

================================ 1 passed, 1 warnings in 142.31s ================================

142 秒跑完 2 条样本——这就是为什么要”golden set 不超过 500 条 + 评估走 LLM 异步并发”。生产上一个完整的 200 条 golden set，8 卡并发 GPT-4o 大约 8~12 分钟。

七、避坑指南：评估体系的六大隐性陷阱

7.1 评估集腐烂（Dataset Rot）

症状：golden set 分数从 0.85 涨到 0.92，业务投诉反而变多。

根因：业务 prompt 分布变了，golden set 还在跑旧分布。

防御：

每月从线上 trace 抽样 5%~10% 入库
老的样本按”已超过 90 天未出现”自动降权
季度做一次”set vs production distribution” KL 散度检查，> 0.2 就要重标

7.2 指标漂移（Metric Drift）

症状：LLM-as-Judge prompt 没改，分数突然系统性偏移。

根因：裁判模型本身升级了（gpt-4o-2024-08 → gpt-4o-2025-01），新版本打分风格变了。

防御：

裁判模型 pin 版本，绝不”自动升级”
每次裁判模型升级前，先在 100 条”已知分数”的样本上跑一遍，差异 > 0.05 要重新校准

7.3 自我偏置（Self-Enhancement）

症状：用 GPT-4o 评 GPT-4o 生成的答案，分数虚高 5%~10%。

根因：同一系列模型对自身输出有结构性偏好（来自 LMArena 2024 公开数据）。

防御：

跨厂商裁判：GPT-4o 评 Claude / Claude 评 Gemini
降一档裁判：被评对象是 GPT-4o，裁判用 GPT-4o-mini（弱模型评强模型，偏差更小）

7.4 提示词耦合（Prompt Coupling）

症状：judge prompt 里写了”必须包含订单号”，业务 prompt 里本来就没有订单号，所有样本被判 0。

根因：judge prompt 是按某个具体业务写的，没考虑业务 prompt 变化。

防御：

judge prompt 写成”通用模板 + 业务占位符”
占位符支持 disabled（这维度跳过）
跑分前 dry-run 10 条，确认 judge 输出非零

7.5 评估的成本陷阱

症状：每月 LLM 评估成本超过 1 万美元，老板问”这个分数真的值吗”。

根因：

200 条 golden set × 4 个 LLM 指标 × 每次 CI 跑 5 次/天 × 30 天 = 12 万次裁判调用
GPT-4o 单次裁判约 $0.05 → 每月 $6000

防御：

分层采样：CI 用 50 条小集（5 分钟内跑完），日构建用 200 条全集
用小模型当裁判：gpt-4o-mini 评一般任务，质量损失 < 3% 成本省 95%
缓存 judge 结果：同样 input + output 的 pair 跑过就不再跑

7.6 评估的”评估”——人评一致性

症状：两个标注员对同一批 100 条样本打分，Kappa 只有 0.4。

根因：标注规范写得太粗，标注员对”答案正确”的边界理解不同。

防御：

标注规范必须含 20+ 边界 case 范例
每月做一次”标注员校准会议”，把 Kappa < 0.6 的 case 拿出来讨论
Kappa 长期 < 0.6 就要考虑”这道题是不是真的可标注”——不可标注的就别标了

八、2026 年的几个新趋势（值得关注）

趋势	状态	影响
Process Reward Model (PRM)	实验阶段	不只评最终答案，评推理过程每一步。Agent 友好。
Agent 专用 Benchmark（如 SWE-bench、τ-bench）	已成熟	评估 agent 多步推理能力的事实标准
Self-Play 对抗评估	学术	让一个 agent 攻击另一个 agent，自动生成难 case
多模态评估（看图说话 Agent）	早期	Phoenix / LMMs-Eval 在补这块
评估数据集合成	早期	用 GPT-4o 生成测试集 + 人校准，成本可降 80%

对工程师最实际的影响：2026 下半年开始招 Agent 工程师，简历上写”我搭过一套 LLM-as-Judge + Golden Set + CI Gate 的评估体系”会比”我做过 RAG”值钱得多——前者代表系统化能力，后者已经被商品化。

九、总结：一张图看清 Agent 评估全景

                 业务方/标注团队
                      ↓
               ┌──────────────┐
               │  Golden Set  │  ← 月度刷新 5%~10%
               └──────────────┘
                      ↓
     ┌────────────────┼────────────────┐
     ↓                ↓                ↓
Dataset         Metric            Judge Prompt
(git)           (git/pkg)          (git/prompts)
     │                │                │
     └────────────────┼────────────────┘
                      ↓
               ┌──────────────┐
               │  CI 评估    │  ← PR 必跑，< 5min
               └──────────────┘
                      ↓
               ┌──────────────┐
               │ Online Eval │  ← 5% 抽样，人机对照
               └──────────────┘
                      ↓
               ┌──────────────┐
               │  Human Eval  │  ← 周/月，Kappa > 0.8
               └──────────────┘
                      ↓
               回到 Golden Set（闭环）

核心原则：评估不是 prompt 工程，是软件工程。Dataset / Metric / Judge 三件套独立版本管理、CI 阻断、Online + Offline + Human 三层闭环、月度刷新。

把这套体系搭起来，你的 Agent 项目就从”调 prompt 凭手感”进化成”数据驱动的可量化迭代”。这也是 2026 年 AI Agent 工程师的核心竞争力。

附录：参考资源

DeepEval 官方文档：https://docs.confident-ai.com/
LangSmith 评估指南：https://docs.smith.langchain.com/evaluation
LangFuse 评估：https://langfuse.com/docs/scores/overview
RAGAS 论文：https://arxiv.org/abs/2309.15217
MT-Bench / LMArena：https://lmarena.ai/
τ-bench（Agent benchmark）：https://github.com/sierra-research/tau-bench