AI Agent 面试题深度解析（五）：Harness Engineering 篇

核心答案#

Harness Engineering 是**为 Agent 设计和实现”模型之外的那一层系统”**的工程方法论。Harness 这个词本意是”马具”——把马拉到车上、控制马的方向、利用马的力量。Harness Engineering 在 Agent 领域的含义是”如何把 LLM 的能力组织起来、约束起来、利用起来”。

Harness 的核心思想是：不要把 Agent 表现完全归因于模型本身。模型负责推理和生成，模型之外的任务管理、上下文供给、工具反馈、验证机制、错误恢复，同样决定系统上限。Harness 就是把这些”模型之外的部分”组织起来的系统。

Harness Engineering 和 Prompt Engineering、Context Engineering 的关系可以这样理解：

• Prompt Engineering 关注”指令文本”——怎么把任务写清楚，是 Harness 的最基础输入。
• Context Engineering 关注”上下文窗口”——什么信息在什么时机进入模型，是 Harness 的核心组件。
• Harness Engineering 关注”完整系统”——除了 Prompt 和 Context，还包括任务状态、工具调用、错误恢复、验证、安全、评测等所有模型之外的部分。

Harness 是个更大的概念。Context Engineering 是 Harness 的子集，Prompt Engineering 是 Context 的子集。三者是从微观到宏观的层级关系。

Harness 的核心组件至少包括：上下文管理、任务状态机、工具调用框架、错误处理与重试、验证与评测、安全与权限、可观测性、成本控制。这些组件每一个都”编码了一个假设”——模型单独做不好什么。比如设计验证器，是因为模型输出不一定可信；设计重试机制，是因为工具调用会失败；设计上下文压缩，是因为模型有窗口限制。

讲 Harness 时一个有效的切入方式是”假设 LLM 是不可靠的，然后看系统怎么补”。这个思路能立刻让面试官意识到你不是在讲抽象概念，而是在讲工程约束。

关键要点#

• Harness 是”模型之外的那一层系统”，是 Agent 工程化的核心概念。
• Prompt Engineering < Context Engineering < Harness Engineering，是从微观到宏观的层级。
• Harness 的每个组件都编码了”模型做不好什么”的假设。

容易踩的坑#

• 把 Harness 讲成”新名词堆砌”，没有具体内容。
• 不知道 Harness 和 Prompt/Context Engineering 的层级关系。
• 把 Harness 讲得太抽象，没法落地。

示范话术#

Harness Engineering 我用一句话定义：它是”模型之外的那一层系统”。LLM 只负责推理，但 Agent 要稳定运行还需要任务状态、上下文供给、工具调用、错误恢复、验证、安全、评测、成本控制这些工程组件——这些就是 Harness。Harness 每一个组件都编码了一个假设：“模型单独做不好什么”。比如设计验证器是因为模型输出不一定可信；设计重试机制是因为工具调用会失败；设计上下文压缩是因为模型有窗口限制。Harness 和 Prompt、Context Engineering 的关系是层级：Prompt Engineering 是最基础的指令文本优化；Context Engineering 是中间层的上下文管理；Harness Engineering 是完整的工程系统，Prompt 和 Context 都是它的子集。讲这一题我会用”假设 LLM 是不可靠的”切入——这个思路能让面试官立刻意识到你在讲工程约束而不是抽象概念。

核心答案#

「Agent = Model + Harness」是生产级 Agent 系统的核心公式。它的含义是：Agent 的最终表现是模型能力 × Harness 设计的乘积。

为什么不是”Agent = Model”？因为单独的模型只能做”输入到输出”的映射，没有持续执行任务的能力。模型不会自己记住任务状态、不会自己调用工具、不会自己从错误中恢复、不会自己验证输出。这些能力全部来自 Harness。

Model 的边界。模型擅长：理解自然语言、推理、生成文本、选择工具、解释结果。模型不擅长：保持长期状态、调用真实工具、自我验证、在错误中恢复、跨会话记忆。这些”不擅长”的部分，必须由 Harness 补足。

Harness 的作用。Harness 把”模型不擅长的事”系统化。它做四件事：第一，给模型供给”完成任务所需要的信息”——上下文、记忆、工具描述、检索证据；第二，让模型能影响外部世界——工具调用、API 执行、文件操作；第三，验证模型的输出——结构化校验、断言、用户确认；第四，让系统能从失败中恢复——重试、降级、回滚、状态保存。

用一个具体例子说明 Model × Harness 的乘积效应。

如果只用裸模型做”分析 GitHub Issue 并自动回复”任务，模型会输出看似合理的回复，但：可能编造不存在的 Issue；可能调用错误的 API；可能重复回复同一个 Issue；可能在错误的方向上越走越远。

加上 Harness 后：Harness 提供真实的 Issue 列表（不是让模型编）；提供 issue_reply 工具的标准化接口（不是让模型自己挑 API）；记录已回复的 Issue 状态（避免重复回复）；在模型输出错误时触发重试或回退。结果是同一个模型，能力提升好几倍。

Harness 不是”补丁”。很多人以为 Harness 是”模型不够强所以补丁一下”。但实际上，Harness 编码了”对任务的领域理解”——知道任务什么时候算完成、什么情况下该重试、什么错误是可恢复的。这些知识即使模型再强，也需要 Harness 显式提供。

所以生产 Agent 项目的工程师共识是：模型能力重要，Harness 同样重要，甚至更重要。一个精心设计的 Harness + 较弱模型，可能比裸的强模型表现更好。

关键要点#

• Agent 的最终表现是 Model 能力 × Harness 设计的乘积。
• 模型不擅长”持续执行任务”，这部分必须由 Harness 补足。
• Harness 不是补丁，是领域知识的显式表达。

容易踩的坑#

• 把 Agent 表现完全归因于模型。
• 没意识到 Harness 编码了领域知识。
• 用”模型不够强所以要 Harness”来解释，把 Harness 讲成”补丁”。

示范话术#

「Agent = Model + Harness」是生产级 Agent 的核心公式。模型擅长推理和生成，但模型不擅长持续执行任务——它不会自己记状态、不会自己调工具、不会自己验证输出、不会从错误中恢复。这些事必须由 Harness 补足。Harness 编码了领域知识：任务什么时候算完成、什么错误可恢复、什么情况该重试。我用”分析 GitHub Issue 并自动回复”举例：裸模型会编造 Issue、挑错 API、重复回复；加上 Harness 后，Harness 提供真实 Issue 列表、标准化工具接口、状态记录、错误重试，同一个模型能力提升好几倍。讲这一题我会强调：Harness 不是”模型不够强的补丁”，而是”领域知识的显式表达”。

核心答案#

Harness 的六层架构是对 Agent 系统的层级化拆解，从外到内分别是：任务接入层、上下文供给层、推理决策层、行动执行层、验证反馈层、可观测层。每一层解决不同的问题，层与层之间通过标准化接口协作。

第一层，任务接入层。解决”Agent 怎么接收任务”。包括：用户输入解析、API 接入、事件触发、任务队列管理、目标澄清。任务接入层要把外部请求转化为 Agent 内部可处理的任务对象。

第二层，上下文供给层。解决”模型看到什么”。包括：系统提示、长期记忆召回、检索证据组装、对话历史管理、Token 预算分配、上下文压缩。Context Engineering 主要是这一层的工作。

第三层，推理决策层。解决”模型怎么思考”。包括：LLM 调用、推理模式选择（ReAct / Plan-and-Execute / Reflection）、多 Agent 协作、子任务规划。推理决策层是 Agent 的”大脑”。

第四层，行动执行层。解决”Agent 怎么影响外部世界”。包括：工具调用框架、参数校验、权限控制、超时重试、降级策略、副作用管理。行动执行层是 Agent 的”手脚”。

第五层，验证反馈层。解决”怎么知道做得对不对”。包括：输出结构化校验、断言、用户确认、单元测试、回归测试、A/B 实验。验证反馈层是 Agent 的”质检”。

第六层，可观测层。解决”出问题时怎么排查”。包括：轨迹记录、日志、监控、告警、成本统计、失败回放。可观测层是 Agent 的”黑匣子”。

这六层的关系是逐层依赖、逐层反馈。任务接入层触发上下文供给层；上下文供给层和行动执行层的结果共同喂给推理决策层；推理决策层的输出由验证反馈层把关；可观测层贯穿所有层，记录所有事件。

六层架构的工程价值在于：每一层都可以独立优化、独立替换、独立测试。比如可以单独优化上下文供给层（换更好的检索算法），不影响其他层；可以单独加固行动执行层（更严格的权限控制），不改动推理决策层。

注意：六层架构是抽象模型，不是必须严格按这个切分。不同 Agent 框架（LangGraph、AutoGen、CrewAI）的实现会有差异，但基本都会覆盖这六类工作。

关键要点#

• 六层架构把 Harness 工作拆成任务接入、上下文供给、推理决策、行动执行、验证反馈、可观测层。
• 层与层之间逐层依赖、逐层反馈，可独立优化和替换。
• 六层是抽象模型，不同框架实现各异但核心工作相同。

容易踩的坑#

• 把六层架构讲成”组件列表”，没有说明层间关系。
• 不区分抽象模型和具体实现。
• 漏掉验证反馈层或可观测层——这两层在生产中尤其重要。

示范话术#

Harness 的六层架构我按”任务接入—上下文供给—推理决策—行动执行—验证反馈—可观测”来记。任务接入层解决”任务怎么来”，上下文供给层解决”模型看到什么”，推理决策层解决”模型怎么思考”，行动执行层解决”怎么影响外部世界”，验证反馈层解决”做得对不对”，可观测层解决”出问题时怎么排查”。层与层之间是逐层依赖、逐层反馈——任务接入触发上下文供给，上下文供给和行动执行的结果喂给推理决策，推理决策的输出由验证反馈把关，可观测层贯穿所有层记录所有事件。这个分层最大的工程价值是：每一层都可以独立优化、独立替换、独立测试。讲这一题我会特别强调验证反馈层和可观测层——很多团队做 Agent 只关注”能不能做”，忽略”做得对不对""出问题时怎么查”，这两层恰恰是生产 Agent 区别于 Demo 的关键。

核心答案#

Harness 不是一次设计永久有效的系统。模型能力升级后，Harness 里的某些机制可能变得多余、过时甚至有害，必须重新评估和调整。

为什么会发生这种情况？Harness 的每个组件都建立在”模型做不好什么”的假设上。模型能力提升后，原本”做不好”的事可能变”能做”了，原本”必须引导”的事可能不再需要引导，原本”必须验证”的事可能不再需要验证。

具体表现有四种：

第一种，原本必要的引导变得多余。比如 GPT-3 时代，Prompt 里必须详细写”输出 JSON 格式”才有 50% 概率遵守；GPT-4 时代只要说”用 JSON 输出”就 95% 遵守；Claude 4 时代可能直接给 schema 就够。原本”反复调 Prompt 引导格式”的 Harness 工作变得多余。

第二种，原本必要的验证可以放松。比如模型变强后，结构化校验可以减少；强模型输出错误率下降，重试机制可以简化。

第三种，原本的兜底策略可能反噬。比如”模型可能编造事实，所以要做事实核查”——但如果模型变强后，事实核查本身也用 LLM 做，反而引入了新的不确定性；或者”模型可能漏步骤，所以要做步骤断言”——但如果模型能力变强，步骤断言可能过度约束，反而让模型不敢决策。

第四种，Harness 复杂度成为新瓶颈。当 Harness 越做越复杂，模型能力升级后，部分组件可能从”帮助模型”变成”拖慢模型”。多余的 Context、冗余的验证、复杂的路由会显著增加延迟和成本。

重新验证的方法有四个：

第一，回归测试。保留历史任务样本，模型升级后跑一遍，看通过率、轨迹质量、成本变化。

第二，A/B 实验。新旧 Harness 同时跑，对比效果。

第三，组件级评估。逐一评估 Harness 每个组件的边际贡献——把某组件去掉，看 Agent 表现下降多少。

第四，失败案例回放。分析历史失败任务，模型升级后是否还会失败。

Harness 工程的反模式是”模型换了，Harness 不动”。这会导致 Harness 和新模型能力不匹配，Agent 表现要么过度受限（被旧 Harness 拖累），要么过度放任（失去旧 Harness 保护）。

关键要点#

• 模型能力升级后，Harness 组件可能变得多余、过时甚至有害。
• 重新验证的四种方法：回归测试、A/B 实验、组件级评估、失败案例回放。
• 常见反模式是”模型换了，Harness 不动”。

容易踩的坑#

• 把 Harness 设计成”一劳永逸”的静态系统。
• 不知道模型升级后 Harness 需要重新评估。
• 不做组件级评估，无法判断每个组件的边际价值。

示范话术#

模型能力升级后，Harness 里的某些机制必须重新验证。原因：Harness 的每个组件都建立在”模型做不好什么”的假设上，模型变强后，“做不好”的事可能变”能做”，原本必要的引导就变得多余。具体表现有四种：原本必要的引导变得多余、原本必要的验证可以放松、原本的兜底策略可能反噬、Harness 复杂度成为新瓶颈。我举个例子：GPT-3 时代 Prompt 里必须反复强调”输出 JSON 格式”，GPT-4 时代说”用 JSON 输出”就够，到更强的模型直接给 schema 就够——那些”反复调 Prompt 引导格式”的 Harness 工作就成了历史包袱。重新验证的方法有四个：回归测试、A/B 实验、组件级评估、失败案例回放。讲这一题我会强调：Harness 工程的反模式是”模型换了，Harness 不动”，这会导致 Harness 和新模型能力不匹配，要么过度受限要么过度放任。

核心答案#

上下文污染、代码熵积累、工具调用可靠性是 Agent 一线工程里最常见的三类问题。每类问题有不同的根因和治理方法。

上下文污染指上下文窗口里出现大量噪声、无关、过期、错误信息，挤占关键信息空间，导致模型表现下降。典型表现：Agent 答非所问、调用错工具、重复执行、目标跑偏。

治理方法有五个：

• 写入端治理：写入门槛、置信度标注、定期 Review、可回滚（详见记忆篇）。
• 读取端治理：按需检索、相关性排序、Token 预算、过期过滤、冲突屏蔽。
• 结构化分区：用 XML 标签或 JSON 字段区分不同信息源。
• 压缩与淘汰：定期压缩长上下文，淘汰无关历史。
• 可观测性：记录每次召回了什么、用没用上，事后反查污染源。

代码熵积累指 Agent 在长任务中反复生成相似代码、重复造轮子、引入重复依赖、产生低质量代码，导致代码库越来越乱。典型表现：生成的代码功能重复、风格不一致、依赖冲突、测试覆盖不足。

治理方法有四个：

• 检索增强：每次生成代码前先检索代码库，看是否已有类似实现。
• 代码模板：沉淀常用代码模式为模板，Agent 优先用模板而不是从零写。
• 去重检查：在 Agent 写入代码前做相似度检查，重复就提示复用。
• 质量门禁：CI 流水线里跑 Lint、单元测试、复杂度检查、依赖审计。

工具调用可靠性指工具调用过程中出现参数错误、超时、调用错工具、调用失败、返回结果混乱等问题。典型表现：Agent 调错工具、参数填错、调用超时、死循环调用。

治理方法有五个：

• 工具 description 优化：写清楚”能做什么、什么时候用、参数怎么传、副作用是什么、不适用场景”。
• 参数校验：类型、范围、长度、格式严格校验。
• 超时和重试：每个 Tool 调用设超时，区分可重试错误和不可重试错误。
• 降级方案：工具不可用时有备选方案。
• 限流：防止 Agent 死循环把下游打爆。

三类问题的共同治理思路是”假设问题一定会发生，把系统设计成’即使出问题也不会造成灾难’“。

关键要点#

• 上下文污染、代码熵、工具调用可靠性是 Agent 一线工程三大难题。
• 每类问题有不同的根因和治理方法，但都遵循”假设问题会发生”的思路。
• 写入端、读取端、工具端、CI 端、可观测端都要补防护。

容易踩的坑#

• 只关注一类问题，忽略其他两类。
• 治理方法只做表面，不做根本性优化（比如只压缩不治源头）。
• 缺少可观测性，出问题无法定位。

示范话术#

一线 Agent 工程有三类典型问题：上下文污染、代码熵积累、工具调用可靠性。上下文污染指窗口里噪声太多导致模型表现下降，治理从两端做——写入端做门槛、置信度、Review、回滚；读取端做按需召回、排序、预算、过滤；同时配合结构化分区、压缩淘汰、可观测性。代码熵积累指 Agent 长任务里反复造轮子、生成低质量代码，治理用检索增强、代码模板、去重检查、CI 质量门禁。工具调用可靠性问题包括参数错、超时、调用错工具、死循环，治理用 description 优化、参数校验、超时重试、降级、限流。三类问题的共同治理思路是”假设问题一定会发生”。讲这一题我会强调：这三类问题不是”要不要治理”的问题，是”治理到什么程度”的问题——治理不到位，上线后一定翻车。

核心答案#

评测器、验证器、任务状态管理是 Agent 工程化”质量、可靠性、可恢复性”三大支柱。每一个都解决 LLM 不可靠带来的工程问题。

评测器（Evaluator） 解决”怎么知道 Agent 表现好不好”。LLM 输出具有随机性、不可预测性，传统的 Pass/Fail 测试不够用。评测器通过多种方法评估 Agent 表现：

• 任务完成率：任务是否最终完成、完成质量如何。
• 工具调用准确率：调对了哪些工具、调错了哪些、参数填对率。
• 轨迹质量：执行路径是否合理、有无冗余步骤。
• Token 成本和延迟：每任务消耗多少 Token、多少时间。
• 失败模式分类：失败任务按错误类型分类（参数错、工具不可用、目标跑偏、循环死锁）。

评测器是 Agent 项目的”数据基础设施”，没有它就无法量化改进。

验证器（Validator） 解决”怎么在执行过程中发现错误”。验证器在 Agent 输出的关键节点做检查：

• 输出结构化校验：模型输出是否合法 JSON、字段是否齐全。
• 断言检查：中间结果是否满足预期条件，比如”查询用户接口必须返回非空列表”。
• 用户确认：高敏感操作前要求用户确认。
• 跨步一致性检查：上一步输出和下一步输入是否逻辑一致。

验证器是 Agent 的”实时质检”，能在错误放大前拦截。

任务状态管理（State Management） 解决”任务中断后怎么恢复”。Agent 长任务可能因为超时、崩溃、Token 超限被打断，状态管理保证任务可以从最近断点继续，而不是从零开始。

状态管理包括：

• 状态持久化：把任务进度、已完成步骤、中间结果、关键参数写入 State Store。
• 断点恢复：任务被中断后能加载 State 从断点继续。
• 状态机设计：把任务建模为显式状态机，每个状态有明确的进入条件和退出条件。
• 回滚机制：发现错误后能回滚到之前的状态。

状态管理是 Agent 的”记忆与恢复机制”，没有它长任务几乎无法稳定运行。

三者关系：评测器是”事后看表现”，验证器是”事中查错误”，状态管理是”事前准备 + 事后恢复”。三者共同构成 Agent 工程的”质量三角”。

关键要点#

• 评测器量化 Agent 表现，验证器实时拦截错误，状态管理保证可恢复。
• 三者构成 Agent 工程的”质量三角”。
• 缺任何一个，Agent 都无法稳定生产。

容易踩的坑#

• 只有”事后看表现”，没有”事中查错误”和”事前准备”。
• 评测器只看任务完成率，不看轨迹质量。
• 状态管理设计粗糙，任务中断后无法恢复。

示范话术#

评测器、验证器、任务状态管理是 Agent 工程化的三大支柱。评测器解决”怎么知道表现好不好”——任务完成率、工具调用准确率、轨迹质量、Token 成本、失败模式分类，没有它就无法量化改进。验证器解决”怎么在执行中发现错误”——结构化校验、断言、用户确认、跨步一致性检查，它是 Agent 的实时质检，能在错误放大前拦截。任务状态管理解决”中断后怎么恢复”——状态持久化、断点恢复、状态机设计、回滚机制，它是 Agent 的记忆与恢复机制。三者关系是：评测器事后看，验证器事中查，状态管理事前事后都管。讲这一题我会强调：这三件事缺任何一个，Agent 都无法稳定生产——只有评测器没有验证器，错误会放大；只有验证器没有状态管理，长任务中断就崩。

核心答案#

一线团队做 Agent 工程化时遇到的共同难点，可以总结为七个：模型不确定性、Token 成本爆炸、调试困难、效果评估难、安全合规、用户预期管理、迭代速度。

第一，模型不确定性。同一个 Prompt、同一组上下文，模型每次输出可能不同。这导致 Agent 行为不可预测，同一任务两次执行可能走出不同路径。治理方法：固定随机种子、提高 temperature 约束、增加结构化校验、记录轨迹便于回溯。

第二，Token 成本爆炸。Agent 多步执行、复杂上下文、工具结果累积，Token 消耗远超单轮对话。复杂任务一次执行消耗几十万 Token 并不罕见。治理方法：上下文压缩、记忆按需召回、Prompt 缓存、Sub-agent 拆分、Workflow 兜底。

第三，调试困难。Agent 失败时定位根因极难——是 Prompt 错了、上下文污染了、工具调错了、还是模型本身问题？没有专门 Trace 工具几乎无法排查。治理方法：完善的可观测性、轨迹记录、组件级评估、失败回放平台。

第四，效果评估难。Agent 任务通常很复杂，没有明确的”对/错”标准。LLM-as-Judge 不完全可靠，人工评估成本高。治理方法：建立分层评估体系（自动 + 人工 + 用户反馈）、多维度指标、抽样 Review、A/B 实验。

第五，安全合规。Agent 调用工具、读写数据、对外发送消息，存在越权、数据泄露、Prompt 注入等风险。治理方法：工具白名单、参数校验、权限分级、敏感操作人工确认、审计日志、内容过滤。

第六，用户预期管理。用户经常高估 Agent 能力——以为”全自动数字员工”，实际是不稳定、需要监督的助手。Agent 失败时用户体验骤降。治理方法：明确产品边界、提供进度可见性、失败时优雅降级、引导用户参与关键决策。

第七，迭代速度。Agent 表现受 Prompt、Context、Harness、模型多个因素影响，定位改进点难；A/B 实验周期长；上线风险高。治理方法：建立快速实验平台、组件化设计、灰度发布、明确回滚机制。

这些难点的共同根源是”LLM 的不确定性和传统工程确定性要求的矛盾”。一线团队必须学会在不确定性中构建可用的系统——这正是 Harness Engineering 的核心价值。

关键要点#

• 一线团队七类共同难点：模型不确定性、Token 成本、调试、评估、安全合规、用户预期、迭代速度。
• 共同根源是 LLM 不确定性和工程确定性要求的矛盾。
• Harness 的价值就是”在不确定性中构建可用系统”。

容易踩的坑#

• 只关注技术难点（Token 成本、调试），忽略用户预期管理。
• 把所有难点都寄希望于”模型升级”，不主动做 Harness。
• 没建立评估体系，无法量化改进。

示范话术#

一线团队做 Agent 工程化共同遇到的难点有七个：模型不确定性、Token 成本爆炸、调试困难、效果评估难、安全合规、用户预期管理、迭代速度。这七个难点的共同根源是 LLM 的不确定性和传统工程确定性要求的矛盾——传统软件测试是确定性 Pass/Fail，Agent 同一任务两次跑可能不同路径；传统软件成本可控，Agent 多步执行成本爆炸；传统软件错误栈清晰，Agent 错误定位极难。我特别想强调”用户预期管理”这个常被忽视的难点——用户经常高估 Agent 能力，以为是”全自动数字员工”，实际是不稳定需要监督的助手，期望落差大体验就崩。讲这一题我会总结一句话：Agent 工程的本质是”在不确定性中构建可用系统”，这正是 Harness 的核心价值。