AI工程范式演进，Harness Engineering如何成为？

前言 如果按月份来给AI领域划分关键词，那么2月份大概属于openclaw，而从3月开始，这个关键词则逐渐变成了Harness Engineering。 作为近两个月新兴的核心概念，围绕Harness Engineering的讨论迅速展开，相关文章也层出不穷。但其中相当一部分内容停留在概念层面的反复堆砌，读完之后，往往只剩下模糊的印象（甚至会觉得莫名其妙），而难以形成有效的认知。所以我打算聊一聊自己对这个概念的理解。 Harness Engineering的概念最早由Mitchell Hashimoto在2026年2月5日发表的文章《My AI Adoption Journey》中提及，随后 OpenAI 在2026年2月11日发表了 《工程技术：在智能体优先的世界中利用Codex》，正式采用了这个术语并给出了大规模实践案例，使这个词迅速在行业内传播开来。 演进历程 要理解 Harness Engineering，最好的方式是把它放到 AI 工程实践的演进脉络中去看。从 2022 年底 ChatGPT 引爆大模型浪潮至今，工程师们围绕“如何更好地使用大模型”这个核心命题，已经走过了三个清晰的阶段：Prompt Engineering → Context Engineering → Harness Engineering。 每一次范式的跃迁，都不是对前一阶段的否定，而是解决了前一阶段未能覆盖的问题。 Prompt Engineering：如何与大模型对话 时间线：2022 年底 ~ 2024 年初 这是一切的起点。当大模型刚刚进入开发者视野时，最直接的问题是：怎么让它按我的意思来？ 于是 Prompt Engineering（提示词工程）应运而生。它的核心在于精心设计输入给模型的文本指令，通过措辞、格式、示例的调整来引导模型产出期望的结果。 这个阶段的典型实践包括： 角色设定：「你是一个资深的 Java 架构师，请基于以下需求...」 少样本学习（Few-shot）：在 prompt 中嵌入几组输入-输出示例，让模型模仿格式和风格 思维链（Chain of Thought）：引导模型「一步步思考」，提升推理任务的准确率 输出格式约束：「请以 JSON 格式返回，包含以下字段...」 Prompt Engineering 的价值是真实的——在很多场景下，一个精心设计的 prompt 确实能显著提升模型输出质量。但它的局限也同样明显： Prompt 本质上是一次性的静态指令。当任务变得复杂、需要多步推理、需要引用外部知识时，仅靠 prompt 的措辞技巧已经不够用了。 你可以把一个 prompt 写到 2000 字，把所有的约束、示例、上下文都塞进去，但这就像试图在一封信里把所有事情交代清楚——信息越多，模型越容易迷失重点。 Context Engineering：信息编排的工程 时间线：2024 年初 ~ 2025 年底 随着 RAG（检索增强生成）、Function Calling、多轮对话记忆管理等技术的成熟，工程师们意识到：比起在 prompt 里堆砌文字，更重要的是在正确的时机，向模型提供正确的信息。 这就是 Context Engineering（上下文工程）的核心理念。它不再只关注“怎么写提示词”，而是把注意力转移到如何动态构建和管理模型的输入上下文。 Context Engineering 的典型实践包括： RAG：根据用户查询从知识库中检索相关文档片段，动态注入上下文 Tool / Function Calling：让模型在推理过程中主动调用外部工具获取实时信息 Memory：对多轮对话历史进行摘要、压缩、裁剪，确保有限的上下文窗口被高效利用 System Prompt 模板化：根据不同场景动态组装 system prompt，而非一成不变的静态文本 如果说 Prompt Engineering 是“教你怎么写一封好信”，那 Context Engineering 就是“设计一套信息投递系统，让合适的信息在合适的时候到达合适的位置”。 这个阶段的工程复杂度明显上升：开发者不再只是调 prompt，而是开始构建向量数据库、设计检索策略、工具管理、多步调用链路编排。围绕 LangChain、LlamaIndex 等框架的生态也在这个阶段快速发展。 但 Context Engineering 仍然有一个隐含的前提：人在回路中。大多数场景下，模型在人类的直接监督下运行——一次调用、一次审核、一次反馈。