“我们仍在探讨循环，还是已然迈入图的时代？”
2026 年 7 月 18 日，Peter Steinberger 在 X 平台发布了一条简短却意味深长的推文，悄然为“循环工程”这一阶段画下句点。该帖发布后短短两天内，便收获了 260 万次浏览。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
就在六周之前，他凭借“设计能提示 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 功能架构示意图
通过 Codex CLI 生成图片，支持尺寸控制和批量模式。依赖：codex (npm)。代理默认启用。用 generate.sh 生成单张，batch_generate.sh 批量生成游戏 UI 素材，gen_size.sh 指定尺寸。所有输出保存至 ~/.codex/generated_images/。
开发者如何实践循环
那么，一线开发者究竟如何运用循环？根据社区反馈，目前最普遍的应用场景仍是周期性运维类任务。
但循环的价值远不止于此。真正展现其工程潜力的，是一些需长期演进、反复迭代的复杂任务。
比如大规模代码迁移。创业公司创始人 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 的微观对话，转而聚焦于更高阶的协作结构设计。
参考链接：
https://www.php.cn/link/3025bca536e70f9e252460758ae3e5f2
本文来自微信公众号“InfoQ”（ID：infoqchina），作者：Tina，36氪经授权发布。
