当前位置：首页 > news >正文

从 OpenClaw.NET 的 /loop 实现，看 Loop Engineering 如何从概念走向工程实践

news 2026/6/20 12:36:54

一、引言

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），再基于观察继续思考下一步……这个循环自主运转，直到满足某个终止条件才停下来。

模型不再是被动等指令的聊天机器人，而是你设计的循环里的一个自主参与者。你定义循环的规则、工具和终止条件，模型在规则范围内自己做决策。

演进脉络

这个思路不是凭空冒出来的，它有一条清晰的演进线：

ReAct（2022）：Yao 等人提出推理与行动交替的框架，奠定了"思考→行动→观察"的基本模式，但当时是单步推理，没有持续循环的概念。
AutoGPT（2023）：把循环跑起来了，Agent 全自主决策、自主执行。问题是太容易失控——目标漂移、无限循环、账单爆炸，热度来得快去得也快。
Agent SDK 时代（2025）：Claude SDK、OpenAI Agent SDK 等提供了结构化的循环框架，开发者可以编排 Agent 的执行流程，但循环的驱动力还是单次用户请求。
Loop Engineering（2026）：声明式目标 + 自动循环触发。人负责设计 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：

原语	作用
指令（Instruction）	Loop 要达成的目标，声明式描述
工具（Tools）	Loop 里模型能调用的能力集
上下文（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 一次的定时器作为"心跳"，运行时维护一个 ConcurrentDictionary<string, LoopEntry> 内存注册表，记录每个活跃 loop 的下一次触发时间和间隔。每次 tick 到来时，扫描注册表里哪些 loop 该执行了，把到期的推进一轮。

这个方案的优点是简洁且可靠——没有魔改 TickerQ，没有引入新的调度依赖，ConcurrentDictionary 的线程安全性也经过了充分验证。代价是多了一层内存中的轮询逻辑，但对于分钟级精度的场景完全够用。

2. 零入侵 AgentRuntime：借助现有管道注入

这是一个非常干净的设计决策。

Loop 的提示词不是直接往模型里塞，而是通过 MessagePipeline.InboundWriter 以 ChannelId="cron" 的系统消息注入。这条消息会进入和正常用户消息完全相同的投递管道，由已有的 GatewayInboundMessageWorker 消费、转发给 AgentRuntime。

AgentRuntime 一行代码都不用改。

这个设计的高明之处在于解耦。Loop 模块不依赖 AgentRuntime 的内部实现，只复用现有的消息基础设施。这意味着无论是当前的 AgentRuntime，还是未来的 MafAgentRuntime，或者其他任何实现了同样消息接口的运行时，/loop 都能直接兼容。

"不修改，只扩展"——这是我在这个 PR 里最喜欢的一个决定。

3. 双层语义自终止：工程教训的产物

终止机制是这个实现里我最想展开聊的部分，因为它直接来自血泪教训。

OpenAI 的 Codex 在早期版本中曾因缺乏有效的终止机制，导致 Agent 在任务完成后继续无意义地运转，日志膨胀到 34GB/天。这不是"理论上可能出问题"，是真真切切发生过的事故。

PR #156 采用了双层防御：

主路径：模型主动调用 loop_control(status="complete") 工具，显式声明"我干完了"。这是最干净的终止方式——模型自己知道什么时候该停。

备用路径：检测模型响应文本中的终止关键词，包括 LOOP_TERMINATE、DONE、WORK_COMPLETE 等。如果模型没用工具但嘴上说了"完成了"，系统也能识别并终止循环。

两层机制兜底，避免单点失效。FrozenSet 存储关键词，O(1) 的查找效率。

这套设计说明作者是真的在生产环境里踩过坑——只有被无限循环整过的人，才会在终止条件上如此 paranoid。

4. NativeAOT 全兼容：零反射，零动态代码

如果你是 .NET 开发者，会知道这个 PR 在 NativeAOT 兼容性上花了多少心思。

整个实现零反射、零动态代码生成：

[GeneratedRegex] 编译期生成正则匹配代码
[TickerFunction] 源生成器处理调度声明
System.Text.Json 源生成器序列化所有 payloads
FrozenSet 存储终止关键词集合，启动时冻结、运行时只读

在 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 Step

CI 构建失败后，Agent 自动读取日志、生成错误摘要、定位代码、尝试修复、推送 PR。人在关键环节把关，但重复的"失败→分析→修复"循环由 Agent 自主完成。这类 loop 的价值很直接——减少工程师在流水线失败和代码修复之间来回切换的时间损耗。

3. PR Bot / GitHub App

Review→修复→验证→再 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 不是终局，只是下一层台阶。 但站上去看，视野已经不同了。