feat: add MiniMax as a native LLM provider

[octo-patch]

Summary

Add MiniMax as a native LLM provider, enabling users to use MiniMax models (MiniMax-M1, MiniMax-M2.5, etc.) for stock analysis alongside the existing providers.

MiniMax was previously only used for web search in this project. This PR promotes it to a first-class LLM provider by:

• Registering minimax in _MANAGED_LITELLM_KEY_PROVIDERS and SUPPORTED_LLM_CHANNEL_PROTOCOLS
• Parsing MINIMAX_API_KEY / MINIMAX_API_KEYS for LLM use (same key works for both LLM and search)
• Auto-inferring LITELLM_MODEL=minimax/MiniMax-M1 when only a MiniMax key is configured
• Adding MiniMax deployments to the legacy Router model list
• Mapping the minimax provider in get_api_keys_for_model() and vision key map
• Adding __legacy_minimax__ to _PLACEHOLDER_TO_PROVIDER in agent_model_service.py

All three configuration modes are supported:

• Simple mode: MINIMAX_API_KEY=xxx (auto-detected)
• Channel mode: LLM_CHANNELS=minimax
• YAML mode: minimax/MiniMax-M1 entries in litellm_config.yaml

LiteLLM (>=1.80) has native MiniMax support, so no additional dependencies are needed.

Changes

File	Change
src/config.py	Register provider, parse keys, update model inference & key mapping
src/services/agent_model_service.py	Add __legacy_minimax__ to _PLACEHOLDER_TO_PROVIDER
.env.example	Add MiniMax LLM configuration examples
README.md	Add MiniMax to supported AI models list
docs/CHANGELOG.md	Add Unreleased entry for MiniMax provider
docs/LLM_CONFIG_GUIDE.md	Add MiniMax quick-start example
litellm_config.example.yaml	Add MiniMax YAML configuration example

Test

Verified that:

• minimax appears in _MANAGED_LITELLM_KEY_PROVIDERS and SUPPORTED_LLM_CHANNEL_PROTOCOLS
• Setting MINIMAX_API_KEY auto-infers LITELLM_MODEL=minimax/MiniMax-M1
• get_api_keys_for_model('minimax/MiniMax-M1', config) returns the correct keys
• Legacy model list includes MiniMax deployments
• _PLACEHOLDER_TO_PROVIDER includes __legacy_minimax__ mapping
• No syntax errors in config.py

Rollback Plan

To rollback this change:

1. Remove the minimax entries from src/config.py (PROVIDER_CONFIGS and related functions)
2. Remove __legacy_minimax__ from _PLACEHOLDER_TO_PROVIDER in src/services/agent_model_service.py
3. Remove MiniMax-related env vars from .env.example
4. Remove MiniMax section from docs/LLM_CONFIG_GUIDE.md and litellm_config.example.yaml
5. Revert the MiniMax Unreleased entry in docs/CHANGELOG.md
6. Existing LiteLLM-based MiniMax access via litellm/MiniMax-M2.7 remains unaffected

[github-actions]

🤖 自动审查报告

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

📁 修改的文件

• 📝 .env.example (+6/-1)
• 📝 README.md (+2/-2)
• 📝 docs/CHANGELOG.md (+6/-0)
• 📝 docs/LLM_CONFIG_GUIDE.md (+7/-0)
• 📝 litellm_config.example.yaml (+6/-0)
• 📝 src/config.py (+32/-7)
• 📝 src/services/agent_model_service.py (+1/-0)

---

🧠 AI 代码审查意见

结论

Ready to Merge

结构化审查结果

必要性

通过。 本次 PR 为系统增加了 MiniMax 作为一个原生 LLM 提供商的支持。MiniMax 是一个受欢迎的模型提供商，此项变更能够扩展用户选择，提升系统的灵活性和用户体验，具有明确的业务价值。

关联性

通过。 PR 描述清晰地阐述了添加 MiniMax LLM 提供商的动机和实现方式，虽未直接关联 GitHub Issue，但动机清晰且验收标准明确。

类型

feat。 新增 MiniMax LLM 提供商功能，符合 feat 类型定义。

描述完整性

基本完整。

• 背景与范围：描述清晰地阐明了变更背景（将 MiniMax 从仅用于搜索提升为原生 LLM）和变更范围（代码配置、文档更新、示例）。
• 验证命令与结果：PR 描述中提供了详细的验证点（包括配置注册、API Key 解析、模型自动推断、旧版路由模型列表更新、以及无语法错误），并说明已通过验证。结合 CI 检查状态，语法和致命 Lint 错误已通过。
• 兼容性风险：描述中提及 LiteLLM (>=1.80) 原生支持 MiniMax，隐含了较低的兼容性风险。
• 回滚方案：未明确说明，但考虑到是新增功能，直接回滚本次 PR 提交即可，风险低。
• 缺失项：对 Python 后端代码的改动，PR 描述中未说明是否执行了 ./scripts/ci_gate.sh 或给出跳过原因。这不构成阻断，但会在建议项中提及。

风险级别

低。

• 核心逻辑修改遵循了现有 LiteLLM 集成和多提供商配置的模式，风险可控。
• 主要变更是新增功能和配置，对现有功能的破坏性较小。
• 文档和配置示例更新及时且全面。

必改项

无。

建议项

1. 补充 CI Gate 运行情况：考虑到 src/config.py 和 src/services/agent_model_service.py 属于 Python 后端核心代码，建议在 PR 描述中补充 ./scripts/ci_gate.sh 的执行情况（例如，是否在本地运行过，结果如何），或说明跳过原因。这有助于确保代码质量和一致性。

---

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

[ZhuLinsen]

评审结论

• 必要性：通过 + 原生接入 MiniMax 作为 LLM provider 能补齐现有能力边界，改动目标明确且与项目定位相关。
• 是否有对应 issue：无（PR 描述中未见关联 issue 编号或说明）
• PR 类型：feat + 新增 MiniMax 原生 LLM 能力，并补充对应配置与文档示例。
• description 完整性：不完整 + 缺少风险说明、回滚方案，且未按仓库规范说明 docs/CHANGELOG.md 是否同步更新。
• 是否可直接合入：不可 + 必改项是补充回滚方案，并按 AGENTS.md 要求同步更新 docs/CHANGELOG.md；同时建议补齐与验证矩阵一致的验证说明。

主要问题

1. docs/CHANGELOG.md 未见更新。该 PR 属于用户可见能力与配置方式变更，AGENTS.md 明确要求同步更新 README.md 和 docs/CHANGELOG.md；当前只更新了 README.md 与配置指南，发布记录缺失，后续会增加版本追踪和回溯成本。
2. PR 描述缺少回滚方案。根据 AGENTS.md，“缺少回滚方案”属于合入阻断条件；当前没有说明 MiniMax provider 引入后若出现 LiteLLM 兼容性、路由异常或 key 解析副作用时如何回退。
3. PR 描述缺少风险说明。此次改动触及 src/config.py 的模型自动推断、legacy router model list、key 映射与搜索/LLM 共用 key 语义，存在配置兼容性和默认行为变化风险，但描述中未交代影响面与降级路径。
4. 验证说明不够完整。AGENTS.md 对 Python 后端改动要求优先执行 ./scripts/ci_gate.sh，环境不足时至少明确给出 python -m py_compile <changed_python_files> 等最低验证；当前仅写“config.py 无语法错误”和若干功能点已验证，缺少与仓库验证矩阵对齐的证据说明。

---

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

[ZhuLinsen]

评审结论

• 必要性：通过 + 该 PR 为项目新增原生 MiniMax LLM provider，和现有 LiteLLM 接入体系一致，属于明确且有价值的能力补充。
• 是否有对应 issue：无（未检测到 Fixes/Closes/Refs 语句）
• PR 类型：feat + 新增原生模型提供商支持，并补充了相关配置与文档示例。
• description 完整性：不完整 + 缺少 issue 关联、风险说明、回滚方案，且未说明 ./scripts/ci_gate.sh 是否执行或为何未执行。
• 是否可直接合入：不可 + 需先补齐 docs/CHANGELOG.md，并在 PR 描述中补充回滚方案与验证说明；否则不满足仓库 AGENTS.md 的变更与审查要求。

主要问题

1. docs/CHANGELOG.md 未更新。该 PR 属于用户可见能力变更（新增原生 MiniMax LLM provider），按仓库 AGENTS.md 要求，此类变更必须同步更新 README.md 和 docs/CHANGELOG.md；当前只更新了 README.md，发布记录缺失。
2. PR 描述缺少回滚方案。AGENTS.md 将“缺少回滚方案”列为合入阻断项；当前描述只有 Summary/Changes/Test，没有说明回退到旧行为的路径，不能直接合入。
3. 验证证据不足。此次修改涉及 src/config.py，属于 Python 后端改动，按 AGENTS.md 应优先执行 ./scripts/ci_gate.sh；若环境不足，至少需要明确最低验证范围及缺失原因。当前描述仅提到 config.py 无语法错误，未给出 ci_gate.sh 执行情况，也未说明未执行原因。
4. issue 关联缺失。虽然这不是阻断项，但按仓库规范应优先使用 Fixes #xxx 或 Refs #xxx 建立关联；当前无法判断该能力新增的背景来源与优先级依据。

---

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

[ZhuLinsen]

跟进结论

• 结论：部分接受 + 现有改动已经补齐 MiniMax 作为原生 LLM provider 的主路径说明，我收窄此前对“文档缺失”的判断；但 docs/CHANGELOG.md、存量文档同步和一处配套服务漏改仍未解决。
• 是否仍有阻断：有 + 当前存在明确合并冲突，且 PR 描述仍缺回滚方案，按仓库规则还不能直接合入。

说明

1. README.md、.env.example、docs/LLM_CONFIG_GUIDE.md、litellm_config.example.yaml 已经覆盖了 MiniMax 的单 Key 自动识别、MINIMAX_API_KEY/MINIMAX_API_KEYS、YAML 示例，以及“同一个 Key 同时用于 LLM 和 Web Search”的主语义，所以“这项能力完全没文档化”这个表述过重，我这里收回。
2. 但 docs/CHANGELOG.md 的 Unreleased 仍为空；按 AGENTS.md 对“用户可见能力变更需同步更新 README.md 和 docs/CHANGELOG.md”的规则，这一项目前仍未满足。
3. src/config.py 已新增 __legacy_minimax__ 占位部署；但 src/services/agent_model_service.py 的 _PLACEHOLDER_TO_PROVIDER 仍只覆盖 gemini、anthropic、openai、deepseek。这会导致 legacy env 模式下的 MiniMax 多 Key 在 Agent models API 里按 direct-env provider 退化为单 deployment 展示，和本次对外宣称的“支持多 Key 负载均衡”暴露结果不完全一致，建议连同对应测试一起补齐。
4. README.md 已把 MINIMAX_API_KEYS 改成“同时用于 LLM 和 Web Search”，但 docs/full-guide.md、docs/README_EN.md、docs/README_CHT.md、docs/full-guide_EN.md 仍保留旧的 “Coding Plan Web Search” 语义。这里更准确的定性是“存量文档语义未同步”，而不是“主文档没写”；风险是不同入口给出相互矛盾的配置解释。
5. 当前 CI 已是 success，所以我不再把 ./scripts/ci_gate.sh 未在 PR 描述中说明视为阻断；这部分现在更适合归类为验证说明不够完整。
6. PR 描述现在有 Summary / Changes / Test，但仍没有风险点和回滚方式；而 AGENTS.md 的合入阻断条件里明确包含“缺少回滚方案”。
7. 结构化事实已明确当前分支“存在冲突，当前不能直接合并”；这属于需要先处理的真实阻断，不是单纯的分支保护状态提示。

---

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

[ZhuLinsen]

评审结论

• 必要性：通过 + 原生接入 MiniMax 作为 LLM provider 与现有 LiteLLM 架构一致，目标明确且有实际价值
• 是否有对应 issue：无（未检测到 Fixes/Closes/Refs，讨论区也未见明确 issue 关联）
• PR 类型：feat + 新增 MiniMax 原生 LLM provider、配置入口与示例文档
• description 完整性：不完整 + 缺少风险说明、回滚方案，且未说明 ./scripts/ci_gate.sh 是否执行或为何未执行
• 是否可直接合入：不可 + 当前存在明确合并冲突；此外 MiniMax 在 Web UI / 配置服务链路仍有联动漏改，且 PR 描述缺少回滚方案

主要问题

1. [Correctness blocker] apps/dsa-web/src/components/settings/LLMChannelEditor.tsx 仍未接入 minimax。ChannelProtocol、PROTOCOL_OPTIONS、KNOWN_MODEL_PREFIXES、MANAGED_PROVIDERS 都缺少该 provider，normalizeProtocol() 对未识别协议默认回落到 openai。这会让已有的 LLM_*_PROTOCOL=minimax 渠道在 Web UI 中被当成 OpenAI 兼容渠道，minimax/MiniMax-M1 这类模型还可能被前端预览/回写成错误的 openai/... 形式；用户只要打开并保存渠道编辑器，就可能把新 provider 配置写坏，所以 PR 描述里“channel mode supported”在 Web 设置路径上并未闭环。
2. [Correctness blocker] src/services/system_config_service.py 与 src/services/agent_model_service.py 还有 MiniMax 配套映射漏改。前者 _has_legacy_key_for_provider() 仍不识别 minimax，后者 _PLACEHOLDER_TO_PROVIDER 也没有 __legacy_minimax__，但 src/config.py 已经开始生成该占位符。结果是系统设置校验、模型部署展示与实际运行时行为不一致，新增 provider 没有在现有配置服务链路中完整打通。
3. [Process blocker] docs/CHANGELOG.md 未更新，不符合 AGENTS.md 对“用户可见能力变更必须同步 README 和 docs/CHANGELOG.md”的要求。另一个问题是：仓库里并非完全没有文档，而是已有通用文档/配置元数据仍沿用“MiniMax 仅用于搜索”的旧语义，例如 docs/DEPLOY.md、docs/full-guide.md、docs/README_EN.md、docs/README_CHT.md、src/core/config_registry.py、apps/dsa-web/src/utils/systemConfigI18n.ts；本次新增的“同一 Key 同时用于 LLM 和 Web Search”语义没有同步完，容易继续误导用户。

---

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

[octo-patch]

感谢详细的跟进评审 @ZhuLinsen！已修复以下问题：

1. ✅ 合并冲突已解决（基于最新 main 重新 cherry-pick，保留了 Ollama 与 MiniMax 双方改动）
2. ✅ docs/CHANGELOG.md 已在 Unreleased 段添加 MiniMax 条目
3. ✅ src/services/agent_model_service.py 补充 __legacy_minimax__ 到 _PLACEHOLDER_TO_PROVIDER
4. ✅ PR 描述已补充完整回滚方案

关于 Web UI 集成和存量文档同步，这些属于更大范围的改动，我建议在后续 PR 中单独处理，以保持本 PR 的改动范围可控。请问这个方案是否可接受？

[ZhuLinsen]

评审结论

• 必要性：通过 + 原生接入 MiniMax 作为 LLM provider 与现有 LiteLLM 架构一致，能力补齐有明确价值。
• 是否有对应 issue：无（未检测到 Fixes/Closes/Refs，描述里也未补充“无 issue 时的验收标准”说明）。
• PR 类型：feat + 新增 MiniMax 原生 LLM provider、配置入口与示例文档。
• description 完整性：不完整 + 按仓库模板仍缺 Issue Link、Verification Commands And Results 的实际命令/关键结果、Compatibility And Risk；Rollback Plan 已补齐。
• 是否可直接合入：不可 + 当前有明确兼容性/正确性回归：MINIMAX_API_KEYS 会静默改写存量主模型选择，且 MiniMax-only 配置下会打断图像识股/vision 路径；另外本次新增语义仍未同步到 Web 配置文案和多处存量文档。

主要问题

1. [Correctness blocker] src/config.py 现在把 MINIMAX_API_KEY(S) 纳入主模型自动推断，并且优先级放在 OPENAI_API_KEY/AIHUBMIX_KEY 之前。问题在于 MINIMAX_API_KEYS 在当前仓库里原本就是现有的搜索配置项，存量文档和配置页也一直把它描述为搜索用途；这意味着已有用户只要同时配置了 MiniMax 搜索 key 和 OpenAI 兼容 LLM key，当前 PR 就会把默认主模型静默切到 minimax/MiniMax-M1。这不是单纯“新增 provider”，而是扩大了已有配置项语义并改变了默认行为，存在明显兼容性风险。
2. [Correctness blocker] src/config.py 的新默认路径和 src/services/image_stock_extractor.py 不一致。当前逻辑下，MiniMax-only 配置会把 LITELLM_MODEL 推断成 minimax/MiniMax-M1，图像识股又会回退到这个主模型；但 image_stock_extractor 自己的 _get_api_keys_for_model() 仍只处理 gemini/anthropic/openai，对 minimax/... 会返回空 key，最终直接报 No API key found for vision model minimax/MiniMax-M1。这会把新 provider 的默认路径扩散成现有图片入口的回归。
3. [Process blocker] 已有通用文档，但本次新增语义未同步到存量入口：src/core/config_registry.py、apps/dsa-web/src/utils/systemConfigI18n.ts 以及 docs/full-guide.md、docs/README_EN.md、docs/README_CHT.md、docs/DEPLOY*.md 等位置仍把 MINIMAX_API_KEYS 描述为 search-only；同时本次改动里的 docs/CHANGELOG.md 写的是 “M2.7 default model”，而代码和其余新文档实际落的是 MiniMax-M1。按 AGENTS.md，这种配置语义变化需要同步相关文档和用户可见配置说明，否则会继续放大误导。

---

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

[ZhuLinsen]

这版先不考虑合入，准备关闭。
综合看下来，当前项目更适合继续走 LiteLLM 的统一接入方案，而不是再把 MiniMax 扩成一个新的 native / managed provider。

这个 PR 会把 minimax 加入 _MANAGED_LITELLM_KEY_PROVIDERS、SUPPORTED_LLM_CHANNEL_PROTOCOLS，同时引入专门的 key 解析、默认模型推断、legacy placeholder 和额外的 provider 分支判断。对当前项目来说，整体复杂度上升比较明显，但实际收益有限，因为 MiniMax 本身已经可以通过 LiteLLM 的统一方式接入。

当前更需要解决的是：

minimax/... 这类模型名前缀能被正确识别
在 channel / Web UI / runtime 配置中不要被错误改写

这部分由另一个更小、更聚焦的修复来处理会更合适。
因此这个 PR 我这边先关闭，后续如果项目明确要扩充 native provider 体系，再单独讨论。

感谢贡献。