从Prompt到Harness：AI工程的三次范式转移

2026年，OpenAI内部一个仅3-7人的小团队在五个月内让AI生成了近百万行生产级代码，全程没有工程师亲手编写任何业务逻辑代码。这一里程碑式的事件并非源于模型的突然爆发，而是AI工程方法论持续演进的必然结果。从Prompt Engineering到Context Engineering，再到Harness Engineering，这三次范式转移正在重新定义软件工程的本质。

第二阶段：突破上下文的边界

**第一阶段：提示词工程的本质与局限** 大语言模型本质上是一个极其擅长续写的系统——你给它一段输入，它预测接下来最可能出现的内容。问题在于「最可能」不等于「最需要」。同样一句「帮我写一封道歉信」，加上不同约束条件，结果天差地别。 提示词工程的核心就是「加约束」：通过精心设计的输入来激发模型的正确能力。关键技术包括零样本提示、少样本提示、思维链推理、角色扮演和提示链等。2023-2024年，提示词工程师曾被视为最有前途的职业，但随着模型智能化程度提升，「写好Prompt」的边际效益正在递减。当模型本身就能准确理解模糊表达时，提示词工程的局限性便显现出来——即使模型听懂了，它依然可能给出错误的答案，因为它缺乏关键的业务上下文。

第三阶段：系统架构工程的出现

**Context Engineering：赋予模型「记忆」的能力** 一个思想实验可以帮助理解上下文工程的核心：假设你雇了一位全世界最聪明但记忆只有7秒的助理——每次会面他都忘了上次聊过什么。你会怎么办？你会准备一份简报，告诉他上次的决策、当前目标、需要回避的坑。这个准备简报的过程就是Context Engineering。 大语言模型的上下文窗口（Context Window）就像这位金鱼的记忆。窗口内外的任何信息，模型都一无所知。RAG（检索增强生成）技术让模型能够按需从外部知识库中检索信息，而非将所有知识塞进系统提示词。同时，上下文压缩技术解决了对话过长导致的「中间遗忘」问题——通过滚动摘要、重要性评分和层次记忆来管理信息。 Context Engineering还有一条关键原则：单一事实来源。技术决策散落在即时通讯、文档、Issue中会导致AI无所适从，必须强制将所有规范归档至代码仓库，确保信息来源的唯一性和可追溯性。

三者的关系与演进规律

**Harness Engineering：给AI套上「马具」** 「Harness」原意是马具——没有马具的马野性难驯，套上马具才能指哪打哪。在AI工程中，Harness Engineering就是研究如何为大模型设计这套「驾驭装置」。一个完整的AI Agent系统，除了大模型本身之外的所有组件——工具链、验证回路、反馈机制——都属于Harness范畴。 OpenAI的百万行代码实验揭示了Harness的关键作用。初期Agent频繁跑偏、反复犯同类错误，直到团队实施三大策略：上下文治理（将巨型规范文件压缩为百行索引，动态加载子文档）、验证闭环（接入DevTools、可观测性工具、自动化测试，让AI的「声称完成」变为「验证完成」）、技术债清理（后台任务定期扫描修复偏离规范的代码）。 Anthropic的研究则解决了另一个问题：AI倾向于给自己的Bug打高分。通过F-Harness引入Planner-Generator-Evaluator三角色分工，虽然耗时和成本增加约20倍，但输出质量实现了质的飞跃——从「逻辑残缺」到「生产环境级别」。

工程师的新战场

**不是替代，而是嵌套** 三者之间的关系是层层包裹、相互依存的嵌套结构：没有好的Prompt，Context注入的信息无法被正确理解；没有好的Context，Harness的Agent会在信息真空中瞎跑；没有好的Harness，再好的Prompt和Context也只是沙滩上的城堡。 Anthropic发现了一个深刻规律：模型能力越强，所需的Harness越简单。这意味着Harness Engineering可能是一项过渡性技术——随着模型能力提升，许多规则会被模型「内化」。工程师的实践建议是：不要过度设计模型未来能自我解决的问题，把精力集中在业务逻辑边界和外部环境接口上。 **新范式下的工程师角色** 「Human steer, agents execute」——人类掌舵，Agent执行。工程师的价值正在从「体力劳动」向上迁移：定方向（产品思维、系统思维）、搭架子（Harness设计）、做判别（关键决策点的人工干预）。衡量标准也在切换：从「每天写多少行代码」变为「Harness能支撑多高的代码产出率」。

如有侵权，请联系删除。