回顾过去两年，AI 应用开发经历了三次明显的范式跃迁：
| 时间 | 核心关注 | 代表技术 |
|---|---|---|
| 2024 | Prompt Engineering | 提示词模板、Few-shot |
| 2025 | Context Engineering | RAG、向量数据库、动态检索 |
| 2026 | Harness Engineering | Agent、编排层、沙箱、自我纠错 |
Prompt Engineering、Context Engineering、Harness Engineering，本质上是同一件事在不同复杂度下的三种形态，这三者不是替代关系，而是层层嵌套的演进关系。
Prompt Engineering
当 GPT-3.5 和 GPT-4 刚刚向公众开放时，所有人都面临同一个困惑：
模型明明很聪明，但为什么我问不出来想要的东西？
这就是 Prompt Engineering 诞生的背景。它要解决的核心问题是：如何让模型"听懂"我的需求？
它包含哪些内容：
Prompt Engineering 的产物，是一个个精心设计的文本模板。你可能听过各种提示词框架、比如ICIO、CRISPE、BROKE, 这些提示词框架的核心思路，本质上都是把"模糊的人类语言"翻译成"模型能精确理解的结构化指令"。所以，如果你刚开始接触，可以先背一个框架（比如ICIO），练熟后再忘掉框架，回归提示词的本质：
- 具体指导：明确告诉模型具体任务和关键约束，而不是笼统地说"写一段话"
- 简洁明了：用短句、列表或分段拆分指令，避免长句嵌套和模糊词。
- 适当引导：通过角色设定、Few-shot示例或输出结构来让模型自动对齐你的期望。
- 迭代优化：如果模型答错了，就根据错误反向补充约束或示例，迭代三四次往往就能得到可用的提示词
局限性
然而，Prompt Engineering 有一个根本性的局限：
无法引入模型训练数据之外的实时/私有知识，也无法执行任何外部动作。
- 你问"信用卡中心去年发了多少卡"，模型不知道。
- 当任务变得复杂，比如如百万行代码生成，单一Prompt就会出现"失忆""跑偏"的问题。
这些问题，不是"把 Prompt 写得更好"能解决的。于是，Context Engineering 出现了。
Context Engineering
Context Engineering要解决的核心问题是：
如何让LLM在正确的时间获得'恰到好处'的知识，以帮助 AI 代理有效执行任务。
它包含哪些核心能力
Context Engineering并非单一的指令优化，而是系统性地编排上下文窗口中的内容，包括但不限于以下几个方面：
- 调整指令和系统提示
- 管理提示中的动态元素（如用户输入、日期时间等）
- 搜索和准备相关知识（即 RAG 检索增强生成）
- 工具定义与调用
- 准备和优化少样本示例
- 结构化输入和输出
- 短期记忆管理
- 长期记忆检索
比如：
- RAG 检索增强生成
用户问"我们公司去年信用卡发了多少张？"
先检索公司数据库，把相关财报段落、KPI 摘要自动塞进上下文，再让模型回答。
本质：动态补全模型不知道的事实。 - 工具调用（Function Calling）
用户问"现在北京天气怎么样？"
在系统提示中声明工具（get_weather），让模型输出结构化参数，外部执行后将结果再次放入上下文。
本质：用外部工具扩展模型的能力边界。 - 长对话记忆压缩
对话进行到第20轮，上下文窗口快满了。
不是简单截断，而是让模型总结前 10 轮的关键信息（用户偏好、已解决事项），替换原始对话。
本质：在有限窗口内保留高密度信息。 - 动态少样本示例选择
用户上传一个 PDF 合同，问"这里面的管辖条款是否合规？"
先对合同做语义分类（劳务/采购），再从示例库中检索最相似的 2--3 个合规判断案例，动态插入上下文。
本质：让示例与当前任务更相关，而非固定写死。 - 长期记忆：存储用户偏好
用户在一个 AI 编程助手产品中说：
- "我习惯用 TypeScript 而不是 JavaScript。"
- "代码注释要中文。"
- "函数命名用驼峰法。"
Context Engineering 的做法： - 每次对话结束后，系统可以尝试把用户偏好抽取成键值对存入数据库
- 新对话开始时，检索该用户的长期偏好，自动注入系统提示
- 用户无需重复说明，模型自动对齐习惯
本质：跨会话记住用户偏好，实现个性化体验。
局限性
Context Engineering 已经能处理相当复杂的任务，但它仍然有一个隐形的天花板：它默认模型是"被调用的执行者"，而不是"自主规划的主体"。
当任务链条足够长（比如"帮我调研竞品、写报告、做成 PPT 发给团队"），涉及多个子系统协作、外部环境交互、异常恢复、自我校验时，单纯靠"编排上下文"已经力不从心。于是，Harness Engineering 登场了。
Harness Engineering
2026年2月5日，HashiCorp联合创始人、Terraform之父Mitchell Hashimoto在技术博客中首次正式命名 Harness Engineering，核心理念为「每当Agent犯错，就工程化一套解决方案，让它永远不再犯同样的错误」，核心是通过系统设计而非提示词调优解决模型的不确定性。
前两代范式有一个共同的前提：假设模型本身是可靠的，只要给它正确的指令和足够的知识，它就能把事情做好。但现实是，模型具有内在的不确定性------它会编造事实、逻辑跳步、反复犯同类错误；它的上下文窗口有限，无法支撑跨越多天的长任务；它调用工具时可能越权操作；它的执行过程是个黑盒，无法审计也无法追溯错误根源。
Harness Engineering 的核心命题就是：如何将不可控、不确定的大模型，转化为可工业化部署、可稳定执行、可监控运维的生产力工具。如果说 Prompt Engineering 是在"教模型听懂指令"，Context Engineering 是在"给模型补充知识和工具"，那么 Harness Engineering 就是在为模型构建一套完整的"运行操作系统"
它包含哪些核心能力
一个成熟的 Harness 系统，通常包含以下几个关键模块：
执行闭环：标准化实现 Plan-Act-Observe-Reflect（规划-执行-观察-反思） 闭环，杜绝跳步和幻觉。支持复杂任务自动拆解为可验证的原子步骤，支持任务断点续跑（即使模型重启也能继续），并通过"完成度校验"机制防止模型提前终止任务。
分层记忆：构建工作记忆（当前步骤）、会话记忆（单次任务全流程）、长期记忆（跨任务的规则和经验）三层体系。通过自动压缩、裁剪和检索，把有限的上下文窗口留给核心推理任务。
工具管控：统一工具的封装规范，同时严格划定操作边界------工具白名单、网络访问白名单、资源配额（CPU/内存/Token 上限），所有操作全流程留痕可审计。
安全护栏：在输入前、输出生成后、工具执行前设置多层校验关卡。格式不对？拦截。事实不一致？拦截。试图删除生产数据？拦截。有实践表明，这类机制能让模型错误率降低 90% 以上。
环境隔离：每个 Agent 任务在独立的沙箱中执行------临时文件系统、容器或虚拟机，互不干扰。即便某个 Agent 执行出错，也不会污染生产系统。
自愈闭环：这是 Harness 区别于前两代范式的关键。当系统捕获到错误后，会自动将错误信息和修正要求反馈给 Agent，引导其自主修正；对于高频重复错误，系统会自动生成新的校验规则并沉淀下来。每一次错误都转化为系统的健壮性提升。
可观测性：Agent 的每一步决策、每一次工具调用、每一笔 Token 消耗，都可追踪、可回放、可告警，不再是黑盒。
影响
在工程层面，Harness Engineering 的出现意味着 AI 应用开发的重心发生了转移：从"调教模型"转向"设计系统"。工程师不再需要花大量时间微调提示词，而是构建可复用的规则、校验和闭环体系。
在组织层面，一个新的岗位正在快速成型------Harness Engineer。这个岗位要求的不只是会写提示词或调 RAG，而是具备系统设计能力：能够把业务规则转化为可执行的约束，能够构建 Agent 的全链路管控体系，能够设计错误自愈机制。
在行业层面，已经出现了一批生产级落地案例。最著名的例子是：OpenAI发布重磅报告《Harness engineering: leveraging Codex in an agent-first world》，一个 3 人工程师团队，在 Harness 系统的支撑下，5 个月内没有手写一行代码，仅通过Codex Agent 完成了 100 万行代码的产品开发、1500+PR合并，交付了可服务数百真实用户的内测产品，效率达到手动开发的10倍。
挑战
Harness Engineering 还处于快速发展期，目前面临几个主要挑战：
- 不同厂商的架构和接口规范尚未统一，跨平台迁移成本较高；
- 当前能力主要聚焦文本场景，针对图像、视频等多模态 Agent 的管控体系还有缺口；
- 大规模多 Agent 协同场景下，任务死锁、记忆污染、成本失控等问题还需要更成熟的解决方案。