Claude Fable 5.1 工具调用报 400：tool_choice、thinking block 和数据保留怎么迁

先判断：这不是只改模型名的升级

把现有 Agent 从 Claude Fable 5 切到 claude-fable-5-1 后，最容易踩的坑不是模型找不到，而是旧请求仍然能通过类型检查，却在运行时返回 400，或者在长会话里悄悄丢掉 thinking block。

这次迁移至少要同时检查四件事：

1. tool_choice 是否仍在使用 any 或指定工具的 tool 模式。
2. 历史 thinking block 是否来自当前模型可接受的模型版本。
3. 回放 thinking block 前，system prompt、tools 或更早的消息是否发生变化。
4. 当前组织是否允许 30 天数据保留。

只替换模型字符串，无法覆盖这四条路径。

症状一：tool_choice 直接返回 400

Claude Fable 5.1 和 Claude Mythos 5.1 不支持 tool_choice.type 为 any 或 tool。继续发送这两种值会返回 400。auto 和 none 仍可使用。

下面的旧请求需要迁移：

{
  "model": "claude-fable-5-1",
  "max_tokens": 2048,
  "tools": [
    {
      "name": "read_issue",
      "description": "读取 issue",
      "input_schema": {
        "type": "object",
        "properties": {
          "number": { "type": "integer" }
        },
        "required": ["number"]
      }
    }
  ],
  "tool_choice": { "type": "tool", "name": "read_issue" },
  "messages": [
    { "role": "user", "content": "读取 issue 42" }
  ]
}

迁移时先改为 auto，再用 strict tool use 或 structured outputs 约束输入结构：

{
  "tool_choice": { "type": "auto" }
}

不要把“必须调用某个工具”和“工具参数必须符合 schema”混成一个要求。前者是路由控制，后者是结构校验；Fable 5.1 收紧的是前一种调用方式。

怎么验证

保留一条最小请求，分别测试：

• auto：模型能在需要时调用工具。
• none：模型不调用工具。
• any：确认环境确实返回 400，而不是 SDK 在客户端改写。
• strict tool use：错误字段和缺失字段不会进入业务工具。

记录 HTTP 状态码、响应体中的错误类型和 request-id，不要只保存 SDK 抛出的最后一行异常。

症状二：回放 thinking block 时失败或被丢弃

Fable 5.1 的 thinking block 不是可以任意复制的普通文本。它带有模型和历史前缀约束。官方规则可以概括为两条：

• thinking block 只能由产生它的模型或更新模型继续读取。
• 对新账户而言，如果 block 之前的 system prompt、tools 或历史消息被修改，回放可能返回 400。

因此，下面这些常见操作都可能破坏回放：

• 在恢复会话时给 system prompt 补一段新规则。
• MCP Server 更新后，工具描述或 JSON Schema 发生变化。
• 为节省 token 删除了历史中的一条 tool result。
• 把 Fable 5.1 的会话回退到更早模型，却继续携带原 thinking block。

正确的恢复策略

把可恢复状态分成两层：

1. 业务状态：任务目标、已修改文件、测试结果和待办，可以由应用保存。
2. 模型状态：签名 thinking block 和它依赖的历史前缀，必须原样回放。

如果业务必须修改 system prompt 或 tools，应开启一个新模型回合，用普通消息提供经过核对的任务摘要，而不是强行复用旧 thinking block。

使用 thinking-binding-controls-2026-08-01 beta header 时，检查响应里的 input_transformations。它可以帮助区分 block 是被拒绝还是被丢弃，但不能代替应用自己的恢复日志。

症状三：同一请求在合规环境里不可用

Claude Fable 5.1 和 Claude Mythos 5.1 要求 30 天数据保留。默认情况下，它们不适用于零数据保留环境，除非 Anthropic 明确授权。

这会造成一种容易误判的现象：

• 开发者个人组织可以调用。
• 企业生产组织因为保留策略无法启用。
• 代码、模型名和 API 参数完全相同。

上线前必须向组织管理员确认模型资格和保留策略。不要用个人 Key 的成功结果证明生产 workspace 一定可用。

对于包含私有代码、客户数据或安全事件材料的 Agent，还要确认日志、tool result、Files API 内容和会话转录分别保留多久。模型的 30 天要求只是其中一层。

推荐迁移顺序

第一步：建立请求样本

从生产流量中脱敏选取四类请求：纯文本、单工具、并行工具和带 thinking 回放的长会话。每类保存输入形状、状态码、停止原因、token 用量和工具调用数量。

第二步：先消除确定的 400

搜索代码和配置中的以下内容：

tool_choice
any
type: tool
claude-fable-5
thinking block

把不支持的 tool_choice 改为 auto 或 none。若业务依赖强制工具调用，在应用层验证是否产生目标 tool call；失败时返回可重试的业务错误，不要自动执行模型输出的文本。

第三步：固定历史前缀

为 system prompt 和 tools 生成稳定摘要，例如 SHA-256。保存会话时同时记录模型 ID、prompt 摘要和 tools 摘要。恢复前先比较摘要，不一致就走新会话路径。

第四步：做模型回退测试

模型回退不能只看文本回答。至少检查：

• 旧模型是否能读取新模型产生的 thinking block。
• 回退后工具参数是否仍符合 schema。
• 被丢弃的 thinking 是否出现在 input_transformations。
• 重试是否造成工具重复执行。

对于写数据库、发消息、合并 PR 等有副作用的工具，为每次调用增加幂等键。

第五步：核对数据保留

把模型保留要求写进上线清单。零数据保留是硬约束时，不要先上线再等待豁免，应继续使用满足策略的模型或产品入口。

上线验收清单

• [ ] 所有请求不再发送 tool_choice: any。
• [ ] 所有请求不再发送 tool_choice: {type: tool}。
• [ ] strict tool use 或应用层 schema 校验已经启用。
• [ ] 会话记录包含模型 ID、system prompt 摘要和 tools 摘要。
• [ ] 历史前缀变化时不会继续强行回放 thinking block。
• [ ] 模型回退不会重复执行有副作用的工具。
• [ ] 已确认生产组织允许 30 天数据保留。
• [ ] 日志保留了 request ID、停止原因和输入转换结果，但没有记录密钥或完整敏感正文。

常见误区

误区一：模型名能调用成功就算迁移完成

第一次文本响应成功，只能证明认证、模型名和基础请求可用。工具调用、长会话恢复和组织策略仍可能失败。

误区二：把 thinking 当作普通摘要

普通摘要可以由应用编辑，签名 thinking block 不可以。编辑它前面的历史也可能使签名上下文失效。

误区三：遇到 400 就删除所有高级参数

这种做法可能让请求暂时成功，却同时失去结构校验、思考控制和可观察性。应该根据错误字段逐项迁移，并保留回归样本。

什么时候才算迁移完成

迁移完成的标准不是“新模型回答了一次问题”，而是四条路径都通过：普通对话成功、工具参数可验证、长会话能够恢复、生产组织满足保留策略。任何一条没有验证，都应该保持灰度而不是全量切换。

参考来源

相关文章