从提示词到驾驭工程：AI Agent 的三层进化

一路向北⁢

487人浏览 · 2026-04-16 11:45:25

一路向北⁢ · 2026-04-16 11:45:25 发布

🧠 从提示词到驾驭：AI 工程的三层进化

一篇文章讲透大模型应用开发的三个核心工程概念
提示词工程 → 上下文工程 → 驾驭工程

文章目录

🧠 从提示词到驾驭：AI 工程的三层进化

📌 写在前面

你可能已经用过 ChatGPT、Claude、Cursor、Trae 等 AI 工具。它们看起来各不相同，但底层原理惊人一致。如果你觉得 AI 时灵时不灵、对话越长越傻、写代码写着写着就跑偏……别急，这篇文章将带你从底层原理出发，一步步理解这些现象背后的原因，以及行业是如何通过 三层工程体系 来解决这些问题的。

一、大模型的基础与提示词工程 (Prompt Engineering)

1.1 大模型到底是什么？

把所有 AI 应用的外壳剥开，大模型（LLM, Large Language Model）的本质非常朴素——它就是磁盘上一个 超大的参数文件。

组合方式	得到的产品
参数文件 + 显卡内存 + HTTP 接口	API 服务（如 OpenAI API、Anthropic API）
API 服务 + 聊天界面	ChatGPT、Claude.ai 等对话产品
API 服务 + 代码编辑器	Cursor、Claude Code、Trae 等 AI IDE

1.2 它的工作原理——“猜词游戏”

大模型的核心工作原理极其简单：基于当前输入的所有内容，预测下一个字词大概率是什么。

想象一个游戏：我说 “今天天气真___”，你会补什么？大概率是"好"、“不错”、“热”。大模型做的事情本质上跟这个一模一样，只不过它读过互联网上几乎所有的公开文本，所以"猜"得又快又像样。

关键洞察：如果你的输入太宽泛（比如"帮我写个程序"），它能补出的方向就太多了——可能猜 Python，也可能猜 Java；可能写个计算器，也可能写个爬虫。结果自然不符合你的预期。

1.3 提示词工程——教 AI “听懂人话”

为了让大模型不乱猜，我们需要在输入中增加各种 约束条件，让模型的预测空间变窄、答案更精准。

这种有意识地调整和设计提示词，让模型稳定地朝着预期内容和格式输出的技术手段，就叫做「提示词工程」。

常见的提示词约束维度

┌─────────────────────────────────────────────┐
│              一条好的提示词                    │
├─────────────────────────────────────────────┤
│  🎭 角色设定    "你是一个资深前端工程师"         │
│  📋 背景信息    "项目使用 React + TypeScript"  │
│  🎯 明确需求    "给完整函数代码，不要乱改我的代码"│
│  📖 参考资料    "参考这份 API 文档：..."        │
│  🚫 限制条件    "不要使用第三方库"              │
│  📝 输出格式    "用 Markdown 表格输出"          │
│  💬 历史对话    "之前我们讨论过 X 方案..."       │
└─────────────────────────────────────────────┘

一个直观的对比

场景	❌ 差的提示词	✅ 好的提示词
写代码	“帮我写个排序”	“用 Python 实现快速排序算法，要求：1）函数名为 quick_sort；2）支持自定义比较函数；3）包含完整的 docstring 和类型注解”
翻译	“翻译这段话”	“你是一位专业的技术文档翻译，请将以下英文翻译为简体中文。要求：1）专业术语保留英文原文并在括号中标注；2）保持 Markdown 格式不变”
分析	“分析这个 bug”	“你是一位 Java 后端开发专家。以下是一段出现 NPE 的代码和堆栈信息，请：1）定位根本原因；2）给出修复代码；3）说明如何避免类似问题”

1.4 提示词工程解决了什么？

一句话总结：提示词工程解决了大模型 无引导时乱说话 的问题——通过精心设计的输入，让模型明白你的具体需求和输出标准。

用一个类比来说：大模型是一个超级聪明但需要明确指令的实习生。提示词工程就是学会怎么 给他下一个不会被误解的任务指令。

二、上下文工程 (Context Engineering)

2.1 从提示词到上下文——量变引发的质变

提示词写得越长越仔细，模型回答就越准。于是人们自然想到：把大量资料——文档、代码、数据——全部打包发给大模型，这些所有塞给模型的信息就叫做 「上下文」（Context）。

但问题来了。

2.2 上下文窗口——大模型的"工作台"

大模型一次性能处理的信息量是有限的，这个上限叫做 「上下文窗口」（Context Window）。

你可以把上下文窗口想象成一张 办公桌：

┌─────────────────────────────────────────────┐
│                 办公桌（上下文窗口）            │
│                                             │
│  📄 系统提示词      📋 项目背景              │
│  💬 第1轮对话       💬 第2轮对话              │
│  💬 第3轮对话       📎 参考文档               │
│  💬 第4轮对话       📎 代码文件               │
│  💬 第5轮对话       ⚠️ 报错日志               │
│  ...                                        │
│  ❌ 桌子满了！放不下了！                       │
└─────────────────────────────────────────────┘

当办公桌满了，就必须把一些资料 收起来或扔掉。这就像你把之前的会议记录扔了——下次开会时你可能就忘了之前讨论的决定。

2.3 上下文劣化——AI “越聊越傻” 的根本原因

在多轮对话中，上下文窗口很容易被打满，系统就需要压缩或丢弃部分信息。这会导致：

症状	表现	原因
🧠 失忆	“你之前不是说用方案 A 吗？怎么又变了？”	早期对话被压缩，关键决策信息丢失
🔄 前后矛盾	上一条消息说"不要改 X 文件"，这一条就改了	约束信息随压缩被丢弃
📉 质量下降	对话越长，代码质量越差	核心指令和规范被稀释
🎯 跑偏	做着做着偏离了原始需求	原始目标被新对话内容淹没

这种关键信息丢失、模型理解产生偏差的现象，统称为「上下文劣化」。

2.4 上下文工程的定义

既然提示词只是上下文的一部分，那么 提示词工程本质上也是上下文工程的一个子集。

上下文工程的核心命题是：怎么在合适的时候，将合适的内容，塞入到有限的上下文中。

这通常不再是人手动完成的，而是通过 外部程序（如 Cursor、Claude Code、Trae 等 Coding Agent 工具）来自动实现。

💡 为什么使用同一个模型，不同工具的效果差异很大？ 因为各家 AI 工具的上下文管理策略不同——有的善于召回关键信息，有的压缩做得好，有的组装顺序更合理。模型相同，上下文不同，效果天差地别。

2.5 上下文工程的三大核心步骤

                    ┌──────────┐
    外部世界         │          │          模型
                    │  上下文   │
  📰 新闻资讯  ────→│          │
  💾 历史对话  ────→│  工程流水线│────→  🤖 大模型
  📁 代码文件  ────→│          │
  ⚠️ 报错日志  ────→│          │
                    └──────────┘
                    
          ① 召回  →  ② 压缩  →  ③ 组装

① 召回 (Recall)——找到最相关的信息

从海量信息中，找到与当前任务最相关的内容。信息来源包括但不限于：

外部知识：文档、新闻、API 参考
历史记录：过去的聊天记录、项目决策
当前环境：正在编辑的代码文件、目录结构
运行反馈：程序报错日志、测试结果

常用技术包括 RAG（检索增强生成）、Memory（记忆系统）、语义搜索 等。

类比：你要写一份报告。召回就是去图书馆、网上、同事那里搜集所有相关资料。

② 压缩 (Compress)——把信息变小

由于上下文窗口有限（“办公桌就那么大”），不可能把召回的原始资料全部放进去。需要进行 精简和压缩：

将长文档分段发给模型做摘要
只保留与当前任务相关的 关键片段
用 结构化格式 替换冗长的自然语言描述

类比：你搜集了 200 页资料，但办公桌只放得下 20 页——你需要把每份资料的精华提炼到便利贴上。

③ 组装 (Assemble)——按最优顺序排列

信息放置的 位置和顺序 会直接影响模型的理解和输出质量。

一个重要的发现：越靠后的内容，越容易被模型关注和遵循（类似"近因效应"）。因此：

最重要的指令和约束放在最后
背景信息放在开头
参考资料放在中间

通过精心组装，让进入模型的上下文 更精简、更相关、更有结构，输出也就更稳定、更准确。

类比：你整理好了 20 页精华资料。现在要决定哪页放最上面（最容易看到）、哪页做索引、哪页压箱底。

2.6 上下文工程解决了什么？

一句话总结：上下文工程解决了 信息过多与窗口有限 之间的矛盾——通过智能的召回、压缩、组装，给大模型注入精准有效的上下文。

如果说提示词工程是教你 怎么说话，那上下文工程就是教你 怎么备课——确保你说的每一句话都有正确的背景知识支撑。

三、驾驭工程 (Harness Engineering)

3.1 光说不练的困境

提示词工程和上下文工程让模型变聪明了，但它依然有一个根本性限制：只能"聊天"而没法"干活"。

你可以把到目前为止的 AI 想象成一个 被绑在椅子上的天才顾问——他能给你绝妙的建议，但没有手脚去执行。给他松绑、给他工具、给他工作流程——这就是驾驭工程要做的事。

3.2 Agent 的本质与挑战

Agent（智能体） 是大模型从"能聊天"到"能干活"的关键进化。但它的本质非常简单——就是一个循环：

思考 → 行动 → 观察 → 思考 → 行动 → 观察 → ...（循环）

问题在于：一旦循环变长，上下文必定膨胀甚至劣化。最初设定的目标和约束会被大量的中间信息冲淡，模型的理解会产生偏移——就像一个人走路不看地图，走着走着就迷路了。

3.3 驾驭工程的定义

驾驭工程（Harness Engineering）的概念由 OpenAI 在 2026 年的一篇博客中正式提出。

它是一套包裹着大模型的"工程外壳"。

┌─────────────────────────────────────────────────┐
│               驾驭工程 (Harness)                  │
│  ┌───────────────────────────────────────────┐  │
│  │                                           │  │
│  │    执行层 │ 记忆层 │ 反馈层 │ 编排层        │  │
│  │                                           │  │
│  │    ┌───────────────────────────────┐      │  │
│  │    │         大模型 (LLM)          │      │  │
│  │    └───────────────────────────────┘      │  │
│  │                                           │  │
│  └───────────────────────────────────────────┘  │
│                                                 │
└─────────────────────────────────────────────────┘

其核心公式：

Agent = 大模型 + Harness Engineering

只要不属于大模型本体的部分，都属于驾驭工程的范畴。

3.4 四大核心层级

🔧 执行层 (Execution Layer)——给 AI “松绑”

赋予大模型操作外部世界的能力：

能力	举例	价值
Shell 命令	运行 Bash/PowerShell	执行构建、测试、部署
文件系统	读写本地文件	修改代码、生成文档
MCP 工具	调用外部服务	查数据库、发请求、操作浏览器
浏览器	打开网页、截图	验证 UI、爬取信息

结合外部循环，就形成了 ReAct 机制（Reasoning + Acting）：

大模型思考："需要先安装依赖"
    ↓
外部程序执行：npm install
    ↓
执行结果/报错加入上下文
    ↓
大模型继续推理："安装成功，接下来修改配置文件..."
    ↓
外部程序执行：修改文件
    ↓
... 循环继续

类比：执行层就是给天才顾问配了一套工具箱——锤子、螺丝刀、电脑。他终于可以自己动手干活了。

💾 记忆层 (Memory Layer)——防止 AI “失忆”

为了防止长循环导致目标偏移，必须保证 每次给大模型的上下文都包含核心信息：

📋 项目目标和需求背景
🛠️ 技术栈和架构约定
🎨 代码风格和命名规范
🚫 禁止事项和红线
✅ 质量标准和验收条件

这些信息被写成独立的 “规则文件”。以 Claude Code 为例，这就是 CLAUDE.md 文件。在每次调用模型时，它会作为系统提示词 自动注入 到上下文中。

当规则文件变得太长时，怎么办？

拆分为多个短文件，并加入简单的路由机制：

CLAUDE.md（主文件，始终加载）
├── "背景信息请参考 → docs/background.md"
├── "技术栈规范请参考 → docs/tech-stack.md"  
├── "代码风格请参考 → docs/code-style.md"
└── "禁止事项请参考 → docs/dont-do.md"

平时只加载路径索引，需要时再加载具体内容——这就像一本书的目录，你不需要把整本书背下来，知道去哪里查就行。

类比：记忆层就是给 AI 挂了一个工牌——上面写着：你是谁、你在做什么项目、你必须遵守什么规则。不管任务进行到哪一步，看一眼工牌就不会迷失方向。

🔄 反馈层 (Feedback Layer)——让 AI 学会自我纠错

Agent 在执行过程中难免犯错。反馈层的核心机制是：

Agent 写代码
    ↓
自动运行 Lint 检查 → 发现格式问题
自动运行单元测试 → 发现逻辑错误
    ↓
将错误信息加入上下文
    ↓
Agent 在下一轮循环中自动修复
    ↓
再次运行检查 → 通过 ✅

这套"校验 → 回传错误 → 自动修复"的闭环能力，就构成了反馈层。

反馈层让 AI 从"一次性输出"变成了"迭代改进"——就像真正的开发者一样，写完代码会跑测试，测试不过会改 bug，改完再测，直到全部通过。

类比：反馈层就是给 AI 配了一个 质检员（Lint + 测试）。每次交活，质检员会检查，不合格就打回去重做，合格才放行。

🎯 编排层 (Orchestration Layer)——给 AI 一个"项目经理"

如果 Agent 缺乏全局规划和清晰的结束目标，很容易出现两种问题：

跑偏：做着做着忘了最初要做什么
死循环：在某个问题上反复尝试，永远无法跳出

编排层的职责：

大任务："开发一个用户登录功能"
         ↓
    ┌─── 编排层拆解 ───┐
    ↓         ↓         ↓
 子任务1    子任务2    子任务3
 设计API    写前端     写后端
 [明确标准] [明确标准] [明确标准]
    ↓         ↓         ↓
 Agent执行  Agent执行  Agent执行
    ↓         ↓         ↓
    └─── 全流程管控 ───┘
         ↓
    交付验收 ✅

编排层以 全局规划 为核心：

将大任务拆解为多个 有明确执行标准的子任务
按规划 驱动 Agent 分步执行
进行 全流程管控，确保每步都朝着最终目标推进
在关键节点进行 检查和决策

类比：编排层就是一个 项目经理。他不亲自写代码，但他拆任务、排优先级、盯进度、做验收。没有他，一群程序员（Agent 循环）可能各干各的，最后拼不到一起。

3.5 驾驭工程解决了什么？

一句话总结：驾驭工程解决了 Agent 长任务中失控、跑偏、无法交付 的问题——通过执行、记忆、反馈、编排四层能力，让大模型持续按规范执行任务并最终交付。

如果说提示词工程教你 怎么说话，上下文工程教你 怎么备课，那驾驭工程就是教你 怎么管理一个团队——让每个人（每轮循环）都知道自己该做什么、做完了怎么检查、出了问题向谁汇报。

四、驾驭工程的落地与实践

4.1 轻量级落地——写好你的规则文件

以原生支持驾驭工程四层能力的 Claude Code 为例，最轻量的做法就是直接在规则文件（CLAUDE.md）里把三件事写清楚：

# CLAUDE.md 示例

## 项目背景
这是一个 React + TypeScript 的电商项目，使用 Next.js 14...

## 开发规范（希望 AI 做/不做的事）
- ✅ 使用函数式组件和 Hooks
- ✅ 所有函数必须有 TypeScript 类型注解
- ❌ 不要使用 class 组件
- ❌ 不要修改 package.json 除非被明确要求

## 质量保障（做完后要跑的检查）
- 运行 `npm run lint` 通过
- 运行 `npm test` 所有测试通过
- 运行 `npm run type-check` 类型检查通过

仅仅这样一个简单的文件，就已经涵盖了：

记忆层：项目背景和规范随时注入
反馈层：定义了自动验证的标准
编排层（部分）：指导了执行方向

4.2 进阶落地——SDD（规范驱动开发）

SDD（Spec-Driven Development，规范驱动开发） 是驾驭工程更系统化的落地方式。

以 Spec Kit 等扩展插件为例，它将开发流程拆分为多个阶段：

阶段 1：需求分析
├── 根据项目现状分析需求
├── 生成约束文件（明确需求边界）
└── ✅ 产出：需求规范文档

阶段 2：方案设计
├── 制定具体开发计划
├── 拆解为可执行的子任务
└── ✅ 产出：开发计划文档

阶段 3：编码实现
├── 按计划逐步修改代码
├── 每步都运行测试验证
└── ✅ 产出：代码变更

阶段 4：质量验收
├── 运行完整测试套件
├── 代码审查和规范检查
└── ✅ 产出：交付确认

在每个阶段都可能更新规则文件，从而保证每一阶段注入上下文的都是与当前阶段最相关的核心信息。

这种"规范驱动开发"，本质上就是驾驭工程的系统化落地。

4.3 对行业生态的影响

有了驾驭工程之后，程序员的工作内容正在发生根本性转变：

传统模式：
    程序员 → 写代码 → 调试 → 测试 → 交付

AI 时代：
    程序员 → 写规则(Rules) → 写技能(Skills) → 监督 AI 执行 → 验收交付

规则 (Rules)：告诉 AI 项目的约束和规范（记忆层）
技能 (Skills)：教 AI 完成特定类型任务的方法（执行层 + 编排层）

🤣 行业玩笑：那些拿了 N+1 离职的同事其实从未离开——他们只是变成了 Skill，在系统中默默陪伴大家。

（意思是：资深工程师的经验和知识被编码成规则和技能文件，即使人离开了，他的"专业能力"依然在系统中持续发挥作用。）

五、三层工程的关系总结

5.1 演进关系

提示词工程                     上下文工程                    驾驭工程
(Prompt Engineering)          (Context Engineering)        (Harness Engineering)
      │                              │                           │
  解决什么？                     解决什么？                  解决什么？
  AI 无引导乱说话                信息过多窗口有限              长任务失控跑偏
      │                              │                           │
  怎么做？                       怎么做？                    怎么做？
  写好提示词                   召回+压缩+组装                执行+记忆+反馈+编排
      │                              │                           │
  类比                          类比                          类比
  怎么下指令                    怎么备课                     怎么管团队

5.2 包含关系

┌──────────────────────────────────────────────────────┐
│                  驾驭工程                              │
│  ┌────────────────────────────────────────────────┐  │
│  │              上下文工程                          │  │
│  │  ┌──────────────────────────────────────────┐  │  │
│  │  │          提示词工程                        │  │  │
│  │  │                                          │  │  │
│  │  │  "请用 Python 实现快速排序..."             │  │  │
│  │  │                                          │  │  │
│  │  └──────────────────────────────────────────┘  │  │
│  │                                                │  │
│  │  + RAG 召回 + 压缩 + 组装                       │  │
│  │                                                │  │
│  └────────────────────────────────────────────────┘  │
│                                                      │
│  + 执行层 + 记忆层 + 反馈层 + 编排层                    │
│                                                      │
└──────────────────────────────────────────────────────┘

5.3 一句话核心总结

层级	核心目标	一句话
🗣️ 提示词工程	让 AI 理解需求	让大模型明白你的具体需求和输出标准
📚 上下文工程	让 AI 拥有知识	给大模型注入精准有效的上下文
🏗️ 驾驭工程	让 AI 完成任务	让大模型持续按规范执行任务并最终交付

六、写给实践者的建议

6.1 如果你是 AI 工具的使用者

写好提示词：别只说"帮我改 bug"，要说清楚背景、约束和期望
管理上下文：对话太长就开新会话，主动 /compact 压缩上下文
用好规则文件：花 30 分钟写一份 CLAUDE.md，能节省几小时的反复沟通
拆解大任务：不要让 AI 一口气做完所有事，分步执行效果更好

6.2 如果你是 AI 应用的开发者

设计上下文策略：你的 RAG 准确吗？压缩丢失关键信息了吗？
构建反馈闭环：AI 执行后有验证机制吗？错误能自动回传吗？
实现编排逻辑：复杂任务有拆解和规划吗？有明确的结束条件吗？
持续优化记忆：核心信息是否在每轮对话中都被注入？规则文件是否易于维护？

6.3 如果你是团队管理者

建立团队级 Rules：将团队的最佳实践编码成规则文件，让 AI 帮每个人遵守
积累 Skills 资产：将重复性工作封装成 Skill，新人来了也能立刻上手
关注上下文质量：工具选型时，不只看模型参数大小，更要看上下文工程做得好不好

📖 术语速查表

术语	英文	含义
大模型	LLM (Large Language Model)	基于海量数据训练的大规模语言模型
提示词	Prompt	输入给模型的文本指令
上下文	Context	模型处理的所有输入信息总和
上下文窗口	Context Window	模型一次能处理的信息量上限
上下文劣化	Context Degradation	信息压缩/丢弃导致的理解偏差
RAG	Retrieval-Augmented Generation	检索增强生成，从外部知识库召回信息
Agent	Agent / 智能体	能自主执行任务的 AI 系统
ReAct	Reasoning + Acting	思考与行动交替进行的 Agent 机制
MCP	Model Context Protocol	模型上下文协议，连接外部工具的标准
SDD	Spec-Driven Development	规范驱动开发
Harness	Harness / 驾驭	包裹大模型的工程外壳
Skill	Skill / 技能	封装特定能力的可复用模块