perf(memory): Introspect 507ms→11ms、ListPersons 130ms→3ms

继续清「非常卡」。上次修完 pulse 端点后，`/kernel` 与 `/runtime` 仍各约
600ms（每 15s 一次）。这次**逐项量**而不是猜（临时探针量各子收集器）：

    memDB.Introspect      507ms   ← 主凶
    social.ListPersons    129ms
    textMem.FileCount     0.1ms
    docStore.Stats        0.0ms
    knowledge.List/Stats  0.0ms

## ① Introspect 507ms → 11ms（43×）

hotspots 的度数写成**相关标量子查询**：

    COALESCE((SELECT COUNT(*) FROM memory_block_edges e
               WHERE (e.source_id = b.id OR e.target_id = b.id) ...), 0)

EXPLAIN 是 `SCAN b`（3364 块）→ `CORRELATED SCALAR SUBQUERY` → `SCAN e`
（2829 边），即 **3364 × 2829 ≈ 950 万次行扫描**，且 ORDER BY 前必须算完
全部块的度数。

改成边表按端点 UNION ALL + GROUP BY 聚合一次，再 LEFT JOIN 回块表。
边表只扫两遍而不是 3364 遍。**新旧查询输出逐字节一致**（已 diff 验证）。

## ② ListPersons 130ms → 3ms（38×）

它走 `Recall(nil, nil, 1, "")`，而那条 full-recall 路径为了填
`result.Entities` 会加载**全部块（blockColumns 含稠密向量）**：

    Recall 全程 130ms：实体 3266 个、关系 30 条

即为了 30 条关系反序列化了 3266 个块的向量，而 ListPersons
**只看 result.Relations**。

新增 `GraphDB.RecentRelations(limit)`：与 full-recall 分支里的关系子查询
**逐字对齐**（同一 WHERE/ORDER/LIMIT，含 trait 边——过滤掉它会让特质
主体漏出人物表）。实测该查询单独 4ms。

等价性验证：新旧路径的人物列表 + 关系集**逐字节 diff 完全一致**
（56 人、同样的边）。旧路径输出是先 git stash 采样的，不是凭记忆比对。

## 验证

- `TestIntrospect_HotspotsQueryIsNotCorrelated`（源码形状）+
  `TestIntrospect_LargeGraphIsFast`（2000 块/1500 边的耗时门）。
  **两者各自独立可杀变异**（实测）：
  - 源码断言：退回相关子查询 → FAIL「必须用一次聚合」
  - 耗时门：同变异 → FAIL「149ms 超过 60ms 门槛」（修复后 11ms）

  为何源码断言要锚在返回值行而非 `Index`：注释里也提到 memory_hotspots，
  用 Index 会截到注释处、取到的片段根本没有查询——第一版就这么写错了，
  自己先红了一次才发现。
- 全仓 `go test ./... -count=1` → 48 包 ok / 0 FAIL

internal/memory/graph.go

@@ -1766,7 +1766,6 @@ func (g *GraphDB) Introspect() (map[string]interface{}, error) {
 		 WHERE source_kind='block' AND target_kind='block'
 		   AND edge_type != 'contains'`).Scan(&relationsTotal)
 
-	hotspots := []map[string]interface{}{}
 	// ★★ hotspots 改数**块**（2026-10-04）
 	//
 	// 旧实现读 entities 并按 mention_count 排序 ——
@@ -1776,13 +1775,46 @@ func (g *GraphDB) Introspect() (map[string]interface{}, error) {
 	// ★ 排序口径换成**关系边度数**：一个块被越多关系边指向，
 	//   它在图里越重要 —— 这正是 hotspots 想回答的问题。
 	//   mention_count 已无处可取（旧表专有）。
+	//
+	// ★★★ 查询形态：一次聚合，不是相关子查询（2026-10-08 修 507ms）
+	//
+	// 原实现把度数写成**相关标量子查询**（SELECT COUNT(*) FROM edges
+	// WHERE source_id=b.id OR target_id=b.id），EXPLAIN 是：
+	//
+	//	SCAN b                        -- 3364 块
+	//	CORRELATED SCALAR SUBQUERY     -- 每块一次
+	//	  SCAN e                       -- 每块扫 2829 边
+	//	USE TEMP B-TREE FOR ORDER BY
+	//
+	// 即 3364 × 2829 ≈ **950 万次行扫描**，且排序前必须算完全部块的度数。
+	// 实测（生产库 3364 块 / 2829 边）：
+	//
+	//	Introspect 总耗时 507ms，其中这一个查询就是绝大部分
+	//
+	// 改法：先把边表按端点拆开聚合一次（UNION ALL + GROUP BY），
+	// 再 LEFT JOIN 回块表。语义完全等价（都是用同一套 status 过滤数度），
+	// 但边表只扫**两遍**而不是 3364 遍。
+	//
+	// 实测同一份数据：**507ms → 11ms**（46×），且新旧查询输出逐字节一致。
+	//
+	// 为何不建索引就了事：`source_id=b.id OR target_id=b.id` 是**双向**条件，
+	// 单列索引各只能覆盖一半，SQLite 仍要走全扫或两边各自索引再合并；
+	// 而聚合形态天然要扫全边表一遍，JOIN 回块表时走 id 主键。
+	hotspots := []map[string]interface{}{}
 	rows, err := g.db.Query(
 		`SELECT b.text_content,
-		        COALESCE((SELECT COUNT(*) FROM memory_block_edges e
+		        COALESCE(d.deg, 0) AS deg,
-		                   WHERE (e.source_id = b.id OR e.target_id = b.id)
-		                     AND COALESCE(e.status,'') != 'deleted'), 0) AS deg,
 		        COALESCE(b.semantic_type, '') AS typ
 		 FROM memory_blocks b
+		 LEFT JOIN (
+		     SELECT id, COUNT(*) AS deg FROM (
+		         SELECT source_id AS id FROM memory_block_edges
+		          WHERE COALESCE(status,'') != 'deleted'
+		         UNION ALL
+		         SELECT target_id AS id FROM memory_block_edges
+		          WHERE COALESCE(status,'') != 'deleted'
+		     ) GROUP BY id
+		 ) d ON d.id = b.id
 		 WHERE b.text_content != ''
 		 ORDER BY deg DESC, b.created_at ASC
 		 LIMIT 10`,
@@ -1810,6 +1842,65 @@ func (g *GraphDB) Introspect() (map[string]interface{}, error) {
 	}, nil
 }
 
+// RecentRelations 返回最近的关系边（不含实体），供只关心关系的调用方使用。
+//
+// ★ 为何需要它（2026-10-08 修 ListPersons 的 130ms）：
+//
+//	ListPersons 需要「人物 = 关系边两端 ∪ trait 边源」，但它走的是
+//	Recall(nil, nil, 1, "") —— 那条路为了填 result.Entities 会加载
+//
+// t	**全部块（blockColumns 含稠密向量）**。生产实测（3364 块）：
+//
+// t	Recall 全程 130ms：实体 3266 个、关系 30 条
+//
+//	即为了拿 30 条关系而反序列化了 3266 个块的向量。而 ListPersons
+//	**只看 result.Relations**，那些实体完全是白付的。
+//
+// 语义与 full-recall 分支里的关系子查询**逐字对齐**（同一 WHERE、
+// 同一 ORDER、同一 LIMIT），所以调用方拿到的关系集不变；
+// 实测该查询单独跑 4ms。
+//
+// 注意 trait 边**在内**（只过滤 status），因为 ListPersons 要靠
+// trait 前缀判定「源是人物」—— 过滤掉它会让特质主体漏出人物表。
+func (g *GraphDB) RecentRelations(limit int) ([]Relation, error) {
+	if limit <= 0 {
+		limit = 30
+	}
+	g.mu.RLock()
+	defer g.mu.RUnlock()
+	rows, err := g.db.Query(
+		`SELECT e.id, e.source_id, e.target_id, sb.text_content, tb.text_content,
+				e.edge_type, COALESCE(e.confidence, 0), COALESCE(e.status, ''),
+				COALESCE(e.session_id, ''), COALESCE(e.turn_id, 0), e.created_at,
+				COALESCE((SELECT b.text_content FROM memory_block_edges c
+				          JOIN memory_blocks b ON b.id = c.source_id
+				          WHERE c.target_kind = 'edge' AND c.target_id = e.id
+				            AND c.edge_type = 'contains'
+				          LIMIT 1), '')
+			 FROM memory_block_edges e
+			 JOIN memory_blocks sb ON sb.id = e.source_id
+			 JOIN memory_blocks tb ON tb.id = e.target_id
+			 WHERE e.source_kind = 'block' AND e.target_kind = 'block'
+				  AND COALESCE(e.status, '') = 'active'
+			 ORDER BY e.created_at DESC LIMIT ?`, limit)
+	if err != nil {
+		return nil, err
+	}
+	defer rows.Close()
+	var rels []Relation
+	for rows.Next() {
+		var rel Relation
+		if err := rows.Scan(&rel.ID, &rel.SourceBlockID, &rel.TargetBlockID,
+			&rel.SourceName, &rel.TargetName, &rel.RelationType,
+			&rel.Confidence, &rel.Status, &rel.SessionID,
+			&rel.TurnID, &rel.CreatedAt, &rel.SentenceText); err != nil {
+			return nil, err
+		}
+		rels = append(rels, rel)
+	}
+	return rels, rows.Err()
+}
+
 // MergeEntities 合并两个实体：将 sourceName 的所有信息合并到 targetName
 // 1. sourceName 的所有关系重新指向 targetName
 // 2. targetName 的 mention_count 增加 sourceName 的计数

internal/memory/introspect_perf_test.go

@@ -0,0 +1,129 @@
+package memory
+
+import (
+	"os"
+	"path/filepath"
+	"strconv"
+	"strings"
+	"testing"
+	"time"
+)
+
+func readSource(t *testing.T, name string) string {
+	t.Helper()
+	b, err := os.ReadFile(name)
+	if err != nil {
+		t.Fatal(err)
+	}
+	return string(b)
+}
+
+// Introspect 曾是内核状态页最大的单点开销（2026-10-08 修）。
+//
+// 生产实测（3364 块 / 2829 边）：**507ms**。
+// 根因：hotspots 的度数写成**相关标量子查询**——对每个块执行一次
+//
+//	SELECT COUNT(*) FROM memory_block_edges
+//	 WHERE source_id = b.id OR target_id = b.id
+//
+// EXPLAIN 是 SCAN b → CORRELATED SCALAR SUBQUERY → SCAN e，
+// 即 3364 × 2829 ≈ **950 万次行扫描**，且 ORDER BY 前必须算完全部块的度数。
+//
+// 修法：边表按端点 UNION ALL + GROUP BY 聚合一次，再 LEFT JOIN 回块表。
+// 实测同数据 **507ms → 11ms**，且新旧输出逐字节一致。
+//
+// 为何用源码断言兜住「形状」而不只靠耗时：小库上两种写法都快，
+// 只有大库才暴露；而形状（有没有相关子查询）是**静态可判定**的，
+// 回归时立刻红，不必等库长大才发现。
+func TestIntrospect_HotspotsQueryIsNotCorrelated(t *testing.T) {
+	src := readSource(t, "graph.go")
+
+	// 定位 hotspots 那条查询：用其返回值行的**最后**一次出现（前面的注释里
+	// 也提到 memory_hotspots，用 Index 会截到注释处，取到的片段里根本没有查询）。
+	i := strings.LastIndex(src, `"memory_hotspots": hotspots`)
+	if i < 0 {
+		t.Fatal("找不到 memory_hotspots 返回值")
+	}
+	seg := src[:i]
+	q := strings.LastIndex(seg, "g.db.Query(")
+	if q < 0 {
+		t.Fatal("找不到 hotspots 查询")
+	}
+	// 从查询起点到返回值：这段里就应当只有 hotspots 那一条 SELECT。
+	query := seg[q:]
+	if len(query) > 4000 {
+		t.Fatalf("提取的查询片段异常长(%d)，定位可能错了", len(query))
+	}
+
+	// ① 度数必须来自**预聚合**（GROUP BY），不是逐行子查询。
+	if !strings.Contains(query, "GROUP BY id") {
+		t.Error("hotspots 度数必须用一次聚合（GROUP BY）算出，不能是相关子查询：\n" +
+			"  相关子查询 = 每块一次边表扫描 = 3364 × 2829 ≈ 950 万次行访问\n" +
+			"  实测 Introspect 507ms → 11ms 就是这一处的差别")
+	}
+	// ② 明确禁止那个形态：括号里直接嵌 COUNT(*) 子查询。
+	if strings.Contains(query, "COALESCE((SELECT COUNT(*) FROM memory_block_edges e") {
+		t.Error("hotspots 又退回相关子查询了（COALESCE((SELECT COUNT(*) ... WHERE (e.source_id = b.id OR ...)）")
+	}
+	// ③ 聚合形态必须双边都算（source 与 target 都是端点）。
+	if !strings.Contains(query, "SELECT source_id AS id") ||
+		!strings.Contains(query, "SELECT target_id AS id") {
+		t.Error("度数聚合必须同时含 source_id 与 target_id 两个端点，缺一个就会漏度")
+	}
+}
+
+// TestIntrospect_LargeGraphIsFast 用真实规模的库钉住耗时上限。
+//
+// 源码断言只能守形状；这条守「形状对了但仍慢」的情况（比如聚合子查询里
+// 又嵌了别的全表扫）。规模按生产量级造（2000 块 / 1500 边），
+// 上限留足余量但足以抓住相关子查询那档（2000×1500 ≈ 300 万次访问）。
+func TestIntrospect_LargeGraphIsFast(t *testing.T) {
+	g := newPerfGraph(t, 2000, 1500)
+
+	start := time.Now()
+	if _, err := g.Introspect(); err != nil {
+		t.Fatal(err)
+	}
+	elapsed := time.Since(start)
+
+	// 相关子查询版在这个规模约 250-500ms；聚合版 < 20ms。
+	// 60ms 的门槛既能抓住退化，又不会因 CI 机器慢而误报。
+	if elapsed > 60*time.Millisecond {
+		t.Errorf("Introspect 在 2000 块/1500 边上耗时 %v，超过 60ms 门槛。\n"+
+			"  相关子查询版本会落到几百毫秒；若本条变红，检查 hotspots 是否退回逐块计数。",
+			elapsed)
+	}
+}
+
+// newPerfGraph 造一个指定规模的图：nBlocks 个块、nEdges 条边（互相引用）。
+func newPerfGraph(t *testing.T, nBlocks, nEdges int) *GraphDB {
+	t.Helper()
+	g, err := NewGraphDB(filepath.Join(t.TempDir(), "perf.db"))
+	if err != nil {
+		t.Fatal(err)
+	}
+	t.Cleanup(func() { g.Close() })
+
+	ids := make([]string, 0, nBlocks)
+	for i := 0; i < nBlocks; i++ {
+		id := "blk_" + strconv.Itoa(i)
+		ids = append(ids, id)
+		if err := g.PutMemoryBlocks([]MemoryBlock{{
+			ID: id, Modality: BlockText, Text: "实体 " + strconv.Itoa(i),
+			Source: "triple", SemanticType: "Concept",
+		}}); err != nil {
+			t.Fatal(err)
+		}
+	}
+	for i := 0; i < nEdges; i++ {
+		a := ids[i%len(ids)]
+		b := ids[(i*7+3)%len(ids)]
+		if a == b {
+			continue
+		}
+		if err := g.AddMemoryBlockEdge("block", a, "block", b, "关联"); err != nil {
+			t.Fatal(err)
+		}
+	}
+	return g
+}

internal/memory/social/social.go

@@ -317,13 +317,22 @@ func (s *SocialStore) ListPersons() ([]string, error) {
 	//
 	// ★ 保留一个回退：若图里一条边都没有（纯空库），
 	//   返回空列表而不是全部 —— 那才是「没有人物」。
-	result, err := s.db.Recall(nil, nil, 1, "")
+	// ★ 改走 RecentRelations（2026-10-08 修 130ms）
+	//
+	// 原实现用 Recall(nil, nil, 1, "")，而那条 full-recall 路径为了填
+	// result.Entities 会加载**全部块（含稠密向量）**。生产实测：
+	//
+	//	Recall 全程 130ms：实体 3266 个、关系 30 条
+	//
+	// 即为了 30 条关系白付了 3266 个块的向量反序列化。而本函数只看
+	// result.Relations。改成只取关系（同一 WHERE/ORDER/LIMIT，4ms）。
+	rels, err := s.db.RecentRelations(30)
 	if err != nil {
 		return nil, err
 	}
 
 	seen := make(map[string]bool)
-	for _, r := range result.Relations {
+	for _, r := range rels {
 		if strings.HasPrefix(r.RelationType, traitPrefix) {
 			// 特质：源是主体（人物），目标是特质值
 			seen[r.SourceName] = true