5.4 能力下发策略
概念
成员进来后,下一步就是"给能力"——这就是能力下发。能力下发是企业管理后台最核心的操作,也是客户最容易出问题的地方。
能力下发的完整链路是:
🖼 图:能力下发四步链路:上传(导入 Skill、专家、知识库)→ 分类(打标签、分组)→ 策略(黑名单、白名单、默认允许)→ 到人(成员客户端可见可用)——四步缺一不可,策略配置是最容易出问题的一步。
这四个步骤缺一不可:
| 步骤 | 做什么 | 涉及的能力类型 |
|---|---|---|
| 上传 | 把能力资源导入后台 | Skill、专家、知识库 |
| 分类 | 给能力打标签、分组 | Skill 分类、专家领域、知识库主题 |
| 策略 | 配置谁能用什么、什么时候能用 | 黑名单、白名单、默认允许 |
| 到人 | 能力出现在用户客户端上 | 用户在客户端看到并使用 |
用法
通用套路:上传 → 分类 → 策略
以 Skill 为例,来看具体的操作流程。
上传
进入 AI 资源管理 › Skill 管理 › Skill 列表,点右上角 + 上传 Skill,上传 .zip 包并填写信息。
企业 SKILL 包结构如下:
my-enterprise-skill/
├── SKILL.md # [必填] 名称 + 描述 + 使用说明
├── manifest.yaml # [必填] 版本、依赖、元数据
├── scripts/ # [可选] 可执行脚本
├── references/ # [可选] 参考文档
└── assets/ # [可选] 图标、模板等资源
提示
比个人版多一个
manifest.yaml。这是企业上传的必填项,包含name、version、description、category、author。第 4 章本地自建的技能要上企业后台,得先补这个文件。
分类
切到 分类管理 页签,+ 新增分类。分类名称 2–20 字符(必填),描述 ≤ 500 字符,排序可选「追加到末尾」或「置顶到首位」。
官方建议:分类命名与部门业务对齐,避免过度泛化导致查找困难。删除分类不会删除 Skill,仅解除关联关系。
下发策略
进入 Skill 下发策略 页签,+ 新建策略,选择白名单或黑名单,指定目标 Skill 与作用范围(成员 / 部门 / 角色)。保存后策略即时生效。
企业知识库:客户文档进系统的正规入口
后台提供官方知识库(平台预置的开源框架与技术规范)与自定义知识库(企业私有)两类。FDE 关心的是后者:
| 项目 | 规格 |
|---|---|
| 单文件格式 | .md、.markdown、.docx、.pdf,以及 .py、.js、.css 等代码文件,≤ 30 MB / 文件 |
| 压缩包 | .zip、.tar、.tgz、.tar.gz、.gz、.gzip,≤ 300 MB / 包 |
| 编码要求 | 必须 UTF-8 或 GBK,其他编码索引会失败 |
| 命名限制 | 名称 ≤ 20 英文字符或 ≤ 10 中文字符;描述 ≤ 30 英文字符或 ≤ 15 中文字符 |
| 可见范围 | 必填,默认全部成员,支持指定部分成员 |
| 检索参数 | Top K 推荐 3 ~ 5;Score Threshold 推荐 0 ~ 0.5 |
提示
三个现场高频事故: ① 客户给的老文档是 GBK 之外的编码 → 索引失败,先转码;② 可见范围忘改,客户 HR 制度对全员可见 → 官方明确建议按需调整为「指定成员」;③ 状态还在「索引中」就演示 → 答不出来,客户以为产品不行。数据处理状态变为「已完成」才可启用。 还有一条特别容易漏:成员在客户端对话中必须用
@引用目标知识库,否则回答不会纳入知识库内容作为上下文。培训一线时这句话要单独讲,否则他们会以为「上传了却没用」。
三种能力类型的下发
| 能力类型 | 上传方式 | 分类方式 | 策略配置 |
|---|---|---|---|
| Skill | 在后台创建或导入 Skill 定义(仅接受 .zip 包,必含 manifest.yaml) | 按 Skill 分类标签管理 | 配置可用成员组/黑名单 |
| 专家(Agent) | 在后台配置 Agent(含 Prompt、工具、知识库) | 按业务领域分类 | 配置可用成员组/黑名单 |
| 知识库 | 上传文档 → 向量化 → 入库 | 按主题/部门分类 | 配置可见成员组 |
三者的下发逻辑是一致的:先上传、再分类、然后配策略。
权限优先级机制
这是客户问得最多的问题:"我配了黑名单,也配了白名单,到底听谁的?"
权限判断遵循以下优先级:
黑名单 > 白名单 > 默认允许
也就是说:
-
先查黑名单 ——如果在黑名单里,直接拒绝,不往下查
-
再查白名单 ——如果在白名单里,允许
-
最后默认允许 ——如果不在黑名单也不在白名单,默认允许
| 用户状态 | 黑名单 | 白名单 | 最终结果 |
|---|---|---|---|
| 在黑名单 | 不查 | ❌ 拒绝 | |
| 不在黑名单,在白名单 | ❌ | 允许 | |
| 都不在 | ❌ | ❌ | 默认允许 |
**⚠️ 风险提示:**这个优先级在排查权限问题时至关重要。客户反馈"某用户不能用某能力"时,按以下顺序排查: 先查黑名单——是不是被误加进去了? 再查白名单——是不是白名单只加了部分人,导致其他人"不在白名单"? 最后查默认策略——默认策略是不是被改成了"默认拒绝"? 最常见的问题 :管理员为了"精确控制",把默认策略改成了"默认拒绝",然后只把部分人加进白名单。结果其他正常用户突然就不能用了。
🖼 图:permission priority flow
示例
以下是一个典型的权限排查案例:
客户反馈:维修车间的张三说"用不了故障诊断专家"
排查步骤:
Step 1:查黑名单
- 检查"故障诊断专家"的黑名单列表
- 发现张三不在黑名单里 → 排除黑名单问题
Step 2:查白名单
- 检查"故障诊断专家"的白名单列表
- 发现白名单只加了"维修车间组-主管"分组
- 张三属于"维修车间组-工程师"分组 → 不在白名单里
Step 3:查默认策略
- 检查"故障诊断专家"的默认策略
- 发现默认策略被改成了"默认拒绝"
根因:管理员为了精确控制,把默认策略改成"默认拒绝",
但白名单只加了主管,没加工程师。
解决方案:
方案 A:把"维修车间组-工程师"加入白名单
方案 B:把默认策略改回"默认允许"(如果安全允许)
**⚠️ 风险提示:**在做能力下发时,建议遵循"最小惊讶原则"——不要随意改变默认策略。如果需要精确控制,用白名单来加人,而不是把默认策略改成"默认拒绝"。因为一旦改成"默认拒绝",任何未在白名单里的人都会受影响,很容易出现"全员突然不能用"的事故。
随堂测
逐题作答,即时反馈
1. 能力下发的完整四步链路是?
2. 能力下发的权限判断遵循的优先级是?
3. 成员在客户端对话中,怎样才会把某个知识库的内容纳入回答上下文?