提示词工程、上下文工程之后，循环工程到底是什么？-尧图网络科技

别再给 Agent 写提示词了：三位大佬同时押注「循环工程」

Claude Code 之父 Boris Cherny 称自己已不再直接 prompt Claude：「写循环才是我的工作」。OpenClaw 作者、谷歌 Chrome 团队工程负责人相继发声，吴恩达也分享了自己的三个关键循环。继提示词工程、上下文工程之后，「循环工程」为何突然爆火？

当 AI 可以自己写代码、自己测试、自己修 bug，人类工程师该干什么？最近，AI 编程圈的几位重量级人物几乎同时给出了同一个答案：去设计循环。继提示词工程（Prompt Engineering）、上下文工程（Context Engineering）之后，「循环工程」（Loop Engineering）正在成为 AI 时代的下一门必修课……

还记得当年人手一份的「提示词秘籍」吗？

短短两三年，用 AI 写代码的姿势已经换了三轮：先是卷提示词，后来卷上下文，而现在，最前沿的那批人，连 prompt 都不写了。

事情要从 2026 年 6 月初说起。几天之内，AI 编程圈的三个声音从不同方向汇聚到了同一个想法上，而最终留下来的那个词，叫Loop Engineering（循环工程）。

先是 OpenClaw 的作者 Peter Steinberger 发帖表示：大家不该再给编程智能体写提示词了，而应该去设计那些「会给智能体写提示词」的循环。

紧接着，Claude Code 之父、Anthropic 的 Boris Cherny 从「厂商内部视角」补了一刀。他说自己已经不再直接 prompt Claude 了——他有一堆循环在跑，这些循环会自己 prompt Claude、自己决定接下来做什么。用他的话说：写循环，现在就是我的工作。

随后，谷歌 Chrome 团队的工程负责人 Addy Osmani 给这门实践正式起了名字，还给出了完整的「解剖结构」：自动化、Worktree、技能、连接器、子智能体，外加外部状态。

相关帖子迅速在社交媒体上刷屏，「Loop Engineering」就此出圈——连吴恩达都专门写了一封来信来聊这件事（下文详述）。

那么，循环工程到底是什么？

一句话定义：循环工程是一门新兴学科，研究如何设计 AI 智能体的工作流——让它从一个触发器出发，围绕一个可验证的目标，调用工具与记忆，评估进展，并持续迭代，直到满足停止条件。

值得注意的是，循环工程在原理上并不是编程专属的概念。它的内核，是一种看待任何「重复性、目标导向流程」的方式：一个系统能自己找活、自己干活、自己验活、自己记账、自己决定下一步，而不需要人类每一轮都手动点火。运营、研究筛选、客服、内容流水线乃至个人工作流，处处都有它的用武之地。

只不过，眼下真正把这套东西构建出来、命名、并配齐可用「原语」的领域，是 AI 编程。所以我们也从这里说起。

从「问什么」，到「系统怎么自己转」

回顾大模型落地这几年，其实是三代「工程」的接力：

提示词工程回答的问题是：「我该问什么？」——优化的是一条指令；
上下文工程回答的问题是：「模型该知道什么？」——优化的是喂给模型的信息；
循环工程回答的问题则是：「工作该如何自主推进？」——优化的是整个系统：它决定何时 prompt、prompt 什么，以及结果是否真的好到可以停下来。

换句话说，你最终要构建的，是一个小型执行系统。它会：

找到工作（发现 / 分诊）；
执行工作（由 Agent 完成任务）；
检查结果（由一个独立的校验者来评判）；
记住发生了什么（状态持久化在对话之外）；
决定下一步，然后重复。

拆开一个循环：六块「积木」

按照 Addy Osmani 的拆解，一个像样的循环需要五大构件，外加把一切串起来的第六要素——记忆。

1. 自动化（Automations）：按计划自动触发，独立完成任务的发现与分诊，而不是等人来启动。这是把「单次 Agent 运行」变成「真正的循环」的关键一步。

2. Worktree（并行隔离）：让多个 Agent 并行开工而互不踩踏文件，就像两位工程师在不同分支上开发，不会在同一行代码上相撞。

3. 技能（Skills）：把项目知识固化下来，不用每个会话都从头解释一遍。目前两大主流工具采用了同一种格式——一个装着 SKILL.md 的文件夹。没有它，循环每一轮都要从零推导整个项目；有了它，「理解」就变成了复利。

4. 插件与连接器（Connectors）：基于 MCP 构建，让 Agent 能读 issue、查数据库、调 staging API、往 Slack 发消息。这是「甩给你一段修复代码」的 Agent，和「直接开好 PR、关联工单、等 CI 变绿再来叫你」的循环之间的差距。

5. 子智能体（Sub-agents）：循环中最有用的结构性设计，是把「干活的」和「检查的」分开——写代码的模型，没有立场客观地给自己的作业打分。让第二个 Agent（有时干脆换一个模型）来查，往往能揪出第一个 Agent「说服自己没问题」的地方。

6. 状态（State）：在 Agent 遗忘之后依然存活的记忆。它可以是一个 markdown 文件、一块项目看板，或任何活在单次对话之外的存储，记录着「什么做完了、接下来干什么」——模型在两次运行之间会忘掉一切，但仓库不会。

吴恩达亲自下场：我的三个循环

这股风潮之下，吴恩达也在最新来信中给出了自己的答案。

他表示，在 Boris Cherny 和 Peter Steinberger 的相关言论爆火之后，「循环工程」已经成了热门词汇；如今，循环是让 AI 智能体长时间迭代、构建软件的关键。他分享了自己打造 0 到 1 产品时的三个关键循环——按他的说法，这些循环不仅指导他怎么构建软件，也指导他决定构建什么软件。

循环一：智能体编程循环（分钟级）

给定产品规格，再（可选地）配上一组评估集（evals），AI 智能体就能写代码、自测、持续迭代，直到代码无 bug 且符合规格。这种「闭环」思路从去年底开始起飞，彻底改变了编程智能体在无人干预下长时间高效工作的能力。

吴恩达举了个自家例子：上个周末，他给女儿做了一个练打字的 App，他的编程智能体轻松独立工作了大约一个小时，期间多次自己打开浏览器检查构建成果，全程没有找他。

这个循环转得飞快——每隔几分钟，智能体就可能构建并测试一个新版本。吴恩达还提到，不断有开发者向他分享打造更高效工程循环的新方法，「这是一个非常活跃的创新领域」。

循环二：开发者反馈循环（几十分钟到几小时）

在这个循环里，开发者审视当前产品，引导编程智能体去改进它。去年，很多开发者（包括吴恩达本人）都在给自己的编程智能体当 QA——人肉找 bug，再让 Agent 修。但随着智能体自测能力大增，这部分时间投入已显著减少，开发者得以腾出手来做更高层的产品决策：提供哪些关键功能、UI 哪里要改，等等。

在打字 App 这个例子里，吴恩达改了几次主意的地方分别是：视觉设计、女儿学习后能解锁哪些猫咪装扮（她超爱猫），以及家长登录、引导孩子学习体验的流程。

这一段里还有个很有意思的观点。很多人把人类在这一环的贡献称为「品味」（taste），但吴恩达更愿意称之为**「上下文优势」（context advantage）**——我们远比 AI 更了解用户，以及产品所要运行的环境。他认为这个说法给出了一条更清晰的路径去帮助 AI 系统变强，同时也解释了为什么这一步无法被自动化：只要人类还知道一些 AI 不知道的事，human-in-the-loop 就是刚需——总得有人把这些知识注入系统。

循环三：外部反馈循环（数小时到数周）

这一环包含一系列打法：找几个朋友试用、向 Alpha 测试者发布、带着 A/B 测试直接上生产环境……这些手段通常很慢，很少能在几小时内完成，有时要几天甚至几周。而这些数据会反哺开发者的产品愿景，愿景继续驱动详细的产品规格，规格再驱动编程智能体——外环套内环，整个系统就这样转了起来。

吴恩达最后还观察到一个趋势：随着编程智能体大幅提速，越来越多工程师开始兼任「半个产品经理」。对这些正在转型的工程师而言，最难的是塑造产品愿景，并在「动手构建」与「获取用户反馈以进化愿景」之间找到平衡——两头都不能偏废。他对此持乐观态度：正如产品经理和设计师如今也在做更多工程活儿一样，工程师的角色边界正在扩张。

值得一提的是，Boris Cherny 此前还提出过 AI 时代团队的五类新角色——原型师、构建者、清理师、增长师、维护者（参见我们此前的报道）。两套观察正好对上了：人负责定义方向、把关质量，循环负责执行与迭代。

落地长什么样？让一个 Issue 自己「闭环」

理念讲完，来看一个具体示例。技术博主 Valentina Alto 最近用 GitHub Copilot + GitHub Actions 搭了一个完整的循环，展示了当一个新需求（Issue）出现时，循环是如何把它「接住并转完」的。

假设一家航空公司想给官网加一个对话式行程规划助手——乘客一句「五月中旬去罗马，两个成人，经济舱，600 欧以内」，系统就返回几个带理由的行程方案。当这个需求以 Issue 的形式提出后，循环是这样运转的：

触发：定时调度的 workflow 自动检测分配过来的新 issue，启动循环；
意图规范化：自定义指令 + 技能 + issue 模板，保证进来的输入天生就是结构化的；
人工闸门后的规划：Plan 模式先产出计划，人类批准之前，一行代码都不写；
有边界的自主构建：自动驾驶模式可连续执行多步，但设有连续执行上限，防止「失控循环」；相互独立的子任务还能拆给并行的子智能体；
持续校验：CI 门禁（lint / 单测 / 集成 / 契约测试）层层把关，技能里还写明了「每做完一片就地跑检查」；
自动恢复：CI 挂了、PR 被评论了？编程智能体把这些当作新输入，自动推送后续提交；
记忆持久化：不需要单独的数据库——issue 和 PR 线程本身就是循环的记忆；
完成条件强制执行：验收清单没勾完，CI 就不放行；分支保护让「CI 全绿」成为合并的硬前提。

不难发现，这条流水线上的每一个环节，都能对应到前文的某块「积木」。

亲测：我用一个循环，在 WorldQuant BRAIN 上挖因子

循环工程不只能写代码。笔者最近做了个实验：把量化平台 WorldQuant BRAIN 上「挖 Alpha 因子」这件事，整个交给一个循环去转——每小时自动醒来一次，自己找方向、自己跑模拟、自己校验、自己记笔记，为期七天。

对照前文的五步执行环，它是这样转的：

发现工作（Find work）：定时任务每小时触发一次。循环先读取账户里已提交的因子池和上一轮留下的笔记，自己回答「这一小时该挖哪个方向」——比如「专攻池子里还没用过的算子」；
执行任务（Act）：通过 API 连上 BRAIN 平台，批量构造候选表达式（如用ts_quantile替换已验证的ts_av_diff构造），一小时内真跑了 20 个模拟、5 个批次；
校验结果（Verify）：校验是双重的。第一重是平台硬指标——夏普、Fitness、换手率；第二重是自相关检查：一个候选因子解压后夏普高达 1.71，却因为与池内已有因子相关性 0.77、超过 0.7 的红线而被自动拦下。干活的和把关的不是同一段逻辑——这正是「Maker ≠ Checker」；
记录状态（Persist）：每轮结束，循环把结论写进一个 markdown 笔记：哪些方向已验证、哪些是死胡同（连同具体数字），下一轮直接读取。模型会忘，但笔记不会；
决定下一步（Decide）：基于笔记调整策略，而不是盲目重试。

最有意思的是第五步。第一轮它撞了三堵墙，却各留下了一条可执行的教训：换个新算子并不能带来去相关——去相关靠的是换数据字段，不是换算子；而价值类字段这条轴已经被挖饱和了，再换字段也只是从 1.7 掉到 1.1。于是第二轮醒来时，它没有在老地方继续刨土，而是主动拉取了平台全部 14 个数据集清单，锁定了一个因子池几乎没碰过的分析师预期数据集——1300 多个字段里只用过 2 个，且数据更新慢、天然低换手，恰好对上平台的 Fitness 考核。

一个纯手工的因子研究员，这套「试错—复盘—换赛道」通常以天或周为单位；而这个循环以小时为单位在推进，且每一条死胡同都被明确记录、不再重复踩坑。七天后任务自动过期——这就是预先设好的停止条件。

这个例子也把前文那句话具象化了：循环工程师的产出不是某一个因子，而是这个会自己越挖越聪明的系统本身。