从 Prompt Engineering 到 Loop Engineering：AI 工程的四级进化图谱
一只阿木木约 11 分钟副标题：Karpathy 说英语是最热门的编程语言——三年后，他只说对了一半
引子：一个工程师的三年认知断层
2023年，Andrej Karpathy 说：「最热门的新编程语言是英语。」
所有人觉得他说得对。
「最热门的新编程语言是英语。」——Andrej Karpathy，2023年。三年后，他只说对了一半。从2022年到2026年，AI 开发范式经历了三次转变：Prompt Engineering → Context Engineering → Harness Engineering。
而就在我写这篇文章的2026年6月，第四次转变刚刚发生，名字叫 Loop Engineering。
这篇文章想做一件事：把这四次转变的逻辑讲清楚。不是搬运概念，而是告诉你——每一次转变背后，是什么具体的工程痛点在驱动它，以及你现在站在哪里。
一、为什么会有「进化」？每一层的失败模式
一个让人不舒服的真相是：
每一次工程范式的升级，都不是因为旧方法不好，而是因为旧方法在规模化时暴露了致命缺陷。
每个时代都没有取代上一个。每个时代揭示了上一个是必要的，但还不够充分。
理解这一点，是理解这张图谱的钥匙。
下面这张图，是我们要用整篇文章填充的骨架：
text
时间轴 ──────────────────────────────────────────────►
2022-23 2024-25 2026上半年 2026下半年
│ │ │ │
▼ ▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ L1 │ │ L2 │ │ L3 │ │ L4 │
│ Prompt │ │ Context │ │ Harness │ │ Loop │
│ Engineering │ │ Engineering │ │ Engineering │ │ Engineering │
│ │ │ │ │ │ │ │
│ 优化「如何 │ │ 优化「给 │ │ 优化「Agent │ │ 优化「整个 │
│ 说话」 │ │ 什么信息」 │ │ 的工作环境」│ │ 反馈系统」 │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
失败模式： 失败模式： 失败模式：
同样的问题 噪音淹没信号 孤立任务间
换种说法就坏 上下文焦虑 无法自我校正
二、L1：Prompt Engineering（2022-2023）
它解决了什么？
Phase 1（2022-2023）是 Prompt Engineering 的天下。重点在语言本身。工程师发现，你怎么措辞会显著改变输出质量。AI 工具主要作为智能自动补全，在样板代码和代码片段方面很有用，但需要持续的人工引导。
这个阶段，最聪明的工程师在研究的问题是：怎么和 AI 说话？
Chain-of-Thought、Few-shot、System Prompt——这些都是这个阶段的产物。它们有效，而且今天依然有效。
它在哪里失败了？
等模型更强大了之后，你会发现一件奇怪的事：用同样的提示，给强模型的效果，有时候不如给弱模型的效果好。
因为强模型有能力处理更复杂的任务，但如果你只给它一句提示，它不知道你的项目背景、你的代码风格、你的架构约束。
它在生成通用的正确答案，而不是在解决你的具体问题。
这个痛点催生了 L2。
三、L2：Context Engineering（2024-2025）
它解决了什么？
Phase 2（2024-2025）是 Context Engineering。随着 AI 模型变得更强大，瓶颈从措辞转向了信息。工程师开始精心策划什么进入模型的上下文窗口——包括相关文件、项目规则、架构约束——让 AI 可以针对特定代码库推理，而不是生成通用解决方案。
这个阶段，最重要的一段话来自 Shopify CEO Tobi Lütke，他在公司内部备忘录里写道：
「在你用 Claude 做任何任务之前，你要给它足够的上下文，让 Claude 能够独立完成你的工作。」
Prompt Engineering 告诉模型做什么。Context Engineering 给模型它需要知道的东西。
这也是 RAG（检索增强生成）爆发的阶段。用户发现，与其微调模型，不如在推理时把正确的文档放进上下文窗口。
它在哪里失败了？
Context Engineering 有一个经典的失败模式，我叫它「垃圾进，垃圾出的精致版」。
你精心策划了上下文，但上下文里有一份过时的架构文档。
AI 不会告诉你它过时了。它会非常自信地基于这份过时的文档生成代码。
陈旧的数据血统、未认证的表格、schema 漂移、相互冲突的业务定义进入上下文窗口，产生听起来很可靠的幻觉。Agent 没有犯推理错误——它在对错误输入进行正确推理。这是数据问题，不是模型问题。
还有另一个更致命的问题：
随着上下文窗口填满，模型会「恐慌」并急于完成，以避免空间耗尽；Agent 经常试图一次性解决整个问题，产生一团没有文档的修改。
Context Engineering 的困境在于：你给 Agent 更多信息，但它处理信息的方式依然是一次性的、单向的。 它没有办法验证自己的输出，没有办法在出错时自我纠正。
这个痛点催生了 L3。
四、L3：Harness Engineering（2026上半年）
它解决了什么？
这个概念的提出者是 Mitchell Hashimoto——Terraform 的创始人，Ghostty 的作者。
Harness Engineering 是建立存在于 AI Agent 周围的结构层——它运行的环境、它无法越过的边界、以及当它出错时捕获它的系统。这个术语由 Terraform 的创建者 Mitchell Hashimoto 在2026年初推广。他的核心想法很直接：「每次 Agent 犯错，你不只是告诉它下次做得更好。」
你知道结构化的思维，在 Harness Engineering 里也是核心精神：不是让模型更聪明，而是让失败在结构上不可重复发生。
Harness Engineering 是设计和管理 AI Agent 运行的整个环境的学科。这意味着除了模型本身之外的一切。Martin Fowler 的表述很简洁：「Agent = Model + Harness。」Harness 是运营包装器，决定模型的能力是否转化为可靠的真实世界行为。
Harness Engineering 确保 Agent 能可靠地完成工作。Prompt = 指令；Context = 知识；Harness = 执行系统。这个进化——从语言，到知识，到系统——是自 Transformer 以来应用 AI 中最重要的架构转变。
一个真实的数据点震撼了整个工程界：
2026年3月，LangChain 工程团队在不改变底层模型的情况下，将他们的编码 Agent 从 Terminal Bench 2.0 的第30名提升到了第5名——提升完全通过优化 Harness 实现。
再强调一遍：模型没有变，只是换了 Harness，排名从30提升到5。
同期，OpenAI 的 Codex 团队用 Harness Engineering 原则在五个月内交付了超过100万行生产代码，全部由 AI Agent 编写。
它在哪里失败了？
Harness Engineering 解决了「单任务的可靠性」问题，但它依然有一个根本性的限制：
它是单向的。Agent 执行任务，Harness 捕获错误，但这个过程本身还是需要人来触发。
你写好了 Harness，定义了约束，配置了验证。但谁来决定「下一个任务是什么」？谁来发现「这个函数该被重构了」？谁来决定「现在应该停止了」？
还是你。
Harness 让 Agent 更可靠，但整个系统还没有闭环。
五、L4：Loop Engineering（2026年6月——现在）
它解决了什么？
Loop Engineering 是设计让 AI Agent 在重复循环中运行的系统——行动、观察、决策、重复——而不是每一步手动提示 Agent。你定义一个目标和一个停止条件；循环负责迭代。
用最简洁的语言：
text
Prompt Engineering = 优化你说的话
Context Engineering = 优化 AI 能看到的信息
Harness Engineering = 优化 AI 工作的环境
Loop Engineering = 优化整个系统的反馈机制，让它自己跑起来
这个词的推广者是 Google 工程师 Addy Osmani，他综合了 Anthropic 的 Boris Cherny 和 Peter Steinberger 的观点。杠杆点从单次提示的质量，转移到了生成和验证提示的系统的设计。
四层的关系：不是替代，是叠加
这是最容易被误解的地方。很多人看到「L4 Loop Engineering」就认为前三层过时了。
错误。
你仍然在写提示；你仍然在策划上下文；你仍然在构建 Harness。Loop Engineering 只是让这一切被放入运动状态的那一层。
用一个建筑比喻：
text
Prompt Engineering = 砖块的质量
Context Engineering = 建筑蓝图
Harness Engineering = 建筑规范和安全标准
Loop Engineering = 整栋楼的运营系统（电梯、空调、自动门）
没有好砖块，楼建不起来。没有运营系统，楼只能被动等人使用。
一个完整的 Loop 长什么样？
让我拿一个真实的企业场景做示范：一个监控生产服务健康状态并自动修复的 Agent。
Python
# loop_design.py
# 这不是提示词，这是一个系统设计import subprocess
import json
from anthropic import Anthropic
client = Anthropic()
def check_production_health():
"""状态读取：当前生产环境是否健康？"""
result = subprocess.run(
["pytest", "tests/integration/", "--tb=json", "-q"],
capture_output=True, text=True
)
return {
"passed": result.returncode == 0,
"output": result.stdout,
"errors": result.stderr
}
def write_memory(iteration: int, issue: str, fix: str):
"""记忆持久化：记录这次失败模式，供下次参考"""
with open("LOOP_MEMORY.md", "a") as f:
f.write(f"\n## Iteration {iteration}\n")
f.write(f"**Issue**: {issue}\n")
f.write(f"**Fix Applied**: {fix}\n")
def run_fix_loop(
goal: str,
max_iter: int = 15,
cost_budget_usd: float = 5.0
):
"""
核心 Loop：目标驱动，验证终止，成本受控
这才是 Loop Engineering 的精髓：
不是一段聪明的提示词，而是一个有
目标、验证、记忆、成本控制的完整系统
"""
total_cost = 0.0
for iteration in range(max_iter):
# 1. 读取当前状态
health = check_production_health()
# 2. 验证：是否达成目标？
if health["passed"]:
print(f"✅ Loop 成功，共 {iteration} 次迭代")
return True
# 3. 成本控制：检查预算
if total_cost >= cost_budget_usd:
print(f"⚠️ 已达成本上限 ${cost_budget_usd}，停止循环")
return False
# 4. 读取持久化记忆（这是 Context Engineering 的部分）
try:
with open("LOOP_MEMORY.md", "r") as f:
past_memory = f.read()
except FileNotFoundError:
past_memory = "无历史记录"
# 5. 让 Agent 执行修复（这是 Harness 的边界定义）
response = client.messages.create(
model="claude-opus-4-5",
max_tokens=4096,
system="""你是一个代码修复 Agent。
规则：
- 只修改 src/ 目录下的文件
- 不删除已有测试
- 每次只做最小化修改
- 修改后必须说明你改了什么和为什么""",
messages=[{
"role": "user",
"content": f"""目标：{goal}
当前测试失败信息：
{health['errors'][:2000]}
历史修复记忆：
{past_memory[-1000:]}
请分析失败原因并修复代码。"""
}]
)
fix_description = response.content[0].text
# 6. 记忆持久化
write_memory(
iteration=iteration,
issue=health['errors'][:500],
fix=fix_description[:500]
)
# 7. 成本追踪
total_cost += (response.usage.input_tokens * 0.000003 +
response.usage.output_tokens * 0.000015)
print(f"迭代 {iteration+1}: ${total_cost:.4f} 已消耗")
print(f"⚠️ 达到最大迭代次数 {max_iter}，未能解决问题")
return False
if __name__ == "__main__":
run_fix_loop(
goal="所有集成测试通过，服务健康检查返回200",
max_iter=15,
cost_budget_usd=5.0
)
注意这段代码里有哪些层：
system | L1 Prompt Engineering |
LOOP_MEMORY.mdpast_memory | L2 Context Engineering |
只修改 src/最小化修改 约束 | L3 Harness Engineering |
whilecheck_production_health() + max_iter + cost_budget | L4 Loop Engineering |
四层同时在工作。 没有任何一层是多余的。
六、工程进化的第一性原理：「严谨性的迁移」
读到这里，你可能会有一个感受：这四层的演进，有一种奇怪的规律性。
让我来命名它。这叫做：「Relocating Rigor」——严谨性的迁移。
工程严谨性从未消失。它在移动——从提示词到上下文，从上下文到 Harness。
更精确地说：
text
L1: 严谨性在「一句话里」 → 你每次都要谨慎措辞
L2: 严谨性在「信息质量里」 → 你要维护高质量的知识库
L3: 严谨性在「系统边界里」 → 你要设计可靠的执行环境
L4: 严谨性在「反馈设计里」 → 你要设计可自我校正的循环
每一次迁移，都让单次执行的成本变低，但让系统设计的复杂度上升。
这是好事吗？
是的。因为系统设计的复杂度是一次性的，而单次执行的收益是可重复的。
你花两天设计一个好的 Loop，它可以在接下来的两年里每天自动运行。你花两天写一个完美的 Prompt，只能用一次。
七、预警：L4 不适合所有场景
诚实地说，Loop Engineering 有它的边界。
不是每个任务都应该变成 Loop 的。
适合 Loop 的任务：
有明确的可测量验证条件（测试通过/API 健康/代码覆盖率） 重复性高（每天/每小时运行同类任务） 错误成本可接受（失败了循环，而不是造成不可逆后果）
不适合 Loop 的任务：
需要主观判断（「这个设计好看吗」） 高风险操作（生产数据库写入、发送邮件） 探索性工作（不知道终止条件是什么）
不是所有 Loop 都是平等的。设计糟糕的 Loop 会浪费 token、永远运行，或产生进展的幻觉。
对于高风险操作，你需要在 Loop 里加入「人工审批节点」——Loop 运行到某个检查点，暂停，等待人类确认，然后继续。这是一种「人在回路」的 Loop 设计，比纯自动化 Loop 安全得多，也比纯手动提示高效得多。
八、你现在站在哪里？一个自测框架
根据这四层，我给你一个快速自测：
| L1 | ||
| L2 | ||
| L3 | ||
| L4 早期 |
结语：2026年的进化还没有停止
2026年的关键指标不再是提示词质量——而是 KV 缓存命中率和 Harness 复杂度。
这句话预示着什么？
我认为，L5 已经在路上了。它的名字可能叫「Ecosystem Engineering」——不是设计一个 Loop，而是设计多个 Loop 互相发现、互相调用、互相验证的生态系统。
但那是下一篇文章的主题。
现在，我只想问你一个问题：
你今天写了多少提示词？
其中有多少，可以被替换成一个运行中的 Loop？
从那里开始。
普通人如何用 AI 搭建自己的知识操作系统？
一个程序员出身的知识工作者，公开记录自己如何用 AI 工具搭建个人知识系统、把读过的书和做过的项目变成可复用资产的全过程。
我是【一只阿木木】——公开建造我的 AI 第二大脑。
欢迎加入行动营👇获取更多Obsidian + AI数字大脑实践
我相信：在 AI 时代，每个普通人都该拥有一个自动生长的知识系统
欢迎关注【一只阿木木】🌊