循环:2026 年实现 AI 系统规模化背后的核心技能

@cyrilXBT
英语4周前 · 2026年6月22日
246K
365
56
32
736

TL;DR

本文指出,循环工程(即设计触发器、验证机制和停止条件)是 2026 年 AI 开发中关键的技能缺口。在构建可靠的自主系统时,这一技能的重要性远超模型选择。

2026 年,大多数用 AI 构建产品的人仍在通过提示词的好坏来衡量进展。

这个衡量单位是错误的。

那些真正能规模化、能无人值守运行数小时、能协调多个 Agent、还能在人类看到之前自行修复错误的系统,靠的不是更好的提示词。它们靠的是循环。而循环工程——即设计何时运行、如何自我验证、以及何时停止的实际学科——才是几乎没人谈论的技能,而所有人都在争论这个月哪个模型最聪明。

这个技能差距正在悄然拉开:一边是单纯使用 AI 的人,另一边是用 AI 构建系统的人。本文完整描绘了这个差距到底是什么、为什么它比模型选择更重要、以及如何弥合它。

为什么循环是真正的技能,而不是模型

每隔几周就会有新模型发布。新基准。新的“这改变一切”的说法。每次,对话都会默认回到同一个问题:这个模型比上一个更聪明吗?

这个问题的重要性没有人们想象的那么大。

原因如下。循环是一个重复运行的系统,它有明确的触发条件、明确的处理过程、和明确的停止条件,每次循环都会因为积累上下文、发现自身错误、或根据标准优化输出而变得更好。在循环中运行的模型只是一个组件。一个平庸的模型,放在设计良好、带有适当验证的循环里,其表现始终优于一个仅靠单次无监督通跑的前沿模型。

这个说法不再是争议。它是目前正在交付最强大 AI 产品的公司实际运行的真实情况。Claude Code 的创建者 Boris Cherny 曾公开谈到,他从直接给 Claude 写提示词转向构建让模型自我提示的系统——按计划运行的循环,自行验证输出,只有在真正需要人类判断时才上报。Karpathy 也曾讨论过这样的系统:AI 90% 的错误都源于上下文缺失而非模型弱点,而循环通过在每个周期中积累和重新注入上下文,而不是每次都从零开始,从根本上解决了这个问题。

2026 年每一个严肃的 AI 部署都呈现出相同的模式:模型正在快速商品化。在最难的编程 Agent 基准测试中,GLM 5.2 与 Claude Opus 4.8 的差距大约在 1% 以内。Kimi K2.6 能运行 300 个 Agent 的集群,并带有一个验证层,能捕捉到人类手动无法发现的错误。开放权重模型正在以近乎月度的节奏缩小与封闭前沿系统的差距。

而不会商品化的是模型周围的架构——循环设计、验证逻辑、停止条件。这才是真正的技能,也是几乎没人教授的技能。

循环到底是什么

去掉行话,循环只有四个组成部分。

触发条件。什么开始这个周期。可以是固定的时间间隔、文件更改、Webhook 或人工指令。触发条件回答“这个循环何时运行?”

处理过程。循环每个周期实际做什么。读取一些输入,生成一些输出,采取一些行动。这是大多数人唯一关注的部分,但它只是让循环良好运行的最小一部分。

验证步骤。循环如何检查自己的输出是否符合既定标准,然后决定接受还是修正它。这个组件把那些能不断优化质量的循环和那些只是制造活动的循环区分开来。

停止条件。循环何时结束,要么任务成功,要么失败次数过多,继续只会浪费资源,需要人工升级处理。

大多数失败的自动化尝试都完全缺少这四个部分中的一个。一个每五分钟运行一次但没有验证步骤的脚本不是循环,只是一个定时器。一个无限重试失败任务但从不升级的 Agent 不是持久,而是卡住了。循环工程的纪律就是确保这四个部分都存在、都被明确定义、并且都能发挥实际作用。

触发条件:何时运行

触发条件的选择听起来简单,但实际上比表面看起来更微妙。

固定间隔触发:无论状态如何,按计划运行。每 5 分钟检查一次新的 PR 评论。每晚 11 点寻找近期笔记之间的关联。当底层状态持续变化,并且你希望定期检查点而不是等待特定事件时,这种触发方式很合适。

事件驱动触发:针对特定事件发生而触发。新文件出现在文件夹中。来自部署管道的 Webhook 到达。特定的 Slack 消息被发布。当工作确实只响应某些事件时才需要执行时,这种触发方式很合适;而如果使用固定时间表,要么会错过事件,要么会浪费周期检查无变化。

动态间隔触发:这是最未被充分利用的模式。不是固定的时间表,而是 Agent 自己根据本次周期发现的情况决定等待多久后再开始下一个周期。如果什么都没变,下次就等久一点。如果发生了重要事情,就很快再次检查。Boris Cherny 记录过的循环模式 /loop,带有一个动态提示词让 Claude 自己选择间隔(1 分钟到 1 小时之间),就是这个模式的直接实现。系统学会了自己的合适节律,而不是让人类事先猜测一个固定数字。

大多数人在这里犯的错误是选择一个固定间隔,要么过于激进(产生噪音,在什么都没发现的周期上浪费令牌),要么过于保守(错过信息本来会有用的时机)。解决方法不是选一个更好的固定数字,而是构建动态间隔模式,让系统自我调整。

处理过程:实际发生了什么

处理步骤是大多数人花费 90% 设计精力的地方,而循环在这里实际上最不需要新颖的思考,因为这只是在可重复的包装器内应用标准的提示词和工具设计。

这里的关键纪律是范围纪律。一个试图在一次通跑中完成所有事情的处理步骤,比四个各自做一件窄事且做得好的独立处理步骤更难验证、更难调试、也更难变得可靠。

这就是多 Agent 架构相对于单一巨型提示词的实际论据。不是因为更多 Agent 本身就更好,而是因为窄范围使验证变得可行。一个研究员 Agent,其唯一工作是收集和引用信息,可以对照一个简单的标准进行检查:每个主张是否有来源。一个构建者 Agent,其唯一工作是根据研究摘要生成交付物,可以对照另一个简单的标准进行检查:输出是否符合规格。如果把这些合并成一个同时做研究和写作的 Agent,验证就变成了模糊的判断,而不是清单式核对。

在流程层面进行循环工程,意味着将工作分解成足够窄的步骤,使每一步都有一个明确无误的“正确”定义。

验证步骤:几乎每个人都会跳过的部分

这个组件将循环工程与简单的自动化区分开来,也是大多数教程和大多数自建系统完全跳过的部分。

验证是指在接受输出之前,对照明确标准检查循环自身的输出,并使用一种不会被产生输出的同一过程所利用的方法。

天真的失败模式是自我报告验证:产生输出的 Agent 也判断它是否优秀,使用相同的上下文和相同的盲点,正是这些盲点导致了最初的错误。一个编造了引用的 Agent 在审查时通常不会发现自己的编造,因为产生编造的相同推理在看待审查问题时,会给出同样自信但错误的答案。

真正的验证需要结构性分离。以下是一些实际有效的模式:

独立的验证 Agent。一个不同的 Agent(理想情况下使用不同的模型,或至少完全独立的上下文,并明确指示要寻找失败),对照书面标准检查输出。这就是多 Agent 架构中的“评审”模式:一个组件的唯一工作是评分,从不构建,从不修复,只给出通过或失败以及具体证据。

对照真实来源进行交叉验证。而不是抽象地判断输出质量,要去检查具体主张是否与可验证的来源相符。代码是否真的通过了测试套件?引用的统计数据是否出现在源文档中?输出是否符合某个模式?这是可检查的、机械化的验证,而不是判断,并且在可以构建时是最可靠的形式。

更强的模型验证较弱模型的输出。最近在 Agent 集群演示中描述的 Kimi K2.6 与 Opus 4.8 的配对正是这样:300 个快速 Agent 并行生成,一个更强、更慢的模型在输出到达人类之前检查每个输出与其来源。这个模式之所以有效,是因为验证器与生成器没有共享特定的失败模式,即使两者都是语言模型。

明确的置信度标记。让处理步骤自己标记不确定性,而不是声称一致的置信度。构建者坦诚地说“这部分我不确定”,给验证器一个起点,而不是从零开始评分。这并不能替代独立验证,但能让验证更快,并捕捉到生成步骤本身已知道某些问题的情况。

所有这些规则下的硬性规则是:永远不要让循环仅凭产生工作的同一组件也声称成功就宣布成功。那个单一的失败模式——Agent 报告“成功完成”却悄悄搞错了一些事情——被记录为生产 AI 系统中最具破坏力且最难捕捉的失败模式之一,正是因为它看起来和真正的成功一模一样,直到有人手动检查。

停止条件:知道何时退出

第四个组件防止循环变成每个人都害怕的自主 AI 场景:一个永远运行、消耗资源、从不收敛、从不告诉任何人它卡住了的系统。

真正的停止条件有三个状态,而不是两个。

成功。验证步骤通过了既定标准。循环结束了,它应该明确说明,引用通过了什么以及为什么,而不是仅仅默默停止。

有限重试。验证步骤失败了,但循环尚未耗尽重试次数。它再次尝试,理想情况下,从验证步骤获得具体的修正反馈,而不是从头开始,因为针对性修复比完全重新生成收敛得更快,并且不太可能在修复旧问题的同时引入新问题。

升级。重试次数已用完。这是大多数自建系统完全缺失的状态,也是最重要的一个。一个记录良好且有效的模式:将重试次数限制在一个较小数目(三到四次),在最后一次失败时,自动停止并将完整历史记录交给人类——原始任务、每次尝试、每次验证结果、以及一个具体的建议(首先要检查什么)。

这个第三状态如此重要的原因:同一窄任务的四次失败尝试是一个真正有用的信号。它通常意味着任务定义本身含糊不清或不切实际,而不是系统需要第五次尝试。一个带有正确升级机制的循环,将“这个循环可能会永远运行,你永远不知道”转化为“它要么完成,要么在有限次循环内告诉你为什么无法完成”。这种转化就是你可以信任的系统可以无人值守运行,与你必须时刻看管的系统之间的全部区别。

为什么这会不断优化:记忆层

上面描述的只是单个循环周期。让循环真正规模化而非仅仅重复的关键在于跨周期发生了什么——具体来说,就是循环是否有记忆。

没有记忆的循环,在第 100 次和第 1 次循环时做的工作质量相同。有用,但平淡。

有记忆的循环会随着时间的推移可衡量地变得更好,因为每个周期的输出——包括失败以及修正它们的经验——都会反馈到下一个周期可用的上下文中。

这就是在 2026 年 AI 工具讨论中常见的每个“随着每周运行而变得更聪明的第二大脑”说法背后的实际机制。这不是营销口号。它直接描述了当循环存储自己的历史并在下次执行前读取这段历史时会发生什么。一个运行了九十天的晨间简报循环,拥有九十天的项目历史、决策结果和模式数据,而同样在第一天运行的循环却没有。循环架构没有变。积累的记忆变了,而这就是产生改进的原因。

这也是围绕上下文工程所记录的决策质量数字背后的实际机制——从没有持久上下文文档时的 41% 错误率,下降到拥有全面上下文文档时的 3% 错误率。模型在这两种条件之间并没有变得更聪明。它可以使用的上下文变了,而一个设计得当的循环正是自动积累这些上下文的东西,而不是需要人类每次会话重新解释。

在构建良好的循环系统中,有三种实用的记忆模式:

只追加的执行日志。每个周期记录它做了什么、发现了什么、以及如何被评判,写入持久化日志。未来周期在行动前会读取最近的条目。简单、可靠,是一切上层建筑的基础。

周期性整合。原始日志随时间会积累噪音。一个独立的、频率较低的循环读取三十天或九十天的原始条目,并将其综合成更少数量的持久模式或信念——就像月度模式检测周期将数周的每日条目蒸馏成少数几个有名称、有证据支持的观察。没有这一步,记忆只会线性增长到太大而无法有用读取。有了它,记忆会不断优化成真正更聪明的东西,而不仅仅是更大。

显式信念追踪。最先进的模式:维护一小套关于循环操作领域的明确、可证伪的信念,让每个周期检查新信息是确认还是挑战它们。这将记忆从“一堆过去的输出”转变为更接近循环操作的世界的实际演化模型,并且能够标记出它过去相信但不再成立的事物。

反模式:循环实际上如何失败

理解什么会出错与理解什么会正确同样重要,因为失败模式在不同领域之间惊人地一致。

未定义完成的循环。没有明确的标准来定义什么算完成。每个周期自行决定,而这些个别决定从未累积成连贯的完成状态。解决方法是在构建任何东西之前写下完成定义,具体到陌生人可以对照它评估输出而无需提出一个澄清问题。

自我报告循环。上面已经提到过,但值得重复,因为这是最常见的单一失败:信任做工作的同一组件也来评判工作。

无限重试循环。没有重试上限,没有升级路径。系统要么永远运行,消耗资源在一项它无法完成的任务上,要么悄悄放弃而不告诉任何人——这两种情况都比干净的、有界的失败并带有明确升级更糟糕。

失忆循环。没有跨周期的记忆。每次执行从零开始,重复前一百个周期已经犯过并修正过的错误,因为没有将修正向前传递。

过于激进的触发。无论是否有新信息需要处理,都按固定的激进间隔运行,产生噪音、消耗资源,并训练人类操作员忽略循环的输出,因为大部分内容都是重复的无意义信息。

交接缺口。在多步骤或多 Agent 循环中,步骤之间输出从一个组件传递到下一个组件的点,如果没有定义的 schema 或格式,接收步骤就必须猜测它处理的是什么。这就是大多数多步骤系统中复合错误的真正来源——不是任何单独步骤内部,而是在它们之间未定义的空间。

这些反模式中的每一个都直接对应跳过了四个核心组件之一:触发、过程、验证或停止条件。所有六个的修复方法是一样的:始终如一地应用纪律,让每个组件都明确、可测试、且不可能被悄悄跳过。

构建你的第一个循环:一个实战示例

具体优于抽象,所以这里是一个真实且常见任务的完整架构:监控竞争对手的公开内容,寻找具有战略意义的变化。

触发条件:每周两次,周一和周四早上 7 点。这里固定间隔是合适的,因为竞争监控受益于定期检查点,而不是等待可能没有明显信号的特定触发事件。

处理过程:搜索竞争对手过去 3 到 4 天的公开内容。与存储在记忆中的过去 6 周积累的监控笔记进行比较。识别任何代表有意义转变而非日常活动的内容。

验证:在将任何内容标记为重要之前,对照一个明确的标准进行检查:这对密切关注该领域的人来说是否具有新闻价值,并且是否有证据表明方向发生了真正的改变,而不是一个可能是噪音的孤立数据点?用激进营销语言包装的常规产品更新无法通过此检查。跨多个数据点持续数周的一致信息转变则能通过。

停止条件与记忆:每个周期将其发现(包括“本周期无重大发现”的空结果)写入持久化日志。经过六周每周两次的周期,就有了 12 个记录条目。在任何单个周期中不可见的渐进式定位转变,当这些周期被一起阅读时就变得明显——正是那种需要跨多个周期积累数据才能变得可见(更不用说可行)的模式。

这是一个小例子,但上面各节中的每一个架构元素都存在:深思熟虑的触发选择、狭窄的过程范围、防止将噪音标记为信号的验证步骤,以及一个记忆层——这才是该循环运行时间越长越有价值、而不是保持平稳的实际原因。

弥合差距实际上看起来像什么

现在在 AI 领域领先的人——运行生产 Agent 系统的工程师、交付真正能无人值守运行数天的产品的构建者——他们领先并不是因为他们拥有别人没有的模型。2026 年,开放与封闭系统之间的前沿模型差距正在快速缩小,以至于将全部优势押注在模型访问上已经是一个失败策略。

他们领先是因为他们将循环架构理解为一个与提示词不同的独特技能,并且他们在触发设计、验证逻辑和停止条件上投入了有意识的努力,而不是将这些视为不值得关注的实现细节。

这个技能差距正在比模型差距更慢地弥合,而不是更快——这正说明为什么它是现在建立优势的更持久之处。任何人都可以切换到本月基准测试最好的任何模型。但能够查看一个停滞的多 Agent 系统并正确诊断出问题不是模型,而是缺少验证步骤或未定义停止条件的人,要少得多。

这种诊断技能——循环工程的实际纪律——才是可规模化的。不是模型。不是提示词。是围绕二者的架构,经过深思熟虑的设计,而不是偶然的堆积。

本周就使用上面的四组件框架构建一个循环。明确定义触发条件。严格限定过程范围。构建真正的验证,不信任被验证的东西自己去验证。限制重试次数,并在真正运行之前就写好升级路径。

那才是 2026 年每个可扩展的 AI 系统背后的实际技能。从来都不是模型。

一键保存

使用 YouMind AI 深度阅读爆款文章

保存原文、追问细节、总结观点,并在一个 AI 工作空间里把爆款文章沉淀成可复用笔记。

了解 YouMind
写给创作者

把你的 Markdown 变成干净的 𝕏 文章

图片上传、表格、代码块,往 𝕏 上手动重排太痛苦。YouMind 把整篇 Markdown 一键转成干净、可直接发布的 𝕏 文章草稿。

试试 Markdown 转 𝕏

更多可拆解样本

近期爆款文章

探索更多爆款文章