SkillHub 设计与运行原理

1. 一眼看懂：Skill 从发布到执行

SkillHub 不是 Python 包管理器，也不是一个把 Skill 代码直接运行在服务器上的平台。它更像是一个企业级的“Agent 技能注册中心 + 安全供应链 + 运行时契约”。

先看完整链路：

读图时只需要记住五件事：SkillHub 负责分发和治理，QAuth 只保护 SkillHub 管理面，Workbuddy 负责宿主编排，Skill Runtime 负责执行，下游业务服务负责解析企业 Token 和最终权限。

完整链路可以概括为：

开发者打包 Skill
        |
        v
SkillHub 发布、版本、权限、审核和静态安全扫描
        |
        v
Workbuddy 下载并安装 Skill
        |
        v
Skill Runtime 根据声明准备隔离的 Python、Node 或连接器环境
        |
        v
Agent 读取 SKILL.md，选择能力并执行脚本或平台工具
        |
        v
服务端执行最终鉴权、数据权限和业务操作

最重要的设计边界是：

• SkillHub 负责发布和治理，不负责替业务 Skill 执行 Python。
• Workbuddy 负责安装和调用，实际执行发生在 Skill Runtime 中。
• Skill 包只声明需要什么运行时和连接器，不携带解释器、虚拟环境、token 或 Cookie。
• 静态发布校验不是完整沙箱。发布校验、安装审计、Runtime 隔离、服务端鉴权是多道边界。
• Skill 可以是纯说明，也可以带 Python/Node 脚本，也可以依赖平台连接器；这些模式不能混为一谈。

2. Skill 包到底是什么

一个 Skill 是面向 Agent 的可分发能力包，核心文件是 SKILL.md：

skill-name/
├── SKILL.md                  # 必需：触发条件和执行规则
├── agents/openai.yaml        # 可选：列表展示和默认提示词
├── scripts/                  # 可选：确定性脚本
├── references/               # 可选：接口、字段和业务规范
├── assets/                   # 可选：模板或静态资源
├── requirements.txt          # 可选：Python 依赖
└── package.json              # 可选：Node 依赖

SKILL.md 的 frontmatter 是运行时契约的一部分。例如 Python Skill 应声明：

---
name: example-query
description: 查询示例数据并输出结构化结果。
python: true
requires-python: "3.12"
requirements: requirements.txt
---

其中：

• name 和 description 决定 Skill 如何被发现和触发。
• python: true 表示需要平台提供隔离 Python。
• requires-python: "3.12" 表示作者使用的平台 Python 合同。
• requirements 指向包内依赖声明，不代表可以自定义下载源。
• dependencies 声明其他 Skill 依赖。
• connectors 声明平台连接器依赖。

Skill 不是“把所有逻辑都写在 Prompt 里”。推荐把不需要模型判断、但需要稳定执行的部分放到脚本中，把业务判断、输入收集和结果解释写到 SKILL.md 中。

3. 平台分层

3.1 SkillHub Registry

SkillHub 服务端承担供应链和治理职责：

• Skill 包上传和存储；
• namespace、slug 和版本管理；
• 搜索、发现和下载；
• Owner、Admin、Member 等角色控制；
• 团队 Skill 和全局 Skill 的可见性；
• 发布审核、下线、恢复和推广；
• 静态安全扫描和审计记录；
• CLI 或平台 API 的安装入口。

SkillHub 不应直接执行作者上传的 Python。让注册中心直接执行不可信上传内容，会把文件、网络、进程和凭证权限全部集中到平台服务器，风险和故障半径都过大。

3.2 Workbuddy

Workbuddy 是 Agent 宿主和用户入口，主要做：

• 保存当前用户安装了哪些 Skill；
• 将 Skill 元数据提供给 Agent；
• 根据用户请求选择是否加载某个 Skill；
• 将 Skill 声明的连接器合并到当前 turn；
• 创建或调度 Skill Runtime；
• 向 Runtime 注入本轮允许的临时环境变量；
• 收集标准输出、结构化结果和错误；
• 在加载前和调用前检查权限。

它不应该把所有 Skill 的依赖装到同一个全局 Python 或 Node 环境里，否则一个 Skill 的依赖升级可能破坏另一个 Skill。

3.3 Skill Runtime：执行沙箱

Skill Runtime 是实际执行脚本的受控环境。以下是一

SkillHub 设计与运行原理

1. 一眼看懂：Skill 从发布到执行

SkillHub 不是 Python 包管理器，也不是一个把 Skill 代码直接运行在服务器上的平台。它更像是一个企业级的“Agent 技能注册中心 + 安全供应链 + 运行时契约”。

先看完整链路：

读图时只需要记住五件事：SkillHub 负责分发和治理，QAuth 只保护 SkillHub 管理面，Workbuddy 负责宿主编排，Skill Runtime 负责执行，下游业务服务负责解析企业 Token 和最终权限。

完整链路可以概括为：

开发者打包 Skill
        |
        v
SkillHub 发布、版本、权限、审核和静态安全扫描
        |
        v
Workbuddy 下载并安装 Skill
        |
        v
Skill Runtime 根据声明准备隔离的 Python、Node 或连接器环境
        |
        v
Agent 读取 SKILL.md，选择能力并执行脚本或平台工具
        |
        v
服务端执行最终鉴权、数据权限和业务操作

最重要的设计边界是：

• SkillHub 负责发布和治理，不负责替业务 Skill 执行 Python。
• Workbuddy 负责安装和调用，实际执行发生在 Skill Runtime 中。
• Skill 包只声明需要什么运行时和连接器，不携带解释器、虚拟环境、token 或 Cookie。
• 静态发布校验不是完整沙箱。发布校验、安装审计、Runtime 隔离、服务端鉴权是多道边界。
• Skill 可以是纯说明，也可以带 Python/Node 脚本，也可以依赖平台连接器；这些模式不能混为一谈。

2. Skill 包到底是什么

一个 Skill 是面向 Agent 的可分发能力包，核心文件是 SKILL.md：

skill-name/
├── SKILL.md                  # 必需：触发条件和执行规则
├── agents/openai.yaml        # 可选：列表展示和默认提示词
├── scripts/                  # 可选：确定性脚本
├── references/               # 可选：接口、字段和业务规范
├── assets/                   # 可选：模板或静态资源
├── requirements.txt          # 可选：Python 依赖
└── package.json              # 可选：Node 依赖

SKILL.md 的 frontmatter 是运行时契约的一部分。例如 Python Skill 应声明：

---
name: example-query
description: 查询示例数据并输出结构化结果。
python: true
requires-python: "3.12"
requirements: requirements.txt
---

其中：

• name 和 description 决定 Skill 如何被发现和触发。
• python: true 表示需要平台提供隔离 Python。
• requires-python: "3.12" 表示作者使用的平台 Python 合同。
• requirements 指向包内依赖声明，不代表可以自定义下载源。
• dependencies 声明其他 Skill 依赖。
• connectors 声明平台连接器依赖。

Skill 不是“把所有逻辑都写在 Prompt 里”。推荐把不需要模型判断、但需要稳定执行的部分放到脚本中，把业务判断、输入收集和结果解释写到 SKILL.md 中。

3. 平台分层

3.1 SkillHub Registry

SkillHub 服务端承担供应链和治理职责：

• Skill 包上传和存储；
• namespace、slug 和版本管理；
• 搜索、发现和下载；
• Owner、Admin、Member 等角色控制；
• 团队 Skill 和全局 Skill 的可见性；
• 发布审核、下线、恢复和推广；
• 静态安全扫描和审计记录；
• CLI 或平台 API 的安装入口。

SkillHub 不应直接执行作者上传的 Python。让注册中心直接执行不可信上传内容，会把文件、网络、进程和凭证权限全部集中到平台服务器，风险和故障半径都过大。

3.2 Workbuddy

Workbuddy 是 Agent 宿主和用户入口，主要做：

• 保存当前用户安装了哪些 Skill；
• 将 Skill 元数据提供给 Agent；
• 根据用户请求选择是否加载某个 Skill；
• 将 Skill 声明的连接器合并到当前 turn；
• 创建或调度 Skill Runtime；
• 向 Runtime 注入本轮允许的临时环境变量；
• 收集标准输出、结构化结果和错误；
• 在加载前和调用前检查权限。

它不应该把所有 Skill 的依赖装到同一个全局 Python 或 Node 环境里，否则一个 Skill 的依赖升级可能破坏另一个 Skill。

3.3 Skill Runtime：执行沙箱

Skill Runtime 是实际执行脚本的受控环境。以下是一份企业规范示例：

• Python 当前支持 3.12，实际物化版本为经过 SHA-256 校验的 Python 3.12.7；
• Node Skill 使用平台提供的 Node Runtime；
• 依赖在受控运行时中物化，而不是由 Skill 自行下载解释器；
• 当前用户的企业内部认证 Token 只注入当前 Runtime 子进程和当前 turn；
• 加载后仍要做连接器权限和健康检查；
• 权限被撤销或凭证失效时 fail closed。

规范通常不会要求开发者绑定某一种底层技术，因此不能武断地说“每个 Skill 都运行在一个 Docker 容器里”。比较准确的说法是：

每个 Skill 的脚本应运行在由平台管理的 Skill Runtime，也就是执行沙箱或受控子进程中；具体隔离技术属于平台实现细节。

4. 本地 Workbuddy 如何运行 Skill

一次典型调用可以用下面的流程理解：

可以把本地安装理解为“下载 Skill 包”，但不能理解为“把 Skill 直接放进系统 PATH”。脚本的执行路径、依赖路径和环境变量都应由 Skill Runtime 管理。

4.1 是沙箱还是独立进程

“沙箱”和“独立进程”不是二选一：

• 独立进程是执行模型：每次 Skill 脚本可以运行在独立的 Python/Node 子进程中。
• 执行沙箱是权限模型：限制该进程能访问什么文件、网络、环境变量和系统能力。
• 容器是隔离实现的一种选择，但不是唯一选择。

企业级设计通常采用组合：

独立 Runtime 进程
  + 独立依赖目录
  + 最小环境变量集合
  + 允许域名或连接器白名单
  + 无特权系统用户
  + 超时、输出大小和资源限制
  + 服务端最终鉴权

企业规范通常会明确限制网络、浏览器、MCP 和凭证使用，但不一定公开平台的底层隔离技术。因此开发者应依赖规范边界，不应假设可以访问本机所有文件或任意内网地址。

5. 本地 Skill Runtime 如何设计

这一层是本地 Workbuddy 能否稳定运行 Skill 的关键。推荐的原则是：不从零实现一个操作系统，而是实现一个跨平台 Runtime Adapter，调用 Windows 或 macOS 提供的进程、权限、文件和网络控制能力。

5.1 Runtime 的职责边界

本地 Runtime 不负责 Skill 的发现和发布，也不负责替下游服务判断业务权限。它只负责把一次 Skill 调用变成一个受控的进程执行任务：

Workbuddy 调度
      |
      v
Runtime Adapter
      |
      +-- 选择 Python、Node 或受控命令运行时
      +-- 创建临时工作目录和独立依赖目录
      +-- 过滤环境变量并注入本轮凭证
      +-- 设置超时、输出大小和资源限制
      +-- 约束文件、网络和子进程权限
      +-- 回收进程树并返回结构化结果

建议统一成类似下面的内部接口，Skill 作者不需要感知底层操作系统：

runSkill(
  skillPath,
  runtime: python | node | powershell,
  args,
  envAllowlist,
  networkPolicy,
  timeout,
  outputLimit
)

Runtime Adapter 至少要做到：

• 使用独立子进程执行，不在 Workbuddy 主进程中直接 import 第三方 Skill 代码；
• 为每次执行创建临时工作目录，任务结束后清理；
• 只传入白名单环境变量，Token 不进入命令行参数、URL、日志和持久化文件；
• 默认拒绝任意网络访问，仅允许声明的服务端点或平台连接器；
• 限制执行时间、标准输出大小、子进程数量和资源使用；
• 超时或取消时结束整个进程树，而不是只结束最外层进程；
• 将退出码、结构化输出和错误分类返回给 Workbuddy，便于审计和重试策略判断。

5.2 Windows 上如何借力

Windows 版本的 Runtime Adapter 可以组合使用系统原生能力：

系统能力	Runtime 用途
Job Object	将 Skill 及其子进程纳入同一进程组，限制 CPU、内存和生命周期
Restricted Token	以降权身份启动进程，减少本地资源访问权限
AppContainer	对需要更强隔离的 Skill 限制文件、网络和系统资源访问
NTFS ACL	只允许访问 Skill 工作目录、依赖缓存和必要的输入输出目录
Windows Firewall	对网络访问做域名或地址白名单控制

普通纯计算 Skill 可以使用降权子进程和 Job Object；需要访问文件或网络的 Skill 额外配置 ACL 和白名单；高风险能力优先改成后端 API 或平台连接器。

5.3 macOS 上如何借力

macOS 版本可以使用：

系统能力	Runtime 用途
App Sandbox	限制应用访问文件、网络、摄像头等系统资源
Unix 用户和文件权限	为 Runner、工作目录和依赖缓存设置最小权限
launchd	管理独立 Runner 的启动、退出和资源生命周期
Seatbelt 配置	在受控场景下进一步限制进程能力

Seatbelt 或 sandbox-exec 的可用性和长期支持需要结合目标 macOS 版本验证，因此不应把某一个命令当作跨版本的唯一合同。更稳妥的做法是由 Runtime Adapter 屏蔽差异；能力不足时拒绝高风险 Skill，或降级为只调用平台连接器的模式。

5.4 跨语言运行时适配

Runtime Adapter 对外提供统一的执行协议，对内通过不同 Runner 处理语言差异：

Skill manifest
      |
      +-- python  -> Python Runner -> 受控 Python 3.12.7
      +-- node    -> Node Runner   -> 平台 Node Runtime
      +-- shell   -> OS Runner     -> PowerShell 或 Bash
      +-- connector -> Connector Runner -> 平台 API 或 MCP

Python 和 Node 依赖分别落在 Skill 独立的依赖目录中，不能共享用户全局环境。Shell 只作为明确声明的宿主能力，Windows 和 macOS 的命令差异由平台声明和适配，不应假设所有机器都有相同命令。

对于 Java、Go、Rust 或自带二进制的 Skill，只有在平台提供版本、签名、扫描和权限合同后才允许接入；否则应将能力部署到受控服务，再通过连接器调用。

5.5 启动、复用和回收策略

Runtime 不一定每次都重新下载和安装依赖。可以采用“内容寻址缓存 + 每 Skill 独立环境”的方式：

1. 根据 Skill 版本、运行时版本和依赖锁定文件计算环境指纹；
2. 本地缓存已校验的 Runner 和依赖；
3. 首次调用创建环境，后续调用复用，但每次仍创建新的执行工作目录；
4. Skill 升级、依赖变化或校验失败时重新物化；
5. 长时间未使用的环境按缓存策略回收。

这样既避免每次启动都安装依赖，也不会把多个 Skill 的依赖混在同一套全局环境中。

5.6 失败时如何处理

Runtime 的默认策略应是 fail closed：

• 没有匹配的 Python 或 Node Runtime：不执行，提示缺少受支持的运行时；
• 依赖校验失败：不执行，不从任意 URL 临时安装；
• 网络地址不在白名单：拒绝请求；
• Token 缺失、过期或下游返回 401/403：停止本次业务操作，不回退到旧凭证；
• 超时或超过输出限制：终止进程树并返回可审计的错误原因；
• 操作系统不具备所需隔离能力：拒绝高风险模式，建议改用连接器或服务端代理。

因此，本地沙箱不是 Skill 作者要自己实现的一套完整虚拟机，而是 Workbuddy 内置的 Runtime Adapter 对操作系统能力、统一运行时和企业连接器的组合封装。

6. 如何解决 Python、Node 和其他语言

5.1 优先级

企业平台应按以下优先级取舍：

1. 平台连接器：优先复用企业已治理的 MCP/API 能力。
2. Python/Node 脚本：用于稳定、可测试、需要本地计算的逻辑。
3. 纯 Shell/CMD：只适合简单且明确的平台命令，不适合作为跨系统合同。
4. 其他语言二进制：除非平台提供签名制品和明确 Runtime，否则不建议放进通用 Skill。

原因是连接器可以统一处理权限、凭证和网络；Python/Node 有成熟的受控运行时；Shell 和任意二进制更依赖宿主机，跨平台和安全边界更难治理。

5.2 Python Skill

声明：

python: true
requires-python: "3.12"
requirements: requirements.txt

规则：

• 当前只支持 Python 3.12；实际版本为 3.12.7。
• 依赖放 requirements.txt。
• 不打包 .venv、解释器或 site-packages。
• 不允许自行修改 pip 源、从 Git/URL 安装代码或执行远程安装脚本。
• 只使用标准库时，可以不提供 requirements.txt。

5.3 Node Skill

声明：

node: true

依赖放在根目录 package.json。平台负责准备 Node Runtime 和依赖目录。依赖应来自受支持的 registry 和合法 semver，不允许 Git、URL、本地路径、link: 或 workspace: 形式。

5.4 Shell、PowerShell 和 CMD

示例企业规范对 Shell 并没有像 Python/Node 那样明确的统一 Runtime 合同。因此建议：

• 跨平台 Skill 使用 Python 标准库；
• Windows 专用操作明确声明 PowerShell 前置条件；
• Linux/macOS 专用操作明确声明 Bash 前置条件；
• 不要在 Skill 中安装 Bash、Python、Node 或系统软件；
• 不要把 cmd.exe、powershell.exe 当成所有 Agent 都存在的抽象能力；
• 需要企业系统能力时，优先改成平台连接器或服务端 API。

5.5 其他语言

如果 Skill 需要 Java、Go、Rust 或自带二进制，企业平台必须先回答三个问题：

• Runtime 从哪里来，版本如何固定？
• 二进制如何签名、扫描和升级？
• 网络、文件和子进程权限如何限制？

在平台没有提供这些合同之前，不应把任意解释器或二进制打入 Skill ZIP。更好的方案是把能力部署成受控服务，再通过平台连接器访问。

7. Python 和 Node 版本治理

不同 Skill 使用不同版本会产生三个问题：解释器兼容性、依赖冲突、磁盘和启动成本。

本文示例企业的取舍是“统一受控版本，Skill 独立依赖空间”：

Skill A -> Python 3.12.7 + A 的 requirements
Skill B -> Python 3.12.7 + B 的 requirements
Skill C -> Node Runtime + C 的 package.json

不是：

所有 Skill -> 用户电脑上同一个 Python

因此：

• requires-python: "3.12" 是当前正式合同；
• 显式声明 3.11 时，当前平台应 fail closed，而不是偷偷使用系统 Python；
• 只写 python: true 或漏写声明的存量包可能被自动补成 3.12，但这是兼容路径，不是推荐写法；
• 不要写 >=3.11、3.11 || 3.12 等多版本求解表达式；
• 若业务只能运行在 3.11，应先把代码适配到 3.12，或向平台申请新的 Runtime。

这种方案牺牲了“作者任意选择版本”的自由，换来了可复制性、可扫描性和较低的运维复杂度。对于企业 Skill 平台，这是合理取舍。

8. 连接器、OAuth 和凭证

7.1 平台连接器

Skill 需要企业 MCP 或 API 时，应该声明稳定连接器标识：

connectors:
  - mcphub:crps

Skill 不应自己拼接 MCP 地址、读取连接器凭证或启动本地 MCP Server。平台会根据当前用户权限发现连接器并注入到当前 turn。

必需连接器不可用时，应 fail closed，常见 reason code 包括：

• skill_connector_permission_denied
• skill_connector_not_found
• skill_connector_invalid_declaration
• skill_connector_discovery_failed
• skill_connector_mode_disabled

7.2 两条认证链路：QAuth 管理面与业务 Token 数据面

这里需要区分两个容易混淆的场景：

场景	调用链路	认证职责
SkillHub 管理面	开发者 -> SkillHub -> 企业认证管理入口（QAuth） -> SkillHub	QAuth 保护登录入口，SkillHub 管理会话控制谁能查看、发布、下线或管理 Skill
Skill 执行数据面	Workbuddy -> Skill Runtime -> 下游微服务	Workbuddy 透传企业内部认证 Token，由下游微服务解析 Token 并执行业务权限判断

开发者先访问 SkillHub，由 SkillHub 进入企业认证管理入口并通过 QAuth 完成登录和授权；认证成功后，开发者在同一个认证管理入口中发起发布或管理操作，并携带 SkillHub 管理会话访问管理 API。QAuth 并不是每次 Skill 调用下游微服务时都必须重新介入的中间层。Skill 执行时使用什么 Token，取决于 Workbuddy 当前持有的认证体系和下游微服务的鉴权约定。

示例企业规范支持由宿主向当前 Runtime 注入当前会话的企业内部认证 Token。环境变量名称由宿主平台约定，Skill 只依赖运行时合同，不应硬编码某个客户端产品的变量名：

ENTERPRISE_ACCESS_TOKEN

它只存在于当前 Runtime 子进程和当前 turn。Skill 可以读取，但不得写入日志、URL、文件、缓存、异常或 artifact。

Skill 不负责解析、改写或持久化该 Token，只负责在请求下游微服务时按约定透传。Token 的格式、签名算法、解析方式、过期策略和用户身份字段由下游微服务及其认证基础设施决定。

7.3 QAuth 如何介入完整链路

QAuth 在本文中的定位是 SkillHub 管理面的统一认证入口，并与企业内部管理 App 作为一个整体提供能力。开发者访问 SkillHub 时，通过该认证管理入口完成 QAuth 登录和授权；认证成功后，入口携带 SkillHub 管理会话访问相关管理 API。SkillHub 根据 QAuth 返回的身份和权限，决定用户能否进入页面、发布 Skill、修改版本或执行管理操作。QAuth 解决的是“谁能访问 SkillHub 管理面”，SkillHub 负责“这个用户能管理哪些 Skill”。

QAuth 的典型介入点可以拆成四步：

认证管理入口注册的 client_id 和 redirect_uri
        |
        v
QAuth 登录并同意 SkillHub 管理 scope
        |
        v
授权码换取 access token 和 refresh token
        |
        v
认证管理入口使用会话访问 SkillHub 管理面
        |
        v
SkillHub 根据 QAuth 身份和管理权限执行页面与操作授权

• client_id 标识访问 SkillHub 的认证管理入口这个 OAuth 客户端，不是某个用户的身份，也不是业务系统的公共账号。
• redirect_uri 用于限制登录回调地址，必须与 QAuth 注册配置一致。
• access token 用于认证管理入口调用 SkillHub 管理 API，生命周期较短。
• refresh token 用于刷新 SkillHub 管理面会话，应由认证管理入口的受保护会话管理，不能交给 Skill，也不能写入 Skill 包。
• scope 表示认证管理入口申请的 SkillHub 管理能力，例如发布、修改或下线；具体操作仍由 SkillHub 的角色和资源权限判断。
• SkillHub 应按照 QAuth 集成约定校验令牌，不应只做 Base64 解码；具体验签、公钥、会话或网关校验方式以企业 QAuth 接入规范为准。

因此，QAuth 不是 Skill 的依赖安装器，也不是下游业务数据权限表。它负责保护 SkillHub 管理面；SkillHub 负责 Skill 的发布治理；Workbuddy 负责把企业内部认证 Token 安全地带入执行回合；下游业务服务负责解析 Token 并依据身份和资源规则做最后决定。

认证链路中的职责如下：

组件	负责什么	不负责什么
企业认证管理入口（QAuth）	提供登录、授权和 SkillHub 管理会话	不决定 SkillHub 具体资源的管理权限
企业认证管理入口（QAuth）	携带管理会话访问 SkillHub 页面和管理 API	不把管理面令牌交给 Skill 执行下游业务
SkillHub	校验 QAuth 接入结果，并执行 Skill 发布和管理授权	不替下游微服务解析业务 Token
Workbuddy	创建本轮执行上下文，临时透传企业内部认证 Token	不修改 Token，不伪造用户身份
Skill Runtime	按请求把 Token 透传给下游微服务	不持久化 Token，不读取 Cookie
下游业务服务	解析企业内部 Token，识别用户并执行最终业务授权	不信任请求体中自行传入的用户身份

SkillHub 管理面收到请求后，应按照 QAuth 接入规范校验会话和管理权限：

QAuth 管理面会话
        |
        v
使用 QAuth 会话或集成网关校验身份
        |
        v
读取 QAuth 认证后的用户身份
        |
        v
执行 SkillHub 的角色、资源和操作权限判断
        |

下游业务服务则应使用企业内部认证规范解析透传 Token，不能信任请求体中的 userId、username 或 email 来替代 Token 身份。Skill 只负责透传，不负责推断下游服务的 Token 格式。

企业内部认证 Token 只应存在于当前执行沙箱和当前 turn。不得写入命令行参数、URL query、文件、缓存、数据库、日志、异常、会话 transcript 或测试产物。收到下游服务的 401/403 时，应停止相关操作并提示重新登录或申请权限，不得回退到本地旧 token。

7.4 公共服务账号模式

如果 Skill Runtime 不提供用户 token，可以设计成：

Skill -> 只读业务 API -> 服务端内部凭证 -> 下游系统

服务端内部凭证必须留在 Apollo、密钥管理系统或服务端 Runtime 中，不能提供“获取公共 token”的 OpenAPI。否则 SkillHub 只读查询会退化成凭证导出接口。

9. 发布和安装安全链路

示例企业规范把校验分为多个阶段：

上传 ZIP
  -> 包结构校验
  -> frontmatter 校验
  -> Python/Node 依赖来源校验
  -> 浏览器自动化扫描
  -> 自启 MCP 扫描
  -> HTTP/MCP 地址和 redirect 扫描
  -> 凭证和敏感信息扫描
  -> pass / warn / reject
  -> 平台安装审计
  -> Runtime 依赖物化

8.1 三种结果

结果	含义	行为
pass / ok	静态审计通过	允许安装并投影到 Runtime
warn / auto_declared	缺少部分运行时声明，但未命中硬风险	兼容安装，同时要求作者整改
reject / rejected	命中依赖或安全边界	不安装、不投影

硬安全规则不能通过普通开关关闭：

• browser_auth
• self_mcp
• unsafe_http_mcp

8.2 重点拒绝项

• Playwright、Puppeteer、Selenium、WebDriver、CDP 等浏览器自动化；
• FastMCP、McpServer、stdio MCP server；
• npx/uvx 动态启动 MCP；
• localhost、回环、私网、metadata 地址的 HTTP MCP；
• 自动跨 origin 重定向；
• token、Cookie、client secret、Authorization header；
• 远程 pip/npm 源和 Git/VCS 依赖；
• 读取浏览器 profile、Cookie 或本地高权限文件。

10. 架构图

图中 SkillHub Registry 负责包和治理，Skill Runtime 负责执行，服务端鉴权与业务权限 负责最终安全判断。三者职责不能互相替代。

11. Skill 安装与执行时序图

12. 为什么不让每个 Skill 自带环境

“每个 Skill 自带 Python 3.11、Node 20、依赖和二进制”看似隔离，企业上通常不选，原因是：

• 包体积变大，下载和启动慢；
• 解释器和二进制来源难以审计；
• 同一漏洞需要扫描和升级大量副本；
• GPU、系统库和 CPU 架构兼容更复杂；
• 供应链风险扩大，Skill 可以偷偷带入任意可执行文件；
• 本地磁盘和缓存容易失控。

平台托管 Skill Runtime 的代价是限制版本自由，但换来了统一补丁、可重复执行和清晰的安全边界。

13. 普通程序员最容易问的问题

Q1：SkillHub 下载了代码，为什么不直接在 SkillHub 服务器上运行？

因为 Skill 可能访问本地文件、用户身份和企业连接器。让 Registry 服务器直接运行作者代码会把所有租户的风险集中到注册中心。更合理的是 Registry 负责分发，用户侧或受控执行集群负责运行。

Q2：有了静态扫描，是不是就安全了？

不是。静态扫描只能识别已知文件形态和危险关键词。Runtime 还要限制网络、文件、环境变量、子进程和资源；服务端还要做最终鉴权。安全是纵深防御，不是一次扫描。

Q3：为什么不能让 Skill 自己安装依赖？

因为 pip install URL、npm install git-url、安装脚本都可能执行任意代码、修改源或绕过企业制品管理。示例企业规范要求依赖声明可审计，由平台统一物化。

Q4：Python 3.11 的 Skill 能否在本地 Python 3.12 上碰巧运行？

不能把“碰巧能运行”当成平台合同。作者应按公司支持版本测试并声明 3.12。如果显式声明了不支持的版本，平台应 fail closed。

Q5：为什么 Skill 可以读取平台 Token，但又不能保存？

因为 token 是当前用户的短生命周期授权事实，不是 Skill 的配置。允许读取是为了请求业务服务，禁止持久化是为了避免 Skill 变成凭证窃取器。

Q6：Skill 调 API 和 MCP 有什么区别？

Skill 是上层工作流；API/MCP 是底层工具能力。企业应优先通过平台连接器治理 MCP 的发现、权限和凭证，而不是让 Skill 自己拼接 MCP 地址。

Q7：为什么一个只读业务 Skill 可以不需要用户 token？

例如，一个只读查询 Skill 可以采用服务端代理模式：Skill 只调用只读查询 API，公共凭证留在后端。这样用户没有 token 也能查，但服务端必须限制只读范围、Workspace、请求参数和输出数据。

14. 企业级设计取舍

方案	优点	代价	示例企业取舍
Skill 自带解释器	版本自由	包大、难扫描、难升级	不采用
使用系统 Python/Node	简单	机器差异大、不可复现	不作为正式合同
平台统一 Runtime	可复现、易修复、易审计	限制版本自由	采用
Skill 自启 MCP	灵活	绕过平台权限、供应链风险	拒绝
平台连接器	权限统一、可观测	需要平台接入	优先采用
Skill 直接持有业务 token	实现快	凭证泄露风险高	不采用
后端代理公共能力	Skill 简单、凭证留后端	需要服务端治理权限	仅限受控场景
每个 Skill 全局共享依赖	节省空间	依赖冲突	不采用
每个 Skill 独立依赖空间	隔离好	有缓存和启动成本	采用

15. 开发者发布清单

发布前检查：

• SKILL.md 位于包根目录；
• name、description 完整且名称唯一；
• Python Skill 声明 python: true 和 requires-python: "3.12"；
• Node Skill 声明 node: true；
• 依赖放在 requirements.txt 或 package.json；
• 不打包 .venv、node_modules、解释器、构建缓存和个人配置；
• 不包含 token、Cookie、client secret 和 Authorization header；
• 不使用浏览器自动化、CDP 或无头浏览器；
• 不自启 stdio/local MCP；
• HTTP/MCP 使用受信任 HTTPS，关闭自动重定向；
• 不读取浏览器 profile 和本地高权限文件；
• 服务端仍然验证用户身份和业务权限；
• 只给 Skill 必要的连接器和最小权限。

16. 最后的面试式回答

如果面试官问“你如何设计企业级 SkillHub”，可以这样回答：

我会把 SkillHub 拆成 Registry、Agent Host、Skill Runtime 和业务服务四层。Registry 只负责版本、命名空间、发布审核、静态扫描和分发，不直接执行上传代码；Workbuddy 负责根据 Skill 描述选择能力；Skill Runtime 根据 frontmatter 准备受控的 Python/Node 环境，并为每个 Skill 隔离依赖；连接器负责统一接入 MCP 和企业服务；下游微服务负责解析企业内部认证 Token 并执行最终业务权限。示例企业通过 Python 3.12.7 统一 Runtime、requirements/package.json 管理依赖、管理面使用 QAuth、执行面透传企业 Token，并拒绝浏览器自动化、自启 MCP、不安全 HTTP MCP 和凭证持久化。这样牺牲了任意版本和任意执行能力，换来了可复现、可审计、可撤权和较小的安全爆炸半径。

这个回答的关键不在于说“用了 Docker”，而在于说明：谁分发、谁执行、谁提供运行时、谁注入凭证、谁做最终权限判断，以及每一层为什么不能越权。

17. 相关资料

17.1 QAuth 与 OAuth 基础

• IBM：什么是 OAuth：了解 OAuth 的角色、授权流程、访问令牌和资源访问边界。
• 本文中的 QAuth 可作为企业统一身份认证服务来理解，具体的端点、客户端注册方式、令牌声明和公钥地址应以实际平台配置为准。

17.2 SkillHub 设计与使用

• SkillHub 概览与设计说明：了解开源 SkillHub 的整体定位、核心模块和工作方式。
• SkillHub 开源仓库：查看项目源码、目录结构、实现细节和版本变化。

17.3 阅读建议

建议按以下顺序阅读：先通过 OAuth 资料理解身份认证，再阅读 SkillHub 概览理解技能注册与分发，最后结合开源仓库对照 Registry、运行时和校验流程的具体实现。企业内部平台可能在登录、权限、运行时隔离和发布校验上有定制实现，不能直接假设与开源版本完全一致。

份企业规范示例：

• Python 当前支持 3.12，实际物化版本为经过 SHA-256 校验的 Python 3.12.7；
• Node Skill 使用平台提供的 Node Runtime；
• 依赖在受控运行时中物化，而不是由 Skill 自行下载解释器；
• 当前用户的企业内部认证 Token 只注入当前 Runtime 子进程和当前 turn；
• 加载后仍要做连接器权限和健康检查；
• 权限被撤销或凭证失效时 fail closed。

规范通常不会要求开发者绑定某一种底层技术，因此不能武断地说“每个 Skill 都运行在一个 Docker 容器里”。比较准确的说法是：

每个 Skill 的脚本应运行在由平台管理的 Skill Runtime，也就是执行沙箱或受控子进程中；具体隔离技术属于平台实现细节。

4. 本地 Workbuddy 如何运行 Skill

一次典型调用可以用下面的流程理解：

可以把本地安装理解为“下载 Skill 包”，但不能理解为“把 Skill 直接放进系统 PATH”。脚本的执行路径、依赖路径和环境变量都应由 Skill Runtime 管理。

4.1 是沙箱还是独立进程

“沙箱”和“独立进程”不是二选一：

• 独立进程是执行模型：每次 Skill 脚本可以运行在独立的 Python/Node 子进程中。
• 执行沙箱是权限模型：限制该进程能访问什么文件、网络、环境变量和系统能力。
• 容器是隔离实现的一种选择，但不是唯一选择。

企业级设计通常采用组合：

独立 Runtime 进程
  + 独立依赖目录
  + 最小环境变量集合
  + 允许域名或连接器白名单
  + 无特权系统用户
  + 超时、输出大小和资源限制
  + 服务端最终鉴权

企业规范通常会明确限制网络、浏览器、MCP 和凭证使用，但不一定公开平台的底层隔离技术。因此开发者应依赖规范边界，不应假设可以访问本机所有文件或任意内网地址。

5. 如何解决 Python、Node 和其他语言

5.1 优先级

企业平台应按以下优先级取舍：

1. 平台连接器：优先复用企业已治理的 MCP/API 能力。
2. Python/Node 脚本：用于稳定、可测试、需要本地计算的逻辑。
3. 纯 Shell/CMD：只适合简单且明确的平台命令，不适合作为跨系统合同。
4. 其他语言二进制：除非平台提供签名制品和明确 Runtime，否则不建议放进通用 Skill。

原因是连接器可以统一处理权限、凭证和网络；Python/Node 有成熟的受控运行时；Shell 和任意二进制更依赖宿主机，跨平台和安全边界更难治理。

5.2 Python Skill

声明：

python: true
requires-python: "3.12"
requirements: requirements.txt

规则：

• 当前只支持 Python 3.12；实际版本为 3.12.7。
• 依赖放 requirements.txt。
• 不打包 .venv、解释器或 site-packages。
• 不允许自行修改 pip 源、从 Git/URL 安装代码或执行远程安装脚本。
• 只使用标准库时，可以不提供 requirements.txt。

5.3 Node Skill

声明：

node: true

依赖放在根目录 package.json。平台负责准备 Node Runtime 和依赖目录。依赖应来自受支持的 registry 和合法 semver，不允许 Git、URL、本地路径、link: 或 workspace: 形式。

5.4 Shell、PowerShell 和 CMD

示例企业规范对 Shell 并没有像 Python/Node 那样明确的统一 Runtime 合同。因此建议：

• 跨平台 Skill 使用 Python 标准库；
• Windows 专用操作明确声明 PowerShell 前置条件；
• Linux/macOS 专用操作明确声明 Bash 前置条件；
• 不要在 Skill 中安装 Bash、Python、Node 或系统软件；
• 不要把 cmd.exe、powershell.exe 当成所有 Agent 都存在的抽象能力；
• 需要企业系统能力时，优先改成平台连接器或服务端 API。

5.5 其他语言

如果 Skill 需要 Java、Go、Rust 或自带二进制，企业平台必须先回答三个问题：

• Runtime 从哪里来，版本如何固定？
• 二进制如何签名、扫描和升级？
• 网络、文件和子进程权限如何限制？

在平台没有提供这些合同之前，不应把任意解释器或二进制打入 Skill ZIP。更好的方案是把能力部署成受控服务，再通过平台连接器访问。

6. Python 和 Node 版本治理

不同 Skill 使用不同版本会产生三个问题：解释器兼容性、依赖冲突、磁盘和启动成本。

本文示例企业的取舍是“统一受控版本，Skill 独立依赖空间”：

Skill A -> Python 3.12.7 + A 的 requirements
Skill B -> Python 3.12.7 + B 的 requirements
Skill C -> Node Runtime + C 的 package.json

不是：

所有 Skill -> 用户电脑上同一个 Python

因此：

• requires-python: "3.12" 是当前正式合同；
• 显式声明 3.11 时，当前平台应 fail closed，而不是偷偷使用系统 Python；
• 只写 python: true 或漏写声明的存量包可能被自动补成 3.12，但这是兼容路径，不是推荐写法；
• 不要写 >=3.11、3.11 || 3.12 等多版本求解表达式；
• 若业务只能运行在 3.11，应先把代码适配到 3.12，或向平台申请新的 Runtime。

这种方案牺牲了“作者任意选择版本”的自由，换来了可复制性、可扫描性和较低的运维复杂度。对于企业 Skill 平台，这是合理取舍。

7. 连接器、OAuth 和凭证

7.1 平台连接器

Skill 需要企业 MCP 或 API 时，应该声明稳定连接器标识：

connectors:
  - mcphub:crps

Skill 不应自己拼接 MCP 地址、读取连接器凭证或启动本地 MCP Server。平台会根据当前用户权限发现连接器并注入到当前 turn。

必需连接器不可用时，应 fail closed，常见 reason code 包括：

• skill_connector_permission_denied
• skill_connector_not_found
• skill_connector_invalid_declaration
• skill_connector_discovery_failed
• skill_connector_mode_disabled

7.2 两条认证链路：QAuth 管理面与业务 Token 数据面

这里需要区分两个容易混淆的场景：

场景	调用链路	认证职责
SkillHub 管理面	开发者 -> SkillHub -> 企业认证管理入口（QAuth） -> SkillHub	QAuth 保护登录入口，SkillHub 管理会话控制谁能查看、发布、下线或管理 Skill
Skill 执行数据面	Workbuddy -> Skill Runtime -> 下游微服务	Workbuddy 透传企业内部认证 Token，由下游微服务解析 Token 并执行业务权限判断

开发者先访问 SkillHub，由 SkillHub 进入企业认证管理入口并通过 QAuth 完成登录和授权；认证成功后，开发者在同一个认证管理入口中发起发布或管理操作，并携带 SkillHub 管理会话访问管理 API。QAuth 并不是每次 Skill 调用下游微服务时都必须重新介入的中间层。Skill 执行时使用什么 Token，取决于 Workbuddy 当前持有的认证体系和下游微服务的鉴权约定。

示例企业规范支持由宿主向当前 Runtime 注入当前会话的企业内部认证 Token。环境变量名称由宿主平台约定，Skill 只依赖运行时合同，不应硬编码某个客户端产品的变量名：

ENTERPRISE_ACCESS_TOKEN

它只存在于当前 Runtime 子进程和当前 turn。Skill 可以读取，但不得写入日志、URL、文件、缓存、异常或 artifact。

Skill 不负责解析、改写或持久化该 Token，只负责在请求下游微服务时按约定透传。Token 的格式、签名算法、解析方式、过期策略和用户身份字段由下游微服务及其认证基础设施决定。

7.3 QAuth 如何介入完整链路

QAuth 在本文中的定位是 SkillHub 管理面的统一认证入口，并与企业内部管理 App 作为一个整体提供能力。开发者访问 SkillHub 时，通过该认证管理入口完成 QAuth 登录和授权；认证成功后，入口携带 SkillHub 管理会话访问相关管理 API。SkillHub 根据 QAuth 返回的身份和权限，决定用户能否进入页面、发布 Skill、修改版本或执行管理操作。QAuth 解决的是“谁能访问 SkillHub 管理面”，SkillHub 负责“这个用户能管理哪些 Skill”。

QAuth 的典型介入点可以拆成四步：

认证管理入口注册的 client_id 和 redirect_uri
        |
        v
QAuth 登录并同意 SkillHub 管理 scope
        |
        v
授权码换取 access token 和 refresh token
        |
        v
认证管理入口使用会话访问 SkillHub 管理面
        |
        v
SkillHub 根据 QAuth 身份和管理权限执行页面与操作授权

• client_id 标识访问 SkillHub 的认证管理入口这个 OAuth 客户端，不是某个用户的身份，也不是业务系统的公共账号。
• redirect_uri 用于限制登录回调地址，必须与 QAuth 注册配置一致。
• access token 用于认证管理入口调用 SkillHub 管理 API，生命周期较短。
• refresh token 用于刷新 SkillHub 管理面会话，应由认证管理入口的受保护会话管理，不能交给 Skill，也不能写入 Skill 包。
• scope 表示认证管理入口申请的 SkillHub 管理能力，例如发布、修改或下线；具体操作仍由 SkillHub 的角色和资源权限判断。
• SkillHub 应按照 QAuth 集成约定校验令牌，不应只做 Base64 解码；具体验签、公钥、会话或网关校验方式以企业 QAuth 接入规范为准。

因此，QAuth 不是 Skill 的依赖安装器，也不是下游业务数据权限表。它负责保护 SkillHub 管理面；SkillHub 负责 Skill 的发布治理；Workbuddy 负责把企业内部认证 Token 安全地带入执行回合；下游业务服务负责解析 Token 并依据身份和资源规则做最后决定。

认证链路中的职责如下：

组件	负责什么	不负责什么
企业认证管理入口（QAuth）	提供登录、授权和 SkillHub 管理会话	不决定 SkillHub 具体资源的管理权限
企业认证管理入口（QAuth）	携带管理会话访问 SkillHub 页面和管理 API	不把管理面令牌交给 Skill 执行下游业务
SkillHub	校验 QAuth 接入结果，并执行 Skill 发布和管理授权	不替下游微服务解析业务 Token
Workbuddy	创建本轮执行上下文，临时透传企业内部认证 Token	不修改 Token，不伪造用户身份
Skill Runtime	按请求把 Token 透传给下游微服务	不持久化 Token，不读取 Cookie
下游业务服务	解析企业内部 Token，识别用户并执行最终业务授权	不信任请求体中自行传入的用户身份

SkillHub 管理面收到请求后，应按照 QAuth 接入规范校验会话和管理权限：

QAuth 管理面会话
        |
        v
使用 QAuth 会话或集成网关校验身份
        |
        v
读取 QAuth 认证后的用户身份
        |
        v
执行 SkillHub 的角色、资源和操作权限判断
        |

下游业务服务则应使用企业内部认证规范解析透传 Token，不能信任请求体中的 userId、username 或 email 来替代 Token 身份。Skill 只负责透传，不负责推断下游服务的 Token 格式。

企业内部认证 Token 只应存在于当前执行沙箱和当前 turn。不得写入命令行参数、URL query、文件、缓存、数据库、日志、异常、会话 transcript 或测试产物。收到下游服务的 401/403 时，应停止相关操作并提示重新登录或申请权限，不得回退到本地旧 token。

7.4 公共服务账号模式

如果 Skill Runtime 不提供用户 token，可以设计成：

Skill -> 只读业务 API -> 服务端内部凭证 -> 下游系统

服务端内部凭证必须留在 Apollo、密钥管理系统或服务端 Runtime 中，不能提供“获取公共 token”的 OpenAPI。否则 SkillHub 只读查询会退化成凭证导出接口。

8. 发布和安装安全链路

示例企业规范把校验分为多个阶段：

上传 ZIP
  -> 包结构校验
  -> frontmatter 校验
  -> Python/Node 依赖来源校验
  -> 浏览器自动化扫描
  -> 自启 MCP 扫描
  -> HTTP/MCP 地址和 redirect 扫描
  -> 凭证和敏感信息扫描
  -> pass / warn / reject
  -> 平台安装审计
  -> Runtime 依赖物化

8.1 三种结果

结果	含义	行为
pass / ok	静态审计通过	允许安装并投影到 Runtime
warn / auto_declared	缺少部分运行时声明，但未命中硬风险	兼容安装，同时要求作者整改
reject / rejected	命中依赖或安全边界	不安装、不投影

硬安全规则不能通过普通开关关闭：

• browser_auth
• self_mcp
• unsafe_http_mcp

8.2 重点拒绝项

• Playwright、Puppeteer、Selenium、WebDriver、CDP 等浏览器自动化；
• FastMCP、McpServer、stdio MCP server；
• npx/uvx 动态启动 MCP；
• localhost、回环、私网、metadata 地址的 HTTP MCP；
• 自动跨 origin 重定向；
• token、Cookie、client secret、Authorization header；
• 远程 pip/npm 源和 Git/VCS 依赖；
• 读取浏览器 profile、Cookie 或本地高权限文件。

9. 架构图

图中 SkillHub Registry 负责包和治理，Skill Runtime 负责执行，服务端鉴权与业务权限 负责最终安全判断。三者职责不能互相替代。

10. Skill 安装与执行时序图

11. 为什么不让每个 Skill 自带环境

“每个 Skill 自带 Python 3.11、Node 20、依赖和二进制”看似隔离，企业上通常不选，原因是：

• 包体积变大，下载和启动慢；
• 解释器和二进制来源难以审计；
• 同一漏洞需要扫描和升级大量副本；
• GPU、系统库和 CPU 架构兼容更复杂；
• 供应链风险扩大，Skill 可以偷偷带入任意可执行文件；
• 本地磁盘和缓存容易失控。

平台托管 Skill Runtime 的代价是限制版本自由，但换来了统一补丁、可重复执行和清晰的安全边界。

12. 普通程序员最容易问的问题

Q1：SkillHub 下载了代码，为什么不直接在 SkillHub 服务器上运行？

因为 Skill 可能访问本地文件、用户身份和企业连接器。让 Registry 服务器直接运行作者代码会把所有租户的风险集中到注册中心。更合理的是 Registry 负责分发，用户侧或受控执行集群负责运行。

Q2：有了静态扫描，是不是就安全了？

不是。静态扫描只能识别已知文件形态和危险关键词。Runtime 还要限制网络、文件、环境变量、子进程和资源；服务端还要做最终鉴权。安全是纵深防御，不是一次扫描。

Q3：为什么不能让 Skill 自己安装依赖？

因为 pip install URL、npm install git-url、安装脚本都可能执行任意代码、修改源或绕过企业制品管理。示例企业规范要求依赖声明可审计，由平台统一物化。

Q4：Python 3.11 的 Skill 能否在本地 Python 3.12 上碰巧运行？

不能把“碰巧能运行”当成平台合同。作者应按公司支持版本测试并声明 3.12。如果显式声明了不支持的版本，平台应 fail closed。

Q5：为什么 Skill 可以读取平台 Token，但又不能保存？

因为 token 是当前用户的短生命周期授权事实，不是 Skill 的配置。允许读取是为了请求业务服务，禁止持久化是为了避免 Skill 变成凭证窃取器。

Q6：Skill 调 API 和 MCP 有什么区别？

Skill 是上层工作流；API/MCP 是底层工具能力。企业应优先通过平台连接器治理 MCP 的发现、权限和凭证，而不是让 Skill 自己拼接 MCP 地址。

Q7：为什么一个只读业务 Skill 可以不需要用户 token？

例如，一个只读查询 Skill 可以采用服务端代理模式：Skill 只调用只读查询 API，公共凭证留在后端。这样用户没有 token 也能查，但服务端必须限制只读范围、Workspace、请求参数和输出数据。

13. 企业级设计取舍

方案	优点	代价	示例企业取舍
Skill 自带解释器	版本自由	包大、难扫描、难升级	不采用
使用系统 Python/Node	简单	机器差异大、不可复现	不作为正式合同
平台统一 Runtime	可复现、易修复、易审计	限制版本自由	采用
Skill 自启 MCP	灵活	绕过平台权限、供应链风险	拒绝
平台连接器	权限统一、可观测	需要平台接入	优先采用
Skill 直接持有业务 token	实现快	凭证泄露风险高	不采用
后端代理公共能力	Skill 简单、凭证留后端	需要服务端治理权限	仅限受控场景
每个 Skill 全局共享依赖	节省空间	依赖冲突	不采用
每个 Skill 独立依赖空间	隔离好	有缓存和启动成本	采用

14. 开发者发布清单

发布前检查：

• SKILL.md 位于包根目录；
• name、description 完整且名称唯一；
• Python Skill 声明 python: true 和 requires-python: "3.12"；
• Node Skill 声明 node: true；
• 依赖放在 requirements.txt 或 package.json；
• 不打包 .venv、node_modules、解释器、构建缓存和个人配置；
• 不包含 token、Cookie、client secret 和 Authorization header；
• 不使用浏览器自动化、CDP 或无头浏览器；
• 不自启 stdio/local MCP；
• HTTP/MCP 使用受信任 HTTPS，关闭自动重定向；
• 不读取浏览器 profile 和本地高权限文件；
• 服务端仍然验证用户身份和业务权限；
• 只给 Skill 必要的连接器和最小权限。

15. 最后的面试式回答

如果面试官问“你如何设计企业级 SkillHub”，可以这样回答：

我会把 SkillHub 拆成 Registry、Agent Host、Skill Runtime 和业务服务四层。Registry 只负责版本、命名空间、发布审核、静态扫描和分发，不直接执行上传代码；Workbuddy 负责根据 Skill 描述选择能力；Skill Runtime 根据 frontmatter 准备受控的 Python/Node 环境，并为每个 Skill 隔离依赖；连接器负责统一接入 MCP 和企业服务；下游微服务负责解析企业内部认证 Token 并执行最终业务权限。示例企业通过 Python 3.12.7 统一 Runtime、requirements/package.json 管理依赖、管理面使用 QAuth、执行面透传企业 Token，并拒绝浏览器自动化、自启 MCP、不安全 HTTP MCP 和凭证持久化。这样牺牲了任意版本和任意执行能力，换来了可复现、可审计、可撤权和较小的安全爆炸半径。

这个回答的关键不在于说“用了 Docker”，而在于说明：谁分发、谁执行、谁提供运行时、谁注入凭证、谁做最终权限判断，以及每一层为什么不能越权。

16. 相关资料

16.1 QAuth 与 OAuth 基础

• IBM：什么是 OAuth：了解 OAuth 的角色、授权流程、访问令牌和资源访问边界。
• 本文中的 QAuth 可作为企业统一身份认证服务来理解，具体的端点、客户端注册方式、令牌声明和公钥地址应以实际平台配置为准。

16.2 SkillHub 设计与使用

• SkillHub 概览与设计说明：了解开源 SkillHub 的整体定位、核心模块和工作方式。
• SkillHub 开源仓库：查看项目源码、目录结构、实现细节和版本变化。

16.3 阅读建议

建议按以下顺序阅读：先通过 OAuth 资料理解身份认证，再阅读 SkillHub 概览理解技能注册与分发，最后结合开源仓库对照 Registry、运行时和校验流程的具体实现。企业内部平台可能在登录、权限、运行时隔离和发布校验上有定制实现，不能直接假设与开源版本完全一致。