universal-lsp

一个仓库包含两个项目，它们一起构建，因为彼此需要：

Universal LSP —— 一个单一、快速、低内存的 C++ 语言服务器，通过 Lua 声明的插件 覆盖多种语言。每一个分析层级，包括语义分析，都在一个进程中原生运行。它从不派生、代理或依赖 rust-analyzer、pyright、clangd 或任何其他二进制或网络服务。为终端优先、代理驱动的世界而构建：面向编辑器的标准 stdio 上的 LSP，面向代理的 MCP 前端，以及面向 CI 的无头 批量查询 CLI。

graph-lite —— 缺失的 图数据库版 SQLite：一个体积小、零依赖、可嵌入的属性图库，任何项目都可以通过单个头文件引入。其公共接口是 C ABI，因此 Ruby、JavaScript、Python、Rust、Go 和 C 可以通过各自的 FFI 嵌入它，无需维护任何包装层——这正是 SQLite 获得广泛影响力的原因。 LSP 是它的第一个也是最苛刻的使用者——在交互式延迟下处理大型代码库中的调用图、导入图和符号关系——但 graph-lite 的 API 刻意不包含任何这些词汇，并且通过机制防止其学习这些词汇。

状态：实现前阶段。 仓库、门禁、文档和计划均已就位；构建阶段 1（graph-lite 核心）是当前工作。这里还没有任何东西发布。范围见 docs/spec.md；进度见里程碑。

为什么

如今每种语言都有自己的服务器、自己的进程、自己的内存占用，以及自己对"转到定义"代价的理解。打开四个不同语言的项目，你就在运行十几个互不共享的进程——没有缓存、没有索引、没有关系图。而且它们都不是为现在承担大部分阅读和编辑工作的客户端设计的：一个在终端中工作、没有编辑器、直接在磁盘上进行批量修改的 AI 代理。

Universal LSP 是一个处理所有这一切的进程。添加一种语言意味着编写声明式 Lua 规则，而不是一个新的服务器。

Related MCP server: code-auditor-mcp

层级

一种语言恰好获得其插件规则所描述的深度——不多不少，也从不依赖于机器上安装了什么。

第 4 层才是代理真正想要的：谁在传递性地调用这个 以及 如果我改了这个会破坏什么——从预先计算的图中回答，而不是读取上百个文件。

架构

      editor  ──stdio LSP──┐
      agent   ──MCP────────┤
      CI      ──batch CLI──┘
                           │
                    ┌──────▼──────┐
                    │  shim/cli   │  thin entrypoints, no logic
                    └──────┬──────┘
                           │ unix socket
                  ┌────────▼─────────┐
                  │     daemon       │  one per user, many sessions,
                  │  engine/         │  warm caches, per-workspace state
                  └────┬────────┬────┘
              tree-sitter        │
              + Lua rules        │
                   │             │
              ┌────▼─────┐  ┌────▼─────┐
              │ analysis │──▶ graph-lite│  generic nodes + typed edges
              └──────────┘  └──────────┘  (knows nothing about code)

依赖只朝一个方向流动，且只有一个方向：analysis → graph-lite，绝不反向。两个 lint 守卫和一个独立构建 CI 任务确保这一点，因为另一种选择——在提取时才意识到——意味着重写。

快速开始

git clone https://github.com/developerz-ai/universal-lsp.git
cd universal-lsp
bin/setup          # prerequisites → configure → link compile_commands.json
bin/check          # the full gate: format, guards, build, tests, sanitizers
bin/dev doctor     # one row per thing that can drift

需要 CMake ≥ 3.24、Ninja、C++20 编译器、clang-format，以及用于仓库工具链的 Bun。bin/setup 会指出任何缺失的工具及其安装方法。

单独嵌入 graph-lite

graph-lite 的构建不依赖本仓库的任何知识——这一点在每次 PR 上都会被断言，以便日后提取它仍然是 git mv 而不是重写：

cmake -S graph-lite -B build/graph-lite -G Ninja
cmake --build build/graph-lite

#include "graph-lite.h"     /* the contract: C linkage, opaque handles, status codes */

#include "graph-lite.hpp"   // C++ ergonomics over the same entry points, header-only

require "ffi"               # and the same from Ruby, JS, Python, Rust, Go
module GraphLite
  extend FFI::Library
  ffi_lib "graph-lite"
  attach_function :graph_lite_version_string, [], :string
end

测试套件中的一个 C 翻译单元以 C 语言编译并链接，因此一个不再是 C 兼容的头文件会让我们的构建失败，而不是你的集成失败。

API 和数据模型：docs/graph-lite/README.md · 为什么选 C：ADR 0004。

发布时支持的语言

TypeScript · JavaScript · Ruby · C · C++ · Lua · Python · Java · Kotlin · Swift · Rust

第 1 层和第 2 层首先覆盖全部十一种语言——这对编辑器和代理来说都是大部分价值所在。第 3 层的深度随后按语言逐步增长，降级为"未知类型"而不是错误的类型。

文档

贡献

先读 CONTRIBUTING.md，再读 CLAUDE.md。官方十一种语言之外的插件不需要任何批准，也不需要放在这个仓库里——发布一个 git 仓库并固定版本即可。

许可证

引擎采用 Apache-2.0。graph-lite 采用 MIT 并独立版本化，这是有意为之：嵌入一个头文件绝不应该让人去考虑恰好培育出它的那个东西的许可证。