@henjicc/ai-sdk 0.2.8

package/docs/llm-adaptation/README.md

@@ -0,0 +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` 之于百炼控制台）而不是直接要求登录。
+- **代码侧一旦补上新协议适配器**：回来更新本文件第二节"代码现状"，把对应协议从"资料"状态标记为"已实现"，否则这份文档会长期落后于代码。

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

@@ -0,0 +1,91 @@
+# 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 到错误页面）

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

@@ -0,0 +1,75 @@
+# Kimi（Moonshot）
+
+> 核对时间：2026-08-26。信息来源见文末「原始链接索引」，均无需登录。
+
+## 1. 摘要
+
+| 项目 | 取值 |
+|---|---|
+| `providerId`（项目内约定） | `kimi` / `moonshot` |
+| 对应项目 `adapter` | `openai`（Chat Completions 兼容） |
+| 接入优先级（本项目约定，见 [README 第三节](../README.md)） | 官方**没有** Responses API 也**没有** Anthropic Messages API，Chat Completions 是唯一路径，已实现，无需再排优先级 |
+| 鉴权 | `Authorization: Bearer $MOONSHOT_API_KEY` |
+| Base URL | `https://api.moonshot.cn/v1`（文档站已迁移到 `platform.kimi.com`，但**接口域名仍是 moonshot.cn**，不要混淆两个域名） |
+| 官方协议 | 仅 OpenAI Chat Completions，**没有 Responses API** |
+
+## 2. 协议现状
+
+Kimi 官方文档全文没有出现过 `responses.create`；`platform.kimi.com/docs/llms.txt` 索引里也没有 Responses API 页面。三个消费方（助手、画布文本节点、提示词优化）走本项目现有的 `openai-compatible` 协议即可完整覆盖 Kimi，**不需要等 Responses API 适配器**。
+
+## 3. 模型
+
+| 模型 ID | 简介 | 输入 → 输出 | 上下文 | 最大输出 |
+|---|---|---|---|---|
+| `kimi-k3` | 当前旗舰，2.8 万亿参数，KDA 混合线性注意力，全球首个开源 3 万亿级模型 | 文本、图片、视频 → 文本 | 1,048,576 tokens（1M） | 默认 131,072，最大可设 1,048,576 |
+
+价格（元/百万 tokens）：缓存命中 2、缓存未命中 20、输出 100。
+
+K3 是付费解锁模型：**充值后才能调用**，新用户认证赠送的 15 元代金券不能用于 K3。
+
+## 4. 思考模式（始终开启，不可关闭）
+
+- 顶层 `reasoning_effort`：`low` / `high` / `max`，默认 `max`。**没有 `off`**——K2.x 系列的 `thinking` 配置迁移到 K3 时要整段删除，改传 `reasoning_effort`。
+- 多轮对话/工具调用时必须把 API 返回的**完整** assistant message（含 `reasoning_content` 和 `tool_calls`）原样回传，只保留 `content` 会破坏推理连续性。
+
+## 5. 固定采样参数（不要显式传）
+
+`temperature=1.0`、`top_p=0.95`、`n=1`、`presence_penalty=0`、`frequency_penalty=0` 是官方文档明确写出的固定值，"建议不要显式传入"——如果项目通用请求构建层默认带上自己的 `temperature`/`topP`，K3 这边等于被覆盖成无效参数，属于容易被忽视的静默问题。
+
+## 6. 视觉输入（重要限制）
+
+- 图片必须走 `image_url.url` 的 **base64 data URL**（`data:image/png;base64,...`），**不支持公网图片直链**。这与大多数供应商"直接传 URL"的默认假设相反，接入时要单独处理。
+- 视频走 Files API 先上传拿 `file_id`，再用 `video_url.url = "ms://<file-id>"` 引用，用完建议调用 `client.files.delete` 清理。
+- `content` 必须是对象数组，不能是拼好的字符串。
+
+## 7. 结构化输出
+
+`response_format: {type: "json_schema", json_schema: {name, strict: true, schema}}`，只解析 `message.content`，不解析 `reasoning_content`。
+
+## 8. 联网搜索（官方明确提示不建议用于生产）
+
+- 内置工具名 `$web_search`，声明方式和普通 function 不同：`type` 要写成 `"builtin_function"`（不是 `"function"`），且**只需要 `function.name`，不需要 `parameters`**：
+  ```json
+  { "type": "builtin_function", "function": { "name": "$web_search" } }
+  ```
+  `$` 前缀是 Kimi 保留给内置函数的命名空间，普通 `function` 类型的工具名不允许出现 `$`。
+- 执行方式：模型返回 `finish_reason=tool_calls` 且 `tool_call.function.name="$web_search"` 时，调用方**原样把 `arguments` 塞回一条 `role=tool` 消息**即可，不需要真的执行搜索——搜索本身由 Kimi 服务端完成。
+- 价格：¥0.03/次（只在 `finish_reason=tool_calls` 且工具名是 `$web_search` 时收取；如果中途放弃 `tool_calls` 循环，只收这笔工具调用费，不收搜索内容占用的 token 费）。搜索结果本身也会计入下一次请求的 `prompt_tokens`，可从 `tool_call.function.arguments.usage.total_tokens` 读到这部分用量。
+- **官方定价页原文警告**：「联网搜索（`web_search`）正在更新升级中，近期不建议使用该功能，当前文档已经过时」。项目侧如果要接这个能力，应该默认关闭并在 UI 上标注"实验性/暂不稳定"，而不是当作可靠能力直接暴露。
+- 官方更推荐的替代路径是走 Formula 官方工具通道（标准 OpenAI `function` 类型，见「官方工具」文档），但同样标注"联网搜索工具正在更新，近期不建议使用"。
+
+## 9. 动态加载工具（K3 独有能力）
+
+把完整工具定义放进一条 `role=system` 且不含 `content`、只含 `tools` 字段的消息里，可以从对话中间某一轮开始动态生效，不需要在最初就声明全部工具。用于工具数量多、想省 token 或提升工具选择准确率的场景。
+
+## 原始链接索引（均无需登录）
+
+- [Kimi API 概览](https://platform.kimi.com/docs/overview)
+- [Kimi K3 快速开始](https://platform.kimi.com/docs/guide/kimi-k3-quickstart)
+- [推理强度](https://platform.kimi.com/docs/guide/use-reasoning-effort)
+- [使用 Kimi API 的联网搜索功能](https://platform.kimi.com/docs/guide/use-web-search)
+- [如何在 Kimi API 中使用官方工具](https://platform.kimi.com/docs/guide/use-official-tools)
+- [Kimi K3 定价](https://platform.kimi.com/docs/pricing/chat-k3)
+- [联网搜索定价](https://platform.kimi.com/docs/pricing/tools)
+- [使用思考模式](https://platform.kimi.com/docs/guide/use-thinking-models)
+- [Kimi 文档全量索引](https://platform.kimi.com/docs/llms.txt)

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

@@ -0,0 +1,84 @@
+# MiniMax
+
+> 核对时间：2026-08-26。信息来源见文末「原始链接索引」，均无需登录。
+
+## 1. 摘要
+
+| 项目 | 取值 |
+|---|---|
+| `providerId`（项目内约定） | `minimax` |
+| 对应项目 `adapter` | `openai`（Chat Completions / Responses 均可）。官方推荐的 Anthropic 路径在本项目没有可选的 adapter——那个选项从未接通，已删除，见下方"接入优先级" |
+| 官方协议 | Anthropic Messages（官方推荐）、OpenAI Chat Completions、OpenAI Responses API 三选一，同域名不同路径 |
+| 接入优先级（本项目约定，见 [README 第三节](../README.md)） | MiniMax-M3 已默认走 **Responses API** → Chat Completions 兼容；Anthropic 暂不实现、不显示 |
+
+MiniMax 是本次调研 7 家里**唯一把 Anthropic 协议列为默认推荐接入方式**的供应商——官方"通过 SDK 接入"快速开始页第一步就是装 `anthropic` SDK，不是 `openai`；原因是 Anthropic 协议能拿到原生 `thinking` 块和 interleaved thinking，Chat/Responses 路径下这部分体验打折扣。**但本项目按统一的协议接入优先级执行，不因为某一家官方推荐就单独提高 Anthropic 的实现顺序**——MiniMax 官方文档自己也说 Chat Completions 与 Responses 两条路径"功能对等，只是拿不到原生 thinking 块"，所以 Responses API 仍然是够用的第一选择。
+
+## 2. Base URL
+
+| 协议 | Base URL |
+|---|---|
+| Anthropic Messages（推荐） | `https://api.minimaxi.com/anthropic` |
+| OpenAI Chat Completions | `https://api.minimaxi.com/v1`（路径 `/chat/completions`） |
+| OpenAI Responses API | `https://api.minimaxi.com/v1`（路径 `/responses`） |
+
+## 3. 模型清单
+
+| 模型 ID | 简介 | 输入 → 输出 | 上下文 | 最大输出 |
+|---|---|---|---|---|
+| `MiniMax-M3` | 当前最新旗舰，原生多模态，1M 上下文，面向 Frontier Coding、复杂推理、Agent | 文本、图片、视频 → 文本 | 1,000,000 | 官方建议 131,072，硬上限 524,288 |
+
+`MiniMax-M2.7`（含 `-highspeed`）仍在正常提供服务，属于上一代仍在售的并行线，不是 M3 的档位变体；`M2.5`/`M2.1`/`M2` 系列已归入官方"历史模型"分组。
+
+### 价格（元/百万 tokens，当前促销"永久五折"后）
+
+| 输入长度 | 输入 | 输出 | 缓存读取 |
+|---|---|---|---|
+| ≤ 512K | 2.10 | 8.40 | 0.42 |
+| > 512K | 4.20 | 16.80 | 0.84 |
+
+`service_tier: "priority"` 优先服务档按上表 1.5 倍计费，可换取更快响应与更低失败率。
+
+## 4. Anthropic 协议接入要点（官方推荐路径，但本项目最低优先级，仅供顺手接入时参考）
+
+```python
+import anthropic
+client = anthropic.Anthropic(base_url="https://api.minimaxi.com/anthropic", api_key="<KEY>")
+message = client.messages.create(model="MiniMax-M3", max_tokens=1000, messages=[...])
+for block in message.content:
+    if block.type == "thinking": ...   # 原生 thinking 块
+    elif block.type == "text": ...
+```
+
+- 支持 `thinking` 内容块和 interleaved thinking（推理与工具调用交替）——这是官方文档反复强调的 M3 核心卖点，Chat Completions 路径下只能拿到扁平化的 `reasoning_content` 字符串，信息密度不如原生 `thinking` 块。
+- 官方 Mini-Agent 示例项目就是用 Anthropic 协议 + interleaved thinking 演示"如何用 M3 搭 Agent"的最佳实践，可作为项目内 Agent 集成的参考实现。
+
+## 5. 联网搜索（Server Tools，Beta，两个协议都支持——这与此前认知不同）
+
+**更正**：此前认为 MiniMax 的 `web_search` 只在 Anthropic Messages 文档出现，OpenAI/Responses 路径不支持——这是过时信息。**官方当前 Server Tools 文档明确写：Anthropic Messages API 和 OpenAI Responses API 都支持**，只是工具类型标识不同：
+
+| 接口 | 工具声明 |
+|---|---|
+| Anthropic Messages API | `{"type": "web_search_20250305", "name": "web_search"}` |
+| OpenAI Responses API | `{"type": "web_search"}` |
+
+服务端工具（Server Tools）与项目自研的 function-calling 工具是两套机制：模型在 MiniMax 服务端自动执行搜索并把结果直接嵌进响应，调用方不需要多轮回传 `tool_result`，一次请求内完成。
+
+- Anthropic 路径响应里会依次出现 `text`（引导语）→ `server_tool_use`（`name=web_search`, `input.query`）→ `web_search_tool_result`（含 `title`/`url`/`page_age`/`content`）→ `text`（最终答案），直接读最后一个 `text` 块即可。
+- Responses API 路径的 `output` 数组包含 `web_search_call`（含 `action.query`）和 `message`，可以直接读顶层聚合字段 `output_text`。
+- **纯 Chat Completions（`/v1/chat/completions`）不支持这个工具**——只有 Anthropic Messages 和 Responses 两条路径能用，选型时要注意。
+- 价格 ¥0.03/次；处于 **Beta 阶段**，官方提示行为与参数可能随时调整，服务端全程执行导致单次请求耗时可能更长，客户端超时要放宽。
+
+## 6. 兼容性说明
+
+- OpenAI Chat Completions 与 Anthropic Messages 是"等价的两套非流式样例"，官方文档明确"如果你的项目已经接入 OpenAI SDK，把 base_url 和 model 换成 MiniMax 的值即可直接复用，无需迁移 SDK"——即两条路径功能对等（除服务端工具的可用面略有差异），选哪个更多是团队已有技术栈的问题，不是能力取舍。这也是本项目仍把 Responses API 排在 Anthropic 前面的依据：不用 Anthropic 也不会丢失核心能力，只是拿不到原生 `thinking` 块和 interleaved thinking 这部分体验加成。
+- `LlmProviderConfig.adapter` 只保留内部供应商特性标识；协议由 `apiProtocol` 和预制模型矩阵决定。Anthropic 虽是 MiniMax 官方推荐路径，但项目暂不实现、不显示；MiniMax-M3 由 SDK 自动走 Responses。
+
+## 原始链接索引（均无需登录）
+
+- [模型概览](https://platform.minimaxi.com/docs/guides/models-intro)
+- [模型调用（URL 配置、双协议示例）](https://platform.minimaxi.com/docs/guides/text-generation)
+- [通过 SDK 接入（Anthropic SDK 快速开始）](https://platform.minimaxi.com/docs/guides/quickstart-sdk)
+- [服务端工具（Server Tools / web_search）](https://platform.minimaxi.com/docs/guides/server-tools)
+- [工具使用 & 交错思维链](https://platform.minimaxi.com/docs/guides/text-m3-function-call)
+- [按量计费](https://platform.minimaxi.com/docs/guides/pricing-paygo)
+- [MiniMax 文档全量索引](https://platform.minimaxi.com/docs/llms.txt)

package/docs/llm-adaptation//344/276/233/345/272/224/345/225/206//345/260/217/347/261/263MiMo.md

@@ -0,0 +1,85 @@
+# 小米 MiMo
+
+> 核对时间：2026-08-26。信息来源见文末「原始链接索引」，均无需登录（文档站是 SPA，curl 拿不到正文，用浏览器渲染后取 `innerText`，见采集手册）。
+
+## 1. 摘要
+
+| 项目 | 取值 |
+|---|---|
+| `providerId`（项目内约定，代码中已存在） | `mimo` |
+| 对应项目 `adapter` | `openai`（Chat Completions）；官方也提供 Anthropic Messages API |
+| 官方协议 | OpenAI Chat Completions + **Anthropic Messages API**，**没有 Responses API** |
+| 接入优先级（本项目约定，见 [README 第三节](../README.md)） | 官方**没有** Responses API；Chat Completions 是唯一已实现且能用联网搜索的路径；Anthropic **最低优先级**，且接了也拿不到联网搜索（第 7 节） |
+| 已知协议怪癖（代码里已实现） | 额外发送 `api-key` 认证头；请求体 `max_tokens` 要改名成 `max_completion_tokens`，见 `packages/ai-sdk/src/llm/providerProtocol.ts` |
+
+## 2. Base URL
+
+| 用法 | OpenAI 兼容 | Anthropic 兼容 |
+|---|---|---|
+| 按量计费 | `https://api.xiaomimimo.com/v1` | `https://api.xiaomimimo.com/anthropic` |
+| Token Plan（订阅套餐） | `https://token-plan-cn.xiaomimimo.com/v1` | `https://token-plan-cn.xiaomimimo.com/anthropic` |
+
+两种用法的 Base URL 和 API Key 都不同，Token Plan 走独立域名——如果项目未来要支持订阅制账号，不能简单复用按量计费的 Base URL。
+
+## 3. 认证怪癖（已在代码里处理，供交叉核对）
+
+官方文档给出的 Header 名是 `api-key`（不是 `Authorization: Bearer`）：
+
+```
+curl --header "api-key: $MIMO_API_KEY" ...
+```
+
+这与项目 `providerProtocol.ts` 里 `PROVIDER_EXTRA_AUTH_HEADERS: { mimo: 'api-key' }` 的注释描述完全一致——代码是**额外补发**这个头而不是替换 `Authorization`，因为通用 OpenAI 兼容实现默认发的是 Bearer，MiMo 网关只认它认识的那个头，两个头同时发是安全的。
+
+## 4. 模型清单
+
+| 模型 ID | 简介 | 输入 → 输出 | 上下文 / 最大输出 | RPM / TPM |
+|---|---|---|---|---|
+| `mimo-v2.5-pro` | 复杂推理、深度分析、长文档场景 | 文本 → 文本 | 1M / 128K | 100 / 10M |
+| `mimo-v2.5` | 全模态理解，图片/音频/视频场景 | 文本、图片、音频、视频 → 文本 | 1M / 128K | — |
+
+能力标签（官方模型列表页原文）：两个模型都标注支持 Deep Thinking、Streaming、Function Call、Structured Output、**Web Search**；`mimo-v2.5` 额外标注 Full-modal Understanding。
+
+`mimo-v2-pro`/`mimo-v2-omni`/`mimo-v2-flash`/`mimo-v2-tts` 已于 2026-06-30 正式下线，不要再作为可选模型出现在任何清单里。
+
+### 价格（国内，元/百万 tokens）
+
+| 模型 | 缓存命中 | 缓存未命中 | 输出 |
+|---|---|---|---|
+| `mimo-v2.5-pro` | 0.025 | 3.00 | 6.00 |
+| `mimo-v2.5` | 0.02 | 1.00 | 2.00 |
+
+海外价格另有独立美元档（见原始链接），缓存写入限时免费。
+
+## 5. `max_completion_tokens` 怪癖（已在代码里处理，供交叉核对）
+
+官方 Quick Start 示例请求体直接用的就是 `max_completion_tokens`，不是通用 OpenAI 实现默认的 `max_tokens`。这与项目 `applyProviderRequestBodyQuirks` 的注释一致——实测发 `max_tokens` 时六项能力探测**全部返回 400 `Invalid request parameters`**，包括最基础的纯文本对话，说明这不是能力缺失，是请求字段本身不被接受。
+
+## 6. 思考模式的多轮回传
+
+思考模式下，`assistant` 消息会带 `reasoning_content` 字段（与 `content`/`tool_calls` 并列）。多轮工具调用场景，官方建议把历史轮次的 `reasoning_content` 也保留在 `messages` 里回传，以获得最佳效果——这点和 Kimi K3、GLM 的"必须回传完整 assistant message"是同一类要求，三家风格接近，可以复用同一套"assistant message 原样回传"逻辑，不用分别实现。
+
+## 7. 联网搜索（需要先在控制台激活插件，且只支持 Chat Completions）
+
+- **前置步骤**：控制台 → 插件管理，先激活 Web Search 插件，否则 API 侧声明了 `tools` 也不会生效。
+- 声明方式（比 GLM 简单，扁平结构而非嵌套）：
+  ```json
+  {
+    "type": "web_search",
+    "max_keyword": 3,
+    "force_search": true,
+    "limit": 1,
+    "user_location": { "type": "approximate", "country": "China", "region": "Hubei", "city": "Wuhan" }
+  }
+  ```
+- **官方原文明确写"其他 API 协议暂不支持"**——即联网搜索只能走 OpenAI Chat Completions，Anthropic Messages 路径下不可用，即便两个模型基础对话都支持 Anthropic 协议。
+- 响应里搜索来源以 `annotations: [{type:"url_citation", url, title, ...}]` 形式附在 `message` 里，usage 里会带 `web_search_usage: {tool_usage, page_usage}`。
+- 有 5 分钟缓存期：刚开关搜索插件后 5 分钟内可能不会立即生效，排查"为什么没触发搜索"时先看这一条。
+- 价格：国内 ¥16/1000 次、海外 $5/1000 次；一轮搜索按 `max_keyword` 并发展开多个关键词，会产生多次调用计费；网页内容本身按标准 token 单价计入 `prompt_tokens`。
+
+## 原始链接索引（均无需登录，需浏览器渲染）
+
+- [模型列表](https://mimo.mi.com/docs/quick-start/summary/model)
+- [首次 API 调用（含 OpenAI/Anthropic 双协议示例）](https://mimo.mi.com/docs/quick-start/summary/first-api-call)
+- [联网搜索](https://mimo.mi.com/docs/en-US/quick-start/usage-guide/text-generation/tool-calling/web-search)
+- [按量计费价格](https://mimo.mi.com/docs/en-US/price/pay-as-you-go)