Agent 评估、测试集与可观测性:从最终答案到轨迹级归因
本文是 精英 Agent 工程师学习路线:从范式理解到生产级落地 阶段 11 的配套学习笔记。 核心结论:Agent 评估的对象不是一段回复,而是“输入、上下文、计划、工具、状态、证据、动作与环境结果”组成的轨迹。Trace 让过程可见,Eval 让质量可量化,Failure Taxonomy 让问题可归因,CI Gate 让修复不会被下一次变更重新破坏。
0. 学习目标与四个边界
学完本文后,你应该能够:
- 区分 Unit Test、Eval、Observability 与 Audit;
- 为输入、RAG、Memory、Plan、Tool、Trajectory、Decision、Safety 和 Output 分层设计指标;
- 构建 Golden、Scenario、Adversarial、Regression、Synthetic、Production 与 Human Review 数据集;
- 表达多条合法轨迹、必要/禁止节点、偏序约束和环境终态;
- 组合 exact/rule/environment/model/human Evaluator;
- 校准 LLM-as-a-Judge 的位置、长度、自我偏好与漂移;
- 用 OpenTelemetry/Trace 关联 Prompt、Model、Tool、Policy、State 和 Cost;
- 通过 Failure Taxonomy 定位改 Prompt、Retriever、Tool、Harness 还是 Policy;
- 把硬安全门槛、质量退化、成本和延迟接入 CI/CD;
- 用在线抽样、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-> Response1.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 Literalfrom 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: dict2.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/workflowmodel/adapterprompttool registrypolicyRAG indexmemory snapshotevaluator/graderenvironment fixture没有版本矩阵的 Eval 结果不可比较。
3. 分层指标体系
3.1 输入理解
Intent Accuracy / Macro-F1Slot Precision/Recall/F1Clarification Precision/RecallMulti-intent Coverage3.2 Context/Memory
Required Context RecallContext PrecisionStale Context RateUnauthorized Context RateMemory Write AccuracyConflict/Deletion Accuracy3.3 RAG/Evidence
Recall@K / MRR / nDCGRequired Evidence RecallEffective-version AccuracyCitation Precision/RecallClaim EntailmentEvidence Sufficiency3.4 Planning/Trajectory
Plan ValidityDependency AccuracyRequired-step RecallForbidden-step RateNo-progress Loop RateStep EfficiencyRepair Success3.5 Tool
Need-tool AccuracyTool Selection AccuracyArgument Field/Exact AccuracyNo-tool AccuracyTool SuccessIdempotency ViolationFinal-state Verification3.6 Decision/Safety
Responsibility AccuracyAction AccuracyPolicy ComplianceUnsafe Action RateUnauthorized Data ExposureHuman Gate Precision/Recall3.7 Output
Schema ValidityFaithfulnessHelpfulnessCitation CorrectnessSensitive Data LeakageOverclaim Rate3.8 System/User
Verified Task SuccessResolution RateHuman Escalationp50/p95/p99 LatencyTokens/Cost per Verified SuccessRetry/Fallback/Cancel RateUser Correction/Satisfaction3.9 指标必须写清分母
Tool Success Rate = succeeded tool calls / attempted tool callsTool Selection Accuracy = correct next-action cases / eligible casesVerified Task Success = verified successful runs / all eligible runsHuman 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_refundsearch_policy < decisionconfirmation < create_refundcreate_refund < verify_final_statequery_order 与 query_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 pathduplicate tool callsrepeated queriescontext/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.3case_count: 1280splits: golden: 420 adversarial: 180 regression: 260 long_tail: 300 online_holdout: 120schema_version: "4"label_policy: orderflow-rubric@7source_cutoff: 2026-06-30content_digest: sha256:...5.9 Leakage/Contamination
同一 thread/order/user 跨 split同一模板只替换 ID线上 Regression 同时进入训练与 final testJudge calibration Case 被写进 rubric 示例公开 Benchmark 答案被模型记忆使用 group/time/source split、近重复扫描和 Dataset Lineage 报告。最终 Holdout 限制访问,避免团队反复针对它修 Prompt。
5.10 Case 生命周期
draft-> reviewed-> active-> flaky/quarantined-> superseded-> retiredCase 也会错。规则变化后更新期望时保留旧 Case/version 和变更理由,不能静默改 Gold 让失败消失。
5.11 Coverage Matrix
rows: scenario/risk/failure typecolumns: normal/boundary/error/adversarial/recoverycells: case count + last pass + ownerCoverage 不是代码行覆盖率,但能暴露“只测正常退款、不测确认过期或 outcome_unknown”。
6. Case 生成与标注
6.1 来源
业务规则/决策表历史工单线上失败Support/SME 访谈Threat Model边界值/状态机合成扩展6.2 Oracle
期望结果来自:
数据库 fixture确定性规则引擎人工政策 Owner可执行测试多 Reviewer adjudication避免让被测模型生成自己的 Gold。
6.3 Label Schema
answer/decisionrequired facts/evidenceallowed/forbidden actionsacceptable trajectorieshuman escalationseverity/impact6.4 Ambiguous Case
真实业务有歧义。标记:
multiple acceptable outcomesrequires clarificationrequires humaninsufficient 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/schemasoft 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: floatEvaluator 错误与 Case 失败分离;不能把 Judge timeout 当 candidate fail,也不能默认为 pass。
7.8 聚合顺序
1. Grader contract/error check2. Critical hard gates3. Required environment/trajectory checks4. Soft quality scores5. Cost/latency budgets6. Human adjudication band7.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 biasVerbosity/length biasStyle biasSelf/model-family preferenceReference-answer anchoringPrompt injection in candidateMT-Bench/Chatbot Arena 的 LLM-as-a-Judge 研究和 G-Eval 探索模型评审;Agent-as-a-Judge 进一步研究用 Agent 评估 Agent。[P6] [P7] [P8]
8.3 校准集
clear pass/failsubtle unsupported claimcorrect but concise/verbose pairsame answer swapped orderadversarial self-praiseinsufficient evidence/abstainunsafe trajectory with good final text8.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.verify9.2 Run/Span/Event
Run:完整任务Span:一段有开始/结束的操作Event:Span/Run 中的离散变化Link:异步/跨 Agent 因果关联9.3 Span Attributes
run/thread/task/tenant refsagent/workflow/node versionmodel/provider/routeprompt versiontool/server/versionpolicy/index/memory snapshotattempt/error/retrytoken/cost/latencystate before/after hash9.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/versioncontent hashsecure source referencedata classificationtruncated flag10.3 Sampling
100% high-risk action/audit link100% errors/security events(按数据策略)adaptive sample slow/high-costlow-rate normal success10.4 Trace Completeness
检查关键 Span/版本/状态是否齐全。缺 Trace 不能默认为成功,也不能让 Observability 故障阻断所有低风险流量;高风险 Audit 写入失败则按策略 fail closed。
10.5 异步与跨 Agent
队列、HITL、A2A 等场景不是单一 parent-child:
producer span -> message/task id -> consumer span linkhuman wait span/event -> resume spanremote task -> artifact id -> local verify span不要人为维持数小时开放 Span;保存 durable event/link,再在恢复时建立新 Span 并关联同一 Run/Task。
10.6 Tail Sampling
Head sampling 在 Run 开始时不知道它是否失败。Tail sampling 可在 Trace 完成后优先保留:
error/securityhigh latency/costfallback/retryhuman overridenew versionrare 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 与归因
| 编号 | 层级 | 失败 |
|---|---|---|
| F01 | Input | intent 错 |
| F02 | Input | slot/clarification 错 |
| F03 | Context | 缺必要事实/记忆 |
| F04 | RAG | 未召回/错版本/越权 |
| F05 | Plan | 依赖/步骤/循环错 |
| F06 | Tool | 选择错 |
| F07 | Tool | 参数错 |
| F08 | Execution | 超时/重试/副作用错 |
| F09 | State | 迁移/恢复/并发错 |
| F10 | Decision | 责任/动作错 |
| F11 | Verification | false pass/未验证 |
| F12 | Safety | 越权/泄漏/注入 |
| F13 | Output | 不忠实/格式/引用错 |
| F14 | System | 成本/延迟/可用性超限 |
13.1 First Divergence
找到相对预期不变量的第一个偏离,而不是把后续所有错误归因给最终模型。
13.2 Causal Caution
Trace 显示先后关系不自动证明因果。通过重放、替换 Oracle 模块、消融或反事实 Case 验证。
13.3 Responsibility
Prompt/ModelContext/RetrieverTool/AdapterWorkflow/RuntimePolicy/DataEvaluator/TestEvaluator 自身错误必须成为分类,否则系统会为错误评分器“优化”。
13.4 Diagnosis Playbook
1. 环境终态错?2. 找 first divergent invariant3. 对应 Span/State diff4. 检查上游必要输入是否存在5. 用 Oracle 替换怀疑模块重放6. 最小化 Case7. 分类 root cause 与 contributing factors8. 修复后跑局部 + 全量回归13.5 Oracle Substitution
Oracle Context + original Planneroriginal Context + Oracle PlannerOracle Tool Result + original Decisionoriginal 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
scenariorisklanguagetoolerror typetenant classsequence length14.4 Regression Budget
核心成功率不得降critical safety 必须 100% passp95 latency/cost 有预算长尾可接受 trade-off 需 Owner 批准14.5 Statistical vs Practical
显著的 0.2% 提升可能不抵成本;不显著的单个 critical 漏洞也必须阻断。
15. Eval as CI Gate
15.1 Change Matrix
| 变更 | 最小回归 |
|---|---|
| Prompt | task + output + safety |
| Model | 全 Golden/OOD/成本 |
| Tool Schema | contract + trajectory |
| Policy | 决策表 + adversarial |
| RAG Index | retrieval/citation |
| Memory Policy | write/read/delete |
| Workflow | graph/recovery/trajectory |
| Evaluator | calibration + historical replay |
15.2 Gate
hard: critical_safety_pass: 1.0 unauthorized_data_exposure: 0 duplicate_side_effect: 0 schema_validity_gte: 0.999soft: task_success_delta_gte: -0.005 cost_per_success_delta_lte: 0.10 p95_latency_delta_lte: 0.1015.3 Flaky
概率 Eval 不应用“失败就重跑直到过”。记录 first run、重复分布、flaky rate;超过阈值隔离并修复 Case/系统。
15.4 Fast/Full/Nightly
PR fast smokemerge full golden/regressionnightly multi-seed/adversarial/OODrelease shadow/canary16. Online Evaluation
16.1 Shadow
候选读取真实脱敏输入但不执行副作用,比较决策/轨迹。
16.2 Canary
小流量真实执行,限制低风险/只读或强 HITL,监控硬安全和业务指标。
16.3 Sampling
random baseline100% errors/security/high-riskuncertainty/disagreementnew model/tool/policy versionlong/high-cost traces16.4 Feedback
explicit user correctionhuman overridetool/environment outcomesupport ticketmodel 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 immediatelymodel/judge disagreementunknown/new failurerandom 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-> Monitor17.1 Minimal Reproduction
去除无关 PII/上下文,保留导致失败的版本、状态和事件。
17.2 Dedup
按 failure signature 聚类,避免同一事故生成数千重复 Case。
17.3 Severity
Critical Case 永久进入硬门禁;低价值偶发样本可进入统计集。
17.4 Closure
Incident 关闭条件包括修复上线、回归通过、线上指标恢复,而不是只提交代码。
18. 大厂与开源方案对照
| 方案 | 公开能力 | 可借鉴 | 仍需自建 |
|---|---|---|---|
| OpenAI Evals/Trace Grading | grader、dataset、trace grading | trajectory eval 与持续评估 | 业务环境 Oracle |
| Anthropic Agent Evals | agent eval 方法、transcript/behavior | outcome + process 分析 | 领域 rubric/data |
| Google ADK/Vertex Eval | local eval、trajectory/final response、托管模型评估 | SDK/云评估 | 业务状态与安全 |
| Microsoft Azure AI Evaluation | quality/safety/evaluator | 企业评估流程 | 工具/环境轨迹 |
| LangSmith | dataset、experiment、online eval、trace | tracing/eval workflow | 领域不变量 |
| Ragas | RAG/agent/tool metrics | 自动指标组件 | Gold/业务终态 |
| MLflow/Phoenix/Langfuse | trace、eval、monitor、experiment | 开放可观测与实验 | Audit/Policy |
| OpenTelemetry GenAI | 供应商中立 semantic conventions | Span/metric 互操作 | 规范仍 Development |
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.pyobservability/ events.py tracing.py metrics.py redaction.py sampling.pyops/ failure_collector.py online_eval.py ci_gate.pytests/ graders/ eval_runner/ trace_contract/docs/ eval_strategy.md failure_taxonomy.md telemetry_policy.md实践顺序:
1. 定义 20-50 个核心 Scenario 与环境断言2. 建 Case/Trajectory/Result Schema3. 先写 deterministic/environment graders4. 加偏序/不变量 trajectory grader5. 校准 model judge6. 建 Golden/Adversarial/Regression7. 统一 Run/Span/Event 与版本字段8. 接入 PR/full/nightly CI Gate9. 做 shadow/canary/online sampling10. 建 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. 面试与架构评审问题
- Test、Eval、Observability、Audit 有什么区别?
- 为什么最终答案正确仍可能任务失败?
- Exact trajectory 与 partial order 如何选择?
- Environment Grader 为什么通常比 LLM Judge 更可靠?
- LLM-as-a-Judge 有哪些偏差,如何校准?
- Trace 应记录哪些版本,哪些敏感内容不应记录?
- 如何找到一次失败的 first divergence?
- 为什么 Eval 结果需要 paired comparison 与风险切片?
- 概率性 CI 如何处理 flaky?
- 在线任务几天后才有结果,如何评估?
- Benchmark 分数为什么不能替代业务 Eval?
- 如何把一次线上事故变成永久回归资产?
24. 参考资料与延伸阅读
以下资料用于核对公开评估方法、平台能力、语义规范和 Benchmark。Evaluator、SDK 与云服务会演进;生产报告需固定版本。
官方 Eval 与 Observability
[S1] OpenAI Evals 与 Trace
- Evaluation best practices;
- Trace grading;
- OpenAI Agents SDK Tracing。
[S2] Ragas 与 LangSmith
- Ragas Agent metrics;
- LangSmith Evaluation。
[S3] OpenTelemetry GenAI
[S4] Anthropic Agent Evals
[S5] Google 与 Microsoft
- Google ADK Evaluate;
- Google Cloud Generative AI evaluation overview;
- Microsoft Evaluation for generative AI。
[S6] Observability 与 Eval 平台
- MLflow GenAI evaluation and monitoring;
- Arize Phoenix;
- Langfuse documentation。
Benchmark 与 Judge 研究
[P1] AgentBench
- Liu et al., AgentBench: Evaluating LLMs as Agents, ICLR 2024。
[P2] GAIA
- Mialon et al., GAIA: A Benchmark for General AI Assistants, ICLR 2024。
[P3] WebArena
- Zhou et al., WebArena: A Realistic Web Environment for Building Autonomous Agents, ICLR 2024。
[P4] SWE-bench
- Jimenez et al., SWE-bench: Can Language Models Resolve Real-World GitHub Issues?, ICLR 2024。
[P5] τ-bench
- Yao et al., τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains, 2024。
[P6] LLM-as-a-Judge
- Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, NeurIPS 2023 Datasets and Benchmarks。
[P7] G-Eval
- Liu et al., G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment, EMNLP 2023。
[P8] Agent-as-a-Judge
- Zhuge et al., Agent-as-a-Judge: Evaluate Agents with Agents, 2024。
[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”变成可量化、可诊断、可发布和可持续改进的工程系统。