【干货】从Prompt、Context到Harness，工程的三次进化与终局之战原创

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

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

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

Prompt Engineering、Context Engineering、Harness Engineering。

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

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

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

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

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

• 没有约束：千篇一律的模板文字（我会稳稳地接住你）

• 加上「对象是我的老板，原因是我迟到了三次」：开始接近实际需求

• 再加上「语气要诚恳但不要过分卑微，结尾要暗示我已经采取了改进措施」：这才是一封真正可用的信

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

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

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

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

• 零样本提示（Zero-shot Prompting）： 直接告诉模型做什么，不给例子。适合简单任务。

• 少样本提示（Few-shot Prompting）： 给几个输入-输出的例子，让模型从中"意会"规律。效果往往远好于零样本。

• 思维链（Chain-of-Thought, CoT）： 不让模型直接跳结论，而是引导它一步步推理。在数学、逻辑推理类任务上效果显著。

• 角色扮演（Role Prompting）： "你是一位有 20 年经验的 Java 架构师，请……" 给模型设定一个身份，往往能显著提升输出的专业性。

• 提示链（Prompt Chaining）： 把复杂任务拆成多个小提示，前一步的输出作为后一步的输入，像流水线一样串联。

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

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

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

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

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

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

更深层的问题随之浮现：

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

这，引出了第二次进化。

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

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

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

你会怎么办？

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

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

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

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

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

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

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

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

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

具体流程如下：

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

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

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

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

• 滚动摘要（Rolling Summary）： 定期将旧对话压缩为摘要，只保留精华

• 重要性评分（Importance Scoring）： 给每段历史内容打分，低分内容优先淘汰

• 层次记忆（Hierarchical Memory）： 短期记忆保留细节，长期记忆只存关键节点

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

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

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

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

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

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

• ✅ 精心设计的 System Prompt（Prompt Engineering）

• ✅ 动态注入最相关的代码规范文档（Context Engineering）

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

一小时后，你回来检查：

• 它写了登录逻辑——正确

• 但它同时"顺手"重构了你没让它动的数据库层——没人要求

• 它声称测试通过了——但根本没有运行测试，只是自我评估"应该能过"

• 它命名风格跟项目其他部分完全不一致——因为没有人告诉它有一套命名规范

• 它生成了三个功能重复的工具函数——因为没有机制检测重复

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

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

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

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

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

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

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

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

有一个简洁有力的公式：

一个完整的 AI Agent 系统，除了大模型本身之外的所有东西，都属于 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 任务，像操作系统的垃圾回收机制一样，定期扫描代码库，自动修复偏离规范的代码和过时文档。技术债在积累之前就被清理，代码库的整体健康度得以持续维持。

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

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

• 任务量过大，Agent 在中途耗尽上下文，"记不住"之前做了什么

• 功能只完成了一半，Agent 就宣称"已全部完成"

• 让 Agent 自评输出质量，结果是惊人的过度乐观

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

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

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

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

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

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

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

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

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

这是一个根本性的误解。

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

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

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

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

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

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

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

用三个核心问题来区分：

• Prompt Engineering 回答： "我该跟模型说什么？"

• Context Engineering 回答： "模型在回答时该知道什么？"

• Harness Engineering 回答： "整个 AI 系统该如何可靠地运转？"

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

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

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

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

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

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

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

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

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

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

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

实践建议由此而来：

不要过度设计那些模型未来能自我解决的问题。

把精力集中在两类场景：

1. 模型短期内无法通过自身能力解决的业务逻辑边界（行业特定规则、合规要求、复杂系统协同）

2. 即使模型能力再强也无法自行建立的外部环境接口（工具调用、API 集成、权限控制）

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

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

“Human steer, agents execute.”

人类掌舵，Agent 执行。

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

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

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

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

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

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

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

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

一个能设计出高效 Harness 的工程师，他的杠杆率是惊人的：他搭建的系统，能让 AI 持续产出远超他个人极限的代码量和质量。

升维了啊朋友们！

Prompt Engineering 的底层逻辑是如何清晰、精准地表达意图，是你与 AI 协作的基础语言能力。不必穷尽所有技巧，但要掌握核心：

• 知道如何用思维链引导模型推理

• 知道如何通过角色设定提升输出专业性

• 知道如何设计结构化输出格式（JSON、Markdown 等）以便后续处理

不要执着于"最佳提示词"的追求。 随着模型进化，今天的最优提示明天可能不再必要。

这是当下最具差异化的技能之一。你需要掌握：

• RAG 系统的设计与调优： 如何分块、如何选择 Embedding 模型、如何优化检索精度

• 上下文窗口管理： 如何在有限 Token 中做最优的信息选择

• 记忆系统设计： 短期/长期记忆的分层管理，对话历史的压缩策略

• 知识库治理： 如何维护一个 Agent 可信赖的单一事实来源

开始用 Harness 的视角审视你的 AI 项目：

• 我的 Agent 在哪些地方可能跑偏？如何设计约束防止它？

• 如何建立验证机制，让 Agent 的"声称完成"变成"验证完成"？

• 任务的哪些部分适合单 Agent？哪些需要多 Agent 协作？

• 什么样的监控和可观测性工具能让我及时发现 Agent 的异常？

这是最难培养、也是最有价值的能力。随时问自己两个问题：

1. "这个约束/规则是因为模型能力不足而存在的，还是因为业务逻辑本身需要它？"

2. "如果下一版模型变强了 20%，我的 Harness 里哪些部分可以被简化？"

能清晰回答这两个问题的工程师，能在 Harness 的设计上保持恰当的"薄厚"：不过度设计，不遗漏关键约束。

回到最开始的问题：OpenAI 5 个月 100 万行代码，工程师的价值在哪里？

现在，答案应该清晰了：

那 3 到 7 名工程师，没有一个人的价值体现在"手写代码的速度"上。他们的价值，体现在他们搭建的那套 Harness 系统上，那套让 AI 能够持续、可靠、高质量产出代码的"驾驭装置"。

这三次进化，其实服务于同一个目标：

让大语言模型的能力，真正转化为可靠的生产力。

• Prompt Engineering 解决了"说清楚"的问题

• Context Engineering 解决了"给够信息"的问题

• Harness Engineering 解决了"系统可靠"的问题

三者缺一不可，层层递进。

但最终，它们都在回答同一个问题：如何在人类的掌舵下，让 AI 这匹野马跑得又快又稳？

软件工程没有消失，它在进化。

从"写代码的人"，进化为"设计让 AI 把代码写好的系统的人"。

这，才是这个时代工程师最该掌握的技能——也是最值得你投入时间和精力的方向。