目录

一、先给结论：Agent Runtime 的工程本质

二、关键澄清：Agent ≠ Runtime

1. Agent

2. Agent Runtime

三、Agent Runtime 具体在做什么？（工程拆解）

1. Run 初始化：确认“可执行”的前提

2. 上下文装配（Context Assembly）：Runtime 最核心的一步

3. 执行循环（LLM → Tool → LLM）：拒绝“过度想象”

4. 工具调用的受控执行：守住“安全阀门”

5. 上下文压缩与裁剪：生产级系统的必备能力

6. Run 结束与状态回收：避免“僵尸执行”

四、为什么 Runtime 必须是“中立的执行器”？

五、工程视角下的 3 个关键设计价值

1. 可预测性

2. 可中断性

3. 可审计性

六、总结：Runtime 最怕被写成“魔法”

七、这一层在整个系列中的位置

---

在前两篇内容中，我们已经明确了两个核心要点：

• 第一层：系统是如何被触发的（输入边界）
• 第二层：触发之后，如何被统一调度与治理（Gateway / 控制平面）

现在我们进入第三层，也是最容易被误解的一层——Agent Runtime。

很多人一看到 Runtime，就下意识认为：“哦，这里就是 Agent 在跑的地方”。但如果你真的把 Runtime 当成“Agent 本体”，后续的理解几乎一定会走偏。

一、先给结论：Agent Runtime 的工程本质

在 OpenClaw 体系里，Agent Runtime 的本质是：

一个受控的执行操作系统（Execution OS），专门负责把“一次被允许的 Run”安全、可预测地跑完。

它的核心关键词不是“聪明、决策、自主”，而是：

装配、执行、约束、回收

二、关键澄清：Agent ≠ Runtime

先理清二者关系，否则后续所有理解都会混乱。在 OpenClaw 中：

1. Agent

• 本质是一份执行规格
• 核心作用：描述可用的 Skill、受哪些 Policy 约束
• 关键特点：本身不具备执行能力

2. Agent Runtime

• 本质是执行环境
• 核心作用：把 Agent 的执行规格“跑起来”
• 类比理解：像操作系统运行进程一样，运行 Agent

一句话快速记忆：Agent 是“程序描述”，Runtime 是“运行这个程序的操作系统”。

三、Agent Runtime 具体在做什么？（工程拆解）

把一次 Run 拆解来看，Runtime 至少要完成 6 件核心工作，每一步都对应关键工程逻辑：

1. Run 初始化：确认“可执行”的前提

Runtime 接收到的不是随机消息，而是 Gateway 已经决策通过的 Run。这意味着：入口合法、会话合法、权限合法、策略初步通过。

核心原则：Runtime 从一开始就默认“这是可执行任务”，而非判断“要不要执行”。

2. 上下文装配（Context Assembly）：Runtime 最核心的一步

Runtime 会整合多来源上下文，统一供给执行使用，包括：当前 Session 的状态、Workspace / Memory 中的历史记录、当前 Agent 的 Skill 声明、Policy 约束、本次 Trigger 的输入。

关键工程细节：Runtime 不会把所有上下文一股脑塞给 LLM，而是按执行阶段动态装配——否则会被 token 消耗、成本失控、不可控行为拖垮系统。

3. 执行循环（LLM → Tool → LLM）：拒绝“过度想象”

这是大家最熟悉的环节，但容易陷入认知误区。在 Runtime 中，这个循环有明确硬约束：

• LLM 只能输出结构化结果
• Tool 调用必须符合 Skill 声明和 Tool Policy
• Runtime 是唯一调度者，LLM 不直接调用任何工具

工程视角总结：LLM 更像“策略生成器”，而非“执行者”。

4. 工具调用的受控执行：守住“安全阀门”

当 Runtime 判定“可调用 Tool”时，不会直接执行，而是先完成3步校验与决策：

• 校验 Tool 是否在 Skill 白名单中
• 校验是否触发 Policy 限制
• 决策运行环境：在 sandbox（沙箱）或 elevated（特权）环境中执行

同时，Runtime 会记录完整调用痕迹——Tool 是危险能力，Runtime 是最后一道理性防线。

5. 上下文压缩与裁剪：生产级系统的必备能力

这是很多 Agent Demo 刻意回避的关键环节，但却是生产落地的核心要求。Runtime 必须持续做3件事：历史裁剪、结果摘要、状态压缩。

若不做这些操作，会导致：token 溢出、行为偏离预期、成本失控。

老师傅经验总结：不敢删上下文的 Runtime，一定不敢上生产。

6. Run 结束与状态回收：避免“僵尸执行”

一次 Run 结束后，Runtime 需完成收尾工作，确保系统整洁可控：

• 更新 Session 状态
• 将结果写入 Workspace / Memory
• 标记 Run 的状态（成功 / 失败 / 中断）
• 将最终结果交回 Gateway 或入口

核心提醒：Run 是一次性执行单元，而非常驻进程——这是 OpenClaw 与“常驻 Agent 幻觉”的关键区别。

四、为什么 Runtime 必须是“中立的执行器”？

常见误解：Runtime 会不会越来越聪明，最终取代 Agent？

工程答案：绝对不能。原因很简单：一旦 Runtime 拥有判断权，就会与 Gateway、Policy 的职责重叠，导致系统边界崩塌。

OpenClaw 的设计原则非常克制：判断在控制平面，执行在执行平面。Runtime 只专注一件事：把“已经允许的事情”安全跑完。

五、工程视角下的 3 个关键设计价值

1. 可预测性

Runtime 不追求创造性和惊喜，核心目标是：每一步执行可解释、每一次 Run 可回放——这是系统稳定的基础。

2. 可中断性

真实生产环境中，LLM 可能卡顿、Tool 可能崩溃、外部系统可能超时。因此 Runtime 必须支持：超时处理、中断执行、安全退出——否则会产生“僵尸 Agent”，消耗系统资源。

3. 可审计性

Runtime 需对所有执行过程留痕，包括：上下文如何装配、Tool 为何被调用、Policy 如何生效。这不是为了调试，而是为了明确责任边界，满足生产级系统的合规要求。

六、总结：Runtime 最怕被写成“魔法”

很多 Agent 框架的问题，不在于 LLM 能力不足、Tool 数量不够，而在于 Runtime 被写成了“黑盒魔法引擎”——神秘、拟人、自作主张。

OpenClaw 的 Runtime 设计恰恰相反：不神秘、不拟人、不自作主张，更像一个冷静的系统组件，核心职责就是：你给我一个被允许的 Run，我保证它在边界内、按规则跑完。

七、这一层在整个系列中的位置

到这里，我们已经掌握了 OpenClaw 系统层的三个核心环节：

1. 系统如何被触发（入口层）
2. 触发后如何被治理（Gateway / 控制平面）
3. 执行如何安全完成（Runtime / 执行平面）

吃透系统层的这三个核心环节，是我们后续掌握 OpenClaw 完整能力体系的关键前提——下一期，我们将正式迈入能力层，聚焦支撑 Runtime 高效执行的核心能力底座，重点拆解：

• Workspace / Memory：状态与持久化骨架
• Skills：能力声明与边界合同
• Tools & Policy：危险能力的最后防线