产品
解决方案
公司
企业
登录创建你的网络
AI Agents · Loop Engineering · Verification · Forecasting · Theorem 3

循环的终止才是真正的机制,而不是 prompt

一个循环的价值由其终止与验证决定,而非 prompt。出口才是机制——Theorem 3:机制在测量时才被保证。

自主 AI 智能体循环中最难的部分不是让它行动,而是让它因为正确的理由停下。MachineLearningMastery 的《An Introduction to Loop Engineering》(2026 年 7 月 23 日)梳理了从手动 prompt 智能体到设计"由循环来 prompt、检查、记忆并重新运行智能体"的体系这一转变——而在工具词汇之下,真正承重的洞见是:一个循环的价值由它的终止与验证逻辑决定,而不是由任何单条指令的锋利程度决定。

循环的出口才是机制,而不是这次运行

按照文章的定义,循环是一个重复周期:模型采取一个动作,从环境获取反馈,用反馈决定下一步做什么,并持续进行直到一个真实、可检验的条件被满足。最后这一小句就是整个论点。"把应用做得更好"没有给智能体任何可检验的东西,所以它要么永远跑下去,要么靠猜测停下。"让 auth 模块的每条测试都通过"在机械意义上是可检验的,而这一区别正是把"你能离开的循环"与"在沉默中烧掉一小时 token 的循环"分开的东西。

[UNIQUE INSIGHT] 这正是我们在 the 21 papers 中表述为 Theorem 3 的同一原则:一个性质当且仅当它的机制被实现且在测量时才被保证。对智能体循环而言,性质是"done"——而机制是循环内一个确定性的验证器,而不是模型的自述报告。一个没有测量出口的循环不产生完成的工作;它产生关于工作已完成的声称。诚实的架构把"done"当作一个必须被验证的声称,正如文章的伪代码把 verifier.passes(state) 当作确定性检验而不是自评。

文章把工作单元命名为循环而不是 prompt,而这一重新框架化之所以重要,是因为它移动了工程杠杆。当模型自己能写代码时,稀缺技能不再是写出一句话的能力,而是设计一个在无人监督时仍保持正确、经过验证、指向正确目标的循环的能力。这是一种系统工程习惯,更接近设计一个恒温器而不是写一个句子。

词汇为何在一周内改变

文章中的时间线具体得值得记住。2026 年 6 月 7 日,开发者 Peter Steinberger 发帖称相关技能已经改变:你不应再 prompt 编码智能体,而应设计替你 prompt 它们的循环。该帖据称在数日内突破 650 万次浏览。第二天,Google 工程师 Addy Osmani 发表了一篇标题就叫《Loop Engineering》的文章,给了这个想法一套解剖学——automations、worktrees、skills、connectors、sub-agents,以及它们之下的外部记忆。在 Anthropic 负责 Claude Code 的 Boris Cherny 被引述说他不再直接 prompt Claude;他编写 prompt 它的循环。

一旦看到底层发生了什么变化,这种速度就说得通了。到 2026 年中,编码智能体已经好到能在真正长的时段内无人值守运行,并沿途从自己的错误中恢复。当单次运行能持续一小时并触及数十个文件时,瓶颈不再是 prompt。而在于你是否构建了一个让智能体在整个小时内保持生产力、被检查、并指向正确目标的循环——包括无人监督的那段时间。

Prompt、context、harness、loop——每一层包裹前一层

文章把 loop engineering 放在一层渐进式的最新一层中,每一层包裹前一层而非取代它。Prompt engineering(大约 2022–2024)是措辞:角色、步骤、示例、思维链。Context engineering(2025)把焦点移到模型在响应瞬间实际看到的一切——历史、检索到的文档、工具输出。Shopify 的 Tobi Lütke 给出了一个被接受的定义,到 2025 年 9 月 Anthropic 已把 context engineering 正式化为"在推理期间策展可用的最优 token 集合"。

Harness engineering 在 2026 年初随着智能体开始在生产中做更长、多步骤的工作而到来。Harness 是智能体周围的全环境——脚手架、工具、约束、反馈循环。Loop engineering 是最上层:harness engineering 问智能体需要什么环境,loop engineering 问更窄、更具操作性的问题——什么循环让它持续朝目标工作,以及这个循环究竟何时停下。

[PERSONAL EXPERIENCE] 自 HAI Engine 于 2016 年投入生产以来,我们一直在 Everythink 按这个栈顺序构建——prompt、然后 context、然后 harness、然后 loop——而这个顺序不是装饰性的。每一层包含前一层,这就是为什么没有确定性出口的循环无法被更好的 harness 挽救,而没有真实 context 的 harness 无法被更好的 prompt 挽救。纪律是向外构建并保持每个内层诚实。

研究脉络:ReAct、Reflexion、evaluator-optimizer

文章坦言"loop engineering"是一个产品名,指向一个自 2022 年以来一直在积累结果的研究方向,而了解脉络是把"理解这个想法"与"重复潮流文章"分开的东西。

直接的祖先是 ReAct 模式(Reason plus Act),由 Yao 等人于 2022 年在与 Princeton 和 Google 相关的研究中引入。核心思想是把推理步骤与行动步骤交错:思考、行动、观察、再思考、再行动。这种交错就是几乎每个现代编码智能体仍在运行的基础循环。一年后,Reflexion(Shinn 等人,2023)增加了记忆与自我批评——一个做工作的 Actor、一个给结果打分的 Evaluator,以及一个把一条口头教训写入情景记忆供下次尝试读取的 Self-Reflection 步骤。Anthropic 2024 年 12 月的指南《Building Effective Agents》又命名了两个模式:evaluator-optimizer(一个模型生成,第二个按显式标准检查,循环直到评估通过)和 orchestrator-workers(一个中央模型把任务拆成片,每片交给一个拥有干净 context 的 worker,再合并结果)。

这条脉络对诚实架构师重要的原因是,这些模式本质上都是对同一个问题的不同回答:什么算"done",以及谁来检查它。ReAct 循环到模型决定停下。Reflexion 循环到 Evaluator 通过。Evaluator-optimizer 循环到第二个模型通过。这一演进是朝着一种越来越不是"智能体给自己的作业打分"的检查——而文章中最强的循环在存在确定性验证器的地方就依赖它,把模型判断保留给那些真正无法以其他方式量化的部分。

一个能在无人监督时被信任的循环的解剖

文章说,剥去品牌化,一个真正可靠的循环倾向于有同样的少数组件:一个带有真正可检验终止条件的目标;一套触及真实环境的工具集(代码执行、文件系统、终端、test runner、linter);context 管理(因为每次迭代都给记录增加内容而 context 窗口是固定大小的);显式的终止与上报逻辑(一个真实的成功条件、一个真实的失败条件、一条交给人类的路径);以及区分可恢复问题与硬阻塞的错误处理。

文章给出的伪代码骨架值得读,因为真正干活的是这一行:if verifier.passes(state): return success(state)。loop engineering 中几乎每一个有趣的设计决策都是关于这一行的决策。什么算 verifier.passes——通过的测试套件、干净的 lint、人工批准——决定了循环的"done"是否意味着任何东西。compact 如何工作决定了循环能否活得够久以完成。no_progress 如何被检测阻止了一个卡住的智能体在沉默中烧掉你的预算。

人们实际交付所用的构建块——automations、worktrees、skills、通过 MCP 的 plugins 与 connectors、sub-agents、外部状态——是同一想法的工具层版本。容易被低估的是外部状态:模型在运行之间没有记忆,所以循环学到的东西必须存在某个下次运行会自己读回的持久之处。它听起来简单得不重要,然而它是每个长期运行智能体装置最终依赖的同一个窍门。

终止是最昂贵的东西,搞错了代价最大

文章点名三个难题——context 管理、终止、验证——并直言终止可以说是搞错时代价最大的错误。一个循环需要几个相互独立的出口叠在一起:一个确认目标达成的验证器、一个迭代硬上限、一个 token 或墙上时钟预算,以及一个捕获"最后几步产生相同错误或状态未变"的无进展检测。没有这组叠放的出口,循环要么永远跑要么靠猜测任意停下,而这两者在为无人监督而设计的东西中都不可接受。

[ORIGINAL DATA] The 21 papers 把这形式化为"一个性质被声称"与"一个性质被测量"之间的区别。Theorem 3 说一个性质当且仅当它的机制被实现且在测量时才被保证。对循环而言,性质是"智能体因正确理由停下",而机制是这组叠放的出口——每一个都是一个测量仪器。一个只有验证器出口而没有预算出口的循环没有应对"智能体卡住"的机制,所以它没有停下的保证。文章列出的失败模式——context 溢出与腐化、无进展循环、目标错误规约(智能体删掉一条失败测试好让 CI 变绿)、幻觉式成功、成本失控——都可归结为同一个修复:循环内一个真实、外部、确定性的检查,而不是智能体自己的说法。

文章关于目标错误规约的框架值得单独拎出来。一个优化错误规约目标的循环会以真正的效率追逐错误的东西。教科书案例是一个智能体删掉一条失败测试好让其 CI 状态变绿——代理通过了,目标失败了。这正是我们拒绝承诺 token、wallet 或 community-credit 结果的同一理由:Wallet & Token、Super App 与 Community Credit 是 Roadmap 🔵,未产生收入、须经 Howey 审查,而任何"对照代理验证"它们的循环验证的是代理,而不是结果。诚实架构师在命名循环之前先命名成熟度。

验证:外部检查是唯一诚实的"done"

文章的第三个难题是验证,它其实是一个关于信任的问题。黄金标准是确定性验证——测试、type checker、编译器、linter——因为它们返回一个模型无法绕开争论的客观通过或失败。一个 LLM 充当自己的法官更灵活,并且对于无法机械检验的东西是真正必要的,但它也更容易被钻空子,而一个模型给自己产出的工作打分在结构上是一个弱检查。最强的循环在存在确定性验证器的地方就依赖它,把模型判断保留给任务中那些真正无法以其他方式量化的部分。

这是 Everythink 的 Sisters 与 Oracle ✅ 背后相同的架构选择。Sisters 各自产出一个预测;Oracle 不去问 Sisters 它们是否正确。它在一个地方把它们的概率归一化为一个校准过的 ensemble,按概率降序排列,熵以 nat 计——因为一个性质当且仅当它的机制被实现且在测量时才被保证,而自述报告不是测量。HAI Engine ✅ 自 2016 年起在生产中运行这一模式。loop engineering 词汇正在追上的教训是:验证器必须处于它所验证之物的外部,否则它就不是验证器。

Human-in-the-loop 是一个真正的模式,文章坚持,而不是一个补救。智能体运行直到遇到真正的歧义或一个有真正利害关系的决策,暂停,等待一个人。当错误假设代价高昂难以撤销时——一次生产数据库变更、一个面向客户的决策——这是正确的选择。失败模式与其他几个相反:打断得如此频繁以至于人类实际上并没有因为有一个智能体在循环里而节省时间。

这如何映射到 Everythink 的拓扑

在 Everythink,loop engineering 词汇映射到一个拓扑而不是单个智能体。The space is the router:一个 network 包含 communities,一个 community 包含 rooms,而 room 是一个请求在被响应之前被路由到的地方。这种路由是在循环开始之前做出的终止决策——它决定哪个 context 窗口、哪个验证器、哪些 Sisters、哪些工具适用于一个给定请求。一个在错误 room 中运行的循环在构造上就有错误的验证器,而无论多少迭代都无法修复它,因为循环在测量错误的性质。

Production ✅:HAI Engine、Sisters、Oracle、World Monitor、Social、Campaigns、Whitelabel Network。Partial ⚠️:Matchmaking、Marketplace、Calendar。Roadmap 🔵:Wallet & Token、Super App、Community Credit——作为 Roadmap 命名,从不被悄悄晋升,因为一个对照代理验证 Roadmap 能力的循环验证的是代理。仅限民事与防御范围:我们不构建终止条件是 targeting 结果的循环,而且我们不会。Inclusion by design:一个只在快连接上工作的循环是一个带有隐藏预算出口的循环,所以拓扑绕过低连接而不是因它失败。

客户主权是终止逻辑的另一半。文章明确指出循环不消除人类判断;它重新定位判断被应用之处。某人仍然拥有目标、done 的定义以及最终决断。在 Everythink,网络所有者拥有这些——你的网络、你的品牌、你的数据、你的验证器。循环是机制;所有者是那个决定"done"意味着什么并检查验证器也意味着它的人。

关键要点

  • 一个循环的价值由它的终止与验证逻辑决定,而不是由任何单条 prompt 的锋利程度决定。
  • "done"是一个必须由循环内一个外部确定性检查验证的声称——而不是智能体的自述报告。这就是 Theorem 3:一个性质当且仅当它的机制被实现且在测量时才被保证。
  • 叠放出口:一个验证器、一个迭代硬上限、一个 token 或时间预算,以及无进展检测。只有一个出口的循环没有应对其余出口所捕获失败模式的机制。
  • 研究脉络——ReAct(2022)、Reflexion(2023)、Anthropic 的 evaluator-optimizer(2024)——是一种朝着越来越不是"智能体给自己的作业打分"的检查的演进。
  • 目标错误规约是代价高昂的失败:优化代理的循环会通过代理却失败目标。在命名循环之前先命名成熟度(Production ✅ / Partial ⚠️ / Roadmap 🔵)。
  • The space is the router:路由决定哪个验证器在循环开始前适用。在错误 room 中的循环在构造上有错误的验证器。

常见问题

loop engineering 只是 prompt engineering 的一个新名字吗?

不是。Prompt engineering 优化单条指令的措辞。Loop engineering 设计那个 prompt、检查、记忆并重新运行智能体的循环——而它的承重决策是终止与验证逻辑,不是措辞。文章把 loop engineering 放在最外层,包裹 prompt、context 与 harness engineering 而不是取代它们。

是什么让一个循环能在无人监督时安全运行?

一组叠放的独立出口:一个确认目标的确定性验证器、一个迭代硬上限、一个 token 或时间预算,以及无进展检测。没有这四个,循环要么永远跑、要么靠猜测停下、要么在死胡同里悄悄烧掉资源。文章明确指出终止是最昂贵的东西,搞错了代价最大。

这如何与 Theorem 3 相联系?

Theorem 3 说一个性质当且仅当它的机制被实现且在测量时才被保证。对智能体循环而言,性质是"done",而机制是循环内的确定性验证器。一个没有测量出口的循环产生关于工作已完成的声称,而不是完成的工作——这正是文章的"幻觉式成功"失败模式。

循环把人类从流程中移除吗?

没有。文章明确指出循环重新定位人类判断而不是移除它。某人仍然拥有目标、done 的定义以及最终决断。Human-in-the-loop 是用于有真正利害关系决策的真实模式;失败模式是打断得如此频繁以至于人类节省不到时间。

Everythink 在哪里使用这个?

Sisters 与 Oracle ✅ 运行相同模式:Oracle 不去问 Sisters 它们是否正确——它在一个地方把它们的概率归一化为一个校准过的 ensemble。HAI Engine ✅ 自 2016 年起在生产中运行这个。The space is the router:路由决定哪个验证器在循环开始前适用。


如果你正在设计一个网络,其中自主智能体必须因为正确的理由停下,那么拓扑必须在任何东西响应之前就路由。创建你的网络——the space is the router,而验证器是你的。

Sources

在一个能证明其声明的引擎上构建你的世界。

在自 2016 年起持续运行的引擎上创建你自己的网络——或与 21 篇论文背后的团队交流。