从Prompt到Harness：AI工程三代范式对比

一、对比背景：瓶颈正在从模型外移到系统

本文对比的对象是AI工程方法的三代范式：Prompt Engineering（提示词工程）、Context Engineering（上下文工程）与Harness Engineering（运行框架工程）。这三代范式并非三个并列的工具，而是AI应用工程重心在不同阶段的三次迁移，理解它们的区别与衔接关系，是当前做Agent技术选型的基础。

过去几年，大多数AI应用优化的重心是“如何给模型更好的输入”。但一个越来越清晰的变化是：当基础模型能力逐渐成熟之后，真正决定Agent上限的，已经不是模型本身，而是围绕模型搭建起来的整套系统。业内某头部研究机构的资深工程师曾给出一个被广泛引用的判断：“Harness 本身就是数据集，现在真正的竞争优势，在于你的 Harness 能捕获到怎样的执行轨迹。”换句话说，围绕模型构建的运行与管控系统，不仅决定单次执行的质量，还在持续沉淀可复用的数据资产。

从时间线看，2022年至2024年业界的主流是Prompt Engineering，2025年重心转向Context Engineering，而2025年底某旗舰级模型的发布被视为一个标志性事件——模型的Agent能力到达临界点之后，“用好模型的能力”开始比“提高模型的能力”更加重要，Harness Engineering随之成为一线团队投入的重心。这三代范式分别回答三个不同的问题：怎么向模型表达需求、怎么给模型恰到好处的信息、怎么为模型构建可靠的运行系统。

二、对象定义：三代范式分别解决什么问题

1. Prompt Engineering（提示词工程）

关注如何表达需求，重点是打磨单次对话里的指令。典型手段包括：为模型设定身份与角色、补充任务场景与目的、给出少量示例（few-shot）、拆解任务步骤、约束输出格式等。它解决的问题是：让模型正确理解任务，更稳定地给出想要的结果。这一层工程完全发生在“输入文本”之内，不涉及模型外围的任何系统建设。

2. Context Engineering（上下文工程）

关注如何提供恰到好处的信息。随着任务变复杂，单靠指令已经不够，模型需要在有限的上下文窗口内掌握所有背景资料。典型手段包括：检索增强生成（RAG）、多轮对话历史的摘要压缩、长文档的分块与分层组织、按需注入工具说明与状态信息等。它解决的问题是：在上下文窗口有限的前提下，获取、筛选、压缩和组织模型完成任务所需的信息。

3. Harness Engineering（运行框架工程）

“Harness”一词来自马术，本意是马具：模型就像一匹野马，是一股很强但不稳定的力量，人类用马具限定马匹的行为、掌控前进方向，而Harness就是驾驭模型能力的一整套外围系统。它的组成通常包括：运行环境与沙箱、工具调用体系、记忆系统、评估机制、回滚与降级机制、权限与审计管控等，相当于“一个完整的运行环境+管控系统”。如果要下一个定义：Agent = LLM + Harness。模型决定“要做什么”，Harness决定模型“能看到什么、能用什么工具，以及失败时该怎么办”。

三、相同点分析

虽然三代范式的工程重心不同，但它们在底层逻辑上有明显的共性：

• 目标一致：三者都是在不改动（或少改动）模型权重的前提下，提升同一个模型在真实任务上的产出质量与稳定性，属于应用侧的工程优化手段。
• 底层逻辑一致：三代演进背后是同一条规律——一旦模型能力过线，瓶颈就会开始外移。提示词解决不了信息不足的问题时，出现了上下文工程；上下文也兜不住长链路执行的不确定性时，瓶颈进一步外移到系统层。
• 方法论一致：三者都依赖“提出假设—构造输入或环境—观察结果—迭代修正”的实验闭环，都需要建立评估标准来衡量改动是否有效，凭感觉调优在三代范式中都不可持续。
• 关系是叠加而非替代：后一代范式并不取代前一代。Harness内部依然需要精心的提示词设计与上下文组织，只是它们从“全部工作”降级为“系统中的一个环节”。

四、核心差异分析

4.1 系统边界与作用对象

Prompt Engineering的作用边界是单次输入文本；Context Engineering的作用边界是信息供给层，即模型在推理前“看到什么”；Harness Engineering的作用边界则是模型外围的整个运行环境，包括模型在哪执行、能调用哪些工具、状态如何保存、失败如何处置。系统边界逐层扩大，工程对象从“文本”演进到“信息流”，再演进到“系统”。

4.2 工程重心与典型手段

三代范式的日常工程内容差异很大：提示词工程的核心产物是一份不断迭代的指令模板；上下文工程的核心产物是检索链路、压缩策略与信息组织规则；而Harness工程的核心产物是一套带受控执行、观测与恢复能力的运行时。一个典型的Harness主循环可以用通用伪代码示意：

初始化任务与可用工具清单
while 任务未完成:
    observation = 运行环境.获取当前状态()
    context     = 记忆系统.检索(任务目标) + 压缩(observation)
    action      = 模型.决策(context, 可用工具)
    result      = 沙箱.受控执行(action)        # 限定权限与影响范围
    if 评估器.校验(result) == 失败:
        执行回滚或降级策略()                   # 系统级兜底
    记忆系统.写入(本次执行轨迹)                 # 轨迹沉淀，形成数据资产

4.3 失败处理方式

这是三代范式差异最实质的地方。提示词工程面对失败只能重试或改写指令；上下文工程可以补充缺失信息、修正检索结果来降低失败率；Harness工程则在系统层提供隔离、回滚、降级、断点续跑等机制，失败被设计为常态并被系统性兜底。对于有容错底线的生产任务，这一层差异直接决定了方案是否可用。

4.4 数据闭环与资产沉淀

提示词与上下文的优化产物主要是配置和规则，难以直接转化为模型训练数据；Harness的价值则在于持续捕获高质量执行轨迹——任务如何拆解、工具如何调用、失败如何恢复。这些轨迹既可以用于评估与回归测试，也可以回流用于模型与策略的持续改进，形成“跑得越顺、捕获越多、系统越强”的数据飞轮。

4.5 可靠性与安全边界

前两代范式基本不涉及安全设计；Harness则天然承担权限控制、沙箱隔离、操作审计、敏感信息过滤等职责，是Agent从演示走向生产环境的分水岭。

4.6 成本与团队结构

提示词优化成本低、见效快，主要由业务与算法人员承担；上下文工程需要数据与检索链路的建设投入；Harness工程则接近平台级建设，需要基础设施、安全、评估体系的持续投入，人力与维护成本显著更高，但对应的生产可靠性与数据资产价值也更高。

五、对比表格

对比维度	Prompt Engineering	Context Engineering	Harness Engineering
阶段定位	2022–2024 主流	2025 主流	2026 起重心
核心问题	如何表达需求	如何供给恰到好处的信息	如何构建可靠运行系统
作用边界	单次输入文本	信息获取、压缩与组织	环境、工具、记忆、评估、回滚
典型手段	角色设定、示例、格式约束	RAG、摘要压缩、信息分层	沙箱、工具编排、评估、回滚
失败处理	重试、改写指令	补充或修正上下文	隔离、回滚、降级、断点续跑
数据沉淀	模板与规则	会话与检索日志	执行轨迹，可形成数据飞轮
安全能力	基本不涉及	少量信息过滤	权限、沙箱、审计、合规管控
建设成本	低	中	高，接近平台建设
适用阶段	原型验证、轻量任务	知识密集型任务	生产级、长链路自主任务

六、典型场景选择

• 快速验证与轻量任务（文案生成、格式转换、单轮问答）：Prompt Engineering为主即可满足，引入完整Harness属于过度建设。
• 知识密集型企业应用（内部知识问答、文档摘要、客服辅助）：以Context Engineering为核心，重点投入检索质量与上下文组织。
• 长周期自主任务与生产级Agent（代码生成与执行、自动化运维、多步骤数据分析）：必须以Harness Engineering为核心，否则失败率与安全风险不可控。
• 模型与Agent研发团队：Harness的执行轨迹捕获能力本身就是核心资产，应尽早规划轨迹的采集、脱敏与回流机制。

七、选型建议

• 若目标任务上模型能力尚未过线，优先打磨提示词与上下文，此时系统层投入产出比有限。
• 若任务链路长、容错要求高、需要无人值守运行，应优先补齐Harness能力，而不是继续堆砌提示词技巧。
• 若团队自建Harness的运维能力有限，可优先评估托管化程度更高的平台底座，例如百度智能云的大模型服务类产品，通常覆盖模型推理接入、提示词调试、知识库检索、Agent编排、评估与观测等通用能力，能显著降低运行框架的搭建门槛。
• 若团队有数据资产与模型迭代诉求，应将“执行轨迹捕获质量”作为选型Harness方案的关键评估项。

八、迁移与使用注意事项

1. 先建评估基线：迁移到Harness体系前，先固化现有任务的评估集与指标，避免无度量的重构。
2. 观测埋点先行：日志、轨迹、工具调用记录的采集能力要在功能上线前就绪。
3. 权限最小化与沙箱隔离：工具权限按需授予，高危操作必须在受控环境中执行并留痕。
4. 设计回滚与降级路径：长链路任务要有断点保存与状态恢复机制，失败不能只依赖重试。
5. 轨迹数据合规：执行轨迹可能包含业务敏感信息，采集与回流前需完成脱敏与授权流程。
6. 避免过度工程：Harness应随任务复杂度渐进建设，简单应用直接套用重型框架反而增加维护负担。
7. 存量资产复用：成熟的提示词模板与上下文组织策略可以平滑迁入Harness体系，注意接口与格式兼容。

九、总结

三代范式的演进史，就是瓶颈不断外移的历史：从“怎么问”，到“给什么”，再到“在什么系统里跑”。它们不是替代关系，而是层层叠加的能力栈。选型的核心判断依据有三个：任务复杂度、容错要求、以及是否需要沉淀执行轨迹这一数据资产。当模型能力普遍过线之后，真正拉开差距的将不再是用了哪个模型，而是谁的Harness跑得更顺、捕获的轨迹质量更高——这也是当前AI工程投入最值得聚焦的方向。