注：本文有使用 AI 进行辅助写作，特此说明。

引言：一个令人不安的问题

OpenAI 内部的一支 3 到 7 人小团队，在短短五个月内，让 AI 生成了将近 100 万行生产级别的代码。据称全程，没有一个工程师亲手写过一行业务逻辑代码。

你的第一反应是什么？兴奋？恐慌？焦虑？只要我学得慢，就不用学了？

这个问题的答案，藏在三个词里：

Prompt Engineering、Context Engineering、Harness Engineering。

这篇文章，我想带你完整走一遍这三次进化的逻辑：它们分别解决了什么问题，它们之间是什么关系，它们的边界在哪里，以及：当三者融合，AI 工程师的终极形态究竟是什么？

01

理解起点：为什么和 AI 说话是一门学问？

1.1 模型有能力，但你不一定会用

大语言模型（LLM）的底层逻辑，可以用一句话概括：它是一个极其擅长续写的系统。

你给它一段输入，它预测接下来最有可能出现的内容，不断生成，直到任务完成。

问题在于，最有可能出现并不等于你真正想要的。

同样是「帮我写一封道歉信」，加了不同的约束条件，结果天差地别：

没有约束：千篇一律的模板文字（我会稳稳地接住你）
加上「对象是我的老板，原因是我迟到了三次」：开始接近实际需求
再加上「语气要诚恳但不要过分卑微，结尾要暗示我已经采取了改进措施」：这才是一封真正可用的信

这个加约束的过程，就是提示词工程（Prompt Engineering）的本质。

它研究的是：如何通过精心设计的输入，最大限度地激发模型的正确能力。

1.2 Prompt Engineering 的武器库

在 GPT 刚刚走入大众视野的那段时间，Prompt Engineering 是最炙手可热的技能。

每隔几天就有新的技巧被发现和分享：

零样本提示（Zero-shot Prompting）：直接告诉模型做什么，不给例子。适合简单任务。
少样本提示（Few-shot Prompting）：给几个输入-输出的例子，让模型从中"意会"规律。效果往往远好于零样本。
思维链（Chain-of-Thought, CoT）：不让模型直接跳结论，而是引导它一步步推理。在数学、逻辑推理类任务上效果显著。
角色扮演（Role Prompting）： "你是一位有 20 年经验的 Java 架构师，请……" 给模型设定一个身份，往往能显著提升输出的专业性。
提示链（Prompt Chaining）：把复杂任务拆成多个小提示，前一步的输出作为后一步的输入，像流水线一样串联。

下图展示了 Prompt Engineering 技术的演进路径：

1.3 繁荣与衰退：Prompt Engineering 的宿命

2023—2024 年，"Prompt Engineer"一度被视为最有前途的职业之一，薪资水平令人咋舌。

但随后，底层环境发生了巨变：模型的智能化越来越高了。

GPT-3 时代，你需要精心设计的少样本提示才能让模型完成一个稍复杂的任务。

到了 GPT-4、Claude 3，你随便说一句话，它就能理解你的意图，甚至哪怕你的表达并不精准也没关系。

当模型本身的语言理解能力足够强，写好 Prompt 的边际效益就显著降低了。

更深层的问题随之浮现：

即使模型听懂了你说的话，它有时候依然会给出错误的答案。原因不是你没说清楚，而是它根本不知道一些关键信息，也就是我们常说的上下文。

这，引出了第二次进化。

02

第二进化：Context Engineering 的崛起

2.1 失忆症患者的困境

有一个思想实验可以帮你理解 Context Engineering 的核心：

假设你雇了一位全世界最聪明的助理，但这位助理有一个致命弱点：他属金鱼的，记忆只有 7 秒。

每次会面，他都记不住上次你们聊过什么，不知道你的偏好，不了解你的项目背景。即使他智商超群，每次都要重新从零开始建立对你情况的了解。

你会怎么办？

你会在每次见面前，把关键信息整理成一份简报递给他。你会告诉他上次的决策、当前的目标、需要回避的坑。

这个准备简报的过程，就是 Context Engineering。

大语言模型的本质，就是这位金鱼助理。每次对话，它能看到的信息被严格限制在上下文窗口（Context Window）之内。窗口外的一切，它一无所知。

2.2 上下文窗口里装着什么？

一个完整的 LLM 上下文，通常包含以下几层信息：

每一层都至关重要，却又都在争夺有限的 Token 空间。

Context Engineering 要解决的，就是这个信息注意力的问题。

2.3 RAG：让模型按需取用知识

RAG（Retrieval-Augmented Generation，检索增强生成）是 Context Engineering 中最具革命性的技术之一。

传统做法是把所有知识都写进 System Prompt，结果显而易见：空间爆满，模型不知道看哪里，输出质量反而下降。

RAG 的思路截然不同：不存知识，存索引。需要什么，临时去检索，精准注入。

具体流程如下：

这个机制让模型能够访问远超其参数记忆的外部知识，同时又不会被无关信息淹没。

2.4 上下文压缩：对抗遗忘的艺术

随着对话越来越长，一个严峻问题出现了：历史消息会把上下文窗口撑满，挤走最新的关键信息。

更坑爹的是，研究表明，当上下文过长时，模型会出现"中间遗忘（Lost in the Middle）"现象：它对开头和结尾的内容记忆较好，对中间大段内容的关注度大幅下降。

解决方案是上下文压缩（Context Compression）：

滚动摘要（Rolling Summary）：定期将旧对话压缩为摘要，只保留精华
重要性评分（Importance Scoring）：给每段历史内容打分，低分内容优先淘汰
层次记忆（Hierarchical Memory）：短期记忆保留细节，长期记忆只存关键节点

OpenAI 的实战经验验证了这一点：他们把原来装满所有规范的巨型 Agent.md 文件压缩至百行以内，仅作为索引目录，需要什么规范就动态加载对应子文档。

结果：模型的遵从度和输出质量显著提升。

2.5 单一事实来源：Context Engineering 的纪律

Context Engineering 还有一条常被忽视的原则：单一事实来源（Single Source of Truth）。

在实际工程中，技术决策可能散落在企微消息、腾讯文档、本地 PDF、GitHub Issue 里。对人类工程师来说，这已经够难管理了。对 AI Agent 来说，这是灾难性的：它不知道该信哪个版本，结果就是综合出一个四不像的答案。

解决方案是强制将所有决策、规范、文档都归档进代码仓库，确保 AI 的信息来源是唯一的、可追溯的、版本受控的。

03

两者的局限：当"说对"和"给对"都不够用

3.1 一个 Agent 的典型失控场景

假设你构建了一个代码生成 Agent，已经做到了：

✅ 精心设计的 System Prompt（Prompt Engineering）
✅ 动态注入最相关的代码规范文档（Context Engineering）

然后你让它生成一个用户登录模块。它：开干！

一小时后，你回来检查：

它写了登录逻辑——正确
但它同时"顺手"重构了你没让它动的数据库层——没人要求
它声称测试通过了——但根本没有运行测试，只是自我评估"应该能过"
它命名风格跟项目其他部分完全不一致——因为没有人告诉它有一套命名规范
它生成了三个功能重复的工具函数——因为没有机制检测重复

提示词写得再好，上下文管得再精，也没能阻止这一切发生。

因为这些问题的根源不在"说什么"或"给什么信息"，而在于：系统层面缺乏约束、验证和反馈机制。

这，是 Prompt Engineering 和 Context Engineering 的共同盲区。

填补这个盲区的，是第三次进化。

04

第三进化：Harness Engineering——驾驭 AI 的系统艺术

4.1 什么是 Harness？

Harness，字面意思是"马具"。

套在马身上的那套装备，比如缰绳、鞍具、辔头。没有马具的马骑起来那叫一个信马由缰，野得不行。套上马具的马，才能指哪打哪。

在 AI 工程语境下，这个比喻无比贴切。

Harness Engineering，就是研究如何为大模型设计一套合适的马具。

有一个简洁有力的公式：

一个完整的 AI Agent 系统，除了大模型本身之外的所有东西，都属于 Harness：

4.2 OpenAI 的百万行代码实验：Harness 的实战证明

这个实验值得我们仔细解剖，因为它揭示的不只是 AI 的能力，更是 Harness Engineering 的价值。

实验背景： OpenAI 内部项目，目标是用 AI 从零构建一个真实的软件产品，全程工程师不手写业务代码。

实验结果： 5 个月，3-7 人团队，AI 生成近 100 万行生产级代码，效率约为纯人工的 10 倍。

但是：实验初期，Agent 频繁跑偏、反复犯同类错误，进展远不如预期。

转折点：团队意识到，真正的瓶颈不在于 Harness 的设计。

他们随后实施了三大 Harness 策略：

策略一：上下文治理（Context Governance）

初期，他们把所有编码规范、架构设计、业务逻辑都堆进一个巨大的 agent.md 文件。结果 Agent 越来越傻福，信息太多，反而什么都抓不住重点。

改进方案：将文件压缩至百行，只保留索引和分类。每当 Agent 需要特定规范，系统动态加载对应子文档。同时，强制要求散落各处的决策记录（Slack、邮件、文档）全部迁移至代码仓库，确保 Agent 的唯一信息来源是可信的、版本受控的仓库。

策略二：验证闭环（Verification Loop）

为了防止 Agent 自我声称"测试通过"而实际上根本没运行测试，他们为系统配备了完善的工具栈：

接入 Chrome DevTools：AI 可自行截图、模拟操作，视觉验证 UI 是否符合预期
接入可观测性工具：AI 读日志、查性能指标，主动排查问题
强制 Lint 检查 + 自动化测试：代码不符合规范，报错信息自动反馈给 AI，要求原地修复，形成闭环

这套机制让 AI 的"声称完成"变成了"验证完成"，是质量保障的核心。

策略三：技术债清理（Tech Debt Cleanup）

大规模 AI 代码生成不可避免地引入重复命名、风格不一致、废弃文档等问题。

解决方案：设置后台运行的 Codex 任务，像操作系统的垃圾回收机制一样，定期扫描代码库，自动修复偏离规范的代码和过时文档。技术债在积累之前就被清理，代码库的整体健康度得以持续维持。

4.3 Anthropic 的 F-Harness：解决 AI 的"自恋问题"

Anthropic 的研究揭示了另一个 Harness 必须解决的关键问题：AI 倾向于给自己的 Bug 打高分。

在尝试克隆 Claude.ai 复杂界面的实验中，单 Agent 模式下的问题触目惊心：

任务量过大，Agent 在中途耗尽上下文，"记不住"之前做了什么
功能只完成了一半，Agent 就宣称"已全部完成"
让 Agent 自评输出质量，结果是惊人的过度乐观

Anthropic 的解决方案是F-Harness——引入角色分工机制：

Planner（规划者）：将模糊需求拆解为精细的、可逐项追踪的功能列表。这解决了"任务量过大导致中途迷失"的问题。

Generator（生成者）：按照功能列表逐项执行，完成一项才标记一项，稳扎稳打。

Evaluator（评估者）：独立的第三方审核 Agent，专门审核 Generator 的产出。关键在于：它与 Generator 完全独立，不受生成偏见的影响。

这套机制的代价是真实的：

维度	单 Agent 模式	F-Harness 三 Agent 模式
耗时	约 20 分钟	约 6 小时
成本	约 $9	约 $200
输出质量	逻辑残缺，勉强可用	生产环境级别，逻辑完整

20 倍的时间代价，22 倍的成本代价，换来的是质的飞跃。

当任务的复杂度超过单 Agent 的可靠性边界，多 Agent 协作的 Harness 是唯一可行的工程解法。

05

三者的关系：不是替代，是嵌套

5.1 最大的误解

讨论到这里，很多人会有一个自然的反应：

"所以，Harness Engineering 是最高级的，前两个都过时了？"

这是一个根本性的误解。

三者之间的关系是层层包裹、相互依存的嵌套关系：

没有好的 Prompt，Context Engineering 注入的信息无法被模型正确理解。

即使你把最相关的文档精准注入了上下文，如果指令本身模糊不清，模型依然会产生偏差。

没有好的 Context 的 Harness Engineering 的 Agent 在信息真空中瞎跑。

即使你设计了完美的多 Agent 协作机制、完善的验证回路，如果 Agent 根本不知道业务规则是什么、代码规范是什么，它依然会生成垃圾。

没有好的 Harness，再好的 Prompt 和 Context 只是沙滩上的城堡。

即使单次对话的输出质量很高，没有系统级的约束和反馈，在复杂任务中 Agent 依然会累积错误，最终崩溃。

5.2 三者的职责边界

用三个核心问题来区分：

Prompt Engineering 回答： "我该跟模型说什么？"
Context Engineering 回答： "模型在回答时该知道什么？"
Harness Engineering 回答： "整个 AI 系统该如何可靠地运转？"

三个问题，三个维度，缺一不可。

06

Harness 的衰变定律：最深刻也最容易被误解的规律

6.1 一个反直觉的发现

Anthropic 的研究者在对比不同版本模型的表现时，发现了一个深刻的规律：

模型能力越强，所需的 Harness 越简单。

在 Claude 3.0 时代，为了保证 Agent 不在复杂任务中途崩溃，需要强制实施极严格的 Harness 约束：逐个功能点执行、频繁重置上下文、大量硬编码的检查规则。

但当模型升级到 Claude 3.5，其全局统筹能力、长上下文处理能力和自我校验能力大幅提升：原本不可或缺的许多 Harness 规则，自然变得不再必要。

这一规律，可以用一张图来表达：

6.2 这意味着什么？

这条规律有两层深意，理解它们，能让你避开两个截然相反的陷阱：

第一层：Harness Engineering 是当下的现实答案。

在模型能力尚未完美的今天，Harness 是让 AI 系统在生产环境可靠运行的必要条件。不做 Harness，就是让野马在生产环境横冲直撞。

第二层：Harness Engineering 可能是一项过渡性技术。

随着模型能力持续提升，今天需要精心设计的许多 Harness 规则，未来会被模型能力自然吸收。大语言模型正在逐渐"内化"这些系统规则：自动识别任务优先级、自动验证输出、自动处理边界情况。

实践建议由此而来：

不要过度设计那些模型未来能自我解决的问题。
把精力集中在两类场景：
1. 模型短期内无法通过自身能力解决的业务逻辑边界（行业特定规则、合规要求、复杂系统协同）
2. 即使模型能力再强也无法自行建立的外部环境接口（工具调用、API 集成、权限控制）

谁能根据模型能力的边界，动态调整 Harness 的"厚度"，谁就能在工程效率上获得最高回报。

07

新范式下的工程师：Human Steer, Agents Execute

7.1 一次职责的根本性重构

OpenAI 在实验总结中提出了这个时代最重要的工程哲学：

“Human steer, agents execute.”
人类掌舵，Agent 执行。

这句话的分量，需要反复咀嚼。

它不是在说工程师会被取代。恰恰相反，它是在说工程师的价值正在向上迁移到一个更高的维度。

在传统开发模式下，工程师是"体力劳动者"：大部分时间耗费在编写具体逻辑、处理报错、维护测试、更新文档上。

在 Harness Engineering 的范式下，这一切已经可以交给 Agent 执行。工程师的核心职责变成了三件事：

① 定方向（Steering）：清楚地知道要建什么、为什么建、最终形态是什么。这需要产品思维、系统思维和业务洞察——这些是模型目前最难替代的。

② 搭架子（Harnessing）：为 Agent 构建可靠的运行支架：制定规则、提供可信的上下文来源、设计自动化验证和反馈回路。这是 Harness Engineering 的核心技能。

③ 做判别（Decision Making）：在关键的架构决策点、技术路线选择点、风险边界节点进行人工干预和确认。AI 不应该独立做所有决策，工程师需要知道在哪些节点必须介入。

7.2 衡量标准的切换

这种范式转变带来了一个根本性的变化：衡量一个工程师能力的标准，正在悄悄切换。

过去的衡量标准	新的衡量标准
每天能写多少行代码	Harness 能支撑多高的代码产出率
能实现多复杂的业务逻辑	能设计多健壮的 Agent 系统
能处理多难的 Bug	能构建多完善的自动闭环机制
对某语言/框架的熟悉程度	对 AI 系统边界和失效模式的理解深度
个人产出（Individual Output）	系统杠杆（System Leverage）