Dynamic Workflows 在 DeepSeek-v4-pro 映射下完全不可用：thinking:disabled 与 reasoning_effort 冲突

[nettotem]

环境信息

• cc-switch 版本：Version 3.16.1 (3.16.1)
• Claude Code 版本：2.1.169
• 操作系统：macOS Darwin 24.6.0
• 代理地址：ANTHROPIC_BASE_URL=http://127.0.0.1:15721
• 模型映射配置：
  • ANTHROPIC_DEFAULT_OPUS_MODEL_NAME=DeepSeek-v4-pro
  • ANTHROPIC_DEFAULT_SONNET_MODEL_NAME=DeepSeek-v4-pro
  • ANTHROPIC_DEFAULT_HAIKU_MODEL_NAME=DeepSeek-v4-pro

Bug 描述

Dynamic Workflows（动态工作流）功能完全不可用。当 Claude Code 启动工作流后，所有子代理（Subagent）全部立即失败，统一报错：

API Error: 400 thinking options type cannot be disabled when reasoning_effort is set

工作流脚本本身能正常生成，启动也正常，但 /workflows 进度面板中显示每个子代理都是红色失败状态。4 次尝试 × 40 个子代理 = 160 个子代理全部失败，零成功。

复现步骤

1. 使用 cc-switch 将所有 Anthropic 模型映射到 DeepSeek-v4-pro
2. 在 Claude Code 中触发工作流（输入含 ultracode: 关键字的提示，或使用 Workflow() 调用）
3. 运行 /workflows 查看进度
4. 观察到所有子代理立即报错退出

示例触发命令：

ultracode: audit all scripts under ~/.openclaw/workspace/ for security, error handling, and code quality

尝试过的解决方法（全部无效）

次数	模型	Effort 级别	子代理数	结果
1	Opus 4.8	xhigh	40	全部 400
2	Opus 4.8	high	40	全部 400
3	Opus 4.8	medium	40	全部 400
4	Sonnet 4.6	medium	40	全部 400

切换模型（/model claude-sonnet-4-6）和降低 effort 级别（/effort medium）均无效。

根因分析

这是一个 API 参数冲突：

1. Claude Code 工作流运行时强制为每个子代理请求设置 thinking: { type: "disabled" }（子代理只需返回结果，不需要输出思考过程）
2. cc-switch 代理将请求转发到 DeepSeek V4 时，携带或保留了 reasoning_effort 参数
3. 这两个参数互斥——API 不允许「禁用 thinking」的同时设置「reasoning_effort 深度思考」，服务端直接返回 400

关键点：由于 cc-switch 将所有模型（Opus/Sonnet/Haiku）全部映射到 DeepSeek-v4-pro，切换模型无法绕过这个问题——所有请求最终都走同一个后端，冲突始终存在。

预期行为

以下任一方式解决：

1. cc-switch 在转发请求时，当检测到 thinking: { type: "disabled" }，自动剥离 reasoning_effort 参数
2. 或提供一个配置选项，允许用户指定不设置 reasoning_effort 的模型
3. 或至少在日志 / 错误信息中给出明确提示，说明 DeepSeek 模型与工作流功能不兼容，而不是返回原始 API 错误

实际影响

• 工作流功能（含 /deep-research 及所有自定义工作流）完全不可用
• 每次尝试启动 160 个子代理，虽然没有产生 token 消耗，但用户体验很差
• 错误信息不直观，用户难以自行排查

补充说明

• 直接使用 Anthropic 官方 API + Opus 4.8 也有同样问题，但切到 Sonnet 可绕过。而 cc-switch 全映射到 DeepSeek 场景下无路可绕
• DeepSeek API 文档中 reasoning_effort 和 thinking 的互斥关系需要确认——如果 DeepSeek 本身就不支持 thinking: disabled + reasoning_effort 同时存在，则 cc-switch 需要在转发时做兼容处理

[zhddoge-ai]

API Error: 400 thinking options type cannot be disabled when reasoning_effort is set

更新完直接报错了。。。

[johnjxw]

Try this simple workaround, works so far: #3798 (comment)

[bolemmmsl]

API Error: 400 thinking options type cannot be disabled when reasoning_effort is set

更新完直接报错了。。。

+1
我也是这个问题!!

[HerShin5]

这个根因判断基本是对的。这里最好不要只按“模型名/effort 级别”处理，而是在转发层做一层互斥参数清洗：

1. 如果请求里出现 thinking: { type: "disabled" }，就删除 reasoning_effort / output_config.effort 这类推理强度参数。
2. 如果目标后端是 DeepSeek / OpenAI-compatible endpoint，尽量不要把 Claude/Anthropic 风格的 thinking 原样透传，先转换成目标接口真正支持的字段。
3. workflow/subagent 可能和普通 chat 走不同请求路径，建议单独加一个回归测试：普通对话可带 reasoning_effort，但 subagent disabled-thinking 请求不能再带 reasoning_effort。

我这边在看 KiroForge 这类 OpenAI-compatible gateway 路由时也碰到过类似坑：base_url 切换本身不难，真正容易炸的是 Claude-style 参数、OpenAI-style 参数和不同上游模型的字段归一化。这个 issue 很适合直接加 adapter-level sanitizer。

[cmy-hhxx]

claude code更新到2.1.169版本, cc-switch 更新到v3.16.2， 使用Deepseek 模型， claude code的 子代理和workflow 功能失效， 只能在主会话中操作；切换某中转GPT 模型（GPT in cc）貌似可以正常使用子代理和workflow

[ElvaLiu88]

同样的问题，急蹲一个更新

[johnjxw]

同样的问题，急蹲一个更新

try this workaround, works so far: #3798 (comment)