Anyquery：用 SQL 查 Notion、GitHub 與本機檔案，再把結果餵給 LLM
One SQL interface for 60+ tools (e.g., GitHub, Notion, Airtable). Plug into any LLM through MCP.
秒懂
- 它是什麼？
- Anyquery 是一套以 SQLite 為底的查詢引擎，透過外掛把 60 多種工具與檔案格式轉成資料表，並可用 MCP 讓 LLM 直接查詢。它的價值在於把散落的 API 收斂成一種查詢語言，代價是你得接受外掛品質與 SQLite 的邊界。
- 適合誰用？
- 如果你已經熟悉 SQL，而且需要把多個 SaaS 或本機檔案拼進同一條查詢，Anyquery 值得先在一台機器上裝起來，用 anyquery mcp --stdio 接上你慣用的 LLM 客戶端，實際跑幾條涉及外掛的查詢再決定。若你的情境是低延遲的線上服務、需要嚴格一致性交易，或團隊不願意維護外掛與 cgo 工具鏈，它就不是合適的選擇。
- 可以商用嗎？
- 請先確認。這個儲存庫使用的授權不在我們自動分類的範圍內，商用前請閱讀儲存庫中的 LICENSE 檔案。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 31 天前。
- 用什麼語言寫的？
- 主要是 Go（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要解決的是資料來源太雜，而不是查詢太慢
多數團隊的資料並不是不存在，而是散在幾十個地方：Notion 裡的專案頁面、GitHub 上的 issue、Airtable 的表、本機的 CSV 與 Parquet、還有 Chrome 或 Apple Notes 這類桌面應用。要把它們放在一起看，通常得先寫 ETL，或分別呼叫各家 API 再在程式裡合併。Anyquery 的做法是換一個切入點：不去搬資料，而是把每個來源包成 SQLite 的虛擬表，讓你在同一條 SQL 裡 JOIN。README 對自己的定位是「a SQL query engine that allows you to run SQL queries on pretty much anything」，並明講它建構在 SQLite 之上、靠外掛擴充。
目標讀者其實相當明確：已經會寫 SQL、不想再學一套新 DSL 的工程師或資料分析者。這個選擇有實際好處，SQL 是少數跨職能都看得懂的查詢語言，分析師寫的查詢可以直接交給 LLM 或 BI 工具執行。反過來說，如果你的團隊沒有人熟悉 SQL，Anyquery 反而多了一層學習成本，不如直接用各服務的原生介面。
SQLite 虛擬表加上外掛註冊表，就是它的全部架構
Anyquery 的機制可以拆成三層。底層是 SQLite，負責查詢解析、執行計畫與結果輸出；中間是外掛層，每個外掛把一個外部來源映射成一張或多張虛擬表；上層則是三種對外介面：互動式 shell、MySQL 協定伺服器，以及 MCP 伺服器。
外掛的來源有兩條路。第一條是官方 registry，README 的 badge 直接指向 registry.anyquery.dev，並標示外掛數量與查詢範例數量，安裝與瀏覽都透過 https://anyquery.dev/integrations。第二條是載入既有的 SQLite 擴充，文件路徑為 /docs/usage/plugins#using-sqlite-extensions。第二條路值得留意：它意味著 Anyquery 不必自己重造所有連接器，SQLite 生態裡既有的擴充有機會直接沿用。
資料流本身是拉取式的。你寫一條 SELECT，SQLite 把條件推給虛擬表，外掛再去呼叫對應的 API 或讀取檔案，把結果以列的形式回傳。這裡沒有常駐的同步程序，也沒有本地快取層的描述，所以每次查詢基本上就是一次外部呼叫。這一點決定了它的效能特徵，也決定了它適合的場景。
安裝路徑很多，但 Go 安裝那條要先過 cgo 這一關
官方提供多種安裝方式。macOS 與 Linux 上最快的是安裝腳本，README 說明它會下載對應平台的二進位檔、驗證 checksum 並加進 PATH，且不需要 sudo：
curl -fsSL https://anyquery.dev/install.sh | sh
要固定版本或改安裝位置，設定 ANYQUERY_VERSION（例如 0.4.5）或 ANYQUERY_INSTALL_DIR，之後更新就是重跑同一條指令。Windows 上走 Scoop、Winget 或 Chocolatey，例如 winget install JulienCagniart.anyquery。套件管理器另有 Homebrew 的 brew install anyquery、AUR 的 yay -S anyquery-git、APT 與 YUM/DNF 的自家倉庫設定。
從原始碼安裝則需要留意工具鏈。README 寫明需要 Go 1.26+，並要求 CGO_ENABLED=1，因為它透過 go-sqlite3 依賴 cgo，PATH 裡必須有 C 編譯器：
CGO_ENABLED=1 go install -tags "vtable fts5 sqlite_json sqlite_math_functions" github.com/julien040/anyquery@main
那串 build tags 不是裝飾，vtable 對應虛擬表機制，fts5 是全文檢索，少了它們建出來的二進位檔功能會不完整。這也是評估成本的一部分：純 Go 專案可以交叉編譯出單一靜態檔，Anyquery 因為 cgo 而做不到，CI 與容器映像都得準備對應的 C 工具鏈。
接 LLM 用 MCP，接 BI 工具用 MySQL 協定
對 LLM 的整合走 Model Context Protocol。README 給的啟動方式有兩種，一種由 LLM 客戶端自行啟動，一種走 HTTP 與 SSE 通道：
anyquery mcp --stdio anyquery mcp --host 127.0.0.1 --port 8070
不支援 MCP 但支援 function calling 的客戶端（README 舉 ChatGPT、TypingMind 為例）則走另一條路：執行 anyquery gpt，指令會回傳一個 ID，把它貼進客戶端即可。文件另外在 /integrations#llm 底下為各家客戶端提供連接指南，數量與涵蓋範圍我無法從現有材料確認。
另一條介面是 MySQL 協定。anyquery server 會在本機起一個 MySQL 相容的伺服器，README 的範例是：
anyquery server & mysql -u root -h 127.0.0.1 -P 8070
同一個埠號 8070 同時出現在 MCP 的 HTTP 模式與 MySQL 伺服器範例中，這點值得在實際部署前自己確認，因為兩者若同時啟動可能衝突。這個設計的好處是相容性極廣，TablePlus、Metabase 這類既有工具不用改任何程式就能接上，對已經有 BI 堆疊的團隊來說，導入成本比接 MCP 更低。
拉取式查詢的代價：沒有快取，也沒有交易
README 全篇沒有提到快取、增量同步或本地落地。這代表每條查詢大致上就是一次對來源的即時呼叫。對 Notion 或 GitHub 這類有速率限制的服務，一個沒寫好 WHERE 條件的 JOIN 可能直接吃掉當日額度，而且錯誤會以查詢失敗的形式出現，而不是在同步階段被攔下來。這是使用上最需要事先設計的地方：把過濾條件盡量下推，避免全表掃描式的探索性查詢。
另一個限制來自 SQLite 本身。它是嵌入式資料庫，不是 OLAP 引擎，跨多個遠端來源的 JOIN 沒有查詢優化器能替你把資料搬移成本降到最低，中間結果的規模決定了記憶體與時間。要拿它做跨服務的大型聚合分析，會撞到這面牆。
授權狀態也需要明講：GitHub 上標示為 NOASSERTION，意思是倉庫沒有採用可被自動識別的標準授權條款。這不等於沒有授權，但意味著你不能靠 SPDX 標籤判斷，必須自行閱讀倉庫內的授權檔案，並由你們的法務或合規流程認定。把 Anyquery 嵌進商業產品散布之前，這一步不能省。
與 Steampipe 的差別在於外掛從哪裡來
同類工具裡最直接的對照是 Steampipe。兩者都把外部 API 包成 SQL 資料表，都讓你用 SELECT 查雲端資源與 SaaS，但路線不同。Steampipe 以 PostgreSQL 為底，外掛集中在其官方 hub，並以關聯式資料庫的完整能力（包括較成熟的 JOIN 優化與並行）為賣點，代價是執行時較重，通常以服務形式常駐。
Anyquery 選 SQLite，好處是單一執行檔、啟動快、可以嵌進桌面情境，也能載入既有的 SQLite 擴充，等於借用整個 SQLite 生態。代價是它繼承了 SQLite 的限制：沒有真正的並行寫入、沒有查詢優化器替你處理跨來源的資料搬移。
選擇的關鍵在問題型態。如果你的查詢是「把 Notion 的專案清單和 GitHub issue 對起來，輸出成一份報表」，Anyquery 的輕量與 MCP 整合更順手。如果是「每天掃描數十個雲端帳號的組態並持續監控」，Steampipe 那套以 PostgreSQL 為核心、外掛集中管理的模型更合適。這不是誰取代誰，而是兩種執行模型對應兩種使用頻率。
版本節奏與維護成本要看 release 標題
近期的版本號透露了一些訊息。0.4.5 標題是 Security fixes，0.4.6 是 Security fix again，0.5.0 是 Sandbox strengthening。三個版本裡有兩個直接與安全修補相關，最新一版則把沙箱強化當成主要變更。對於一個會持有各服務 API 憑證、又能被 LLM 呼叫的工具來說，這個方向是合理的，但也說明攻擊面確實存在：外掛執行的程式碼、MCP 通道、以及 LLM 產生的查詢語句，三者疊在一起。
升級成本方面，安裝腳本的路徑只要重跑同一條指令即可，套件管理器則走各自的 upgrade 流程；從原始碼安裝的人要注意 build tags 是否隨版本改變，以及 Go 版本要求（目前是 1.26+）是否跟著上調。由於沒有長期支援版本的說明，跟著最新版走、並在升級前讀 release notes 的標題與內容，是比較務實的做法。
外掛本身是另一個維護面。官方 registry 與社群外掛的更新節奏不會與主程式同步，某個整合的 API 變更可能只反映在外掛版本上。把外掛版本一併納入版本控管，會比只鎖主程式版本更安全。
編輯結論
如果你已經熟悉 SQL，而且需要把多個 SaaS 或本機檔案拼進同一條查詢，Anyquery 值得先在一台機器上裝起來，用 anyquery mcp --stdio 接上你慣用的 LLM 客戶端，實際跑幾條涉及外掛的查詢再決定。若你的情境是低延遲的線上服務、需要嚴格一致性交易，或團隊不願意維護外掛與 cgo 工具鏈，它就不是合適的選擇。動手前先確認三件事：你需要的整合是否在官方 registry 內、外掛對應的 API 額度與認證方式、以及 NOASSERTION 授權條款在你們的合規流程下如何認定。最後這點不是技術問題，但會決定你能不能把它放進正式環境。
社群筆記