RuView 图分析智能体：pagerank-analyzer 的 PageRank 次线性计算、网络优化与工程落地

本文围绕 RuView 仓库中 .claude/agents/sublinear/pagerank-analyzer.md 这份 Agent 定义文档展开，系统讲解 PageRank Analyzer 智能体的核心能力、所依赖的 sublinear-time-solver MCP 工具、四类典型图分析场景（大规模 PageRank、个性化 PageRank、影响力分析、群体拓扑优化），并结合仓库中真实存在的 PageRank 实现（spt_pagerank_influence.rs）与 ADR-038 中的依赖图优先级排序，展示这套"次线性图计算"方法在 RuView 中如何从智能体提示词落到可验证的源码、测试与事件协议。

一、Agent 定位：面向大规模图计算的专用分析器

pagerank-analyzer 是 RuView 中 sublinear（次线性）Agent 系列的一员，与同目录下的 consensus-coordinator.md、matrix-optimizer.md、performance-optimizer.md、trading-predictor.md 配套使用。其 frontmatter 定义如下：

name: pagerank-analyzer
description: Expert agent for graph analysis and PageRank calculations using sublinear
  algorithms. Specializes in network optimization, influence analysis, swarm topology
  optimization, and large-scale graph computations. Use for social network analysis,
  web graph analysis, recommendation systems, and distributed system topology design.
color: purple

从定义看，该 Agent 被明确定位为：使用次线性（sublinear）算法进行图分析与 PageRank 计算的专家智能体，擅长网络优化、影响力分析和大规模图计算，适用场景包括社交网络分析、Web 图分析、推荐系统与分布式系统拓扑设计。它的职责边界是"图/矩阵计算"，与系列中其他 Agent 的分工是：matrix-optimizer 负责邻接矩阵优化与谱分析，consensus-coordinator 负责共识网络与投票网络，pagerank-analyzer 则负责其中的排名与影响力计算。

二、核心能力矩阵

原文档将能力划分为"图分析"与"网络优化"两大类，共 8 项能力：

2.1 图分析（Graph Analysis）

• PageRank 计算：为大规模网络计算 PageRank 分数；
• 影响力分析：识别有影响力的节点与传播模式；
• 网络拓扑优化：为效率目标优化网络结构；
• 社区检测：识别网络中的簇与社区结构。

2.2 网络优化（Network Optimization）

• 群体拓扑设计（Swarm Topology Design）：优化多智能体（agent swarm）通信拓扑；
• 负载分布：在网络节点间优化负载分配；
• 路径优化：寻找最优路径与路由策略；
• 韧性分析：分析网络韧性与容错能力。

这一能力划分与 RuView 的实际图应用场景是吻合的：仓库中 ESP32 多节点 mesh、多人体 CSI 关联图、ADR 依赖图，本质上都是"小规模但需要高吞吐、低开销"的图，正是次线性求解器的主战场。

三、Primary MCP 工具：计算引擎层

Agent 文档明确列出其依赖的四个 MCP 工具（工具前缀为 mcp__sublinear-time-solver__）：

MCP 工具	作用
mcp__sublinear-time-solver__pageRank	核心 PageRank 计算引擎
mcp__sublinear-time-solver__solve	面向图问题的通用线性方程组求解
mcp__sublinear-time-solver__estimateEntry	估计特定图属性
mcp__sublinear-time-solver__analyzeMatrix	分析图邻接矩阵（对称性、条件数、谱间隙等）

这些工具来自仓库 vendored 的第三方子模块 sublinear-time-solver。从 vendor/README.md 可以看到，该仓库通过 git submodule 管理三个上游依赖，其中之一即 sublinear-time-solver/（"Sublinear-time optimization solvers"）。初始化方式：

git submodule update --init --recursive

因此，阅读 pagerank-analyzer 文档时应理解：MCP 工具本身不是 RuView 原生代码，而是由 vendored 求解器提供的计算后端；Agent 文档描述的是"如何编排这些工具解决图问题"的方法论层。

四、典型使用场景（含完整参数说明）

4.1 场景一：大规模 PageRank 计算

原文档给出的首个场景是对百万级节点 Web 图计算 PageRank，采用 COO（Coordinate，坐标格式）稀疏邻接表示：

// Compute PageRank for large web graph
const pageRankResults = await mcp__sublinear-time-solver__pageRank({
  adjacency: {
    rows: 1000000,
    cols: 1000000,
    format: "coo",
    data: {
      values: edgeWeights,       // 边权重数组
      rowIndices: sourceNodes,    // 源节点索引
      colIndices: targetNodes     // 目标节点索引
    }
  },
  damping: 0.85,      // 标准 PageRank 阻尼因子
  epsilon: 1e-8,      // 收敛精度
  maxIterations: 1000 // 最大幂迭代轮数（防不收敛保护）
});

console.log("Top 10 most influential nodes:",
  pageRankResults.scores.slice(0, 10));

参数要点：

• format: "coo"：坐标格式只需三个平行数组（值、行索引、列索引），是稀疏图最紧凑的传输形式，适合百万级矩阵通过 MCP 传递；
• damping: 0.85：经典 PageRank 阻尼因子，表示"随机游走继续跳转"的概率；仓库内真实的 Rust 实现同样采用 0.85（见第六节）；
• epsilon: 1e-8 与 maxIterations: 1000：精度与迭代上限双重约束，保证在次线性求解器内部可以提前收敛停止。

4.2 场景二：个性化 PageRank（推荐系统）

在标准 PageRank 基础上加入个性化向量，即可得到以某个用户/物品为中心的局部排名，这是推荐系统的常用手段：

// Compute personalized PageRank for recommendation systems
const personalizedRank = await mcp__sublinear-time-solver__pageRank({
  adjacency: userItemGraph,
  damping: 0.85,
  epsilon: 1e-6,              // 推荐场景放宽精度，换取更低开销
  personalized: userPreferenceVector, // 个性化偏好向量
  maxIterations: 500
});

// Generate recommendations based on personalized scores
const recommendations = extractTopRecommendations(personalizedRank.scores);

对比场景一可以观察到一个工程惯例：推荐场景把 epsilon 从 1e-8 放宽到 1e-6、maxIterations 从 1000 降到 500——排名推荐只需"相对序"正确，不需要全图数值收敛。

4.3 场景三：网络影响力分析

通过 analyzeMatrix 对社交网络邻接矩阵做结构分析，再用结果识别关键意见节点：

// Analyze influence propagation in social networks
const influenceMatrix = await mcp__sublinear-time-solver__analyzeMatrix({
  matrix: socialNetworkAdjacency,
  checkDominance: false,     // 不检查占优性
  checkSymmetry: true,      // 检查对称性（社交关系是否互惠）
  estimateCondition: true,   // 估计条件数（数值稳定性）
  computeGap: true           // 计算谱间隙（社区划分信号）
});

// Identify key influencers and influence patterns
const keyInfluencers = identifyInfluencers(influenceMatrix);

这里 computeGap（谱间隙）值得单独说明：邻接/拉普拉斯矩阵的谱间隙是社区检测的经典判据，它与原文档"Advanced Graph Algorithms"一节中的谱聚类方法相呼应。

五、与 Claude Flow 的集成：群体拓扑优化与分布式图处理

5.1 群体拓扑优化（Swarm Topology Optimization）

原文档给出了一个 SwarmTopologyOptimizer 类，展示 PageRank 如何用于多智能体通信拓扑设计：

// Optimize swarm communication topology
class SwarmTopologyOptimizer {
  async optimizeTopology(agents, communicationRequirements) {
    // Create adjacency matrix representing agent connections
    const topologyMatrix = this.createTopologyMatrix(agents);

    // Compute PageRank to identify communication hubs
    const hubAnalysis = await mcp__sublinear-time-solver__pageRank({
      adjacency: topologyMatrix,
      damping: 0.9, // Higher damping for persistent communication
      epsilon: 1e-6
    });

    // Optimize topology based on PageRank scores
    return this.optimizeConnections(hubAnalysis.scores, agents);
  }

  async analyzeSwarmEfficiency(currentTopology) {
    // Analyze current swarm communication efficiency
    const efficiency = await mcp__sublinear-time-solver__solve({
      matrix: currentTopology,
      vector: communicationLoads,
      method: "neumann",   // 级数求和（Neumann series）迭代法
      epsilon: 1e-8
    });

    return {
      efficiency: efficiency.solution,
      bottlenecks: this.identifyBottlenecks(efficiency),
      recommendations: this.generateOptimizations(efficiency)
    };
  }
}

两个设计细节值得注意：

1. 阻尼因子提高到 0.9：注释说明"持久通信需要更高阻尼"——高阻尼让分数更集中于长程枢纽节点，适合识别"通信中枢"；
2. Neumann 方法求解负载：method: "neumann" 即级数求和迭代（(I-A)^-1 b 的截断级数），只对严格收缩的矩阵有效，正是一次性"近似"而非"精确"的次线性手段，与 Agent 的"sublinear"定位一致。

原文档还列出了共识网络分析（Consensus Network Analysis）三项子任务：投票权分析（Voting Power Analysis）、拜占庭容错分析（Byzantine Fault Tolerance）、通信效率优化。这部分在本文档中是能力声明而非流程细节，可结合同系列的 consensus-coordinator.md 理解分工。

5.2 分布式图处理（Flow Nexus 沙箱）

对于超出单机内存的图，文档给出的路线是把 PageRank 分发到 Python 沙箱执行，按图分块（chunk）做局部迭代 + 分区同步：

// Deploy distributed PageRank computation
const graphSandbox = await mcp__flow-nexus__sandbox_create({
  template: "python",
  name: "pagerank-cluster",
  env_vars: {
    GRAPH_SIZE: "10000000",
    CHUNK_SIZE: "100000",
    DAMPING_FACTOR: "0.85"
  }
});

// Execute distributed PageRank algorithm
const distributedResult = await mcp__flow-nexus__sandbox_execute({
  sandbox_id: graphSandbox.id,
  code: `
    import numpy as np
    from scipy.sparse import csr_matrix
    import asyncio

    async def distributed_pagerank():
        # Load graph partition
        graph_chunk = load_graph_partition()

        # Initialize PageRank computation
        local_scores = initialize_pagerank_scores()

        for iteration in range(max_iterations):
            # Compute local PageRank update
            local_update = compute_local_pagerank(graph_chunk, local_scores)

            # Synchronize with other partitions
            global_scores = await synchronize_scores(local_update)

            # Check convergence
            if check_convergence(global_scores):
                break

        return global_scores

    result = await distributed_pagerank()
    print(f"PageRank computation completed: {len(result)} nodes")
  `,
  language: "python"
});

这段代码体现的分布式 PageRank 结构是：每个分区持有图的 CSR 块，每轮先做局部幂迭代，再通过 synchronize_scores 做跨分区全量归约（对应 PageRank 更新中的"入边汇总"步骤），最后按收敛判据提前终止。

5.3 图神经网络（GNN）训练配置

文档还给出了一个 GNN 训练配置示例，把 PageRank 分析结果与学习型图模型衔接：

const graphNeuralNetwork = await mcp__flow-nexus__neural_train({
  config: {
    architecture: {
      type: "gnn", // Graph Neural Network
      layers: [
        { type: "graph_conv", units: 64, activation: "relu" },
        { type: "graph_pool", pool_type: "mean" },
        { type: "dense", units: 32, activation: "relu" },
        { type: "dense", units: 1, activation: "sigmoid" }
      ]
    },
    training: {
      epochs: 50,
      batch_size: 128,
      learning_rate: 0.01,
      optimizer: "adam"
    }
  },
  tier: "medium"
});

从该配置可读出其意图：graph_conv + mean pool + 两层 dense + sigmoid 输出，是典型的二分类（如节点分类/链路预测）图模型骨架，与后文"Graph Machine Learning"能力条目对应。

六、高级图算法与性能优化策略

6.1 高级图算法

原文档列出三组进阶算法：

社区检测：

• 模块化优化（Modularity Optimization）：以模块度为目标函数切分社区；
• 谱聚类（Spectral Clustering）：用拉普拉斯特征向量做社区识别；
• 层次社区（Hierarchical Communities）：检测多层嵌套的社区结构。

网络动力学：

• 时序网络（Temporal Networks）：分析随时间演化的网络结构；
• 动态 PageRank（Dynamic PageRank）：对拓扑持续变化的图维护排名；
• 影响力传播建模（Influence Propagation）：预测影响力随时间的扩散。

图机器学习：

• 节点分类、链路预测、图嵌入（Graph Embeddings）。

6.2 性能优化三维度

维度	技术
可扩展性	图划分（分区并行）、近似算法（超大图用近似值）、增量更新（动态图只更新受影响部分）
内存	稀疏表示（CSR/COO）、图数据压缩、流式算法（处理超出内存的图）
计算	多核并行、GPU 加速、多机分布式

这几条不是空泛罗列：epsilon + maxIterations 双参数（场景一）、COO 稀疏格式（场景一）、分块同步（分布式沙箱）分别对应"近似算法、稀疏表示、图划分"三项，构成了一套自洽的工程策略。

七、应用域与集成模式

7.1 四个应用域

• 社交网络分析：影响力排名、社区检测、病毒式传播营销的目标用户选择；
• Web 搜索与排名：网页权威度排名、链接结构分析、站点结构优化；
• 推荐系统：基于网络分析的内容推荐、协同过滤、信任网络；
• 基础设施优化：通信网络路由优化、负载均衡、容错架构设计。

7.2 与系列 Agent 的集成模式

原文档定义了三个集成面：

集成对象	集成内容
Matrix Optimizer	邻接矩阵优化、图拉普拉斯谱分析、特征值/特征向量计算
Trading Predictor	金融市场网络分析、资产相关性网络、系统性风险评估
Consensus Coordinator	共识拓扑设计、投票网络与权力结构分析、拜占庭韧性结构

三个集成面分别对应同目录下的 matrix-optimizer、trading-predictor、consensus-coordinator 三个 Agent 文档，说明 pagerank-analyzer 在 sublinear 智能体群中承担的是"图计算中枢"角色：矩阵由 optimizer 预处理，排名结果再交给 coordinator 用于共识决策。

7.3 三条端到端工作流

社交媒体影响力活动：构建交互图 → 计算 PageRank 识别 KOL → 社区检测定位目标社群 → 优化投放策略 → 用网络指标度量活动效果。

Web 搜索优化：构建爬虫链接图 → 计算页面权威度 → 查询处理引入 PageRank → 按相关度 + 权威度排序结果 → 监控搜索质量。

分布式系统设计：分析现有拓扑 → 定位通信/处理瓶颈 → 基于 PageRank 分析设计优化拓扑 → 实施 → 验证性能提升。

八、从提示词到源码：RuView 仓库中的 PageRank 实证

pagerank-analyzer.md 定义的是"方法论与工具编排"，而 RuView 仓库中恰好存在两处可验证的 PageRank 落地，可以印证文档中"0.85 阻尼、幂迭代、稀疏图"这套参数选择的工程一致性。

8.1 边侧实现：spt_pagerank_influence 模块

Rust 工作区中的 spt_pagerank_influence.rs 是一个完整的 PageRank 影响力模块：它把最多 4 个人建模为图节点，边权重取各人"子载波相位组"之间的归一化互相关，用幂迭代找出多人 WiFi 感知场景中的主导人物。其关键常量与 Agent 文档的推荐值完全一致：

const MAX_PERSONS: usize = 4;   // 最大追踪人数
const SC_PER_PERSON: usize = 8; // 每人 8 个子载波
const DAMPING: f32 = 0.85;      // PageRank 阻尼因子（与文档默认值一致）
const PR_ITERS: usize = 10;     // 幂迭代轮数（小图 10 轮即收敛）
const ALPHA: f32 = 0.15;        // 影响力 EMA 平滑
const CHANGE_THRESHOLD: f32 = 0.05; // 触发 INFLUENCE_CHANGE 事件的秩变化阈值

幂迭代核心（对应文档场景一中 pageRank 工具的数学内核）：

/// Standard PageRank: r_{k+1} = d * M * r_k + (1-d)/N.
// 列归一化邻接矩阵得到转移矩阵 M，每轮迭代后归一化使秩和为 1
let base = (1.0 - DAMPING) / (np as f32);
for _iter in 0..PR_ITERS {
    for i in 0..np {
        let mut weighted = 0.0f32;
        for j in 0..np {
            if col_sum[j] > 1e-9 {
                weighted += (self.adj[i][j] / col_sum[j]) * self.rank[j];
            }
        }
        new_rank[i] = DAMPING * weighted + base;
    }
    // ... 归一化使 ranks sum to 1
}

输出协议是三个事件 ID（760-762）：EVENT_DOMINANT_PERSON（每帧广播主导人索引）、EVENT_INFLUENCE_SCORE（主导人分数，[0,1]）、EVENT_INFLUENCE_CHANGE（某人秩变化超过 0.05 时触发，整数部分编码 person_id、小数部分编码带符号增量）。模块自带一组单元测试覆盖单/双人场景、对称等秩、正交信号零相关、突变帧等用例（spt_pagerank_influence.rs#L251-L344），并在 skill_registry.rs#L405 中以 SptPagerankAdapter 注册进边侧技能注册表。docs/edge-modules/spatial-temporal.md 对该模块的公开 API 与事件表有完整说明，其预算标注为 "S (<5 ms)"，说明在 ESP32 级别的算力约束下 PageRank 10 轮迭代是可以实时运行的——这正是"次线性/小图快速近似"思路在硬件端的体现。

8.2 规划侧实现：ADR-038 的 PageRank 优先级排序

ADR-038（Sublinear Goal-Oriented Action Planning） 第 2.8 节给出了 PageRank 在另一个维度上的应用：当用户没有指定目标、只问"下一步该做什么"时，规划器对 ADR 动作依赖图跑 PageRank 找出"杠杆最高"的动作：

1. 构建邻接矩阵：A[i][j] = 1 表示动作 j 依赖动作 i（完成 i 解锁 j）；
2. 以阻尼因子 0.85 运行 PageRank；
3. 分数最高的动作是"承重"动作——解锁的下游工作最多；
4. 过滤出前置条件当前可满足的动作；
5. 按 PageRank_score * (1 / cost_days)（单位投入价值）返回 Top-K。

其性能预算明确写道：PageRank 优先级排序 < 2ms（稀疏矩阵迭代）。这与 pagerank-analyzer 文档"用 PageRank 识别枢纽/承重节点"的能力声明在方法上完全同源——一个用于智能体通信拓扑，一个用于研发任务依赖拓扑。

8.3 小结：文档与实现的一致性

维度	Agent 文档	仓库实现
阻尼因子	0.85（标准场景）/ 0.9（持久通信）	0.85（spt_pagerank_influence.rs#L24、ADR-038 §2.8）
迭代策略	幂迭代 + epsilon/最大轮数双约束	固定 10 轮（小图快速收敛，无需 epsilon 判定）
稀疏表示	COO 三数组传输	4×4 稠密切片（图小，稠密更省）
结果消费	Top-K 分数、枢纽识别	事件 760-762、Top-K 动作优先级

可以推断：pagerank-analyzer 文档中"百万级 Web 图"的场景面向 MCP 求解器的一般能力，而 RuView 自身更常处理的是 4 节点~80 节点的"小而稠密"图，因此仓库内实现选择了固定轮数、零分配（const fn new()、栈上矩阵）的嵌入式形态。两者共享同一套数学内核与参数惯例，但按图规模做了不同层次的近似。

九、适用前提与限制说明

基于仓库实际内容，使用该 Agent 定义与相关工具时应注意以下前提：

1. MCP 工具可用性：mcp__sublinear-time-solver__* 工具依赖 vendor/README.md 所述子模块初始化（git submodule update --init --recursive）；文档中的 mcp__flow-nexus__* 沙箱工具同样属于外部编排层，不是 RuView 原生代码。
2. 参数适用域：damping: 0.85 是标准推荐值；拓扑枢纽识别场景可上调至 0.9（见 5.1 节注释）。epsilon 与 maxIterations 应根据"要相对序还是要绝对收敛"权衡（场景一 vs 场景二）。
3. 近似性：Neumann 迭代、固定轮数幂迭代（边侧 10 轮）都是近似手段，结论是"足够用的排名"而非精确 PageRank 值；对数值敏感的场景应回到 analyzeMatrix 的条件数/谱间隙检查。
4. 规模适配：仓库实证（8.1 节）表明小图场景下应去掉动态收敛判定、用固定轮数换取可预测延迟；百万级图才需要 COO 传输 + 分布式分块同步。

十、延伸阅读路径

• Agent 定义本体：.claude/agents/sublinear/pagerank-analyzer.md
• 同系列 Agent：.claude/agents/sublinear/matrix-optimizer.md、.claude/agents/sublinear/consensus-coordinator.md、.claude/agents/sublinear/performance-optimizer.md、.claude/agents/sublinear/trading-predictor.md
• 计算后端子模块说明：vendor/README.md
• 边侧 PageRank 实现与测试：v2/crates/wifi-densepose-wasm-edge/src/spt_pagerank_influence.rs、技能注册 v2/crates/wifi-densepose-wasm-edge/src/skill_registry.rs
• 模块级文档（API、事件、常量表）：docs/edge-modules/spatial-temporal.md
• PageRank 用于研发规划优先级的 ADR：docs/adr/ADR-038-sublinear-goal-oriented-action-planning.md

综合来看，pagerank-analyzer 的价值在于把"PageRank 怎么算、什么图用什么参数、结果如何驱动拓扑/推荐/共识决策"沉淀为可被编排的专家提示词；而仓库中的 spt_pagerank_influence 模块、事件协议与 ADR-038 则提供了从嵌入式实时路径到研发规划路径的两份可验证落证，读者可以沿这两条线索在仓库中自行复现与扩展。