“我们还在讨论循环，还是已经转向图了？” 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 之间的协作结构。
