从 Prompt、Context 到 Harness，工程的三次进化
Prompt Engineering、Context Engineering、Harness Engineering。这篇文章带你完整走一遍这三次进化的逻辑：它们分别解决了什么问题，之间的关系是什么，边界在哪里，以及当三者融合，AI 工程师的终极形态究竟是什么。
引言
OpenAI 内部的一支 3 到 7 人小团队，在短短五个月内，让 AI 生成了将近 100 万行生产级别的代码。全程没有工程师亲手写过一行业务逻辑代码。
这个问题的答案，藏在三个词里。
01 理解起点：Prompt Engineering
1.1 模型有能力，但你不一定会用
LLM 的底层逻辑：它是一个极其擅长续写的系统。你给它输入，它预测接下来最有可能出现的内容。问题在于，最有可能出现并不等于你真正想要的。
同样是「帮我写一封道歉信」：
- 没有约束 → 千篇一律
- 加上「对象是老板，原因迟到三次」 → 开始接近需求
- 加上「语气诚恳但不卑微，结尾暗示已改进」 → 真正可用
这个加约束的过程，就是 Prompt Engineering 的本质。
1.2 武器库
| 技术 | 说明 |
|---|---|
| 零样本提示 | 直接说，不给例子 |
| 少样本提示 | 给几个输入输出示例 |
| 思维链 (CoT) | 引导逐步推理 |
| 角色扮演 | 设定身份，提升专业性 |
| 提示链 | 多步串联，前一步输出作后一步输入 |
1.3 繁荣与衰退
2023-2024 年"Prompt Engineer"最炙手可热。但模型智能化程度越来越高——GPT-3 需要精心的少样本提示，到了 GPT-4、Claude 3，随便说一句话就能理解意图。
更深层的问题：即使模型听懂了，它有时候依然会给出错误答案。原因不是你没说清楚，而是它根本不知道一些关键信息——上下文。
02 Context Engineering 的崛起
2.1 金鱼助理
思想实验：你雇了全世界最聪明的助理，但他记忆只有 7 秒。每次会面都记不住上次聊过什么。
你会怎么办？每次见面前把关键信息整理成简报递给他。这个准备简报的过程，就是 Context Engineering。
2.2 Context Window 里装着什么？
系统提示、对话历史、检索到的知识、工具调用结果——每一层都在争夺有限的 Token 空间。
2.3 RAG：让模型按需取用知识
传统做法：把所有知识写进 System Prompt → 空间爆满，输出质量下降。
RAG 思路：不存知识，存索引。需要什么，临时检索，精准注入。让模型访问远超其参数记忆的外部知识，同时不被无关信息淹没。
2.4 上下文压缩
当对话越来越长，"中间遗忘（Lost in the Middle）"现象出现：模型对开头和结尾记忆较好，对中间关注度大幅下降。
解决方案：
- 滚动摘要：定期将旧对话压缩
- 重要性评分：低分内容优先淘汰
- 层次记忆：短期保留细节，长期只存关键节点
OpenAI 实战：把巨型 agent.md 压缩至百行以内，仅作为索引目录，需要什么规范动态加载对应子文档。模型遵从度和输出质量显著提升。
2.5 单一事实来源
技术决策散落在企微、文档、PDF、Issue 里 → AI 不知道该信哪个版本 → 综合出四不像。
解决方案：强制所有决策、规范、文档归档进代码仓库，确保 AI 的信息来源唯一、可追溯、版本受控。
03 两者的局限
即使做到了精心设计的 System Prompt + 动态注入最相关的代码规范，Agent 依然可能失控：
- 顺手重构没让它动的数据库层
- 声称测试通过但根本没运行
- 命名风格与项目不一致
- 生成功能重复的工具函数
因为问题根源不在"说什么"或"给什么信息"，而在系统层面缺乏约束、验证和反馈机制。
04 Harness Engineering — 驾驭 AI 的系统艺术
4.1 什么是 Harness？
Harness = 马具。套在马身上的缰绳、鞍具、辔头。没有马具的马信马由缰，套上马具才能指哪打哪。
有一个简洁的公式：AI Agent 系统 = LLM + Harness
4.2 OpenAI 百万行代码实验
背景：用 AI 从零构建软件产品，工程师不手写业务代码。
结果：5 个月，3-7 人，近 100 万行生产级代码，效率约为纯人工的 10 倍。
转折点：初期 Agent 频繁跑偏，团队意识到瓶颈在 Harness。
三大 Harness 策略：
| 策略 | 做法 |
|---|---|
| 上下文治理 | agent.md 压缩至百行只做索引，动态加载子文档。散落决策全部迁移至仓库 |
| 验证闭环 | Chrome DevTools 截图验证 UI + 可观测性工具 + 强制 Lint/测试，报错自动反馈给 AI 修复 |
| 技术债清理 | 后台 Codex 任务定期扫描代码库，自动修复规范偏离和过时文档 |
4.3 Anthropic 的 F-Harness
Anthropic 发现 AI 倾向于给自己的 Bug 打高分。解决方案——F-Harness 角色分工：
| 角色 | 职责 |
|---|---|
| Planner | 将模糊需求拆解为可逐项追踪的功能列表 |
| Generator | 按功能列表逐项执行，完成一项标记一项 |
| Evaluator | 独立第三方审核，与 Generator 完全独立 |
代价对比：
| 维度 | 单 Agent | F-Harness 三 Agent |
|---|---|---|
| 耗时 | ~20min | ~6h |
| 成本 | ~$9 | ~$200 |
| 输出 | 逻辑残缺 | 生产级别，逻辑完整 |
05 三者的关系：不是替代，是嵌套
最大的误解："Harness 最高级，前两个过时了？"
三者是层层包裹、相互依存的嵌套关系：
- 没有好的 Prompt，Context 注入的信息无法被正确理解
- 没有好的 Context，Harness 里的 Agent 在信息真空中瞎跑
- 没有好的 Harness，再好的 Prompt 和 Context 只是沙滩上的城堡
三个核心问题：
| Engineering | 回答的问题 |
|---|---|
| Prompt | 我该跟模型说什么？ |
| Context | 模型在回答时该知道什么？ |
| Harness | 整个 AI 系统该如何可靠地运转？ |
06 Harness 的衰变定律
模型能力越强，所需的 Harness 越简单。
Claude 3.0 时代需要强制实施极严格的 Harness 约束。Claude 3.5 升级后，许多规则自然变得不再必要。
两层深意：
- Harness 是当下的现实答案 — 在模型能力尚未完美的今天，不做 Harness 就是让野马在生产环境横冲直撞
- Harness 可能是一项过渡性技术 — 随着模型进化，许多规则会被模型能力自然吸收
实践建议：不要过度设计那些模型未来能自我解决的问题。精力集中在：
- 模型短期内无法解决的业务逻辑边界
- 即使模型能力再强也无法自行建立的外部环境接口
07 新范式：Human Steer, Agents Execute
"人类掌舵，Agent 执行。"
工程师的核心职责变成三件事：
| 职责 | 说明 |
|---|---|
| 定方向 | 清楚地知道要建什么、为什么建 |
| 搭架子 | 为 Agent 构建可靠的运行支架 |
| 做判别 | 在关键决策点进行人工干预和确认 |
衡量标准切换：
| 过去 | 现在 |
|---|---|
| 每天写多少行代码 | Harness 能支撑多高的代码产出率 |
| 实现多复杂的业务逻辑 | 设计多健壮的 Agent 系统 |
| 个人产出 | 系统杠杆 |
08 实践路线图
- 打牢 Prompt 基础：知道 CoT、角色设定、结构化输出。不执着于"最佳提示词"
- 系统学习 Context Engineering：RAG 设计调优、上下文窗口管理、记忆系统设计、知识库治理
- 从系统视角思考 Agent 设计：Agent 在哪里可能跑偏？如何设计约束和验证？何时单 Agent 何时多 Agent？
- 培养"动态 Harness 思维"：这个约束是因为模型能力不足还是业务逻辑需要？如果下一版模型强了 20%，哪些部分可以简化？
结语
Prompt Engineering 解决了"说清楚"，Context Engineering 解决了"给够信息"，Harness Engineering 解决了"系统可靠"。
三次进化，一个目标：让 LLM 的能力真正转化为可靠的生产力。
从"写代码的人"，进化为"设计让 AI 把代码写好的系统的人"。