Nightingale 如何通过 API 创建和管理 AI 助手的大模型配置

Nightingale 如何通过 API 创建和管理 AI 助手的大模型配置【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingaleNightingale 的 AI 助手依赖一套集中管理的大模型LLM配置模型地址、API Key、模型名和采样参数都存在ai_llm_config表里助手按配置 ID 引用它们。如果你的目标是通过接口脚本、CI 或第三方系统完成测试连通性 → 创建配置 → 查询 → 更新 → 删除这一整套操作API 文档给出的 6 个端点就是全部所需。前提条件是 nightingale center 服务已启动且调用账号具备 LLM 配置管理权限——API 文档将其表述为管理员权限authadmin路由实现上对应的是auth、user加/ai-config/llm-configs权限检查见 路由注册 中ai-llm-configs相关行。下文命令统一假设N9E_ADDRcenter 服务的地址加端口例如http://127.0.0.1:port替换为你的实际部署地址token登录返回的 JWT用于后续所有请求。准备登录并拿到请求 tokencurl -s -X POST N9E_ADDR/api/n9e/auth/login \ -H Content-Type: application/json \ -d {username: admin, password: 你的登录密码}username和password是必填字段登录请求结构见 router_login.go。两条条件性要求服务开启验证码时请求体还需带captchaid和verifyvalue可先调POST /api/n9e/auth/captcha获取服务开启 RSA 登录加密时password需先按服务端公钥加密再提交。登录成功后dat字段返回 JWT token。后续所有/api/n9e/ai-llm-config*请求都要在请求头中携带AUTHAuthorization: Bearer token如果服务端启用了固定 token 认证TokenAuth也可以改用X-User-Token头传递用户 token两者在 tokenAuth 中间件 中是并列的鉴权途径。先不创建配置直接测试连通性创建配置前建议先验证模型端点、Key 和模型名是否正确。POST /api/n9e/ai-llm-config/test直接基于你传入的连接参数发起真实请求配置不必事先存在curl -s -X POST N9E_ADDR/api/n9e/ai-llm-config/test \ -H $AUTH -H Content-Type: application/json \ -d { api_type: openai, api_url: https://api.openai.com, api_key: sk-你的真实Key, model: gpt-4o, extra_config: { timeout_seconds: 30, skip_tls_verify: false, proxy: , custom_headers: {} } }api_url、api_key、model以上面的文档示例值为模板替换为你自己的。探测行为由 probe.go 实现服务端按api_type向对应端点发送一条Hi消息输出上限 512 token。三种api_type的实际请求如下来自 API 文档api_type请求 URL鉴权方式openai{api_url}/chat/completionsAuthorization: Bearer {api_key}claude{api_url}/v1/messagesx-api-key: {api_key}gemini{api_url}/v1beta/models/{model}:generateContent?key{api_key}URL 参数文档示例的成功响应{ dat: { success: true, duration_ms: 856 }, err: }success为true即端点、凭据、模型名三者都验证通过。一个值得注意的判定推理模型reasoning model可能把 512 token 全部花在思考上正文为空且finish_reasonlength——这种情况连接仍视为健康因为探测目的验证端点/鉴权/模型已达成只有响应正常结束finish_reasonstop却完全无内容时才会报 no content。失败时文档示例如下{ dat: { success: false, duration_ms: 5000 }, err: HTTP 401: {\error\: \invalid api key\} }注意实现细节当前路由实现同时会把分类后的错误信息放进dat.error字段见 aiLLMConfigTest 处理器错误文案跟随请求头X-Language的语言设置。创建 LLM 配置连通性验证通过后创建配置。POST /api/n9e/ai-llm-configs的必填字段是name、api_type、api_url、api_key、modelapi_type取值为openai、claude、gemini三种文档示例curl -s -X POST N9E_ADDR/api/n9e/ai-llm-configs \ -H $AUTH -H Content-Type: application/json \ -d { name: gpt-4o, description: OpenAI GPT-4o, api_type: openai, api_url: https://api.openai.com, api_key: sk-你的真实Key, model: gpt-4o, extra_config: { timeout_seconds: 60, temperature: 0.7, max_tokens: 4096, custom_headers: { X-Custom: value } }, enabled: true }成功响应返回新配置的 ID文档示例{ dat: 1, err: }两条来自 模型实现 的硬规则创建前要知道name 全局唯一重名会返回ai llm config name xxx already exists错误默认配置系统中第一条配置自动成为默认is_default true后续创建或更新时把is_default置为true会清除其他行上的默认标记保证默认配置唯一。extra_configLLMExtraConfig各字段及含义见 API 文档timeout_seconds请求超时默认 30 秒、skip_tls_verify、proxy、custom_headers、custom_params、temperature、max_tokens、context_length全部可选。查询配置与 Key 的掩码规则# 列出全部 curl -s N9E_ADDR/api/n9e/ai-llm-configs -H $AUTH # 按 ID 查详情 curl -s N9E_ADDR/api/n9e/ai-llm-config/1 -H $AUTH列表按 ID 排序查详情时 ID 不存在返回404ai llm config not found。注意响应中api_key是掩码值而不是明文保留前 4 位和后 4 位、中间以****替代例如sk-a****wxyz长度不超过 8 位的 Key 整体显示为****见 MaskAPIKey。所以从 GET 响应里拿到的 Key 不能当作真实 Key 再用于测试或更新——后文会说明服务端如何处理这种回传。更新配置curl -s -X PUT N9E_ADDR/api/n9e/ai-llm-config/1 \ -H $AUTH -H Content-Type: application/json \ -d { name: gpt-4o, description: OpenAI GPT-4o, api_type: openai, api_url: https://api.openai.com, api_key: , model: gpt-4o-mini, enabled: true }请求体结构与创建接口一致校验规则也一致。关于api_key有两条保留原值的路径文档规则api_key传空字符串时保留已有值而不覆盖实现补充如果你把 GET 拿到的掩码值原样 PUT 回来更新处理器 会识别出这是掩码回传同样保留真实 Key不会把sk-a****wxyz写进数据库。只有确实要换 Key 时才传新的明文api_key。改名时依然受 name 唯一性约束。成功响应为{dat: , err: }ID 不存在返回404。删除配置curl -s -X DELETE N9E_ADDR/api/n9e/ai-llm-config/1 -H $AUTH删除成功响应同样为{dat: , err: }ID 不存在返回404。删除是不可逆操作执行前确认没有助手还引用该配置的 ID。把配置接到 AI 助手上LLM 配置创建后AI 助手Agent通过llm_config_id字段引用它。按 AI Agent API 文档创建 Agent 时llm_config_id必填且必须大于 0curl -s -X POST N9E_ADDR/api/n9e/ai-agents \ -H $AUTH -H Content-Type: application/json \ -d { name: chat-agent, use_case: chat, llm_config_id: 1, enabled: true }另外当自动接入的消费者如默认 chat agent没有绑定具体LLMConfigId时会回退使用is_default true且enabled true的那条配置见 AILLMConfigPickDefault——这就是第一条配置自动设为默认这个行为存在的意义。连接测试失败时怎么读错误POST /api/n9e/ai-llm-config/test的错误信息按 HTTP 状态分类分类逻辑见 classifyProbeError每类都附带服务端响应原文错误类别触发条件含义鉴权失败HTTP 401/403API Key 不正确检查api_key端点不存在HTTP 404检查api_urlOpenAI 兼容接口的 URL 应以/v1结尾例如https://api.openai.com/v1限流HTTP 429Key 配额耗尽或请求过于频繁请求失败其他非 2xx 状态附带具体状态码响应格式异常无法解析响应体api_url可能指向了错误的端点模型错误 / 无内容提供方返回模型级错误检查model字段填的模型名是否正确边界说明api_type目前只支持openai、claude、gemini三种所有接口都要求登录态与 LLM 配置管理权限普通无权限账号调用会得到鉴权失败创建、更新、删除操作都会真实落库并影响所有引用该配置的助手批量变更前建议先用 test 端点验证、再逐条操作。【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingale创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考