Harness 工程面试题：22 道题及参考答案（AI 工程师）

如何准备

Harness 工程的面试问题通常由浅入深：什么是 Harness，它由哪些部分组成，你如何诊断问题，如何衡量效果。面试官看重的是工程思维：能否区分模型的问题和环境的问题，并提出可以验证的解决方案。下面是 22 道题及参考答案，按主题分组。

基础

1. 什么是智能体的 Harness？

Harness 是 AI 智能体工作所处的全部环境，模型本身除外：指令、工具、运行环境、状态存储和反馈回路。模型负责决策，而 Harness 决定它知道什么、能做什么，以及如何得知结果。同一个模型在不同的 Harness 中，表现可能天差地别。

2. Harness 工程与提示词工程、上下文工程有什么区别？

提示词工程处理单次请求的措辞，上下文工程处理每一步进入模型窗口的内容。Harness 工程两者都包括，并增加了仅靠文字无法解决的部分：工具访问、可复现的环境、跨会话的状态以及机器可执行的验证。

3. 请列出 Harness 的五个子系统。

指令（AGENTS.md、CLAUDE.md、skills、文档）、工具（shell、测试、代码检查、浏览器、MCP）、环境（依赖、运行时、Docker、worktree）、状态（PROGRESS.md、功能列表、决策记录）以及反馈（make check、端到端测试、钩子、评估者）。缺少任何一个子系统，导致的不是“稍微差一点”，而是一类系统性的失败。

4. 为什么换一个更强的模型往往无效？

因为很多失败与模型的智力无关。再强的模型也无法使用它没有权限访问的命令，无法记起没有状态文件记录的上一次会话，也不会知道一个从未运行过的迁移已经坏了。它也猜不到具体团队的约定。

诊断

5. 智能体违反了写在 CLAUDE.md 中的规则，你会怎么做？

首先检查智能体是否能找到这条规则：几十条规则的长文件会稀释重要内容。把入口文件精简成目录，把细节移到按条件加载的文档中。如果规则很关键，就把它变成可执行的检查：代码检查规则、测试、grep 守卫或钩子。这样违规就能被机器发现，而不依赖模型的注意力。

6. 如何从症状判断哪个子系统出了问题？

违反已知约定，是指令的问题。智能体“想做却做不了”，是工具的问题。每个会话都从修环境开始，是环境的问题。新会话不知道上次停在哪里，是状态的问题。“完成”与实际不符，是反馈的问题。

7. 应该先搭建 Harness 的哪个子系统？为什么？

先从反馈开始。在没有一条命令能机器化地回答“能不能用”之前，无法衡量其他任何改动的效果。之后通常是指令、状态、环境和工具，但顺序应根据哪个环节最薄弱来经验性地确定。

8. 如何衡量 Harness 中某个组件的贡献？

使用消融实验：固定模型和任务集，每次关闭一个子系统，观察性能下降。但更好的起点是带有分层标注的失败日志，它能更快地指出瓶颈。关闭某个组件后没有下降，并不说明它无用：可能只是这组任务没有用到它，或者它是冗余的。

指令与上下文

9. 一份好的 AGENTS.md 应该怎么写？

它应当是路由而不是教科书：项目是什么，如何启动，如何验证，完成定义，以及一份简短的硬性约束清单。细节放在独立文档中，并附上“在处理支付相关任务时阅读”这样的条件性链接。文件应规定不变量（“数据在边界处校验”），而不是逐行规定实现和库的选择。

10. 为什么需要子智能体？

为了隔离上下文。搜索代码库、代码评审、验证等旁支任务在独立的上下文中执行，只返回结果。主线程不会被污染；而且负责检查的子智能体不会继承执行者的推理，这对公正的评估至关重要。

11. 什么是 Harness 债务？

Harness 与现实之间不断累积的偏差：过时的规则，已经无法运行的命令，描述着已不存在模块的文档。它的表现与技术债务相似：悄然积累，最终以智能体的失败来偿还。Harness 需要定期审查，而不是配置一次就不管。

状态与会话

12. 如何应对智能体在会话之间的“失忆”？

把状态保存在仓库中：PROGRESS.md（当前状态、已完成内容、阻塞项、下一步）、DECISIONS.md（决定、理由、被否决的方案）、带状态的功能列表以及频繁的提交。在指令中规定启动顺序：先读进度文件，运行环境检查脚本，然后领取活动功能。

13. 为什么要遵守 WIP=1 的规则？

当智能体同时启动多个功能时，状态会变得支离破碎：没有一个功能真正完成，改动相互缠绕，回滚也很困难。同一时间只有一个活动功能，才能有清晰的检查点、干净的提交，以及失败后的简单恢复。

14. 什么是冷启动测试？

检验一个新会话在没有人提示的情况下，能否回答基本问题：这是什么项目，上次停在哪里，哪个功能正在进行，如何验证一切正常。如果智能体能基于文件给出确定的回答、没有靠猜测，说明状态子系统在起作用。

验证

15. 为什么绿色的单元测试不能证明功能可用？

单元测试隔离模块并 mock 依赖，因此看不到接口的交接处：接口不匹配，状态传播问题（结构已变，缓存仍是旧的），资源泄漏，配置和环境问题。单元测试能发现的缺陷，是集成测试能发现的子集；集成测试能发现的缺陷，又是端到端测试能发现的子集。

16. 什么是 verification gap？如何计算？

它是智能体宣布完成、但独立验证没有确认的任务所占的比例。取 10 个连续的任务，每个都记录这两个事实。这个指标提供了基线：在改进 Harness 之后，在相似的任务集上重新计算。

17. 如何为智能体编写完成定义（Definition of Done）？

写在 AGENTS.md 中，列出可验证的条目：验证命令以退出码 0 结束，存在覆盖该场景的端到端测试，迁移可以应用，进度已更新。最好同时明确列出“不算完成”的情况，例如“看起来正确”“单元测试通过”“我本地能跑”。

18. 为什么智能体不应该自己标记“完成”？

模型倾向于高估自己的工作，而且自我评估发生在做决定的同一个上下文中。“通过”状态应由验证脚本根据运行结果设置，并记录提交哈希作为证据。

19. 如何设置独立的评估者？

使用单独的智能体或会话，它只看到需求、代码差异和运行结果，看不到执行者的推理。它依据评分标准（正确性、架构、测试、错误处理）进行评估，每条结论都引用文件、行号或日志。最好使用另一个模型，因为不同模型的盲区不同。

20. 如何让架构规则变得可执行？

分三个层次：grep 守卫（快速，基于模式匹配），理解导入图的代码检查规则（import-linter、dependency-cruiser），以及 CI 中的架构测试。它们都应被纳入 make check，失败时返回非零退出码，并输出 WHY 和 FIX，让智能体自己修复违规。引入新检查的触发条件，通常是代码评审中出现的第二次相同评论。

自主工作

21. 要让智能体连续工作数小时，需要具备哪些条件？

一个明确的目标，单调递增的进度指标（例如处于 passing 状态的功能数），每个功能的时间与尝试次数预算，回归时自动回滚，以及需要人工处理的事项清单：迁移、基础设施、资金。此外还要有隔离：沙箱或独立的 git worktree，使错误不会影响正在使用的工作环境。

22. 什么时候单个智能体循环不够？如何设计角色图？

当执行者开始自我检查并陷入停滞时。此时把任务拆分为角色：实现、评审、测试、合并。评审者获得干净的上下文和评分标准；评审通过（review == pass）时，由代码执行合并。评审失败时功能返回实现阶段；多次失败后，则用干净的上下文重新开始——这通常说明问题出在对任务的理解上，而不在代码。

总结

在 Harness 工程的面试中，最能打动面试官的，是那些可以检验的回答：具体是哪些文件、哪些命令、哪个指标。牢记五个子系统、verification gap，以及“完成由脚本判定”这条原则。所有这些主题，都在 Harness 工程课程中汇聚到一个完整的、基于实际项目的 Harness 上。