5.4 能力下发策略

约 15 分钟L2L3T4B3

课程来源

[来源] 腾讯云培训认证《腾讯云人工智能前沿部署工程师(FDE)》第 5 章 ·〈5.4 能力下发策略〉

原文:https://cloud.tencent.com/edu/learning/course-4767-84813-84825(腾讯云在线学习中心)

[收录说明] 企业内部培训用途蒸馏收录:保留原课章节结构与要点,截图以图注转写、互动组件转写为要点清单;概念与事实以原课为准。

本课目录(7 节)

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、工具、知识库)按业务领域分类配置可用成员组/黑名单
知识库上传文档 → 向量化 → 入库按主题/部门分类配置可见成员组

三者的下发逻辑是一致的:先上传、再分类、然后配策略。

权限优先级机制

这是客户问得最多的问题:"我配了黑名单,也配了白名单,到底听谁的?"

权限判断遵循以下优先级:


黑名单 > 白名单 > 默认允许

也就是说:

  1. 先查黑名单 ——如果在黑名单里,直接拒绝,不往下查

  2. 再查白名单 ——如果在白名单里,允许

  3. 最后默认允许 ——如果不在黑名单也不在白名单,默认允许

用户状态黑名单白名单最终结果
在黑名单不查❌ 拒绝
不在黑名单,在白名单❌允许
都不在❌❌默认允许

**⚠️ 风险提示:**这个优先级在排查权限问题时至关重要。客户反馈"某用户不能用某能力"时,按以下顺序排查: 先查黑名单——是不是被误加进去了? 再查白名单——是不是白名单只加了部分人,导致其他人"不在白名单"? 最后查默认策略——默认策略是不是被改成了"默认拒绝"? 最常见的问题 :管理员为了"精确控制",把默认策略改成了"默认拒绝",然后只把部分人加进白名单。结果其他正常用户突然就不能用了。

🖼 图:permission priority flow

示例

以下是一个典型的权限排查案例:


客户反馈:维修车间的张三说"用不了故障诊断专家"

排查步骤:

Step 1:查黑名单

  - 检查"故障诊断专家"的黑名单列表

  - 发现张三不在黑名单里 → 排除黑名单问题

Step 2:查白名单

  - 检查"故障诊断专家"的白名单列表

  - 发现白名单只加了"维修车间组-主管"分组

  - 张三属于"维修车间组-工程师"分组 → 不在白名单里

Step 3:查默认策略

  - 检查"故障诊断专家"的默认策略

  - 发现默认策略被改成了"默认拒绝"

根因:管理员为了精确控制,把默认策略改成"默认拒绝",

      但白名单只加了主管,没加工程师。

解决方案:

  方案 A:把"维修车间组-工程师"加入白名单

  方案 B:把默认策略改回"默认允许"(如果安全允许)

**⚠️ 风险提示:**在做能力下发时,建议遵循"最小惊讶原则"——不要随意改变默认策略。如果需要精确控制,用白名单来加人,而不是把默认策略改成"默认拒绝"。因为一旦改成"默认拒绝",任何未在白名单里的人都会受影响,很容易出现"全员突然不能用"的事故。

随堂测

逐题作答,即时反馈

0 / 3 已作答
  1. 1. 能力下发的完整四步链路是?

  2. 2. 能力下发的权限判断遵循的优先级是?

  3. 3. 成员在客户端对话中,怎样才会把某个知识库的内容纳入回答上下文?