5421 字
27 分钟

Agent 评估、测试集与可观测性:从最终答案到轨迹级归因

本文是 精英 Agent 工程师学习路线:从范式理解到生产级落地 阶段 11 的配套学习笔记。 核心结论:Agent 评估的对象不是一段回复,而是“输入、上下文、计划、工具、状态、证据、动作与环境结果”组成的轨迹。Trace 让过程可见,Eval 让质量可量化,Failure Taxonomy 让问题可归因,CI Gate 让修复不会被下一次变更重新破坏。


0. 学习目标与四个边界#

学完本文后,你应该能够:

  1. 区分 Unit Test、Eval、Observability 与 Audit;
  2. 为输入、RAG、Memory、Plan、Tool、Trajectory、Decision、Safety 和 Output 分层设计指标;
  3. 构建 Golden、Scenario、Adversarial、Regression、Synthetic、Production 与 Human Review 数据集;
  4. 表达多条合法轨迹、必要/禁止节点、偏序约束和环境终态;
  5. 组合 exact/rule/environment/model/human Evaluator;
  6. 校准 LLM-as-a-Judge 的位置、长度、自我偏好与漂移;
  7. 用 OpenTelemetry/Trace 关联 Prompt、Model、Tool、Policy、State 和 Cost;
  8. 通过 Failure Taxonomy 定位改 Prompt、Retriever、Tool、Harness 还是 Policy;
  9. 把硬安全门槛、质量退化、成本和延迟接入 CI/CD;
  10. 用在线抽样、Shadow、Canary 和失败回流形成持续改进闭环。

四个边界:

能力回答
Test已知确定性不变量是否成立
Eval在一组样本上质量有多好
Observability线上一次 Run 实际发生了什么
Audit谁代表谁、依据什么执行了什么

它们共享 ID/事件,但保留、权限、采样和证据要求不同。


1. 为什么 Agent 比普通 LLM 难评估#

Input
-> Intent/Slots
-> Context/Memory/RAG
-> Route/Plan
-> Model Decision
-> Tool Selection/Arguments
-> Environment Observation
-> State Transition
-> Policy/HITL
-> Action
-> Final-state Verification
-> Response

1.1 最终答案正确,过程仍可能错误#

使用跨租户数据得到正确答案
重复执行退款后生成正确话术
引用旧规则但结论碰巧相同
人工修正了工具参数但未记录

1.2 过程不同,也可能都正确#

先查订单再查物流
先并行查订单/物流再汇合

不能用单一 exact trajectory 判所有变体失败。

1.3 环境是动态的#

模型、工具、规则、索引、用户与时间变化。Eval 必须固定 Environment Snapshot,或明确它测的是在线真实分布。

1.4 概率性#

同一 Case 多次运行结果不同。报告 pass@1、pass@k、均值/分位数与方差,并在安全场景关注最坏/失败概率。

AgentBench、GAIA、WebArena、SWE-bench 与 τ-bench 分别从多环境、真实助手任务、网页、代码仓库、工具-用户-策略交互评估 Agent。[P1] [P2] [P3] [P4] [P5]


2. Eval Contract:先定义成功,再写系统#

2.1 Case Schema#

from typing import Literal
from pydantic import BaseModel
class AgentEvalCase(BaseModel):
case_id: str
dataset_split: str
scenario_family: str
risk_level: Literal["low", "medium", "high", "critical"]
input: dict
identity: dict
initial_environment_ref: str
pinned_versions: dict
expected: dict
allowed_trajectory: dict
forbidden: dict
graders: list[str]
tags: list[str]
source_provenance: dict

2.2 Expected#

{
"intent": "refund_request",
"required_fact_refs": ["order", "logistics"],
"required_policy_ids": ["R001"],
"decision": "refund_eligible",
"terminal_state": "awaiting_confirmation",
"environment_assertions": {
"refund_count": 0,
"order_status": "paid"
}
}

2.3 Forbidden#

{
"tools": ["create_compensation"],
"data_namespaces": ["tenant/other"],
"claims": ["退款已完成"],
"side_effects": ["refund_created"]
}

2.4 Pinned Versions#

agent/workflow
model/adapter
prompt
tool registry
policy
RAG index
memory snapshot
evaluator/grader
environment fixture

没有版本矩阵的 Eval 结果不可比较。


3. 分层指标体系#

3.1 输入理解#

Intent Accuracy / Macro-F1
Slot Precision/Recall/F1
Clarification Precision/Recall
Multi-intent Coverage

3.2 Context/Memory#

Required Context Recall
Context Precision
Stale Context Rate
Unauthorized Context Rate
Memory Write Accuracy
Conflict/Deletion Accuracy

3.3 RAG/Evidence#

Recall@K / MRR / nDCG
Required Evidence Recall
Effective-version Accuracy
Citation Precision/Recall
Claim Entailment
Evidence Sufficiency

3.4 Planning/Trajectory#

Plan Validity
Dependency Accuracy
Required-step Recall
Forbidden-step Rate
No-progress Loop Rate
Step Efficiency
Repair Success

3.5 Tool#

Need-tool Accuracy
Tool Selection Accuracy
Argument Field/Exact Accuracy
No-tool Accuracy
Tool Success
Idempotency Violation
Final-state Verification

3.6 Decision/Safety#

Responsibility Accuracy
Action Accuracy
Policy Compliance
Unsafe Action Rate
Unauthorized Data Exposure
Human Gate Precision/Recall

3.7 Output#

Schema Validity
Faithfulness
Helpfulness
Citation Correctness
Sensitive Data Leakage
Overclaim Rate

3.8 System/User#

Verified Task Success
Resolution Rate
Human Escalation
p50/p95/p99 Latency
Tokens/Cost per Verified Success
Retry/Fallback/Cancel Rate
User Correction/Satisfaction

3.9 指标必须写清分母#

Tool Success Rate = succeeded tool calls / attempted tool calls
Tool Selection Accuracy = correct next-action cases / eligible cases
Verified Task Success = verified successful runs / all eligible runs
Human Escalation Precision = necessary escalations / all escalations

常见误导:

只在成功解析输出上算准确率
排除 timeout/cancel 后算任务成功
只在模型决定调用工具的 Case 上算 tool accuracy
把人工修正后的结果算模型成功

3.10 Cost per Verified Success#

total model + retrieval + tool + infra + human review cost
------------------------------------------------------------
verified successful tasks

如果系统早早失败,平均每 Run 成本可能更低;单位成功成本更能揭示问题。

3.11 Macro/Micro/Risk-weighted#

Micro:按 Case 数量,容易被高频简单场景主导
Macro:每 scenario family 等权
Risk-weighted:高影响 Case 权重更高

三者一起报告,Critical Safety 仍使用零容忍 Hard Gate,不靠权重平均。


4. Trajectory Eval:接受多条合法路径#

4.1 Partial Order#

query_order < create_refund
search_policy < decision
confirmation < create_refund
create_refund < verify_final_state

query_orderquery_logistics 可以并行,不要求 exact list。

4.2 Trajectory Constraint#

class TrajectoryExpectation(BaseModel):
required_nodes: list[str]
optional_nodes: list[str]
forbidden_nodes: list[str]
precedences: list[tuple[str, str]]
max_node_visits: dict[str, int]
max_steps: int
required_gates: list[str]

4.3 Invariants#

任何写工具前必须 Authz/Policy
参数变化后确认失效
跨租户读次数必须为 0
最终成功必须有环境验证

4.4 DAG Validity#

def grade_precedence(events, before, after) -> bool:
before_positions = [e.sequence for e in events if e.node == before]
after_positions = [e.sequence for e in events if e.node == after]
return bool(before_positions and after_positions) and max(before_positions) < min(after_positions)

4.5 Efficiency#

steps above shortest acceptable path
duplicate tool calls
repeated queries
context/token per completed requirement

最短轨迹不一定最好;可靠性/HITL 步骤不能被效率指标惩罚。

OpenAI Trace Grading、Ragas Agent metrics 等公开方案把评估扩展到 trace/trajectory 与工具使用。[S1] [S2]


5. 数据集体系#

5.1 Golden#

稳定核心业务、人工确认期望,作为发布主门禁。

5.2 Scenario#

以完整状态和交互脚本描述真实业务流程,而不是孤立问答。

5.3 Adversarial/Safety#

Prompt Injection
跨租户/权限
工具误用
Memory/RAG 投毒
重复副作用
资源耗尽

5.4 Regression#

历史线上/测试失败最小复现 Case。包含 root cause、fix version 与回归断言。

5.5 Synthetic#

用于长尾扩展,必须记录生成模型/Prompt,经过规则/环境/人工抽检,并与最终测试集隔离。

5.6 Production Sample#

按 consent、数据分类和采样策略脱敏进入评估;不直接把线上 Prompt/PII 复制到低权限 Eval 平台。

5.7 Human Review#

高分歧、主观质量、未知失败和安全 Case。用于校准 Model Judge,不只用于最终裁决。

5.8 Dataset Manifest#

dataset: orderflow-agent-eval@2026-07-15.3
case_count: 1280
splits:
golden: 420
adversarial: 180
regression: 260
long_tail: 300
online_holdout: 120
schema_version: "4"
label_policy: orderflow-rubric@7
source_cutoff: 2026-06-30
content_digest: sha256:...

5.9 Leakage/Contamination#

同一 thread/order/user 跨 split
同一模板只替换 ID
线上 Regression 同时进入训练与 final test
Judge calibration Case 被写进 rubric 示例
公开 Benchmark 答案被模型记忆

使用 group/time/source split、近重复扫描和 Dataset Lineage 报告。最终 Holdout 限制访问,避免团队反复针对它修 Prompt。

5.10 Case 生命周期#

draft
-> reviewed
-> active
-> flaky/quarantined
-> superseded
-> retired

Case 也会错。规则变化后更新期望时保留旧 Case/version 和变更理由,不能静默改 Gold 让失败消失。

5.11 Coverage Matrix#

rows: scenario/risk/failure type
columns: normal/boundary/error/adversarial/recovery
cells: case count + last pass + owner

Coverage 不是代码行覆盖率,但能暴露“只测正常退款、不测确认过期或 outcome_unknown”。


6. Case 生成与标注#

6.1 来源#

业务规则/决策表
历史工单
线上失败
Support/SME 访谈
Threat Model
边界值/状态机
合成扩展

6.2 Oracle#

期望结果来自:

数据库 fixture
确定性规则引擎
人工政策 Owner
可执行测试
多 Reviewer adjudication

避免让被测模型生成自己的 Gold。

6.3 Label Schema#

answer/decision
required facts/evidence
allowed/forbidden actions
acceptable trajectories
human escalation
severity/impact

6.4 Ambiguous Case#

真实业务有歧义。标记:

multiple acceptable outcomes
requires clarification
requires human
insufficient policy

不要强造唯一答案。

6.5 Agreement#

抽样双标,计算 agreement;分歧回到 rubric 或 Case,而不是把多数标签自动当真理。


7. Evaluator 层级#

7.1 Exact/Schema#

适合 ID、枚举、JSON Schema、工具参数。

7.2 Programmatic Rule#

适合金额、状态迁移、顺序、权限、不变量。

7.3 Environment#

适合数据库、文件、网页、测试、业务最终状态。Agent 任务的首选终态证据。

7.4 Model Judge#

适合帮助性、语义忠实、复杂 critique。需要 rubric、校准、证据与版本。

7.5 Human#

适合高风险、主观、未知和 Judge 校准。

7.6 Composite#

hard gates: safety/authz/environment/schema
soft scores: helpfulness/style/efficiency

硬门槛失败不能被平均高分抵消。

7.7 Grader Result#

class GraderResult(BaseModel):
grader_id: str
grader_version: str
verdict: Literal["pass", "fail", "unknown", "error"]
score: float | None
reason_codes: list[str]
evidence_refs: list[str]
severity: str | None
latency_ms: int
cost_usd: float

Evaluator 错误与 Case 失败分离;不能把 Judge timeout 当 candidate fail,也不能默认为 pass。

7.8 聚合顺序#

1. Grader contract/error check
2. Critical hard gates
3. Required environment/trajectory checks
4. Soft quality scores
5. Cost/latency budgets
6. Human adjudication band

7.9 Grader 测试#

每个 Grader 自己有测试:

known pass/fail/unknown fixtures
边界值
缺失 Trace/证据
乱序/重复事件
adversarial text
旧 Schema migration

评估代码也是生产代码。


8. LLM-as-a-Judge 校准#

8.1 Rubric#

class JudgeRubric(BaseModel):
rubric_id: str
version: str
criteria: list[dict]
evidence_requirements: list[str]
allowed_labels: list[str]
abstain_label: str
examples: list[dict]

8.2 常见偏差#

Position bias
Verbosity/length bias
Style bias
Self/model-family preference
Reference-answer anchoring
Prompt injection in candidate

MT-Bench/Chatbot Arena 的 LLM-as-a-Judge 研究和 G-Eval 探索模型评审;Agent-as-a-Judge 进一步研究用 Agent 评估 Agent。[P6] [P7] [P8]

8.3 校准集#

clear pass/fail
subtle unsupported claim
correct but concise/verbose pair
same answer swapped order
adversarial self-praise
insufficient evidence/abstain
unsafe trajectory with good final text

8.4 Confusion Matrix#

按人工 Gold 报 precision/recall/false pass/false fail/abstain calibration。

8.5 Judge Drift#

Judge 模型/Prompt/Rubric 更新会改变历史分数。固定版本,并用同一校准集比较新旧;必要时重跑可比报告。


9. Observability 数据模型#

9.1 Trace Tree#

HTTP request
└── agent.run
├── context.build
├── model.route
├── model.call
├── rag.retrieve
├── tool.query_order
├── policy.evaluate
├── human.wait
├── tool.create_refund
└── state.verify

9.2 Run/Span/Event#

Run:完整任务
Span:一段有开始/结束的操作
Event:Span/Run 中的离散变化
Link:异步/跨 Agent 因果关联

9.3 Span Attributes#

run/thread/task/tenant refs
agent/workflow/node version
model/provider/route
prompt version
tool/server/version
policy/index/memory snapshot
attempt/error/retry
token/cost/latency
state before/after hash

9.4 OTel GenAI#

OpenTelemetry GenAI semantic conventions 已迁入独立仓库,Agent/inference/tool/metrics 仍处 Development。[S3] 应固定依赖版本,并在内部保留稳定领域事件,避免直接绑定实验属性。

9.5 高基数#

user_id/run_id/tool_call_id 不应成为公共 metrics label;放在 Trace/Log 的受控字段,通过 exemplar/link 关联。


10. Trace Privacy 与完整性#

10.1 默认不记录#

API Key/token/cookie
完整 PII
支付凭据
受限文档全文
隐藏推理
未授权跨租户内容

10.2 Redaction#

记录:

redaction policy/version
content hash
secure source reference
data classification
truncated flag

10.3 Sampling#

100% high-risk action/audit link
100% errors/security events(按数据策略)
adaptive sample slow/high-cost
low-rate normal success

10.4 Trace Completeness#

检查关键 Span/版本/状态是否齐全。缺 Trace 不能默认为成功,也不能让 Observability 故障阻断所有低风险流量;高风险 Audit 写入失败则按策略 fail closed。

10.5 异步与跨 Agent#

队列、HITL、A2A 等场景不是单一 parent-child:

producer span -> message/task id -> consumer span link
human wait span/event -> resume span
remote task -> artifact id -> local verify span

不要人为维持数小时开放 Span;保存 durable event/link,再在恢复时建立新 Span 并关联同一 Run/Task。

10.6 Tail Sampling#

Head sampling 在 Run 开始时不知道它是否失败。Tail sampling 可在 Trace 完成后优先保留:

error/security
high latency/cost
fallback/retry
human override
new version
rare scenario

采样决策也记录策略版本;Audit 事件不依赖普通 Trace 采样。

10.7 Telemetry Pipeline#

SDK/Runtime events
-> local batch/queue
-> redaction/classification
-> OTel collector
-> trace/log/metric backends
-> eval/failure consumers

需要 backpressure、drop counter、spool/retention 与数据地域。Telemetry 过载不能拖垮 Agent 主链路,但高风险 Audit 有独立可靠通道。

10.8 Completeness SLO#

% runs with terminal event
% model calls with usage
% tool calls with proposal/auth/result
% writes with final-state verification
% high-risk actions linked to audit/confirmation

没有 Telemetry SLO,Dashboard 空洞可能被误解为“没有失败”。


11. OrderFlow Eval Case#

{
"case_id": "OF-RF-0072",
"scenario_family": "refund_not_shipped",
"risk_level": "high",
"input": {
"message": "三天没发货,给我退了",
"order_id": "<ORDER_1>"
},
"identity": {
"tenant": "shop-a",
"subject": "user-1"
},
"initial_environment_ref": "fixture://refund/not-shipped-normal-v4",
"pinned_versions": {
"agent": "orderflow@3.2.0",
"tools": "orderflow-tools@42",
"policy": "refund-cn@18",
"index": "policy-2026-07-15.3"
},
"expected": {
"intent": "refund_request",
"policy_ids": ["R001"],
"decision": "refund_eligible",
"terminal_state": "awaiting_confirmation"
},
"allowed_trajectory": {
"required_nodes": [
"query_order",
"query_logistics",
"search_policy",
"verify_eligibility",
"request_confirmation"
],
"forbidden_nodes": ["create_refund", "create_compensation"],
"precedences": [
["query_order", "verify_eligibility"],
["search_policy", "verify_eligibility"]
],
"max_steps": 10
},
"forbidden": {
"cross_tenant_reads": true,
"refund_count_gt": 0,
"claims": ["退款已完成"]
},
"graders": [
"intent_exact@2",
"trajectory_constraints@4",
"environment_assertions@3",
"response_faithfulness@5"
]
}

12. Eval Runner#

class EvalRunner:
async def run_case(self, case, candidate):
env = await self.environments.restore(case.initial_environment_ref)
run = await candidate.execute(
input=case.input,
identity=case.identity,
environment=env,
pinned_versions=case.pinned_versions,
)
trace = await self.traces.get_complete(run.trace_id)
final_state = await env.snapshot()
results = []
for grader_ref in case.graders:
grader = self.graders.resolve(grader_ref)
results.append(
await grader.grade(case, run, trace, final_state)
)
return aggregate_with_hard_gates(case, results)

12.1 Isolation#

每个 Case 独立环境 namespace、seed、clock、quota;禁止跨 Case cache/state 污染。

12.2 Repetitions#

概率任务运行 N 次,固定与变化 seed 分开报告。

12.3 Failure Capture#

保存最小复现:Case/version/seed/trace refs/environment diff/grader results。


13. Failure Taxonomy 与归因#

编号层级失败
F01Inputintent 错
F02Inputslot/clarification 错
F03Context缺必要事实/记忆
F04RAG未召回/错版本/越权
F05Plan依赖/步骤/循环错
F06Tool选择错
F07Tool参数错
F08Execution超时/重试/副作用错
F09State迁移/恢复/并发错
F10Decision责任/动作错
F11Verificationfalse pass/未验证
F12Safety越权/泄漏/注入
F13Output不忠实/格式/引用错
F14System成本/延迟/可用性超限

13.1 First Divergence#

找到相对预期不变量的第一个偏离,而不是把后续所有错误归因给最终模型。

13.2 Causal Caution#

Trace 显示先后关系不自动证明因果。通过重放、替换 Oracle 模块、消融或反事实 Case 验证。

13.3 Responsibility#

Prompt/Model
Context/Retriever
Tool/Adapter
Workflow/Runtime
Policy/Data
Evaluator/Test

Evaluator 自身错误必须成为分类,否则系统会为错误评分器“优化”。

13.4 Diagnosis Playbook#

1. 环境终态错?
2. 找 first divergent invariant
3. 对应 Span/State diff
4. 检查上游必要输入是否存在
5. 用 Oracle 替换怀疑模块重放
6. 最小化 Case
7. 分类 root cause 与 contributing factors
8. 修复后跑局部 + 全量回归

13.5 Oracle Substitution#

Oracle Context + original Planner
original Context + Oracle Planner
Oracle Tool Result + original Decision
original Trace + Oracle Verifier

如果替换某模块后问题消失,它是强线索;仍需检查接口契约和下游鲁棒性。

13.6 State Diff#

{
"node": "verify_eligibility",
"expected": {"policy_ids": ["R001"], "product_type": "normal"},
"actual": {"policy_ids": ["R001"], "product_type": null},
"first_missing_field": "product_type",
"source_node": "query_order_adapter"
}

State Diff 比读完整 transcript 更快定位责任边界。


14. 统计与比较#

14.1 Paired#

同一 Case/seed 跑 baseline/candidate,比较配对差异。

14.2 Confidence Interval#

对率、均值、分位数采用适当 bootstrap/统计方法;低频安全事件需要更多 Case 或零容忍门禁。

14.3 Multiple Slices#

scenario
risk
language
tool
error type
tenant class
sequence length

14.4 Regression Budget#

核心成功率不得降
critical safety 必须 100% pass
p95 latency/cost 有预算
长尾可接受 trade-off 需 Owner 批准

14.5 Statistical vs Practical#

显著的 0.2% 提升可能不抵成本;不显著的单个 critical 漏洞也必须阻断。


15. Eval as CI Gate#

15.1 Change Matrix#

变更最小回归
Prompttask + output + safety
Model全 Golden/OOD/成本
Tool Schemacontract + trajectory
Policy决策表 + adversarial
RAG Indexretrieval/citation
Memory Policywrite/read/delete
Workflowgraph/recovery/trajectory
Evaluatorcalibration + historical replay

15.2 Gate#

hard:
critical_safety_pass: 1.0
unauthorized_data_exposure: 0
duplicate_side_effect: 0
schema_validity_gte: 0.999
soft:
task_success_delta_gte: -0.005
cost_per_success_delta_lte: 0.10
p95_latency_delta_lte: 0.10

15.3 Flaky#

概率 Eval 不应用“失败就重跑直到过”。记录 first run、重复分布、flaky rate;超过阈值隔离并修复 Case/系统。

15.4 Fast/Full/Nightly#

PR fast smoke
merge full golden/regression
nightly multi-seed/adversarial/OOD
release shadow/canary

16. Online Evaluation#

16.1 Shadow#

候选读取真实脱敏输入但不执行副作用,比较决策/轨迹。

16.2 Canary#

小流量真实执行,限制低风险/只读或强 HITL,监控硬安全和业务指标。

16.3 Sampling#

random baseline
100% errors/security/high-risk
uncertainty/disagreement
new model/tool/policy version
long/high-cost traces

16.4 Feedback#

explicit user correction
human override
tool/environment outcome
support ticket
model judge(辅助)

16.5 Delayed Outcome#

有些任务数天后才知道是否解决。用 outcome join pipeline 将 Run 与退款完成、工单重开、用户复联关联,避免只评即时回复。

16.6 Drift#

监控 input/intent/tool/error/latency/cost/outcome 分布变化;Drift 触发分析和新 Case,不自动判定模型退化。

16.7 在线对照#

按用户/租户稳定分桶,避免一次会话跨版本
记录 eligibility/exposure
避免共享缓存/人工 Reviewer 污染
预定义主/护栏指标和停止规则

高风险 Agent 通常先 Shadow,再限制读操作 Canary;不为实验随机开放危险能力。

16.8 Sequential Monitoring#

持续查看数据并随时宣布胜出会增加假阳性。使用预先定义的样本/时长或合适 sequential 方法,并保留安全 kill switch(安全事件不受实验显著性约束)。

16.9 Human Review Queue#

分层:

critical safety immediately
model/judge disagreement
unknown/new failure
random quality sample

记录 Reviewer、rubric version、耗时和 override;监控积压与 reviewer drift。


17. Failure-to-Dataset 闭环#

Online Failure
-> Triage
-> Minimal Reproduction
-> Root Cause/Failure Code
-> Fix
-> Regression Case
-> Offline Eval
-> Shadow/Canary
-> Monitor

17.1 Minimal Reproduction#

去除无关 PII/上下文,保留导致失败的版本、状态和事件。

17.2 Dedup#

按 failure signature 聚类,避免同一事故生成数千重复 Case。

17.3 Severity#

Critical Case 永久进入硬门禁;低价值偶发样本可进入统计集。

17.4 Closure#

Incident 关闭条件包括修复上线、回归通过、线上指标恢复,而不是只提交代码。


18. 大厂与开源方案对照#

方案公开能力可借鉴仍需自建
OpenAI Evals/Trace Gradinggrader、dataset、trace gradingtrajectory eval 与持续评估业务环境 Oracle
Anthropic Agent Evalsagent eval 方法、transcript/behavioroutcome + process 分析领域 rubric/data
Google ADK/Vertex Evallocal eval、trajectory/final response、托管模型评估SDK/云评估业务状态与安全
Microsoft Azure AI Evaluationquality/safety/evaluator企业评估流程工具/环境轨迹
LangSmithdataset、experiment、online eval、tracetracing/eval workflow领域不变量
RagasRAG/agent/tool metrics自动指标组件Gold/业务终态
MLflow/Phoenix/Langfusetrace、eval、monitor、experiment开放可观测与实验Audit/Policy
OpenTelemetry GenAI供应商中立 semantic conventionsSpan/metric 互操作规范仍 Development

官方入口见 [S1][S6]


19. Benchmark 如何正确使用#

19.1 用途#

理解能力维度
复用环境/指标思想
做模型/框架初筛
发现测试盲区

19.2 不能证明#

你的业务规则正确
你的权限安全
你的工具稳定
你的成本/SLO 可接受
你的数据分布表现

19.3 Contamination#

公开 Benchmark 可能进入模型训练。不要把分数当唯一能力证据;建立私有 Holdout、时间切分和变体 Case。

19.4 Environment Version#

Benchmark 环境/依赖/网站改变会影响结果。固定 commit/container/fixture,并报告失败是 Agent 还是环境。

19.5 Benchmark-to-Business Mapping#

Benchmark capability -> 业务能力假设 -> 本地 Case -> 环境成功条件

例如 ToolSandbox 的状态工具能力可启发多轮工具测试,但不能替代退款权限和金额规则。

19.6 Leaderboard Reproduction#

记录模型版本、Prompt、工具接口、采样次数、环境 commit、超时和失败处理。若无法复现公开结果,先报告差异,不选择性重跑最佳样本。


20. 常见反模式#

20.1 “回答看起来不错”#

没有标准、数据集和环境断言,无法回归。

20.2 Exact Trajectory Only#

把合法并行/顺序变体误判失败;应使用偏序与不变量。

20.3 只用 LLM Judge#

权限、金额、Schema、数据库状态应确定性评估。

20.4 Eval Set 与训练/调参泄漏#

分数虚高,无法反映未来。

20.5 只看平均分#

掩盖 critical safety 与长尾退化。

20.6 Trace Everything#

PII/Secret/成本爆炸;需分类、脱敏、采样和受控引用。

20.7 CI 失败就重跑#

隐藏概率退化;应测 flaky rate 和分布。

20.8 线上失败不回流#

同类问题反复出现,Eval 与真实分布脱节。


21. 项目目录与实践任务#

eval/
schemas/
case.py
trajectory.py
result.py
datasets/
golden.jsonl
adversarial.jsonl
regression.jsonl
long_tail.jsonl
graders/
exact.py
schema.py
trajectory.py
environment.py
safety.py
model_judge.py
runner.py
aggregation.py
statistics.py
report.py
observability/
events.py
tracing.py
metrics.py
redaction.py
sampling.py
ops/
failure_collector.py
online_eval.py
ci_gate.py
tests/
graders/
eval_runner/
trace_contract/
docs/
eval_strategy.md
failure_taxonomy.md
telemetry_policy.md

实践顺序:

1. 定义 20-50 个核心 Scenario 与环境断言
2. 建 Case/Trajectory/Result Schema
3. 先写 deterministic/environment graders
4. 加偏序/不变量 trajectory grader
5. 校准 model judge
6. 建 Golden/Adversarial/Regression
7. 统一 Run/Span/Event 与版本字段
8. 接入 PR/full/nightly CI Gate
9. 做 shadow/canary/online sampling
10. 建 failure -> regression 闭环

22. 达标检查清单#

Contract/Dataset#

  • 成功条件在系统实现前定义;
  • Case 固定环境与全部关键版本;
  • 同时表达 expected、allowed trajectory 与 forbidden;
  • Golden/Adversarial/Regression/Long-tail 分离;
  • Dataset 有来源、cutoff、rubric 和 digest。

Grading#

  • 环境终态优先于文本自评;
  • 轨迹支持多条合法路径和偏序;
  • 安全/权限/副作用是 Hard Gate;
  • Model Judge 有人工校准、abstain 和版本;
  • Evaluator 错误进入 Failure Taxonomy。

Observability#

  • Trace 关联 Agent/Model/Prompt/Tool/Policy/Index/Memory 版本;
  • 异步/跨 Agent 用 Link/Task ID 关联;
  • PII/Secret 默认不记录;
  • 高基数字段不进入公共 Metric Label;
  • Trace、Eval、Audit 的保留和权限分离。

CI/Online#

  • PR/full/nightly/release 分级;
  • 概率 Eval 不通过重跑掩盖;
  • 报 paired delta、置信区间和风险切片;
  • Online 采样覆盖错误、高风险、漂移和新版本;
  • 每个重要失败都有最小回归 Case 和关闭证据。

23. 面试与架构评审问题#

  1. Test、Eval、Observability、Audit 有什么区别?
  2. 为什么最终答案正确仍可能任务失败?
  3. Exact trajectory 与 partial order 如何选择?
  4. Environment Grader 为什么通常比 LLM Judge 更可靠?
  5. LLM-as-a-Judge 有哪些偏差,如何校准?
  6. Trace 应记录哪些版本,哪些敏感内容不应记录?
  7. 如何找到一次失败的 first divergence?
  8. 为什么 Eval 结果需要 paired comparison 与风险切片?
  9. 概率性 CI 如何处理 flaky?
  10. 在线任务几天后才有结果,如何评估?
  11. Benchmark 分数为什么不能替代业务 Eval?
  12. 如何把一次线上事故变成永久回归资产?

24. 参考资料与延伸阅读#

以下资料用于核对公开评估方法、平台能力、语义规范和 Benchmark。Evaluator、SDK 与云服务会演进;生产报告需固定版本。

官方 Eval 与 Observability#

[S1] OpenAI Evals 与 Trace#

[S2] Ragas 与 LangSmith#

[S3] OpenTelemetry GenAI#

[S4] Anthropic Agent Evals#

[S5] Google 与 Microsoft#

[S6] Observability 与 Eval 平台#

Benchmark 与 Judge 研究#

[P1] AgentBench#

[P2] GAIA#

[P3] WebArena#

[P4] SWE-bench#

[P5] τ-bench#

[P6] LLM-as-a-Judge#

[P7] G-Eval#

[P8] Agent-as-a-Judge#

[P9] ToolSandbox#

[P10] AgentDojo#

  • Debenedetti et al., AgentDojo, NeurIPS 2024 Datasets and Benchmarks。

25. 阶段总结#

成熟的 Agent 评估闭环是:

先定义业务成功和禁止结果;
再记录可复现的状态与版本;
用环境、规则、轨迹、模型和人工分层评估;
用 Trace 找 first divergence;
用 Failure Taxonomy 归因;
把修复变成 Regression Case;
通过 CI、Shadow、Canary 和 Online Eval 持续验证。

最终报告不应只写一个“准确率”,而应同时回答:

任务是否真的完成?
哪一步首先出错?
是否越权或产生副作用?
证据与引用是否充分?
有多少合法路径通过?
成本和延迟是多少?
相比上一版本改变了什么?
失败能否复现并永久回归?

做到这些,Agent 才从“感觉不错的 Demo”变成可量化、可诊断、可发布和可持续改进的工程系统。

Agent 评估、测试集与可观测性:从最终答案到轨迹级归因
https://jupiter-ws.cn/posts/agent/agent-evaluation-observability/
作者
Jupiter
发布于
2026-04-23
许可协议
CC BY-NC-SA 4.0