目录Loop Engineering 的诞生Prompt 到 Loop 的 演进什么是 Loop EngineeringLoop的使用场景Loop 的6大组件自动化Automations工作树WorktreeSkills沉淀的技能连接器Connectors子智能体Sub-agents记忆系统Memory/StateLoop带来的问题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.mdClaude 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_QUAetJiDlH9pTXfsAAJAhttps://www.bilibili.com/video/BV1h6jn6WEF7/?spm_id_from333.1007.top_right_bar_window_custom_collection.content.clickvd_source5acbf37a28d859aa6c96fefb088a4587
最近很火的Loop Engineering到底是什么？
发布时间：2026/6/30 22:12:25
目录Loop Engineering 的诞生Prompt 到 Loop 的 演进什么是 Loop EngineeringLoop的使用场景Loop 的6大组件自动化Automations工作树WorktreeSkills沉淀的技能连接器Connectors子智能体Sub-agents记忆系统Memory/StateLoop带来的问题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.mdClaude 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_QUAetJiDlH9pTXfsAAJAhttps://www.bilibili.com/video/BV1h6jn6WEF7/?spm_id_from333.1007.top_right_bar_window_custom_collection.content.clickvd_source5acbf37a28d859aa6c96fefb088a4587
![华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
![华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
