引言Loop Engineering 这个词最近又热起来了。如果你从去年开始关注 AI 工程化领域的动态大概已经习惯了这种概念迭代的节奏——Prompt Engineering 还没完全消化Context Engineering 就登场了Harness Engineering 的论文刚存进收藏夹Loop Engineering 又冒了出来。新概念一个接一个快得让人应接不暇。这难免让人心里打鼓Loop Engineering 是真有价值还是又一轮概念炒作我的看法是判断一个新概念是不是噱头最好的方式不是争论定义而是去看真实的工程实现。一个概念如果能经得起代码的检验——有人愿意写、有人愿意 review、有测试覆盖、能合并进主干——那它至少解决了一个真实存在的问题。OpenClaw.NET 刚合并的/loop 命令PR #156恰好提供了这样一个检验样本。这个 PR 由 geffzhang 贡献灵感来自 OpenAI Codex 的/loop原语。它用1,033 行代码实现了一个完整的定时循环提示词注入系统涉及 11 个文件62 个测试全部通过。用户可以输入类似/loop 5m check CI status的命令系统就会每 5 分钟自动注入提示词驱动 Agent 持续执行任务直到满足终止条件。这不是概念验证是生产级的实现。这篇文章就想借这个 PR把 Loop Engineering 的技术本质拆开来看聊聊它在研发平台里到底该放在什么位置以及为什么它比表面看起来更值得关注。二、Loop Engineering 是什么Loop Engineering 的核心是回答一个问题怎么让 AI Agent 持续、自主、可控地运行传统的 LLM 调用是一问一答模式——你发一条消息模型回复对话结束。Agent 稍微进了一步模型可以在一次调用里决定我要用工具执行完再把结果塞回上下文继续推理。但本质上模型还是被动地等你的输入。Loop Engineering 要做的是把模型放进一个你设计好的循环里让它自己跑起来。Agent Loop 的核心机制一个典型的 Agent Loop 长这样Thought → Action → Observation → Thought → ...模型先思考当前该做什么Thought然后执行动作比如调用工具或写代码Action接着观察执行结果Observation再基于观察继续思考下一步……这个循环自主运转直到满足某个终止条件才停下来。模型不再是被动等指令的聊天机器人而是你设计的循环里的一个自主参与者。你定义循环的规则、工具和终止条件模型在规则范围内自己做决策。演进脉络这个思路不是凭空冒出来的它有一条清晰的演进线ReAct2022Yao 等人提出推理与行动交替的框架奠定了思考→行动→观察的基本模式但当时是单步推理没有持续循环的概念。AutoGPT2023把循环跑起来了Agent 全自主决策、自主执行。问题是太容易失控——目标漂移、无限循环、账单爆炸热度来得快去得也快。Agent SDK 时代2025Claude SDK、OpenAI Agent SDK 等提供了结构化的循环框架开发者可以编排 Agent 的执行流程但循环的驱动力还是单次用户请求。Loop Engineering2026声明式目标 自动循环触发。人负责设计 loop 的结构什么时候触发、用什么工具、怎么判断完成AI 负责在 loop 里自主运行。人和机器的职责第一次被清晰地分开了。Loop 的本质一个公式如果把 Loop 的本质压缩成一句话大概是Loop Cron定时触发 决策器判断下一步做什么Cron 负责什么时候推进下一轮决策器就是 LLM负责这一轮该做什么。模型变成了你程序里的一个子程序而你变成了这个循环的作者——你写主循环模型跑子程序。概念层级链把 Loop Engineering 放到更大的图景里看AI 工程化经历了这样一层层的能力堆叠Prompt Engineering怎么跟模型说话→Harness Engineering怎么给模型造一个稳定的运行环境→Loop Engineering怎么让这个运行环境自己跑起来→Factory Model怎么让多个 loop 协同起来产出完整的软件每一层都建立在前一层的基础之上。没有 Harness 的隔离和工具调用能力Loop 就无从谈起没有 Loop 的持续运转能力Factory 级别的多 Agent 协作也只是纸上谈兵。六大原语Addy Osmani 在梳理 Loop Engineering 时总结了六个核心原语可以作为设计一个 loop 的 checklist原语作用指令InstructionLoop 要达成的目标声明式描述工具ToolsLoop 里模型能调用的能力集上下文Context每轮注入的 prompt 和运行时信息记忆Memory跨轮次的状态积累和知识沉淀终止Termination判断 loop 什么时候该停下来评估Evaluation每轮执行结果的校验和反馈机制这六个原语听起来抽象但你在接下来的/loop实现里每一个都能找到对应的工程决策。概念和代码之间其实只隔了一层窗户纸。三、解剖 OpenClaw.NET 的/loop命令概念聊完了来看代码。geffzhang 的 PR #156 把 Loop Engineering 的六个原语落到了实处其中几个设计决策尤其值得细品。PR #156 概览这个实现的核心能力很直观用户在聊天界面输入/loop 5m check CI status系统注册一个定时循环每 5 分钟向指定 session 注入一次系统消息驱动 Agent 检查 CI 状态并汇报。Agent 可以自主决定任务已完成调用loop_control工具也可以由系统根据语义关键词强制终止。1,033 行代码11 个文件变更62 个单元测试。体量不算大但设计密度很高。四大核心设计决策1. TickerQ 混合调度编译期声明 运行时注册表这是整个实现的地基也是最需要权衡的地方。OpenClaw.NET 的调度底层用的是 TickerQ 10.4.0这个版本有个特点只支持编译期的 cron 表达式不暴露动态注册接口。也就是说你不能在运行时说给我新建一个每 5 分钟执行一次的任务只能在代码里写死[TickerFunction(AgentLoopExecutor, * * * * )]编译后就定了。但/loop命令显然需要动态创建定时任务——用户随时可能发起一个新的循环间隔也各不相同。PR 采用的方案是混合调度编译期挂一个每分钟 tick 一次的定时器作为心跳运行时维护一个ConcurrentDictionarystring, LoopEntry内存注册表记录每个活跃 loop 的下一次触发时间和间隔。每次 tick 到来时扫描注册表里哪些 loop 该执行了把到期的推进一轮。这个方案的优点是简洁且可靠——没有魔改 TickerQ没有引入新的调度依赖ConcurrentDictionary 的线程安全性也经过了充分验证。代价是多了一层内存中的轮询逻辑但对于分钟级精度的场景完全够用。2. 零入侵 AgentRuntime借助现有管道注入这是一个非常干净的设计决策。Loop 的提示词不是直接往模型里塞而是通过MessagePipeline.InboundWriter以ChannelIdcron的系统消息注入。这条消息会进入和正常用户消息完全相同的投递管道由已有的GatewayInboundMessageWorker消费、转发给 AgentRuntime。AgentRuntime 一行代码都不用改。这个设计的高明之处在于解耦。Loop 模块不依赖 AgentRuntime 的内部实现只复用现有的消息基础设施。这意味着无论是当前的 AgentRuntime还是未来的 MafAgentRuntime或者其他任何实现了同样消息接口的运行时/loop都能直接兼容。不修改只扩展——这是我在这个 PR 里最喜欢的一个决定。3. 双层语义自终止工程教训的产物终止机制是这个实现里我最想展开聊的部分因为它直接来自血泪教训。OpenAI 的 Codex 在早期版本中曾因缺乏有效的终止机制导致 Agent 在任务完成后继续无意义地运转日志膨胀到 34GB/天。这不是理论上可能出问题是真真切切发生过的事故。PR #156 采用了双层防御主路径模型主动调用loop_control(statuscomplete)工具显式声明我干完了。这是最干净的终止方式——模型自己知道什么时候该停。备用路径检测模型响应文本中的终止关键词包括LOOP_TERMINATE、DONE、WORK_COMPLETE等。如果模型没用工具但嘴上说了完成了系统也能识别并终止循环。两层机制兜底避免单点失效。FrozenSet 存储关键词O(1) 的查找效率。这套设计说明作者是真的在生产环境里踩过坑——只有被无限循环整过的人才会在终止条件上如此 paranoid。4. NativeAOT 全兼容零反射零动态代码如果你是 .NET 开发者会知道这个 PR 在 NativeAOT 兼容性上花了多少心思。整个实现零反射、零动态代码生成[GeneratedRegex]编译期生成正则匹配代码[TickerFunction]源生成器处理调度声明System.Text.Json源生成器序列化所有 payloadsFrozenSet存储终止关键词集合启动时冻结、运行时只读在 NativeAOT 模式下反射和动态代码会被编译器裁剪掉轻则性能下降重则直接跑不起来。PR 从第一天就规避了这些陷阱说明作者对部署目标有清晰的认识——这个系统是要打包进容器、启动速度要快、内存占用要低。状态机设计/loop维护了一个精简的三态机Scheduled已注册等待触发 ↓ 定时器到期注入提示词 Running正在执行本轮任务 ↓ 语义终止触发 Terminated终态不可恢复围绕这个状态机有三条关键规则幂等覆盖同一个 session 只能有一个活跃 loop。用户重复发起/loop时新 loop 会覆盖旧 loop。这避免了 session 里堆叠多个循环导致的行为混乱。非抢占执行如果某个 session 当前正在处理消息比如上一轮还没跑完定时触发的新消息会排队等待不会强行中断。这是防止 race condition 的关键设计。静默自毁当 loop 因语义终止而结束时系统不会主动发送通知打扰用户。任务完成了就安静地退出把界面还给用户。这个细节体现了对用户体验的考量——没人喜欢被一个已经没必要的循环反复弹窗。与/goal的互补关系/loop不是 OpenClaw.NET 里唯一的循环原语。平台里还有一个/goal命令两者形成了有趣的互补/loop/goal驱动方式外部定时器驱动模型停止时自动续跑典型场景持续监控检查CI、扫描日志、定期代码审查一次性目标修完所有测试、清完所有 lint循环节奏固定间隔连续推进不等待/goal适合干到条件满足就结束的任务——模型推不动了会自动重试直到达成目标或超出限制。/loop适合需要等待外部状态变化的场景——每 5 分钟看一眼 CI不是一直盯着而是间歇性地检查。两者独立运作互不干扰。同一个 session 可以同时拥有/loop和/goal一个负责定时巡检一个负责持续推进。这种组合能力让 OpenClaw.NET 的 Agent 系统同时具备了间歇性监控和持续性推进两种工作模式。Loop Engineering 的魅力就在于此——它不是给你一个固定的运行方式而是给你一套组合原语让你根据场景搭配出合适的自主运行模式。四、Loop Engineering 不是噱头但有前提回到那个更本质的问题Loop Engineering 在整个 AI 研发平台里到底算什么级别的存在我的判断是它不是新神坛而是站在 Harness Engineering 肩膀上的流程控制层。如前文所述从 Prompt Engineering 到 Harness Engineering 再到 Loop Engineering每一层都依赖前一层的基础不存在谁替代谁。但这里我必须说一个可能不受欢迎的观点Loop Engineering 不是银弹甚至很容易被滥用。不是什么 Loop 都值得写如果只是写一个while (true)不断调用大模型 API那不叫 Loop Engineering那叫自动化烧 token。如果只是给 Agent 丢一句你自己一直干到完成没有状态追踪、没有质量门、没有停止条件、没有人工接管点——那叫把不确定性规模化。你本来只是偶尔被模型的幻觉坑一下现在好了幻觉被自动化了24 小时不间断地坑。Loop Engineering 真正有价值的地方是把过去人手动反复推动 Agent 的动作变成可触发、可验证、可追踪、可停止的研发流程。它把人从反复催促 AI的重复劳动里解放出来但前提是——这个流程本身是经过设计的。五种落地形态在实际工程里Loop Engineering 目前呈现出五种形态成熟度由低到高1. 本地短循环Claude Code 的/goal命令是典型代表——改代码→跑测试→看报错→继续修在个人开发机上循环运行。模型自己发现问题、自己修复、自己验证干完就停。这种场景上下文相对封闭失败成本可控是目前最成熟的落地形态。2. CI/CD Agent StepCI 构建失败后Agent 自动读取日志、生成错误摘要、定位代码、尝试修复、推送 PR。人在关键环节把关但重复的失败→分析→修复循环由 Agent 自主完成。这类 loop 的价值很直接——减少工程师在流水线失败和代码修复之间来回切换的时间损耗。3. PR Bot / GitHub AppReview→修复→验证→再 review 的循环。代码审查机器人不只是提意见而是发现 lint 错误、测试缺口或安全漏洞后直接提交修复建议跑完验证再通知人类 reviewer 确认。这个模式在代码风格统一、测试补全、依赖升级等有明确规则的场景里表现最好。4. Workflow Engine长周期任务的编排——状态机、任务队列、事件流、重试策略。一个需求从提出到上线涉及多个角色和环节每个环节都可能触发 Agent 的自主 loop。这种形态对系统的可靠性和可观测性要求最高。5. AI First 研发协同平台需求→设计→开发→测试→发布→复盘的全流程 AI 参与。多个 loop 嵌套协同——需求 loop 触发开发 loop开发完成触发测试 loop测试通过触发发布 loop。每个环节都有明确的输入输出契约和人工决策点。一个场景值不值得做成 Loop看五个条件不是所有任务都适合交给 loop。一个场景只有满足下面五个条件Loop Engineering 才能发挥正面价值清晰的触发器什么事件启动这一轮循环是定时 tick、上游任务完成、还是外部状态变化触发条件必须明确且可检测。可信的上下文每一轮循环注入的 prompt 和状态信息必须足够让模型做出合理决策。上下文缺失或污染的 loop跑起来就是灾难。受控的执行器模型能调用的工具集、能影响的系统范围必须有边界。无限制的 Agent loop 等于给了模型一把没有保险栓的枪。可验证的结果每一轮循环的产出必须能被检验——代码能编译、测试能跑过、指标能衡量。无法验证结果的 loop 等于黑盒运行。明确的停止条件什么时候停达成目标、超过重试次数、人工干预、还是异常熔断没有停止条件的 loop 就是无限循环的另一种写法。五个条件都满足Loop Engineering 是你的利器。缺一个就可能把混乱自动化了。五、范式迁移从你催 AI 干活到你设计 AI 自主干活Loop Engineering 的出现标志着 AI 工具从对话助手向执行代理的跃迁。这不是渐进式改良是工作模式的根本转变。行业里的两个信号今年圈子里有两个判断让我印象很深。一个是 Peter Steinberger 说的你不应该再手动 prompt coding agent 了。你应该设计 loop 来 prompt 你的 agent。 另一个人是 Claude Code 的负责人 Boris Cherny我不再 prompt Claude 了。我写 loop 让它们运行。我的工作是写 loop。两句话的核心意思一样——人的工作从跟模型对话变成了设计模型的运行规则。这跟软件工程的历史有相似之处。早年的程序员直接在机器上写汇编指令后来进化成写高级语言再进化成写框架和配置。每一次跃迁人的工作空间都往上升了一层——离具体执行更远离结构设计更近。Loop Engineering 正在推动类似的跃迁人从代码的作者变成循环的作者。两条产品路线Claude Code 和 OpenAI Codex 今年的产品更新不约而同地指向同一个方向但路径略有不同。Claude Code走的是评估驱动路线。/goal命令背后有一个独立的评估模型每轮执行后检查终止条件是否满足——测试通过了没lint 清完了没错误修完了没同时推出的 Agent View 提供了一个全屏管理后台让用户能看到所有正在运行的 Agent 任务、状态和输出。核心理念是模型自主推进系统负责校验。OpenAI Codex走的是触发编排路线。Automations 支持定时触发 durable prompt——你写好一套 prompt 和工具配置设定触发条件系统到点就自动跑。Triage 模式则是在 Agent 完成初步任务后把结果推给人工分诊由人决定下一步走向。核心理念是规则驱动触发人工把控关键节点。两条路线殊途同归都在把模型从被询问的对象变成自主运行的节点。Anthropic 的内部数据说明了什么今年 6 月 Anthropic 发布了一篇内部报告《When AI builds itself》其中几组数据值得关注Claude 写的代码占当月合并代码总量的比例在今年 5 月超过了80%工程师日均代码合并量相比 2024 年同期增长了8 倍开放式任务帮我完成这个功能而非帮我写这行代码的成功率从半年前的26%提升到了76%这些数字背后有两个关键拐点2025 年初Claude 从建议代码进化到自己跑代码——模型不再只输出文本而是直接执行、观察结果、迭代修复。2026 年初模型开始能够长时间自主工作——一次任务可能持续几十分钟甚至几小时期间模型自主决定调用什么工具、重试几次、什么时候放弃。人的角色在转变这不是AI 取代程序员的末日叙事。现实更微妙也更值得思考。你仍然需要理解业务逻辑、设计系统架构、做出工程判断。但你不再需要在跑测试→等结果→修 bug→再跑测试这个循环里手动推进每一步。你设计循环的规则——什么条件下启动、用什么工具、怎么判断完成、什么时候让人介入——然后让模型在规则范围内自主运行。从司机变成调度中心。你不是在循环里催促 AI你是在循环外设计 AI 的运行规则。问题空间变大了技能天花板也更高了。六、结语写到这里回到文章开头的问题Loop Engineering 是真有价值还是又一轮概念炒作我的答案是它不是噱头但需要工程约束。一个没有终止条件的 loop 是灾难一个有良好设计的 loop 是杠杆。区别不在于概念本身而在于你愿不愿意回答那五个问题——触发器清楚吗上下文可信吗执行器受控吗结果可验证吗停止条件明确吗OpenClaw.NET 的 PR #156 之所以值得关注正是因为它把一个正在形成的行业共识变成了可运行的代码。它有状态机有双层终止机制有并发安全有 AOT 兼容。这不是概念验证是一个生产系统对待 Loop Engineering 的认真态度。给正在考虑引入 Loop Engineering 的开发者一个实在的建议不要追概念从实际场景出发。先看看你的 workflow 里有没有人在反复做同样结构、不同内容的事情——检查 CI、跑测试、补全代码、审查 PR。如果有再问那五个问题。五个答案都有了Loop Engineering 就是你的利器。这不是 AI 取代人而是人的工作空间从代码层上升到了编排层——你掌控的范围更大了设计的权重也更高了。Loop Engineering 不是终局只是下一层台阶。但站上去看视野已经不同了。