近日，多位开发者反馈在使用 DeepSeek 的 Anthropic 兼容端点配合 Claude Code 2.1.166 及以上版本时遭遇了严重的功能阻断。问题的根源在于 Claude Code 在其 Workflow（多 Agent 编排）功能中，为了不向用户展示子 Agent 的思考过程，会在请求中强制附带 `thinking: { type: “disabled” }` 参数。然而，DeepSeek 官方为了启用深度推理，建议配置 `CLAUDE_CODE_EFFORT_LEVEL=max`，这会注入 `reasoning_effort` 参数。DeepSeek 的服务端校验逻辑错误地认为这两个参数互斥，当请求中同时出现“禁用思考输出”和“设置推理力度”时，直接返回 HTTP 400 错误。这导致 Claude Code 的子 Agent 无法生成，多任务协作功能彻底失效。目前唯一的解决方案是将 Claude Code 回退至 2.1.165 版本。该 Bug 不仅影响了 Claude Code，理论上任何在 Anthropic 兼容模式下同时发送这两个参数的客户端都会触发此拦截。
事件分析
此次事件凸显了当前大模型 API 生态中“名义兼容、实质割裂”的现状。虽然 DeepSeek 提供了 Anthropic 格式的兼容端点，但在具体参数逻辑（如 `reasoning_effort` 与 `thinking` 模式的共存规则）上与原生实现存在偏差。从技术架构看，DeepSeek 的校验逻辑可能存在误判：`thinking: disabled` 仅控制前端输出流的屏蔽，不应限制模型内部的推理强度。这种过度严格的校验直接阻碍了高级 AI Agent 框架的正常运行。对于开发者而言，这意味着在利用国产模型替代海外 API 进行 AI 编程时，仍需面对非预期的兼容性调试成本。短期内，建议 DeepSeek 调整端点校验策略，允许屏蔽输出与高强度的内部推理并存。
💡 核心观点：API 参数校验的微小偏差能瘫痪整个 Agent 工作流，这暴露了模型生态兼容性仍处于“能跑通”与“好用”之间的巨大鸿沟。
原文链接：Linux.do
评论前必须登录！
立即登录 注册