1. 项目概述：从“养虾”到智能体开发

最近在开发者圈子里，一个叫“OpenClaw”的项目火得不行，连带“飞书”和“每日免费百万tokens”这几个词也成了高频讨论点。乍一看标题“养虾实战教程”，你可能以为这是个农业养殖或者美食博主的分享，但实际上，这是一个极具吸引力的技术组合：OpenClaw是一个开源的AI智能体（Agent）框架，而“养虾”是开发者们对它的一种戏称，意指“培养和调教自己的AI智能体”。这个项目的核心魅力在于，它让你能够轻松地将强大的AI能力，通过字节跳动的飞书办公套件，无缝集成到日常工作和协作流程中。更关键的是，它巧妙地利用了飞书开放平台提供的免费额度，让你每天都能“薅到”价值不菲的AI计算资源（即tokens），实现近乎零成本的自动化与智能化。

简单来说，这就是一个“用官方资源，搭私人AI助手”的实战方案。对于中小团队、个人开发者，或者任何希望提升工作效率、尝试AI应用落地的朋友来说，这无疑打开了一扇新的大门。你不再需要为调用OpenAI、Claude等商业API的昂贵费用而头疼，也不再需要从零开始搭建复杂的后端服务。OpenClaw提供了智能体的大脑和骨架，飞书提供了现成的交互界面和免费的“算力饲料”，你要做的，就是按照“教程”把它们组装起来，开始“养”一只听话又能干的“电子宠物虾”。

接下来，我将以一个实际操盘手的角度，为你彻底拆解这个组合。从OpenClaw的核心概念、飞书Skill的创建，到如何稳定部署、高效利用免费tokens，以及避坑指南，我会把每一步的原理、操作和背后的考量讲清楚。无论你是想快速尝鲜，还是计划深度集成，这篇内容都能给你提供一条清晰的路径。

2. 核心组件深度解析：OpenClaw与飞书Skill

在动手之前，我们必须先理解手中的“积木”到底是什么，以及它们为何能组合在一起发挥巨大威力。这部分的深入理解，能帮助你在后续部署和调试时事半功倍。

2.1 OpenClaw：不只是另一个AI框架

OpenClaw本质上是一个开源的多智能体（Multi-Agent）协作框架。它的设计目标很明确：降低构建复杂AI工作流的门槛。与需要你从零编写大量胶水代码的原始API调用不同，OpenClaw提供了一套声明式的配置方法和丰富的内置“技能”（Skill），让你可以通过YAML配置文件，就像搭积木一样，定义智能体的角色、能力、记忆以及它们之间的协作关系。

它的核心优势在于：

1. 模块化与可扩展性：每个“技能”都是一个独立的模块，比如网络搜索、文件读取、代码执行等。你可以像安装插件一样轻松添加或移除技能，也可以基于模板开发自己的专属技能。
2. 多模型支持：它不绑定任何单一的大模型供应商。你可以轻松配置后端连接 OpenAI GPT、Anthropic Claude、本地部署的 Llama 系列模型（通过 Ollama）等。这带来了极大的灵活性，也是实现“免费tokens”策略的基础。
3. 状态管理与记忆：智能体不是一次性的问答机器。OpenClaw为智能体提供了对话历史、短期/长期记忆的管理能力，使其能在多轮交互中保持上下文连贯，完成更复杂的任务。
4. 易于集成的网关（Gateway）：OpenClaw Gateway 作为一个统一的HTTP服务接口暴露出来，这使得它可以被任何能够发送HTTP请求的应用调用，比如飞书机器人、微信机器人、自定义的Web界面等。

注意：网络上搜索“openclaw”时，可能会遇到一些混淆的信息，因为它有时也指代其他项目或工具。在本教程语境下，我们特指在GitHub上活跃的那个开源AI智能体框架。确保你从官方或可靠的社区仓库获取代码和文档。

2.2 飞书Skill与免费tokens的奥秘

这是整个方案中最具吸引力的部分。飞书Skill，指的是在飞书开放平台上创建的一个自定义机器人（Bot）应用。这个机器人可以被添加到飞书群聊或作为单独的应用使用，用户通过@机器人或点击应用卡片与之交互。

那么，“每日免费百万tokens”从何而来？这并非飞书直接赠送AI算力，而是一个巧妙的资源利用：

1. 飞书开放平台的API调用配额：飞书为开发者提供的机器人、消息、审批等API接口，在一定的调用频率和数量内是免费的。当我们通过OpenClaw处理用户请求时，智能体本身的计算（大模型推理）发生在别处（如本地或第三方平台），而飞书机器人只负责接收和发送消息。这部分消息收发的API调用，在常规使用量下，完全在飞书的免费额度内。
2. 大模型侧的免费资源：这才是“tokens”的真正来源。关键在于OpenClaw支持连接免费或低成本的大模型服务。例如：
   • Ollama + 本地模型：在你自己电脑或服务器上部署Ollama，然后运行开源的Llama 3、Qwen等模型。这完全是零token成本，但消耗本地算力。
   • 云厂商的免费额度：许多AI云平台（如DeepSeek、智谱AI、月之暗面等）为新用户或特定模型提供一定量的免费API调用额度。OpenClaw可以配置使用这些API。
   • 项目本身的福利：有时开源项目会与模型提供商合作，提供一些测试用的API Key。

所谓的“百万tokens”，通常是指通过组合利用这些免费资源所能获得的等效计算量。例如，一个中等规模的本地模型，处理日常问答和文档总结，一天消耗的token量折算成商业API的价格，可能确实价值数百元。因此，这个说法是一种形象化的表达，核心是极低的边际成本。

飞书机器人的核心价值在于，它提供了一个现成的、用户友好的、且与工作场景深度绑定的交互界面。你不需要自己开发前端，你的团队成员也无需学习新工具，直接在熟悉的飞书里就能使用AI助手。

2.3 技术架构与数据流

理解了组件，我们来看它们如何协同工作。整个系统的数据流是这样的：

用户 @飞书机器人 -> 飞书服务器 -> (飞书事件回调) -> 你的服务器(运行OpenClaw Gateway) -> OpenClaw智能体引擎 -> 调用配置的大模型(Ollama本地/云API) -> 生成回复 -> 你的服务器 -> (调用飞书发消息API) -> 飞书服务器 -> 用户收到回复

1. 事件驱动：你在飞书开放平台配置一个“事件订阅”URL，指向你部署的OpenClaw Gateway。当用户在飞书里@机器人时，飞书服务器会向这个URL发送一个携带事件信息的HTTP POST请求。
2. 请求处理：OpenClaw Gateway收到请求后，解析出用户的文本消息。
3. 智能体执行：Gateway将用户消息交给配置好的OpenClaw智能体。智能体根据其角色设定、记忆和技能库，决定如何响应该消息。这可能包括调用网络搜索、查询数据库、执行代码等。
4. 模型推理：智能体组织好思考过程和需要生成的回复内容，向配置的后端大模型（如本地Ollama）发起请求，得到模型生成的文本。
5. 响应返回：OpenClaw将最终回复文本通过Gateway返回给飞书事件回调的处理逻辑。
6. 消息发送：你的服务器端逻辑（通常是一段简单的Webhook处理代码）调用飞书的“发送消息”API，将AI的回复内容发送回原来的群聊或会话。

这个架构清晰地将交互界面（飞书）、智能逻辑（OpenClaw）和计算核心（大模型）解耦，每一层都可以独立替换和升级，提供了极大的灵活性。

3. 环境准备与部署实战

理论清晰后，我们进入实战环节。部署是整个流程中步骤最多的一环，我会详细拆解，并标注出每个环节的注意事项。我们将采用Docker Compose作为部署方式，这是目前最推荐的方法，能极大简化依赖管理和服务编排。

3.1 基础环境搭建

你需要一台拥有公网IP地址的服务器（云服务器如阿里云ECS、腾讯云CVM均可），或者如果你只想在本地局域网测试，一台性能尚可的PC/Mac也可以。操作系统以Ubuntu 22.04 LTS为例。

第一步：系统更新与基础工具安装

sudo apt update && sudo apt upgrade -y sudo apt install -y curl wget git vim net-tools

第二步：安装Docker与Docker ComposeDocker能保证环境一致性，避免“在我机器上好好的”这类问题。

# 安装Docker curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh sudo usermod -aG docker $USER # 将当前用户加入docker组，避免每次sudo newgrp docker # 刷新用户组，或退出重新登录 # 安装Docker Compose插件（Docker新版本已集成） sudo apt install -y docker-compose-plugin # 验证安装 docker --version docker compose version

第三步：获取OpenClaw部署文件OpenClaw社区通常提供了标准的docker-compose.yml配置文件。

git clone <OpenClaw官方或社区维护的仓库地址> # 请替换为实际仓库地址 cd openclaw-deploy

这里有一个关键点：你需要确认仓库里的docker-compose.yml文件是否包含了所有必需的服务，特别是Ollama服务（用于运行本地大模型）和OpenClaw Gateway服务。

实操心得：在克隆仓库前，先浏览仓库的README文件。优秀的开源项目会在README中明确说明部署方式、环境变量配置和快速启动命令。如果仓库没有提供现成的compose文件，你可能需要参考文档，自己编写一个，将OpenClaw、PostgreSQL（用于记忆存储）、Redis（用于缓存）和Ollama服务编排在一起。

3.2 配置与启动核心服务

假设我们有一个标准的docker-compose.yml，内容概览如下：

version: '3.8' services: ollama: image: ollama/ollama:latest container_name: ollama ports: - "11434:11434" volumes: - ollama_data:/root/.ollama restart: unless-stopped openclaw: image: openclaw/openclaw:latest # 假设的官方镜像，请以实际为准 container_name: openclaw depends_on: - ollama environment: - OLLAMA_BASE_URL=http://ollama:11434 - DEFAULT_MODEL=llama3.1:8b # 指定默认使用的模型 - LOG_LEVEL=info volumes: - ./config:/app/config - ./data:/app/data ports: - "3000:3000" # OpenClaw Gateway端口 restart: unless-stopped # 可能还有PostgreSQL、Redis等服务... volumes: ollama_data:

关键配置解析：

1. OLLAMA_BASE_URL：这是最重要的环境变量之一。它告诉OpenClaw去哪里寻找大模型服务。在Docker Compose网络内，服务间可以使用服务名（ollama）进行通信，对应容器内部的11434端口。
2. DEFAULT_MODEL：指定智能体默认使用哪个模型。你需要确保这个模型已经在Ollama中拉取（Pull）了。
3. 卷（Volumes）映射：将容器内的配置目录（/app/config）和数据目录（/app/data）映射到宿主机，这样即使容器重建，你的配置和记忆数据也不会丢失。

启动服务并拉取模型：

# 1. 启动所有服务（后台运行） docker compose up -d # 2. 查看日志，确认服务启动正常 docker compose logs -f openclaw # 3. 进入Ollama容器，拉取所需的大模型 docker exec -it ollama ollama pull llama3.1:8b # 你也可以拉取其他模型，如 qwen2.5:7b, mistral:7b 等，根据你的硬件选择。

模型拉取需要时间，取决于你的网络和模型大小。8B参数模型大约需要4-5GB磁盘空间。

注意事项：首次启动时，务必通过日志检查OpenClaw是否成功连接到了Ollama。常见的错误是OLLAMA_BASE_URL配置错误或Ollama服务未就绪。你可以在宿主机上运行curl http://localhost:11434/api/tags来测试Ollama API是否可用。

3.3 配置OpenClaw智能体与技能

服务运行后，OpenClaw本身还需要配置。这通常通过修改宿主机./config目录下的YAML文件来完成。你需要创建一个智能体定义文件，例如my_assistant.yaml。

# ./config/agents/my_assistant.yaml name: "飞书小助手" model: "llama3.1:8b" # 与DEFAULT_MODEL一致，或覆盖它 description: "一个集成在飞书中的全能助手，可以回答问题、总结内容、搜索信息。" skills: - name: "web_search" # 假设有网络搜索技能 enabled: true config: api_key: ${ENV_WEB_SEARCH_KEY} # 建议从环境变量读取 - name: "file_reader" enabled: true system_prompt: | 你是一个专业的办公助手，集成在飞书平台中。你的回答应简洁、清晰、有用。 如果用户的问题需要实时信息，你可以使用网络搜索技能。 如果用户上传了文件，你可以尝试读取并总结其内容。 请保持友好和乐于助人的态度。

这个配置文件定义了智能体的身份、能力和行为准则。skills部分列出了它可用的工具。你需要根据OpenClaw官方文档，了解有哪些内置技能可用以及如何配置它们。

配置完成后，通常需要重启OpenClaw服务或通过其管理API加载新配置。

docker compose restart openclaw

4. 飞书机器人创建与事件订阅

这是连接飞书与你的OpenClaw服务器的桥梁。步骤稍多，但飞书开放平台的界面比较友好。

4.1 创建飞书机器人应用

1. 登录 飞书开放平台 ，进入“开发者后台”。
2. 点击“创建企业自建应用”。
3. 填写应用名称（如“AI工作助手”）、描述，并上传应用图标。
4. 创建完成后，进入应用详情页，你需要关注几个关键信息：
   • App ID和App Secret：这是应用的身份凭证，用于调用飞书API。务必妥善保管App Secret。
   • Encryption Key和Verification Token：在“事件订阅”部分，飞书会提供这两个值，用于验证来自飞书服务器的请求真实性。

4.2 配置权限与启用能力

为了让机器人能接收消息和发送消息，你需要为它添加相应的权限。

1. 在应用详情页，找到“权限管理”。
2. 添加以下权限（根据你的需求选择）：
   • 获取用户发给机器人的单聊消息(im:message.p2p_msg)
   • 获取群聊中用户@机器人的消息(im:message.group_at_msg)
   • 获取用户在群聊中@机器人的消息(im:message.group_at_msg?only_bot=false)
   • 以应用身份发消息(im:message)
   • 获取用户发给机器人的单聊消息(im:message.p2p_msg)
   • （可选）获取与上传图片或文件(im:image,im:file)，如果想让AI处理图片或文档。
3. 添加权限后，记得在页面底部点击“申请线上发布”或“版本管理与发布”，创建一个新版本并申请发布。通常测试阶段可以在“安全设置”中添加测试人员，无需正式发布。

4.3 配置事件订阅（核心步骤）

事件订阅是让飞书主动通知你的服务器的机制。

1. 在应用详情页，找到“事件订阅”。
2. 开启事件订阅。
3. 填写请求地址URL：这里要填入你部署了OpenClaw Gateway的服务器公网地址，并指向一个特定的webhook端点。例如：https://your-server.com:3000/feishu/webhook。这个端点需要你后续在代码中实现。
   • 重要：此URL必须支持HTTPS。对于测试，你可以使用内网穿透工具（如ngrok、localtunnel）将本地服务暴露为一个HTTPS地址。
4. 验证请求：填写URL后点击“保存”，飞书会向该地址发送一个带有challenge参数的GET请求。你的webhook服务必须能正确解析这个请求并返回challenge值，否则无法通过验证。这通常在webhook处理代码的第一步实现。
5. 订阅事件：在事件列表里，找到并订阅“接收消息”相关的事件，例如：
   • im.message.receive_v1(用户发送消息给机器人)
6. 保存所有配置。

4.4 编写飞书Webhook处理服务

你的OpenClaw Gateway（端口3000）需要有一个额外的路由来处理飞书的回调。你可以用任何你熟悉的语言（Python, Node.js, Go）写一个简单的服务，或者利用OpenClaw社区可能提供的飞书适配器模块。

以下是一个极简的Python Flask示例，展示核心逻辑：

# feishu_webhook.py from flask import Flask, request, jsonify import requests import json import hashlib import hmac import base64 import time app = Flask(__name__) # 从环境变量读取飞书配置 APP_SECRET = os.getenv('FEISHU_APP_SECRET') VERIFICATION_TOKEN = os.getenv('FEISHU_VERIFICATION_TOKEN') OPENCLAW_GATEWAY_URL = "http://openclaw:3000/v1/chat/completions" # Docker网络内地址 # 飞书消息处理函数 def handle_feishu_event(event): # 1. 提取消息内容 msg_type = event.get('message', {}).get('message_type') content = json.loads(event.get('message', {}).get('content', '{}')) text = content.get('text', '').strip() # 移除可能存在的@机器人标记 if text.startswith('@_user_'): text = text.split(' ', 1)[1] if ' ' in text else '' if not text: return None # 2. 构造请求发送给OpenClaw Gateway headers = {'Content-Type': 'application/json'} payload = { "model": "llama3.1:8b", # 或你的智能体名 "messages": [{"role": "user", "content": text}], "stream": False } try: resp = requests.post(OPENCLAW_GATEWAY_URL, json=payload, headers=headers, timeout=30) resp.raise_for_status() ai_response = resp.json()['choices'][0]['message']['content'] except Exception as e: ai_response = f"处理请求时出错：{str(e)}" return ai_response # 飞书事件回调验证 def verify_feishu_token(token, timestamp, nonce, signature): # 验证逻辑，此处省略，需按飞书文档实现 pass @app.route('/feishu/webhook', methods=['POST', 'GET']) def webhook(): if request.method == 'GET': # 飞书验证回调 challenge = request.args.get('challenge') return jsonify({'challenge': challenge}) elif request.method == 'POST': # 处理事件 data = request.json # 验证签名（重要！） # if not verify_feishu_token(...): return jsonify({}), 403 # 判断事件类型 if data.get('type') == 'url_verification': return jsonify({'challenge': data.get('challenge')}) elif data.get('type') == 'event_callback': event = data.get('event') # 只处理消息事件 if event.get('type') == 'message_received': reply = handle_feishu_event(event) if reply: # 调用飞书API发送回复消息 # 需要实现 send_feishu_message 函数 send_feishu_message(event['message']['chat_id'], reply) return jsonify({}), 200 return jsonify({}), 404 if __name__ == '__main__': app.run(host='0.0.0.0', port=3001) # 注意不要和Gateway端口冲突

这个示例省略了详细的签名验证和飞书消息发送API的调用实现，你需要参考飞书官方文档补全。核心思路是：接收飞书事件 -> 提取用户消息 -> 转发给OpenClaw -> 获取AI回复 -> 调用飞书API发回消息。

将这个服务也通过Docker Compose管理，与OpenClaw服务一同部署。

5. 高级配置、优化与安全考量

基础功能跑通后，我们需要关注如何让它更稳定、更安全、更好用。

5.1 智能体技能扩展与记忆增强

OpenClaw的强大之处在于技能库。除了基本的对话，你可以为你的“虾”添加更多能力：

• 网络搜索技能：配置Serper API或SearxNG（自建搜索引擎），让AI能回答实时性问题。注意：使用商业搜索API会产生费用。
• 文件处理技能：让AI能读取用户上传到飞书的TXT、PDF、Word、Excel文件，并进行总结、问答。这需要配置相应的文件解析库（如pypdf,python-docx）。
• 代码解释/执行技能（谨慎使用）：在沙箱环境中执行Python代码片段，用于数学计算或数据分析演示。务必严格限制权限和资源，避免安全风险。
• 长期记忆：配置OpenClaw使用PostgreSQL或向量数据库（如Chroma, Weaviate）来存储和检索长期对话记忆，使AI能记住跨会话的上下文。

配置这些技能通常需要在智能体的YAML配置文件中声明，并确保相应的后端服务可用。

5.2 性能优化与稳定性

1. 模型选择：本地部署时，模型大小需与服务器硬件匹配。8B参数模型在16GB内存的服务器上运行较为流畅。如果资源紧张，可以考虑更小的模型（如Phi-3 mini, 3.8B），或使用量化版本（如llama3.1:8b-instruct-q4_K_M）。
2. Ollama优化：
   • 使用ollama pull拉取模型时，可以指定标签，如llama3.1:8b-instruct-q4_K_M，其中q4_K_M是4位量化，能显著减少内存占用和提升推理速度，精度损失在可接受范围内。
   • 在Ollama运行时，可以通过环境变量OLLAMA_NUM_PARALLEL等控制并发数。
3. OpenClaw配置：
   • 调整max_tokens,temperature等生成参数，控制回复长度和创造性。
   • 设置合理的请求超时时间，避免长时间无响应。
4. 网关与Webhook服务：
   • 为Flask/Django等Web服务配备生产级WSGI服务器，如Gunicorn（配合Nginx反向代理），而不是直接运行开发服务器。
   • 在Nginx配置中启用HTTPS、设置超时、限制请求体大小等。
   • 为webhook服务添加重试和队列机制（如使用Redis Queue），防止因OpenClaw处理慢导致飞书回调超时（飞书回调有5秒超时限制）。常见的做法是webhook接口收到事件后立即返回200，然后将任务放入队列异步处理，再主动调用飞书API发送消息。

5.3 安全与权限管理

这是一个企业级应用必须考虑的问题。

1. 飞书侧：
   • 权限最小化：只申请应用真正需要的权限。
   • IP白名单：在飞书开放平台配置服务器IP白名单，防止回调地址被恶意调用。
   • 妥善保管密钥：App Secret、Encryption Key等绝对不要提交到代码仓库。使用环境变量或密钥管理服务。
2. 服务器侧：
   • HTTPS：公网服务必须使用HTTPS。可以使用Let‘s Encrypt免费证书。
   • 验证签名：务必在webhook服务中实现飞书事件签名验证。这是确认请求真正来自飞书的唯一方式，防止伪造请求攻击。
   • 防火墙：只开放必要的端口（如443, 80）。Ollama的11434端口、OpenClaw的管理端口不应直接暴露到公网。
   • Docker安全：以非root用户运行容器，定期更新镜像。
   • 模型与技能隔离：对于文件读取、代码执行等高风险技能，应在严格的沙箱环境中运行，并限制其访问的文件系统范围和网络权限。
3. 内容安全：
   • 在OpenClaw的system_prompt中明确加入内容安全约束，要求AI不生成有害、违法、侵权的内容。
   • 考虑在webhook层或OpenClaw之前添加一个内容过滤中间件，对用户输入和AI输出进行二次检查。

6. 常见问题与排查实录

在实际部署和运行中，你几乎一定会遇到下面这些问题。这里记录了我的排查思路和解决方法。

6.1 部署与连接问题

问题1：Docker Compose启动后，OpenClaw日志报错“连接Ollama失败”或“模型未找到”。

• 排查：
  1. 检查docker-compose.yml中OLLAMA_BASE_URL的值。在Compose网络内，应使用服务名http://ollama:11434；如果从宿主机测试，用http://localhost:11434。
  2. 运行docker compose logs ollama查看Ollama容器是否启动成功，有无错误日志。
  3. 进入Ollama容器检查模型是否已拉取：docker exec -it ollama ollama list。
  4. 在OpenClaw容器内测试网络连通性：docker exec -it openclaw curl http://ollama:11434/api/tags。
• 解决：
  • 确保Ollama容器健康运行。
  • 如果模型未拉取，执行docker exec -it ollama ollama pull <model_name>。
  • 检查OpenClaw配置中model名称是否与Ollama中的模型名完全一致（包括标签）。

问题2：飞书事件订阅URL验证失败。

• 排查：
  1. 确认你的webhook服务已经运行且端口可访问。
  2. 确认URL是HTTPS（飞书要求）。本地测试必须用ngrok等工具。
  3. 检查你的webhook服务是否正确响应了GET请求并返回了正确的challenge值。查看你的服务日志。
  4. 检查服务器防火墙/安全组是否放行了webhook服务端口。
• 解决：
  • 在webhook服务中，确保/feishu/webhook的GET请求处理逻辑正确。
  • 使用curl或 Postman 手动模拟飞书的验证请求进行测试。

6.2 运行与功能问题

问题3：用户在飞书@机器人，机器人没反应。

• 排查：
  1. 检查事件订阅：飞书开发者后台-事件订阅，查看是否有事件送达记录。如果有“失败”记录，点击查看详情。
  2. 检查webhook服务日志：看是否收到了POST请求。如果没收到，问题在飞书侧或网络。
  3. 检查签名验证：如果收到了请求但返回了403，可能是签名验证失败。仔细核对Verification Token和签名计算逻辑。
  4. 检查OpenClaw Gateway：webhook服务转发请求给OpenClaw后，查看OpenClaw的日志是否有错误。
  5. 检查飞书API调用：webhook服务调用飞书发消息API是否成功。飞书API返回的错误码很有帮助。
• 解决：这是一个典型的端到端排查流程。按照“飞书->你的服务器->OpenClaw->你的服务器->飞书”这个链条，逐一检查日志和状态。

问题4：AI回复速度很慢，或者飞书提示“消息发送失败，超时”。

• 原因：大模型推理本身较慢，尤其是首次加载或处理长文本时。飞书服务器等待回调响应有超时限制（约5秒）。
• 解决：
  • 异步处理：这是必须的优化。Webhook接口收到事件后，立即返回成功响应。然后使用消息队列（如Redis + RQ，或Celery）将处理任务异步化。异步任务完成后，再调用飞书的“发送消息”API（该API没有短超时限制）。
  • 模型量化：使用量化模型（如q4, q5）提升推理速度。
  • 硬件升级：确保服务器有足够的CPU/GPU资源和内存。

问题5：OpenClaw技能（如搜索、读文件）不工作。

• 排查：
  1. 检查智能体YAML配置中，该技能是否enabled: true。
  2. 检查技能所需的配置项（如API Key、文件路径）是否正确设置，特别是通过环境变量引用的值是否已正确注入容器。
  3. 查看OpenClaw日志，通常会有技能加载失败或执行错误的具体信息。
  4. 如果技能涉及外部API，在容器内测试网络连通性。
• 解决：根据日志错误信息，修正配置或解决网络问题。

6.3 资源与成本问题

问题6：本地模型消耗内存太大，服务器卡顿。

• 解决：
  • 换用更小或量化模型：这是最直接有效的方法。
  • 调整Ollama参数：通过OLLAMA_NUM_PARALLEL限制并发请求数。
  • 硬件层面：增加虚拟内存（swap空间），但会影响速度。最根本的还是升级服务器配置。

问题7：担心飞书API免费额度超限。

• 分析：飞书开放平台对机器人消息API的调用频率有限制（如单个机器人每分钟最多发送20条消息到群聊）。对于个人或小团队内部使用，通常远达不到限额。
• 监控：在飞书开发者后台可以查看API调用量统计。
• 策略：在webhook服务中添加简单的限流逻辑，防止异常情况（如群聊刷屏）导致短时间内大量调用。

整个项目搭建下来，从最初的“雾里看花”到最后的“稳定运行”，最大的体会是：开源生态的成熟和云服务的便利，极大地降低了个人开发者构建复杂AI应用的门槛。OpenClaw提供了智能体的“灵魂”与“骨架”，飞书提供了绝佳的“舞台”和“免费门票”，而Docker等工具则让部署变得标准化。这个组合的成功，不在于任何单一技术的颠覆性，而在于它们恰到好处的衔接与互补。

最后分享一个小心得：在配置智能体的system_prompt时，花点心思描述它的角色、边界和能力，效果会截然不同。一个清晰的“人设”能让AI的表现更加稳定和符合预期。比如，明确告诉它“你是一个专注于提高办公效率的助手，对于无法确定的信息，应建议用户进行网络搜索，而非编造答案”，这能有效减少胡言乱语的情况。