从提示工程到上下文/循环工程（最新范式）
2023 年大家比拼「谁的 prompt 写得好」，2025 年的关注点已经转移：当应用变成多步、有状态、会调工具的 Agent，决定成败的不再是某句提示词，而是整个上下文如何被动态组织、Agent 如何在循环里自我驱动。本文梳理 Prompt → Context → Loop 这条演进线，并对 ACE、loop engineering、Hermes 式自改进等新名词给出核实过的、不夸大的解释。
术语澄清（重要）
社区里这些词大多来自工程实践与博客，尚未形成统一学术定义，不同来源叫法不一。本文标注每个概念的成熟度：✅ 已确立 / 🔶 实践概念（无统一定义）/ ⚠️ 易混淆。读者面试时可以讲，但要说清「这是工程社区的提法」。
演进主线：Prompt → Context → Loop
Prompt Engineering ──► Context Engineering ──► Loop / Agentic Engineering
写好「一句话」 管好「整个窗口」 管好「自驱的循环」
单轮、静态 多步、有状态 自主、长程
人来给指令 系统来组装上下文 Agent 自己给自己下指令三者不是替代而是层层包裹：循环里的每一步仍要组装上下文，组装上下文里仍要写好局部提示词。理解这条线，是回答「提示工程过时了吗」这类问题的标准框架。
一、Context Engineering（上下文工程）✅
定义（已被广泛接受）：设计一套动态系统，在正确的时机、以正确的格式，把正确的信息和工具喂给 LLM，让它具备完成任务所需的一切。关注点从「提示措辞」转向「上下文内容的全生命周期」。
四大操作 Write / Select / Compress / Isolate 与上下文退化（poisoning/distraction/confusion/clash）已在 上下文工程 详述，这里只补提示工程视角的增量：
- 过去优化「system prompt 怎么写」，现在优化「system prompt + 历史 + 工具结果 + 检索 + 记忆」如何共同占用有限窗口；
- 经典实证依据：lost-in-the-middle（中部信息利用率最低）、context rot（有效注意力随长度衰减）——所以「精准最小上下文」胜过「把能塞的都塞进去」。
ACE：Agentic Context Engineering（最新）🔶
2025 年的代表性工作（arXiv:2510.04618）。核心思想：把上下文当作一份会进化的「攻略手册（playbook）」，通过三个角色循环不断积累、提炼、组织策略：
Generator（生成解法/轨迹） ──► Reflector（反思成败、提炼经验）
▲ │
└──── Curator（把经验增量写回 playbook，去冗余）◄┘- 与「让模型反复重写整段上下文」不同，ACE 强调增量更新（只追加/修订有用条目），避免「上下文塌缩」（反复重写导致信息丢失、同质化）。
- 本质是把 Reflexion 的「语言记忆」和 记忆系统 的「写入-检索」工程化成一套自改进上下文流程。
- 面试讲法：ACE = 上下文工程 + 自我改进循环，让 Agent 的「经验手册」随使用越变越好，而不是每次从零提示。
二、Loop Engineering / Agentic Loop（循环工程）🔶
定位：这是工程社区的提法（博客/实践为主，无统一学术定义），指的是从「人不断手写 prompt 推进任务」转向「给定目标，让 Agent 在循环里自己给自己下一步指令」。
核心循环（与 ReAct 同源，见 Agent 基础）：
目标 ──► [ 模型决定下一步 → 执行工具 → 观察结果 → 评估是否达成 ] ──► 达成则停
▲___________________________ 未达成则继续 ___________________│「loop engineering」强调的设计要点（社区共识，非定论）：
- 目标导向而非步骤导向：你定义「成功长什么样」和停止条件，而不是把每一步写死；
- 循环的护栏：最大步数/预算、关键操作人工确认、失败重试上限、可观测轨迹——没有护栏的自驱循环会烧钱或跑偏（见 工作流 vs Agent）；
- 反馈质量决定上限：循环每轮要有可靠的进展信号（测试通过、检索命中、子目标达成），否则模型在循环里「空转打转」。这与 自我纠错依赖外部反馈 是同一条原理。
诚实提醒：「loop engineering」目前更像是给「带护栏的 agentic 循环设计」起的新名字，而非一项独立新技术。面试中可以这么讲，但别把它说成有严格定义的范式。
三、Hermes 式自改进循环 🔶 ⚠️
先消歧义
「Hermes」在 LLM 语境下有两个完全不同的所指：
- Hermes 模型：NousResearch 开源的指令/对话模型系列（基于 LLaMA/Qwen 等微调），是一个模型，与提示工程无关。
- Hermes 式 Agent / 学习循环：工程社区描述的一种自改进 Agent 模式，与上面的「模型」不是一回事。用户常说的「Hermes engineering」多指后者。
Hermes 式学习循环（社区描述，🔶 无统一定义）的核心想法：当一次任务成功且方法非平凡时，Agent 把其中的推理模式提炼成一个命名的「技能（skill）」——一个结构化模板：「当情境长这样时，这个做法有效」。之后遇到相似情境就复用该技能；若出现更好的做法，就更新技能。久而久之积累出一套贴合具体工作流的技能库。
成功且非平凡的解法 ──► 提炼为命名 skill（情境→做法 模板）
│
相似情境再次出现 ──► 调用 skill ──► 若新做法更优 ──► 更新 skill- 这本质是 Reflexion / ACE 思路的「技能化」变体：把零散的语言反思，固化成可检索、可更新、可复用的命名模板。
- 与 记忆系统 的「从情景记忆蒸馏语义/程序记忆」、上下文工程 的「playbook」高度同源——都是「让 Agent 把经验沉淀成资产」。
- 面试讲法：Hermes 式循环 = 把成功经验提炼成命名技能并持续更新的自改进 Agent 模式，并主动点明「Hermes 也是个模型名，注意区分」——这个消歧义本身就是加分项。
四、把这些串成一张认知图
| 概念 | 一句话 | 成熟度 | 本质来源 |
|---|---|---|---|
| Prompt Engineering | 写好单条提示 | ✅ 经典 | 指令设计 |
| Context Engineering | 管好整个上下文窗口 | ✅ 已确立 | 信息架构 + 记忆/检索 |
| ACE | 上下文当可进化攻略，增量自改进 | 🔶 最新论文 | 上下文工程 + Reflexion |
| Loop Engineering | 给目标让 Agent 自驱循环 | 🔶 实践概念 | ReAct + 护栏设计 |
| Hermes 式循环 | 把成功经验提炼成命名技能并复用 | 🔶 实践概念 | Reflexion/记忆蒸馏 |
它们共享一条主线：从「人精心给指令」走向「系统/Agent 自己积累并组织经验」。这正是「提示工程没有过时，而是被包进了更大的工程命题里」的完整答案。
高频追问
Q：提示工程过时了吗？ 没过时，是被「包」进了更大的范畴。单轮写好提示仍是地基；但 Agent 时代的主要矛盾上移到了上下文工程（管整个窗口）和循环工程（管自驱过程）。会写提示 + 懂上下文/循环设计，才是完整能力。
Q：Context Engineering 和 Prompt Engineering 到底差在哪？ 对象和时态不同：Prompt 工程是「一段静态指令」的措辞优化；Context 工程是「多步、有状态系统中，整个上下文窗口内容（历史/工具结果/检索/记忆）如何被动态组装」的工程。后者面向 Agent，前者面向单轮。
Q：ACE 解决了什么痛点？ 解决「Agent 不会从经验里变好」和「反复重写上下文导致信息塌缩」。它用 Generator/Reflector/Curator 三角色把经验增量沉淀进一份会进化的 playbook，让上下文越用越强，而非每次从零提示。
Q：loop engineering 是不是就是 ReAct？ 同源但侧重点不同。ReAct 描述「思考-行动-观察」的单元循环；loop engineering 更强调工程视角——目标导向的停止条件、护栏（限步数/预算/确认）、可靠进展信号的设计。可以理解为「把 ReAct 循环做成可生产的系统」。它是实践概念，没有严格学术定义。
Q：面试官问你「Hermes engineering」你怎么答？ 先消歧义：Hermes 既是 NousResearch 的开源模型系列，也被用来指一类「把成功经验提炼成命名技能、持续更新复用」的自改进 Agent 循环。用户多指后者，它本质是 Reflexion/记忆蒸馏的技能化变体。能主动区分两个所指、并指出它无统一定义，比硬背一个「定义」更显专业。
Q：这些新范式有什么共同的工程风险？ 自改进/自驱循环都依赖可靠的反馈信号和护栏：反馈不可靠→在循环里强化错误经验（poisoning）；无护栏→烧钱、跑偏、误操作。落地时务必配可验证信号、最大步数/预算、人工确认与全轨迹可观测（见 LLMOps）。