holaOS 评测：把 Claude Code 和 Codex 装进同一个本地工作台
Open-source agentic workspace enterprises can make their own. Connect the systems you already run — 100+ integrations, MCP, chat tools, apps, browser, local files — with shared memory. Any agent (Claude Code, Codex), any model, or BYOK. Set up in clicks, not months. Local-first: your data never leaves your machines.
秒懂
- 它是什么？
- holaOS 是一个开源的企业级 agent 工作台，用 Electron 和 TypeScript 构建，主打本地优先。它把应用、聊天工具、MCP 服务器和共享内存拼在一起，让 Claude Code、Codex 或自带 agent 在同一界面里操作真实应用，而不是输出一堵聊天文本墙。
- 适合谁用？
- holaOS 适合那些已经依赖 Slack、飞书、钉钉或微信做决策，又希望 Claude Code 或 Codex 直接读取这些上下文的企业团队。它不适合只想要一个开箱即用、不关心数据流向的云端 agent 工具的个人用户，也不适合完全没有自托管基础设施的小团队。
- 能商用吗？
- 请先确认。这个仓库使用的许可证不在我们自动归类的范围内，商用前请阅读仓库里的 LICENSE 文件。
- 还在维护吗？
- 在维护。仓库最近一次提交在 25 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题：上下文散落在聊天、应用和文件里
企业里的决策经常不在文档里，而在 Slack 线程、飞书群、钉钉消息中。holaOS 的定位是让 agent 直接读取这些真实对话，而不是依赖用户事后总结。它同时把 Notion、浏览器、自建应用这些真实界面放在 agent 旁边，agent 操作的结果直接落在应用里，而不是生成一段文字描述。这个项目面向的是已经跑着多种 SaaS 工具、又想让多个 agent 共享同一套工具和记忆的团队。它不是一个聊天机器人框架，而是一个桌面工作台，Electron 打包，TypeScript 编写，支持 macOS（Apple Silicon 和 Intel）、Windows 和 Linux。
HolaApps 的机制：真实界面而非聊天记录
README 强调 HolaApps 是 live UI，不是 transcript。每个应用都对应一个真实的可交互表面，比如 Notion 或浏览器。用户可以从工作区内的 marketplace 一键安装，也可以指向任意 URL 和 MCP 服务器来创建自己的 HolaApp。关键在于双向上下文同步：用户手动点击、输入、打开的内容会变成 agent 已有的上下文，agent 操作时用户也能随时接手。这说明 holaOS 不是简单的屏幕录制加 LLM 调用，它需要维护应用状态与 agent 上下文之间的映射关系，这部分机制在 README 中没有展开，但可以推测它依赖 Electron 的渲染进程与主进程之间的通信通道。
IM 集成与权限边界：读取前需批准
holaOS 支持 Slack、飞书、钉钉、微信，连接哪些由用户自己选。权限按工具和范围授予，agent 在读取任何内容之前必须得到批准。这个设计与许多云端 agent 工具不同，后者通常一次性授权整个工作区。按范围授权意味着企业可以限制 agent 只能访问特定频道或群组，而不是整个租户。不过 README 没有说明这些权限是 OAuth scope 级别的，还是 holaOS 自己实现的过滤层。如果是后者，那么消息在到达 agent 之前会先经过 holaOS 的本地处理，这符合 local-first 的承诺，但具体实现细节需要查看源码才能确认。
模型与 agent 的多样性：BYOK 与内置模型的取舍
holaOS 内置了多个模型，包括成本导向的 Kimi K3、GLM 5.2，以及高端的 GPT 5.6、Claude Opus 5、Fable 5。用户也可以使用自己的 OpenAI 或 Anthropic key，或者任何兼容端点。README 声称这些 BYOK 请求运行在用户自己的账户上，不消耗 holaOS 套餐额度。同时，它支持 Claude Code、Codex 和内置 holaOS agent 在同一工作区运行，共享同一套记忆、工具和技能。这意味着企业可以针对不同任务选择不同的 agent，而不需要为每个 agent 单独配置集成。但这里有一个隐含的成本：维护多个 agent 的兼容层，因为 Claude Code 和 Codex 的 tool calling 格式不同，holaOS 需要把它们统一到自己的工具抽象上。
获取与运行：从 Quick Start 到实际部署
README 提供了 Quick Start 链接，指向 holaos.ai 的 getting-started 文档，但没有在仓库内给出具体安装命令。平台支持 macOS（Apple Silicon 和 Intel）、Windows 和 Linux，这暗示有对应平台的安装包。由于是 Electron 应用，安装后应该是一个桌面程序，而不是命令行工具。用户需要先创建账户（网站有 Sign in 入口），然后从 marketplace 安装应用和集成。对于开发者来说，仓库默认分支是 main，有 CI workflow（ci.yml），但没有说明如何从源码构建。如果你想自己编译，需要查看 docs 目录或 GitHub Actions 配置来推断构建步骤，但这部分在 README 中是缺失的。
真实局限：本地优先的代价与许可证风险
README 声称“你的数据永远不会离开你的机器”，但这对 IM 集成来说是个挑战。Slack 或飞书的消息需要先被拉取到本地才能被 agent 读取，这意味着本地存储会成为敏感对话的汇聚点。如果本地机器被攻破，数据泄露的范围可能比云端工具更大。另外，许可证标注为 Modified Apache 2.0，GitHub 显示为 NOASSERTION，这意味着它不是标准的 Apache 2.0，可能有额外限制。企业采用前必须仔细阅读 LICENSE 文件，确认修改了哪些条款，比如是否限制商业使用或要求开源衍生作品。这些信息在 README 中没有说明，属于需要自行核实的风险点。
替代方案与差异：ChatGPT 桌面版与自建 MCP 聚合器
一个直接的替代方案是使用 ChatGPT 桌面版或 Claude 桌面应用，它们也提供本地文件访问和 MCP 支持，但它们是单 agent 绑定的，不能同时运行 Claude Code 和 Codex。另一个方向是自建一个 MCP 聚合服务器，把所有工具统一暴露给任意 agent，再搭配一个浏览器扩展来捕获上下文。这个方案更灵活，但需要自己维护工具注册、权限控制和共享内存，而 holaOS 把这些做成了开箱即用的功能。差异在于：自建方案适合有专门平台团队的工程组织，holaOS 则适合业务团队直接采用，不需要写胶水代码。不过 holaOS 的共享内存是它独有的卖点，自建方案很难在短时间内复现同样的双向同步体验。
维护与升级成本：桌面应用的更新节奏
仓库显示最后推送是 2026 年 8 月，最新 release 是 2026 年 8 月 6 日，说明项目处于活跃状态。作为 Electron 应用，升级通常由用户手动触发或自动更新，但 README 没有说明更新机制。企业需要关注的是：每次升级是否可能破坏已有 HolaApp 或 MCP 服务器的兼容性，尤其是当内置模型或 agent 版本更新时。另外，本地优先意味着每个用户机器上都需要维护一份应用和配置，不像云端工具那样集中管理。对于超过几十人的团队，IT 部门需要评估如何分发更新和备份本地记忆数据。这些运维细节在文档中尚未提及，采用前应咨询项目维护者或查看 docs 目录。
编辑结论
holaOS 适合那些已经依赖 Slack、飞书、钉钉或微信做决策，又希望 Claude Code 或 Codex 直接读取这些上下文的企业团队。它不适合只想要一个开箱即用、不关心数据流向的云端 agent 工具的个人用户，也不适合完全没有自托管基础设施的小团队。采用前需要先核实三件事：Modified Apache 2.0 许可证的具体限制条款，因为 NOASSERTION 意味着你不能默认它等同于标准 Apache 2.0；本地优先的存储机制是否覆盖所有集成类型，尤其是 IM 工具的消息缓存；以及内置模型（如 Kimi K3、GLM 5.2）的计费方式是否与 BYOK 模式在同一账户下清晰分离。如果这些条件能满足，holaOS 的 side-by-side 应用界面和共享内存设计确实能减少 agent 与人工之间的上下文重述，这是它区别于普通聊天式 agent 工具的核心价值。
社区笔记