@henjicc/ai-sdk 0.2.8 → 0.3.0

package/docs/llm-adaptation/README.md

@@ -1,139 +1,139 @@
-# LLM 供应商适配清单（总索引）
-
-| 项目 | 内容 |
-|---|---|
-| 最后更新 | 2026-08-28 |
-| 覆盖供应商 | 火山引擎（Doubao）、Kimi（Moonshot）、智谱 GLM、DeepSeek、小米 MiMo、阿里云百炼（Qwen）、MiniMax |
-| 覆盖模型 | 7 家供应商的当前旗舰文本/多模态系列；供应商专属模型见各自文档内的“模型清单” |
-
-## 一、这是什么，和 `docs/model-adaptation/` 有什么不一样
-
-`../model-adaptation/` 管的是**生成模型**（图片/视频/音频）：每个 (模型, 供应商) 组合对应一份 SDK catalog 定义，包含参数 schema、提交/轮询/结果解析与计价，文档和代码是 1:1 影子关系，所以按"一个模型一个文件夹、每个支持它的供应商一份文件"组织。
-
-LLM（本目录）是完全不同的架构：
-
-- **供应商和模型是用户运行时自建的**（设置页手填 `providerId`/`baseUrl`/API Key，模型 ID 靠手填或探测），不是代码里为每个模型写一份文件。三个消费方——智能助手 Agent、画布文本处理节点、提示词优化——共用同一份 `LlmConfigState`（`providers` + `models`），走同一条 `runModelStep` → AI SDK `streamText` 管线（[modelStep.ts](../../src/llm/modelStep.ts)、[SDK modelStep.ts](../../src/llm/sdk/modelStep.ts)）。
-- 真正需要"文档变了就要回去改代码"的东西只有两处，且都是**供应商级**而不是模型级：
-  1. [providerProtocol.ts](../../src/llm/providerProtocol.ts) 里按 `providerId` 收口的协议怪癖（额外认证头、请求体字段改名）
-  2. [providerAdapter.ts](../../src/llm/sdk/providerAdapter.ts) 里的 `ModelStepProviderAdapterRegistry`——按协议注册的适配器
-- 因此本目录按**供应商**组织，不按模型：`供应商/<供应商名>.md`，每份文件自包含该供应商的 Base URL、协议现状、模型速查表、思考参数、联网搜索能力和已知怪癖。
-
-```
-docs/llm-adaptation/
-├── README.md              # 本文件：协议矩阵 + 供应商速查 + 代码现状
-├── 文档采集手册.md          # 怎么发现/抓取 LLM 供应商文档（调研前先看）
-└── 供应商/
-    ├── 火山引擎.md
-    ├── Kimi.md
-    ├── 智谱GLM.md
-    ├── DeepSeek.md
-    ├── 小米MiMo.md
-    ├── 百炼Qwen.md
-    └── MiniMax.md
-```
-
-## 二、代码现状（先看这个，再看下面的协议矩阵）
-
-### 2.1 已经落到代码里的（2026-08-29）
-
-| 能力 | 落点 | 说明 |
-|---|---|---|
-| 内置模型能力目录 | [modelCatalog.ts](../../src/llm/modelCatalog.ts) + [modelCatalogEntries.ts](../../src/llm/modelCatalogEntries.ts) | 本目录里核对过的模型按 ID 登记输入模态、工具调用、结构化输出、上下文与输出上限。添加模型（手动、探测、预设三个入口）时自动标好，用户不用自己勾；存量配置在归一化时补标一次并盖 `catalogId` 戳，之后用户的手工修改不再被覆盖 |
-| 内置供应商预设 | [providerPresets.ts](../../src/llm/providerPresets.ts) | 七家供应商 + 派欧云的 Base URL、思考默认值、推荐模型打包，设置页「管理供应商」里选一下即可建好 |
-| 思考参数按供应商翻译 | [providerReasoningRequest.ts](../../src/llm/providerReasoningRequest.ts) | 把统一的五档强度映射到各家实际接受的字段与取值（第六节那张表就是它的数据来源），原生流式与 SDK 模型步骤两条路径共用 |
-| Responses API 运行时 | [provider.ts](../../src/llm/sdk/provider.ts) + [providerPresets.ts](../../src/llm/providerPresets.ts) | `openai-responses` 与 Chat 并存；预制供应商按“供应商端点 × 具体模型”自动选择，用户不需要也不能逐模型手选协议 |
-
-改动前的状态：思考模式下拉**只对 DeepSeek 有效**，其余六家发出去的请求里根本没有对应字段；而且两条路径给 DeepSeek 发的还不一样（原生流式发 `reasoning: true`，不是官方要求的 `thinking` + `reasoning_effort`）。
-
-### 2.2 协议选择已经收进 SDK
-
-- `LlmApiProtocol` 已包含 `openai-compatible`（Chat Completions）与 `openai-responses`。
-- `ModelStepProviderAdapterRegistry` 同时注册两条真实运行时；Responses 通过官方 `@ai-sdk/openai` 转换请求与标准 SSE 事件。
-- 协议不是供应商级一刀切：例如智谱国内只有 `glm-5.3` 默认 Responses，`glm-5.3-flash` / `glm-5v-turbo` 保持 Chat；派欧云聚合网关也不会因为底层模型原厂支持 Responses 就被误切换。
-- 预制供应商的协议控件不在界面显示；自定义未知端点才允许选择 Chat / Responses。Anthropic 没有运行时实现，也不在界面显示，存量伪配置继续归一化成 OpenAI Chat。
-
-当前已自动走 Responses 的预制组合：DeepSeek V4 Pro / Flash / Vision、火山引擎目录内三款 Doubao、百炼 Qwen3.8-Max、MiniMax-M3、智谱中国大陆 GLM-5.3。Kimi、MiMo、Groq、派欧云以及未确认的智谱模型继续走 Chat。
-
-### 2.3 Responses 事件契约与验证证据
-
-| 官方事件/边界 | SDK 统一结果 | 验证 |
-|---|---|---|
-| `response.created` | 记录 response id，不向业务层制造文本事件 | 官方形状 fixture |
-| `response.output_item.added` + `response.output_text.delta` | `TextDelta` 与最终文本 | [openai-responses-text.json](../../tests/fixtures/llm/openai-responses-text.json) |
-| `response.function_call_arguments.delta` + function item done | 既有 `ToolCall`，工具仍由助手运行时执行 | runtime 工具调用精确测试 |
-| `response.completed` / `response.incomplete` | finish reason、usage、缓存与推理 token | runtime 精确测试 |
-| `response.failed` / SSE `error` | 结构化 provider error，不返回半成功结果 | runtime 负例测试 |
-| AbortSignal / 断流 | 取消请求并释放读取器，统一为 `task_cancelled` | runtime 取消测试 |
-
-Responses 请求统一下发 `store: false`：助手自己的会话存储仍是唯一事实来源，同时兼容 DeepSeek 不支持 `store` / `previous_response_id` 的无状态实现。
-
-### 2.4 一个容易踩的坑：两条请求路径能表达的输入模态不同
-
-- 画布文本处理、提示词优化走**原生流式路径**（[streaming.ts](../../src/llm/streaming.ts)），`image_url` / `video_url` / `input_audio` 三种内容块都能发。
-- 智能助手走 **AI SDK 模型步骤**（[provider.ts](../../src/llm/sdk/provider.ts)），当前转换器只能表达 **image 与 audio**，视频会被 `assertInputModalities` 拦下。
-
-所以模型能力目录里的 `input` 记的是"**本项目当前请求路径下真实可用**"的模态，不是模型宣传的模态。DeepSeek 视觉模型已经因 Responses 接通而开放图片；智能助手的视频输入仍会在协议边界明确阻断，不会降级成文本地址造成静默失效。
-
-## 三、本项目的协议接入优先级（产品决策，不是能力强弱排序）
-
-新写协议适配器、给某个供应商挑协议时，按下面顺序取舍——这是本项目的既定优先级，**不因某家供应商官方推荐哪个协议就单独提高它的顺序**（MiniMax 官方推荐 Anthropic，但本项目仍按下表顺序执行，见 [MiniMax.md 第 6 节](供应商/MiniMax.md)）：
-
-1. **Responses API 优先**。结构化输出、上下文管理、内置工具（联网搜索等）通常最先在这条协议上落地，是新协议适配器要覆盖的首要目标。
-2. **Chat Completions 兜底**。Responses 未确认的供应商/模型继续用它，不阻塞可用性。
-3. **Anthropic Messages API 暂不实现、不显示**。官方支持面只作为未来资料保留，不向用户暴露一个不能工作的选项。
-
-每个供应商文件的「摘要」表里都有一行"接入优先级"，按这三条给出该供应商的具体落点（例如 Kimi/百炼没有 Anthropic，MiMo 没有 Responses API，落点就相应收窄）。
-
-## 四、协议矩阵（官方支持面，供路线图参考）
-
-| 供应商 | Chat Completions | Responses API | Anthropic Messages API | 联网搜索可用协议 |
-|---|---|---|---|---|
-| [火山引擎](供应商/火山引擎.md) | ✅ | ✅ | ❌ 官方未提供 | **仅 Responses API**（Chat API 完全不支持内置工具） |
-| [Kimi](供应商/Kimi.md) | ✅ | ❌ 官方未提供 | ❌ 官方未提供 | Chat Completions（`$web_search`，官方标注"近期不建议用于生产"） |
-| [智谱 GLM](供应商/智谱GLM.md) | ✅（`glm-5.3-flash` 目前仅确认此协议） | ✅（仅 `glm-5.3`） | ✅（仅 `glm-5.3`） | Chat Completions 工具 / 独立 Web Search API 均可，GLM-Coding-Plan 订阅账号暂时只能走 Chat Completions |
-| [DeepSeek](供应商/DeepSeek.md) | ✅ | ✅ | ✅ | **仅 Responses API**（Chat Completions 不支持 `web_search`） |
-| [小米 MiMo](供应商/小米MiMo.md) | ✅ | ❌ 官方未提供 | ✅ | **仅 Chat Completions**（官方原文："其他 API 协议暂不支持"），且需先在控制台激活插件 |
-| [百炼 Qwen](供应商/百炼Qwen.md) | ✅ | ✅ | ❌ 官方未提供 | 两条协议都支持，但 Responses 路径能力更全（额外有 `web_extractor`/`code_interpreter`） |
-| [MiniMax](供应商/MiniMax.md) | ✅ | ✅ | ✅（**官方推荐首选**） | Anthropic Messages + Responses API 均支持，纯 Chat Completions 不支持 |
-
-**两条对制定路线图有直接影响的结论**：
-
-1. **7 家里有 6 家原生支持 Responses API 或与之等价的能力**（火山引擎、GLM-5.3、DeepSeek、百炼、MiniMax 直接支持 Responses API；Kimi、小米 MiMo 没有 Responses API，只能走 Chat Completions）——这与第三节"Responses API 优先"的既定优先级吻合，先做 Responses API 适配器能覆盖到的供应商数量最多，也是联网搜索等内置工具最主要的解锁路径。
-2. **联网搜索能不能用，很大程度上取决于选了哪个协议**，不是"这家供应商支不支持"这么简单：火山引擎和 DeepSeek 的联网搜索**必须**走 Responses API，MiMo 的联网搜索**必须**走 Chat Completions，MiniMax 的联网搜索 Anthropic/Responses 都行但纯 Chat Completions 不行。做 Responses API 适配器时可以顺带核对一下能不能同时把对应供应商的联网搜索也接上，性价比更高。
-3. **4 家（DeepSeek、GLM、MiMo、MiniMax）原生支持 Anthropic Messages API，MiniMax 官方甚至推荐它作为首选**——这是资料记录，供未来"顺手就能接"时参考，**不代表应该优先做**：按第三节的既定优先级，Anthropic 排在 Responses API 和 Chat Completions 之后，不单独立项。
-
-## 五、供应商速查表
-
-| 供应商 | Base URL（OpenAI 兼容） | 旗舰模型 | 上下文 | 价格量级（输入/输出，元/百万 tokens） |
-|---|---|---|---|---|
-| 火山引擎 | `https://ark.cn-beijing.volces.com/api/v3` | `doubao-seed-evolving` | 1024K | 6 / 30 |
-| Kimi | `https://api.moonshot.cn/v1` | `kimi-k3` | 1,048,576 | 20 / 100 |
-| 智谱 GLM | 国内 `https://open.bigmodel.cn/api/paas/v4`；国际 `https://api.z.ai/api/paas/v4` | `glm-5.3` / `glm-5.3-flash`（原生多模态） | 1M | 国内 GLM-5.3：8 / 28；Flash：CNY 0.8 / 2.8、USD 0.15 / 0.50 |
-| DeepSeek | `https://api.deepseek.com` | `deepseek-v4-pro` | 1M | 4.5 / 13.5（闲时） |
-| 小米 MiMo | `https://api.xiaomimimo.com/v1` | `mimo-v2.5-pro` | 1M | 3 / 6 |
-| 百炼 Qwen | `https://{WorkspaceId}.cn-beijing.maas.aliyuncs.com/compatible-mode/v1` | `qwen3.8-max` | ~1M | 12 / 36 |
-| MiniMax | `https://api.minimaxi.com/v1` | `MiniMax-M3` | 1,000,000 | 2.10 / 8.40（≤512K，促销价） |
-
-价格列只取旗舰模型的标准档，完整价格表（含缓存命中价、批量价、区域差异）见各供应商文件；价格会变，不要把这张表当长期不变的计费合同。
-
-## 六、思考参数速查（各家字段名一致但取值集合不同，不要共用常量）
-
-| 供应商 | 字段 | 取值 | 默认 | 能否关闭 |
-|---|---|---|---|---|
-| 火山引擎 | `reasoning_effort` | `none`/`minimal`/`low`/`medium`/`high`/`xhigh`/`max`（7 档） | `high` | 可以（`thinking` 开关） |
-| Kimi | `reasoning_effort` | `low`/`high`/`max` | `max` | **不可以**，K3 始终思考 |
-| 智谱 GLM | `reasoning_effort` + `thinking` | `low`/`high`/`max`（`glm-5.3`、`glm-5.3-flash`） | `max` | GLM-5.3 / Flash 不可以；GLM-5V-Turbo 可以 |
-| DeepSeek | `reasoning_effort` + `thinking.type` | 字符串透传，无固定枚举 | — | 可以 |
-| 小米 MiMo | 无强度分级，仅 `reasoning_content` 回传约定 | — | — | 未见明确开关文档 |
-| 百炼 Qwen | `enable_thinking`（布尔） | `true`/`false` | 视模型而定 | 可以 |
-| MiniMax | 仅 Anthropic 协议下确认为原生 `thinking` 内容块；Chat/Responses 路径的思考强度字段未在公开文档中找到，接入 Responses API 时需要单独实测确认 | — | — | 视协议而定 |
-
-## 七、维护方式
-
-- **动手前**：先读 [文档采集手册.md](文档采集手册.md)——LLM 供应商的文档比生成模型更碎，同一模型的思考参数、联网搜索、工具调用往往各自独立成页，只看模型主页会漏掉大半内容。
-- **新增供应商**：在本文件协议矩阵、供应商速查表、思考参数速查三张表里各加一行 → 在 `供应商/` 下新建 `<供应商名>.md`，按现有文件的结构写（摘要 → Base URL → 协议现状 → 模型清单 → 思考模式 → 联网搜索/工具 → 适配要点 → 原始链接索引）→ 再把它落到代码的三处：[modelCatalogEntries.ts](../../src/llm/modelCatalogEntries.ts) 加模型条目、[providerPresets.ts](../../src/llm/providerPresets.ts) 加供应商预设、思考参数写法与通用 `reasoning_effort` 不同时在 [providerReasoningRequest.ts](../../src/llm/providerReasoningRequest.ts) 加一条映射。
-- **文档与代码的对齐由测试守着**：`modelCatalog.test.ts` 断言每条目录条目的 `docs` 路径真实存在，`providerPresets.test.ts` 断言每个预设的推荐模型都能在目录里查到、且有专门思考写法的供应商 id 与映射表一致。改了文件名或 providerId 而没同步，测试会红。
-- **只登记文档明确写出的能力**：目录里的每一项都要能在对应供应商文档里找到出处，文档没写的保持保守取值（false / null），交给用户手工勾或走「验证此模型」动态探测，不靠模型名猜。
-- **更新已有供应商**：直接改对应文件，同步更新该文件与本文件头部的"最后更新"。
-- **信息来源要求**：每条参数/价格都要能追溯到文件末尾"原始链接索引"里的某个链接；需要登录才能看到的页面必须标注，且优先尝试公开镜像（如 `help.aliyun.com` 之于百炼控制台）而不是直接要求登录。
-- **代码侧一旦补上新协议适配器**：回来更新本文件第二节"代码现状"，把对应协议从"资料"状态标记为"已实现"，否则这份文档会长期落后于代码。
+# LLM 供应商适配清单（总索引）
+
+| 项目 | 内容 |
+|---|---|
+| 最后更新 | 2026-08-28 |
+| 覆盖供应商 | 火山引擎（Doubao）、Kimi（Moonshot）、智谱 GLM、DeepSeek、小米 MiMo、阿里云百炼（Qwen）、MiniMax |
+| 覆盖模型 | 7 家供应商的当前旗舰文本/多模态系列；供应商专属模型见各自文档内的“模型清单” |
+
+## 一、这是什么，和 `docs/model-adaptation/` 有什么不一样
+
+`../model-adaptation/` 管的是**生成模型**（图片/视频/音频）：每个 (模型, 供应商) 组合对应一份 SDK catalog 定义，包含参数 schema、提交/轮询/结果解析与计价，文档和代码是 1:1 影子关系，所以按"一个模型一个文件夹、每个支持它的供应商一份文件"组织。
+
+LLM（本目录）是完全不同的架构：
+
+- **供应商和模型是用户运行时自建的**（设置页手填 `providerId`/`baseUrl`/API Key，模型 ID 靠手填或探测），不是代码里为每个模型写一份文件。三个消费方——智能助手 Agent、画布文本处理节点、提示词优化——共用同一份 `LlmConfigState`（`providers` + `models`），走同一条 `runModelStep` → AI SDK `streamText` 管线（[modelStep.ts](../../src/llm/modelStep.ts)、[SDK modelStep.ts](../../src/llm/sdk/modelStep.ts)）。
+- 真正需要"文档变了就要回去改代码"的东西只有两处，且都是**供应商级**而不是模型级：
+  1. [providerProtocol.ts](../../src/llm/providerProtocol.ts) 里按 `providerId` 收口的协议怪癖（额外认证头、请求体字段改名）
+  2. [providerAdapter.ts](../../src/llm/sdk/providerAdapter.ts) 里的 `ModelStepProviderAdapterRegistry`——按协议注册的适配器
+- 因此本目录按**供应商**组织，不按模型：`供应商/<供应商名>.md`，每份文件自包含该供应商的 Base URL、协议现状、模型速查表、思考参数、联网搜索能力和已知怪癖。
+
+```
+docs/llm-adaptation/
+├── README.md              # 本文件：协议矩阵 + 供应商速查 + 代码现状
+├── 文档采集手册.md          # 怎么发现/抓取 LLM 供应商文档（调研前先看）
+└── 供应商/
+    ├── 火山引擎.md
+    ├── Kimi.md
+    ├── 智谱GLM.md
+    ├── DeepSeek.md
+    ├── 小米MiMo.md
+    ├── 百炼Qwen.md
+    └── MiniMax.md
+```
+
+## 二、代码现状（先看这个，再看下面的协议矩阵）
+
+### 2.1 已经落到代码里的（2026-08-29）
+
+| 能力 | 落点 | 说明 |
+|---|---|---|
+| 内置模型能力目录 | [modelCatalog.ts](../../src/llm/modelCatalog.ts) + [modelCatalogEntries.ts](../../src/llm/modelCatalogEntries.ts) | 本目录里核对过的模型按 ID 登记输入模态、工具调用、结构化输出、上下文与输出上限。添加模型（手动、探测、预设三个入口）时自动标好，用户不用自己勾；存量配置在归一化时补标一次并盖 `catalogId` 戳，之后用户的手工修改不再被覆盖 |
+| 内置供应商预设 | [providerPresets.ts](../../src/llm/providerPresets.ts) | 七家供应商 + 派欧云的 Base URL、思考默认值、推荐模型打包，设置页「管理供应商」里选一下即可建好 |
+| 思考参数按供应商翻译 | [providerReasoningRequest.ts](../../src/llm/providerReasoningRequest.ts) | 把统一的五档强度映射到各家实际接受的字段与取值（第六节那张表就是它的数据来源），原生流式与 SDK 模型步骤两条路径共用 |
+| Responses API 运行时 | [provider.ts](../../src/llm/sdk/provider.ts) + [providerPresets.ts](../../src/llm/providerPresets.ts) | `openai-responses` 与 Chat 并存；预制供应商按“供应商端点 × 具体模型”自动选择，用户不需要也不能逐模型手选协议 |
+
+改动前的状态：思考模式下拉**只对 DeepSeek 有效**，其余六家发出去的请求里根本没有对应字段；而且两条路径给 DeepSeek 发的还不一样（原生流式发 `reasoning: true`，不是官方要求的 `thinking` + `reasoning_effort`）。
+
+### 2.2 协议选择已经收进 SDK
+
+- `LlmApiProtocol` 已包含 `openai-compatible`（Chat Completions）与 `openai-responses`。
+- `ModelStepProviderAdapterRegistry` 同时注册两条真实运行时；Responses 通过官方 `@ai-sdk/openai` 转换请求与标准 SSE 事件。
+- 协议不是供应商级一刀切：例如智谱国内只有 `glm-5.3` 默认 Responses，`glm-5.3-flash` / `glm-5v-turbo` 保持 Chat；派欧云聚合网关也不会因为底层模型原厂支持 Responses 就被误切换。
+- 预制供应商的协议控件不在界面显示；自定义未知端点才允许选择 Chat / Responses。Anthropic 没有运行时实现，也不在界面显示，存量伪配置继续归一化成 OpenAI Chat。
+
+当前已自动走 Responses 的预制组合：DeepSeek V4 Pro / Flash / Vision、火山引擎目录内三款 Doubao、百炼 Qwen3.8-Max、MiniMax-M3、智谱中国大陆 GLM-5.3。Kimi、MiMo、Groq、派欧云以及未确认的智谱模型继续走 Chat。
+
+### 2.3 Responses 事件契约与验证证据
+
+| 官方事件/边界 | SDK 统一结果 | 验证 |
+|---|---|---|
+| `response.created` | 记录 response id，不向业务层制造文本事件 | 官方形状 fixture |
+| `response.output_item.added` + `response.output_text.delta` | `TextDelta` 与最终文本 | [openai-responses-text.json](../../tests/fixtures/llm/openai-responses-text.json) |
+| `response.function_call_arguments.delta` + function item done | 既有 `ToolCall`，工具仍由助手运行时执行 | runtime 工具调用精确测试 |
+| `response.completed` / `response.incomplete` | finish reason、usage、缓存与推理 token | runtime 精确测试 |
+| `response.failed` / SSE `error` | 结构化 provider error，不返回半成功结果 | runtime 负例测试 |
+| AbortSignal / 断流 | 取消请求并释放读取器，统一为 `task_cancelled` | runtime 取消测试 |
+
+Responses 请求统一下发 `store: false`：助手自己的会话存储仍是唯一事实来源，同时兼容 DeepSeek 不支持 `store` / `previous_response_id` 的无状态实现。
+
+### 2.4 一个容易踩的坑：两条请求路径能表达的输入模态不同
+
+- 画布文本处理、提示词优化走**原生流式路径**（[streaming.ts](../../src/llm/streaming.ts)），`image_url` / `video_url` / `input_audio` 三种内容块都能发。
+- 智能助手走 **AI SDK 模型步骤**（[provider.ts](../../src/llm/sdk/provider.ts)），当前转换器只能表达 **image 与 audio**，视频会被 `assertInputModalities` 拦下。
+
+所以模型能力目录里的 `input` 记的是"**本项目当前请求路径下真实可用**"的模态，不是模型宣传的模态。DeepSeek 视觉模型已经因 Responses 接通而开放图片；智能助手的视频输入仍会在协议边界明确阻断，不会降级成文本地址造成静默失效。
+
+## 三、本项目的协议接入优先级（产品决策，不是能力强弱排序）
+
+新写协议适配器、给某个供应商挑协议时，按下面顺序取舍——这是本项目的既定优先级，**不因某家供应商官方推荐哪个协议就单独提高它的顺序**（MiniMax 官方推荐 Anthropic，但本项目仍按下表顺序执行，见 [MiniMax.md 第 6 节](供应商/MiniMax.md)）：
+
+1. **Responses API 优先**。结构化输出、上下文管理、内置工具（联网搜索等）通常最先在这条协议上落地，是新协议适配器要覆盖的首要目标。
+2. **Chat Completions 兜底**。Responses 未确认的供应商/模型继续用它，不阻塞可用性。
+3. **Anthropic Messages API 暂不实现、不显示**。官方支持面只作为未来资料保留，不向用户暴露一个不能工作的选项。
+
+每个供应商文件的「摘要」表里都有一行"接入优先级"，按这三条给出该供应商的具体落点（例如 Kimi/百炼没有 Anthropic，MiMo 没有 Responses API，落点就相应收窄）。
+
+## 四、协议矩阵（官方支持面，供路线图参考）
+
+| 供应商 | Chat Completions | Responses API | Anthropic Messages API | 联网搜索可用协议 |
+|---|---|---|---|---|
+| [火山引擎](供应商/火山引擎.md) | ✅ | ✅ | ❌ 官方未提供 | **仅 Responses API**（Chat API 完全不支持内置工具） |
+| [Kimi](供应商/Kimi.md) | ✅ | ❌ 官方未提供 | ❌ 官方未提供 | Chat Completions（`$web_search`，官方标注"近期不建议用于生产"） |
+| [智谱 GLM](供应商/智谱GLM.md) | ✅（`glm-5.3-flash` 目前仅确认此协议） | ✅（仅 `glm-5.3`） | ✅（仅 `glm-5.3`） | Chat Completions 工具 / 独立 Web Search API 均可，GLM-Coding-Plan 订阅账号暂时只能走 Chat Completions |
+| [DeepSeek](供应商/DeepSeek.md) | ✅ | ✅ | ✅ | **仅 Responses API**（Chat Completions 不支持 `web_search`） |
+| [小米 MiMo](供应商/小米MiMo.md) | ✅ | ❌ 官方未提供 | ✅ | **仅 Chat Completions**（官方原文："其他 API 协议暂不支持"），且需先在控制台激活插件 |
+| [百炼 Qwen](供应商/百炼Qwen.md) | ✅ | ✅ | ❌ 官方未提供 | 两条协议都支持，但 Responses 路径能力更全（额外有 `web_extractor`/`code_interpreter`） |
+| [MiniMax](供应商/MiniMax.md) | ✅ | ✅ | ✅（**官方推荐首选**） | Anthropic Messages + Responses API 均支持，纯 Chat Completions 不支持 |
+
+**两条对制定路线图有直接影响的结论**：
+
+1. **7 家里有 6 家原生支持 Responses API 或与之等价的能力**（火山引擎、GLM-5.3、DeepSeek、百炼、MiniMax 直接支持 Responses API；Kimi、小米 MiMo 没有 Responses API，只能走 Chat Completions）——这与第三节"Responses API 优先"的既定优先级吻合，先做 Responses API 适配器能覆盖到的供应商数量最多，也是联网搜索等内置工具最主要的解锁路径。
+2. **联网搜索能不能用，很大程度上取决于选了哪个协议**，不是"这家供应商支不支持"这么简单：火山引擎和 DeepSeek 的联网搜索**必须**走 Responses API，MiMo 的联网搜索**必须**走 Chat Completions，MiniMax 的联网搜索 Anthropic/Responses 都行但纯 Chat Completions 不行。做 Responses API 适配器时可以顺带核对一下能不能同时把对应供应商的联网搜索也接上，性价比更高。
+3. **4 家（DeepSeek、GLM、MiMo、MiniMax）原生支持 Anthropic Messages API，MiniMax 官方甚至推荐它作为首选**——这是资料记录，供未来"顺手就能接"时参考，**不代表应该优先做**：按第三节的既定优先级，Anthropic 排在 Responses API 和 Chat Completions 之后，不单独立项。
+
+## 五、供应商速查表
+
+| 供应商 | Base URL（OpenAI 兼容） | 旗舰模型 | 上下文 | 价格量级（输入/输出，元/百万 tokens） |
+|---|---|---|---|---|
+| 火山引擎 | `https://ark.cn-beijing.volces.com/api/v3` | `doubao-seed-evolving` | 1024K | 6 / 30 |
+| Kimi | `https://api.moonshot.cn/v1` | `kimi-k3` | 1,048,576 | 20 / 100 |
+| 智谱 GLM | 国内 `https://open.bigmodel.cn/api/paas/v4`；国际 `https://api.z.ai/api/paas/v4` | `glm-5.3` / `glm-5.3-flash`（原生多模态） | 1M | 国内 GLM-5.3：8 / 28；Flash：CNY 0.8 / 2.8、USD 0.15 / 0.50 |
+| DeepSeek | `https://api.deepseek.com` | `deepseek-v4-pro` | 1M | 4.5 / 13.5（闲时） |
+| 小米 MiMo | `https://api.xiaomimimo.com/v1` | `mimo-v2.5-pro` | 1M | 3 / 6 |
+| 百炼 Qwen | `https://{WorkspaceId}.cn-beijing.maas.aliyuncs.com/compatible-mode/v1` | `qwen3.8-max` | ~1M | 12 / 36 |
+| MiniMax | `https://api.minimaxi.com/v1` | `MiniMax-M3` | 1,000,000 | 2.10 / 8.40（≤512K，促销价） |
+
+价格列只取旗舰模型的标准档，完整价格表（含缓存命中价、批量价、区域差异）见各供应商文件；价格会变，不要把这张表当长期不变的计费合同。
+
+## 六、思考参数速查（各家字段名一致但取值集合不同，不要共用常量）
+
+| 供应商 | 字段 | 取值 | 默认 | 能否关闭 |
+|---|---|---|---|---|
+| 火山引擎 | `reasoning_effort` | `none`/`minimal`/`low`/`medium`/`high`/`xhigh`/`max`（7 档） | `high` | 可以（`thinking` 开关） |
+| Kimi | `reasoning_effort` | `low`/`high`/`max` | `max` | **不可以**，K3 始终思考 |
+| 智谱 GLM | `reasoning_effort` + `thinking` | `low`/`high`/`max`（`glm-5.3`、`glm-5.3-flash`） | `max` | GLM-5.3 / Flash 不可以；GLM-5V-Turbo 可以 |
+| DeepSeek | `reasoning_effort` + `thinking.type` | 字符串透传，无固定枚举 | — | 可以 |
+| 小米 MiMo | 无强度分级，仅 `reasoning_content` 回传约定 | — | — | 未见明确开关文档 |
+| 百炼 Qwen | `enable_thinking`（布尔） | `true`/`false` | 视模型而定 | 可以 |
+| MiniMax | 仅 Anthropic 协议下确认为原生 `thinking` 内容块；Chat/Responses 路径的思考强度字段未在公开文档中找到，接入 Responses API 时需要单独实测确认 | — | — | 视协议而定 |
+
+## 七、维护方式
+
+- **动手前**：先读 [文档采集手册.md](文档采集手册.md)——LLM 供应商的文档比生成模型更碎，同一模型的思考参数、联网搜索、工具调用往往各自独立成页，只看模型主页会漏掉大半内容。
+- **新增供应商**：在本文件协议矩阵、供应商速查表、思考参数速查三张表里各加一行 → 在 `供应商/` 下新建 `<供应商名>.md`，按现有文件的结构写（摘要 → Base URL → 协议现状 → 模型清单 → 思考模式 → 联网搜索/工具 → 适配要点 → 原始链接索引）→ 再把它落到代码的三处：[modelCatalogEntries.ts](../../src/llm/modelCatalogEntries.ts) 加模型条目、[providerPresets.ts](../../src/llm/providerPresets.ts) 加供应商预设、思考参数写法与通用 `reasoning_effort` 不同时在 [providerReasoningRequest.ts](../../src/llm/providerReasoningRequest.ts) 加一条映射。
+- **文档与代码的对齐由测试守着**：`modelCatalog.test.ts` 断言每条目录条目的 `docs` 路径真实存在，`providerPresets.test.ts` 断言每个预设的推荐模型都能在目录里查到、且有专门思考写法的供应商 id 与映射表一致。改了文件名或 providerId 而没同步，测试会红。
+- **只登记文档明确写出的能力**：目录里的每一项都要能在对应供应商文档里找到出处，文档没写的保持保守取值（false / null），交给用户手工勾或走「验证此模型」动态探测，不靠模型名猜。
+- **更新已有供应商**：直接改对应文件，同步更新该文件与本文件头部的"最后更新"。
+- **信息来源要求**：每条参数/价格都要能追溯到文件末尾"原始链接索引"里的某个链接；需要登录才能看到的页面必须标注，且优先尝试公开镜像（如 `help.aliyun.com` 之于百炼控制台）而不是直接要求登录。
+- **代码侧一旦补上新协议适配器**：回来更新本文件第二节"代码现状"，把对应协议从"资料"状态标记为"已实现"，否则这份文档会长期落后于代码。

package/docs/llm-adaptation//344/276/233/345/272/224/345/225/206/DeepSeek.md

@@ -1,91 +1,103 @@
-# DeepSeek
-
-> 核对时间：2026-08-26。信息来源见文末「原始链接索引」，均无需登录。
-
-## 1. 摘要
-
-| 项目 | 取值 |
-|---|---|
-| `providerId`（项目内约定） | `deepseek` |
-| 对应项目 `adapter` | `deepseek`（已实现；思考参数映射见 `packages/ai-sdk/src/llm/providerReasoningRequest.ts`，认证与请求体怪癖见 `packages/ai-sdk/src/llm/providerProtocol.ts`） |
-| 接入优先级（本项目约定，见 [README 第三节](../README.md)） | **Responses API 已实现并作为直连默认** → Chat Completions 兜底；Anthropic 暂不实现、不显示 |
-| 鉴权 | `Authorization: Bearer <DEEPSEEK_API_KEY>` |
-| 官方协议 | OpenAI Chat Completions、OpenAI Responses API、**Anthropic Messages API** 三选一，同一 Base URL 域名 |
-| 项目当前实际协议 | 直连预制模型自动使用 Responses；Chat Completions 保留为兼容路径 |
-
-## 2. Base URL
-
-| 协议 | Base URL |
-|---|---|
-| OpenAI 格式（Chat Completions / Responses） | `https://api.deepseek.com` |
-| Anthropic 格式（Messages API） | `https://api.deepseek.com/anthropic` |
-
-三种协议共用同一域名，只是路径不同：`/chat/completions`、`/responses`、`/anthropic/v1/messages`。
-
-## 3. 协议现状
-
-| 协议 | 官方支持 | 备注 |
-|---|---|---|
-| Chat Completions | ✅ | SDK 兼容路径 |
-| Responses API | ✅ | SDK 直连默认；`client.responses.create(model=..., input=...)`，见第 6 节 |
-| Anthropic Messages API | ✅ | 把 Claude 模型名映射到 DeepSeek 模型（`claude-opus-*` → `deepseek-v4-pro`；`claude-haiku-*`/`claude-sonnet-*` → `deepseek-v4-flash`），可以不改代码直接把现有 Anthropic 客户端指过来 |
-
-三种协议**同一批新模型会同步支持**，官方没有"新模型先上 Chat 后补 Responses"的滞后期。
-
-## 4. 模型清单
-
-官方用稳定别名指向最新快照，调用时直接用别名即可，无需关心具体快照号：
-
-| 模型别名 | 当前快照 | 简介 | 输入 → 输出 | 上下文 / 最大输出 | 并发上限 |
-|---|---|---|---|---|---|
-| `deepseek-v4-flash` | DeepSeek-V4-Flash-0731 | 高性价比、低延迟 | 文本 → 文本 | 1M / 384K | 2500 |
-| `deepseek-v4-pro` | DeepSeek-V4-Pro-0813 | 高能力，复杂推理与长任务 | 文本 → 文本 | 1M / 384K | 500 |
-| `deepseek-v4-flash-vision-exp` | — | **实验性视觉模型**，在 Flash 基础上加图片输入 | 文本、图片 → 文本 | 1M / 384K | 2500 |
-
-`deepseek-v4-flash-vision-exp` 不在此前整理的清单里，是新发现——它是唯一支持图片输入的 DeepSeek 模型，且**只能通过 Responses API 调用**（`input_image` 内容块），Chat Completions 路径下这个模型不接受图片。
-
-### 价格（元/百万 tokens，闲时/高峰各半，高峰为北京时间 09:00–12:00、14:00–18:00 工作日）
-
-| 模型 | 输入（缓存命中） | 输入（缓存未命中） | 输出 |
-|---|---|---|---|
-| `deepseek-v4-flash` | 闲时 0.05 / 高峰 0.10 | 闲时 1.5 / 高峰 3 | 闲时 4.5 / 高峰 9 |
-| `deepseek-v4-pro` | 闲时 0.15 / 高峰 0.30 | 闲时 4.5 / 高峰 9 | 闲时 13.5 / 高峰 27 |
-| `deepseek-v4-flash-vision-exp` | 同 flash | 同 flash | 同 flash |
-
-## 5. 思考模式
-
-- 请求体同时传 `thinking: {"type": "enabled"}` 和顶层 `reasoning_effort`；官方两个字段都要求（示例见 curl）。`reasoning_effort` 取值与思考强度的对应关系官方未列举离散档位，直接透传字符串即可。
-- 思考模式下 `temperature`、`top_p` 无效——传了也不报错，但不生效，UI 应避免让用户误以为调节生效。
-
-## 6. Responses API 适配要点（比 Chat Completions 复杂得多，接入前必读）
-
-`client.responses.create(model=..., input=..., instructions=...)`：
-
-- `input` 可以是字符串或 `input_text`/`input_image` 内容块数组；`instructions` 相当于插入一条首位 system 消息。
-- **不支持** `previous_response_id`、`conversation`、`store`（响应恒为 `store: false`）——**是无状态 API**，不要按 OpenAI 官方 Responses API 的"自动多轮托管"心智去设计，每次都要自己拼完整历史。
-- `tools` 只支持 `function` 与 `web_search`/`web_search_2025_08_26`，其余内置工具类型（`file_search`/`code_interpreter`/`computer_use`/`mcp`）会被**静默忽略**，不报错。
-- `web_search` 由服务端执行，`search_context_size`/`user_location` 参数会被忽略，服务端自动续搜最多 10 轮。**Chat Completions 完全不支持这个工具**——DeepSeek 官方 `guides/tool_calls` 文档里没有出现过 `web_search`，要联网搜索必须走 Responses API。
-- 未知/不支持的顶层参数一律静默忽略而不报错，意味着"参数传了但没生效"这类 bug 不会在 DeepSeek 侧报错，需要自己校验响应内容。
-
-## 7. Anthropic Messages API 适配要点（最低优先级，仅供顺手接入时参考）
-
-- 沿用 Anthropic 官方字段名（`system`、`messages[].content[].type=text/image/tool_use/tool_result` 等），`thinking` 支持但 `budget_tokens` 被忽略。
-- `output_config.effort` 是 DeepSeek 侧唯一生效的思考强度字段，其余 Anthropic 原生参数（`top_k`、`cache_control`、`disable_parallel_tool_use` 等）大多被忽略。
-- 项目设置页不显示 Anthropic：它没有运行时实现，存量伪配置会归一化成 OpenAI Chat。官方能力只留作未来资料，不让用户面对无效协议选项。
-
-## 8. 视觉输入限制（`deepseek-v4-flash-vision-exp`）
-
-- 单张内联图片 ≤ 32 MiB，`file_id` 图片 ≤ 64 MiB；不含 `file_id` 时总大小 ≤ 64 MiB，含则 ≤ 200 MiB；单请求最多 600 张图。
-- 图片只能出现在 `user`/`developer` 消息里，出现在 `system`/`assistant` 消息会直接返回 400。
-- 非视觉模型收到 `input_image` 不会报错，而是被替换成占位文本——容易造成"没报错但模型看不到图"的静默失效。
-
-## 原始链接索引（均无需登录）
-
-- [Your First API Call](https://api-docs.deepseek.com/quick_start/pricing)（含 base_url/模型 ID/思考请求示例）
-- [Models & Pricing](https://api-docs.deepseek.com/quick_start/pricing)
-- [Using the Responses API](https://api-docs.deepseek.com/guides/responses_api)
-- [Using the Anthropic API](https://api-docs.deepseek.com/guides/anthropic_api)
-- [Reasoning Model（思考模式）](https://api-docs.deepseek.com/guides/reasoning_model)
-- [Function Calling](https://api-docs.deepseek.com/guides/tool_calls)
-- [Vision（视觉输入限制）](https://api-docs.deepseek.com/guides/vision)
-- [API sitemap](https://api-docs.deepseek.com/sitemap.xml)（用于核对页面是否存在，避免中文 `/zh-cn/` 前缀 404 后静默 fallback 到错误页面）
+# DeepSeek
+
+> 核对时间：2026-09-11。以中文官方文档为准，英文页面尚有更新滞后。
+
+## 2026-09-11 更新（覆盖下方历史资料中的旧模型和能力说明）
+
+- 官方默认与预设唯一推荐模型改为 `deepseek-flash`（DeepSeek V4.1 Flash），原生文本、图片输入，1M 上下文、384K 最大输出。Chat Completions 和 Responses 均支持图片；项目继续默认 Responses。
+- 旧 `deepseek-v4-flash`、`deepseek-v4-flash-vision-exp` 已由官方转发到新版。`deepseek-v4-pro` 将于北京时间 2026-09-14 12:00 转由新版承接。项目不再推荐这些旧名字，也不把聚合供应商的旧 ID 当作新版别名。
+- 新版价格（人民币/百万 token，闲时 / 工作日高峰）：缓存命中输入 0.02 / 0.04，未命中输入 1 / 2，输出 4 / 8。高峰为北京时间工作日 09:00–12:00、14:00–18:00。
+- 思考默认开启，默认 high；正式档位 low/high/max，兼容 minimal→low、medium/xhigh→high、ultra→max。Responses 用 reasoning.effort，none 关闭。思考时 temperature 无效，top_p 生效但下限 0.95；非思考 top_p 固定 1。
+- Responses 为无状态 API，必须回传完整历史；text.format 支持 json_schema。当前仅支持 function 工具，内置工具会被忽略，不能再据旧资料宣称 web_search 可用。SDK 本次只更新目录与默认选型，不新增内置工具或协议分支。
+- 图片支持 JPEG/PNG/GIF/WebP；请求体最多 48 MiB，单图内联/URL 32 MiB，file_id 64 MiB，最多 600 张；总大小不含 file_id 64 MiB、包含时 200 MiB。Chat 图片仅 user；Responses 支持 user/developer 和工具结果，system/assistant 图片返回 400。SDK 沿用已实现的 URL/内联图片通道，不新增 Files 上传能力。
+- 官方来源：[模型与价格](https://api-docs.deepseek.com/zh-cn/quick_start/pricing/)、[图片理解](https://api-docs.deepseek.com/zh-cn/guides/vision/)、[思考模式](https://api-docs.deepseek.com/zh-cn/guides/thinking_mode/)、[Responses API](https://api-docs.deepseek.com/zh-cn/api/create-response/)。
+
+以下为 2026-08-26 历史采集记录；冲突字段以本节为准。
+
+## 1. 摘要
+
+| 项目 | 取值 |
+|---|---|
+| `providerId`（项目内约定） | `deepseek` |
+| 对应项目 `adapter` | `deepseek`（已实现；思考参数映射见 `packages/ai-sdk/src/llm/providerReasoningRequest.ts`，认证与请求体怪癖见 `packages/ai-sdk/src/llm/providerProtocol.ts`） |
+| 接入优先级（本项目约定，见 [README 第三节](../README.md)） | **Responses API 已实现并作为直连默认** → Chat Completions 兜底；Anthropic 暂不实现、不显示 |
+| 鉴权 | `Authorization: Bearer <DEEPSEEK_API_KEY>` |
+| 官方协议 | OpenAI Chat Completions、OpenAI Responses API、**Anthropic Messages API** 三选一，同一 Base URL 域名 |
+| 项目当前实际协议 | 直连预制模型自动使用 Responses；Chat Completions 保留为兼容路径 |
+
+## 2. Base URL
+
+| 协议 | Base URL |
+|---|---|
+| OpenAI 格式（Chat Completions / Responses） | `https://api.deepseek.com` |
+| Anthropic 格式（Messages API） | `https://api.deepseek.com/anthropic` |
+
+三种协议共用同一域名，只是路径不同：`/chat/completions`、`/responses`、`/anthropic/v1/messages`。
+
+## 3. 协议现状
+
+| 协议 | 官方支持 | 备注 |
+|---|---|---|
+| Chat Completions | ✅ | SDK 兼容路径 |
+| Responses API | ✅ | SDK 直连默认；`client.responses.create(model=..., input=...)`，见第 6 节 |
+| Anthropic Messages API | ✅ | 把 Claude 模型名映射到 DeepSeek 模型（`claude-opus-*` → `deepseek-v4-pro`；`claude-haiku-*`/`claude-sonnet-*` → `deepseek-v4-flash`），可以不改代码直接把现有 Anthropic 客户端指过来 |
+
+三种协议**同一批新模型会同步支持**，官方没有"新模型先上 Chat 后补 Responses"的滞后期。
+
+## 4. 模型清单
+
+官方用稳定别名指向最新快照，调用时直接用别名即可，无需关心具体快照号：
+
+| 模型别名 | 当前快照 | 简介 | 输入 → 输出 | 上下文 / 最大输出 | 并发上限 |
+|---|---|---|---|---|---|
+| `deepseek-v4-flash` | DeepSeek-V4-Flash-0731 | 高性价比、低延迟 | 文本 → 文本 | 1M / 384K | 2500 |
+| `deepseek-v4-pro` | DeepSeek-V4-Pro-0813 | 高能力，复杂推理与长任务 | 文本 → 文本 | 1M / 384K | 500 |
+| `deepseek-v4-flash-vision-exp` | — | **实验性视觉模型**，在 Flash 基础上加图片输入 | 文本、图片 → 文本 | 1M / 384K | 2500 |
+
+`deepseek-v4-flash-vision-exp` 不在此前整理的清单里，是新发现——它是唯一支持图片输入的 DeepSeek 模型，且**只能通过 Responses API 调用**（`input_image` 内容块），Chat Completions 路径下这个模型不接受图片。
+
+### 价格（元/百万 tokens，闲时/高峰各半，高峰为北京时间 09:00–12:00、14:00–18:00 工作日）
+
+| 模型 | 输入（缓存命中） | 输入（缓存未命中） | 输出 |
+|---|---|---|---|
+| `deepseek-v4-flash` | 闲时 0.05 / 高峰 0.10 | 闲时 1.5 / 高峰 3 | 闲时 4.5 / 高峰 9 |
+| `deepseek-v4-pro` | 闲时 0.15 / 高峰 0.30 | 闲时 4.5 / 高峰 9 | 闲时 13.5 / 高峰 27 |
+| `deepseek-v4-flash-vision-exp` | 同 flash | 同 flash | 同 flash |
+
+## 5. 思考模式
+
+- 请求体同时传 `thinking: {"type": "enabled"}` 和顶层 `reasoning_effort`；官方两个字段都要求（示例见 curl）。`reasoning_effort` 取值与思考强度的对应关系官方未列举离散档位，直接透传字符串即可。
+- 思考模式下 `temperature`、`top_p` 无效——传了也不报错，但不生效，UI 应避免让用户误以为调节生效。
+
+## 6. Responses API 适配要点（比 Chat Completions 复杂得多，接入前必读）
+
+`client.responses.create(model=..., input=..., instructions=...)`：
+
+- `input` 可以是字符串或 `input_text`/`input_image` 内容块数组；`instructions` 相当于插入一条首位 system 消息。
+- **不支持** `previous_response_id`、`conversation`、`store`（响应恒为 `store: false`）——**是无状态 API**，不要按 OpenAI 官方 Responses API 的"自动多轮托管"心智去设计，每次都要自己拼完整历史。
+- `tools` 只支持 `function` 与 `web_search`/`web_search_2025_08_26`，其余内置工具类型（`file_search`/`code_interpreter`/`computer_use`/`mcp`）会被**静默忽略**，不报错。
+- `web_search` 由服务端执行，`search_context_size`/`user_location` 参数会被忽略，服务端自动续搜最多 10 轮。**Chat Completions 完全不支持这个工具**——DeepSeek 官方 `guides/tool_calls` 文档里没有出现过 `web_search`，要联网搜索必须走 Responses API。
+- 未知/不支持的顶层参数一律静默忽略而不报错，意味着"参数传了但没生效"这类 bug 不会在 DeepSeek 侧报错，需要自己校验响应内容。
+
+## 7. Anthropic Messages API 适配要点（最低优先级，仅供顺手接入时参考）
+
+- 沿用 Anthropic 官方字段名（`system`、`messages[].content[].type=text/image/tool_use/tool_result` 等），`thinking` 支持但 `budget_tokens` 被忽略。
+- `output_config.effort` 是 DeepSeek 侧唯一生效的思考强度字段，其余 Anthropic 原生参数（`top_k`、`cache_control`、`disable_parallel_tool_use` 等）大多被忽略。
+- 项目设置页不显示 Anthropic：它没有运行时实现，存量伪配置会归一化成 OpenAI Chat。官方能力只留作未来资料，不让用户面对无效协议选项。
+
+## 8. 视觉输入限制（`deepseek-v4-flash-vision-exp`）
+
+- 单张内联图片 ≤ 32 MiB，`file_id` 图片 ≤ 64 MiB；不含 `file_id` 时总大小 ≤ 64 MiB，含则 ≤ 200 MiB；单请求最多 600 张图。
+- 图片只能出现在 `user`/`developer` 消息里，出现在 `system`/`assistant` 消息会直接返回 400。
+- 非视觉模型收到 `input_image` 不会报错，而是被替换成占位文本——容易造成"没报错但模型看不到图"的静默失效。
+
+## 原始链接索引（均无需登录）
+
+- [Your First API Call](https://api-docs.deepseek.com/quick_start/pricing)（含 base_url/模型 ID/思考请求示例）
+- [Models & Pricing](https://api-docs.deepseek.com/quick_start/pricing)
+- [Using the Responses API](https://api-docs.deepseek.com/guides/responses_api)
+- [Using the Anthropic API](https://api-docs.deepseek.com/guides/anthropic_api)
+- [Reasoning Model（思考模式）](https://api-docs.deepseek.com/guides/reasoning_model)
+- [Function Calling](https://api-docs.deepseek.com/guides/tool_calls)
+- [Vision（视觉输入限制）](https://api-docs.deepseek.com/guides/vision)
+- [API sitemap](https://api-docs.deepseek.com/sitemap.xml)（用于核对页面是否存在，避免中文 `/zh-cn/` 前缀 404 后静默 fallback 到错误页面）