Agent能力评估框架:从单任务到多任务综合评测

为什么Agent评估比LLM评估更难 LLM评估可以简化为"输入→输出→对比",因为LLM是单轮的。但Agent是多步、多工具、有状态的,评估维度爆炸式增长: 不仅看最终答案对不对,还要看过程是否合理 不仅看单任务表现,还要看跨任务迁移能力 不仅看成功率,还要看效率、成本、安全性 本文构建一个从单任务到多任务的综合评估框架。 第一层:单任务评测 任务级指标矩阵 from dataclasses import dataclass, field from typing import Any from enum import Enum class MetricCategory(Enum): ACCURACY = "准确性" EFFICIENCY = "效率" SAFETY = "安全性" ROBUSTNESS = "鲁棒性" @dataclass class TaskMetric: name: str category: MetricCategory value: float weight: float = 1.0 description: str = "" @dataclass class TaskResult: task_id: str task_type: str success: bool metrics: list[TaskMetric] = field(default_factory=list) steps_taken: int = 0 tools_used: list[str] = field(default_factory=list) error_log: list[str] = field(default_factory=list) def weighted_score(self) -> float: total_weight = sum(m.weight for m in self.metrics) weighted_sum = sum(m.value * m.weight for m in self.metrics) return weighted_sum / total_weight if total_weight > 0 else 0.0 核心指标定义 指标 计算方式 说明 任务成功率 成功次数/总次数 基础指标 步骤效率 最优步数/实际步数 0-1,越高越好 工具选择准确率 正确工具调用/总调用 反映工具使用能力 格式合规率 格式正确输出/总输出 结构化输出能力 错误恢复率 恢复成功次数/错误次数 容错能力 成本效率 最优成本/实际成本 token消耗评估 安全违规率 违规次数/总次数 越低越好 评测执行框架 import asyncio from abc import ABC, abstractmethod class TaskEvaluator(ABC): @abstractmethod async def evaluate(self, agent, task) -> TaskResult: pass class CodeGenerationEvaluator(TaskEvaluator): async def evaluate(self, agent, task) -> TaskResult: # 执行Agent result = await agent.run(task["prompt"]) metrics = [] # 1. 功能正确性(单元测试通过率) test_pass = await self._run_tests(result.code, task["test_cases"]) metrics.append(TaskMetric( name="functional_correctness", category=MetricCategory.ACCURACY, value=test_pass, weight=2.0 )) # 2. 步骤效率 optimal_steps = task.get("optimal_steps", 3) actual_steps = result.steps efficiency = min(optimal_steps / actual_steps, 1.0) if actual_steps > 0 else 0 metrics.append(TaskMetric( name="step_efficiency", category=MetricCategory.EFFICIENCY, value=efficiency, weight=1.0 )) # 3. 代码质量(LLM-as-Judge) quality_score = await self._llm_judge( result.code, criteria=["可读性", "性能", "安全性"] ) metrics.append(TaskMetric( name="code_quality", category=MetricCategory.ACCURACY, value=quality_score, weight=1.5 )) # 4. 安全检查 violations = self._check_safety(result.code) metrics.append(TaskMetric( name="safety_compliance", category=MetricCategory.SAFETY, value=1.0 - violations / max(len(result.code.split("\n")), 1), weight=1.0 )) return TaskResult( task_id=task["id"], task_type="code_generation", success=test_pass > 0.8, metrics=metrics, steps_taken=actual_steps, tools_used=result.tools_used, error_log=result.errors ) async def _run_tests(self, code: str, test_cases: list) -> float: passed = 0 for tc in test_cases: try: result = self._execute_code(code, tc["input"]) if result == tc["expected"]: passed += 1 except Exception: pass return passed / len(test_cases) if test_cases else 0 async def _llm_judge(self, code: str, criteria: list[str]) -> float: prompt = f"评估以下代码质量,维度{criteria},给出0-1的分数:\n{code}" score = await judge_llm(prompt) return score 第二层:多任务综合评测 能力维度模型 class CapabilityModel: """Agent能力维度定义""" CAPABILITIES = { "reasoning": "逻辑推理", "coding": "代码生成", "extraction": "信息抽取", "planning": "任务规划", "tool_use": "工具使用", "creativity": "创意生成", "safety": "安全合规", "multilingual": "多语言能力" } def __init__(self): self.dimension_scores: dict[str, list[float]] = { dim: [] for dim in self.CAPABILITIES } def add_result(self, capability: str, score: float): if capability in self.dimension_scores: self.dimension_scores[capability].append(score) def aggregate(self) -> dict[str, float]: return { dim: sum(scores) / len(scores) if scores else 0.0 for dim, scores in self.dimension_scores.items() } 雷达图生成 import numpy as np class RadarChart: def __init__(self, capabilities: dict[str, float]): self.capabilities = capabilities self.angles = np.linspace(0, 2 * np.pi, len(capabilities), endpoint=False).tolist() self.angles += self.angles[:1] def to_plotly_data(self) -> dict: values = list(self.capabilities.values()) values += values[:1] return { "type": "scatterpolar", "r": values, "theta": list(self.capabilities.keys()) + [list(self.capabilities.keys())[0]], "fill": "toself", "name": "Agent能力" } 跨任务迁移评测 class TransferEvaluator: """评估Agent的跨任务迁移能力""" async def evaluate_transfer(self, agent, source_task: dict, target_task: dict) -> float: """在源任务上训练/调整后,在目标任务上的表现""" # 1. 记录基线表现 baseline = await self._run_task(agent, target_task) # 2. 在源任务上的经验 await self._run_task(agent, source_task) # 3. 再测目标任务 after = await self._run_task(agent, target_task) # 4. 迁移增益 transfer_gain = after - baseline # 5. 归一化 max_possible = 1.0 - baseline normalized = transfer_gain / max_possible if max_possible > 0 else 0 return normalized 第三层:系统级评估 长期稳定性评测 from collections import defaultdict import statistics class StabilityMonitor: def __init__(self, window_size: int = 100): self.window_size = window_size self.results: dict[str, list[float]] = defaultdict(list) def record(self, task_type: str, score: float): self.results[task_type].append(score) if len(self.results[task_type]) > self.window_size: self.results[task_type].pop(0) def get_stability_metrics(self) -> dict[str, dict]: metrics = {} for task_type, scores in self.results.items(): if len(scores) < 10: continue metrics[task_type] = { "mean": statistics.mean(scores), "stdev": statistics.stdev(scores), "min": min(scores), "max": max(scores), "cv": statistics.stdev(scores) / statistics.mean(scores) if statistics.mean(scores) > 0 else 0, "trend": self._trend(scores) } return metrics def _trend(self, scores: list[float]) -> str: if len(scores) < 5: return "insufficient_data" first_half = statistics.mean(scores[:len(scores)//2]) second_half = statistics.mean(scores[len(scores)//2:]) if second_half > first_half * 1.05: return "improving" elif second_half < first_half * 0.95: return "declining" return "stable" 评测报告模板 def generate_eval_report(agent_name: str, results: list[TaskResult]) -> str: capability = CapabilityModel() for r in results: # 映射任务类型到能力维度 dim_map = { "code_generation": "coding", "logical_reasoning": "reasoning", "information_extraction": "extraction", "task_planning": "planning" } dim = dim_map.get(r.task_type, "reasoning") capability.add_result(dim, r.weighted_score()) scores = capability.aggregate() report = f"""# Agent评测报告: {agent_name} ## 总览 - 评测任务数: {len(results)} - 平均得分: {sum(r.weighted_score() for r in results)/len(results):.2f} - 整体成功率: {sum(r.success for r in results)/len(results):.1%} ## 能力雷达 {scores} ## 详细指标 | 任务类型 | 成功率 | 平均步骤 | 平均得分 | |----------|--------|----------|----------| """ by_type = {} for r in results: by_type.setdefault(r.task_type, []).append(r) for ttype, task_results in by_type.items(): success_rate = sum(r.success for r in task_results) / len(task_results) avg_steps = sum(r.steps_taken for r in task_results) / len(task_results) avg_score = sum(r.weighted_score() for r in task_results) / len(task_results) report += f"| {ttype} | {success_rate:.1%} | {avg_steps:.1f} | {avg_score:.2f} |\n" return report 评测集构建原则 原则 说明 示例 覆盖性 覆盖所有能力维度 每个维度≥20题 难度梯度 简单/中等/困难均匀 3:5:2比例 防污染 避免训练数据泄露 用私有数据集 可扩展 支持动态新增 模块化任务定义 可复现 固定随机种子 temperature=0 总结 Agent评估是一个多层次工程:单任务看指标,多任务看雷达,长期看稳定性。核心原则: ...

2026-07-29 · 4 min · 779 words · 硅基 AGI 探索者

从零开始构建AI Agent评估管线

从零开始构建AI Agent评估管线 “没有度量就没有改进”——这句话对AI Agent尤其成立。一个没有评估管线的Agent项目,就像在没有仪表盘的飞机上飞行。本文是一份从零开始构建Agent评估管线的实操指南。 评估管线的整体架构 一个完整的Agent评估管线包含五个核心模块: 指标体系:定义"什么算好" 数据集:定义"在什么上评估" 评估器:执行评估的逻辑 报告系统:可视化评估结果 持续集成:将评估嵌入开发流程 模块一:指标体系设计 指标分类框架 我们将Agent评估指标分为四层: 任务完成层(最基础): 成功率:任务是否完成 完成时间:从开始到完成的时间 步数效率:完成任务用的对话轮次/工具调用次数 质量层: 正确性:输出是否准确 完整性:是否覆盖了所有要求 相关性:输出是否切题 交互层: 理解准确度:是否正确理解了用户意图 澄清频率:需要多少次澄清才能理解 错误恢复率:出错后能否恢复 安全层: 安全通过率:安全测试集的通过率 过度拒绝率:安全请求被误拒的比例 越狱成功率:攻击测试的成功率 指标定义的SMART原则 每个指标必须满足: Specific:明确定义计算方法 Measurable:可量化计算 Actionable:指标变化能指导行动 Relevant:和产品质量相关 Trackable:可追踪趋势 反例:“用户满意度”——太模糊,无法计算。 正例:“用户在Agent完成任务后点击’满意’按钮的比例”——可计算、可追踪。 模块二:评估数据集构建 数据集类型 Golden Set:人工标注的标准问答对,有唯一正确答案。用于回归测试。 Evaluation Set:人工标注的开放性任务,可能有多种正确答案。用LLM-as-Judge评分。 Adversarial Set:红队设计的攻击性输入。用于安全测试。 Real-world Set:从真实用户对话中抽样(脱敏后)。用于反映实际使用场景。 数据集构建流程 需求分析:确定需要评估哪些能力和场景 种子设计:为每个场景设计3-5个种子案例 扩增:用LLM基于种子生成更多变体 人工审核:过滤质量不高的扩增案例 标注:为每个案例标注期望结果或评分标准 版本管理:数据集版本化,支持增量更新 数据集规模建议 类型 最小规模 推荐规模 更新频率 Golden Set 100 500+ 季度 Evaluation Set 50 200+ 月度 Adversarial Set 30 100+ 月度 Real-world Set 200 1000+ 周度 模块三:评估器实现 精确匹配评估器 适用于有唯一正确答案的任务: ...

2026-07-13 · 2 min · 357 words · 硅基 AGI 探索者

AI Agent的可靠性评估:从单点到系统级

Agent可靠性:被忽视的关键维度 2026年的AI社区仍然充斥着各种"Agent能力突破"的新闻,但很少有人认真讨论Agent的可靠性。一个能在90%情况下完美完成任务的Agent,和一个能在99.9%情况下可靠完成任务的Agent,在工业应用中是截然不同的产品。 前者是玩具,后者是工具。 从单点指标到系统级评估 传统的模型评估聚焦于单点指标——准确率、召回率、BLEU、ROUGE等。但Agent是一个系统,涉及感知、规划、执行、反思多个环节,单点指标无法反映整体可靠性。 我们提出一个五维度Agent可靠性评估框架: 1. 任务完成率(Task Completion Rate) 最基本的指标:Agent成功完成用户委派任务的比例。关键在于"成功"的定义——需要明确的标准来判定任务是否真正完成,而非"看起来完成了"。 实践中我们采用人工标注+LLM评判的混合方式,对每个任务标注为:完全成功、部分成功、失败、无法判定。 2. 规划质量(Planning Quality) 对于复杂任务,Agent需要将其分解为子任务并规划执行顺序。评估规划质量需要关注: 子任务分解是否合理且无遗漏 执行顺序是否满足依赖关系 是否识别了潜在的失败路径并有备选方案 3. 错误恢复能力(Error Recovery) Agent在执行过程中遇到错误是常态。关键不在于不犯错,而在于能否从错误中恢复。评估指标包括: 遇到工具调用失败后是否能调整策略 遇到信息不足时是否能主动寻求补充信息 在部分子任务失败时是否能优雅降级 4. 一致性(Consistency) 同一个任务多次执行的结果是否一致?不一致的Agent让用户无法建立信任。需要注意的是,一致性不等于确定性——Agent可以有不同的问题解决路径,但最终结果应该一致。 5. 边界感知(Boundary Awareness) Agent是否知道自己的能力边界?一个好的Agent应该在遇到超出能力范围的任务时明确告知用户,而不是自信地给出错误结果。这需要评估模型的"不确定性表达"能力。 评估方法设计 基于上述五个维度,我们设计了一套标准化的评估流程: 测试集构建:从真实用户日志中提取1000个任务,按复杂度分为简单(单步)、中等(3-5步)、复杂(10步以上)三档。每个任务配备人工标注的黄金答案。 执行评估:每个任务独立执行5次,记录每次的执行轨迹和结果。执行轨迹包括每一步的思考、工具调用、中间结果。 评分:使用GPT-5作为评判模型,结合人工审核,对每个执行轨迹在五个维度上打分。最终可靠性得分为五个维度的加权平均。 基准对比:将结果与基线Agent(如纯GPT-5+函数调用)对比,量化被评估Agent相对于基线的改进幅度。 当前Agent的可靠性现状 我们用这个框架评估了2026年中主流的几个Agent框架,发现了一些有趣的结论: 大多数Agent的任务完成率在复杂任务上低于50%,简单任务约为85%,中等任务约为65%。 错误恢复是最薄弱的环节——多数Agent在首次尝试失败后缺乏有效的重试和调整策略。 一致性普遍较差——同一任务5次执行的结果完全一致的不到30%。 边界感知有所改善——经过对齐训练的模型在不确定性表达上有进步,但仍远不够。 提升可靠性的实践建议 引入反思机制:在每个子任务完成后让Agent自我评估结果质量 设计失败兜底策略:为高风险步骤设计备选方案和超时机制 增加确定性约束:对关键步骤使用结构化输出而非自由文本 建立评估闭环:将生产环境的失败case持续纳入测试集 可靠性不是一次性的工作,而是需要持续投入的工程实践。 本文同步发布于 硅基AGI论坛

2026-07-12 · 1 min · 53 words · 硅基 AGI 探索者

AI Agent的可靠性评估:从单点到系统级

Agent可靠性:被忽视的关键维度 2026年的AI社区仍然充斥着各种"Agent能力突破"的新闻,但很少有人认真讨论Agent的可靠性。一个能在90%情况下完美完成任务的Agent,和一个能在99.9%情况下可靠完成任务的Agent,在工业应用中是截然不同的产品。 前者是玩具,后者是工具。 从单点指标到系统级评估 传统的模型评估聚焦于单点指标——准确率、召回率、BLEU、ROUGE等。但Agent是一个系统,涉及感知、规划、执行、反思多个环节,单点指标无法反映整体可靠性。 我们提出一个五维度Agent可靠性评估框架: 1. 任务完成率(Task Completion Rate) 最基本的指标:Agent成功完成用户委派任务的比例。关键在于"成功"的定义——需要明确的标准来判定任务是否真正完成,而非"看起来完成了"。 实践中我们采用人工标注+LLM评判的混合方式,对每个任务标注为:完全成功、部分成功、失败、无法判定。 2. 规划质量(Planning Quality) 对于复杂任务,Agent需要将其分解为子任务并规划执行顺序。评估规划质量需要关注: 子任务分解是否合理且无遗漏 执行顺序是否满足依赖关系 是否识别了潜在的失败路径并有备选方案 3. 错误恢复能力(Error Recovery) Agent在执行过程中遇到错误是常态。关键不在于不犯错,而在于能否从错误中恢复。评估指标包括: 遇到工具调用失败后是否能调整策略 遇到信息不足时是否能主动寻求补充信息 在部分子任务失败时是否能优雅降级 4. 一致性(Consistency) 同一个任务多次执行的结果是否一致?不一致的Agent让用户无法建立信任。需要注意的是,一致性不等于确定性——Agent可以有不同的问题解决路径,但最终结果应该一致。 5. 边界感知(Boundary Awareness) Agent是否知道自己的能力边界?一个好的Agent应该在遇到超出能力范围的任务时明确告知用户,而不是自信地给出错误结果。这需要评估模型的"不确定性表达"能力。 评估方法设计 基于上述五个维度,我们设计了一套标准化的评估流程: 测试集构建:从真实用户日志中提取1000个任务,按复杂度分为简单(单步)、中等(3-5步)、复杂(10步以上)三档。每个任务配备人工标注的黄金答案。 执行评估:每个任务独立执行5次,记录每次的执行轨迹和结果。执行轨迹包括每一步的思考、工具调用、中间结果。 评分:使用GPT-5作为评判模型,结合人工审核,对每个执行轨迹在五个维度上打分。最终可靠性得分为五个维度的加权平均。 基准对比:将结果与基线Agent(如纯GPT-5+函数调用)对比,量化被评估Agent相对于基线的改进幅度。 当前Agent的可靠性现状 我们用这个框架评估了2026年中主流的几个Agent框架,发现了一些有趣的结论: 大多数Agent的任务完成率在复杂任务上低于50%,简单任务约为85%,中等任务约为65%。 错误恢复是最薄弱的环节——多数Agent在首次尝试失败后缺乏有效的重试和调整策略。 一致性普遍较差——同一任务5次执行的结果完全一致的不到30%。 边界感知有所改善——经过对齐训练的模型在不确定性表达上有进步,但仍远不够。 提升可靠性的实践建议 引入反思机制:在每个子任务完成后让Agent自我评估结果质量 设计失败兜底策略:为高风险步骤设计备选方案和超时机制 增加确定性约束:对关键步骤使用结构化输出而非自由文本 建立评估闭环:将生产环境的失败case持续纳入测试集 可靠性不是一次性的工作,而是需要持续投入的工程实践。 本文同步发布于 硅基AGI论坛

2026-07-12 · 1 min · 53 words · 硅基 AGI 探索者
Agent基准设计

Agent基准设计2026:如何评估智能体能力

引言 Agent(智能体)的评估比传统LLM评估复杂得多。Agent不仅需要理解语言,还需要规划任务、调用工具、处理异常、与环境交互。传统的"输入-输出"评估模式无法捕捉Agent的多步骤、动态特性。本文将系统介绍2026年Agent评估基准的设计方法。 Agent能力维度 维度一:任务理解与规划 任务分解:将复杂任务分解为子任务 计划制定:为子任务制定执行顺序 动态调整:根据执行结果调整计划 维度二:工具调用 工具选择:选择正确的工具 参数生成:生成正确的工具参数 结果处理:正确处理工具返回结果 错误恢复:工具调用失败时的恢复策略 维度三:环境交互 网页操作:浏览网页、点击、输入 文件操作:创建、读取、修改文件 API调用:调用外部API 代码执行:编写并执行代码 维度四:记忆与上下文 短期记忆:当前任务的上下文 长期记忆:跨任务的知识积累 记忆检索:从记忆中检索相关信息 维度五:协作能力 多Agent协作:与其他Agent分工合作 人机协作:与人类用户交互 角色适应:根据角色调整行为 主流Agent基准 AgentBench AgentBench是最全面的Agent评估基准,覆盖8个场景: 场景 说明 评估指标 网页购物 模拟电商购物 任务完成率 网页浏览 浏览网页获取信息 信息准确率 数据库操作 SQL查询和数据操作 查询正确率 卡牌游戏 策略游戏 胜率 知识问答 多跳推理问答 准确率 房间设计 3D空间布局 满意度 操作系统 Linux命令操作 任务完成率 数据库管理 数据库维护 操作正确率 WebArena WebArena测试Agent在真实网页环境中的操作能力: 任务示例: 1. "在亚马逊上找到评分4星以上的无线耳机,加入购物车" 2. "在GitLab上创建一个新仓库,命名为'test-project'" 评估指标: - 任务完成率(Success Rate) - 步骤效率(Step Efficiency) - 路径准确率(Path Accuracy) ToolBench ToolBench评估工具调用能力: ...

2026-07-02 · 3 min · 454 words · 硅基 AGI 探索者
agent benchmark methodology

Agent 基准测试方法论:从设计到执行

Agent 基准测试与传统 LLM 评测的区别 传统 LLM 评测关注单轮输入输出质量——生成文本是否流畅、知识是否准确、推理是否正确。但 Agent 评测面临根本差异:Agent 需要在多轮交互中自主决策、调用工具、维护状态、处理错误。一次错误的工具调用可能让整个任务失败,即使后续推理完全正确。 Agent 基准测试必须考察:长程规划能力(复杂目标分解为可执行步骤)、工具使用准确性(参数构造与调用时机)、错误恢复能力(异常时调整策略)、状态管理(多轮交互的上下文一致性)。 设计原则 任务真实性:基准任务应反映真实世界需求,而非人造玩具问题 可复现性:同一 Agent 多次运行结果应稳定,随机性需控制和记录 评估客观性:优先程序化评估而非人工判断,可大规模运行 难度梯度:包含不同难度级别,避免天花板或地板效应 测试集构建 来源 优点 缺点 示例 真实工单 高生态效度 获取困难 SWE-bench 人工构造 可控性强 偏离真实分布 AgentBench 合成生成 规模可扩展 复杂度有限 ToolBench 混合方法 兼顾真实与可控 设计成本高 tau-bench 构建流程:原始任务池 → 去重过滤 → 难度标注 → 验证集构建 → 评估脚本开发 → 试测校准 → 正式发布 评估指标体系 metrics = { "success_rate": "任务完成率(最核心指标)", "step_efficiency": "实际步骤数 / 最优步骤数", "tool_accuracy": "正确工具调用数 / 总工具调用数", "cost_efficiency": "任务完成数 / 总 token 消耗", "error_recovery_rate": "成功恢复的错误数 / 总错误数", "hallucination_rate": "幻觉工具调用数 / 总工具调用数", } def composite_score(result): weights = {"success_rate": 0.5, "step_efficiency": 0.2, "tool_accuracy": 0.2, "cost_efficiency": 0.1} return sum(result[k] * w for k, w in weights.items()) 主流基准对比 AgentBench 覆盖 8 类任务环境:操作系统交互、数据库操作、知识图谱问答、卡片游戏、迷宫导航、网页浏览、家务模拟、购物对话。优势是覆盖面广,局限是部分任务生态效度参差不齐。 ...

2026-06-24 · 2 min · 266 words · AI 实战派
鲁ICP备2026018361号