从 Prompt 到 Harness：AI Agent 工程的三次范式迁移

前言

在过去两年中，AI 应用的工程范式正在经历一场深刻的演进。从最初的 Prompt Engineering，到 Context Engineering，再到近期逐渐成为行业共识的 Harness Engineering，这一系列概念的变化并不仅仅是术语的更替，而是 AI 系统复杂度不断提升之后的必然结果。

如果你最近在做 Agent，或者尝试推动 AI 在真实业务中的落地，很可能已经遇到这样的问题：为什么同样的模型，在别人手里可以稳定运行并完成复杂任务，而在自己系统中却始终表现不稳定，成功率难以提升？

很多团队最初会怀疑模型能力、提示词设计，甚至参数配置。但实践反复证明，真正决定系统是否能够稳定运行的，往往不是模型本身，而是模型之外那套“运行环境”。这套系统，如今被统一称为 Harness。

AI 工程的三次迁移

如果从工程视角回看 AI 的发展，可以清晰地看到三个阶段，每个阶段都对应着一个核心问题。

Prompt Engineering：模型有没有听懂你的问题？

在大模型刚兴起时，最直观的现象是：同一个模型，仅仅改变提问方式，输出结果就可能发生巨大变化。因此，当时的核心共识是：模型不是不会，而是你没有把问题表达清楚。

Prompt Engineering 正是在这样的背景下兴起。开发者通过角色设定、风格约束、示例引导、输出格式控制等手段，引导模型在一个更有利的“概率空间”中生成结果。

从本质上看，提示词工程并不是在“命令模型”，而是在塑造模型的局部概率分布。这一阶段的核心能力，是语言表达能力，而非系统设计能力。

然而，Prompt Engineering 很快遇到了瓶颈。因为很多问题并不是“说清楚”就能解决的，而是需要模型真正“知道”。

Context Engineering：模型有没有拿到正确的信息？

当任务从简单问答升级为复杂任务执行时，问题开始发生变化。例如：

分析企业内部文档结合历史数据生成决策建议调用多个工具完成复杂流程

此时，单纯依靠提示词已经无法支撑任务完成。模型的表现开始取决于它是否能够获取到完整且正确的信息。

需要强调的是，这里的 Context 并不仅仅是几段背景资料，而是所有影响模型决策的信息总和，包括：

用户输入与历史对话检索结果（RAG）工具调用返回结果当前任务状态与中间结果系统规则与安全约束

因此，Prompt 只是 Context 的一个子集。成熟的 Context Engineering 关注的是整条链路，例如：

文档如何切分与排序长文本如何压缩历史信息何时保留或摘要工具结果如何筛选与结构化

Harness Engineering：模型能否持续做对？

在真实环境中，即便模型理解正确、信息充分，也未必能够稳定完成任务。常见问题包括：

执行过程中逐渐偏离目标错误使用工具长链路任务中状态混乱无法发现自身错误

这类问题本质上已经超出了输入侧优化的范畴。Prompt 和 Context 解决的是“输入问题”，而这里需要解决的是“执行过程问题”。这正是 Harness Engineering 出现的背景。

Harness 的原意是“缰绳”，用于约束和控制。在 AI 系统中，它代表的是：对整个执行过程的控制、约束与纠偏机制。AI Agent = LLM Harness，即除 LLM 外都可以归属到 Harness 中。

Harness Engineering 的系统结构

从工程角度来看，一个成熟的 Harness 通常可以拆分为六个层次。

上下文控制（Context Control）

模型是否稳定发挥，很大程度上取决于它“看到了什么”。

这一层的核心在于：

明确角色与任务目标精准裁剪上下文信息对信息进行结构化组织

上下文不是越多越好，而是越相关越好。

工具系统（Tooling）

没有工具的模型，本质上只是一个文本生成器。

Harness 不仅负责接入工具，还要解决：

工具的选择与数量控制工具调用时机判断工具返回结果的筛选与重构

关键在于让模型“合理使用工具”，而不是“随意调用工具”。

执行编排（Orchestration）

这一层解决的问题是：模型下一步该做什么。

一个完整任务通常包括：

理解目标判断信息是否充分补充信息执行操作校验结果必要时重试

这实际上是在构建一条类似人类工作流程的执行轨道。

状态与记忆（State & Memory）

如果没有状态管理，Agent 每一轮都会像“失忆”。

系统需要区分三类信息：

当前任务状态中间结果长期记忆与用户偏好

清晰的状态管理，是稳定协作的前提。

评估与观测（Evaluation & Observability）

很多系统的问题不是“做不出来”，而是“做完不知道对不对”。

这一层通常包括：

输出结果校验自动化测试日志与指标监控错误归因分析

系统不仅要能做，还要知道自己是否做对。

约束、校验与恢复（Guardrails & Recovery）

在真实环境中，失败是常态，而不是例外。

因此系统必须具备：

行为约束（能做什么、不能做什么）关键步骤校验机制失败后的重试与恢复能力

这一层往往决定系统是否具备上线能力。

一线公司的实践启示

当前，Harness Engineering 已经在多家领先公司中落地。

Anthropic：上下文重置与角色分离

Anthropic 发现，长时间运行后上下文会变得混乱，因此采用了“Context Reset”机制，即在必要时重启 Agent，并迁移关键状态。

同时，他们将系统拆分为：

Planner（规划）Generator（执行）Evaluator（评估）

通过“生成与验收分离”，构建闭环反馈机制。

OpenAI：渐进式信息披露与自动化治理

OpenAI 的实践强调：

将庞大的规则体系拆分为分层文档按需加载信息，而非一次性注入让 Agent 能够操作真实环境（浏览器、日志、监控）将工程经验转化为系统规则，实现自动化治理

其核心思路是：让 Agent 不只是“写代码”，而是能够“运行、验证并修复”。

总结：从“聪明”到“可靠”的转变

回顾整个演进过程，可以用一句话总结：

Prompt Engineering 解决表达问题Context Engineering 解决信息问题Harness Engineering 解决执行问题

三者并不是替代关系，而是逐层扩展的包含关系。

当任务简单时，Prompt 足够；当任务依赖信息时，Context 必不可少；而当任务进入真实世界、需要长期稳定执行时，Harness 就成为决定成败的关键。

因此 AI 落地的核心挑战，正在从“让模型更聪明”，转向“让系统更可靠”。模型决定上限，而 Harness 决定能否真正落地。