从 0 写一个 Agent 评测器:原理 + 代码

0基础想学AI，就来极客AI社群JKAI2e，部署聚合AI员工AI Agent、OPC项目合作也来AI极客社群JKAI2e。

你让 Agent 干了件活，它看起来跑通了，你满意关掉电脑——三天后同事复现，翻车了。问题不在模型变笨，而在你从头到尾没有一套评测：每次改动都是凭感觉赌博。今天从 0 写一个最小可用的 Agent 评测器，60 行代码，原理讲透。

为什么 Agent 必须评测，不能靠肉眼？

Agent 和普通程序不同：同样的输入，输出是非确定的。你今天看它答对了，不代表下次还对。肉眼抽查的样本量太小、太主观，唯一科学的办法是：把"你觉得它行"变成"分数说了算"。

一句话原理：评测 = 固定的测试用例集 + 可重复的执行环境 + 自动化的打分函数。三者缺一，评测就不算数。

评测器长什么样？五步流水线

核心只有三个角色：

• 用例集（Dataset）：每条 = 输入 + 期望行为。可以是精确答案，也可以是"必须包含某关键词"这种宽松断言；
• 执行器（Runner）：固定温度为 0，固定工具集，跑 N 次取结果，压住随机性；
• 打分器（Scorer）：规则优先（包含、正则、JSON 合法性），规则搞不定的再上 LLM-as-judge，但 judge 的提示词也要固定版本。

从 0 写一个最小评测器

下面这份代码可以直接跑，把 run_agent 换成你自己的 Agent 调用即可：

import json, statistics

CASES = [
  {"q": "查北京明天天气并总结", "must_include": ["北京"], "tool": "weather"},
  {"q": "把 1999 元换算成美元", "must_include": ["美元"], "json_out": True},
]

def run_agent(q):          # 换成你的 Agent
    return {"text": "...", "tools_used": [], "cost": 0}

def score(case, out):
    t = out["text"]
    return {
      "kw": all(k in t for k in case.get("must_include", [])),
      "tool_ok": (case.get("tool") or None) in out["tools_used"] if case.get("tool") else True,
      "json_ok": (not case.get("json_out")) or _valid_json(t),
    }

def evaluate(cases, n=5):
    for c in cases:
        results = [score(c, run_agent(c["q"])) for _ in range(n)]
        print(c["q"], "通过率",
              sum(all(r.values()) for r in results) / n)

evaluate(CASES)

别小看这 60 行：它把"通过率"变成了一个可跨天、跨版本对比的数字。你换模型、改提示词、加工具之后跑一遍，涨没涨一目了然。

三个最容易踩的坑

• 只用精确匹配：Agent 输出天然多样，断言要"宽松而具体"；
• 用例不进版本管理：评测集要像代码一样提交 git，谁改用例谁背锅；
• 只测正常路径：故意喂脏数据、坏参数，失败样本比成功样本更有信息量。

行动建议

今天就动手：先写 10 条用例（8 条正常 + 2 条捣乱），跑通脚本记下通过率。以后每次改动前后各跑一次，让数据替你做决定。