Hermes 的 LSP 诊断很有用，但默认策略需要一次操作者安全打磨
Hermes 新的 LSP edit diagnostics 正从功能点快速变成运维面。新 issue #25015 指出，当前 LSP 子系统默认 enabled，且 `install_strategy: auto`，这意味着在 git repo 里第一次编辑 Python、Go、Rust 或 TypeScript 文件时，可能静默把 language server 安装到 Hermes home。Issue #25017 补上供应链角度：部分 install recipes 使用移动的 `@latest`，例如 `golang.org/x/tools/gopls@latest`，这对审计环境和可复现部署并不友好。Issue #25016 则是资源问题：LSP manager 虽然定义了 600 秒 idle timeout，但没有 reaper，长时间运行的 gateway 可能一直保留 pyright、gopls、tsserver、rust-analyzer 等进程，每个语言 / workspace 大约占 80-300+ MB。PR #25021 补上 idle-subprocess reaper；PR #25011 则批量带回两个小修复：`hermes lsp` 跳过插件发现更快启动，以及 diagnostics 中嵌套 `error` key 时不再把成功的 write_file / patch 误判失败。
这是让 Agent 拥有更好代码反馈后的正常二阶成本。真实 language servers 能提升编辑质量，但也把包安装、版本漂移、子进程生命周期和内存归属带进 Agent runtime。对团队来说，这不是实现细节；它决定一个有帮助的诊断层能不能无人值守地安全运行。
- Issue #25015 说明 LSP 默认 enabled 且 install_strategy 为 auto，首次编辑可触发在 HERMES_HOME/lsp/bin 下安装 language server
- Issue #25017 指出 gopls@latest 等未 pin recipe，并将其视为 supply-chain hygiene gap
- Issue #25016 称 idle LSP subprocesses 有追踪但不会被 reaped；pyright 约 200 MB、gopls 约 80 MB、tsserver 约 150 MB、rust-analyzer 超过 300 MB
- PR #25021 增加 idle reaper loop，并测试 stale clients 会 shutdown、active clients 会保留
- PR #25011 包含 mutation diagnostics false positive 修复，避免带 nested diagnostic errors 的成功 write_file / patch 被误判失败
- 多数内容仍是 open issues 或 PR，最终默认策略可能在 release 前变化
- 关闭 auto-install 能保护审计环境，但可能让 diagnostics 在手动安装 server 前不可用
- pin 住 recipe 提升可复现性，但也需要后续安全更新维护流程