AI Agent 上线后，团队最常被问的问题不是"它有多聪明"，而是"它现在表现怎么样、变好了还是变坏了"。这个问题看似简单，实际工程复杂度极高——Agent 是非确定性系统，相同输入可能产生不同输出，传统的"准确率"指标几乎失效。
2026 年，Agent 评估已经从"几个离线 benchmark"演变为"离线 + 在线 + 持续回归"的完整工程体系。本文系统介绍这套体系的设计与实现。## 一、为什么 Agent 评估比传统软件测试难传统软件测试有三个前提：1. 确定性：相同输入必产生相同输出2. 可断言：输出能用布尔表达式判定对错3. 覆盖度可计算：通过代码覆盖率评估测试完整性Agent 系统三条都不满足：1. LLM 推理的非确定性：相同 prompt、不同时间可能产生不同 token 序列2. 输出的"正确性"模糊：同样是"帮我订明天去上海的机票"，订国航还是东航、订早班还是晚班，没有唯一正确答案3. 行为空间巨大：传统代码的执行路径有限，Agent 可能产生指数级的执行路径组合直接套用传统测试方法必然失败。## 二、三层评估体系生产级 Agent 评估应该分三层：### 第 1 层：离线基准（Offline Benchmark）在受控数据集上跑测试，目标是横向对比模型版本和纵向跟踪能力变化。常用基准：| 基准 | 评测能力 | 规模 | 适用场景 ||------|---------|------|----------|| SWE-bench | 真实 GitHub Issue 修复 | 2294 实例 | 代码 Agent || GAIA | 多模态推理 + 工具使用 | 450 任务 | 通用 Agent || WebArena | 浏览器任务执行 | 812 任务 | Web Agent || ToolBench | 工具调用准确率 | 16000+ 工具 | 工具 Agent || AgentBench | 7 类 Agent 任务 | 累计 1300+ | 通用 || τ-bench | 用户交互场景 | 165 场景 | 客服 Agent || MLE-bench | 机器学习工程 | 75 任务 | AutoML Agent |执行方法：pythonfrom langsmith import evaluatefrom langchain.agents import create_agentagent = create_agent(model="claude-4-5", tools=tools)def accuracy(run, example): expected = example.outputs["expected_result"] actual = run.outputs["agent_response"] return 1 if fuzzy_match(expected, actual) else 0results = evaluate( agent.invoke, data="gaia-test-set", evaluators=[accuracy, tool_selection_accuracy, step_count], experiment_prefix="claude-4-5-20260620")text注意：离线基准只能告诉你"模型 A 比模型 B 在 SWE-bench 上高 5%“，不能告诉你"你的 Agent 在生产环境中表现更好"。这是评估体系最常见的误区。### 第 2 层：在线评估（Online Evaluation）在生产流量上做实时评估，目标是监控真实表现和捕捉回归。在线评估的核心是评估器（Evaluator）——一个能对 Agent 输出打分的 LLM 或规则系统。常见评估维度：pythonEVALUATORS = { "task_success": { "type": "llm_judge", "prompt": """请评估以下 Agent 输出是否完成了用户任务。 用户任务: {task} Agent 输出: {output} 评判标准: - 完全完成: 1.0 - 部分完成: 0.5 - 未完成: 0.0 请只输出数字。""", "model": "claude-haiku-4" }, "tool_call_correct": { "type": "rule", "check": lambda trace: validate_tool_sequence(trace.tool_calls) }, "response_relevance": { "type": "embedding_similarity", "threshold": 0.85 }, "hallucination_score": { "type": "llm_judge", "prompt": "请判断以下输出是否包含幻觉内容。\n{output}", "model": "claude-haiku-4" }, "cost_per_task": { "type": "metric", "extract": lambda trace: trace.total_cost_usd, "threshold_max": 0.50 }, "latency_p95": { "type": "metric", "extract": lambda trace: trace.latency_seconds, "threshold_max": 30.0 }}每个评估结果绑定到原始 trace，存入评估数据库。这样就能做后续的回归分析——比如"上个月工具调用准确率 94%，这个月掉到 88%，是哪次模型升级导致的？”### 第 3 层：持续回归（Continuous Regression）把生产流量的一部分作为回归测试集，每次代码或模型变更后自动跑一遍，确保不退化。pythonclass RegressionSuite: def __init__(self, baseline_dataset): self.baseline = baseline_dataset # 上线时锁定的"金标准"集 self.evaluators = [task_success, tool_call_correct, hallucination_score] def run_regression(self, new_agent_version): new_results = evaluate(new_agent_version, self.baseline, self.evaluators) baseline_results = self.load_baseline_results() regressions = [] for evaluator in self.evaluators: old = baseline_results[evaluator.name] new = new_results[evaluator.name] if (old - new) > REGRESSION_THRESHOLD: # 比如 0.05 regressions.append({ "evaluator": evaluator.name, "old_score": old, "new_score": new, "delta": new - old }) if regressions: raise RegressionError(regressions) return new_resultstext关键设计：回归测试集必须周期性刷新。如果永远跑同一批数据，模型会"过拟合到测试集"——分数越来越高，但实际能力不一定提升。建议每周或每两周从生产流量中采样 100-500 个新样本，替换掉老的。## 三、LLM-as-Judge：评估器自身的设计评估器自身也是个 LLM，评估器的质量直接决定评估体系的可信度。常见的设计陷阱和最佳实践：### 陷阱 1：用最强模型当评估器很多团队直接用 GPT-5 评估所有 Agent 输出。这是浪费且低效——GPT-5 评估 Haiku 生成的内容，1 次评估可能比生成本身贵 20 倍。最佳实践：- 评估器分层：简单任务用规则或小模型（Haiku、Gemini Flash），复杂任务用大模型- 评估器性能验证：人工标注 200 个样本，对比评估器和人类判断的一致性，Cohen’s Kappa > 0.7 才算合格### 陷阱 2：评估 prompt 不稳定评估 prompt 一改，评估结果就波动，无法纵向比较。评估 prompt 必须版本化管理，且每次评估带上 prompt hash。pythonEVALUATOR_VERSIONS = { "task_success_v1": "....", "task_success_v2": "....", "task_success_v3": "....", # 当前}def run_evaluator(trace, version="task_success_v3"): prompt = EVALUATOR_VERSIONS[version] return judge_llm(prompt.format(trace=trace))### 陷阱 3：单一评估器视角任务成功率高 ≠ 用户满意。可能 Agent 用 5 步完成了任务，但每步都很慢；可能答案正确，但语气生硬用户烦躁。多评估器组合：pythondef composite_score(trace): scores = { "task_success": trace.evaluations["task_success"], "user_satisfaction": trace.evaluations["user_satisfaction"], "efficiency": max(0, 1 - trace.evaluations["step_count"] / 10), "cost_efficiency": max(0, 1 - trace.evaluations["cost_per_task"] / 0.50), } return weighted_average(scores, weights={ "task_success": 0.5, "user_satisfaction": 0.3, "efficiency": 0.1, "cost_efficiency": 0.1 })text## 四、生产案例：客服 Agent 评估体系以一个电商客服 Agent 为例，完整评估流程：### 评估指标| 维度 | 指标 | 目标 | 告警阈值 ||------|------|------|----------|| 业务 | 任务完成率 | > 90% | < 85% || 业务 | 首次解决率 | > 75% | < 70% || 业务 | 升级人工率 | < 15% | > 20% || 体验 | 用户满意度（1-5） | > 4.2 | < 4.0 || 体验 | 平均响应时间 | < 1.5s | > 3.0s || 体验 | 对话轮次 | < 6 | > 10 || 工程 | 单次成本 | < $0.20 | > $0.50 || 工程 | 工具调用准确率 | > 95% | < 90% || 工程 | 幻觉率 | < 3% | > 8% || 安全 | 越权访问 | 0 | > 0 |### 回归测试集管理pythonREGRESSION_SET = { "common_scenarios": 200, # 高频场景 "edge_cases": 100, # 极端输入 "regression_bugs": 50, # 历史出过的 bug "security_attacks": 30, # 已知攻击样本 "multi_turn": 80, # 多轮对话}每次 Agent 版本升级前，自动跑完 460 个回归用例，4 个核心指标下降超阈值就阻塞发布。## 五、工具栈选型### 开源方案- LangSmith（LangChain 官方）：评估 + 追踪 + 数据集管理一体化- Langfuse：开源可自托管，OpenTelemetry 兼容- Phoenix（Arize）：开源可自托管，偏模型可观测性- DeepEval：专注 LLM 输出评估，单元测试风格- RAGAS：专注 RAG 评估### 商业方案- LangSmith Cloud：托管版，免运维- Helicone：可观测性 + 评估- Braintrust：评估平台，强 PM 视角- Arize Phoenix Cloud：偏 MLOps- Confident AI / DeepEval Cloud：评估即服务### 自建方案自建适合大型企业，需要：- Trace 存储：ClickHouse / TimescaleDB- 评估调度：Temporal / Argo Workflows- 评估存储：PostgreSQL- 可视化：Grafana + 自定义面板- 告警：AlertManager / PagerDuty## 六、评估体系常见的反模式### 反模式 1：只看离线 benchmark 数字Sonnet 4.5 在 SWE-bench 上比 Opus 4.7 高 3 个点，但你的客服 Agent 用 Sonnet 反而更差——因为 SWE-bench 考的是编码能力，客服需要的是工具调用稳定性和对话能力。正解：用业务数据训练自己的评估集，让评估集与业务强相关。### 反模式 2：相信 LLM 评估器，不做人工校验LLM 评估器自己会出错。每周抽样 50 个评估结果让人工复核，跟踪评估器的准确率。### 反模式 3：评估指标越多越好50 个指标的评估报告没人看。核心指标控制在 10-15 个，且必须每个指标都有明确的所有者和响应预案。## 七、2026 年的演进方向1. Agent 评估 Agent（Meta-Evaluation）：用专门的"评估 Agent" 监控其他 Agent，自动发现新出现的失败模式。2. 过程评估（Process Evaluation）：不仅评估最终结果，还评估 Agent 思考过程是否合理，识别"答对但推理错"的隐患。3. 多模态评估成熟：视觉、音频、动作类 Agent 的评估框架在 2026 年下半年会逐步完善。4. 联邦评估：跨企业、跨场景共享匿名化评估数据，建立行业级 Agent 能力地图。## 一句话总结Agent 评估的本质是**“把不可预测的系统变成可量化的工程”**。三层评估（离线基准、在线评估、持续回归）缺一不可，且每层都要警惕"评估器自身不可靠"的问题。评估体系的成熟度，决定了一个 Agent 团队能从"能跑"走向"能持续变好"。## 常见踩坑- 不要把评估当一次性项目——评估体系需要持续运营，指标、评估器、测试集都要随业务演化。- 不要忽视人类反馈——LLM 评估再准，也是 LLM 视角的"准"，用户视角的"满意"必须有人工通道。- 不要等到出问题才做评估——评估能力是产品竞争力的一部分，越早建设越好。