Loops闭环工作流如何取代提示词工程

来源：X @

2026 年 6 月，生产级 AI 代理工作流的主导模式发生了一次转移：不再是”手动发提示词、等待、人工审查”的循环，而是能自行运转的自治系统 ^[4]。这个转变被命名为 Loop Engineering——设计代理运行其中的循环，而不是逐条手写提示词 ^[56]，名称也在 2026 年 6 月随一篇标志性文章被正式叫响 ^[58]。素材的主角 Loops 正是这一范式下的具体产品：一个以”停止提示，开始循环”（Stop prompting. Start looping）为口号的 AI 编程工作流平台，把复杂开发任务拆成带触发器、反馈门控和退出条件的预构建闭环 ^[0]。

循环的三要素：触发、验证、停止

代理循环的基本形态并不神秘：AI 思考该做什么、执行、观察结果，如此重复，直到命中某个目标或停止标准 ^[3]。IBM 把这类”思考—行动—观察”循环追溯到 ReAct 范式下的多步问题求解 ^[5]。Loops 将其包装成三个可配置要素 ^[0]：

触发器（Triggers）：启动工作流的初始事件 ^[0]。事件驱动型循环由外部事件启动——PR 被推送、CI 失败、Slack 消息到达，每次触发跑一轮 ^[4]；也可以按计划定时运行 ^[4]。
反馈门控（Feedback Gates）：闭环的关键 ^[0]。一个循环的内核是 discover → plan → execute → verify 四步的重复 ^[56]，其中 verify 决定输出是否合格——在任何一个循环里，验证器才是瓶颈，而不是模型 ^[56]。这也是控制重心的转移：人提前定义目标和验收标准，代理在闭环内自行多轮尝试，直到达标或遇到需要人判断的边界 ^[52]。对应到素材的说法，就是开发者从”如何写 Prompt”转向”如何定义任务目标”^[0]。闭环并不取消人的位置——流程终点仍由人做最终确认 ^[52]。
退出条件（Exit Conditions）：任务完成的标志 ^[0]。实际工程里，停止条件总是伴随预算上限：Build Until Green 模板把最大迭代次数设为 10 ^[14]；Greptile 驱动的代码审查循环在评分低于 4/5 时继续修，但最多 5 轮就放弃 ^[10]；另一个教程里的 worker 脚本写死”8 轮仍失败就停”^[7]。当超预算或无进展时，还需要安全停止（guardrail stop）兜底 ^[62]。

IBM 对这场变化的概括是：开发者的角色从”提示代理”重构为”设计会提示、检查、引导代理的自动化系统”^[59]；素材中”以前人主要写需求，现在人还要写验收规则”的表述，说的正是同一件事 ^[52]。

一个循环的真实配置：预构建模板

Loops 的卖点是开箱即用的模板，并允许社区贡献和分享新模板 ^[0]。公开资料里有真实配置可查：mcp.so 收录的 “Build Until Green” 模板写明——目标：生产构建成功；最大迭代 10 次；每次迭代之间运行 npm run build；当构建命令退出时结束 ^[14]。模板库网站提供了 20 个带验证、边界和停止规则的循环模板，包括”PR Babysitter Loop”（监控 PR 直到 CI 变绿、审查评论全部解决，在每个 PR 上运行）和”CI Failure Fix Loop”（读日志、做最小改动、重跑验证，在 CI 变红时运行）^[18]。

素材提到的”Skip PR Until Green”（自动部署、跑测试、推送 PR，在 CI 检查通过前持续重试）^[0]，与 Anthropic 官方 loops 入门中记载的热门循环 “Ship PR Until Green”（在分支上实现、跑测试、开 PR，持续监测 CI 直到全部检查通过才停）属同一类 ^[13]。至于”自动生成测试直到代码覆盖率达到阈值”的 “Coverage Until Threshold”，则是素材自己的例子 ^[0]。

循环如何接入现有开发流程

素材称 Loops 支持 VS Code 等主流 IDE，能与 GitHub Actions、GitLab CI 等现有 DevOps 管道集成，以插件形式作为工作流的增强层 ^[0]。这类能力在 2026 年年中已经下沉为平台原生：Claude Code、OpenAI Codex 等主流编码代理内置了并行 agent 所需的 worktree、调度原语，以及每次迭代后评估停止条件的内置 goal 命令 ^[57]。

更复杂的工作流让循环互相嵌套。一个 supervisor 程序可以同时调度多个 worker 循环并行运行，各自在隔离的代码副本里工作；supervisor 不信任 worker 自报的结果，写入前自己复核 ^[7]。循环还能生成自己的子代理循环：Claude Code 里的 PR 审查循环会为每个 PR 派出专门子代理，盯到所有合并检查变绿 ^[9]。开源项目 looper 采用类似设计——为单个 PR 启动 reviewer 与 fixer 两个循环来回 ping-pong，直到审查干净，必要时开启自动合并 ^[12]。无人监督的例子也真实存在：有人在 Reddit 记录了一个自学习循环，4 小时、119 次提交，把 1.4 万行 Python 翻译成 TypeScript，零构建错误、测试全过 ^[8]。

与 Loops 这类”低代码模板”相对的，是 LangGraph 一类的图工作流框架：用节点和条件边把循环画成图，靠回边实现 review → revise → review，用迭代计数做安全边界，并把状态持久化，以便中断后从最近的 checkpoint 恢复 ^[43]。LangChain 官方文档同样把”工作流”与”代理”区分开，由条件边决定继续调用工具还是结束 ^[46]。

验证、幻觉与失控边界

反馈门控被素材视为解决”幻觉”和”半途而废”的关键 ^[0]，其机制是把校验从模型内部搬到系统外部：每次线上失败都能沉淀成数据集里的用例，反馈循环把一次生产事故变成可重复的回归测试 ^[37]。这之所以必要，是因为幻觉不会随推理能力增强而自动消失——有研究显示，经过 RLHF 训练后模型的”胡扯指数”几乎翻倍，推理模型相比前代幻觉率上升两位数 ^[33]。

闭环也带来新的工程问题：什么时候该停、失败信息怎么复用、记忆给多大、怎样防止编造、成本如何控制 ^[62]。素材点出了调试难度——闭环失败时追踪错误源头比单行调试更复杂，也担心代理为通过测试而”作弊”（如硬编码返回值），需要透明的日志与审计 ^[0]。安全方面，自主权越大风险越大 ^[0]；关于自我演化类代理的工程建议是：先做监测再谈演化，把 meta-agent 与任务代理分离，对结构性变更要求人工核准，并版本化记录所有自我修改以便审计 ^[2]。

自动化本身也有前提。与其一上来就设计定时任务和自动触发，不如先把手动流程跑通——只有流程频繁重复、人是瓶颈、状态可以持久化，三个问题都回答”是”，才值得自动化；Stripe Minions 每周自动合并 1300+ PR 的流水线，正是先验证手动流程有效后才自动化出来的 ^[53]。

Loops闭环工作流如何取代提示词工程

循环的三要素：触发、验证、停止

一个循环的真实配置：预构建模板

循环如何接入现有开发流程

验证、幻觉与失控边界

参考来源