AI编程的核心技能，正在经历一场从“直接对话”到“设计系统”的深刻转变。从精心设计提示词，到设计自动化循环，再到构建多Agent协作的图，开发者正在逐步远离与AI的直接交互，转而设计让AI自主工作的系统。2026年7月18日，Peter Steinberger在X平台上的一条推文“我们还在讨论循环，还是已经转向图了？”，如同一声发令枪，正式宣告了AI编程范式即将迈入下一个阶段。

循环工程：从“提示”到“循环”的革命

在2026年，“Loop Engineering（循环工程）”迅速成为AI编程领域最炙手可热的概念。它的起源可以追溯到2025年7月，当时软件工程师Geoffrey Huntley提出了一个名为“Ralph”的简单方法——一个Bash循环，让Claude Agent反复执行任务，直到目标达成：

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

这个方法的出现，是为了解决当时AI编程的核心痛点：上下文窗口限制。当时，主流模型的上下文窗口上限为20万Token，对于复杂任务而言远远不够。Ralph方法通过将任务拆解，极大地提升了效率和稳定性。

Ralph方法的运作机制

• 为项目设定一个明确的目标，然后持续运行或重新运行Agent，直到目标实现。
• 以“压缩”形式（如日志或更新后的计划）将已完成的工作持久化到文件系统中。
• 每次启动Agent时都使用全新的上下文，从而最大限度地减少“上下文腐化”（即上下文窗口被无关信息污染）。
• 在必要时，允许每个Agent添加或修改“总体计划”，实现动态调整。

Huntley本人用这个方法从零构建了一门编程语言，成功验证了其可行性。随着更强模型的出现，这种方法在开发者圈子里迅速传播开来。

小提示： Ralph方法的名称来源于其核心思想：让Agent像拉尔夫（Ralph）一样，不知疲倦地重复执行任务，直到完成。其精髓在于“持续运行，直到成功”，而不是一次性给出完美答案。

概念普及与产品化

Loop的爆火离不开Anthropic和OpenAI核心开发者的推动。在Anthropic的开发者大会上，Claude Code的创造者Boris Cherny表示：“我现在已经不再提示Claude了。我运行的是一些循环，由这些循环去提示Claude，并判断接下来该做什么。我的工作是编写循环。”随后，Peter Steinberger也发帖呼吁：“每月提醒一次：你不应该再亲自提示编程Agent了。你应该设计能够提示Agent的循环。” 前Google工程师Addy Osmani专门撰文，将其概括为：“循环工程，就是让自己退出亲自提示Agent的位置，转而设计一个替你完成这件事的系统。”

概念清晰后，基础设施迅速跟进。2026年4至5月，Codex、Claude Code、Hermes等主流AI编程工具相继推出了/goal命令，将手工编写的循环产品化为一条指令。Codex文档写道：“Goals是Codex中持久存在的目标，可以让一个对话线程在多轮交互中持续朝着明确的结果推进。Goal会为Codex提供一个完成条件：什么状态应该成立、如何检查是否成功，以及哪些约束必须始终得到保留。” 文档特别指出：“普通提示词表达的是：接下来做这件事。Goal表达的是：继续工作，直到这个结果成立。”

例如，一个典型的Goal可以是：“在保证正确性测试套件始终通过的前提下，将结账基准测试中的p95延迟降低到120毫秒以下。” 这是一个足够清晰的“结束标准”，Agent会自行拆分任务、创建子Agent，并持续运行，直到工作完成。

开发者如何应用循环工程

根据社区反馈，循环工程最常见的应用场景是处理周期性工作，例如自动化测试、代码审查、每日报告生成等。但其真正的价值，体现在处理需要持续迭代的长期任务上。

一个典型的案例是创业公司创始人Rafel Mendiola，他需要将一个大型React应用迁移到React Native。传统做法是创建一个庞大的Epic（史诗级任务），再拆分成50到100张工单，光是搭建基础设施就令人望而却步。他的替代方案是创建一个“Skill”（技能），让Agent自己识别可迁移的代码块、完成转换并追踪进度，然后把这个Skill放进每30分钟运行一次的Cron定时任务里。与传统管理庞大迁移计划的方式相比，这种方法在认知负担上轻松得多。

常见问题： 循环工程是否只能用于大规模代码迁移？
答案： 并非如此。虽然大规模迁移是典型应用，但循环工程的应用范围非常广泛。它适用于任何需要“持续迭代直到达成目标”的场景，例如：自动化重构、持续集成/持续部署（CI/CD）流水线、长期运行的性能优化任务、自动化文档生成、以及跨多个微服务的系统级测试等。只要任务具备明确的“完成条件”和可重复的迭代过程，循环工程都能发挥巨大作用。

图工程：循环的下一个演进

Peter Steinberger的推文“我们还在讨论循环，还是已经转向图了？” 实际上指向了一条清晰的演进路径：从提示工程，到循环工程，再到图工程。

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

为什么需要图？

Luis Catacora的回复一针见血：“循环有很大的容错空间。图会迫使你承认，工作流中还有多少部分根本没有被真正建模。” 这句话道出了这两种范式的根本区别：

• 循环允许你推迟架构设计： 先让一个Agent包揽所有工作，直到它处理不了为止。这是一种“先做，再想”的灵活方式。
• 图则要求提前声明整个结构： 谁负责什么？哪些任务依赖哪些任务？某个分支失败后该怎么办？这是一种“先想，再做”的严谨方式。

简而言之，循环是延期决策，图是提前决策。 对于小规模、探索性任务，循环的灵活性是优势；但对于生产级、多Agent协作的复杂系统，图的结构化是保证稳定性和可维护性的关键。

两张图：组织图与工作图

Google高级AI产品经理Shubham Saboo进一步区分了生产级多Agent系统中的两个关键层次：组织图（Org Graph）和工作图（Work Graph）。这两张图同时运行，缺一不可。

组织图（Org Graph）： 定义“谁负责什么”。它由长期存在的Agent组成，每个Agent负责一个固定领域，保留该领域的上下文、专业能力和工具权限。组织图相对稳定，类似公司的组织架构。
工作图（Work Graph）： 定义“现在要做什么，以及任务如何流转”。它会随着任务和新证据不断变化，可以拆分、合并、调整顺序或直接取消。工作图更像实时生成的项目计划。

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

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

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

参考链接：

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