能力（scope）说明

应用注册时勾选需要的能力，管理员随时可在应用设置里调整；被其他组织安装时， 能力由安装方管理员单独授权（默认零授权，只有免登身份）。

scope	名称	说明	对应接口
（无需勾选，恒定授予）	免登身份	拿到当前用户的 user_id/昵称/头像/组织角色	POST /auth/user
contacts	组织通讯录	读取组织成员列表与团队架构（昵称/头像/角色/团队树）	GET /org/members、GET /org/teams、GET /org/teams/{id}/members
im	IM 消息通知	给组织成员发工作通知（系统账号代发，带应用名前缀）；也管着 JSAPI share（用户选人后以用户自己身份分享，同样需要这个能力）	POST /im/send；JSAPI jlt.share
ai	AI 能力	查可用模型清单 + 调用对话模型，消耗应用所属组织的积分	GET /ai/models、POST /ai/completions
kb	知识库检索	在管理员绑定的知识库范围内检索	POST /kb/search
db	数据库查询	在管理员绑定的外部数据库上只读查询（单条 SELECT、行数上限、语句超时）	GET /db/databases、GET /db/{id}/tables、POST /db/query
ai_tools	AI 工具	给组织成员的 AI 助手注册自定义工具（模型调用经签名回调）	应用设置「AI 工具」，协议见给 AI 注册工具
local	本地能力	页面在用户确认（首访弹窗，可选「始终允许」按应用+域名记住、工具栏可撤销）下从其电脑抓取网页/无头浏览器提取/多步隔离浏览器会话（仅桌面端）；与 ai 一起授予时解锁 JSAPI agent（完整 AI 能力，每轮确认亦可「始终允许」）	JSAPI localFetch / browserExtract / browserOpen… / agent

JSAPI 的选人组件（selectUsers）不需要任何能力：成员由用户亲手挑选， 页面只会拿到被选中的那几位——用户挑选即用户授权。

授权范围的两个层级

1. 应用自身申请的能力（app.scopes）——你在注册/编辑应用时勾选，决定 这个应用最多能用到哪些能力。
2. 组织实际授予的能力——按能力操作的对象分两种情况：

能力	实际生效的判定	原因
contacts / im	操作的是某个组织的数据/成员：目标为应用所属组织时 = 应用自身申请；目标为安装方组织时 = 安装方授予 ∩ 应用自身申请（默认空）	读的是对方的通讯录、打扰的是对方的成员，必须对方管理员同意
ai_tools / local	安装的市场应用 = 安装方授予 ∩ 应用自身申请；自建应用 = 应用自身申请	工具出现在对方成员的 AI 助手里、本地能力跑在对方成员的设备上——影响的是安装方的人，必须对方管理员同意
ai / kb / db	只看应用自身申请，与安装方是否授予无关	消耗/访问的都是应用所属组织的资源——AI 计费走应用组织的钱包，知识库/数据库白名单由应用组织的管理员绑定

也就是说：即使应用申请了 contacts 能力，安装方组织如果没有勾选，你调 GET /org/members?org_id=<安装方org_id> 仍会收到 403（不传 org_id 时默认 读应用所属组织，不受影响）。

最小权限建议

只勾选你确实用得到的能力——尤其是 im（会给成员发通知，打扰用户）和 ai（消耗组织积分），管理员在审批安装/授权时会看到你申请了哪些能力。

发布到应用市场需要逐 scope 声明用途 + 平台审核

发布到其他组织可见/可安装的应用市场与只在本组织内部使用不同——应用在 市场里会接触到完全不信任你的安装方组织，因此提交前多一层要求：

1. 为每个已勾选的 scope 填写一句用途说明（≤300 字符，在应用编辑页填写） ——不是泛泛写"需要通讯录读取权限"，而是具体说明"为什么需要"（例如 contacts → "在审批卡片上展示审批人姓名"）。这些说明会展示给平台审核 人员与安装方管理员参考。
2. 提交审核（private → pending_review），平台审核通过才会真正上架 （published）；审核中或被驳回期间应用不会出现在市场列表里（被驳回时可 看到驳回理由，修改后可重新提交）。
3. 已上架后如果扩大了能力范围（scopes）或改了页面地址，会自动降级回 private 并要求重新提交审核——防止"先用很小的能力范围过审，上架后再悄悄 扩大范围"这条绕过审核的路径。只改简介/图标/绑定的知识库数据库白名单不 会触发降级。

这一整套流程只影响"发布到市场"——应用在自己组织内部使用（private 状态）不需要任何审核，/api/open/* 的日常调用也不受影响。