什么是 Evaluation Harness
1️⃣ 考察意图
面试官想考察你对AI Agent评估基础设施的系统性理解，而非简单背诵概念。这是“系统设计+工程取舍”类问题，刁钻点在于：多数候选人只谈“评估指标”（如准确率），却忽略了Harness作为一套可复现、可扩展的自动化测试框架的设计哲学。答好了能展示你从单体模型评估到复杂Agent系统评估的架构视野，以及处理非确定性、长链路、工具调用等实际问题的工程能力。
2️⃣ 标准答
Evaluation Harness 不是某个工具，而是一套标准化评估基础设施，用于自动化、可复现地衡量AI Agent（或LLM）在特定任务上的性能。它把评估从“手动跑几个case”升级为“工业化测试流水线”。
核心组件（四层架构）：
- 任务定义层：定义评估场景。包括输入（prompt模板、多轮对话历史）、预期输出（精确答案、正则模式、工具调用序列）、环境配置（模拟用户、外部API mock）。例如，在客服Agent评估中，任务定义包含“用户抱怨物流慢”的对话起始状态。
- 执行引擎层：驱动Agent与环境交互。关键设计：非确定性控制——固定随机种子（seed=42）、温度（temperature=0）、top_p=1，确保同一输入多次执行结果一致。同时支持并行执行（asyncio + 进程池）以加速大规模评估。
- 评分模块层：计算指标。不能只靠LLM-as-Judge（如GPT-4打分），因为成本高且不稳定。实际工程中采用混合评分策略：精确匹配（Exact Match）用于事实性问答，F1 Score用于摘要，工具调用序列匹配（如检查是否调用了
search_weather并传参正确），最后用LLM-as-Judge做开放性评估（如“回答是否礼貌”），并设置置信度阈值（Judge打分<0.7时人工复审）。 - 报告与归因层：输出聚合指标（准确率、延迟P95、成功率）和失败case的可追溯日志（输入、Agent输出、环境状态、评分细节）。这是Debug的关键，否则你只知道“准确率80%”，却不知道哪20%错了。
常见实现与取舍：
- OpenAI Evals：轻量级，适合单轮问答。坑：不支持多轮对话和工具调用，扩展性差。
- LangChain Evaluation：支持链式调用，但依赖LangChain生态，耦合度高。取舍：快速原型 vs 生产级稳定性。
- 自定义Harness：生产环境首选。用
pytest+pytest-asyncio做测试框架，用unittest.mock模拟外部API，用pandas做结果聚合。实际落地的坑：Agent调用外部API时，网络延迟导致评估时间暴涨。解法：对API调用做mock（返回固定响应），并在Harness中设置超时机制（单步执行超时30秒，整体任务超时5分钟）。
为什么这么做？ 因为Agent评估不同于传统NLP评估：输出是动作序列（如“先搜索，再总结，最后发邮件”），而非单一文本。Harness必须能捕获中间状态（工具调用参数、环境变化），否则无法定位失败原因（是检索错了，还是工具调用参数错了？）。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从定义、核心组件、工程取舍三个层面回答。定义上，Evaluation Harness是一套标准化评估基础设施，用于自动化、可复现地衡量Agent性能。核心组件包括任务定义层、执行引擎层、评分模块层和报告归因层。工程取舍上，关键点在于非确定性控制（固定seed和temperature）、混合评分策略（精确匹配+LLM-as-Judge）、以及对外部API的mock。总结一句：Harness的本质是把评估从‘手动跑case’升级为‘工业化测试流水线’。”
4️⃣ 高频追问 & 应对
追问 1：如何评估Agent的“工具调用”正确性？比如调用了错误参数怎么办？
分三层：1）调用决策：是否在正确时机调用了正确工具（如用户问天气，Agent应调
get_weather而非search_web）。用精确匹配检查工具名。2）参数正确性：检查参数类型和值域（如city参数必须是有效城市名）。用JSON Schema校验。3）调用顺序：多工具调用时，检查序列是否合理（如先搜索再总结，不能颠倒）。用序列对齐算法（类似Levenshtein距离）计算与预期序列的相似度。坑：Agent可能因幻觉生成不存在的工具名，Harness需预注册所有合法工具列表，并设置严格模式（调用未注册工具直接判失败）。
追问 2：如何保证评估结果的可复现性？Agent输出是随机的。
核心是确定性控制：1）固定LLM的随机种子（seed=42）和采样参数（temperature=0, top_p=1）。2）对外部环境（如数据库、API）做快照（snapshot），确保每次评估时环境状态一致。3）对Agent的内部状态（如对话历史、缓存）做隔离，避免跨case污染。4）记录执行指纹（fingerprint）：LLM版本、prompt模板哈希、环境快照ID。这样即使结果异常，也能回放复现。取舍：完全确定性会牺牲评估的多样性（如无法测试模型对同义问题的鲁棒性），生产环境通常做双轨评估：确定性测试（回归） + 随机性测试（压力）。
5️⃣ 避坑 · 常见错误答法
- ❌ 只谈“Evaluation Harness就是LLM-as-Judge，用GPT-4打分就行” → ✅ 正确切入：Harness是框架，Judge只是评分模块的一部分。实际工程中需混合多种评分策略（精确匹配、F1、工具调用校验），并处理Judge本身的偏差（如偏好长回答、重复内容）。
- ❌ 说“Harness很简单，写几个pytest用例就行” → ✅ 正确切入：简单case可以，但生产级Harness需处理非确定性、并行执行、mock外部依赖、失败归因等复杂问题。例如，Agent调用外部API时，网络波动会导致评估结果不可复现，必须用mock和快照。
6️⃣ 简历呼应
- 如果你有RAG项目：从“检索质量评估”切入，说明Harness如何模拟用户query、检查检索结果的相关性（用NDCG@10）和生成答案的忠实度（用FactScore）。强调你如何用Harness发现“检索器返回了无关文档但LLM仍生成了正确回答”的假阳性case。
- 如果你只做过传统NLP：用“分类模型评估”类比——传统NLP用固定测试集和准确率，Agent评估需动态环境（如多轮对话）和动作序列校验。强调你如何将传统评估的“测试集+指标”迁移到Agent的“任务定义+执行引擎+评分模块”架构。
- 如果你是校招无项目：聚焦OpenAI Evals论文（《Eval Harness: A Framework for Evaluating LLMs》）和LangChain评估文档，说明你理解Harness的设计哲学（可扩展性、可复现性），并动手复现了一个轻量级Harness（支持问答和工具调用，用pytest+mock实现）。
- 《Eval Harness: A Framework for Evaluating LLMs》（OpenAI技术报告）
- 《Language Model Evaluation Harness》（EleutherAI开源项目，支持100+基准）
- 《AgentBench: Evaluating LLMs as Agents》（ICLR 2024，多任务Agent评估基准）
- 《ToolQA: A Dataset for Evaluating Tool-Augmented LLMs》（评估工具调用能力）
- 《Evaluating Verifiability in Generative AI》（Google，评估忠实度和可验证性）