从 Skill 化到控制权：AI 系统中的能力分层与资产保护

发表于
当 AI 系统将任务封装为 Skills 交给外部执行时，哪些能力可以暴露，哪些必须留在内部？本文从数据暴露的三种形态出发，提出通用能力、业务能力、核心能力的三层划分框架，以及“最小输入而非脱敏”的数据策略。

以下根据个人观点及网络资料，并由AI辅助整理

一、核心问题：能力分层与执行边界

在一些 AI 系统中，正在出现这样一种趋势：用 SDK + Runtime 提供执行环境，将任务拆解为 Skills，Runtime 负责编排，模型负责推理。这套模式提升了开发效率，但也引出一个更本质的问题：

哪些能力可以交给 Runtime 执行，哪些必须留在系统内部？

这不是“用不用大模型”的问题，而是能力分层与执行边界的划分问题。

二、这个问题的前提

这里讨论的风险，有一个明确的前提：你在使用外部系统——无论是直接调用外部大模型、接入第三方 Agent，还是通过 SDK 对接外部服务，数据和上下文都需要离开你的系统边界。

如果你有能力自己部署本地模型，或者业务足够简单、本地轻量模型就能满足需求，数据根本不出去，Skill 化暂时可能也没有泄露风险需要考虑。

所以，分层不是普遍原则，而是使用外部系统时的边界管理问题。

三、进入外部系统意味着什么

使用外部系统时，所有传出去的内容本质上都一样：作为 prompt 的一部分明文传入模型参与推理。举几个典型的例子：

数据：用户数据、业务数据、RAG 检索内容，作为上下文直接传入，访问路径不再受控。

策略：prompt 模板、system prompt、参数配置，决定模型如何理解和执行任务，同样随请求传出。

结构：这类暴露更隐蔽。即使你没有把业务逻辑直接写进 prompt，外部也可以通过观察大量的输入输出反推出你的设计——调用顺序可以还原 workflow，结果分布可以逼近业务策略。

前两类是直接暴露，数据和策略作为 prompt 明文传出；第三类是间接暴露，通过观察大量输入输出来反推设计。两者的性质不同，但方向一致：核心能力都存在被还原的可能。

四、能力分层：三种典型情形

有效的应对方式不是加密，而是从源头控制哪些内容可以传出去，哪些不能。这需要对 Skill 做分层处理——以下不是严格的分类，更像是三种典型情形，用来说明“进不进外部系统”的判断逻辑。

通用能力不依赖私有数据，没有业务逻辑，文本总结、改写翻译、信息抽取都属于这类。这类 Skill 可以直接交给外部系统执行，暴露了也无妨。

从这里开始，判断逻辑就不再是“能不能暴露”，而是“暴露到什么程度”。

业务能力包含逻辑，但关键在于：结果对外暴露是可以接受的，不可接受的只是“怎么算出来的”。与其把数据传出去让外部处理，不如反过来——在你的系统内部封装为 API，让外部系统调用这个接口、接收返回结果。数据的计算和处理全程留在你的系统内部，对外部不可见。风控判断、推荐候选、用户标签这类都适用这个模式。

核心能力的情况更进一步：不只是逻辑不能暴露，连结果本身都会泄露设计。比如 RAG 的切分与检索方式，光看输出的召回内容，就能反推出你的索引结构和排序策略。这类能力唯一的保护方式，是让它根本不出现在外部系统的执行链上。

三类的本质区别只有一个维度：暴露结果是否可以接受。可以接受的，封装逻辑即可；不可以接受的，整个从外部执行链移走。

五、数据策略：最小输入，而非脱敏

许多系统选择对数据脱敏（替换姓名、隐藏手机号），但这只减少了识别风险，并没有减少信息暴露本身。更有效的策略是只提供完成任务所需的最小信息。

以“判断是否推荐某产品”为例：

❌ 直接传原始数据，暴露完整数据结构：

1
2
3
4
5
6
7
{
  "name": "张三",
  "age": 32,
  "income": 50000,
  "loan_history": [...],
  "credit_score": 0.82
}

✅ 只传决策所需特征，不暴露来源与结构：

1
2
3
4
{
  "risk_level": "high",
  "repayment_stability": "low"
}

本质上是从“给数据”变成“给结论所需的最小条件”。这一原则适用于所有需要向外部系统传递信息的场景。

六、设计原则：核心能力不可被还原

整篇收敛为一个判断框架：

能力类型 处理方式
通用能力 直接 Skill 化，交给外部系统
业务能力 工具化封装，接口调用
核心能力 内收，不进入外部执行链

最终目标不是“完全不暴露”，而是：

即使外部系统可以观测所有调用，也无法还原你的核心逻辑与数据结构。