前言

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

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

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

AI 工程的三次迁移

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

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

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

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

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

提示词工程的本质不是控制模型，而是通过上下文设计，约束并引导模型在当前语境下的概率分布，使目标输出成为“更高概率事件”。

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

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

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

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

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

Context Engineering 的核心就是在合适的时机，将正确的信息注入模型的上下文中。

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

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

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

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

一个典型的实践是“渐进式披露”：不是一次性提供全部信息，而是在需要时逐步注入，从而避免上下文过载。

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

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

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

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

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

如果说 Prompt 关注“说清楚”，Context 关注“给对信息”，那么 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 决定能否真正落地。