在 Cursor 中使用 AWS Bedrock（BYOK）

AWS Bedrock BYOK in Cursor

自带密钥（BYOK）让你把 Cursor 指向一个你已经在付费的模型提供商，而不是使用 Cursor 内置的模型路由。AWS Bedrock 是最常见的选择之一，因为它在你已经掌控的 AWS 账号背后托管 Anthropic Claude 以及其他前沿模型。本指南将介绍什么是 BYOK、为什么特别选择 Bedrock、如何在 Cursor 中配置它、计费与成本控制如何运作，以及如何修复你最可能遇到的错误，包括那个令人困惑的「Invalid signature in thinking block is bound to a different conversation」。

什么是 BYOK，什么时候该用

BYOK 意味着你提供自己的提供商凭据，由提供商直接对你消耗的 token 计费。在 Cursor 中，模型仍然通过 Cursor 的界面和功能运行，但推理请求会发往你的账号，而不是 Cursor 的账号。

你通常会在以下情况下想要使用 BYOK：

你已经有承诺的云支出。 如果你的组织有 AWS 承诺用量或企业折扣，把模型流量通过 Bedrock 路由可以消耗这笔支出，而不是新增一项开支。
合规要求特定的边界。 Bedrock 把数据保留在你的 AWS 账号和区域内，这简化了数据驻留和安全审查。
采购偏好单一供应商。 通过 AWS 采购通常比在合同里新增一个 AI 供应商更容易。

BYOK 并不总是更便宜。对于小团队来说，Cursor 的包含额度和按用量计费可能比 Bedrock 更划算，而且配额管理要由你自己承担。选择 BYOK 是为了控制和合规，而不仅仅是为了价格。

BYOK 是按模型提供商生效的，不是按对话

在 Cursor 中，你可以在 Settings > Models 里启用提供商。一旦启用了 Bedrock 并保存了凭据，你选定的 Bedrock 模型 ID 就会出现在所有选择模型的地方。你不会因此在其他模型上被锁定到 Bedrock。

BYOK vs Cursor 内置路由

在做出决定之前，把这两条路径并排比较会很有帮助。

维度	Cursor 内置模型	使用 Bedrock 的 BYOK
计费	Cursor 向你收费	AWS 直接向你收费
凭据	由 Cursor 管理	你自行提供并轮换 AWS 密钥
配额	由 Cursor 管理	你自行管理各模型的配额
合规	Cursor 的边界	你的 AWS 账号与区域
配置工作量	零	IAM、模型访问、提供商配置
模型列表	由 Cursor 精选	你所在区域暴露的所有模型

如果你是一位追求速度的独立开发者，请继续使用内置路由。如果你所在的组织要求 AWS 账单、区域和 IAM 策略都属于自己，那么 BYOK 就是正确答案。

为什么选择 AWS Bedrock

Bedrock 是一个托管的推理层，本身不是模型。它通过单一的 AWS API 暴露 Anthropic Claude、Amazon Nova、Meta Llama、Mistral 等模型。正是这个单一 API 让它在企业使用场景中具有吸引力。

合规与治理。 请求和数据都留在你的 AWS 账号和区域内，处于你现有的控制和审计日志之下。
已有的 AWS 支出。 模型用量会出现在你的 AWS 账单上，可以由现有的承诺用量覆盖。
数据驻留。 区域由你选择，当法规要求数据留在某个国家时这一点很重要。
企业采购。 在大多数大型组织中，AWS 已经是获批的供应商。

取舍则是其镜像：配额、IAM 配置和故障排查都由你自己负责。

前提条件

在配置 Cursor 之前，请先在 AWS 侧准备好以下内容。

AWS 账号与模型访问

你需要一个启用了计费的 AWS 账号。在 Bedrock 控制台中，模型访问是按模型逐个开启的（opt-in），因此你必须显式申请访问你打算使用的 Anthropic Claude 模型。有些模型会自动授予；另一些则需要一个接受步骤或简短的使用场景表单。

IAM 权限

为 Cursor 创建一个 IAM 用户或角色，并赋予仍然可用的最窄权限。至少，Cursor 需要能够调用模型并列出模型。

IAM 权限	Cursor 为什么需要它
`bedrock:InvokeModel`	向模型发送非流式请求
`bedrock:InvokeModelWithResponseStream`	发送流式请求，聊天界面使用的就是它
`bedrock:ListFoundationModels`	填充模型选择器并验证模型 ID

对于 Bedrock 上的 Claude 模型，你通常还需要把 bedrock:InvokeModel 限定到模型 ARN，或者更简单地限定到该区域的推理配置文件。请把策略保持限定范围，避免附加宽泛的管理员策略。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CursorBedrockInvoke",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-4-5-v1:0",
        "arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.anthropic.claude-sonnet-4-5-v1:0"
      ]
    },
    {
      "Sid": "CursorBedrockList",
      "Effect": "Allow",
      "Action": "bedrock:ListFoundationModels",
      "Resource": "*"
    }
  ]
}

请把这份策略附加到一个专为 Cursor 创建的 IAM 用户或角色上，而不是复用一个已有的管理员身份。如果你的组织使用短期凭据，请采用代入角色（assume a role）并定期刷新会话 token 的方式，而不是创建一个静态密钥。

在配置 Cursor 之前先验证访问权限

先在命令行上证明凭据可用。如果调用在这里就失败，那么在 Cursor 中也会失败，而你已经省下了一次令人困惑的来回排查。

# Confirm the configured identity is the one you expect
aws sts get-caller-identity

# List the models your region exposes
aws bedrock list-foundation-models \
  --region us-east-1 \
  --query "modelSummaries[?contains(modelId, 'anthropic')].[modelId]" \
  --output table

如果列出模型能成功但调用失败，那么问题在于模型访问权限或具体的模型 ID，而不是凭据。

区域选择

选择一个你想要使用的模型可用、且你的数据被允许存放在那里的区域。某些模型通过推理配置文件前缀支持跨区域推理，因此你可能并不受限于单一区域。

在 Cursor 中配置 Bedrock

Cursor 在 Models 设置中暴露 BYOK 提供商。每个提供商的流程形态都是一样的。

打开 Cursor Settings > Models。
找到 AWS Bedrock 提供商并启用它。
输入你的 AWS 访问密钥 ID、秘密访问密钥以及区域。
选择你希望在选择器中可见的模型 ID。
保存并返回一个对话，然后选择一个 Bedrock 模型。

凭据字段

Cursor 需要一份带区域限定的配置。一个 Bedrock 提供商配置块大致长这样：

{
  "provider": "bedrock",
  "aws_access_key_id": "AKIAIOSFODNN7EXAMPLE",
  "aws_secret_access_key": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
  "aws_region": "us-east-1",
  "models": [
    "anthropic.claude-sonnet-4-5-v1:0",
    "anthropic.claude-3-5-haiku-v1:0"
  ]
}

在开发者机器上使用长期有效的 IAM 访问密钥是万不得已的选择。对于团队，请使用临时会话或代入角色，这样密钥就不会以明文形式存储在磁盘上。

模型 ID 与跨区域推理

Bedrock 的模型 ID 遵循可预测的形态：厂商、系列、版本。某些模型需要推理配置文件前缀，它会为了可用性和吞吐量把请求路由到多个区域。

# Direct model IDs (region-scoped)
anthropic.claude-sonnet-4-5-v1:0
anthropic.claude-3-5-haiku-v1:0

# Cross-region inference profile IDs (note the region prefix)
us.anthropic.claude-sonnet-4-5-v1:0
eu.anthropic.claude-sonnet-4-5-v1:0
apac.anthropic.claude-sonnet-4-5-v1:0

如果某个模型即使你已经启用了它仍然返回访问错误，那么几乎总是模型 ID 导致的：请检查它是否需要 us. 或 eu. 前缀以匹配你选择的区域。

访问密钥是敏感信息

不要把访问密钥粘贴到对话、规则文件或共享截图中。请把它们存储在 Cursor 存放提供商凭据的地方，并轮换任何你怀疑已经暴露的密钥。上面的示例密钥是 AWS 公开文档中的占位符，不是真实凭据。

在 Cursor 中验证连接

保存提供商配置之后，请用一个简单的提示词而非真实任务来确认接线是否正确，这样一旦失败就不会有歧义。

打开一个新对话，从模型选择器中选中一个你的 Bedrock 模型 ID。
提一个很小的要求，比如「回复 ready 这个词」。
如果得到了回复，说明凭据、区域和模型 ID 都正确。
如果失败，请重新运行下面的 CLI 调用测试，并把错误文本与 Cursor 显示的内容进行对比。

# Invoke the model directly so you can see the raw error text
aws bedrock-runtime invoke-model \
  --model-id anthropic.claude-sonnet-4-5-v1:0 \
  --region us-east-1 \
  --body '{"anthropic_version":"bedrock-2023-05-31","max_tokens":16,"messages":[{"role":"user","content":"reply with the word ready"}]}' \
  --cli-binary-format raw-in-base64-out \
  /tmp/out.json && cat /tmp/out.json

为你使用的每个模型保留一条可用的 CLI 命令，能把 Cursor 的错误信息从模糊变得可解读，因为你已经知道一次成功的调用长什么样。

计费与成本控制

使用 BYOK 时，AWS 为你消耗的 token 计费，而不是 Cursor。这会改变你做预算和监控的方式。

模型定价

Bedrock 按输入和输出 token 计费，费率取决于模型。输入 token 通常比输出 token 便宜，而长上下文模型每 token 的成本比小模型更高。

模型系列	相对输入成本	相对输出成本	说明
Claude Sonnet 级别	中	中	稳健的通用编程默认选择
Claude Haiku 级别	低	低	快速、便宜，适合小改动
Claude Opus 级别	高	高	推理能力最佳，成本最高
Amazon Nova	低	低	具有成本效益的替代方案

成本分摊与监控

给你的 Bedrock 用量打上标签，使其可归因，并关注指标而不是账单。

# Enable cost allocation tags on the resources that call Bedrock
aws resourcegroupstaggingapi tag-resources \
  --resource-arn-list arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.anthropic.claude-sonnet-4-5-v1:0 \
  --tags Project=cursor-byok Team=platform

在 CloudWatch 中跟踪 Bedrock 的调用指标，并设置一个账单告警，这样失控的智能体就不会在你睡觉时悄悄花掉你整月的预算。

# Quick cost sanity check: list recent Bedrock usage with Cost Explorer
aws ce get-cost-and-usage \
  --time-period Start=2026-10-01,End=2026-10-20 \
  --granularity DAILY \
  --metrics BlendedCost \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Bedrock"]}}'

降低 Token 成本

BYOK 把 token 计量器交到了你手里，因此几个习惯很快就能见效：

选对模型规模。 小改动使用 Haiku 级别的模型，把 Opus 级别的模型留给真正困难的推理。
保持上下文紧凑。 臃肿的上下文窗口是最大的隐性成本；当话题跑偏时就开一个新对话。
批量处理小改动。 几个微小的提示词加起来比一个覆盖同样改动的范围明确提示词更贵。
精简规则。 每一条始终应用的规则都会在每次请求中发送 token，因此请让 .cursor/rules 保持精简。
盯住第一周。 第一周每天查看 Cost Explorer，之后改为每周一次，这样你能在真实基线让你意外之前先了解它。

修复「Invalid signature in thinking block」错误

这是 Cursor 中最令人困惑的 Bedrock 错误，因为它听起来像 API 密钥问题，但几乎总是对话状态问题。完整信息读起来是：

Invalid `signature` in `thinking` block is bound to a different conversation

根本原因

Claude 的扩展思考会产生加密的推理块，它们携带一个绑定到创建它们的那个确切对话和轮次的签名。当这些块被重放到新请求中时，签名的内容不再匹配，提供商就会拒绝整个请求。以下情况会触发它：

来自较早轮次的扩展思考块在较晚的轮次中被重新发送，
代理或网关缓存并重放了请求体，
对话状态过期或重复，例如在对话中途切换模型之后。

修复方法

按顺序逐一处理：

开一个新对话。 签名绑定到对话，因此新开对话是可靠的复位方式。
在你排查期间禁用扩展思考，等流程干净后再重新启用。
更新 Cursor。 思考块的签名处理已在新版本中修复；客户端版本过旧是常见原因。
移除中间代理或网关，它们可能会在 Cursor 与 Bedrock 之间缓存或改写请求体。
降低 temperature 并缩短对话长度，让上下文里累积更少的思考块。

先开新对话，其他方法其次

十有八九，开一个新对话就能立刻解决签名错误。如果它在全新的对话中仍然复现，那就去检查代理和客户端版本。

限流与 resource_exhausted 错误

Bedrock 会施加按账号、按模型的吞吐量配额。当你超出配额时，会得到限流或 resource_exhausted 错误，而不是一次干净的失败。

ResourceNotFoundException / ServiceQuotaExceededException:
You have exceeded the rate of requests allowed for this model.

这是配额问题，不是凭据问题。两种修复方式：

把负载分散到多个模型或区域。 跨区域推理配置文件的存在正是为了汇集容量。
申请提高配额，在 AWS Service Quotas 控制台中针对你正在使用的 Bedrock 模型提交。

# List the Bedrock service quotas you can request increases for
aws service-quotas list-service-quotas \
  --service-code bedrock \
  --query "Quotas[?contains(QuotaName, 'Claude')].[QuotaName,QuotaCode,Value]" \
  --output table

一旦突发流量消退，该错误通常会自行清除，但如果它是长期性的，申请配额就是解决办法。

访问、区域与代理错误

未授予模型访问权限时的 Access Denied

AccessDeniedException: You don't have access to the model with the specified model ID

这里主要有两个原因：

从未在 Bedrock 控制台中授予模型访问权限。 打开控制台并申请访问那个特定的 Anthropic 模型。
IAM 策略过窄，或者模型 ID 写错了。 确认策略授予了 bedrock:InvokeModelWithResponseStream，并且模型 ID 字符串与你实际启用的某个模型一致。

区域错误

如果 Cursor 配置的区域不托管该模型，或者模型 ID 需要跨区域前缀，那么即使密钥有效，请求也会失败。请确认 Cursor 中的区域与你启用模型访问的那个控制台区域一致。

企业代理后面的流式传输失败

聊天默认使用流式传输。企业代理和进行 TLS 检查的防火墙经常会破坏 text/event-stream 响应，表现为聊天卡住或只返回部分回答。

把 Bedrock 的区域端点加入白名单（例如 bedrock-runtime.us-east-1.amazonaws.com）。
确保代理不会缓冲流式响应；请查找「streaming」或「chunked transfer」之类的设置。
如果代理无法避免，请确认 Cursor 是否可以为 Bedrock 主机绕过它。

故障排查快速参考

症状	可能原因	修复
`thinking` 块中 `signature` 无效	思考块跨对话被重放	开一个新对话、禁用扩展思考、更新 Cursor
`resource_exhausted` / 限流	超出按模型配额	分散到多个区域，申请提高配额
`AccessDeniedException`	未授予模型访问权限或策略过窄	在控制台中启用模型，放宽 IAM 策略
某个区域中找不到模型 / 无访问权限	区域错误或缺少推理配置文件前缀	匹配区域，使用 `us.` / `eu.` 前缀
聊天卡住且没有流式输出	代理缓冲 `text/event-stream`	把 Bedrock 端点加入白名单，禁用代理缓冲
模型选择器为空	缺少 `bedrock:ListFoundationModels`	添加该权限，重新保存凭据
密钥轮换后出现认证错误	Cursor 中保存的是过期凭据	在 Models 设置中重新输入访问密钥和秘密密钥
本地能用，CI 中失败	流水线中未传入区域或配置文件	在 CI 环境中设置区域和配置文件

流程稳定之后，请在提供商配置旁边简短记录你的区域、模型 ID 和配额限制。当错误在六个月后出现时，这份记录能把两小时的排查变成两分钟的修复。

什么是 BYOK，什么时候该用​

BYOK vs Cursor 内置路由​

为什么选择 AWS Bedrock​

前提条件​

AWS 账号与模型访问​

IAM 权限​

在配置 Cursor 之前先验证访问权限​

区域选择​

在 Cursor 中配置 Bedrock​

凭据字段​

模型 ID 与跨区域推理​

在 Cursor 中验证连接​

计费与成本控制​

模型定价​

成本分摊与监控​

降低 Token 成本​

修复「Invalid signature in thinking block」错误​

根本原因​

修复方法​

限流与 resource_exhausted 错误​

访问、区域与代理错误​

未授予模型访问权限时的 Access Denied​

区域错误​

企业代理后面的流式传输失败​

故障排查快速参考​