指南/Bedrock 转发证据
号称 Amazon Bedrock 转发，哪些证据能支持
中转站把分组标成「Amazon Bedrock」，客户端看到的却可能是 OpenAI、Anthropic 或 AWS 风格响应。Bedrock 的 bedrock-runtime 和 bedrock-mantle 都提供兼容接口，因此协议外形只能说明请求像哪种 API；要确认某次调用进入 AWS 账户，还得把请求 ID 与账户侧记录关联起来。
先看证据能支持到哪一层
| 材料 | 可以支持 | 还不能支持 |
|---|---|---|
| AWS、OpenAI 或 Anthropic 风格字段 | 外层协议与对应 API 相似 | 请求来自哪家云、进入哪个账户 |
| 多次响应结构与官方定义一致 | 兼容行为具有连续性 | 中间代理没有重写字段 |
| 可在 AWS 账户日志中查到的请求 ID | 该请求进入对应账户和操作 | 同一中转站的其他请求走相同渠道 |
| 同期调用日志、CloudTrail 与指标 | 账户、身份、操作和用量能够交叉核对 | 客户端与 AWS 之间没有改写内容 |
| 能分配到项目或身份的成本记录 | 对应 AWS 资源产生费用 | 单靠费用还原某次请求内容 |
判断 Bedrock 来源时，最有价值的是能跨系统关联的记录。单个字段、模型名、错误对象或一张总账截图都容易被代理生成，也缺少请求级对应关系。
Runtime、Converse 和 Mantle 是三种不同维度
bedrock-runtime 与 bedrock-mantle 是端点；Converse 是 bedrock-runtime 上的调用接口。三者不能放在同一层并列。
| 入口 | 请求与响应特点 | 账户侧观测 |
|---|---|---|
Runtime InvokeModel | 路径包含 modelId，正文按目标模型的原生推理格式组织 | 支持 model invocation logging、CloudTrail 与 AWS/Bedrock 指标 |
Runtime Converse | 用统一的 messages、system、inferenceConfig、toolConfig 等字段调用支持消息的模型 | 同样属于 Runtime，可进入 invocation logging |
| Runtime 兼容接口 | AWS 在 Runtime 上提供 OpenAI Chat Completions 和 Anthropic Messages 格式 | 使用 Runtime 的认证与权限；具体日志覆盖仍按操作核对 |
bedrock-mantle | 提供 OpenAI Responses、Chat Completions 和 Anthropic Messages 路径，支持 API key；部分项目、状态保存和异步能力与 Runtime 不同 | 有独立的 CloudTrail 文档和 AWS/BedrockMantle 指标；不进入 Runtime 的 invocation logging |
AWS 的 InvokeModel API 明确要求请求体遵循目标模型格式；Converse API 则统一消息结构，并把模型专属参数放进 additionalModelRequestFields。看到 stopReason 或 usage.outputTokens，只能说明外层像 Converse。
AWS 的 Responses API 文档使用 Mantle；Chat Completions API和 Anthropic Messages API则可使用 Runtime 或 Mantle。OpenAI 或 Claude 风格响应因此不能排除 Bedrock；AWS 风格响应也可能是中转站自行转换的结果。接口兼容范围应按“兼容 OpenAI API”到底兼容到哪一层逐项核对。
客户端字段只能提供协议线索
公开响应里可以保存字段层级、流式事件、终止原因、Token 分类、状态码、响应头和请求 ID。这些材料适合比较协议是否发生变化，也能帮助服务方查日志。
它们无法独立证明 AWS 来源。代理可以把供应商的终止原因映射成 AWS 名称，统一错误对象，删除或重写响应头，也可以自行填写模型名。一个 AWS 风格请求 ID 如果无法在对应账户中查询，证据强度与普通代理 ID 相近。错误排查时仍应保留原始状态码、响应头与请求 ID，具体边界见 AI API 错误排查手册。
账户日志怎样形成请求级证据
Runtime 的 model invocation logging 可把受支持调用的 operation、modelId、requestId、调用身份和请求/响应元数据写入同账户、同 Region 的 CloudWatch Logs 或 S3。它支持 Converse、ConverseStream、InvokeModel 和流式 InvokeModel，但默认关闭。
未找到调用日志时，要先排除三个条件：调用发生时日志尚未启用、查询了错误的 Region，或请求走的是 Mantle。AWS 明确说明 Mantle 调用不进入这套 invocation logging。
CloudTrail 是另一类记录。Runtime 和 Mantle 都有 CloudTrail 集成，但应按各自文档查询。Runtime 的 InvokeModel、Converse 等操作会记录调用身份、时间、Region 和请求 ID；CloudWatch 指标则提供调用量、延迟、Token 与错误等聚合数据。Runtime 使用 AWS/Bedrock 命名空间，Mantle 使用 AWS/BedrockMantle。
一次较强的核验可以按以下方式关联：
- 客户端记录发送时间、模型声明、自定义关联 ID 与收到的 AWS 请求 ID。
- 账户侧用请求 ID、时间窗口或
requestMetadata查 invocation log 与 CloudTrail。 - 再用同一模型和时间窗口的 CloudWatch 指标、成本记录核对调用量。
这能支持「该请求进入了该 AWS 账户」。若 AWS 账户不由核验方控制，只拿到服务方提供的截图或导出文件，还要保留其来源和导出过程；静态截图本身无法排除剪裁或拼接。
模型 ID、Region 和账单各有边界
Runtime 的 modelId 可以指向基础模型、推理配置文件、Provisioned Throughput、Marketplace 端点、定制模型部署或 Prompt Management 资源。仅凭供应商前缀无法还原实际资源类型。
Region 也只能说明入口的一部分。按照 AWS 的跨区域推理说明，使用 inference profile 时，源 Region 可以把请求路由到配置允许的目标 Region。因此，端点域名不能单独证明模型最终处理位置，也不能直接推出数据驻留结论。
账单证明账户产生了 Bedrock 用量，但 Cost Explorer 和 CUR 主要提供聚合成本。要把成本关联到某个用户或请求，还需要 IAM 身份、项目、标签、requestMetadata 或调用日志。总账金额与客户端账单接近，仍不足以证明某笔费用对应某次请求。
结论应停在证据覆盖的位置
只有客户端材料时，适合写「响应长期符合某类 Bedrock 接口特征」。请求 ID 能在账户侧日志中关联后，可以写「该请求进入对应 AWS 账户」。要判断中转站是否持续使用同一渠道，还需重复关联不同时间的请求，并查看变化记录应该怎么看和中转站渠道类型。
LinkyMonitor 保存模型标识、错误语义、响应结构与时间变化，便于在渠道切换或协议改写后回到原始证据核对。
官方资料
- AWS：InvokeModel API
- AWS：Converse API
- AWS：Responses API on Mantle
- AWS：Chat Completions API on Runtime and Mantle
- AWS：Anthropic Messages API on Runtime and Mantle
- AWS：Model invocation logging
- AWS：CloudTrail logging for
bedrock-runtime - AWS：CloudTrail logging for
bedrock-mantle - AWS：Runtime CloudWatch metrics
- AWS：Mantle CloudWatch metrics
- AWS：Cross-Region inference
- AWS：Track usage and costs