# 本章小结

本章阐述了智能体系统的多层级评估方法，以下是核心要点的总结。

## 核心要点回顾

### 1. 评估的三层级架构

智能体系统的评估需要从 **步骤、轨迹、任务** 三个层级进行：

* **步骤级**：单个工具调用的准确性（工具选择、参数正确性、执行成功性）
* **轨迹级**：工具调用序列的效率（最优性比、错误恢复率、重复率）
* **任务级**：最终目标达成（成功率、执行时间、Token效率、成本）

三者环环相扣，步骤级的准确性支撑轨迹级的效率，轨迹级的优化保证任务级的成功。

### 2. Mock vs 真实测试的取舍

* **Mock测试**：快速、确定性强、易隔离问题，适合开发迭代
* **真实测试**：真实度高、能发现Mock无法发现的问题，适合验收阶段

**最佳实践**：开发期用Mock确保快速反馈，发布前用真实测试验证。

### 3. 基准测试的标准化

四大学术基准各有侧重：

| 基准         | 焦点      | 任务数  | 难度         |
| ---------- | ------- | ---- | ---------- |
| GAIA       | 推理+工具使用 | 466  | 三级         |
| WebArena   | 网页自动化   | 812  | 真实网站       |
| SWE-Bench  | 代码修改    | 2294 | 真实GitHub问题 |
| AgentBench | 多领域综合   | 1447 | 工作场景模拟     |

在自有系统上复现这些基准，能客观评估智能体能力。NIST 2026标准化倡议将进一步统一评估方法。

### 4. 生产环境的持续监控

三个维度的实时监控：

**质量指标**：成功率、错误恢复率、执行时间 **异常检测**：Z-score等统计方法自动识别性能下滑 **A/B测试**：科学验证系统改进是否显著优于基线

配合Langfuse/Prometheus等工具，实现完整的可观测性。

### 5. 完整测试套件

MiniHarness的四层测试确保全面覆盖：

1. **单元测试**：路径校验、命令检测等模块单独验证
2. **集成测试**：权限流程、护栏集成等模块间协作验证
3. **端到端测试**：完整工作流验证
4. **性能基准**：延迟、吞吐量等性能指标验证

## 评估框架选择指南

根据项目阶段选择合适的评估方法：

```mermaid
flowchart LR
    A["开发期"] --> B["迭代期"]
    B --> C["验收期"]
    C --> D["生产期"]

    A --> A1["Mock测试"]
    A --> A2["单元测试"]
    A --> A3["回归基线"]

    B --> B1["E2E测试"]
    B --> B2["性能测试"]
    B --> B3["回归检查"]

    C --> C1["基准测试"]
    C --> C2["用户测试"]
    C --> C3["A/B测试"]

    D --> D1["持续监控"]
    D --> D2["异常检测"]
    D --> D3["成本分析"]

    style A fill:#fff9c4
    style B fill:#c8e6c9
    style C fill:#bbdefb
    style D fill:#f8bbd0
```

## 常见评估误区

### 误区1：只看任务成功率

**问题**：成功率高但单个任务消耗大量Token，成本难以承受。 **正确做法**：平衡成功率、效率、成本的加权评分。

### 误区2：用人工评分代替自动化

**问题**：不可扩展，主观性强，难以持续监控。 **正确做法**：优先建立自动化指标，人工评分仅用于难以自动化的维度。

### 误区3：忽视生产与开发的差异

**问题**：开发期性能好，上线后性能下降（冷启动、真实流量等）。 **正确做法**：生产环境需专门的监控和告警机制。

### 误区4：基准测试过度参考

**问题**：优化以适应基准，但在真实场景表现不佳（对标优化）。 **正确做法**：基准用于建立基线，但要结合业务KPI调整权重。

## 评估成本考虑

| 评估方法    | 成本 | 时间      | 精度 |
| ------- | -- | ------- | -- |
| Mock测试  | 低  | 快（秒）    | 中  |
| E2E测试   | 中  | 中（分钟）   | 高  |
| 真实API调用 | 高  | 慢（秒/调用） | 最高 |
| 基准测试    | 中  | 中（小时）   | 高  |
| 持续监控    | 中  | 实时      | 高  |

**成本优化**：结合Mock和采样真实调用，控制整体成本。

## 与AI研究的联系

学术研究与工程实践的反馈循环：

```mermaid
flowchart TD
    A["<b>研究提出新基准</b><br/>GAIA, WebArena"] --> B["<b>工程采用评估</b><br/>复现基准"]
    B --> C["<b>发现系统弱点</b><br/>分析失败案例"]
    C --> D["改进算法或框架"]
    D --> E["重新评估性能"]
    E --> F["发表结果,推动学术进展"]
    F -->|新一轮| A

    style A fill:#e3f2fd
    style C fill:#ffebee
    style D fill:#e8f5e9
    style F fill:#f3e5f5
```

本章的评估方法论正是这个循环的工程侧面。

## 生产就绪检查清单

部署前确保：

* [ ] 建立了三层级评估指标体系
* [ ] 准备了Mock和真实两套测试用例
* [ ] 在至少一个学术基准上验证了性能基线
* [ ] 实现了实时监控和异常告警
* [ ] 设计了A/B测试框架用于验证改进
* [ ] 测试覆盖率≥80%
* [ ] 有专门的性能基准跟踪
* [ ] 建立了用户反馈收集机制
* [ ] 准备好了性能退化的应急响应
* [ ] 定期进行评估和优化周期

***

**完成第13章意味着掌握了“如何衡量好坏”的系统方法。下一章展望Harness工程的未来方向——从今天的工程实践走向明天的范式创新。**


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/harness_engineering_guide/di-si-bu-fen-an-quan-ping-gu-yu-yan-jin/13_evaluation/summary.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.