Ruflo 中的矩阵优化 Agent：从对角占优分析到子线性求解的完整实战指南

本篇以 Ruflo（原 claude-flow v3 体系）仓库中的 matrix-optimizer 技能文档 为核心，系统讲解矩阵优化 Agent（Agent Matrix Optimizer）的能力模型、四类 MCP 工具的调用方式与参数含义，并结合仓库中 ruflo-graph-intelligence 插件 的真实求解器源码，深入剖析对角占优（diagonal dominance）检测、Neumann/CG 迭代求解、单点 PageRank 估计与复杂度预算治理的底层实现。读完后你能够：独立完成"先分析、再求解、后验证"的矩阵优化流水线，理解每个参数（epsilon、maxIterations、coherenceThreshold、maxComplexityClass）对数值稳定性与性能的实际影响，并知道如何在 Ruflo 的 swarm 与 Flow Nexus 沙箱环境中集成这套能力。

一、Agent 定位：矩阵属性的"体检医生"与求解路径的决策者

该技能的 frontmatter 将其定义为：一个专门使用子线性（sublinear）算法做矩阵分析与优化的专家 Agent，"Use when you need to analyze matrix properties, optimize matrix operations, or prepare matrices for sublinear solvers"（当你需要分析矩阵属性、优化矩阵运算，或为子线性求解器准备矩阵时使用）。

它承担的核心职责是四件事：

能力	说明
Property Detection（属性检测）	分析矩阵的对角占优性、对称性与结构特征
Condition Assessment（条件数评估）	估计条件数与谱间隙（spectral gap），用于判断求解器稳定性
Optimization Recommendations（优化建议）	给出矩阵变换与预处理步骤的建议
Performance Prediction（性能预测）	预测求解器的收敛行为与性能特征

这一设计背后的关键前提是：子线性求解器（如 Neumann 迭代、forward-push PageRank）只有在矩阵满足对角占优（DD, Diagonally Dominant）条件时才能保证快速收敛。因此 Agent 的第一职责不是"解"，而是"判"——先判断矩阵是否具备子线性求解的条件，不具备时给出正则化（regularization）或预条件（preconditioning）建议。

二、四类 MCP 工具与参数速查

技能文档声明了四类主要 MCP 工具（mcp__sublinear-time-solver__ 前缀），它们构成了 Agent 的"手术刀"：

• mcp__sublinear-time-solver__analyzeMatrix —— 综合矩阵属性分析
• mcp__sublinear-time-solver__solve —— 求解对角占优线性系统
• mcp__sublinear-time-solver__estimateEntry —— 估计特定解向量分量（无需全量求解）
• mcp__sublinear-time-solver__validateTemporalAdvantage —— 验证计算加速优势是否真实成立

从仓库实现可以印证这套工具契约的实际落地形态。Ruflo 将求解能力以插件形式发布：ruflo-graph-intelligence 在其 package.json 中直接依赖上游包 sublinear-time-solver: ^1.7.0（见 package.json），并在 mcp-tools/index.ts 中挂载了六个工具，其中与本文主题最相关的三个是：

工具名	对应技能文档职责	适用场景
sublinear/page-rank-entry	estimateEntry（单点估计）	只需要一个节点的分数时，避免计算完整解向量
sublinear/solve	solve（全量求解）	需要完整解向量，如批量排序、信任向量物化
sublinear/analyze	analyzeMatrix（诊断）	一致性分数、稀疏度、推荐算法

值得注意的工程细节：插件的求解器桥接层（solver-bridge.ts）在头注释中明确说明，其 Phase 1 实现采用"进程内确定性 forward-push + 小型 CG 求解器"，但对外契约与上游 sublinear-time-solver@1.7.0 完全一致，以便后续可以整体替换为公开的 WASM/原生 crate 版本而不改调用方——这正是 validateTemporalAdvantage 类"验证加速优势"工具存在的意义：先声明复杂度类，再用实测迭代数事后校验（post-hoc observation），两者取更保守（更诚实）的一个上报。

三、场景一：求解前的矩阵属性分析

3.1 标准调用

技能文档给出的第一个使用场景是"求解前先体检"：

// Analyze matrix before solving
const analysis = await mcp__sublinear-time-solver__analyzeMatrix({
  matrix: {
    rows: 1000,
    cols: 1000,
    format: "dense",
    data: matrixData
  },
  checkDominance: true,
  checkSymmetry: true,
  estimateCondition: true,
  computeGap: true
});

// Provide optimization recommendations based on analysis
if (!analysis.isDiagonallyDominant) {
  console.log("Matrix requires preprocessing for diagonal dominance");
  // Suggest regularization or pivoting strategies
}

四个布尔开关分别对应技能文档"Core Capabilities"中的四项能力：checkDominance（对角占优检测）、checkSymmetry（对称性检测）、estimateCondition（条件数估计）、computeGap（谱间隙计算）。

3.2 对角占优判定在仓库中的真实实现

仓库中的"诊断"内核就是 coherence score（一致性分数），其定义在 solver-bridge.ts 的 coherenceScore：

export function coherenceScore(matrix: SparseMatrix): number {
  const rowSums = new Array<number>(matrix.size).fill(0);
  const diag = new Array<number>(matrix.size).fill(0);
  for (const { row, col, value } of matrix.entries) {
    if (row === col) diag[row] = Math.abs(value);
    else rowSums[row] += Math.abs(value);
  }
  let minMargin = Infinity;
  for (let i = 0; i < matrix.size; i++) {
    const d = diag[i];
    if (d === 0) return -Infinity; // a zero diagonal is fatal
    const margin = (d - rowSums[i]) / d;
    if (margin < minMargin) minMargin = margin;
  }
  return Math.min(1, minMargin);
}

这段代码揭示了 checkDominance 的实质：对每一行计算 DD 余量 margin = (|对角元| − Σ|非对角元|) / |对角元|，取所有行的最小值并截断到 (−∞, 1]。几个关键行为：

1. 零对角元直接返回 −∞。注释写明 "a zero diagonal is fatal"——Neumann/Jacobi 迭代每步都要除以对角元（见 neumann 实现），对角元为零意味着算法根本不可行，任何后续预处理建议（正则化、行重排）都应优先处理这一行。
2. score ≥ 0 等价于行对角占优。margin ≥ 0 即 |对角元| ≥ Σ|非对角元|，所以"分析结果为非对角占优"在实现上就是 coherenceScore < 0，与文档中 !analysis.isDiagonallyDominant 分支一一对应。
3. 阈值门控由 coherenceThreshold 参数控制。checkCoherence 返回 { score, passed, threshold } 三元组（类型定义见 types.ts CoherenceReportSchema），其中 threshold = 0 表示禁用门控（wire-compatible default），正数表示要求 DD 余量下限。这与技能文档"Check diagonal dominance and recommend fixes if needed"的最佳实践在机制上完全一致：门控失败时抛出结构化错误 coherence-rejected（见 runPageRank），Agent 据此进入"给出修复建议"分支而非硬解。

3.3 条件数评估与算法选择

estimateCondition 的下游价值在于选择迭代算法。仓库实现把这一点固化成了显式的分支逻辑（runSolve）：

const solver = query.algorithm === 'neumann' ? neumann : conjugateGradient;

其中 algorithm 取值为 'cg' | 'neumann' | 'random-walk'（见 SolveQuerySchema），默认 'cg'。选择依据可直接从两套求解器的数学前提读出：

• CG（共轭梯度）：只对对称正定（SPD）矩阵保证收敛。仓库在 conjugateGradient 中实现的是标准残差驱动 CG（每次迭代做两次稀疏矩阵-向量积 spmv + 标量更新）。
• Neumann（Jacobi-Neumann 迭代）：x_{k+1} = D⁻¹(b − (A − D)x_k（neumann 实现），收敛条件正是对角占优——对角元越大相对非对角元的占比越高，收敛越快。这解释了为什么 solve 工具的描述里写明 "CG (symmetric PD) or Neumann (general DD)"：对称占优矩阵走 CG，一般占优矩阵走 Neumann。
• random-walk：对应技能文档场景三的随机游走式单点估计，在 sublinear/page-rank-entry 工具中落地为 forward-push 实现（下文第四节展开）。

另一个印证"条件数影响性能"的仓库证据来自 ruflo-neural-trader 的 SublinearAdapter：其头注释引用 ADR-123 §162 Row 8 的性能契约——对 n=256 的 SPD 输入（协方差矩阵），Neumann 序列约 50 µs，而 CG 约 816 ns，即上游基准测得的 40–60× 加速。该适配器的 SPD 校验策略也值得参考：协方差矩阵按构造是 Gram 矩阵、天然 SPD，因此只做一个廉价的"方阵 + 对称"体检，失败时不直接报错，而是打上 degraded: true 警告并让调用方回退到旧的 Neumann 路径（见 SolveResult 类型注释）。这正是技能文档"Numerical Stability Assessment"（数值稳定性评估）一项在工程上的具体做法：廉价体检 + 优雅降级 + 结果元数据标注，而不是昂贵的完整特征值分解。

四、场景二：大规模稀疏系统的优化求解

4.1 标准调用（COO 稀疏格式）

技能文档的第二个场景是万级规模的稀疏系统：

// Optimize for large sparse systems
const optimizedSolution = await mcp__sublinear-time-solver__solve({
  matrix: {
    rows: 10000,
    cols: 10000,
    format: "coo",
    data: {
      values: sparseValues,
      rowIndices: rowIdx,
      colIndices: colIdx
    }
  },
  vector: rhsVector,
  method: "neumann",
  epsilon: 1e-8,
  maxIterations: 1000
});

三个参数的作用与实现对应关系：

• format: "coo"（COO, Coordinate format）：values / rowIndices / colIndices 三元组即 COO 稀疏存储。这与仓库 SparseMatrixSchema 的 entries: [{ row, col, value }] 是同一种思想的两种线协议（wire shape）——仓库实现额外带了 graphId、nodeIndex（节点名→行号）和 indexNode（行号→节点名）双向映射，让调用方可以用领域标识符而非裸行号与矩阵交互。
• epsilon：残差 L2 范数收敛目标。对照仓库中 neumann 的收敛判据，每轮迭代末计算 r = b − A·x 并检查 ||r||₂ < epsilon。文档示例取 1e-8，仓库默认取 1e-8（options: { epsilon: number } = { epsilon: 1e-8 }）。经验上：epsilon 每收紧一个数量级，Neumann 在弱占优矩阵上可能要多跑若干轮迭代，因此技能文档"Set convergence criteria based on problem requirements"的最佳实践是——先按业务精度需求定 epsilon，不要用默认值糊弄。
• maxIterations：硬上限，防止弱占优/病态输入下迭代不收敛。仓库实现同样有该参数（neumann options.maxIter，默认 256；CG 的 maxIter 默认为 n），达到上限即返回当前解与末次残差，由上层判断残差是否可接受。

4.2 求解结果的"诚实性"：实测复杂度类

技能文档要求 Agent 能"Predict solver convergence and performance characteristics"。仓库实现把这一点做成了结果内嵌的审计字段：每次求解都会记录实际迭代次数，并通过 observedComplexity 事后归类到 12 级复杂度体系：

export function observedComplexity(iterations: number, n: number): ComplexityClass {
  if (iterations <= 1) return 'constant';
  if (iterations <= Math.ceil(Math.log2(Math.max(2, n)))) return 'logarithmic';
  if (iterations <= Math.ceil(Math.pow(Math.log2(Math.max(2, n)), 2))) return 'polylogarithmic';
  if (iterations < n) return 'sublinear';
  if (iterations < n * Math.log2(Math.max(2, n))) return 'linear';
  if (iterations < n * n) return 'linearithmic';
  return 'polynomial';
}

完整的 12 级分类（constant → logarithmic → polylogarithmic → sublinear → linear → linearithmic → polynomial → exponential → doubleExponential → adaptive → unknown → unbounded）定义在 types.ts 的 ComplexityClassSchema，注释标明它对齐上游 sublinear-time-solver@1.7.0 的分类法。adaptive 类附带一个 AdaptiveBound { default, worst } 二元组，同时上报默认与最坏情况。

这套机制与 validateTemporalAdvantage 工具的意图一致：声称的子线性优势必须被实测数据背书。求解结果 SolveResult 会携带 iterations、complexityClass（实测所得）、coherence 报告与 residualNorm（见 SolveResultSchema），调用方可以直接回答"这次求解是否真的落在子线性区间内、加速优势是否成立"。

4.3 复杂度预算：把"性能承诺"变成可拒绝的契约

技能文档 Best Practices 中"Monitor computational resources during operations"在仓库中有一条硬执行路径——复杂度预算门控。每个求解查询都接受 maxComplexityClass（默认 linear，见 PageRankQuerySchema 注释 "Budget gate. Default linear (tier-2-safe)"），求解完成后执行 fitsBudget 检查：

/** Is `actual` within `budget`? */
export function fitsBudget(actual: ComplexityClass, budget: ComplexityClass): boolean {
  return COMPLEXITY_RANK[actual] <= COMPLEXITY_RANK[budget];
}

排序规则（COMPLEXITY_RANK）把 12 个类映射为可比较的成本等级，adaptive 默认按 linear 计、unknown 按 8 计（保守）。若实测类超出预算，runSolve 直接抛出结构化错误：

throw {
  kind: 'complexity-budget-exceeded',
  message: `observed ${obs} exceeds budget ${query.maxComplexityClass}`,
  recoverable: true,
  requiredClass: obs,
  requestedClass: query.maxComplexityClass,
};

错误是 recoverable: true 且附带 requiredClass/requestedClass 两个字段——Agent 收到后可以明确告诉用户"该矩阵实际需要 linearithmic 级预算，而你只给了 linear，建议要么放宽预算、要么做预处理提升占优性"。这正是技能文档中"Optimization Recommendations"职责的机器可执行形态。完整的结构化错误分类（complexity-budget-exceeded / coherence-rejected / graph-not-found / invalid-input / solver-failed / not-applicable）定义在 types.ts 末尾，每类错误都带 recoverable 标志，供 Agent 决策"重试/换算法/降级/放弃"。

五、场景三：单点分量估计——不求解整个系统

技能文档的第三个场景是"只估计解向量的特定分量，而不做全量求解"：

// Estimate specific solution entries without full solve
const entryEstimate = await mcp__sublinear-time-solver__estimateEntry({
  matrix: systemMatrix,
  vector: rhsVector,
  row: targetRow,
  column: targetCol,
  method: "random-walk",
  epsilon: 1e-6,
  confidence: 0.95
});

这是整个技能里最具子线性算法特色的能力。仓库中它的完整实现是 singleEntryPageRank（forward-push），头注释精确解释了为什么它在 DD 图上是子线性的：

On a DD graph (which our (I − αP^T)π = e_seed rewriting always is for α<1) this is sublinear: only nodes within the active push-frontier are touched. Guarantee: result is within ε of the true PR score.

实现要点有三，值得逐条对照理解：

1. 残差驱动（residual-driven）：维护残差向量 r，每轮只"唤醒" r[u] > eps 的节点（L103-L104），把阻尼质量 (1−α)·ru 计入解、把 α·ru 按出度比例分发给邻居。未被触及的节点完全不做浮点运算——这是"只碰活跃前沿"子线性性质的直接体现。
2. 个性化种子：seedNodes 非空时，重启分布（restart distribution）集中到种子上（每个种子分得 1/len(seeds) 的质量）；否则退化为均匀分布。这使单点估计天然支持"相对于某个种子集合，这个节点有多重要"这类查询。
3. 迭代上限有理论下界：maxIter = max(64, 4·log(1/ε)/log(1/(1−α)))（L98）——注意它只依赖 ε 和 α，与矩阵规模 n 无关，这是 α<1 时 forward-push 在占优系统上对数级收敛的工程化表达。对照技能文档的 confidence: 0.95 参数：单点估计的置信度由 ε 与 α 共同决定，收紧 ε 即提高置信，但代价是更多的 push 轮次。

对应地，sublinear/page-rank-entry 工具 的描述直接给出了选型建议："Use when you need a relevance/centrality score for ONE node … without computing the full PR vector"——单点查询用 page-rank-entry，全量解向量才用 solve。返回的 PageRankResult 包含 score、iterations、complexityClass、coherence，以及一个对 (graphId, nodeId, alpha, epsilon, seedNodes, score) 做 SHA-256 的 resultHash（hashResult），用于确定性记忆化（memoization）：同样的查询、同样的分数，产生同样的哈希，可直接命中缓存。

六、与 Claude Flow swarm 及 Flow Nexus 沙箱的集成

6.1 Swarm 协同的三个切入点

技能文档在"Integration with Claude Flow"一节定义了矩阵优化能力与 swarm 的三种结合方式：

• Matrix Distribution（矩阵分发）：把大规模矩阵运算分发到多个 swarm agent 上分片执行；
• Parallel Analysis（并行分析）：协调并行的矩阵属性分析（多个 Agent 各查一部分行/块的对角占优与对称性）；
• Consensus Building（共识构建）：把矩阵分析结果用作 swarm 共识机制的输入。

性能优化一侧则给出：基于矩阵属性做资源分配、跨计算节点的负载均衡、面向大规模矩阵的内存管理。仓库中这类"分发 + 联邦"的执行面由 federation 相关模块承接（可参见 federation 文档），矩阵优化 Agent 负责的是其中的数值内核与质量门控。

6.2 Flow Nexus 沙箱部署

技能文档提供了在 Flow Nexus 沙箱中隔离运行矩阵优化的完整示例：

// Deploy matrix optimization in Flow Nexus sandbox
const sandbox = await mcp__flow-nexus__sandbox_create({
  template: "python",
  name: "matrix-optimizer",
  env_vars: {
    MATRIX_SIZE: "10000",
    SOLVER_METHOD: "neumann"
  }
});

// Execute matrix optimization
const result = await mcp__flow-nexus__sandbox_execute({
  sandbox_id: sandbox.id,
  code: `
    import numpy as np
    from scipy.sparse import coo_matrix

    # Create test matrix with diagonal dominance
    n = int(os.environ.get('MATRIX_SIZE', 1000))
    A = create_diagonally_dominant_matrix(n)

    # Analyze matrix properties
    analysis = analyze_matrix_properties(A)
    print(f"Matrix analysis: {analysis}")
  `,
  language: "python"
});

这个模式的设计意图与技能文档 Integration Guidelines 第 2 条"use Flow Nexus sandboxes for isolated matrix operations"一致：矩阵运算往往内存密集（n=10000 的 dense 矩阵约 800MB float64），沙箱隔离既防止宿主机内存被击穿，也约束了失败爆炸半径。env_vars 传 MATRIX_SIZE 与 SOLVER_METHOD，让同一份沙箱代码可以在不同规模/算法下参数化复测——这实际上就是"性能预测 + 验证"闭环的载体：先跑小矩阵验证分析逻辑，再放大规模验证性能预测。

文档还列出了与神经网络的集成点：训练数据矩阵优化、权重矩阵稳定性分析、梯度计算矩阵优化。仓库中与这一方向最近的落地是 ruflo-neural-trader：它把组合优化中的均值-方差问题 Σ·x = μ 识别为"SPD 线性系统"（协方差矩阵 Σ 是 Gram 矩阵、按构造 SPD），从而合法地交给 CG 求解器——这是"权重/协方差矩阵 → 子线性求解"路径在生产代码中的一个具体实例。

七、高级能力：预处理、监控与误差分析

技能文档的"Advanced Features"一节定义了三个高级能力域，结合仓库实现可以给出各自的工程对应：

1. 矩阵预处理（Matrix Preprocessing）

• Diagonal Dominance Enhancement（占优性增强）：把非占优矩阵变换为占优矩阵。从 coherenceScore 的实现可以直接读出操作空间——margin 最小的行就是攻击目标，常见手段是对该行加正则项（增大对角元）或做行/列重排。
• Condition Number Reduction（条件数降低）：预条件（preconditioning）。Jacobi-Neumann 迭代本身就是以对角阵 D 为预条件的迭代（D⁻¹ 显式出现在更新式中），因此"诊断 margin、选择 D"正是预条件设计的直接体现。
• Sparsity Pattern Optimization（稀疏模式优化）：仓库的 SparseMatrix 契约（COO entries + 双向前缀索引）即为稀疏存储模式优化的落点，存储非零元而非稠密全阵。

2. 性能监控（Performance Monitoring）

• Convergence Tracking（收敛跟踪）：SolveResult 中的 iterations + residualNorm 字段对，允许在每次求解后记录"多少轮迭代、残差压到多少"，跨运行对比收敛曲线；
• Memory Usage / Computational Cost：稀疏存储 + 复杂度类审计（第四节）分别对应内存与计算成本的量化。

3. 误差分析（Error Analysis）

• Numerical Stability Assessment：coherence 门控 + SPD 廉价体检 + degraded 降级标注（见 3.3 节）；
• Error Propagation Tracking：残差 L2 范数 ||A·x − b||₂ 是迭代法误差传播的直接上界观测量，仓库所有求解函数都强制返回它；
• Precision Requirements：epsilon 即精度需求的显式参数化。

八、最佳实践与五阶段流水线

技能文档"Best Practices"一节的完整清单（原文三条准备 + 四条性能 + 四条集成）值得原样保留并对照仓库机制逐条理解：

矩阵准备（Matrix Preparation）

1. 求解前必须先分析矩阵属性 —— 对应 analyze 工具与 coherence 门控（runSolve 在求解前强制 checkCoherence）；
2. 检查对角占优，必要时给出修复建议 —— 对应 coherence-rejected 错误 + Agent 建议分支；
3. 估计条件数以评估稳定性 —— 对应 CG/Neumann 算法选择逻辑；
4. 考虑稀疏模式以提升内存效率 —— 对应 COO/SparseMatrix 存储契约。

性能优化（Performance Optimization）

1. 按矩阵属性选求解方法 —— algorithm: 'cg' | 'neumann' 分支；
2. 按问题需求设定收敛判据 —— epsilon 参数化；
3. 运算期间监控计算资源 —— maxIterations 硬上限 + 迭代计数上报；
4. 大规模运算实现检查点（checkpointing）—— 对应 solveOnChange / sublinear/solve-on-change：当矩阵发生稀疏变化时，只需对增量 A·dx = δ 求解再叠加 x_new = x_prev + dx，避免全量重解——这正是"检查点 + 增量恢复"的数值形态（类型契约 SolveOnChangeQuerySchema）。

集成规范（Integration Guidelines）

1. 与其他 Agent 协同做分布式运算；
2. 用 Flow Nexus 沙箱做隔离矩阵运算（第六节）；
3. 利用 swarm 能力做并行处理；
4. 实现完善的错误处理与恢复机制 —— 对应 6 类结构化错误 + recoverable 标志。

完整优化流水线（五阶段），即文档"Example Workflows"部分：

1. Analysis Phase：分析矩阵属性与结构（analyzeMatrix）；
2. Preprocessing Phase：施加必要的变换与优化（正则化、预条件、稀疏化）；
3. Solving Phase：执行优化后的子线性求解算法（solve）；
4. Validation Phase：验证结果与性能指标（残差、实测复杂度类、validateTemporalAdvantage）；
5. Optimization Phase：基于性能数据精化参数（调 epsilon、换算法、改预处理）。

文档最后列出了该 Agent 的协作面：与 consensus-coordinator（分布式矩阵运算）、performance-optimizer（系统级优化）、trading-predictor（金融矩阵计算）、pagerank-analyzer（图矩阵优化）协作。文档结尾的定位语概括了它在体系中的角色："The Matrix Optimizer Agent serves as the foundation for all matrix-based operations in the sublinear solver ecosystem, ensuring optimal performance and numerical stability across all computational tasks."

九、延伸阅读与验证路径

想继续深入仓库源码，建议按以下路径：

• 求解器内核与复杂度审计：solver-bridge.ts（forward-push PageRank、CG/Neumann 双求解器、solveOnChange、hashResult）；
• 线协议类型契约：types.ts（SparseMatrix、12 级 ComplexityClass、CoherenceReport、结构化错误）；
• MCP 工具面：mcp-tools/index.ts（sublinear/page-rank-entry、sublinear/solve、sublinear/solve-on-change、sublinear/analyze 等六个工具的输入 Schema）；
• 生产级性能契约：sublinear-adapter.ts 头注释中对 ADR-123 §162 Row 8 的 40–60× CG 加速引用、SPD 校验与降级策略；架构决策背景见 ADR-123；
• 回归测试：mcp-tools.test.ts 覆盖了工具面的行为契约。

需要提醒的适用前提：本文中的 MCP 工具名以当前仓库的实际挂载形态为准（sublinear/* 前缀，见 mcp-tools/index.ts）；技能文档中 mcp__sublinear-time-solver__* 系列工具名来自上游包的发布面，两套命名在仓库中并存（插件依赖 sublinear-time-solver@^1.7.0，而求解桥接层以契约兼容方式本地实现）。若你运行 sublinear-time-solver 未安装或未注册 MCP 插件，技能文档中的调用将以"工具不存在"失败——此时可参照 sublinear-adapter.ts 的双探针检测模式（探测全局工具挂载 + 环境变量 RUFLO_SUBLINEAR_NATIVE 覆盖）判断当前运行时是否具备原生求解面，不具备时回退到本地 JS CG 内核并保持相同的输入/输出形状。