AI工具 on Svtter's Blog

我不喜欢 MiniMax 和火山

Tue, 02 Jun 2026 10:18:18 +0800

准确来说，是我不喜欢这两家的 coding plan 产品。

MiniMax

不喜欢 MiniMax 主要原因是 M2.7 的高分低能。之前感叹 M2.7 性能好，但是偶尔会出现幻觉已经随意改代码的情况。让人不敢用。

最近，M3 打榜很好。但是在 omp 下：

工具调用频繁失败。这意味着 Benchmark 高，harness 没适配，也发挥不出。
存在费用问题。尽管 token plan 看起来便宜，但是每次执行工具都失败，也不顶用啊。

omp（oh my pi）测试结果

BTW：这个问题 kimi k2 的时候还会出现，现在 kimi k2.6 早就没有这个问题了。

此外，还有文件修改出错的问题，我在 omp 上频繁遇到。

opencode

暂未出现问题。

最后：不建议购买。我已经买了一个月，下个月不再续购。

火山引擎 - 字节 coding plan

火山在之前可以说是压根没法用。我大概买了三次，每次都是兴冲冲去，然后失望的退订。

什么，你说最近更新了？我是不会再上当了。

OpenCode LLM Provider 层的三连修：从图片序列化到错误信息丢失

Sat, 23 May 2026 10:00:00 +0800

16 万 star 的 opencode 项目最近连续合并了三个 LLM provider 层的 bug 修复 PR，都是核心维护者 kitlangton 提交的。这三个 bug 不是某次重构引入的回归问题，而是从协议层初始设计就存在的缺陷——只是在最近使用量增长后才暴露出来。

这篇文章分析这三个 bug 的根因、修复方式，以及对开发 AI 工具的启示。

背景：opencode 的 LLM 协议层

opencode 支持多个 LLM provider（OpenAI、Anthropic 等），每个 provider 有自己的协议实现文件，负责把统一的内部格式转换成各 provider 的 API 格式。比如 openai-responses.ts 处理 OpenAI Responses API，anthropic-messages.ts 处理 Anthropic Messages API。

这些协议层有两个核心工作：

下行（lowering）：把 opencode 内部的消息格式转成 provider 的请求格式
上行（parsing）：把 provider 返回的流式响应解析成 opencode 内部的消息格式

三个 bug 分别出在这两个方向上。

Bug 1：Tool Result 中的图片被字符串化

相关 PR：#28754（OpenAI，关闭 #28859）、#28755（Anthropic，关闭 #28861）

问题

当 LLM 调用一个工具（比如截图工具），工具返回的结果可能包含图片（base64 编码）。opencode 的协议层在处理这种 tool result 时，统一调用了 ProviderShared.toolResultText(part)，这个函数把整个 tool result——包括图片——JSON.stringify 成一个字符串。

对于 OpenAI Responses API，这意味着：

1
2


// 修复前：所有 tool result 都变成字符串
{ type: "function_call_output", call_id: "...", output: '{"type":"image","data":"base64..."}' }

一个包含 base64 图片的 tool result 被序列化成字符串塞进了 function_call_output.output。对于 Anthropic Messages API 同样：图片被 JSON.stringify 后塞进了 tool_result.content。

修复

OpenAI 端：新增 lowerToolResultOutput 函数，判断 tool result 的类型：

文本/json/error → 保持原来的字符串行为（向后兼容）
图片 → 以 input_image 结构化块发送

1
2
3
4


// 修复后：图片以结构化格式发送
{ type: "function_call_output", call_id: "...", output: [
 { type: "input_image", image_url: "data:image/png;base64,..." }
]}

Anthropic 端做了类似的处理，图片以 Anthropic 原生的 image 块发送。同时 function_call_output.output 的 schema 从 Schema.String 改成了 Schema.Union([Schema.String, Schema.Array(...)])，既支持旧的字符串格式，也支持新的结构化数组。

根因

这不是某次重构搞坏的，而是初始设计就没考虑到 tool result 会返回非文本内容。toolResultText() 作为一个通用函数，把所有内容都当文本处理——在只有文本 tool result 的世界里这是对的，但世界变了。

Bug 2：Stream Error 信息被吞掉

相关 PR：#28757（关闭 #28860）

问题

LLM provider 的流式响应可能在中途出错（rate limit、context overflow、model overload 等）。opencode 的错误处理代码把这些错误全部压成了通用字符串：

1
2


// 修复前
event.message ?? event.code ?? "OpenAI Responses stream error"

所有错误都变成了 "OpenAI Responses stream error" 这一句话。维护者在 PR 描述里提到，这使得某个 session 的诊断变得极其痛苦——底层原因（base64 图片过大）完全不可见。

OpenAI 的 response.failed 事件更惨：错误信息在 response.error 下面，但代码读的是 event.message 和 event.code（顶层字段），永远是 undefined。

修复

OpenAI 端：先读顶层 event.{code, message, param}，再回退到嵌套的 event.response.error.{code, message, param}。当 code 和 message 同时存在时，用 code 做前缀：

1
2


rate_limit_exceeded: Slow down
server_error: Upstream model unavailable

Anthropic 端：用 error.type 做前缀：

1

overloaded_error: Overloaded

根因

错误处理的代码写得太"乐观"了——假设错误信息总在预期的位置。但 OpenAI 的 API 在不同错误场景下把信息放在不同的嵌套层级，代码没有覆盖所有情况。

Bug 3：Anthropic Tool Result 类型检查不稳定

相关 PR：#28909

问题

这个 PR 在前两个修复合并后才出现。修复了图片 tool result 的结构化发送后，Anthropic 端的类型检查变得不稳定——某些边缘情况下 tool result 的类型推断会失败。

具体来说，tool_result.content 的类型从 string 扩展成了 string | ContentItem[]，但下游代码没有完全适配这个联合类型。

修复

稳定了 Anthropic tool result 的类型检查逻辑，确保联合类型的所有分支都被正确处理。

根因

这是 Bug 1 修复的连锁反应。把 schema 从 Schema.String 改成 Schema.Union 后，类型系统变复杂了，之前不需要处理的分支现在必须处理。

三个 Bug 的关系

1
2
3
4
5
6
7
8


初始设计缺陷
├── tool result 只考虑文本场景
│ ├── Bug 1a: OpenAI 图片被字符串化 (#28754)
│ └── Bug 1b: Anthropic 图片被字符串化 (#28755)
├── error handler 只覆盖理想情况
│ └── Bug 2: stream error 信息丢失 (#28757)
└── Bug 1 修复后类型变复杂
 └── Bug 3: 类型检查不稳定 (#28909)

Bug 1 和 Bug 2 是独立的初始设计缺陷。Bug 3 是 Bug 1 修复的副作用。

对 AI 工具开发的启示

1. 协议层的"够用就行"是最危险的

toolResultText() 在只有文本 tool result 的时候完全够用。但协议层的抽象一旦固定下来，后续扩展就很难——因为所有调用方都依赖当前行为。opencode 的修复保持了向后兼容（文本场景仍然用字符串），但代价是类型变复杂了（Bug 3）。

如果初始设计就把 tool result 分成文本/结构化两条路径，就不会有后面的问题。当然，这是事后诸葛亮——没有人能在第一天就预见到 tool result 会包含图片。

2. 错误处理要假设最坏情况

“错误信息总在预期位置"这个假设在 LLM API 上尤其不成立。各家 provider 的错误格式不一致，同一家 provider 的不同错误类型格式也不一致。写错误处理代码时，应该假设错误信息可能在任何嵌套层级，甚至完全缺失。

3. 修一个 bug 可能暴露下一个

opencode 的三个 PR 形成了一条修复链。修了图片序列化后，类型变复杂了，暴露了类型检查的漏洞。在提交修复时应该考虑到类型变更的下游影响。

4. 观察 bug 的方式决定了修复速度

kitlangton 在 #28757 的 PR 描述里提到，stream error 信息丢失使得某个 session 极其难诊断。如果错误信息是可见的，可能早就发现了。让错误可见是基础设施类代码的重要原则——宁可多输出一点，也不要吞掉信息。

总结

opencode 的这三个 LLM provider bug 都源自初始设计对复杂场景的简化处理。随着 AI 工具能力边界的扩展（从纯文本到多模态），早期"够用就行"的抽象开始出现裂缝。修复的方式是务实的：保持向后兼容的同时扩展新能力。对 AI 工具开发者来说，这是一个提醒——协议层的设计要为未知的变化留余地，错误处理要假设最坏的情况。

OpenCode 配置之外的优化 — 基于插件的优化

Tue, 19 May 2026 10:00:00 +0800

之前我写过一篇 OpenCode 配置优化记录，解决的是 token 消耗和上下文管理的问题。但配置优化管的是"模型怎么跑"，而"代码写到一半质量怎么样"——这件事配置管不了。这篇文章从我开发 opencode-review 插件的过程出发，聊聊 opencode-review 如何在一个 session 内帮助 agent 审查并改进自己的代码，让最终进入 PR 的代码质量更高。

问题：session 内的代码质量谁来把关？

用 OpenCode 写代码时，一个典型的工作流是：agent 在一个 session 内完成编码，然后我 review diff、创建 PR。但我发现一个反复出现的问题：agent 写完的代码经常带着"第一次草稿"的质量问题就进入 PR 了。

这些问题包括：缺少错误处理、安全漏洞、性能不佳的查询、缺失的测试。如果能在 session 内——也就是代码还没提交到 PR 之前——让 agent 自行审查一轮，很多问题在 PR 阶段就不存在了。

这和 CI 阶段的 code review 是不同层次的事情。CI 审查我已经通过 opencode-actions（之前写过一篇介绍文章）实现了——它发生在 PR 创建之后，由 GitHub Actions 触发。后来 Cloudflare 也在工程博客中分享了类似思路：用 OpenCode 构建大规模 AI code review。而 opencode-review 要解决的是更早的阶段：在 session 内、在 PR 之前，让 agent 在写完代码后主动审查并修复问题。两者互补：opencode-review 提升进入 PR 的代码质量基线，opencode-actions 则作为最后一道关卡。

具体来说，有三个需要解决的子问题：

审查覆盖不全：agent 生成的代码可能引入安全漏洞、性能问题，但它自己不会主动检查这些
缺乏系统性的审查框架：没有结构化的维度来评估代码，容易只关注功能正确性而忽略安全和性能
发现问题和修复之间缺乏闭环：即使 agent 发现了问题，也需要一个机制来自动修复，而不是等人来指出

opencode-review 的设计

基于这三个问题，我设计了 opencode-review：一个结构化的代码审查插件。

多维度分析

第一个设计决策是为什么分五个维度，而不是一个笼统的"好不好"的评价。

代码质量不是一个单一维度。一段代码可能功能正确、性能优秀，但存在 SQL 注入漏洞；也可能安全无害，但缺少测试覆盖。把它们混在一起评估，结果必然模糊。

学术上，Modern Code Review (MCR) Survey 收集了 2013-2025 年间的代码审查研究，提出了一个分类体系，涵盖缺陷检测、安全审查、性能分析、可维护性评估等多个任务维度。Ericsson 的研究团队在 Automated Code Review Using Large Language Models at Ericsson 中也验证了：按维度拆分的审查比笼统审查在工业场景中更有效。

opencode-review 的五个维度——code-quality、security、performance、testing、documentation——对应的就是这些研究中识别出的核心审查维度。每个维度可以独立开关，因为不同项目关注的重点不同：一个内部工具可能不需要文档审查，但一个安全敏感的服务不能跳过 security 维度。

严重性分级

第二个设计决策是为什么分三级严重性（critical / suggestion / highlight）。

这来自静态分析工具领域的经验教训。安全工具和 linter 长期面临一个问题：alert fatigue（告警疲劳）。当所有问题都被标记为同等重要时，开发者会开始忽略它们。Veracode 的研究指出，告警疲劳导致的直接后果是真正的严重问题被淹没在噪音中。

分三级的逻辑是：

critical：必须修复（安全漏洞、逻辑错误、资源泄漏）
suggestion：建议改进（代码可读性、性能优化、更好的实践）
highlight：值得注意（风格一致性、潜在的改进空间）

这样开发者可以优先处理 critical，而不会在一堆 “consider refactoring” 中错过一个 SQL 注入。

自动修复链

第三个设计决策是为什么 critical 问题要自动触发修复，而不是仅仅报告。

这是一个有争议的设计。传统的审查工具通常是"只报告不修复"，把修复留给开发者。但 opencode-review 的场景不同——它审查的代码本身就是 AI agent 刚写完的，让另一个 agent 去修复合情合理。

学术上这属于 Automated Program Repair (APR) 的范畴。A Survey of LLM-based Automated Program Repair (arXiv 2506.23749) 综述了 2022-2025 年间的 63 个 LLM-based APR 系统，分为四种范式。其中"分析增强"（analysis-augmented）范式——先用静态分析定位问题，再用 LLM 生成修复——被证明是最有效的。opencode-review 的 auto-fix chain 本质上就是这个范式：reviewer 发现 critical issue → 定位问题位置 → spawn fixer sub-agent → 生成最小化修复。

ICSE 2025 的一篇论文也指出，LLM 在 APR 中的关键挑战是目标对齐（objective alignment）——修复的目标不是"生成看起来合理的代码"，而是"精确解决报告的问题"。这也是为什么 opencode-review 的 fixer 被设计为 minimal fix——只做最小的修改来解决问题，不重写、不重构、不"顺手"做其他改动。

自动审查的隐性收益：代码质量基线的持续提升

上面三个设计解决的是"发现问题"和"修复问题"。但自动审查还有一个容易被忽略的好处：它在不经意间持续提升了代码质量的基线。

这个效果来自两个机制：

第一，审查反馈对写代码者的塑造。 FSE 2022 的研究在两年的工业实践中发现，当开发者知道自己的代码会被自动审查时，他们会在写代码阶段就更有意识地遵循规范——因为事后被指出来的成本变低了，提前写好的收益变高了。这是一种 nudge effect（助推效应）。在 AI agent 的场景下，这个效应更强：agent 在一个 session 中写了代码、被 review 指出问题、修复、再次被审查——这个循环在同一 session 内就能完成多轮。每一轮反馈都在修正 agent 的输出倾向，相当于一个隐式的 fine-tuning 过程。

第二，自动修复的直接质量累积。 critical issue 被自动修复意味着每一轮提交的代码质量都比没有审查时更高。这不是一次性的改进，而是持续的。就像代码库中的 lint 规则一样——一开始只是禁止明显错误，但随着规则积累，代码库的整体风格和质量在不知不觉中被拉高了。auto-fix chain 做的事情类似：安全漏洞被自动堵上、资源泄漏被自动修复、缺失的测试被自动补充。时间一长，代码库的质量基线自然高于没有自动审查的情况。

简单说：审查不是目的，质量提升才是。自动审查把"事后检查"变成了"过程中提升"。

Cooldown 机制

还有一个小的设计细节：cooldown_seconds。

auto-review 在 session idle 时触发，但 idle 事件可能频繁触发（比如 agent 在等待用户确认时也会 idle）。没有 cooldown 的话，同一份代码可能被审查好几次，浪费 token。120 秒的默认冷却期是一个经验值——足够让一轮修改完成，又不会等太久。

opencode-froggy：另一种思路

opencode-froggy（85 Stars，昨天刚发 0.12.0）提供了另一种思路。它不做结构化的多维度审查，而是提供 6 个专用 agent（architect、code-reviewer、code-simplifier、doc-writer、partner、rubber-duck）和一套灵活的 hooks 系统。

Froggy 的 code-reviewer 是一个通用的只读审查 agent，不区分维度和严重性。但它的 hooks 系统很强——你可以配置 session.idle 事件自动跑 lint、自动格式化、甚至在写入敏感文件时拦截：

1
2
3
4
5
6
7
8


---
hooks:
 - event: session.idle
 conditions: [hasCodeChange, isMainSession]
 actions:
 - bash: "npm run lint --fix"
 - command: simplify-changes
---

这是一种"开发者自己编排流程"的思路，和 opencode-review 的"开箱即用的结构化审查"形成互补。

对比

	opencode-review	opencode-froggy
审查方式	结构化多维度分析	通用 code-reviewer agent
严重性分级	critical / suggestion / highlight	无
自动修复	critical issue → fixer sub-agent	code-simplifier，需手动触发
触发方式	session idle + cooldown	hooks 配置
自定义规则	custom_rules 支持项目规范	无
其他功能	无	6 agent + hooks + gitingest + 区块链

两个不冲突，可以一起装。我的建议是：opencode-review 做日常自动审查，froggy 的 hooks 做流程编排。

插件安装

两个插件的安装方式不同。

opencode-froggy 支持通过 npm 直接安装，在 opencode.json 中添加即可：

1
2
3


{
 "plugin": ["opencode-froggy"]
}

opencode-review 目前 npm 安装尚未上线，需要 clone 后本地链接：

1
2
3
4
5
6
7
8
9


# clone 到任意位置
git clone https://github.com/sun-praise/opencode-review.git /path/to/opencode-review

# 项目级安装（推荐）
mkdir -p .opencode/plugins
ln -s /path/to/opencode-review/src/index.ts .opencode/plugins/opencode-review.ts

# 或全局安装
ln -s /path/to/opencode-review/src/index.ts ~/.config/opencode/plugins/opencode-review.ts

opencode-review 还需要创建 .opencode/review.json 来配置审查行为：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


{
 "language": "zh",
 "dimensions": ["code-quality", "security", "performance", "testing", "documentation"],
 "trigger": {
 "auto_on_idle": true,
 "cooldown_seconds": 120
 },
 "custom_rules": [
 "All API endpoints must have error handling",
 "Database queries must use parameterized statements"
 ]
}

其他值得关注的插件

生态已经超过 70 个插件了，再推荐几个：

opencode-worktree：零摩擦的 git worktree 管理
opencode-notify：任务完成时发送系统通知
dynamic-context-pruning：自动裁剪过时的工具输出，优化 token 使用
envsitter-guard：阻止 agent 读取 .env 敏感文件

完整列表见 awesome-opencode。

参考文献

Modern Code Review (MCR) Survey — 2013-2025 代码审查研究综述
Automated Code Review Using LLMs at Ericsson — LLM 辅助代码审查的工业实践
A Survey of LLM-based Automated Program Repair — LLM 自动修复综述，覆盖 63 个系统
Aligning the Objective of LLM-Based Program Repair (ICSE 2025) — LLM 修复的目标对齐问题
Understanding Automated Code Review Process (FSE 2022) — 两年工业环境自动审查的经验总结
AI-Assisted Assessment in Modern Code Review (AIware 2024) — AutoCommenter 的部署与评估
Code Review Agent Benchmark (c-CRAB) — AI agent 代码审查基准测试
opencode-actions - 一个 coding review agent — 基于 OpenCode 构建的 GitHub Action，CI 阶段的 code review
Cloudflare: Orchestrating AI Code Review at Scale — Cloudflare 用 OpenCode 构建大规模 AI 审查

DeepSeek + Claude Code: Thinking Block 兼容性问题分析

Thu, 30 Apr 2026 15:00:00 +0800

问题描述

在 Claude Code 中直接使用 DeepSeek 模型（如 deepseek-v4-flash）时，开启 extended thinking 后，多轮对话会触发 400 错误：

1

Bad Request: {"error":{"message":"The content[].thinking in the thinking mode must be passed back to the API.","type":"invalid_request_error","param":null,"code":"invalid_request_error"}}

根因分析

调用链

1

Claude Code → DeepSeek Anthropic 兼容端点 (https://api.deepseek.com/anthropic)

协议不兼容

根据 DeepSeek Anthropic API 兼容文档，兼容情况如下：

Message 字段	支持状态
`content[].thinking`	✅ Supported
`content[].redacted_thinking`	❌ Not Supported

Claude Code 在 extended thinking 模式下的多轮对话中，会忠实地将上一轮返回的所有 thinking blocks（包括 redacted_thinking 类型）原样回传给 API。DeepSeek 不识别 redacted_thinking，因此报 400。

此外，DeepSeek 的 thinking block 格式与 Anthropic 原生协议存在差异，在 tool_use 场景下的回传逻辑也不完全兼容。

核心矛盾

Anthropic API 要求：extended thinking 模式下，content[].thinking 和 content[].redacted_thinking 必须原封不动回传
DeepSeek 兼容层：只支持 thinking，不支持 redacted_thinking
Claude Code 行为：按 Anthropic 协议硬编码，不区分目标端点类型

社区反馈

这是一个广泛存在的社区问题，几乎所有 CC 代理/路由项目都遇到了：

Issue	项目	标题
#1	cc-use	DeepSeek Thinking Mode Error: `content[].thinking` Must Be Passed Back
#878	openclaude	DeepSeek V4: reasoning_content must be passed back (400) on tool_calls
#1355	claude-code-router	CCR 代理 deepseek V4 思考时返回 400
#4543	new-api	ClaudeCode 接入 DeepSeek V4 遇到 400 reasoning_content 报错
#355	9router	DeepSeek API Error 400 – Missing reasoning_content
#16748	hermes-agent	DeepSeek /anthropic: stripped thinking blocks cause HTTP 400 on replay
#2414	cc-switch	Claude 使用 cc-switch 配置 deepseek-v4-pro，无法识别字段
#174	cc-haha	/compact 命令在使用 DeepSeek API 时无法工作

DeepSeek 官方回应

零回应。 也没必要回应。

首先，DeepSeek 没有公开的 API issue 仓库，所有反馈均发生在第三方项目中，无 DeepSeek 官方人员参与任何讨论。
其次，是否将 Anthropic 作为标准来兼容，我想 DeepSeek 应该是犹豫的。

临时解决方案

关闭 extended thinking — 用 DeepSeek 时在 CC 中关闭 thinking 模式
使用代理过滤 — 在 CC 和 DeepSeek 之间加一层代理，过滤掉 redacted_thinking blocks
换模型 — 非 thinking 场景使用 DeepSeek，thinking 场景使用 Anthropic 原生模型

OpenCode 为什么没有这个问题？

OpenCode (opencode-ai/opencode) 在架构上天然规避了这个问题，并非专门"修复"。

关键在 internal/llm/provider/anthropic.go 的 convertMessages 方法（第 60-119 行）：

构建 assistant 消息时，只回传 TextContent（文本）和 ToolCall（工具调用）
完全忽略 ReasoningContent（thinking 内容），不放入 messages
thinking 内容仅通过 stream 的 thinking_delta 事件在 UI 展示，不会回传给 API

对比 Claude Code 的行为：

	Claude Code	OpenCode
thinking 回传	✅ 忠实回传所有 thinking blocks（含 redacted_thinking）	❌ 不回传 thinking blocks
架构原因	遵循 Anthropic API 规范，要求原样回传	自行管理对话状态，thinking 仅用于 UI 展示
DeepSeek 兼容性	❌ 触发 400（redacted_thinking 不被识别）	✅ 不受影响（根本不传 thinking）

结论：OpenCode 避开问题的方式是以不遵循 Anthropic extended thinking 规范为代价的。 这种做法对 DeepSeek 等第三方兼容端点友好，但如果未来需要 Anthropic 原生的 thinking 上下文保持能力，可能需要重新实现。

不回传 thinking blocks 是否会影响 DeepSeek 性能？

基本不会，原因：

thinking blocks 是模型的内部 scratchpad，不是最终输出。对话历史里的文本回复和工具调用已经保留了关键决策和结论
DeepSeek 的 reasoning 更接近 OpenAI 的模式——每轮独立生成，不像 Anthropic 那样强依赖跨轮回传来保持推理连贯性
OpenCode 的大量实际使用也印证了这一点——社区用户在 OpenCode 中用 DeepSeek thinking 模式跑多轮对话，没有反馈过推理质量下降的问题

真正可能受影响的极端场景：超长多轮任务中，模型可能重复之前已经推理过的结论。但在大多数实际使用中影响可忽略。

Issue	标题	状态
#10199	API Error 400 - Thinking Block Modification Error	Open (oncall)
#51985	thinking block missing in multi-turn conversations	Open
#20692	thinking blocks order error on first tool use	Open (oncall)
#54482	Thinking blocks stripped from context every turn (Opus 4.7)	Open

如何解决 opencode 中 deepseek 模型的 reasoning 问题

Fri, 24 Apr 2026 12:23:58 +0800

当我们使用 deepseek-reasoner 的时候，往往会遇到这个问题：

1

The reasoning_content' in the thinking mode must be passed back to the API.

更新

现在两个问题都已经被 opencode 官方解决。用户只需要安装最新的 opencode，通过 deepseek provider 即可使用，无需额外配置。

1
2
3
4
5
6


问题1
The reasoning_content' in the thinking mode must be passed back to the API.

问题2
Bad Request: {"error":{"message":"The content[].thinking in the thinking mode must be passed back to the
API.","type":"invalid_request_error","param":null,"code":"invalid_request_error"}}

这两个问题已经被官方解决。安装 1.14.29 以及以上版本即可。

以下旧的解决方法：

怎么解决呢？也容易。

如何配置

添加 provider 信息到配置中：

.config/opencode/opencode.json 或者 .config/opencode/opencode.jsonc

修改 provider 部分为：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


{
 "provider": {
 "deepseek": {
 "npm": "@ai-sdk/anthropic",
 "name": "DeepSeek",
 "options": {
 "baseURL": "https://api.deepseek.com/anthropic",
 "apiKey": "<apikey>"
 },
 "models": {
 "deepseek-v4-pro": {
 "name": "DeepSeek-V4-Pro",
 "limit": {
 "context": 1048576,
 "output": 262144
 },
 "options": {
 "thinking": {
 "type": "enabled",
 "budgetTokens": 8192
 }
 }
 },
 "deepseek-v4-flash": {
 "name": "DeepSeek-V4-Flash",
 "limit": {
 "context": 1048576,
 "output": 262144
 },
 "options": {
 "thinking": {
 "type": "enabled",
 "budgetTokens": 8192
 }
 }
 }
 }
 }
 }
}

如何使用

选择 deepseek 模型。

效果。

补充

这个方式无法解决问题

Bad Request: {"error":{"message":"The content[].thinking in the thinking mode must be passed back to the API.","type":"invalid_request_error","param":null,"code":"invalid_request_error"}}

如果你遇到这个问题，还需要等待 opencode 去修复。

相关文章：DeepSeek + Claude Code: Thinking Block 兼容性问题分析 — 分析了 Claude Code 使用 DeepSeek 时 extended thinking 模式下多轮对话触发 400 错误的根因，以及社区解决方案。