搓了个给 Agent 用的 LSP 增强层，弥补 Claude Code 目前的代码理解短板

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

爱意满满的作品展示区。

最近高强度用各种 AI Coding Agent 写代码，发现一个挺无语的现象。现在的 Agent （包括最近很火的 Claude Code ）查代码主要还是靠 grep/ripgrep 暴力搜索。小项目还好，代码一多，或者遇到复杂的跨模块引用，正则匹配根本搞不定。这就导致 Agent 想重构代码的时候唯唯诺诺，生怕改了一个文件把隔壁模块搞挂了。

虽然 Claude Code 官方也在推进 LSP 支持，但目前体验确实还差点意思。之前试过社区里的一些方案（像 Serena ，cclsp ），大多只是简单粗暴地把 LSP 原始 JSON 扔给 LLM 。这种做法最大的问题是费 Token 且慢，Agent 往往需要往返交互十几次才能搞懂一个函数的上下文。

实在受不了这个效率，就自己动手造了个轮子叫 lsp-skill。

跟市面上其他简单的 LSP 包装器不同，lsp-skill 应该是目前唯一一个把“写操作”作为核心能力的方案。绝大多数竞品都停留在“只读”阶段（查查定义、找找引用），但 lsp-skill 支持完整的重构预览。这意味着 Agent 不再是瞎改，而是能像人一样，在重命名变量前先生成跨文件的 Diff 预览，确认无误了再下手。这点在维护大型遗留代码时非常关键。

另外一个比较独特的设计是它的扩展机制。通常 LSP 工具只懂语法不懂框架，但我们引入了基于 Markdown 的 Best Practices 系统。你不需要懂底层代码，只要写个 Markdown 文档，就能教 Agent 怎么处理 Django 的 View 或者 React 的 Hooks 。这种让社区通过文档来定义“代码导航策略”的做法，目前还没在其他工具里见到过。

这些特性加上它是完全为 LLM 优化的（输出 Markdown 而不是 JSON ），算是在“Agent Native”这个方向上走得比较远的一次尝试。

架构上为了稳，拆成了 lsp-client 处理底层脏活（ Server 生命周期、多 Workspace 管理），中间层做协议转换，最上层通过 MCP 对接 Claude Code 或者 Cursor 。目前 Python, TS, Go, Rust, Deno 这些主流语言都已经支持了。

有兴趣的朋友可以玩玩看，如果是做 Agent 开发或者对 MCP 感兴趣的，也可以看看我们的 Protocol 设计，说不定能有点启发。

🔗 GitHub: https://github.com/lsp-client/lsp-skill 📄 文档: https://lsp-client.github.io/

第 1 条附言 · 1 天前

哦对了忘了说了，我觉得最值得说道的是我设计的协议层 LSAP。

我将Agent与LSP的这套交互模式标准化为了 **LSAP (Language Server Agent Protocol)**，它将 LSP 面向编辑器的“原子操作”封装为面向 Agent 的“认知指令”，让 Agent 可以直接获取聚合好的 Markdown 代码报告，而无需通过多次往返交互来拼凑上下文，从而显著降低 Token 消耗并提升准确率。

以查找引用举例：

LSAP 指令: mode: "references" (配合 locate 或 find 参数)
底层编排 LSP 操作:
- textDocument/hover: 确认符号定义信息。
- textDocument/references: 获取所有引用位置列表。
- textDocument/documentSymbol: 识别引用点所属的函数或类（上下文感知）。
- 文件读取: 读取引用点周围的代码片段。
返回结果: 结构化 Markdown 报告
- 不仅仅是简单的“文件名:行号”，而是按文件分组，明确指出引用所在的上下文（例如：In LoginHandler.authenticate）。直接包含代码片段，Agent 无需额外读取文件即可理解用法。

Agent 看到的信息将会是这样的：

# References Found

Total references: 12 | Showing: 2

### src/auth/login.py:45

In `LoginHandler.authenticate` (`method`)

```python
44 | def authenticate(credentials):
45 |     if not User.validate(credentials):
46 |         raise AuthError()
```
--
Authenticate the login data.

### src/api/register.py:28

In `register_user` (`function`)

```python
27 | def register_user(new_user_data):
28 |     User.validate(new_user_data)
29 |     db.save(new_user_data)
```

lsp-skill

lsp

agent

10 条回复 • 2026-01-09 16:54:39 +08:00

fusi

1 天前 via Android

牛逼！下午就试一试

Oilybear

1 天前

来支持了

shunia

1 天前

1. 安装 skill （ codex 手动拷贝）
2. codex 用 gpt-5.2 + high ，项目是一个 javascript 的项目，给了 Agent 权限（可读写）
3. 输入 "用 lsp_skill 帮我读一下这个项目的代码，准备回答我的问题"
4. 中间一大堆“使用 lsp-cli 对渲染核心模块生成符号大纲需要语言服务器与本地 socket 通信，需提升权限运行。”，需要手动确认
5. 烧了 30%的 context ，似乎能用了
6. 持续提示 “使用 lsp-cli 对渲染核心模块生成符号大纲需要语言服务器与本地 socket 通信，需提升权限运行。”

我个人感觉似乎不太好用？

observerw

1 天前

@shunia 可以把具体过程在 https://github.com/lsp-client/lsp-skill 中提一个 Issue 吗，非常感谢

lsk569937453

1 天前

看来你没看过这个观点。Claude Code 核心工程师：「 Bash 即一切」，https://www.zhihu.com/question/1992208967498236682/answer/1992396321282357047

aminobody

1 天前

我很好奇为什么现在主流的 vibe code 工具都没用 lsp 呢?

observerw

1 天前

@lsk569937453 Anthropic 他们向来都是说一套做一套的🤣 MCP 是他们先提出的，bash 即一切也是他们提出的，有点左右脑互博了

此外，bash 即一切这个思想是好的，基于 Unix 哲学当然没什么问题；但这也是有前提的，那就是在 bash 中有好用的命令行工具。比如让 Agent 操作 GitHub 一般来说会使用 `gh` 命令行工具，而不是 “你必须通过 curl 请求 GitHub 的 API 端点“。

我这个项目就是基于这种思想来设计的。我提供给 Agent 的不是若干 LSP 工具，而是一个名为 `lsp` 的命令行工具（ https://github.com/lsp-client/lsp-cli ）。Agent 可以在 bash 中调用这个工具来探索代码仓库。我感觉这种设计还是比较符合 Bash 即一切的思想的，有兴趣欢迎来看看~

observerw

1 天前

@aminobody 我老早就在想这个问题了🤣 Claude Code 早些时候非得嘴硬说 "grep 加上 LLM 的理解能力就已经足够强大了，不需要额外工具“，结果现在还不是在做 LSP 支持（而且做的还不是很好）

vonfry

1 天前

@aminobody 你是否在寻找： https://github.com/oraios/serena

observerw

1 天前

@vonfry 谢邀，我还是做了竞品调研的😎 Serena 提供的 LSP 能力局限于搜索引用定义之类的，比较有局限性；相较而言我这个项目能做的事情就更多，而且能够轻易的持续扩展，可以说比 Serena 要强大的多，具体请看 https://github.com/lsp-client/LSAP 中的设计理念部分