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 不是噱头，但有前提