最近高强度用各种 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 条附言 10 天前
哦对了忘了说了，我觉得最值得说道的是我设计的协议层 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) ```  | 1 fusi 10 天前 via Android 牛逼！下午就试一试 |
 | 2 Oilybear 10 天前 来支持了 |
 | 3 shunia 10 天前 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 通信，需提升权限运行。” 我个人感觉似乎不太好用？ |
 | 4 observerw OP @shunia 可以把具体过程在 https://github.com/lsp-client/lsp-skill 中提一个 Issue 吗，非常感谢 |
 | 5 lsk569937453 10 天前 看来你没看过这个观点。Claude Code 核心工程师：「 Bash 即一切」，https://www.zhihu.com/question/1992208967498236682/answer/1992396321282357047 |
 | 6 aminobody 10 天前 我很好奇为什么现在主流的 vibe code 工具都没用 lsp 呢? |
| 7 observerw OP @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 即一切的思想的，有兴趣欢迎来看看~ |
| 8 observerw OP @aminobody 我老早就在想这个问题了 Claude Code 早些时候非得嘴硬说 "grep 加上 LLM 的理解能力就已经足够强大了，不需要额外工具“，结果现在还不是在做 LSP 支持（而且做的还不是很好） |
 | 9 vonfry 10 天前 |
| 10 observerw OP @vonfry 谢邀，我还是做了竞品调研的 Serena 提供的 LSP 能力局限于搜索引用定义之类的，比较有局限性；相较而言我这个项目能做的事情就更多，而且能够轻易的持续扩展，可以说比 Serena 要强大的多，具体请看 https://github.com/lsp-client/LSAP 中的设计理念部分 |
Select Language