AI Agent 的评测与质量保障：从"能跑"到"可靠"的完整体系

本文承接多智能体协作，系统讲解 AI Agent 的评测与质量保障体系。文章分析单轮模型评测的局限性，构建覆盖任务完成率、步骤准确性、效率、成本、安全、鲁棒性的六维评测框架，介绍任务级评测集设计、自动化评测流水线、LLM-as-Judge 评分、人工评估流程、生产环境在线监控、回归测试与持续改进闭环，并结合代码说明如何搭建可量化、可对比、可持续的 Agent 质量保障体系。

目录

• 一、为什么 Agent 评测不同于传统模型评测
• 二、Agent 评测的核心维度体系
• 三、任务级评测：构建可复现的评测任务集
• 四、自动化评测框架与实现
• 五、人工评估与专家评审
• 六、生产环境的在线监控
• 七、回归测试与持续质量保障
• 八、上线前检查清单
• 结语

引言

当你把一个 AI Agent 从 demo 推向生产，最常遇到的问题不是”它能不能做”，而是”它做得够不够好、够不够稳”。单轮大模型的评测已经相对成熟——给一个问题，看答案对不对、流畅不流畅。但 Agent 不一样：它要连续做十几步决策、调用五六个工具、处理中间失败、最终交付一个完整结果。任何一步出问题，最终结果都可能南辕北辙。

多智能体协作让这个问题更复杂：多个 Agent 之间的消息传递、任务分发、冲突解决，每一个环节都可能引入错误。你需要一套完整的评测与质量保障体系，才能回答这些问题：这个 Agent 的任务完成率是多少？哪类任务最容易失败？新版本是进步了还是退化了？生产环境出问题能不能及时发现？

本文从评测维度、任务集设计、自动化框架、人工评估、在线监控、回归测试六个层面，系统讲解如何为 AI Agent 构建一套从开发到生产的完整质量保障体系。

一、为什么 Agent 评测不同于传统模型评测

1.1 单轮回答评测的局限性

传统大模型评测（如 MMLU、GSM8K、HumanEval）衡量的是”单轮回答能力”：给一个输入，模型输出一个答案，然后和标准答案比对。这种评测方式有三个根本局限。

第一，它假设任务是单步的。但 Agent 任务通常是多步的：理解需求 → 规划步骤 → 调用工具 → 观察结果 → 调整计划 → 继续执行 → 最终交付。单轮评测只能衡量其中某一步的能力，无法衡量整体流程的完成质量。

第二，它假设答案是确定的。但 Agent 任务的正确答案往往不唯一：完成同一个数据分析任务，可以用不同的工具组合、不同的执行顺序，只要最终结果正确就行。用单一标准答案去比对，会误判很多合理的执行路径。

第三，它不衡量过程质量。一个 Agent 可能最终结果对了，但中间走了很多弯路、调用了不必要的工具、消耗了大量 Token。另一个 Agent 可能结果差不多，但步骤精简、成本低廉。单轮评测无法区分这两种情况。

1.2 Agent 任务的复杂性

Agent 任务的复杂性体现在四个维度：

多步决策意味着错误会传播：第 3 步的工具调用参数错了，第 4 步基于错误结果做决策，第 5 步继续偏离，最终结果可能完全错误，但你很难一眼看出是哪一步出了问题。

长上下文意味着信息可能丢失：Agent 在第 1 步获取的关键信息，到第 20 步可能已经被遗忘或混淆。这不是模型”笨”，而是上下文窗口的物理限制。

1.3 从”回答对不对”到”任务成没成”

Agent 评测的核心范式转变是：从衡量”回答对不对”转向衡量”任务成没成”。

这意味着评测的基本单位不再是”问题-答案对”，而是”任务-结果对”。一个任务有明确的目标、可验证的完成标准、允许的工具集合。Agent 执行完任务后，评测系统检查：目标是否达成？过程是否合理？成本是否可接受？

这种范式转变要求你重新设计评测的每一个环节：任务怎么设计、结果怎么判定、过程怎么分析、指标怎么统计。后面的章节会逐一展开。

二、Agent 评测的核心维度体系

2.1 任务完成率（Task Success Rate）

任务完成率是最核心、最直观的指标：在 N 个评测任务中，Agent 成功完成了多少个。

任务完成率 = 成功完成的任务数 / 总任务数 × 100%

但”成功完成”的定义需要仔细设计。对于有明确输出的任务（如”计算这个表格的总和”），可以用精确匹配或容差匹配。对于开放式任务（如”写一份市场分析报告”），需要用 LLM-as-Judge 或人工评估来判定。

建议按任务难度分级统计完成率：

如果简单任务的完成率低于 95%，说明 Agent 有基础能力问题，需要优先修复。

2.2 步骤准确性与工具调用正确率

任务完成率只看最终结果，不看过程。步骤准确性衡量每一步决策的质量：

• 规划合理性：Agent 制定的执行计划是否合理、完整、有序
• 工具选择正确率：是否选择了正确的工具来完成当前子任务
• 参数准确率：工具调用的参数是否正确、完整、格式合规
• 错误恢复率：遇到工具调用失败时，能否正确诊断并恢复

工具调用正确率尤其重要，因为它是 Agent 与外部世界交互的接口。参数错误会导致工具失败，工具选择错误会导致任务偏离。

工具调用正确率 = 正确的工具调用次数 / 总工具调用次数 × 100%

建议统计每类工具的单独正确率，找出最容易出错的工具类型，针对性优化。

2.3 效率：步数、耗时、Token 消耗

两个 Agent 都完成了同一个任务，但一个用了 5 步、10 秒、2000 Token，另一个用了 20 步、2 分钟、15000 Token。显然后者的效率差很多。

效率指标包括：

• 平均步数：完成一个任务平均需要多少步决策
• 平均耗时：从任务开始到完成的平均墙钟时间
• 平均 Token 消耗：输入 + 输出的总 Token 数
• 工具调用次数：平均每个任务调用多少次工具
• 重试率：因失败而重试的步骤占比

效率和完成率之间需要平衡。有时候增加几步验证可以提高完成率，但会增加成本。你需要找到适合业务场景的平衡点。

2.4 成本：API 调用费用与资源占用

成本是生产环境必须考虑的指标。对于基于 LLM 的 Agent，主要成本是 API 调用费用：

单次任务成本 = (输入 Token 数 × 输入单价 + 输出 Token 数 × 输出单价) / 1000

除了直接的 API 费用，还要考虑： – 工具调用的后端服务成本（如搜索 API、数据库查询） – 计算资源占用（如本地模型推理的 GPU 时间） – 人工审核成本（需要人工介入的任务比例）

建议建立成本仪表盘，按任务类型、Agent 版本、时间维度统计成本趋势，及时发现成本异常。

2.5 安全与合规

Agent 可以调用工具、操作数据，这带来了安全风险。安全评测需要检查：

• 越权操作：Agent 是否尝试执行超出其权限范围的操作
• 数据泄露：Agent 是否在输出中泄露了不应公开的敏感信息
• 注入攻击：面对提示注入攻击时，Agent 是否能正确识别和拒绝
• 合规性：Agent 的行为是否符合行业法规和公司政策

安全评测应该用专门的红队测试集，包含各种攻击场景和边界情况。安全指标的目标通常是 0 容忍：任何安全漏洞都必须修复后才能上线。

2.6 鲁棒性：异常输入与环境波动

生产环境永远不是理想环境。鲁棒性衡量 Agent 在面对异常情况时的表现：

• 异常输入：用户输入模糊、矛盾、不完整时，Agent 能否正确处理
• 工具失败：工具调用超时、返回错误、返回异常格式时，Agent 能否恢复
• 网络波动：API 调用间歇性失败时，Agent 能否重试或降级
• 上下文溢出：任务过长导致上下文接近上限时，Agent 能否优雅处理

鲁棒性测试通常用”故障注入”的方法：在评测过程中故意让某些工具调用失败、返回异常数据，观察 Agent 的应对能力。

三、任务级评测：构建可复现的评测任务集

3.1 评测任务的设计原则

一个好的评测任务集是整个评测体系的基础。设计评测任务时遵循以下原则：

代表性：任务应该覆盖真实使用场景中的主要类型，而不是只挑简单的或只挑难的。

可复现：同一个任务多次运行应该得到可比较的结果。这意味着任务的输入、可用工具、环境状态都应该是确定的。

可判定：每个任务都应该有明确的完成标准，能够客观判定成功或失败。

多样性：任务应该在难度、类型、工具组合上有足够的多样性，避免评测结果偏科。

独立性：任务之间应该相互独立，一个任务的执行结果不应该影响另一个任务。

3.2 任务分级与覆盖矩阵

建议按两个维度对任务进行分类：难度等级和任务类型。

难度等级： – L1 简单：1-3 步，单工具，无异常 – L2 中等：4-10 步，多工具，可能有小异常 – L3 复杂：10+ 步，多工具协作，需处理异常 – L4 极难：开放式目标，需自主规划和创新

任务类型（以数据分析 Agent 为例）： – 数据查询：从数据库或 API 获取数据 – 数据清洗：处理缺失值、异常值、格式转换 – 数据分析：统计分析、趋势分析、对比分析 – 数据可视化：生成图表和报告 – 多步综合：需要多种操作组合的复杂任务

构建一个覆盖矩阵，确保每个难度等级 × 任务类型的组合都有足够的任务样本：

3.3 任务模板与参数化生成

手工编写大量评测任务费时费力。更好的方法是设计任务模板，然后用参数化的方式批量生成。

例如，一个”数据查询”任务模板：

任务模板：查询{时间范围}内{产品类别}的{指标}，并按{维度}排序

参数空间：
- 时间范围：["最近7天", "最近30天", "本季度", "去年全年"]
- 产品类别：["电子产品", "服装", "食品", "家居"]
- 指标：["销售额", "订单量", "用户数", "退货率"]
- 维度：["按天", "按周", "按月", "按地区"]

生成方式：从每个参数中随机取值，组合成具体任务

参数化生成的好处是可以快速扩大任务集规模，同时保持任务的多样性和代表性。但要注意：生成的任务需要人工抽查，确保任务描述清晰、完成标准明确。

3.4 黄金答案与判定标准

每个任务都需要有明确的判定标准。根据任务类型，可以采用不同的判定方式：

精确匹配：适用于有唯一正确答案的任务，如”计算 2024 年总销售额”。判定时检查数值是否在容差范围内。

包含匹配：适用于答案需要包含某些关键信息的任务，如”列出销量前 5 的产品”。判定时检查关键信息是否都在输出中。

LLM-as-Judge：适用于开放式任务，如”写一份市场分析报告”。用另一个 LLM 作为评委，按预设的评分标准打分。

人工评估：适用于特别重要或特别复杂的任务，由人类专家评估完成质量。

建议为每个任务编写结构化的判定标准：

任务 ID: T001
任务描述: 查询最近30天电子产品的销售额，按周排序
判定标准:
  - 必须包含4个周的数据点
  - 每个数据点必须有周标签和销售额数值
  - 销售额数值与数据库查询结果的误差 < 1%
  - 按时间顺序排列
判定方式: 精确匹配 + 数值校验

四、自动化评测框架与实现

4.1 评测流水线架构

一套完整的自动化评测流水线包含以下组件：

任务加载器 → 任务执行器 → 结果采集器 → 自动判定器 → 报告生成器
     ↓             ↓             ↓             ↓             ↓
  任务集JSON    Agent运行环境  执行轨迹日志  判定标准引擎  指标统计可视化

各组件职责：

• 任务加载器：从任务集文件中读取任务，按配置筛选和分组
• 任务执行器：调用 Agent 执行每个任务，记录完整的执行轨迹
• 结果采集器：收集 Agent 的最终输出、中间步骤、工具调用、Token 消耗等数据
• 自动判定器：根据每个任务的判定标准，自动判定成功/失败并打分
• 报告生成器：统计各项指标，生成可视化报告和对比分析

4.2 用 LLM-as-Judge 做自动评分

对于开放式任务，LLM-as-Judge 是目前最实用的自动评分方法。基本思路是：用一个能力较强的 LLM（如 GPT-4 或 Claude）作为评委，给它任务描述、Agent 的输出、评分标准，让它打分。

评分提示词模板：

你是一个严格的评测专家。请评估以下 Agent 任务的完成质量。

【任务描述】
{task_description}

【Agent 输出】
{agent_output}

【评分标准】
1. 目标达成度（0-4分）：是否完成了任务的核心目标
2. 信息完整性（0-3分）：是否包含了所有必要的信息
3. 准确性（0-3分）：事实和数据是否准确
4. 条理性（0-2分）：输出是否结构清晰、易于理解
5. 额外问题（扣分项）：是否有幻觉、错误信息、安全问题

【输出格式】
请严格按以下 JSON 格式输出，不要有其他文字：
{
  "scores": {
    "goal_achievement": <分数>,
    "completeness": <分数>,
    "accuracy": <分数>,
    "organization": <分数>
  },
  "deductions": ["扣分项描述，没有则为空数组"],
  "total_score": <总分>,
  "pass": <true或false，总分>=10为通过>,
  "reason": "简短的评分理由"
}

使用 LLM-as-Judge 时需要注意： – 评委模型的能力要显著高于被评测模型，否则评分不可靠 – 多次运行取平均值，减少评分随机性 – 定期用人工评估结果校准评委模型的评分偏差 – 对于安全相关的任务，不要完全依赖自动评分

4.3 代码示例：自动化评测脚本

以下是一个简化的自动化评测脚本，展示核心流程：

import json
import time
from dataclasses import dataclass, asdict
from typing import List, Dict, Any

@dataclass
class TaskResult:
    task_id: str
    success: bool
    score: float
    steps: int
    tool_calls: int
    input_tokens: int
    output_tokens: int
    duration_seconds: float
    error: str = ""
    trajectory: List[Dict] = None

def run_task(agent, task: Dict) -> TaskResult:
    """执行单个评测任务"""
    start_time = time.time()

    try:
        # 重置 Agent 状态
        agent.reset()

        # 执行任务
        result = agent.run(task["description"])

        duration = time.time() - start_time

        # 自动判定
        success, score = judge_result(task, result)

        return TaskResult(
            task_id=task["id"],
            success=success,
            score=score,
            steps=result.get("steps", 0),
            tool_calls=result.get("tool_calls", 0),
            input_tokens=result.get("input_tokens", 0),
            output_tokens=result.get("output_tokens", 0),
            duration_seconds=duration,
            trajectory=result.get("trajectory", []),
        )

    except Exception as e:
        duration = time.time() - start_time
        return TaskResult(
            task_id=task["id"],
            success=False,
            score=0,
            steps=0,
            tool_calls=0,
            input_tokens=0,
            output_tokens=0,
            duration_seconds=duration,
            error=str(e),
        )

def judge_result(task: Dict, result: Dict) -> tuple:
    """根据任务判定标准判定结果"""
    judge_type = task.get("judge_type", "exact")

    if judge_type == "exact":
        # 精确匹配
        expected = task["expected_output"]
        actual = result.get("output", "")
        success = expected.strip() == actual.strip()
        score = 1.0 if success else 0.0

    elif judge_type == "contains":
        # 包含匹配
        keywords = task["expected_keywords"]
        actual = result.get("output", "")
        matched = sum(1 for kw in keywords if kw in actual)
        success = matched == len(keywords)
        score = matched / len(keywords)

    elif judge_type == "llm_judge":
        # LLM-as-Judge
        score, success = llm_judge(task, result)

    else:
        success = False
        score = 0.0

    return success, score

def evaluate(agent, tasks: List[Dict]) -> Dict:
    """运行完整评测，返回统计结果"""
    results = []

    for task in tasks:
        print(f"执行任务 {task['id']}: {task['description'][:50]}...")
        result = run_task(agent, task)
        results.append(result)
        print(f"  结果: {'成功' if result.success else '失败'}, "
              f"分数: {result.score:.2f}, "
              f"步数: {result.steps}, "
              f"耗时: {result.duration_seconds:.1f}s")

    # 统计指标
    total = len(results)
    success_count = sum(1 for r in results if r.success)
    avg_score = sum(r.score for r in results) / total if total > 0 else 0
    avg_steps = sum(r.steps for r in results) / total if total > 0 else 0
    avg_duration = sum(r.duration_seconds for r in results) / total if total > 0 else 0
    total_input_tokens = sum(r.input_tokens for r in results)
    total_output_tokens = sum(r.output_tokens for r in results)

    # 按任务类型分组统计
    by_type = {}
    for task, result in zip(tasks, results):
        task_type = task.get("type", "unknown")
        if task_type not in by_type:
            by_type[task_type] = {"total": 0, "success": 0}
        by_type[task_type]["total"] += 1
        if result.success:
            by_type[task_type]["success"] += 1

    for task_type in by_type:
        t = by_type[task_type]
        t["success_rate"] = t["success"] / t["total"] if t["total"] > 0 else 0

    return {
        "summary": {
            "total_tasks": total,
            "success_count": success_count,
            "success_rate": success_count / total if total > 0 else 0,
            "avg_score": avg_score,
            "avg_steps": avg_steps,
            "avg_duration_seconds": avg_duration,
            "total_input_tokens": total_input_tokens,
            "total_output_tokens": total_output_tokens,
        },
        "by_type": by_type,
        "results": [asdict(r) for r in results],
    }

if __name__ == "__main__":
    # 加载任务集
    with open("eval_tasks.json", "r") as f:
        tasks = json.load(f)

    # 初始化 Agent
    agent = MyAgent()

    # 运行评测
    report = evaluate(agent, tasks)

    # 保存报告
    with open("eval_report.json", "w") as f:
        json.dump(report, f, ensure_ascii=False, indent=2)

    # 打印摘要
    print("\n" + "=" * 60)
    print("评测报告摘要")
    print("=" * 60)
    print(f"任务总数: {report['summary']['total_tasks']}")
    print(f"成功数: {report['summary']['success_count']}")
    print(f"完成率: {report['summary']['success_rate']:.1%}")
    print(f"平均分数: {report['summary']['avg_score']:.2f}")
    print(f"平均步数: {report['summary']['avg_steps']:.1f}")
    print(f"平均耗时: {report['summary']['avg_duration_seconds']:.1f}s")
    print(f"总Token消耗: {report['summary']['total_input_tokens'] + report['summary']['total_output_tokens']}")
    print("=" * 60)

4.4 评测结果的统计与可视化

评测不只是跑一遍得到一个完成率数字，更重要的是从结果中发现问题、指导改进。建议从以下角度分析评测结果：

按任务类型分析：哪类任务完成率最低？是工具调用问题还是规划问题？

按失败原因分析：对失败任务进行归类，统计各类失败的占比。常见失败原因包括： – 工具参数错误 – 工具选择错误 – 规划不完整 – 上下文信息丢失 – 异常处理失败 – 输出格式错误

按步骤分析：统计每一步的失败率，找出最容易出错的步骤。

版本对比：对比不同版本 Agent 的评测结果，看哪些指标提升了、哪些退化了。

建议用可视化图表展示这些分析： – 完成率趋势图（按版本） – 失败原因饼图 – 任务类型完成率柱状图 – 步骤失败率热力图

五、人工评估与专家评审

5.1 什么时候需要人工评估

自动评测效率高、成本低，但不能完全替代人工评估。以下场景必须有人工评估：

• 新任务类型首次评测：自动判定标准还不成熟，需要人工建立基准
• 开放式、主观性强的任务：如报告撰写、创意生成，质量好坏难以用规则判定
• 安全相关的任务：涉及安全、合规、隐私的任务，必须人工审核
• 自动评分存疑的任务：LLM-as-Judge 评分与预期不符时，需要人工复核
• 上线前的最终验收：重要版本上线前，需要人工全面评估

建议采用”自动评测为主、人工评估为辅”的策略：日常迭代用自动评测快速反馈，关键节点用人工评估确保质量。

5.2 评估维度与评分标准

人工评估需要有明确的评分标准，避免不同评估人员的标准不一致。建议使用结构化的评分表：

每个维度按 1-4 分打分，加权计算总分。安全合规维度实行一票否决：如果有安全漏洞，整体评估不通过。

5.3 多人评估与一致性检验

对于重要的评测，建议由多个人独立评估，然后取平均值。这可以减少个人偏好带来的偏差。

多人评估时需要检验评估者之间的一致性。常用指标是 Cohen’s Kappa 系数：

Kappa = (实际一致率 - 随机一致率) / (1 - 随机一致率)

Kappa 值的解读： – < 0：一致性极差 – 0-0.2：轻微一致 – 0.2-0.4：一般一致 – 0.4-0.6：中等一致 – 0.6-0.8：高度一致 – 0.8-1.0：几乎完全一致

如果 Kappa 值低于 0.4，说明评分标准不够清晰，需要修订标准并重新培训评估人员。

5.4 评估流程与质量控制

一套规范的人工评估流程包括：

1. 评估准备：准备评估任务集、评分标准、评估工具
2. 评估培训：对评估人员进行培训，统一评分标准，用 3-5 个样例任务进行试评
3. 正式评估：评估人员独立打分，记录评分理由
4. 一致性检验：计算评估者间的 Kappa 值
5. 争议仲裁：对评分差异大的任务，由高级评估者仲裁
6. 结果汇总：统计各项指标，生成评估报告
7. 反馈改进：将评估结果反馈给开发团队，指导后续改进

质量控制要点： – 每个评估人员的评估量不要超过每天 50 个任务，避免疲劳导致质量下降 – 随机插入 5-10% 的”校准任务”（已知标准答案的任务），监控评估人员的准确性 – 评估人员之间互相不知道对方的评分，避免互相影响 – 评估过程中如果发现评分标准有歧义，及时记录并修订

六、生产环境的在线监控

6.1 关键指标监控体系

评测环境的表现好不代表生产环境一定好。生产环境有真实用户、真实数据、真实网络波动，需要建立在线监控体系。

核心监控指标分为四类：

业务指标： – 日活跃任务数 – 任务完成率（生产环境真实数据） – 用户满意度（点赞/点踩比例） – 人工介入率（需要人工接管的任务比例）

性能指标： – 平均响应时间 – P50/P95/P99 延迟 – 任务成功率 – 工具调用成功率

成本指标： – 日均 Token 消耗 – 日均 API 费用 – 单任务平均成本 – 成本趋势

安全指标： – 安全事件数 – 越权操作拦截数 – 敏感信息泄露告警数 – 注入攻击检测数

建议为每类指标设置基线和告警阈值。例如：任务完成率低于 80% 触发告警，P95 延迟超过 30 秒触发告警。

6.2 异常检测与告警

静态阈值告警简单有效，但不够灵敏。更先进的方法是异常检测：基于历史数据建立正常模式，当实时数据偏离正常模式时触发告警。

常用的异常检测方法：

• 统计方法：基于均值和标准差，超过 3 个标准差视为异常
• 同比环比：与上周同期、昨日同期对比，偏差超过阈值告警
• 趋势检测：检测指标是否在持续恶化（如完成率连续 3 天下降）
• 相关性分析：多个指标同时异常时，可能是系统性问题

告警分级：

避免告警疲劳：合理设置阈值，合并相关告警，自动恢复后发送恢复通知。

6.3 用户反馈收集与分析

用户反馈是最直接的质量信号。建立多渠道的用户反馈收集机制：

• 显式反馈：点赞/点踩按钮、评分、评论、举报
• 隐式反馈：任务完成后用户是否继续使用、是否重复执行同一任务、是否中途放弃
• 主动收集：定期用户调研、满意度问卷、用户访谈

对用户反馈进行分析： – 按任务类型分类，看哪类任务用户满意度最低 – 对负面反馈进行根因分析，归类为：功能问题、性能问题、准确性问题、体验问题 – 提取高频关键词，发现用户最关心的问题 – 跟踪反馈趋势，看改进措施是否有效

建议每周生成一份用户反馈分析报告，作为产品迭代的重要输入。

6.4 A/B 测试与灰度发布

新版本上线前，不要直接全量发布。用 A/B 测试和灰度发布来验证新版本的效果。

A/B 测试： – 将用户随机分为两组：对照组（旧版本）和实验组（新版本） – 两组用户同时使用，对比核心指标 – 统计显著性检验，确保差异不是随机波动 – 实验周期通常 1-2 周，确保覆盖不同时间段的用户行为

灰度发布： – 先给 1% 的用户使用新版本 – 观察核心指标和错误率，无异常则逐步扩大到 5%、10%、50% – 任何阶段出现问题，立即回滚 – 全量发布前，确保新版本在各指标上不劣于旧版本

A/B 测试的核心指标应该提前确定，不要在测试过程中随意更改。同时要注意：如果新版本有多个变更，A/B 测试只能告诉你整体效果，无法区分每个变更的单独影响。

七、回归测试与持续质量保障

7.1 回归测试集的构建与维护

每次修改 Agent 的代码、提示词、模型版本后，都可能引入新的问题。回归测试的目的是确保修改不会破坏已经正常工作的功能。

回归测试集的构建原则：

• 覆盖核心场景：包含所有主要任务类型和关键用户路径
• 包含历史失败案例：把曾经出过问题的任务加入回归集，确保不再复发
• 包含边界情况：异常输入、工具失败、长上下文等边界场景
• 定期更新：每发现一个新的 bug，就把对应的测试用例加入回归集

回归测试集的规模建议： – 核心回归集：50-100 个任务，每次提交都跑，5-10 分钟完成 – 完整回归集：200-500 个任务，每天夜间跑，1-2 小时完成 – 全量评测集：1000+ 个任务，每周或每个版本跑一次

维护回归测试集需要注意：定期清理过时的任务，补充新场景的任务，确保测试集与业务实际保持一致。

7.2 CI/CD 中的自动化评测

把自动化评测集成到 CI/CD 流水线中，实现”每次提交自动评测、不达标不合并”。

CI/CD 流水线的典型阶段：

代码提交 → 单元测试 → 核心回归评测 → 代码审查 → 合并 → 完整回归评测 → 灰度发布

各阶段的评测要求：

• 单元测试：测试工具函数、数据处理逻辑等，要求 100% 通过
• 核心回归评测：跑 50-100 个核心任务，要求完成率不低于基线的 95%，无 P0 级失败
• 完整回归评测：合并后夜间跑 200-500 个任务，生成详细报告
• 发布前验收：灰度发布前，跑全量评测集，人工审核关键指标

在 CI/CD 中设置质量门（Quality Gate）： – 完成率低于阈值 → 阻止合并 – 出现安全相关失败 → 阻止合并 – 平均成本上升超过 20% → 需要人工审批 – 核心任务失败 → 阻止合并

7.3 版本对比与退化检测

每次发布新版本后，与上一个稳定版本进行对比，检测是否有退化。

版本对比报告应包含：

退化检测的重点： – 哪些任务类型的完成率下降了？ – 失败任务的失败原因是否有新模式？ – 有没有之前成功的任务现在失败了？（精确回归） – 成本和延迟是否在可接受范围内？

建议建立版本对比的自动化报告，每次发布后自动生成，发送给开发团队。

7.4 持续改进闭环

评测和监控的最终目的是持续改进。建立一个”发现问题 → 分析根因 → 修复改进 → 验证效果”的闭环：

1. 发现问题：从评测失败、监控告警、用户反馈中发现问题
2. 分析根因：查看执行轨迹，定位是哪一步出了问题，根因是什么（提示词问题、工具问题、模型能力问题、数据问题）
3. 修复改进：针对性修复，可能是修改提示词、优化工具接口、增加异常处理、调整模型参数
4. 验证效果：把修复后的版本跑评测集，确认问题解决且没有引入新问题
5. 沉淀经验：把问题和解决方案记录下来，把测试用例加入回归集

每周召开一次质量复盘会议： – 回顾本周的评测结果和监控数据 – 分析 Top 3 质量问题的根因和改进计划 – 跟踪上周改进措施的效果 – 确定下周的质量目标

用数据驱动改进，而不是凭感觉调参。每次改进都要有评测数据证明效果。

八、上线前检查清单

发布新版本前，逐项确认以下检查清单：

评测验证

• [ ] 核心回归测试集 100% 通过，无 P0 级失败
• [ ] 整体任务完成率不低于上一版本的 95%
• [ ] 各难度等级任务完成率无显著下降（>5%）
• [ ] 工具调用正确率不低于上一版本
• [ ] 新增功能有对应的评测任务覆盖
• [ ] 历史 bug 对应的回归用例全部通过

性能与成本

• [ ] 平均响应时间不超过上一版本的 120%
• [ ] P95 延迟在可接受范围内（< 30 秒）
• [ ] 单任务平均 Token 消耗增幅不超过 20%
• [ ] 高并发场景下无明显性能退化
• [ ] 工具调用失败率 < 5%

安全与合规

• [ ] 安全红队测试集全部通过，无安全漏洞
• [ ] 无越权操作、无敏感信息泄露
• [ ] 提示注入攻击测试通过
• [ ] 数据处理符合隐私政策和法规要求
• [ ] 操作日志完整可审计

监控与告警

• [ ] 核心指标监控已配置，基线已更新
• [ ] 告警阈值已设置，告警通道已验证
• [ ] 仪表盘已更新，能实时查看新版本指标
• [ ] 回滚方案已准备，回滚操作已演练
• [ ] 值班人员已通知，应急预案已确认

发布策略

• [ ] 灰度发布计划已制定（1% → 5% → 20% → 50% → 100%）
• [ ] A/B 测试方案已设计，核心对比指标已确定
• [ ] 发布时间已选择低峰期
• [ ] 用户公告已准备（如有重大变更）
• [ ] 发布后验证清单已准备

结语

AI Agent 的评测与质量保障是一个系统工程，不是写几个测试用例就能解决的。你需要从评测维度、任务集设计、自动化框架、人工评估、在线监控、回归测试六个层面，构建一套覆盖开发到生产全流程的质量保障体系。

核心原则有三条：第一，用数据说话，每次改进都要有评测数据证明效果，不要凭感觉调参；第二，建立闭环，从发现问题到修复验证再到沉淀经验，让质量持续提升；第三，平衡成本与质量，追求 100% 完美的成本可能极高，找到适合业务场景的质量平衡点才是关键。

至此，AI Agent 工程化实践系列已经覆盖了从提示词工程、Function Calling、任务规划、长期记忆、多智能体协作到评测质量保障的完整链路。下一篇可以继续讨论 AI Agent 的部署与运维：从模型服务化、Agent 运行时架构、弹性扩缩容、成本优化到可观测性，探讨如何把一个 Agent 系统稳定、高效、低成本地运行在生产环境中。