跳转至

智能体评估技能

一个轻量级 CLI 工具,用于在可复现任务中头对头比较编码智能体。“哪个编码智能体最好?”这类比较往往依赖直觉——该工具将其系统化。

启动时机

  • 在自己的代码库中比较编码智能体(Claude Code、Aider、Codex 等)
  • 在采用新工具或模型之前测量智能体性能
  • 当智能体更新模型或工具时执行回归检查
  • 为团队提供基于数据的智能体选择决策

安装

注意: agent-eval 请在审查源代码后,从仓库安装。

核心概念

YAML 任务定义

以声明方式定义任务。每个任务指定要做什么、操作哪些文件以及如何判定成功:

name: add-retry-logic
description: Add exponential backoff retry to the HTTP client
repo: ./my-project
files:
  - src/http_client.py
prompt: |
  Add retry logic with exponential backoff to all HTTP requests.
  Max 3 retries. Initial delay 1s, max delay 30s.
judge:
  - type: pytest
    command: pytest tests/test_http_client.py -v
  - type: grep
    pattern: "exponential_backoff|retry"
    files: src/http_client.py
commit: "abc1234"  # 再現性のために特定コミットに固定

Git 工作树隔离

每个智能体运行都会获得独立的 git 工作树——无需 Docker。这提供了可复现的隔离,智能体不会相互干扰或破坏基础仓库。

收集指标

指标 测量内容
通过率 智能体是否生成了通过评判的代码?
成本 每个任务的 API 费用(如可用)
时间 完成所需的墙钟秒数
一致性 重复运行中的通过率(例如:3/3 = 100%)

工作流

1. 定义任务

创建 tasks/ 目录,每个任务一个 YAML 文件:

mkdir tasks
# タスク定義を作成(上記のテンプレートを参照)

2. 运行智能体

对任务运行智能体:

agent-eval run --task tasks/add-retry-logic.yaml --agent claude-code --agent aider --runs 3

每次运行: 1. 从指定提交创建新的 git 工作树 2. 向智能体提供提示 3. 执行评判标准 4. 记录通过/失败、成本和时间

3. 比较结果

生成比较报告:

agent-eval report --format table
Task: add-retry-logic (3 runs each)
┌──────────────┬───────────┬────────┬────────┬─────────────┐
│ Agent        │ Pass Rate │ Cost   │ Time   │ Consistency │
├──────────────┼───────────┼────────┼────────┼─────────────┤
│ claude-code  │ 3/3       │ $0.12  │ 45s    │ 100%        │
│ aider        │ 2/3       │ $0.08  │ 38s    │  67%        │
└──────────────┴───────────┴────────┴────────┴─────────────┘

评判类型

基于代码(确定性)

judge:
  - type: pytest
    command: pytest tests/ -v
  - type: command
    command: npm run build

基于模式

judge:
  - type: grep
    pattern: "class.*Retry"
    files: src/**/*.py

基于模型(LLM-as-judge)

judge:
  - type: llm
    prompt: |
      Does this implementation correctly handle exponential backoff?
      Check for: max retries, increasing delays, jitter.

最佳实践

  • 从 3 到 5 个任务开始 — 使用代表实际工作负载的任务,而不是玩具示例
  • 每个智能体至少运行 3 次 — 智能体是非确定性的,因此了解分布
  • 在任务 YAML 中固定提交 — 使结果可以跨天或跨周复现
  • 每个任务至少包含一个确定性评判(测试、构建)— LLM 评判会引入噪声
  • 与通过率一起跟踪成本 — 成本高出 10 倍的 95% 智能体可能不是正确选择
  • 对任务定义进行版本控制 — 它们是测试夹具,应像代码一样对待

本页原文 Markdown:在 AtomGit 查看·内容源自开源项目 ev/ECC