AI工程范式演进：从Prompt Engineering到Context Engineering到Harness Engineering

当模型越来越聪明，驾驭它的艺术也在悄然升级。这不只是技术潮流的更迭，更是人类与AI协作方式的一次次深层重构。

引言：一场被低估的范式革命

2020年，当OpenAI发布GPT-3时，最令研究者震惊的，不是模型的规模，而是一个意外的发现：你不需要重新训练模型，只需要换一种问法，就能得到截然不同的结果。

这个发现，催生了一个全新的职业——Prompt Engineer，以及一个全新的工程领域——Prompt Engineering（提示词工程）。

五年之后，这个领域已经经历了两次重大范式迁移。今天我们聊的，不是某个具体的AI工具或产品，而是AI工程师们驾驭语言模型的方式本身，是如何在短短五年内完成三次根本性升级的。

理解这三次迁移，就是理解AI应用开发的过去、现在和未来。

第一章：Prompt Engineering——语言即接口的黄金时代

1.1 横空出世：一个意外发现改变了一切

2020年之前，要让AI完成特定任务，标准路径是：收集标注数据、微调模型、部署推理服务。整个流程动辄数月，成本高昂，且每换一个任务就得重来一遍。

GPT-3的出现打破了这一切。Brown等人在论文中展示了一个令人瞠目的能力：只要在输入文本中给出几个示例，模型便能在没有任何参数更新的情况下完成新任务。他们把这种能力称为"In-context Learning"（上下文学习）。

这意味着，模型本身就是一个通用函数，而自然语言就是调用这个函数的接口。

Prompt Engineering这个词随之诞生。它的核心主张很简单：你不需要懂神经网络，不需要写代码，只需要学会"怎么问"。

1.2 核心技术：从措辞到思维链

Prompt Engineering发展迅速，几年内形成了一套系统性的技术体系：

Zero-shot Prompting（零样本提示） 最基础的形式。直接给出任务描述，不提供示例。例如：

将以下英文翻译成中文，保持正式语气：
"The quarterly results exceeded expectations."

Few-shot Prompting（少样本提示） 在prompt中嵌入若干输入-输出对作为示例，让模型"模仿"。这是早期最有效的技术之一，能显著提升模型在特定任务上的表现。

Chain-of-Thought（思维链） 2022年，Google Brain的研究者Wei等人发现了一个重要技巧：在prompt中要求模型"一步一步地思考"，可以大幅提升复杂推理任务的准确率。这个发现意义深远——它揭示了中间推理步骤对最终答案质量的关键作用。

Q: 小明有5个苹果，送给小红3个，又买了7个，还剩多少？
A: 让我一步步计算：
   1. 初始：5个苹果
   2. 送出：5 - 3 = 2个
   3. 购入：2 + 7 = 9个
   所以还剩9个苹果。

角色设定（Role Prompting） 通过赋予模型特定身份，激活其对应的"行为模式"：你是一位经验丰富的外科医生，请从临床角度分析……

自洽性（Self-Consistency） 对同一个问题生成多个不同推理路径，然后投票选择最一致的答案，以提高推理稳定性。

1.3 工程实践：一门关于"措辞"的学问

这个阶段的工程实践，本质上是语言直觉与模型行为的反复校准。优秀的Prompt Engineer需要建立一套关于"这个模型对哪类语言更敏感"的直觉模型。

一些被反复验证的经验法则在社区中流传：

• 用正面指令而非否定指令（“请简洁回答"优于"不要冗长”）
• 在prompt末尾重申关键约束，模型更可能遵守
• 对于结构化输出，在prompt中先给出格式模板
• “Let’s think step by step” 这七个词，在特定任务上能将准确率提升近40%

这一时期涌现了大量"Prompt技巧"的分享内容，PromptBase等平台甚至出现了Prompt的交易市场——人们买卖精心设计的prompt，就像买卖模板和脚本。

1.4 内在局限：聪明的问法，填不上信息的真空

然而，Prompt Engineering有一个根本性的天花板，无论措辞多么精妙，都无法突破：

模型只知道它被训练时学到的东西。

你可以告诉它"你是一位了解我公司内部数据的分析师"，但它不知道你公司的真实数据。你可以让它扮演"实时新闻播报员"，但它的知识截止于训练日期。你可以要求它"根据用户历史行为个性化推荐"，但它不知道这个用户是谁。

更深层的问题是：Prompt是无状态的。 每次对话都是全新的开始，模型不记得昨天和你说了什么，不记得上个任务的中间结果，不记得你的偏好和上下文。

这个局限，在模型能力还比较弱的时候并不突出——因为任务本身就比较简单。但随着模型能力的提升，人们开始想用它完成更复杂的任务，这道墙就变得越来越清晰。

第二章：Context Engineering——信息环境塑造的新范式

2.1 顿悟时刻：问题不在于怎么问，而在于给什么信息

2023年前后，AI工程领域发生了一次集体性的认知升级。

随着GPT-4的发布、Claude的问世、以及Llama系列开源模型的涌现，一个共识逐渐形成：现代大语言模型已经足够聪明，大多数情况下它们知道怎么完成任务。真正的瓶颈，是它们拿到的信息太少、太孤立。

Andrej Karpathy（特斯拉前AI总监，OpenAI联合创始人之一）在2025年的一次访谈中，将这个转变说得很直白：

“The hottest new programming language is English… but really context is everything. The model is only as good as what you put in the context window.”

上下文窗口——这个模型在单次推理中能"看到"的全部信息——成为了新的核心战场。

与此同时，几项关键技术的成熟为这个范式奠定了基础：

• 长上下文窗口：从早期的4K token扩展到32K、128K，再到如今Claude的200K、Gemini的百万级token
• RAG（检索增强生成）：系统化的外部知识注入方案
• Function Calling / Tool Use：让模型能够主动调用外部工具获取实时信息
• 结构化输出：模型可以稳定地输出JSON、XML等格式，便于程序处理

2.2 什么是上下文工程

如果说Prompt Engineering是"怎么问问题"，那么Context Engineering是"如何为模型构建一个完整的信息环境"。

一次典型的现代LLM调用，其上下文窗口中可能包含：

[System Prompt]      ← 角色定义、行为规范、输出格式要求
[Retrieved Docs]     ← 从知识库检索出的相关文档（RAG）
[Tool Definitions]   ← 可用工具的描述和参数规范
[Memory Summary]     ← 历史对话的压缩摘要
[Conversation History] ← 最近几轮对话原文
[Current User Query] ← 用户当前的输入
[Tool Results]       ← 工具调用返回的数据

管理这七类信息的选择、排布、格式化、压缩和更新，就是Context Engineering的核心工作。

2.3 核心技术详解

RAG（检索增强生成）

RAG是Context Engineering最重要的技术之一，解决的是"模型知识的时效性和私域化"问题。

基本流程：

1. 将私域文档（公司知识库、产品手册、历史数据等）切分成小块，通过Embedding模型转化为向量
2. 存入向量数据库（如Pinecone、Weaviate、pgvector）
3. 用户提问时，先将问题向量化，检索出最相关的文档块
4. 将检索结果注入上下文，再让模型回答

RAG的难点并不在于基本流程，而在于工程细节：如何切分文档（chunk size的选择）、如何处理跨页面的语义单元、如何融合关键词检索和语义检索（混合检索）、如何处理检索召回的噪声文档……这些细节决定了RAG系统的实际效果。

Memory管理

模型本身无记忆，但应用系统可以维护记忆。主流方案形成了四个层次：

实践中的关键问题是：何时更新、更新什么、如何压缩。对话历史的直接堆叠会很快耗尽上下文窗口，而机械截断又会丢失重要上下文。这催生了"对话摘要"、“滑动窗口”、“重要性加权保留"等多种策略。

Tool Calling（工具调用）

OpenAI在2023年将Function Calling正式标准化，这是Context Engineering的另一个里程碑。

模型不再是被动接受信息的"答题机器”，而是可以主动发出调用请求——搜索网页、查询数据库、执行代码、调用API——并将结果纳入推理过程。这让模型从"知识库"变成了"行动者"。

典型的Tool Calling循环：

用户提问 → 模型决定调用weather_api工具 → 系统执行调用 → 
将结果注入上下文 → 模型基于实时天气数据给出回答

上下文压缩与优先级排序

当可用信息超过上下文窗口时，必须做出取舍。“Lost in the Middle"现象（模型对上下文中间位置的信息关注度显著低于开头和结尾）的发现，进一步要求工程师精心设计信息的排布位置。

高质量的Context Engineering需要回答：

• 哪些信息是"必须有"的？哪些是"有更好"的？
• 信息应该按什么顺序排列？
• 如何在信息量和token成本之间平衡？

2.4 工程实践：Context是产品的核心资产

这一阶段，工程实践的重心从"写好prompt"转移到了构建数据管道。

以一个企业知识问答助手为例，其工程复杂度在Context Engineering时代大幅提升：

• 数据摄取层：PDF解析、表格提取、图像OCR、多格式文档处理
• 索引层：文本切分策略、Embedding模型选择、向量索引构建、增量更新机制
• 检索层：查询改写、混合检索、重排序（Reranking）、多路召回融合
• 注入层：上下文格式化、长度控制、引用追踪
• 评估层：检索准确率、答案忠实度、幻觉检测

一套成熟的RAG系统，工程量远超普通人的想象。它不只是"把文档存进去，然后搜出来”，而是一套精密的信息流水线。

主流框架如LangChain、LlamaIndex在这一阶段爆炸式增长，本质上是Context Engineering工具的集大成者。

2.5 内在局限：单智能体的天花板

Context Engineering极大地扩展了LLM应用的能力边界。但随着任务复杂度的进一步提升，新的问题出现了。

想象一个任务：为我们公司的新产品撰写一份完整的市场进入策略报告，包含竞品分析、目标用户研究、定价策略和渠道规划。

这个任务需要：搜索竞品信息、分析行业报告、查阅内部销售数据、进行多轮推理……对于单个LLM调用而言，上下文窗口即便再大，也难以在一次推理中完成所有子任务；而串行处理又太慢，且中间结果难以管理。

更根本的问题在于：当系统开始"自主行动"，而不只是"回答问题"时，如何确保它的行为是可预期的、可控的、可审计的？

一个能够自主调用工具、访问数据、执行操作的AI系统，出了错怎么办？谁来监督它？如何回滚？

这些问题，Context Engineering没有答案。

第三章：Harness Engineering——系统驾驭的前沿范式

3.1 范式转变的触发点

“Harness"这个词来自马具——驾驭马匹的缰绳和挽具系统。选择这个词意味深长：我们面对的，是一匹越来越强壮、越来越有自主行动能力的马，而我们的任务，是让它可靠地为我们所用。

触发这次范式转变的，是几个同时发生的技术突破：

Agent能力的质变：Claude 3.7的"Extended Thinking”（扩展思考）、o3的长链推理、Gemini 2.0的多模态Agent能力——现代模型已经可以在内部进行大量推理，自主规划子任务，持续执行数分钟到数小时的复杂任务。

多Agent框架的成熟：LangGraph、AutoGen、CrewAI、Anthropic的Claude Agent SDK等框架让多个AI智能体的协作编排变得可行——一个Orchestrator Agent分配任务，多个Specialist Agent并行执行，Critic Agent负责质量审核。

“Vibe Coding"的兴起：以Cursor、Windsurf为代表的AI编程工具，以及GitHub Copilot Workspace，让AI开始真正参与到生产级代码的自主编写中。这些系统中，模型不只是"提供建议”，而是在执行一个跨越多个文件、多个步骤、需要调试和迭代的复杂任务。

Claude Code的出现（2025年初）：Anthropic发布的命令行AI编程工具，能够在本地环境中自主读取文件、运行代码、执行git操作，代表了从"对话型AI"到"执行型AI"的重要跨越。

3.2 什么是Harness Engineering

Harness Engineering的核心问题，已经不再是"如何让模型更好地理解我的需求"，而是：

如何构建一个由多个AI智能体组成的可靠系统，使其能够自主完成复杂的长程任务，同时保持可预期、可控、可审计的行为？

这个定义中包含几个关键词：

• 多智能体（Multi-Agent）：不是单一模型，而是多个具有不同角色、不同工具访问权限的AI协同工作
• 自主（Autonomous）：无需人类在每一步介入，系统自主规划和执行
• 长程（Long-horizon）：任务时间跨度长，可能包含数十乃至数百个步骤
• 可靠（Reliable）：系统行为稳定，错误可被发现和处理，结果可被验证

Harness Engineering的工程重心，从"怎么填充上下文"转向了"怎么设计系统行为边界"。

3.3 核心技术与架构

Orchestration（编排）

多Agent系统的核心是编排层——决定谁做什么、按什么顺序做、如何传递中间结果。

主要模式：

Router模式：由一个Orchestrator Agent分析用户请求，将其路由给最合适的专家Agent处理。

用户请求 → Orchestrator分析 → 路由至 [CodeAgent / DataAgent / WritingAgent] → 结果汇总

Pipeline模式：任务按固定顺序流经多个Agent，每个Agent处理特定阶段。适合流程固定、步骤清晰的任务。

Swarm模式：多个Agent平行工作，通过共享状态协调。适合可以并行分解的大规模任务。

Critic-Actor模式：一个Agent执行任务（Actor），另一个Agent审查结果（Critic），循环迭代直到质量达标。

Guardrails（护栏）

当AI开始自主执行操作时，护栏系统变得至关重要。它是防止系统"偏轨"的安全机制。

护栏通常分为两层：

• 输入护栏：检测恶意prompt注入、越权请求、违反政策的输入，在任务开始前拦截
• 输出护栏：检测幻觉（Hallucination）、有害内容、与业务约束冲突的输出，在结果输出前过滤

技术实现从简单的规则匹配，到专门的分类模型（如Llama Guard、Aegis），再到调用另一个LLM进行语义审查（“LLM-as-Judge”）。

Evaluation Pipeline（评估管道）

这是Harness Engineering中最被低估、也最重要的组件之一。

当系统变得复杂、任务变得长程，人工评估成本高到无法持续。自动化评估管道（Evals）成为系统稳定运行的基础设施：

• 基准测试套件：覆盖各类典型任务的测试用例集，每次模型版本更新后自动回归测试
• LLM-as-Judge：用一个强大的模型来评估另一个模型的输出质量，实现可扩展的语义评估
• Golden Dataset维护：持续维护一个"黄金数据集"，标注了期望的输入输出对，作为评估基准
• Failure Analysis：对系统失败案例进行系统性分析，识别失败模式，驱动改进

“Evals are the new unit tests”——评估管道是AI系统的单元测试，这一比喻在业界已被广泛接受。

Observability（可观测性）

在传统软件工程中，可观测性意味着日志、指标、链路追踪。在多Agent系统中，这些需求变得更加复杂：

• 步骤追踪：记录每个Agent的每次工具调用、每次推理的完整链路
• Token用量统计：各Agent的Token消耗，用于成本控制和性能优化
• 延迟监控：识别系统瓶颈，优化关键路径
• 语义Diff：当系统输出与预期不符时，能够追溯到具体的哪个步骤、哪个Agent出了问题

LangSmith、Langfuse、Weights & Biases等工具在这一领域迅速崛起，成为AI系统可观测性的重要基础设施。

Failure Recovery（故障恢复）

长程自主任务中，步骤越多，出错概率越高。系统必须设计健壮的故障恢复机制：

• Checkpoint机制：将任务执行状态定期持久化，出错时从最近的检查点恢复，而不是从头开始
• 重试策略：对瞬时错误（网络超时、API限流）自动重试，并设定退避策略
• 降级处理：当某个子任务失败时，能够使用备选方案（如用较弱的模型、较简单的工具）完成该步骤
• 人工介入触发：对于超出系统处理能力的错误，能够暂停任务并通知人类介入

3.4 工程实践：从工具使用到系统设计

Harness Engineering阶段的工程师，身份已经从"写好prompt的人"、“构建数据管道的人”，演变成了AI系统架构师。

以2025年真实的生产实践为例：

代码生成系统：一个典型的企业级AI编程助手，可能包含：需求理解Agent（解析用户需求）、架构规划Agent（设计模块结构）、多个代码生成Agent（并行实现各模块）、代码审查Agent（检查安全漏洞和代码风格）、测试生成Agent（自动生成测试用例）、集成测试Agent（运行测试并处理报错）。整个系统可以在30分钟内自主完成一个中等复杂度的功能开发。

研究报告系统：Orchestrator接收研究题目，分解为数个子议题；Search Agent并行检索学术数据库和公开信息；Analysis Agent分析各份资料；Synthesis Agent整合多方观点、处理矛盾；Writing Agent起草报告各章节；Editor Agent负责整合、润色和格式化。全程无需人工介入。

这类系统的设计决策，已经完全超出了"prompt怎么写"的范畴，进入了分布式系统设计、错误处理、状态管理等经典软件工程问题的领地。

3.5 当前最大挑战：可靠性与对齐

Harness Engineering尚处于快速演进阶段，面临的挑战真实而棘手：

错误的积累与放大：多步骤任务中，早期的小错误可能被后续步骤放大，最终导致灾难性的输出。如何检测和纠正中间步骤的偏差，是尚未完全解决的难题。

长程任务的对齐：短对话中，模型偏离用户意图时用户可以立即纠正。但在长达数小时的自主任务中，当模型悄悄地"理解错了需求"，发现问题时可能已经在错误方向上走了很远。

“Computer Use"的安全边界：当AI系统开始真正操作计算机——操作文件、执行命令、访问网络——如何确保它不会执行有害操作，是一个兼具技术和伦理维度的挑战。

成本控制：多Agent系统的Token消耗可能是单次调用的数十倍。如何在能力和成本之间找到平衡，是商业化落地的核心约束。

第四章：演进的深层逻辑

回顾三个范式，有一条贯穿始终的逻辑线：

4.1 控制层次的上移

每次范式迁移，都是因为模型能力提升，使得上一层的瓶颈得以突破，同时暴露出下一层的新瓶颈。这是技术系统演进的普遍规律——每解决一个层次的问题，就会遇到上一个层次更深处的挑战。

4.2 包含而非取代

重要的是，这三个范式并非相互取代，而是层层包含：

• 在Harness Engineering系统中，每个Agent的每次调用，仍然需要精心设计的Prompt
• 每个Agent的上下文，仍然需要Context Engineering的精细管理
• 系统层面的编排、护栏、评估，是新增的工程维度

这与软件工程的演进完全一致：我们有了操作系统，并不意味着不再需要算法；我们有了云原生，并不意味着不再需要操作系统。抽象层次上移，但下层的工作依然存在并且重要。

4.3 工程价值的迁移

随着范式的演进，工程价值的来源也在迁移：

• Prompt Engineering时代：核心价值在于"解锁模型能力”——找到那些让模型表现突出的特殊措辞。这是一种接近"玄学"的技艺，个人经验极其重要，但可复制性差。
• Context Engineering时代：核心价值在于"构建数据基础设施"——高质量的知识库、高效的检索管道、精准的信息管理。这更接近传统的数据工程，有明确的工程标准和最佳实践。
• Harness Engineering时代：核心价值在于"系统架构设计"——如何分解任务、如何保证可靠性、如何设计安全边界、如何评估系统质量。这需要软件架构师级别的系统思维。

第五章：未来可能的发展路径

5.1 近期趋势：可靠性工程的成熟

未来1-2年内，最确定的趋势是AI可靠性工程的系统化成熟。

随着Agent系统进入生产环境，评估框架、可观测性工具、Guardrails系统将形成标准化的最佳实践。就像云计算时代催生了DevOps文化和SRE角色，AI系统时代将催生"AI可靠性工程师"这个新职业——他们的核心工作是确保AI系统在生产环境中的稳定运行和持续改进。

5.2 中期展望：认知架构的探索

更长远地看，当前的Transformer + Tool Use架构可能并非终点。研究者们正在探索：

记忆架构的革新：当前LLM本质上是无状态的推理引擎，外部记忆是一种"假肢"。未来可能出现原生具备长期记忆能力的模型架构，使得Context Engineering中的Memory管理问题在模型层面得到解决。

规划能力的内化：当前多Agent系统的"规划"主要由Orchestrator模型通过提示和工具实现。随着o3、Claude的扩展思考等技术的成熟，规划能力将越来越多地内化到模型自身，减少对外部编排框架的依赖。

持续学习与个性化：当前模型的训练和推理是严格分离的。未来可能出现在推理阶段能够持续学习和适应的模型，使得Memory管理从"工程问题"变成"模型能力"。

5.3 长期猜想：从工具到协作者

如果说Prompt Engineering时代，人类是主人，AI是工具；Context Engineering时代，人类是导演，AI是演员；那么Harness Engineering时代，人类正在成为系统的设计者和监督者，AI成为了系统的执行主体。

这个趋势的终点在哪里，是当前最富争议的问题之一。

一种可能的图景是：AI系统将形成一种新的"认知分工"——人类负责设定目标、价值判断和最终决策，AI负责信息处理、方案生成和任务执行。Harness Engineering的核心，将从"如何控制AI行为"演变为"如何设计人机协作的工作流"。

另一种可能是：随着AI系统可靠性的提升，Harness工程本身也将被AI系统承担——AI设计和管理AI，而人类的角色进一步上移，专注于更高层次的目标设定和伦理监督。这不是科幻，某种程度上，自动化的Evals和自主优化的Prompt已经是这个方向的早期尝试。

5.4 一个不变的核心：理解问题本身

无论范式如何演进，有一个能力始终无法被自动化工具替代：

深刻理解你试图解决的问题。

最好的Prompt，来自对任务本质的深刻理解。最好的Context设计，来自对信息流的深刻理解。最好的Harness架构，来自对系统失败模式的深刻理解。

工具在变，范式在变，但清晰的问题意识和对失败的敏锐直觉，始终是优秀AI工程师的核心资产。

结语：站在范式迁移的节点上

我们正处于一个极其罕见的历史节点：一项通用技术的能力在短短五年内提升了数个数量级，而驾驭它的工程范式也随之经历了三次根本性的重构。

Prompt Engineering给了我们第一把钥匙，让我们能够用自然语言与AI沟通。Context Engineering给了我们更大的舞台，让AI能够接触到真实世界的信息。Harness Engineering正在给我们一整套基础设施，让AI能够可靠地自主完成真实世界的复杂任务。

每一次范式的迁移，都意味着AI工程师的工作内容和所需能力的深层变化。理解这个演进逻辑，不只是为了追赶技术潮流，更是为了在这个快速变化的领域中，保持清醒的判断力——知道什么在变，知道什么不变，知道自己站在哪里，知道下一步应该走向何处。

这场旅程，才刚刚开始。

本文写于2026年4月。AI领域发展迅速，部分技术细节可能随时间推移而更新，欢迎交流探讨。