目录
- Loop Engineering 的诞生
- Prompt 到 Loop 的 演进
- 什么是 Loop Engineering
- Loop的使用场景
- Loop 的6大组件
- 自动化（Automations）
- 工作树（Worktree）
- Skills（沉淀的技能）
- 连接器（Connectors）
- 子智能体（Sub-agents）
- 记忆系统（Memory/State）
- Loop带来的问题
Loop Engineering 的诞生
抛开Loop Engineering 这个新出的概念，其实他做的事情，或者说他的流程早就存在于我们日常使用和一些成熟产品里了。只不过刚好被几位大佬提出来造了一个Loop Engineering这个词火起来了。下面看看到底发生了什么。
首先在2026 年 6 月，Anthropic Claude Code 的负责人 Boris Cherny 先说了句话：
“I don’t prompt Claude anymore. I have loops that are running. They’re the ones that are prompting Claude and figuring out what to do. My job is to write loops.”
意思就是我不再写提示词了，我有loop跑着帮我做提示词并自己识别要做什么，我只写loop。
同一周，OpenClaw 的创始人 Peter Steinberger 也说了类似的话：
“You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”
谷歌云 AI 总监 Addy Osmani 后面又发了一篇长文，详细介绍了Loop 这种工作方式。
至此也正式确立了Loop Engineering 这个词。
短短一两周的时间，这个词就火遍全球了。那这个改变我们使用AI方式的工程到底是什么呢？
Prompt 到 Loop 的 演进
2024 年的时候对 AI 的使用很简单，我们写一条 prompt，等AI回复一段结果。Prompt Engineering 这个词就是在这个阶段被发明的，用措辞+例子+格式，通过清晰的表达，让模型输出结果尽量偏向我么你的预期。
这套方法有一个根本性的局限：就是必须在一条消息里事先预见模型需要的一切。你得把背景、规则、示例、约束全塞进去。模型看到什么就知道什么，看不到的只能猜。
到了 2025 年初，AI还达不到我们想要的效果，光靠 Prompt Engineering ，已经提升不了了。于是，为了让模型拿到的信息更多，Context Engineering（上下文工程）应运而生。他是为了精心构造模型“看到”的东西，比如用system prompt 提供角色和规则，few-shot 示例校准输出格式，RAG 检索注入实时知识，结构化输入让模型精确理解需求边界。本质都是一种信息增强技术。
上下文做好了，模型不再猜了。但一个新问题浮出来：即使信息完美，复杂任务一次做不完。重构一个模块需要先读代码、再改接口、再更新调用方、再跑测试验证——这不是一个 prompt 能搞定的事。模型需要多步执行，需要工具，需要在中间观察结果再决定下一步。
于是 Harness Engineering出现了，他就是给 Agent 装上工具——shell 命令、文件系统读写、MCP 连接器、沙箱环境，然后给它一套重试机制和权限控制，让它能在一次 session 内完成多步操作。Claude Code、Cursor、Codex 这些产品本质上都是 harness。我们给它一个任务，它可以自己规划步骤、调用工具、观察结果、失败后还能重试。
Harness 解决了“单次 session 内的执行能力”问题。但它没解决一个更大的瓶颈——人。
现在我们已经有一个超级强的Agent了。它能读代码、写代码、跑测试、开 PR。但是，我们每天还是要打开电脑、检查 CI 状态、复制错误日志、把日志贴给 Agent、等它修完、review 结果、批准合并。每天都在重复一样的过程，AI似乎一直在等我们给他发指令，告诉他怎么做。
此时Agent 的能力不是瓶颈，人才是。
Loop Engineering 的出发点正基于此，把“人触发 Agent → 人判断结果 → 人决定下一步”这个循环中的人替换成一个自动化系统。这个系统能定时触发、能验证结果、能记住上次做到哪了、能决定继续还是停止还是上报。
什么是 Loop Engineering
上面介绍了Loop Engineering是怎么一步步发展过来的。其实他很好理解。
他把“人触发 Agent → 人判断结果 → 人决定下一步”这个循环中的人替换成一个自动化系统。这个系统能定时触发、能验证结果、能记住上次做到哪了、能决定继续还是停止还是上报。
他通过设定好的循环，能让AI一直按照循环干活，走下去，循环写好了，我们人后面就很少介入了。大大提高了AI干活的效率。
我们唯一要做的，就是写好这个Loop，然后等着最后验收即可。
有人会把 Loop 理解成定时跑个任务。定时只是开始。一个真正能用的 Loop，至少要做到这几件事：它能自己启动，知道去哪找信息，做完一轮知道怎么检查结果，失败了知道要不要重试，每轮知道把进展记到哪，也知道什么时候该停下来交给人。
这本质还是一套工作流。
Addy 在原文里的说法是：Loop 不是你去给 Agent 写提示词，而是你设计一个系统，让这个系统替你去写。人的位置往后退了一层，从执行者，变成了调度者。
当你真正学会使用Loop Engineering，你会发现，他真的强的可怕。它能24小时不间断地干活，完全摒弃人为的干预。比如，我下班前给AI设好目标，然后回家睡觉。第二天早上醒来，会发现代码已经写好了，测试也跑通了，甚至连文档都写完了。
Loop的使用场景
既然Loop 那么牛逼，那是不是我无脑使用呢？
并不是，Loop也有自己的使用场景。
Loop适用场景：针对目标清晰、对错可验证的机械性任务，如写测试、修Bug、代码去重等。这类任务有明确通过标准（如测试全通过、Bug不复现），非常适合交给AI在循环中自主高效迭代。
Loop不适用场景：针对涉及权衡取舍、没有唯一正确答案的复杂决策，如架构设计、产品规划、长期策略制定等。这些需要结合市场、商业目标和用户理解进行价值判断，人类应主导决策，AI仅作参考和辅助。
核心策略：让AI负责“对错可验证”的执行，人类负责“需要判断与取舍”的决策。
在动手之前，先问四个问题：
- 这个任务是否重复？Loop 的价值来自复用：每天跑、每周跑、每次 CI 失败都跑、每次依赖升级都跑。如果一个任务只做一次，搭 Loop 的成本往往收不回来。
- 有没有自动验收标准？Loop 最需要的不是“聪明的模型”，而是能自动判断结果好坏的闸门。比如，单元测试是否通过；类型检查是否通过；lint 是否通过；
- Agent 能否运行自己写的东西？写代码只是第一步。真正重要的是 Agent 能不能看到结果。如果 Agent 只能写代码，不能运行和观察结果，它就只能猜。猜出来的代码，也许能过肉眼，但很难过工程。
- 你会 review 吗？Loop Engineering 不是“无人负责工程”。Agent 可以执行、可以验证、可以汇报，但最终责任仍然在人类。尤其是涉及架构、权限、安全、数据、支付、用户隐私的地方，不能让 Loop 自己决定。
Loop 的6大组件
用一个具体场景来看。
假设你的团队每天都会遇到 CI 红了的情况——某个测试挂了，某个类型检查报错。没有 Loop 时，流程是这样的：早上打开电脑，看到 CI 红了，把错误日志复制出来，贴给 Agent，等它修完，跑测试，提 PR。明天重复。
有 Loop 时，流程变成：每天早上 8 点，系统自动醒来。接下来发生的事情，是一次完整的运行循环
自动化（Automations）
即找到要做的事。
系统检查 CI 状态。全绿就什么也不做。有失败，就读取错误日志，确定今天的工作目标。这是触发层——Loop 需要某种东西把它叫醒，可以是定时器（cron）、可以是事件（CI 失败触发 webhook）、也可以是 Agent 自己的心跳检测。没有这个，Loop 不会自己开始。
工作树（Worktree）
为了隔离，开一个干净的工作区。
系统在一个独立的 git worktree 里启动修复。为什么不直接在主分支上改？因为如果你同时跑三个修复任务，它们不能在同一个代码目录里互相覆盖。每个子任务需要自己的副本，互不干扰。
Skills（沉淀的技能）
读规则，不从零开始。Agent 启动时先读项目知识文件——Codex 叫它 AGENTS.md，Claude Code 叫 CLAUDE.md，更细粒度的技能文件叫 SKILL.md。不管叫什么名字，做的是同一件事：把编码规范、架构约定、常见坑点写下来，Agent 每次启动时自动读取。否则每个 session 都在重新“学习”你的项目，浪费 token，浪费时间。
并且，这个skill是要沉淀的，也就发现错误，自己改进，不断完善。
连接器（Connectors）
使用外部工具，动手做事。
Agent 修完代码后，需要开 PR、关 ticket、通知你。这要求它能触达外部系统——通过 MCP 连接 GitHub、Linear、Slack、数据库，与外界交互或通知。
子智能体（Sub-agents）
验证，找另一个智能体打分。
修完后自动跑测试。但这里有个关键设计：写代码的 Agent 不能自己验证自己的代码——就像学生自己给自己批卷，它犯的错误恰恰是它发现不了的错误，需要用另一个 Agent 来检查。
记忆系统（Memory/State）
测试通过了就开 PR 并更新状态文件；没通过就把“今天尝试了什么、卡在哪里”写进状态文件。下次 Loop 醒来时读取这个文件，就知道上次做到哪了、什么试过失败了。Agent 的上下文窗口每次都会清空，但磁盘可以用来存储记忆知识库。
上面就是一次完整的 Loop 运行。你早上打开电脑看到的不再是“CI 红了”，而是“这里有个 PR 等你 review”或者“这个问题跑了两天没搞定，需要你看看”。
其实在Claude Code 和CodeX都有对应的组件：
Loop带来的问题
- 巨量的token消耗
Loop的token消耗很可能是翻几倍增长的。以前AI一次就能完成的任务，现在可能要跑十几遍甚至几十遍。token消耗是原来的好几倍，所以对于小团队和个人或者预算不充足的个人来说，成本是不小的。
- 可能陷入死循环
有时候AI会在一个问题上打转，改来改去越改越差。或者它会误解你的验收标准，做出来的东西根本不是你想要的。这时候还是需要人工介入，打断它的循环。
- 安全问题
如果给AI太高的权限，让它可以随便执行命令，可能会带来严重的安全风险。比如不小心删除了重要文件，或者泄露了敏感数据。所以在使用循环工程的时候，一定要设置好安全边界，不能让AI随便造。
- 假装完成
Agent 最危险的能力之一，是把未完成的事情讲得像完成了。它可能会说“测试通过”，但其实没有跑测试；它可能会说“问题修复”，但只修了表面；它可能会说“没有副作用”，但根本没检查。
- 理解债务
Loop 跑得越快，代码库变化越快。包括没用Loop的时候可能你也会发现，领导催的紧，仓库里多了很多你没读过、团队也没真正理解过代码。理解债是团队不知道代码为什么存在。这样其实危险。
所以在你要使用Loop时，请仔细考虑自己或团队是否适合？
参考：https://mp.weixin.qq.com/s/7_QUAetJiDlH9pTXfsAAJA
https://www.bilibili.com/video/BV1h6jn6WEF7/?spm_id_from=333.1007.top_right_bar_window_custom_collection.content.click&vd_source=5acbf37a28d859aa6c96fefb088a4587