从 Prompt Engineering 到 Harness Engineering：AI 时代的工程范式变迁

2020 年，GPT-3 发布，人们发现只要把提示词写对，模型就能完成各种任务。一个新职业诞生了：Prompt Engineer。

2025 年中，Shopify CEO Tobi Lutke 发了一条推文：

I really like the term 'context engineering' over prompt engineering. It describes the core skill better.

Andrej Karpathy 立刻跟进，Simon Willison 写博客声援。几周之内，Context Engineering 成了行业共识。

2026 年初，OpenAI 的 Codex 团队发布了一篇博客，描述他们如何用 3 个工程师、5 个月、0 行手写代码，构建了一个百万行级别的内部产品。他们给这种工作方式起了个名字：Harness Engineering。

三个术语，三次范式转变。每一次都在回答同一个问题：人类和 AI 之间的分工界面应该在哪里？

一、Prompt Engineering：对话的艺术（2020-2024）

Prompt Engineering 的核心假设很简单：你说得越准确，模型回答得越好。

GPT-3 刚出来的时候，大家发现一个现象 —— 同样的模型，不同的提示词，输出质量天差地别。于是一系列技巧被总结出来：

Few-shot prompting：给几个示例，模型就能模仿模式
Chain-of-Thought：让模型"一步一步想"，推理能力大幅提升
Role prompting：给模型一个角色设定，输出更符合预期
System prompt：定义全局行为约束

2023 年，"Prompt" 成为牛津词典年度词汇的候选。公司开始招聘专职的 Prompt Engineer，薪资甚至超过传统软件工程师。

但问题很快暴露了。

Prompt Engineering 的局限在于它只关注单次交互。 你在精心打磨一条提示词，但模型看到的上下文远不止这一条。在生产环境中，模型需要处理的是：历史对话、检索到的文档、可用的工具列表、结构化的输出格式、用户的偏好设置…… 这些东西拼在一起，才是模型真正"看到"的全部。

打个比方：Prompt Engineering 像是在给演员写台词，但舞台布景、灯光、道具、对手戏，全都不管。

到 2024 年底，越来越多的实践者意识到，"写好提示词"只是冰山一角。真正的挑战是设计模型看到的整个信息环境。

二、Context Engineering：系统级设计（2025）

2025 年 6 月 19 日，Tobi Lutke 在 X 上写道：

The art of providing all the context for the task to be plausibly solvable by the LLM.

六天后，Andrej Karpathy 补了一刀：

People associate prompts with short task descriptions you'd give an LLM in your day-to-day use. In every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window with just the right information for the next step.

这两条推文引爆了一场术语革命。不是因为技术有了突破，而是因为既有术语已经无法描述工程师实际在做的事情了。

Simon Willison 解释了为什么 Context Engineering 会取代 Prompt Engineering：

"Prompt engineering" acquired an unfortunate inferred definition — "typing things into a chatbot." Context engineering's inferred definition is much closer to the intended meaning.

Hugging Face 的 Philipp Schmid 给出了一个系统性的定义。Context Engineering 包含七个组成部分：

组件	说明
Instructions / System Prompt	全局行为指令
User Prompt	用户的具体请求
State / History	对话历史和状态
Long-Term Memory	跨会话的持久化记忆
Retrieved Information	RAG 检索的实时数据
Available Tools	模型可调用的工具
Structured Output	预定义的输出格式

关键区别在于：Prompt Engineering 是在写一个字符串，Context Engineering 是在设计一个系统。

Prompt Engineering 问的是："这句话怎么写？" Context Engineering 问的是："模型需要看到什么才能完成这个任务？"

这不是术语的升级，而是工作层次的转变。当你在设计一个 AI 应用时，你要考虑的不是单条提示词的措辞，而是：

什么信息应该放进上下文？什么时候放？
历史对话要保留多少？怎么压缩？
检索系统返回的文档如何排序和截断？
工具的描述怎么写，才能让模型正确调用？
输出格式怎么约束，才能被下游系统解析？

MIT Technology Review 在 2025 年 11 月的总结文章里写道：2025 年的软件开发，经历了"从 Vibe Coding 到 Context Engineering"的转变。Gartner 也把 Context Engineering 列为企业 AI 的关键概念。

但 Context Engineering 仍然有一个盲区：它只关注模型"看到什么"，不关注模型"被允许做什么"以及"做错了怎么办"。

三、Harness Engineering：全环境设计（2026）

2026 年 3 月，OpenAI 发布了一篇名为 "Harness engineering: leveraging Codex in an agent-first world" 的博客。

文章描述了一个实验：

从一个空仓库开始
3 个工程师（后来扩展到 7 个）
5 个月，约 1,500 个 PR
0 行手写代码
产出约 100 万行代码，包括应用逻辑、测试、CI 配置、文档、可观测性、内部工具

所有代码全部由 Codex Agent 生成。人类的工作从"写代码"变成了"设计让 Agent 能干活的环境"。

Harness 这个词的原义是"挽具"—— 套在马身上让马拉车的装置。Harness Engineering 的意思是：搭建环境、工具和约束，让 AI Agent 在其中可靠地工作。

Context Engineering 是组件，Harness Engineering 是系统

Martin Fowler 网站上的分析文章把 Harness Engineering 分解为三个支柱：

1. Context Engineering —— 知识库管理

OpenAI 团队学到的第一课：给 Agent 一张地图，而不是一本说明书。

他们最初把所有规则塞进一个巨大的 AGENTS.md，结果 Agent 反而更容易搞混。后来改成了：

AGENTS.md 只有约 100 行，充当"目录"
具体知识放在结构化的 docs/ 目录中
设计文档、架构决策、执行计划、技术债务 —— 全部版本化，放在 repo 里
渐进式信息披露（Progressive Disclosure）：Agent 先看入口，需要时再深入

从 Agent 的角度，任何它在运行时无法访问的东西，等于不存在。Google Docs 里的讨论、Slack 里的决策、人脑里的知识 —— 对 Agent 来说都不存在。

2. 架构约束 —— 防护栏

Types → Config → Repo → Service → Runtime → UI

每个业务领域按固定分层划分，依赖只能单向向前。跨领域依赖必须通过统一的 Providers 接口。违反规则？CI 直接拦住。

这是文章最反直觉的点：严格的架构治理通常是几百人团队才需要的事，但在 Agent-first 模式下，这是早期就必须做的事。

他们用 Codex 自己写了一套自定义 Linter，不只是检查规则，还在错误信息里嵌入修复指南。Agent 犯错时，自动获得"怎么改"的上下文。

原则是：守住边界，不要微管理实现。

比如，他们要求 Agent 在数据边界处做类型校验（Parse, don't validate），但不限定必须用哪个库 —— Agent 喜欢用 Zod，那就用 Zod。

3. 垃圾回收 —— 持续清理

Our team used to spend every Friday (20% of the week) cleaning up "AI slop."

每周五花一整天手动清理 AI 生成的低质量代码 —— 这显然不可持续。

后来他们把"品味"编码成规则（Golden Principles），让后台 Codex 任务定期扫描、开 refactoring PR、自动合并。就像垃圾回收机制 —— 技术债是高利贷，小额持续还款，别攒着一次性还。

三者的关系

把这三个概念放在一起，可以理解为同心圆：

┌─────────────────────────────────────┐
│         Harness Engineering         │
│  ┌───────────────────────────────┐  │
│  │     Context Engineering       │  │
│  │  ┌─────────────────────────┐  │  │
│  │  │   Prompt Engineering    │  │  │
│  │  │                         │  │  │
│  │  │  你说什么给模型听？      │  │  │
│  │  └─────────────────────────┘  │  │
│  │                               │  │
│  │  模型需要看到什么？            │  │
│  └───────────────────────────────┘  │
│                                     │
│  整个系统如何运转？                  │
│  架构约束 · CI 门禁 · 反馈循环      │
│  可观测性 · 垃圾回收 · 自动修复     │
└─────────────────────────────────────┘

或者用一个比喻：

Prompt Engineering：给马下指令
Context Engineering：给马选好路线、带够地图和干粮
Harness Engineering：设计整套挽具、护栏和检查站，让马在正确的道路上跑

有人总结得更简洁：模型是 CPU，Harness 是操作系统。

四、一条清晰的演进脉络

维度	Prompt Engineering	Context Engineering	Harness Engineering
时间	2020-2024	2025	2026
核心问题	怎么写提示词？	模型需要看到什么？	整个系统怎么运转？
操作对象	单条文本	信息架构	完整工作环境
关注层次	输入-输出	上下文窗口	端到端工作流
代表人物	OpenAI 社区	Tobi Lutke, Karpathy	OpenAI Codex 团队
类比	写台词	搭舞台	建剧场

这条脉络背后有一个一致的方向：人类的工作越来越远离"直接操作"，越来越接近"设计环境"。

从亲手写每一行代码，到精心编写提示词，到设计信息架构，到搭建完整的 Agent 工作环境 —— 抽象层级在不断上移。

五、这意味着什么？

好的工程实践变得更重要了

这是最反直觉的结论。你可能以为 AI 写代码了，工程纪律就不重要了。恰恰相反。

OpenAI 团队的经验表明：架构分层、结构化文档、自动化测试、CI 门禁 —— 这些"传统"的工程实践在 Agent-first 模式下不是过时了，而是变成了生产力的放大器。没有这些基础设施，Agent 的产出质量会迅速退化。

瓶颈从"写代码"转向"设计环境"

当代码不再是人写的，工程师的核心工作变成了：

文档和知识库的设计
架构约束和防护栏的制定
反馈循环和可观测性的建设
质量标准的编码和自动化执行

这些听起来像是"管理工作"，但实际上是更高层次的工程工作。

不是每个人都需要 Harness Engineering

如果你在用 ChatGPT 帮你写邮件，Prompt Engineering 就够了。如果你在构建一个 RAG 应用，Context Engineering 是你的主战场。Harness Engineering 目前主要适用于让 AI Agent 端到端负责代码生成和维护的场景。

但方向是明确的。随着 Agent 能力的增强，"设计 Agent 工作环境"的重要性只会越来越高。

中间插曲：Vibe Coding

值得一提的是，2025 年 2 月 Andrej Karpathy 还造了另一个词：Vibe Coding（氛围编程）。

There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.

Vibe Coding 后来成了 Collins 词典的 2025 年度词汇。它代表的是这条演进线的另一端 —— 完全放弃对代码的控制，"感觉对了就行"。适合周末项目，不适合生产环境。

把它放进完整的谱系里：

Vibe Coding → Prompt Engineering → Context Engineering → Harness Engineering
─────────────────────────────────────────────────────────────────────────────→
随意                                                                  严谨

六、写在最后

从 Prompt Engineering 到 Harness Engineering，不到六年时间。这个速度本身就说明了一个问题：我们还远没到稳定状态。

OpenAI 团队自己也承认：

What we don't yet know is how architectural coherence evolves over years in a fully agent-generated system.

全 Agent 生成代码的长期可维护性，仍然是一个开放问题。

但有一件事已经很清楚：软件工程的重心正在从"写代码"转向"设计让 AI 写好代码的环境"。无论你现在处于哪个阶段 —— 还在打磨 Prompt，还是在构建 Context Pipeline，还是在设计完整的 Agent Harness —— 理解这条演进脉络，能帮你更清楚地看到自己的位置和下一步的方向。

相关链接：