feat: add MiniMax as LLM provider preset with M2.7 as default

[octo-patch]

Summary

• Add MiniMax as a selectable LLM provider preset in Web UI channel editor and configuration examples
• Add MiniMax-M2.7 and MiniMax-M2.7-highspeed model entries to litellm_config.example.yaml
• Update documentation and multilingual READMEs with MiniMax LLM configuration guidance

Changes

• litellm_config.example.yaml: Add M2.7/M2.7-highspeed example entries alongside existing M2.5
• .env.example: Add MINIMAX_LLM_API_KEY variable example for YAML config mode
• docs/LLM_CONFIG_GUIDE.md: Add MiniMax LLM configuration section (OpenAI-compatible via LiteLLM)
• apps/dsa-web/src/components/settings/LLMChannelEditor.tsx: Add MiniMax preset with api.minimax.io base URL and M2.7 placeholder
• README.md, docs/README_CHT.md, docs/README_EN.md: Mention MiniMax in AI model list
• docs/CHANGELOG.md: Add entry under [Unreleased]

Why

MiniMax M2.7 is a recent flagship model with 1M context and strong reasoning. The OpenAI-compatible API (api.minimax.io/v1) integrates seamlessly via LiteLLM. This PR adds it as an optional preset/example — no runtime defaults or existing behavior are changed.

Scope Clarification

This PR does not change any system default model or runtime behavior. It only adds:

1. A new preset entry in the Web UI channel editor dropdown
2. Example configuration snippets in docs and config templates
3. Documentation references

Users must explicitly select MiniMax and provide their own MINIMAX_LLM_API_KEY to use it.

Testing

• Model IDs verified against MiniMax API documentation
• Existing MiniMax search provider (src/search_service.py) unchanged
• No runtime default changes — existing deployments unaffected
• Frontend change is a static preset addition (label, baseUrl, placeholder)

Risk

• Low risk: All changes are additive (presets, examples, docs). No existing configuration, runtime default, or API behavior is modified.
• Existing OpenAI-compatible LLM configurations remain unaffected.

Rollback

• Remove the MiniMax preset entry from LLMChannelEditor.tsx, revert example config and doc additions. No data migration or state cleanup required.

[github-actions]

🤖 自动审查报告

项目	结果
📊 变更文件	8 个
➕ 新增行数	49 行
➖ 删除行数	5 行
🔍 静态检查	✅ 通过
🧠 AI 审查	✅ 已完成

📁 修改的文件

• 📝 .env.example (+5/-0)
• 📝 README.md (+1/-1)
• 📝 apps/dsa-web/src/components/settings/LLMChannelEditor.tsx (+6/-0)
• 📝 docs/CHANGELOG.md (+6/-0)
• 📝 docs/LLM_CONFIG_GUIDE.md (+10/-2)
• 📝 docs/README_CHT.md (+1/-1)
• 📝 docs/README_EN.md (+1/-1)
• 📝 litellm_config.example.yaml (+19/-0)

---

🧠 AI 代码审查意见

结论：Not Ready

结构化审查结果

• 必要性：通过
  本次 PR 旨在新增 MiniMax 作为 LLM 提供商预设，并默认使用其最新的 M2.7 旗舰模型。这为用户提供了更多 LLM 选择，特别是增强了推理和编码能力，具有明确的业务价值。

• 关联性：通过
  尽管没有明确关联 Issue ID，但 PR 描述中的“Why”部分清晰阐述了本次变更的动机和业务价值，足以提供背景信息。

• 类型：feat
  本次变更添加了新的 LLM 提供商支持，并更新了相关配置和文档，完全符合 feat (feature) 类型。

• 描述完整性：不完整（缺失项）
  PR 描述明确列出了对 litellm_config.example.yaml 和 .env.example 的修改，并且 docs/CHANGELOG.md 也提到了这些文件的更新。然而，提供的 diff 中缺少这些文件的具体变更内容。这导致无法全面审查 PR 所声称的所有修改。

• 风险级别：中
  主要风险在于，如果 litellm_config.example.yaml 和 .env.example 的修改未能正确执行，可能会导致 MiniMax LLM 的配置不生效或引发其他配置问题。由于这些文件的实际变更未包含在 diff 中，无法评估其具体实现风险。

必改项

1. 提供的 diff 与 PR 描述不一致。 PR 描述的“Changes”部分明确提到修改了 litellm_config.example.yaml 和 .env.example，并且 docs/CHANGELOG.md 中也记录了这些修改。但提供的 diff 中并未包含这两个文件的变更内容。请务必更新 PR，确保 diff 中包含所有声称修改的文件，以便进行完整的审查。

建议项

1. 在修复上述必改项后，建议提供关于 MiniMax LLM 配置和运行的验证截图或日志（例如，通过 OPENAI_BASE_URL 和 LITELLM_MODEL=openai/MiniMax-M2.7 配置后，成功调用 MiniMax 模型并获得响应的证明），以进一步验证其可用性。

---

💡 提示: 请确保代码已通过本地测试，并遵循项目代码规范。

[ZhuLinsen]

评审结论

• 必要性：通过，PR 聚焦新增 MiniMax 作为 LLM Provider 预设，改动范围基本围绕用户可见能力展开，符合 feat 的最小必要改动方向。
• 是否有对应 issue：无（PR 描述中未看到关联 issue 编号或明确关联说明）
• PR 类型：feat，新增了 Web UI 预设、示例配置和文档说明，属于能力扩展而非缺陷修复。
• description 完整性：不完整，缺少关联 issue、实际验证结果、风险说明、回滚方案；同时 Test Plan 仍是未勾选状态。
• 是否可直接合入：不可，存在仓库规范未满足项和配置说明不一致的问题，需先补齐。

主要问题

1. docs/CHANGELOG.md 未更新。根据仓库 AGENTS.md，涉及用户可见能力、CLI/API 行为、部署方式、通知方式、报告结构变化时必须同步更新 README.md 和 docs/CHANGELOG.md。本 PR 明确新增了用户可见的 LLM provider 能力，但变更文件中没有 docs/CHANGELOG.md，这是合入阻断项。
2. litellm_config.example.yaml 新增了 MINIMAX_LLM_API_KEY 环境变量引用，但 .env.example 没有同步提供该变量示例。AGENTS.md 明确要求新增配置项时必须同步更新 .env.example 和相关文档；目前 .env.example 只新增了 OPENAI_API_KEY / OPENAI_BASE_URL / LITELLM_MODEL 的示例，和 YAML 示例配置不一致，容易导致用户照着 YAML 配置时缺少对应环境变量。
3. docs/LLM_CONFIG_GUIDE.md 与 litellm_config.example.yaml 的 MiniMax 配置入口不一致。前者引导用户走 OPENAI_API_KEY 方案，后者示例使用 MINIMAX_LLM_API_KEY，会造成“同一 provider 到底该填哪个环境变量”的认知冲突，增加配置失败风险。建议统一文档口径，或明确区分“简单模式”和“YAML 模式”的变量命名规则。
4. PR 描述缺少仓库规范要求的风险与回滚说明。对于新增 provider 这类配置面扩展，至少应说明默认行为是否变化、失败时的降级路径，以及回滚到“无 MiniMax 预设”状态的方式；当前描述只有 Summary 和未执行的 Test Plan，不满足 AGENTS.md 的默认交付要求。

---

🤖 此回复由 OpenReview Bot 自动生成，仅供参考。如有疑问请 @维护者。

[massif-01]

@ZhuLinsen 项目已有，我认为应该关闭 @ZhuLinsen

[ZhuLinsen]

评审结论

• 必要性：通过 + 为系统新增 MiniMax 这一一线 LLM 预设，属于明确的用户可见能力补充，改动范围也基本聚焦
• 是否有对应 issue：无（未检测到 Fixes/Closes/Refs 语句）
• PR 类型：feat + 新增 MiniMax 作为可选 LLM provider preset，并补充对应配置与文档
• description 完整性：不完整 + 缺少风险说明、回滚方案，且只有 Test Plan 未提供实际验证结果或未执行原因
• 是否可直接合入：不可 + 必须补齐 docs/CHANGELOG.md，并在 PR 描述中补充验证情况、风险与回滚方案

主要问题

1. docs/CHANGELOG.md 未更新。根据仓库 AGENTS.md，涉及用户可见能力、CLI/API 行为、部署方式、通知方式、报告结构变化时，必须同步更新 README.md 和 docs/CHANGELOG.md；本 PR 明显属于新增用户可见能力，但结构化事实显示未改该文件，这是合入阻断项。
2. PR 描述缺少风险与回滚方案，不符合仓库审查模板要求。按 AGENTS.md，PR 默认需要包含背景、范围、验证、风险、回滚；当前只有 Summary/Changes/Test Plan，缺少“主要风险”和“回滚方式”，不满足直接合入条件。
3. 验证证据不足。该 PR 同时改动了前端文件 apps/dsa-web/src/components/settings/LLMChannelEditor.tsx、配置样例 .env.example、litellm_config.example.yaml 和多份文档，但描述中没有提供已执行的验证结果，也未说明为何未执行 apps/dsa-web 的 lint/build 或脚本级检查；按仓库规范，这至少需要在 PR 描述中明确补充。

---

🤖 此回复由 OpenReview Bot 自动生成，仅供参考。如有疑问请 @维护者。

[ZhuLinsen]

评审结论

• 必要性：不通过 + 补充 MiniMax 预设本身有价值，但当前改动与描述存在偏差，且未满足仓库对用户可见变更的文档要求。
• 是否有对应 issue：无（未检测到 Fixes/Closes/Refs 语句）
• PR 类型：feat + 新增 MiniMax 作为 LLM provider preset，并补充对应示例与前端预设展示
• description 完整性：不完整 + 缺少 issue 关联、风险说明、回滚方案、验证说明不充分，且未说明 docs/CHANGELOG.md 缺失
• 是否可直接合入：不可 + 必改项为补齐 docs/CHANGELOG.md，并修正 PR 描述与实际改动不一致的问题

主要问题

1. docs/CHANGELOG.md 未更新。按仓库 AGENTS.md，涉及用户可见能力、CLI/API 行为、部署方式、通知方式、报告结构变化时，必须同步更新 README.md 和 docs/CHANGELOG.md。本 PR 明显属于用户可见的 LLM 配置与 Web UI 预设变更，当前缺少 changelog 属于流程阻断项。
2. PR 描述与实际改动存在实质性不一致。描述中写了 “Set MiniMax-M2.7 as default model”，但从变更看，实际只是更新 .env.example 注释示例、litellm_config.example.yaml 示例条目顺序，以及前端预设 placeholder；没有看到运行时默认模型配置被真正切换。这会导致 reviewer 和用户误判行为变更范围，按 AGENTS.md 的合入阻断条件，应先对齐描述或补足实现。
3. 验证信息不足。该 PR 同时改了 apps/dsa-web/ 和配置/文档文件，按 AGENTS.md 至少应说明前端是否执行过 npm run lint、npm run build，以及为什么未执行；当前仅写 “Model IDs verified against MiniMax API documentation”，不足以覆盖实际改动面。
4. 缺少风险与回滚说明。仓库规范要求交付需说明风险点和回滚方式；本 PR 涉及新增 provider 预设、示例配置和文档入口，至少需要说明对现有 OpenAI-compatible 配置无行为影响，以及回滚方式为移除新增 MiniMax 示例/预设并恢复原展示顺序。

---

🤖 此回复由 OpenReview Bot 自动生成，仅供参考。如有疑问请 @维护者。

[octo-patch]

感谢详细的评审 @ZhuLinsen！我会补齐 docs/CHANGELOG.md 的更新，并修正 PR 描述。

@massif-01 谢谢提醒！我查看一下现有的 MiniMax 支持情况。

[ZhuLinsen]

评审结论

• 必要性：通过 + 为项目补充 MiniMax 作为可选 LLM provider 预设，改动范围集中在示例配置、文档和 Web UI 提示，符合最小必要改动
• 是否有对应 issue：无（PR 描述中未检测到 Fixes/Closes/Refs 或明确 issue 编号）
• PR 类型：feat + 新增 MiniMax 作为 LLM provider preset，并同步更新示例配置、说明文档和 Web 端预设占位提示
• description 完整性：不完整 + 缺少 issue 关联、风险说明、回滚方案，且未说明前端改动是否执行了 npm run lint / npm run build
• 是否可直接合入：不可 + 当前存在 merge conflict；同时未按仓库规范同步更新 docs/CHANGELOG.md，且 PR 描述未补齐回滚方案

主要问题

1. docs/CHANGELOG.md 未更新。按仓库 AGENTS.md，涉及用户可见能力变化时必须同步更新 README.md 和 docs/CHANGELOG.md；本 PR 已更新 README.md，但 changelog 仍缺失，版本变更记录不完整，发布追踪和回滚依据不足。
2. apps/dsa-web/src/components/settings/LLMChannelEditor.tsx、.env.example、litellm_config.example.yaml、docs/LLM_CONFIG_GUIDE.md 的实际改动更接近“新增/前置 MiniMax-M2.7 示例与预设”，但 PR 描述写成“Set MiniMax-M2.7 as default model”。当前 diff 未体现明确的全局运行时默认值切换，存在描述与实际行为不一致的风险，需澄清是“示例默认/预设优先展示”还是“系统默认模型”。
3. apps/dsa-web/src/components/settings/LLMChannelEditor.tsx 涉及前端改动，但 PR 描述仅写了模型 ID 校验，未按仓库验证矩阵说明 npm run lint、npm run build 是否执行或未执行原因；这类 UI 配置改动虽然较小，但仍可能引入类型、构建或展示回归。

---

🤖 此回复由 OpenReview Bot 自动生成，仅供参考。如有疑问请 @维护者。

[ZhuLinsen]

跟进结论

• 结论：部分接受 + “项目已有”对“仓库早已具备 MiniMax 搜索能力和通用 OpenAI 兼容接入”这一点成立，但不足以据此关闭这个 PR，因为当前改动确实新增了 MiniMax 的 LLM 预设示例和 Web UI 渠道预设。
• 是否仍有阻断：有 + docs/CHANGELOG.md 仍未补齐，PR 描述里“Set MiniMax-M2.7 as default model”也与当前代码不符，而且当前分支还存在合并冲突。

说明

1. src/search_service.py、src/config.py、README.md 里早就有 MINIMAX_API_KEYS 和 MiniMax 搜索链路，docs/CHANGELOG.md 也已有 MiniMax search provider 的历史记录；所以此前如果把这次 PR 表述成“从零新增 MiniMax 能力”，现在应收窄为“补充 MiniMax 的 LLM 预设/示例”，这点我接受。
2. 但“这个 PR 应该关闭”不成立。apps/dsa-web/src/components/settings/LLMChannelEditor.tsx 在基线里没有 minimax 渠道预设，这次新增了 label、baseUrl 和模型 placeholder；litellm_config.example.yaml、.env.example、docs/LLM_CONFIG_GUIDE.md 也新增了 MiniMax LLM 的具体配置示例，所以这不是纯重复提交。
3. docs/CHANGELOG.md 仍然不在本次改动文件列表里。即便按“已有通用能力”收窄定性，这个 PR 也至少引入了新的 Web UI 预设和新的文档语义，按仓库规范这里仍需要补一条变更记录。
4. PR 描述写的是“Set MiniMax-M2.7 as default model”，但当前改动只是在 .env.example、docs/LLM_CONFIG_GUIDE.md、litellm_config.example.yaml 和前端 placeholder 中把 M2.7 放到示例/展示的前面；我没有看到 src/config.py、系统默认值或运行时选择逻辑有对应变更，所以这句仍然会误导读者。
5. 当前 CI 已是 success，所以这一轮不再把 CI 作为问题；剩余阻断点是上面的文档/描述一致性，以及结构化事实里已明确给出的合并冲突。

---

🤖 此回复由 OpenReview Bot 自动生成，仅供参考。如有疑问请 @维护者。

[octo-patch]

感谢跟进评审 @ZhuLinsen！您说得对，PR 描述需要修正，不应表述为"从零新增"而应是"补充 MiniMax LLM 预设示例"。

我会修复以下问题：

1. 解决合并冲突
2. 补充 docs/CHANGELOG.md 条目
3. 修正 PR 描述，使其准确反映改动范围

请稍等，我会尽快推送更新。

[ZhuLinsen]

评审结论

• 必要性：通过 + 补充 MiniMax 作为可选 LLM 预设、示例配置和文档说明，属于明确的用户可见能力扩展，改动范围也基本收敛在相关文件内。
• 是否有对应 issue：无（PR 描述中未检测到 Fixes/Closes/Refs 或 issue 编号）
• PR 类型：feat + 新增 Web 渠道预设、LiteLLM YAML 示例和文档说明，未改动现有默认运行逻辑。
• description 完整性：不完整 + 风险/回滚已补齐，但仍缺少 issue 关联，且未明确说明前端改动的本地验证证据，以及英文详细指南未同步的原因。
• 是否可直接合入：不可 + 当前 CI 已通过，但新增 MiniMax YAML 示例与现有 GitHub Actions / .env.example 配置入口不一致，属于需要先修正的兼容性问题。

主要问题

1. [Correctness blocker] litellm_config.example.yaml 新增的 MiniMax deployment 全部引用 os.environ/MINIMAX_LLM_API_KEY，但 .github/workflows/daily_analysis.yml 当前只注入 LITELLM_API_KEY、OPENAI_API_KEY、ANTHROPIC_API_KEY 等固定变量，没有 MINIMAX_LLM_API_KEY；同时 .env.example 新增的 MiniMax 示例又是 OPENAI_API_KEY / OPENAI_BASE_URL / LITELLM_MODEL 这一套。结果是同一个 MiniMax 配置在“极简模式”和“YAML 模式”里引入了两套未说明清楚的变量命名，而且 GitHub Actions 用户如果按本 PR 的 YAML 示例配置，运行时拿不到密钥。这和仓库现有 README.md、docs/LLM_CONFIG_GUIDE.md 中“GitHub Actions 也支持 YAML 高级配置”的路径不一致。置信度：高。
2. docs/LLM_CONFIG_GUIDE.md 已新增 MiniMax 详细配置，但 docs/LLM_CONFIG_GUIDE_EN.md 没有同步，且中文文档内示例编号已出现两个“示例 4”。这不是“完全无文档”，而是本 PR 扩大了已有中英文详细指南的漂移；按 AGENTS.md，这里至少需要补同步，或在 PR 说明里明确写清不同步的范围和原因。

---

🤖 此回复由 OpenReview Bot 自动生成，仅供参考。如有疑问请 @维护者。

[ZhuLinsen]

这版也先不考虑合入，准备关闭。
原因不是 MiniMax 不支持，而是当前更倾向于保留 LiteLLM 统一接入的整体方向，不想继续引入一套单独的 MiniMax provider 语义。

这个 PR 里加的 preset / 文档方向本身是有价值的，但当前更优先的是先把 minimax/... 模型名前缀在配置归一化、前端展示和运行时选择里的兼容性问题修好，避免模型名被错误改写。相比之下，单独增加 preset 不是最紧迫的问题，而且如果底层归一化逻辑还没完全理顺，先加 preset 反而容易让用户更早踩到兼容性问题。

所以这版我先关闭。
后续如果需要，可以再单独提一个更小的 PR，只保留：

MiniMax 的文档示例
或者 UI 上的轻量 preset

前提是底层模型名前缀兼容问题已经先处理好。

感谢贡献。