ishenwei/nexus
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
c5a6f4d76e2c37d80030062034b28f7ee5489921
nexus/wiki/sources/lsp-index-engineer.md

5.4 KiB
Raw Blame History

title, type, tags, date
title type tags date
LSP/Index Engineer Agent Personality source
2026-04-25

Source File

Summary（用中文描述）

  • 核心主题：LSP/Index Engineer 是 The Agency Specialized 部门的代码智能系统架构师 Agent，通过编排 Language Server Protocol（LSP）客户端并构建统一语义图谱，实现跨多语言的代码智能查询能力。
  • 问题域：如何将异构语言服务器（TypeScript、PHP、Go、Rust、Python）的语义数据统一为一致的代码图谱，并在亚秒级延迟内提供导航/定义/引用查询。
  • 方法/机制：graphd LSP 聚合器 + 多语言 LSP 客户端编排 + nav.index.jsonl 语义索引 + WebSocket 实时增量更新 + SQLite/JSON 持久化缓存层。
  • 结论/价值：将不同语言服务器的输出标准化为统一图谱（节点：文件/符号，边：contains/imports/calls/refs），实现 100k+ 符号规模下 60fps 的沉浸式代码可视化，定义/引用查询响应 <150ms，Hover 文档 <60ms。

Key Claims（用中文描述）

  • graphd 通过 LSP 聚合器并发编排 TypeScript/PHP/Go/Rust/Python 多语言 LSP 客户端，将响应转换为统一图谱模式
  • 语义索引基础设施 nav.index.jsonl 存储符号定义、引用和 Hover 文档，支持 LSIF 导入/导出
  • 原子性图谱更新确保从不处于不一致状态，WebSocket 实时推送图谱差异
  • 默认要求 TypeScript 和 PHP 支持必须首先达到生产就绪状态
  • 严格遵循 LSP 3.17 规范，正确处理各语言服务器的能力协商
  • 每个符号必须有且仅有一个定义节点，所有边必须引用有效节点 ID
  • /graph 端点在 <10k 节点数据集下 100ms 内响应，/nav/:symId 查找缓存 <20ms / 未缓存 <60ms
  • 系统处理 100k+ 符号时性能不降级，内存保持在 500MB 以下

Key Quotes

"Build the graphd LSP Aggregator — Orchestrate multiple LSP clients (TypeScript, PHP, Go, Rust, Python) concurrently, Transform LSP responses into unified graph schema (nodes: files/symbols, edges: contains/imports/calls/refs)" — 核心交付物定义 "Strictly follow LSP 3.17 specification for all client communications, Handle capability negotiation properly for each language server" — 协议合规要求 "Every symbol must have exactly one definition node, All edges must reference valid node IDs" — 图谱一致性约束 "Sub-500ms response times for definition/reference/hover requests" — 性能北极星指标

Key Concepts

  • LSP-317-Specification：Language Server Protocol 3.17 规范——LSP 的最新版本，定义了客户端与语言服务器之间的标准化通信协议
  • Semantic-Index-Infrastructure：语义索引基础设施——将 LSP 响应转换为持久化结构（nav.index.jsonl + SQLite/JSON 缓存），支持快速启动和增量查询
  • Graph-Node-Schema：图谱节点模式——统一表示文件节点（file:）、模块节点（module/）、符号节点（sym:），支持 6 种节点类型和 6 种边类型
  • Incremental-Graph-Update：增量图谱更新——通过文件监视器和 Git hooks 触发增量更新，WebSocket 推送图谱差异，原子性保证从不处于不一致状态
  • LSP-Client-Orchestration：LSP 客户端编排——多语言 LSP 客户端并发初始化、能力协商、请求批量处理和缓存管理的统一架构
  • Performance-Contracts：性能契约——量化系统性能约束：/graph <100ms、/nav <60ms、WebSocket <50ms、内存 <500MB

Key Entities

  • The-Agency：The Agency 多智能体系统组织，147 个 Agent 跨 12 个部门，LSP/Index Engineer 属于 Specialized 部门
  • TypeScript-Language-Server：TypeScript 语言服务器——支持 TypeScript 和 JavaScript 的 LSP 实现
  • Intelephense：PHP Intelephense——PHP 语言的 LSP 服务器实现
  • gopls：Go 语言服务器——Go 官方 LSP 实现
  • rust-analyzer：Rust 语言服务器——Rust 官方 LSP 实现
  • pyright：Python 语言服务器——Microsoft 的 Python 类型检查和 LSP 实现
  • LSIF：Language Server Index Format——预计算语义数据的标准化交换格式

Connections

Contradictions

  • 与 specialized-workflow-architect 存在张力：
    • 冲突点：LSP/Index Engineer 要求"每个系统边界定义显式交接合同"（确定性要求），而 Workflow Architect 承认 LLM 概率性使得穷举建模存在上限
    • 当前观点（LSP/Index Engineer）：图谱节点必须精确——"每个符号必须有且仅有一个定义节点"，"Reference edges must point to definition nodes"
    • 对方观点（Workflow Architect）：穷举工作流存在概率性上限，某些边界条件只能通过概率性处理
    • 协调方向：LSP/Index Engineer 的确定性约束适用于代码符号层面（静态分析），Workflow Architect 的概率性适用于行为工作流层面，两者作用于不同抽象层次，可共存
Reference in New Issue View Git Blame Copy Permalink