指南/Bedrock 转发证据
号称 Amazon Bedrock 转发，哪些证据能支持
中转站把某个分组标成「Amazon Bedrock」，客户端却通常只看到统一的 OpenAI 或 Claude 风格响应。要核对这项说法，先要知道 Bedrock 本身就不止一种推理入口：AWS 原生 Runtime、统一消息接口 Converse，以及同时提供 OpenAI 和 Anthropic 兼容路径的 Mantle，字段不同，日志覆盖也不同。
Bedrock 不是一套固定响应格式
「走 Bedrock」可能指不同入口。AWS 当前提供 bedrock-runtime 与 bedrock-mantle 两类推理端点；模型是否支持某个端点和 API，还要按模型查看。AWS 的模型可用性与兼容性说明把端点、API 与区域列为三个独立维度。
因此，响应看起来像 OpenAI，不能直接排除 Bedrock；响应带有 AWS 原生字段，也不能直接确认请求来自 Bedrock。中转站可以在两端之间转换 JSON，最终外形取决于它暴露给用户的协议。
Bedrock 只回答推理渠道这一层。底层模型、Claude Code 或 Kiro 等产品环境，以及承担费用的资源来源仍需分别核对，四层关系见卖的是 Claude Code，为什么回答自己在 Kiro 或 Copilot。
bedrock-runtime 下还有两种调用方式
InvokeModel 是 AWS 原生的通用推理操作。请求路径包含 modelId，请求体则取决于目标模型供应商及模型版本。AWS 的 InvokeModel 文档要求调用方按对应模型的原生推理参数构造正文。换模型时，正文 schema 可能一起变化。
Converse 和 ConverseStream 在同一个 bedrock-runtime 端点上提供统一消息接口。按照 Converse API 参考，通用请求字段包括 messages、system、inferenceConfig 与 toolConfig；模型特有参数进入 additionalModelRequestFields。响应统一提供 output、stopReason、usage 与 metrics，需要的模型专属返回项可通过 additionalModelResponseFieldPaths 请求。
这套统一 schema 是 Bedrock 的协议，不是底层模型供应商的原始响应。看到 stopReason 或 usage.outputTokens，最多能说明外层遵循 Converse 风格；代理完全可以生成同样的字段。反过来，中转站把 Converse 结果改写成 choices 或 Claude Messages 后，客户端也看不到这些痕迹。
bedrock-mantle 同时提供兼容接口
AWS 的 Inference using Responses API说明，bedrock-mantle.<region>.api.aws/v1 提供 OpenAI Responses API，可用 OpenAI SDK 调用，并支持流式、后台处理与保存的多轮状态。它与 bedrock-runtime 使用不同端点，也受不同配额约束。
Mantle 还提供 Anthropic Messages 兼容路径。AWS 的 Inference using Anthropic Messages API列出 /anthropic/v1/messages，使用 Claude 风格的 model、max_tokens、messages 与 anthropic-version。因此，客户端看到 Claude Messages 外形也不能排除 Bedrock Mantle。
这解释了一个常见误区：收到 Responses 风格事件、response 对象或 Bearer 认证外形，不足以判定上游一定是 OpenAI。Bedrock Mantle 本来就有这套兼容表面。判断接口兼容范围，应按“兼容 OpenAI API”到底兼容到哪一层逐项看，而不是根据一个字段猜服务来源。
bedrock-runtime 与 bedrock-mantle 的观测系统也不能混用。AWS 的模型调用日志说明明确写明，CloudWatch Logs 或 S3 的 model invocation logging 目前只捕获 Runtime 的 Converse、ConverseStream、InvokeModel 与流式 InvokeModel，不捕获 Mantle Responses 调用。Mantle 另有自己的 CloudWatch 指标与 CloudTrail 文档。
协议一致性只能算外层线索
公开响应中可观察到的材料包括：字段层级、流式事件名称、终止原因、usage 分类、HTTP 错误对象、响应头与请求 ID。若多项长期符合某个 AWS 接口的公开定义，可以支持「该服务表现出 Bedrock 协议一致性」。
但它不能单独支持「请求进入了某个 AWS 账户」。代理可以规范化错误，把供应商原生终止原因映射成 AWS 名称，也可以删除或伪造请求 ID 与响应头。模型名同样可以由网关自行填写。错误排查时应保留原始状态码、响应头和请求 ID，边界见 AI API 错误排查手册；这些材料用于关联记录，不是渠道身份证。
传输元数据的价值取决于能否在服务方系统中交叉查询。一个只在客户端出现、无法由 AWS 账户持有人定位的 AWS 风格 ID，证据强度有限。若同一请求 ID 能关联到自有账户的 CloudTrail、调用日志或支持工单，证明力才明显提高。
区域与模型 ID 也不是单值答案
Converse 的 modelId 不只接受基础模型 ID。AWS 文档列出的资源还包括推理配置文件、Provisioned Throughput、Marketplace 端点、定制模型部署和 Prompt Management 资源。调用方看到一个带供应商前缀的模型 ID，不能据此还原完整资源类型。
区域也可能被过度解读。使用区域内基础模型时，请求由选定 Region 处理；使用跨区域 inference profile 时，源 Region 可以把请求路由到配置允许的目标 Region。AWS 的跨区域推理说明区分地理范围配置与全球配置，支持区域页面还说明全球配置的目标 Region 列表可能随 AWS 扩展而变化。
因此，端点域名里的 Region 主要说明请求入口或源 Region。没有 inference profile 和账户配置，不能仅凭它断言模型算力所在的最终 Region，更不能延伸到数据驻留结论。
账户侧记录更接近来源证据
如果 Bedrock 账户由核验方控制，证据会强很多。Runtime 的 model invocation logging 可以在同一账户与 Region 的 CloudWatch Logs 或 S3 中记录 operation、modelId、requestId、调用身份、请求与响应元数据；该功能默认关闭，未找到记录前要先确认当时是否启用、是否查看了正确 Region。
CloudTrail 集成说明记录 Bedrock API 操作及调用身份；CloudWatch 的 AWS/Bedrock Runtime 指标可观察调用量、延迟、Token 与错误。Mantle 则发布到 AWS/BedrockMantle namespace。这些记录来自账户控制面，比客户端可复制的 JSON 字段更难由中转页面单独伪造。
账单能证明账户产生了某类 Bedrock 用量，却不天然对应到某个终端用户请求。AWS 的成本追踪指南说明，Cost Explorer 与 CUR 2.0 提供聚合成本维度；要把费用关联到用户、项目或请求，还需 IAM 身份、资源标签、项目或调用日志中的元数据设计。只有一张总账截图，无法证明其中某笔费用就是被核验的请求。
把结论按证据强度写清楚
| 材料 | 可以支持 | 仍不能证明 |
|---|---|---|
| AWS 风格字段、错误或模型名 | 外层协议与某类 Bedrock API 相似 | 请求进入 AWS 或指定账户 |
| 多次响应结构与官方 schema 一致 | 协议一致性具有连续性 | 代理没有规范化或伪造字段 |
| 可由账户日志关联的请求 ID | 对应调用进入该 AWS 账户与操作 | 中转站所有请求都走相同渠道 |
| 同期 CloudTrail、调用日志与指标 | 账户、身份、操作和用量可相互核对 | 客户端请求未被中间层改写 |
| 可分配到项目或身份的 CUR 成本 | 对应 AWS 用量产生了费用 | 单凭费用还原完整传输内容 |
单参数、单错误、单次延迟或一个模型 ID 都不应被写成 Bedrock 渠道证明。公开材料不足时，结论停在「与某接口一致」；拿到可关联的账户日志和账单后，才能进一步说「该请求进入了对应 AWS 账户」。渠道还会随时间变化，长期判断应同时查看变化记录应该怎么看和中转站渠道类型。
LinkyMonitor 保存模型标识、错误语义、响应结构与时间变化，便于在渠道切换或协议改写后回到原始证据核对。