7月18日，Peter Steinberger在X上发了一条推文："我们还在讨论循环，还是已经转向图了？"
两天内，这条帖子获得260万浏览。六周前，他用另一条推文——"设计能提示Agent的循环"——获得了840万浏览，让全球开发者意识到Prompt Engineering的时代正在过去，Loop Engineering才是新方向。
两条推文累计1100万+浏览，把AI编程领域最热门的讨论推向了转折点。而这一次，Steinberger的问题本身就暗示了答案。
一、Loop的崛起：当"提示"变成了"设计"
回顾这一年，AI编程范式的演进速度远超大多数人的预期。
2025年7月，软件工程师Geoffrey Huntley提出了一种被他称为"Ralph"的方法——一个简单的Bash循环，让Claude反复执行任务直到目标达成：
while :; do cat PROMPT.md | claude-code ; doneRalph方法的精髓在于：绕过上下文窗口的限制。当时主流模型的上下文窗口只有20万Token，复杂任务远远不够。解决方案很朴素——把Agent运行拆分为更小的单元，每次用全新上下文启动，以"压缩"形式将已完成工作持久化到文件系统。
Huntley用这个方法从零构建了一门编程语言，验证了可行性。但直到更强模型出现后，这个方法才在开发者圈子里迅速传开。
Loop的爆火离不开Anthropic和OpenAI核心开发者的推动。Claude Code的创造者Boris Cherny在开发者大会上直言："我现在已经不再提示Claude了。我运行一些循环，由这些循环去提示Claude，并判断接下来该做什么。我的工作是编写循环。"
前Google工程师Addy Osmani随后撰写了题为《Loop Engineering》的文章，将其概括为："循环工程，就是让自己退出亲自提示Agent的位置，转而设计一个替你完成这件事的系统。"
概念有了，名字有了，基础设施也迅速跟进。2026年4到5月，Codex、Claude Code、Hermes相继推出/goal命令，把手工编写的循环产品化为一条指令。
Codex文档写道："Goal表达的是：继续工作，直到这个结果成立。" 在普通请求中，Codex处理当前指令、汇报结果、等待下一步。使用Goal时，线程上附着持久目标，执行结束后自动检查完成状态，未完成则继续工作。
比如："在保证正确性测试套件始终通过的前提下，将结账基准测试中的p95延迟降低到120毫秒以下。"——这是一个足够清晰的结束标准，Agent会自行拆分任务、创建子Agent、持续运行，直到工作完成。
二、Graph的到来：当"设计循环"变成了"设计协作"
Steinberger的最新推文指向的是一条更远的演进路径。
一年前，Prompt Engineering还是核心技能。到了2025到2026年初，重心转移到设计循环。而现在，前方已经清晰可见：设计由多个循环组成的图——每个Agent运行自己的循环，通过依赖关系彼此连接。
Luis Catacora在推文讨论串中的回复一针见血：
"循环有很大的容错空间。图会迫使你承认，工作流中还有多少部分根本没有被真正建模。"
这句话点出了两种范式的根本区别：
- 循环允许你推迟架构设计——先让一个Agent包揽所有工作，直到它再也处理不了为止。
- 图要求你提前声明整个结构——谁负责什么，哪些任务依赖哪些任务，某个分支失败后该怎么办。
循环是延期决策，图是提前决策。
三、两张图：组织图与工作图
Google高级AI产品经理Shubham Saboo（Awesome LLM Apps代码库作者，GitHub 12.4万+星）给出了更精致的拆解：
"长期存在的组织图定义谁负责哪个领域并保留上下文；工作图定义当前需要做什么，可以根据证据拆分、合并、重新排序或直接消失。"
这意味着生产级多Agent系统实际上有两张图在同时运行：
📋 组织图（Org Graph）——定义"谁负责什么"。由长期存在的Agent组成，每个Agent负责固定领域，保留该领域的上下文、专业能力和工具权限。组织图相对稳定，类似公司的组织架构。
⚡ 工作图（Work Graph）——定义"现在要做什么以及任务如何流转"。它会随着任务和新证据不断变化，可以拆分、合并、调整顺序或直接取消。工作图更像实时生成的项目计划。
它们运行在不同的时间尺度上：组织图被预先设计并部署；工作图针对每项任务动态生成，并在任务完成后丢弃。
四、推演：开发者能力的持续上移
理解这个演进链条的关键在于看到一条清晰的能力迁移路径：
Prompt → Loop → Graph → 动态图
每一个阶段，开发者都离"亲自与AI对话"更远一步，离"设计AI与AI如何协作"更近一步。
- Prompt Engineering：你亲自写提示词，直接与模型对话。
- Loop Engineering：你设计一个循环，让循环去提示Agent，你退到系统设计层面。
- Graph Engineering：你设计多个Agent的协作结构，每个Agent运行自己的循环，通过依赖关系组织工作流。
- 动态图（未来）：图本身就是可编程的——任务执行过程中，图会自行改写自身结构。
Preston Holmes的总结很到位："Loop让Agent的行为变得可编程。Graph让Agent组织变得可编程。"
这场竞争的壁垒正在从"谁更会用AI"变成"谁更会设计多Agent协作系统"。
五、落到行动：拥抱Graph范式的三个切入点
对于正在使用或构建AI编程工具的团队，这三点值得立即关注：
1. 把/goal用起来
如果你还在手动给Codex或Claude Code逐条发指令，今天就可以切换思维。写一个清晰的Goal，让Agent自己去规划、执行、检查。这不是偷懒，是拥抱新的工作范式。
2. 开始区分"组织"和"工作"
在多Agent场景中，先问自己两个问题：哪些Agent应该长期存在、各负责什么领域？当前任务需要临时创建什么Agent、任务如何流转？把这两张图画出来，哪怕很简陋，也比只有一个大循环强。
3. 关注工具的演进方向
在工具选择上，优先选择支持Goal级指令的工具，关注那些开始提供多Agent拓扑管理能力的平台。下一个AI编程工具的大战，不会比谁的prompt模板好，而是比谁的Agent协作架构更优雅。
结语
Peter Steinberger的推文并非宣告Loop的死亡，而是标记了它的成熟。当一个范式开始被命名、被讨论、产生大量方法论和基础设施时，它本身就为下一个范式铺平了道路。
从写好Prompt，到设计Loop，再到构建Graph，AI编程的能力重心持续上移。开发者越来越不需要关心如何与单个Agent对话，而是需要思考如何设计Agent之间的协作结构。
这不是技术迭代，而是开发者角色的重塑。