9.1 控制平面职责与边界

本节以官方 Gateway 能力为准，说明控制平面为什么必须承担“身份、归属、裁决”三类责任：谁能连、这条消息归谁、这次允许做什么。重点不是抽象术语，而是把这些裁决点落到可配置、可观测、可审计的工程行为，并给出一套用 status 与 health 快速定界故障层级的排障路径。

9.1.1 控制平面要裁决什么：身份、归属与策略

在 OpenClaw 中，Gateway 不只是一个转发器。它必须在消息进入执行环前完成三类裁决。

• 身份：连接或消息是否来自可信主体，凭据是否有效，是否处于吊销或冷却状态。

• 归属：消息应该路由到哪个智能体与哪个会话，避免串话与重复消费。

• 策略：本次请求是否命中访问控制、群聊门控、工具治理与安全防护栏。

这些能力的配置入口分散在 Gateway 配置、渠道配置、会话与配对治理里。

9.1.2 边界划分：控制平面与执行平面的接口契约

工程上要把控制平面与执行平面的边界写成契约。

• 控制平面负责拒绝与降级：不满足身份或策略的请求应尽早拒绝。

• 执行平面负责推理与工具：只处理“已被裁决允许”的任务，并把结果与副作用回注为证据。

边界清晰的直接收益是可排障：当出现故障时，能用观测信号判断是“入口拒绝”“路由异常”“模型失败”还是“工具失败”。

9.1.3 可观测与可审计：控制面必须产出证据链

控制平面做的每一次关键决定，都应在日志与审计里留下证据。

• 允许或拒绝的原因。

• 路由与会话键。

• 配对与白名单是否命中。

• 工具策略是否拦截。

官方对安全与网关职责的说明可参考：https://docs.openclaw.ai/gateway/security 与 https://docs.openclaw.ai/gateway。

9.1.4 典型工作流与执行时序（以带审批的系统动作为例）

为了直观体会 Gateway 作为“控制中心”对数据流转的把控，我们可以来看一个典型的工作流：当用户在 Telegram 中命令智能体在宿主机上执行一个敏感的 Shell 脚本时，全链路的时序是如何协作的。

图 9-1：带有安全审批的 Gateway 核心流转时序图

在这个闭环中，Gateway 一方面对前维持了聊天连接（ChatProvider），另一方面对后启动了智能体推理（Runtime），又在中间横插一手拦截了敏感的系统操作（ExecTool），并再次回调人的意图（Approve）。

9.1.5 排障命令：先用 health 与 status 定界

当系统表现为“没响应”或“偶发断线”，建议先用两个命令把问题定界。

# 健康检查，适合做自动化探测

openclaw health --json

# 状态总览，--deep 会触发更深的探测

openclaw status --deep

如果 health 异常而 status 显示依赖不可用，优先回到认证与渠道状态；如果 status 正常但执行异常，优先看工具链路与模型回退。