Loop Engineering 的演进：从 Prompt 到自主循环
这几个概念可以放在同一条线上看：AI 应用，尤其是 AI Agent，从能演示，到能放进真实项目里跑，中间经历了几次工程重心的变化。
它们不是谁替代谁的关系，更像一层套一层：
- Prompt Engineering 解决"怎么问"，让模型更容易理解任务。
- Context Engineering 解决"看什么"，让模型拿到足够的背景信息。
- Harness Engineering 解决"怎么用"，让 Agent 能在约束里调用工具、执行任务。
- Loop Engineering 解决"怎么持续干"，让系统能自己规划、执行、检查和修正。
先用一张表把差别放清楚：
| 工程范式 | 兴起时间 | 关注点 | 要解决的问题 | 常见技术或组件 |
|---|---|---|---|---|
| Prompt Engineering | ~2022 年 | 单次交互的输入指令 | 怎么写 Prompt，模型才更容易理解意图并按要求输出 | 角色设定、思维链、少样本示例、输出格式约束 |
| Context Engineering | ~2025 年 | 上下文信息的组织与检索 | 怎么给模型提供正确、相关的背景信息，比如知识库和历史记录 | RAG、向量数据库、上下文压缩、长期记忆 |
| Harness Engineering | 2026 年初 | 系统运行的框架与约束 | 怎么给 AI Agent 搭一个可控、可观测、安全的运行环境 | 工具调用、权限控制、状态管理、错误重试、安全护栏、可观测性 |
| Loop Engineering | 2026 年中 | 持续自主的工作循环 | 怎么让 Agent 自己规划、执行、检查、修正，持续逼近复杂目标 | 自动化触发器、工作树隔离、技能库、子 Agent 协同、跨会话记忆 |
下面分阶段看。
L1: Prompt Engineering，先把"怎么问"讲清楚
这是 AI 应用最早、也最基础的一层。
它的思路很直接：模型本来就有一定能力，问题是你怎么把任务说清楚。一个含糊的 Prompt，通常会换来一个含糊的回答；一个有角色、目标、格式和限制的 Prompt，模型就更容易给出可用结果。
比如你不只是问：
帮我写个介绍。
而是问：
请用面向企业 CTO 的语气，写一段 300 字以内的产品介绍，重点突出安全，避免营销腔。
这就是 Prompt Engineering 在做的事。
- 要解决的问题：怎么问，AI 才更容易答对。
- 常见方法：明确角色、任务、输出格式、限制条件和示例。
- 适合场景：边界清楚的单次任务，比如文案、总结、翻译。
- 局限：一旦任务需要多步推理、外部工具、大量背景知识，只改 Prompt 就不够了。
L2: Context Engineering，重点变成"给它看什么"
后来大家发现，模型回答得好不好，不只看 Prompt 写得怎么样，还看它拿到了什么信息。
尤其是在 RAG 普及、上下文窗口变大之后，很多问题不再是"模型会不会"，而是"模型有没有看到该看的材料"。比如让它修一个代码库里的 bug，如果不给相关文件、调用链、报错信息，它只能猜。
Context Engineering 做的就是这件事：从企业知识库、历史记录、代码库等来源里，找出和当前任务有关的内容，压缩、整理，然后放进模型上下文里。
可以把它理解成一个减少混乱的过程。人类的需求常常是零散的，系统要把这些信息整理成模型能用的输入。
- 要解决的问题：给 AI 看什么，它才更容易做对。
- 常见方法：RAG、向量检索、上下文压缩、长期记忆。
- 适合场景：需要背景知识的任务，比如代码库 bug 修复、长文档分析、企业知识问答。
- 局限：它能让模型"知道更多"，但不能保证 Agent 执行时不出错、不跑偏。
L3: Harness Engineering，让 Agent 能可靠执行
当 AI Agent 开始调用工具、改文件、访问外部系统时，问题就变了。
这时候不能只关心模型会不会回答，还要关心它怎么执行、出错后怎么办、能不能追踪、有没有权限边界。Harness 可以理解成包在模型外面的一层运行框架，它负责把 Agent 放进一个更可控的环境里。
如果说 Prompt 是教它怎么说，Context 是给它看材料，那么 Harness 就是在管它怎么动手。
- 要解决的问题：怎么让 AI Agent 在复杂系统里安全、稳定地执行任务。
- 常见做法：工具调用管理、任务状态持久化、权限控制、错误恢复、审计日志。
- 本质：它不是某个单独功能，而是一套 Agent 运行框架的工程方法。
这一层很重要，因为很多 Agent 的失败不是"不会想"，而是执行过程没有边界：工具乱调、状态丢失、错误不处理，最后结果就不可控。
L4: Loop Engineering，让系统持续自主工作
Loop Engineering 是更进一步的方向。
这里的重点不是让开发者一步一步提示 Agent，而是设计一个能自己跑起来的循环。Agent 在循环里完成规划、执行、检查、修正，然后继续下一轮，直到逐渐接近目标。
开发者的角色也会变化。以前更像是在写 Prompt，现在更像是在设计工作流和检查点：什么时候启动任务，怎么隔离工作空间，谁来检查结果，失败后怎么重试，哪些经验要沉淀成技能。
常见组件包括：
- 自动化触发器：按时间或事件启动任务。
- 工作树隔离：给不同任务单独的工作空间，减少冲突。
- 技能库：沉淀项目规范、踩坑经验和固定流程。
- 子 Agent 协同：让不同 Agent 分工，比如一个写代码，另一个负责检查，避免自己给自己打分。
- 外部连接器：通过 MCP 等协议连接外部工具。
这也是 Loop Engineering 和前几层最大的区别。它关注的不是单次回答，也不是单次执行，而是一个持续运行的系统。
小结
从 Prompt 到 Loop，AI 应用的工程重点一直在往外扩。
一开始，我们关心怎么把问题问清楚。后来发现，模型还需要看见正确的上下文。再往后，Agent 不只是回答问题，还要调用工具、执行任务，所以需要 Harness 来提供运行边界。到了 Loop Engineering，重点变成设计一个能持续运转的自主循环。
这几层不是替代关系。Loop 需要 Harness，Harness 需要 Context，Context 也离不开 Prompt。外层想跑得稳，内层就不能太松。
所以可以简单记成一句话：
Prompt 负责把话问清楚，Context 负责把材料给够，Harness 负责把执行管住，Loop 负责让系统自己一轮一轮干下去。