MiniMax_Agent_GroupID和API_Key配合方法

必须同时提供有效的 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 密钥管理」页面。

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

密钥生成后，页面立即显示

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

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

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

旧版 v1 的接口地址是 /v1/text/chatcompletion，这里有个很容易踩坑的细节：

。比如：https://api.minimax.chat/v1/text/chatcompletion?group_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 详情页复制

和测试 Token（或复用项目级 API Key）。

第二步：组装请求 URL：https://api.minimax.chat/v1/text/chatcompletion?group_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。