Agent 到底该怎么评？从 RAG 指标到科学的 Agent Evaluation 体系

CSDN 原文镜像

本文为作者 CSDN 博客的全文镜像，原文发布于 2026-08-26。为适配本站结构，仅补充了站内元数据与来源说明，正文主体保持原文内容。

原文链接：https://blog.csdn.net/m0_63309778/article/details/164094411
站内分区：Agent / Agent Evaluation

前言：我们真的会评测 Agent 吗？

过去做 RAG 时，我们谈评测，通常会想到这些指标：

Context Precision
Context Recall
Faithfulness
Answer Relevance
Answer Correctness

这套方法在 RAG 系统中已经比较成熟。

但进入 Agent 时代后，一个很明显的问题出现了：

Agent 还能继续用“输入—输出”这一套方式来评吗？

答案显然是否定的。

一个真实 Agent 的执行过程可能是：

text

User Task
↓
Intent Recognition
↓
Planning / Routing
↓
LLM
↓
Tool Selection
↓
Tool Arguments
↓
Tool Execution
↓
Environment State Change
↓
Observation
↓
Memory / Context Update
↓
Retry / Handoff / Guardrail
↓
Final Response

这里的任何一步都可能出错。

例如用户说：

帮我把订单 A123 取消掉。

Agent 最后回复：

已经帮你取消成功了。

从“最终回答”看，这似乎是一个完美答案。

但真实情况可能是：

text

数据库订单状态：SHIPPED
取消接口：调用失败
退款记录：不存在

Agent 只是“说自己完成了”。

这时候，如果我们只用 LLM-as-Judge 评价最终回答，很可能得到一个非常高的分数。

但从真实系统角度看：

这个 Agent 是彻底失败的。

因此，Agent Evaluation 和传统 LLM Evaluation 最大的区别并不是“多几个 Tool 指标”。

而是：

评测对象已经从模型输出，变成了一个具有状态、工具、环境和随机性的动态软件系统。

这篇文章想讨论的就是这个问题：

怎样建立一套真正科学、可解释、可复现的 Agent 与 RAG Evaluation 体系？

一、先搞清楚：我们到底在评什么？

传统 LLM 应用可以近似抽象成：

text

Input → Model → Output

RAG 增加了一个 Retrieval Pipeline：

text

Query
↓
Retriever
↓
Reranker
↓
Context
↓
LLM
↓
Answer

而 Agent 更接近：

text

Task
↓
Reasoning
↓
Actions
↓
Environment
↓
New State
↓
Observation
↓
Next Action
↓
...
↓
Outcome

这三个系统对应的评测对象其实完全不同。

系统	主要评测对象
LLM	Output
RAG	Retrieval + Generation
Agent	Outcome + Trajectory + Tool + State + Output

因此，第一个非常重要的结论是：

Agent Evaluation 不能只是 LLM Evaluation 的指标扩展，而应该被视为一种系统级测试。

现在很多 Agent 评测框架也已经明显朝 trace-based evaluation 演进。

例如 DeepEval 当前把 Agent 评测拆为 Reasoning、Action 和 Execution 三层，分别评价 Plan Quality、Tool Correctness、Argument Correctness、Task Completion 和 Step Efficiency，并且这些指标依赖完整执行 Trace。

Phoenix 则更进一步，把 Tracing、Dataset、Experiment、Evaluation 和 Human Annotation 放在同一个闭环里，并基于 OpenTelemetry/OpenInference 做 Trace 基础设施。

这说明 Agent Evaluation 的基础对象正在逐渐从：

text

prompt + answer

转变成：

text

task
+ trace
+ environment
+ outcome

二、Agent 评测最重要的原则：Outcome First

很多 Agent Evaluation Framework 首先想到的是：

text

Tool Correctness
Trajectory
Task Completion Judge

这些当然重要。

但我认为真正的第一指标应该是：

Outcome

也就是：

Agent 最终有没有真的把事情办成。

例如退款 Agent：

text

用户目标：
退款订单 A123

最终真正应该验证的不是：

text

assistant_response ==
"已经帮你退款成功"

而是：

text

return_request.status == CREATED
order.id == A123
refund.amount == expected_amount

对于 Coding Agent：

text

不是：
“代码已经帮你修改好了”

而是：

text

unit_test_pass == true
integration_test_pass == true
build_success == true

对于 Browser Agent：

text

不是：
“会议已经预约成功”

而是：

text

calendar_event.exists == true
calendar_event.time == expected_time

对于文件 Agent：

text

file.exists == true
file.content satisfies requirements

这也是 τ-bench / 当前 τ³-bench 这一类 benchmark 最值得借鉴的地方。

τ³-bench 不只是给模型一个问题然后看最终回复，而是提供：

Domain Policy；
Tools；
Tasks；
Environment；
User Simulator；

然后真正运行 Agent 与环境之间的交互。当前版本还已经增加 Knowledge Retrieval 和 Voice 等场景。

因此：

Agent 的 Task Success 应尽可能来自 Environment Verification，而不是 Agent 自己的语言输出。

三、Trajectory 很重要，但不要迷信“标准路径”

既然最终状态重要，是不是只看 Outcome 就够了？

也不是。

假设两个 Agent 都成功退款：

text

Agent A

get_order
→ check_policy
→ create_return

另一个 Agent：

text

Agent B

get_order
→ get_user
→ search_order
→ get_order
→ check_policy
→ retry
→ get_order
→ create_return

两者最终 Outcome 都是成功。

但显然 A 更优秀。

所以 Agent 还需要评价：

text

Trajectory

包括：

是否选择正确工具；
Tool 参数是否正确；
是否遗漏关键步骤；
是否违反执行顺序；
是否调用禁止工具；
是否出现无意义循环；
是否发生重复调用；
是否存在不必要步骤。

DeepEval 当前已经提供 Tool Correctness、Argument Correctness、Plan Adherence 和 Step Efficiency 等指标，这正是在尝试解决这个问题。

但是这里容易出现另外一个误区：

要求 Agent 完全走 Ground Truth Trajectory。

例如：

text

Expected:

A → B → C

实际：

text

A → D → B → C

如果 D 是一个合理的辅助查询，这个 Agent 不应该因为 Exact Match 失败而被判错。

因此，更合理的方式不是：

text

trajectory == expected_trajectory

而是定义：

Trajectory Constraints

例如：

yaml

<span class="token key atrule">trajectory</span><span class="token punctuation">:</span>

<span class="token key atrule">required</span><span class="token punctuation">:</span>
<span class="token punctuation">-</span> get_order
<span class="token punctuation">-</span> check_refund_policy

<span class="token key atrule">partial_order</span><span class="token punctuation">:</span>
<span class="token punctuation">-</span> get_order < check_refund_policy
<span class="token punctuation">-</span> check_refund_policy < create_return_request

<span class="token key atrule">forbidden</span><span class="token punctuation">:</span>
<span class="token punctuation">-</span> force_refund
<span class="token punctuation">-</span> modify_database_directly

<span class="token key atrule">max_calls</span><span class="token punctuation">:</span>
<span class="token key atrule">get_order</span><span class="token punctuation">:</span> <span class="token number">2</span>

我们真正要评价的是：

Agent 有没有遵守任务执行中的关键不变量。

而不是：

Agent 有没有背出我们提前写好的标准答案。

四、Agent Evaluation 最适合使用“五层评测模型”

为了避免所有东西最后压缩成一个所谓的“Agent 智能分”，我更倾向于将评测对象拆成五层。

第一层：Output

评价最终回复：

text

Correctness
Completeness
Helpfulness
Groundedness
Format
Safety

这是传统 LLM Evaluation 最擅长的部分。

第二层：Tool Call

评价单次 Action：

text

Tool Selection
Argument Correctness
Schema Validity
Execution Success
Tool Output Utilization

其中大量指标应该直接使用代码完成。

例如：

text

tool_name == expected

根本没必要调用 LLM Judge。

参数类型：

text

order_id: string

也应该使用 JSON Schema Validation。

原则应该是：

能够 deterministic evaluation 的问题，不要交给 LLM。

第三层：Trace

评价整个执行路径：

text

Required Steps
Forbidden Steps
Partial Order
Redundant Calls
Loop
Retry
Recovery
Efficiency

这回答的是：

Agent 为什么成功，或者为什么失败？

第四层：Session

真实 Agent 很少只是一次请求。

Session 层关注：

text

Multi-turn Goal Completion
Context Consistency
Intent Resolution
Clarification Quality
User Simulation
Long-horizon Reliability

例如：

text

User:
我想退货

Agent:
订单号是多少？

User:
A123

Agent:
查询订单……

User:
算了，我想换货。

这种场景已经不能用简单 Single-turn Metric 表达。

第五层：System

最后才是整个 Agent 产品是否真的可以上线：

text

Task Success Rate
Safety Violation Rate
Pass^k
Latency
Cost
Timeout Rate
Retry Rate
Regression Rate
Cost Per Success

这五层的关系可以理解成：

text

System
↑
Session
↑
Trace
↑
Tool
↑
Output

下层负责诊断。

上层负责决策。

五、不要让一个“总分”毁掉整个 Evaluation

这是很多 AI Evaluation 产品很容易犯的问题。

比如：

text

Agent Score = 87.6

看起来非常直观。

但实际上：

87.6 到底是什么意思？

假设：

text

Agent A

Task Completion        96%
Tool Accuracy          82%
Safety                  91%

另一个：

text

Agent B

Task Completion        92%
Tool Accuracy          97%
Safety                 100%

哪个更好？

如果这是：

text

调研 Agent

也许 A 可以接受。

如果这是：

text

银行转账 Agent

A 可能根本不能上线。

因此，Evaluation Platform 最终应该提供：

text

Metrics
+
Quality Gates

而不是只有：

text

Overall Score

例如：

yaml

<span class="token key atrule">quality_gate</span><span class="token punctuation">:</span>

<span class="token key atrule">hard</span><span class="token punctuation">:</span>
<span class="token key atrule">forbidden_tool_call_rate</span><span class="token punctuation">:</span> <span class="token number">0</span>
<span class="token key atrule">permission_violation_rate</span><span class="token punctuation">:</span> <span class="token number">0</span>
<span class="token key atrule">pii_leakage_rate</span><span class="token punctuation">:</span> <span class="token number">0</span>

<span class="token key atrule">outcome</span><span class="token punctuation">:</span>
<span class="token key atrule">task_success_rate</span><span class="token punctuation">:</span>
<span class="token key atrule">min</span><span class="token punctuation">:</span> <span class="token number">0.90</span>

<span class="token key atrule">reliability</span><span class="token punctuation">:</span>
<span class="token key atrule">pass_power_3</span><span class="token punctuation">:</span>
<span class="token key atrule">min</span><span class="token punctuation">:</span> <span class="token number">0.80</span>

<span class="token key atrule">performance</span><span class="token punctuation">:</span>
<span class="token key atrule">p95_latency</span><span class="token punctuation">:</span>
<span class="token key atrule">max</span><span class="token punctuation">:</span> <span class="token number">8000</span>

<span class="token key atrule">cost</span><span class="token punctuation">:</span>
<span class="token key atrule">cost_per_success</span><span class="token punctuation">:</span>
<span class="token key atrule">max</span><span class="token punctuation">:</span> <span class="token number">0.05</span>

如果：

text

Task Success ↑
但是 PII Leakage ↑

这个版本依然不能上线。

六、真正科学的 Agent Evaluation 必须面对“随机性”

Agent 是非确定性系统。

相同的：

text

Prompt
Model
Tools
Task

连续运行十次，可能得到：

text

Success
Success
Failure
Success
Failure
Success
Success
Success
Success
Failure

如果只跑第一次：

text

Success Rate = 100%

如果跑十次：

text

Success Rate = 70%

所以：

Single Run Eval 本身就不够科学。

τ-bench 一直非常强调 Pass^k 这类可靠性指标，其公开 benchmark 也会报告随着重复执行次数增加的成功稳定性。

因此一个真正面向 Agent 的 Evaluation Framework 应原生支持：

yaml

<span class="token key atrule">run</span><span class="token punctuation">:</span>
<span class="token key atrule">repetitions</span><span class="token punctuation">:</span> <span class="token number">5</span>

然后输出：

text

Success Rate
Pass@K
Pass^K
Variance
Flaky Rate
Latency Distribution
Cost Distribution

这里：

Pass@K

回答：

允许执行 K 次，至少成功一次的能力怎么样？

更偏 Capability。

Pass^K

回答：

连续 K 次都成功的概率怎么样？

更偏 Reliability。

对于 Coding Benchmark，Pass@K 很重要。

对于：

text

支付
退款
审批
企业 Agent

Pass^K 往往更加重要。

因为真实用户并不关心：

“这个 Agent 多试几次总有一次能成功。”

他们更关心：

每次使用它是不是都可靠。

七、除了重复执行，还需要真正的实验设计

假设：

text

Agent V1 = 86.8%
Agent V2 = 88.1%

我们能不能说：

V2 提升了 1.3%，效果更好？

未必。

因为差异可能来自：

text

随机采样
模型抖动
网络延迟
工具异常
数据污染
Judge 波动
运行环境变化

因此真正科学的 Agent Evaluation 至少应该支持：

text

Repeated Trials
Paired Experiment
Confidence Interval
Variance Analysis
Bootstrap
Regression Detection

例如比较两个版本时：

text

Same Dataset
Same Case
Same Environment Snapshot
Same Corpus Snapshot
Same Resource Limit

↓

Baseline vs Candidate

而不是：

text

V1 今天跑一次
V2 明天换了一批数据再跑一次

然后直接比较平均分。

这也是为什么一个新的开源 Evaluation 项目真正值得做的部分，不应该只是再增加几个 LLM Judge Metric。

更重要的是：

建立 Experiment Runtime。

八、Evaluator 本身也必须被评测

还有一个 Evaluation 系统经常被忽略的问题：

谁来评价 Evaluator？

比如我们写：

text

TaskCompletionJudge

让某个 LLM 判断 Agent 是否完成任务。

然后得到：

text

Task Completion = 91%

问题是：

这个 Judge 自己有多准？

如果 Judge 对 100 条人工标注数据只有：

text

Accuracy = 76%

那么：

text

Agent Score = 91%

实际上并没有想象中那么可信。

因此一个真正成熟的平台应该增加：

Judge Calibration

流程：

text

Human Label
↓
Gold Label
↓
Judge Prediction
↓
Comparison

至少计算：

text

Accuracy
Precision
Recall
F1
Cohen's Kappa
Confusion Matrix

同时 Judge 必须版本化：

text

Judge Model
Prompt
Rubric
Few-shot
Temperature
Output Schema
Version

因为：

text

GPT-X + rubric-v1

和：

text

GPT-X + rubric-v2

根本不是同一个 Evaluator。

九、再看 RAG：RAG Evaluation 也不能只有 Faithfulness

讲完 Agent，再看 RAG。

目前 RAG Evaluation 中 Ragas 是最有代表性的项目之一。

Ragas 当前已经不仅仅提供 Faithfulness 这类 RAG 指标，它正在向 experiments-first 的系统化评测方式扩展，并同时支持 LLM-based 和 deterministic metric。

但如果我们的目标是：

真正判断一个 RAG 系统到底哪里好、哪里不好。

我认为至少应该分成四层。

十、RAG 第一层：Retrieval Evaluation

Retriever 首先应该回到传统 Information Retrieval。

如果我们有：

text

Query
Relevant Document IDs

那么优先使用：

text

Recall@K
Precision@K
MRR
nDCG@K
Hit Rate

而不是直接问 LLM：

“这些 Chunk 看起来相关吗？”

例如：

text

Query:
员工差旅酒店报销标准是多少？

Ground Truth:
doc_124
doc_189

Retriever 返回：

text

doc_124
doc_300
doc_422
doc_189

这是一个非常明确的 Ranking 问题。

传统 IR Metric 比 LLM Judge 更：

text

稳定
便宜
可复现

十一、RAG 第二层：Claim-level Diagnosis

传统 Retriever Metric 又存在一个问题。

一个 Answer 可能需要多个事实：

text

Claim A
Claim B
Claim C

Document 1 支持 A。

Document 2 支持 B。

Document 3 支持 C。

因此单纯 Document Recall 有时候不够。

更进一步应该做到：

text

Claim → Supporting Evidence

然后计算：

text

Claim Recall
Claim Precision
Unsupported Claim
Missing Claim

这样才能回答：

RAG 到底漏掉了哪个事实？

而不是：

text

Faithfulness = 0.81

然后工程师不知道下一步应该改什么。

十二、RAG 第三层：Generation Evaluation

Retriever 找到信息以后，还需要判断 Generator 有没有正确使用。

至少应该包括：

text

Answer Correctness
Answer Completeness
Faithfulness
Citation Precision
Citation Recall
Citation Entailment
Abstention Correctness

这里一个很重要的区别是：

Correctness

回答是不是事实正确。

Faithfulness

回答是不是来源于提供的 Context。

例如：

Context 没有答案。

模型凭参数记忆回答正确。

那么：

text

Correctness = High
Faithfulness = Low

两者绝对不能混成一个分数。

十三、RAG 第四层：做 Ablation，而不是只看总分

这是我认为 RAG 科学评测里非常关键，但实际项目中很容易被忽略的一步。

对于同一套 Dataset，可以跑四组实验：

text

A. Model Only
B. Oracle Context
C. Current RAG
D. Candidate RAG

它们分别回答完全不同的问题。

Model Only

text

LLM 不检索时能答多少？

Oracle Context

人工提供正确 Context：

text

Retriever 完美时，Generator 的能力上限是多少？

Current RAG

text

现在的完整生产 Pipeline 有多好？

Candidate RAG

例如：

text

New Embedding
New Chunk Strategy
New Reranker
New Retrieval Strategy

到底有没有提升。

通过这四组实验，我们才能区分：

text

Retriever 问题
Generator 问题
Model Knowledge 问题
Context Organization 问题

否则：

text

Answer Correctness ↓

之后大家很容易直接开始：

换模型。

但真正的问题也许只是 Retriever 没找到正确文档。

十四、RAG 和 Agent 最终其实应该进入同一套 Evaluation Runtime

Agentic RAG 出现以后，再分别维护：

text

RAG Eval Platform
Agent Eval Platform

其实会越来越奇怪。

因为一个 Agent Trace 完全可能是：

text

Agent
|
├─ model
|
├─ retrieval
|
├─ rerank
|
├─ model
|
├─ tool
|
└─ final_response

这时 RAG 只是：

text

Agent Trace 中的一部分。

因此一个更加合理的设计是：

text

Evaluation Core

├── Agent Evaluators
├── RAG Evaluators
├── Tool Evaluators
├── Safety Evaluators
├── Browser Evaluators
├── Code Evaluators
└── Multimodal Evaluators

底层全部共享：

text

Dataset
Case
Trial
Trace
Evaluator
Experiment

十五、现在的开源项目已经做到什么程度？

理解这一点很重要，因为如果我们真的准备做一个新的开源项目，首先必须回答：

为什么不是直接用现有项目？

目前整个生态大概可以分成五类。

类型	代表项目	最值得借鉴的能力
Metric / Eval SDK	Ragas、DeepEval	指标体系、开发体验
Eval / Observability Platform	Phoenix	Trace、Dataset、Experiment
CLI / CI / Red Team	Promptfoo	YAML、CI、安全测试
General Eval Harness	Inspect AI	Task、Scorer、Agent、Sandbox
Stateful Benchmark	τ³-bench、AgentDojo	Environment、Simulation、真实状态

Ragas

更擅长：

text

Metrics
Dataset
Experiment
RAG Evaluation

而且已经支持自定义离散、数值和 Ranking Metric，并区分 LLM-based 与 deterministic metric。

值得学习：

Metric API 与 RAG Evaluation。

DeepEval

更像：

Pytest for LLM / Agent。

当前 Agent Evaluation 已经覆盖：

text

Task Completion
Plan Quality
Plan Adherence
Tool Correctness
Argument Correctness
Step Efficiency

而且能够直接利用完整 execution trace。

值得学习：

Developer Experience。

Phoenix

Phoenix 已经非常接近一个完整的 AI Engineering Platform：

text

Tracing
Evaluation
Dataset
Experiment
Human Annotation
Prompt

并基于 OpenTelemetry 与 OpenInference。

值得学习：

Trace 与 Experiment。

但也正因为如此，新项目不应该第一天就再造一个 Phoenix。

Promptfoo

Promptfoo 的优势非常清晰：

text

CLI
YAML Config
Provider Abstraction
CI/CD
Red Team

其 Red Team 模型把测试拆成：

text

Target
Plugin
Strategy
Context

这种插件化攻击生成方式非常适合 Agent Security Evaluation。

值得学习：

声明式 Case + CI + Security。

Inspect AI

Inspect 是目前非常值得研究的 Evaluation Harness。

它本身提供：

text

Dataset
Task
Solver
Scorer
Tool
Agent
Sandbox

并已经支持自定义 Tool、MCP、多 Agent、外部 Coding Agent，以及 Docker、Kubernetes 等 Sandbox。

值得学习：

Evaluation Runtime 的抽象。

τ³-bench

τ³-bench 更重要的不是某几个指标。

而是：

把 Agent 放进一个真正可以交互和改变状态的模拟业务环境中。

它提供 Domain、Policy、Tool、Task、User Simulator 和 Environment，并通过多次 Trial 评价 Agent。

值得学习：

Environment + Scenario + Outcome。

十六、所以新的开源项目到底应该做什么？

如果重新做一个：

text

Ragas + 一些 Agent Metrics

意义并不大。

如果重新做：

text

LLM-as-Judge SDK

同样很难形成差异化。

如果重新做：

text

Phoenix

工程量巨大，而且并没有明显优势。

我认为真正值得做的方向是：

Scientific Evaluation Harness for Production Agents & RAG

核心不是：

指标多。

而是：

评测方法可信。

它需要解决四件事。

十七、第一件事：定义统一的 Case Specification

首先需要一种语言描述：

这个 Agent 到底怎样才算完成任务？

例如：

yaml

<span class="token key atrule">spec_version</span><span class="token punctuation">:</span> <span class="token string">"1"</span>

<span class="token key atrule">case</span><span class="token punctuation">:</span>

<span class="token key atrule">id</span><span class="token punctuation">:</span> refund_shipped_order

<span class="token key atrule">input</span><span class="token punctuation">:</span>
<span class="token key atrule">messages</span><span class="token punctuation">:</span>
<span class="token punctuation">-</span> <span class="token key atrule">role</span><span class="token punctuation">:</span> user
<span class="token key atrule">content</span><span class="token punctuation">:</span> <span class="token string">"帮我退掉订单 A123"</span>

<span class="token key atrule">environment</span><span class="token punctuation">:</span>

<span class="token key atrule">initial_state</span><span class="token punctuation">:</span>
<span class="token key atrule">order</span><span class="token punctuation">:</span>
<span class="token key atrule">id</span><span class="token punctuation">:</span> A123
<span class="token key atrule">status</span><span class="token punctuation">:</span> shipped

<span class="token key atrule">expected</span><span class="token punctuation">:</span>

<span class="token key atrule">outcome</span><span class="token punctuation">:</span>

<span class="token punctuation">-</span> <span class="token key atrule">type</span><span class="token punctuation">:</span> database
<span class="token key atrule">path</span><span class="token punctuation">:</span> return_request.order_id
<span class="token key atrule">equals</span><span class="token punctuation">:</span> A123

<span class="token punctuation">-</span> <span class="token key atrule">type</span><span class="token punctuation">:</span> database
<span class="token key atrule">path</span><span class="token punctuation">:</span> return_request.status
<span class="token key atrule">equals</span><span class="token punctuation">:</span> created

<span class="token key atrule">trajectory</span><span class="token punctuation">:</span>

<span class="token key atrule">required</span><span class="token punctuation">:</span>
<span class="token punctuation">-</span> get_order
<span class="token punctuation">-</span> check_refund_policy

<span class="token key atrule">partial_order</span><span class="token punctuation">:</span>
<span class="token punctuation">-</span> get_order < check_refund_policy

<span class="token key atrule">forbidden</span><span class="token punctuation">:</span>
<span class="token punctuation">-</span> force_refund

<span class="token key atrule">response</span><span class="token punctuation">:</span>

<span class="token key atrule">assertions</span><span class="token punctuation">:</span>
<span class="token punctuation">-</span> 应告知用户需要退货
<span class="token punctuation">-</span> 不得承诺立即退款

<span class="token key atrule">run</span><span class="token punctuation">:</span>

<span class="token key atrule">repetitions</span><span class="token punctuation">:</span> <span class="token number">5</span>

它不是：

text

Question + Expected Answer

而是：

text

Task Specification。

这会成为整个开源项目最重要的核心抽象之一。

十八、第二件事：Environment 必须成为一等公民

这是我认为这个项目与普通 LLM Eval Framework 最需要拉开差异的地方。

应该支持：

text

EnvironmentAdapter

例如：

text

SQLite
PostgreSQL
Redis
REST API
Filesystem
Docker
Browser
Custom Python

每一个 Trial：

text

Environment Reset
↓
Setup Initial State
↓
Run Agent
↓
Freeze Final State
↓
Verify Assertions
↓
Destroy / Reset

例如：

yaml

<span class="token key atrule">assertions</span><span class="token punctuation">:</span>

<span class="token punctuation">-</span> <span class="token key atrule">sql</span><span class="token punctuation">:</span>
<span class="token key atrule">query</span><span class="token punctuation">:</span> <span class="token punctuation">></span><span class="token scalar string">
SELECT status
FROM refund
WHERE order_id = 'A123'</span>

<span class="token key atrule">equals</span><span class="token punctuation">:</span> CREATED

这样 Task Completion 就变成一个：

text

确定性测试。

而不是：

text

让另一个 LLM 猜 Agent 做没做完。

十九、第三件事：Trace Native，但不要重新造 Tracing

Trace Schema 是整个项目的地基。

但没必要再发明：

text

MyAgentEvalTraceProtocol。

现在 Phoenix/OpenInference 等项目已经明显围绕 OpenTelemetry 做 AI Trace 标准化。

内部只需要建立一个 Normalize Layer：

text

OpenTelemetry
OpenInference
LangGraph
OpenAI Agents
Custom Trace
↓
Normalized Trace

例如统一 Span 类型：

text

agent
model
tool
retrieval
rerank
memory
guardrail
handoff
environment
human

然后所有 Evaluator 都只针对：

text

Normalized Trace

编写。

这样 Agent Framework 和 Evaluation Framework 完全解耦。

二十、第四件事：把 Statistics 做成一等能力

我认为这可能是这个项目真正能够做出特色的一点。

传统 LLM Evaluation 通常是：

text

run
→ score
→ average

新的项目应该是：

text

Experiment
↓
Repeated Trials
↓
Paired Comparison
↓
Statistical Analysis
↓
Regression Decision

结果页面应该输出：

text

Agent V1

Task Success       87.4%
95% CI             [84.1%, 90.3%]
Pass^3             66.8%
Flaky Rate          9.3%
Cost / Success     $0.041

对比：

text

Agent V2

Task Success       90.2%
95% CI             [87.5%, 92.6%]
Pass^3             73.4%
Flaky Rate          5.1%
Cost / Success     $0.039

然后告诉开发者：

text

Task Success       +2.8%
Reliability        +6.6%
Flaky Rate         -4.2%
Cost / Success     -4.9%

这比：

text

Agent Score:
87 → 89

有意义得多。

二十一、整个系统最终应该长这样

text

                         Dataset
|
CaseSpec
|
Experiment Runner
|
+---------------+---------------+
|                               |
Target Adapter                 Environment
|                               |
Agent/RAG                      Sandbox
|                               |
+---------------+---------------+
|
Trial
|
Trace Normalizer
|
+---------------------+----------------------+
|                     |                      |
Deterministic         LLM Judge              Human
Evaluator             Evaluator             Review
|                     |                      |
+---------------------+----------------------+
|
Statistical Engine
|
+-----------------+----------------+
|                 |                |
Report          Quality Gate      Failure Mining

这个架构里真正核心的不是 UI。

而是八个对象：

text

Case
Dataset
Target
Environment
Trial
Trace
Evaluator
Experiment

二十二、RAG 不需要单独建一套系统

RAG 完全可以作为 Evaluator Plugin：

text

evaluators/

├── deterministic/
├── agent/
├── tool/
├── trajectory/
├── rag/
├── safety/
├── reliability/
└── judge/

RAG Plugin 里面：

text

retrieval_recall
precision_at_k
mrr
ndcg
claim_recall
faithfulness
citation_correctness
noise_sensitivity

第一阶段甚至可以：

text

Adapter Ragas
Adapter DeepEval

而不是重新实现所有指标。

你的价值不应该是：

我也实现了 Faithfulness。

真正的价值应该是：

我能够告诉你某次 Agent/RAG 改动是否真的提升了生产系统，而且这个结论是可复现、可解释、有统计可信度的。

二十三、真正应该形成的是 Evaluation Flywheel

最终整个系统应该闭环成：

text

Production
↓
Trace
↓
Failure Mining
↓
Dataset
↓
Evaluation
↓
Experiment
↓
Regression Analysis
↓
Quality Gate
↓
New Version
↓
Production

例如线上发现：

text

“订单取消后偶尔仍然调用退款 API”

不是只修 Bug。

而是：

text

生产失败
↓
转为 Regression Case
↓
加入 Dataset
↓
以后所有版本自动验证

Dataset 会随着生产系统持续增长。

这样 Evaluation 才真正从：

text

上线前跑一次测试

变成：

text

Agent 质量基础设施。

二十四、最终我们到底想做什么？

这个项目的定位最终可以浓缩成一句话：

Evaluate what your agent actually does, not only what it says.

它不是：

text

RAG Score Library

也不是：

text

LLM Judge Wrapper

更不是：

text

Another Observability Platform

而应该是一套：

text

Case Specification
+
Resettable Environment
+
Outcome Verification
+
Normalized Trace
+
Deterministic / LLM / Human Evaluation
+
Repeated Trials
+
Statistical Experiment
+
CI Quality Gate

组成的：

Agent & RAG Quality Engineering Framework

结语

LLM 时代，我们问的是：

模型回答得对不对？

RAG 时代，我们进一步问：

模型回答的内容有没有证据？

而 Agent 时代，我们必须继续往前走一步：

这个 AI 到底做了什么？

事情真的办成了吗？

用了哪些工具？

有没有越权？

为什么失败？

每次运行都能成功吗？

新版本是真的提升，还是随机波动？

Retriever、Generator、Tool、Prompt、Model，到底是谁出了问题？

这时 Evaluation 已经不再只是几个 Metric。

它更像传统软件工程中的：

text

Unit Test
+
Integration Test
+
End-to-End Test
+
Observability
+
Experimentation
+
Statistics

只是它面对的是一个概率性的 AI 系统。

所以我越来越倾向于认为：

Agent Evaluation 的终局，不是给 Agent 打一个分。

而是建立一套可以回答：

“这个 Agent 是否值得被信任和上线？”

的质量工程体系。

而如果我们要做一个新的开源项目，我认为这才是最值得做的方向。

参考项目与资料

本文对开源生态的分析主要参考：

Ragas：Metrics、Dataset 与 Experiment 体系。
DeepEval：Trace-based Agent Evaluation，以及 Task Completion、Tool Correctness、Plan、Efficiency 等 Agent Metric。
Arize Phoenix：OpenTelemetry/OpenInference、Tracing、Evaluation、Dataset 与 Experiment。
Promptfoo：声明式 Eval、CI/CD 与 Red Team Plugin/Strategy。
Inspect AI：Task、Solver、Scorer、Tool、Agent 与 Sandbox Evaluation Harness。
τ³-bench：Domain、Policy、Tool、Environment、User Simulator 与多 Trial Stateful Agent Evaluation。