Loop Engineering 实战：把 /goal 和 /loop 变成可验证的 AI 工程循环

沐风 2026-7-6--
ClaudeCode系列 Claude Code codex Loop Engineering Harness Engineering
type
status
date
slug
summary
tags
category
icon
password
wechat_gate
Loop Engineering 最近被很多人讨论，但它不是一个新的魔法词，也不是把一句 prompt 前面加上 /loop 就能让 AI 自动交付。
我更愿意把它定义为：为 AI Agent 设计一个可反复执行、可验证、可停止、可恢复的工作循环。
这篇文章会把几个关键概念讲清楚：
  • /goal 和 /loop 分别适合什么任务
  • Harness、Verifier、Memory、Stop Rules 到底在循环里做什么
  • Claude Code 和 Codex 在这些能力上的对应关系
  • 怎么写一个能落地的循环任务规格
  • 哪些坑会让循环变成死循环、假完成或者成本黑洞

为什么现在要认真看 Loop Engineering

过去我们用 AI 编程，大多是单轮交互：
  1. 我写一个 prompt。
  1. AI 改代码。
  1. 我跑测试、看报错、贴回去。
  1. AI 再修。
  1. 重复。
这个流程看似是 AI 在工作，实际上人一直在循环里做人肉调度器：判断下一步、检查输出、决定是否继续、记录哪里改过。
Loop Engineering 想解决的不是“让 AI 回答更漂亮”，而是把这几个动作显式设计出来：
  • 目标是什么
  • 一轮该做什么
  • 每轮怎么验证
  • 失败几次停
  • 成功怎么判断
  • 中间状态写到哪里
  • 哪些权限可以自动执行，哪些必须等人确认
这也是它和普通 Prompt Engineering 的根本区别。
Prompt Engineering 关注“怎么让模型这一次回答更好”。Loop Engineering 关注“怎么让模型在多轮执行中持续靠近一个可验证结果”。
如果你只问一个概念解释，普通 prompt 足够。如果你要让 AI 连续改一个模块、写测试、修构建、查资料、更新文档、反复验证，Loop Engineering 才开始有价值。
notion image

先把几个词说清楚

Prompt Engineering

Prompt Engineering 是写好一次指令。它的典型目标是让模型在当前上下文里给出更好的回答或操作。
例如：
这是一条任务指令。它可能有效，但结束条件、验证方式、失败处理、作用范围都不够明确。

Context Engineering

Context Engineering 是管理模型每一轮能看到什么。它关心的不只是 prompt，还包括系统指令、历史对话、文件内容、工具结果、记忆、检索结果、MCP 数据源等。
长任务里，Context Engineering 比 Prompt Engineering 更重要。因为 Agent 每轮都会产生新信息，如果不筛选、压缩、外部化，后面的轮次会被旧日志、无关文件和过期判断拖垮。

Harness Engineering

Harness 是 Agent 运行的工程底座。你可以把它理解成一组稳定约束：
  • 项目说明：CLAUDE.md、AGENTS.md
  • 权限边界：哪些命令允许自动执行，哪些必须确认
  • 工具连接：MCP、浏览器、GitHub、数据库、设计工具
  • Hooks：每次写文件后自动格式化、提交前自动跑 lint
  • Subagents：让验证、研究、审查在独立上下文里执行
  • Memory：跨会话保存重要事实和偏好
Loop 是在 Harness 里面运行的。没有 Harness，循环会不断猜项目结构、猜测试命令、猜权限边界。猜得越久，越容易出现假完成。
notion image

Loop Engineering

Loop Engineering 是把 Agent 的长期任务设计成一个闭环：
它不是代码里的 while true，也不是普通定时任务。
传统脚本的步骤是写死的。Loop 里的关键是有一个会看当前状态、选择下一步、处理错误的模型参与决策。
但是，模型参与决策不等于可以没有边界。恰恰相反，Loop Engineering 最重要的部分就是边界。

Verifier

Verifier 是验证层。它不应该只问“你觉得完成了吗”，而要拿证据判断：
  • 测试是否通过
  • 构建是否通过
  • 目标文件是否真的改到位
  • 链接是否能打开
  • 截图是否符合预期
  • PR diff 是否只触及允许范围
更好的做法是让 Verifier 和执行者分离。执行者负责改，Verifier 负责挑错。两者共用同一个上下文时，很容易出现“自己证明自己正确”的问题。

Memory 和 State

Memory 是跨会话知识。State 是当前任务进度。
这两个东西容易混用，但最好分开：
  • Memory：项目偏好、长期决策、反复出现的约束
  • State：这次循环做到了哪一步，哪些完成，哪些阻塞，下一轮先看什么
一个常见文件组合是：
没有 State，循环很容易每次从头开始，最后看起来很忙，其实一直在重复同一步。

Stop Rules

Stop Rules 是循环的刹车。它至少要包含两类：
  • 成功停止：什么证据出现后算完成
  • 失败停止：什么时候不要再试，必须交还给人
例如：
很多人第一次用循环踩坑，不是模型太弱，而是没有写 Stop Rules。没有刹车的 Agent，不是自动化，是成本风险。

/goal 和 /loop 的区别

根据 Claude Code 官方文档，/goal 用来设置完成条件，Claude 会在每轮之后用一个较快的小模型检查条件是否满足；如果没满足，就继续下一轮。它适合有明确终点的工作。
/loop 则用于在当前 Claude Code 会话里按间隔重复运行 prompt。它适合轮询、巡检、提醒、等待外部状态变化这类任务。
简单说：
命令
核心问题
停止方式
典型场景
/goal
做到什么状态才算完成
条件满足后自动停
迁移模块、修测试、补文档、清 issue
/loop
多久回来检查一次
人停止，或 Agent 判断已完成
等部署、巡检 PR、周期性检查
需要注意一个现实细节：不同工具的命令名并不完全一致。
Claude Code 官方文档明确列出了 /goal 和 /loop。Codex 官方文档当前更强调 AGENTS.md、Automations、Subagents、Workflows、CLI slash commands 等能力；Codex CLI 的公开 slash command 列表里并不应该被简单等同为 Claude Code 的 /loop。所以写跨工具教程时，要把“工程模式”和“具体命令名”分开。
工程模式可以迁移，命令名不能乱套。

什么时候用 /goal

只要任务有一个可验证终点，就优先考虑 /goal。
好的 /goal 不是“帮我修好”，而是“满足这些条件才算修好”。
例如一个 auth 模块迁移任务：
这个写法的关键不在字数，而在可验证。
如果你的完成条件不能被测试、构建、diff、文件内容、截图、链接检查或人工验收标准验证，它就不适合直接丢给 /goal。

什么时候用 /loop

/loop 更像一个会思考的轮询器。
适合它的任务通常不是“把这个做完”，而是“隔一段时间回来看看状态有没有变化”。
例如等待部署：
这里用 /goal 也能描述“等到部署完成”，但 /loop 的节奏更自然，因为它的核心是定时检查外部状态。
/loop 的典型场景：
  • 每 5 分钟检查一次部署状态
  • 每 30 分钟检查一次 PR 是否有新 review
  • 每天早上生成一份项目状态摘要
  • 监控某个外部服务是否恢复
  • 定期整理日志或失败任务
不适合 /loop 的场景：
  • 一次性问答
  • 目标还很模糊的创意发散
  • 需要大量人类判断的产品方向选择
  • 高风险生产操作
  • 没有明确停止条件的“持续优化”
“持续优化”是最危险的词。它听起来很积极，但对 Agent 来说常常意味着没有终点、没有边界、没有成本上限。

一个可复用的 Loop 规格模板

中高级开发者可以直接把下面这个模板放进 PROMPT.md 或 LOOP-SPEC.md。
这个模板的价值是让 Agent 知道“做事方式”，而不是只知道“要做什么”。

Codex 里怎么对应

如果你用的是 Codex，建议把思路拆成三层。
第一层是 AGENTS.md。OpenAI 官方文档明确说明，Codex 会在工作前读取 AGENTS.md，用它承载项目级指导、测试命令、代码规范和目录约束。
一个最小 AGENTS.md 可以这样写：
第二层是 Codex Automations。它对应“按计划回来处理”的需求，类似周期性检查、提醒、固定节奏的 review loop。
第三层是 Subagents 和 Workflows。它对应“把研究、验证、日志分析、代码审查拆出去”的需求。尤其是大规模资料分析、并行排查、多文件审查时，不要把所有上下文都塞进主线程。
但是有一个边界要记住：Codex 官方文档也提醒，子代理不会无条件自动生成，通常需要明确要求使用 subagents 或 parallel agent work。它们会消耗更多 token，不是默认越多越好。

它到底能解决什么问题

减少人肉 QA

过去你要反复看结果、跑测试、贴报错。Loop 把这些动作变成任务规格的一部分。
你仍然要最终 review，但不必在每一个低层错误上做人肉中继。

让长任务可恢复

长任务最怕上下文断掉。一个清晰的 LOOP-STATE.md 可以让 Agent 在下一轮知道：
  • 哪些已经完成
  • 哪些失败过
  • 哪些不要重复做
  • 下一步从哪里开始
这比把所有历史聊天留在上下文里更可靠。

把“自信”换成“证据”

Agent 很容易写出看起来合理但没有证据的结果。Loop 的验证层会强制它回到证据：
  • 测试日志
  • 构建结果
  • diff
  • 运行截图
  • 链接访问结果
  • benchmark 输出
没有证据，就不要标记完成。

把经验沉淀成团队资产

一个好的 loop spec 可以复用。你第一次写得慢，第二次就可以改模板，第三次就应该沉淀成 skill、workflow 或 automation。
这也是 Loop Engineering 和一次性 prompt 的区别：前者会沉淀，后者通常只留下一段聊天记录。

三个真实场景

场景一：研究 brief 防止假引用

素材里有一个很典型的例子：让 AI 写一页 brief，结果引用看起来完整，点开却可能是死链或内容不支持观点。
普通 prompt 的失败点是：AI 写完就交差，人来查证。
Loop 写法应该是：
这里 Loop 解决的是真实性问题，不是写作速度问题。

场景二：修一个前端保存 Bug

假设用户反馈设置页点击保存后显示成功，但刷新后配置丢失。
一个可执行的 /goal 应该写成：
这种任务很适合循环，因为它有复现、修复、测试、验证四个天然阶段。

场景三：0 到 1 产品开发的三层循环

Andrew Ng 的材料里提到三个循环，我把它翻译成工程视角是：
  • Agentic coding loop：Agent 根据规格写代码、跑测试、修 Bug
  • Developer feedback loop：开发者看产品方向、交互、体验，再更新规格
  • External feedback loop：真实用户、朋友、Alpha、A/B Test 给反馈
这三个循环的节奏完全不同。
编码循环可能几分钟一轮。开发者反馈循环可能几十分钟到几小时。外部反馈循环可能几天甚至几周。
很多人会犯一个错误：想把三层都自动化。
我的经验判断是，第一层可以高度自动化，第二层需要人提供产品上下文，第三层更不能伪造。用户反馈不能用模型脑补，A/B Test 不能用“感觉不错”替代。
Loop Engineering 的上限，不是把人彻底拿掉，而是把人从低层重复劳动里拿出来，放回目标、取舍和验收上。

最容易踩的坑

坑一：把任务写成愿望

坏写法：
这不是目标，是愿望。
好写法：
Agent 需要终点，不需要情绪价值。

坑二：Verifier 太弱

“检查一下有没有问题”不叫验证。
更好的验证是：
  • 运行指定测试
  • 读取指定输出
  • 对比目标条件
  • 给出通过或失败原因
  • 失败时不要顺手修，先报告
如果 Verifier 既当裁判又当运动员，很多问题会被它自己合理化。

坑三：没有状态文件

没有 LOOP-STATE.md，长任务很容易重复：
  • 已经修过的测试又修一遍
  • 已经排除的方向又排查一次
  • 已经确认不能改的文件又被打开
  • 上次失败原因在下一轮丢失
状态文件不要写成长篇日记。推荐保持结构化：

坑四：权限开太大

循环越自动，权限越要小。
尤其要限制：
  • 删除命令
  • 强制 push
  • 数据库迁移
  • 生产部署
  • 购买、发邮件、发消息
  • 写入用户数据或客户数据
如果一个循环需要无人值守，默认权限应该更保守，而不是更宽。

坑五：上下文越堆越多

把所有文件、所有日志、所有历史都塞给 Agent，不会让它更聪明，只会让它更容易失焦。
更好的模式是：
  • 用文件路径作为索引
  • 需要时再读取
  • 大日志只看摘要、头尾、关键错误
  • 每轮写状态，不把全部历史留在上下文
  • 长会话主动 compact
Anthropic 的 Context Engineering 文章也强调，Agent 在循环中会不断产生新数据，必须持续筛选和压缩上下文。长任务的关键不是保存一切，而是保存高信号信息。

坑六：用 /loop 做应该由 /goal 做的事

如果你知道终点，用 /goal。如果你只知道检查节奏，用 /loop。
错误示例：
这里既没有终点，也没有作用范围，也没有停止条件。
改成：

坑七：把人类上下文过早自动化

产品取舍、商业判断、用户洞察、品牌表达，这些事情不是不能让 AI 辅助，而是不应该让它在缺少真实上下文时自作主张。
Loop 更适合执行和验证。方向判断仍然需要人提供上下文优势。

我自己的使用原则

我现在判断一个任务是否适合 Loop，会先问 5 个问题：
  1. 结果能不能被验证
  1. 作用范围能不能收窄
  1. 失败能不能自动恢复
  1. 需要人工确认的动作是否明确
  1. 状态能不能写到文件里
如果 5 个问题里有 2 个以上回答不出来，我就不会直接开 loop。
比如“帮我设计一个更好的商业模式”，我会先普通对话，拆出约束和候选方向。
但“把 20 篇用户反馈分类，输出 top 5 问题，每条保留原文证据和建议优先级”，就很适合 loop，因为它有输入、输出、证据和完成标准。

真实写作过程

这篇文章不是从空白话题写的。我先读取了当前目录下 5 份素材：
  • Fable 5 A Beginner's Guide to Loop Engineering.md
  • Loop and Harness engineering 7 files, 5 steps. Every config inside.md
  • Loop Engineering：让 AI 自己循环，而不是你加入循环.md
  • Loop engineering（循环工程）最近成了热门词.md
  • Andrew Ng on X ... Loop engineering ... .md
然后我做了三件事。
第一，提取共同概念：/goal、/loop、Harness、Verifier、Stop Rules、Memory、Subagents、MCP、Context Rot。
第二，核验官方资料。因为 /goal、/loop、Codex、Claude Code 都是变化很快的工具，不能只靠社交媒体材料写。本文最终引用了 Claude Code 官方文档、OpenAI Codex 官方文档、Anthropic Context Engineering 文章和 MCP 官方说明。
第三，处理证据边界。当前目录没有本地真实截图，只有远程 X/Twitter 图片链接和剪藏文字。因此本文不使用“真实截图”来证明执行过程，只会使用说明性配图，且不会把生成图描述成产品截图、终端截图或工具截图。
这里也有一个失败教训：资料里有些说法很吸引人，比如仓库 star 数、某些论文数字、某些工具版本。如果没有在本轮核验到权威来源，我不会把它们写成事实。热点文章最容易的问题就是把二手材料里的数字当成定论，最后文章看起来很硬，实际上证据很软。

一份落地检查清单

你可以在每次写 loop 前检查下面这些项：
如果这张清单填不出来，先不要开循环。

总结

Loop Engineering 的重点不是让 AI “自己跑起来”，而是让它在边界内自己跑起来。
它真正改变的是开发者的工作重心：
  • 从写单次 prompt，变成写完成条件
  • 从手动贴报错，变成设计验证层
  • 从看模型自信不自信，变成看证据是否成立
  • 从把上下文堆满，变成把状态外部化
  • 从一次性对话，变成可复用的工程流程
/goal 适合有终点的任务。/loop 适合按节奏重复检查的任务。Harness 提供底座，Verifier 提供证据，Memory 和 State 提供连续性，Stop Rules 提供刹车。
你可以把这套东西理解为 AI Agent 的工程纪律。
模型越强，越需要纪律。因为弱模型跑不远，强模型跑偏了才更危险。

参考资料

 
2026.07.05 22:50
沪·赵巷
📌 声明：本文由 AI 辅助完成
 
 
 
giffgaff 激活保号实战：英国实体 SIM 开卡、防扣费与长期使用
使用 simctl、cliclick 和 ffmpeg 调试三个 UINavigationBar Large Title Bug：一次真实的 iOS Debug 实战
相关文章