面试优先顺序（通用 AI 应用开发岗位）：Q1、Q2、Q4、Q5、Q6、Q7、Q8、Q11、Q12、Q13、Q14、Q15。其余题目用于进阶或特定岗位拓展；实际频率会随岗位和面试轮次变化，产品版本资讯不应当作通用必考题。
难度： ⭐⭐⭐ 更新： 2026-08-13 考点： Test Harness、mock/stub/fake/spy、fixture、flaky 治理、特征测试、契约测试、LLM Eval Harness、评测集建设、灰度评测、Agent 轨迹评测
面试官问 harness，第一层考定义，第二层考组成，第三层考"你和它的真实关系"。简历写"熟悉单元测试、参与过 CI 集成"的人，最容易被这道题卡住——不是技术不行，是没想过"测试"本身也是会被深挖的系统设计题。
标准定义： Test Harness（测试夹具/测试台）是一套把被测代码"装进去跑起来"的基础设施，包含五个部分：
| 要素 | 职责 | 示例 |
|---|---|---|
| 测试运行器 | 收集并执行用例 | Go testing / pytest / JUnit |
| 测试数据 | 固定、可复现的输入 | fixture、fixture 文件、YAML 数据集 |
| 断言逻辑 | 校验实际输出与期望一致 | testify / assert |
| 依赖替身 | 隔离外部依赖 | stub / mock / fake / spy |
| 结果报告 | 汇总通过率、覆盖率、耗时 | 覆盖率报告、CI 报告 |
核心职责三个词：可重复、可隔离、可自动化。
和测试框架的区别（最容易被绕晕、最爱考的点）：
- 测试框架（pytest / JUnit / Go testing）是"语言层面的工具"，提供断言、收集用例、跑用例的能力；
- Test Harness 是"工程层面的系统"，在框架之上，负责把被测模块和外部依赖（数据库、网络、文件、时间）剥离开，让测试在任何环境、任何顺序下跑，结果都一样。
一句话记忆：框架管"怎么跑"，harness 管"跑得干不干净、靠不靠谱"。
为什么需要它： 没有 harness，你的测试依赖本地数据库、依赖网络、依赖环境变量，今天能过明天挂，换个同事机器就红——这种测试比没有测试还可怕，因为它给你虚假的安全感。
和测试脚本的区别： 脚本是"一次性验证"，harness 是"可持续运行、可重复、可集成进 CI 的工程系统"。pytest + fixture + mock + 覆盖率报告 + Jenkins/GitHub Actions 触发，这一整套才是 harness。
面 AI 后端 / RAG / Agent 岗，这部分才是拉开差距的地方。传统 harness 测的是"代码逻辑对不对"，LLM 评测 harness 测的是"模型输出好不好"——后者没有确定的正确答案，问题维度完全不同。
为什么 AI 项目必须要有 eval harness：
- 大模型输出是概率的，改一个 prompt、换一个模型版本，效果是涨是跌，不测永远不知道；
- 业务方一句"效果变差了"，你没有评测集就无从定位是检索问题、prompt 问题还是模型问题；
- 面试里"我用评测集管理 RAG 质量"和"我调参靠感觉"，是两个档次的回答。
一套完整的 LLM eval harness 五件套：
| 组件 | 职责 |
|---|---|
| 评测集 | 一组带标注的输入-期望输出（问题 + 标准答案/判定标准） |
| 运行器 | 批量把评测集喂给模型/RAG 系统，跑出结果 |
| 指标 | 离线：准确率、召回、忠实度、答案相关性；线上：点击、采纳率、成本 |
| 报告 | 每次改动自动出一份对比报告，diff 到上一版，红了就回滚 |
| CI 集成 | 评测集 + 跑批 + 报告封装进 CI，改动即回归 |
常用工具（面试点名说工具名，非常加分）：
- lm-evaluation-harness： EleutherAI 出品，评测主流开源模型的标准工具；
- OpenAI Evals： 写 eval 用例、跑对比评测的框架；
- RAGAS： 专门评测 RAG 四维指标——忠实度、答案相关性、上下文相关性、噪声鲁棒性（四个指标详解见 09 · 安全与评估 Q6）；
- 自建： 把评测集 + 跑批 + 报告封装进自己的 CI，就是生产级做法。
评测集怎么建（最容易露馅的问题，认真记）：
- 从真实线上日志挖（用户真实问题，不是拍脑袋编的）；
- 按维度分层： 简单/中等/难，覆盖不同业务场景；
- 每类问题配判定标准（期望答案要点），宁可少而准，不要多而水；
- 版本化管理， 测试集和开发集分开，防止调参时"背题"；
- 定期抽检人工复核， 防止标注质量漂移。
灰度评测（高级考点）： 线上新模型先 Shadow 模式（影子流量，新旧并行跑，结果对拍不计费不展示），指标稳了再 Canary（小流量放量），最后全量。这套词说出来，面试官就知道你真上过生产。（RAG 灰度发布详细流程见 20 · RAG 高级优化 Q28）
面试答题万能框架（所有 harness 题通用）：
- 先给定义：一句话说清是什么；
- 再讲为什么：解决什么问题；
- 然后举例子：我项目里具体怎么做的（有数据最好）；
- 最后说坑：我踩过什么坑、怎么解决的。
这个"定义-动机-实例-坑"四步法，比背答案高级得多。简历 STAR 写法与量化原则见 16 · 简历与面试技巧。
harness 专属简历写法（数字 + 工具名 + 结果，三样齐了面试官就追不动了）：
❌ 熟悉 pytest，会写单元测试
✅ 搭建项目级 Test Harness：基于 pytest 实现 fixture 数据隔离 + mock 外部依赖，单测 flaky 率从 [你的基线] 降到 [你的结果]，接入 CI 全量 [你的耗时] 跑完
❌ 熟悉 RAG 开发
✅ 自建 RAG 评测集（[你的数量]+ 真实线上问题）与 Eval Harness，接入灰度发布，chunk 策略调优后检索召回率提升 [你的结果]
⚠️ 数字必须是你的真实数据（参考 内容质量规范），面试前把 [占位符] 全部替换成可解释口径的数字。
| 日期 | 更新内容 |
|---|---|
| 2026-08-18 | 新增 Q17-Q19 Agent 运行治理五大维度（权限/熔断/隔离/审计/生命周期）、工具调用熔断与幂等设计、Prompt/Skill 回归评测（基线 + 评测集） |
| 2026-08-14 | 新增 Q16 Agent 安全沙箱 Harness（权限管控四件套 + 评测闭环 + 红队化） |
| 2026-08-13 | 新增模块：Test Harness 与 LLM 评测 Harness 15 题，已按仓库规范重写 |
内容治理：2026-08-13 | 对已覆盖考点（RAGAS 四指标、RAG 灰度、Agent 评估、STAR 简历）链接主答案，只保留新增考察角度
题目目录（按原文档学习顺序，⭐ = 面试高频优先题）
Agent 运行治理与回归评测（Q17-Q19）
- Q17 · Agent 运行治理（Harness）的五大维度是什么？权限、熔断、上下文隔离、审计、生命周期各解决什么问题？
- Q18 · 工具连续失败或重复调用，系统在哪里熔断？幂等、超时重试、熔断、审计怎么设计？
- Q19 · Prompt 或 Skill 改了一版，怎么证明效果没有退化？（基线 + 回归评测）
LLM 评测 Harness（Q11-Q16）
- ⭐ Q11 · 你的 RAG 项目效果怎么评测？
- ⭐ Q12 · 离线评测和线上评测有什么区别？
- ⭐ Q13 · 怎么建评测集？怎么防止评测集被"背题"（过拟合/数据泄漏）？
- ⭐ Q14 · 离线评测分高，线上效果却变差了，怎么排查？（经典"评测跷跷板"）
- ⭐ Q15 · Agent 类应用（会调工具的）怎么评测？（最前沿，答出来直接拉开差距）
- Q16 · Harness 作为 Agent 的"安全沙箱"怎么理解？权限管控和自动化评测如何落地？（2026 高频）
Test Harness 工程实践 10 问（Q1-Q10）
- ⭐ Q1 · 什么是 test harness？和测试脚本有什么区别？
- ⭐ Q2 · 如何设计一个可重复运行的 harness？（系统设计题）
- Q3 · fixture 的生命周期和作用域怎么控制？
- ⭐ Q4 · mock、stub、fake、spy 的区别？什么时候用哪个？（必考）
- ⭐ Q5 · 测试里依赖数据库/网络/时间/文件，怎么隔离？
- ⭐ Q6 · 测试经常随机挂（flaky），怎么治理？（高频追问，体现工程经验）
- ⭐ Q7 · 接手一堆没有测试的老代码，怎么补 harness？（考察落地能力）
- ⭐ Q8 · 集成测试的 harness 怎么设计？真实依赖还是替身？
- Q9 · 怎么衡量一个 harness 本身好不好？（考察质量意识）
- Q10 · 参数化测试和数据驱动怎么落地？