从 Gemini 切到 Claude Opus：我在 OpenClaw + AWS Bedrock 上踩的 3 个坑

花了大半天排查一个配置问题，最后发现核心原因只有一句话就能讲清楚。但这个过程本身，比答案更有价值。

背景

我用 OpenClaw 搭了一个 AI 助手，挂在 Discord 上当日常工具用。之前一直跑的是 Google Gemini 3 Pro，稳得一批。最近想切到 Claude Opus 4.6 试试，选了 AWS Bedrock 做中间层——毕竟公司有现成的 AWS 账号，IAM 权限也配好了，觉得改个 JSON 就完事了。

然后就开始了长达数小时的排错之旅。

坑一：模型 ID 不是你以为的那个模型 ID

改完配置，重启 gateway，Discord bot 直接回复了一句冰冷的：

The provided model identifier is invalid.

我最初配的是：

{
  "id": "anthropic.claude-opus-4-6-v1",
  "name": "claude-opus-4-6"
}

看起来没毛病对吧？这就是 Bedrock 控制台里基础模型（Foundation Model）的 ID。

但 Bedrock 现在不让你直接用基础模型 ID 调用了。 较新的模型必须通过 Inference Profile 调用。这是 AWS 在 2025 年底开始强制推的机制，用来做跨区域路由和流量管理。

用 AWS CLI 一查就明白了：

aws bedrock list-inference-profiles --region us-east-1 | grep -i "opus"

出来的 ID 是 us.anthropic.claude-opus-4-6-v1，注意前面多了个 us. 前缀。

用基础模型 ID 调用，AWS 返回 The provided model identifier is invalid。用 inference profile ID 调用，通了。一个前缀的差距。

这个坑的恶心之处在于：Bedrock 控制台的模型列表页展示的就是基础模型 ID，inference profile 藏在另一个页面。你如果不知道这个机制，会以为自己抄的 ID 是对的。

坑二：OpenClaw 的 name 和 id，你以为改了就行？

改了 id 字段，重启，还是报 invalid。

这时候日志给了一个关键线索：每次请求只用了 2 秒就完成了。Claude Opus 4.6 的正常响应时间怎么着也得 20-40 秒。2 秒，说明根本没有真正调用模型，API 直接返回错误了。

问题出在 OpenClaw 内部。它有两个字段：id 和 name。我改了 id，但 name 还是 claude-opus-4-6。OpenClaw 在某些路径下会用 name 而不是 id 去拼 Bedrock 的 API 请求。

修复方法很暴力：把 name 也改成 inference profile ID，同时把 agents 配置里所有引用这个模型的地方都对齐。

改之前：

"models": [{
  "id": "us.anthropic.claude-opus-4-6-v1",
  "name": "claude-opus-4-6"
}],
"agents": {
  "defaults": {
    "model": { "primary": "bedrock:us-east-1/claude-opus-4-6" }
  }
}

改之后：

"models": [{
  "id": "us.anthropic.claude-opus-4-6-v1",
  "name": "us.anthropic.claude-opus-4-6-v1"
}],
"agents": {
  "defaults": {
    "model": { "primary": "bedrock:us-east-1/us.anthropic.claude-opus-4-6-v1" }
  }
}

改完重启，日志里的请求时间从 2 秒变成了 33 秒。这才是真正在调模型的表现。

坑三：Gemini 的 1M 上下文 vs Claude 的 200K 上下文

模型调通了，webchat 完美运行。但 Discord bot 还是不行，这次报了个新错：

Context overflow: prompt too large for the model.

原因很简单：Gemini 3 Pro 的上下文窗口是 1M tokens，Claude Opus 4.6 只有 200K。

OpenClaw 的 Discord 会话是按 channel 绑定的，同一个 channel 共用一个 session，所有历史消息都在里面累积。之前用 Gemini 的时候，1M 的窗口随便塞。切到 Claude 后，旧会话的历史直接把 200K 撑爆了。

解决方法：删掉旧的会话文件，让 Discord channel 创建一个新的 session。

# 找到会话文件
find ~/.openclaw -name "*.json" -path "*/sessions/*"
# 删掉对应的 Discord 会话
rm <对应的会话文件>
# 重启 gateway
openclaw gateway restart

这个问题本身不复杂，但它暴露了一个容易被忽略的事实：切换模型不只是换个 ID，上下文窗口、token 限制、compaction 策略都要跟着调。Gemini 和 Claude 的上下文差了 5 倍，这不是一个可以无视的差异。

排查过程中的一些经验

1. 看响应时间比看错误日志更有效。

OpenClaw 会把 Bedrock 返回的错误信息当成正常回复发出去，日志里看不到 error。但响应时间会暴露一切：2 秒完成 = API 直接报错返回了；33 秒完成 = 模型真的在思考。

2. 用 AWS CLI 先验证，再改配置。

别在 OpenClaw 的配置上反复试错。先用 aws bedrock-runtime converse 命令确认模型 ID 能通，再回去改 JSON。OpenClaw 中间多了一层抽象，出了问题不知道是 AWS 的锅还是 OpenClaw 的锅。

aws bedrock-runtime converse \
  --model-id "us.anthropic.claude-opus-4-6-v1" \
  --region "us-east-1" \
  --messages '[{"role":"user","content":[{"text":"hi"}]}]'

3. Inference Profile 是 Bedrock 的新常态。

如果你以前用过 Bedrock 的老模型（比如 Claude 3），可能没遇到这个问题，因为老模型还支持直接调用。但从 Opus 4.5 开始，AWS 强制要求走 inference profile。以后配任何 Bedrock 模型，第一步就该 list-inference-profiles。

4. 切模型要做 checklist，不能只改一行。

我整理了一个最小 checklist：

最终可用的配置

给后来人留个参考，这是验证过能跑通的完整 Bedrock 配置片段：

{
  "models": {
    "providers": {
      "bedrock:us-east-1": {
        "baseUrl": "us-east-1",
        "api": "bedrock-converse-stream",
        "auth": "aws-sdk",
        "models": [{
          "id": "us.anthropic.claude-opus-4-6-v1",
          "name": "us.anthropic.claude-opus-4-6-v1",
          "input": ["text", "image"],
          "contextWindow": 200000,
          "maxTokens": 16384
        }]
      }
    }
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "bedrock:us-east-1/us.anthropic.claude-opus-4-6-v1"
      },
      "models": {
        "bedrock:us-east-1/us.anthropic.claude-opus-4-6-v1": {
          "alias": "claude"
        }
      },
      "compaction": {
        "mode": "safeguard"
      }
    }
  }
}

前提条件：

• 本地已配置 AWS CLI（aws configure 或 aws sso login）
• IAM 权限包含 bedrock:InvokeModel 和 bedrock:InvokeModelWithResponseStream
• 你所在的区域已开通 Claude Opus 4.6 的模型访问权限

写在最后

这篇文章的技术含量其实不高。三个坑加起来，核心知识点也就是：inference profile、name/id 对齐、上下文窗口差异。

但我想记录的不是答案本身，而是排查问题的思路。在 AI Agent 这个领域，你面对的不是一个系统，而是一条链路：你的配置 → OpenClaw 的抽象层 → AWS Bedrock 的 API → Claude 模型本身。链路上的每一环都可能出问题，而且错误信息经常被中间层吞掉或者包装成你看不懂的样子。

学会沿着链路一步步验证——先确认 AWS 凭证，再确认模型 ID，再确认 OpenClaw 配置，最后确认会话状态——这个方法论比任何一个具体的修复方案都更有价值。

毕竟 AI Agent 的玩法每天都在变，但排查问题的逻辑是通用的。