先说几个核心判断：提示工程正在加速退场，循环工程已经成了当下真正的主旋律。而接下来，更值得关注的，是图结构——一个由多个循环构成的网络，每个Agent运行独立循环，彼此通过依赖关系耦合联动。

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的运行过程拆成更小、更可控的单元，再通过循环的方式依次推进。

典型的工作流是这样的：

• 明确项目的终极目标，持续启动或重启Agent，直到目标落地；
• 把已完成的结果以“压缩态”持久化到文件系统，比如日志记录或计划更新；
• 每次启动Agent时都用全新的上下文，最大限度避免“上下文污染”；
• 允许各Agent在必要时增删或调整全局计划，保持灵活性。

Huntley曾经用这个方法从零构建了一门编程语言，证明了它的可行性。但直到更强力的模型出现，这套思路才真正破圈，在开发者社区广泛传播开来。

循环的走红，也离不开Anthropic和OpenAI核心成员的背书。最早在Anthropic开发者大会上，Claude Code的主创Boris Cherny公开表示：“我现在已经不再手动提示Claude了。我运行的是若干循环——由它们来调用Claude、评估结果、决定下一步动作。我的角色，是编写这些循环。”

随后，Peter Steinberger也在社交平台呼吁：“每月提醒一次：请停止亲手提示编程类Agent。你该做的，是设计一个能替你提示Agent的循环系统。”

前Google工程师Addy Osmani更进一步，写了一篇深度解析文章《Loop Engineering》，把它凝练成一个定义：“循环工程，就是主动退出直接提示Agent的角色，转而构建一个自动化完成该任务的系统。”

概念成型了，命名确立了，基础设施也快速跟进。

2026年4到5月间，Codex、Claude Code和Hermes相继上线了/goal命令，把原本需要手写脚本实现的循环逻辑，封装成了一条简洁指令。

Ralph方法普及大约半年后，Codex正式推出了Goal功能。

Codex官方文档里写道：“Goals是Codex中长期存在的目标实体，支持单一对话线程跨多轮交互持续逼近明确结果。Goal为模型设定了完成判据：何种状态必须成立、如何验证成功、哪些约束须全程维持。”

文档特别强调：“普通提示表达的是‘接下来做这件事’；Goal表达的则是‘持续工作，直到这个结果达成’。”

在常规请求中，Codex执行当前指令、返回结果、静待下一条指令。而在Goal模式下，对话线程会绑定一个持久目标。每轮执行结束后，系统自动检验当前状态是否满足目标条件。如果没达成，而且Goal还在激活状态、预算也没用完，Codex就会基于最新上下文继续推进。

举个例子：“在确保全部正确性测试始终通过的前提下，把结账基准测试的p95延迟压降到120毫秒以内。”

这是一个具备明确终止条件的任务描述，可以直接交给Agent处理。后续它会自主拆解子任务、调度子Agent、持续迭代，直到达标。Codex团队正是借鉴了Ralph循环的思想，才构建起整套底层支撑能力：协调多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构成的组织图，类似区域联防，各司其职；第二类则是围绕具体任务形成的动态工作图，它随任务进展不断演化。

Shubham Saboo：组织图决定“谁管什么”，并承载领域上下文；工作图决定“此刻做什么”，随新证据灵活调整——可拆、可合、可重排，也可瞬时消解。

这正是生产级多Agent系统的核心特征：两张图并行运转。

组织图（Org Graph）：定义责任归属。“谁负责什么”——由长期存活的Agent构成，每人锚定特定领域，持续积累上下文、专业知识与工具权限。这个图相对静态，近似企业组织架构。

工作图（Work Graph）：定义任务流转。“现在要做什么、如何推进”——随任务需求与实时证据动态生成，支持拆分、聚合、顺序调整乃至即时废弃。这个图更像一份活的项目作战地图。

Preston Holmes同样强调二者缺一不可，而且运行于不同时间尺度：组织图预先设计、长期部署；工作图按需生成、任务终结即销毁。

如果说循环让Agent的行为变得可编程，那么图让Agent的组织形态变得可编程。再进一步，就是动态Agent组织——在任务执行过程中，图结构本身就可以自我演化、实时重构。

从撰写Prompt，到设计Loop，再到构建Graph，AI编程的能力重心正在持续上移。开发者正逐步脱离与单个Agent的微观对话，转而聚焦于更高阶的协作结构设计。