Harness 面试考察落地实践指南：从概念辨析到面试题库设计

一、教程目标

本教程要帮助读者完成一件具体的事：把 Harness（运行框架/编排骨架）作为面试中的独立考察维度，设计出一套可执行、可评分、可复用的面试方案。

适合阅读本文的读者包括：

• 正在招聘 Agent 方向工程师的技术负责人；
• 需要参与面试但不确定该问什么的资深开发者；
• 希望把团队技术认知沉淀为面试标准的研发管理者；
• 对 Agent 工程体系感到困惑、想弄清几个热门概念边界的工程师。

读完之后，你应该能够：区分 Harness 与上下文工程、提示词工程的差异；判断一个候选人是否真正做过 Agent 落地；独立设计一套 Harness 相关的面试题与评分表。

二、适用场景

这套面试方案适合以下情形：

• 团队准备招聘 Agent 应用开发、平台工程或 AI 基础设施方向岗位；
• 现有面试只考察算法题与框架 API，无法判断候选人是否具备端到端落地能力；
• 团队内部对 Harness 的理解不统一，面试官各问各的，评价标准漂移；
• 需要在短时间内筛选出既懂模型调用、又懂运行时治理的复合型人才。

如果你的岗位只做模型微调或纯算法研究，本文的侧重点需要适当调整。

三、前置准备

在开始设计面试题之前，需要先完成三项准备。

1. 统一团队内部的概念认知

面试官之间如果对 Harness 的理解都不一致，评分必然失真。建议先组织一次内部对齐，明确以下定义（业界通用理解）：

• 提示词工程（Prompt Engineering）：关注单次输入的措辞、结构、示例设计，目标是让模型在单轮或短交互中输出符合预期的内容。
• 上下文工程（Context Engineering）：关注在有限上下文窗口内，如何组织历史、检索结果、工具返回、系统指令等信息，目标是让模型在多轮、多源信息下保持稳定的判断。
• Harness（运行框架/编排骨架）：关注 Agent 在真实运行时的整体控制结构，包括任务分解、工具调用循环、状态管理、失败重试、超时控制、权限边界、可观测性与人工介入点。

一句话概括：提示词工程管“怎么说”，上下文工程管“给什么信息”，Harness 管“怎么跑起来、跑得住、跑得可观测”。

2. 明确岗位画像

不同岗位对 Harness 的考察深度不同：

• 应用开发岗：能说清调用循环、状态传递、错误处理即可；
• 平台工程岗：需要能设计编排层、抽象工具接口、定义重试与熔断策略；
• 技术负责人岗：需要能权衡成本、稳定性、可维护性，并给出架构取舍。

3. 准备评估材料

• 一份统一的评分维度表（下文给出示例）；
• 若干道开放式场景题，而非纯记忆题；
• 一套追问路径，用于区分“听过”和“做过”。

四、实施步骤

步骤一：设计面试结构

建议把面试拆成四段，每段对应不同考察目标：

1. 概念辨析（5–10 分钟）：判断候选人是否分清几个概念；
2. 项目追问（15–20 分钟）：让候选人讲一个真实做过的 Agent 项目；
3. 场景设计（15–20 分钟）：给一个开放性任务，观察其设计思路；
4. 故障排查（10 分钟）：给出一个运行异常现象，观察其排查逻辑。

这样做的好处是：概念题防止“名词党”，项目题验证真实性，设计题考察抽象能力，排查题考察实战经验。

步骤二：编写概念辨析题

不要问“请解释什么是 Harness”，这种题只能得到背诵答案。更好的问法是给对比场景：

某个 Agent 在单轮对话中表现很好，但连续执行十步任务后开始重复调用同一个工具、丢失中间结果、偶发超时。请判断：这更可能是提示词问题、上下文问题，还是 Harness 问题？为什么？

参考判断路径：

• 单轮好、多轮差 → 上下文组织可能有问题；
• 重复调用同一工具、状态丢失、无超时控制 → Harness 层面的循环与状态管理缺陷；
• 输出格式不稳定 → 更偏提示词。

追问：“如果三者都有问题，你会按什么顺序修？”优秀的候选人会先修 Harness，因为运行框架不稳定时，调提示词的效果无法被可靠观测。

步骤三：编写项目追问题

用 STAR 式追问，但重点放在运行层细节上：

• 你的 Agent 一次任务的完整执行链路是怎样的？
• 工具调用失败时，是谁负责重试？重试几次？有没有退避？
• 中间状态存在哪里？进程重启后会丢吗？
• 有没有超时和最大步数限制？设成多少，为什么？
• 如何观测一次失败任务？能看到每一步的输入输出吗？
• 哪些环节需要人工介入？怎么触发？

如果候选人只能回答“我调了某个大模型接口，然后让它自己跑”，说明他没有真正处理过 Harness 层的问题。能具体说出重试策略、状态存储位置、超时阈值来源的候选人，通常有真实落地经验。

步骤四：编写场景设计题

给一个中立场景，例如：

设计一个能自动处理工单的 Agent：读取工单内容，判断类型，调用内部查询工具，生成回复草稿，必要时转人工。要求可观测、可重试、可限流。

观察候选人是否主动覆盖以下要点：

• 任务分解与状态机设计；
• 工具接口的抽象与版本管理；
• 失败分类（可重试 / 不可重试 / 需人工）；
• 超时、最大步数、并发限流；
• 日志、追踪、指标三类可观测性；
• 权限与敏感操作边界。

步骤五：编写故障排查题

给出一个现象，例如：

某 Agent 在压测时成功率从 95% 掉到 60%，日志显示大量工具调用超时，但下游服务监控正常。你会怎么排查？

合格的排查路径应包含：确认超时阈值是否合理、检查 Agent 侧并发是否超过下游承载、查看是否有重试风暴、核对上下文是否膨胀导致单步耗时上升、确认是否存在状态锁竞争。

步骤六：制定评分标准

建议每个维度按 1–4 分打分：

• 1 分：只听过名词，无法展开；
• 2 分：能描述概念，但无落地细节；
• 3 分：有真实项目经验，能说清关键决策；
• 4 分：能横向对比方案取舍，并给出可验证的优化路径。

维度建议包括：概念清晰度、运行链路掌控、失败处理能力、可观测性设计、成本与稳定性权衡、沟通表达。

五、配置说明（评分表示例）

可以用一份通用配置片段描述评分表结构：

interview:
  role: agent_platform_engineer
  dimensions:
    - name: concept_clarity
      weight: 0.15
    - name: runtime_control
      weight: 0.25
    - name: failure_handling
      weight: 0.25
    - name: observability
      weight: 0.2
    - name: cost_stability_tradeoff
      weight: 0.15
  pass_threshold: 3.0

配置含义说明：

• weight 表示维度权重，应按岗位调整，平台岗可提高 runtime_control；
• pass_threshold 是加权平均通过线，避免单一维度决定结果；
• 不建议设置过多维度，否则面试官难以在有限时间内打分。

六、结果验证

面试方案上线后，通过以下方式验证有效性：

• 一致性验证：多位面试官对同一份面试记录独立打分，偏差应控制在一个等级内；
• 预测性验证：入职后 3 个月的绩效与面试评分做相关性观察；
• 区分度验证：通过者和未通过者在关键维度上应有明显分差；
• 反馈验证：收集候选人反馈，判断题目是否表述清晰、无歧义。

如果发现某道题所有人都得高分或都得低分，说明该题缺乏区分度，需要重写。

七、常见问题与排查

问题一：候选人把 Harness 和上下文工程混为一谈。
这不一定是否决项，关键看追问后能否区分。如果提示后仍无法区分运行控制与信息组织，说明缺乏体系认知。

问题二：面试官问得太发散，20 分钟没问完。
原因是题目没有主线和追问边界。建议每题预设 2–3 层追问，超出即收。

问题三：候选人项目经验真实，但表达零散。
可以主动用结构化提问引导，例如“我们按任务分解、工具调用、失败处理、观测四块来聊”。评分应看实质内容，而非表达流畅度。

问题四：团队对某个概念的边界仍有争议。
不要在面试中强行下结论。把争议记录下来，内部对齐后再更新题库。

八、优化建议

• 性能与稳定性：面试题中的场景应尽量贴近团队真实架构，避免纸上谈兵；
• 安全与权限：加入对敏感操作、人工审核、审计日志的考察，这在 Agent 落地中越来越关键；
• 可维护性：优先选择能讲清“为什么这么设计”的候选人，而非只会用某个框架 API 的人；
• 成本控制：可加入对 token 消耗、重试放大、并发成本的估算题，观察候选人是否有成本意识；
• 持续迭代：技术概念演进快，建议每季度复盘一次题库，淘汰过时题目。

九、总结

把 Harness 纳入面试，不是为了多问几个名词，而是为了识别出真正能把 Agent 跑稳、跑可观测、跑可维护的工程师。本教程给出的路径是：先统一内部概念，再按概念辨析、项目追问、场景设计、故障排查四段设计面试，配合统一评分表与验证机制，最后通过一致性、预测性、区分度三类指标持续优化。

后续可以继续关注的方向包括：Agent 运行时的标准可观测性约定、多 Agent 协作下的编排复杂度控制、以及人工介入点的自动化触发策略。这些都会反过来影响你的面试题库设计。