“我们还在讨论循环,还是已经转向图了?” 2026 年 7 月 18 日,Peter Steinberger 在 X 平台上发出的这一疑问,悄然宣告了循环工程时代的终结。这条帖子在发布两天内便获得了 260 万浏览量。回溯六周前,他关于“设计能提示 Agent 的循环”的帖子曾获得 840 万浏览,让全球开发者意识到提示工程的时代正在过去,循环工程才是新的方向。这两条帖子累计浏览量超过 1100 万,将 AI 编程领域的讨论推向了下一个关键节点。
**循环的崛起与 Ralph 的诞生**
循环工程的崛起并非偶然,其真正的起源可以追溯到一年前。2025 年 7 月,软件工程师 Geoffrey Huntley 提出了一种被他称作“Ralph”的方法。这是一种简单的 Bash 循环脚本,能让 Claude 反复执行任务直到目标达成:`while :; do cat PROMPT.md | claude-code ; done`。Ralph 方法的核心在于突破上下文窗口的限制。当时上下文窗口最大仅为 20 万 Token,对于复杂任务来说远远不够,因此需要将 Agent 运行拆分为更小的运行单元,逐个执行。
在这种背景下,Ralph 的工作方式如下:为项目设定目标,持续运行或重运行 Agent 直到目标实现;将已完成的工作以“压缩”形式持久化到文件系统,如保存为日志或更新后的计划;启动全新的上下文运行 Agent,以尽量减少“上下文腐化”;在必要时,允许每个 Agent 添加或修改“总体计划”。Huntley 用此方法从零构建了一门编程语言,验证了可行性。但随着更强模型的出现,它才在开发者圈迅速传开。
**从概念到基础设施**
循环工程的爆火离不开 Anthropic 和 OpenAI 核心开发者的推动。最早是在 Anthropic 的开发者大会上,Claude Code 的创造者 Boris Cherny 表示:“我现在已经不再提示 Claude 了。我运行的是一些循环,由这些循环去提示 Claude,并判断接下来该做什么。我的工作是编写循环。”随后,Peter Steinberger 也呼吁开发者停止直接提示编程 Agent,转而设计能够提示 Agent 的循环。前 Google 工程师 Addy Osmani 随后撰写文章,将其概括为:“循环工程,就是让自己退出亲自提示 Agent 的位置,转而设计一个替你完成这件事的系统。”
概念有了,名字有了,基础设施也迅速跟进。2026 年 4 月至 5 月,Codex、Claude Code、Hermes 相继推出 `/goal` 命令,将手工编写的循环产品化为一条指令。Codex 文档写道:“Goals 是 Codex 中持久存在的目标,可以让一个对话线程在多轮交互中持续朝着明确的结果推进。Goal 会为 Codex 提供一个完成条件:什么状态应该成立、如何检查是否成功,以及哪些约束必须始终得到保留。”
文档特别指出:“普通提示词表达的是:接下来做这件事。Goal 表达的是:继续工作,直到这个结果成立。”在普通请求中,Codex 会处理当前指令,汇报结果,然后等待下一步。而在使用 Goal 时,线程上会附着一个持久目标。一轮执行结束后,它可以检查当前证据,判断目标是否已经完成。如果答案是否定的,且 Goal 仍处于激活状态、预算未耗尽,Codex 就可以从最新状态继续工作。例如:“在保证正确性测试套件始终通过的前提下,将结账基准测试中的 p95 延迟降低到 120 毫秒以下。”这是一个清晰的“结束标准”,可以直接交给 Agent。Codex 团队借鉴了 Ralph 循环的思路,构建了协调多个 Agent、管理状态、运行测试、启动和停止 Agent 的基础设施,并增加了预算设置等功能。
**实战应用:从周期性任务到大规模迁移**
开发者实际在用循环做什么?根据社区反馈,最常见的场景是处理周期性工作,但其能力远不止于此。真正体现循环工程价值的,是那些需要持续迭代的长期任务。例如完成大规模代码迁移。创业公司创始人 Rafel Mendiola 需要将一个 React 应用转换成 React Native。传统做法是创建一个大型 Epic,再拆分出 50 到 100 张工单,仅搭建基础设施就令人望而却步。他的替代方案是创建一个 Skill,让 Agent 识别可迁移的代码块,完成转换并追踪进度,然后将这个 Skill 放进每 30 分钟运行一次的 Cron 定时任务里。相比管理一份庞大的迁移计划,这种方式在认知上轻松得多。
**下一站:从 Loop 到 Graph**
Peter 的推文问题实际上指向了一条演进路径。一年前,提示工程还是核心技能;到了 2025 年至 2026 年初,重心转移到了设计循环;而现在,Peter 所指向的是更远的地方:设计由多个循环组成的图——每个 Agent 运行自己的循环,通过依赖关系彼此连接。讨论串中最精彩的回复来自 Luis Catacora:“循环有很大的容错空间。图会迫使你承认,工作流中还有多少部分根本没有被真正建模。”这句话深刻体现了两种范式的区别。循环允许你推迟架构设计:先让一个 Agent 包揽所有工作,直到它再也处理不了为止。图则要求你提前声明整个结构——谁负责什么,哪些任务依赖哪些任务,某个分支失败后该怎么办。循环是延期决策,图是提前决策。
Google 高级 AI 产品经理、Awesome LLM Apps 代码库作者 Shubham Saboo 区分了两个层次:“长期存在的组织图定义谁负责哪个领域并保留上下文;工作图定义当前需要做什么,可以根据证据拆分、合并、重新排序或直接消失。”他说:“Loop 让 Agent 的行为变得可编程。Graph 让 Agent 组织变得可编程。”再往前一步是动态 Agent 组织:任务执行过程中,Graph 会自行改写自身结构。
Preston Holmes 认为,至少有两种 Graph 很重要。第一种是你图中展示的、由长期存在的 Agent 组成的 Graph,它们像区域联防一样,各自负责一个区域。第二种是需要完成的工作所形成的 Graph。它是动态的,会不断变化。Shubham Saboo 进一步解释,长期存在的“组织图”决定由谁负责每个区域,并负责保留上下文。“工作图”决定当前需要完成什么任务。随着新证据出现,它可以拆分、合并、重新排序,或者直接消失。这是生产级多 Agent 系统的关键:实际上有两张图在同时运行。组织图定义“谁负责什么”,它由长期存在的 Agent 组成,每个 Agent 负责一个固定领域,保留该领域的上下文、专业能力和工具权限。它相对稳定,类似公司的组织架构。工作图定义“现在要做什么,以及任务如何流转”,它会随着任务和新证据不断变化,可以拆分、合并、调整顺序或直接取消,更像实时生成的项目计划。Preston Holmes 也认为这两张图都很重要,且运行在不同的时间尺度上。组织图会被预先设计并部署;工作图则针对每项任务动态生成,并在任务完成后丢弃。
如果说循环让 Agent 的行为变得可编程,那么图让 Agent 组织变得可编程。再往前一步是动态 Agent 组织——任务执行过程中,图会自行改写自身结构。从写好 Prompt,到设计 Loop,再到构建 Graph,AI 编程的能力重心正在持续上移。开发者越来越不需要关心如何与单个 Agent 对话,而是需要思考如何设计 Agent 之间的协作结构。
