mayneyao/eidos 是什么？

Eidos 用单一 .eidos 文件封装 SQLite 数据库，配合桌面端、浏览器端和 CLI，让个人与 AI 代理都能直接操作关系数据。本文基于仓库文档分析它的架构、用法和适用边界。

mayneyao/eidos 可以商用吗？

可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。

mayneyao/eidos 还在维护吗？

在维护。仓库最近一次提交在 1 天前。

mayneyao/eidos 是用什么编程语言写的？

主要是 TypeScript（依据 GitHub 的语言统计）。

Eidos 评测：单文件 SQLite 关系表格，面向个人与 AI 代理

Q: mayneyao/eidos 还在维护吗？

在维护。仓库最近一次提交在 1 天前。

秒懂

它是什么？: Eidos 用单一 .eidos 文件封装 SQLite 数据库，配合桌面端、浏览器端和 CLI，让个人与 AI 代理都能直接操作关系数据。本文基于仓库文档分析它的架构、用法和适用边界。
适合谁用？: Eidos 适合需要把结构化数据、Markdown 笔记和 AI 代理工作流放进同一个本地文件的个人用户，尤其是熟悉 SQL 或愿意学习 SQL 的 Notion 替代品追求者。不适合需要多人实时协作、细粒度权限或深度移动端支持的用户，因为仓库没有显示这些能力。
能商用吗？: 可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。
还在维护吗？: 在维护。仓库最近一次提交在 1 天前。
用什么语言写的？: 主要是 TypeScript（依据 GitHub 的语言统计）。

以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。

开源项目深度解析

Hysen Labs 编辑部 · 2026年9月10日 · mayneyao/eidos

它解决什么问题，为谁而做

Eidos 想解决的问题很具体：个人数据散落在电子表格、笔记应用和数据库之间，而这三者各有缺陷。电子表格擅长二维视图，但难以表达关系；笔记应用灵活，但查询能力弱；数据库强大，却要求服务器和导入导出流程。Eidos 把三者压进一个 .eidos 文件，这个文件本质是标准 SQLite 数据库。README 明确说 Eidos File 是建立在 SQLite 上的开放单文件格式。它的目标用户有两类：一是不想被云服务绑定的个人知识管理者，二是需要以编程方式操作数据的 AI 代理。后者从 CLI 的存在可以看出来，README 将 CLI 描述为 agent-first，也就是为代理优先设计的命令行工具。

单文件格式与运行时：核心机制

Eidos 的架构从仓库目录能看出层次。packages/eidos-file 实现了文件格式和 Runtime，这是核心。packages/eidos-file-ui 提供共享的 React 编辑器界面，而 apps/eidos-lite-desktop 是桌面应用外壳。关键设计在于 Markdown 包：packages/markdown 基于 Lexical 实现所见即所得编辑，但 README 强调 Markdown 仍然是规范值，导入、编辑、序列化和保真检查都由这个包负责，宿主只负责持久化和附件存储。这意味着你编辑的每个字段，底层可能存成 Markdown 文本，SQLite 只是容器。这种设计让数据保持可读，不依赖特定编辑器。Runtime 的概念值得注意，它暗示 .eidos 文件不只是静态数据，还包含执行逻辑的层，具体如何工作，仓库只给了目录结构，没有深入说明。

三种运行方式：桌面、浏览器与 CLI

Eidos 提供三条使用路径。桌面端下载 Eidos Lite，本地使用不需要账户，这符合 local-first 的定位。浏览器端 editor.eidos.space 允许不安装任何软件就创建或编辑本地 .eidos 文件，注意是本地文件，不是云存储。CLI 是面向自动化的入口，安装命令因系统而异，macOS 和 Linux 用 curl 管道到 sh，Windows 用 PowerShell 的 irm 到 iex。创建文件的命令很直观：eidos create example.eidos 可以指定表名、标签字段和字段列表，字段类型包括 text 和 select。然后 eidos serve example.eidos --open 会在本地打开文件。这套命令适合脚本调用，但 README 没有展示更新或查询的具体语法，只指向 apps/cli 目录下的详细指南。

本地优先的版本历史：Graft 的作用

Eidos Lite 依赖一个独立项目 Graft 来实现本地版本历史和可选同步。README 把 Graft 描述为面向应用状态的开发者级版本控制系统。这意味着 .eidos 文件的每次修改都可能被追踪，类似 Git 但针对应用数据。这个选择有代价：Graft 是独立项目，它的成熟度和 API 稳定性决定了 Eidos 的可靠性。仓库没有提供 Graft 的实现细节，也没有说明同步冲突如何处理。如果你需要多人协作或跨设备一致同步，这部分信息缺失是个风险。本地优先的好处是离线可用和隐私控制，但同步从来是难点，Eidos 把这个问题外包给 Graft，用户需要额外评估这个依赖。

开发与测试：真实的技术栈

仓库的开发要求明确列出：Node.js 22.23.1、Corepack 和 Rust stable。前端用 pnpm 管理，测试命令包括 pnpm test:eidos-file 和 pnpm test:markdown-editor。CLI 是独立的 Rust workspace，测试用 cargo test --workspace --locked。这种前后端分离的工程结构说明 Eidos 不是玩具项目，而是有一定规模的多包仓库。但注意，README 没有给出任何覆盖率数字或 CI 状态，所以无法判断测试的深度。Rust CLI 的选择意味着安装包是编译好的二进制，性能应该不错，但用户无法像纯 Node 工具那样轻松审计源代码。

许可证的双轨制与限制

仓库整体采用 AGPL-3.0，这是强 copyleft 许可证，对网络服务也有传染性。但可复用的两个包 @eidos.space/eidos-file 和 @eidos.space/eidos-file-ui 单独以 MIT 发布。这种双轨制对开发者友好，你可以把核心文件格式库用在闭源项目中，但如果你修改桌面应用或 CLI 本身，就得开源。对普通用户没有影响，因为本地使用不涉及分发。对想基于 Eidos 做商业产品的团队，这是个关键分界点：请先确认你修改的是哪个层。另一个限制是单文件 SQLite 的天然边界：并发写入和超大数据库不是它的强项，适合个人数据量，不适合团队级 OLTP。

替代方案与真正的差异

Eidos 的替代品不是 Notion 或 Airtable，而是 Obsidian 加插件、或直接用 SQLite 加一个前端。Obsidian 也基于本地 Markdown 文件，但没有内建关系字段和 SQL 查询能力，它的社区插件可以模拟，但那是拼凑。直接使用 SQLite 加 Datasette 这类工具，你能获得完全的关系查询，但失去 Eidos 提供的表格编辑界面和 Markdown 编辑体验。Eidos 的差异在于把三者整合进一个文件：SQLite 存储、Markdown 作为规范文本、Lexical 编辑器处理显示。另一个值得提的替代是 NocoDB，它提供类似 Airtable 的界面，但它是 Web 应用，需要服务器运行，不是本地单文件。Eidos 的本地优先和单文件特性在个人工具场景里有独特位置，但如果你需要团队共享，NocoDB 这类客户端服务器架构反而更合适。

编辑结论

Eidos 适合需要把结构化数据、Markdown 笔记和 AI 代理工作流放进同一个本地文件的个人用户，尤其是熟悉 SQL 或愿意学习 SQL 的 Notion 替代品追求者。不适合需要多人实时协作、细粒度权限或深度移动端支持的用户，因为仓库没有显示这些能力。采用前请先验证三件事：一是你的数据量是否适合单文件 SQLite，二是 AGPL 对应用层的传染性是否影响你的分发方式，三是 CLI 目前只覆盖创建、查询、更新和服务操作，复杂迁移或同步需要依赖 Graft 的成熟度。最终判断：Eidos 的文件格式设计有清晰的技术方向，但它的价值取决于 Graft 和编辑器生态的持续演进，当前更适合技术用户尝鲜而非关键业务依赖。

官方来源

社区笔记