Qwen3.5 Plus + OpenClaw：构建高可用智能体技能路由系统

1. 这不是又一个“一键部署”幻觉：Qwen3.5 Plus + OpenClaw 组合的真实水位线

你点开这篇博文，大概率刚在某个技术群或论坛里看到“5分钟跑通智能体”的标题，心里一边嘀咕“又来？”一边还是点了进来——我完全理解。过去三个月，我亲手拆解过27个标榜“保姆级”的智能体部署教程，其中21个在“安装依赖”环节就卡死，剩下6个跑通了Demo，但一接入真实业务API就报错，错误信息里反复出现context window limit、output token maximum、socket connection closed unexpectedly这些词。它们不是偶然，而是当前智能体开发链路上最真实的三道坎。

Qwen3.5 Plus 和 OpenClaw 的组合，之所以值得单独拎出来讲，是因为它绕开了两个主流陷阱：第一，它不依赖 Claude 或 DeepSeek 的闭源 API（也就避开了402 insufficient balance和model names are deepseek-v4-pro or deepseek这类权限/命名错误）；第二，它不强求本地运行 72B 级别大模型（也就跳过了mineru本地部署、deepseek本地部署带来的显存焦虑）。OpenClaw 的核心价值，是把 Qwen3.5 Plus 这个开源模型的推理能力，封装成一套可插拔、可编排、可调试的技能调度引擎。它不是另一个 LLM，而是一个“LLM 操作系统”。

关键词里没写，但所有热词都在指向同一个事实：开发者真正卡住的地方，从来不是“能不能调用 API”，而是“怎么让模型稳定、可控、可维护地执行多步骤任务”。比如openclaw skill不是写个函数就完事，它必须定义输入 Schema、输出约束、失败重试策略和上下文裁剪逻辑；openclaw配置也不是填个 URL 就行，它要处理 token 预估、流式响应缓冲、超时熔断；api中转站这个热词背后，其实是开发者在手动补全 OpenClaw 缺失的鉴权透传和请求体标准化能力。所以这篇博文不讲“怎么装”，而讲“为什么这样装才不会在第三天凌晨两点被报警电话叫醒”。

我用这组方案落地过三个真实项目：一个为电商客服团队搭建的自动退换货工单生成器（日均调用量 1.2 万次），一个为法务部门做的合同条款风险扫描助手（平均单次推理耗时 8.3 秒），还有一个给内部运营同学用的爆款口播脚本生成器（支持飞书消息卡片直出）。它们的共性是：必须稳定运行超过 72 小时，不能因某次context window limit错误导致整个工作流中断，且每次 API 调用成本必须可预测。下面所有步骤，都来自这三套生产环境的迭代记录，不是实验室里的玩具。

2. OpenClaw 的本质：一个被严重低估的“技能路由器”

很多人把 OpenClaw 当成 Dify 或 Coze 的开源平替，这是最大的误解。Dify 解决的是“如何把提示词变成 Web 页面”，Coze 解决的是“如何在 Bot 里嵌入工作流”，而 OpenClaw 解决的是更底层的问题：当一个智能体需要同时调用天气 API、数据库查询、Python 脚本和另一个 LLM 接口时，谁来决定调用顺序？谁来处理第一个接口超时后是否跳过后续步骤？谁来把 JSON 响应里的temperature字段安全地映射到下一个请求的top_p参数？这些问题，OpenClaw 用“Skill”和“Workflow”两个概念给出了答案。

2.1 Skill 不是函数，是带 SLA 的服务契约

在 OpenClaw 里，一个 Skill 的定义远比def get_weather(city: str) -> dict:严格。它必须包含：

• Input Schema：不是 Python 类型注解，而是 JSON Schema。例如天气 Skill 的输入必须声明"city": {"type": "string", "maxLength": 32, "pattern": "^[a-zA-Z\\u4e00-\\u9fa5]+$"}。这直接拦截了city="北京; DROP TABLE users;"这类注入尝试，也避免了前端传入空字符串导致下游 API 报400 Bad Request。
• Output Constraints：明确指定返回字段的类型、长度、正则匹配。比如合同扫描 Skill 的输出必须包含risk_level: {"enum": ["low", "medium", "high"]}，强制模型不能输出 “中等偏高” 这种模糊值，为后续自动化决策提供确定性。
• Execution Policy：这才是关键。你可以设置max_retries: 2,timeout_ms: 5000,fallback_to: "static_risk_low"。当天气 API 因网络抖动超时，它不会抛出ConnectionError让整个工作流崩溃，而是自动返回预设的静态值，并记录一条WARN日志。这种设计，让智能体第一次具备了传统微服务的可靠性特征。

我在线上环境把fallback_to用到了极致。比如对接飞书 API 的 Skill，我们预置了三个 fallback：第一个是返回“消息已收到，稍后处理”的占位响应；第二个是触发企业微信备用通道；第三个才是真正的告警通知。这保证了即使飞书服务不可用，用户也不会看到空白页面或报错弹窗。

2.2 Workflow 是 DAG，不是线性脚本

OpenClaw 的 Workflow 描述文件（YAML 格式）本质上是一个有向无环图（DAG）。每个节点是一个 Skill，边是数据流向。但它和 Airflow 或 Prefect 的 DAG 有本质区别：OpenClaw 的边携带的是运行时数据约束，而非静态依赖关系。举个例子：

nodes: - id: extract_entities skill: "nlp/ner" input: text: "{{ $.user_input }}" - id: check_policy skill: "legal/policy_check" input: entities: "{{ $.extract_entities.output.entities }}" # 关键在这里：这个 input 不是直接传递，而是经过一个校验器 # 如果 extract_entities.output.entities 是空列表，check_policy 不会执行，直接跳到 next - id: generate_response skill: "llm/qwen35plus" input: prompt: | 你是一个专业客服。用户提到：{{ $.user_input }} 实体识别结果：{{ $.extract_entities.output.entities }} 合规检查结论：{{ $.check_policy.output.conclusion }} 请生成不超过 150 字的回复。

这个check_policy节点的执行，取决于extract_entities的输出是否满足entities | length > 0。OpenClaw 在运行时会动态计算这个布尔表达式，为真才执行，否则跳过并把控制权交给generate_response。这种基于数据状态的条件分支，是硬编码 if-else 无法优雅实现的。我们在口播脚本生成器里用它解决了“当用户输入太短（<5字）时，跳过风格分析，直接进入模板填充”的问题，避免了模型对无效输入的胡言乱语。

2.3 Qwen3.5 Plus 的角色：不是万能大脑，而是“决策翻译官”

这里必须澄清一个常见误区：Qwen3.5 Plus 在这个组合里，不负责原始信息提取，也不负责最终文案润色，它只做一件事——把结构化 Skill 输出，翻译成符合人类阅读习惯的自然语言。它的 Prompt 工程极其简单：

你是一个严谨的翻译官。你面前有： - 用户原始问题：{{ user_input }} - 结构化分析结果：{{ structured_output }} 请严格遵循以下规则： 1. 只使用中文回答； 2. 字数严格控制在 120-180 字之间； 3. 不得添加任何分析过程描述，只输出最终结论； 4. 如果 structured_output 中 risk_level 为 "high"，必须以“⚠️ 风险提示：”开头。

这个设计带来了三个实际好处：第一，Qwen3.5 Plus 的 context 窗口压力极大降低，因为我们喂给它的structured_output是高度压缩的 JSON，而不是原始网页 HTML 或 PDF 文本；第二，输出长度绝对可控，彻底规避了response exceeded the 32000 output token maximum；第三，当需要更换模型时（比如换成更便宜的 Qwen2.5），只需修改这个 Prompt 模板，Workflow 和 Skills 完全不用动。我们在法务项目里做过 AB 测试，Qwen3.5 Plus 在“风险结论一致性”上比 Qwen2.5 高 22%，但推理耗时只多 1.3 秒，这个性价比我们愿意付。

提示：不要试图让 Qwen3.5 Plus 直接调用 API 或读取数据库。它的定位就是“最后一公里”的语言生成器。所有脏活累活，都交给 OpenClaw 的 Skills 去干。这是稳定性的分水岭。

3. 部署实录：从零到生产环境的七步，每一步都踩过坑

所谓“5 分钟跑通”，指的是在已有 Docker 环境的 Linux 服务器上，执行git clone && docker-compose up -d到看到http://localhost:8000响应的时间。但真正的生产可用，需要额外四步加固。下面是我整理的完整路径，括号里标注了每个步骤我踩过的具体坑。

3.1 环境准备：别碰 macOS，也别信“一键脚本”

• 操作系统：必须是 Ubuntu 22.04 LTS 或 Debian 12。CentOS Stream 9 表面能跑，但在docker build阶段会因 cgroups v2 兼容性问题导致 OpenClaw Worker 进程静默退出（错误日志只有一行Killed，查了三天才发现是内核参数问题）。
• Docker 版本：要求24.0.0+。低于此版本，在docker-compose up时会报service 'openclaw-worker' has neither an image nor a build context，这是 Docker Compose v2.20+ 对 YAML 解析的变更，旧版脚本没适配。
• GPU 支持（可选但强烈推荐）：如果你用 Qwen3.5 Plus 的 4-bit 量化版（推荐Qwen/Qwen3.5-4B-Chat-GGUF），NVIDIA GPU 不是必须的，CPU 也能跑（Intel i7-11800H 实测 3.2 tok/s）。但如果你要用原生 FP16 版本，必须安装nvidia-container-toolkit并验证docker run --rm --gpus all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi能正常输出。我第一次部署时漏了--gpus all参数，容器里nvidia-smi显示“No devices were found”，以为驱动坏了，重装了两遍驱动。

注意：网上流传的openclaw安装教程和群晖 docker openclaw 下载哪个，基本都失效了。群晖 DSM 7.2+ 的 Container Manager 对docker-compose.yml的 volume 挂载路径解析有 Bug，会导致/app/config目录为空。解决方案是改用 SSH 手动执行docker run，或者降级到 DSM 7.1。

3.2 获取代码与配置：官方仓库只是起点

OpenClaw 的 GitHub 仓库（https://github.com/OpenClaw/openclaw）只提供了核心框架。要让它真正工作，你必须合并三个关键配置：

1. Qwen3.5 Plus 模型接入配置：官方没有提供现成的 Qwen3.5 Plus Skill。你需要基于openclaw-skill-template创建一个新 Skill，核心是skill.py文件：

   from openclaw.skill import Skill from transformers import AutoTokenizer, AutoModelForCausalLM import torch class Qwen35PlusSkill(Skill): def __init__(self, model_path="/models/Qwen3.5-4B-Chat-GGUF"): super().__init__() self.tokenizer = AutoTokenizer.from_pretrained(model_path) self.model = AutoModelForCausalLM.from_pretrained( model_path, torch_dtype=torch.float16, device_map="auto", trust_remote_code=True ) def execute(self, input_data: dict) -> dict: prompt = input_data.get("prompt", "") inputs = self.tokenizer(prompt, return_tensors="pt").to(self.model.device) outputs = self.model.generate( **inputs, max_new_tokens=256, # 关键！硬性限制，防爆显存 do_sample=True, temperature=0.7, top_p=0.9 ) response = self.tokenizer.decode(outputs[0], skip_special_tokens=True) return {"response": response[len(prompt):]} # 剔除 prompt 本身

   这个 Skill 的max_new_tokens=256是血泪教训。不加这个，模型会一直生成直到填满显存，然后 OOM Killer 杀掉进程。

2. API 中转站配置：热词api中转站指的就是这个。你需要在docker-compose.yml里额外加一个服务：

   services: api-proxy: image: nginx:alpine ports: - "8080:80" volumes: - ./nginx.conf:/etc/nginx/nginx.conf depends_on: - openclaw-api

   nginx.conf的核心是反向代理和请求体标准化：

   location /v1/chat/completions { proxy_pass http://openclaw-api:8000/v1/chat/completions; proxy_set_header Content-Type "application/json"; # 强制添加 X-Request-ID，用于全链路追踪 proxy_set_header X-Request-ID $request_id; # 重写请求体，把前端传来的 {message: "..."} 转成 OpenClaw 要的 {prompt: "..."} proxy_set_body '{"prompt": "$request_body"}'; }

3. 飞书接入配置：openclaw接入飞书的关键，在于skills/flybook.py里的签名验证。飞书的X-Lark-Signature是用sha256(app_secret + timestamp + body)生成的，而 OpenClaw 默认不解析原始 body。你必须在 Skill 的execute方法开头加：

   import hashlib import hmac def verify_signature(self, body: bytes, timestamp: str, signature: str) -> bool: msg = f"{self.app_secret}{timestamp}{body.decode('utf-8')}" expected = hmac.new( self.app_secret.encode(), msg.encode(), hashlib.sha256 ).hexdigest() return hmac.compare_digest(expected, signature)

3.3 模型文件放置：路径、权限、格式，一个都不能错

Qwen3.5 Plus 的 GGUF 模型文件（约 2.1GB）不能随便放。我试过三种方式，只有最后一种成功：

• ❌ 放在./models/目录下，用volumes: - ./models:/app/models挂载：失败。因为 OpenClaw Worker 容器以nonroot用户运行，对挂载目录没有写权限，启动时报Permission denied。
• ❌ 放在宿主机/opt/models/，用volumes: - /opt/models:/app/models:ro只读挂载：失败。GGUF 加载时需要创建临时 mmap 文件，只读挂载会报OSError: [Errno 30] Read-only file system。
• ✅ 正确做法：把模型文件放在./models/，但修改docker-compose.yml的 worker 服务：

  openclaw-worker: # ... 其他配置 volumes: - ./models:/app/models user: "root" # 关键！覆盖默认 nonroot command: ["sh", "-c", "chown -R 1001:1001 /app/models && exec gosu 1001:1001 openclaw-worker"]

  这样，容器启动时先用 root 权限修复权限，再降权运行，既安全又可行。

3.4 启动与验证：别只看docker-compose ps

执行docker-compose up -d后，别急着打开浏览器。先做三件事：

1. 检查日志流：docker-compose logs -f openclaw-api。健康的启动日志末尾应该是：

   INFO: Application startup complete. INFO: Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)

   如果卡在INFO: Loading model...超过 90 秒，大概率是模型路径错了或显存不足。

2. 验证 Skill 注册：curl http://localhost:8000/v1/skills。你应该看到一个 JSON 数组，每个元素包含id,name,input_schema。如果返回空数组或 404，说明skills/目录下的 Python 文件没被正确加载。检查文件名是否是*.py（不能是__init__.py或test_skill.py），以及__init__.py是否存在（必须有，否则 Python 包导入失败）。

3. 手工触发 Workflow：用curl发送一个最小化测试请求：

   curl -X POST http://localhost:8000/v1/workflows/run \ -H "Content-Type: application/json" \ -d '{ "workflow_id": "test_qwen", "input": {"user_input": "今天北京天气怎么样？"} }'

   成功响应应该是一个包含status: "success"和output字段的 JSON。如果返回500 Internal Server Error，看openclaw-worker日志，90% 是 Skill 里的 Python 语法错误或模型路径错误。

3.5 生产加固：四步脱离“Demo 状态”

跑通 Demo 只是开始。要上生产，必须做：

1. HTTPS 终止：用 Nginx 或 Traefik 做反向代理，强制 HTTPS。OpenClaw API 本身不支持 TLS，硬编码证书会极大增加运维复杂度。我们用 Traefik 的自动 Let's Encrypt，配置就一行traefik.http.routers.openclaw.tls=true。

2. 请求限流：在 Nginx 层加limit_req zone=api burst=10 nodelay。OpenClaw 自身没有限流，一个恶意脚本疯狂请求/v1/workflows/run会迅速拖垮 Worker。

3. 健康检查端点：在openclaw-api的 FastAPI 应用里加一个/healthz路由，它检查三件事：数据库连接（如果有）、模型加载状态、Worker 进程存活。K8s 的 liveness probe 就靠它。

4. 日志结构化：把所有print()和logger.info()改成 JSON 格式输出。我们用structlog，一行配置就能让日志变成{"event": "workflow_started", "workflow_id": "qwen_chat", "user_id": "U12345"}。这样，ELK 或 Loki 才能有效聚合分析。

提示：railway部署和dify本地部署的教程常忽略一点：它们默认把所有服务暴露在公网上。OpenClaw 的/v1/workflows/run是无认证的，必须用 API Gateway 做鉴权，或者至少加一个X-API-KeyHeader 校验。我们线上用的是 Keycloak，但小项目用 Nginx 的auth_request模块也足够。

4. 故障排查：那些让你凌晨三点还在看日志的典型错误

部署中最耗时间的，永远是排查。我把线上遇到的高频错误归为三类：模型层、OpenClaw 层、基础设施层。下面按发生频率排序，每个都附带真实日志、根因和修复命令。

4.1 模型层错误：context window limit的真相

现象：Workflow 执行到 Qwen3.5 Plus Skill 时，API 返回{"error": "context window limit exceeded"}，但日志里看不到详细堆栈。

根因：不是模型本身的问题，而是 OpenClaw 在拼接prompt时，把user_input、structured_output、system_prompt全部无脑拼接，总长度超过了 Qwen3.5 Plus 的 32K token 上限。尤其当structured_output是一个包含 50 个字段的 JSON 时，光是 JSON 的 key 名就占了上千 token。

修复：在 Qwen3.5 Plus Skill 的execute方法里，加 token 预估和裁剪：

def execute(self, input_data: dict) -> dict: # 1. 预估 token 数 full_prompt = self.build_prompt(input_data) # 你的拼接逻辑 estimated_tokens = len(self.tokenizer.encode(full_prompt)) # 2. 如果超限，裁剪 structured_output if estimated_tokens > 28000: # 留 4K buffer structured_output = input_data.get("structured_output", {}) # 只保留前 10 个关键字段 trimmed_output = {k: v for k, v in list(structured_output.items())[:10]} input_data["structured_output"] = trimmed_output full_prompt = self.build_prompt(input_data) # 重新拼 # 3. 正常执行 inputs = self.tokenizer(full_prompt, return_tensors="pt").to(self.model.device) # ... 后续生成逻辑

验证命令：curl -X POST http://localhost:8000/v1/workflows/run -d '{"workflow_id":"test","input":{"user_input":"a"*10000}}'。这个长输入应该能成功返回，而不是报错。

4.2 OpenClaw 层错误：socket connection was closed unexpectedly

现象：openclaw-worker容器日志里反复出现ERROR: Exception in ASGI application，后面跟着ConnectionResetError: [Errno 104] Connection reset by peer，但openclaw-api日志一切正常。

根因：这是典型的异步编程陷阱。OpenClaw Worker 使用asyncio，但某些 Skill（比如调用同步 HTTP 库requests的）阻塞了事件循环。当一个 Skill 执行超过 30 秒（Uvicorn 默认 timeout），Uvicorn 主动关闭 socket，Worker 进程来不及清理就崩溃。

修复：所有阻塞操作必须用loop.run_in_executor包装：

import asyncio class WeatherSkill(Skill): async def execute(self, input_data: dict) -> dict: loop = asyncio.get_event_loop() # 把 requests.get 放进线程池执行 result = await loop.run_in_executor( None, lambda: requests.get(f"https://api.weather.com/v3/wx/forecast/daily/5day?geocode={input_data['city']}") ) return result.json()

验证命令：curl -X POST http://localhost:8000/v1/workflows/run -d '{"workflow_id":"weather","input":{"city":"beijing"}}'。这个请求应该在 5 秒内返回，而不是卡住然后报错。

4.3 基础设施层错误：insufficient balance的伪装者

现象：明明没调用任何付费 API，却在日志里看到api error: 402 insufficient balance。

根因：这不是 OpenClaw 的错，而是你配置的api-proxy服务，把请求错误地转发给了某个收费 API 网关（比如你之前测试过 DeepSeek，网关配置还残留着）。402是 HTTP 标准状态码，表示“Payment Required”，任何服务都可以返回它。

排查链路：

1. docker-compose logs -f api-proxy：看转发日志，确认目标 URL 是http://openclaw-api:8000还是https://api.deepseek.com。
2. curl -v http://localhost:8080/v1/chat/completions：用-v看完整的 HTTP 请求头和响应头，确认Server头是uvicorn还是cloudflare。
3. kubectl get svc,ep -n openclaw（如果用 K8s）：检查 Service 的spec.externalName是否指向了外部域名。

修复：彻底删除api-proxy的upstream配置，或者在 Nginx 里加return 403 "Forbidden";作为兜底。

4.4 终极排查法：用tcpdump抓包定位网络层

当所有日志都显示“正常”，但请求就是不通时，祭出终极武器：

# 在宿主机上，抓 openclaw-worker 容器的出向流量 docker run -it --rm --net container:openclaw-worker nicolaka/netshoot tcpdump -i any -w /tmp/worker.pcap port 8000 # 然后在另一个终端触发一次失败请求 curl http://localhost:8000/v1/workflows/run -d '{"workflow_id":"test"}' # 停止抓包，把 pcap 文件拷贝出来用 Wireshark 分析 docker cp openclaw-worker:/tmp/worker.pcap .

在 Wireshark 里过滤http and ip.dst == 172.20.0.3（openclaw-api 的容器 IP），你会看到：

• 如果只有 SYN 包，没有 SYN-ACK，说明网络路由不通；
• 如果有 SYN-ACK，但没有 HTTP POST 请求，说明 OpenClaw Worker 根本没发请求，问题在 Skill 逻辑；
• 如果有完整的 HTTP 200 响应，但 curl 没收到，说明问题在api-proxy或客户端。

这个方法帮我定位过一次iptables规则冲突，那是我职业生涯里最烧脑的 6 小时。

5. 运维与扩展：让这套系统活过三个月

部署完成只是第一天。一个智能体系统要长期稳定，运维和扩展比部署更重要。分享几个我们沉淀下来的实战技巧。

5.1 模型热更新：不重启服务切换 Qwen 版本

Qwen3.5 Plus 发布后，我们想无缝升级到 Qwen3.5 Plus Turbo，但不想中断服务。方案是：

1. 在./models/目录下，同时存放两个模型：

   ./models/ ├── Qwen3.5-4B-Chat-GGUF/ # 当前主力 └── Qwen3.5-Plus-Turbo-GGUF/ # 新模型

2. 修改 Qwen3.5 Plus Skill 的__init__方法，支持环境变量：

   def __init__(self, model_path=os.getenv("QWEN_MODEL_PATH", "./models/Qwen3.5-4B-Chat-GGUF")): # ... 初始化逻辑

3. 更新docker-compose.yml，为 worker 服务加环境变量：

   openclaw-worker: # ... environment: - QWEN_MODEL_PATH=/app/models/Qwen3.5-Plus-Turbo-GGUF

4. 执行docker-compose up -d --force-recreate openclaw-worker。新容器启动后，旧容器还在处理剩余请求，流量自动切到新容器。整个过程，API 响应时间波动小于 50ms。

5.2 Skill 版本管理：用 Git Tag 控制线上行为

每个 Skill 都是一个独立 Python 包。我们为skills/目录初始化 Git 仓库，并打 Tag：

cd skills git init git add . git commit -m "v1.0: initial release" git tag v1.0 # 后续修复 bug git commit -am "fix: handle empty entities" git tag v1.0.1

然后在docker-compose.yml里，用git clone --branch v1.0.1替代volumes挂载：

openclaw-worker: build: context: . dockerfile: Dockerfile.worker args: - SKILL_REPO=https://github.com/your-org/openclaw-skills.git - SKILL_TAG=v1.0.1

Dockerfile.worker 里：

ARG SKILL_REPO ARG SKILL_TAG RUN git clone -b ${SKILL_TAG} ${SKILL_REPO} /app/skills

这样，回滚一个 Skill 只需改一行SKILL_TAG，docker-compose up -d即可，无需登录服务器删文件。

5.3 成本监控：用 Prometheus 抓取真实 token 消耗

OpenClaw 本身不暴露 token 指标。我们在 Qwen3.5 Plus Skill 里加了 Prometheus Client：

from prometheus_client import Counter, Histogram TOKEN_COUNTER = Counter('qwen35_tokens_total', 'Total tokens generated', ['model']) TOKEN_HISTOGRAM = Histogram('qwen35_generation_seconds', 'Time spent generating', ['model']) def execute(self, input_data: dict) -> dict: start_time = time.time() # ... 生成逻辑 output_tokens = len(self.tokenizer.encode(response)) TOKEN_COUNTER.labels(model="Qwen3.5-4B").inc(output_tokens) TOKEN_HISTOGRAM.labels(model="Qwen3.5-4B").observe(time.time() - start_time) return {"response": response}

然后在docker-compose.yml里加 Prometheus 服务：

prometheus: image: prom/prometheus:latest volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml ports: - "9090:9090"

prometheus.yml里：

scrape_configs: - job_name: 'openclaw-worker' static_configs: - targets: ['openclaw-worker:8000']

这样，你就能在 Grafana 里看到每小时 token 消耗曲线，精准计算成本。我们发现，把max_new_tokens从 512 降到 256，token 成本下降 41%，而业务效果几乎无损。

5.4 安全加固：三个必须做的最小动作

1. 禁用 Swagger UI：openclaw-api默认开启/docs。在main.py里，把app = FastAPI(docs_url="/docs")改成app = FastAPI(docs_url=None, redoc_url=None)。Swagger 是 API 密钥的放大器。

2. 最小权限原则：openclaw-worker容器的user: "1001:1001"是必须的。永远不要用root。我们曾因一个user: "root"配置，导致攻击者通过一个未授权的 Skill 执行os.system("rm -rf /")（当然，容器里删不掉宿主机，但足以瘫痪自身）。

3. 敏感配置外置：所有 API Key、App Secret，都用docker-compose.yml的environment从.env文件读取，.env文件权限设为600，且绝不提交到 Git。docker-compose.yml里写：

   environment: - FLYBOOK_APP_SECRET=${FLYBOOK_APP_SECRET}

   .env文件：

   FLYBOOK_APP_SECRET=your_real_secret_here

我在实际使用中发现，最常被忽略的不是技术细节，而是“谁在用”和“怎么用”。我们上线后，市场部同事把口播脚本生成器当成了“万能文案机”，输入“帮我写个卖咖啡的广告”，结果模型生成了一篇 300 字的散文诗。后来我们加了强制输入约束：input_schema里要求product_type: {"enum": ["coffee", "tea", "juice"]}和tone: {"enum": ["funny", "professional", "urgent"]}。一句话的事，却让输出质量提升了 70%。技术是骨架，而对业务场景的敬畏，才是让智能体真正活起来的血液。