夜雨聆风
OpenClaw不仅仅是聊天框,还是Agent后台引擎,通过API接入现有平台
OpenClaw 通常的用法是独立部署——在自己的机器上跑，通过对话框或 Cron 和 Agent 交互。但 OpenClaw 也可以换一种方式用：作为后台 Agent 引擎，由现有业务平台通过 HTTP API 调度它。
一套运维平台，Prometheus 采集指标、AlertManager 发告警、自研 CMDB 管设备，已经稳定运行多年。现在想让告警处理自动化——来了告警自动查设备、算影响、出建议。方案不是把整个平台迁到 OpenClaw，而是在现有平台的告警回调里加一段 HTTP 调用，让平台去调 OpenClaw 的 API。下面讲具体做法。
一、什么场景应该用 API 调度，什么场景不用
应该用的场景
-
多步骤任务，步骤之间有依赖。告警处理分三步：先查设备信息，再算影响范围，最后出处理建议。计算之前必须拿到设备信息，建议之前必须拿到计算结果。这是典型的 DAG 任务——单次 LLM 调用的上下文装不下所有步骤的中间结果，需要拆任务、发任务、收结果。Supervisor-Worker 模式把这三个职责分给不同的 Agent。
-
需要调用多种外部工具。查设备要调 CMDB 的 REST API，算影响要调拓扑服务的 gRPC 接口，发通知要调企业微信的 Webhook。每个工具的认证方式、参数格式、返回结构都不一样。MCP 工具注册机制可以把这些异构工具统一包装成 Agent 能理解的标准接口。
-
平台已经在跑，不能停。告警采集不能断、工单系统不能关、CMDB 不能迁。API 调度模式不用动现有系统，只在上面加一层 HTTP 调用。
不应该用的场景
-
简单查询——”今天有几个 P1 告警”——不需要多 Agent 编排，一个 SQL 查询就够了。
-
延迟敏感——Supervisor 拆任务 + Worker 执行 + 汇总，至少要三四次 LLM 调用。如果告警必须在 500ms 内响应，这套链路太长。回退到规则引擎。
-
工具不超过三个且稳定不变——工具注册中心的解耦价值体现不出来，直接在 Agent 代码里硬编码更省事。
二、在现有平台中调度 OpenClaw Agent
2.1 平台端直接调 OpenClaw API
OpenClaw 启动后，Gateway 监听 18789 端口，提供 HTTP API。现有平台不需要中间层，直接 POST 过来：
import requestsOPENCLAW_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 调用。
2.2 OpenClaw 端的 Agent 配置
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: 5Agent 的行为全部由 system_prompt 和 tools 列表决定。工具注册在 OpenClaw 的工具目录中，启动时自动加载。
2.3 在 OpenClaw 中注册工具，打通现有平台接口
OpenClaw 的工具是 MCP 协议的标准实现。每个工具一个 Python 文件，放在 tools/目录下：
# tools/get_device_info.pyimport requestsdef 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.pydef 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 打通。
三、OpenClaw 的 Agent 怎么执行任务
调度不是简单的”把消息发给 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 循环：
-
第一轮推理——Agent 判断需要查设备信息，调
get_device_info(device_id="S9300-12")。工具函数内部 HTTP GEThttp://cmdb.internal/api/devices/S9300-12，返回设备型号、机房位置、维护责任人、近 7 天告警 3 次（上次为端口抖动）。结果注入 Agent 上下文。 -
第二轮推理——Agent 拿到设备信息后，判断需要评估影响。调
get_topology(device_id="S9300-12")拿到下游依赖列表，再调calculate_impact(alert_level="P1", device_id="S9300-12")，工具内部调拓扑服务和业务权重表，返回：业务 A 和 B 受影响，预估用户 2000，预计恢复 15 分钟。 -
第三轮——Agent 综合前两轮数据，生成处理建议：立即派单、备用链路切换方案。
-
第四轮——Agent 调
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.yamlRestart=alwaysRestartSec=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 变成后台引擎、让现有平台来调度，是另一种。