“我们还在讨论循环，还是已经转向图了？”

2026 年 7 月 18 日，Peter Steinberger 在 X 平台上用这一句话，悄然宣告了循环工程时代的终结。这条帖子在发布后的两天内获得了 260 万浏览。

六周前，他用“设计能提示 Agent 的循环”获得了 840 万浏览，让全球开发者意识到提示工程的时代正在过去，循环工程才是新的方向。

两条帖子，累计浏览量超过 1100 万次，把 AI 编程领域最热门的讨论推向了下一个节点。

循环的崛起

过去一个月，“Loop Engineering（循环工程）”迅速成为 AI 编程领域的热门概念。

但它真正的起源，要追溯到一年前。2025 年 7 月，软件工程师 Geoffrey Huntley 提出了一种被他称作“Ralph”的方法——一个简单的 Bash 循环，让 Claude 反复执行任务直到目标达成：

while :; do cat PROMPT.md | claude-code ; done

Ralph 方法的核心在于绕过上下文窗口的限制。当时是 2025 年中期，上下文窗口的最大为 20 万 Token。这对于更复杂的任务来说远远不够，因此需要将 Agent 运行拆分为更小的运行单元，然后逐个运行。

在这种背景下，Ralph 方法的运作方式如下：

• 为项目设定一个目标，然后持续运行或重新运行 Agent，直到实现目标。
• 以“压缩”形式将已经完成的工作持久化到文件系统中，例如保存为日志或更新后的计划。
• 使用全新的上下文启动 Agent，从而尽量减少“上下文腐化”。
• 在必要时，允许每个 Agent 添加或修改“总体计划”。

Huntley 用这个方法从零构建了一门编程语言，验证了可行性。但直到更强模型出现后，它才在在开发者圈子里迅速传开。

Loop 的爆火也离不开 Anthropic 和 OpenAI 的一些核心开发者。最开始是在 Anthropic 的开发者大会上，Claude Code 的创造者 Boris Cherny 表示：“我现在已经不再提示 Claude 了。我运行的是一些循环，由这些循环去提示 Claude，并判断接下来该做什么。我的工作是编写循环。”

随后，Peter Steinberger 也发帖呼吁开发者停止直接提示编程 Agent：“每月提醒一次：你不应该再亲自提示编程 Agent 了。你应该设计能够提示 Agent 的循环。”

前 Google 工程师 Addy Osmani 随后还专门撰写了一篇题为《Loop Engineering》的文章，将其概括为：“循环工程，就是让自己退出亲自提示 Agent 的位置，转而设计一个替你完成这件事的系统。”

概念有了，名字有了，基础设施也迅速跟进。

2026 年 4 到 5 月，Codex、Claude Code、Hermes 相继推出 /goal 命令，把手工编写的循环产品化为一条指令。

在 Ralph 开始广泛应用约六个月后，Codex 发布了 goal 功能

Codex 文档写道：“Goals 是 Codex 中持久存在的目标，可以让一个对话线程在多轮交互中持续朝着明确的结果推进。Goal 会为 Codex 提供一个完成条件：什么状态应该成立、如何检查是否成功，以及哪些约束必须始终得到保留。”

文档特别指出：“普通提示词表达的是：接下来做这件事。Goal 表达的是：继续工作，直到这个结果成立。”

在普通请求中，Codex 会处理当前指令，汇报结果，然后等待下一步。在使用 Goal 时，线程上会附着一个持久目标。一轮执行结束之后，它可以检查当前证据，并判断目标是否已经完成。如果答案是否定的，并且 Goal 仍然处于激活状态、预算也没有耗尽，Codex 就可以从最新状态继续工作。

比如：“在保证正确性测试套件始终通过的前提下，将结账基准测试中的 p95 延迟降低到 120 毫秒以下。”

这是一个足够清晰的“结束标准”，可以直接交给 Agent。随后，Agent 会自行拆分任务、创建子 Agent，并持续运行，直到工作完成。Codex 团队借鉴了 Ralph 循环的思路，在此基础上构建了基础设施：协调多个 Agent，避免它们彼此干扰；管理状态；运行测试；启动和停止 Agent；随后又增加了预算设置等功能。

Goals 功能的架构

开发者如何使用循环

那开发者实际在用循环做什么？根据社区反馈，最常见的场景还是处理一些周期性工作。

但循环的能力远不止于此。真正体现循环工程价值的，是一些更复杂的、需要持续迭代的长期任务。

比如完成大规模代码迁移。创业公司创始人 Rafel Mendiola 需要将一个 React 应用转换成 React Native。传统做法是创建一个大型 Epic，再拆分出 50 到 100 张工单，光是搭建基础设施就让人望而却步。

他的替代方案是创建一个 Skill，让 Agent 自己识别可迁移的代码块，完成转换并追踪进度，然后把这个 Skill 放进每 30 分钟运行一次的 Cron 定时任务里。与管理一份庞大的迁移计划相比，这种方式在认知上轻松得多。

下一站：Graph

Peter 的推文问题实际上指向了一条演进路径。

一年前，提示工程还是核心技能。到了 2025 年到 2026 年初，重心转移到了设计循环。而现在，Peter 所指向的已经是更远的地方：设计由多个循环组成的图——每个 Agent 运行自己的循环，通过依赖关系彼此连接。

他这条推文的讨论串中最精彩的回复来自 Luis Catacora：“循环有很大的容错空间。图会迫使你承认，工作流中还有多少部分根本没有被真正建模。”

这句话能体现出这两种范式的区别。循环允许你推迟架构设计：先让一个 Agent 包揽所有工作，直到它再也处理不了为止。图则要求你提前声明整个结构——谁负责什么，哪些任务依赖哪些任务，某个分支失败后该怎么办。循环是延期决策，图是提前决策。

Google 高级 AI 产品经理、Awesome LLM Apps 代码库（GitHub 上超过 12.4 万颗星）的作者 Shubham Saboo，给出了另一个拆解，他区分了两个层次：“长期存在的组织图定义谁负责哪个领域并保留上下文；工作图定义当前需要做什么，可以根据证据拆分、合并、重新排序或直接消失。”

Graph 到底是什么鬼？

Loop 让 Agent 的行为变得可编程。Graph 让 Agent 组织变得可编程。

再往前一步是动态 Agent 组织：任务执行过程中，Graph 会自行改写自身结构。

Preston Holmes：至少有两种 Graph 很重要。第一种是你图中展示的、由长期存在的 Agent 组成的 Graph，它们像区域联防一样，各自负责一个区域。第二种是需要完成的工作所形成的 Graph。它是动态的，会不断变化。

Shubham Saboo：长期存在的“组织图”决定由谁负责每个区域，并负责保留上下文。“工作图”决定当前需要完成什么任务。随着新证据出现，它可以拆分、合并、重新排序，或者直接消失。

这是生产级多 Agent 系统的关键：实际上有两张图在同时运行。

组织图（Org Graph）：定义“谁负责什么”。它由长期存在的 Agent 组成，每个 Agent 负责一个固定领域，保留该领域的上下文、专业能力和工具权限。组织图相对稳定，类似公司的组织架构。

工作图（Work Graph）：定义“现在要做什么，以及任务如何流转”。它会随着任务和新证据不断变化，可以拆分、合并、调整顺序或直接取消。工作图更像实时生成的项目计划。

Preston Holmes 也认为两张图都很重要，而且它们运行在不同的时间尺度上。组织图会被预先设计并部署；工作图则针对每项任务动态生成，并在任务完成后丢弃。

如果说循环让 Agent 的行为变得可编程，那么图让 Agent 组织变得可编程。再往前一步是动态 Agent 组织——任务执行过程中，图会自行改写自身结构。

从写好 Prompt，到设计 Loop，再到构建 Graph，AI 编程的能力重心正在持续上移。开发者越来越不需要关心如何与单个 Agent 对话，而是需要思考如何设计 Agent 之间的协作结构。

参考链接：

https://x.com/i/trending/2077885008564646115