当前位置：首页 > news >正文

阿里云ECS部署OpenClaw+GLM-5完整实践指南

news 2026/7/16 14:23:22

1. 这不是“一键部署”，而是新手在阿里云上亲手把 OpenClaw 和 GLM-5 拉进现实的完整手记

2026年，大模型应用层的门槛正在肉眼可见地塌陷。但“零基础”三个字，从来不是一句轻飘飘的营销话术——它意味着你可能连docker ps和systemctl status docker的区别都分不清，看到Permission denied (publickey)会下意识截图发给朋友，甚至不确定自己买的那台“阿里云ECS”到底算不算一台真正的Linux服务器。我写这篇东西，就是为那个刚在阿里云控制台点完“立即购买”、正对着黑乎乎的终端窗口发呆的自己写的。OpenClaw 不是玩具，它是开源世界里少有的、真正把“多智能体协作”从论文概念拉进命令行的工程化框架；智谱GLM-5 也不是又一个参数堆砌的玩具模型，它在中文长文本理解、结构化输出和工具调用上的稳定性，在当前开源生态里有明确的实测优势。把这两者在阿里云上跑通，核心价值从来不是“能跑起来”，而是建立一套可复现、可调试、可扩展的本地AI工作流基线。它解决的是：当你的业务需要一个能自动读取Excel、调用内部API、生成合规报告并邮件发送的“数字员工”时，你手里有没有一条从零开始、不依赖任何SaaS黑盒的、完全可控的技术路径。这篇文章不讲“为什么大模型重要”，只讲“怎么让openclaw run --config config.yaml这条命令，在你刚重装完系统的阿里云服务器上，真的吐出一行带[INFO] Agent 'researcher' started的日志”。关键词就三个：阿里云ECS、OpenClaw、GLM-5——所有其他热词，无论是“Docker社区版自带环境吗”还是“RockyLinux换源”，都是这条主线上必然踩到的坑，我们一个一个填平。

2. 阿里云ECS不是“开箱即用”的玩具，而是你需要亲手校准的第一台精密仪器

很多新手的崩溃，始于第一行ssh root@xxx.xxx.xxx.xxx。你以为买的是服务器，其实买的是一个裸露的、没有任何预装软件、没有任何安全加固、甚至连时间都可能不准的Linux内核实例。这恰恰是阿里云最务实的地方——它卖的是计算资源，不是保姆服务。所以，部署前的“环境准备”，绝不是走个过场，而是决定后续所有步骤能否成立的基石。

2.1 镜像选择：为什么放弃Ubuntu 24.04，坚定选Rocky Linux 9.3？

网络上充斥着“Ubuntu最友好”的说法，但在2026年的阿里云生产环境里，这已成历史。关键差异在于内核模块与容器运行时的兼容性。Ubuntu 24.04 默认搭载5.15内核，而OpenClaw底层依赖的minio（对象存储）和pgvector（向量数据库）在该内核下与某些阿里云自研驱动存在微妙的内存映射冲突，表现为docker run后容器秒退，日志里只有Killed二字，查遍dmesg也找不到明确OOM Killer记录。Rocky Linux 9.3基于RHEL 9.3，内核版本为5.14.0-362，其cgroup v2默认启用策略与Docker CE 26.x的containerd运行时匹配度极高，实测在阿里云ecs.g7ne.2xlarge机型上，连续72小时无异常重启。更重要的是，Rocky的dnf包管理器对阿里云官方镜像源的支持是原生级的，不像Ubuntu的apt需要手动编辑sources.list并反复验证GPG密钥。我试过在Ubuntu上硬扛，花了17小时排查cgroup权限问题，最终发现是内核配置项CONFIG_CGROUP_FREEZER=y在Ubuntu定制内核里被禁用所致——这种底层细节，新手根本无从下手。Rocky Linux 9.3，是经过阿里云官方深度适配、且社区长期维护的稳定基座，它的“不时髦”，恰恰是稳定性的代名词。

2.2 网络与安全组：别让“端口未开放”成为你第一个无法逾越的墙

阿里云的安全组，是新手最容易忽略的“隐形防火墙”。你可能在docker-compose.yml里把OpenClaw的Web UI端口设为3000:3000，信心满满地执行docker-compose up -d，然后在浏览器里输入http://你的公网IP:3000，得到一个冰冷的“连接已重置”。此时，99%的新手会立刻去查Docker日志、查Nginx配置、查SSL证书……而真相，往往藏在阿里云控制台一个叫“安全组”的二级菜单里。默认情况下，新购ECS的安全组规则只放行22（SSH）端口。3000、8080、11434（Ollama默认端口）这些，全被无情拦截。正确操作是：进入ECS实例详情页 → “安全组”标签页 → 点击关联的安全组名称 → “配置规则” → “添加安全组规则”。这里有个致命细节：协议类型必须选“全部”，而不是“自定义TCP”。因为OpenClaw内部组件间通信（如Agent与Orchestrator）大量使用UDP协议进行心跳检测和状态同步，若只开TCP，你会看到openclaw进程在启动后几秒内就因无法完成健康检查而自我终止。我曾在一个深夜，盯着docker logs openclaw_orchestrator里反复出现的failed to connect to udp://172.20.0.3:5353错误，翻了三遍文档才意识到是安全组问题。规则示例：

方向	协议类型	端口范围	授权对象	描述
入方向	全部	-1/-1	0.0.0.0/0	临时开放所有端口，用于调试（上线前务必收紧）
入方向	TCP	22	0.0.0.0/0	SSH访问
入方向	TCP	3000	0.0.0.0/0	OpenClaw Web UI
入方向	TCP	11434	0.0.0.0/0	Ollama API

提示：生产环境严禁使用0.0.0.0/0。应精确到你的办公IP或公司出口IP段，并为Ollama端口设置独立安全组，仅允许OpenClaw容器网络内的IP访问（如172.20.0.0/16），这是防止模型被恶意调用的基础防线。

2.3 存储规划：为什么200GB系统盘是底线，而非“够用就好”

OpenClaw本身不大，但它的“胃口”来自两个地方：一是GLM-5模型文件，二是运行时产生的向量数据库索引。GLM-5-Chat-1B模型（量化版）解压后约3.2GB，而qwen3.5:9b（常被误认为GLM-5替代品）则需12GB以上。更关键的是pgvector——当你让OpenClaw处理一份100页的PDF并构建知识库时，它会将每一页切片后的嵌入向量（embedding）存入PostgreSQL。一个中等复杂度的PDF，生成的向量数据轻松突破5GB。阿里云ECS的系统盘（ESSD云盘）IOPS性能与容量强相关：200GB提供约3000 IOPS，而100GB仅有1500 IOPS。在向量入库阶段，低IOPS会导致INSERT语句排队，openclaw主进程因等待数据库响应而超时，最终触发重试机制，形成恶性循环。我实测过：在100GB系统盘上导入一份50页技术白皮书，耗时18分钟且失败率37%；换成200GB后，同一任务耗时4分12秒，成功率100%。这不是玄学，是云厂商公开的IOPS性能公式：基础IOPS = 容量(GB) × 15。所以，200GB不是奢侈，是保障流程稳定运行的物理下限。

3. Docker不是魔法，而是你需要亲手拧紧每一颗螺丝的精密引擎

网上教程常说“Docker社区版自带环境”，这句话在2026年的阿里云Rocky Linux上，是严重误导。Rocky Linux 9.3默认安装的是podman，一个符合OCI标准但与Docker CLI不完全兼容的容器引擎。podman没有docker-compose命令，其podman-compose项目也早已停止维护。而OpenClaw官方docker-compose.yml文件里大量使用了Docker特有的network_mode: "host"和volumes_from语法，podman-compose会直接报错退出。因此，“安装Docker”是不可跳过的硬性步骤，且必须是Docker CE 26.1.3这个特定版本。

3.1 为什么必须是Docker CE 26.1.3？一个被忽略的`containerd`版本锁

Docker CE 26.x系列引入了对containerd1.7+的强制依赖，而containerd1.7.x修复了一个关键bug：在高并发场景下，containerd-shim进程会因epoll_wait系统调用返回EINTR错误而意外退出，导致容器“幽灵化”——docker ps里看不到，但ps aux | grep ollama却能看到进程还在跑，占用全部GPU显存。这个bug在OpenClaw启动多个Agent并行调用GLM-5时必现。Docker CE 26.1.3捆绑的containerd版本为1.7.20，是首个稳定修复该问题的版本。低于此版本（如25.0.3），你大概率会在openclaw run执行到第3个Agent时，看到ollama容器莫名消失，nvidia-smi显示显存被未知进程占满。安装命令必须严格按此顺序执行，任何一步出错都会导致版本错乱：

# 1. 卸载可能存在的旧版Docker（包括podman） sudo dnf remove -y podman docker docker-client docker-client-latest docker-common docker-latest docker-latest-logrotate docker-logrotate docker-engine # 2. 添加Docker官方YUM仓库（使用阿里云镜像加速） sudo yum install -y yum-utils sudo yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo sudo sed -i 's+download.docker.com+mirrors.aliyun.com/docker-ce+' /etc/yum.repos.d/docker-ce.repo # 3. 安装指定版本（关键！） sudo dnf install -y docker-ce-26.1.3-3.el9 docker-ce-cli-26.1.3-3.el9 containerd.io-1.7.20-3.1.el9 # 4. 启动并设置开机自启 sudo systemctl enable docker sudo systemctl start docker # 5. 验证版本（必须看到26.1.3和1.7.20） docker --version containerd --version

3.2 Docker守护进程配置：绕过`/var/lib/docker`的磁盘陷阱

Docker默认将所有镜像、容器、卷的数据存放在/var/lib/docker目录下。在阿里云ECS上，这个目录位于系统盘。而我们前面已确定，系统盘最小需200GB，但其中很大一部分要留给OS和日志。如果让Docker数据也挤在这里，很快就会触发No space left on device。解决方案是将其迁移到一块独立的高效云盘上。但这不是简单的ln -s软链接，因为Docker守护进程在启动时会校验/var/lib/docker的文件系统类型和挂载选项。正确做法是：购买一块1TB的ESSD PL1云盘（性价比最高），在ECS控制台挂载为/dev/vdb，然后格式化并挂载到/mnt/docker-data：

# 格式化新盘（ext4，支持大文件和高IO） sudo mkfs.ext4 /dev/vdb # 创建挂载点并挂载 sudo mkdir -p /mnt/docker-data sudo mount /dev/vdb /mnt/docker-data # 永久挂载（写入/etc/fstab） echo '/dev/vdb /mnt/docker-data ext4 defaults,noatime 0 0' | sudo tee -a /etc/fstab # 停止Docker，迁移数据（首次执行，确保Docker已停止） sudo systemctl stop docker sudo rsync -avz /var/lib/docker/ /mnt/docker-data/ sudo mv /var/lib/docker /var/lib/docker.bak sudo ln -s /mnt/docker-data /var/lib/docker # 启动Docker sudo systemctl start docker

注意：rsync命令末尾的斜杠/至关重要，它表示同步目录内容而非目录本身。漏掉斜杠会导致/mnt/docker-data/docker这样的嵌套结构，Docker将无法识别。

3.3 Docker网络：为什么`bridge`模式不够用，必须自建`openclaw-net`

OpenClaw的架构要求多个容器（orchestrator, agent, ollama, pgvector, minio）之间实现毫秒级、低延迟的通信。Docker默认的bridge网络使用iptables进行NAT转发，会引入额外的网络栈开销和不确定性延迟。在高并发Agent调度时，orchestrator向agent发送指令的RTT可能从2ms飙升至200ms，导致超时重试风暴。解决方案是创建一个自定义的macvlan网络，让容器直接获得与宿主机同网段的IP地址，绕过NAT：

# 创建macvlan网络（假设宿主机eth0网卡，网关为172.18.0.1） sudo docker network create -d macvlan \ --subnet=172.18.0.0/16 \ --gateway=172.18.0.1 \ -o parent=eth0 \ openclaw-net # 在docker-compose.yml中指定网络 networks: default: external: name: openclaw-net

这样，ollama容器的IP可能是172.18.10.5，pgvector是172.18.10.6，它们之间的通信等同于局域网内两台物理机，延迟稳定在0.3ms以内。这是OpenClaw多Agent协同流畅运行的网络基石。

4. OpenClaw部署：从`git clone`到`openclaw run`，每一步都是精心设计的逻辑链

OpenClaw的GitHub仓库（https://github.com/ai-forever/openclaw）提供了完整的docker-compose.yml，但直接docker-compose up -d会失败。原因在于，官方配置是为本地开发环境设计的，它假设你已手动下载好GLM-5模型，并配置好了所有环境变量。我们需要对其进行四层改造，才能让它在阿里云上真正“活”起来。

4.1 模型加载策略：为什么不能用`ollama pull`，而必须`COPY`模型文件

Ollama官方推荐使用ollama pull glm5:chat来下载模型。但在阿里云ECS上，这个命令会失败。根本原因在于：ollama的模型拉取机制依赖https://registry.ollama.ai，而该域名在国内DNS解析不稳定，且其CDN节点对阿里云华北地域的回源速度极慢，pull过程常卡在Downloading layers阶段超过30分钟，最终超时。更致命的是，ollama pull下载的模型文件存储在~/.ollama/models下，而Docker容器默认无法访问宿主机的用户目录。正确的方案是：在构建Ollama容器镜像时，将GLM-5模型文件直接COPY进镜像的/root/.ollama/models目录。具体操作：

在本地电脑下载GLM-5-Chat-1B量化版（glm5-chat.Q4_K_M.gguf），大小约3.2GB；
将其上传至阿里云ECS的/tmp目录；
修改docker-compose.yml中ollama服务的定义，添加build上下文：

ollama: image: ollama/ollama:latest build: context: ./ollama-custom dockerfile: Dockerfile # ... 其他配置保持不变

在./ollama-custom/Dockerfile中写入：

FROM ollama/ollama:latest COPY /tmp/glm5-chat.Q4_K_M.gguf /root/.ollama/models/blobs/sha256-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx # 注意：此处的sha256值需通过`sha256sum /tmp/glm5-chat.Q4_K_M.gguf`计算得出，并替换为实际值 RUN ollama create glm5:chat -f /root/.ollama/models/blobs/sha256-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

这样，每次docker-compose build ollama，都会生成一个内置GLM-5模型的定制镜像，启动速度从分钟级降至秒级，且完全规避网络依赖。

4.2 配置文件`config.yaml`：那些文档里没写的、决定成败的12个参数

OpenClaw的config.yaml是它的“大脑”，但官方文档对关键参数的解释极其简略。以下是我在阿里云环境上实测必须调整的12个参数及其原理：

参数名	默认值	阿里云推荐值	原理与影响
`orchestrator.max_concurrent_agents`	5	3	阿里云`g7ne`机型单核性能有限，过高并发会导致CPU争抢，Agent响应延迟激增
`agent.llm_api_base_url`	`http://localhost:11434`	`http://host.docker.internal:11434`	在`macvlan`网络下，`localhost`指向容器自身，必须用`host.docker.internal`指向宿主机Ollama服务
`agent.timeout_seconds`	120	300	GLM-5处理长文本时较慢，120秒易超时，300秒更稳妥
`vector_db.connection_string`	`postgresql://...`	`postgresql://postgres:password@pgvector:5432/vector_db`	必须使用`pgvector`容器名作为host，而非`localhost`
`minio.endpoint`	`http://localhost:9000`	`http://minio:9000`	同上，使用容器名
`minio.bucket_name`	`openclaw`	`openclaw-prod`	避免与测试环境桶名冲突
`logging.level`	`INFO`	`WARNING`	生产环境减少日志IO，提升性能
`cache.redis_url`	`redis://localhost:6379`	`redis://redis:6379`	同上
`webui.port`	`3000`	`3000`	保持不变，但需确保安全组已放行
`webui.host`	`0.0.0.0`	`0.0.0.0`	允许外部访问
`agent.max_retries`	3	1	减少因网络抖动导致的无效重试，由Orchestrator统一调度更可靠
`orchestrator.health_check_interval`	`30`	`10`	加快故障发现速度，避免Agent“假死”

提示：host.docker.internal在Docker CE 20.10+的Linux上默认不可用，需在docker-compose.yml的ollama服务下添加extra_hosts：
extra_hosts: - "host.docker.internal:host-gateway"

4.3 启动与验证：如何读懂`docker logs`里的“真·成功信号”

执行docker-compose up -d后，不要急着打开浏览器。先用docker ps确认所有容器状态为Up，然后逐个检查日志：

# 检查Ollama是否加载了GLM-5模型 docker logs ollama | grep "glm5:chat" # 检查pgvector是否初始化成功（关键看"database system is ready"） docker logs pgvector | tail -20 # 检查MinIO是否创建了bucket（关键看"created bucket"） docker logs minio | grep "openclaw-prod" # 检查OpenClaw Orchestrator是否完成初始化（关键看"Orchestrator initialized"和"Health check passed"） docker logs openclaw_orchestrator | grep -E "(initialized|Health check)"

真正的成功信号，不是Starting...，而是Started之后的Health check passed for service 'ollama'。如果看到Health check failed for service 'ollama'，说明agent.llm_api_base_url配置错误，或Ollama容器未真正监听11434端口（可用docker exec -it ollama curl http://localhost:11434/api/tags验证）。此时，不要盲目重启，先执行docker exec -it ollama ps aux | grep ollama，确认ollama serve进程是否在运行。我曾因ollama容器内/root/.ollama目录权限为700（仅root可读），导致ollama serve启动后无法加载模型文件，日志里只有panic: open /root/.ollama/models/...: permission denied，花了2小时才定位到COPY命令未指定--chown=root:root。

5. GLM-5集成：不只是“换个模型”，而是重构整个推理链路的稳定性

把GLM-5塞进OpenClaw，远不止是改个模型名那么简单。GLM-5的架构特性（如长上下文、结构化输出偏好、工具调用协议）与OpenClaw的Agent设计存在天然张力，必须进行针对性适配，否则会出现“能跑，但总出错”的诡异现象。

5.1 Prompt Engineering：为什么官方`system_prompt`要重写，且必须包含`<|user|>`分隔符

agents: - name: "researcher" system_prompt: | <|system|>你是一个专业的信息研究员，严格按以下JSON Schema输出结果： { "summary": "字符串，不超过200字", "key_points": ["字符串数组"], "sources": ["字符串数组"] } 你只能输出纯JSON，不加任何解释、不加任何Markdown、不加任何额外字符。 <|user|>

5.2 工具调用（Tool Calling）：如何让GLM-5真正“听懂”OpenClaw的function call指令

OpenClaw支持Agent调用外部函数（如search_web,read_file），其底层机制是将函数定义以JSON Schema形式注入Prompt，并期望模型返回一个包含tool_calls字段的JSON。但GLM-5原生并不支持OpenAI的tool_choice协议。强行使用会导致模型忽略函数定义，直接生成自然语言回答。破解之道在于：利用GLM-5的“结构化输出”能力，将其转化为一个严格的JSON生成任务。在config.yaml中，为需要调用工具的Agent，修改prompt_template：

prompt_template: | <|system|>{{system_prompt}} <|user|>请根据以下工具定义，严格按JSON Schema输出tool_calls： {{tools_json_schema}} 用户问题：{{user_input}} 请只输出JSON，不加任何解释。 <|assistant|>

其中{{tools_json_schema}}是动态注入的、描述所有可用工具的JSON Schema字符串。这样，GLM-5的输出就变成了一个纯粹的、可预测的JSON对象，OpenClaw只需做一次json.loads()即可提取tool_calls，无需复杂的正则匹配或LLM解析。实测表明，此方案下工具调用成功率从不足40%提升至99.2%。

5.3 性能调优：`num_ctx`与`num_gpu`的黄金配比，榨干阿里云GPU的每一分算力

GLM-5-Chat-1B在Ollama中运行时，有两个关键参数直接影响性能：num_ctx（上下文长度）和num_gpu（GPU层数）。阿里云g7ne机型配备NVIDIA A10 GPU（24GB显存），但并非所有层都能放入GPU。Ollama的num_gpu参数表示“将前N层Transformer放到GPU上”，剩余层在CPU运行。num_ctx则决定了KV Cache的大小，直接影响显存占用。我的实测黄金配比是：num_ctx=8192，num_gpu=35。理由如下：

num_ctx=4096时，处理长文档（>50页PDF）会频繁触发context overflow，模型被迫截断输入，丢失关键信息；
num_ctx=16384时，KV Cache占用显存达18GB，留给模型权重的空间不足，num_gpu被迫降至25，导致大量计算在CPU进行，整体推理速度下降40%；
num_gpu=35时，模型权重的95%在GPU上，KV Cache占用约12GB，剩余12GB显存足够支撑num_ctx=8192的长上下文，达到速度与容量的最佳平衡。

在docker-compose.yml的ollama服务中，通过command覆盖默认启动参数：

ollama: # ... 其他配置 command: > sh -c "OLLAMA_NUM_GPU=35 OLLAMA_NUM_CTX=8192 ollama serve"

6. 避坑指南：那些让我在凌晨三点对着终端抓狂、最终凝结成17条血泪经验的清单

部署不是一蹴而就的仪式，而是一场与无数隐藏陷阱的持久战。以下是我从第一次Connection refused到最终[SUCCESS] All agents healthy之间，亲手踩过、并用journalctl -u docker和strace -p逐行分析过的17个真实坑点。它们不炫技，不讲原理，只告诉你“当XXX发生时，你应该立刻执行YYY”。

坑：openclaw: command not found
解：这是openclawCLI工具未安装。它与Docker容器无关，是宿主机上的Python包。执行：pip3 install openclaw-cli --break-system-packages（Rocky Linux 9.3默认禁用--user，必须加--break-system-packages）。
坑：docker-compose up报错ERROR: Network openclaw-net declared as external, but could not be found.
解：macvlan网络必须在docker-compose up前手动创建。执行：sudo docker network create -d macvlan --subnet=172.18.0.0/16 --gateway=172.18.0.1 -o parent=eth0 openclaw-net。
坑：ollama容器日志里反复出现error loading model，但curl http://localhost:11434/api/tags返回空数组
解：ollama容器内/root/.ollama/models目录权限错误。执行：docker exec -it ollama chown -R root:root /root/.ollama。
坑：pgvector容器启动后立即退出，docker logs pgvector显示FATAL: database files are incompatible with server
解：这是PostgreSQL主版本升级导致的数据目录不兼容。删除/mnt/docker-data/volumes/openclaw-pgvector/_data目录（注意备份！），然后docker-compose up -d pgvector重建。
坑：openclaw_orchestrator日志里有Failed to connect to http://minio:9000，但docker exec -it minio ping pgvector能通
解：MinIO的MINIO_ROOT_PASSWORD必须至少8位，且不能是纯数字。检查docker-compose.yml中minio服务的environment，确保MINIO_ROOT_PASSWORD符合要求。
坑：浏览器打开http://你的IP:3000，显示502 Bad Gateway
解：Nginx反向代理未配置。OpenClaw Web UI默认不带HTTPS和负载均衡。在宿主机上安装Nginx：sudo dnf install -y nginx，然后编辑/etc/nginx/conf.d/openclaw.conf，添加反向代理配置，最后sudo systemctl restart nginx。
坑：openclaw run --config config.yaml执行后，docker ps里看不到openclaw_agent_*容器
解：config.yaml中agent.image指定的镜像不存在。OpenClaw不会自动拉取，必须先执行docker pull your-registry/your-agent-image，或在docker-compose.yml中为agent服务添加build上下文。
坑：ollama list在宿主机上能看见glm5:chat，但在openclaw_orchestrator容器里执行curl http://ollama:11434/api/tags返回空
解：ollama服务在docker-compose.yml中未暴露端口给其他容器。在ollama服务下添加：expose: ["11434"]。
坑：openclaw启动后，Agent处理任务时CPU使用率100%，但无任何输出，docker stats显示ollama容器内存持续增长至24GB后OOM
解：num_ctx设置过大。立即停止openclaw，修改config.yaml中agent.llm_options.num_ctx为4096，再启动。
坑：minioWeb UI (http://你的IP:9000) 登录后，无法创建Bucket，提示Access Denied
解：MinIO的MINIO_ROOT_USER和MINIO_ROOT_PASSWORD在docker-compose.yml中被错误地用双引号包裹，导致密码中的特殊字符（如$）被Shell解析。改用单引号：MINIO_ROOT_PASSWORD: 'my$ecur3P@ss'。
坑：openclaw_orchestrator日志里有Error: unable to verify the first certificate
解：这是ollama服务启用了HTTPS，但OpenClaw客户端未配置CA证书。在config.yaml中，将agent.llm_api_base_url改为http://开头（非https://），并在ollama服务的command中添加OLLAMA_INSECURE=true。
坑：docker-compose down后，docker volume ls显示大量openclaw_*卷未被清理，磁盘空间告急
解：docker-compose down默认不删除卷。执行：docker-compose down -v（-v参数强制删除关联卷）。
坑：openclaw启动后，docker logs openclaw_orchestrator里反复出现Failed to get agent status: Get "http://agent-1:8000/health": dial tcp: lookup agent-1 on 127.0.0.11:53: no such host
解：agent服务在docker-compose.yml中未定义container_name。为每个agent服务添加：container_name: openclaw_agent_1。
坑：ollama容器内curl http://host.docker.internal:11434/api/tags能通，但openclaw_orchestrator容器内curl http://ollama:11434/api/tags超时
解：ollama服务未加入openclaw-net网络。在ollama服务下添加：networks: ["openclaw-net"]。
坑：openclaw处理PDF时，agent日志里出现ModuleNotFoundError: No module named 'pymupdf'
解：pymupdf（PyMuPDF）未安装在agent容器内。修改agent服务的Dockerfile，在RUN pip install命令后添加pymupdf。
坑：openclaw_orchestrator日志里有KeyError: 'tool_calls'
解：GLM-5