OpenClaw：轻量级智能体调度中枢实战指南

1. OpenClaw 是什么？它不是另一个“本地大模型前端”，而是一套轻量级智能体调度中枢

OpenClaw 这个名字在最近三个月的开发者社区里出现频率陡增，但很多人第一次看到时下意识会把它和 Dify、Ollama、ComfyUI 这类工具划等号——认为它是个“本地部署的大模型聊天界面”或者“可视化提示词编排器”。这是最典型的误判。我花了一周时间把它的源码翻了三遍、跑了七种不同配置组合、踩了包括飞书机器人权限链断裂、MinerU PDF解析超时、本地模型路由错配在内的十二个坑之后，才真正理解：OpenClaw 的本质，是一个面向工作流场景的、极简主义的智能体（Agent）运行时调度器，它的核心价值不在于“跑模型”，而在于“管动作”。

它不内置任何大语言模型，也不提供训练能力；它甚至不直接处理用户输入的自然语言。你给它一个 JSON 格式的技能定义（Skill），它就负责把这个定义里的“触发条件→参数提取→模型调用→结果格式化→输出投递”这一整条链路串起来，并确保每个环节可观察、可调试、可灰度。比如你要实现“飞书群内发 /summary 就自动总结今天所有未读消息”，OpenClaw 不关心你是用 Qwen3-VL 看图，还是用 DeepSeek-R1 做摘要，它只关心：这个命令怎么被识别？消息列表从哪来？摘要结果怎么塞进飞书卡片里？失败了报什么错误码？这些才是它真正发力的地方。

这解释了为什么搜索热词里反复出现 “openclaw 接入飞书”、“openclaw 飞书机器人”、“error: 发送飞书失败, 返回信息:{"code":11232,"msg":"frequency limited"} —— 因为绝大多数人卡在了“调度器”和“执行端”的握手环节，而不是模型本身。11232 错误码根本不是 OpenClaw 的问题，它是飞书平台对机器人 API 调用频次的硬性限制，OpenClaw 只是那个如实把错误透传回来的“信使”。如果你没在 OpenClaw 的配置里启用重试退避（exponential backoff）或本地缓存队列，那它就会忠实地每秒尝试三次，然后被飞书直接拉黑一小时。

关键词里高频出现的 “本地部署” 也常被误解。OpenClaw 的“本地”不是指“把 Llama-3-70B 拉到自己笔记本上跑”，而是指整个调度逻辑、技能注册中心、API 网关、日志追踪全部运行在你可控的环境里——可以是 Windows WSL2，可以是群晖 Docker，也可以是树莓派。它默认监听http://localhost:8080，所有配置文件都是纯文本 YAML，没有后台管理界面，没有云同步账户，没有 SaaS 订阅。这种设计让企业内网、离线审计、合规审查变得极其简单：你删掉那个openclaw.yaml文件，整个系统就彻底消失，不留痕迹。

所以，当你打开终端输入openclaw start的那一刻，你启动的不是一个 AI 应用，而是一个微型的、可编程的“数字员工调度台”。它不聪明，但它极度可靠；它不炫技，但它绝不甩锅。接下来要讲的每一个步骤，都围绕着如何把这个调度台稳稳地安放在你的本地机器上，并让它和飞书机器人建立起一条不掉链子的通信通道。

2. 为什么必须放弃“一键安装包”？从源码构建是唯一可控的起点

几乎所有新手教程开头都会写：“下载最新 release 的二进制文件，chmod +x，然后 ./openclaw start”。我试过，而且是在三台不同配置的机器上试的——Mac M2、Windows 11 WSL2 Ubuntu 24.04、群晖 DS923+ Docker。结果无一例外：启动后访问http://localhost:8080/healthz返回 503，日志里只有一行failed to load config: open openclaw.yaml: no such file or directory，然后进程静默退出。这不是 Bug，这是设计哲学：OpenClaw 拒绝任何形式的“开箱即用”，它强制你从第一行配置开始，亲手定义这个调度台的边界。

原因很现实。OpenClaw 的核心依赖项里，有三个是高度环境敏感的：

• MinerU：负责 PDF、PPT、Word 文档的结构化解析。它底层调用的是pdfiumC++ 库，而这个库在不同 Linux 发行版上的动态链接库路径（.so文件位置）完全不同。Ubuntu 默认装在/usr/lib/x86_64-linux-gnu/，Alpine 在/usr/lib/，而群晖 DSM 的ldconfig根本不认这个路径。二进制包里打包的 MinerU 是针对 Ubuntu 构建的，扔到群晖上必然libpdfium.so: cannot open shared object file。

• 飞书 SDK 的认证模块：它依赖golang.org/x/oauth2，而这个包在 Go 1.21 之后引入了net/http/httptrace的深度钩子。如果你的系统里装了旧版 Go（比如群晖套件中心里那个 1.19），编译出来的二进制在调用飞书 OAuth2 接口时，会在RoundTrip阶段 panic，错误信息藏在http.Client的 trace 里，根本不会打到 OpenClaw 主日志中。

• 本地模型路由的健康检查：OpenClaw 启动时会向你配置的ollama或lmstudio地址发一个GET /api/tags请求。这个请求的超时时间硬编码为 3 秒。但在 WSL2 环境下，由于虚拟网络栈的 NAT 延迟，3 秒经常不够，导致 OpenClaw 直接判定模型服务不可用，连配置文件都不加载就退出。

所以，正确的起点只有一个：用你本地已有的、版本明确的 Go 工具链，从 GitHub 官方仓库拉取源码，现场编译。这不是折腾，而是建立信任的第一步。你得亲眼看着它怎么链接 MinerU，怎么注入飞书 SDK，怎么生成最终的可执行文件。过程如下（以 Ubuntu 24.04 为例，其他系统仅路径微调）：

# 1. 确保 Go 版本 >= 1.22（这是硬性要求，低于此版本无法编译飞书 SDK 的新认证流） $ go version go version go1.22.5 linux/amd64 # 2. 克隆官方仓库（注意：必须是 main 分支，dev 分支有未合并的飞书 v3 API 改动） $ git clone https://github.com/open-claw/openclaw.git $ cd openclaw # 3. 编译前，先手动验证 MinerU 是否能被正确链接 # 进入 mineru 子模块，运行其自带的测试 $ cd cmd/mineru $ go test -v ./... # 如果这里失败，说明你的系统缺少 pdfium 开发头文件 # Ubuntu 上执行：sudo apt install libpdfium-dev libpoppler-cpp-dev # Alpine 上执行：apk add pdfium-dev poppler-cpp-dev # 4. 回到根目录，编译 OpenClaw 主程序 $ cd ../.. $ make build # 这会触发 go build -o bin/openclaw ./cmd/openclaw # 编译成功后，bin/openclaw 就是你专属的、与你系统完全匹配的二进制

提示：make build这个命令背后，Makefile 会自动执行go mod download和go mod verify，确保所有依赖的 checksum 与官方一致。这是防止供应链攻击的关键一步。很多“快速安装教程”跳过这步，直接go install，结果拉下来的是被中间代理篡改过的lark-sdk-go，导致后续飞书签名永远验不过。

编译完成后，别急着运行。先执行./bin/openclaw version，你会看到类似这样的输出：

OpenClaw v0.8.3 (commit: a1b2c3d) Built with go1.22.5 on linux/amd64 MinerU: v0.5.1 (pdfium: 5210) Lark SDK: v3.2.0 (OAuth2 flow: v3)

这个输出里的每一个字段，都是你未来排查问题的黄金线索。比如MinerU: v0.5.1告诉你文档解析引擎的版本，Lark SDK: v3.2.0告诉你用的是飞书最新的机器人认证协议。如果某天你发现 PDF 解析失败，第一反应不应该是“重装 OpenClaw”，而是去查v0.5.1的 MinerU Release Notes，看是否已知某个 Office 365 新格式的兼容性问题。

这就是从源码构建的价值：你不再是一个被动的使用者，而是一个拥有完整上下文的协作者。每一个错误，你都能精准定位到是 OpenClaw 的调度逻辑问题，还是 MinerU 的解析引擎问题，或是飞书 SDK 的认证流程问题。这种颗粒度的掌控感，是任何“一键安装包”永远无法提供的。

3. 飞书机器人接入不是“填个 token 就完事”，而是三重身份校验的精密协作

当./bin/openclaw start终于成功打印出Server started on :8080时，很多人会立刻打开浏览器访问http://localhost:8080/skills，期待看到一个漂亮的 Web UI。结果页面一片空白，控制台只有一行404 Not Found。这是因为 OpenClaw 根本没有 Web UI。它的全部交互，都通过一套严格定义的 REST API 和一个同样严格的飞书机器人配置流程来完成。而后者，恰恰是整个部署链条里最脆弱、最容易被忽略的一环。

飞书机器人不是简单的“消息转发器”，它是一个拥有三重独立身份的实体：

1. 应用身份（App Identity）：由飞书开放平台分配的APP_ID和APP_SECRET，用于换取长期有效的APP_ACCESS_TOKEN。这个 token 是 OpenClaw 向飞书平台证明“我是谁”的凭证。

2. 机器人身份（Bot Identity）：由飞书管理员在“机器人管理”页面创建的BOT_VERIFICATION_TOKEN和BOT_ENCRYPT_KEY。这两个密钥是飞书用来验证“发来的消息确实来自我的机器人，而不是黑客伪造的”——所有飞书发给你的 Webhook 消息，都经过 AES-256-GCM 加密，并用BOT_ENCRYPT_KEY签名，BOT_VERIFICATION_TOKEN用于校验签名。

3. 群组身份（Group Identity）：每个飞书群组都有一个唯一的CHAT_ID。OpenClaw 必须知道它要往哪个群发消息，这个 ID 不是群名，也不是群链接里的字符串，而是调用飞书GET /chat/v4/listAPI 后返回的chat_id字段值。

这三重身份，缺一不可，且必须在 OpenClaw 的配置文件openclaw.yaml中精确对应。网上流传的很多“填好 token 就能用”的教程，之所以失败率高达 80%，就是因为它们把这三者混为一谈，或者只配置了其中一两个。

下面是我为你梳理的、经过七次完整重装验证的、零容错的接入流程：

3.1 创建飞书应用并获取 APP 凭据

• 登录 飞书开放平台 ，进入「开发者后台」→「应用管理」→「创建应用」。
• 应用类型选「企业自建」，应用名称填OpenClaw-Scheduler（不要用中文，避免编码问题）。
• 创建后，在「凭证与基础信息」页，复制APP_ID和APP_SECRET。注意：APP_SECRET只显示一次，务必立刻保存！

3.2 创建机器人并获取 BOT 凭据

• 在同一应用的「机器人管理」页，点击「添加机器人」。
• 机器人名称填openclaw-bot，功能描述留空。
• 关键一步：在「安全设置」里，将「事件订阅」开关打开，并勾选「消息事件」和「群组事件」。然后点击「生成密钥」，得到BOT_VERIFICATION_TOKEN和BOT_ENCRYPT_KEY。同样，BOT_ENCRYPT_KEY只显示一次，必须立刻保存。

3.3 获取目标群组的 CHAT_ID

• 这是最容易出错的一步。很多人直接把飞书群链接https://applink.feishu.cn/client/chat/chats?chat_id=oc_abc123...里的oc_abc123...当成CHAT_ID，这是错的。那个是前端渲染用的 ID，不是 API 用的。
• 正确方法是：用你刚拿到的APP_ID和APP_SECRET，调用飞书 API 获取：

  # 先用 APP 凭据换一个临时的 APP_ACCESS_TOKEN $ curl -X POST "https://open.feishu.cn/open-apis/auth/v3/app_access_token/internal/" \ -H "Content-Type: application/json" \ -d '{"app_id":"YOUR_APP_ID","app_secret":"YOUR_APP_SECRET"}' # 假设返回的 token 是 `t-xxx`，再用它查群列表 $ curl -X GET "https://open.feishu.cn/open-apis/chat/v4/list?page_size=50" \ -H "Authorization: Bearer t-xxx"

• 在返回的 JSON 里，找到你目标群组的name字段，然后记下它对应的chat_id。这个chat_id是一长串字母数字，形如oc_7a8b9c0d1e2f3g4h5i6j7k8l9m0n1o2p。

3.4 编写 OpenClaw 的核心配置文件

现在，把上面三步得到的所有密钥，填入openclaw.yaml。这个文件必须手写，不能用任何在线 YAML 格式化工具生成，因为缩进和引号的细微差别会导致解析失败。我给你一个绝对可用的模板：

# openclaw.yaml server: port: 8080 host: "0.0.0.0" lark: app_id: "cli_a1b2c3d4e5f67890" # 你的 APP_ID，必须加双引号 app_secret: "a1b2c3d4e5f67890a1b2c3d4e5f67890" # 你的 APP_SECRET，必须加双引号 bot_verification_token: "a1b2c3d4e5f67890a1b2c3d4e5f67890" # BOT_VERIFICATION_TOKEN bot_encrypt_key: "a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890" # BOT_ENCRYPT_KEY chat_id: "oc_7a8b9c0d1e2f3g4h5i6j7k8l9m0n1o2p" # 你查到的群组 chat_id # 这里定义 OpenClaw 如何调用你的本地模型 model: provider: "ollama" # 支持 ollama, lmstudio, openai-compatible base_url: "http://localhost:11434" # ollama 默认地址 model_name: "qwen3:8b" # 你本地已 pull 的模型名 # 日志级别，调试时设为 debug，生产环境用 info log: level: "debug"

注意：所有密钥字段都必须用双引号包裹，尤其是bot_encrypt_key这种包含斜杠/的字符串，不加引号 YAML 解析器会把它当成除法运算符，直接报错invalid character '/' looking for beginning of value。

配置文件写好后，执行：

$ ./bin/openclaw start --config ./openclaw.yaml

如果一切顺利，你会看到日志里滚动出现：

INFO[0000] Lark bot webhook server started on :8080/webhook INFO[0000] Lark app access token refreshed successfully INFO[0000] Model health check passed: qwen3:8b INFO[0000] Server started on :8080

此时，OpenClaw 才真正和飞书建立了双向通信。它不仅能接收飞书发来的加密消息，还能用自己的APP_ACCESS_TOKEN主动向飞书 API 发起请求（比如发送卡片、更新消息）。这才是一个完整的、可信赖的智能体调度中枢该有的样子。

4. 技能（Skill）不是代码，而是可执行的 JSON 协议契约

OpenClaw 的灵魂，不在它的调度引擎，而在它的技能（Skill）定义机制。很多人以为要写 Python 或 JavaScript 代码才能扩展功能，这是对 OpenClaw 最深的误解。它的 Skill，本质上是一份声明式的、基于 JSON Schema 的协议契约。你不需要写一行业务逻辑代码，只需要用 JSON 描述清楚：“当什么条件满足时，我要调用哪个模型，传什么参数，把结果变成什么格式，最后发到哪里”。

这种设计带来了两个巨大优势：一是极致的安全隔离——OpenClaw 永远不会执行你传来的任何代码，它只做 JSON 解析和 HTTP 转发；二是惊人的跨平台兼容性——同一个 Skill JSON，可以在 Windows、Linux、macOS 上无缝运行，因为它不依赖任何操作系统特性。

我们以一个真实需求为例：“在飞书群里发 /summary @张三，就自动总结张三今天所有未读消息”。这个需求看似复杂，但拆解成 OpenClaw 的 Skill，只需要 47 行 JSON。

4.1 Skill 的核心四要素

每个 Skill JSON 必须包含且仅包含以下四个顶级字段：

• trigger: 定义触发条件。支持正则匹配（regex）、命令前缀（command）、关键词（keyword）三种模式。对于/summary，我们用command模式。
• input: 定义如何从用户输入中提取参数。这是一个 JSON Schema，OpenClaw 会用它来校验和结构化用户输入。
• action: 定义要执行的动作。目前只支持llm_call（调用大模型）和http_request（发起 HTTP 请求）两种。
• output: 定义如何将动作结果格式化并输出。支持text（纯文本）、card（飞书富媒体卡片）、update_message（更新已有消息）三种。

4.2 编写 /summary Skill 的完整 JSON

把下面这段 JSON 保存为skills/summary.json（注意路径，OpenClaw 默认从skills/目录加载）：

{ "id": "summary-today", "name": "今日消息摘要", "description": "总结指定成员今日所有未读消息", "trigger": { "type": "command", "value": "/summary" }, "input": { "$schema": "https://json-schema.org/draft/2020-12/schema", "type": "object", "properties": { "target_user": { "type": "string", "description": "被@的用户飞书ID，例如 'ou_a1b2c3d4e5f67890'" } }, "required": ["target_user"] }, "action": { "type": "llm_call", "model": "qwen3:8b", "prompt": "你是一个专业的会议纪要助手。请根据以下消息内容，用中文生成一份简洁、重点突出的摘要，不超过200字。消息内容：{{.input.messages}}", "input_mapping": { "messages": "user_messages" } }, "output": { "type": "card", "template": { "config": { "wide_screen_mode": true, "enable_forward": true }, "elements": [ { "tag": "div", "text": { "content": "**📌 今日消息摘要**\n\n{{.result}}", "tag": "lark_md" } } ], "header": { "title": { "content": "🤖 OpenClaw 智能摘要", "tag": "plain_text" } } } } }

这个 JSON 里藏着几个关键设计点，直接决定了它能否在生产环境稳定运行：

• input字段的 JSON Schema 强制要求target_user是一个非空字符串。这意味着如果用户只发/summary而不 @ 任何人，OpenClaw 会直接返回400 Bad Request，并附带清晰的错误信息missing required field: target_user。这比让模型去“猜”用户想总结谁要安全得多。

• action.prompt里的{{.input.messages}}是一个模板变量，它的值由input_mapping决定。input_mapping告诉 OpenClaw：“把用户输入里解析出来的user_messages字段，映射到 prompt 的messages占位符上”。而user_messages这个字段，是由 OpenClaw 的飞书适配器在收到消息后，自动调用飞书GET /im/v1/messagesAPI 获取的。这个过程对用户完全透明，你只需要在 JSON 里声明“我要用什么”，OpenClaw 就会去“拿什么”。

• output.template是一个标准的飞书卡片 JSON Schema。OpenClaw 不做任何渲染，它只是把{{.result}}替换成模型返回的摘要文本，然后原封不动地 POST 到飞书POST /message/v4/send接口。这意味着卡片的样式、交互按钮、多维表格嵌入等所有高级功能，你都可以通过修改这个 JSON 来实现，无需改动 OpenClaw 一行代码。

4.3 加载 Skill 并测试

把summary.json放到skills/目录后，不需要重启 OpenClaw。它会自动热重载（hot reload）。你可以通过 API 查看当前加载的 Skill：

$ curl http://localhost:8080/skills # 返回一个 JSON 数组，包含所有已加载的 Skill 信息

然后，在飞书群里发送：

/summary @张三

OpenClaw 会立刻捕获这条消息，解析出target_user: "ou_a1b2c3d4e5f67890"，调用qwen3:8b模型生成摘要，并以一张精美的飞书卡片形式返回。整个过程，从消息发出到卡片呈现，实测平均耗时 2.3 秒（在本地 Ollama + Qwen3-8B 配置下）。

提示：如果第一次测试失败，90% 的概率是target_user的 ID 不对。飞书用户 ID 不是用户名，也不是邮箱，而是以ou_开头的 32 位字符串。你可以在飞书客户端右键点击用户头像 → 「复制用户 ID」来获取。千万别手输，一个字符错了，飞书 API 就会返回404 User not found，而 OpenClaw 会把这个错误原样记录在日志里，方便你快速定位。

这就是 OpenClaw 的力量：它把一个涉及多个 API、多种数据格式、多次网络调用的复杂工作流，压缩成了一份人类可读、机器可执行的 JSON 协议。你不需要成为全栈工程师，只需要理解业务逻辑，就能用最朴素的 JSON，编织出强大的自动化能力。

5. 故障排查不是“百度错误码”，而是沿着日志链路做逆向工程

部署完成后的最大挑战，往往不是安装，而是维护。OpenClaw 的日志设计非常克制，它不会告诉你“哪里错了”，而是告诉你“在哪个环节，收到了什么，发出了什么，得到了什么”。这就要求你必须掌握一套基于日志的逆向工程排查法。我整理了五个最高频、最致命的问题，以及它们的完整排查链路。

5.1 问题：飞书机器人不回消息，日志里只有INFO[0001] Received webhook event: message，然后就没了

表象：你在群里发/summary @张三，OpenClaw 日志显示收到了消息，但没有任何后续动作，也没有错误。

逆向排查链路：

1. 确认 Webhook 是否被飞书成功投递：在 OpenClaw 日志里，找到那条Received webhook event，复制整行。它后面应该跟着一个很长的 Base64 字符串（飞书加密的消息体）。把这个字符串粘贴到在线 Base64 解码器里，解码后你会看到原始 JSON。检查里面的event.type是否为message，event.sender.sender_id.user_id是否是你自己的 ID（说明是测试消息），最关键的是event.message.text字段，它应该是"/summary @张三"。如果这个字段是空的，说明飞书根本没有把消息文本传过来，问题出在飞书端的机器人权限设置。

2. 确认触发器是否匹配：OpenClaw 收到消息后，会立即尝试匹配所有已加载的 Skill 的trigger。在日志里搜索match trigger。如果看到INFO[0001] No skill matched for trigger command '/summary'，说明summary.json文件没被正确加载，或者文件名不是.json后缀，或者skills/目录路径不对。

3. 确认输入解析是否成功：如果触发器匹配了，日志里会出现DEBUG[0001] Parsed input: {"target_user":"ou_a1b2..."}。如果没有这行，说明input的 JSON Schema 校验失败。最常见的原因是用户@的方式不对。飞书消息里的@实际上传的是<at user_id="ou_a1b2...">张三</at>这样的 HTML 片段，而 OpenClaw 的默认解析器需要你手动在input里写正则来提取。你需要修改summary.json的input部分：

"input": { "$schema": "...", "type": "object", "properties": { "target_user": { "type": "string", "pattern": "^ou_[a-f0-9]{32}$" } } }

5.2 问题：日志报错error="failed to call llm: Post \"http://localhost:11434/api/chat\": dial tcp 127.0.0.1:11434: connect: connection refused"

表象：OpenClaw 启动时健康检查就失败，或者调用 Skill 时模型返回超时。

逆向排查链路：

1. 确认 Ollama 是否真的在运行：systemctl is-active ollama或ps aux | grep ollama。很多人以为ollama serve后台运行了，其实它默认是前台进程，关掉终端就死了。

2. 确认 Ollama 的监听地址：Ollama 默认监听127.0.0.1:11434，这个地址在 Docker 容器里是不通的。如果你在群晖 Docker 里跑 OpenClaw，base_url必须改成http://host.docker.internal:11434（Docker Desktop）或http://172.17.0.1:11434（Linux Docker）。这个 IP 地址必须和你的 Docker 网络配置完全一致。

3. 确认模型是否已下载：ollama list。如果qwen3:8b不在列表里，ollama run qwen3:8b。注意，ollama run第一次会下载，耗时很长，期间 OpenClaw 的健康检查会一直失败，这是正常现象。

5.3 问题：飞书卡片发出来了，但摘要内容是空的，或者全是乱码

表象：卡片标题正常，但正文区域显示{{.result}}或一堆问号。

逆向排查链路：

1. 确认模型调用是否成功：在日志里搜索llm_call response。你应该能看到模型返回的原始 JSON，里面有个message.content字段。如果这个字段是空的，说明模型没生成内容，问题在模型侧（比如提示词太短，或者模型本身崩了）。

2. 确认输出模板是否引用了正确的字段：output.template.elements[0].text.content里的{{.result}}，这个.result是 OpenClaw 的固定字段名，它代表action.llm_call的返回值。但如果action类型是http_request，返回值字段名就是{{.response.body}}。字段名写错，就会渲染为空。

3. 确认飞书卡片的字符编码：飞书卡片 JSON 必须是 UTF-8 编码。如果你用 Windows 记事本编辑summary.json，保存时选了ANSI，那么中文就会变成乱码。务必用 VS Code 或 Notepad++，并确认右下角显示UTF-8。

5.4 问题：频繁出现error: 发送飞书失败, 返回信息:{"code":11232,"msg":"frequency limited"}

表象：机器人偶尔能回消息，但大部分时候报 11232 错误。

逆向排查链路：

1. 确认错误来源：11232 是飞书平台的限流码，不是 OpenClaw 的 Bug。它表示“你的机器人在一分钟内调用send接口超过 60 次”。OpenClaw 默认没有内置限流，它会忠实地转发每一次请求。

2. 启用 OpenClaw 的内置限流：在openclaw.yaml的lark部分，添加rate_limit配置：

lark: # ... 其他配置 rate_limit: requests_per_minute: 50 burst: 10

这会让 OpenClaw 在内存里维护一个令牌桶，确保每分钟最多发 50 条消息，突发流量最多 10 条。这是最简单有效的解决方案。

3. 检查是否有循环调用：比如你的 Skill 里，模型返回的内容又触发了另一个 Skill，形成死循环。在日志里搜索Received webhook event的频率，如果一秒内出现 5 次以上，基本可以确定是循环。

5.5 问题：openclaw : 无法将“openclaw”项识别为 cmdlet、函数、脚本文件或可运行程序的名

表象：在 Windows PowerShell 里执行openclaw start报错。

逆向排查链路：

1. 确认执行的是二进制，不是命令名：PowerShell 默认只在PATH环境变量里找命令。你编译出来的openclaw.exe在./bin/目录下，所以必须写./bin/openclaw.exe start，或者先把./bin加到PATH里。

2. 确认文件扩展名：Windows 下，Go 编译的可执行文件默认后缀是.exe。如果你在 Linux 上编译了openclaw，然后拷贝到 Windows，它没有.exe后缀，PowerShell 就不认识。必须在 Windows 上用go build重新编译，或者手动重命名为openclaw.exe。

3. 确认执行策略：PowerShell 默认禁止运行本地脚本。以管理员身份运行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser。

排查的本质，就是把日志里每一行信息，当作一个证据节点，然后用逻辑推理，把它们串成一条完整的因果链。你不需要记住所有错误码，你只需要记住：OpenClaw 的日志，永远是你最诚实的搭档。它从不说谎，它只陈述事实。你唯一要做的，就是学会读懂它用 HTTP 状态码、JSON 字段名和时间戳写成的“侦探小说”。

6. 从单点技能到智能体网络：OpenClaw 的终极扩展形态

当你已经能稳定运行/summary这个 Skill，并且能自如地排查各种网络、配置、权限问题时，OpenClaw 的旅程才刚刚开始。它的设计上限，远不止于“在群里发个命令”。它的真正威力，在于将多个 Skill 组合成一个有状态、有记忆、能协作的智能体（Agent）网络。

举个例子：一个完整的“项目周报生成”工作流，需要串联至少五个环节：

1. 抓取数据：从 Zabbix API 拉取本周告警；
2. 聚合分析：用 LLM 总结告警趋势；
3. 关联文档：用 MinerU 解析本周所有项目周报 Word 文档，提取关键指标；
4. 交叉验证：把 LLM 分析的趋势和 Word 文档里的指标做对比，找出矛盾点；
5. 生成报告：把所有信息整合成一份带图表的飞书多维表格。

如果用传统方式开发，这需要写一个复杂的后端服务，处理五种不同的 API、四种数据格式、三次网络调用。而用 OpenClaw，你只需要定义五个 Skill，并用output.type: "http_request"和input_mapping把它们像乐高一样拼接起来。

6.1 Skill 间的 HTTP 协作协议

OpenClaw 的http_requestaction，支持将一个 Skill 的输出，作为另一个 Skill 的输入。关键在于output的type和url字段：

// skills/zabbix-fetch.json { "id": "zabbix-fetch", "trigger": { "type": "cron