为什么AI Agent需要专门的评测体系
传统软件的测试是确定性的：输入A，期望输出B。但AI Agent的输出具有非确定性——同一个输入可能产生不同但都合理的输出。我们在深圳的多个AI Agent项目中看到，团队最头疼的问题不是”Agent能不能跑起来”，而是”怎么知道Agent跑得好不好”。
没有评测体系，Agent的迭代就变成”凭感觉调Prompt”和”用户投诉驱动开发”。建立系统化的评测体系，是AI Agent从Demo走向生产的关键一步。
行业现状：超过80%的AI Agent项目卡在评测阶段——不是因为技术不够，而是因为团队不知道如何定义”够好”。
AI Agent评测的三大维度
维度一：能力评测（Capability）
能力评测回答”Agent能不能做某件事”，是最基础的评测层：
| 评测类型 | 评测内容 | 评测方法 | 典型指标 |
|---|---|---|---|
| 工具调用 | Function Calling准确性 | 标准化测试集 | 参数准确率、调用成功率 |
| 推理能力 | 多步推理、逻辑推理 | Chain-of-Thought评测 | 推理正确率、步骤完整性 |
| 知识检索 | RAG检索准确性 | QA数据集 | 召回率、精确率、F1 |
| 代码生成 | 代码可执行性 | 单元测试 | 通过率、覆盖率 |
| 多语言 | 中英双语处理 | 平行语料 | 翻译BLEU、语义一致性 |
维度二：行为评测（Behavior）
行为评测回答”Agent做得好不好”，关注的是用户体验和交互质量：
- 任务完成率：Agent成功完成用户任务的比例
- 平均轮数：完成任务所需的对话轮数（越少越好）
- 错误恢复率：Agent在出错后自行纠正恢复的比例
- 幻觉率：Agent生成虚假信息的频率
- 拒答合理性：面对无法回答的问题时，Agent是否恰当拒答
维度三：工程评测（Engineering）
工程评测回答”Agent是否适合生产环境”，关注性能和可靠性：
| 指标 | 定义 | 合格标准 | 告警阈值 |
|---|---|---|---|
| P50延迟 | 50%请求的响应时间 | < 3s | > 5s |
| P99延迟 | 99%请求的响应时间 | < 15s | > 30s |
| 成功率 | 非异常响应的请求比例 | > 99.5% | < 98% |
| Token消耗 | 单次平均Token使用量 | < 8K | > 16K |
| 成本/请求 | 单次请求平均花费 | < 0.05元 | > 0.15元 |
LLM-as-Judge：用大模型评大模型
评测架构设计
人工评测昂贵且不可扩展。LLM-as-Judge方法用更强的大模型（如GPT-5.6、GLM-5.2.2）自动评估Agent输出质量，已被上海多家AI企业采纳：
# LLM-as-Judge 评测框架
EVAL_PROMPT = """你是一个严格的AI质量评测员。
请对以下Agent回答进行评分（1-5分），维度包括：
1. 准确性：信息是否正确、有无幻觉
2. 完整性：是否完整回答了用户问题
3. 相关性：回答是否与问题高度相关
4. 可操作性：用户能否根据回答采取行动
用户问题: {question}
标准答案: {reference}
Agent回答: {response}
请输出JSON格式：
{{"accuracy": X, "completeness": X,
"relevance": X, "actionability": X,
"overall": X, "reason": "..."}}
"""
def evaluate_response(question, response, reference=None):
result = llm.chat(
model="glm-5", # 用最强模型做裁判
messages=[{
"role": "user",
"content": EVAL_PROMPT.format(
question=question,
reference=reference or "（无标准答案）",
response=response
)
}],
temperature=0, # 评测时温度设为0确保一致性
response_format={"type": "json_object"}
)
return json.loads(result)
评测一致性校验
LLM-as-Judge存在位置偏差（偏向第一个选项）和冗长偏差（偏向更长的回答）。杭州某实验室的校验方案：
| 偏差类型 | 表现 | 消除方法 |
|---|---|---|
| 位置偏差 | 偏向第一个选项 | 交换AB顺序，取平均分 |
| 冗长偏差 | 偏向更长的回答 | 加入长度归一化评分 |
| 自我偏好 | 同模型评分偏高 | 用不同模型族交叉评测 |
| 格式偏差 | 偏向Markdown格式 | 统一输出格式后评测 |
评测数据集构建
从生产日志中构建评测集
最好的评测数据来自真实用户。北京某智能客服团队的评测集构建流程：
- 采样：从生产日志中按场景类型随机采样1000条对话
- 标注：人工标注每条对话的质量（好/一般/差）和原因
- 归类：按问题类型、难度、Agent表现聚类
- 精选：每个类别选10-20条作为基准测试集
- 迭代：每月补充新发现的问题模式
# 从生产日志采样评测数据
def build_eval_dataset(log_db, sample_size=1000):
conn = sqlite3.connect(log_db)
# 按场景类型分层采样
conversations = conn.execute("""
SELECT session_id, user_msg, agent_reply,
feedback_score, scene_type
FROM conversation_logs
WHERE created_at > datetime('now', '-30 days')
AND agent_reply IS NOT NULL
ORDER BY RANDOM() LIMIT ?
""", (sample_size,)).fetchall()
eval_set = []
for conv in conversations:
session_id, user_msg, agent_reply, score, scene = conv
eval_set.append({
"id": session_id,
"question": user_msg,
"response": agent_reply,
"scene_type": scene,
"user_score": score, # 用户反馈作为弱标注
"auto_score": None # 待LLM-as-Judge填充
})
return eval_set
Golden Set vs Adversarial Set
| 数据集类型 | 用途 | 数据来源 | 更新频率 |
|---|---|---|---|
| Golden Set | 回归测试 | 人工精选的典型场景 | 季度 |
| Adversarial Set | 鲁棒性测试 | 红队攻击、边界case | 月度 |
| Production Set | 线上质量监控 | 生产日志采样 | 周度 |
| Edge Case Set | 异常处理 | 用户投诉、bad case | 实时 |
经验：评测集不是越大越好。50条高质量、覆盖核心场景的评测用例，比500条随机采样的用例更有价值。深圳某团队用80条精选评测集做到了85%的问题发现率。
多Agent系统的评测挑战
单Agent vs 多Agent评测差异
多Agent系统的评测复杂度显著增加，因为需要评估的不仅是单个Agent的能力，还有Agent之间的协作质量：
| 评测层级 | 单Agent | 多Agent | 额外挑战 |
|---|---|---|---|
| 个体能力 | 工具调用准确率 | 每个Agent的独立能力 | 角色差异下的能力基线 |
| 协作效率 | 不适用 | 任务分配合理性 | 谁该做什么的判断准确性 |
| 信息传递 | 不适用 | Agent间上下文传递准确性 | 信息衰减与失真 |
| 死循环检测 | 不适用 | Agent间无限调用检测 | 终止条件设计 |
| 系统延迟 | 单次LLM调用 | 多轮Agent调用叠加 | 延迟放大效应 |
多Agent评测指标
# 多Agent系统评测
def evaluate_multi_agent(session_traces):
metrics = {
# 1. 协作效率
"task_routing_accuracy": 0, # 任务分配正确率
"avg_agent_handoffs": 0, # 平均交接次数
"redundant_calls": 0, # 冗余调用次数
# 2. 信息传递
"context_fidelity": 0, # 上下文传递保真度
"info_loss_rate": 0, # 信息丢失率
# 3. 系统健康
"total_llm_calls": 0, # 总LLM调用次数
"max_depth": 0, # 最大调用深度
"loop_detected": False, # 是否检测到死循环
"total_cost": 0, # 总Token成本
}
for trace in session_traces:
# 检测死循环：同一Agent连续调用超3次
if detect_loop(trace, threshold=3):
metrics["loop_detected"] = True
# 统计调用深度
metrics["max_depth"] = max(
metrics["max_depth"],
trace_depth(trace)
)
return metrics
评测自动化与CI/CD集成
评测流水线设计
评测不应是上线前的一次性工作，而应嵌入持续集成流程：
# 评测流水线（CI/CD集成）
# .github/workflows/agent-eval.yml 或 Jenkins pipeline
STAGES = [
{
"name": "Golden Set回归",
"dataset": "eval/golden_set.jsonl",
"model": "glm-5-turbo", # 快速预筛
"threshold": 0.85, # 通过阈值
"action": "fail_on_miss" # 不达标则阻断
},
{
"name": "Adversarial鲁棒性",
"dataset": "eval/adversarial.jsonl",
"model": "glm-5.2",
"threshold": 0.70,
"action": "warn_only" # 仅告警不阻断
},
{
"name": "性能基准",
"dataset": "eval/perf.jsonl",
"model": "glm-5-turbo",
"threshold": None, # 仅采集指标
"action": "collect"
}
]
def run_eval_pipeline(version):
results = []
for stage in STAGES:
scores = run_eval(
dataset=stage["dataset"],
model=stage["model"],
agent_version=version
)
if stage["action"] == "fail_on_miss":
if scores["pass_rate"] < stage["threshold"]:
return {"status": "BLOCKED", "stage": stage["name"]}
results.append({"stage": stage["name"], **scores})
return {"status": "PASSED", "results": results}
评测看板设计
| 看板模块 | 展示内容 | 数据来源 | 更新频率 |
|---|---|---|---|
| 能力趋势 | 各维度评分的历史曲线 | Golden Set评测 | 每次发版 |
| 线上质量 | 用户满意度、投诉率 | 生产日志+反馈 | 实时 |
| 成本看板 | Token消耗、单次成本 | API计费数据 | 日度 |
| Bad Case | 低分对话、失败案例 | 自动筛选+人工标注 | 周度 |
评测体系的成熟度模型
参考杭州某AI企业的实践，我们将评测体系分为5个成熟度等级：
| 等级 | 名称 | 特征 | 典型表现 |
|---|---|---|---|
| L1 | 人工抽检 | 无系统化评测 | 上线靠人肉测试 |
| L2 | 静态测试集 | 有固定测试用例 | 每次发版跑一遍 |
| L3 | 自动化评测 | LLM-as-Judge + CI集成 | 发版自动跑评测 |
| L4 | 持续监控 | 线上实时评测+告警 | 质量问题自动发现 |
| L5 | 自进化评测 | 评测集自动扩展+自适应 | Bad case自动入集 |
建议路径：不要试图一步到位到L5。从L2开始（建一个20-50条的Golden Set），在3个月内推进到L3（自动化评测），6个月内到L4（持续监控）。上海某团队从L1到L4用了4个月，Agent线上问题发现时间从”天级”缩短到”分钟级”。
常见问题
LLM-as-Judge可靠吗？会不会”自己评自己”导致虚高？
LLM-as-Judge确实存在自评偏好问题——用GPT-5.6评GPT-5.6的输出会偏高。解决方案：一是用不同模型族交叉评测（GLM评GPT、GPT评GLM）；二是定期抽取10-20%的评测样本进行人工复核校准；三是使用Pair-wise比较（让模型比较两个回答的优劣）而非绝对评分，偏差更小。深圳某团队用GLM-5.2.2评GPT-5.6输出，与人工评分的相关性达到0.82。
评测数据集需要多大才够用？
质量远比数量重要。50条覆盖核心场景的高质量评测用例，比500条随机采样的数据更有价值。建议按20/30/50原则：20条Golden Set（核心场景，用于回归测试）、30条Adversarial Set（边界case，用于鲁棒性测试）、50条Production Set（线上采样，用于质量监控）。总计100条左右即可覆盖80%以上的问题模式。随着业务发展逐步扩充到200-300条。
多Agent系统怎么评测协作质量？
重点评测三个指标：一是任务路由准确率（Agent是否把子任务分配给正确的专业Agent）；二是信息保真度（上游Agent传递给下游的信息是否完整无失真）；三是死循环检测（系统是否能在合理步数内终止）。北京某多Agent项目通过Tracing日志记录每步Agent调用的输入输出，再用LLM-as-Judge评估每个交接点的质量，有效发现了信息丢失问题。
评测应该用temperature=0吗？
评测时建议设temperature=0以减少随机性，确保结果可复现。但这会低估Agent在生产环境（通常temperature>0）的实际表现。折中方案：核心评测用temperature=0（确保稳定性），另外跑10%的评测用temperature=0.3-0.7以模拟线上多样性。两者对比可发现Agent在”保守模式”和”创造性模式”下的表现差异。
如何在评测中发现Agent的幻觉问题？
幻觉是最难评测的维度。三个方法：一是用有标准答案的QA数据集，检测Agent回答中是否有标准答案之外的事实陈述；二是用Knowledge Grounding评测——给Agent一段背景知识，检测回答是否全部基于给定知识（不引入外部知识）；三是对比验证——让Agent对同一问题回答两次，如果两次回答存在事实矛盾，则大概率有幻觉。杭州某团队用方法三发现了7%的幻觉率。