AI 工程的四层进化：从 Prompt 到 Loop
2026/6/18大约 10 分钟
每往上一层，你操心的东西就大一号。
从「一句话」（Prompt）
→ 到「一个窗口」（Context）
→ 再到「一次运行」（Harness）
→ 最后到「一整套自动跑的循环」（Loop）。
这就是 AI 工程的四层进化。
全景图
┌─────────────────────────────────────────────────────────┐
│ AI 工程的四层进化 │
├─────────────────────────────────────────────────────────┤
│ │
│ 层级 关注范围 核心问题 │
│ │
│ ┌─────────────────────────────────────────────┐ │
│ │ Prompt Engineering 单次提问 我该说什么？ │ │
│ │ (一句话) │ │
│ └──────────────────────┬──────────────────────┘ │
│ ↓ 扩大 │
│ ┌─────────────────────────────────────────────┐ │
│ │ Context Engineering 一次会话 窗口里放什么？│ │
│ │ (一个窗口) │ │
│ └──────────────────────┬──────────────────────┘ │
│ ↓ 扩大 │
│ ┌─────────────────────────────────────────────┐ │
│ │ Harness Engineering 单次任务 给什么工具？ │ │
│ │ (一次运行) │ │
│ └──────────────────────┬──────────────────────┘ │
│ ↓ 扩大 │
│ ┌─────────────────────────────────────────────┐ │
│ │ Loop Engineering 自动化迭代 怎么自己跑？ │ │
│ │ (一整套循环) │ │
│ └─────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘第一层：Prompt Engineering（一句话）
核心定义
最基础、最微观的层面。
关注的是单次提问的质量：指令是否清晰、格式是否恰当、是否包含必要约束。
核心问题
「我该告诉模型什么？」
即内容设计。
关键要素
1. 指令清晰度
- 任务描述是否明确
- 输出格式是否指定
- 约束条件是否列出
2. 上下文充分性
- 是否提供了足够的背景信息
- 是否包含了必要的示例
- 是否定义了角色和语气
3. 约束精确性
- 长度限制
- 格式要求
- 禁止事项
典型对比
差的 Prompt：
帮我写一篇文章好的 Prompt：
帮我写一篇关于 RAG 的技术博客文章。
要求：
- 面向有基础的开发者
- 1500-2000 字
- 包含架构图描述
- 包含代码示例
- 语气：专业但不枯燥
结构：
1. 问题引入
2. RAG 核心概念
3. 架构详解
4. 代码实战
5. 总结这一层的技能
- 指令设计
- Few-shot 示例
- 角色扮演
- 格式约束
- Chain-of-Thought 提示
局限性
Prompt 只管「这一次提问」。
它不管：
- 之前的对话历史
- 检索到的外部知识
- 模型能调用什么工具
- 任务是否需要多轮迭代
要解决这些问题，需要进入第二层。
第二层：Context Engineering（一个窗口）
核心定义
提升到对话窗口/会话级别。
管理的是当前轮次中送入模型的所有信息，包括历史记录、检索到的文档、摘要、临时清除的内容等。
核心问题
「这一刻窗口里放什么？」
即信息筛选与组织。
关键要素
1. 历史管理
- 保留多少轮对话
- 哪些消息需要摘要
- 哪些消息可以删除
2. 检索注入
- RAG 检索到的文档
- 向量搜索结果
- 知识图谱查询
3. 信息优先级
- 哪些信息放最前面
- 哪些信息放最后面
- 哪些信息可以省略
4. 窗口优化
- Token 预算分配
- 信息压缩
- 动态裁剪
典型场景
场景一：长对话的上下文管理
[系统消息] 你是一个编程助手
[第 1-10 轮] 用户讨论了 React 项目的搭建"
→ 摘要："用户正在搭建一个 React + TypeScript 项目，
使用 Vite 构建，已配置 Tailwind CSS"
[第 11-20 轮] 用户讨论了状态管理
→ 摘要："用户选择了 Zustand 作为状态管理库，
讨论了与 Redux 的对比"
[当前轮] 用户问："怎么实现一个购物车功能？"
→ 检索：注入相关的 Zustand 购物车实现文档
→ 保留：最近 3 轮对话原文场景二：RAG 的上下文构建
用户提问："Zustand 怎么处理异步操作？"
窗口构建：
┌──────────────────────────────────────┐
│ [系统消息] 编程助手角色定义 │
│ [摘要] 之前讨论的 React 项目背景 │
│ [最近对话] 最近 3 轮原文 │
│ [检索文档] Zustand 异步文档 Top 5 │
│ [检索文档] Zustand middleware 文档 │
│ [当前问题] "Zustand 怎么处理异步？" │
└──────────────────────────────────────┘每一个区块的取舍，都是 Context Engineering。
这一层的技能
- 对话摘要策略
- RAG 检索与重排
- Token 预算管理
- 信息优先级排序
- 上下文窗口压缩
- Sliding Window / 摘要链
局限性
Context 只管「模型知道什么」。
它不管：
- 模型能不能执行代码
- 模型能不能调用外部 API
- 模型能不能读写文件
- 任务完成后如何终止
要解决这些问题，需要进入第三层。
第三层：Harness Engineering（一次运行）
核心定义
上升到单次任务执行的层面。
负责给模型配备外部能力（工具、API、函数调用），并定义允许的动作和终止条件（什么算完成）。
核心问题
「给哪些工具、允许哪些动作、什么算完成？」
即运行环境的配置。
关键要素
1. 工具配置
- 代码执行沙箱
- 文件读写权限
- Web 搜索能力
- API 调用接口
2. 权限边界
- 允许访问哪些资源
- 禁止执行哪些操作
- 敏感操作需要确认
3. 终止条件
- 任务完成的标志
- 最大迭代次数
- 超时限制
- 错误处理策略
4. 安全机制
- 输出验证
- 操作审计
- 回滚机制
典型架构
┌─────────────────────────────────────────────────┐
│ Harness 架构 │
├─────────────────────────────────────────────────┤
│ │
│ ┌───────────┐ ┌───────────┐ │
│ │ 用户 │───→│ Harness │ │
│ │ 请求 │ │ 控制器 │ │
│ └───────────┘ └─────┬─────┘ │
│ │ │
│ ┌────┴────┐ │
│ │ LLM │ │
│ │ 推理 │ │
│ └────┬────┘ │
│ │ │
│ ┌──────────┼──────────┐ │
│ ↓ ↓ ↓ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ 代码执行 │ │ 文件系统 │ │ Web 搜索│ │
│ │ 沙箱 │ │ 读写 │ │ API │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ │
│ 终止条件： │
│ · 任务完成 ✓ │
│ · 最大迭代次数（20 次） │
│ · 超时（5 分钟） │
│ · 用户中断 │
│ │
└─────────────────────────────────────────────────┘典型案例：Claude Code 的 Harness
Harness 配置：
├── 工具
│ ├── bash（执行 shell 命令）
│ ├── read/write（文件读写）
│ ├── web_search（网络搜索）
│ └── web_fetch（抓取网页）
├── 权限
│ ├── 允许：项目目录内读写
│ ├── 允许：执行非破坏性命令
│ ├── 禁止：rm -rf
│ └── 确认：git push
├── 终止条件
│ ├── 任务完成（代码写完且测试通过）
│ ├── 最大 50 次工具调用
│ └── 用户 Ctrl+C
└── 安全
├── 输出审查
├── 操作日志
└── 可回滚这一层的技能
- 工具设计与 API 封装
- 沙箱隔离与权限控制
- 终止条件设计
- 错误处理与重试
- 安全审计
- 资源限制（Token/时间/次数）
局限性
Harness 只管「一次任务执行」。
它不管：
- 任务之间的衔接
- 长期目标的追踪
- 失败后的自动重试
- 定时执行和调度
要解决这些问题，需要进入第四层。
第四层：Loop Engineering（一整套循环）
核心定义
最高层，关注自动化迭代。
在 Harness 的基础上，设计循环机制，让模型能够自主地反复执行任务、检查结果、调整策略，直到达成目标。
核心问题
「怎么让它自己一遍遍跑起来？」
即调度与循环控制。
关键要素
1. 循环设计
- 循环入口条件
- 循环退出条件
- 循环体（每轮做什么）
- 循环间隔
2. 状态管理
- 上一次结果如何传递给下一次
- 失败状态如何恢复
- 进度如何持久化
3. 自适应策略
- 根据结果调整方向
- 根据错误调整策略
- 根据反馈优化参数
4. 编排模式
- Pipeline（串行流水线）
- MapReduce（并行 + 汇聚）
- Checkpoint-Resume（断点续传）
- Event-Driven（事件驱动）
四种经典 Loop 模式
模式一：Pipeline（串行流水线）
任务 A → 任务 B → 任务 C → 任务 D → 输出
案例：自动化博客生产
选题 → 调研 → 写作 → 配图 → 发布模式二：MapReduce（并行 + 汇聚）
┌→ 子任务 1 ─┐
├→ 子任务 2 ─┤
任务 ┼→ 子任务 3 ─┼→ 汇聚 → 输出
├→ 子任务 4 ─┤
└→ 子任务 5 ─┘
案例：批量代码审查
扫描 N 个 PR → 各自审查 → 汇总报告模式三：Checkpoint-Resume（断点续传）
任务步骤 1 ✓ → 步骤 2 ✓ → [崩溃]
↓
重启后恢复
↓
步骤 3 ✓ → 步骤 4 ✓ → 完成
案例：长时间运行的迁移任务
每完成一步保存进度，崩溃后从断点恢复模式四：Event-Driven（事件驱动）
事件监听 → 触发任务 → 执行 → 等待下一个事件
案例：自动化运维
监控告警 → 自动诊断 → 自动修复 → 验证 → 记录典型案例：自动代码审查 Loop
┌─────────────────────────────────────────────────┐
│ 自动代码审查 Loop │
├─────────────────────────────────────────────────┤
│ │
│ [触发] PR 创建事件 │
│ ↓ │
│ [步骤 1] 拉取 PR 代码 │
│ ↓ │
│ [步骤 2] 运行静态分析（Harness） │
│ ↓ │
│ [步骤 3] AI 审查（Context + Prompt） │
│ ↓ │
│ [步骤 4] 生成审查报告 │
│ ↓ │
│ [步骤 5] 发布到 PR 评论 │
│ ↓ │
│ [步骤 6] 如果有严重问题 → 请求修改 │
│ 否则 → 标记 Approved │
│ ↓ │
│ [等待] 下一个 PR 事件 │
│ │
└─────────────────────────────────────────────────┘这一层的技能
- 循环设计与退出策略
- 状态持久化与恢复
- 任务编排（Pipeline / MapReduce / DAG）
- 调度系统（Cron / Event-Driven）
- 监控与告警
- 自适应与反馈闭环
四层对比总览
| 维度 | Prompt | Context | Harness | Loop |
|---|---|---|---|---|
| 关注范围 | 单次提问 | 一次会话 | 单次任务 | 自动化迭代 |
| 核心问题 | 我该说什么？ | 窗口里放什么？ | 给什么工具？ | 怎么自己跑？ |
| 时间跨度 | 秒级 | 分钟级 | 小时级 | 天/周级 |
| 复杂度 | 低 | 中 | 高 | 很高 |
| 可控性 | 最强 | 强 | 中 | 弱（需要监控） |
| 自主性 | 无 | 无 | 中 | 高 |
| 类比 | 说一句话 | 开一次会 | 做一个项目 | 运营一个部门 |
进化路径
从 Prompt 到 Context
关键转变：从「怎么说」到「提供什么信息」。
- Prompt 关注表达方式
- Context 关注信息完整度
- 升级方式：引入 RAG、对话摘要、记忆系统
从 Context 到 Harness
关键转变：从「知道什么」到「能做什么」。
- Context 关注模型的输入
- Harness 关注模型的能力边界
- 升级方式：引入工具、API、沙箱、权限控制
从 Harness 到 Loop
关键转变：从「做一次」到「持续做」。
- Harness 关注单次任务执行
- Loop 关注任务的自动化迭代
- 升级方式：引入调度、状态管理、编排模式、监控
不同角色的关注层级
内容创作者 / 营销人员
主要关注：Prompt + Context
- Prompt：如何让 AI 写出好文案
- Context：如何提供足够的品牌背景和素材
应用开发者
主要关注：Context + Harness
- Context：如何构建有效的 RAG 管道
- Harness：如何给模型配备合适的工具
AI 平台工程师
主要关注：Harness + Loop
- Harness：如何设计安全的执行环境
- Loop：如何实现可靠的自动化流水线
AI 产品经理
需要理解全部四层
- 判断产品需要哪一层的能力
- 评估每层的投入产出比
- 设计用户体验流程
实践建议
不要跳层
常见错误： 在 Prompt 都没做好的情况下，直接跳到 Harness。
正确顺序：
- 先把 Prompt 做到 80 分
- 再用 Context 补充信息
- 然后用 Harness 扩展能力
- 最后用 Loop 实现自动化
每层投入比例
对于个人开发者：
- Prompt：40%
- Context：30%
- Harness：20%
- Loop：10%
对于平台团队：
- Prompt：10%
- Context：20%
- Harness：30%
- Loop：40%
工具选择
Prompt 层：
- Claude / GPT / Gemini
- Prompt 管理工具（LangSmith、PromptHub）
Context 层：
- RAG 框架（LangChain、LlamaIndex）
- 向量数据库（Pinecone、Weaviate）
- 记忆系统（Mem0）
Harness 层：
- Agent 框架（Claude Code、Cursor、Cline）
- 工具平台（MCP）
- 沙箱环境（E2B、Daytona）
Loop 层：
- 工作流引擎（Temporal、Inngest）
- 调度系统（Cron、GitHub Actions）
- 监控平台（LangSmith、Langfuse）
关键洞察
AI 工程的四层进化，本质上是「抽象层次」的不断提升：
Prompt — 关注「一句话」的内容
Context — 关注「一个窗口」的信息
Harness — 关注「一次运行」的能力
Loop — 关注「一整套循环」的自动化每往上一层：
- 你操心的东西就大一号
- 你需要控制的细节就少一层
- 系统的自主性就强一分
- 对基础设施的要求就高一档
收尾金句：
- Prompt Engineering：我该告诉模型什么？
- Context Engineering：这一刻窗口里放什么？
- Harness Engineering：给哪些工具、允许哪些动作、什么算完成？
- Loop Engineering：怎么让它自己一遍遍跑起来？
四个层级，四种思维。
从「说对话」到「搭系统」，AI 工程的世界，远比写好一个 Prompt 要大得多。
AI 工程的四层进化
从 Prompt 到 Loop