13 | 评估与可观测性：怎么知道Agent"好不好"？
June 29, 202612 min read
Agent
13 | 评估与可观测性：怎么知道Agent"好不好"？
核心问题：Agent的输出不确定，怎么系统性地评估？线上出了问题怎么排查？
一个真实的线上事故
2024年3月，某电商平台的客服Agent上线。测试阶段一切正常：回答准确、工具调用正确、用户满意度92%。上线第一天，灾难来了。
用户：我想退这件衣服，订单号 20240315-7821
Agent：好的，我来帮您处理退货。
[调用 cancel_order 工具，参数 order_id="20240315-7821"]
⚠️ 执行了取消订单操作（而非退货）
用户：？？？我只是要退货，不是取消订单！
问题复盘：
- 测试集里"退货"和"取消"的样本比例是 1:1，Agent学会了区分
- 线上真实数据中，"退货"出现的频率远高于"取消"，但用户表述模糊
- Agent在边界case上把"退货"误分类为"取消订单"操作
- 更糟的是：没有人在监控这个Agent的实时行为
这个事故暴露了Agent开发中最核心的难题：你怎么知道Agent"好不好"？测试通过了就够了吗？上线之后怎么知道它没在"犯错"？
这不是个例。根据LangChain 2024年的调查，超过67%的Agent项目在上线后遇到了"测试时没发现"的问题。根本原因在于——Agent的行为空间远大于传统软件，我们需要一套全新的评估和可观测性体系。
┌─────────────────────────────────────────────────────────┐
│ Agent 评估的三层挑战 │
├─────────────────────────────────────────────────────────┤
│ │
│ 第一层：结果对不对？（Task Success） │
│ ├── 最终答案是否正确 │
│ ├── 是否完成了用户的目标 │
│ └── 答案质量如何（完整性、准确性） │
│ │
│ 第二层：过程好不好？（Trajectory Quality） │
│ ├── 步骤是否合理 │
│ ├── 工具调用是否恰当 │
│ └── 有没有走弯路 │
│ │
│ 第三层：值不值得？（Cost Efficiency） │
│ ├── 花了多少token │
│ ├── 调用了多少次LLM │
│ └── 延迟是否在可接受范围 │
│ │
└─────────────────────────────────────────────────────────┘
一、Agent评估框架：三个维度看Agent
1.1 任务成功率（Task Success Rate）
最基础的指标：Agent有没有完成任务？
┌──────────────────────────────────────────────────────────┐
│ 任务成功率的评估方式 │
├──────────────────────────────────────────────────────────┤
│ │
│ 精确匹配（Exact Match） │
│ ├── 答案必须完全一致 │
│ ├── 适用：数学题、代码生成、分类任务 │
│ └── 局限：太严格，不接受等价表述 │
│ │
│ 模糊匹配（Fuzzy Match） │
│ ├── 允许一定程度的差异 │
│ ├── 适用：摘要、翻译、信息抽取 │
│ └── 方法：ROUGE、BLEU、BERTScore │
│ │
│ LLM-as-Judge │
│ ├── 用另一个LLM来判断答案质量 │
│ ├── 适用：开放式问答、创意写作 │
│ └── 注意：评判LLM本身的偏差 │
│ │
│ 人工评估 │
│ ├── 最可靠但最昂贵 │
│ ├── 适用：高风险场景、关键指标校准 │
│ └── 方法：A/B比较、Likert量表 │
│ │
└──────────────────────────────────────────────────────────┘
关键洞察：对于Agent来说，"任务成功"往往不是二元的。一个Agent可能完成了80%的目标，但用了3倍的成本——这算成功还是失败？我们需要更细致的评估维度。
1.2 轨迹质量（Trajectory Quality）
Agent的行为是一个序列（trajectory），我们不仅要看结果，还要看过程。
好的轨迹：
用户：帮我查一下明天北京的天气
Agent：[call: weather_api(city="北京", date="tomorrow")]
→ 结果：晴，25°C
Agent：明天北京天气晴朗，气温25°C，适合出行。
步骤数：1 | 工具调用：1次 | Token：~150
差的轨迹：
用户：帮我查一下明天北京的天气
Agent：[call: search(query="北京天气")]
→ 结果：一堆网页链接
Agent：[call: search(query="明天北京天气预报")]
→ 结果：更多网页链接
Agent：[call: weather_api(city="Beijing", date="2024-03-16")]
→ 结果：晴，25°C
Agent：明天北京天气晴朗，气温25°C。
步骤数：3 | 工具调用：3次 | Token：~800
轨迹质量的评估维度：
| 维度 | 定义 | 计算方式 | |------|------|----------| | 步骤效率 | 完成任务所需的最少步骤 | 实际步骤 / 最优步骤 | | 工具准确性 | 是否选对了工具 | 正确调用 / 总调用 | | 参数正确性 | 工具参数是否正确 | 正确参数 / 总参数 | | 冗余度 | 是否有无效或重复操作 | 冗余步骤 / 总步骤 | | 回溯率 | 是否走了弯路又折返 | 回溯次数 / 总步骤 |
1.3 成本效率（Cost Efficiency）
在生产环境中，成本是硬约束。
┌─────────────────────────────────────────────────────────┐
│ 成本效率的核心指标 │
├─────────────────────────────────────────────────────────┤
│ │
│ Token成本 │
│ ├── Input tokens × 单价 │
│ ├── Output tokens × 单价 │
│ └── 总成本 = Σ(每次LLM调用的成本) │
│ │
│ 延迟（Latency） │
│ ├── 首token延迟（TTFT） │
│ ├── 总响应时间（E2E） │
│ └── 各步骤耗时分布 │
│ │
│ 性价比 │
│ ├── 每成功任务的平均成本 │
│ ├── 质量/成本 比值 │
│ └── 与基线方案的成本对比 │
│ │
└─────────────────────────────────────────────────────────┘
一个真实的成本分析案例：
任务：从PDF发票中提取关键信息
方案A：直接丢给GPT-4
- 每次调用：~4000 tokens（含PDF转文本）
- 成功率：85%
- 单次成本：$0.12
- 每成功任务成本：$0.14
方案B：先用小模型提取，再用GPT-4校验
- 第一次调用（GPT-3.5）：~4000 tokens，$0.008
- 第二次调用（GPT-4校验）：~500 tokens，$0.015
- 成功率：92%
- 每成功任务成本：$0.025
方案B的成功率更高，成本反而低了5倍。
这就是评估驱动优化的价值。
二、Benchmark Suites：站在巨人肩膀上评估
2.1 主流Agent Benchmark一览
┌─────────────────────────────────────────────────────────────────┐
│ Agent Benchmark 全景图 │
├─────────────┬───────────────┬───────────────────────────────────┤
│ Benchmark │ 评估维度 │ 核心特点 │
├─────────────┼───────────────┼───────────────────────────────────┤
│ GAIA │ 通用AI助手 │ 466个问题，需多步推理+工具使用 │
│ │ │ 强调"人类能解但AI难解"的任务 │
├─────────────┼───────────────┼───────────────────────────────────┤
│ SWE-bench │ 代码修复 │ 真实GitHub issue + PR │
│ │ │ 评估Agent能否独立修bug │
├─────────────┼───────────────┼───────────────────────────────────┤
│ WebArena │ 网页操作 │ 自包含的网页环境 │
│ │ │ 评估Agent能否完成真实网站任务 │
├─────────────┼───────────────┼───────────────────────────────────┤
│ AgentBench │ 综合评估 │ 8个不同环境的统一框架 │
│ │ │ OS/DB/KG/Web/游戏等 │
├─────────────┼───────────────┼───────────────────────────────────┤
│ ToolBench │ 工具使用 │ 16000+真实API │
│ │ │ 评估工具选择和组合能力 │
├─────────────┼───────────────┼───────────────────────────────────┤
│ τ-bench │ 客服场景 │ 真实客服对话模拟 │
│ │ │ 评估策略性对话能力 │
└─────────────┴───────────────┴───────────────────────────────────┘
2.2 GAIA：通用AI助手的"高考"
GAIA（General AI Assistants）由Meta提出，核心理念是：如果一个问题普通人能在30分钟内解决，AI也应该能做到。
GAIA 题目示例：
问题：在2023年世界田径锦标赛上，获得男子100米金牌的选手，
他的出生城市在2023年的人口是多少？
解题轨迹：
1. [搜索] 2023世界田径锦标赛男子100米金牌 → Noah Lyles
2. [搜索] Noah Lyles 出生城市 → Gainesville, Florida
3. [搜索] Gainesville, Florida 2023年人口 → 141,967
4. [回答] 141,967
关键：需要多步推理 + 工具使用 + 信息整合
GAIA的三级难度：
| 级别 | 特征 | 所需步骤 | GPT-4通过率 | |------|------|----------|-------------| | Level 1 | 简单多步 | 2-3步 | ~75% | | Level 2 | 中等复杂 | 3-5步 | ~55% | | Level 3 | 高度复杂 | 5+步 | ~30% |
2.3 SWE-bench：代码Agent的试金石
SWE-bench从真实GitHub仓库中收集issue和对应的PR，评估Agent能否独立完成代码修复。
SWE-bench 工作流程：
1. 给定一个真实的GitHub Issue
例："pandas read_csv 在处理空文件时抛出未捕获的异常"
2. Agent需要：
├── 理解issue描述
├── 在代码库中定位相关文件
├── 理解现有代码逻辑
├── 编写修复代码
└── 确保通过原有测试
3. 评估：运行PR中的测试用例
├── PASS_TO_PASS：原有通过的测试仍然通过
└── FAIL_TO_PASS：原有失败的测试现在通过
SWE-bench的关键数据（截至2024年底）：
模型/系统 Resolve Rate 备注
───────────────────────────────────────────────
SWE-agent + GPT-4 12.5% 早期系统
AutoCodeRover 14.3% 结合程序分析
OpenDevin 16.8% 开源Agent框架
Devin 13.8% 商业系统
Claude 3.5 + Agent 49.0% 2024年最佳
Human (Senior Dev) ~95% 参考基线
2.4 WebArena：网页操作的真实考场
WebArena构建了一个自包含的网页环境（包含电商、论坛、GitLab、地图等），评估Agent能否完成真实的网页操作任务。
WebArena 任务示例：
"在Amazon-like网站上，找到评分最高的无线耳机，
把它加入购物车，然后用信用卡 ****1234 结账，
寄到 123 Main St, Springfield"
Agent需要：
├── 打开网站并登录
├── 搜索"wireless earbuds"
├── 按评分排序
├── 选择评分最高的商品
├── 加入购物车
├── 进入结算页面
├── 填写收货地址
├── 填写支付信息
└── 确认订单
评估：最终状态检查（购物车内容、订单是否创建）
2.5 如何选择Benchmark？
你的Agent类型 推荐Benchmark 关注指标
─────────────────────────────────────────────────────────────
通用问答助手 GAIA 三级通过率
代码开发Agent SWE-bench Resolve Rate
网页操作Agent WebArena Task Success
多场景Agent AgentBench 各场景分数
工具调用密集型 ToolBench Pass Rate
客服/对话Agent τ-bench Policy Adherence
重要提醒：Benchmark分数不等于实际效果。一个在SWE-bench上得分很高的Agent，在你的代码库上可能表现很差。Benchmark是起点，不是终点。
三、Trace分析：深入Agent的"大脑"
3.1 什么是Agent Trace？
Agent的每次执行都会产生一条trace（轨迹），记录了Agent的完整思考过程。
一条完整的Agent Trace：
{
"trace_id": "tr_abc123",
"task": "帮我查一下明天北京的天气并订一个餐厅",
"steps": [
{
"step_id": 1,
"type": "llm_call",
"model": "gpt-4",
"input_tokens": 250,
"output_tokens": 80,
"latency_ms": 1200,
"thought": "用户需要两个信息：天气和餐厅。我先查天气。",
"action": {
"tool": "weather_api",
"params": {"city": "北京", "date": "tomorrow"}
}
},
{
"step_id": 2,
"type": "tool_result",
"tool": "weather_api",
"result": {"temp": 25, "condition": "晴"},
"latency_ms": 300
},
{
"step_id": 3,
"type": "llm_call",
"model": "gpt-4",
"input_tokens": 380,
"output_tokens": 90,
"latency_ms": 1500,
"thought": "天气查到了，现在找餐厅。天气好，推荐户外餐厅。",
"action": {
"tool": "restaurant_search",
"params": {"city": "北京", "type": "户外", "date": "tomorrow"}
}
},
{
"step_id": 4,
"type": "tool_result",
"tool": "restaurant_search",
"result": [{"name": "翠园", "rating": 4.8}, ...],
"latency_ms": 450
},
{
"step_id": 5,
"type": "llm_call",
"model": "gpt-4",
"input_tokens": 520,
"output_tokens": 150,
"latency_ms": 2000,
"thought": "信息齐了，给用户汇总。",
"action": {"type": "final_answer"}
}
],
"summary": {
"total_steps": 5,
"llm_calls": 3,
"tool_calls": 2,
"total_tokens": 1370,
"total_cost_usd": 0.042,
"total_latency_ms": 5450
}
}
3.2 Trace分析的四个维度
┌─────────────────────────────────────────────────────────────┐
│ Trace 分析的四个维度 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ① LLM调用分析 │
│ ├── 每次调用的token数 │
│ ├── 思考过程的质量 │
│ ├── 模型选择的合理性 │
│ └── prompt的构造方式 │
│ │
│ ② 工具调用分析 │
│ ├── 工具选择是否正确 │
│ ├── 参数是否合理 │
│ ├── 调用顺序是否最优 │
│ └── 错误处理和重试策略 │
│ │
│ ③ Token使用分析 │
│ ├── 输入/输出token比例 │
│ ├── 上下文窗口的利用效率 │
│ ├── 是否有冗余信息占用token │
│ └── 成本分布（哪些步骤最贵） │
│ │
│ ④ 延迟分析 │
│ ├── 各步骤耗时分布 │
│ ├── 瓶颈在哪里（LLM？工具？网络？） │
│ ├── 是否有可并行的步骤被串行执行 │
│ └── 用户等待体验 │
│ │
└─────────────────────────────────────────────────────────────┘
3.3 用OpenTelemetry追踪Agent
在生产环境中，推荐使用OpenTelemetry标准来采集Agent trace。
# Agent Trace 的 OpenTelemetry 集成思路
# 每个Agent步骤 = 一个Span
# 整条Trace = 一个Trace
Trace: "task_abc123"
├── Span: "agent.plan" (1200ms)
│ ├── attributes: {model: "gpt-4", tokens: 330}
│ └── events: ["thought: 需要先查天气"]
├── Span: "tool.weather_api" (300ms)
│ ├── attributes: {city: "北京", date: "tomorrow"}
│ └── result: {temp: 25, condition: "晴"}
├── Span: "agent.plan" (1500ms)
│ ├── attributes: {model: "gpt-4", tokens: 470}
│ └── events: ["thought: 现在找餐厅"]
├── Span: "tool.restaurant_search" (450ms)
│ └── ...
└── Span: "agent.finalize" (2000ms)
└── events: ["final_answer generated"]
主流工具链：
| 工具 | 特点 | 适用场景 | |------|------|----------| | LangSmith | LangChain官方，深度集成 | LangChain项目 | | Phoenix (Arize) | 开源，支持OTEL | 通用Agent | | Weights & Biases Traces | 实验管理+追踪 | 研究+生产 | | Helicone | 轻量，API代理模式 | 快速接入 | | Braintrust | 评估+追踪一体 | 评估驱动开发 |
四、失败模式分类：Agent是怎么"犯错"的？
理解Agent的失败模式，才能有针对性地改进。
┌─────────────────────────────────────────────────────────────────┐
│ Agent 失败模式分类体系 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ A. 幻觉类（Hallucination） │
│ ├── A1: 事实性幻觉 - 编造不存在的事实 │
│ ├── A2: 工具幻觉 - 调用不存在的工具 │
│ └── A3: 参数幻觉 - 编造工具参数的值 │
│ │
│ B. 工具使用类（Tool Misuse） │
│ ├── B1: 选错工具 - 应该用A工具却用了B工具 │
│ ├── B2: 参数错误 - 工具选对了但参数不对 │
│ ├── B3: 顺序错误 - 工具调用顺序不合理 │
│ └── B4: 遗漏调用 - 该调工具没调，直接编答案 │
│ │
│ C. 规划类（Planning Failure） │
│ ├── C1: 死循环 - 反复执行相同操作 │
│ ├── C2: 路径偏移 - 偏离原始目标 │
│ ├── C3: 过早停止 - 任务没完成就停了 │
│ └── C4: 过度复杂 - 把简单问题复杂化 │
│ │
│ D. 记忆类（Memory Loss） │
│ ├── D1: 上下文遗忘 - 忘了之前步骤的结果 │
│ ├── D2: 目标遗忘 - 忘了用户最初的需求 │
│ └── D3: 状态混乱 - 混淆了不同步骤的信息 │
│ │
│ E. 安全类（Safety Violation） │
│ ├── E1: 权限越界 - 执行了不该执行的操作 │
│ ├── E2: 信息泄露 - 泄露了敏感信息 │
│ └── E3: 注入攻击 - 被prompt injection攻击 │
│ │
└─────────────────────────────────────────────────────────────────┘
4.1 失败模式的自动检测
# 失败模式自动分类的思路
def classify_failure(trace):
"""根据trace自动分类失败模式"""
failures = []
# 检测幻觉
if trace.has_tool_call_to_nonexistent_tool():
failures.append("A2:工具幻觉")
if trace.has_fabricated_facts():
failures.append("A1:事实性幻觉")
# 检测工具使用问题
if trace.has_wrong_tool_selection():
failures.append("B1:选错工具")
if trace.has_wrong_parameters():
failures.append("B2:参数错误")
# 检测规划问题
if trace.has_repeated_actions(threshold=3):
failures.append("C1:死循环")
if trace.stopped_before_completion():
failures.append("C3:过早停止")
# 检测记忆问题
if trace.ignored_previous_results():
failures.append("D1:上下文遗忘")
return failures
4.2 失败模式的统计数据
根据多个公开报告和我们的实践经验，典型的Agent系统中各失败模式的占比：
失败模式分布（基于500+失败案例分析）：
规划类失败 ████████████████████████████ 35%
├── 死循环 12%
├── 路径偏移 10%
└── 过早停止 13%
工具使用类 ████████████████████ 25%
├── 选错工具 10%
├── 参数错误 9%
└── 遗漏调用 6%
幻觉类 ████████████████ 20%
├── 事实性幻觉 12%
└── 参数幻觉 8%
记忆类 ██████████ 13%
└── 上下文遗忘 13%
安全类 ██████ 7%
└── 权限越界 7%
关键发现：规划类失败是最大的问题来源，而不是大家通常认为的"幻觉"。这提示我们：改进Agent的规划能力，比减少幻觉更能提升整体表现。
五、线上监控：Agent的"心电图"
5.1 监控指标体系
┌────────────────────────────────────────────────────────────────┐
│ Agent 线上监控指标体系 │
├────────────────────────────────────────────────────────────────┤
│ │
│ 第一层：系统指标（System Metrics） │
│ ├── 请求QPS │
│ ├── 响应延迟 P50/P95/P99 │
│ ├── 错误率（HTTP错误、超时、异常） │
│ └── 资源使用（CPU、内存、GPU） │
│ │
│ 第二层：业务指标（Business Metrics） │
│ ├── 任务成功率 │
│ ├── 平均步骤数 │
│ ├── 工具调用成功率 │
│ └── 用户满意度（显式/隐式） │
│ │
│ 第三层：成本指标（Cost Metrics） │
│ ├── 每请求平均token消耗 │
│ ├── 每请求平均成本 │
│ ├── 日/月总成本 │
│ └── 成本趋势（环比、同比） │
│ │
│ 第四层：质量指标（Quality Metrics） │
│ ├── LLM-as-Judge评分 │
│ ├── 幻觉检测率 │
│ ├── 工具误用率 │
│ └── 安全事件数 │
│ │
└────────────────────────────────────────────────────────────────┘
5.2 异常检测策略
异常检测的三种方法：
1. 阈值告警（Threshold Alert）
├── 规则：当指标超过阈值时告警
├── 示例：错误率 > 5% → 告警
├── 优点：简单直接
└── 缺点：阈值难定，容易误报
2. 统计异常（Statistical Anomaly）
├── 规则：当指标偏离历史均值N个标准差时告警
├── 示例：平均步骤数突然从3变成8 → 告警
├── 优点：自适应
└── 缺点：对周期性变化敏感
3. 语义异常（Semantic Anomaly）
├── 规则：用模型判断行为是否"正常"
├── 示例：Agent突然开始调用从未用过的工具组合
├── 优点：能发现深层问题
└── 缺点：计算成本高
5.3 成本告警实战
# 成本告警的实用配置
class CostAlertConfig:
"""成本告警配置"""
# 单请求成本上限
MAX_COST_PER_REQUEST_USD = 0.50
# 每分钟总成本上限
MAX_COST_PER_MINUTE_USD = 10.00
# 每小时总成本上限
MAX_COST_PER_HOUR_USD = 100.00
# 单请求token上限
MAX_TOKENS_PER_REQUEST = 50000
# 单请求LLM调用次数上限
MAX_LLM_CALLS_PER_REQUEST = 20
# 成本环比增长告警阈值
COST_INCREASE_RATIO_ALERT = 2.0 # 环比增长200%告警
一个真实的成本事故：
某团队部署了一个"研究助手"Agent，上线后第一天：
- 平均每个请求花费 $2.3（预期 $0.3）
- 原因：Agent在搜索信息时进入了死循环
- 搜索 → 发现信息不够 → 换个关键词搜索 → 还是不够 → 继续搜...
- 单个请求最多调用了47次搜索API
如果没有成本告警，按这个速率，月成本将达到 $70,000。
有了告警后，15分钟内发现并修复了问题。
5.4 质量退化监控
Agent的质量可能随时间缓慢退化，原因包括：
质量退化的常见原因：
1. 数据漂移（Data Drift）
├── 用户输入分布发生变化
├── 例：新功能上线后，用户问的问题类型变了
└── 检测：监控输入文本的embedding分布
2. API变化（API Drift）
├── 外部API返回格式变化
├── 例：天气API更新了返回字段名
└── 检测：监控工具调用的错误率
3. 模型更新（Model Drift）
├── 底层LLM被更新（即使是同一版本号）
├── 例：GPT-4的某次静默更新
└── 检测：定期在固定测试集上回归测试
4. 上下文窗口溢出
├── 随着对话变长，早期信息被截断
├── 检测：监控长对话的成功率
└── 解决：实现更好的记忆管理
六、踩坑实录：三个血泪教训
坑1：用准确率评估Agent，结果翻车了
背景：我们开发了一个数据分析Agent，用户用自然语言提问，Agent生成SQL查询数据库返回结果。
评估方式：用200个QA对测试，比较Agent返回的数值和标准答案是否一致。
结果：准确率87%，看起来不错。
翻车：上线后发现用户实际使用中满意度很低。
原因分析：
测试集的问题都是"简单直接"的：
"上个月销售额是多少？" → SELECT sum(amount) FROM sales WHERE ...
但用户的真实问题很"模糊"：
"最近销售情况怎么样？"
→ Agent生成了SQL，返回了一个数字
→ 但用户想要的是趋势分析、环比对比、异常点...
准确率衡量的是"答案对不对"，
但用户关心的是"有没有帮到我"。
教训：评估指标必须对齐用户价值。对于开放式任务，需要引入"有用性"评估，而不仅仅是"正确性"。
坑2：Trace太多看不过来
背景：Agent上线后，我们接入了全链路追踪，每天产生5万条trace。
问题：根本没人看。trace数据躺在那里，出了问题还是靠用户反馈才发现。
解决方案：
第一版（失败）：
- 记录所有trace → 5万条/天 → 没人看
第二版（改进）：
- 只记录失败case → 5000条/天 → 还是太多
第三版（有效）：
- 自动分类失败模式
- 每天只推送"新发现的失败模式"（通常5-10条）
- 周度汇总报告
- 异常自动告警
关键转变：从"记录一切"到"只关注异常"
教训：可观测性的目的不是"记录所有数据"，而是"快速发现问题"。需要建立从数据到行动的闭环。
坑3：Benchmark分数高 ≠ 生产效果好
背景：我们的Agent在内部benchmark上超过了竞品，信心满满地上线。
结果：生产环境效果远不如benchmark预期。
原因分析：
我们的benchmark：
├── 问题都是英文的 → 但用户说中文
├── 工具都是mock的 → 但真实工具有延迟、有限流
├── 问题都是独立的 → 但用户会追问、改需求
└── 评估只看最终答案 → 但用户在意响应速度和交互体验
竞品的benchmark分数低，但：
├── 针对中文做了优化
├── 做了流式输出，用户感觉更快
└── 在用户常问的问题上做了special handling
教训：Benchmark是必要的，但不够。你需要构建贴近真实场景的评估数据集，并在评估中包含用户体验维度。
七、动手实验：构建Agent评估Pipeline
本节我们实现一个完整的Agent评估pipeline，包含trace收集、指标计算和失败分类。
7.1 实验设计
实验目标：构建一个可复用的Agent评估框架
输入：Agent执行的trace数据（JSON格式）
输出：
├── 每条trace的评分（成功率、效率、成本）
├── 失败模式分类
├── 整体统计报告
└── 可视化图表
数据来源：
├── 模拟数据（本实验）
├── 可替换为真实Agent的trace
└── 支持自定义评估指标
7.2 核心实现
完整代码见 code/13_evaluation_demo.py，这里展示核心设计。
评估Pipeline架构：
┌──────────────────────────────────────────────────────────────┐
│ │
│ ┌─────────────┐ ┌──────────────┐ ┌───────────────┐ │
│ │ Trace │───>│ Metric │───>│ Report │ │
│ │ Collector │ │ Calculator │ │ Generator │ │
│ └─────────────┘ └──────────────┘ └───────────────┘ │
│ │ │ │ │
│ v v v │
│ ┌─────────────┐ ┌──────────────┐ ┌───────────────┐ │
│ │ Trace │ │ Failure │ │ Visualization │ │
│ │ Validator │ │ Classifier │ │ │ │
│ └─────────────┘ └──────────────┘ └───────────────┘ │
│ │
└──────────────────────────────────────────────────────────────┘
7.3 运行实验
# 安装依赖
pip install matplotlib numpy
# 运行评估demo
python code/13_evaluation_demo.py
# 生成可视化图表
python code/generate_charts_13.py
7.4 实验结果分析
运行评估pipeline后，我们得到以下关键发现：
评估结果摘要（基于100条模拟trace）：
整体指标：
任务成功率： 72.0%
平均步骤数： 4.3步
平均Token消耗： 1,847 tokens
平均成本： $0.056/请求
平均延迟： 3,200ms
失败模式分布：
规划类失败： 32%（最多）
工具使用失败： 28%
幻觉类失败： 22%
记忆类失败： 18%
关键发现：
1. 死循环是最大的成功率杀手（贡献了15%的失败）
2. 工具参数错误是第二常见问题（12%）
3. 成本与成功率正相关（高成本请求成功率更高）
4. 3步以内的请求成功率95%，超过8步骤降到40%
步骤数 vs 成功率：
100% ┤
90% ┤ ██████████
80% ┤ ██████████████████
70% ┤ ████████████████████████
60% ┤ ██████████████████████████████
50% ┤ ████████████████████████████████████
40% ┤ ██████████████████████████████████████
30% ┤ ██████████████████████████████████████
└────────────────────────────────────────────────────
1步 2步 3步 4步 5步 6步 7步 8步+
结论：步骤越少，成功率越高。
优化方向：减少不必要的步骤，提高每步的质量。
八、评估最佳实践：从经验到方法论
8.1 评估金字塔
┌─────────────────────────────────────────────────────────┐
│ │
│ △ │
│ / \ 人工评估 │
│ / 人 \ （最可靠，最昂贵） │
│ /______\ │
│ / \ LLM-as-Judge │
│ / LLM判断 \ （较可靠，中等成本） │
│ /____________\ │
│ / \ 自动化指标 │
│ / 自动指标 \ （快速，低成本） │
│ /__________________\ │
│ / \ 单元测试 │
│ / 单元测试/回归测试 \ （基础，必须有） │
│ /________________________\ │
│ │
└─────────────────────────────────────────────────────────┘
建议比例：
单元测试/回归测试：每次提交都跑
自动化指标：每次部署前跑
LLM-as-Judge：每周跑一次
人工评估：每月做一次
8.2 评估驱动开发（Evaluation-Driven Development）
传统的Agent开发流程：
写代码 → 手动测试 → 感觉不错 → 上线 → 出问题 → 修bug → 循环
评估驱动开发（EDD）：
1. 先定义评估标准和测试集
2. 建立baseline
3. 每次修改后自动跑评估
4. 评估结果指导优化方向
5. 只有评估通过才能上线
EDD的核心原则：
├── "If you can't measure it, you can't improve it"
├── 评估集就是产品规格的另一种表达
├── 每次线上bug都应该变成评估集的新样本
└── 评估不是一次性的，是持续的过程
8.3 构建你的评估集
评估集的来源和构建方法：
1. 从真实用户数据中采样
├── 收集线上请求日志
├── 按任务类型分层采样
├── 人工标注"正确答案"
└── 定期更新（反映最新分布）
2. 从失败案例中积累
├── 每个线上bug → 一个评估样本
├── 每个用户投诉 → 一个评估样本
└── 每个"差点出错"的case → 一个评估样本
3. 合成数据
├── 用LLM生成边界case
├── 对抗性样本（prompt injection等）
└── 多语言、多风格变体
4. 竞品对比
├── 同一组问题在竞品上的表现
├── 差异化场景的覆盖
└── 定期更新对比结果
九、工具生态：评估与可观测性工具箱
┌──────────────────────────────────────────────────────────────────┐
│ 评估与可观测性工具生态 │
├──────────────────┬───────────────────────────────────────────────┤
│ 类别 │ 工具 │
├──────────────────┼───────────────────────────────────────────────┤
│ │ LangSmith - LangChain生态的追踪+评估平台 │
│ 追踪平台 │ Phoenix - Arize开源的LLM可观测性工具 │
│ (Tracing) │ W&B Traces - 实验管理+追踪 │
│ │ Arize - 生产级LLM监控 │
├──────────────────┼───────────────────────────────────────────────┤
│ │ RAGAS - RAG评估框架 │
│ 评估框架 │ DeepEval - LLM单元测试框架 │
│ (Evaluation) │ Promptfoo - Prompt评估+对比 │
│ │ AgentEval - Agent专用评估 │
├──────────────────┼───────────────────────────────────────────────┤
│ │ GAIA - 通用AI助手benchmark │
│ Benchmark │ SWE-bench - 代码修复benchmark │
│ (Benchmarks) │ WebArena - 网页操作benchmark │
│ │ AgentBench - 综合Agent benchmark │
├──────────────────┼───────────────────────────────────────────────┤
│ │ OpenTelemetry - 通用追踪标准 │
│ 基础设施 │ Grafana - 可视化+告警 │
│ (Infra) │ Prometheus - 指标采集 │
│ │ PagerDuty - 告警管理 │
└──────────────────┴───────────────────────────────────────────────┘
十、总结与展望
核心要点回顾
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. Agent评估需要三个维度：结果、过程、成本 │
│ │
│ 2. Benchmark是起点不是终点，需要构建贴近真实场景的评估集 │
│ │
│ 3. Trace分析是理解Agent行为的关键手段 │
│ │
│ 4. 失败模式分类帮助我们有针对性地改进 │
│ │
│ 5. 线上监控必须包含：系统、业务、成本、质量四层指标 │
│ │
│ 6. 评估驱动开发（EDD）是最有效的Agent开发方法论 │
│ │
└─────────────────────────────────────────────────────────────┘
评估的未来方向
Agent评估领域仍在快速发展，几个值得关注的方向：
-
动态评估集：不再使用固定的测试集，而是根据Agent的当前水平自适应生成难度合适的测试用例。
-
对抗性评估：自动搜索Agent的弱点，生成针对性的测试用例（类似fuzz testing）。
-
多Agent评估：评估多个Agent协作时的表现，包括通信效率、任务分配合理性等。
-
长期评估：评估Agent在长时间运行中的表现退化、记忆管理效果等。
-
用户价值评估：从"任务是否完成"转向"用户是否满意"，建立更贴近商业价值的评估体系。
参考文献
-
GAIA: A Benchmark for General AI Assistants (Mialon et al., 2023) - 提出了通用AI助手评估的标准框架，强调"人类能解AI也应能解"的理念。
-
SWE-bench: Can Language Models Resolve Real-World GitHub Issues? (Jimenez et al., 2024) - 代码Agent评估的里程碑，从真实GitHub仓库收集issue-PR对。
-
WebArena: A Realistic Web Environment for Building Autonomous Agents (Zhou et al., 2024) - 构建了自包含的网页操作评估环境，推动了网页Agent的发展。
-
AgentBench: Evaluating LLMs as Agents (Liu et al., 2024) - 统一的多环境Agent评估框架，覆盖8个不同场景。
-
RAGAS: Automated Evaluation of Retrieval Augmented Generation (Es et al., 2024) - RAG系统评估的标准框架，提出了faithfulness、answer relevancy等核心指标。
-
OpenTelemetry for LLM Applications (OpenTelemetry Community, 2024) - 将OpenTelemetry标准应用于LLM应用的可观测性，定义了Semantic Conventions for GenAI。
-
LangSmith Documentation (LangChain, 2024) - LangChain生态的追踪和评估平台，提供了Agent可观测性的最佳实践。
下期预告
第14篇：工程实战——从原型到生产级Agent系统
评估做好了，接下来怎么把Agent真正部署到生产环境？下一篇我们将讨论：
- 生产级Agent的系统架构设计
- 可靠性工程：重试、降级、熔断
- 性能优化：缓存、并行、流式输出
- 安全加固：权限控制、输入过滤、审计日志
- 灰度发布和A/B测试策略
从"能用"到"好用"到"敢用"，工程化是Agent落地的最后一公里。
作者注：本文的所有代码和图表均可在配套仓库中找到。如果你在实践中遇到了有趣的评估问题，欢迎在评论区分享。评估是一个"做比说难十倍"的领域——但也是区分"玩具Agent"和"生产Agent"的分水岭。