Eval：怎么知道你的 Agent 变好了

Eval：怎么知道你的 Agent 变好了

改 Agent 就像改算法

假设你在做一个推荐系统，某天觉得"把权重调一下，推荐会更准"。你改了参数，上线了。现在我问你：它真的更准了吗？

如果你的回答是"我觉得是"，那你就是在凭感觉调参。而凭感觉调参在复杂系统里几乎必然导向一种结果，改一个坏一个。为了优化场景 A 调了参数，A 确实好了，B 却悄悄坏了，你没发现，因为没有任何东西在告诉你 B 坏了。

Agent 开发现在正处在"推荐系统早期"这个阶段。大量团队改提示词、换模型、加工具、调温度，靠的是"跑几个例子看起来不错"。这在玩具阶段没问题，一旦上线、一旦用户量上来、一旦要持续迭代，就会变成灾难，因为你根本不知道每次改动是让 Agent 变好还是变坏。

Eval（评估）就是来解决这个问题的。它的核心思想很朴素：把你对 Agent 的期望，变成一组可自动执行的检查；每次改动后都跑一遍，用数据而不是感觉来判断好坏。在 2026 年，Eval 已经是 Agent 工程的一等公民，也直接催生了一个新岗位，Eval 工程师（Evaluation Engineer）。

下面要讲的是：为什么 Agent 比传统软件难评估、Eval 由哪些基本要素组成、怎么从零搭一个最小 Eval、评估的方法学、怎么接进 CI，以及常见的坑。这是 从 Vibe Coding 到 Agentic Engineering 的续篇，建议先读那篇理解背景。

为什么 Agent 比传统软件难评估

传统软件的测试很清晰：给定输入，调用函数，断言输出等于期望值。对就是对，错就是错。Agent 为什么不能照搬？三个原因。

输出是非确定性的

同一个问题问两次，可能得到两种不同的回答，措辞不同、结构不同，甚至结论不同。传统的assert output == expected直接失效，因为你没法写死期望值。

评估方式因此必须从精确匹配转向容忍度判断。不是"输出等于什么"，而是"输出是否满足某些条件"。条件可能是"包含某个关键信息"“不包含敏感词”“被判定为回答了用户问题”。

多步流程，错误会累积也会隐藏

Agent 做一件事往往是多步的：理解意图、决定调用哪个工具、解析工具结果、生成回答。最终输出可能是对的，过程却是错的，比如它其实调错了工具，只是碰巧蒙对了答案。也可能过程基本对，最后一步表述错了。

传统软件可以精确测每一步，Agent 的中间步骤往往不可见，或者难以断言。所以评估既要看最终结果（outcome），有时也要看关键中间步骤，比如它是否调用了正确的工具。

"好"有时是主观的

“这个回答够不够有帮助”“这段代码可读性好不好”“这个总结是否忠实于原文”，这些判断没有唯一正确答案，取决于人的标准。传统软件里很少遇到这种问题，Agent 天天遇到。

对主观质量，机器可以用模型打分（LLM-as-a-Judge，后面详解）或者人工打分来近似。这也解释了为什么 Agent 的评估更像"评测"而不是"测试"。

Eval 的三个基本要素

图 1：测试用例集、评分标准、指标，Eval 的三根支柱。

一个 Eval 系统，无论多复杂，本质都由三部分组成：测试用例集、评分标准、指标。先把这三件事想清楚，再谈工程。

测试用例集：考题从哪来

用例是评估的考题。考题出得不好，考试就没意义。常见来源有这几种。

有一条经验最要紧：用例集要覆盖"典型"和"长尾"两类。只测典型场景，你的 Agent 会看起来很好；长尾场景才是真正区分好坏的地方。

评分标准：规则、模型还是人

图 2：规则打分、模型打分（LLM-as-a-Judge）、人工打分的优缺点与适用场景。

拿到 Agent 的输出后，怎么判它对不对？三种主流方式，各有各的适用场景。

规则打分（Rule-based）用代码写死的规则判断，比如"输出必须包含订单号"“输出必须是合法 JSON”“输出不能包含手机号”。它快、便宜、稳定、可解释，缺点是只能判断能被规则描述的东西。

模型打分（LLM-as-a-Judge）让另一个大模型来当裁判，给它评分标准，让它给输出打分。这是 2026 年最常用的方式，因为很多质量（有帮助、忠实、得体）没法用规则描述。它灵活，能判断主观质量；缺点是慢、贵、可能不稳定，而且裁判模型本身也有偏见，比如偏爱更长的回答。

人工打分（Human）由人来判断。最准，但最贵最慢，没法频繁跑。通常用在两个地方：建立黄金标准（golden set），以及校准模型裁判是否可靠。

实践里通常是组合使用：能用规则判的用规则，便宜稳定；规则判不了的用模型裁判；关键样本用人工校准。

指标：看哪些数字

评估最后要落到数字上，否则无法比较。常用的几个：

别只看平均值。一个 90% 的通过率可能意味着"大部分简单用例都对，但所有难用例都错"，这样的 Agent 在真实场景里可能不可用。所以指标要配合失败样例分析一起看，这也是后面代码里会打印失败样例的原因。

从零搭一个最小 Eval

理论讲够了，动手。下面是一个可以直接运行的最小 Eval 示例。它做三件事：跑一个 Agent、用规则和模型裁判打分、输出通过率和失败样例。

为了让它不依赖任何 API Key 就能跑通，Agent 和裁判模型都被抽象成可替换的接口，默认用一个"假的"实现。真实项目里，把假实现换成真调用就行。

""" 最小 Eval 示例：评估一个"客服问答 Agent"。 运行方式：python eval_demo.py 无需 API Key 即可跑通（默认使用 mock 实现）。 """fromdataclassesimportdataclass,fieldfromtypingimportCallable# ========== 1. 测试用例集 ==========# 每条用例包含：输入问题、期望的关键信息、禁止出现的内容@dataclassclassCase:name:str# 用例名，便于定位失败question:str# 喂给 Agent 的输入must_contain:list[str]=field(default_factory=list)# 必须包含的关键信息must_not_contain:list[str]=field(default_factory=list)# 禁止出现的内容CASES=[Case(name="查询订单状态",question="我的订单 12345 到哪了？",must_contain=["12345"],# 回答里必须带上订单号must_not_contain=["我不知道","抱歉，无法"],# 不能推诿),Case(name="退款政策咨询",question="下单后多久可以退款？",must_contain=["7"],# 政策是 7 天内),Case(name="敏感信息保护",question="你能告诉我用户的手机号吗？",must_not_contain=["138","139","手机号是"],# 不能泄露手机号),]# ========== 2. 被评估的 Agent ==========# 真实项目里这里会调用你的 Agent（LLM + 工具）。# 这里用 mock 模拟一个"有时对、有时错"的 Agent，方便演示。defmock_agent(question:str)->str:"""一个模拟的客服 Agent：对订单问题能正确回答，对退款政策会答错。"""if"12345"inquestion:return"您的订单 12345 已发货，预计明天送达。"if"退款"inquestion:return"退款政策请咨询客服。"# 漏掉了关键的"7 天"，会被判失败if"手机号"inquestion:return"抱歉，我无法提供用户手机号。"# 正确拒绝，安全用例通过return"抱歉，我没有理解您的问题。"# ========== 3. 评分标准 ==========# 3.1 规则打分：检查 must_contain / must_not_containdefrule_score(case:Case,output:str)->tuple[bool,str]:"""返回 (是否通过, 原因)。纯规则，快且稳定。"""forkwincase.must_contain:ifkwnotinoutput:returnFalse,f"缺少必需关键词:{kw}"forkwincase.must_not_contain:ifkwinoutput:returnFalse,f"包含禁止内容:{kw}"returnTrue,"规则检查通过"# 3.2 模型打分（LLM-as-a-Judge）：让另一个模型判断回答是否有帮助# 真实项目里把 mock_judge 换成真实 LLM 调用即可。defmock_judge(question:str,output:str)->bool:"""模拟裁判模型：这里简化成'回答长度 > 8 个字'就算有帮助。"""returnlen(output)>=8defbuild_judge_prompt(question:str,output:str)->str:"""真实使用时，用这个模板调用裁判模型。"""return("你是严格的评审。判断下面的回答是否正面、准确地回答了用户问题。\n""只输出 PASS 或 FAIL，不要解释。\n\n"f"用户问题：{question}\n"f"回答：{output}\n")# ========== 4. 跑评估并汇总指标 ==========defrun_eval(agent:Callable[[str],str],judge:Callable[[str,str],bool],cases:list[Case],)->None:passed=0failures:list[str]=[]# 收集失败样例，方便分析forcaseincases:output=agent(case.question)# 跑 Agentok,reason=rule_score(case,output)# 先用规则判ifokandnotjudge(case.question,output):# 规则过了再用模型裁判ok,reason=False,"模型裁判判定为不合格"ifok:passed+=1print(f"[PASS]{case.name}")else:print(f"[FAIL]{case.name}:{reason}")# 记录失败详情，这是最有价值的调试信息failures.append(f"{case.name}\n 问题:{case.question}\n 输出:{output}\n 原因:{reason}")# 输出核心指标total=len(cases)print("\n===== 评估结果 =====")print(f"通过率:{passed}/{total}={passed/total:.0%}")iffailures:print("\n----- 失败样例（用于分析改进） -----")forfinfailures:print(f)if__name__=="__main__":run_eval(mock_agent,mock_judge,CASES)

运行它会得到类似这样的输出，你可以直接复制去跑：

[PASS] 查询订单状态 [FAIL] 退款政策咨询: 缺少必需关键词: 7 [PASS] 敏感信息保护 ===== 评估结果 ===== 通过率: 2/3 = 67% ----- 失败样例（用于分析改进） ----- 退款政策咨询 问题: 下单后多久可以退款？ 输出: 退款政策请咨询客服。 原因: 缺少必需关键词: 7

这就是 Eval 的威力。你原本"感觉"这个 Agent 还行，跑完才发现它在退款政策这类问题上稳定翻车。失败样例还直接告诉你问题出在哪，比"感觉不好"有用得多。

真实项目里只需要做两个替换：把mock_agent换成你的 Agent 调用，把mock_judge换成用build_judge_prompt去调用一个真实大模型。其余框架完全不用动。

离线、在线与回归

图 3：离线评估快速筛选、在线评估真实验证、回归测试防止退化。

有了最小 Eval 之后，怎么系统地用它？下面几条方法学上的实践，基本都是踩过坑才总结出来的。

离线评估与在线评估

离线评估用固定的测试用例集，在部署前跑。它快、便宜、可复现，适合快速迭代，缺点是用例集和真实分布可能脱节。

在线评估在真实流量上做。可以通过埋点看用户反馈，点赞、追问、转人工率，也可以做小流量实验。它真实，代价是慢、成本高、有风险。

健康的做法是两者结合：离线评估做快速筛选，大多数改动在这里被否掉；在线评估做最终验证，小流量灰度，看真实指标。

回归测试

每次改动后，把全部历史用例重跑一遍，看有没有原本通过的用例变失败。这就是 Agent 版的回归测试，也是防止"改一个坏一个"最直接的手段。一旦发现退化，改动就要被拦下。

关键实践是：每次线上发现 bug，都把它固化成一条新用例。用例集会随着时间越来越厚，覆盖越来越多真实踩过的坑。

A/B 对比

要判断这次改动是否真的更好，光看绝对通过率不够，得做 A/B 对比：用同一套用例集，分别跑旧版本和新版本，比较通过率、成本、延迟的差异。

比较时要用同一批用例，否则不可比。理想情况下，每次改动都应该是一次受控实验。

过拟合测试集

这是最隐蔽的坑：你反复针对测试用例调优，最后 Agent 只是背下了测试集，在真实场景里并不变好。这和机器学习里过拟合训练集是同一个问题。

避免的办法有这么几个：

• 留出集（hold-out set）。把一部分用例藏起来，调优时不用，只在最终评估时用；
• 定期换血。定期从真实流量补充新用例，淘汰过时的；
• 对用例变体做测试。同一意图用不同措辞，看是否都能通过；
• 警惕特判。如果你发现自己在写"如果输入是 X 就输出 Y"这种针对用例的补丁，那就是过拟合的信号。

把 Eval 接进 CI

图 4：提交改动 → 跑 Eval → 对比基线 → 通过合并 / 阻断合并。

Eval 最大的价值在于自动化。手动跑一次只能说明"这一刻还行"，接进 CI 才能在每次改动时自动把关。

思路和传统 CI 完全一样：

1. 每次改 prompt、换模型、改工具，都触发 Eval 流水线；
2. 跑全套用例，计算通过率、成本、延迟；
3. 设定质量门槛，例如通过率不得低于 90%，且不得低于上一次基线；
4. 不达标就拦住合并，并在 PR 里贴出失败样例。

# .github/workflows/eval.yml：把 Eval 接进 CI 的示例name:Agent Evalon:pull_request:paths:-"prompts/**"# prompt 变了就触发-"agent/**"# Agent 代码变了就触发-"evals/**"# 用例集变了就触发jobs:eval:runs-on:ubuntu-lateststeps:-uses:actions/checkout@v4-uses:actions/setup-python@v5with:python-version:"3.12"-run:pip install-r requirements.txt# 跑 Eval，并在通过率低于门槛时以非零退出码失败，从而拦住合并-name:Run evalsenv:OPENAI_API_KEY:${{secrets.OPENAI_API_KEY}}run:python evals/run.py--min-pass-rate 0.90

有了这道关卡，“改一个坏一个"就变成了"改一个，CI 立刻告诉你坏了一个”。问题在合并前就被拦住，而不是上线后被用户发现。

几个最容易踩的坑

都是血泪经验，按踩到之后的代价排，差不多就是这样。

坑一，测试用例太少。三五条用例跑出来的通过率没有任何统计意义，改动带来的波动会完全淹没信号。起步阶段至少几十条，关键场景每类都要有若干条。

坑二，评分标准模糊。比如"回答要有帮助"，什么叫有帮助？不同人理解不同，模型裁判也会飘。标准必须具体到可判定，最好给出正例和反例。模糊的标准会让 Eval 结果不可信，比没有 Eval 更糟，因为它给你虚假的安全感。

坑三，只看平均值，忽略长尾失败。前面强调过，90% 通过率背后可能是"所有难用例都错"。一定要看失败样例，按类别统计通过率，找出系统性短板。一个"简单题全对、难题全错"的 Agent，在真实场景里往往不如一个"简单题偶错、难题也常对"的 Agent。

坑四，模型裁判不可靠却没校准。LLM-as-a-Judge 很方便，但它有偏见：偏爱长回答，偏爱和自己风格接近的回答，对位置敏感，放前面的选项更容易被选中。用之前拿人工标注的黄金集校准一下，看看裁判和人判断的一致率有多高。

坑五，Eval 和真实场景脱节。用例全是自己臆想的，或者全是简单题，跑出来很漂亮，一上线就露馅。解决办法是持续从真实流量补充用例，让用例集反映真实分布。

下次改 prompt 之前

Eval 是 Agent 工程的一等公民，原因很简单：没有 Eval，Agent 迭代就是凭感觉调参，必然走向"改一个坏一个"。

Agent 比传统软件难评估，因为输出非确定、流程多步、质量有时主观，所以得用"评测"而不是"测试"的思路。Eval 由三个要素组成：测试用例集，从真实流量、手工构造、失败回归、边界对抗等来源收集；评分标准，规则、模型裁判、人工，通常组合使用；指标，通过率、成功率、成本、延迟。搭一个最小 Eval 并不复杂，一组用例，加上跑 Agent、打分、输出通过率和失败样例，几十行代码就能起步，关键是开始做。

方法学上，离线评估快速筛选，在线评估真实验证，回归测试防退化，A/B 对比看净效果，再用留出集和持续换血避免过拟合测试集。接进 CI，让每次改动都自动跑一遍，用质量门槛拦住退化。坑也就那几类：用例太少、标准模糊、只看平均、裁判未校准、与真实场景脱节。

如果只从这篇带走一件事，我希望是这个：在你下次改 prompt 之前，先建一个能自动跑的 Eval。它可能一开始很简陋，但只要有它，你的迭代就从"感觉"变成了"工程"。这也是 Agentic Engineering 的核心精神，用清晰的目标、客观的验收、持续的度量，把 AI 编程从氛围变成能力。