近日,多位开发者反馈在使用 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

IT资源栈
评论前必须登录!
立即登录 注册