必须同时提供有效的 Group ID 和 API Key，并按接口版本匹配传参方式：v1 接口需将 group_id 作为 query 参数拼入 URL，v2 接口虽可省略但跨组织场景仍需显式传入。

想在 MiniMax 平台顺利调用 Agent 接口，并让请求既能完成鉴权、又能准确路由到对应组织，有两个前提不能少：有效的 Group ID 和 API Key。

同时，传参方式还得和接口版本严格对齐。旧版 v1 接口要求把 group_id 作为 query 参数拼进 URL，这一步少不了，缺任何一项都不行。

至于新版 v2 接口，虽然在形式上可以不传 group_id，但如果项目涉及多组织归属，或者存在跨 group 调用的情况，最好还是显式带上。

原因也很直接：否则请求有可能落到错误的配额池里，甚至触发不匹配的权限策略。

获取 Group ID 和 API Key

登录 MiniMax 最新开发者控制台（当前有效入口为 https://api.minimax.chat/console），使用已实名认证的账号进入「API 密钥管理」页面。

点击【创建新密钥】，填写应用名称（如“客服机器人”），选择对应项目后确认生成。

密钥生成后，页面立即显示 【api_key（sk-开头）】 和 【group_id（grp_开头，16位十六进制字符串）】。

这两项仅在此刻完整可见，关闭页面即不可再查，务必全选复制并保存至安全位置。

区分接口版本决定传参方式

新版 v2 接口路径为 /v1/text/chatcompletion_v2，认证仅需 Header 中携带 Authorization: Bearer {api_key}，group_id 通常不强制传入。

旧版 v1 接口路径为 /v1/text/chatcompletion，必须将 group_id 作为 query 参数拼在 URL 后面。

例如：https://api.minimax.chat/v1/text/chatcompletiongroup_id=grp_abc123。若遗漏，服务端返回 401 错误而非明确提示参数缺失，极易误判为密钥失效。

注意：Agent 类接口（如调用已发布的智能体）默认走 v1 路径，除非文档明确标注支持 v2，否则一律按旧版规则处理。

安全注入凭证到运行环境

方法一：使用 .env 文件（推荐）

在项目根目录新建 .env 文件，写入两行：

• MINIMAX_GROUP_ID=grp_abc123
• MINIMAX_API_KEY=sk-xyz789

Python 中加载：from dotenv import load_dotenv; load_dotenv()。

方法二：直接设置系统环境变量

在 Linux/macOS 终端里，直接执行：

export MINIMAX_GROUP_ID="grp_abc123" && export MINIMAX_API_KEY="sk-xyz789"

如果用的是 Windows PowerShell，则执行：

$env:MINIMAX_GROUP_ID="grp_abc123"; $env:MINIMAX_API_KEY="sk-xyz789"。

方法三：代码中声明（仅限调试，禁止提交至 Git）

直接赋值：

• GROUP_ID = "grp_abc123"
• API_KEY = "sk-xyz789"

这一步操作起来很简单，但上线前必须删掉，否则密钥会随代码泄露。

构造含 Agent ID 的请求（以旧版 v1 为例）

• 第一步：确认 Agent 已发布，在 Agent 详情页复制 【Agent ID（agt_开头）】 和测试 Token（或复用项目级 API Key）。
• 第二步：组装请求 URL：https://api.minimax.chat/v1/text/chatcompletiongroup_id=grp_abc123。
• 第三步：设置 Headers：{"Authorization": "Bearer sk-xyz789", "Content-Type": "application/json"}。
• 第四步：构造 Body JSON，确保包含 "agent_id": "agt_def456" 和 "messages": [{"role": "user", "content": "你好"}]；缺少 agent_id 字段会导致 404，不是 401。