从"说对话"到"建系统"：Prompt、Context、Harness 工程的三次进化与终局之战

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

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

这不是科幻小说，这是已经发生的事实。

你的第一反应是什么？兴奋？恐慌？还是一种说不清道不明的焦虑——"我还需要学什么，才不会被时代抛下？"

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

Prompt Engineering、Context Engineering、Harness Engineering。

如果你只知道第一个，你还停留在 AI 应用的起点。如果你开始理解第二个，你已经迈入中级。而如果你真正掌握了第三个——你将成为这个时代最稀缺的那种工程师。

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

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

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

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

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

听起来很简单？

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

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

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

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

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

Prompt Engineering 的武器库

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

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

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

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

繁荣与衰退：Prompt Engineering 的宿命

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

但随后，一个微妙的变化开始发生：模型越来越聪明了。

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

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

这不是说 Prompt Engineering 毫无价值，而是它的边际收益在递减。当模型本身的语言理解能力足够强，"说对话"的门槛自然降低。

更深层的问题随之浮现：

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

这，引出了第二次进化。

二、第二进化：Context Engineering 的崛起

失忆症患者的困境

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

假设你雇了一位全世界最聪明的助理，但这位助理有一个致命弱点——他有严重的短期失忆症。

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

你会怎么办？

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

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

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

上下文窗口里装着什么？

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

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

Context Engineering 要解决的，正是这场信息的"争夺战"。

RAG：让模型按需取用知识

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 的纪律

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

在实际工程中，技术决策可能散落在 Slack 消息、Google Docs、Confluence 页面、GitHub Issue 里——四处为家。

对人类工程师来说，这已经够难管理了。对 AI Agent 来说，这是灾难性的：它不知道该信哪个版本，往往会"综合"出一个四不像的答案。

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

这不只是工程习惯，这是让 AI 可靠工作的基础设施。

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

一个 Agent 的典型失控场景

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

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

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

它开始工作了……

一小时后，你回来检查：

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

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

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

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

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

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

什么是 Harness？

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

套在马身上的那套装备——缰绳、鞍具、辔头——不是为了限制马的能力，而是为了将马的力量导向正确的方向，防止它伤人伤己。

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

大语言模型就是那匹野马——天赋异禀，力量惊人，但如果没有约束，它随时可能跑偏、踩坑、把你的生产环境搞得一团糟。

Harness Engineering，就是研究如何为这匹野马设计一套合适的"驾驭系统"。

有一个简洁有力的公式：

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

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 任务，像操作系统的垃圾回收机制一样，定期扫描代码库，自动修复偏离规范的代码和过时文档。技术债在积累之前就被清理，代码库的整体健康度得以持续维持。

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

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 系统该如何可靠地运转？"

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

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

一个反直觉的发现

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

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

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

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

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

这意味着什么？

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

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

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

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

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

实践建议由此而来：

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

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

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

一次职责的根本性重构

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

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

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

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

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

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

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

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

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

衡量标准的切换

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

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

这不是取代，这是升维。

八、实践路线图：如何成为 Harness Engineering 时代的工程师

第一步：打牢 Prompt 基础，但不要执着于它

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

• 知道如何用思维链引导模型推理
• 知道如何通过角色设定提升输出专业性
• 知道如何设计结构化输出格式（JSON、Markdown 等）以便后续处理

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

第二步：系统学习 Context Engineering

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

• RAG 系统的设计与调优： 如何分块、如何选择 Embedding 模型、如何优化检索精度
• 上下文窗口管理： 如何在有限 Token 中做最优的信息选择
• 记忆系统设计： 短期/长期记忆的分层管理，对话历史的压缩策略
• 知识库治理： 如何维护一个 Agent 可信赖的单一事实来源

第三步：从系统视角思考 Agent 设计

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

• 我的 Agent 在哪些地方可能跑偏？如何设计约束防止它？
• 如何建立验证机制，让 Agent 的"声称完成"变成"验证完成"？
• 任务的哪些部分适合单 Agent？哪些需要多 Agent 协作？
• 什么样的监控和可观测性工具能让我及时发现 Agent 的异常？

第四步：培养"动态 Harness 思维"

这是最难培养、也是最有价值的能力：

随时问自己两个问题：

1. "这个约束/规则是因为模型能力不足而存在的，还是因为业务逻辑本身需要它？"
2. "如果下一版模型变强了 20%，我的 Harness 里哪些部分可以被简化？"

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

结语：三次进化，一个目标

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

现在，答案应该清晰了：

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

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

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

• Prompt Engineering 解决了"说清楚"的问题
• Context Engineering 解决了"给够信息"的问题
• Harness Engineering 解决了"系统可靠"的问题

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

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

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

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

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

你现在站在哪一层？ Prompt Engineer？Context Engineer？还是已经在思考 Harness 的设计了？

欢迎留言，我们一起探讨。

下期预告：如何从零设计一个生产级别的 Multi-Agent Harness 系统——从架构设计到工具选型，完整实战拆解。