OpenClaw 装好了、渠道也通了结果卡在模型接入上。llm-deepseek: no api key for provider route deepseek-official这种报错我估计不少人都见过。换一个环境就要重新配一次 API Key配置里藏 Key、日志里打印 Key、不小心把.env提交进仓库又是一场事故。所以我这次干脆把 OpenClaw 的模型后端整套搬到 AWS Bedrock 上用 IAM 角色的临时凭证替代所有静态密钥再把服务部署到 Lightsail通过一段启动脚本完成一键安装。整条链路跑下来应用侧不出现一把云厂商的 Key。这篇文章会把原理、部署步骤和踩坑记录都捋清楚适合手里有 AWS 账号、不想再维护一堆 API Key、又希望自己在云上稳定跑 OpenClaw 的朋友。1. 先搞明白OpenClaw 卡在模型接入卡的其实是什么1.1 OpenClaw 本身不负责模型它只负责路由 编排OpenClaw 这类开源智能体平台的定位不是又一个聊天前端它更像一个消息网关 任务编排器你通过飞书、Telegram、网页等渠道跟它说话它负责理解你的意图、决定调用什么工具、最后把结果返回给渠道。这中间最关键的一环就是它必须知道自己该去哪个大模型拿结果。模型接入这一步说白了就两件事第一选哪个模型第二怎么证明你有权限调用这个模型。OpenClaw 的模型路由设计得比较灵活你可以同时配置多个厂商、多个模型然后给不同渠道指定不同的默认模型。灵活性上来了配置复杂度也跟着上来了——一旦某个 provider 没有配好对应的 Key它不会在启动时拦住你而是等你真正发消息时才报错no api key for provider route deepseek-official。这类报错特别有迷惑性。很多人一看deepseek就以为要去 DeepSeek 官方申请一个 Key实际上可能只是你的模型路由配置里同时挂着多个 providerOpenClaw 在路由时默认要求每个 provider 都能被解析某个没配 Key 的 provider 就成了拦路虎。所以我在第一次部署时就决定收敛模型路由让 OpenClaw 只指向一个统一的模型入口这个入口背后由我自己控制而不是让 OpenClaw 直接面对一大堆厂商的 Key。1.2 大量 API Key 的真实痛点不是多记几个密码这么简单如果你只是在自己电脑上试一下配一把 Key 确实没什么。但只要你把这套东西部署到云上或者打算长期跑API Key 的数量和分发问题会迅速变成一个管理灾难模型厂商越来越多每个渠道、每个模型都可能要独立的 Key不同环境本机、测试服务器、生产服务器要用不同 Key否则没法追踪和隔离Key 轮换是硬需求但你根本不知道哪些地方引用了旧 Key日志、报错信息、第三方组件都可能在不知不觉中把 Key 打出来一旦进了 Git 历史清理成本极高。我在之前一个项目里就遇到过某个子模块把 Key 写死在配置里一个月后仓库权限调整Key 被外部扫描到然后云厂商账单里出现了一堆陌生地区的调用记录。从那以后我对静态密钥散落各处这件事特别敏感。所以当我开始部署 OpenClaw 时第一个要求就是架构里不要出现任何长期静态凭证。AWS Bedrock IAM 角色这套组合正好能解决这个问题。1.3 为什么是 Bedrock而不是继续买第三方模型的 Key选择 Bedrock 有几个很实际的理由。首先它直接托管了 Claude 这类模型你不用分别跟 Anthropic、DeepSeek、千问等厂商一个个申请 Key只需在 AWS 一个账号里开通模型访问权限就能按量调用多个模型。其次AWS 的 IAM 体系本身就能做到不留 Key 跑服务把某个 IAM 角色挂到云服务器上服务器上的程序运行时自动向元数据服务申请临时凭证这个凭证有有效期、会自动轮换而且权限可以收敛到只允许调用 Bedrock 的某个模型。这不只是少记一个密码的问题。使用长期 Key 时程序需要知道用户名 密码使用 IAM 角色时程序只知道自己跑在某个受信任的云环境里凭证是环境发的应用层根本看不见。对我来说这才是真正的零密钥。2. IAM 零密钥方案把静态 Key 从架构里彻底拿掉2.1 长期凭证和临时凭证的区别长期凭证就是 Access KeyAK/SK它的特点是在手动吊销之前一直有效泄露了就是长期风险。你可以把它理解成家里的备用钥匙——放了一把在外面只要没换锁它永远能开你家门。IAM 角色的临时凭证更像是酒店房卡。服务器启动时通过实例元数据服务自动获取一张房卡上面写明了有效期默认几小时和权限范围谁允许调用 Bedrock、不允许调用其他服务。房卡到期后SDK 会自动续领新的整个过程对应用透明。就算某张房卡被日志打出来了它也有有效期而且权限是受限的影响面远小于静态 Key。下面这个表可以直观对比一下对比维度传统 API Key / Access KeyIAM 角色临时凭证有效期长期有效手动吊销几小时后自动过期自动轮换存储位置配置、环境变量、代码里实例元数据服务应用不用管泄露影响长期可用风险大临时凭证影响时间窗有限权限控制一般是一个账号一把 Key可按最小权限策略收敛适合场景本地调试、外部客户端云上服务器、容器、CI/CD2.2 整体链路OpenClaw、LiteLLM、Bedrock 怎么协作这次我采用的架构是三层OpenClaw 在最前面中间加一个 LiteLLM 网关最后指向 Bedrock。LiteLLM 是一个开源的大模型网关它能把 Bedrock、OpenAI、Anthropic 等一堆后端封装成统一的 OpenAI 兼容接口。OpenClaw 只需要配置一个普通的 HTTP endpoint完全不用关心后端是哪家。好处是以后想换模型厂商只要改 LiteLLM 的配置OpenClaw 侧一行都不用动。完整调用链是这样的OpenClaw 收到飞书消息按配置把请求发到http://litellm:4000/v1LiteLLM 收到请求后根据模型名去调用 BedrockLiteLLM 运行时自动从实例元数据服务获取 IAM 角色临时凭证Bedrock 验证凭证调用 Claude 模型返回结果。全程没有任何一个环节需要 OpenClaw 保存 API Key。LiteLLM 这个网关本身也可以不开鉴权或只开一个本地 token因为它只绑定在本机内网不暴露到公网。2.3 IAM 策略最小化只给 Bedrock 调用权限IAM 角色肯定不能给管理员权限按最小权限原则来。我建议的策略只需要两条 actionbedrock:InvokeModel和bedrock:InvokeModelWithResponseStream后者对流式响应很关键别漏了。策略参考如下{ Version: 2012-10-17, Statement: [ { Sid: AllowBedrockClaudeInvocation, Effect: Allow, Action: [ bedrock:InvokeModel, bedrock:InvokeModelWithResponseStream ], Resource: [ arn:aws:bedrock:us-east-1:123456789012:model/anthropic.claude-sonnet-4-0 ] } ] }Resource 里的账号 ID 和模型 ID 按你自己的实际情况替换。如果后续想用多个模型就把模型 ARN 列全。尽量避免直接写成Resource: *虽说临时期限有保护但权限面还是越窄越好。这里有个前置动作要提醒Bedrock 对模型的访问不是开了账号就默认可用你需要先去 Bedrock 控制台的 Model access 页面勾选你要用的 Claude 模型并等待开通。新账号这一步经常被忽略导致后面调用时报AccessDeniedException排查半天才发现模型本身没开通。3. Lightsail 部署实操实例创建、角色挂载、一键脚本3.1 为什么选 Lightsail 而不是 EC2Lightsail 是 AWS 的轻量级云服务器方案优势是定价足够透明一个月固定费用套餐里包含固定 CPU、内存、流量配额。对于 OpenClaw 这种个人或小团队级别的智能体服务性能不追求极致Lightsail 的性价比和易用性都比 EC2 好不少。EC2 的好处是配置更灵活、可扩展性更强但如果你只是要一台稳定跑服务的 Ubuntu 机器没必要一开始就上 EC2。选择区域时要注意必须选 Bedrock 可用的区域比如 us-east-1弗吉尼亚北部。不同区域能用哪些模型不一样而且模型开通状态不通用。3.2 创建实例并挂载 IAM 角色操作流程我记得很清楚因为这几步最容易乱在 Lightsail 控制台点 Create instance选择 Linux/Unix 平台镜像选 Ubuntu 24.04 LTS实例套餐我选的是 4GB 内存档。OpenClaw 本身不算吃资源但 Node.js 进程加上 LiteLLM、再算上 Docker 容器2GB 会有点紧在实例创建页面里找到 IAM permissions 或类似入口选一个已经建好的角色。如果你之前没建建议先去 IAM 控制台创建角色信任实体类型选 AWS Service - EC2因为 Lightsail 的实例角色底层复用的就是 EC2 那套机制。把角色挂到实例上之后不用重启实例也会很快生效但不放心的话可以重启一次。角色附加完成后SSH 登录实例直接跑一下aws sts get-caller-identity如果能正常返回 Account、Arn 和 UserId说明临时凭证已经通了这是整套零密钥方案能不能成立的第一步验证。3.3 启动脚本Docker OpenClaw LiteLLM 一次装好Lightsail 支持在创建实例时传入用户数据脚本也就是 launch script。我是把这些安装步骤写进脚本里的这样实例第一次启动时就自动把环境拉起来。安装 Docker 最简单的方式是用官方脚本然后写 docker-compose 文件。我的启动脚本大致长这样#!/bin/bash set -e # 安装 Docker curl -fsSL https://get.docker.com | sh systemctl enable --now docker usermod -aG docker ubuntu # 数据目录 mkdir -p /opt/openclaw/data mkdir -p /opt/openclaw/litellm # 写入 LiteLLM 配置后面单独讲 cat /opt/openclaw/litellm/config.yaml EOF model_list: - model_name: bedrock-claude litellm_params: model: bedrock/anthropic.claude-sonnet-4-0 aws_region_name: us-east-1 EOF # 写入 docker-compose.yml cat /opt/openclaw/docker-compose.yml EOF services: litellm: image: ghcr.io/berriai/litellm:main-latest container_name: litellm restart: unless-stopped volumes: - /opt/openclaw/litellm:/app/config environment: - AWS_REGIONus-east-1 - AWS_DEFAULT_REGIONus-east-1 - LITELLM_MASTER_KEYlocal_change_me command: [--config, /app/config/config.yaml] networks: - openclaw-net openclaw: image: ghcr.io/openclaw/openclaw:latest container_name: openclaw restart: unless-stopped depends_on: - litellm environment: - OPENCLAW_CONFIG_DIR/opt/openclaw/data - OPENCLAW_MODEL_BASE_URLhttp://litellm:4000/v1 - OPENCLAW_MODEL_NAMEbedrock-claude - OPENCLAW_MODEL_API_KEYlocal_change_me volumes: - /opt/openclaw/data:/opt/openclaw/data ports: - 80:3000 networks: - openclaw-net networks: openclaw-net: driver: bridge EOF cd /opt/openclaw docker compose up -dOpenClaw 的镜像名和具体环境变量以你安装时官方文档为准不同版本可能会有调整。我这个脚本的核心思想是固定的两个容器都通过同一个 Docker 网络互联LiteLLM 通过 IAM 角色访问 BedrockOpenClaw 通过内网地址访问 LiteLLM。这里再说一下OPENCLAW_MODEL_API_KEYlocal_change_me。这个值不是云厂商的 Key而是 LiteLLM 网关自己要求的一个本地 token我在 LiteLLM 里通过LITELLM_MASTER_KEY设置成同一个值。它只存在于服务器内部的容器间通信不对公网暴露所以不存在泄露到云厂商的风险。如果你完全在内网环境跑也可以把两边的鉴权关掉这个看个人选择。3.4 一键安装完成后的检查清单脚本执行完之后别急着用按这个顺序做一轮检查docker compose ps确认两个容器都是 Up 状态docker logs litellm看有没有报错重点看有没有CredentialsError、AccessDeniedException在容器内手动调用一下 Bedrock确认全链路是通的docker exec -it openclaw bash -c curl http://litellm:4000/v1/models如果能看到模型列表说明 OpenClaw 访问 LiteLLM 没问题LiteLLM 那侧也基本配置正确。4. LiteLLM 网关 OpenClaw 侧模型路由无 Key 调通 Bedrock4.1 LiteLLM 配置文件里最重要的原则不写 AK/SKLiteLLM 连接 Bedrock 有两种方式一种是你手动提供aws_access_key_id和aws_secret_access_key另一种是什么都不写让它从运行环境里自动找凭证。我们当然要选第二种。配置文件就是这么干净model_list: - model_name: bedrock-claude litellm_params: model: bedrock/anthropic.claude-sonnet-4-0 aws_region_name: us-east-1model_name是给 OpenClaw 看的别名litellm_params.model里的bedrock/前缀告诉 LiteLLM 要走 Bedrock 通道后面的anthropic.claude-sonnet-4-0是 Bedrock 控制台里显示的模型 ID。aws_region_name必须和实例所在区域一致。注意配置文件里千万、千万不要手贱把 Access Key 填进去。一旦你手动填了 AK/SKLiteLLM 会优先用静态凭证这样零密钥方案就名存实亡了。我之前有个朋友部署时图省事填了 AK/SK结果三天后静态 Key 脚本泄露整个方案直接破功。4.2 OpenClaw 侧只需要一个 OpenAI 兼容地址OpenClaw 不需要知道 Bedrock 是什么。它只需要知道有一个 OpenAI 兼容的 API 服务地址是http://litellm:4000/v1模型名是bedrock-claude。所以 OpenClaw 侧配置的本质只有一个动作把模型后端指向 LiteLLM。不同渠道、不同 agent 的默认模型全部指向这个别名。千万不要再给某个渠道单独配 DeepSeek、千问之类的独立 provider否则又会绕回多 Key 并存的坑。我这次的经验是模型路由里的 provider 数量越少越好理想情况就是一个。模型切换的需求交给 LiteLLM 去处理OpenClaw 始终只认一个别名。4.3 首次调用验证配置完成之后发一条最简短的测试消息比如让 OpenClaw 回答你好请回复 OK。然后立刻去两条链路分别确认看 LiteLLM 日志docker logs litellm --tail 100正常会看到一次 Bedrock 调用成功记录耗时一般在几百毫秒到几秒看 OpenClaw 日志确认没有模型路由相关的报错。如果 LiteLLM 日志里出现CredentialsError: Unable to locate credentials多半是实例角色没生效。这时不要急着配 AK/SK先回到实例上用aws sts get-caller-identity验证再检查 Docker 容器能否访问实例元数据服务。容器默认网络模式下访问169.254.169.254通常是通的如果你自己创建了自定义网络且禁用了出站就可能在容器内拿不到临时凭证。5. 部署后最容易翻车的五个现场与排查记录5.1llm-deepseek: no api key for provider route deepseek-official这个报错我在开头提过。它出现的典型场景是OpenClaw 的模型路由里同时存在多个 provider或者某个渠道的配置还残留着对 deepseek 路由的引用。OpenClaw 在路由时会尝试解析整个路由表发现 deepseek 这个 provider 没有 Key就直接报错退出。排查链路是这样的检查 OpenClaw 的模型路由配置把所有第三方 provider 的条目删掉只保留bedrock-claude检查各个 channel 的默认模型名确保没有指向 deepseek/qwen 这类已经不用了的模型名重启容器docker compose restart openclaw再发消息验证。这个报错是最容易误导人的因为它让你以为问题在 DeepSeek 那边。实际上你的服务根本不需要 DeepSeek只是路由表里没清理干净而已。5.2agent failed before reply: session file locked (timeout 60000ms)这个报错我踩过一次。表现是 OpenClaw 收到消息后迟迟不回复60 秒后报 session file locked。原因基本是两类。第一类OpenClaw 同时跑了多个实例或进程两个进程同时要写同一个 session 文件加锁互相冲突。比如你既用了 systemd 服务又手动跑了一个进程或者 Docker 容器被重复启动了。第二类上次进程异常退出session 文件的锁没释放成了一个残留锁。排查和解决# 看是否存在多个 openclaw 进程 ps aux | grep openclaw # 看会话目录里的锁文件 ls -la /opt/openclaw/data/sessions/ # 如果确认没有其他进程在跑删除残留锁 find /opt/openclaw/data/sessions/ -name *.lock -delete然后重启容器。如果你用负载均衡暴露了多个 OpenClaw 实例那还要注意会话粘滞问题同一用户的会话必须固定到同一实例上处理否则也会出现锁冲突。5.3 飞书输出容易被截断热词里有OpenClaw 在飞书输出容易被截断这个问题确实存在。飞书自定义机器人对单条消息的长度有限制模型回复一长内容就会被从中间切断体验很差。我的处理思路是分块发送。OpenClaw 或你的渠道适配层拿到完整回复后先按一个阈值拆成多条消息再逐条发到飞书。阈值可以按字数控制也可以按 token 控制我实际用下来 1000 字左右一条比较稳。如果你用了流式输出不要每来一个 token 就转发一次那样既容易触发飞书限流又容易把消息切得乱七八糟。最好是攒满一个分片再发。另外如果模型喜欢输出超长代码块飞书对 Markdown 代码块的渲染也有限制建议在 prompt 里让模型控制输出长度回复太长时主动分点总结。5.4401 Unauthorized: authentication fails, your api key: ****这个报错在零密钥方案里出现时通常不是云厂商 Key 错了而是 LiteLLM 网关的 token 校验出了问题。最常见的情况是OpenClaw 侧的OPENCLAW_MODEL_API_KEY和 LiteLLM 侧的LITELLM_MASTER_KEY不一致或者 LiteLLM 要求必须带 token 而 OpenClaw 没带。排查链路先确认两个环境变量在 docker-compose 里是同一个值用 curl 手动访问 LiteLLM看带不带 token 的差异curl http://localhost:4000/v1/models curl -H Authorization: Bearer local_change_me http://localhost:4000/v1/models如果带 token 能通不带 token 报 401那就是 OpenClaw 侧没传 token检查环境变量引用如果带 token 也报 401检查 LiteLLM 启动时到底加载的是哪个配置文件是不是有多个 config 文件互相覆盖。5.5 WSL2 环境验证失败如果你看完这篇还是想先在 Windows 本机跑一遍热词里的openclaw could not safely verify the wsl2 environment大概率会遇上。OpenClaw 在 Windows 上依赖 WSL2 来做容器或进程隔离但很多本机环境默认 WSL 版本是 1或者内核没更新。快速检查wsl --status wsl --update wsl --set-default-version 2如果是已经装好的发行版是 WSL1需要wsl --set-version 发行版名 2转换。这个和云上部署关系不大但如果是新手上路很容易卡在这一步连安装都过不去。6. 这套零密钥 云托管方案用了一周的体感与边界提醒先说边界。这套方案适合的场景是自托管服务跑在 AWS 云服务器上流量不大不想为密钥管理投入精力。但它不是万能的如果 OpenClaw 要跑在你的 MacBook 上IAM 角色这套就使不上劲了那更适合用 SSO 短期凭证或第三方密钥管理服务另外 Bedrock 不是所有区域都有中国区的账号策略和全球区也不同选型之前先确认好区域开通情况。再说个人体感。用了一周多最明显的改变是日志干净了。以前 OpenClaw 的日志里动不动就把调用的模型 Key 打出来现在我扫了一圈日志看不到任何 credential 信息。中间还经历过一次容器异常重启LiteLLM 起来后自动重新从元数据服务拉临时凭证完全没有人工干预。这一点放在传统 Key 方案里就得检查 Key 是否还有效、有没有过期。成本方面Lightsail 是固定月费Bedrock 按调用量另算。如果你只是自用级别每个月的账单基本可控不会出现模型调用量爆炸导致云账单无法预估的情况。最后再分享一个小技巧这套云上托管模型 实例角色 内部 API 网关的组合不只 OpenClaw 能用。我后来把另一个自托管的翻译服务也接到了同一个 LiteLLM 网关上只改了一行配置就切到了 Bedrock全程没配任何新的 Key。你如果也在维护多个自托管 AI 服务建议把 LiteLLM 当成一个独立的基础设施来跑一次搭好长期受益。