OpenClaw 通常的用法是独立部署——在自己的机器上跑,通过对话框或 Cron 和 Agent 交互。但 OpenClaw 也可以换一种方式用:作为后台 Agent 引擎,由现有业务平台通过 HTTP API 调度它。
一套运维平台,Prometheus 采集指标、AlertManager 发告警、自研 CMDB 管设备,已经稳定运行多年。现在想让告警处理自动化——来了告警自动查设备、算影响、出建议。方案不是把整个平台迁到 OpenClaw,而是在现有平台的告警回调里加一段 HTTP 调用,让平台去调 OpenClaw 的 API。下面讲具体做法。

OpenClaw 启动后,Gateway 监听 18789 端口,提供 HTTP API。现有平台不需要中间层,直接 POST 过来:
import requests
OPENCLAW_GATEWAY = "http://localhost:18789"
def on_alert(alert_msg: str):
"""告警回调。直接调 OpenClaw API"""
# 创建一个 Session,OpenClaw 会返回 session_id,后续追问可以复用
resp = requests.post(
f"{OPENCLAW_GATEWAY}/api/sessions",
json={"label": f"告警-{alert_msg[:30]}"},
timeout=10,
)
session_id = resp.json()["id"]
# 向 Agent 发送消息,OpenClaw 内部走 ReAct Loop 处理
resp = requests.post(
f"{OPENCLAW_GATEWAY}/api/sessions/{session_id}/messages",
json={
"content": alert_msg,
"tools": ["get_device_info", "calculate_impact",
"get_topology", "send_wework"],
},
timeout=60,
)
data = resp.json()
# data["reply"] → Agent 的最终回复
# data["tool_calls"] → Agent 调了哪些工具、各返回了什么
return data平台端不引入 OpenClaw 依赖,不引入 Agent 框架,就是标准 HTTP 调用。
OpenClaw 启动时加载配置文件,定义 Agent 的角色、可用工具和系统提示词:
# openclaw.config.yamlagents: supervisor: name: 告警调度员 model: claude-sonnet-4-6 system_prompt: | 你是一个告警处理调度器。收到告警后: 1. 分析告警内容,判断需要哪些信息 2. 调用 get_device_info 获取设备详情 3. 调用 get_topology + calculate_impact 评估影响范围 4. 综合以上信息,生成处理建议 5. 调用 send_wework 推送到运维群 工具调用顺序遵循:先查信息,再计算,最后发通知。 tools: - get_device_info - get_topology - calculate_impact - send_wework max_tool_rounds: 5
# openclaw.config.yaml
agents:
supervisor:
name: 告警调度员
model: claude-sonnet-4-6
system_prompt: |
你是一个告警处理调度器。收到告警后:
1. 分析告警内容,判断需要哪些信息
2. 调用 get_device_info 获取设备详情
3. 调用 get_topology + calculate_impact 评估影响范围
4. 综合以上信息,生成处理建议
5. 调用 send_wework 推送到运维群
工具调用顺序遵循:先查信息,再计算,最后发通知。
tools:
- get_device_info
- get_topology
- calculate_impact
- send_wework
max_tool_rounds: 5Agent 的行为全部由 system_prompt 和 tools 列表决定。工具注册在 OpenClaw 的工具目录中,启动时自动加载。

OpenClaw 的工具是 MCP 协议的标准实现。每个工具一个 Python 文件,放在 tools/目录下:
# tools/get_device_info.py
import requests
def run(device_id: str) -> dict:
"""根据设备ID查询设备详情、历史告警"""
resp = requests.get(
f"http://cmdb.internal/api/devices/{device_id}",
headers={"Authorization": "Bearer {CMDB_TOKEN}"},
timeout=5,
)
data = resp.json()
return {
"device_name": data["name"],
"location": data["location"],
"owner": data["owner"],
"recent_alerts": data["alert_history"][:5],
}
# 工具元数据:Agent 通过 description 判断何时调用
TOOL_META = {
"name": "get_device_info",
"description": "查询设备详情、机房位置、维护责任人、近期告警历史。"
"当告警中包含设备名称或设备ID时调用此工具。",
"parameters": {
"type": "object",
"properties": {
"device_id": {"type": "string", "description": "设备唯一标识"}
},
"required": ["device_id"],
},
}# tools/calculate_impact.py
def run(alert_level: str, device_id: str) -> dict:
"""计算告警影响范围"""
# 1. 调拓扑服务拿下游依赖
topo = requests.get(
f"http://topo.internal/api/devices/{device_id}/downstream",
timeout=5,
).json()
# 2. 根据告警级别 + 下游依赖查业务权重表
# ...计算逻辑
return {
"affected_businesses": ["业务A", "业务B"],
"estimated_users": 2000,
"estimated_recovery_minutes": 15,
}
TOOL_META = {
"name": "calculate_impact",
"description": "计算告警影响范围,返回受影响的业务列表、预估用户数、预估恢复时间。"
"等级为 P1 或影响核心设备时优先调用。",
"parameters": {
"type": "object",
"properties": {
"alert_level": {"type": "string", "description": "P1/P2/P3"},
"device_id": {"type": "string", "description": "告警设备ID"},
},
"required": ["alert_level", "device_id"],
},
}工具代码跑在 OpenClaw 进程内,底层 HTTP 调用打到现有平台的 CMDB、拓扑服务、企业微信接口。对 OpenClaw 来说是一个函数调用,对现有平台来说是一个普通的 API 请求。两层之间通过 HTTP 打通。

调度不是简单的"把消息发给 Agent,等回复"。OpenClaw 内部走的是 ReAct 循环:
第一步:Agent 读消息,判断需要什么信息。告警文本"核心交换机 S9300-12 端口 Down,级别 P1"进来后,Agent 根据 system_prompt 中的规则判断:需要先查设备信息。
第二步:Agent 决定调哪个工具。Agent 扫描可用工具列表,匹配 description。get_device_info的描述是"查询设备详情...当告警中包含设备名称时调用",匹配。Agent 输出工具调用请求,OpenClaw Gateway 拦截,调对应工具的 run()函数,拿到 CMDB 返回的数据后注入回 Agent 上下文。
第三步:Agent 基于工具返回的数据继续推理。拿到设备信息后,Agent 判断下一步需要评估影响范围。调 get_topology查下游依赖,再调 calculate_impact算影响面。每个工具调用都是一次完整的"分析→决策→执行→观察"循环。
第四步:生成最终回复。Agent 综合所有工具返回的数据,按 system_prompt 要求的格式输出处理建议。最后调 send_wework把结果推送到运维群。
整个过程平台端不参与——平台只发了第一条消息,后续的推理和工具调用全部由 OpenClaw 内部的 ReAct Loop 驱动。max_tool_rounds: 5限制了最多 5 轮工具调用,防止死循环。
检测到核心交换机端口异常 → AlertManager 触发告警 → 告警回调函数 on_alert被调用,拿到告警文本"核心交换机 S9300-12 端口 Down,级别 P1"。
on_alert调 OpenClaw Gateway 的 API,创建 Session,发送消息,附带四个可用工具的名称。
OpenClaw Agent 收到消息,执行 ReAct 循环:
get_device_info(device_id="S9300-12")。工具函数内部 HTTP GET http://cmdb.internal/api/devices/S9300-12,返回设备型号、机房位置、维护责任人、近 7 天告警 3 次(上次为端口抖动)。结果注入 Agent 上下文。get_topology(device_id="S9300-12")拿到下游依赖列表,再调 calculate_impact(alert_level="P1", device_id="S9300-12"),工具内部调拓扑服务和业务权重表,返回:业务 A 和 B 受影响,预估用户 2000,预计恢复 15 分钟。send_wework推送到运维群。Agent 返回最终回复给 Gateway,Gateway 返回给 on_alert。整个链路对平台端是一次 HTTP POST + 等待响应,内部推理和工具调用由 OpenClaw 自动完成。
OpenClaw Gateway 本身是一个常驻进程,用 systemd 守护:
[Service]
ExecStart=/usr/local/bin/openclaw gateway --port 18789 --config /etc/openclaw/config.yaml
Restart=always
RestartSec=5生产部署关注三个点:
超时控制。OpenClaw 的 max_tool_rounds限制了工具调用轮数,Timeout 设置限制单次 Agent 执行的总时长。平台端 HTTP 调用的 timeout=60是第二道防线——超时后平台可以做降级处理。
Token 用量。OpenClaw 每次 Agent 执行返回 usage字段,包含 prompt_tokens 和 completion_tokens。平台端可以记录每次告警分析的 Token 消耗,用于成本追踪。
错误处理。工具调用失败(CMDB 接口挂了、超时),OpenClaw 将错误信息注入 Agent 上下文,Agent 可以据此调整回复——"无法查询设备信息,请人工确认 S9300-12 状态"。平台端 HTTP 超时或返回 5xx 时,告警回调做降级处理——走老的规则引擎或人工通知。

把 OpenClaw 当作后台 Agent 引擎、由现有平台通过 HTTP API 调度,适合平台已稳定运行不能迁移、需要多步骤推理和工具调用、工具类型多变需要灵活组合的场景。不适合简单查询、延迟敏感(毫秒级响应)、工具少且固定的场景。
平台端的改动:告警回调里加一个 HTTP POST 到 OpenClaw Gateway(18789 端口)。OpenClaw 端的配置:一个 YAML 文件定义 Agent 和工具列表,每个工具一个 Python 文件包装现有平台的接口。两层之间只有 HTTP,不共享进程、不共享文件系统。
核心判断不是用不用 OpenClaw,而是怎么用。独立部署、对话框、Cron 是一种用法。把 OpenClaw 变成后台引擎、让现有平台来调度,是另一种。