一、引言
Loop Engineering 这个词最近再次成为行业热议的焦点。
如果你从去年开始持续关注 AI 工程化领域的发展动态，大概已经习惯了这种概念快速迭代的节奏——Prompt Engineering 尚未完全消化，Context Engineering 便已登场；Harness Engineering 的论文刚刚存入收藏夹，Loop Engineering 又进入了视野。新概念层出不穷，让人应接不暇。
这不禁让人产生疑虑：Loop Engineering 究竟具备真实价值，还是又一场概念炒作？
判断一个新概念是否为噱头，最佳方式并非争论定义，而是审视其真实的工程实现。一个概念若能经受住代码的检验——有人愿意编写、有人愿意审查、有测试覆盖、能合并进主干——那么它至少解决了一个实际存在的问题。
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），再基于观察结果继续思考下一步……这个循环自主运转，直到满足某个终止条件才会停止。
模型不再是被动等待指令的聊天机器人，而是你设计的循环中一个自主参与的节点。你定义循环的规则、工具和终止条件，模型在规则范围内自行做出决策。
演进脉络
这一思路并非凭空而来，它拥有一条清晰的演进路线：
ReAct（2022）：Yao 等人提出了推理与行动交替进行的框架，奠定了“思考→行动→观察”的基本模式，但当时仅限于单步推理，尚未形成持续循环的概念。 AutoGPT（2023）：将循环真正运行起来，Agent 实现全自主决策与执行。然而问题在于它容易失控——目标漂移、无限循环、费用超支，热度来得快去得也快。 Agent SDK 时代（2025）：Claude SDK、OpenAI Agent SDK 等工具提供了结构化的循环框架，开发者可以编排 Agent 的执行流程，但循环的驱动力仍源于单次用户请求。 Loop Engineering（2026）：采用声明式目标与自动循环触发机制。人负责设计 loop 的结构（何时触发、使用哪些工具、如何判断完成），AI 则负责在 loop 内自主运行。人与机器的职责第一次被清晰地区分开来。Loop 的本质：一个公式
如果将 Loop 的本质压缩为一句话，大致可以表述为：
Cron 负责“何时推进下一轮”，决策器（即 LLM）负责“本轮应该做什么”。模型变成了你程序中的一个子程序，而你则成为这个循环的作者——你编写主循环，模型执行子程序。
概念层级链
将 Loop Engineering 置于更大的图景中观察，AI 工程化经历了层层递进的能力堆叠：
Prompt Engineering（如何与模型交流） → Harness Engineering（如何为模型构建稳定的运行环境） → Loop Engineering（如何让运行环境自主运转） → Factory Model（如何让多个 loop 协同工作，产出完整的软件成果）
每一层都建立在前一层的基础之上。没有 Harness 的隔离与工具调用能力，Loop 便无从谈起；没有 Loop 的持续运转能力，Factory 级别的多 Agent 协作也只是纸上谈兵。
六大原语
Addy Osmani 在梳理 Loop Engineering 时总结了六个核心原语，可作为设计一个 loop 的检查清单：
原语 | 作用 |
|---|---|
指令（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 内存注册表，记录每个活跃 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) 的查找效率。
这套设计表明作者确实在生产环境中踩过坑——只有被无限循环折磨过的人，才会在终止条件上如此谨慎。
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 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 不是终局，只是下一层台阶。 但站上去看，视野已经截然不同了。
