Harness Engineering：AI Agent 稳定落地的核心引擎

分析、整理并扩写。原材料存在表格错位、条目缺失和个别疑似转写错误，本文在不改变核心观点的前提下重构了内容。文中企业实践部分作为工程思路示例，不作为对相关公司内部架构的完整或最新官方描述。

一、原材料分析

原材料试图回答一个重要问题：为什么同一个大模型在演示环境里表现很好，接入真实业务后却经常不稳定？

它给出的答案是，模型本身只决定系统能力的一部分。要让 AI Agent 从“偶尔能做对”走向“持续、稳定、可验证地完成任务”，还需要在模型之外建立完整的运行体系，包括上下文、工具、任务编排、状态管理、评估观测、约束校验和失败恢复。这套体系被称为 Harness Engineering。

材料最有价值的三点是：

1. 用 Prompt、Context、Harness 三个层次解释 AI 工程关注点的演进；
2. 将成熟 Harness 拆分为六个相互配合的工程层；
3. 强调验证、状态和恢复能力，而不是只关注模型生成质量。

原材料也存在几处需要修正或补充的地方：

• 三阶段对比表在纯文本中发生了字段错位，需要重新排版；
• “检索增强（IG）”更可能是“检索增强生成（RAG）”的转写错误；
• “上下文边界层”的关键组件从第 1 项直接跳到第 3 项，第 2 项缺失；本文结合上下文补充为“信息选择与边界控制”；
• 企业案例没有列出来源、产品版本和时间，应作为方法论示例审慎表述；
• 原材料主要讲技术组成，但对安全权限、人工治理、评估指标和实施路线展开不足，本文予以补全。

二、Harness Engineering 的定义

Harness 的本义是挽具、背带或控制装置。在 AI Agent 语境下，可以把它理解成一套“驾驭系统”：不是替代模型思考，而是让模型在清晰目标、正确上下文、有限权限和可验证流程中完成真实任务。

一个相对完整的定义是：

Harness Engineering 是围绕 AI Agent 建设运行环境和工程控制体系的实践。它涵盖模型之外所有影响任务稳定交付的关键能力，包括目标定义、上下文供给、工具调用、流程编排、记忆与状态、质量评估、运行观测、权限约束、异常恢复和人工治理。

它要解决的不是“模型能不能生成一个正确答案”，而是以下一组更接近生产环境的问题：

• Agent 是否理解了真实目标；
• Agent 是否拿到了正确且足够的信息；
• Agent 是否选对了工具和执行顺序；
• 执行中断后能否继续，而不是从头开始；
• 结果是否经过独立验证；
• 失败后能否停止、重试、回滚或请求人工处理；
• 全过程是否可观察、可审计、可追责；
• 系统能否在可接受的成本和风险内重复运行。

因此，Harness Engineering 的核心不是让模型“看起来更聪明”，而是把不稳定的概率性能力组织成相对稳定的工程能力。

三、为什么只有模型还不够

大模型擅长理解语言、归纳信息、生成方案和调用工具，但它天然具有一些不适合直接进入生产流程的特点：

• 输出具有概率性，同一输入可能产生不同结果；
• 容易在信息不足时做出合理猜测；
• 长任务中可能遗忘早期约束或偏离目标；
• 对自身答案的判断不一定可靠；
• 不天然掌握企业内部的最新知识和隐性规则；
• 不理解某个操作在真实环境中的业务后果；
• 无法仅靠语言推理证明代码、数据或界面真的正确；
• 面对工具故障、网络异常和状态冲突时可能无序重试。

在演示中，这些问题可能只表现为一次回答不够准确；在生产系统中，却可能造成错误写入、重复操作、敏感信息泄露、服务中断或难以追责。

Harness 的作用，就是把目标、事实、权限、工具和验证从模型内部推理中剥离出来，变成外部可控制、可检查的工程机制。

四、AI 工程的三个关注层次

Prompt Engineering、Context Engineering 和 Harness Engineering 并不是简单的替代关系，而是从局部到整体的逐层扩展。

层次	核心问题	主要手段	技术重点	主要局限
Prompt Engineering（提示词工程）	模型是否听懂指令	角色设定、任务说明、格式约束、少样本示例	优化语言表达	无法补齐缺失知识，也难以管理持续变化的外部状态
Context Engineering（上下文工程）	模型是否获得了正确的信息	RAG、信息筛选、渐进式披露、上下文分层	优化信息供给	不能单独解决长任务中的执行监督、权限控制和失败恢复
Harness Engineering（驾驭工程）	Agent 能否持续、稳定地完成任务	工具系统、执行编排、状态管理、验证观测、约束恢复	优化完整运行系统	建设复杂度更高，需要跨模型、数据、平台、安全和业务协同

1. Prompt Engineering：把话说清楚

Prompt Engineering 关注如何表达任务，让模型更准确地理解角色、目标、限制和输出格式。

常见方式包括：

• 明确模型身份和任务目标；
• 规定输出结构；
• 提供正例和反例；
• 拆分复杂要求；
• 说明禁止事项；
• 要求模型先分析再输出。

提示词很重要，但它不能创造模型没有获得的事实，也不能替代真实环境中的执行和验证。

2. Context Engineering：把信息给对

Context Engineering 关注的不只是“给更多资料”，而是“在正确的时间提供正确的信息”。

典型机制包括：

• 从知识库或代码库检索相关内容；
• 只在需要时加载详细资料；
• 区分稳定规则、当前任务和临时证据；
• 对过期、冲突和低可信信息进行过滤；
• 为不同步骤提供不同粒度的上下文；
• 对长任务做摘要和信息压缩。

上下文工程可以减少知识缺失和信息噪声，但如果没有流程控制、外部验证和失败恢复，Agent 仍可能在执行中逐渐偏离。

3. Harness Engineering：让系统持续做对

Harness Engineering 把 Prompt 和 Context 纳入更大的系统边界，并增加真实行动所需的工具、状态、流程、验证、安全和恢复机制。

三者可以概括为：

Prompt 解决“说清楚”，Context 解决“信息对”，Harness 解决“在真实环境里持续做对”。

五、成熟 Harness 的六层架构

六层不是彼此孤立的模块，而是一个相互制约的闭环。上层定义目标和信息边界，中间层负责执行与状态，下层提供验证、控制和恢复。

1. 上下文边界层

核心目标

确保 Agent 在正确的问题范围、事实范围和责任范围内思考，避免因目标模糊、信息污染或规则冲突而偏离任务。

关键组件

角色与目标定义

需要明确：

• Agent 当前扮演什么角色；
• 要解决什么问题；
• 哪些内容属于任务范围；
• 成功标准是什么；
• 哪些决策可以自主完成；
• 哪些情况必须请求人工确认。

信息选择与边界控制

这是对原材料缺失条目的补充。它负责：

• 选择与当前任务直接相关的信息；
• 排除无关、过期或未经授权的数据；
• 标注事实来源和可信等级；
• 处理规则之间的优先级；
• 控制上下文长度和敏感信息暴露。

结构化组织

建议将上下文分为：

• 长期稳定规则：安全政策、组织规范、业务红线；
• 项目知识：架构、术语、接口、数据定义；
• 当前任务：目标、范围、步骤和验收条件；
• 动态状态：已完成事项、待处理问题和中间结果；
• 外部证据：日志、检索结果、测试报告和工具返回值。

设计原则

• 只提供当前步骤真正需要的信息；
• 权威规则与普通资料分开；
• 动态状态与长期知识分开；
• 所有关键事实尽量可追溯；
• 过期信息应有更新或失效机制。

2. 工具系统层

核心目标

为 Agent 提供连接现实世界的受控接口，使其能够检索、计算、修改、测试和执行，而不只是输出文字建议。

工具类型

• 信息工具：搜索、数据库查询、知识库检索、日志读取；
• 开发工具：文件编辑、版本控制、编译、测试和静态分析；
• 业务工具：订单查询、内容发布、工单创建、客户信息读取；
• 交互工具：浏览器、桌面操作、表单填写和截图；
• 运维工具：监控查询、部署、扩缩容和回滚；
• 协作工具：发送消息、生成报告、申请审批和任务交接。

三个关键难题

工具选择

工具太少会限制能力，工具太多则会增加选择错误、权限风险和调用成本。应优先提供边界清晰、稳定、可组合的工具。

调用时机

Agent 需要知道什么时候应该查证，什么时候可以直接回答。既要避免可以读取事实时凭空猜测，也要避免每个简单问题都进行高成本调用。

结果处理

工具可能返回大量噪声、错误状态或不完整结果。Harness 需要对返回值进行结构化、筛选、截断和可信度标注，使它成为后续决策的有效证据。

工具设计要求

• 输入参数有明确类型和约束；
• 输出结构稳定；
• 错误信息可被 Agent 理解；
• 写操作尽量支持幂等和回滚；
• 高风险工具必须设置审批；
• 工具调用过程必须留痕；
• 凭据不直接暴露给模型。

3. 执行编排层

核心目标

将复杂目标拆成可执行、可检查、可恢复的步骤，防止 Agent “想到哪做到哪”。

典型执行流程

1. 理解目标和验收标准；
2. 检查已有信息是否足够；
3. 获取缺失信息；
4. 生成可执行计划；
5. 按计划调用工具；
6. 检查每一步结果；
7. 根据证据进行修正；
8. 完成整体结果验证；
9. 输出交付物和执行摘要。

编排层应具备的能力

• 任务分解与依赖管理；
• 步骤状态记录；
• 超时与重试次数限制；
• 并行任务协调；
• 条件分支与异常分支；
• 人工审批节点；
• 中断后的继续执行；
• 达到终止条件后及时停止。

编排的价值不在于把所有任务变成固定流程，而在于为动态决策提供稳定骨架。

4. 记忆与状态层

核心目标

解决 Agent 在长任务、多轮会话和跨会话协作中的“失忆”与状态混乱问题。

三类状态

当前任务状态

包括任务目标、当前步骤、已完成事项、待办事项、阻塞原因、权限状态和验收进度。

会话中间结果

包括临时分析、工具返回、代码差异、测试结果和正在使用的假设。这类信息有价值，但通常不应永久保存。

长期记忆与用户偏好

包括经过确认的用户偏好、稳定业务规则、长期项目决策和历史成功经验。

管理原则

• 任务状态、临时证据和长期知识分类存储；
• 长期记忆写入前应确认真实性和必要性；
• 用户偏好不能覆盖安全政策或当前明确指令；
• 敏感信息设置保存期限和访问权限；
• 对旧状态进行版本管理，避免把过期信息当成当前事实；
• 关键状态外部化，不能只依赖模型上下文。

5. 评估与观测层

核心目标

建立独立于 Agent 自我判断的质量反馈机制，避免“自我感觉良好”。

评估体系

• 规则验证：格式、字段、范围、政策是否合规；
• 确定性测试：计算结果、代码测试、查询校验；
• 模型评估：对开放性内容进行多维度打分；
• 人工验收：处理高价值、高风险或主观性任务；
• 线上反馈：观察真实用户行为和业务结果；
• 回归评测：确保系统升级后旧能力没有明显退化。

可观测内容

• 输入目标和上下文来源；
• 计划及关键决策；
• 每次工具调用及返回状态；
• 状态变化；
• 失败类型和重试过程；
• 输出内容与验证证据；
• 执行时长、资源消耗和成本；
• 人工介入和审批记录。

观测的价值

观测不是为了保存所有模型思考过程，而是为了回答：系统做了什么、依据是什么、哪里失败、如何恢复、结果是否可信。

6. 约束校验与恢复层

核心目标

在错误不可避免的前提下，控制错误影响并让系统恢复到可继续工作的状态。

约束机制

约束回答“Agent 可以做什么、不能做什么”。主要包括：

• 最小权限；
• 目录和数据访问范围；
• 网络与外部服务白名单；
• 资源、时间和成本上限；
• 高风险动作审批；
• 敏感信息保护；
• 操作频率和并发限制。

校验机制

校验应覆盖执行前、执行中和执行后：

• 执行前检查参数、权限和前置条件；
• 执行中检查状态变化和异常信号；
• 执行后检查结果、影响范围和验收标准。

恢复机制

• 对瞬时故障进行有限重试；
• 对参数错误先修正再重试；
• 设置检查点并从最近状态恢复；
• 对写操作使用事务、备份或补偿动作；
• 超过风险阈值时自动停止；
• 无法可靠判断时升级给人工处理。

真正决定系统可用性的，往往不是它从不失败，而是它能否识别失败、限制损失并恢复。

六、六层架构如何协同

以“让 Agent 修复一个线上系统的登录异常”为例：

1. 上下文边界层说明问题范围、禁止直接修改生产数据，并提供登录模块架构；
2. 工具系统层允许读取日志、搜索代码、修改测试环境文件和运行测试；
3. 执行编排层要求先复现、再定位、再修改、最后回归；
4. 记忆与状态层记录已经排除的原因、修改内容和当前验证进度；
5. 评估与观测层保存日志证据，运行单元测试和端到端登录测试；
6. 约束校验与恢复层阻止未经批准的生产发布，并在测试失败时回滚改动。

如果缺少其中任何一层，系统都可能出现明显问题：

• 没有上下文边界，Agent 可能修改错误模块；
• 没有工具系统，只能给出建议，无法验证；
• 没有执行编排，可能跳过复现直接改代码；
• 没有状态管理，长任务中会重复操作或忘记结论；
• 没有评估观测，无法证明问题已经解决；
• 没有约束恢复，错误操作可能直接影响生产。

七、实践案例的工程化解读

原材料提到 Anthropic 和 OpenAI 的若干做法。由于材料未给出来源和版本，下面不把它们表述为相关公司的完整官方架构，而是提炼其中具有普遍价值的方法。

1. 长任务中的上下文重置

长时间运行的 Agent 会不断积累对话、工具结果和中间分析。上下文越长，不一定效果越好，反而可能出现：

• 早期错误持续影响后续判断；
• 重要约束被大量细节淹没；
• 重复信息增加成本；
• 状态与事实互相冲突；
• 模型注意力下降。

上下文重置的核心不是简单清空，而是先将任务状态外部化，再建立一份经过筛选的恢复摘要，然后在更干净的上下文中继续工作。

建议保留：

• 原始目标和验收标准；
• 当前进度；
• 已确认事实；
• 已完成改动；
• 未解决问题；
• 下一步计划；
• 关键证据的引用位置。

这相当于保存进程状态后重新启动，避免无效历史不断堆积。

2. 规划、生成与评估角色分离

如果同一个 Agent 同时负责提出方案、执行方案和评价自己，很容易出现自我确认偏差。角色分离可以形成更清晰的责任：

• Planner：把需求转化为规格、步骤和验收标准；
• Generator：根据规格执行任务并生成结果；
• Evaluator：基于测试、环境和外部规则判断结果是否合格。

角色分离不一定要求三个不同模型，也可以通过独立上下文、不同工具权限和明确的输入输出接口实现。关键是评估者不能只重复生成者的结论，而应获得独立证据。

3. 渐进式披露

与其一次性把巨型文档塞入上下文，不如先提供目录、摘要和索引，在 Agent 确认需要时再加载具体章节。

这种方式能够：

• 减少信息噪声；
• 降低上下文成本；
• 让当前步骤更聚焦；
• 更容易控制敏感信息；
• 降低过期文档影响。

4. 环境化验证

语言上的“看起来正确”不能代替真实验证。环境化验证要求 Agent 在目标环境或可信模拟环境中执行操作，例如：

• 运行代码和自动化测试；
• 打开页面并检查视觉结果；
• 查询日志和指标；
• 在隔离环境中演练部署；
• 比较操作前后的数据；
• 验证用户能够真正完成目标流程。

环境化验证把答案质量从主观判断转化为可观察证据。

5. 将资深经验编码为规则

资深工程师的价值往往存在于隐性经验中，例如某类故障的判断顺序、某个模块的历史兼容限制、某种操作的回滚方式。Harness 可以把这些经验转化为：

• 可执行检查；
• 工具使用规范；
• 任务模板；
• 错误分类规则；
• 修复建议；
• 审批条件；
• 回归测试。

需要注意的是，规则必须有版本、所有者和更新机制。否则，经验被编码后也可能逐渐过期。

八、评估 Harness 的指标体系

1. 任务结果指标

• 任务成功率；
• 首次验收通过率；
• 需求偏离率；
• 人工返工率；
• 生产缺陷率。

2. 稳定性指标

• 相同任务多次运行的一致性；
• 长任务中断率；
• 工具调用失败率；
• 自动恢复成功率；
• 异常操作拦截率。

3. 自主性指标

• 无需人工介入的任务比例；
• 单任务平均人工介入次数；
• 因信息不足产生的暂停次数；
• 从目标到交付的自动闭环比例。

4. 效率与成本指标

• 单个成功任务的总成本；
• 平均完成时间；
• 无效工具调用次数；
• 无效重试次数；
• 上下文使用量；
• 人工节省时间。

5. 安全与治理指标

• 越权尝试次数；
• 高风险操作审批覆盖率；
• 敏感信息泄露事件；
• 审计记录完整率；
• 回滚成功率；
• 规则和知识的更新及时性。

指标应以“成功交付”为分母。例如，仅统计调用成本可能鼓励系统少调用必要工具，却降低任务成功率；更合理的是统计每个成功任务的成本。

九、常见失败模式

1. 把 Harness 等同于提示词模板

问题：优化了语言说明，却没有工具、状态、验证和恢复机制。

后果：演示效果改善，但复杂任务仍不稳定。

2. 上下文越多越好

问题：把整个知识库或代码库直接塞给 Agent。

后果：信息冲突、重点稀释、成本上升，模型更容易遗漏关键规则。

3. 工具数量优先于工具质量

问题：接入大量功能重叠、参数混乱的工具。

后果：Agent 选择困难，错误率上升，审计和权限管理复杂。

4. 依赖 Agent 自我评估

问题：Agent 生成结果后直接判断自己已完成任务。

后果：错误无法被独立发现，形成虚假成功。

5. 状态只保存在对话中

问题：进度、证据和决策全部依赖当前上下文。

后果：一旦上下文重置或服务中断，任务无法可靠恢复。

6. 无限制重试

问题：失败后反复调用同一个工具或重复同一方案。

后果：成本失控、重复写入，甚至扩大故障。

7. 为追求自动化而取消必要审批

问题：对生产写入、删除、外发和发布等操作也完全自动执行。

后果：小概率错误转化为不可接受的业务风险。

8. 只优化平均效果

问题：只看大部分普通任务表现，不处理低频高风险场景。

后果：整体成功率很高，仍可能因一次严重错误造成重大损失。

十、建设 Harness 的分阶段路线

第一阶段：单任务闭环

先选择低风险、结果可验证的任务，例如生成报告、代码检查、测试补充或内部资料整理。

最低要求：

• 任务目标和验收标准清晰；
• 有限且可靠的工具；
• 全过程留痕；
• 输出可以自动或人工验证；
• 失败后安全停止。

第二阶段：标准化上下文与工具

• 建立知识目录和检索机制；
• 区分组织规则、项目知识和任务状态；
• 统一工具输入输出；
• 建立权限分级；
• 对敏感数据进行脱敏和隔离。

第三阶段：引入状态与恢复

• 将任务进度外部化；
• 设置检查点；
• 建立错误分类；
• 区分可重试与不可重试错误；
• 支持回滚和人工接管。

第四阶段：建立评估和观测体系

• 建立离线评测集；
• 记录线上成功率和失败类型；
• 为关键任务加入独立验证；
• 监测成本、时延和人工介入；
• 对模型、提示、工具和规则变更进行回归评测。

第五阶段：规模化治理

• 建立统一的风险分级；
• 明确各类操作的责任人与审批人；
• 维护组织级工具和规则平台；
• 建立事故复盘和规则更新机制；
• 持续比较不同模型和流程；
• 防止局部自动化带来系统性风险。

十一、最小可用 Harness 清单

一个可以开始投入真实任务的最小 Harness，至少应具备：

• 明确的目标、范围和验收标准；
• 分层且可追溯的上下文；
• 少量稳定、结构化的工具；
• 隔离执行环境；
• 最小权限和高风险操作审批；
• 可恢复的任务状态；
• 外部验证机制；
• 有上限的重试；
• 日志、差异和结果证据；
• 失败后停止、回滚或人工接管的路径。

如果缺少验证、权限或恢复能力，即使 Agent 表现再聪明，也不应直接承担高风险生产任务。

十二、人与 Agent 的新分工

随着 Harness 逐渐成熟，工程师的角色会从直接执行大量细节，转向设计 Agent 能够可靠工作的环境。

人更适合负责

• 定义业务目标和优先级；
• 处理模糊需求与价值冲突；
• 设计系统边界和风险政策；
• 建设工具、评估和恢复机制；
• 审批高风险操作；
• 处理无法规则化的异常；
• 对最终结果承担责任。

Agent 更适合负责

• 信息检索和初步分析；
• 明确流程下的重复操作；
• 代码生成、测试和批量修改；
• 持续运行检查；
• 汇总日志与证据；
• 根据清晰反馈进行迭代。

工程师不是简单地“少写代码”，而是更多地设计环境、规则、工具、反馈和责任边界。

十三、关键结论

1. 模型决定能力上限，Harness 决定稳定下限

更强的模型能够处理更复杂的问题，但没有 Harness，能力无法稳定转化为生产结果。好的 Harness 也不能让弱模型无限突破能力边界，但可以减少大量由信息、流程、工具和验证不足造成的失败。

2. Harness 包含 Prompt 和 Context

提示词和上下文不是过时技术，而是 Harness 的基础组成。Harness 在此基础上进一步加入执行、状态、评估、权限和恢复。

3. 稳定性来自外部闭环

生产级 Agent 的可靠性不应完全依赖模型“自觉做对”，而应来自外部目标、事实、工具、验证和约束共同形成的闭环。

4. 失败恢复与成功能力同样重要

真实环境中，工具会报错、数据会缺失、上下文会冲突。系统是否能够发现错误、限制影响、保存进度并恢复，直接决定它是否可用。

5. AI 落地的竞争正在转向工程系统

当基础模型能力逐渐普及后，团队之间的差距会更多体现在：谁拥有更高质量的上下文、更可靠的工具、更严格的评估、更完善的安全边界，以及更快的反馈改进循环。

十四、总结

Harness Engineering 关注的是 AI Agent 从“能思考”到“能稳定做事”的跨越。

Prompt Engineering 让任务表达更清楚，Context Engineering 让信息供给更准确，而 Harness Engineering 把目标、信息、工具、流程、状态、验证、权限、观测和恢复连接成完整运行系统。

其核心价值可以概括为：

不把生产可靠性寄托在模型每次都恰好做对，而是通过工程化控制，让正确行为更容易发生，让错误更早暴露，让风险受到限制，并让失败之后能够恢复。

因此，Agent 真正落地的关键不只是继续寻找更强的模型，还包括持续建设模型之外的系统。模型提供智能，Harness 把智能转化为可重复、可验证、可治理的生产能力。