Anthropic Messages 适配层字段表
Doc status已发布Feature status已上线Last updated：2026-09-19
调用 POST /v1/messages 时，平台会先把你的请求解析成内部统一结构，再按实际路由到的上游协议重新构造请求——即使这次恰好路由到另一家也说 Anthropic 协议的供应商，也会经过这次解析与重建，不是逐字节透传。这张表记录这个过程中哪些字段被保留、哪些被改写、哪些被丢弃。
本页答的是"我们的适配层做了什么"，不是"Anthropic 协议本身是什么"——协议本身请参考 Anthropic 官方文档。本表只覆盖顶层请求参数与消息级的工具/思考块，不覆盖内容块级别的细节（如图片/文档块的
cache_control、base64/URL 形态差异），那部分尚待补充。
一、入站（你的请求 → 平台）保留的字段
| 字段 | 处理方式 |
|---|---|
model / messages | 解析进内部结构，必填 |
system（字符串或内容块数组） | 拼成纯文本，作为一条 system 角色消息前置；多个 system 块的内容会被合并成一段 |
max_tokens | 保留数值，出站时可能被裁剪（见下） |
temperature / top_p | 保留数值 |
stream | 保留 |
tools / tool_choice | 原样保留，出站时按目标协议改写形状 |
thinking（{type, budget_tokens}） | 解析出预算值，归一成内部推理结构 |
消息里的 tool_use / tool_result / thinking / redacted_thinking 内容块 | 分别识别并保留（工具调用改写成内部统一形状；thinking/redacted_thinking 连同 signature 整块原样保留，见下方跨协议限制） |
二、入站解析时被静默丢弃的字段
以下字段传了不会报错，但也完全不会生效——平台内部结构根本没有为它们保留位置：
| 字段 | 现象 |
|---|---|
top_k | 传了完全不生效，无论目标供应商是谁 |
stop_sequences | 即使目标供应商也是 Anthropic，你传的停止序列也不会被使用 |
metadata（含 user_id） | 整体丢弃 |
三、出站（平台 → 目标为 Anthropic 的供应商）时的改写
| 字段 | 改写规则 |
|---|---|
max_tokens | 你给了就用，但不超过该模型规格配置的输出上限（超了截断为该上限）；你没给则用规格上限，规格也没配则回落 4096；非流式请求这个值另有硬顶 8192 |
temperature | 你给的值 > 1.0 时截断为 1.0（Anthropic 硬性上限），不会报错 |
system | 见上——多个 system 消息被换行符拼接成一段 |
thinking.budget_tokens | 若达到或超过最终的 max_tokens，截断为 max_tokens - 1；若结果小于 1024，整个 thinking 字段不会发送（低于 Anthropic 最小预算，发了必然 400，索性不发等同于"这次没开思考"） |
frequency_penalty / presence_penalty / n / seed / logprobs / top_logprobs / response_format | Anthropic 协议没有对应概念，出站请求里完全不会出现这些键——这是协议本身不支持，不是平台缺陷 |
四、跨协议限制：携带签名的推理内容
如果你的会话历史里携带了上游签发的 thinking/redacted_thinking 内容块（带有加密签名），而这次调用需要路由到另一家供应商时，会直接返回 4xx，而不是尝试转发。这类内容块的签名由签发方私钥验证，换一家供应商必然验证失败；平台选择在请求到达上游前就明确拒绝，而不是发送一个必然会失败的请求。