用 api-gateway 技能把 OpenClaw 接入 100+ 外部服务：从 Notion 到 Google Calendar 的实战

那天凌晨，小蜜蜂差点把生产环境搞挂

2026-03-18，凌晨 2:46。

小蜜蜂在群里发了一条消息：「CMS API 挂了，PM2 进程没了。」

我打开监控面板，cms-api 的进程确实在 2:43 分 crash 了。重启后，5 分钟内又挂了两次。

查日志，发现一个问题：外部 API 调用把内存吃爆了。

当时我们的架构是这样的：

OpenClaw Agent → 直接调用 Notion API / Google Calendar API / Slack API

每个 Agent 都自己维护一套 API 凭据、一套重试逻辑、一套错误处理。15 个 Agent，就是 15 套重复代码。

那天之后，我花了 3 天时间把整个系统重构成了：

OpenClaw Agent → api-gateway 技能 → 统一的外部服务接入层

现在，15 个 Agent 共用一套 API 配置、一套重试机制、一套监控。代码量减少了 70%，稳定性提升了 3 倍。

api-gateway 技能是干啥的

一句话：让 OpenClaw 用统一的方式接入任何外部服务。

它不是简单的 HTTP 客户端。它提供了： 1. 凭据管理：API Key、OAuth Token 集中存储，不用硬编码在代码里 2. 请求模板：预定义常用 API 的请求格式，不用每次手写 3. 自动重试：429/503 自动重试，带指数退避 4. 速率限制：防止把外部 API 打挂 5. 日志审计：所有外部调用都有记录，方便排查

安装和配置

clawhub install api-gateway
openclaw config set api-gateway.services.notion.base_url "https://api.notion.com/v1" openclaw config set api-gateway.services.notion.auth_type "bearer" openclaw config set api-gateway.services.notion.token "secret_xxxxx"  # 从密钥管理读取
openclaw config set api-gateway.services.notion.rate_limit "3/s"

openclaw config set api-gateway.services.notion.retry.max_attempts "3" openclaw config set api-gateway.services.notion.retry.backoff "exponential"

关键点： 凭据不要直接写在配置文件里。我们用数据库加密存储，api-gateway 启动时从数据库读取。

实战使用：让 Agent 调用 Notion API

配置好后，Agent 调用 Notion API 只需要一行：

// 在 Agent 代码里

const result = await gateway.call('notion', { method: 'POST', path: '/pages', body: { parent: { database_id: 'xxx' }, properties: { Name: { title: [{ text: { content: '新任务' } }] } } } });

对比之前的写法：

// 之前的写法（每个 Agent 都要写一遍）
const response = await fetch('https://api.notion.com/v1/pages', { method: 'POST', headers: { 'Authorization': `Bearer ${process.env.NOTION_TOKEN}`, 'Notion-Version': '2022-06-28', 'Content-Type': 'application/json' }, body: JSON.stringify({...}) });

// 手动处理 429 if (response.status === 429) { await sleep(1000); // 重试逻辑... }

代码量减少了 60%，而且不用每个 Agent 都维护一套重试逻辑。

踩坑记录

坑 1：OAuth Token 刷新

Google Calendar API 的 Access Token 有效期只有 1 小时。一开始我们没处理刷新逻辑，结果每天凌晨 3 点所有 Calendar 相关的 Agent 集体失效。

解决方案： api-gateway 内置了 OAuth Token 自动刷新。检测到 401 错误时，自动用 Refresh Token 换新 Token，然后重试原请求。

openclaw config set api-gateway.services.google.auth_type "oauth2"

openclaw config set api-gateway.services.google.oauth.token_endpoint "https://oauth2.googleapis.com/token" openclaw config set api-gateway.services.google.oauth.client_id "xxx" openclaw config set api-gateway.services.google.oauth.client_secret "xxx" # 从密钥管理读取 openclaw config set api-gateway.services.google.oauth.refresh_token "xxx" # 从密钥管理读取

坑 2：速率限制没配好，把 Slack API 打挂了

有一次，15 个 Agent 同时往 Slack 发消息，瞬间把 Slack API 的速率限制打满了。结果整个团队的 Slack 通知停了 2 小时。

解决方案： 给每个服务配严格的速率限制，api-gateway 会在本地做令牌桶限流。

openclaw config set api-gateway.services.slack.rate_limit "1/s"

openclaw config set api-gateway.global.max_concurrent "5"

坑 3：错误日志太多，找不到重点

一开始，api-gateway 把所有请求都记日志。一天下来，日志文件 2GB，查问题根本找不到重点。

解决方案： 只记录错误和慢请求。

openclaw config set api-gateway.logging.log_success "false"

openclaw config set api-gateway.logging.log_error "true" openclaw config set api-gateway.logging.slow_threshold_ms "1000" # 超过 1 秒的请求才记录

和其他技能的配合

api-gateway 经常和这些技能一起用：

1. n8n-automation：api-gateway 处理简单 API 调用，复杂工作流交给 n8n 2. self-improving-agent：API 调用失败时，自动记录到错题本 3. multi-agent-cn：多个 Agent 共用一套 API 配置，避免重复

实战场景： 我们的日更内容 pipeline

小狐狸写文章 → api-gateway 调用 CMS API 发布

→ api-gateway 调用 OSS API 上传封面图 → api-gateway 调用 Telegram API 发通知

三个外部调用，全部通过 api-gateway，统一监控、统一重试、统一日志。

SFD 实验室怎么用的

我们 15 个 Agent，有 12 个需要调用外部服务：

Agent调用的外部服务 小狐狸🦊CMS API, OSS API, Telegram API 小蜜蜂🐝SSH, PM2 API, Certbot 小章鱼🐙PostgreSQL, Redis 小鹦鹉🦜Twitter API, LinkedIn API 招财猫🐱港股 API, 汇率 API ......

之前每个 Agent 自己维护一套配置，改个 API Key 要改 12 个地方。现在全部集中到 api-gateway，改一处，全局生效。

效果：

• 配置错误减少了 90%

API 调用失败率从 8% 降到 1.2%

排查问题的时间从平均 30 分钟降到 5 分钟

写在最后

那天凌晨 3:47，我把 api-gateway 的配置全部上线。

小蜜蜂在群里发：「cms-api 稳了，内存占用从 512MB 降到 180MB。」

Franky 说：「早该这么干了。」

行。下次我早点发现。

---

SFD 编者注： api-gateway 技能的核心价值不是「能调用 API」，而是统一治理。15 个 Agent、100+ 外部服务，如果没有统一网关，就是 100+ 个潜在的故障点。2026 年，任何超过 5 个 Agent 的团队，都应该考虑用 api-gateway 做统一接入层。