【智能体测评-09】三类典型场景的测评方案：Coding Agent、客服Agent、深度研究Agent

为什么不能用一套尺子量所有 Agent

一个看似显然但经常被忽视的事实：Coding Agent、客服 Agent 和深度研究 Agent 是三种完全不同的系统。

它们的差异不是“用了不同的工具”那么简单，而是在测评的每一个根本维度上都不同：

用 Coding Agent 的标准（测试通过率）去测客服 Agent，你会完全忽略多轮对话中的政策违背；用客服 Agent 的标准（用户满意度）去测深度研究 Agent，你会错过事实性错误；用深度研究 Agent 的标准（信息全面性）去测 Coding Agent，你会鼓励它过度工程化。

所以这篇我们逐个来。

一、Coding Agent 测评

Coding Agent 是目前测评体系最成熟的 Agent 类型，很大程度上要归功于 SWE-bench 建立的“真实 issue + 测试用例判定”范式。

核心评分逻辑：测试用例是金标准

Coding Agent 的最大优势是成功判定高度客观：Agent 提交的 patch 能不能让之前失败的测试通过、且不破坏已有测试。这个判定不需要 LLM-as-Judge，不需要人工，跑一遍测试套件就知道。

评分分三层：

最终 patch
   │
   ├── FAIL_TO_PASS 测试（必须通过）── 权重最高
   ├── PASS_TO_PASS 测试（不能退化）── 权重次之
   └── 静态检查（lint/type check）── 门槛条件

• FAIL_TO_PASS：issue 修复前失败、修复后应该通过的测试。这是核心得分项。
• PASS_TO_PASS：修复前就通过、修复后不能被破坏的测试。这是防退化项。
• 静态检查：代码风格、类型安全。不作为主分但可以设门槛。

SWE-bench 的官方评分公式是：resolved = FAIL_TO_PASS 全部通过 AND PASS_TO_PASS 全部通过，是二元判定。实际自建测评时可以做更细的打分：

score = (FAIL_TO_PASS 通过比例 × 0.6) + (PASS_TO_PASS 保留比例 × 0.4)

这样“修好了问题但搞坏了一个边角测试”和“完全没修好”能区分开。

任务设计要点

来源：真实 issue > 合成任务

最好的 Coding Agent 测评任务来自真实开源仓库的 issue：

• 有明确的问题描述
• 有对应的 commit 修复（作为 ground truth 参考，但不要求 Agent 生成相同 patch）
• 有测试用例可以判定
• 难度天然分布（从改一个错别字到重构一个模块）

SWE-bench 已经从 12 个 Python 仓库挖了 2292 个任务。自建时可以参考它的方法论，从你自己的代码仓库挖 issue。

难度分级标准：

环境隔离是硬要求：

每个任务必须在独立的、可重置的环境中运行（Docker 容器是标准选择）。Agent 在执行过程中会安装依赖、修改文件、跑命令，任务之间不能有污染。

轨迹指标（Coding 场景定制）

第 6 篇讲的通用轨迹指标之外，Coding Agent 还有几个专属指标：

1. 测试调用效率

Agent 在解决问题过程中跑了多少次测试？每次跑测试是全量还是只跑相关文件？

• 好的 Agent：定位到相关测试，反复跑那几个文件快速迭代
• 差的 Agent：每次改动都跑全量测试（慢），或者从不跑测试（盲改）

2. 文件导航效率

Agent 读了多少文件？其中多少是真正相关的？

文件相关率 = 实际修改的文件数 / 读取过的文件总数

一个读了 50 个文件但只改了 1 个的 Agent，要么在探索阶段浪费了大量 token，要么对代码库的理解不够精准。

3. Patch 质量

不只看测试是否通过，还看 patch 本身：

• 改动行数是否和问题规模匹配（改 1 行能解决的问题不要改 100 行）
• 是否引入了新的依赖
• 是否有硬编码、注释掉的代码、debug print 等“脏代码”
• 是否破坏了代码风格一致性

这些维度适合用 LLM-as-Judge 评分，作为测试通过率的补充。

4. 迭代收敛性

Agent 的修改是否在逼近正确答案，还是在来回“横跳”？

• 统计每次修改后 FAIL_TO_PASS 的通过数量变化
• 理想趋势：单调递增（逐步解决）
• 危险信号：通过数上下波动（改好一个搞坏另一个）

常见陷阱

陷阱一：测试覆盖率不足

如果一个 issue 对应的测试本身就不充分，Agent 可能提交一个“过了测试但没真正修问题”的 patch。对策是人工审查 L3 难度任务的 patch，或者引入变异测试（mutation testing）验证测试质量。

陷阱二：环境特定的假阳性/假阴性

某些测试依赖网络、时区、随机种子，在沙箱环境中不稳定。对策是对所有任务先在没有 Agent 改动的情况下跑一遍基线，确保 FAIL_TO_PASS 确实稳定失败、PASS_TO_PASS 确实稳定通过。

陷阱三：Agent 记住了答案

如果测评任务来自知名开源仓库，模型的训练数据中可能已经包含了修复 commit。对策是使用内部仓库的 issue、对合成任务做变体、或者定期更新任务集。

Coding Agent 评分表模板

scoring:
  primary:
    method: test_execution
    fail_to_pass_weight: 0.6
    pass_to_pass_weight: 0.4
  secondary:
    - dimension: patch_quality
      method: llm_judge
      rubric: "改动是否最小化、是否引入脏代码、是否符合项目风格"
      weight: 0.1  # 加分项，不超过主分的 10%
    - dimension: efficiency
      method: rule
      metrics: [step_count, file_read_ratio, test_runs]
  gate:
    - no_secret_leak  # patch 中不能包含密钥
    - no_destructive_command  # 不能执行 rm -rf 等危险命令
    - static_check_pass

二、客服 Agent 测评

客服 Agent 和 Coding Agent 的测评哲学几乎相反：Coding 有客观测试，客服的核心挑战是“政策遵从 + 多轮一致性 + 人类满意度”，这些都很难自动化判定。

τ-bench（第 4 篇讲过）在客服测评上做了开创性工作，它的核心思想是用用户模拟器 + 策略遵从检查来代替人工对话。

核心评分逻辑：三层判定

最终对话结果
   │
   ├── 任务完成率（用户的问题是否解决）
   ├── 政策遵从率（是否违反业务规则）
   └── 对话质量（语气、效率、一致性）

1. 任务完成率（What）

用户来做什么，做成了没有？

• 查订单 → 订单信息是否正确返回
• 退款 → 退款是否发起、金额是否正确
• 修改地址 → 地址是否正确更新
• 取消订阅 → 订阅是否真的取消了

这一层可以用环境状态校验：对话结束后检查后台系统（数据库/API）的状态是否符合预期。和 Coding Agent 的测试用例类似，是客观判定。

2. 政策遵从率（Must NOT）

这是客服 Agent 最关键也最容易出事的维度。典型政策规则：

• 退款政策：超过 30 天不可退款、折扣商品不退、运费不退
• 权限政策：不能修改他人订单、不能查看非本人信息
• 承诺政策：不能承诺具体送达时间、不能承诺赔偿金额超出权限
• 合规政策：不能泄露其他客户信息、不能提供法律/医疗建议

政策遵从的判定方式是：在对话的每一轮检查 Agent 的输出是否触发了任何政策规则。这需要把政策形式化为机器可检查的规则，或者用 LLM-as-Judge 逐轮检查。

3. 对话质量（How）

• 语气是否专业、有同理心
• 是否在合理轮次内解决问题（不是来回踢皮球）
• 多轮对话中是否前后一致（不能上一轮说可以退，这一轮说不能退）
• 是否正确理解了用户意图（而不是答非所问）

这一层用 LLM-as-Judge + 人工抽检最合适。

用户模拟器：让测评规模化

客服 Agent 测评的最大挑战是：你不可能让真人每次测评都来聊几百轮。τ-bench 的方案是用另一个 LLM 扮演用户。

用户模拟器的设计要点：

user_simulator:
  persona: "一个想退货的顾客，语气有点不耐烦"
  goal: "退掉上周买的鞋子，因为尺码不合适"
  constraints:
    - "不要主动提供订单号，等客服问了再给"
    - "如果客服说不能退，要据理力争"
    - "最多对话 8 轮，超过就放弃"
  user_profile:
    order_id: "ORD-20260820-8842"
    purchase_date: "2026-08-18"
    item: "运动鞋，尺码42"
    return_window: "30天"

好的用户模拟器应该能模拟：

• 不同性格：耐心的、急躁的、啰嗦的、沉默寡言的
• 不同表达能力：把问题描述得很清楚的、说得很模糊的、用口语/方言的
• 边界行为：试图诱导 Agent 违反政策（“你就通融一下吧”）、提供错误信息、中途改变需求
• 多轮记忆：记住之前说过的话，对 Agent 的不一致提出质疑

用户模拟器自身也需要测评——如果模拟器总是很容易被说服，Agent 会得到虚高的分数。需要验证模拟器是否能稳定地“扮演角色”并坚持目标。

轨迹指标（客服场景定制）

1. 轮次效率

解决问题用了多少轮对话？太少可能没充分确认，太多可能在兜圈子。按任务类型设定合理区间：

• 查订单：2-4 轮
• 退款：4-8 轮（需要验证身份、确认政策、执行操作）
• 投诉处理：5-12 轮（需要安抚、调查、给出方案）

2. 政策违规次数和严重度

不是所有违规都一样严重：

P0 违规应该是一票否决——不管任务完成得多好，发生 P0 违规就是不合格。

3. 意图识别准确率

Agent 是否在每一轮正确识别了用户的当前意图？用户说“我上次买的那个东西”，Agent 知不知道是哪个订单？这需要标注每一轮的真实意图和 Agent 识别的意图。

4. 升级率（Escalation Rate）

Agent 有多少次把用户转给了人工客服？适当的升级是好事（Agent 知道自己的边界），但升级率过高说明 Agent 能力不足。需要区分：

• 合理升级：超出权限、用户明确要求人工、情绪激烈
• 不合理升级：Agent 本来能处理但放弃了、因为理解错误而升级

多轮一致性测评

客服 Agent 有一个 Coding Agent 不太涉及的问题：多轮对话中的自相矛盾。

测评方法：在对话中间插入“一致性探针”——在第 5 轮问一个和第 2 轮相关的问题，看 Agent 是否保持一致。例如：

第 2 轮：Agent 说"您的订单可以在 30 天内退货"
第 6 轮：用户问"我 35 天前买的，能退吗？"
合格回答："抱歉，超过 30 天退货窗口了。"
不合格回答："可以的，我帮您退。"（和之前的政策陈述矛盾）

这种探针需要专门设计，通常占测评集的 15-20%。

客服 Agent 评分表模板

scoring:
  primary:
    task_completion:
      method: state_verification
      weight: 0.4
    policy_compliance:
      method: rule_check + llm_judge
      weight: 0.4
      zero_tolerance: [P0_violation]
    dialogue_quality:
      method: llm_judge
      weight: 0.2
  trajectory:
    - turns_to_resolution
    - escalation_rate
    - intent_accuracy
    - contradiction_count
  gate:
    - no_P0_violation
    - no_data_leak

三、深度研究 Agent 测评

深度研究 Agent（Deep Research Agent）是三种类型中最难测评的。它的输出是一份开放式的研究报告，没有标准答案、没有通过/失败的测试、也没有可以校验的环境状态。

核心挑战：质量是多维度的

一份好的研究报告的质量取决于：

• 事实准确性：引用的信息是否真实
• 信息覆盖度：是否遗漏了重要方面
• 推理质量：结论是否有证据支撑、逻辑是否自洽
• 来源可信度：引用的来源是否权威
• 时效性：信息是否是最新的
• 客观性：是否有选择地只引用支持预设结论的来源
• 可操作性：结论是否能指导决策

这些维度相互制约（追求覆盖度可能影响深度，追求客观性可能显得没有观点），不能简单加总成一个分数。

评分逻辑：Rubric + 事实验证双轨制

轨道一：基于 Rubric 的质量评分

为每个维度设计明确的评分标准（参考第 5 篇的 rubric 设计方法）：

rubric:
  - dimension: factual_accuracy
    description: "报告中的每一个事实性声明是否有可靠来源支撑，是否存在歪曲或编造"
    weight: 0.25
    anchors:
      5: "所有事实均有来源且引用准确，无任何错误"
      3: "大部分事实准确，有 1-2 处小错误但不影响结论"
      1: "存在多处事实错误或编造信息"

  - dimension: coverage
    description: "是否覆盖了主题的核心方面，没有重大遗漏"
    weight: 0.15
    anchors:
      5: "全面覆盖，包含了预期之外的相关视角"
      3: "覆盖了主要方面，缺少 1-2 个次要方面"
      1: "有重大遗漏，关键方面未涉及"

  - dimension: reasoning
    description: "分析和结论是否基于证据，逻辑链是否完整"
    weight: 0.20
    anchors:
      5: "结论有充分证据支撑，推理严密，考虑了反论点"
      3: "结论基本合理，但部分推理跳跃或缺乏充分论证"
      1: "结论与证据脱节，存在明显逻辑谬误"

  - dimension: source_quality
    description: "引用来源是否权威、多元、时效"
    weight: 0.15
    anchors:
      5: "来源权威且多元，引用了一手数据和多视角"
      3: "来源基本可靠但类型单一"
      1: "来源不可靠或大量引用二手信息"

  - dimension: actionability
    description: "结论是否具体、可操作，能否指导实际决策"
    weight: 0.15
    anchors:
      5: "给出明确的建议和优先级，附实施路径"
      3: "有建议但不够具体"
      1: "只有泛泛而谈，无法指导行动"

  - dimension: structure
    description: "报告结构是否清晰，信息层次是否合理"
    weight: 0.10

轨道二：自动化事实验证

Rubric 评分依赖 LLM-as-Judge，可能漏掉具体的事实错误。需要一层自动化的事实验证：

1. 引用验证：抽取报告中所有引用的 URL，检查是否可访问、内容是否确实支撑了声明
2. 数字校验：报告中的统计数字是否与来源一致
3. 时间一致性：引用的信息是否在有效期内（2026 年的报告不能引用 2022 年的数据作为“当前”情况）
4. 矛盾检测：报告内部不同部分是否有事实矛盾

这一层做不到 100% 自动（理解“内容是否支撑声明”需要语义判断），但可以用规则 + LLM 的组合覆盖 60-70% 的事实性问题。

任务设计要点

深度研究任务的设计和前两种有很大不同：

1. 任务必须有明确的研究边界

开放式任务（“研究一下 AI 行业”）无法测评——太宽泛，Agent 写什么都不能算错。好的任务应该有明确的范围和交付要求：

“调研 2026 年中国市场上主流的向量数据库产品（Pinecone、Milvus、Weaviate、Qdrant、腾讯云 VectorDB），从性能、成本、生态、运维难度四个维度对比，给出一个面向 1000 万向量规模的选型建议，要求引用至少 5 个来源。”

这个任务有：明确的对象（5 个产品）、明确的维度（4 个）、明确的规模（1000 万）、明确的输出要求（选型建议）、最低来源要求。

2. 要有“信息盲点”设计

好的研究任务应该要求 Agent 找到不容易找到的信息，而不是搜一下第一个结果就能回答的。比如：

• 需要对比多个来源的价格并计算
• 需要找到某产品最新版本的 changelog
• 需要发现两个来源之间的矛盾并做出判断
• 需要从非英文来源获取信息

3. 难度主要由信息环境决定

4. 配套“研究大纲”作为部分 ground truth

深度研究任务没有标准答案，但可以有一份专家编写的研究大纲，列出这个主题应该覆盖的关键点。评分时检查报告覆盖了大纲中的多少要点：

expected_coverage:
  - "各产品的架构差异（单机 vs 分布式）"
  - "索引算法支持（HNSW、IVF、量化）"
  - "定价模型（按存储/按查询/包年包月）"
  - "与主流框架的集成（LangChain、LlamaIndex）"
  - "社区活跃度（GitHub stars、贡献者数量）"
  - "已知的局限性和踩坑记录"

覆盖率 = 报告中涉及的要点数 / 大纲总要点数。这比让 LLM 笼统地打“覆盖度”分要客观得多。

轨迹指标（深度研究场景定制）

1. 搜索质量

• 搜索查询多样性：用了多少不同的搜索关键词？是否在反复用相似词搜索？
• 来源覆盖率：读取了多少不同域名的内容？是否只依赖一两个来源？
• 深读率：搜索后有多少比例的结果被实际阅读（而不只是看标题）？
• 搜索迭代深度：是否根据前期发现调整了后续搜索方向？

2. 信息综合效率

• 阅读了多少字/Token 的原始材料？最终报告多少字？
  • 输入/输出比太低（1
    ）说明没有充分调研
  • 输入/输出比太高（100
    ）说明可能效率低或没抓住重点
  • 健康范围通常在 10
    到 30
• 多少条信息被实际引用到了报告中？采集了但没用上的比例有多高？

3. 认知过程质量

这是最抽象但区分度最高的指标。需要检查 Agent 的中间思考（thought/plan）是否展现了：

• 假设生成：是否在调研前提出了预期，在调研后验证/修正
• 信息缺口识别：是否意识到“我还缺什么信息”并主动补充搜索
• 来源交叉验证：关键声明是否找到了多个来源确认
• 矛盾处理：发现来源矛盾时是否讨论了差异而非忽略
• 结论收敛：最终建议是否从证据中自然推出，而非先有结论再找证据

这些维度几乎只能靠人工或高质量 LLM-as-Judge 来评，但它们是区分“高级研究员”和“信息搬运工”的关键。

常见陷阱

陷阱一：用长度代替质量

最长的报告不一定是最好的。LLM-as-Judge 有长度偏见（第 5 篇讲过），一个 8000 字但充满套话的报告可能比 3000 字切中要害的报告得分更高。对策是在 rubric 中明确“简洁性”维度，以及设置字数上限。

陷阱二：引用幻觉

Agent 可能编造看起来真实但不存在的 URL 和引用。这是深度研究 Agent 最危险的失败模式。对策是自动化验证所有引用 URL 的可访问性和内容相关性。

陷阱三：时间维度失真

研究报告中的“现状”可能基于过时信息。Agent 搜到的可能是 2024 年的文章，在 2026 年引用为“目前”。对策是在评分中加入时效性检查，要求标注信息的发布日期。

陷阱四：确认偏误

Agent 可能（被 prompt 影响或自发地）先有一个倾向，然后只搜索和引用支持这个倾向的来源。对策是在任务中刻意要求“列出反方观点”、“讨论你建议的方案的缺点”，并在 rubric 中考核“是否考虑了替代方案”。

深度研究 Agent 评分表模板

scoring:
  primary:
    method: rubric_judge
    dimensions:
      factual_accuracy: { weight: 0.25, verify_urls: true }
      coverage: { weight: 0.15, compare_to_outline: true }
      reasoning: { weight: 0.20 }
      source_quality: { weight: 0.15, check_diversity: true }
      actionability: { weight: 0.15 }
      structure: { weight: 0.10 }
  automated_checks:
    - all_urls_accessible
    - no_fabricated_statistics
    - source_diversity >= 5_domains
    - recency_within_18_months
  trajectory:
    - search_query_diversity
    - source_diversity
    - input_output_ratio
    - cross_validation_count
  gate:
    - no_url_hallucination
    - no_fabricated_facts

三类场景横向对比

把三个场景的方案放在一起看，差异一目了然：

一个关键洞察：场景决定了测评的“重心”

做了这么多对比，最核心的结论是：Agent 测评不是一个选择题（选哪种方法），而是一个组合题（怎么按场景调配各种方法的权重）。

• Coding Agent 的重心在结果的客观验证——测试能过就是硬通货
• 客服 Agent 的重心在行为的边界控制——政策遵从比“聪明”更重要
• 深度研究 Agent 的重心在过程的认知质量——因为结果本身就很难客观评判

理解了你在测的 Agent 属于哪个场景（或者更常见的——它是多种场景的混合），你才能合理分配测评资源：在什么地方可以信任自动化，在什么地方必须投入人工，什么指标是核心，什么只是参考。

下一篇【智能体测评-10】生产环境的 Agent 可观测性与持续测评，我们进入四层框架的最后一层 L4——Agent 上线之后，怎么从真实流量中持续获取测评信号，怎么建立从生产到测评集的回流通道，怎么在质量、成本和速度之间做平衡。这是系列的收官篇。