Skales 评测：闭源 BSL 1.1 桌面智能体，仓库里躺着一份冻结的 v7 快照
Personal AI desktop agent for Windows, macOS, Linux, Android & iOS. Set a goal, it works on its own. Teams (pair two desktops, agents + humans), Agent2Agent, Workflows, Codework, multi-agent orgs, desktop + browser automation. 15+ AI providers, BYOK. No Docker, no terminal. Agent Skills (SKILL.md). Migration importer. Recurring autonomous tasks.
秒懂
- 它是什么？
- Skales 把个人 AI 智能体做成双击安装的桌面程序，覆盖 Windows、macOS、Linux、Android 与 iOS，支持自带密钥与 Ollama 离线运行。它的发行仓库与产品本身是两回事：源码是 v7 历史快照，实际运行的是从 skales.app 下载的签名应用。
- 适合谁用？
- Skales 适合想要本地文件访问、又不想碰 Docker 和命令行的个人用户，以及需要把手机当作远程入口驱动桌面工具链的人。不适合需要审计源码、需要自托管服务端或需要可编程 API 的团队，因为仓库里的 TypeScript 只是冻结的 v7 快照，不参与构建。
- 能商用吗？
- 请先确认。这个仓库使用的许可证不在我们自动归类的范围内，商用前请阅读仓库里的 LICENSE 文件。
- 还在维护吗？
- 在维护。仓库最近一次提交在 5 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
先厘清一件事：这个仓库不是 Skales 本身
README 顶部有一行小字，写得比大多数项目都诚实：closed source under BSL 1.1，免费供个人使用，这个仓库承载的是发行包、变更日志和 issue 追踪，检入的源码是冻结的 v7 快照，不是实际发布的代码。下面又重复了一遍：源码树是历史 v7 快照，不维护、不构建、也不运行在你的机器上。
这决定了整个评估的框架。你无法通过读代码来判断 Skales 12.9.26 到底做了什么，只能通过官方文档、变更日志和实际安装的签名应用。对于一个宣称能访问你的文件、浏览器、日历和邮件的智能体来说，这是个需要认真对待的信任问题：能力越大，不可审计的代价越高。项目方显然知道这一点，所以把 SECURITY.md 放在显眼位置，说明哪些在范围内。但范围界定不等于代码可读。
仓库语言标注为 TypeScript，主题标签里同时出现 electron 和 react-native，这与桌面加移动的双端形态吻合。不过这只能说明 v7 时期的技术选型，不能推断当前版本仍在使用同一套栈。任何基于仓库文件结构做出的架构判断，都要打上这个折扣。
它解决的是安装门槛，不是能力上限
同类工具的通病是启动成本。README 的对比表格给出的说法是：典型 AI 智能体需要 Docker、终端和 Python CLI，内存占用 1.5GB 到 3GB 以上，通常只在 Linux 或容器里跑；Skales 则是下载 EXE、DMG 或 AppImage 后双击，标称内存约 300MB，三平台原生支持，首次任务耗时以秒计。这些数字来自项目自己的对比表，没有第三方验证，应当当作宣传口径而非实测结论。
真正值得注意的不是这些数字，而是目标用户的定位。README 明确写着 made for everyone from 6 to 60+，并且强调不需要终端。这是一个明确的产品决策：牺牲可脚本化和可组合性，换取非开发者也能用起来。对工程师来说，这意味着你拿不到一个可以塞进 CI 流水线的命令行工具，拿到的是一个有图形界面、有像素皮肤、有桌面宠物的应用。
它要解决的问题因此很具体：让不懂技术的人也能用上一个能读写本地文件、能操作浏览器的智能体，而不必先学会容器编排。这个目标本身是合理的，只是它和工程团队通常的采购标准并不重合。
十一个入口背后的机制：目标、绑定与后台续跑
README 把功能组织成十一个位置：Chat、Code、Studio、Cockpit、Planner、Iris Orbit、Memory、Mobile、Skales Pocket、Plugins、Discover and Wrapped，外加 Settings 与 Add-Ons。这个划分方式本身透露了架构取向：不是围绕单一对话窗口堆功能，而是按任务类型切分工作面。
最能说明运行机制的是两个斜杠命令。`/goal build me a trading bot` 表示把目标交给它，然后合上笔记本，任务在后台跨多步执行，并且能从上次中断的地方继续。`/code` 把某个文件夹绑定到任意一个聊天会话上，配合内联 diff 和一键撤销。前者说明存在任务持久化与断点续跑，后者说明文件系统访问是按会话授权的，而不是全局开放。
移动端的设计也值得单独看。README 说通过二维码配对后，手机可以驱动这台桌面的完整工具集，或者手机独立运行。这是两种不同的部署形态：一种是远程控制，算力和文件访问仍在桌面；另一种是手机端自持。文档没有说明配对时的认证细节和传输加密方式，这一点在评估时应当归入待确认项。
Agent Skills 以 SKILL.md 形式存在，说明技能是可扩展的文本定义，而不是编译进二进制的固定能力。这给了用户一定的自定义空间，但具体加载规则、优先级和权限边界，README 没有展开。
安装：下载、密钥与那把「不需要密钥」的试用
安装路径是三条下载链接：Windows、macOS（分 Apple Silicon 与 Intel 两个包）、Linux，移动端走 Google Play 和 App Store。桌面端没有包管理器入口，没有 Homebrew formula，也没有 apt 源。对习惯了 `brew install` 的人来说，这意味着升级要靠应用自身的更新机制或手动重下。
模型接入分三层。第一层是 Skales IQ，README 称为免费内置试用，不需要 API 密钥，开箱即用。第二层是自带密钥，支持 15 家以上提供商。第三层是 Ollama，完全离线，不向任何服务付费。README 反复强调 your files never leave your machine，但这句话的适用范围需要区分：走内置试用或云端提供商时，模型推理发生在外部，只有走 Ollama 才是端到端的本地处理。文档没有逐条说明哪些数据会随请求发出，这是隐私声明里最需要追问的部分。
迁移路径被明确写出来了：Settings > Import from Another Tool，支持从 OpenClaw、Hermes Agent 或 ChatGPT 导入。这是一个降低切换成本的实用功能，但 README 没有说明导入的粒度，是只搬对话历史，还是连配置和技能一起搬。
配置项在 README 中只出现了这一个路径，其余设置散落在文档站 docs.skales.app，不在本仓库范围内。
真正的限制：不可审计、不可脚本化、不可自托管
第一条限制是源码不可读。BSL 1.1 是源码可得许可，但这里连源码都没给最新的，只有一份不维护的 v7 快照。对一个能读你日历和邮件的程序来说，安全审计只能依赖厂商的 SECURITY.md 和签名验证，无法自行验证行为。这在个人使用场景下或许可以接受，在受监管环境里基本不可行。
第二条限制是自动化能力的天花板。没有终端、没有 Docker、没有 CLI，意味着它很难嵌入现有流水线。你可以让它 `/goal` 去做一件事，但没法在 Jenkins 或 GitHub Actions 里调用它。它面向的是人和桌面的交互，不是机器和机器的编排。
第三条是平台绑定。桌面端是 Electron 形态的原生应用，移动端是 React Native，两者都依赖官方分发的构建产物。没有自托管服务端选项，没有私有化部署路径。如果你的组织要求数据不出内网，唯一可行的是 Ollama 那条路，而且仍然要接受桌面应用的闭源属性。
第四条是发布节奏带来的维护压力。从变更日志看，v12.9.21 到 v12.9.26 之间隔了不到一周，版本号带代号（Cockpit 2.0、Backbone、Grip）。高频迭代对用户是好事，但也意味着界面和配置项可能频繁变动，任何基于当前版本的内部文档都会很快过时。
和 OpenClaw 之类的可编程智能体比，差在哪
README 主动点名了 OpenClaw、Hermes Agent 和 ChatGPT 作为迁移来源，等于承认了这三者是用户会拿来比较的对象。差别不在模型能力，而在控制权的位置。
以 OpenClaw 这类开源、可自行部署的智能体框架为例，典型形态是你在自己的机器或服务器上跑一个服务进程，通过配置文件定义工具、权限和触发条件，再用命令行或 API 调用它。你能读到每一行代码，能改工具实现，能把它接进 cron 或 CI。代价是你得自己装依赖、管进程、处理升级，出问题时也没有官方支持。
Skales 把这条路径反过来：它替你做完所有工程决策，换来双击即用。你得到的是图形界面、二维码配对、像素皮肤和桌面宠物，失去的是可组合性。两者不是同一类工具，谈不上谁替代谁。真正需要判断的是你自己的场景：如果任务是「帮我把下载文件夹里的发票整理进表格」，Skales 的形态更合适；如果任务是「每天凌晨从三个 API 拉数据、跑模型、写回数据库」，你需要的是能写进调度器的东西，Skales 不是。
值得注意的是，README 里那段来自社区贡献者的推荐语用词相当夸张，说在这个领域里没找到其他能做到的。这类引用属于社区评价，不构成技术论据，读的时候跳过即可。
许可与维护成本：BSL 1.1 意味着什么
仓库的 License 字段显示为 NOASSERTION，README 和徽章则明确写 BSL 1.1。两者不一致，通常是因为 GitHub 无法自动识别 BSL 1.1 的文本，所以标成未断言。以 README 为准，许可标识是 BSL 1.1。
BSL 1.1 的通用结构是：源码可得，在许可方规定的附加使用限制生效前，允许非生产性使用；限制期结束后转为开源许可。README 只说 free for personal use，没有给出附加使用限制的具体条款，也没有说明变更日期。这意味着商用是否被允许、在什么条件下被允许，从这份材料里无法确认。任何打算在公司环境里部署的人，都需要先去 skales.app 或仓库的 LICENSE 文件确认原文。本文不构成法律意见。
维护成本方面，材料支持的信息有限。可以确定的是：桌面端没有包管理器通道，升级依赖应用内机制；版本迭代频繁，一周内可见多个带代号的发布；仓库里的源码不参与构建，所以对仓库提 PR 不会影响产品行为，能贡献的只有 issue 和讨论。移动端走应用商店，更新节奏受商店审核约束。
至于长期支持策略、向后兼容承诺和弃用政策，README 和变更日志摘要里都没有提及。这是采用前应当直接向项目方确认的问题。
编辑结论
Skales 适合想要本地文件访问、又不想碰 Docker 和命令行的个人用户，以及需要把手机当作远程入口驱动桌面工具链的人。不适合需要审计源码、需要自托管服务端或需要可编程 API 的团队，因为仓库里的 TypeScript 只是冻结的 v7 快照，不参与构建。采用前先确认三件事：你所在组织对 BSL 1.1 的商用条款是否接受，你的数据是否必须完全离线（若是则必须走 Ollama 而非内置试用），以及从 OpenClaw、Hermes Agent 或 ChatGPT 迁移时导入器能覆盖多少历史数据。
社区笔记