📌 项目地址：holaboss-ai/holaOS | ⭐ 6,416 颗星 | 🔧 TypeScript | 📜 未标注
同时用 Claude Code 和 Codex 的人，大概率遇到过这种场景：Claude Code 写到一半的代码，切到 Codex 继续改，得从头交代项目背景、当前进度、改过哪些文件。每个工具各记各的，切换一次丢一次上下文。
holaOS 的做法是把这个问题的根源处理掉：多个 Agent 跑在同一个本地工作区里，共用同一份记忆、工具和技能。这个项目在 GitHub 上拿了 6416 个 star，TypeScript 写的。它不是又一个 Agent，而是让已有 Agent 共享环境的底座。
多 Agent 并排跑，上下文在工作区里，不在 Agent 脑子里
holaOS 的工作区可以同时运行 Claude Code、Codex 和内置的 holaOS agent。选哪个干哪件事由你定，但不管哪个在干活，它读到的都是同一个项目状态。
需要讲清楚的是：这跟”支持多 Agent”是两回事。支持多 Agent 的工具很多，但多半是各跑各的，上下文不互通。holaOS 的关键在共享——同一个文件结构、同一套 MCP server 配置、同一份技能定义。习惯用 Claude Code 写业务逻辑，用 Codex 做重构，以前每次切换都要重新描述一遍的工程背景，现在存在工作区里，谁跑都能直接读到。
这背后有一个架构判断：Agent 之间不直接对话，它们通过文件系统交换状态。A 改了文件，B 接手时看到的已经是改完的样子。用 README 的话说是 “No lock-in”——你带自己信任的 Agent 进来，它不做替换。
记忆是本地普通文件，不是私有格式
holaOS 的上下文、偏好、项目历史全存在本地，形式是普通文件，可以直接读、直接改。
这个设计对开发者来说是个实打实的优势。其他工具的记忆往往封装在私有格式里，你看不到它记了什么、怎么记的。holaOS 给你一个透明的存储器，想知道 Agent 记了哪些项目上下文，打开文件看就行。README 里写得很直白：”stored locally, as plain files you can read and edit”。
记忆不是简单堆聊天记录，而是结构化加向量化地存。结构化保证了按目录和字段能查出来，向量化做语义检索——下次需要某段上下文时，不是翻历史聊天记录，而是把相关的项目状态直接调出来。
还有个容易忽略的点：既然是纯文本文件，就可以交给 git。Agent 的记忆可以 diff、可以 review、可以回滚。这对团队协作很重要，相当于整个团队的 Agent 共享一份可审计的、人类可读的状态文件。
模型两条路：内置用，还是带自己的 Key
模型接入分两种模式。
第一种是开箱即用：注册一个账号，内置了一批前沿模型。日常高频任务用成本更低的 Kimi K3 和 GLM 5.2，复杂任务用 GPT 5.6、Claude Opus 5、Fable 5。不用配置任何 API key，也不用管供应商账号。
第二种是 BYOK（Bring Your Own Key）：你有 OpenAI 或 Anthropic 的账号，就用自己的 key。流量走你自己的渠道，价格也按你的供应商合约来算。同时也兼容 OpenAI 和 Anthropic 协议的端点，意味着可以接自定义的内部服务。
两种模式可以混着用：日常任务走内置，涉及敏感数据的特定任务走自己的 key。README 的说法是 “Right model per task”——按任务选模型，而不是被某个单一供应商锁死。
HolaApps：Agent 在真实界面里干活，你在旁边看着
HolaApps 是 holaOS 里最有辨识度的设计。
工作区里有一个应用市场，安装后的应用会以真实 UI 的形式打开，跟 Agent 并排显示。Agent 直接在应用里操作，你在旁边实时看着，随时能插手。它不是告诉你”我帮你改了文档”，而是直接在 Notion 界面里操作给你看。改的过程可见，出问题你中途就能接管。
用 README 的话说：”the actual app, driven by the agent, next to the agent”。
这个设计比”Agent 调用 API 改数据”多了一层可观察性。API 调用是黑盒，你只知道结果；HolaApps 把过程摊开在你面前。对于需要信任 Agent 去操作真实系统的场景，可见性是建立信任的前提。
不限于官方市场的应用。你可以把任意 URL 加一个 MCP server 配成自己的 HolaApp。公司内部系统也能以这种形式接进来，应用本身存在本地，数据不出你的机器。
Skills 和 MCP：配一次，所有 Agent 通用
你在 holaOS 里给一个 Agent 配好的技能和集成，其他 Agent 也会。README 提到了 Gmail 等一批集成，支持 MCP 服务器。避免为每个 Agent 单独配一遍工具链，这是多 Agent 协作里最容易被忽略的效率点。
几个值得注意的问题
项目还在早期阶段，几点观察：
- README 没有写 License。拿到公司生产环境之前，建议先问清楚授权条款。
- 没有找到安装命令。Quick Start 和完整文档在官网，实际部署需要去 docs 里自己走一遍流程。
- 模型的 BYOK 模式和内置模式在数据走向上是两回事。对数据路径有严格要求的环境，需要自己确认两种模式各自的数据流向。
我的判断是：如果你被”多 Agent 之间频繁丢失上下文”这件事折磨过，holaOS 的思路值得试。它让 Claude Code 和 Codex 这类工具共享同一份记忆，目前市面上做到这一点的产品不多。但正式用到团队协作里，可以等它再成熟一些。