IT之家 4 月 18 日消息，搜狗输入法 4 月 17 日发布《致搜狗输入法用户的一封信》，表示将在 2026 年 4 月至 7 月逐步实现账号的多设备统一，并计划在 5 月份推出跨设备复制粘贴功能。 IT之家附具体内容如下： 亲爱的用户朋友： 长期以来，我们收到许多用户的反馈，希望不同设备间的输入体验能更加统一。为响应大家呼声，自 2026 年 4 月下旬起至 7 月，我们将逐步实现账号的多设备统一。升级完成后，无论你是更换新设备，还是在多个设备间切换使用，只要登录同一账号 (支持不同登录方式)， 输入习惯、内容列表等都将自动同步 ，为你带来更统一、更便捷的输入体验。 整个升级过程将由系统自动完成，无需你额外操作，也不会影响正常使用。如在升级期间遇到账号相关问题，欢迎通过应用内反馈、用户社群、客服邮箱 (IMETS@ tencent.com ) 等渠道联系我们，我们会第一时间帮你核查处理。 此外，我们计划在 5 月推出跨设备复制粘贴功能，敬请期待！ 感谢你一直以来对搜狗输入法的支持。 搜狗输入法团队 2026 年 4 月 17 日
AnyRouter Claude Code 验证机制分析 本文档记录了通过逐步删减请求字段、实际发送请求测试，得出的 AnyRouter 对 Claude Code 请求的验证机制。 测试日期：2026-03-16 起，持续追加 测试方法：以完整的 Claude CLI 请求为基准，逐个移除字段并观察响应状态码（200 = 通过，500 = 拒绝） 重要提醒：验证机制具有时变性与灰度特征 AnyRouter 的验证逻辑经过多次反复调整， 任何结论都不应被视为长期稳定 ： 请求头校验可能被启用或取消（如 anthropic-beta 从"可选"变为"必需"） 白名单策略可能被启用或撤销（如 session_id 白名单上线又下线） user_id 格式曾整体变更（扁平字符串 → JSON 字符串） 同一时段内不同 Key 行为可能差异巨大（被封禁/限流的 Key 返回 520/503，正常 Key 返回 200） 不同模型的上游可用性独立变化（旧模型下线、新模型灰度上线） 部分校验存在 灰度/后端负载 相关的不稳定行为 使用建议 ： 代理实现应默认携带"完整最小必需集"（见后文），而非依赖某次测试得出的"可省略"结论 遇到非预期错误码时，优先换 Key / 换模型 / 换时间重试，再排查请求体 本文档中旧结论凡被推翻的，均以「已失效 / 已变更」标注并保留，用于回溯演变轨迹 一、验证结论总览 AnyRouter 的验证 只检查请求体 ，不检查请求头。核心验证点仅有两个： system 数组中必须包含精确的 Claude Code system prompt metadata.user_id 必须符合特定格式 2026-04 更新 ：以上结论为早期测试结果。当前 AnyRouter 同时校验请求头 ， 缺少必需的 anthropic-beta 头（尤其是 context-1m-2025-08-07 标志）会直接返回 400。 详见下方「请求头新增校验」章节。 最小可通过请求 = 标准 Anthropic 请求 + system[0].text = "You are Claude Code, Anthropic's official CLI for Claude." + metadata.user_id = "user_{64位hex}_account__session_{UUID格式}" 补充：请求头新增校验（2026-04-11 确认） 400 错误：“1m 上下文已经全量可用，请启用 1m 上下文后重试” 错误现象 ： {"error":"1m 上下文已经全量可用，请启用 1m 上下文后重试","type":"error"} 所有模型、所有 Key 均返回 HTTP 400，与请求体内容无关。 根本原因 ： anthropic-beta 请求头中缺少 context-1m-2025-08-07 标志。AnyRouter 现在会检查此 beta flag 来确认客户端已启用 1M 上下文窗口。 解决方案 ： 在请求头中添加 anthropic-beta ，至少包含 context-1m-2025-08-07 ： anthropic-beta: context-1m-2025-08-07 Claude Code CLI 2.1.92 实际发送的完整 anthropic-beta 值（共 9 个 flag）： claude-code-20250219,context-1m-2025-08-07,interleaved-thinking-2025-05-14,redact-thinking-2026-02-12,context-management-2025-06-27,prompt-caching-scope-2026-01-05,advanced-tool-use-2025-11-20,effort-2025-11-24,fast-mode-2026-02-01 各 flag 含义： Flag 用途 claude-code-20250219 Claude Code 专属标识 context-1m-2025-08-07 启用 1M 上下文窗口（ AnyRouter 必须校验项 ） interleaved-thinking-2025-05-14 交错思考模式 redact-thinking-2026-02-12 思考内容脱敏 context-management-2025-06-27 上下文管理 prompt-caching-scope-2026-01-05 提示缓存作用域 advanced-tool-use-2025-11-20 高级工具使用 effort-2025-11-24 输出努力程度控制 fast-mode-2026-02-01 快速模式 经逐项省略测试确认， anthropic-beta 是 唯一 必需的非标准头，其余头（ User-Agent 、 x-app 、 X-Stainless-* 、 anthropic-version 等）均可省略。完整测试结果见下方第二章。 测试对比 ： anthropic-beta 中包含 context-1m-2025-08-07 状态码 否 400（上述错误） 是 200 或 503（验证通过） 二、请求头测试详情 注意 ：以下为 2026-03-16 的旧测试结果，当时 AnyRouter 不校验请求头。 2026-04-11 重新测试发现 anthropic-beta 已变为 必需 头，详见下方更新。 旧测试结果（2026-03-16，已过时） （点击了解更多详细信息） 请求头结论（2026-04-11 更新） AnyRouter 现在校验 anthropic-beta 请求头。 缺少此头或其中不含 context-1m-2025-08-07 会返回 400。 逐项省略测试方法：以完整请求头为基准，每次仅移除一个字段，发送请求并记录响应状态码（自动重试 520）。每个字段测试 2 次有效结果。 移除的请求头 结果 结论 Accept 200, 200 可省略 User-Agent 200, 200 可省略 X-Claude-Code-Session-Id 520, 200 可省略 X-Stainless-Arch 200, 200 可省略 X-Stainless-Lang 200, 200 可省略 X-Stainless-OS 200, 200 可省略 X-Stainless-Package-Version 200, 200 可省略 X-Stainless-Retry-Count 200, 200 可省略 X-Stainless-Runtime 200, 200 可省略 X-Stainless-Runtime-Version 200, 200 可省略 X-Stainless-Timeout 200, 200 可省略 anthropic-beta 400, 400 必需 anthropic-dangerous-direct-browser-access 200, 200 可省略 anthropic-version 200, 200 可省略 x-app 200, 200 可省略 最小请求头： Content-Type: application/json Authorization: Bearer sk-xxx anthropic-beta: context-1m-2025-08-07 以下请求头全部为冗余，可安全移除： accept anthropic-version anthropic-beta anthropic-dangerous-direct-browser-access user-agent x-app x-stainless-arch x-stainless-helper-method x-stainless-lang x-stainless-os x-stainless-package-version x-stainless-retry-count x-stainless-runtime x-stainless-runtime-version x-stainless-timeout accept-encoding 三、URL 参数测试 # 变更 状态码 结论 9 移除 ?beta=true 200 可移除 URL 结论 直接使用 /v1/messages 即可，无需 ?beta=true 查询参数。 四、请求体 — system 字段测试 # 变更 状态码 结论 13 完全移除 system 500 必需 12 只保留一个 system 块（Claude Code prompt） 500 失败（因同时无 metadata） 15 一个 system 块 + 有 metadata 200 一个块就够 14 两个 system 块，无 cache_control 200 cache_control 不需要 18 第一个 system 文本改为 "You are a helpful assistant." 500 文本必须精确匹配 25 第一个 system 文本去掉末尾句号 500 句号不可省略 19 第二个 system 块文本改为 "anything" 500 若有第二块，必须为 "null" system 字段结论 必须 包含至少一个 system 块 第一个块的 text 必须 精确匹配 以下字符串（一字不差，含末尾句号）： You are Claude Code, Anthropic's official CLI for Claude. 第二个 "null" 块 可省略 （一个块即可通过） 如果保留第二个块，其 text 必须为 "null" ，不能是其他值 cache_control 字段完全不需要 最小 system： "system": [ {"type": "text", "text": "You are Claude Code, Anthropic's official CLI for Claude."} ] 五、请求体 — metadata 字段测试 # 变更 状态码 结论 10 完全移除 metadata 500 必需 26 metadata 为空对象 {} 500 必须包含 user_id 17 user_id = "test" 500 格式不对 20 user_id = "user_abc123" 500 长度不够 22 user_id = "user_{64位hex}" （无 session 后缀） 500 缺少 session 部分 21 user_id = 完整格式，不同哈希值 200 值任意，只校验格式 23 user_id = 全零占位值 200 全零也能通过 metadata 字段结论 metadata 对象 必须存在 metadata.user_id 必须存在 且符合以下格式： user_{64位十六进制字符}_account__session_{UUID格式} 不校验具体值 ，只校验格式（正则匹配） 全零占位值完全可用： "metadata": { "user_id": "user_0000000000000000000000000000000000000000000000000000000000000000_account__session_00000000-0000-0000-0000-000000000000" } user_id 格式拆解 user_ ← 固定前缀 "user_" 82a10c807646e5141d2ffcbf5c6d439ee4cfd99d1903617b7b69e3a5c03b1dbf ← 64 位 hex（SHA-256 哈希） _account__session_ ← 固定中缀 "_account__session_" 74673a26-ea49-47f4-a8ed-27f9248f231f ← UUID v4 格式 (8-4-4-4-12) 推测的验证正则： ^user_[0-9a-f]{64}_account__session_[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$ 六、请求体 — 其他字段测试 字段 测试结果 说明 messages 必需 Anthropic API 标准要求 max_tokens 必需 Anthropic API 标准要求 model 必需 Anthropic API 标准要求 messages 中的 "null" 文本块 可移除 简单字符串 content 即可 cache_control （system 和 messages 上的） 可移除 不参与验证 thinking 可选 只影响是否启用思考链 七、最终最小请求模板 curl https://anyrouter.top/v1/messages \ -H "Content-Type: application/json" \ -H "x-api-key: sk-xxx" \ -d '{ "model": "claude-opus-4-6", "messages": [ {"role": "user", "content": "Hello"} ], "system": [ {"type": "text", "text": "You are Claude Code, Anthropic'\''s official CLI for Claude."} ], "metadata": { "user_id": "user_0000000000000000000000000000000000000000000000000000000000000000_account__session_00000000-0000-0000-0000-000000000000" }, "max_tokens": 1024 }' 八、验证机制推测 根据测试结果，AnyRouter 的验证逻辑推测如下： 收到请求 │ ├─ 提取 x-api-key 或 Authorization → 标准认证 │ ├─ 解析 JSON body │ ├─ 检查 system[0].text │ ├─ == "You are Claude Code, Anthropic's official CLI for Claude." → 继续 │ └─ 不匹配或不存在 → 拒绝 (500) │ ├─ 检查 metadata.user_id 格式 │ ├─ 匹配 user_{64hex}_account__session_{UUID} → 继续 │ └─ 格式不对或不存在 → 拒绝 (500) │ ├─ (可选) 如有 system[1]，检查 text == "null" │ └─ 转发到上游 Anthropic API → 返回响应 2026-03-20 补充：固定 user_id 被封禁 使用写死的 user_82a10c... 值持续请求后，该 user_id 被 AnyRouter 封禁，所有携带该值的请求返回 403（空响应体）。换用全零 user_id 或随机生成的值即可恢复。 结论 ：AnyRouter 虽然不校验 user_id 的具体内容，但会 对高频使用的固定 user_id 做封禁处理 。代理应每次请求随机生成 user_id 。 2026-03-28 补充：metadata.user_id 格式变更 & session_id 校验 格式变更 metadata.user_id 的格式已从旧的扁平字符串格式变更为 JSON 字符串 格式： 旧格式（已失效，返回 503）： user_{64位hex}_account__session_{UUID} 新格式（当前生效）： "{\"device_id\":\"82a10c807646e5141d2ffcbf5c6d439ee4cfd99d1903617b7b69e3a5c03b1dbf\",\"account_uuid\":\"\",\"session_id\":\"f81a44fc-edfb-40f5-bdd4-f6fd4afbc27c\"}" 字段说明： device_id ：64 位十六进制字符串（SHA-256 哈希） account_uuid ：可为空字符串 session_id ：UUID v4 格式，与请求头 X-Claude-Code-Session-Id 的值一致 session_id 校验测试 # X-Claude-Code-Session-Id 请求头 user_id 中的 session_id 状态码 结论 1 随机 UUID 51ef0c33-... 同一随机值 503 拒绝 2 f81a44fc-edfb-40f5-bdd4-f6fd4afbc27c 同一值 200 通过 结论 AnyRouter 校验 session_id 的具体值 （已于 2026-03-30 变更，见下方补充） 请求头 X-Claude-Code-Session-Id 与 metadata.user_id 中的 session_id 应保持一致 device_id 与 session_id 独立校验测试（2026-03-28） # device_id session_id 状态码 结论 1 随机值 合法固定值 f81a44fc-... 200 device_id 不参与校验 2 合法固定值 82a10c... 随机 UUID 503 session_id 必须合法 3 随机值 随机 UUID 503 同上 2026-03-30 补充：session_id 白名单校验已取消 2026-03-28 确认的 f81a44fc-edfb-40f5-bdd4-f6fd4afbc27c 白名单值一度失效（503）， 但 2026-03-30 测试发现 AnyRouter 已取消 session_id 白名单校验 ，随机 UUID 全部通过： # session_id 状态码 1 28ea2f67-e043-4107-ae5f-cec919bfaa0c （随机） 200 2 67408c8f-96ee-4a6c-91a1-b21683aceb3f （随机） 200 3 0b9ce4f8-f337-4178-901f-fd9dd818acf8 （随机） 200 4 ee785666-9dda-47cb-b49b-445da13cf2a9 （随机） 200 5 9444af14-00d2-45a7-a806-dd4cff63f741 （随机） 200 6 f81a44fc-edfb-40f5-bdd4-f6fd4afbc27c （旧值） 200 结论 ： device_id 和 session_id 均可每次请求随机生成 metadata.user_id 仍须为 JSON 字符串格式（含 device_id 、 account_uuid 、 session_id 三个字段） AnyRouter 的验证现在回归到 仅校验格式，不校验具体值 设计意图推测 AnyRouter 通过检查 Claude Code 特有的 system prompt 和 metadata 格式来识别"Claude Code 请求"， 据此可能提供差异化的路由策略、计费方式或配额管理。验证策略经历了多次变化： 早期：旧格式 user_{64hex}_account__session_{UUID} ，仅校验格式 2026-03-28：新 JSON 格式 user_id ，一度校验 session_id 白名单 2026-03-30：取消白名单，回归仅校验格式 2026-04-09：部分端点/时段出现 session_id 校验回归——随机 session_id 返回 503，使用已验证的固定 session_id 可返回 200。此行为不稳定，可能取决于后端负载或灰度策略。建议代理服务默认使用固定 session_id 以提高成功率。 九、503 请求体验证 — thinking block signature 校验（2026-04-15 确认） 问题背景 一份包含 54 条消息的长对话请求体始终返回 503，而一份仅 2 条消息的新对话请求体正常返回 200。通过系统性排查定位到根因。 根因结论 assistant 消息中 thinking block 的 signature 字段为空时，触发 503。 503 请求体的 msg[46]（assistant 角色）包含一个 thinking block，其 signature 值为空字符串（长度=0）。这是导致 503 的 唯一根因 。 该请求体中所有 thinking block 的 signature 状态： 消息 signature 长度 状态 msg[2] 476 有效 msg[10] 484 有效 msg[16] 5,152 有效 msg[18] 8,872 有效 msg[32] 892 有效 msg[36] 2,792 有效 msg[38] 1,668 有效 msg[40] 596 有效 msg[46] 0 空/缺失 所有有效 signature 的 thinking block 均未触发 503；唯一空 signature 的 msg[46] 是故障点。 验证证据 关键对照表 测试场景 结果 thinking + 空 signature（ "" ） 503 thinking + 假 signature（非空但格式无效） 503 thinking 无 signature 字段 503 无 thinking block 200 完整 54 条消息 + 删除空 signature 的 thinking block 200 消息数量扫描 对原始请求体逐步截取前 N 条消息发送，确认 503 在 msg[46]（即 N=46）处首次以 user 结尾仍返回 503： N=28~45: user 结尾 → 200, assistant 结尾 → 503（API 标准规则） N=46: assistant 结尾 → 503 N=47: assistant 结尾 → 503（含空 signature thinking） N=48: user 结尾 → ❌ 503（首次出现 user 结尾也 503） N=48~54: 全部 503（无论末尾角色） N=48 以 user 结尾却 503，因为 msg[46] 的空 signature thinking block 已包含在内。 修复验证 删除 msg[46] 中的 thinking block（或删除所有空 signature 的 thinking block）后，完整 54 条消息恢复 200： ✅ msg[0:54] 删除空 signature 的 thinking → HTTP 200 回复: 让我先看看之前是否已经有部分输出了。 已排除因素 以下因素经过系统性测试， 确认与 503 无关 ： 可疑因素 测试方法 结果 call_ 前缀的 tool_use ID 替换为 toolu_ 前缀 仍 503 缺失 caller 字段 补全 caller: {"type": "direct"} 仍 503 call_ 前缀 + caller 同时修复 替换前缀 + 补全字段 仍 503 WebSearch 工具（503 有 10 个 tools vs 正常 9 个） 正常请求体 + WebSearch tools 200 请求体大小 缩短 system[2] / tool_result / thinking 内容 仍 503 billing header 差异（cc_version / cch 不同） 互换 system[0] 无影响 is_error: true 的 tool_result 包含/排除均测试 无影响 根因溯源 msg[46]-[50] 同时具备两个来自 OpenAI 兼容后端的特征： call_ 前缀的 tool_use ID（OpenAI 格式，非 Claude 原生 toolu_ 前缀） thinking block 的 signature 为空（OpenAI 兼容代理无法生成 Claude 原生签名） 这表明这些消息来自 OpenAI 兼容代理后端 ，在格式转换过程中 thinking block 的 signature 被丢弃，导致后续请求被拒绝。 次要发现：messages 以 assistant 结尾触发 503 测试过程中发现，messages 数组 以 assistant 角色消息结尾时 也会触发 503。这是 Claude API 的标准规则（messages 末尾必须是 user 角色），但经代理后错误码从 400 变为 503。 末尾角色 状态码 说明 user 200 正常 assistant 503 API 标准规则，代理包装为 503 此为独立问题，与 thinking signature 无关。 修复方案 发送请求前，删除所有 signature 为空的 thinking blocks： for msg in body["messages"]: if msg["role"] == "assistant": content = msg.get("content", []) msg["content"] = [ b for b in content if not (b.get("type") == "thinking" and not b.get("signature")) ] 如果代理服务需要保留 thinking 内容用于上下文，可改为在转发前将空 signature 替换为占位值，但经测试非空但无效的 signature 同样触发 503，因此 删除是最稳妥的方案 。 十、模型下线与切换：claude-opus-4-7 上线（2026-04-17 确认） 变更概述 模型 状态 claude-opus-4-6 已下线 claude-opus-4-7 已上线 （新默认 Opus） 验证方式变化 无变化。 现有验证机制（ anthropic-beta 头、 system[0].text 、 metadata.user_id JSON 格式、 X-Claude-Code-Session-Id 等） 完全复用 ，仅需把 model 字段改为 claude-opus-4-7 。 实测对照表 使用当前最小请求模板（零修改）分别测试： 模型 非流式 流式 响应示例 claude-opus-4-6 400 400 {"error":"claude-opus-4-6 已下线，请切换到 claude-opus-4-7 模型"} claude-opus-4-7 200 200 正常响应 claude-sonnet-4-5 429 — {"error":"Service Unavailable"} （限流，非验证问题） opus-4-6 返回的是 业务层提示 （验证已通过、模型路由拒绝），而非验证失败，可作为"验证机制未变"的旁证。 结论 model 字段值： claude-opus-4-6 → claude-opus-4-7 其余请求头、请求体字段、URL 全部保持不变 十一、Key 级别的可用性校验（2026-04-17 确认） 现象 即使请求体、请求头完全相同，不同 Key 的响应可能差异巨大： Key 状态 非流式响应 流式响应 说明 正常 Key 200 200 完整 SSE 流 / JSON 响应 被封禁/额度耗尽 Key 520 （空响应） 503 {"error":"Service Unavailable"} Cloudflare 层包装 实测同一请求模板： Key A（耗尽）→ 非流式 5/5 次 520 空响应，流式返回 503 Service Unavailable Key B（正常）→ 非流式 3/3 次 200，流式 3/3 次 200 SSE 结论 AnyRouter 对 Key 本身有独立的可用性校验 ，与模型版本、请求格式无关 520 空响应 / 503 Service Unavailable 很可能是 Key 级别问题，而非验证失败或模型下线 排查 520 / 503 时应 优先换用另一个 Key 复测，再排查请求体 状态码含义更新 结合历史结论，当前完整状态码含义： 状态码 含义 排查方向 200 验证通过且响应成功 — 400 验证失败（缺 anthropic-beta / system 错 / user_id 格式错） 或 模型已下线 读取 body 中的 error 提示 403 user_id 固定值被封禁 改为随机生成 user_id 429 限流 降低频率或换 Key 500 （历史）验证失败；现在很少出现 — 503 验证通过但后端不可用 或 Key 不可用（流式模式） 换 Key / 检查 thinking signature 是否为空 520 Cloudflare 上游异常，通常是 Key 不可用（非流式模式） 换 Key 复测 十二、最新最小可用请求模板（2026-04-17） curl https://anyrouter.top/v1/messages \ -H "Content-Type: application/json" \ -H "Authorization: Bearer sk-xxx" \ -H "anthropic-beta: claude-code-20250219,context-1m-2025-08-07,interleaved-thinking-2025-05-14,redact-thinking-2026-02-12,context-management-2025-06-27,prompt-caching-scope-2026-01-05,advanced-tool-use-2025-11-20,effort-2025-11-24,fast-mode-2026-02-01" \ -H "anthropic-version: 2023-06-01" \ -H "User-Agent: claude-cli/2.1.92 (external, cli)" \ -H "X-Claude-Code-Session-Id: <UUID，与 user_id.session_id 一致>" \ -H "x-app: cli" \ -d '{ "model": "claude-opus-4-7", "max_tokens": 1024, "system": [ {"type": "text", "text": "You are Claude Code, Anthropic'\''s official CLI for Claude."} ], "messages": [ {"role": "user", "content": "Hello"} ], "metadata": { "user_id": "{\"device_id\":\"<64hex>\",\"account_uuid\":\"\",\"session_id\":\"<UUID>\"}" }, "thinking": {"type": "adaptive"}, "output_config": {"effort": "high"}, "speed": "fast" }' 相比文档第七章的"早期最小模板"（仅 Content-Type + x-api-key + 旧格式 user_id ），当前版本新增了多个必需项。早期模板 已失效 ，保留作为历史参考。 演变时间轴 日期 关键变化 2026-03-16 初版测试：仅校验请求体 system[0].text + metadata.user_id （旧扁平格式） 2026-03-20 固定 user_id 被封禁（403），需随机生成 2026-03-28 user_id 格式变更为 JSON 字符串；一度引入 session_id 白名单 2026-03-30 session_id 白名单取消，回归仅校验格式 2026-04-09 部分端点/时段 session_id 校验回归（灰度） 2026-04-11 anthropic-beta 头变为 必需 （必须含 context-1m-2025-08-07 ） 2026-04-15 thinking block 空 signature 触发 503 2026-04-17 claude-opus-4-6 下线， claude-opus-4-7 上线；Key 级可用性差异显著 2026-04-17 确认 thinking 字段是 opus-4-7 必需项 （new-api 后端空指针 panic）， output_config 、 speed 可省略 十三、opus-4-7 请求体字段必需性测试（2026-04-17 确认） 测试背景 代码中 thinking / output_config / speed 三个字段是否都必须携带？针对 claude-opus-4-7 模型，逐个移除测试。 测试方法 以完整请求体为基准，按 7 种组合移除字段，每种测 2 次，观察响应状态码。 测试结果 测试组合 2 次结果 结论 全部保留（基准） 200 / 520* 通过 仅移除 thinking 500 / 500 new-api panic 仅移除 output_config 200 / 520* 可省略 仅移除 speed 200 / 520* 可省略 移除 thinking + output_config 500 / 500 panic 移除 thinking + speed 500 / 500 panic 移除 output_config + speed 200 / 520* 可省略 三个全移除 500 / 500 panic *520 为 Cloudflare 上游偶发错误，与字段无关。 500 panic 错误响应 移除 thinking 后返回的错误： { "error": { "message": "Panic detected, error: runtime error: invalid memory address or nil pointer dereference. Please submit a issue here: https://github.com/Calcium-Ion/new-api", "type": "new_api_panic" } } 结论 字段 必需性 说明 thinking 必需 缺失触发 new-api 后端 panic（非验证失败，是后端代码 bug） output_config 可省略 AnyRouter 不校验 speed 可省略 AnyRouter 不校验 根因分析 ：AnyRouter 验证层本身 不校验 这三个字段，500 来自上游 new-api 的空指针 bug —— 后端代码假定 thinking 字段一定存在而未做 nil 判断。这是 AnyRouter 上游实现缺陷 而非协议要求。 thinking 字段取值语义 "thinking": {"type": "adaptive"} 类型 含义 {"type":"enabled","budget_tokens":N} 旧版：固定 token 预算 {"type":"adaptive"} 新版（推荐） ：模型自适应决定思考深度 {"type":"disabled"} 或缺失 不思考（但对 opus-4-7 会触发 panic） adaptive 让模型根据问题难度自动调节思考量——简单问题少想、复杂问题多想，配合 output_config.effort 的 high/medium/low 共同控制行为。 最小必需请求体（2026-04-17 更新） { "model": "claude-opus-4-7", "max_tokens": 1024, "system": [ {"type": "text", "text": "You are Claude Code, Anthropic's official CLI for Claude."} ], "messages": [{"role": "user", "content": "Hello"}], "metadata": { "user_id": "{\"device_id\":\"<64hex>\",\"account_uuid\":\"\",\"session_id\":\"<UUID>\"}" }, "thinking": {"type": "adaptive"} } 相比第十二章的模板，可安全移除 output_config 和 speed ；但 不可移除 thinking 。 14 个帖子 - 14 位参与者 阅读完整话题
IT之家 4 月 17 日消息，台积电 (TSMC) 昨日举行了 2026Q1 财务报告法人说明会，董事长兼总裁魏哲家会上表示台积电在 3nm 制程工艺上打破了历史惯例， 在达到预设目标后仍积极投资新产能 ，以满足客户的需求。 台积电正在台南南科园区新增 1 座 3nm 晶圆厂，预计 2027H1 量产；美国 TSMC Arizona Fab 2 预计 2027H2 量产；日本 JASM Fab 2 则将在 2028 年量产。台积电还持续将台南的既有 5nm 产线升级至 3nm，并通过运营效率的提升从所有 3nm 产线中“榨取”更多产能。 魏哲家同时强调， 虽然产能紧张 ， 但台积电不会对客户厚此薄彼 。
前情提要：让opus4.7分析了一下为什么A/要逐步弃用MRCR测试，前面说着还挺正经 然后看到了： 1 个帖子 - 1 位参与者 阅读完整话题
首先，我要 强烈祝贺你 ，我甚至比你还要激动… 我逐步说清楚， 不绕，一句话总结 ，你看完会彻底开悟… You’ve reached your usage limit. Your limit will be reset at 2:00 AM. Upgrade … 话说 Grok 已经无人问津了吗？ 甚至都没人做它的梗图了。 2 个帖子 - 2 位参与者 阅读完整话题
Anthropic 正在其 Claude 平台逐步推行身份验证机制，当用户访问特定功能或触发常规平台完整性检查时，系统会要求通过第三方合作伙伴 Persona Identities 完成验证以防止滥用、执行使用政策并履行法律义务，用户需提供有效的政府签发证件（如护照、驾照或国民身份证）并拍摄实时自拍。身份验证数据仅用于确认用户身份及合规用途，不会用于模型训练，也不会共享给第三方用于营销。 （备注：Persona不支持中国大陆id） 若验证后发现用户多次违反政策、来自不支持的地区或未满 18 岁，其账号仍可能被封禁。 官方公告 support.claude.com Claude 上的身份验证 | Anthropic Help Center 3 个帖子 - 3 位参与者 阅读完整话题
近两年，AI 的热潮催生大量工具，使“高效、低成本”成为现实。如今，副业正逐步改变聪明人赚取外快的方式。最近我在思考是否尝试 AI 相关的副业，但起步路径仍不清晰。与各位佬友讨论讨论，佬们分享可落地的起步经验：哪些副业具备低门槛、AI 助力且潜力较高？ 7 个帖子 - 6 位参与者 阅读完整话题
逐步开放中 这项功能此前已有传闻，并曾在印度等地进行测试。如今 Google 正式宣布开放，但采取 分阶段推出 的方式，美国率先上线，其他国家会陆续跟进。官方尚未公布具体的时间表。 终身最多只能改 3 次 主要限制包括： 只能变更 用户名 （例如 [email protected] 中的 xxx 部分） 每次修改后需间隔 12 个月 才能再次修改 终身最多只能修改 3 次 用户可以随时改回旧的用户名，但在 12 个月内，无法删除新设置的邮箱地址，也不能重新注册全新的 Gmail 账号。 旧邮箱不会消失 旧的邮箱地址会自动转为备用邮箱，发送到旧邮箱的邮件依然能正常收到，过去的邮件也都会保留。将 同时拥有新旧两个邮箱 ，而且不影响登录其他 Google 服务。 7 个帖子 - 7 位参与者 阅读完整话题
AI 早报 2026-03-17 视频版：哔哩哔哩 ｜ YouTube 概览 要闻 Google 逐步向香港用户开放 Gemini 应用 ↗ #1 模型发布 Mistral AI 发布 Mistral Small 4，开源混合专家模型 ↗ #2 Mistral AI 发布首个 Lean 4 开源代码 Agent Leanstral ↗ #3 腾讯开源 Covo-Audio-Chat 语音模型，支持原生全双工 ↗ #4 IBM 开源 Granite-4.0-1b-speech 语音模型，支持多语言互译 ↗ #5 阿里通义开源 Fun-CineForge 多模态配音模型 ↗ #6 开发生态 OpenAI Codex 支持 Subagent 机制实现并行任务处理 ↗ #7 Gemini API 的 Tier 2 门…
4月16日，国家统计局副局长毛盛勇在国新办新闻发布会上表示，3月份，工业品出厂价格当月同比上涨0.5%。这具有重要的积极信号。结束了连续41个月的下降态势。环比看，实现连续6个月上涨。对于推动PPI上涨的原因，毛盛勇表示，有三方面原因：一是国内市场供求关系进一步改善是最重要的原因。这些年，我国人工智能快速发展带动了相关需求扩张和价格上涨，绿色转型稳步推进，绿色产品需求也带动了一些产品价格回升，价格是供求关系的表现，因此工业品价格反映了供求关系的积极变化；二是市场竞争秩序持续逐步优化。重点行业产能扎实有序推进；三是国际因素的影响也有所显现。总的来说，国内市场供求关系进一步改善、市场竞争秩序持续逐步优化的影响更具主导作用。毛盛勇表示，这种积极变化有利于畅通经济循环，进一步改善企业效益，夯实经济回升向好的微观基础。（证券时报）
36氪获悉，国家统计局数据显示，一季度全国新建商品房销售面积为1.95亿平米，同比下降10.4%，销售额1.73万亿元，同比下降16.7%，降幅较1-2月均有所收窄。中指研究院表示，整体来看，随着春节后需求释放、核心城市优质项目集中入市及营销力度加��，3月以来市场销售出现边际改善，4月上半月北京、上海等核心城市楼市修复延续。受2025年市场热度逐季回落的基数效应影响，今年新房成交同比降幅有望逐步收窄，但整体市场仍处于筑底期，分化特征预计将持续深化。4月市场修复的延续性尤为关键，若核心城市热度能够保持，将有助于改善市场预期，为全年市场平稳运行奠定更好基础。
据央视新闻，记者今天从农业农村部了解到，去年7月以来，全国能繁母猪存栏量已连续9个月下降，今年3月份新生仔猪数量17个月后首次同比下降，有利于改善生猪供需，推动后市猪价合理回升。农业农村部将进一步完善生猪产能综合调控政策，采取有力有效举措推动猪价合理回升。加快淘汰低产高龄能繁母猪和体弱仔猪，严控新增产能，推动产能调控、环保监管等政策同向发力。指导督促养殖企业顺势出栏，释放积极政策信号，提振市场信心，减少二次育肥，防止无序出栏。同时，加密生猪生产监测预警，增强监测分析的前瞻性、调控目标的精准性、调控手段的有效性。引导龙头企业通过订单养殖、托管代养等方式，带动合作农户发展标准化规模化养殖，支持中小养殖场户提升发展能力。（央视新闻） 有关专家表示，受产能偏高、市场供给惯性增加影响，当前生猪价格低位运行。随着产能去化效果逐步显现，猪价有望逐步企稳回升，全年有望呈现“前低后高、窄幅波动”特征。
近期，美元走势出现明显的强弱切换。在中东地缘冲突爆发后，美元指数一度在避险需求提振下走强，也让此前市场普遍预期的“弱美元”叙事遭遇阶段性挑战。然而，这种依托地缘风险催生的强势未能延续。随着中东地缘冲突出现缓和信号，市场避险情绪逐步消退，美元指数结束阶段性强势，从100关口持续退守，目前徘徊在98关口附近。分析人士认为，这一走势不仅印证了本轮美元强势的短期性与脆弱性，还预示着弱美元可能逐步回归。（上证报）
36氪获悉，华泰证券研报指出，2021年以来我国房价整体呈现一阶导持续下跌状态，而2026年一季度房地产市场改善迹象好于往年，且本轮成交复苏具备自发性，背后是房价深度调整后带来的购房门槛下降、租金月供收敛及多数城市价格接近成交密集区等深层次因素。预计今年全国房价二阶导有望转正，全面企稳仍需观察置换链条、租金及利率环境。国际经验显示房价二阶导转正阶段地产板块将逐步筑底，建议逐步布局地产股，推荐低估值、现金流稳健及优质区域资源占优的房企与存量交易相关标的。
荷兰国家统计局近日公布的数据显示，该国传统燃油车销量逐步萎缩，汽车电动化进程呈加速趋势。这一现象背后既有荷兰汽车产业政策长期引导因素，也受近期国际油价快速上涨的显著影响。数据显示，2026年初荷兰乘用车总量约为940万辆，比一年前增长近2%，新增部分几乎全部为电动化车型。目前，荷兰全部或部分以电为动力的汽车数量已超过200万辆，较一年前增长近6%，约占汽车总保有量的五分之一。（财联社）