概念解析：到底什么是 Evaluation Harness
1️⃣ 考察意图
面试官想看你是否理解AI Agent评估的系统级基础设施，而非只背过几个指标。这属于系统设计+工程取舍类问题。刁钻点在于：多数候选人能说出“评估就是用测试验证集”，但讲不清Harness如何解决可复现性、环境隔离、多模态交互这三个核心工程难题。答好了能展示你对Agent生产化部署的全局视野，以及从“跑通demo”到“可信任上线”的工程思维。
2️⃣ 标准答
Evaluation Harness 不是某个工具，而是一套标准化评估基础设施，核心目标是在可控环境中对Agent进行可复现、可扩展、可比较的性能测量。它解决了三个关键问题：① 如何模拟Agent的复杂交互环境（工具调用、多轮对话、状态变化）；② 如何保证不同实验间的结果可比（随机种子、模型版本、环境状态）；③ 如何高效并行执行大量测试用例。
核心组件（按执行流水线排列）：
- 任务定义层（Task Spec）：定义Agent的输入输出格式、成功标准、约束条件。例如客服Agent的任务定义包含：用户意图分类、工具调用序列（如查订单→退款）、回复格式（JSON/自然语言）。坑：任务定义必须包含状态机，因为Agent的决策依赖历史上下文。常见错误是只定义单轮问答，导致评估结果无法反映真实场景。
- 环境模拟器（Env Simulator）：模拟Agent的外部世界，包括API响应、数据库状态、用户行为。对于工具调用Agent，需要mock外部服务（如天气API、数据库查询），并控制响应延迟和错误率。工程取舍：完全模拟真实环境成本高，通常采用分层模拟——核心逻辑用真实服务，非关键路径用mock。例如评估电商Agent时，商品库存查询用真实数据库，但支付回调用mock。
- Agent适配器（Agent Adapter）：将不同Agent框架（LangChain、AutoGPT、自定义）统一成标准接口。核心是定义动作空间（Action Space）和观察空间（Observation Space）。例如LangChain的Agent输出是
AgentAction对象，而AutoGPT输出是自然语言，需要统一成(action_type, parameters)元组。 - 执行引擎（Execution Engine）：负责并行调度测试用例，管理超时、重试、资源隔离。实际落地的坑：Agent执行可能产生副作用（如发送真实邮件），必须用沙箱机制隔离。解法：使用Docker容器或子进程，每次评估后重置环境状态。
- 评分模块（Scoring Module）：计算指标。除了准确率、成功率，还需关注过程指标：工具调用次数、平均延迟、无效动作率。关键取舍：自动化评分（如精确匹配）效率高但漏检多，人工评分（如GPT-4作为judge）准确但成本高。工业界常用混合策略：简单任务用规则，复杂任务用LLM-as-Judge，并设置置信度阈值触发人工复核。
常见实现对比：
- OpenAI Evals：轻量级，适合快速验证，但缺乏环境模拟和并行执行支持。
- LangSmith：企业级，提供完整trace和可视化，但定制化成本高。
- 自研Harness：适合特定场景（如多Agent协作），需要实现上述所有组件。
实战案例：评估一个代码生成Agent。Harness需要：① 定义任务（生成Python函数并测试通过）；② 模拟Python解释器环境（隔离文件系统、限制网络访问）；③ 执行引擎并行运行100个测试用例，每个用例超时30秒；④ 评分模块计算通过率、代码复杂度、执行时间。坑：Agent可能生成无限循环代码，必须设置CPU时间限制和内存上限。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，Evaluation Harness是一套标准化评估基础设施，核心解决可复现性、环境隔离、多模态交互三个问题；第二，它的核心组件包括任务定义层、环境模拟器、Agent适配器、执行引擎和评分模块，每个组件都有工程取舍，比如环境模拟采用分层策略平衡成本和真实性；第三，实际落地时要注意副作用隔离和混合评分策略。总结一句：Harness不是工具，而是让Agent评估从‘跑通demo’升级为‘可信任上线’的系统工程。”
4️⃣ 高频追问 & 应对
追问 1：如何保证评估结果的可复现性？如果Agent调用外部API，结果会变化怎么办？
应对策略：核心是确定性模拟。① 对所有外部服务做mock，记录请求-响应映射（如用VCR.py录制真实API调用）；② 固定随机种子（包括模型temperature、采样策略）；③ 对非确定性操作（如LLM输出）做快照回放——首次评估记录所有LLM响应，后续评估直接回放。取舍：完全mock会丢失真实环境变化（如API更新），建议在CI/CD中设置定期回归测试，用真实环境验证mock的准确性。
追问 2：如何评估Agent的“智能”而非“运气”？比如Agent可能随机猜对答案。
应对策略：引入对抗性测试和鲁棒性指标。① 设计边缘案例：如输入包含拼写错误、歧义指令、缺失参数；② 计算一致性分数：对同一任务多次运行（不同随机种子），看输出是否稳定；③ 使用过程奖励模型（Process Reward Model）评估中间步骤质量，而非只看最终结果。例如在数学推理Agent中，即使答案正确，如果推理步骤有逻辑漏洞，也要扣分。
追问 3：你的Harness如何支持多Agent协作场景？
应对策略：需要扩展环境模拟器为多Agent沙箱。① 定义共享状态空间（如共享数据库、消息队列）；② 引入通信协议（如Agent间消息格式、超时机制）；③ 评分模块需计算团队指标（如任务完成时间、通信开销、冲突次数）。坑：Agent可能互相干扰（如同时修改同一文件），需要实现锁机制或事务性操作。工业界参考：Google的AgentBench和Meta的CICERO评估框架。
5️⃣ 避坑 · 常见错误答法
- ❌ “Evaluation Harness就是用测试验证集，类似pytest。” → ✅ “它比pytest复杂得多，需要模拟环境、管理副作用、处理多轮交互，本质是Agent的‘操作系统级测试框架’。”
- ❌ “指标就是准确率和召回率。” → ✅ “Agent评估需要过程指标（工具调用次数、延迟、无效动作率）和鲁棒性指标（一致性、对抗性测试通过率），不能只看最终结果。”
- ❌ “用真实环境评估最准确。” → ✅ “真实环境不可控且成本高，工业界采用分层模拟+定期回归测试的混合策略，平衡准确性和效率。”
6️⃣ 简历呼应
- 如果你有RAG项目：从“检索质量评估”切入，说明Harness如何扩展为RAG专用版——增加文档检索模拟器、评估检索结果的相关性和多样性。
- 如果你只做过传统NLP：类比“模型评估从静态数据集到动态Agent的演进”，强调Harness需要处理状态管理和多轮交互，这是传统NLP评估没有的挑战。
- 如果你是校招无项目：聚焦“论文复现”——用OpenAI Evals复现AgentBench论文中的评估流程，说明你理解Harness的组件和设计取舍，并附上GitHub链接。
- 《AgentBench: Evaluating LLMs as Agents》—— 多Agent评估基准论文
- 《Evaluating Large Language Model Agents: A Survey》—— 综述Agent评估方法
- LangSmith官方文档：Trace和Evaluation模块设计
- OpenAI Evals GitHub仓库：轻量级Harness实现参考
- 《Process Reward Models for Mathematical Reasoning》—— 过程奖励模型论文