加载失败
Anthropic 的 Claude Code（面向代码的 CLI/agent 客户端）在其插件市场里加入对 LSP（Language Server Protocol）的原生支持，目标是让代理在终端会话中按需调用语言服务器以获取跳转、引用、hover 等代码情报。讨论围绕这项功能的实用性与局限展开：有人认为它能显著降低对全文 grep 和海量上下文的依赖，提高符号查找和类型推断的准确度；也有人指出当前实现缺乏重命名/diagnostics/变更命令、权限提示与市场 UX 粗糙。评论把焦点放在三类技术栈上：编辑器协议（LSP）、编译器/IDE 级 API（如 Roslyn/.NET 的编译器 API 或 JetBrains 的 PSI）以及 agent/工具调用接口（MCP 或 CLI 桥接），并讨论应由谁把哪些能力以何种方式暴露给 agent 才能实现可编译、可回退的代码改动。
大量评论认为 JetBrains 把其语义代码模型（PSI）和成熟重构工具锁在内部，未把这些变更 API 暴露给 agent/AI，因而错失把 IDE 变成 agent‑first 平台的机会。讨论列举了 Junie 的挫折和随后把 Junie 当作多供应商之一的策略、MCP server 对多文件夹项目支持差以及长期被忽视的 bug，这些都损伤了用户信任并促使开发者转向 VS Code、Cursor 或第三方插件。评论还提到定价、UI 改动（例如移除 commit modal）与产品线调整（Fleet 终止、改向 agent）等经营决策，认为这些都在削弱 JetBrains 过去基于语义理解形成的护城河。整体观点是：如果不把可编译/可回退的深度重构接口尽快开放给 agents，迁移成本会因 agent 效率提升而迅速降低。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11]
用户普遍欢迎 Claude Code 在插件市场加入 LSP，但指出实现还很粗糙：启用流程要在 /plugin->marketplace 手动搜索 'lsp'，旧版本默认不显示市场，部分用户根本搜不到插件或需要手动更新市场。功能层面代理能声明并使用一组 LSP 操作（如 goToDefinition、findReferences、hover、workspaceSymbol 等），但缺少关键的变更命令（例如方便的一键 rename symbol）、部分 LSP（如 typescript‑lsp）缺失实时 diagnostics，且权限提示/安装弹窗有重复或非阻塞的问题。结论是 LSP 为代理带来更精准的符号与类型信息，但要发挥最大价值需要补齐重命名/diagnostics/变更 API、改善安装可见性與权限流。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11]
讨论呈现两派：偏好 CLI 的人认为在终端驱动 agent（如 Claude Code、OpenCode、Crush）更贴近“在电脑上直接编排”工作流，可以按需启用工具、避免把大量上下文长期塞进模型，从而节省 tokens；反对者则问既然 IDE 已有 LSP，为什么不直接在 GUI 中让 agent 利用这些能力。技术上有人指出 LSP 的设计哲学是“一套 server 多个 client”，因此 CLI 实现一个轻量 client 并非再造轮子；另一个重要论点是未启用的 CLI 不会占用上下文窗口，这在长会话或对 token 敏感的场景里能显著提升迭代效率。总体观点倾向于把 LSP/语言服务做成按需可调用的工具，不必强行绑在单一 UI 上。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]
评论者对各家工具与模型的体验分歧明显：有人表示在 GPT‑5.2 / Codex 下体验大幅改善，但早期版本会漏掉符号引用，因此有人为其做了基于 rope 的 Python 重构技能以补缺；另一些人认为 Claude Code 的交互与 UX 更成熟、响应流畅、更易上手。OpenCode（开源的 agent/CLI）被多次提及为早期支持 LSP 的方案且适合自托管，但也被抱怨存在性能抖动、弹窗误触和工具调用失败等可用性问题。总体结论是：模型本身、底层 prompt/集成质量和工具稳定性三者共同决定日常可用性，开源路线上虽然灵活但在工程抛光上仍需投入。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10]
多条评论强调 LSP 提供的是符号查找、跳转與诊断等信息，而真正“可编译、有保障”的大规模重构需要编译器或 IDE 内部的语义 API。以 Roslyn（.NET 的编译器 API）为例，评论指出其 analyzer/quick‑fix 能在抽象语法树层面做精确转换（例如把 foreach 转为 for、重写复杂 LINQ、改变类型签名或删除冗余代码），这些是简单的 find/replace 无法完成的。因此，如果代理要在大型代码库执行深度改动，就必须能调用编译器/IDE 的变更接口（或由 IDE 提供变更保证），否则只能做有限且容易出错的文本级变更。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
一些评论指出，尽管有工具/项目（如 Crush、Serena、mcp‑language‑server 等）早已支持把 LSP 暴露给 agent，但实际 agent 很少稳定地调用这些接口，仍依赖 grep 或全文扫描导致不准确的重命名与符号查找。大家期望 agent 在变更流程中能原子化调用工具：把 LSP/编译器作为 deterministic 的工具调用、在 Stop hook 或变更完成时运行测试并将精简的测试结果回传给模型，以便判定改动是否可编译且未破坏行为。还有人建议把 LSP 做成 CLI 前端或轻量 shell 命令，以便按需启用、节省上下文并提高可预测性。总体诉求是减少把大量信息塞进上下文，而用可调用的工具链保证准确性与效率。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
多名用户报告 Claude Code 在插件市场、权限提示与自动更新上存在稳定性或可用性问题：macOS 自动更新报错、市场未默认启用导致看不到 LSP 插件、权限弹窗非阻塞或重复出现、以及 MCP 在某些情形下会挂起。这些问题让新特性难以被广泛验证，用户被迫采取手动升级、用 Homebrew 重新安装或采用替代插件（例如 mcp‑language‑server、Augment）来规避。评论普遍认为在把 LSP 与重构接口正式推广到日常工作流之前，需要解决安装可见性、权限流和运行时稳定性方面的抛光工作。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
LSP (Language Server Protocol): 一种编辑器与语言服务之间的标准协议，允许客户端获取代码智能（如 go‑to‑definition、find‑references、hover/type info、diagnostics、inlay hints 及部分重构命令），以实现“一套 language server 多个编辑器”的可复用性。
MCP（MCP server / JetBrains MCP）: 在讨论中指 JetBrains 提供的一个中介/服务（MCP server），用于将 IDE 的代码元数据與语义模型（例如项目结构、符号定义）暴露给外部工具或 agent；评论里称其实现目前有可用性与范围受限的问题。
Roslyn: Roslyn 是 .NET 的编译器平台/API，允许直接操作抽象语法树并实现编译器级的检查与代码变换（如 analyzer、quick‑fixes），适合做保证可编译性的复杂重构。