应用(App)
一个 App = 一个可发布的喵喵分身:它绑定自己的提示词(或人格)、模型、工具与知识库开关,并拥有专属的 App 级 API key。把那把 key 发给一台设备 / 一个产品 / 一个客户,对方调 /v1/agent 时拿到的就是这个分身——key 决定身份,请求体里什么都不用多传。
概念(30 秒)
- 租户通用 key:你一直在用的 key(
app_id为空),代表整个租户的默认行为,且只有它能管理 App; - App 级 key:从某个 App 签发的 key,调
/v1/agent即该 App 的配置;调任何/v1/apps*管理端点一律403「App 级 key 无管理权」(最小权限); - 配置全部可缺省:App 没配的字段逐级回落(见下表),所以「只改个提示词,其余跟租户走」是最常见形态;
- 配额:每租户最多 20 个 App;名称 ≤60 字,直写提示词 ≤8000 字。
三步发布一个分身
bash
# 1) 建 App(用租户通用 key)
curl -X POST "$BASE/v1/apps" \
-H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
-d '{"name": "客服喵", "system_prompt": "你是 XX 产品的客服…", "kb_enabled": true}'
# → 201 {"id": "<app_id>", …}
# 2) 给它签 App 级 key(明文只回显这一次)
curl -X POST "$BASE/v1/apps/<app_id>/keys" \
-H "Authorization: Bearer $KEY" -H "Content-Type: application/json" -d '{}'
# → 201 {"key": "sk-meow-…", "app_id": "<app_id>", …}
# 3) 用 App key 对话——就是这个分身在说话
curl -N "$BASE/v1/agent" \
-H "Authorization: Bearer <App key>" -H "Content-Type: application/json" \
-d '{"text": "你好", "session_id": "device-001"}'控制台「应用」区提供其中最常用的部分:新建、列表、删除、签发 key(建好就能
粘进试聊框体验)。改名/改 prompt/改模型覆盖/配工具白名单这几样,目前走
PUT /v1/apps/:id(或 /console/apps/:id)接口——UI 编辑卡在路上,接口先行。
配置回落(三级,逐字段)
App 级 key 的每个配置字段独立回落,App 配了用 App 的,没配承租户,租户也没配用平台默认:
| 字段 | App 配置 | ② 租户(控制台「模型设置」等) | ③ 平台默认 |
|---|---|---|---|
| 提示词 | system_prompt > persona_id→人格库 | (请求级 persona_id/persona,见下)→ 租户默认人格 | 默认人格「喵喵」 |
| 模型 | model | 租户模型设置 | MiniMax-M3 |
| 思考开关 | thinking | 租户思考开关 | 关 |
| 温度 | temperature | 租户温度 | 不传(provider 默认) |
| 知识库 | kb_enabled(false = 该 App 恒关,与请求 kb:false 同效) | —(租户有文档即默认开) | 开 |
| 工具 | tools_enabled 白名单([] = 全禁) | — | 全部内置工具 |
提示词的完整优先级(产品语义:App 主人说了算):
code
app.system_prompt > app.persona_id→人格库 > 请求体 persona_id / persona > 租户默认人格 > 平台默认喵喵即:App 显式配置 > 请求级参数 > 默认——给 App 配了提示词后,调用方在请求体里传 persona 也覆盖不掉(防止终端用户改写你发布的分身);App 什么都没配时,请求级参数照常生效(与通用 key 行为一致)。App 引用的人格被删除后静默回落下一级,不报错。
最小权限(App 级 key 能干什么)
| 端点 | 通用 key | App 级 key |
|---|---|---|
/v1/agent、/v1/sessions/*、/v1/tts*、/v1/asr、/v1/kb/* | ✓ | ✓(对话按其 App 配置) |
/v1/apps*(全部管理端点) | ✓ | 403「App 级 key 无管理权」 |
注意:App 级 key 目前仍可读写本租户知识库(
/v1/kb/*)——KB 是租户级资源,App 只有「注入开关」;若你要把 App key 发给不受信的终端,请评估这一点(更细的按 App 限权在路线图上)。
管理 API 一览(双面同形)
机器面 /v1/apps* 用 Bearer 租户通用 key;控制台面 /console/apps* 用登录会话,行为逐字节相同:
| 方法与路径 | 作用 |
|---|---|
GET /v1/apps | 列本租户全部 App |
POST /v1/apps | 新建(name 必填;其余字段可缺省 = 不覆盖) |
GET /v1/apps/:id | 详情 |
PUT /v1/apps/:id | 整体更新(缺省字段 = 清回「不覆盖」,非逐字段 PATCH) |
DELETE /v1/apps/:id | 删除:其全部 App key 同步撤销(立刻 401);会话历史保留(归租户) |
POST /v1/apps/:id/keys | 签发 App 级 key(可带 rate_limit,口径同通用 key;明文只回一次) |
与人格库 / 知识库 / 模型设置的关系
- 人格库:App 的
persona_id引用的就是控制台人格库里的人格——人格改了,所有引用它的 App 即刻生效;system_prompt则是 App 私有的一份独立文本; - 知识库:KB 文档是租户级的(所有 App 共享一套资料);App 用
kb_enabled决定自己对话时检索不检索; - 模型设置:控制台「模型设置」是租户级缺省;App 的
model/thinking/temperature是其上的逐字段覆盖; - 用量:每次调用的用量事件带
app_id,per-App 用量看板在路线图上; - 会话:会话仍按
session_id归属租户,与 App 无关——删 App 不动任何历史。
常见问题
- 通用 key 的行为会变吗? 不会。没有
app_id的 key 全链路行为与引入 App 前完全一致。 - 一个 App 能签几把 key? 不限(配额按租户 key 总量与限流管);撤销单把 key 用
DELETE /console/keys/:id照旧。 - App key 调
/v1/apps为什么 401 而不是 403? 401 说明 key 本身无效(已撤销 / 拼错);403 才是「key 有效但无管理权」。