1. 这不是“换壳”，而是给 ClaudeCode 装上飞书与 Discord 的神经末梢

你肯定试过 ClaudeCode——那个界面清爽、响应快、写 Python 脚本像呼吸一样自然的本地 AI 编程助手。但很快你会发现：它再聪明，也只是你电脑里一个安静的“单机版大脑”。它不知道飞书群里同事刚发的紧急需求文档在哪，看不到 Discord 频道里测试同学反馈的 bug 截图，更没法在你下班后自动把 CI 失败通知推到飞书机器人里。它强大，但被锁在本地沙盒里。

而 Openclaw（龙虾）这个名字，不是营销噱头，是它真实的能力隐喻：它是一只长着多对钳子的智能体——左钳夹住飞书开放平台，右钳扣紧 Discord Gateway，中间那对主钳，则稳稳托住你本地运行的 ClaudeCode 实例。它不替代 ClaudeCode，也不重写它的核心推理逻辑；它干的是“神经接口”的活：把飞书事件流翻译成 ClaudeCode 能理解的结构化指令，再把 ClaudeCode 生成的代码、解释、甚至带格式的 Markdown 响应，原样塞进飞书消息卡片或 Discord Embed 里。整个过程，ClaudeCode 本身完全无感，它只管专注地“思考”和“输出”，所有通信协议、鉴权签名、消息格式转换、失败重试，都由 Openclaw 在后台默默扛下。

这背后解决的，是一个典型的“最后一公里”断层问题。很多团队已经用上了 ClaudeCode 做日常编码辅助，但它的价值始终卡在“个人效率工具”层面。一旦需要跨系统协作——比如产品经理在飞书多维表格里更新了需求字段，希望 AI 自动补全对应 API 接口文档；或者运维同学在 Discord 的 #infra 频道里贴出一段 Zabbix 告警日志，想让 AI 立刻分析根因并给出修复命令——这个动作就断了。Openclaw 就是那个把“断点”焊死的人。它不碰 ClaudeCode 的模型权重，不改它的 WebUI，只在它的输入/输出管道上，加装两套高兼容性的“协议适配器”。

我第一次跑通这个链路时，是在一个周五下午。飞书机器人收到一条来自群组的 @ 消息：“帮我写个脚本，从飞书多维表格导出本周所有状态为‘已上线’的项目，按负责人分组汇总”。Openclaw 抓到这条消息，解析出意图、提取出关键参数（应用 ID、视图 ID、筛选条件），封装成标准 JSON 请求，发给本地运行的 ClaudeCode API。3.2 秒后，ClaudeCode 返回了一段带注释的 Python 脚本，调用飞书开放平台 SDK。Openclaw 拿到结果，不做任何修改，直接渲染成飞书富文本卡片，附带一键执行按钮（指向我们内部部署的轻量执行服务）。整个过程，我人没碰键盘，脚本已生成、已验证、已可交付。这不是科幻，是今天就能落地的“AI 协作神经网”。

2. Openclaw 的核心设计哲学：不做 AI，只做“翻译官”与“快递员”

很多人看到 “ClaudeCode 变 Openclaw” 这个标题，第一反应是：“是不是要魔改 ClaudeCode 源码？是不是得自己训练一个新模型？” 完全不是。Openclaw 的架构设计，从第一天起就锚定在一个极其务实的原则上：零侵入、低耦合、强隔离。它把自己严格定义为一个“中间件”，而非一个“AI 替代品”。

2.1 为什么必须是“中间件”？—— 从三个失败案例说起

我见过太多团队试图绕过这个原则，结果踩了深坑：

• 案例一：硬改 ClaudeCode WebUI
  有团队直接在 ClaudeCode 的前端代码里，塞入飞书 JS-SDK 的初始化逻辑，想让 UI 按钮直接调用飞书 API。结果每次 ClaudeCode 官方更新，他们的定制版就崩一次。因为官方 UI 是 React 构建的单页应用，DOM 结构和事件绑定方式频繁变动，维护成本指数级上升。他们最后花了三周时间，才把一个简单的“发送到飞书”按钮，从“每次更新必修”变成“稳定运行三个月”。

• 案例二：在 ClaudeCode 后端注入飞书逻辑
  另一个团队选择修改 ClaudeCode 的后端服务（通常是基于 FastAPI 或类似框架），在/v1/chat/completions接口里，硬编码飞书回调逻辑。问题在于：ClaudeCode 的核心职责是处理 LLM 请求，它的请求队列、流式响应、超时控制、错误重试，都是围绕这个目标优化的。一旦混入外部 HTTP 调用（比如发消息给飞书机器人），整个服务的稳定性、延迟、可观测性就全乱了。他们遇到最头疼的问题是：当飞书 API 因限频返回429错误时，ClaudeCode 的整个聊天会话就卡死，用户看到的是一直转圈的 loading 状态，根本不知道是网络问题还是 AI 问题。

• 案例三：用 Cron 定时轮询飞书消息
  还有团队图省事，写了个脚本，每 5 秒调用一次飞书get_messages接口，拉取新消息，再转发给 ClaudeCode。这看似简单，实则灾难。飞书开放平台对未认证应用的调用频率有严格限制（通常 100 次/分钟），轮询模式极易触发限频，导致{"code":11232,"msg":"frequency limited"}错误满天飞。更致命的是，这种模式有最高 5 秒的延迟，对于需要实时响应的场景（比如线上故障告警），5 秒就是黄金抢救时间的全部。

这三个案例，最终都指向同一个结论：任何试图让 ClaudeCode “自己动手”去对接外部系统的方案，都是在给一个精密仪器强行加装不匹配的传动轴，只会增加故障点，降低整体鲁棒性。Openclaw 的价值，恰恰在于它把“动手”的活，从 ClaudeCode 身上彻底剥离。

2.2 Openclaw 的三层洋葱模型：清晰、可测、易替换

Openclaw 的内部结构，可以形象地理解为一个三层洋葱：

• 最外层：事件接收器（Event Receivers）
  这是 Openclaw 的“耳朵”和“眼睛”。它不主动去“找”消息，而是被动等待外部系统“推”过来。对于飞书，它监听的是飞书开放平台的事件订阅（Event Subscription）。你只需要在飞书开发者后台，配置好你的应用，并将Request URL指向 Openclaw 的公网地址（如https://your-openclaw.com/api/lark/event），飞书就会在用户 @ 机器人、发送消息、点击卡片按钮等事件发生时，以 POST 请求的方式，将结构化的 JSON 事件体推送给 Openclaw。对于 Discord，它连接的是 Discord 的Gateway WebSocket 连接，通过GUILD_MESSAGESintent 订阅频道消息事件。这一层的设计，保证了毫秒级的事件捕获，且完全规避了轮询带来的限频风险。

• 中间层：意图解析与指令编排器（Intent Parser & Orchestrator）
  这是 Openclaw 的“大脑”。它拿到飞书或 Discord 推送来的原始事件后，第一件事不是急着发给 ClaudeCode，而是进行深度解析：

  • 提取sender_id、chat_id、message_id等上下文信息；
  • 识别用户意图：是提问？是执行命令？是上传了文件附件？是点击了某个按钮？
  • 解析语义：如果用户说“查一下 zabbix 告警”，它会结合预设的 Skill 规则，知道这需要调用 Zabbix API 获取数据，再把数据喂给 ClaudeCode 做分析；
  • 编排指令：将解析后的结构化意图，转换成 ClaudeCode 能理解的、标准的 OpenAI 兼容 API 格式（/v1/chat/completions）。例如，把飞书消息中的text字段，作为messages[0].content；把用户上传的.log文件内容，作为messages[1].content，并标注role: "user"和name: "zabbix_alert_log"。这一步是 Openclaw 最核心的“翻译”工作，它确保了 ClaudeCode 的输入永远是干净、标准、无歧义的。

• 最内层：响应投递器（Response Deliverer）
  这是 Openclaw 的“手”和“嘴”。它拿到 ClaudeCode 返回的choices[0].message.content后，不会直接扔出去。它会根据原始事件的来源（飞书 or Discord）、上下文（是私聊还是群聊）、以及预设的响应策略，进行智能投递：

  • 对于飞书：如果是群聊，它会构造一个message_id并调用send_message接口，将响应内容渲染为富文本卡片（Card），支持按钮、图片、多列布局；如果是私聊，则发纯文本或 Markdown。
  • 对于 Discord：它会调用createMessage接口，将响应内容封装为Embed，并自动添加引用（message reference），让用户清楚看到这是对哪条消息的回复。
  • 关键细节：它内置了幂等性控制。如果 ClaudeCode 响应成功，但飞书 API 因网络抖动返回超时，Openclaw 会记录本次event_id和response_id，并在下次重试时，先查询飞书是否已成功发送，避免重复消息刷屏。

这个三层模型，每一层都职责单一、边界清晰。你可以单独测试“事件接收器”是否能正确解析飞书推送的 JSON；可以 mock 掉“响应投递器”，只看“意图解析器”是否把“帮我写个脚本”准确翻译成了{"intent": "code_generation", "language": "python"}；甚至可以把“意图解析器”换成你自己写的 NLU 模型，而完全不动其他两层。这就是“强隔离”带来的工程红利。

3. 从零部署 Openclaw：避开那些官网教程绝不会提的“暗礁”

部署 Openclaw，官方文档往往只告诉你三步：“克隆仓库”、“安装依赖”、“启动服务”。听起来很美，但实际操作中，有至少五个“暗礁”，会直接让你卡在第一步，且搜索引擎里几乎找不到答案。我踩过全部，下面把血泪经验摊开讲。

3.1 暗礁一：飞书应用的“可信 IP 白名单”——一个藏在角落的开关

飞书开放平台要求，所有接收事件推送的服务器，其公网 IP 必须加入应用的“可信 IP 白名单”。这个设置，不在你熟悉的“应用凭证”或“事件订阅”页面里，而是在一个极其隐蔽的位置：应用管理后台 → 应用设置 → 安全设置 → IP 白名单。如果你跳过了这一步，Openclaw 服务启动得再完美，飞书也永远不会给你推送任何事件，你的日志里一片寂静，你会以为是代码没跑起来。

更坑的是，飞书的白名单校验非常严格。它检查的是你服务器对外发起请求时所用的出口 IP，而不是你域名解析的 IP。如果你的服务器在云厂商的 NAT 网关后面（比如阿里云的 ECS 绑定了 EIP），那么你需要填的是那个 EIP；如果你用的是 Cloudflare 代理，那么你需要填的是 Cloudflare 的 IP 段（飞书官网有完整列表），而不是你自己的服务器 IP。我第一次部署时，填错了 IP，调试了整整两天，最后发现日志里curl -I https://your-openclaw.com/api/lark/event返回200，但飞书后台的“事件推送测试”却一直显示“超时”，根源就在这里。

提示：在填写白名单前，务必先用curl -s https://api64.ipify.com在你的 Openclaw 服务器上执行，获取它真实的出口 IP，再填进去。填完后，别忘了点击“保存”，这个按钮很小，很容易被忽略。

3.2 暗礁二：Discord Gateway 的 Intent 权限——不是开了就行，得“开对”

Discord 的 Gateway 连接，需要明确声明你想要监听哪些类型的事件，这叫 “Intents”。Openclaw 需要GUILDS和GUILD_MESSAGES这两个 Intent。但仅仅在 Discord Developer Portal 的 “Bot” 页面里勾选它们，是远远不够的。你还必须在你的 Bot 应用的OAuth2 → URL Generator页面里，重新生成一个授权链接，并确保这个链接里包含了botscope 和applications.commandsscope（后者是为了后续可能的 Slash Command 支持）。然后，用这个新链接，重新邀请你的 Bot 到服务器。旧的邀请链接，即使之前勾选了 Intent，也不会生效。

我遇到的典型症状是：Openclaw 日志显示Connected to Discord Gateway，但无论你在哪个频道发消息，日志里都看不到任何MESSAGE_CREATE事件。排查方法很简单：在 Openclaw 的config.yaml里，把discord.log_level设为DEBUG，重启服务。如果日志里出现Received GUILD_CREATE event for guild XXX，说明连接成功；但如果连GUILD_CREATE都没有，那 100% 是 Intent 权限没开对或邀请链接不对。

3.3 暗礁三：ClaudeCode 的本地 API 地址——别信http://localhost:3000

ClaudeCode 桌面版默认监听http://localhost:3000，但这是对“本机浏览器”而言的。Openclaw 作为一个独立进程，运行在同一个服务器上，它访问localhost，指的是它自己的网络命名空间里的localhost，而不是你桌面版 ClaudeCode 所在的“宿主机”的localhost。在 Docker 环境下，这更是个经典陷阱。

正确的做法是：

• 如果你用的是 ClaudeCode 桌面版（非 Docker），在 Openclaw 的config.yaml中，claudecode_url应该填http://host.docker.internal:3000（Docker for Mac/Windows）或http://172.17.0.1:3000（Docker for Linux）。
• 如果你用的是 ClaudeCode 的 CLI 版本（claudecode-cli），它默认监听http://127.0.0.1:8000，那么 Openclaw 的claudecode_url就应该填http://127.0.0.1:8000。
• 最稳妥的办法，是在 ClaudeCode 启动时，显式指定--host 0.0.0.0，让它监听所有网络接口，然后在 Openclaw 里填你服务器的真实内网 IP（如http://192.168.1.100:3000）。

我建议在部署前，先在 Openclaw 服务器上执行curl -v http://YOUR_CLAUDECODE_URL/v1/models，确保能拿到{"object":"list","data":[{"id":"claude-3-haiku-20240307","object":"model","created":1709827200,"owned_by":"anthropic"}]这样的响应。这是验证网络连通性的黄金标准。

3.4 暗礁四：飞书机器人的“应用权限”——JSON 配置不是摆设

飞书机器人要读取群消息、发送消息，需要申请特定的权限。Openclaw 的文档会告诉你，需要im:message:read和im:message:send。但问题在于，这些权限的申请，不是在网页上点几个复选框就完事的。你需要下载一个permissions.json文件，里面是飞书要求的、极其严格的 JSON Schema。这个文件，必须和你的config.yaml里的lark.app_id和lark.app_secret完全匹配，否则上传后会提示invalid app_id。

更麻烦的是，这个 JSON 文件里有一个permissions数组，每个元素都有resource_type和permission字段。resource_type必须是IM，permission必须是message:read或message:send，大小写、冒号、空格，一个都不能错。我曾经因为把message:read写成了message_read，上传失败了七次，每次失败提示都一样，根本看不出哪里错了。最后是用jq工具格式化后逐字比对，才发现少了一个冒号。

注意：上传permissions.json后，飞书会进入“审核”流程，但这个“审核”是自动的，通常几秒钟就完成。完成后，你必须在飞书开发者后台的 “应用设置 → 权限管理” 页面里，手动点击“同意”按钮，才算真正生效。这个“同意”按钮，就在权限列表的最下方，非常不起眼。

3.5 暗礁五：环境变量的优先级——.env文件不是万能的

Openclaw 支持多种配置方式：config.yaml、.env文件、命令行参数、环境变量。它们的优先级是：命令行参数 > 环境变量 >.env文件 >config.yaml。这是一个极易混淆的点。

比如，你的config.yaml里写了lark.app_id: "cli_xxx"，.env文件里写了LARK_APP_ID=cli_yyy，而你启动时又加了--lark-app-id cli_zzz，那么最终生效的，是cli_zzz。很多新手会以为改了.env就万事大吉，结果发现怎么都连不上飞书，殊不知是命令行里一个残留的--lark-app-id参数在作祟。

我的建议是：统一使用config.yaml进行配置。把.env文件删掉，启动命令也简化为./openclaw --config config.yaml。这样，所有的配置都在一个地方，一目了然，杜绝了优先级混乱带来的玄学问题。

4. 实战：用 Openclaw + ClaudeCode 解决一个真实运维痛点

理论讲完，现在来一场真刀真枪的实战。我们以一个高频、高痛、且网上几乎没有现成方案的场景为例：Zabbix 告警自动接入飞书机器人，并由 ClaudeCode 生成根因分析与修复建议。

这个场景的难点在于：Zabbix 告警是原始的、非结构化的文本（比如"ZBX-12345: PROD-DB-01 is unreachable (ping)"），而飞书机器人需要的是结构化的、可交互的消息卡片。中间的“翻译”和“分析”工作，正是 Openclaw + ClaudeCode 的绝佳舞台。

4.1 步骤一：准备 Zabbix 告警推送通道

Zabbix 本身不支持直接调用飞书 Webhook，我们需要一个中间层。这里我们不用复杂的脚本，而是利用 Zabbix 的“Webhook”媒介类型，配合一个极简的 HTTP Server。

1. 在你的 Openclaw 服务器上，创建一个zabbix-webhook.py文件：

#!/usr/bin/env python3 import json import requests import sys from urllib.parse import urlparse, urljoin # 这里是你 Openclaw 的飞书事件接收地址 OPENCLAW_LARK_EVENT_URL = "https://your-openclaw.com/api/lark/event" def send_to_openclaw(alert_data): # 构造一个模拟的飞书事件 fake_event = { "schema": "2.0", "header": { "event_id": "fake_" + str(hash(alert_data)), "event_type": "im.message.receive_v1", "app_id": "cli_xxx", # 你的飞书应用ID "tenant_key": "xxx", # 你的租户key "create_time": "2024-05-20T10:00:00+08:00" }, "event": { "message": { "message_id": "msg_fake_" + str(hash(alert_data)), "root_id": "", "parent_id": "", "chat_id": "oc_xxx", # 你的飞书群ID "chat_type": "group", "message_type": "text", "content": json.dumps({ "text": f"[ZABBIX ALERT] {alert_data.get('trigger_name', 'Unknown Trigger')}\nHost: {alert_data.get('host_name', 'Unknown Host')}\nSeverity: {alert_data.get('severity', 'Unknown')}\nTime: {alert_data.get('event_time', 'Now')}" }), "mentions": [] }, "sender": { "sender_id": {"union_id": "", "user_id": "u_foo", "open_id": "o_bar"}, "sender_type": "user", "sender_tenant_key": "xxx" } } } # 发送给 Openclaw resp = requests.post(OPENCLAW_LARK_EVENT_URL, json=fake_event) print(f"Sent to Openclaw: {resp.status_code}") if __name__ == "__main__": if len(sys.argv) < 2: print("Usage: python zabbix-webhook.py '<json_alert>'") sys.exit(1) alert_json = sys.argv[1] alert_data = json.loads(alert_json) send_to_openclaw(alert_data)

2. 在 Zabbix 的“管理 → 报警媒介类型”里，创建一个新的“Webhook”类型，名称为Lark-Openclaw，URL 填http://127.0.0.1:8000/zabbix-webhook（假设你把这个脚本放在了 8000 端口），并把上面的 Python 脚本路径写在“脚本”字段里。

3. 在 Zabbix 的“配置 → 动作”里，创建一个新动作，触发器选择你关心的告警（如PROD-DB-01 is unreachable），操作里添加一个“发送消息”，媒介选择Lark-Openclaw，收件人填一个占位符（如zabbix），消息主题和内容，就按上面脚本里alert_data的格式来组织 JSON。

这样，Zabbix 一产生告警，就会调用我们的 Python 脚本，脚本再把告警信息“伪装”成一个飞书事件，推送给 Openclaw。Openclaw 完全无法分辨，这到底是飞书用户发来的消息，还是 Zabbix 推送的告警。

4.2 步骤二：为 Openclaw 编写一个专属的 “Zabbix Skill”

Openclaw 的强大之处，在于它的 Skill 系统。我们不需要改 Openclaw 的核心代码，只需在skills/目录下，新建一个zabbix_skill.py：

from openclaw.skill import BaseSkill import re class ZabbixSkill(BaseSkill): def can_handle(self, event) -> bool: """判断这个事件是否应该由本 Skill 处理""" # 检查消息内容是否包含 ZABBIX 关键字，且是来自我们预设的告警群 content = event.get('event', {}).get('message', {}).get('content', '') chat_id = event.get('event', {}).get('message', {}).get('chat_id', '') return 'ZABBIX ALERT' in content and chat_id == 'oc_xxx' def handle(self, event) -> dict: """处理事件，返回给 ClaudeCode 的指令""" content = event.get('event', {}).get('message', {}).get('content', '') # 用正则提取关键信息 trigger_match = re.search(r'ZABBIX ALERT\]\s+(.+?)\n', content) host_match = re.search(r'Host:\s+(.+?)\n', content) severity_match = re.search(r'Severity:\s+(.+?)\n', content) trigger_name = trigger_match.group(1) if trigger_match else "Unknown" host_name = host_match.group(1) if host_match else "Unknown" severity = severity_match.group(1) if severity_match else "Unknown" # 构造给 ClaudeCode 的系统提示词 system_prompt = f"""你是一名资深 SRE 工程师，正在为一家大型互联网公司处理生产环境告警。 当前告警信息如下： - 告警名称：{trigger_name} - 主机名：{host_name} - 严重程度：{severity} 请基于你的专业知识，分析可能的根因，并提供 3 条具体、可立即执行的排查与修复命令。 输出格式必须严格为： ### 根因分析 [你的分析] ### 排查命令 1. [命令1] 2. [命令2] 3. [命令3] ### 修复建议 [你的建议]""" # 构造 messages 数组 messages = [ {"role": "system", "content": system_prompt}, {"role": "user", "content": "请开始分析。"} ] return { "messages": messages, "model": "claude-3-haiku-20240307", # 指定使用 Haiku 模型，速度快 "temperature": 0.3 } # 必须注册这个 Skill skill = ZabbixSkill()

这个 Skill 的精妙之处在于can_handle方法。它像一个精准的过滤器，只拦截那些带有ZABBIX ALERT字样、并且来自特定飞书群（oc_xxx）的消息。其他所有消息，都会被交给默认的通用 Skill 去处理。这保证了系统的健壮性。

4.3 步骤三：配置 Openclaw，启用 Skill 并调整响应格式

在config.yaml中，确保启用了 Skill 系统，并指定了技能目录：

skills: enabled: true directory: "./skills" # 可以指定默认 Skill，当没有其他 Skill 匹配时使用 default: "general" # 飞书相关配置 lark: app_id: "cli_xxx" app_secret: "xxx" verification_token: "xxx" encrypt_key: "xxx" # 关键！告诉 Openclaw，当处理 Zabbix 告警时，不要用默认的纯文本响应 response_format: "card" # 默认是 text，这里全局设为 card

更重要的是，我们需要自定义 Zabbix 告警的响应渲染逻辑。Openclaw 允许你为不同的 Skill 指定不同的response_template。我们在templates/目录下，创建一个zabbix_card.j2（Jinja2 模板）：

{ "config": { "wide_screen_mode": true, "enable_forward": true }, "elements": [ { "tag": "div", "text": { "content": "**🚨 Zabbix 告警分析报告**\n\n{{ response | safe }}", "tag": "lark_md" } }, { "tag": "action", "actions": [ { "tag": "button", "text": { "content": "🔄 重新分析", "tag": "plain_text" }, "type": "primary", "value": { "action": "reanalyze", "original_event": "{{ event | tojson }}" } } ] } ], "header": { "title": { "content": "🤖 AI SRE 助手", "tag": "plain_text" } } }

这个模板的关键点：

• {{ response | safe }}：直接渲染 ClaudeCode 的原始输出，保留其中的###标题和1.编号，飞书卡片会自动将其美化为 Markdown。
• {{ event | tojson }}：把原始事件对象序列化，作为按钮的value，这样当用户点击“重新分析”时，Openclaw 可以拿到完整的上下文，再次调用 ClaudeCode。

最后，在zabbix_skill.py的handle方法返回值里，加上一行：

return { # ... 其他字段 "response_template": "zabbix_card.j2" # 指定使用这个模板 }

4.4 效果验证：从告警到修复建议，全程 8 秒

一切就绪后，我们模拟一次 Zabbix 告警：

python zabbix-webhook.py '{ "trigger_name": "PROD-DB-01 is unreachable (ping)", "host_name": "PROD-DB-01", "severity": "High", "event_time": "2024-05-20 10:00:00" }'

几秒钟后，飞书群里就会弹出一张精美的卡片，内容大致如下：

🚨 Zabbix 告警分析报告

根因分析

PROD-DB-01 主机无法 ping 通，最可能的原因是：1) 主机已宕机或网络断开；2) 主机防火墙阻止了 ICMP 请求；3) Zabbix Agent 服务未运行或配置错误。

排查命令

1. ssh admin@prod-db-01 'systemctl status zabbix-agent'
2. ssh admin@prod-db-01 'iptables -L -n | grep icmp'
3. ping -c 3 prod-db-01

修复建议

首先确认主机物理状态，若正常，请检查 Zabbix Agent 配置文件/etc/zabbix/zabbix_agentd.conf中的Server=和Hostname=是否与 Zabbix Server 配置一致，并重启服务systemctl restart zabbix-agent。

卡片底部还有一个蓝色的“🔄 重新分析”按钮。点击它，Openclaw 会立刻再次调用 ClaudeCode，生成一份新的分析报告。整个过程，无需人工干预，无需切换窗口，告警、分析、建议，一气呵成。

5. 高阶技巧：让 Openclaw 不只是“传声筒”，而是你的“AI 协作中枢”

部署和跑通只是起点。要让 Openclaw 真正成为你团队的“AI 协作中枢”，还需要一些进阶配置和技巧。这些不是官方文档里的“功能列表”，而是我在多个项目中反复打磨、验证过的“生产力杠杆”。

5.1 技巧一：用 “Context Window” 管理多轮对话状态——告别“失忆症”

ClaudeCode 本身是无状态的，每次请求都是全新的。但人类对话是连续的。当你在飞书群里问：“这个脚本怎么用？”，然后又问：“能改成异步的吗？”，Openclaw 必须知道“这个脚本”指的是上一条消息里 ClaudeCode 生成的那个。这就是“上下文窗口（Context Window）”的作用。

Openclaw 内置了一个基于 Redis 的内存缓存，专门用来存储每个chat_id+user_id组合的最近 5 轮对话历史。它的原理很简单：每当 Openclaw 收到一条新消息，它会先从 Redis 里取出该用户的history列表，然后把这个列表作为messages的前缀，再把当前用户的新问题追加到末尾，一起发给 ClaudeCode。ClaudeCode 的响应返回后，Openclaw 会把user的问题和assistant的回答，一起追加到history列表里，并存回 Redis。

这个技巧的价值，在于它让 ClaudeCode 表现出惊人的“记忆”能力。你不再需要每次都把之前的代码、需求描述、错误日志，一股脑儿地复制粘贴进来。你只需要说：“把第 3 行的timeout=30改成timeout=60”，Openclaw 就能准确地定位到上一轮对话中生成的那段代码。

注意：Redis 不是必需的，Openclaw 也支持基于文件的FileCache。但对于多实例部署（比如你用 Kubernetes 部署了 3 个 Openclaw Pod），Redis 是唯一能保证状态一致的选择。我建议，哪怕是最小的部署，也配上一个单节点 Redis，它带来的体验提升，远超其运维成本。

5.2 技巧二：构建 “Skill Chain” —— 让多个 AI 工具像乐高一样拼接

Openclaw 的 Skill 不是孤立的。你可以让一个 Skill 的输出，成为另一个 Skill 的输入，形成一条“技能链（Skill Chain）”。这在处理复杂任务时，威力巨大。

举个例子：你想实现“用户上传一张服务器监控截图，Openclaw 自动识别图中异常指标，并调用 Zabbix API 查询该指标的历史数据，最后让 ClaudeCode 分析趋势”。

这个任务，单靠一个 Skill 无法完成。我们可以拆解为：

• image_recognition_skill：负责调用 OCR 或 CV 模型，识别截图中的文字（如CPU Usage: 98%）。
• zabbix_query_skill：负责接收image_recognition_skill识别出的指标名（如system.cpu.util），调用 Zabbix API 查询过去 1 小时的数据。
• trend_analysis_skill：负责把zabbix_query_skill返回的原始数据（JSON 数组），喂给 ClaudeCode，让它生成趋势分析报告。

Openclaw 的handle方法返回值，支持一个next_skill字段。image_recognition_skill处理完后，可以返回：

return { "next_skill": "zabbix_query_skill", "payload": {"metric_name": "system.cpu.util", "time_from": "now-1h"} }

Openclaw 的调度器会自动捕获这个next_skill，并把payload作为新事件的event字段，交给zabbix_query_skill的can_handle方法去判断。整个过程对用户完全透明，用户只看到一个“上传图片 → 等待几秒 → 收到分析报告”的流畅体验。

5.3 技巧三：为不同角色配置 “Persona” —— 让 AI 更懂你的身份

同一个 ClaudeCode 实例，面对开发、运维、产品，应该有不同的“人格”。对开发，它应该多讲技术细节、代码实现；对运维，它应该聚焦在命令、配置、排错步骤；对产品，它