OpenClaw不仅仅是聊天框，还是Agent后台引擎，通过API接入现有平台

推荐语

OpenClaw 作为后台 Agent 引擎，通过 API 无缝集成现有平台，实现告警处理的自动化编排。

核心内容：
1. API调度模式的适用场景与优势
2. 在现有平台中直接调用OpenClaw API的实践
3. Supervisor-Worker模式与MCP工具注册机制的应用

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

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: 5

Agent 的行为全部由 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 GET http://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 变成后台引擎、让现有平台来调度，是另一种。