一个尴尬的现实
我见过太多团队，Agent 做得风风火火，Demo 演示惊艳全场，可你一问"它到底好不好用、好用到什么程度"，全场沉默。
因为他们根本没法量化。全凭"我感觉还行""上次跑得挺好"这种主观感受。
这是 Agent 工程里最容易被跳过、却最致命的一环——评估（Evaluation）。做得出来一个 Agent 是一回事，能证明它好、能持续监控它有没有变差，是另一回事，而且是更难的那回事。
这篇我把一套可落地的 Agent 评估体系拆开讲：评什么、怎么评、怎么自动化。
一、为什么 Agent 评估比想象中难
评估传统软件很简单：输入确定，输出也确定，对比一下就行。但 Agent 不一样，它难在三点：
- 输出不确定：同一个问题问两次，Agent 可能给出措辞完全不同但都正确的答案。你没法用"字符串完全相等"来判对错。
- 过程也要评：Agent 是多步的。最终答案对，不代表过程对——它可能瞎蒙对了，也可能绕了一大圈才到。
- 没有标准答案：很多任务（比如"写一份调研报告"）压根没有唯一正确答案，只有"好不好"的程度差异。
这三点决定了：Agent 评估不能只看最终结果，得是一套多维度的体系。
二、评什么：四个核心维度
我把 Agent 该评的东西，归纳成四个维度。
维度一：任务完成度（Task Success）
最核心的问题——它把活干成了吗？
- 对有明确答案的任务：用准确率、F1 这类硬指标；
- 对开放式任务：用打分（比如 1-5 分），评"完成质量"。
维度二：过程质量（Trajectory Quality）
不光看结果，还要看它是怎么走到结果的：
- 路径效率：用了几步？有没有多余的弯路？
- 工具使用：调对工具了吗？参数传对了吗？
- 推理合理性：每一步的"思考"站得住脚吗？
一个走 3 步到答案的 Agent，比绕 15 步才到的，显然更好——哪怕最终答案一样。
维度三：稳定性（Consistency）
同一个任务，多跑几次，表现稳不稳？
把同一组测试用例跑 N 遍，看结果的方差。一个时好时坏的 Agent，哪怕平均分高，也不能上生产——你没法信任它。
维度四：成本与延迟（Cost & Latency）
工程上绕不开的现实维度：
- 单次任务消耗多少 token、多少钱？
- 端到端要多久？用户能忍吗？
一个准确率 95% 但每次要烧 10 块钱、等 2 分钟的 Agent，和一个准确率 90% 但又快又便宜的，哪个更好？取决于场景，但你必须先把这两个数测出来。
三、怎么评：三种方法各管一段
知道了评什么，接下来是怎么评。三种方法，各有适用场景。
方法一：基于规则（Rule-based）
对有标准答案的任务，写死规则判分最快最准。
def evaluate_rule(output, expected):
return {
"exact_match": output.answer == expected.answer,
"step_count": len(output.steps),
"tools_correct": output.tools_used == expected.tools,
}
优点：快、便宜、确定。缺点：只能评有明确答案的，开放任务无能为力。
方法二：LLM 当裁判（LLM-as-Judge）
对开放式任务，用一个更强的模型当"考官"，按评分标准给答案打分。
def evaluate_by_llm(task, output):
prompt = f"""
你是严格的评审。请按以下标准给这个回答打分(1-5)：
- 准确性：信息是否正确
- 完整性：是否覆盖了问题的所有方面
- 实用性：对用户是否真的有帮助
任务：{task}
回答：{output}
请逐项打分并给出理由。
"""
return judge_llm.chat(prompt)
优点：能评开放式、主观质量。缺点：裁判模型本身有偏好，得校准；成本也更高。一个实用技巧——让裁判给出打分理由，比只给分数更可靠，也方便你排查它判得对不对。
方法三：人工评估（Human Eval）
终极裁判还是人。但人工贵、慢，所以要用在刀刃上：
- 用规则 + LLM 自动跑大批量，筛出可疑的、分歧大的；
- 只对这部分做人工复核。
这样既保住了人工的可靠性，又不至于让人去看几千条。
四、把评估自动化：建一套回归测试
零散地评几次没意义。真正有价值的，是把评估变成像软件单元测试一样的自动化回归。
核心是建一个评估数据集（Eval Set）——一批有代表性的测试用例，覆盖常见场景、边界情况、已知会翻车的 case。
# eval_suite.py —— Agent 回归测试
class AgentEvalSuite:
def __init__(self, eval_set):
self.cases = eval_set # 测试用例集
def run(self, agent, repeat=3):
results = []
for case in self.cases:
# 每个用例跑多次，测稳定性
runs = [agent.run(case.input) for _ in range(repeat)]
results.append({
"case": case.id,
"success_rate": self.success_rate(runs, case.expected),
"avg_steps": self.avg_steps(runs),
"avg_cost": self.avg_cost(runs),
"variance": self.variance(runs), # 稳定性
})
return self.aggregate(results)
有了这套东西，每次你改了 prompt、换了模型、调了流程，跑一遍就知道是变好了还是变差了——而不是凭感觉。这一点，是业余和专业的分水岭。
五、上线后别停：持续监控
评估不是上线前跑一次就完事。模型会漂移、用户的问法会变、数据分布会偏移——线上 Agent 的表现是会随时间衰减的。
所以要做线上监控：
- 采样回放：抽一部分真实流量，定期用评估体系跑一遍；
- 关键指标看板：成功率、平均步数、成本、延迟，做成趋势图盯着；
- 异常告警：某个指标突然掉下来，自动报警，而不是等用户投诉。
线上监控 + 离线回归，双管齐下，你才能对"我的 Agent 现在到底好不好"这个问题，随时给出有数据支撑的答案。
六、给起步者的最小方案
如果你刚开始、没精力搞这么全，我给一个最小可行评估方案，先把框架立起来：
- 攒 20-30 个测试用例：覆盖你最常见的场景 + 几个已知会翻车的；
- 每个用例跑 3 遍：先把"稳不稳"这个最容易被忽略的维度抓住；
- 自动指标 + LLM 裁判：成功率、步数、成本用脚本算，质量用 LLM 打分；
- 每次改动前后各跑一遍：建立"改动 → 评估 → 对比"的习惯。
就这四步，你已经超过了绝大多数"凭感觉"的团队。
写在最后
整个 Agent 实战系列写到这里，我想用评估这一篇收尾，是有意的——因为它最容易被跳过，却最能区分"做着玩"和"动真格"。
能跑出 Demo 的 Agent 遍地都是，能被持续、量化地证明"它确实好用"的 Agent，凤毛麟角。
会评估，你才敢迭代；敢迭代，Agent 才能越做越好。这是把 Agent 从"演示品"变成"生产力"的最后一公里。