Loop Engineering 直译是「循环工程」，中文里还没有固定译法。它描述的是 2026 年上半年在 AI 编程圈里迅速传开的一种做法：不再一句一句地给 AI Agent 下指令，而是搭一套会自己找活、自己派活、自己检查结果的循环，让 Agent 在这个循环里持续跑下去。
这个词的落点不在模型，而在模型外面那一圈。谁来决定下一步做什么、做完怎么验收、失败了怎么重来、跑偏了谁来叫停——Loop Engineering 关心的正是这些问题。
先用一句话抓住它
Loop Engineering 是把「你反复提示 Agent」换成「一套系统反复提示 Agent」，你只负责设计这套系统的目标、边界和验收标准。
生活里的类比是从「点菜」变成「排班」。以前你饿了就点一道菜，吃完再点下一道；现在你写一份排班表和出品标准，厨房按表自己备料、出餐、试味、返工，你只在交付口和异常时出现。菜还是那些菜，变的是谁在推动下一步。
为什么会出现这个词
2026 年 6 月初，Peter Steinberger 在 X 上写了一句被大量转发的话，大意是「别再给编程 Agent 写提示词了，你应该去设计那些给 Agent 写提示词的循环」。他提供了这个说法，但没有给它命名。随后 Addy Osmani 写了一篇标题就叫 Loop Engineering 的长文，把这套做法整理成了一个有名字、有结构的模式，这个词才固定下来。
Anthropic 负责 Claude Code 的 Boris Cherny 也有过类似表述，说自己已经不再直接给 Claude 写提示词，而是有若干循环在跑、由它们决定该做什么，自己的工作是写循环。几方说法叠在一起，让这个词在 2026 年年中快速扩散。
背后的现实是：编程 Agent 的单次执行质量已经够用，瓶颈转移到了「一个人一次只能盯一个会话」。当模型能连续工作几十分钟而人只能守在旁边点确认时，把人从循环的每一步里挪出来，就成了很自然的下一步。
flowchart LR
Goal["你定义的目标与验收标准"] --> Discover["发现任务<br/>定时扫描 / 队列 / issue"]
Discover --> Dispatch["派发给 Agent<br/>隔离工作区并行执行"]
Dispatch --> Run["Agent 执行"]
Run --> Verify["验证<br/>测试 / 评估 / 审查"]
Verify -->|不通过| Dispatch
Verify -->|通过| Ship["交付并记录状态"]
Ship --> Discover它通常包含什么
Addy Osmani 那篇文章把一个完整的循环拆成了几块。第一块是定时任务，负责按节奏发现和分拣要做的事，循环的起点不再是你打字，而是一次调度。第二块是隔离的工作区，让多个 Agent 并行跑而不互相覆盖文件，常见做法是每个任务一个 git worktree。
第三块是沉淀下来的知识，把项目里那些反复要交代的规范写成可复用的技能文件，而不是每次重新粘贴。第四块是外部连接，通过 MCP 之类的标准接口把 Agent 接到 issue 系统、CI、数据库和浏览器上。第五块是子智能体，让出主意的和挑毛病的分开，避免同一个上下文里自己批改自己。
还有一块常被忽略但很关键：外部状态。循环跑久了，进度、待办、失败原因不能只留在对话历史里，需要落到 markdown 文件、看板或数据库上，这样循环重启后还能接着跑。
和 Prompt Engineering、Harness Engineering 的区别
三个词的层次不同。Prompt Engineering 关心的是「这一次怎么把话说清楚」；Harness Engineering 关心的是「Agent 干活时周围该有什么环境」，包括上下文、工具、权限和验证；Loop Engineering 再往外一层，关心「谁来决定还有没有下一次、下一次干什么」。
可以理解成：Harness 是给一次执行搭的场地，Loop 是让场地被反复使用的那套调度。Osmani 的文章里也区分了内循环和外循环——内循环是 Agent 每一轮本来就在跑的「想—做—看结果」，外循环才是你要搭的那层：按时唤起内循环、喂给它任务、检查产出、决定下一步。
和 Agent、自动化脚本的关系
Agent 是循环里干活的那个角色，Loop 是让它持续有活干、有人验收的机制。传统自动化脚本也是循环，区别在于脚本每一步都是确定的，而这里的每一步由模型现场判断，所以验证环节的分量比脚本重得多。
也正因为如此，Loop Engineering 在实践里几乎总要和评估、测试、代码审查绑在一起。没有自动验收的循环不是循环，是无人看管的批量生成。
容易误解的地方
最常见的误解是把它当成「让 AI 全自动接管」。Osmani 在文章里专门警告了三件事：验证责任始终在人身上，无人看管的循环会犯无人看管的错误；只求交付速度会积累「理解债」，代码进了仓库但没人真的懂；以及最危险的一种——放弃判断，循环输出什么就接受什么。他的原话大意是，同一套循环，在还保持理解的工程师手里和在把责任一并自动化掉的人手里，结果是相反的。
另一个误解是觉得所有任务都该上循环。同样是 Steinberger，也写过主张少加仪式感、直接跟模型对话的文章。这两种说法并不矛盾：探索性的、一次性的、需要你边看边改主意的任务，加一层循环只是徒增开销；重复的、有明确验收口径的、可以无人值守跑的任务，循环才划算。
怎么判断它该不该用
先问三个问题。这件事会不会重复发生？完成的标准能不能写成机器可判断的检查（测试通过、评估分数达标、schema 校验通过）？失败了会不会造成不可逆的后果？
前两个都是「是」、第三个是「否」的任务，最适合做成循环，比如依赖升级、批量修 lint、补测试、把积压 issue 分拣成可执行任务。反过来，需求还没想清楚、验收全靠人眼判断、或者一旦出错会动到生产数据和线上配置的场景，先别急着自动化，把 Harness 和验收标准做扎实再说。