范式跃迁史 —— Prompt→Context→Harness→Loop

2.1 一张贯穿 4 年的演进图

我们先把整章要讲的内容浓缩到一张图：

┌─────────────────┬──────────────────┬──────────────────┬──────────────────┐
│  第一级         │  第二级          │  第三级          │  第四级          │
│  Prompt Eng.    │  Context Eng.    │  Harness Eng.    │  Loop Eng.       │
│  2022 - 2023    │  2023 - 2024     │  2025 - 2026.05  │  2026.06 - 至今  │
├─────────────────┼──────────────────┼──────────────────┼──────────────────┤
│ 优化对象：       │ 优化对象：        │ 优化对象：        │ 优化对象：        │
│ "话术"          │ "信息"           │ "环境"           │ "系统"           │
├─────────────────┼──────────────────┼──────────────────┼──────────────────┤
│ 人是：          │ 人是：            │ 人是：            │ 人是：            │
│ "对话者"        │ "信息整理秘书"   │ "环境搭建包工头" │ "循环系统设计师" │
├─────────────────┼──────────────────┼──────────────────┼──────────────────┤
│ 杠杆：          │ 杠杆：            │ 杠杆：            │ 杠杆：            │
│ 1x              │ 10x              │ 100x             │ 1000x            │
├─────────────────┼──────────────────┼──────────────────┼──────────────────┤
│ 代表工具：      │ 代表工具：        │ 代表工具：        │ 代表工具：        │
│ ChatGPT 基础版  │ LangChain        │ AutoGPT          │ Claude Code      │
│                 │ LlamaIndex       │ Claude Code      │ Loop Routines    │
│                 │                  │ Codex CLI        │ /goal            │
├─────────────────┼──────────────────┼──────────────────┼──────────────────┤
│ 关键问题：      │ 关键问题：        │ 关键问题：        │ 关键问题：        │
│ "怎么问"        │ "喂什么"         │ "在哪跑"         │ "怎么转"         │
└─────────────────┴──────────────────┴──────────────────┴──────────────────┘

四级跳的本质规律是：

优化对象从"模型的输入"（话术/信息）→"模型的工作环境"（环境/系统）→"模型的协作方式"（循环）；人的角色从"对话者"→"信息整理者"→"环境设计师"→"循环架构师"。每一级跳都是上一级跳的"答案"，但同时是下一级跳的"问题"。

下面我们逐级展开。

2.2 第一级：Prompt Engineering（2022-2023）

2.2.1 起源

Prompt Engineering 不是 2023 年 ChatGPT 爆火之后才出现的——它的"祖先"是 2020 年 GPT-3 发布时社区总结的 “prompt 设计技巧”。

但真正把 Prompt Engineering 变成"显学"的是 2022 年 11 月 ChatGPT 发布后：

• 2022.12：公众号、Medium、X 上开始流传"100 个有用的 prompt"
• 2023.01：Reddit r/PromptEngineering 突破 10 万订阅
• 2023.03：OpenAI 推出 “Prompt Engineering Guide” 官方文档
• 2023.06：DAIR.AI 发布 “Prompt Engineering Guide” 仓库
• 2023.09：吴恩达联合 OpenAI 发布 “ChatGPT Prompt Engineering for Developers” 课程

2.2.2 核心思想

Prompt Engineering 的核心假设是：模型本身已经足够强，问题只在于"你怎么问它"。

因此这一阶段的所有方法论都在解决一个事：怎么把单次输入写得更"对"。

经典技巧包括：

• Zero-shot / Few-shot：直接问 vs 给几个例子
• Chain-of-Thought（CoT）：让模型"一步一步想"
• ReAct：让模型交替"思考"和"行动"
• Self-Consistency：多次采样后投票
• Tree of Thought（ToT）：让模型探索多条推理路径

2.2.3 带来的新问题

Prompt Engineering 在原型阶段极强，但在生产环境暴露了三组问题：

问题 1：模型对 prompt 的微小变化极度敏感

Prompt A: "列出这五个城市的天气。"
Prompt B: "请告诉我这五个城市的天气情况。"

这两个 prompt 在 GPT-3.5 上的输出差异极小，但在 GPT-4 上的输出顺序、详细程度、风格可能有显著差异。同一个问题换一种说法就需要重新调 prompt。

问题 2：长 prompt 的边际收益急剧下降

2023 年的研究（Liu et al., “Lost in the Middle”）发现：随着 prompt 长度的增加，模型对 prompt 中部内容的注意力会显著下降。这意味着把 2000 token 的上下文塞进 prompt，模型可能只会认真对待前 500 和后 500 token。

问题 3：跨任务迁移几乎为零

为"代码生成"优化的 prompt，在"代码审查"任务上几乎用不上；为"客户服务"优化的 prompt，在"技术支持"任务上也无法复用。每次面对新任务，都要重新调 prompt。

2.2.4 关键判断

Prompt Engineering 解决了"AI 怎么用"的第一个问题——怎么让单次交互得到好结果。但它把"人"放在了"对话者"的位置上：人要不断地写 prompt、调 prompt、维护 prompt。

Prompt Engineering 时代的人，是"翻译官"——把业务需求翻译成模型能听懂的咒语。

2.3 第二级：Context Engineering（2023-2024）

2.3.1 起源

Context Engineering 作为一个独立概念被正式提出，是在 2024 年。它的标志性事件是：

• 2024.03：Anthropic 在 “Building Effective Agents” 文章中明确区分"prompt"和"context"
• 2024.06：LangChain 团队在 “The Rise of Context Engineering” 博文中正式命名
• 2024.09：Andrej Karpathy 推文：“English is the new programming language. Context is the new codebase.”
• 2024.12：Anthropic 发布《Effective Context Engineering for AI Agents》长文

Context Engineering 关注的核心问题从"怎么问"转向了**“喂什么”**——模型应该看到哪些信息、这些信息如何组织、什么时候更新。

2.3.2 核心思想

Context Engineering 把 prompt 分为多个层次：

System Prompt（系统提示）       —— 稳定不变，定义模型角色
Domain Context（领域上下文）    —— 业务规则、API 文档、架构图
Task Context（任务上下文）      —— 当前任务、用户需求、历史对话
Working Memory（工作记忆）     —— 短期状态、中间结果
Long-term Memory（长期记忆）   —— 跨 session 持久化的知识

Context Engineering 解决的核心问题不是"话术写得多漂亮"，而是"模型看到的信息是否足够、是否相关、是否最新"。

经典方法包括：

• RAG（Retrieval-Augmented Generation）：在生成前从外部知识库检索相关内容
• Memory Systems：让模型有跨 session 的记忆（短期 + 长期）
• Tool Use：让模型通过工具主动获取信息
• Context Compression：用摘要、向量检索等方式压缩上下文

2.3.3 框架爆发

2023-2024 是"Context Engineering 框架"爆发的两年：

这些框架的共同点是：人在"信息整理秘书"的位置上——负责把外部信息整理成模型可消费的格式。

2.3.4 带来的新问题

Context Engineering 解决了"喂什么"的问题，但又引入了新问题：

问题 1：上下文窗口的"无限幻觉"

模型支持 1M token 上下文，不意味着能"用好" 1M token。Chroma 的研究显示，当上下文超过 ~32K token 后，模型在复杂推理任务上的表现开始持续下降——这就是 “Context Rot”。

问题 2：信息过载

把所有相关信息都塞进上下文，反而会让模型"挑花眼"。检索出了 20 篇相关文档，但只有 3 篇是关键信息——模型会"被无关信息误导"。

问题 3：跨任务的"上下文漂移"

为任务 A 精心组织的上下文，在任务 B 上可能完全不适用。Context Engineering 让"上下文"变成了一项需要持续维护的工程资产。

2.3.5 关键判断

Context Engineering 解决了"信息怎么喂"的问题，让人从"翻译官"升级为"信息整理秘书"。但它把人困在了"信息管理"的工作里——整理信息本身不会让 AI 跑得更好，它只是让 AI 不那么糊涂。

Context Engineering 时代的人，是"图书管理员"——负责把信息整理好，让 AI 能找到它。

2.4 第三级：Harness Engineering（2025-2026.05）

2.4.1 起源

Harness Engineering 的正式命名有两条线索：

• Anthropic 线索（概念源头）：2025.11《Effective Harnesses for Long-Running Agents》、2026.03《Harness Design for Long-Running Apps》——Harness 概念的雏形
• OpenAI 线索（命名推广）：2026.02 OpenAI 发布《Harness engineering: leveraging Codex in an agent-first world》，把 Harness Engineering 升格为完整工程方法论

中间还发生了关键事件：

• 2026.02.05：Mitchell Hashimoto（HashiCorp 联合创始人）在个人博客发布博文，正式使用 “Harness Engineering” 这一术语
• 2026.02 中旬：Hacker News 上 Harness Engineering 讨论帖冲到 286 赞、~200 评论
• 2026.05：Harness Engineering 被 Gartner 2026Q2 报告列入"主流工程实践"

2.4.2 核心思想

Harness Engineering 把优化对象从"信息"升级为"环境"——Agent 不再在"裸模型 + 信息"上工作，而是在一个为它设计好的运行环境中工作。

Harness 的核心理念：

不要让 AI 在野生环境里工作，要给它一个设计好的"工作场"。

Harness 的五大组成（来自 Anthropic/OpenAI 共识）：

1. Context Manager：管理 AI 可见的信息（CLAUDE.md、AGENTS.md 等）
2. Constraint Layer：约束 AI 的行为（架构约束、代码约束、安全约束）
3. Orchestration Layer：组织 AI 的执行（Sub-agent、Skill、Loop）
4. Verification Layer：验证 AI 的输出（测试、Lint、形式化验证）
5. Observability Layer：观测 AI 的行为（Trace、Token 成本、行为画像）

2.4.3 关键证据

OpenAI 在 2026.02 公开的实验数据：

LangChain 团队的内部实验（2026.04）：

• 仅改 Harness（不换模型），deepagents-cli 在 Terminal Bench 上的得分从 52.8 提升到 66.5（+13.7 分）
• 提升来源：上下文管理 + 约束层 + 验证层
• 启示：好的 Harness 能让中等模型表现得像高级模型

2.4.4 带来的新问题

Harness Engineering 解决了"在哪跑"的问题，但带来了新问题：

问题 1：Harness 本身需要设计

Harness 不是"装上就管用"的工具——它需要根据项目特点定制。Harness 的设计本身就需要专业能力。

问题 2：Harness 会"老化"

项目演进过程中，Harness 也要持续更新——Spec 会过时、Lint 规则会失效、测试会覆盖不全。

问题 3：Harness 的复杂度爆炸

当 Harness 组件超过 5 个，组件之间的相互依赖会急剧上升。Anthropic 内部多次反思"Harness 本身已经变成了一个软件系统，需要专门的工程师维护"。

2.4.5 关键判断

Harness Engineering 解决了"在哪跑"的问题，让人从"图书管理员"升级为"环境搭建包工头"。但它有一个根本限制：它假设"人 + Harness + Agent"是一个稳定三角，没有考虑"Agent 自主优化 Harness"的可能性。

Harness Engineering 时代的人，是"包工头"——负责把 AI 工作场搭好。

2.5 第四级：Loop Engineering（2026.06 - 至今）

2.5.1 起源

Loop Engineering 作为一个正式命名的概念，是在 2026 年 6 月由 Google Chrome 工程负责人 Addy Osmani 推广的。它不是从零开始的发明，而是对 2025-2026 年一系列实践的概念化命名：

• 2025.05：Boris Cherny 在 Anthropic 内部使用 “loop” 概念
• 2026.04：Anthropic Claude Code 发布 /loop 命令
• 2026.05：Sequoia AI Ascent 2026，Boris Cherny 公开演讲 “I have loops that are running. They’re the ones that are prompting Claude.”
• 2026.06：OpenClaw 创始人 Peter Steinberger 公开呼应 “你应该设计一套循环机制”
• 2026.06.08：Addy Osmani 在 X、Substack、GitHub repo 上系统化"Loop Engineering"概念
• 2026.06.16：Loop Engineering 概念被 CSDN 等中文社区广泛传播

2.5.2 核心思想

Loop Engineering 把优化对象从"环境"升级为"系统"——不再有"人 + Harness + Agent"三角，而是 Agent 自己组成的"循环系统"。

Loop 的核心理念（来自 Addy Osmani + Boris Cherny + Peter Steinberger 共识）：

不要给 Agent 写 prompt，要写"让 Agent 自主提示自己"的循环。

Loop 的五大组件：

┌─────────────────────────────────────────────┐
│              Loop (循环)                     │
│                                             │
│   1. Trigger ──→ 2. Goal                    │
│        │            │                       │
│        │            ▼                       │
│        │      3. Actions                    │
│        │            │                       │
│        │            ▼                       │
│        │      4. Verification               │
│        │            │                       │
│        │            ▼                       │
│        │      5. Memory ──→ 回到 Trigger    │
│        │                                   │
│        └──── (失败时熔断 / 成功时升级)       │
└─────────────────────────────────────────────┘

2.5.3 关键实践

实践 1：/goal 命令（Anthropic Claude Code）

/goal "修复所有 ESLint 错误" or stop after 20 turns

/goal 命令会：

• 启动一个独立 session 跑循环
• 派生出独立的 Haiku 模型作为 supervisor 验证结果
• 设置熔断保护：最多 20 turns
• 状态可查：/goal 无参数时显示运行统计

实践 2：/loop 命令（Anthropic Claude Code）

/loop 30m "检查 CI 失败的 PR，自动修复并 rebase"

/loop 是 cron 式调度，让 agent 每 30 分钟执行一次任务。

Boris Cherny 公开表示他跑了"几十个"持久循环：

• PR 看护：自动修复 CI 失败
• CI 维护：识别并修复 flaky test
• 反馈聚合：每 30 分钟抓 X 平台聚类用户反馈
• 代码搜索：扫代码库找可优化点

实践 3：Routines（例程）

Routines 是"watch 任务队列的 agent"——Boris 团队的核心实践：

# 伪代码：Routine 的本质
routine:
  trigger: "queue 里有新任务"
  action: "派 agent 处理任务"
  verification: "agent 报告完成 + 独立验证"
  memory: "任务状态写入数据库"

2.5.4 Boris Cherny 的工作流（Sequoia AI Ascent 2026）

Boris Cherny 在 2026 年 5 月 Sequoia AI Ascent 2026 上公开了自己的工作流：

• 5-10 个活跃 root session
• 每个 session 下面挂数百个 sub-agent
• 一夜之间执行数千个 agent
• 工作站：手机（！）
• 真实数据：150 PR/天（个人纪录）

Boris 说：“我不再提示 Claude 了。我有循环在运行，它们自己在提示 Claude，自己决定下一步怎么做。我的工作是写循环。”

2.5.5 关键判断

Loop Engineering 解决了"怎么转"的问题，让人从"包工头"升级为"循环系统设计师"。

但 Loop Engineering 也带来了全新的挑战：

1. Loop 的可观测性：循环里跑了成百上千个 agent，怎么知道哪个在干什么？
2. Loop 的可调试性：循环失败时，怎么定位是哪个环节出问题？
3. Loop 的可治理性：循环是"自主"的，但人类的责任如何划分？

这些问题是 2026 年下半年的研究热点，也是本课程第 11 章要重点讨论的内容。

Loop Engineering 时代的人，是"循环系统设计师"——负责设计让 Agent 自主运转的闭环。

2.6 四级跳的本质规律

2.6.1 规律一：优化对象递进

话术 → 信息 → 环境 → 系统

每一级跳的优化对象都比上一级更"重"。这是物理意义上的"基础设施升级"——不是模型变强了，是模型的工作条件变好了。

2.6.2 规律二：人的角色降级

对话者 → 整理者 → 包工头 → 设计师

每一级跳中，人类的"直接工作量"都减少，但"间接责任"都增大——从"我必须每句 prompt 都写对"到"我必须设计一个让 Agent 自主运转的系统"。

2.6.3 规律三：杠杆指数级提升

1x → 10x → 100x → 1000x

每一级跳带来的"产能提升"是指数级的：

• Prompt Engineering：单次交互的产出
• Context Engineering：单次任务的产出（带信息的 RAG）
• Harness Engineering：跨任务的产出（带环境的 agent）
• Loop Engineering：跨时间的产出（带循环的系统）

2.6.4 规律四：每级都是上级的"答案"和下级的"问题"

这意味着：不存在"银弹"——每一级跳都解决了上一级跳的痛点，但又引入了新的痛点。

2.6.5 规律五：模型本身的"分值"在下降

越到高级范式，对模型"内功"的要求越低——Harness/Loop 时代，模型可以不是最强的，但 Harness/Loop 必须是设计得最精妙的。

2.7 2026 年我们站在哪一级？

我们来看几个代表性案例：

大多数开发者目前停留在第一级（Prompt）——他们有 AI 工具，但还没建立 Harness，更不用说 Loop。

本课程的目标是：带你从第一级跃迁到第四级，重点是第三级（Harness）和第四级（Loop）。

2.8 常见误区

2.8.1 误区一：“我用 Cursor，已经在 Harness 阶段了”

不一定。

判断标准是：你的项目里是否有显式的、可维护的、跨 session 持久化的"运行环境定义"。

• ❌ 写过一次 prompt 模板，不是 Harness
• ❌ 在 Cursor 里设过几条规则，不一定是 Harness
• ✅ 维护一个 AGENTS.md / CLAUDE.md 体系，才是 Harness 的起点

2.8.2 误区二：“Loop 就是 Agent 自主决策”

不完全。

Loop 的核心是**“系统自主提示 Agent”**——包括 trigger、goal、verification、memory 四个闭环组件。单纯的"Agent 自主决策"是 AutoGPT 式的无目标探索，那不是 Loop，是死循环。

2.8.3 误区三：“越高级越好”

不是。

每一级跳都有其适用场景：

• 第一级适合：原型、概念验证
• 第二级适合：单任务、多文档处理
• 第三级适合：多任务、生产环境
• 第四级适合：跨时间、跨任务的自动化运营

没有最好的范式，只有最合适的范式。

2.9 本章小结

四级跳是 AI 编程范式的完整演进图。每一级跳都解决了上一级跳的痛点，但又引入了新的痛点。关键不是"我现在在哪一级"，而是"我下一步要升到哪一级"。

下一章（第 3 章）我们将聚焦在第二级和第三级之间的"中间地带"——In-the-loop 模式——并解释为什么这种"折中方案"注定失败。

2.10 思考题

1. 你的项目目前停留在哪一级？列出 3 个具体证据。
2. 你所在团队有没有人已经在尝试 Harness 或 Loop？他们的实践遇到了什么困难？
3. 如果要你给团队做一次范式跃迁培训，你会按什么顺序讲这四级跳？为什么？

2.11 参考资料

• Anthropic, “Building Effective Agents”, 2024.03
• LangChain, “The Rise of Context Engineering”, 2024.06
• Andrej Karpathy X 推文, 2024.09
• OpenAI, “Harness engineering: leveraging Codex in an agent-first world”, 2026.02
• Mitchell Hashimoto, “Harness Engineering”, 2026.02.05
• Addy Osmani, “What Is Loop Engineering?”, 2026.06
• Boris Cherny, Sequoia AI Ascent 2026 演讲, 2026.05
• Anthropic Claude Code /goal /loop 文档, 2026.04
• The Neuron, “Claude Code Creators Explain How to Use Agent Loops”, 2026.06.09
• CSDN, “Claude Code Loop Engineering：从手动提示到自主循环”, 2026.06.16