Anyquery：把 60 多个 SaaS 塞进 SQLite，再用 MCP 交给 LLM
One SQL interface for 60+ tools (e.g., GitHub, Notion, Airtable). Plug into any LLM through MCP.
秒懂
- 它是什么？
- Anyquery 用 SQLite 的虚拟表机制给 Notion、GitHub、Airtable 这类外部数据套上一层 SQL 外壳，同时提供 MCP 服务端和 MySQL 协议入口。它解决的是「数据在别人那里，但我想用 SQL 查」的问题，代价是插件质量与凭据管理都由你自己承担。
- 适合谁用？
- Anyquery 适合手上有一堆互不相通的 SaaS 账号、又习惯用 SQL 做临时分析的人，也适合想让 LLM 通过 MCP 读取本地与云端数据、但不想为每个服务单独写连接器的团队。它不适合要求强事务一致性、需要跨源 JOIN 大规模数据、或对许可证合规有硬性审查流程的场景：仓库的 License 字段显示为 NOASSERTION，GitHub 无法自动识别具体条款，采用前应当直接查看仓库根目录的许可证文件确认授权范围。
- 能商用吗？
- 请先确认。这个仓库使用的许可证不在我们自动归类的范围内，商用前请阅读仓库里的 LICENSE 文件。
- 还在维护吗？
- 在维护。仓库最近一次提交在 31 天前。
- 用什么语言写的？
- 主要是 Go（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它真正要解决的问题：数据在别人的 API 后面
大部分工程团队的数据分析困境不是没有工具，而是数据散在几十个 SaaS 里，每个都有独立的 REST API、分页规则、速率限制和认证方式。想回答「上个月 Notion 里标记为阻塞的任务，有多少对应 GitHub 上未关闭的 issue」，通常要写两段脚本、处理两次分页、再在内存里做关联。Anyquery 的思路是把这些 API 包装成 SQLite 虚拟表，让 SQL 的 JOIN、WHERE、GROUP BY 直接作用在上面。目标用户不是数据仓库团队，而是会用 SQL 但不想为每个 SaaS 写连接器的开发者、做业务分析的产品人员，以及想给 LLM 提供结构化数据入口的人。README 把它描述为「一个 SQL 查询引擎，可以对几乎任何东西运行 SQL 查询」，覆盖文件、数据库和应用三类数据源。
架构：SQLite 虚拟表加插件，而不是自建查询引擎
Anyquery 建立在 SQLite 之上，用插件扩展能力，这一点决定了它的全部行为特征。插件通过 SQLite 的虚拟表接口注册成表，SQL 语句被 SQLite 解析后，由虚拟表实现负责把查询条件下推成对外部 API 的调用。这意味着 JOIN 的语义由 SQLite 决定，而不是由远端服务决定。文档提到 Anyquery 也能加载任意 SQLite 扩展，所以它同时接受两种扩展形态：自有的 Anyquery 插件，以及现成的 SQLite 扩展。数据流大致是：客户端（shell、MySQL 客户端或 LLM）发出 SQL，SQLite 解析并规划，虚拟表把过滤条件下推、调用外部 API、把返回的 JSON 转成行，再交回 SQLite 做聚合与连接。这个设计的好处是复用 SQLite 成熟的查询能力，坏处是跨源 JOIN 的实际执行位置在本地进程，远端数据要先落到本地才能参与连接。
三种接入方式：shell、MySQL 协议、MCP
Anyquery 对外暴露三种入口，面向三类不同的调用方。第一种是交互式 shell，README 说明在终端直接输入 anyquery 即可进入 shell 模式执行查询。第二种是 MySQL 服务端，用 anyquery server 启动，然后照 README 给出的示例连接：mysql -u root -h 127.0.0.1 -P 8070。注意端口是 8070，不是 MySQL 默认的 3306，任何 MySQL 兼容客户端（文档提到 TablePlus、Metabase）都可以接上来，这样 BI 工具不需要知道 Anyquery 的存在。第三种是 MCP，面向 LLM：anyquery mcp --stdio 由 LLM 客户端启动子进程，anyquery mcp --host 127.0.0.1 --port 8070 则通过 HTTP 和 SSE 暴露。对不支持 MCP 但支持 function calling 的客户端，README 给出 anyquery gpt 命令，它返回一个 ID，粘贴到 ChatGPT 或 TypingMind 这类客户端里完成绑定。三条路径共用同一套插件和查询引擎，差别只在传输层。
安装路径很多，但 Go 构建这条路有硬门槛
官方给出的安装方式覆盖面很广：macOS 和 Linux 上可以跑 curl -fsSL https://anyquery.dev/install.sh | sh，README 说这个脚本会下载对应平台的二进制、校验 checksum、加入 PATH，并且不需要 sudo；也可以用 brew install anyquery；Arch 用户走 AUR 的 anyquery-git；APT 需要先写入源 echo "deb [trusted=yes] https://apt.julienc.me/ /" | sudo tee /etc/apt/sources.list.d/anyquery.list；YUM/DNF 的 repo 文件里 gpgcheck=0；Windows 侧有 Scoop、Winget 和 Chocolatey 三条路。如果从源码构建，README 给的是 CGO_ENABLED=1 go install -tags "vtable fts5 sqlite_json sqlite_math_functions" github.com/julien040/anyquery@main，并明确要求 Go 1.26+，理由是部分依赖不支持更老的版本。同时因为底层走 go-sqlite3，需要 cgo，也就需要 PATH 里有 gcc、clang 或 Windows 上的 mingw 工具链。对纯 Go 环境来说这是一个真实门槛：交叉编译会变得麻烦，CI 里也要额外准备 C 编译器。安装脚本支持用 ANYQUERY_VERSION 固定版本、用 ANYQUERY_INSTALL_DIR 改安装目录，更新方式是重跑同一条命令。
插件是它的全部价值，也是它的全部风险
Anyquery 本身只是一层壳，能查什么完全取决于装了哪些插件。插件可以来自官方注册表，也可以自己写，README 明确说「Anyquery 是插件化的」。这里有几个需要提前想清楚的问题。第一，插件要访问外部服务，就必须持有凭据，凭据存放在哪里、以什么形式保存、是否加密，README 没有说明，采用前应当去文档的插件章节确认。第二，每个插件对外部 API 的映射质量直接决定查询体验：哪些过滤条件能真正下推到远端、分页怎么处理、速率限制触顶后是报错还是重试，这些都不由 SQLite 决定，而由插件作者决定。第三，任何插件更新都可能改变表的列名或语义，SQL 查询会跟着失效。仓库最近的发布记录里有 0.4.5、0.4.6 两次以「Security fix」为标题的版本，以及 0.5.0 的「Sandbox strengthening」，说明插件执行与沙箱隔离是这个项目持续在修补的区域。这本身不是缺点，但意味着把 Anyquery 放进生产链路时，版本升级需要验证。
什么时候它是对的，什么时候它是错的工具
Anyquery 的强项是临时性的、跨源的、以读为主的分析查询，尤其是那种「只跑一次、不值得为它建管道」的需求。它不适合的场景同样明确。需要事务一致性的写入操作不要指望它：底层是 SQLite，外部服务也不是事务性数据源，跨源写入无法保证原子性。数据量大的连接也不合适：如果两个源各有百万行，条件又无法下推到远端，数据会先被拉到本地进程再参与 JOIN，内存和网络都会成为瓶颈。对延迟敏感的服务端接口同样不合适，因为每次查询都可能触发一次外部 API 调用，响应时间取决于对方。另外，把 Anyquery 的 MySQL 服务端直接暴露到公网是不必要的风险，README 的示例绑定在 127.0.0.1，这个默认值应当保留。
和 Steampipe 的差别：SQLite 与 PostgreSQL 的分叉
同类工具里最直接的对标是 Steampipe，它同样把云服务和 SaaS 暴露成 SQL 表，但走的是另一条技术路线：Steampipe 基于 PostgreSQL 外部数据包装器（FDW），插件是 Postgres 扩展，查询在 PostgreSQL 进程内执行。Anyquery 选择 SQLite 虚拟表，带来的差别是实打实的。部署上，Anyquery 是单个二进制，装完就能跑，不需要维护一个 PostgreSQL 实例；Steampipe 需要拉起 Postgres，资源占用和运维复杂度都更高。查询能力上，PostgreSQL 的优化器、窗口函数、CTE 和并行查询比 SQLite 丰富，复杂分析 SQL 在 Steampipe 上更容易写。扩展生态上，Steampipe 的插件以 Go SDK 编写并编译进 Postgres 扩展体系，Anyquery 的插件既可以是自有格式，也可以直接加载现成 SQLite 扩展，后者让它可以复用 SQLite 社区已有的扩展。选哪个取决于你更在意「零运维的单文件工具」还是「完整的 PostgreSQL 分析能力」，以及你现有的 BI 客户端更习惯连哪种协议。
维护成本与许可证：两件需要自己确认的事
维护成本主要来自插件而不是核心。核心是单个二进制，更新方式在 README 里写得很直白：重跑安装脚本即可，Homebrew 和包管理器用户走各自的升级命令。但插件来自注册表，版本节奏与核心不同步，升级核心后应当逐个验证关键插件的查询是否仍然可用。仓库的发布节奏可以参考：0.4.5 在 2026-06-09，0.4.6 在 2026-07-03，0.5.0 在 2026-08-05，最近一次 push 在 2026-08-16，属于活跃维护状态，但版本号仍停留在 0.5.x，API 与插件接口都还没有进入稳定期。许可证方面，GitHub 的 License 字段显示为 NOASSERTION，意思是平台无法自动匹配到已知许可证模板。这不等于没有许可证，也不等于许可证有问题，只说明需要人工确认。如果要把 Anyquery 嵌进商业产品分发，或者用在需要过合规审查的环境里，应当直接查看仓库根目录的 LICENSE 文件，必要时咨询法务，不要依赖 GitHub 的自动识别结果。
编辑结论
Anyquery 适合手上有一堆互不相通的 SaaS 账号、又习惯用 SQL 做临时分析的人，也适合想让 LLM 通过 MCP 读取本地与云端数据、但不想为每个服务单独写连接器的团队。它不适合要求强事务一致性、需要跨源 JOIN 大规模数据、或对许可证合规有硬性审查流程的场景：仓库的 License 字段显示为 NOASSERTION，GitHub 无法自动识别具体条款，采用前应当直接查看仓库根目录的许可证文件确认授权范围。上手第一步建议先跑 curl -fsSL https://anyquery.dev/install.sh | sh 安装，再用 anyquery mcp --stdio 验证 MCP 通道，最后才装业务插件。
社区笔记