OpenClaw 的 Agent Runner 是如何工作的？一次 Agent 运行经历了哪些阶段？

🏛 业务架构师

Agent Runner 是 OpenClaw 的执行引擎，一次 Agent 运行的阶段我概括为"装载→装配→循环→收尾"：

1. 装载期（Load）：读取该 Agent 的配置——System Prompt、模型选择（LLM Provider 路由）、工具清单与权限、Hook 链、记忆策略。相当于员工上岗前领工牌、工具包和操作规程。

2. 上下文装配期（Assemble）：Context Engine 组装上下文——System Prompt + 会话历史（按策略裁剪/摘要）+ 长期记忆召回 + 当前用户消息，并核对 token 预算。装配质量直接决定模型发挥。

3. 推理循环期（Agent Loop）：调 LLM 生成 → 若输出工具调用意图：经工具权限管道校验 → 执行工具 → 结果由 Context Engine 截断/摘要后回填 → 再调 LLM……循环直到模型给出最终文本或触发终止条件（步数上限、预算上限、超时）。

4. 收尾期（Finalize）：执行输出 Hook（安全过滤、格式化）→ 持久化会话与审计日志 → 计量 token 成本 → 通过 Gateway/Channel 下发回复。

设计亮点（自研可借鉴）：运行与配置分离（同一 Runner 跑不同 Agent）、循环有硬性熔断、每阶段都有 Hook 切面可插入企业管控。这套"引擎与业务分离"的思路，正是 Agent 平台支撑多业务线的架构前提。

Agent Runner 是 OpenClaw 的任务执行内核，我按一次运行的生命周期阶段讲：

触发与初始化：消息到达或任务调度触发 → 加载 Agent 定义（System Prompt、工具集、模型配置、权限策略）→ 初始化运行环境（沙箱、变量、执行预算：步数/token/时长上限）；
上下文装配：从 Context Engine 取数——历史（裁剪后）、长期记忆、检索内容、System Prompt，组装首版上下文，做窗口预算分配；
推理-行动循环（核心阶段）：调 LLM → 解析输出：纯文本 = 最终答案，结束；工具调用 = 走权限管道校验 → 沙箱执行 → 结果处理（压缩/落盘）回填上下文 → 进入下一轮；每轮检查预算与终止条件；
异常与中断处理：工具失败回结构化错误供模型改道；预算耗尽优雅终止（输出中间结果）；支持挂起（等待人工输入/审批）与恢复（checkpoint 续跑）——长任务的断点续传能力在这里；
收尾：产出最终回复 → 异步任务收尾（记忆抽取、指标上报、审计落盘、沙箱清理）。

架构师视角：Runner 的设计要点是把"不可靠的模型循环"包进"可靠的运行时外壳"——预算熔断、幂等、checkpoint、沙箱隔离四件套决定了它能否生产化。类比操作系统：LLM 是 CPU，Runner 是进程调度与资源管理子系统。

Agent Runner 是 OpenClaw 的执行核心，一次运行按阶段拆：

1. 初始化（Setup）：加载 Agent 定义（system prompt、模型配置、工具集声明）；恢复会话状态（或新建）；初始化预算（max_steps、token 上限、超时时钟）；注册本轮 Hook。

2. 上下文构建（每轮循环都做）：向 Context Engine 请求本轮上下文——窗口裁剪、Compaction 检查（超阈值先压缩）、长期记忆检索、工具 schema 注入。产出「本轮消息数组」。

3. 推理（Reason）：调 LLM，拿到输出：纯文本（可能就是最终答案）、tool_call（进入行动）、或停止信号。

4. 行动（Act）：tool_call 进入权限管道 → 校验通过则沙箱执行（超时、资源限制）→ 结果裁剪/摘要 → 作为 tool 消息追加。confirm 类工具挂起任务等待人工回调（这时任务状态持久化，进程可以释放——异步设计的价值）。

5. 观察-循环（Observe & Loop）：回到 2，直到模型给出最终回复，或触发终止条件（步数/token/时间超限、循环检测指纹命中）。

6. 后处理（Teardown）：记忆抽取写入、审计与计费落账、会话状态持久化、清理沙箱。

我借鉴到自研框架的三个设计：预算对象在初始化时创建并全程扣减（想失控都难）；每轮循环无状态化+状态外存，进程崩了能从检查点恢复；工具执行与 LLM 调用异步解耦，confirm 类操作不占计算资源。