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 和一个同样严格的飞书机器人配置流程来完成。而后者恰恰是整个部署链条里最脆弱、最容易被忽略的一环。飞书机器人不是简单的“消息转发器”它是一个拥有三重独立身份的实体应用身份App Identity由飞书开放平台分配的APP_ID和APP_SECRET用于换取长期有效的APP_ACCESS_TOKEN。这个 token 是 OpenClaw 向飞书平台证明“我是谁”的凭证。机器人身份Bot Identity由飞书管理员在“机器人管理”页面创建的BOT_VERIFICATION_TOKEN和BOT_ENCRYPT_KEY。这两个密钥是飞书用来验证“发来的消息确实来自我的机器人而不是黑客伪造的”——所有飞书发给你的 Webhook 消息都经过 AES-256-GCM 加密并用BOT_ENCRYPT_KEY签名BOT_VERIFICATION_TOKEN用于校验签名。群组身份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_idoc_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_size50 \ -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 SchemaOpenClaw 会用它来校验和结构化用户输入。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 日志显示收到了消息但没有任何后续动作也没有错误。逆向排查链路确认 Webhook 是否被飞书成功投递在 OpenClaw 日志里找到那条Received webhook event复制整行。它后面应该跟着一个很长的 Base64 字符串飞书加密的消息体。把这个字符串粘贴到在线 Base64 解码器里解码后你会看到原始 JSON。检查里面的event.type是否为messageevent.sender.sender_id.user_id是否是你自己的 ID说明是测试消息最关键的是event.message.text字段它应该是/summary 张三。如果这个字段是空的说明飞书根本没有把消息文本传过来问题出在飞书端的机器人权限设置。确认触发器是否匹配OpenClaw 收到消息后会立即尝试匹配所有已加载的 Skill 的trigger。在日志里搜索match trigger。如果看到INFO[0001] No skill matched for trigger command /summary说明summary.json文件没被正确加载或者文件名不是.json后缀或者skills/目录路径不对。确认输入解析是否成功如果触发器匹配了日志里会出现DEBUG[0001] Parsed input: {target_user:ou_a1b2...}。如果没有这行说明input的 JSON Schema 校验失败。最常见的原因是用户的方式不对。飞书消息里的实际上传的是at user_idou_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 问题日志报错errorfailed to call llm: Post \http://localhost:11434/api/chat\: dial tcp 127.0.0.1:11434: connect: connection refused表象OpenClaw 启动时健康检查就失败或者调用 Skill 时模型返回超时。逆向排查链路确认 Ollama 是否真的在运行systemctl is-active ollama或ps aux | grep ollama。很多人以为ollama serve后台运行了其实它默认是前台进程关掉终端就死了。确认 Ollama 的监听地址Ollama 默认监听127.0.0.1:11434这个地址在 Docker 容器里是不通的。如果你在群晖 Docker 里跑 OpenClawbase_url必须改成http://host.docker.internal:11434Docker Desktop或http://172.17.0.1:11434Linux Docker。这个 IP 地址必须和你的 Docker 网络配置完全一致。确认模型是否已下载ollama list。如果qwen3:8b不在列表里ollama run qwen3:8b。注意ollama run第一次会下载耗时很长期间 OpenClaw 的健康检查会一直失败这是正常现象。5.3 问题飞书卡片发出来了但摘要内容是空的或者全是乱码表象卡片标题正常但正文区域显示{{.result}}或一堆问号。逆向排查链路确认模型调用是否成功在日志里搜索llm_call response。你应该能看到模型返回的原始 JSON里面有个message.content字段。如果这个字段是空的说明模型没生成内容问题在模型侧比如提示词太短或者模型本身崩了。确认输出模板是否引用了正确的字段output.template.elements[0].text.content里的{{.result}}这个.result是 OpenClaw 的固定字段名它代表action.llm_call的返回值。但如果action类型是http_request返回值字段名就是{{.response.body}}。字段名写错就会渲染为空。确认飞书卡片的字符编码飞书卡片 JSON 必须是 UTF-8 编码。如果你用 Windows 记事本编辑summary.json保存时选了ANSI那么中文就会变成乱码。务必用 VS Code 或 Notepad并确认右下角显示UTF-8。5.4 问题频繁出现error: 发送飞书失败, 返回信息:{code:11232,msg:frequency limited}表象机器人偶尔能回消息但大部分时候报 11232 错误。逆向排查链路确认错误来源11232 是飞书平台的限流码不是 OpenClaw 的 Bug。它表示“你的机器人在一分钟内调用send接口超过 60 次”。OpenClaw 默认没有内置限流它会忠实地转发每一次请求。启用 OpenClaw 的内置限流在openclaw.yaml的lark部分添加rate_limit配置lark: # ... 其他配置 rate_limit: requests_per_minute: 50 burst: 10这会让 OpenClaw 在内存里维护一个令牌桶确保每分钟最多发 50 条消息突发流量最多 10 条。这是最简单有效的解决方案。检查是否有循环调用比如你的 Skill 里模型返回的内容又触发了另一个 Skill形成死循环。在日志里搜索Received webhook event的频率如果一秒内出现 5 次以上基本可以确定是循环。5.5 问题openclaw : 无法将“openclaw”项识别为 cmdlet、函数、脚本文件或可运行程序的名表象在 Windows PowerShell 里执行openclaw start报错。逆向排查链路确认执行的是二进制不是命令名PowerShell 默认只在PATH环境变量里找命令。你编译出来的openclaw.exe在./bin/目录下所以必须写./bin/openclaw.exe start或者先把./bin加到PATH里。确认文件扩展名Windows 下Go 编译的可执行文件默认后缀是.exe。如果你在 Linux 上编译了openclaw然后拷贝到 Windows它没有.exe后缀PowerShell 就不认识。必须在 Windows 上用go build重新编译或者手动重命名为openclaw.exe。确认执行策略PowerShell 默认禁止运行本地脚本。以管理员身份运行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser。排查的本质就是把日志里每一行信息当作一个证据节点然后用逻辑推理把它们串成一条完整的因果链。你不需要记住所有错误码你只需要记住OpenClaw 的日志永远是你最诚实的搭档。它从不说谎它只陈述事实。你唯一要做的就是学会读懂它用 HTTP 状态码、JSON 字段名和时间戳写成的“侦探小说”。6. 从单点技能到智能体网络OpenClaw 的终极扩展形态当你已经能稳定运行/summary这个 Skill并且能自如地排查各种网络、配置、权限问题时OpenClaw 的旅程才刚刚开始。它的设计上限远不止于“在群里发个命令”。它的真正威力在于将多个 Skill 组合成一个有状态、有记忆、能协作的智能体Agent网络。举个例子一个完整的“项目周报生成”工作流需要串联至少五个环节抓取数据从 Zabbix API 拉取本周告警聚合分析用 LLM 总结告警趋势关联文档用 MinerU 解析本周所有项目周报 Word 文档提取关键指标交叉验证把 LLM 分析的趋势和 Word 文档里的指标做对比找出矛盾点生成报告把所有信息整合成一份带图表的飞书多维表格。如果用传统方式开发这需要写一个复杂的后端服务处理五种不同的 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