/loop 实现，看 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源生成器序列化所有 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 的魅力就在于此——它不是给你一个固定的运行方式，而是给你一套组合原语，让你根据场景搭配出合适的自主运行模式。