大多数人仍然手动使用 AI。
他们输入一个提示。
他们等待一个答案。
他们自己审查输出。
他们注意到哪里出错了。
他们写另一个提示。
然后他们再次重复整个过程。
感觉就像是人工智能在做这些工作。
但如果你仔细看，人类仍然是引擎。
人类决定接下来要问什么。
人类检查答案。
人类记住失败的地方。
人类推动每一个新步骤。
那就是与人工智能合作的老方法。
新方法有所不同。
你不仅仅是提示代理。你是围绕代理设计循环。
一个循环为人工智能提供了一个目标、正确的上下文、行动方式、验证结果的方法以及下一步该做什么的规则。如果结果失败，循环会将其返回以再次处理。如果结果成功，循环就会停止。
这种转变被称为循环工程。
提示给 AI 一个指令。
循环工程给 AI 一份工作。
一个提示产生一个答案。
一个循环会不断运行，直到结果通过。
这就是整个想法。
没有一个完美的提示。
没有一次幸运的输出。
没有一段长对话是你手动推动模型前进的。
循环是一个可重复的系统，从尝试到验证结果的过程。
循环到底是什么
循环是AI代理的反馈循环。
基本的形式很简单：
发现。
计划。
执行。
验证。
迭代。
先系统确定需要做什么。
然后它规划下一步。
然后代理采取行动。
然后检查结果。
如果结果足够好，循环停止。
如果不够好，输出回到系统中，下一轮迭代开始。
这就是人工智能如何从被动工具变成工作流程。
普通的提示会说：
「帮我写这个。」
一个循环会说：
「朝着这个目标努力。检查你的结果。修正失败的部分。继续前进，直到结果达到标准，或者在达到极限时停止。」
最后这一部分很重要。
真正的循环不会永远运行。它需要一个停止条件。
没有停止条件，你建造了一台可以整晚消耗代币却仍然一无所获的机器。
一个好的循环总是知道两件事：
成功是什么样子。
什么时候该放弃。
这就是区别于高成本混乱的高效 AI 循环的原因。
为什么循环现在很重要
在过去几年里，主要技能是提示工程。
提示越好，答案越好。
当人工智能主要一次只处理一步时，这是有道理的。你给模型一个任务，模型会给你一个回应。
但是智能体就不同了。
代理可以读取文件。
使用工具。
运行代码。
搜索来源。
打开拉取请求。
编写草稿。
检查结果。
调用其他代理。
跨多个步骤继续操作。
一旦人工智能可以执行多个步骤，最高杠杆技能将不再仅仅是编写更好的提示。
杠杆向上提升一个级别。
新的问题不是：
「我如何更好地向模型提问？」
新的问题是：
「我如何设计一个系统，让模型工作、进行自我检查、改进，并正确停止？」
那是循环工程。
提示工程师改进单个指令。
循环工程师设计围绕代理的反馈系统。
起初看起来差别很小，但它改变了一切。
提示工程师说：
「编写一个函数。」
一位循环工程师说：
「阅读问题，检查代码，编写最小的修复，运行测试，修复失败，当测试套件通过时停止，并总结所做的更改。」
相同的模型。
相同的工具。
不同的系统。
系统才是杠杆所在。
你真的需要一个循环吗？
这是大多数人出错的地方。
循环听起来很强大，所以人们尝试循环所有东西。
那是一个错误。
并非每个任务都值得使用循环。实际上，大多数任务不需要。
只有当任务通过一个简单的测试时，才值得建立循环。
有四个问题。
第一个：这个任务会重复吗？
如果任务只发生一次，好的手动提示通常更快。循环有设置成本。只有当任务定期出现时才有意义：每天，每周，每次拉取请求，每张新票，每次新报告，每封新邮件。
第二：结果可以自动验证吗？
这是最重要的条件。
对于代码，验证可以是测试、代码检查、类型检查或构建。
对于研究，它可以是源检查、论点验证或冲突来源比较。
对于内容，它可以是一个严格的评分标准。
对于操作，它可以是一个可测量的条件：工单已创建，电子邮件已发送，报告已生成，数字超过阈值，警报已解决。
如果没有办法自动拒绝错误的结果，那么人类仍然是真正的验证者。如果人类仍然必须从头检查每一个输出，那么这个循环并没有节省太多。
第三：代理能否实现端到端操作？
一个循环需要代理实际去完成工作。
如果代理每两分钟就需要向你请求许可或缺失的上下文，它实际上并没有真正运行循环。它仍然是带有 AI 协助的手动工作。
第四：「完成」是客观的吗？
「测试通过」是客观的。
「构建是绿色的」是客观的。
「摘要包括所有必填字段」是客观的。
「文章感觉很好」不是客观的。
「设计很漂亮」不是客观的。
「策略是正确的」不是客观的。
当成功可以被清楚地衡量时，循环效果最好。
如果遗漏了其中一个步骤，请保留任务手册。
不要仅仅因为循环听起来很高级就去构建它们。
当工作具有重复性、可验证性、可操作性且有界限时，再去构建循环。
一个良好循环的构建模块
循环不仅仅是一个代理重复自身。
循环是围绕代理的系统。
代理只是其中的一部分。
一个有效的循环通常需要六个构建模块。
第一个模块是自动化。
自动化是核心。它可以在你无需手动启动的情况下开始循环。
那个触发器可以是一个时间表、一个事件或一个条件。
每天早上。 每个星期五。 当拉取请求开启时。 当持续集成失败时。 当收到新邮件时。 当出现新的Linear工单时。 当文件发生变化时。 当报告到期时。
没有自动化时，循环只有在你启动它时才会运行。这仍然有用，但它不是完整版本。
第二个区块是上下文。
代理需要知道什么是重要的。
对于编码循环，上下文可能包括架构文档、仓库规则、测试命令、编码规范以及它绝不能触碰的文件。
对于写作循环，上下文可能包括受众、语气、示例、结构和质量标准。
对于一个研究循环，背景可能包括问题、来源要求、信心阈值，以及如何处理冲突信息。
没有可重用的背景，每次循环都是从零开始。
有了可重用的背景，循环会随着时间变得更智能。
第三个模块是行动。
循环不仅应该建议做什么。它还应该能够完成工作。
那可能意味着编辑代码、运行测试、开启拉取请求、创建工单、更新文档、发送总结或起草消息。
这是助手和代理之间的区别。
助手会说：
「这是我会做的事情。」
代理循环会说：
「我做了，检查了，这就是结果。」
第四个模块是验证。
这是循环的核心。
没有验证，重复不是进步。它只是代理不断地同意自己而已。
验证者可以是测试套件、类型检查器、代码检查工具、构建工具、评分标准、事实核查过程，或一个独立的审查代理。
重要的是，糟糕的工作可能会失败。
一个循环需要一个门。
没有门，就没有真正的循环。
第五个模块是状态。
模型会忘记。文件不会。
一个长时间运行的循环需要记住之前发生的事情。
它尝试了什么？
什么失败了？
什么成功了？
还有什么未完成？
下次应该避免什么？
什么需要人工审查？
那个记忆可以存在于 markdown 文件、项目日志、GitHub 问题、Linear 工单、数据库或共享文档中。
具体格式不如原则重要。
状态必须存在于模型之外。
如果循环没有将状态写入某处，每次运行都从零开始。
第六个块是一个停止条件。
每个严肃的循环都需要一个停止规则。
停止条件有两种类型。
成功停止：
「所有测试通过。」
「报告已完成。」
「草稿得分 8 / 10 或更高在每个标准上。」
「工单已创建并关联。」
「源检查通过。」
失败停止：
「在 5迭代后停止。」
「在 30 分钟。"
「在用完这个令牌预算后停止。」
「如果权限缺失则停止。」
「如果同样的错误发生两次则停止。」
一个好的循环知道何时继续。
一个优秀的循环也知道何时停止并寻求帮助。
单代理循环 vs 舰队循环
循环有两种基本尺寸。
单代理循环和舰队循环。
单代理循环使用一个代理来运行整个周期。
它发现需要做的事情，计划工作，执行，验证，并改进。
这最适合范围较小的集中任务。
示例：
重写草稿直到通过评分标准。
修复一个失败的测试。
总结一个研究主题。
清理一个小型代码文件。
分拣一个简单的问题。
生成每周报告。
一个代理。
一个循环。
一个专注的任务。
一个舰队循环更大。
一个协调者负责主要任务。它将工作分解成部分，并将这些部分发送给专业代理。
例如：
一个研究代理负责寻找来源。
一个工程代理负责编写代码。
一个质量保证代理负责测试输出。
一个评审代理负责检查边界情况。
一个总结代理负责撰写最终报告。
这更像是一个小型人工智能团队，而不是一个人工智能工作者。
车队循环很强大，但它们也更昂贵且更难控制。
每增加一个代理都会消耗代币。
每增加一个角色都会增加协调成本。
每增加一个分支都会产生更多需要验证的结果。
所以规则很简单：
从单代理循环开始。
只有当任务足够大以至于需要专家时，才转向舰队循环。
当一个好的循环就能完成工作时，不要构建群体。
创建者和检查者不应是同一个代理
最重要的循环模式之一是制作者-检查者分离。
创建工作的代理不应是唯一验证该工作的代理。
为什么？
因为模型在评判自己的工作时往往过于宽容。
模型编写代码并说服自己修改是正确的。
模型撰写文章时遗漏了薄弱的论点。
模型总结研究内容时忽略了来源冲突。
模型起草计划，并假设模糊的部分是清楚的。
这并不是因为模型无用。
而是因为自我审查能力较弱。
人类也有同样的问题。
写这个东西的人通常不是最适合审查这个东西的人。
一个更强的循环区分了角色。
创建者：
创造输出。
检查者：
根据目标审核输出。
检查器可以是一个独立的模型、一个更严格的提示、一个不同的工具、一个测试套件，或者一个人工审批步骤。
对于代码，检查器可能是自动化测试。
对于写作，检查器可能会评分清晰度、结构、具体性和原创性。
对于研究，检查者可能会将每个声明与来源核对。
对于操作，检查者可能会确认任务确实在外部工具中发生。
这种分离提高了质量，因为循环不再仅依赖于模型批改自己的作业。
但这有一个权衡。
制作-检查循环成本更高。
两个代理意味着更多的令牌。
更多的验证意味着更多的时间。
更多的上下文意味着更大的运行。
所以在质量重要的地方使用它。
不要在只需要简单门控的任务上花费审阅者代理的令牌。
开放循环 vs 闭环
还有一个重要的区别：开放循环和闭合循环。
开放循环给代理一个广泛的目标，并让它进行探索。
例子：
「寻找改进此产品的方法，并实施最佳的创意。」
听起来很令人兴奋。
但未完成的循环很混乱。
它们可能探索太多路径。
它们可能偏离目标。
它们可能快速消耗代币。
它们可能产生大量仍需人工审查的输出。
它们可能混淆活动和进展。
开放回路对于探索是有用的，但它们不是最好的起点。
闭合回路是有界的。
路径是清晰的。
检查是明确的。
停止条件是明确的。
范围是有限的。
示例：
「每周一，检查依赖更新。对于每个安全更新，提交一个PR。运行测试。如果测试通过，保留PR进行审查。如果测试失败，记录失败并停止。」
这是一个封闭循环。
它不那么光鲜，但实用得多。
闭环系统更便宜。
闭环系统更容易调试。
闭环系统更安全。
闭环系统产生的结果更干净。
从闭环系统开始。
一旦你的验证足够强，你的权限受到控制，你的状态可靠，并且你的代币成本被理解，那么你就可以更开放地使用循环。
可靠性优先。
自主性随后。
最小可行的编码循环
代码是最先使循环变得明显的地方。
原因很简单：代码是可以被检查的。
测试通过或失败。
构建成功或失败。
类型检查通过或失败。
代码风格检查器返回干净或不干净。
这给代理一个真实的信号。
一个基本的编码循环看起来像这样：
阅读上下文。
计划最小的有用改动。
编辑代码。
运行测试。
阅读失败情况。
修复根本原因。
再次运行测试。
当测试通过时停止。
总结所做的更改。
这不是魔法。
这只是一个反馈循环。
但它很强大，因为人类不再需要手动推进每一个步骤。
旧的工作流程：
你让代理修复某些东西。
它给你代码。
你运行测试。
你把错误粘回去。
它再试一次。
你再次运行测试。
你粘贴另一个错误。
它再试一次。
新的工作流程：
循环读取错误，修复代码，运行测试，并重复进行，直到门通过或循环达到限制。
人类仍然会审核最终结果。
但是，人类不再是那个手动将每个失败从一个步骤带到下一个的人。
那就是杠杆。
有用循环的真实例子
最好的初始循环很无聊。
那是一件好事。
无聊的循环更容易验证。
CI 分类循环：
每天早上，扫描失败的 CI 作业。将每个失败分类为环境问题、不稳定测试、真实 bug、依赖问题或基础设施问题。为简单且确定性的失败起草修复方案。将其余问题升级处理。
依赖更新循环：
每周检查安全包更新。每次应用一个更新。运行测试。如果一切顺利，打开一个拉取请求。如果出现问题，记录失败情况。
一个lint和修复循环：
当拉取请求打开时，运行格式化程序和代码检查工具。应用安全的样式修复。再次运行检查。清理完成时停止。
一个研究循环：
从一个研究问题开始。搜索资料来源。提取论点。根据资料来源验证论点。比较冲突的信息。仅在核查关键论点后撰写总结。
一个内容循环：
从一个主题、受众和目标开始。起草文章。根据评分标准进行批评。重写最薄弱的部分。再次评分。当文章达到标准或达到迭代上限时停止。
收件箱循环：
每天早上，阅读新的重要电子邮件和日历事件。识别紧急消息、需要准备的会议以及已逾期的跟进事项。发送一份简短的简报。
一次销售外展循环：
查找符合理想客户画像的潜在客户。丰富每个公司的信息。根据明确的标准进行资格审查。起草个性化信息。进行质量审查。仅当信息通过审核或转交给人工时才发送。
骨架始终相同：
目标。
背景。
行动。
验证。
状态。
下一步行动。
停止条件。
一旦你看到那个模式，循环设计就会容易得多。
没有人愿意谈论的成本
循环不是免费的。
每次迭代都消耗代币。
每次重试都消耗代币。
每次验证都消耗代币。
每个子代理都消耗代币。
每次上下文刷新都消耗代币。
而且成本会复合增加。
运行十次的循环不仅仅是十个普通提示。
每一次迭代可能包含原始任务、当前状态、之前的失败、工具结果、代码片段、日志以及下一个指令。
上下文在增长。
账单随之增长。
这就是令牌预算重要的原因。
一个中等规模的编码循环可以消耗大量令牌。
一个拥有多个代理的循环可以消耗更多。
一个每天运行的定期循环可能悄悄成为一个持续的成本中心。
重要的指标不是：
「我们运行了多少次循环？」
重要的指标是：
「每个被接受结果的成本是多少？」
每个被接受结果的成本才是真正的数值。
如果你的循环产生十个输出而你拒绝了其中七个，循环并没有为你节省工作。这是在制造审查债务。
如果你的循环打开了五个拉取请求而你只合并了一个，这个循环可能比手动工作更昂贵。
如果你的循环生成的每日报告没人看，那它只是自动化的噪音。
一个好的循环应该减轻人类的负担。
一个糟糕的循环会产生更多需要人工清理的东西。
无声的失败模式
糟糕的循环往往不会大声报错。
它们会悄悄地失败。
代理声称已完成，但实际上没有完成。
验证者过于宽松。
循环重复同样的错误。
状态文件未得到更新。
输出看起来合理，但不完整。
系统在消耗大量代币的同时产生的价值很少。
这是代理循环中最危险的事情之一。
一个普通的脚本会崩溃。
一个糟糕的循环可能会自信地继续。
这就是为什么硬门控很重要。
测试套件比「评论一下」更好。
类型检查器比「看起来不错」更好。
严格的评分标准比「改进它」更好。
人工审批步骤比静默部署更好。
循环在适当的地方需要摩擦。
重点不是完全去除人类。
重点是将人类从重复的操作中移出，同时保持他们对判断、审查和不可逆行为的控制。
潜在风险：理解债务
除了代币之外，还有另一种成本。
理解负债。
循环产生工作的速度越快，你的理解就越容易落后。
在代码中尤其如此。
如果一个代理循环每天都打开拉取请求，而团队在没有仔细阅读的情况下合并它们，代码库的更新速度将超过人类的理解能力。
起初，这会让人觉得有生产力。
后来，这就会成为一个问题。
出现了一个错误。
没有人知道代码为什么是那样编写的。
代理修改了五个文件，没有人完全阅读过。
测试通过了，但架构变得更糟。
系统可以运行，但团队不理解它。
那就是理解债务。
循环在前期节省了时间，但未来会产生调试成本。
解决方法不是避免使用循环。
解决方法是设计时给它们设置限制。
阅读差异。
在小任务上保持循环。
使用客观门控。
阻止敏感区域。
定期审查权限。
不要让代理单独做出架构决策。
不要仅因为可以就自动化判断决策。
循环工程并不意味着放弃你的思考。
它意味着决定哪里最需要思考。
哪些不应该循环
有些任务是糟糕的首次循环。
架构重写。
认证逻辑。
支付。
生产部署。
法律建议。
医疗建议。
公司战略。
招聘决策。
品牌品味。
任何「完成」主要依赖判断的事情。
人工智能仍然可以帮助处理这些任务。
但是人类应该保持靠近。
当工作狭窄、重复且可检查时，循环最强。
当工作模糊、高风险且主观时，循环最弱。
那就是界限。
不要用循环来避免思考。
使用循环来避免手动重复那些可以安全检查的步骤。
如何构建你的第一个循环
不要从一个庞大的系统开始。
从一个小循环开始。
一个重复的任务。
一个上下文来源。
一个动作。
一个验证者。
一个状态文件。
一个停止条件。
顺序很重要。
先手动运行任务。
确保你理解这些步骤。
然后将这些指令变成一个可重复使用的技能或保存的提示。
然后添加一个验证机制。
然后添加状态。
然后添加自动化。
在一次手动运行可靠工作之前，不要安排任何任务。
这就是循环在你睡觉时崩溃的方式。
最小可行循环按设计来说很无聊。
例如：
任务：
修复一个失败的测试。
上下文：
阅读问题、相关文件和测试输出。
操作：
进行最小的代码修改。
验证者：
运行测试。
状态：
记录失败的内容、更改内容以及仍需审查的内容。
停止条件：
测试通过时停止，或在尝试五次后停止。
那就够了。
你不需要十个代理。
你不需要复杂的协调器。
你需要一个能够生成一个被接受结果的紧密循环。
然后你可以扩展。
一个简单的自我检查循环，你可以手动使用
你可以通过一个提示感受到任何大型语言模型中的循环模式。
这不是完全自动化，因为你仍然需要手动启动它。
但它可以教你结构。
使用类似这样的东西：
那是循环的最简单版本。
它不需要工具。
它不需要安排时间。
它不需要多个代理。
它只是将模式从：
「只回答一次。」
改为：
「工作，检查，改进，然后停止。」
这种思维的转换是关键部分。
循环工程师的真正工作
循环工程师并不是让人工智能永远运行的人。
那不是目标。
目标是可控自治。
循环工程师决定：
是什么启动了循环。
代理会获得什么上下文。
它可以使用什么工具。
允许哪些操作。
什么算作成功。
什么会导致工作失败。
必须保存什么状态。
循环什么时候应该停止。
什么时候必须由人类审查。
循环绝不能触碰什么。
这就是为什么循环工程不仅仅是提示。
它更接近于工作流设计。
你不仅仅是在编写指令。
你是在设计一个环境，使智能体能够安全地产生有用的工作。
这意味着最优秀的循环工程师不是那些盲目自动化一切的人。
他们是那些知道什么不应该自动化的人。
思维方式的转变
旧的思维方式：
「我需要一个更好的提示。」
新的思维方式：
「我需要一个更好的循环。」
更好的提示可以改进一次输出。
更好的循环可以改进创造输出的过程。
这就是为什么这项技能很重要。
未来不仅仅是人们在聊天框中输入巧妙的提示。
未来是人们设计系统，将杂乱的尝试反复转化为经过验证的结果。
循环就是产品。
提示只是其中的一部分。
最终的想法
循环工程是从手动提示转向自动反馈循环的转变。
这并不意味着人类会消失。
这意味着人类不再手动驱动每一个小步骤。
人类定义目标。
人类设定界限。
人类设计验证器。
人类审查高风险工作。
循环处理重复。
糟糕的循环消耗代币并制造噪音。
良好的循环节省注意力。
一个好的循环知道该做什么，如何自我检查，什么时候重试，什么时候停止，以及什么时候呼叫人类。
那才是真正的解锁。
不要再试图写出一个完美的提示。
构建能够让不完美输出变得更好的循环。
一个可靠的循环胜过完美的提示。
如果你读到这里：
-
收藏这个。
-
关注 @LunarResearcher
把第一个循环限制在一个小任务里：一次输入、一次可检查输出、一个明确上限。跑稳之后，再扩大范围。
把循环改造成可交接的本地流程
一个可靠循环至少要回答：本轮读什么、允许改什么、用什么检查、失败后怎样修复、最多重试多少次、什么时候交给人。预先确定路径的工作流和动态选择过程与工具的代理并不相同，不必把所有自动化都包装成「智能代理」。
Claude Code 的 Stop hook 可以在结束前调用检查逻辑，例如运行测试；HTTP hook 则可以把事件数据发送到指定端点。 这些机制能承载验证和通知，但不能替你定义什么才算完成。Codex 的 harness 同样负责在用户、模型与工具之间协调代理循环。
独立子任务可以并行，有依赖的步骤仍然要排序并共享状态。 没有可靠自动验收的高风险任务，不适合完全无人值守。
本地试跑时，请把权限限制到专用工作目录，固定预算和最大轮数，每轮保存输入、修改、命令输出与检查结果。只要检查器无法给出明确通过，循环就应停止，而不是用模型自己的「完成了」作为证据。