从零开始构建AI Agent评估管线

“没有度量就没有改进”——这句话对AI Agent尤其成立。一个没有评估管线的Agent项目，就像在没有仪表盘的飞机上飞行。本文是一份从零开始构建Agent评估管线的实操指南。

评估管线的整体架构

一个完整的Agent评估管线包含五个核心模块：

  1. 指标体系：定义"什么算好"
  2. 数据集：定义"在什么上评估"
  3. 评估器：执行评估的逻辑
  4. 报告系统：可视化评估结果
  5. 持续集成：将评估嵌入开发流程

模块一：指标体系设计

指标分类框架

我们将Agent评估指标分为四层：

任务完成层（最基础）：

  • 成功率：任务是否完成
  • 完成时间：从开始到完成的时间
  • 步数效率：完成任务用的对话轮次/工具调用次数

质量层：

  • 正确性：输出是否准确
  • 完整性：是否覆盖了所有要求
  • 相关性：输出是否切题

交互层：

  • 理解准确度：是否正确理解了用户意图
  • 澄清频率：需要多少次澄清才能理解
  • 错误恢复率：出错后能否恢复

安全层：

  • 安全通过率：安全测试集的通过率
  • 过度拒绝率：安全请求被误拒的比例
  • 越狱成功率：攻击测试的成功率

指标定义的SMART原则

每个指标必须满足：

  • Specific：明确定义计算方法
  • Measurable：可量化计算
  • Actionable：指标变化能指导行动
  • Relevant：和产品质量相关
  • Trackable：可追踪趋势

反例：“用户满意度”——太模糊，无法计算。 正例：“用户在Agent完成任务后点击’满意’按钮的比例”——可计算、可追踪。

模块二：评估数据集构建

数据集类型

Golden Set：人工标注的标准问答对，有唯一正确答案。用于回归测试。

Evaluation Set：人工标注的开放性任务，可能有多种正确答案。用LLM-as-Judge评分。

Adversarial Set：红队设计的攻击性输入。用于安全测试。

Real-world Set：从真实用户对话中抽样（脱敏后）。用于反映实际使用场景。

数据集构建流程

  1. 需求分析：确定需要评估哪些能力和场景
  2. 种子设计：为每个场景设计3-5个种子案例
  3. 扩增：用LLM基于种子生成更多变体
  4. 人工审核：过滤质量不高的扩增案例
  5. 标注：为每个案例标注期望结果或评分标准
  6. 版本管理：数据集版本化，支持增量更新

数据集规模建议

类型最小规模推荐规模更新频率
Golden Set100500+季度
Evaluation Set50200+月度
Adversarial Set30100+月度
Real-world Set2001000+周度

模块三：评估器实现

精确匹配评估器

适用于有唯一正确答案的任务：

def exact_match_eval(response, expected):
    """精确匹配评估"""
    return {
        "score": 1.0 if response.strip().lower() == expected.strip().lower() else 0.0,
        "reason": "精确匹配" if response.strip().lower() == expected.strip().lower() else "不匹配"
    }

语义匹配评估器

适用于答案有多个正确表述的任务：

def semantic_match_eval(response, expected, model="embedding-model"):
    """基于嵌入的语义匹配"""
    response_emb = get_embedding(response, model)
    expected_emb = get_embedding(expected, model)
    similarity = cosine_similarity(response_emb, expected_emb)
    return {
        "score": similarity,
        "reason": f"语义相似度: {similarity:.3f}"
    }

LLM-as-Judge评估器

适用于开放性任务，使用更强的模型做评估：

def llm_judge_eval(response, task, criteria):
    """LLM-as-Judge评估"""
    prompt = f"""
    任务: {task}
    回答: {response}
    评估标准: {criteria}
    
    请按1-10分评估回答质量，并说明理由。
    输出JSON格式: {{"score": 8, "reason": "..."}}
    """
    result = call_llm(prompt)
    return parse_json(result)

组合评估器

实际评估通常需要多个维度：

def composite_eval(response, task, expected):
    """组合评估"""
    results = {
        "exact_match": exact_match_eval(response, expected),
        "semantic_match": semantic_match_eval(response, expected),
        "llm_judge": llm_judge_eval(response, task, EVAL_CRITERIA),
        "safety": safety_check(response),
        "latency_ms": measure_latency(response)
    }
    
    # 加权综合得分
    weights = {"exact_match": 0.3, "semantic_match": 0.2, 
               "llm_judge": 0.3, "safety": 0.2}
    total = sum(results[k]["score"] * weights[k] for k in weights)
    results["total_score"] = total
    return results

模块四：报告系统

报告维度

评估报告应包含：

总体评分：所有任务的加权平均分 分维度得分：各能力维度的得分分布 趋势图：评分随时间的变化 失败分析：失败案例的分类统计 对比分析：与上一版本或基线模型的对比

可视化设计

  • 雷达图：展示各维度的能力分布
  • 趋势线：展示评分随版本的变化
  • 散点图：展示各任务的得分分布
  • 热力图：展示能力维度×任务类型的得分矩阵

模块五：持续集成

CI集成

# GitHub Actions workflow
name: Agent Evaluation
on: [pull_request]

jobs:
  evaluate:
    steps:
      - name: Run Golden Set
        run: python eval.py --dataset golden --threshold 0.95
      
      - name: Run Safety Set  
        run: python eval.py --dataset adversarial --threshold 0.99
      
      - name: Check Regression
        run: python eval.py --check-regression --max-drop 0.02
      
      - name: Generate Report
        run: python eval.py --report --format markdown > eval_report.md
      
      - name: Comment on PR
        uses: actions/github-script@v6
        with:
          script: |
            const report = require('fs').readFileSync('eval_report.md', 'utf8');
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              body: report
            });

质量门控

设置自动化的质量门控：

  • Golden Set通过率<95% → 阻止合并
  • 安全测试通过率<99% → 阻止合并
  • 相比基线退化>2% → 需要人工审核

告警机制

评估结果异常时自动告警：

  • 某维度得分突降>10% → 告警
  • 新增失败模式出现 → 告警
  • 安全测试出现新失败 → 紧急告警

高级实践

在线评估

除了离线评估，在线评估同样重要：

A/B测试框架：新版本和旧版本同时服务部分流量，对比关键指标 用户反馈收集：在Agent回复后收集用户反馈（点赞/点踩） 隐式信号：用户是否复制了Agent的回复、是否继续追问、是否中断对话

对抗性评估

定期进行对抗性评估：

  • 红队测试：专业攻击者尝试突破Agent
  • 自动化攻击：使用攻击生成工具批量生成攻击输入
  • 长期对抗：持续运行Agent，监控行为漂移

多模态评估

如果Agent支持多模态，评估需要覆盖：

  • 文本理解能力
  • 图像理解能力
  • 语音交互能力
  • 多模态融合能力

常见陷阱

  1. 过度依赖LLM-as-Judge：LLM评估者自身有偏差，不能完全替代人工评估
  2. 数据集污染：评估数据泄露到训练数据中，评估结果虚高
  3. 指标过拟合：过度优化评估指标，忽略了真实用户体验
  4. 静态数据集：数据集不更新，无法覆盖新的使用模式
  5. 忽略长尾：只关注平均分，忽略少数极端失败案例

结语

构建评估管线是Agent工程化的基石。投入在评估上的时间回报率极高——一个好的评估管线可以让你在每次变更时知道"变好了还是变坏了"，而不是靠"感觉"。在2026年，Agent评估管线已经从"奢侈品"变成了"必需品"。你的评估管线有多完善，你的Agent就有多可靠。

本文同步发布于 硅基AGI论坛