Agent Evaluation (AI Agent Evals)

基于 Anthropic 的 “揭开 AI 代理评估的神秘面纱”

何时使用此技能

• 为 AI 代理设计评估系统
• 为编码、对话或研究型代理构建基准测试
• 创建评分器（基于代码、基于模型、人工评分）
• 为 AI 系统实施生产监控
• 设置包含自动评估的 CI/CD 流水线
• 调试代理性能问题
• 衡量代理随时间的改进情况

核心概念

评估的演进：单轮 → 多轮 → 代理型

7个关键术语

操作指南

步骤 1：了解评分器类型

基于代码的评分器（推荐用于编码代理）

• 优点：快速、客观、可重现
• 缺点：需要明确的成功标准
• 最适合：编码代理、结构化输出

# 示例：基于代码的评分器
def grade_task(outcome: dict) -> float:
    """通过测试通过情况给编码任务评分。"""
    tests_passed = outcome.get("tests_passed", 0)
    total_tests = outcome.get("total_tests", 1)
    return tests_passed / total_tests

# SWE-bench 风格的评分器
def grade_swe_bench(repo_path: str, test_spec: dict) -> bool:
    """运行测试并检查补丁是否解决了问题。"""
    result = subprocess.run(
        ["pytest", test_spec["test_file"]],
        cwd=repo_path,
        capture_output=True
    )
    return result.returncode == 0

基于模型的评分器（大语言模型作为评判者）

• 优点：灵活，能处理细微差别
• 缺点：需要校准，可能不一致
• 最适合：对话代理、开放式任务

# 示例：客户支持代理的 LLM 评分细则
rubric:
  dimensions:
    - name: empathy  # 同理心
      weight: 0.3
      scale: 1-5
      criteria: |
        5: 承认客户情绪，使用温暖的语气
        3: 礼貌但缺乏人情味
        1: 冷淡或敷衍了事

    - name: resolution  # 问题解决
      weight: 0.5
      scale: 1-5
      criteria: |
        5: 完全解决问题
        3: 部分解决
        1: 未解决

    - name: efficiency  # 效率
      weight: 0.2
      scale: 1-5
      criteria: |
        5: 在最少轮次内解决
        3: 轮次合理
        1: 来回沟通过多

人工评分器

• 优点：准确性最高，能捕捉到边缘情况
• 缺点：昂贵、缓慢、不易扩展
• 最适合：最终验证、模棱两可的案例

步骤 2：根据代理类型选择策略

2.1 编码代理

基准测试：

• SWE-bench Verified：真实的 GitHub 问题（可实现从 40% 到 80%+ 的准确率）
• Terminal-Bench：复杂的终端任务
• 针对您代码库的自定义测试套件

评分策略：

def grade_coding_agent(task: dict, outcome: dict) -> dict:
    return {
        "tests_passed": run_test_suite(outcome["code"]),
        "lint_score": run_linter(outcome["code"]),
        "builds": check_build(outcome["code"]),
        "matches_spec": compare_to_reference(task["spec"], outcome["code"])
    }

关键指标：

• 测试通过率
• 构建成功
• 代码风格合规性
• 差异大小（越小越好）

2.2 对话代理

基准测试：

• τ2-Bench：多领域对话
• 自定义的特定领域测试套件

评分策略（多维度）：

success_criteria:
  - empathy_score: >= 4.0
  - resolution_rate: >= 0.9
  - avg_turns: <= 5
  - escalation_rate: <= 0.1

关键指标：

• 任务解决率
• 客户满意度代理指标
• 轮次效率
• 升级率

2.3 研究型代理

评分维度：

1. 依据性：论点是否有来源支持
2. 覆盖率：是否涵盖了所有方面
3. 来源质量：是否使用了权威来源

def grade_research_agent(task: dict, outcome: dict) -> dict:
    return {
        "grounding": check_citations(outcome["report"]),
        "coverage": check_topic_coverage(task["topics"], outcome["report"]),
        "source_quality": score_sources(outcome["sources"]),
        "factual_accuracy": verify_claims(outcome["claims"])
    }

2.4 计算机使用代理

基准测试：

• WebArena：网页导航任务
• OSWorld：桌面环境任务

评分策略：

def grade_computer_use(task: dict, outcome: dict) -> dict:
    return {
        "ui_state": verify_ui_state(outcome["screenshot"]),
        "db_state": verify_database(task["expected_db_state"]),
        "file_state": verify_files(task["expected_files"]),
        "success": all_conditions_met(task, outcome)
    }

步骤 3：遵循 8 步路线图

步骤 0：尽早开始（20-50 个任务）

# 创建初始评估套件结构
mkdir -p evals/{tasks,results,graders}

# 从有代表性的任务开始
# - 常见用例 (60%)
# - 边缘情况 (20%)
# - 失败模式 (20%)

步骤 1：转化手动测试

# 将现有的 QA 测试转化为评估任务
def convert_qa_to_eval(qa_case: dict) -> dict:
    return {
        "id": qa_case["id"],
        "prompt": qa_case["input"],
        "expected_outcome": qa_case["expected"],
        "grader": "code" if qa_case["has_tests"] else "model",
        "tags": qa_case.get("tags", [])
    }

步骤 2：确保清晰度并提供参考解决方案

# 好的任务定义
task:
  id: "api-design-001"
  prompt: |
    为用户管理系统设计一个 REST API，要求包含：
    - CRUD 操作
    - 通过 JWT 进行身份验证
    - 速率限制
  reference_solution: "./solutions/api-design-001/"
  success_criteria:
    - "所有端点都有文档说明"
    - "包含了身份验证中间件"
    - "存在速率限制配置"

步骤 3：平衡正面/负面案例

# 确保评估套件的平衡性
suite_composition = {
    "positive_cases": 0.5,    # 应该成功的案例
    "negative_cases": 0.3,    # 应该优雅失败的案例
    "edge_cases": 0.2         # 边界条件
}

步骤 4：隔离运行环境

# 基于 Docker 的编码评估隔离
eval_environment:
  type: docker
  image: "eval-sandbox:latest"
  timeout: 300s
  resources:
    memory: "4g"
    cpu: "2"
  network: isolated
  cleanup: always

步骤 5：关注结果，而非过程

# 好：关注结果的评分器
def grade_outcome(expected: dict, actual: dict) -> float:
    return compare_final_states(expected, actual)

# 差：关注过程的评分器（太脆弱）
def grade_path(expected_steps: list, actual_steps: list) -> float:
    return step_by_step_match(expected_steps, actual_steps)

步骤 6：始终审阅对话记录

# 用于调试的对话记录分析
def analyze_transcript(transcript: list) -> dict:
    return {
        "total_steps": len(transcript),
        "tool_usage": count_tool_calls(transcript),
        "errors": extract_errors(transcript),
        "decision_points": find_decision_points(transcript),
        "recovery_attempts": find_recovery_patterns(transcript)
    }

步骤 7：监控评估套件饱和度

# 检测评估何时不再有用
def check_saturation(results: list, window: int = 10) -> dict:
    recent = results[-window:]
    return {
        "pass_rate": sum(r["passed"] for r in recent) / len(recent),
        "variance": calculate_variance(recent),
        "is_saturated": all(r["passed"] for r in recent),
        "recommendation": "添加更困难的任务" if saturated else "继续"
    }

步骤 8：长期维护

# 评估套件维护检查清单
maintenance:
  weekly:
    - Review failed evals for false negatives: 审查失败的评估以发现假阴性
    - Check for flaky tests: 检查不稳定的测试
  monthly:
    - Add new edge cases from production issues: 从生产问题中添加新的边缘案例
    - Retire saturated evals: 淘汰已饱和的评估
    - Update reference solutions: 更新参考解决方案
  quarterly:
    - Full benchmark recalibration: 完整基准重新校准
    - Team contribution review: 团队贡献回顾

步骤 4：与生产环境集成

CI/CD 集成

# GitHub Actions 示例
name: Agent Evals
on: [push, pull_request]

jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Evals
        run: |
          python run_evals.py --suite=core --mode=compact
      - name: Upload Results
        uses: actions/upload-artifact@v4
        with:
          name: eval-results
          path: results/

生产监控

# 实时评估采样
class ProductionMonitor:
    def __init__(self, sample_rate: float = 0.1):
        self.sample_rate = sample_rate

    async def monitor(self, request, response):
        if random.random() < self.sample_rate:
            eval_result = await self.run_eval(request, response)
            self.log_result(eval_result)
            if eval_result["score"] < self.threshold:
                self.alert("检测到低质量响应")

A/B 测试

# 比较代理版本
def run_ab_test(suite: str, versions: list) -> dict:
    results = {}
    for version in versions:
        results[version] = run_eval_suite(suite, agent_version=version)
    return {
        "comparison": compare_results(results),
        "winner": determine_winner(results),
        "confidence": calculate_confidence(results)
    }

最佳实践

应该做的 ✅

1. 从 20-50 个有代表性的任务开始
2. 尽可能使用基于代码的评分器
3. 关注结果，而非过程
4. 审阅对话记录以进行调试
5. 监控评估套件的饱和度
6. 平衡正面/负面案例
7. 隔离评估环境
8. 对您的评估套件进行版本控制

不该做的 ❌

1. 不要未经校准就过度依赖基于模型的评分器
2. 不要忽视失败的评估（假阴性确实存在）
3. 不要对中间步骤进行评分
4. 不要跳过对话记录分析
5. 不要未经脱敏就使用生产数据
6. 不要让评估套件变得过时

成功模式

模式 1：渐进式评估复杂度

级别 1：单元评估（单一能力）
级别 2：集成评估（组合能力）
级别 3：端到端评估（完整工作流）
级别 4：对抗性评估（边缘情况）

模式 2：评估驱动开发

1. 为新功能编写评估任务
2. 运行评估（预期失败）
3. 实现功能
4. 运行评估（预期通过）
5. 添加到回归测试套件

模式 3：持续校准

每周：审查评分器准确性
每月：根据反馈更新评分细则
每季度：以人工为基准进行完整的评分器审计

故障排除

问题：评估分数达到 100%

解决方案：添加更困难的任务，检查评估套件是否饱和（步骤 7）

问题：基于模型的评分器得分不一致

解决方案：在评分细则中添加更多示例，使用结构化输出，组合多个评分器

问题：评估在 CI 中运行太慢

解决方案：使用精简模式，并行化，为 PR 检查抽取子集样本

问题：代理通过评估但在生产中失败

解决方案：将生产失败案例添加到评估套件，增加任务多样性

参考链接

• Anthropic：揭开 AI 代理评估的神秘面纱
• SWE-bench
• WebArena
• τ2-Bench

使用示例

示例 1：简单的编码代理评估

# 任务定义
task = {
    "id": "fizzbuzz-001",
    "prompt": "用 Python 写一个 fizzbuzz 函数",
    "test_cases": [
        {"input": 3, "expected": "Fizz"},
        {"input": 5, "expected": "Buzz"},
        {"input": 15, "expected": "FizzBuzz"},
        {"input": 7, "expected": "7"}
    ]
}

# 评分器
def grade(task, outcome):
    code = outcome["code"]
    exec(code)  # 在沙箱环境中执行
    for tc in task["test_cases"]:
        if fizzbuzz(tc["input"]) != tc["expected"]:
            return 0.0
    return 1.0

示例 2：使用 LLM 评分细则的对话代理评估

task:
  id: "support-refund-001"
  scenario: |
    客户想要为损坏的产品退款。
    产品：笔记本电脑，订单号：#12345，损坏情况：屏幕破裂
  expected_actions:
    - 承认问题
    - 验证订单
    - 提供解决方案选项
  max_turns: 5

grader:
  type: model
  model: claude-3-5-sonnet-20241022
  rubric: |
    在每个维度上按 1-5 分评分：
    - 同理心：代理是否承认了客户的挫败感？
    - 解决方案：是否提供了明确的解决方案？
    - 效率：问题是否在合理的轮数内得到解决？