【稀缺实战】腾讯云知识引擎 Skill 技能对接自有业务接口：私有化定制问答从 0 到 1（含权限隔离）

本文不教你怎么创建一个"调公开天气 API"的玩具技能。
本文只讲三件事：私有接口对接、业务数据联动、权限隔离。
这是把腾讯云大模型知识引擎（LKE）从"演示玩具"变成"企业生产力"最关键、也最没人写透的三道坎。

---

一、先泼冷水：为什么通用技能教程救不了你的企业

在 网上搜"腾讯云 LKE 技能/插件"，十篇有九篇是同一个套路：

1. 创建一个插件；
2. 填一个公开 API 地址（热榜、天气、新闻）；
3. 选"无需授权"；
4. 绑定到 Agent，完事。

这套流程演示价值满分，但放到企业内部立刻失效，因为企业场景有四个通用教程根本不碰的硬约束：

通用教程	企业私有场景
公开 API，无需鉴权	内网/半公开接口，需签名、密钥、Token
数据所有人可见	每个员工只能看自己权限内的数据
静态数据拉取即可	需要实时查库（订单、库存、工单、物流）
参数写死在请求里	参数要来自多轮对话上下文，还要做身份透传

如果你的目标是企业私有化定制问答——让员工/客户用自然语言查询内部业务系统——那上面那张表里右边这一列，才是你要解决的核心问题。

下面直接进入正题，手把手拆解。

---

二、先搞懂架构：私有化定制问答的四层模型

先建立一个全局视角。所谓"Skill 技能对接自有业务接口"，本质上是下面这条链路：

关键认知：

• LKE 应用（Application）是"大脑"：负责理解意图、规划任务、组织语言回答；
• 技能/插件（Skill/Plugin）是"手"：负责把大模型的意图翻译成对企业内部接口的真实 HTTP 调用；
• 企业 API 网关是"门卫"：所有从技能发出的请求，必须在网关层完成二次鉴权、身份映射、数据过滤、审计——这一层绝不能省，后面会重点讲。

腾讯云知识引擎提供三种应用模式，对接私有技能时的选择逻辑：

模式	适用场景	对接技能的方式
标准模式	纯知识库问答（制度、手册、FAQ）	不调接口，走 RAG
工作流模式	固定流程（工单流转、申请审批）	画布编排，节点内嵌接口调用
Agent 模式	开放问答 + 实时数据（订单、物流、库存）	大模型自主选择技能调用

做私有化定制问答，90% 的诉求落在 Agent 模式——因为它能在一个对话里同时完成"查知识库"和"调接口拿实时数据"，这就是下一章讲的"业务数据联动"。

---

三、核心一：私有接口对接——把企业内部 API"翻译"成大模型能用的技能

3.1 先立规矩：私有接口设计三原则

大模型不会"将就"你的接口，接口必须迁就大模型。对接前请先按这三条改造你的内部接口：

原则 1：标准化 OpenAPI 描述。 LKE 插件中心支持"解析为工具"，底层走 OpenAPI 3.0.0 规范。接口必须有规范的 paths、parameters、requestBody、responses 定义，否则解析不了。

原则 2：统一返回结构。 建议所有技能接口返回如下固定结构，方便大模型解析和你的网关统一处理：

{
  "code": 0,
  "message": "success",
  "data": {
    "list": [],
    "total": 1,
    "page": 1
  },
  "traceId": "e3f2a9c1-...",
  "requestId": "技能侧透传的业务号"
}

原则 3：无状态 + 幂等 + 限流。 技能调用没有"会话亲和性"保证，接口必须无状态；查询类接口天然幂等，写操作建议带幂等键；网关层必须限流，防止大模型多轮对话触发接口风暴。

3.2 创建私有技能（插件）的五步实操

以下路径基于 LKE 控制台（lke.cloud.tencent.com），具体菜单位置以官方文档为准：

Step 1｜进入插件中心，点击"创建插件"

Step 2｜基础配置——名称和描述决定"模型会不会用它"

这一步是通用教程不讲、但决定成败的地方。插件/工具的 description 会被拼进模型上下文，模型靠它判断"什么时候该调这个技能"。写法有讲究：

❌ 错误写法：查询订单接口

✅ 正确写法：
当用户询问订单状态、物流进度、发货时间、收货地址等与订单相关的问题时，
调用此工具获取实时数据。调用前请先从对话上下文中提取：订单号(orderId)、
当前用户的企业编码(tenantId)。若用户只提供部分参数，请主动向用户追问缺失项。

要点：写明触发条件 + 参数来源 + 缺失参数的澄清策略。写清楚这三件事，多轮对话的参数补齐成功率能翻倍。

Step 3｜添加工具，填写调用地址

• 工具名称：动词 + 名词，如 queryOrderDetail；
• 调用地址：企业内部接口（内网可用 Nginx/网关反代暴露为 HTTPS，或使用云函数转发）；
• 请求方法、Headers、Params、Body 按实际接口填写。

Step 4｜配置入参/出参，点击"解析为工具"

把接口的请求参数和响应 JSON 字段映射到工具定义中，让平台自动生成 OpenAPI 工具描述。这一步要把每个字段的中文含义写清楚，模型是靠字段描述理解参数语义的。

Step 5｜鉴权方式选择

插件授权支持两种基础模式，私有接口场景我们一般选 API Key（也可自定义 Header 透传凭证）：

授权方式	说明	私有接口建议
无需授权	无凭证	仅限纯公开数据，私有场景禁用
API Key	请求头携带密钥	✅ 常用，配合网关二次鉴权

⚠️ 注意：技能侧配置的 API Key 只是"应用凭证"，证明"这个请求来自 LKE 平台"。它不等于用户权限。用户是谁、能看什么数据，必须靠后面的身份透传 + 网关校验解决。

3.3 一个完整示例：私有订单查询技能

假设企业有一个内部订单服务 https://gw.corp.com/api/order，技能工具定义如下：

openapi: "3.0.0"
info:
  title: "企业内部订单服务"
  version: "1.0.0"
  description: "查询企业自营订单的实时状态、物流、金额等数据，需 tenantId 与 userId 双重鉴权"
servers:
  - url: "https://gw.corp.com"
paths:
  /api/order/detail:
    get:
      summary: "查询订单详情"
      description: "根据订单号查询订单实时状态与物流信息；只能查询当前用户有权访问的订单"
      parameters:
        - name: orderId
          in: query
          required: true
          description: "订单号，如 ORD202608170001"
          schema:
            type: string
        - name: tenantId
          in: query
          required: true
          description: "企业编码，从会话上下文中的当前登录用户信息获取"
          schema:
            type: string
        - name: userId
          in: query
          required: true
          description: "当前登录用户ID，由平台透传，网关将据此做数据权限校验"
          schema:
            type: string
      responses:
        "200":
          description: "查询成功"
          content:
            application/json:
              schema:
                type: object
                properties:
                  code:
                    type: integer
                    description: "0表示成功"
                  data:
                    type: object
                    properties:
                      orderStatus:
                        type: string
                        description: "订单状态：待支付/待发货/已发货/已完成/已取消"
                      logisticsStatus:
                        type: string
                        description: "物流状态描述"
                      amount:
                        type: number
                        description: "订单金额(元)"

把这份定义填进插件中心解析，模型就能在"用户问我的订单到哪了"时自动识别参数并发起调用。

---

四、核心二：业务数据联动——知识库 RAG 与实时接口的"双引擎"

私有化定制问答最大的价值在于：一次对话同时利用"静态知识"和"动态数据"。通用教程只教了调接口，或只教了建知识库，而真正的落地是两者联动。

4.1 决策矩阵：什么内容放知识库，什么内容走接口

内容类型	示例	存放方式	原因
规章制度/流程文档	《报销制度》《SOP 手册》	知识库（RAG）	内容静态、更新低频
主数据/字典	部门名、产品名、术语表	知识库（RAG）	结构化程度低，适合检索
实时业务数据	订单状态、库存、物流轨迹	私有技能接口	数据秒级变化，必须实时查库
用户私有数据	我的订单、我的报销单	私有技能接口	涉及行级权限，必须后端校验

判断标准一句话：数据会变就走接口，数据不变才进知识库。 把实时数据喂进知识库是新手最常见的错误——不仅回答过期，还埋下数据泄露隐患。

4.2 混合问答实战：一条对话同时命中两种引擎

以企业内部 IT 服务助手为例，员工提问：

“我的电脑报修单修到哪一步了？如果今天修不好，我能申请备用机吗？”

理想答案需要：

1. 调技能 queryRepairTicket 查实时工单状态 → “维修中，预计明天完成”；
2. 查知识库 命中《备用机申请制度》→ “根据制度第 3.2 条，维修超 24 小时可申请备用机”；
3. 组装回答 → 结论 + 依据 + 下一步引导。

在 Agent 模式下，模型会自主完成"意图拆解 → 并行调技能 + 检索知识库 → 汇总回答"。这要求你在**角色指令（Prompt）**里明确告诉模型两种信息来源的优先级：

你是企业内部智能助手。回答规则：
1. 涉及订单/工单/库存/物流等实时数据时，必须调用对应技能获取最新数据，禁止凭知识库或记忆猜测；
2. 涉及制度、流程、FAQ 时，优先基于知识库内容作答，并注明依据；
3. 知识库与实时数据冲突时，以实时数据为准，并提示用户可能存在的信息差异。

4.3 多轮对话的参数补齐

技能调用常遇到参数不全：用户第一句只说了"帮我查订单"，没说单号。处理策略：

• 在工具描述中声明"参数缺失时主动追问"（见 3.2 的写法）；
• 工作流模式下可利用"多参数同时提取 + 多轮反问澄清"节点，一轮收集齐所有参数再调接口；
• 把已收集的上下文参数（tenantId、userId）设计为隐藏参数，不让模型暴露给用户，也不要求用户提供。

---

五、核心三：权限隔离——私有技能的灵魂（全网最稀缺的部分）

这是通用教程完全不碰、但企业私有化问答生死攸关的部分。先记住一句铁律：

大模型永远不可信。权限校验永远不能只在前端/提示词层做，必须在你的业务后端做。

5.1 三层权限模型

把权限拆成三层，逐层收口：

第一层｜应用层：谁能访问这个 Agent

• 发布渠道控制：仅内网、仅企业微信/钉钉集成、或公网 + 登录态；
• 应用接入 Token：调用 LKE 开放 API 时校验；
• 用企业身份源（企微、AD、LDAP）登录后进入应用。

第二层｜技能层：哪些技能对该用户可见

• 普通员工的应用只挂 查询我的订单；
• 财务人员的应用额外挂 导出对账单；
• 实现方式：按角色建应用，或网关层按用户角色过滤工具白名单。

第三层｜数据层：同一接口，不同用户看到不同数据（行级权限）
这是最容易漏、也最致命的一层。实现方式见 5.2。

5.2 身份透传 + 接口侧二次鉴权（核心实现）

目标：技能调用接口时，必须携带"当前真实用户"的身份，由接口侧校验该用户是否有权访问这条数据——而不是相信大模型传进来的 orderId。

完整链路：

1. LKE 应用侧拿到登录用户身份（来自企微/AD 登录态或应用内用户体系）；
2. 平台将 userId / tenantId 注入技能请求（作为隐藏参数或 Header）；
3. 企业网关剥离不可信参数，只保留平台签发的可信身份；
4. 网关把身份映射为内部权限上下文，再转发到业务服务；
5. 业务服务用 userId/tenantId + orderId 做行级权限校验，无权则返回拒绝。

网关侧伪代码（强烈建议加签校验，防止伪造请求直接打业务接口）：

# gateway/guard.py —— 企业API网关鉴权中间件（伪代码）
def guard(request):
    # 1. 校验平台签名：确认请求确实来自 LKE 技能，而非攻击者直连
    if not verify_platform_sign(request.headers.get("X-LKE-Sign")):
        return reject("invalid platform signature")

    # 2. 取可信身份：user_id/tenant_id 必须来自平台签发的凭证，而非请求参数
    identity = decode_platform_token(request.headers.get("X-LKE-Identity"))
    user_id, tenant_id = identity["userId"], identity["tenantId"]

    # 3. 工具级鉴权：该用户角色是否允许调用此接口
    if not role_allow(user_id, request.path):
        return reject("no tool permission")

    # 4. 数据级鉴权（行级权限）：orderId 必须属于该用户/租户
    order = query_order(request.params["orderId"])
    if order.tenant_id != tenant_id or order.owner_id != user_id:
        return reject("no data permission")

    # 5. 脱敏：按用户角色裁剪敏感字段
    if user_id not in finance_roles:
        order.hide("costPrice", "supplierName")

    # 6. 审计：记录 谁 + 何时 + 调了什么 + 返回了什么
    write_audit(user_id, request.path, request.params, trace_id=request.traceId)

    return ok(order)

关键细节（都是踩坑换来的）：

• 可信身份不能走请求参数：orderId 可以来自模型，但 userId/tenantId 必须来自平台签发的 Header/Token，请求参数里的同名值一律忽略，否则任何人改个参数就能越权；
• 接口必须幂等 + 可审计：每条技能调用都留 traceId，出问题能回溯到具体对话；
• 敏感字段接口层脱敏：成本价、供应商、手机号等字段按角色裁剪，别指望大模型"注意别泄露"——提示词约束一律视为无效；
• 限流 + 配额：防止模型循环调用或恶意刷量。

5.3 多租户隔离与数据脱敏

如果你的平台服务多个企业（SaaS 模式），权限隔离的粒度要下沉到租户：

• 知识库维度：租户 A 的知识库与租户 B 物理隔离（LKE 支持私有知识库隔离，企业数据不参与外部模型训练）；
• 技能维度：技能资源按租户隔离，租户间不可见；
• 数据维度：网关强制 tenant_id 与业务数据归属匹配，交叉访问直接拒绝；
• 输出维度：对模型返回内容做敏感词/正则脱敏后置过滤（手机号、身份证、银行卡号正则替换）。

---

六、稀缺落地案例：某连锁零售企业"供应商协同助手"

说明：以下为脱敏后的真实落地案例框架，业务数据与接口细节已做简化处理。

6.1 业务背景与痛点

某连锁零售企业（数千家门店），供应商每天通过电话/微信问采购员"这批货到哪了"“对账单什么时候出”，采购员 60% 的白天时间耗在重复查单、答非所问上。客户要的答案很简单：让供应商用自然语言自助查订单、查对账、查结算——但前提是：每个供应商只能看自己企业的数据，绝不能看到别的供应商的。

6.2 整体方案

层	选型	职责
应用	LKE Agent 模式应用，接入供应商企业微信	对话入口、意图理解、回答生成
技能	自建 3 个私有技能：订单查询、对账单查询、结算进度查询	对接企业内部 SAP/OMS 接口
网关	企业自建 API 网关（Nginx + 自研中间件）	平台签名校验、身份映射、行级权限、脱敏、审计
数据	知识库（采购政策、结算规则）+ 实时接口（订单、账单、结算）	静态知识走 RAG，动态数据走接口

6.3 接口清单（节选）

技能	接口	入参	返回关键字段
订单查询	GET /api/order/list	tenantId, userId, page	订单号、状态、预计到货日、门店
订单明细	GET /api/order/detail	tenantId, userId, orderId	明细行、金额、物流轨迹
对账单查询	GET /api/settle/bill	tenantId, userId, month	账单金额、结算状态、付款日期
结算进度	GET /api/settle/progress	tenantId, userId	本期待结算、已结算金额

6.4 权限矩阵（关键）

角色	可见技能	数据范围	敏感字段
供应商普通员工	订单查询、对账单查询	仅本供应商企业（tenantId 匹配）	不可见成本价、其它供应商价格
供应商财务	全部查询技能	仅本企业 + 结算明细	可见本企业结算金额
企业内部采购员	全部技能	全量 + 跨租户检索	可见成本价
审计员	只读查询	全量（只读）	全量 + 审计流水

6.5 效果数据

• 采购员日均接听"查单"电话从 60+ 通降至 8 通（仅异常单人工介入）；
• 供应商查询响应从"电话排队 30 分钟"变为"秒级返回"；
• 上线 3 个月 0 起数据越权事件（得益于网关层强制行级校验 + 审计）；
• 订单口径争议减少，因为回答附带了数据来源与时间戳。

6.6 一条真实效果对话（示意）

供应商："帮我看看这个月对账单出来没有，金额多少？"

助手：调用 settle/bill（tenantId=供应商A, month=本月）
→ 检索知识库《结算规则》确认"每月 5 号出账"

回答："贵司本月对账单已于 8 月 5 日生成，待结算金额 286,400 元，
结算状态为'财务复核中'。根据结算规则，复核通过后 3 个工作日内付款。
需要我为您导出对账单明细吗？"

注意：回答里没有出现其它供应商的任何数据，即使模型"猜"了一个别的单号，网关也会直接拒绝并返回"无权访问"。

---

七、避坑指南 Top 6（全是真金白银的教训）

1. 内网接口调不通
技能调用发生在腾讯云侧，你的接口必须能公网访问（或通过云函数/专线转发）。用 Nginx 反代只暴露必需路径，网关层做 IP 白名单（仅放行腾讯云调用来源）。

2. 大模型"发明"参数
模型可能把订单号编造成 123456 去调接口。对策：接口对不存在/无权限的数据返回统一 code=4001 无权访问或不存在，并引导用户提供正确单号；网关对查询类接口加频控。

3. 返回结构不规范，解析失败率高
接口返回字段命名随意、类型混乱（金额有时是字符串有时是数字），模型解析出错的概率会直线上升。对策：严格执行统一返回结构 + 明确字段类型与枚举值描述。

4. 超时与重试
技能调用默认超时较短，你的业务接口如果超过秒级，请在网关层做异步化 + 任务查询模式：先返回"处理中"，再提供进度查询技能。

5. 权限只做"前端隐藏"
有人把权限写成"在提示词里告诉模型别查别人的数据"——这是把公司数据安全交给幻觉。所有权限必须在业务后端强校验，提示词只是体验层，不是安全层。

6. 忽略审计
私有化问答上线后，业务方第一件事一定是查"谁问了什么、看到了什么"。接口层从第一天就埋审计日志（谁 + 何时 + 参数 + 返回 + traceId），否则出事无法追溯。

---

八、总结：一套可以复用的落地方法论

把整篇文章压缩成一张检查清单，照着做就能少踩 80% 的坑：

□ 接口规范：OpenAPI 3.0 描述 + 统一返回结构 + 幂等/限流
□ 技能设计：描述里写清触发条件、参数来源、缺失追问策略
□ 数据分工：静态→知识库 RAG，动态→技能接口
□ 身份透传：userId/tenantId 走平台签发凭证，不走请求参数
□ 三层隔离：应用层 + 技能层 + 数据层(行级)
□ 网关兜底：平台签名校验 + 行级权限 + 脱敏 + 审计
□ 效果度量：接通率、越权事件数、人工介入率

最后说一句大实话：私有化定制问答的难点从来不在"创建一个技能"，而在"技能背后的接口规范、数据权限和企业安全体系"。把这三件事做扎实，腾讯云知识引擎才能真正从"演示平台"变成"企业生产力平台"。

如果你正在做类似的私有化对接，欢迎评论区交流你们在权限隔离、接口对接上踩过的坑。

---

免责声明：本文中的案例与接口均为脱敏示例，控制台操作路径以腾讯云官方文档为准。