这篇文章把 AI 工程实践分成三层递进能力：Prompt Engineering、Context Engineering、Harness Engineering。作者的核心判断是，Prompt 解决“说清楚”，Context 解决“给对信息”，Harness 解决“让系统可靠地跑起来”。当模型越来越强，Prompt 的边际价值在下降，真正决定生产级交付质量的，是上下文治理、验证闭环、技术债清理和多 Agent 协作等系统性设计。工程师的价值也因此上移，从“写代码的人”转向“设计让 AI 稳定写代码的系统的人”。
OpenAI 内部的一支 3 到 7 人小团队，在短短五个月内，让 AI 生成了将近 100 万行生产级别的代码。据称全程，没有一个工程师亲手写过一行业务逻辑代码。
你的第一反应是什么？兴奋？恐慌？焦虑？只要我学得慢，就不用学了？
这个问题的答案，藏在三个词里：Prompt Engineering、Context Engineering、Harness Engineering。
这篇文章想完整走一遍这三次进化的逻辑：它们分别解决了什么问题，它们之间是什么关系，它们的边界在哪里，以及当三者融合，AI 工程师的终极形态究竟是什么。
大语言模型（LLM）的底层逻辑，可以用一句话概括：它是一个极其擅长续写的系统。
你给它一段输入，它预测接下来最有可能出现的内容，不断生成，直到任务完成。
问题在于，最有可能出现并不等于你真正想要的。
同样是“帮我写一封道歉信”，加了不同的约束条件，结果天差地别：
这个“加约束”的过程，就是提示词工程（Prompt Engineering）的本质。
它研究的是：如何通过精心设计的输入，最大限度地激发模型的正确能力。
在 GPT 刚刚走入大众视野的那段时间，Prompt Engineering 是最炙手可热的技能。
每隔几天就有新的技巧被发现和分享：
2023—2024 年，“Prompt Engineer”一度被视为最有前途的职业之一。
但随后，底层环境发生了巨变：模型的智能化越来越高了。
GPT-3 时代，你需要精心设计的少样本提示才能让模型完成一个稍复杂的任务。到了 GPT-4、Claude 3，你随便说一句话，它就能理解你的意图，哪怕表达并不精准也没关系。
当模型本身的语言理解能力足够强，写好 Prompt 的边际效益就显著降低了。
更深层的问题随之浮现：即使模型听懂了你说的话，它有时候依然会给出错误的答案。原因不是你没说清楚，而是它根本不知道一些关键信息，也就是我们常说的上下文。
这，引出了第二次进化。
假设你雇了一位全世界最聪明的助理，但这位助理有一个致命弱点：记忆只有 7 秒。
每次会面，他都记不住上次聊过什么，不知道你的偏好，不了解你的项目背景。即使他智商超群，每次也要重新从零开始建立对你情况的了解。
你会在每次见面前，把关键信息整理成一份简报递给他，告诉他上次的决策、当前的目标、需要回避的坑。
这个准备简报的过程，就是 Context Engineering。
大语言模型的本质，就是这位“金鱼助理”。每次对话，它能看到的信息被严格限制在上下文窗口（Context Window）之内。窗口外的一切，它一无所知。
一个完整的 LLM 上下文，通常包含多层信息：系统指令、任务目标、历史消息、外部文档、工具输出、环境反馈等。
每一层都至关重要，却又都在争夺有限的 Token 空间。
Context Engineering 要解决的，就是这个信息注意力的问题。
RAG（Retrieval-Augmented Generation，检索增强生成）是 Context Engineering 中最具革命性的技术之一。
传统做法是把所有知识都写进 System Prompt，结果往往是空间爆满、模型不知道看哪里、输出质量反而下降。
RAG 的思路截然不同：不存知识，存索引。需要什么，临时去检索，精准注入。
这个机制让模型能够访问远超其参数记忆的外部知识，同时又不会被无关信息淹没。
随着对话越来越长，一个严峻问题出现了：历史消息会把上下文窗口撑满，挤走最新的关键信息。
更关键的是，当上下文过长时，模型会出现“中间遗忘（Lost in the Middle）”现象：它对开头和结尾内容记忆较好，对中间大段内容的关注度大幅下降。
解决方案是上下文压缩（Context Compression）：
OpenAI 的实战经验验证了这一点：他们把原来装满所有规范的巨型 agent.md 文件压缩到百行以内，只保留索引目录，需要什么规范就动态加载对应子文档。
结果是模型遵从度和输出质量显著提升。
Context Engineering 还有一条常被忽视的原则：单一事实来源（Single Source of Truth）。
在实际工程中，技术决策可能散落在企微消息、腾讯文档、本地 PDF、GitHub Issue 里。对 AI Agent 来说，这是灾难性的：它不知道该信哪个版本，最终只能综合出一个四不像的答案。
解决方案是强制将所有决策、规范、文档归档进代码仓库，确保 AI 的信息来源唯一、可追溯、版本受控。
假设你构建了一个代码生成 Agent，已经做到了：
然后你让它生成一个用户登录模块。
一小时后你回来检查，发现它：
提示词写得再好，上下文管得再精，也没能阻止这一切发生。
这些问题的根源不在“说什么”或“给什么信息”，而在于系统层面缺乏约束、验证和反馈机制。
这，是 Prompt Engineering 和 Context Engineering 的共同盲区。
Harness，字面意思是“马具”。
在 AI 工程语境下，这个比喻非常贴切：没有马具的马，信马由缰；套上马具，才能指哪打哪。
Harness Engineering，就是研究如何为大模型设计一套合适的“马具”。
一个完整的 AI Agent 系统，除了大模型本身之外的所有东西，都属于 Harness：规则、流程、工具、验证、反馈、记忆、权限、监控、回滚、多 Agent 协作等。
实验背景：OpenAI 内部项目，目标是用 AI 从零构建一个真实的软件产品，全程工程师不手写业务代码。
实验结果：5 个月，3-7 人团队，AI 生成近 100 万行生产级代码，效率约为纯人工的 10 倍。
但实验初期，Agent 频繁跑偏、反复犯同类错误，进展远不如预期。
转折点是团队意识到，真正的瓶颈不在模型，而在于 Harness 的设计。
他们实施了三大 Harness 策略：
策略一：上下文治理（Context Governance）
初期，他们把所有编码规范、架构设计、业务逻辑都堆进一个巨大的 agent.md 文件。结果 Agent 信息过载，越来越抓不住重点。
改进方案是把文件压缩到百行，只保留索引和分类。每当 Agent 需要特定规范，系统动态加载对应子文档。同时强制要求散落各处的决策记录全部迁移到代码仓库，确保唯一可信来源。
策略二：验证闭环（Verification Loop）
为了防止 Agent 自称“测试通过”，系统配备了完整工具栈：
这套机制把“声称完成”变成“验证完成”。
策略三：技术债清理（Tech Debt Cleanup）
大规模 AI 代码生成不可避免地引入重复命名、风格不一致、废弃文档等问题。
解决方案是设置后台运行的 Codex 任务，像垃圾回收机制一样，定期扫描代码库，自动修复偏离规范的代码和过时文档，让技术债在积累之前就被清理。
Anthropic 的研究揭示了另一个 Harness 必须解决的关键问题：AI 倾向于给自己的 Bug 打高分。
在尝试克隆 Claude.ai 复杂界面的实验中，单 Agent 模式下的问题很典型：
Anthropic 的解决方案是 F-Harness，引入角色分工机制：
这套机制代价很高：时间约从 20 分钟提升到 6 小时，成本从约 9 美元提升到约 200 美元，但输出质量从“勉强可用”提升到“生产环境级别”。
作者的结论是：当任务复杂度超过单 Agent 的可靠性边界，多 Agent 协作的 Harness 是唯一可行的工程解法。
很多人会误解为：Harness Engineering 更高级，前两个都过时了。
文章明确反对这种看法。三者之间是层层包裹、相互依存的嵌套关系：
用三个核心问题区分：
Anthropic 的研究者发现了一个很深刻的规律：模型能力越强，所需的 Harness 越简单。
在 Claude 3.0 时代，为了保证 Agent 不在复杂任务里崩溃，需要强制实施很严格的 Harness 约束：逐个功能点执行、频繁重置上下文、大量硬编码检查规则。
到了 Claude 3.5，其全局统筹能力、长上下文处理能力和自我校验能力显著提升，原本不可或缺的许多 Harness 规则，自然变得不再必要。
这条规律有两层含义：
第一层：Harness Engineering 是当下的现实答案。
第二层：Harness Engineering 可能是一项过渡性技术。随着模型能力持续提升，今天需要精心设计的许多规则，未来会被模型自然吸收。
实践建议：
OpenAI 在实验总结中提出了一个关键工程哲学：
“Human steer, agents execute.”
人类掌舵，Agent 执行。
这意味着工程师不是被取代，而是价值上移到了更高层：
衡量标准也发生切换：
掌握清晰表达意图的基本能力，包括：
但不要执着于“最佳提示词”，因为模型进化会让今天的最优提示变得不再必要。
需要掌握：
开始用 Harness 视角审视 AI 项目：
随时问自己两个问题：
能回答清楚这两个问题，才能把 Harness 设计得恰到好处。
回到最开始的问题：OpenAI 5 个月 100 万行代码，工程师的价值在哪里？
答案是：那 3 到 7 名工程师的价值，不体现在“手写代码的速度”上，而体现在他们搭建的那套 Harness 系统上，那套让 AI 能持续、可靠、高质量产出代码的“驾驭装置”。
这三次进化，其实服务于同一个目标：让大语言模型的能力，真正转化为可靠的生产力。
三者缺一不可，层层递进。
软件工程没有消失，它在进化。
从“写代码的人”，进化为“设计让 AI 把代码写好的系统的人”。
这，才是这个时代工程师最该掌握的技能。
来源：腾讯云开发者 原文链接：https://mp.weixin.qq.com/s/b1VL28GX5d17sKPfkSbIsw
标签：#主题/AI-Coding #主题/AI-Agent #手法/权威背书 #手法/对比冲突 #场景/公众号长文