OpenClaw+LiteLLM+Discord：从零搭建多端AI助手中控实战-AI智能范式网

OpenClaw+LiteLLM+Discord：从零搭建多端AI助手中控实战

篷汎山·2026-09-25·阅读 22 GEO检测（免费）

OpenClawLiteLLMDiscord

|难度：普通|阅读约 40 分钟

先别急着装环境，我想先聊一个很多人容易忽略的问题：你搭一个开源 Agent 框架，到底是为了什么？我在反复折腾 OpenClaw 的过程中，最大的感受是——模型本身不稀奇，稀奇的是把“模型层”“会话层”“入口层”三件事分开，然后让它们按一个稳定的顺序协作起来。OpenClaw 管会话和 Agent 行为，LiteLLM 管模型网关，Discord 管用户入口，这一套组合下来，基本就等于自己搭了一个可定制的多端智能助理中控。

我写这篇东西的初衷很直接：把 openclaw 安装、对接 LiteLLM 网关、再挂到 Discord 上这个过程，用踩坑之后才明白的方式完整讲一遍。适合手里已经有大模型 API Key、想自己搭一个跨渠道 AI 助手的人，也适合第一次听说这三个名字、打算入门的同学。我会尽量把配置和排查过程讲细，因为实操里真正的门槛不是启动，而是出了问题不知道去哪看。

1. 先搞清楚：OpenClaw + LiteLLM + Discord 到底是怎么协作的

1.1 三个组件各管什么

先说人话版：OpenClaw 是“大脑容器”，负责接收消息、管理会话、调用工具、组织回复；LiteLLM 是“模型总闸”，把所有乱七八糟的模型接口统一成一个 OpenAI 格式的接口；Discord 是“遥控器”，让你在聊天框里就能跟这个 Agent 对话。

如果你把这套链路想象成一家餐厅，那 Discord 就是顾客的餐桌，OpenClaw 是后厨的厨师长，LiteLLM 是那个负责对接所有供应商的采购主管。厨师长不需要知道每道菜去哪买食材，他只需要让采购主管按标准格式把原材料送进来。这个解耦特别重要，因为当你今天用通义千问，明天换 Claude，后天想接本地模型，你改的只是 LiteLLM 那边的一行配置，OpenClaw 本身完全不用动。

很多人一开始图省事，直接把模型 API 地址填进 OpenClaw 里，这当然能跑通。但一旦你有多个模型、多个 Key、多个人在用，问题就来了：每个 Key 的限额怎么管？调用日志去哪看？模型挂了能不能自动切备用？这些事如果全塞在 OpenClaw 的配置里，你会发现配置文件越改越长，最后根本不敢动。

1.2 一次完整请求的流转链路

从你在 Discord 里发一条“帮我总结这个网页”，到屏幕上出现答案，中间其实走了这么几步：

你在 Discord 频道或私信里发消息，Discord Bot 把这条消息通过 Gateway 事件推给 OpenClaw 的 Discord Adapter。OpenClaw 拿到消息后先去匹配会话：同一个频道、同一个用户、同一个线程算一个会话，它会先从会话存储里把上下文历史捞出来。然后把用户消息和上下文拼成模型的输入结构，调用模型层。因为 OpenClaw 默认走的是 OpenAI 兼容格式，所以它不需要知道后端到底是什么模型，只需要把请求发到 LiteLLM 的地址上。

LiteLLM 收到请求后，根据 URL 里的 model 名称去 config.yaml 的模型列表里找对应的路由规则，然后把请求转发给真正的模型供应商。模型返回结果后，原路返回给 OpenClaw。OpenClaw 把回复内容做后处理，比如分段、去掉特殊字符、计数 token，最后通过 Discord 的 REST API 把消息发回刚才那个频道。你在 Discord 里看到回复，整个过程一般几秒到十几秒。

这条链路里最容易出问题的是第二到第五步：会话锁、模型路由、Key 鉴权、Discord 发送。后面我会逐个拆开说。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. OpenClaw 安装：先把“大脑”安置好

2.1 环境准备与目录规划

OpenClaw 的部署方式我推荐用 Docker，原因很简单：它自带运行时依赖，和宿主机的隔离干净，升级、回滚、迁移都方便。如果你用的是 Linux 服务器，建议选 Ubuntu 22.04 或 Debian 12，内存至少 4G，硬盘 20G 以上。要是你的机器只有 2G 内存，跑起来会比较吃紧，因为 OpenClaw 本身、LiteLLM 再加一个模型网关，两三个容器同时跑，内存很容易被吃光。

Windows 用户也不用绕道走，装一个 Docker Desktop 就能跑同样的镜像。在 Windows 上安装时注意一点：Docker Desktop 默认用 WSL2 后端，如果你的项目目录放在 D 盘这类非系统盘，记得在 Docker Desktop 的设置里确认共享目录权限，否则容器挂载宿主机目录的时候老是报 permission denied。我在 Windows 上第一次踩这个坑的时候完全蒙了，后来才发现是挂载目录没给权限。

目录规划我建议这样建：把所有东西放在一个总目录下面，比如 ~/agent-stack/openclaw 和 ~/agent-stack/litellm，两个服务分开管理，不要堆在一起。OpenClaw 的配置、会话数据、日志分别建子目录，这样后面排错的时候，你知道日志去哪翻，会话文件在哪看，不用整个目录翻个底朝天。

2.2 容器方式安装并完成首次启动

安装 OpenClaw 的官方方式在不同版本里入口有一点差异，但核心思路一致：把项目代码拉下来，写一个 docker-compose.yml，把配置目录挂载进去，然后启动。

我的做法是先把项目 clone 到本地：

bash复制git clone https://github.com/your-org/openclaw.git
cd openclaw

然后创建 docker-compose.yml：

yaml复制services:
  openclaw:
    image: openclaw:latest
    container_name: openclaw
    restart: unless-stopped
    ports:
      - "8080:8080"
    environment:
      - OPENCLAW_CONFIG_DIR=/app/config
      - OPENCLAW_SESSION_DIR=/app/data/sessions
    volumes:
      - ./config:/app/config
      - ./data:/app/data

这里有几个点要解释一下。第一，OPENCLAW_CONFIG_DIR 是配置目录，OpenClaw 启动的时候会从这里面读主配置；OPENCLAW_SESSION_DIR 是会话目录，所有会话状态和锁文件都会生成在这里，后面那个 session file locked 的报错就跟它直接相关。第二，端口映射成 8080 是为了你本地能打开控制台或者调试接口，如果不需要可以去掉。第三，restart: unless-stopped 加上之后，进程崩了或者机器重启，容器会自动拉起来，省心很多。

启动命令很简单：

bash复制docker compose up -d
docker compose logs -f

第一次启动不要加 -d 先前台跑一次也行，因为你能直接看到日志输出，确认到底有没有正常初始化。看着日志滚动起来，没有标红的报错，才算第一步过了。

2.3 配置目录初始化与第一个配置文件

启动之后，OpenClaw 会往 ./config 里生成一个默认配置文件，通常叫 openclaw.yaml 或者 .env，具体看版本。打开它，你会看到一堆默认值，我建议先别急着全改，找到这几个关键项填上即可：

yaml复制llm:
  provider: openai
  base_url: http://host.docker.internal:4000/v1
  api_key: sk-你的虚拟key
  model: qwen-plus
  temperature: 0.7
  max_tokens: 2048

这几行先别细看参数，后面第三章会展开讲。你只需要知道，OpenClaw 通过这一段的 base_url 来决定把模型请求发给谁，我们现在打算发给本机的 LiteLLM，所以写 host.docker.internal，因为容器里不能直接用 127.0.0.1 访问宿主机的服务。这是新手最容易卡住的地方之一，我见过好几个人在容器里配 http://localhost:4000，结果服务永远连不上，其实不是服务的问题，是网络命名空间的问题。

配置保存之后，重启容器让配置生效。此时 OpenClaw 会尝试连 LiteLLM，因为还没部署，日志里大概率会有连接错误，不用慌，这是正常的，接下去我们把网关补上。

3. 对接 LiteLLM 网关：把模型接入管起来

3.1 为什么是 LiteLLM，而不是直接改模型地址

你可能会问：OpenClaw 不是可以直接接 OpenAI 兼容的接口吗？那我直接把 base_url 填成 DashScope 或者别的供应商地址不就行了？确实可以，但只限于你只有一个模型、一个 Key、不需要统计的场景。

一旦你有多模型、多 Key、多人使用的需求，直连的方式就尴尬了。比如你想给团队里每个人分配一个独立 Key，OpenClaw 本身没有用户级 Key 的概念，它只会拿着自己的配置去请求模型供应商。又比如你想统计这个月的 token 消耗，直连模式下你得去各个平台分别看账单，然后手工加总。还比如你想在主力模型不可用的时候自动切到备用模型，直连模式下 OpenClaw 没有一个轻量的路由逻辑去帮你处理。

LiteLLM 解决的就是这堆事。它在中间起一个网关，统一暴露成 OpenAI 格式的 /v1/chat/completions，背后路由到任意模型。它还支持虚拟 Key，可以给每个调用方一个单独的 Key，随时作废、设置额度、看每一把 Key 花了多少 token。说白了，它让“模型资源”变成了一种可管控的内部服务，这在多人和生产环境下几乎是必需品。

我做一个直观对比，你看一眼就明白为什么推荐走网关：

场景	直连模型	走 LiteLLM 网关
换模型厂商	要改 OpenClaw 配置并重启	只改网关配置，OpenClaw 零改动
多模型路由	不支持	按名称路由，支持故障切换
多人使用	全都共享一个 Key	每人独立虚拟 Key，可限额
用量统计	需要去各平台手动看	网关面板统一看
模型报错排查	日志分散	网关日志集中，curl 一眼定位

3.2 部署 LiteLLM 并用 config.yaml 管理模型列表

LiteLLM 部署也很简单，官方镜像直接拉起来，关键在 config.yaml 怎么写。我建了一个单独的 ~/agent-stack/litellm/config.yaml，内容大概是：

yaml复制model_list:
  - model_name: qwen-plus
    litellm_params:
      model: openai/qwen-plus
      api_base: https://dashscope.aliyuncs.com/compatible-mode/v1
      api_key: os.environ/DASHSCOPE_API_KEY
  - model_name: claude-sonnet
    litellm_params:
      model: anthropic/claude-sonnet-4
      api_key: os.environ/ANTHROPIC_API_KEY

litellm_settings:
  drop_params: true
  num_retries: 2
  request_timeout: 120

这里要解释三个关键点。第一，model_name 是你在 OpenClaw 里填的模型名，你可以随便起别名，比如把某家模型叫成 my-main-model，OpenClaw 只认这个别名，不关心底层到底是哪家的模型。第二，litellm_params 里的 model 字段是 LiteLLM 看到的标准模型路径，OpenAI 兼容的供应商一般写成 openai/模型名，Anthropic 的模型写成 anthropic/模型名，LiteLLM 会自动识别协议。第三，api_key 可以直接写成环境变量引用，这样密钥不会裸露在文件里，我用 os.environ/DASHSCOPE_API_KEY 这种方式，安全很多。

启动命令：

bash复制docker run -d --name litellm \
  -v $(pwd)/config.yaml:/app/config.yaml \
  -p 4000:4000 \
  -e DASHSCOPE_API_KEY=你的密钥 \
  ghcr.io/berriai/litellm:main-stable \
  --config /app/config.yaml --port 4000

启动之后先验证一下网关本身是否健康：

bash复制curl http://localhost:4000/health

如果返回一个 JSON 且有 ok 字样，说明网关起来了。再用一个最简单的请求测试路由：

bash复制curl http://localhost:4000/v1/chat/completions \
  -H "Authorization: Bearer sk-临时主key" \
  -H "Content-Type: application/json" \
  -d '{"model":"qwen-plus","messages":[{"role":"user","content":"你好"}]}'

这一步非常关键，因为它能把问题边界框死。如果 curl 直接报错，那说明 LiteLLM 配置有问题，跟 OpenClaw 没关系；如果 curl 返回了正常回复，说明网关和模型都没问题，后面 OpenClaw 接不上，就是 OpenClaw 侧的连接问题。我每次排查都会先做这一步，省掉无数瞎猜的时间。

3.3 OpenClaw 侧配置 base_url 与虚拟 Key

OpenClaw 那边要改的就是刚才 config 文件里的 llm 段。把 base_url 指向 LiteLLM 的地址，api_key 用一把专门给 OpenClaw 的虚拟 Key，而不是主 Key。

虚拟 Key 可以通过 LiteLLM 的 UI 面板生成，也可以直接调接口：

bash复制curl http://localhost:4000/key/generate \
  -H "Authorization: Bearer sk-主key" \
  -d '{"models":["qwen-plus"],"max_budget":5}' \
  -H "Content-Type: application/json"

返回的 JSON 里有个 key 字段，那才是你填进 OpenClaw 的 Key。给虚拟 Key 设置 5 美元的预算，意思就是当这把 Key 的 token 消耗到 5 美元，网关自动拒绝，防止某个失控的循环任务把你的预算烧穿。这种保护机制在直连模型时根本不存在，所以我才一直强调网关的价值。

填好之后，在 OpenClaw 配置里确认这几个值：

yaml复制llm:
  provider: openai
  base_url: http://host.docker.internal:4000/v1
  api_key: sk-xxxxxxxx
  model: qwen-plus

这里有个细节容易搞错：base_url 要不要带 /v1？要看 LiteLLM 的接口设计。LiteLLM 自己是同时兼容 /chat/completions 和 /v1/chat/completions 的，但 OpenClaw 发请求时会在 base_url 后面拼接路径，如果你填了 http://host.docker.internal:4000，它拼成 /chat/completions；如果你填了 .../v1，它拼成 /v1/chat/completions。两种通常都能通，但我建议统一填带 /v1 的格式，因为 OpenAI 兼容生态里大家默认 /v1，后续换别的工具不会出岔子。

改完配置重启 OpenClaw，然后去日志里看模型调用是否成功。这一步如果通了，你就已经完成了一大半：OpenClaw 能跟模型说上话了。

3.4 多模型路由的进阶玩法

LiteLLM 的模型列表可以放很多模型，OpenClaw 侧只要把 model 字段切到对应的别名，就能马上换模型。比如你白天用 qwen-plus 跑日常任务，晚上跑复杂推理的时候切到 claude-sonnet，不需要改代码，改一个配置值就行。

更有意思的是你可以给 OpenClaw 配一个“模型链”。LiteLLM 支持在请求失败时自动切换到备用模型，这个配置放在 config.yaml 里：

yaml复制model_list:
  - model_name: qwen-plus
    litellm_params:
      model: openai/qwen-plus
      api_base: https://dashscope.aliyuncs.com/compatible-mode/v1
      api_key: os.environ/DASHSCOPE_API_KEY
    model_info:
      mode: completion
router_settings:
  strategy: simple-shuffle
  fallbacks:
    qwen-plus:
      - claude-sonnet

这段配置的意思是，qwen-plus 如果连续失败，自动降级到 claude-sonnet。网关挂了或者限流的时候，OpenClaw 的用户无感，最多就是回复慢一点。这种容灾能力单靠几个 provider 地址是做不到的。

关于接 Azure OpenAI、AWS Bedrock 这类后端，LiteLLM 也都支持，同样是改 litellm_params 里的认证参数。但这类接入通常要过云厂商的账号体系，配置项多而且容易踩区域和权限的坑，我建议你先把本地 OpenAI 兼容的模型链路跑通，再碰云厂商的接入，这样万一报错，你至少知道问题在云厂商侧而不是在网关侧。

4. 把 Discord 接到 OpenClaw

4.1 在 Discord Developer Portal 创建 Bot

Discord 接入的第一步不是写代码，而是先去 Discord Developer Portal 申请一个 Bot。登录之后点 New Application，起个名字，左边菜单进入 Bot 页面，点 Reset Token 拿到 Bot Token，这个 Token 要立刻复制保存好，因为 Discord 只显示一次，丢了只能重置。

很多人卡在 Bot 建好了但收不到消息，十有八九是没开消息内容权限。Discord 的 Bot 要读取用户在聊天框里发的文字，必须在 Bot 页面把 MESSAGE CONTENT INTENT 这个开关打开。这个开关默认是关的，开了之后 Bot 才能通过 Gateway 事件拿到消息正文，否则它只能知道“有人在某频道发了消息”，却不知道具体内容，OpenClaw 自然无从回复。

权限方面，OpenClaw 的机器人需要在服务器里拥有这些权限：发送消息、读取消息历史、创建公开帖子。在 OAuth2 的 URL Generator 里勾选 bot 这个 scope，然后在 Bot Permissions 里勾选 Send Messages、Read Message History、Create Public Threads。生成邀请链接，把 Bot 拉进你的服务器。

4.2 OpenClaw 的 channel 匹配机制

拿到 Bot Token 之后，在 OpenClaw 的配置里加一段：

yaml复制channels:
  discord:
    enabled: true
    bot_token: 你的BotToken
    allowed_channels:
      - 频道ID1
      - 频道ID2
    allowed_users:
      - 用户ID1

allowed_channels 是白名单机制，OpenClaw 收到 Discord 消息后，会先判断这条消息来自哪个频道，如果频道 ID 不在白名单里，直接忽略，不入会话、不调模型。这个设计挺重要，因为 Discord 服务器里通常还有别人，你不想让一个无关的人对着你的 Bot 随便使唤你的模型额度。

如果要开启私聊支持，可以把 allowed_users 也配一下，这样用户私信 Bot 时 OpenClaw 只响应名单里的人。频道 ID 的获取方式是：在 Discord 里打开你要绑定的频道，右键频道名，复制频道 ID。如果没出现复制选项，需要在用户设置里打开开发者模式。

4.3 验证收消息、回消息和触发方式

配置完后重启 OpenClaw，去 Discord 对应的白名单频道里发一句 “ping”，正常情况下 Bot 会回复。这里有个细节，OpenClaw 不是每条消息都会触发 Agent 回复的，它有自己的触发规则。比如频道模式下，有的版本要求消息必须以 @Bot 开头，或者需要回复 Bot 的上一条消息，否则它不会行动。这个规则通常在配置里叫 trigger_mode 或 directive，可以设置成 always 或者 mention。

我的建议是频道里用 mention 模式，私信里用 always 模式，这样在公共频道里 Bot 不会被无意义的群聊刷屏带起来，私信里又足够灵敏。等你在 Discord 里真正收到 Bot 的回复时，整个链路已经全部打通：Discord 发消息、OpenClaw 接会话、LiteLLM 转发模型、模型回复、OpenClaw 发回 Discord。

这里顺带提一句，OpenClaw 不只支持 Discord，Teams、飞书这些入口在适配器层是类似的思路，只是配置不同的 channel 参数和凭据。我见过有人同时在 Discord 和飞书挂同一个 Agent，两个入口共享一套会话数据，用户在哪个平台都能找它干活。

5. 实战中踩过的坑和排查速查

5.1 session file locked：最典型的锁文件问题

这个报错如果你跑过 OpenClaw，大概率见过：

text复制agent failed before reply: session file locked (timeout 60000ms)

我第一次看到这个报错的时候，第一反应是配置写错了，于是我反反复复查模型地址、查 Token，最后发现完全是另一回事。这个报错的本质是：同一个会话文件被进程锁住了，OpenClaw 等在等锁释放，等了 60 秒没等到，直接放弃。

什么情况下会锁住？最常见的是你同时起了两个 OpenClaw 进程。比如你在宿主机上手动执行了一次启动命令，然后又通过 Docker Compose 拉了一个容器，两个进程同时读写同一个 sessions 目录里的同一个 session 文件，操作系统层面的文件锁互相不买账，后到的那个就一直等不到锁。

解决方法也很直接：先用 ps aux | grep openclaw 查一遍，把所有相关进程停掉，只保留一个实例。然后看一下 sessions 目录里有没有残留的 .lock 文件，有就删掉。这种情况一般发生在暴力 kill 进程、容器强制停止的时候，锁文件没有被正常清理，重启后又读到了那个老的锁。

还有一种隐蔽情况，你在同一个 OpenClaw 实例里同时收到了 Discord 同一频道的多条消息，而它们被路由到同一个 session。如果多条消息几乎同时进来，后一条会等前一条完成会话处理，正常等待没关系，但如果前一条因为模型超时或者回复太长卡住了，后面就会一路叠加延迟，最终触发 60 秒锁超时。解决思路是调整配置里的并发模型，把 concurrency 打开，或者给会话加一个 per-user 的串行队列，避免同一个 session 被多线程同时写。

5.2 模型请求超时和 401/404 排查

当你发现 OpenClaw 能收到 Discord 消息，但始终不回复，或者回复“模型连接失败”，先别急着改代码，按照我前面说的办法分三步排查。

第一步，直接 curl 一下 LiteLLM 网关，看网关本身是否正常。如果 curl 也报错，说明问题在网关到模型这一段。常见的是模型别名没有匹配：你在 OpenClaw 里填了 qwen-plus，但 LiteLLM config.yaml 的 model_list 里只定义了别的名字，网关会返回类似 model not found 的 404。这时候去对齐两个名字即可。

第二步，如果是 401，说明 Key 不对。LiteLLM 的主 Key 和虚拟 Key 不能混用，OpenClaw 用的应该是虚拟 Key。如果你把主 Key 填进 OpenClaw，有时候也能通，但一旦你在网关侧设置了主 Key 只允许特定路径的请求，就会开始报权限错误。

第三步，如果是超时，大概率是模型供应商响应太慢，而网关或 OpenClaw 的 timeout 设置太短。我在 config.yaml 里专门加了 request_timeout: 120，并且在 OpenClaw 侧把模型调用的超时时间同步调大。另外，LiteLLM 收到上游错误后会重试，默认 2 次，如果你不想让用户等太久，可以设置为 1 次，或者关掉重试直接报错。

5.3 Discord 端收不到消息、回复被截断

Bot 拉进服务器了，配置也都对了，但 Bot 就是不理人，这种情况我见过好几次，原因一般只有一个：消息内容权限没开。注意，Discord 的 MESSAGE CONTENT INTENT 是在 Developer Portal 的 Bot 页面打开，不是在服务器设置里打开，很多人找错地方。

另一个容易踩的坑是：你启用了 Bot 之后，Discord 要求 Bot 必须能在 3 秒内响应一个事件，否则会认为它失联。OpenClaw 走的是 Agent 会话，经常需要调用模型，几秒钟内根本回复不完，这种情况下要用“先回应再处理”的模式：Bot 收到消息后，先在 Discord 里回一句“正在处理”，再实际去调模型。OpenClaw 一般默认处理好了这个时序，但如果你自己改过事件处理逻辑，别忘了这一点。

至于回复被截断，这里要说明白：Discord 单条消息有 2000 字符上限，OpenClaw 默认会把超长的回复切成多段发送，但也有的版本默认不切，导致 Bot 发送消息时被 Discord 拒绝，表现为“发到一半没了”或者“提示失败”。解决办法是在 OpenClaw 配置里把输出分段打开。飞书平台上也有类似的问题，飞书 Bot 对单条消息长度限制更苛刻，你必须开启分段输出或者控制 max_tokens 上限，避免生成大段长文直接卡在渠道限制上。

如果你希望长文不打断阅读，还可以让 OpenClaw 在 Discord 里开一个 Thread 把长回复发进去，这样整个回复作为一条独立线程展示，不会被其他消息插在中间。配置里加一个 thread_reply: true 之类的开关就可以，具体名字看版本。

5.4 并发冲击下的网关稳定性

一旦你这个 Agent 真的被多人用起来，网关这一层就成了最需要关注的地方。LiteLLM 单实例默认其实扛不了太高的并发，但它可以横向扩容。做法是同一个 config.yaml 启动多个 LiteLLM 容器，前面用 Nginx 做一个简单的负载均衡轮询，OpenClaw 的 base_url 指向 Nginx 的地址而非某个具体的 LiteLLM 容器。

nginx复制upstream litellm_backend {
    server 127.0.0.1:4001;
    server 127.0.0.1:4002;
    server 127.0.0.1:4003;
}

server {
    listen 4000;
    location / {
        proxy_pass http://litellm_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

这样三个实例分担请求，单点故障也不会让整个 Agent 断线。跟 oneapi 这类网关工具对比，LiteLLM 的优势在于虚拟 Key、预算管理和 OpenAI 兼容度；如果你已经有一套 oneapi 在管理供应商，也可以让 OpenClaw 直接对接它，因为 oneapi 同样暴露 OpenAI 兼容接口，底层逻辑是一样的。

并发还有一个隐藏瓶颈在会话锁这里。流量上来之后，不同频道的用户其实是不同 session，互相不抢锁，但同一频道的多条消息会被排在同一个 session 后面。如果真的想把并发做高，建议把会话划分细一点，比如按 Discord 子线程拆分成独立 session，这样并行度会高很多。

写在最后的实操体会

这套组合我实际用了两周之后，最大的感受是稳定性的瓶颈通常不在模型本身，而在中间链路的小细节。比如 session file locked 这种问题，如果没有经验，你可能翻遍模型文档也找不到答案，而当你明白它只是文件锁冲突之后，五分钟就能解决。另一个体会是，网关层的价值是在你遇到问题之后才真正体会到的——没有 LiteLLM 的时候，出了错我只能看 OpenClaw 转发的原始报错，模糊且难定位；有了网关之后，我可以直接 curl 网关接口，把“模型的问题”和“框架的问题”干净地分开，排查效率完全不一样。

最后分享一个小技巧：不管装什么服务，第一次配置都先把日志打到前台看着跑，别急着后台化。OpenClaw、LiteLLM 的日志会把每一次模型请求的耗时、状态码、错误信息都打出来，这些是排错的第一现场。等你看到日志里连续出现正常响应，再改成后台运行也不迟。这套东西后续还能扩展出一个很实用的方向——配合飞书或者 Teams 搭建团队内部的公共助手入口，模型调度的思路完全不用改，加一个 channel 适配器就能用。