一、为什么要做 SkillGo?
聚焦于解决:
创造一个私有化部署的社区,Skill 获得以后,在社区中怎样管理、怎样运行、怎样隔离,以及怎样将skill配置成可以接入业务系统的api。
这是 SkillGo 出现的原因。
GitHub:
GitHub - Max-cu/SkillGo: A self-hosted multi-user Agent and Skill platform with isolated execution, auditable runs, and verifiable artifacts. · GitHub
最新正式版本:
Release SkillGo v0.2.1 · Max-cu/SkillGo · GitHub
二、SkillGo 是什么?
SkillGo 是一个面向企业私有化部署的多用户 Skill 管理与运行平台。
它不是单纯的 Skill 商店,也不是一个只负责安装 Skill 的命令行工具。
SkillGo 希望建立一条完整链路:
上传 Skill ↓ 结构校验 ↓ 版本管理 ↓ 审核与发布 ↓ 用户选择并运行 ↓ 独立沙箱执行 ↓ 结果与产物交付 ↓ 发布为外部 API它主要解决四个问题:
- Skill 的统一管理
- Skill 的真实运行
- 不同用户和任务之间的环境隔离
- Skill 的 API 化与企业内部接入
一句话概括:
SkillGo 让 Skill 不只是一个可以下载的文件包,而是一个可以被治理、运行、复用和接入业务的能力单元。
三、Skill 的统一管理
当 Skill 数量逐渐增加以后,仅仅把它们放在文件夹或代码仓库中是不够的。
SkillGo 为此提供了完整的 Skill 生命周期管理:
- Skill 上传
- 包结构校验
SKILL.md解析- 版本管理
- 不可变发布版本
- 私有与社区可见性
- 管理员审核
- 发布状态管理
- 运行画像识别
- 所有者与权限管理
- 历史任务版本追踪
SkillGo 兼容以顶层SKILL.md为入口的通用 Agent Skill,同时支持可选的skillgo.yaml扩展配置。
一个基础 Skill 可以是:
weather/ └── SKILL.md复杂 Skill 也可以包含脚本、依赖和参考资料:
document-review/ ├── SKILL.md ├── scripts/ │ └── review.py ├── references/ │ └── formatting-rules.md └── requirements.txt平台会分析 Skill 中声明或实际使用的:
- 脚本
- 命令
- Python 依赖
- 输入文件
- 输出文件
- 网络需求
- 工具需求
- 执行方式
经过审核和发布的版本会被固定保存。
任务运行时绑定到确切的 Skill 版本,后续即使上传了新版本,也不会改变历史任务的执行依据。
四、Skill 不只是被管理,还要能够真正运行
SkillGo 和普通 Skill Hub 最大的区别,是它不仅保存和展示 Skill,还负责真正运行 Skill。
有些 Skill 只包含文字指令,可以直接交给模型执行。
但更多实用 Skill 会涉及:
- 执行 Python
- 调用 Shell 命令
- 读取用户文件
- 安装临时依赖
- 调用工具
- 执行多轮流程
- 生成 Word、Excel、PDF 或其他文件
- 对生成结果进行验证
这些操作需要一个真实运行环境。
因此,SkillGo 在控制面之外实现了一套 Worker 和沙箱执行链路。
当用户运行需要工具或脚本的 Skill 时,平台会:
- 创建任务记录;
- 固定本次使用的 Skill 版本;
- 保存当前用户和输入文件归属;
- 由 Worker 领取任务;
- 创建本次任务专属的 Docker Volume;
- 将 Skill 和输入文件放入独立工作区;
- 创建独立任务容器;
- 在容器中执行 Agent、工具和脚本;
- 收集并验证输出文件;
- 保存任务结果;
- 销毁临时容器和 Volume。
这意味着 Skill 在 SkillGo 中不是一段只供模型阅读的说明,而是能够进入真实执行环境、调用工具并交付结果的完整工作单元。
五、多用户之间怎样保证互不干扰?
企业内部部署 Skill 平台时,不可能只考虑一个用户。
多个用户会同时:
- 上传不同 Skill
- 运行不同任务
- 上传内部文件
- 生成任务产物
- 创建 API Endpoint
- 查看自己的历史记录
如果只使用一个公共工作目录,就容易出现文件混用、任务覆盖和数据越权。
SkillGo 使用两层隔离解决这个问题。
第一层:用户资源隔离
SkillGo 中的以下资源都有明确的所有者:
- Skill
- 会话
- 附件
- 任务
- 输入文件
- 生成产物
- API Endpoint
后端 API 查询资源时,会同时校验当前用户和对象归属。
这不是简单地在前端隐藏其他人的菜单,而是在数据库查询和接口层限制访问。
文件存储路径也会按照用户和任务划分:
workspaces/{user_id}/{conversation_id}/... job-inputs/{user_id}/{job_id}/... job-artifacts/{user_id}/{job_id}/...第二层:任务级沙箱隔离
SkillGo 不会给每个用户永久运行一台虚拟机,而是采用更细粒度的任务隔离:
每次 Skill 任务的每次执行尝试,都创建一套独立沙箱。
例如:
用户 A ├── 任务 A1 → Volume A1 + 容器 A1 └── 任务 A2 → Volume A2 + 容器 A2 用户 B └── 任务 B1 → Volume B1 + 容器 B1不同任务之间不会共享:
- 可写文件系统
/workspace/tmp- 临时依赖
- 进程状态
- 输入文件
- 生成产物
即使同一个用户并发运行两个 Skill,这两个任务也拥有各自独立的执行环境。
因此,SkillGo 实际实现的是:
用户级资源隔离 + 任务级运行环境隔离。
六、使用 Docker 和 gVisor 运行 Skill
SkillGo 的完整部署模式面向 Linux 服务器,并支持使用 gVisor 的runsc作为 Docker Runtime。
gVisor 是 Google 开源的容器沙箱技术。
在 SkillGo 中,执行关系如下:
SkillGo Worker ↓ Docker SDK ↓ Docker Container ↓ runtime=runsc gVisor ↓ Skill 任务进程每个 Skill 任务容器还会应用以下限制:
- 使用非 root 用户
- 根文件系统只读
- 独立可写工作区
- 独立
/tmp - 移除 Linux Capabilities
- 启用
no-new-privileges - 限制 CPU
- 限制内存
- 限制进程数量
- 默认关闭任务网络
- 不挂载 Docker Socket
- 不提供数据库连接
- 不提供平台 JWT Secret
- 不向任务容器暴露模型 API Key
Worker 只会把本次任务选择的 Skill 和输入文件放入独立 Volume,不会把平台完整存储目录挂载到任务容器。
这使得不同用户运行 Skill 时,不会共享工作目录和进程环境。
七、将配置好的 Skill 发布为 API
企业内部完成一个 Skill 的配置、审核和验证以后,往往不希望它只能在网页中运行。
其他系统可能也需要调用同一项能力,例如:
- OA 系统
- 文档管理系统
- 数据平台
- 企业内部工作流
- 审批系统
- 研发平台
- 业务后台
因此,SkillGo 支持把已发布的 Skill 版本部署成 API Endpoint。
平台根据 Skill 的执行方式提供两种接口。
指令型 Skill:同步 API
适合不需要独立沙箱文件任务的 Skill:
POST /api/v1/invoke/{slug}调用方提交 JSON 数据,平台同步返回结构化结果和run_id。
沙箱型 Skill:异步任务 API
适合需要上传文件、运行脚本和生成产物的 Skill:
POST /api/v1/workflow-endpoints/{slug}/jobs调用示例:
curl -X POST "https://your-skillgo.example/api/v1/workflow-endpoints/document-review/jobs" \ -H "X-SkillGo-Key: $SKILLGO_API_KEY" \ -H "Idempotency-Key: request-001" \ -F "file=@./input.docx" \ -F "instruction=请执行文档校对并生成结果文件"接口返回任务 ID 后,调用方可以继续:
- 查询任务状态
- 取消任务
- 获取执行结果
- 下载生成产物
每个 Endpoint 使用独立 API Key。
密钥完整内容只会在创建或轮换时返回一次,数据库仅保存密钥前缀和 SHA-256 摘要。
外部 API 创建的任务不会绕过平台原有的用户归属和沙箱机制。
它仍然会:
- 绑定 Endpoint 所有者
- 固定 Skill 版本
- 创建独立任务
- 进入独立沙箱
- 验证输出文件
- 记录执行过程
这使企业可以先在 SkillGo 网页中配置和验证 Skill,再把同一项能力接入现有业务系统。
八、为什么适合企业私有化部署?
SkillGo 从一开始就不是按照公共 SaaS 工具设计的,而是面向企业内部部署场景。
完整平台可以部署在企业自己的 Linux 服务器中,包括:
- Web 前端
- FastAPI 控制面
- PostgreSQL
- Sandbox Worker
- Docker
- gVisor
- 文件存储
- 模型连接配置
企业可以连接自己的 OpenAI-compatible 模型服务。
用户上传的 Skill、附件、任务记录和生成产物都保存在自己的实例中。
平台支持:
- 成员、管理员和唯一超级管理员
- 管理员注册审核
- Skill 发布审核
- 用户资源归属
- 模型连接管理
- API Key 管理
- 审计记录
- 数据库迁移
- 备份与恢复
- 版本升级
- 存储生命周期管理
对话附件、任务输入和生成产物默认保留 15 天,到期后自动删除,避免长期运行后文件无限堆积。
管理员可以在存储管理页面查看服务器磁盘容量和不同用户的文件占用情况。
九、SkillGo 的运行架构
SkillGo 当前的整体执行链路如下:
主要组件包括:
用户工作台 / 外部业务系统 ↓ React + TypeScript ↓ FastAPI 控制面 ↓ PostgreSQL 任务与资源记录 ↓ Sandbox Worker 领取任务 ↓ 独立 Docker Volume ↓ gVisor runsc 任务容器 ↓ Agent 执行 Skill ↓ 产物验证与持久化 ↓ 网页下载 / API 返回控制面负责:
- 用户身份
- 权限检查
- Skill 管理
- 版本管理
- 任务创建
- Endpoint 管理
- 审计记录
Worker 负责:
- 任务租约
- 模型编排
- 容器生命周期
- 工具执行
- 产物收集
- 结果验证
任务容器只负责运行当前 Skill,不拥有平台控制权限。
十、技术栈
| 层级 | 技术 |
|---|---|
| 前端 | React、TypeScript、Vite、Nginx |
| 后端 | Python 3.12、FastAPI、Pydantic、SQLAlchemy |
| 数据库 | PostgreSQL,开发环境支持 SQLite |
| 数据库迁移 | Alembic |
| 身份认证 | JWT、Argon2 |
| 模型接入 | OpenAI-compatible API |
| 任务调度 | 数据库行锁、任务租约、心跳与失效恢复 |
| 沙箱运行 | Docker SDK、独立 Volume、gVisorrunsc |
| 前端动画 | GSAP |
| 部署 | Docker Compose |
| 自动化测试 | pytest、TypeScript、Vite、GitHub Actions |
十一、快速体验
基础模式
基础模式可以预览 SkillGo 界面、用户管理和普通对话,不包含完整沙箱 Worker。
git clone https://github.com/Max-cu/SkillGo.git cd SkillGo git checkout v0.2.1 cp .env.example .env启动前需要编辑.env,至少替换:
- PostgreSQL 密码
- JWT Secret
- 初始超级管理员邮箱
- 初始超级管理员密码
然后执行:
docker compose up -d --build默认访问地址:
http://127.0.0.1:8080完整沙箱模式
完整模式需要:
- Linux
- Docker Engine
- Docker Compose v2
- gVisor
runsc
配置.env和deploy/ecs.env后执行:
docker compose \ --env-file .env \ --env-file deploy/ecs.env \ --profile build-only \ build sandbox-runtime docker compose \ --env-file .env \ --env-file deploy/ecs.env \ --profile sandbox \ up -d --build完整部署文档:
SkillGo/deploy/README.md at main · Max-cu/SkillGo · GitHub
十二、SkillGo 适合哪些场景?
SkillGo 适合需要统一管理和运行 Skill 的团队或企业,例如:
- 企业内部 Skill 中心
- 私有化 Agent 能力平台
- 文档处理与审核平台
- 数据处理 Skill 平台
- 研发自动化工具平台
- 多用户 AI 工作台
- AI 能力 API 网关
- 将已有 Skill 接入业务系统
- 需要隔离运行第三方 Skill 的场景
如果只是搜索或下载 Skill,现有 Skill Hub 已经能够很好地解决问题。
但如果你还需要:
- 管理 Skill
- 审核 Skill
- 固定 Skill 版本
- 让多个用户运行 Skill
- 保证不同任务环境独立
- 交付真实生成的文件
- 将 Skill 发布成 API
- 在企业内部私有化部署
那么这正是 SkillGo 想解决的问题。
十三、写在最后
SkillGo 的出发点并不是再做一个 Skill Hub。
现有生态已经有很多优秀的 Skill 发现、分享和安装工具。
SkillGo 希望补齐的是 Skill 被发现和安装之后的下一段链路:
怎样统一管理 Skill,怎样让 Skill 真正运行,怎样让不同用户和任务互不干扰,以及怎样把验证过的 Skill 接入企业业务。
这也是 SkillGo 最核心的定位:
一个支持多用户管理、任务级独立沙箱运行和 Skill API 化的私有化平台。
项目已经正式开源,并发布了正式版本 v0.2.1。
GitHub:
GitHub - Max-cu/SkillGo: A self-hosted multi-user Agent and Skill platform with isolated execution, auditable runs, and verifiable artifacts. · GitHub
正式 Release:
Release SkillGo v0.2.1 · Max-cu/SkillGo · GitHub
如果你正在寻找一套能够管理并真正运行 Skill 的私有化功能平台,欢迎体验 SkillGo。
如果项目对你有帮助,也欢迎点一个 ⭐ Star,或者提交 Issue 分享你的使用反馈。