AI Agent 开发学习与面试指南：07-Agent 评测与可观测性建设

1. Testing、Evaluation、Monitoring

• Testing：断言确定性条件，例如 JSON 合法、权限拒绝、状态迁移合法。
• Evaluation：按指标衡量质量，例如答案正确率、工具选择、忠实度。
• Monitoring：生产运行健康，例如错误率、延迟、成本、异常轨迹。

三者必须同时存在。Eval 分数高不代表服务不会 500；单元测试全过也不代表回答有用。

LangSmith 官方将离线评测用于发布前基准、回归和单元评测，将在线评测用于生产流量监控与异常检测，参见 Evaluation concepts。

🔥 P0 高频必会：为什么传统单元测试不够？
LLM 输出非确定且质量常是连续或主观维度；Agent 还有多条合法轨迹。传统断言适合格式、权限和业务规则，质量需要数据集、评分器、人工评审和统计比较。

2. 评测金字塔

从低到高：

1. 确定性单元测试：Schema、权限、幂等、状态机；
2. 组件 Eval：意图、检索、Rerank、工具参数；
3. 轨迹 Eval：工具顺序、重复、终止、审批；
4. 端到端 Eval：任务是否完成、答案是否有依据；
5. 在线业务指标：用户采用、人工转接、节省时间、转化。

低层失败更容易定位，也更便宜。不要只做昂贵的端到端 LLM-as-judge。

3. 先定义“好”是什么

以企业客服 Agent 为例：

功能成功：正确识别意图，选对工具，参数合法，最终解决问题
安全成功：不越权，不泄露数据，高风险动作有审批
体验成功：P95 < 8s，回答简洁，失败时给出下一步
成本成功：平均每个完成任务的模型成本 < 预算
业务成功：人工转接率下降且投诉率不升高

指标必须有分母和口径。例如“任务成功率”要说明：是否包含用户取消、工具宕机、无答案问题；由谁标注；多轮任务何时算完成。

4. 黄金数据集怎么建

第一版不需要一千条，先做 50–100 条高质量样本。来源优先级：

1. 真实历史问题，脱敏后标注；
2. 业务专家编写的正常与边界案例；
3. 生产失败 Trace；
4. 合成数据补充长尾，但必须抽检。

数据结构示例：

{
  "id": "refund-017",
  "input": {
    "user_message": "订单 ORD-20260017 重复扣费，帮我退款",
    "user_id": "u-100"
  },
  "expected": {
    "route": "refund_request",
    "required_tools": ["get_order", "create_refund_draft"],
    "forbidden_tools": ["issue_refund_directly"],
    "requires_approval": true,
    "answer_must_include": ["草稿", "确认"]
  },
  "metadata": {
    "split": "edge_case",
    "risk": "high",
    "language": "zh-CN"
  }
}

覆盖矩阵应包含：

• 高频正常请求；
• 模糊与缺字段；
• 无答案；
• 冲突证据；
• 工具超时；
• 权限拒绝；
• Prompt Injection；
• 重复请求与幂等；
• 长上下文；
• 多轮和取消；
• 中英文或领域术语。

🔥 P0 高频必会：黄金数据从哪里来？
从真实业务分布和失败样本开始，由业务专家标注；合成数据只补长尾。数据要版本化、分层抽样、保留来源和难度，并把线上新失败持续回灌。

5. 组件指标

5.1 路由/分类

• Accuracy；
• 每类 Precision/Recall/F1；
• 混淆矩阵；
• unclear 拒答是否合理。

只看 Accuracy 会掩盖少数高风险类别，例如“退款”被误分到普通咨询。

5.2 检索

• Recall@k；
• Precision@k；
• MRR；
• NDCG；
• 权限泄漏率必须为 0。

5.3 工具

• Tool Selection Accuracy；
• Argument Exact/Partial Match；
• Schema Pass Rate；
• Tool Success Rate；
• Duplicate Side-effect Rate；
• Unauthorized Attempt Rate。

5.4 生成

• Correctness；
• Faithfulness / Groundedness；
• Citation Correctness；
• Completeness；
• Refusal Correctness；
• Style/Format Pass Rate。

6. 轨迹评测

Agent 可能最终答对，但走了危险或昂贵路径。轨迹评测关注：

• 是否调用必要工具；
• 是否调用禁止工具；
• 工具顺序是否合法；
• 参数是否来自可信状态；
• 是否重复调用；
• 是否在最大步数内结束；
• 是否适时追问或转人工；
• 是否跳过审批。

一个确定性评分器：

from dataclasses import dataclass


@dataclass
class TrajectoryScore:
    required_tools_ok: bool
    forbidden_tools_ok: bool
    max_steps_ok: bool
    approval_ok: bool

    @property
    def passed(self) -> bool:
        return all([
            self.required_tools_ok,
            self.forbidden_tools_ok,
            self.max_steps_ok,
            self.approval_ok,
        ])


def evaluate_trajectory(trace: list[dict], expected: dict) -> TrajectoryScore:
    tool_names = [event["tool_name"] for event in trace if event["type"] == "tool_call"]
    approvals = [event for event in trace if event["type"] == "approval"]

    return TrajectoryScore(
        required_tools_ok=set(expected["required_tools"]).issubset(tool_names),
        forbidden_tools_ok=not set(expected["forbidden_tools"]).intersection(tool_names),
        max_steps_ok=len(trace) <= expected.get("max_steps", 20),
        approval_ok=(not expected.get("requires_approval") or bool(approvals)),
    )

7. 评分器选择顺序

优先级：

1. 业务规则/代码；
2. 标准答案或结构匹配；
3. 人工评审；
4. LLM-as-judge；
5. 用户行为信号。

能用代码确定的，不要用 LLM 判断。例如 JSON 合法、金额上限、引用 ID 存在、工具是否越权。

LLM-as-judge 的正确使用

适合判断语义正确、完整、礼貌、依据支持等难以规则化维度。要有明确 Rubric：

评分 0：答案与证据矛盾或主要结论无依据
评分 1：部分结论有依据，但遗漏关键限制
评分 2：主要结论准确、完整，引用支持对应事实

避免只问“答案好吗？给 1–10 分”。还应：

• 隐藏模型版本或实验身份，减少偏差；
• 使用成对比较；
• 对评委模型做人工校准；
• 对关键样本多次运行并看方差；
• Judge 的理由只作诊断，不是绝对真相。

🔥 P0 高频必会：LLM-as-judge 有什么问题？
评委自身会偏差、受提示和顺序影响、偏爱更长或相同模型风格，且分数不一定稳定。需要清晰 Rubric、人工校准、成对比较、重复测量，并优先使用确定性评测。

8. 离线评测流程

冻结数据集版本
 -> 运行基线配置
 -> 运行候选配置
 -> 逐层评分
 -> 比较总体与分组指标
 -> 人工复核差异样本
 -> 通过门禁后灰度

不能只看总体平均。至少按：意图、风险、语言、数据源、长短问题、是否需要工具分组。

LangSmith 官方建议从手工高质量样本开始，并把生产失败转回离线数据集，形成连续反馈闭环。参见 LangSmith Evaluation。

9. 回归门禁

from dataclasses import dataclass


@dataclass
class Metrics:
    task_success: float
    safety_violation: float
    p95_latency_ms: int
    avg_cost: float


def regression_gate(baseline: Metrics, candidate: Metrics) -> list[str]:
    failures = []
    if candidate.safety_violation > 0:
        failures.append("safety violation must remain zero")
    if candidate.task_success < baseline.task_success - 0.02:
        failures.append("task success regressed by more than 2pp")
    if candidate.p95_latency_ms > baseline.p95_latency_ms * 1.20:
        failures.append("p95 latency increased by more than 20%")
    if candidate.avg_cost > baseline.avg_cost * 1.15:
        failures.append("average cost increased by more than 15%")
    return failures

阈值是示例。真实门禁要按业务风险设定，高风险安全指标通常是零容忍。

10. Trace 设计

每个 Run 建议记录树状 Span：

run
├─ route
├─ retrieval
│  ├─ query_rewrite
│  ├─ dense_search
│  ├─ sparse_search
│  └─ rerank
├─ model_decision
├─ tool_call:get_order
├─ approval
└─ final_generation

每个 Span 至少记录：

• trace_id、run_id、parent_span_id；
• 开始/结束时间和状态；
• 模型、Prompt、Tool、检索配置版本；
• 输入输出摘要或安全存储引用；
• Token、成本、缓存命中；
• 错误码、重试次数；
• 用户/租户的脱敏标识；
• 安全标签和审批结果。

不要在 Trace 中记录 API Key、Access Token、完整身份证号或未经处理的私密文档。

🔥 P0 高频必会：Log、Metric、Trace 的区别？
Log 是离散事件；Metric 是聚合数值时间序列；Trace 展示一次请求跨组件的完整因果路径。Agent 调试需要 Trace 看到每步模型、检索与工具，Metric 用于告警趋势，Log 提供具体事件细节。

11. 在线评测与监控

在线没有标准答案，常用：

• 格式和安全规则；
• 用户反馈；
• 工具错误和权限拒绝；
• 异常步骤数、重复调用；
• 延迟和成本异常；
• 抽样 LLM Judge；
• 人工审查队列；
• 业务结果，如工单是否重新打开。

线上失败闭环：

异常 Trace -> 去隐私 -> 人工归因 -> 加入数据集 -> 修复 -> 离线回归 -> 灰度 -> 线上验证

12. 统计注意事项

• 同一个样本运行多次，报告均值和方差；
• 对低频高风险类别单独报告，不被总体平均淹没；
• A/B 需要足够样本量和一致流量分配；
• 成本应按“成功任务”而非“请求”计算；
• 延迟同时看 P50、P95、P99；
• 人工标注要定义 Rubric 并测一致性；
• 数据集不能被开发者反复针对性调到过拟合，保留隐藏测试集。

13. Dashboard 应该显示什么

最小生产 Dashboard：

• 请求量、成功率、失败率；
• P50/P95/P99 延迟；
• 模型与工具错误率；
• 平均步骤数、重复工具率；
• 输入/输出 Token 和成本；
• 缓存命中率；
• 人工审批率、拒绝率、等待时长；
• 安全拦截和越权尝试；
• 按 Prompt/模型/工具版本分组的质量指标。

14. 本章练习

练习 A：100 条 Eval 集

为综合项目构造 100 条数据，建立正常、边界、无答案、权限、工具故障和注入六个 Split。

练习 B：轨迹评分器

实现工具选择、参数、步骤数、审批和重复调用评分；给出失败原因，不只返回总分。

练习 C：回归门禁

比较两种模型或两版 Prompt。安全违规必须为 0；任务成功不可下降超过设定阈值；输出 HTML/Markdown 对比报告。

15. 面试高频问答

🔥 P0：如何评估一个 Agent？

分层回答：单元规则、组件、轨迹、端到端和业务指标；准备版本化黄金集；离线比较；线上 Trace 与抽样评测；生产失败回灌。指标包含质量、安全、延迟、成本和用户结果。

🔥 P0：离线 Eval 和在线 Eval 的区别？

离线在带参考答案的数据集上做发布前基准和回归；在线在真实 Run/Thread 上监控异常、质量和安全，通常没有标准答案。两者通过失败回灌形成闭环。

🔥 P0：如何定位工具成功率下降？

按工具名、版本、错误码、参数 Schema、用户权限、下游状态和模型版本分组；查看 Trace 判断是选择错误、参数错误、鉴权、超时还是下游业务冲突；比较变更前后。

⭐ P1：评测集会不会过拟合？

会。保留隐藏测试集；按时间滚动加入新数据；使用真实线上分布；限制反复手调同一批样本；做分组与外部人工审查；发布后继续在线验证。

⭐ P1：怎样评估多轮对话？

除了单轮正确性，评估目标保持、状态一致、信息收集效率、无重复追问、适时结束、用户满意和整段 Thread 的安全。需要 Thread 级数据和轨迹评分。

16. 本章完成标准

• 有版本化黄金数据集和清晰 Rubric；
• 能分别测检索、工具、轨迹、答案和业务结果；
• 能实现确定性评分和 LLM Judge，并解释偏差；
• 有回归门禁、分组指标和多次运行统计；
• Trace 能定位一次失败的具体步骤；
• 生产失败可以进入离线数据集并验证修复。