回顾 -> 新问题

1. DeepRearchSystem 0x00：初识
2. DeepRearchSystem 0x01：Agent 基础
3. DeepRearchSystem 0x02：Graph 建立
4. DeepRearchSystem 0x03：HITL
5. DeepResearchSystem 0x04：MAS 进阶

至此，DeepResearchSystem 已经是一个多 Agent 协作的智能体研报程序。到此就结束了吗，用我们之前客户端的思维，一个产品从开发完成到上线之前往往还需要经历严格的测试以保证产品可用性和性能。那么对于一个 Agent？如何确保其可用性呢，怎么去对一个 Agent 做测试？

解决

Agent 测试困境

回想一下以往我们客户端的测试方式:

• 分析业务场景可能对应的 case。创建测试用例
• 测试时拿程序执行结果去和测试用例的结果对比

对于 LLM Agent，输出并不是确定的。我们就不能靠以前传统的那套测试方式来应对 Agent。Agent 的测试困境还不限于此：

1. 输出非确定性：同个输入跑 N 次输出都不一样，没法用传统等值断言；
2. 中间态不可观测：Agent 多步推理的中间结果默认不暴露，出问题没法定位；
3. 因果链难追溯：最终报告出错。可能是计划、搜索、摘要任意环节的问题，定位成本可能是传统测试的10倍以上；
4. 幻觉难界定：传统规则没法判断“无中生有”的语义幻觉，比如 Agent 编了不存在的政策条款；
5. 环境依赖强：依赖搜索、工具调用等外部环境。测试结果波动大，反复调用外部 API 成本极高。

困境突围

既然有这么多不确定性，显然不能像传统测试那样拥有一个确定的预期结果和固定的用例。针对以上困境，业界常规做法包括:

1. 端到端评估：测整体任务完成度。 用LLM 去评估一次执行结果的完整性、准确性、信息覆盖度等。
2. 组件化评估：将 Agent 流程拆分成组件去评估，用解耦思路单独测每个模块。
3. 混合策略：确定性规则仍采用传统断言；语义判断交给L​LM 去评估。
4. Judge可靠性调整： 使用比被测 Agent 更强的模型当 Judge。Prompt 中加入 CoT 要求先给理由再打分，高风险场景采用双模型交叉验证。

架构设计

LLM as Judge

其实上面说到的方法就是业界所称的 “LLM as Judge”。它通过# 强 LLM +结构化评分规则# ,为 Agent 输出还有中间态提供语义级判断。

• L​LM as Judge 定义： 基于预设结构化评分规则，让S​trong LLM 对 Agent 的输出、中间态进行语义级评估。
• L​LM as Judge 本质： 利用 AI 的认知能力解决#传统测试无法处理的模糊语义问题#。

目标 & 能力需求

我们必须使用 LLM as Judge 范式，对整套多 Agent 程序做全链路评估。Judge 模块必须具备以下主要能力:

•  使用L​LM 去评估一次执行结果完整性、准确性与信息覆盖度。

•  将流程拆解为独立组件，单独打分并能定位拖后腿的模块。

分工 & 三大主要类

• evaluator 负责编排 ：决定测什么、按什么顺序测。
• judger 负责执行 ：怎么测、怎么打分。
• hook_context 负责采集 ：底层数据捕获。话说回来，

  ---