Prompt 之后是 Context，Context 之后为什么是 Loop

Fri, 31 Jul 2026 18:30:00 +0800

毕业之前，我属实没有想到，IT 工程师的工作方式会在短短几年里经历如此翻天覆地的变化。

以前理解的程序员工作，就是分析需求、设计接口，然后一行一行写业务代码。

现在则越来越像是先设计系统、整理上下文、写清约束和验收标准，再让 AI 生成代码，最后通过测试、工具和人工审核结果。

某种程度上，相当于给自己配了一个 24 小时在线的下属。

它不会累，可以不停地读代码、改代码、跑测试。但它也不是一个可以完全放手的成熟员工。如果目标、权限、工具或验收标准设计错了，它同样可以 24 小时不间断地往错误方向狂奔。

我最近看到的两张图，正好把这种变化总结了出来。

第一张图把 AI 工程分成五个阶段：Prompt Engineering、Context Engineering、Harness Engineering、Loop Engineering 和 Graph Engineering。

第二张图则把它们画成一层套一层的结构。

我不打算考证每个名词究竟在哪一年出现。对我来说，这两张图最有价值的地方，是它们表达了一种关系：这些阶段并不是后一代替代前一代，而是每一层都在解决上一层暴露出来的问题，同时又建立在上一层之上。

Prompt Engineering 解决的是怎么把话说清楚。

Context Engineering 解决的是怎么把正确的背景、文档和记忆交给模型。

Harness Engineering 解决的是怎么给模型准备工具、权限、运行环境和跨上下文的状态。

Loop Engineering 进一步要解决的，则是怎么让模型自己发现问题、修正结果，并在合适的时候停下来。

再往外一层的 Graph Engineering，开始考虑多个 Loop 之间如何分工、依赖、并行和调度。

我自己对 Loop Engineering 的理解还很浅，这篇文章也只是一次学习记录。

在 Loop 之前，人其实就是那个循环

在 Loop 这个概念出现之前，我们使用大模型的方式通常是这样的：

用户提出问题，模型给出答案；用户检查结果，发现问题；用户把问题重新描述给模型，模型再次修改；如此反复，直到用户觉得结果可以接受。

表面上看，这是人在和模型对话。

实际上，它已经是一个完整的循环：

提出问题 -> 生成结果 -> 检查偏差 -> 提供反馈 -> 再次生成

只不过这个循环里的观察、判断和停止，全都由人来完成。

如果把这些工作也交给系统，让模型自己读取执行结果、判断哪里不对、制定下一步方案，然后继续尝试，是不是就可以节省人很多精力？

这就是我目前对 Loop Engineering 最直观的理解。

它不是让模型多回答几次，也不是简单地在程序外面套一个 while true。它真正要做的，是把原本依赖人完成的反馈过程，设计成一个可以自动运行的工程系统。

如果反馈足够准确，模型每一轮都能根据结果修正下一步动作，那么最终表现出来的能力确实会变强。

不过严格来说，变强的不是模型本身。

模型参数没有因为多跑几轮而发生变化。真正变强的是模型、工具、环境、反馈和停止条件共同组成的整个系统。

Loop 能不能收敛

说到循环，我最先想到的是“收敛”。

我第一次接触收敛，是在学习微积分里的极限时。简单理解，就是一个序列随着不断变化，越来越接近某个确定的值。

拿大模型回答问题举一个并不严谨、但很直观的例子。

第一次问大模型 1 + 1 等于几，它回答 1，和正确答案偏差很大。

把错误反馈给它以后，第二次回答变成 2.1，已经更接近答案。

第三次回答 2.0001，偏差又缩小了一些。

如果误差能够在每一轮里不断减小，就可以把这个过程理解为正在收敛。

这背后依赖的是一种负反馈调节机制：系统观察当前结果与目标之间的偏差，再用这个偏差修正下一轮行为。

问题在于，大模型的循环并不保证一定收敛，更不保证每一轮都比上一轮更好。

它第三次回答了 2.0001，第四次完全可能突然回答 10。

为什么会这样？

可能是反馈本身判断错了，可能是模型选错了工具，可能是上下文里混进了互相冲突的信息，也可能是前几轮留下的错误状态没有被清理。

即使这些步骤都没有明显出错，上下文不断膨胀以后，旧信息、无关信息和重复信息也可能开始干扰模型。

另外，大模型本身就带有概率性。同样的输入，不同轮次也未必会沿着同一条路线继续优化。

所以，循环次数更多，不等于结果一定更准确。

如果反馈方向错了，Loop 甚至会把一个小错误不断放大。那个 24 小时在线的下属，也可能非常勤奋地把整个项目带进沟里。

可观测性和可验证性不是一回事

我最初理解这件事时，把可观测性和可验证性混在了一起。

后来想了一下，它们其实解决的是两个不同的问题。

可观测性解决的是：系统刚才做了什么？

比如模型读取了哪些文件、调用了什么工具、当前执行到了哪一步、消耗了多少时间和 token、修改了哪些代码，以及为什么做出这个决定。

没有这些信息，Loop 一旦偏离目标，我们甚至不知道问题出在哪一轮。

可验证性解决的则是：系统做得对不对？

代码有没有通过单元测试和类型检查，接口返回值是否符合 Schema，页面是否真的可以操作，性能指标有没有达标，最终结果是否满足最初的验收条件。

只有可观测性，没有可验证性，我们可以看到模型忙了很久，却不知道它到底有没有把事情做好。

只有可验证性，没有可观测性，测试失败以后，我们又很难判断问题究竟发生在哪里。

Loop 想要稳定运行，两者缺一不可。

这也是为什么写代码很适合使用 Agent Loop。代码天然拥有很多相对明确的反馈信号：编译是否通过、测试是否成功、接口是否返回预期结果、页面是否正常渲染。

相比之下，“这篇文章写得够不够好”就很难量化，因为它缺少唯一正确的答案。

当然，即使测试全部通过，也不代表业务一定正确。测试本身可能写错，覆盖范围也可能不够，模型甚至可能通过修改测试来让错误代码变绿。

所以 Harness 里还需要权限边界、受保护的验收标准，以及必要时由人介入审核。

什么时候应该结束循环

Loop Engineering 还有一个很重要的问题：什么时候停？

大模型每次回答的，本质上都是它认为概率最高的结果，而不是经过数学证明的唯一答案。

既然很难得到绝对完美的结果，就不能要求 Loop 一直运行到“完全正确”。

否则它可能永远不会结束。

我目前理解，一套 Loop 至少要回答四个问题：

如何感知当前状态和问题？
如何根据问题决定下一步方案？
执行以后，如何验收结果？
验收完成后，应该继续、停止，还是交给人处理？

最理想的停止方式，当然是所有验收条件都已经满足。

但工程上还需要更多保险。

例如达到最大迭代次数就停止，超过时间或 token 预算就停止，连续几轮没有明显改善就停止，反复出现相同错误就停止，或者遇到高风险操作时暂停并等待人工确认。

有时候，停止条件甚至比生成代码的提示词更重要。

因为一个不会写代码的 Agent，最多只是交不出结果；一个不知道什么时候停的 Agent，却可能不停重试、消耗额度、反复修改已经正确的代码，最后把原本能用的东西也弄坏。

所以 Loop Engineering 不是研究怎么让 AI 无限工作，而是研究怎么让它在一个受控的反馈系统里持续工作。

再往外一层，就是多个 Loop 的协作

当一个 Loop 能够稳定完成任务以后，下一步自然会遇到新的问题。

一个复杂项目里，可能同时存在需求分析 Loop、编码 Loop、测试 Loop、代码审查 Loop 和部署 Loop。

它们之间谁先开始，谁依赖谁，哪些任务可以并行，某个 Loop 失败以后应该重试还是回退，都需要更高一层的系统来调度。

这大概就是图里 Graph Engineering 想要解决的问题。

如果说 Loop Engineering 是让一个执行者能够自己工作，那么 Graph Engineering 更像是在组织一支团队。

至于这一层具体应该怎么设计，我现在的理解就更浅了，还有待后续继续学习。

最后

毕业之前，我以为程序员的成长路径，是不断学习新的语言、框架和架构，然后写出越来越多、越来越复杂的代码。

现在才发现，未来工程师的工作可能会越来越少地停留在“亲手写出每一行业务代码”上。

我们开始负责定义问题、设计环境、准备工具、设置权限、编写验收标准、观察执行过程，并决定什么时候应该让 AI 继续，什么时候必须由人接手。

代码仍然重要，只是它正在从工作的全部，变成整个系统中的一部分。

工程师也正在从代码的直接生产者，慢慢变成反馈系统和工作机制的设计者。

所谓配备一个 24 小时在线的下属，真正困难的从来不是让它开始工作。

而是让它知道该做什么，做完以后如何证明自己做对了，以及什么时候应该停下来。