ruflo 次线性 GOAP 目标规划智能体（sublinear-goal-planner）：状态空间建模、A* 搜索与多智能体协调实战指南

ruflo 仓库在 .claude/agents/reasoning/agent.md 中定义了一个名为 sublinear-goal-planner 的目标导向行动规划（Goal-Oriented Action Planning，GOAP）智能体，它将游戏 AI 的规划思想、图论与矩阵线性代数、次线性时间求解器以及多智能体群（swarm）协调统一到"目标 → 行动序列"的自动化决策链路中。本文将以该关联文档为骨架，结合仓库内专职 sublinear 智能体定义与 ADR 文档，完整拆解其状态空间建模、行动图构建、PageRank 目标优先级排序、时间优势预测规划（temporal advantage planning）、A* 搜索、OODA 动态重规划等核心方法，并给出可直接落地的参数说明与工程实践建议。读完本文，你将掌握如何把任意复杂目标分解为可执行、可优化、可自适应重规划的行动序列，并理解次线性矩阵求解与多智能体编排在此过程中各自承担的职责。

关联文档同时以镜像形式存在于 plugin/agents/reasoning/agent.md，二者内容一致；配套的简化版提示词变体见 .claude/agents/reasoning/goal-planner.md。

1. 智能体定位：一份带"数学求解器"的 GOAP 规划专家

文档 frontmatter 将本智能体命名为 sublinear-goal-planner，其职责描述为：面向复杂目标动态生成智能计划的 GOAP 专家，借助游戏 AI 技术，通过"创造性地组合行动"来发现新解；擅长自适应重规划、多步推理，以及在复杂状态空间中找到最优路径。

与"纯 LLM 推理式规划"不同，该智能体的核心差异在于引入次线性时间求解器作为规划引擎：把"目标—行动"关系表达成矩阵/图，再用基于对角占优系统（diagonally dominant system）的线性代数求解来完成成本收益分析、优先级排序与预测性行动执行。文档原文对此做了三点概括：

• 将高层目标转换为可执行行动序列，依赖数学优化；
• 通过时间优势预测（temporal advantage prediction） 提前应对未来状态；
• 通过多智能体协调分担复杂目标的求解。

这一架构立场在仓库的 ADR-123 图智能引擎集成说明 中得到了呼应：该 ADR 明确将 ruflo 的智能层描述为"复杂度感知执行（complexity-aware execution）"——只计算"变化到足以产生影响"的部分，只计算运行时预算允许的深度，只计算仍然承重的关联。换言之，sublinear-goal-planner 正是"图智能/复杂度治理"这套架构在单智能体规划任务上的具体体现。

1.1 与专职 sublinear 智能体群的分工

仓库 plugin/agents/sublinear/ 目录下存在一组与该智能体共享同一套 MCP 工具的专职专家，可作为理解本智能体"谁在提供什么能力"的对照：

专职智能体	对应文档	与本 GOAP 智能体的关系
matrix-optimizer（矩阵优化）	plugin/agents/sublinear/matrix-optimizer.md	负责 analyzeMatrix、solve、estimateEntry 等矩阵预处理与求解前的性质分析（对角占优、对称性、条件数）
pagerank-analyzer（优先级分析）	plugin/agents/sublinear/pagerank-analyzer.md	对应本智能体的 PageRank 目标/行动优先级排序能力
consensus-coordinator（共识协调）	plugin/agents/sublinear/consensus-coordinator.md	对应本智能体的"基于共识的决策"工作流
performance-optimizer（性能优化）	plugin/agents/sublinear/performance-optimizer.md	覆盖规划方案的性能与资源分配优化
trading-predictor（预测交易）	plugin/agents/sublinear/trading-predictor.md	时间优势预测的典型应用场景（在数据到达前行动）

也就是说，sublinear-goal-planner 可视作在规划语境下组合调用上述工具能力的"总规划师"。

2. 五大核心能力

文档将智能体能力划分为五个维度，它们是后文所有工作流的抽象来源。

动态目标分解（Dynamic Goal Decomposition）

• 基于依赖分析的分层目标拆解；
• 以图表示"目标—行动"关系；
• 自动识别前置条件与依赖；
• 上下文感知的目标优先级排序与串行化。

次线性优化（Sublinear Optimization）

• 用矩阵运算做行动—状态图优化；
• 通过对角占优系统求解做成本收益分析；
• 以极低计算开销实现实时计划优化；
• 面向预测性行动执行的"时间优势规划"。

智能优先级排序（Intelligent Prioritization）

• 基于 PageRank 的行动与目标优先级计算；
• 带加权准则的多目标优化；
• 面向时间敏感目标的关键路径识别；
• 跨竞争目标的资源分配优化。

预测性规划（Predictive Planning）

• 面向未来状态预测的时间计算优势；
• 在条件真正出现前进行主动行动规划；
• 风险评估与应急计划生成；
• 基于实时反馈的自适应重规划。

多智能体协调（Multi-Agent Coordination）

• 通过群（swarm）协调实现分布式目标达成；
• 面向并行目标执行的负载均衡；
• 面向共享目标状态的智能体间通信；
• 面向冲突目标的基于共识的决策。

3. MCP 工具链：求解器与编排两类工具

3.1 次线性求解器工具（sublinear-time-solver）

这是该智能体的"数学内核"。文档列出了以下 7 个工具及用途：

工具名	用途
mcp__sublinear-time-solver__solve	优化行动序列与资源分配
mcp__sublinear-time-solver__pageRank	基于重要性对目标与行动排序
mcp__sublinear-time-solver__analyzeMatrix	分析目标依赖与系统性质
mcp__sublinear-time-solver__predictWithTemporalAdvantage	在数据到达前预测未来状态
mcp__sublinear-time-solver__estimateEntry	高效评估部分状态信息
mcp__sublinear-time-solver__calculateLightTravel	为时间关键型规划计算时间优势
mcp__sublinear-time-solver__demonstrateTemporalLead	验证预测性规划场景

配套专职智能体文档还使用了第 8 个工具 mcp__sublinear-time-solver__validateTemporalAdvantage（matrix-optimizer.md 与 trading-predictor.md 均有引用），用于校验规划方案的时间可行性。

命名约定提示：仓库文档中对同一工具存在 kebab-case（sublinear-time-solver）与 snake_case（sublinear_time_solver）两种写法，这是 MCP 工具名中连字符与下划线混用的常见历史现象。本文统一按工具清单的规范名书写；在实际配置环境中应以其 MCP server 注册名称为准。

3.2 Claude Flow 编排工具（flow-nexus）

求解器解决"怎么优化"，编排工具解决"谁来执行"。文档列出的 flow-nexus 工具与用途对应关系如下：

工具名	用途
mcp__flow-nexus__swarm_init	初始化多智能体执行系统
mcp__flow-nexus__task_orchestrate	执行已规划的行动序列
mcp__flow-nexus__agent_spawn	为特定目标创建专职智能体
mcp__flow-nexus__workflow_create	定义可复用的目标达成模式
mcp__flow-nexus__sandbox_create	创建隔离环境用于目标测试

flow-nexus 生态在仓库中有对应实现目录：plugin/agents/flow-nexus/（9 个智能体定义）、plugin/commands/flow-nexus/（9 个命令）以及 plugin/skills/flow-nexus-platform/ 等技能，它们共同支撑文档中 swarm_init / agent_spawn / task_orchestrate 之类的编排语义。

4. 核心规划工作流（五步法）

以下五个步骤构成文档定义的"规划主线"：建模状态空间 → 构建行动图 → 优先级排序 → 时间优势预测 → 搜索最优路径。

4.1 第一步：状态空间建模

规划的第一步是把目标与现状形式化。文档给出的世界状态以键值 Map 表达：current_state 记录"当前为假/真"，goal_state 记录"目标为真"。一个典型的软件交付目标被拆为四个布尔命题：code_written（代码已写）、tests_passing（测试通过）、documentation_complete（文档齐全）、deployment_ready（可部署）。

行动定义的核心是三元组：name（名称）、cost（成本，用于路径代价）、preconditions（前置条件，决定何时可应用）+ effects（效果，施加到状态上）。例如 deploy_application 成本为 4，前置条件是前三者全为真，效果是 deployment_ready=true。这在语义上等价于经典规划（STRIPS/PDDL）中的 operator 定义：

// World state representation
const WorldState = {
  current_state: new Map([
    ['code_written', false],
    ['tests_passing', false],
    ['documentation_complete', false],
    ['deployment_ready', false]
  ]),
  goal_state: new Map([
    ['code_written', true],
    ['tests_passing', true],
    ['documentation_complete', true],
    ['deployment_ready', true]
  ])
};

// Action definitions with preconditions and effects
const Actions = [
  {
    name: 'write_code',
    cost: 5,
    preconditions: new Map(),
    effects: new Map([['code_written', true]])
  },
  {
    name: 'write_tests',
    cost: 3,
    preconditions: new Map([['code_written', true]]),
    effects: new Map([['tests_passing', true]])
  },
  {
    name: 'write_documentation',
    cost: 2,
    preconditions: new Map([['code_written', true]]),
    effects: new Map([['documentation_complete', true]])
  },
  {
    name: 'deploy_application',
    cost: 4,
    preconditions: new Map([
      ['code_written', true],
      ['tests_passing', true],
      ['documentation_complete', true]
    ]),
    effects: new Map([['deployment_ready', true]])
  }
];

这一建模方式的关键收益是状态可比较、行动可校验：任何"写完计划"的动作都可以被机器检查前置条件是否满足，这正是后续 A* 搜索能够机械执行的基础。

4.2 第二步：行动图构建与矩阵分析

把行动间的迁移关系编码为邻接矩阵，是"次线性优化"介入的入口。文档给出的 buildActionGraph 实现要点：

• 当行动 i 在给定世界状态下可迁移到行动 j（canTransition 为真）时，邻接权重记为 1 / cost[j]——成本越低权重越高，从而让求解器天然偏好低成本路径；
• 对矩阵调用 analyzeMatrix 并开启 checkDominance: true（检查对角占优）、estimateCondition: true（估计条件数），这正是为后续"对角占优系统快速求解"铺路。

// Build adjacency matrix for sublinear optimization
async function buildActionGraph(actions, worldState) {
  const n = actions.length;
  const adjacencyMatrix = Array(n).fill().map(() => Array(n).fill(0));

  // Calculate action dependencies and transitions
  for (let i = 0; i < n; i++) {
    for (let j = 0; j < n; j++) {
      if (canTransition(actions[i], actions[j], worldState)) {
        adjacencyMatrix[i][j] = 1 / actions[j].cost; // Weight by inverse cost
      }
    }
  }

  // Analyze matrix properties for optimization
  const analysis = await mcp__sublinear_time_solver__analyzeMatrix({
    matrix: {
      rows: n,
      cols: n,
      format: "dense",
      data: adjacencyMatrix
    },
    checkDominance: true,
    checkSymmetry: false,
    estimateCondition: true
  });

  return { adjacencyMatrix, analysis };
}

仓库层面，矩阵分析是专职 matrix-optimizer 的本职。plugin/agents/sublinear/matrix-optimizer.md 将其细化为四件事：性质检测（对角占优/对称性/结构性质）、条件评估（条件数与谱隙，用于判断求解器稳定性）、优化建议（矩阵变换与预处理）、性能预测（求解器收敛性）。ADR-123 进一步佐证：其求解上游（sublinear-time-solver）的正交对角占优（SDD）系统求解可追溯至 Andoni–Krauthgamer–Pogrow（ITCS 2019）等学术工作——即文档中的"对角占优系统求解"并非虚构，而是确有学术谱系的算法族。

4.3 第三步：基于 PageRank 的目标优先级排序

在多目标并存时，prioritizeGoals 用 pageRank 工具给每个目标打分排序，damping（阻尼系数）默认 0.85（与经典 PageRank 一致），epsilon 收敛阈值为 1e-6。

async function prioritizeGoals(actionGraph, goals) {
  // Use PageRank to identify critical actions and goals
  const pageRank = await mcp__sublinear_time_solver__pageRank({
    adjacency: {
      rows: actionGraph.length,
      cols: actionGraph.length,
      format: "dense",
      data: actionGraph
    },
    damping: 0.85,
    epsilon: 1e-6
  });

  // Sort goals by importance scores
  const prioritizedGoals = goals.map((goal, index) => ({
    goal,
    priority: pageRank.ranks[index],
    index
  })).sort((a, b) => b.priority - a.priority);

  return prioritizedGoals;
}

参数含义补充：

• damping：阻尼系数，越低越"局部"，越高越偏向全网重要性，0.85 是链接分析领域的事实标准取值；
• epsilon：迭代收敛容差，1e-6 意味着排名计算会迭代到残差低于该量级才停止；
• format: "dense"：稠密矩阵表示；文档"最佳实践"章节提醒，当行动网络规模很大时应改用稀疏表示以节省内存与计算（详见 §8.4）。

在仓库语境中，个性化 PageRank 正是 ADR-123 定义的"关系智能"技术基元（single-entry personalized PageRank、sparse propagation / forward-push），本智能体把这一基元用在目标优先级这一具体任务上。

4.4 第四步：时间优势预测规划

这是全文最具"前瞻性"的一步：planWithTemporalAdvantage 先调用 predictWithTemporalAdvantage，基于矩阵与约束向量预测"完整问题显形之前"的可行解，再用 validateTemporalAdvantage 校验其时间可行性。distanceKm 参数代表协同/数据传播距离（文档示例 12000km，对应全球协同尺度）：

async function planWithTemporalAdvantage(planningMatrix, constraints) {
  // Predict optimal solutions before full problem manifestation
  const prediction = await mcp__sublinear_time_solver__predictWithTemporalAdvantage({
    matrix: planningMatrix,
    vector: constraints,
    distanceKm: 12000 // Global coordination distance
  });

  // Validate temporal feasibility
  const validation = await mcp__sublinear_time_solver__validateTemporalAdvantage({
    size: planningMatrix.rows,
    distanceKm: 12000
  });

  if (validation.feasible) {
    return {
      solution: prediction.solution,
      temporalAdvantage: prediction.temporalAdvantage,
      confidence: prediction.confidence
    };
  }

  return null;
}

设计逻辑：计算速度可能快于信息的物理传播速度（例如跨越长距离的市场数据或远端状态变更），因此若计算能在数据到达前完成，就获得了"时间优势"。第 6.2 节的动态重规划会以 confidence > 0.8 作为是否采纳预测计划的阈值。文档"Advanced Features"中的"Temporal Computational Advantage"一段将其目标概括为：在远端数据到达前行动、用未来信息优化资源配置、以时间精度协调全球操作。trading-predictor 是该能力在金融场景的专职化：用 calculateLightTravel({ distanceKm }) 计算跨市场（如东京—纽约）的传输时延并据此提前建仓，是对同一 API 语义的复用佐证。

4.5 第五步：A* 搜索 + 次线性启发式优化

当目标无法一步到位时，智能体回退到经典的图搜索范式。findOptimalPath 是标准 A*（open set / closed set / gScore / fScore / cameFrom 回溯），但在两点上做了 GOAP 定制：

• 邻居生成并非预置拓扑，而是动态执行 getApplicableActions(current, actions)，即只有前置条件满足的行动才会展开，因此搜索空间被前置条件实时裁剪；
• 启发式函数 optimizedHeuristic 会借助次线性求解器估算，将"距离目标的数学距离"替换为"求解器给出的优化估计"，从而让 A* 的剪枝更贴合矩阵模型。

async function findOptimalPath(startState, goalState, actions) {
  const openSet = new PriorityQueue();
  const closedSet = new Set();
  const gScore = new Map();
  const fScore = new Map();
  const cameFrom = new Map();

  openSet.enqueue(startState, 0);
  gScore.set(stateKey(startState), 0);
  fScore.set(stateKey(startState), heuristic(startState, goalState));

  while (!openSet.isEmpty()) {
    const current = openSet.dequeue();
    const currentKey = stateKey(current);

    if (statesEqual(current, goalState)) {
      return reconstructPath(cameFrom, current);
    }

    closedSet.add(currentKey);

    // Generate successor states using available actions
    for (const action of getApplicableActions(current, actions)) {
      const neighbor = applyAction(current, action);
      const neighborKey = stateKey(neighbor);

      if (closedSet.has(neighborKey)) continue;

      const tentativeGScore = gScore.get(currentKey) + action.cost;

      if (!gScore.has(neighborKey) || tentativeGScore < gScore.get(neighborKey)) {
        cameFrom.set(neighborKey, { state: current, action });
        gScore.set(neighborKey, tentativeGScore);

        // Use sublinear solver for heuristic optimization
        const heuristicValue = await optimizedHeuristic(neighbor, goalState);
        fScore.set(neighborKey, tentativeGScore + heuristicValue);

        if (!openSet.contains(neighbor)) {
          openSet.enqueue(neighbor, fScore.get(neighborKey));
        }
      }
    }
  }

  return null; // No path found
}

5. 多智能体协调：swarm 编排与共识决策

单个规划器负责"想"，分布式执行则需要 swarm 负责"做"。

5.1 基于 swarm 的规划

coordinateWithSwarm 展示了如何围绕一个复杂目标建立规划群：以 topology: "hierarchical"、maxAgents: 8、strategy: "adaptive" 初始化，再按职责 spawn 三类智能体——coordinator（目标分解与计划合成）、analyst（约束分析与可行性评估）、optimizer（路径优化与资源分配），最后用 task_orchestrate 以 strategy: "parallel"、priority: "high" 分派并行规划任务：

async function coordinateWithSwarm(complexGoal) {
  // Initialize planning swarm
  const swarm = await mcp__claude_flow__swarm_init({
    topology: "hierarchical",
    maxAgents: 8,
    strategy: "adaptive"
  });

  // Spawn specialized planning agents
  const coordinator = await mcp__claude_flow__agent_spawn({
    type: "coordinator",
    capabilities: ["goal_decomposition", "plan_synthesis"]
  });

  const analyst = await mcp__claude_flow__agent_spawn({
    type: "analyst",
    capabilities: ["constraint_analysis", "feasibility_assessment"]
  });

  const optimizer = await mcp__claude_flow__agent_spawn({
    type: "optimizer",
    capabilities: ["path_optimization", "resource_allocation"]
  });

  // Orchestrate distributed planning
  const planningTask = await mcp__claude_flow__task_orchestrate({
    task: `Plan execution for: ${complexGoal}`,
    strategy: "parallel",
    priority: "high"
  });

  return { swarm, planningTask };
}

要点：

• topology 可取 hierarchical、mesh 等，决定智能体之间的通信/汇报结构；
• strategy 可取 adaptive、parallel、specialized 等，决定编排策略（详见 §7 各示例中的不同取值）；
• spawn 的 type + capabilities 是"按需组建团队"的抽象——不同目标只需换一组能力词条。

5.2 基于共识的决策

当多个智能体对同一批候选方案意见不一（例如冲突目标间争抢资源），achieveConsensus 用"共识矩阵求解"来调和：把每个智能体对各方案的偏好编码进矩阵，调用 solve（method: "neumann"、epsilon: 1e-6，Neumann 级数迭代法适合对角占优系统），取解向量中得分最高的提案并报告收敛时间：

async function achieveConsensus(agents, proposals) {
  // Build consensus matrix
  const consensusMatrix = buildConsensusMatrix(agents, proposals);

  // Solve for optimal consensus
  const consensus = await mcp__sublinear_time_solver__solve({
    matrix: consensusMatrix,
    vector: generatePreferenceVector(agents),
    method: "neumann",
    epsilon: 1e-6
  });

  // Select proposal with highest consensus score
  const optimalProposal = proposals[consensus.solution.indexOf(Math.max(...consensus.solution))];

  return {
    selectedProposal: optimalProposal,
    consensusScore: Math.max(...consensus.solution),
    convergenceTime: consensus.convergenceTime
  };
}

method: "neumann" 的语义：迭代展开 (I - A)^(-1) 的 Neumann 级数，在对角占优条件下收敛快速且无需显式求逆——这正是文档反复强调"对角占优系统"的真正原因。convergenceTime 用于观察多智能体意见收敛的代价，可作为规划质量 KPI。

6. 高级规划工作流：分解、重规划与学习

如果说 §4–§5 是"一次规划"，本节则是"规划的全生命周期"。

6.1 层级目标分解 + 依赖排序

decomposeGoal 的思路：先在 sandbox（template: "node"，环境变量注入 GOAL_CONTEXT 与序列化后的 CONSTRAINTS）中模拟目标，再做最多 3 层的递归分解（recursiveDecompose(complexGoal, 0, 3)），把子目标关系建成依赖矩阵，最后用 PageRank（damping: 0.9）对子目标排序以确定执行顺序，并估算完成时间：

async function decomposeGoal(complexGoal) {
  // Create sandbox for goal simulation
  const sandbox = await mcp__flow_nexus__sandbox_create({
    template: "node",
    name: "goal-decomposition",
    env_vars: {
      GOAL_CONTEXT: complexGoal.context,
      CONSTRAINTS: JSON.stringify(complexGoal.constraints)
    }
  });

  // Recursive goal breakdown
  const subgoals = await recursiveDecompose(complexGoal, 0, 3); // Max depth 3

  // Build dependency graph
  const dependencyMatrix = buildDependencyMatrix(subgoals);

  // Optimize execution order
  const executionOrder = await mcp__sublinear_time_solver__pageRank({
    adjacency: dependencyMatrix,
    damping: 0.9
  });

  return {
    subgoals: subgoals.sort((a, b) =>
      executionOrder.ranks[b.id] - executionOrder.ranks[a.id]
    ),
    dependencies: dependencyMatrix,
    estimatedCompletion: calculateCompletionTime(subgoals, executionOrder)
  };
}

工程含义：

• 递归深度上限（3） 防止目标爆炸式展开，配合"增量更新而非整体重建"（§8.4）可控制规划成本；
• sandbox 先行：在隔离环境验证分解与效果，避免污染真实世界状态；
• 分解深度与优先级排序是两层职责：分解负责"切分"，PageRank 负责"排程"。

6.2 动态重规划：OODA 闭环的 1 秒循环

DynamicPlanner 将军事决策环 OODA（Observe→Orient→Decide→Act）实现为一个 1000ms 心跳的监控循环：

• Observe：检测世界状态变化并更新内部世界模型；
• Orient：分析实际状态与预期的偏差，若偏差显著则标记"需重规划"；
• Decide：判断是否需要重规划，需要则调用重规划；
• Act：执行当前计划的下一个行动（若有）；
• Replan：用时间优势规划生成新计划，仅当 confidence > 0.8 才采纳；同时把"触发原因 + 新方案 + 世界状态快照"写入 goap-patterns 命名空间（mcp__claude_flow__memory_usage, action: "store"），沉淀为可复用模式。

class DynamicPlanner {
  constructor() {
    this.currentPlan = null;
    this.worldState = new Map();
    this.monitoringActive = false;
  }

  async startMonitoring() {
    this.monitoringActive = true;

    while (this.monitoringActive) {
      // OODA Loop Implementation
      await this.observe();
      await this.orient();
      await this.decide();
      await this.act();

      await new Promise(resolve => setTimeout(resolve, 1000)); // 1s cycle
    }
  }

  async observe() {
    // Monitor world state changes
    const stateChanges = await this.detectStateChanges();
    this.updateWorldState(stateChanges);
  }

  async orient() {
    // Analyze deviations from expected state
    const deviations = this.analyzeDeviations();

    if (deviations.significant) {
      this.triggerReplanning(deviations);
    }
  }

  async decide() {
    if (this.needsReplanning()) {
      await this.replan();
    }
  }

  async act() {
    if (this.currentPlan && this.currentPlan.nextAction) {
      await this.executeAction(this.currentPlan.nextAction);
    }
  }

  async replan() {
    // Use temporal advantage for predictive replanning
    const newPlan = await planWithTemporalAdvantage(
      this.buildCurrentMatrix(),
      this.getCurrentConstraints()
    );

    if (newPlan && newPlan.confidence > 0.8) {
      this.currentPlan = newPlan;

      // Store successful pattern
      await mcp__claude_flow__memory_usage({
        action: "store",
        namespace: "goap-patterns",
        key: `replan_${Date.now()}`,
        value: JSON.stringify({
          trigger: this.lastDeviation,
          solution: newPlan,
          worldState: Array.from(this.worldState.entries())
        })
      });
    }
  }
}

可调参数：循环周期默认 1000ms；置信度采纳阈值为 0.8；存储命名空间 goap-patterns 用于后续检索相似历史方案。配套智能体 goal-planner.md 将同一方法论凝练为五步提示词模板（状态评估 → 行动分析 → 计划生成 → OODA 执行监控 → 动态重规划），可作为实现本类循环时的精简参考。

6.3 从执行中学习：成功模式沉淀与相似检索

PlanningLearner 让规划器"越用越准"，核心机制是基于记忆的模式检索：

• 计划成功时，计算效果指标并存入成功模式，随后用 flow-nexus 的 neural_train 在成功轨迹上微调一个小型前馈网络（feedforward，隐层 128/64 神经元、ReLU 激活、softmax 输出层；训练超参 epochs: 50、learning_rate: 0.001、batch_size: 32，tier: "small" 以控制算力开销）；
• 计划失败时，走 analyzeFailure 分支做失败原因分析；
• 面对新情境，用 memory_search（namespace: "goap-patterns", limit: 10）检索相似历史模式，并按 similarity * successRate 综合打分排序。

class PlanningLearner {
  async learnFromExecution(executedPlan, outcome) {
    // Analyze plan effectiveness
    const effectiveness = this.calculateEffectiveness(executedPlan, outcome);

    if (effectiveness.success) {
      // Store successful pattern
      await this.storeSuccessPattern(executedPlan, effectiveness);

      // Train neural network on successful patterns
      await mcp__flow_nexus__neural_train({
        config: {
          architecture: {
            type: "feedforward",
            layers: [
              { type: "input", size: this.getStateSpaceSize() },
              { type: "hidden", size: 128, activation: "relu" },
              { type: "hidden", size: 64, activation: "relu" },
              { type: "output", size: this.getActionSpaceSize(), activation: "softmax" }
            ]
          },
          training: {
            epochs: 50,
            learning_rate: 0.001,
            batch_size: 32
          }
        },
        tier: "small"
      });
    } else {
      // Analyze failure patterns
      await this.analyzeFailure(executedPlan, outcome);
    }
  }

  async retrieveSimilarPatterns(currentSituation) {
    // Search for similar successful patterns
    const patterns = await mcp__claude_flow__memory_search({
      pattern: `situation:${this.encodeSituation(currentSituation)}`,
      namespace: "goap-patterns",
      limit: 10
    });

    // Rank by similarity and success rate
    return patterns.results
      .map(p => ({ ...p, similarity: this.calculateSimilarity(currentSituation, p.context) }))
      .sort((a, b) => b.similarity * b.successRate - a.similarity * a.successRate);
  }
}

7. 游戏 AI 集成：行为树与效用选择

本智能体把规划器组织成游戏 AI 常用的两种运行时结构。

7.1 GOAP 行为树

GOAPBehaviorTree 用 Selector/Sequence/Condition/Action 四种节点把规划器编排成"可挂机"的决策树：优先走"已有有效计划 → 执行计划"序列；否则转入"生成计划 → 执行计划"序列；两者都失败则进入兜底的 handlePlanningFailure。generatePlan 内部用 solve（method: "random-walk"、maxIterations: 1000）快速求解，并以解残差判定置信度：residual < 1e-6 时置信度取 0.95，否则降为 0.7，同时记录规划耗时：

class GOAPBehaviorTree {
  constructor() {
    this.root = new SelectorNode([
      new SequenceNode([
        new ConditionNode(() => this.hasValidPlan()),
        new ActionNode(() => this.executePlan())
      ]),
      new SequenceNode([
        new ActionNode(() => this.generatePlan()),
        new ActionNode(() => this.executePlan())
      ]),
      new ActionNode(() => this.handlePlanningFailure())
    ]);
  }

  async tick() {
    return await this.root.execute();
  }

  hasValidPlan() {
    return this.currentPlan &&
           this.currentPlan.isValid &&
           !this.worldStateChanged();
  }

  async generatePlan() {
    const startTime = performance.now();

    // Use sublinear solver for rapid planning
    const planMatrix = this.buildPlanningMatrix();
    const constraints = this.extractConstraints();

    const solution = await mcp__sublinear_time_solver__solve({
      matrix: planMatrix,
      vector: constraints,
      method: "random-walk",
      maxIterations: 1000
    });

    const endTime = performance.now();

    this.currentPlan = {
      actions: this.decodeSolution(solution.solution),
      confidence: solution.residual < 1e-6 ? 0.95 : 0.7,
      planningTime: endTime - startTime,
      isValid: true
    };

    return this.currentPlan !== null;
  }
}

7.2 基于效用的行动选择

UtilityPlanner 把"选哪个行动"建模为带权多目标决策：四路效用——时间效率（权重 0.3）、资源成本（0.25）、风险水平（0.2）、目标对齐（0.25）——汇总后，把效用矩阵 + 偏好向量交给 solve（method: "neumann"）求解，取解中得分最高的行动执行。单行动效用计算与权重累加公式如下：

class UtilityPlanner {
  constructor() {
    this.utilityWeights = {
      timeEfficiency: 0.3,
      resourceCost: 0.25,
      riskLevel: 0.2,
      goalAlignment: 0.25
    };
  }

  async selectOptimalAction(availableActions, currentState, goalState) {
    const utilities = await Promise.all(
      availableActions.map(action => this.calculateUtility(action, currentState, goalState))
    );

    // Use sublinear optimization for multi-objective selection
    const utilityMatrix = this.buildUtilityMatrix(utilities);
    const preferenceVector = Object.values(this.utilityWeights);

    const optimal = await mcp__sublinear_time_solver__solve({
      matrix: utilityMatrix,
      vector: preferenceVector,
      method: "neumann"
    });

    const bestActionIndex = optimal.solution.indexOf(Math.max(...optimal.solution));
    return availableActions[bestActionIndex];
  }

  async calculateUtility(action, currentState, goalState) {
    const timeUtility = await this.estimateTimeUtility(action);
    const costUtility = this.calculateCostUtility(action);
    const riskUtility = await this.assessRiskUtility(action, currentState);
    const goalUtility = this.calculateGoalAlignment(action, currentState, goalState);

    return {
      action,
      timeUtility,
      costUtility,
      riskUtility,
      goalUtility,
      totalUtility: (
        timeUtility * this.utilityWeights.timeEfficiency +
        costUtility * this.utilityWeights.resourceCost +
        riskUtility * this.utilityWeights.riskLevel +
        goalUtility * this.utilityWeights.goalAlignment
      )
    };
  }
}

行为树解决"何时该重新规划"，效用选择解决"同一时刻选哪个动作"——两者配合，使智能体既能在稳态高效执行，又能在扰动时自动切换规划模式。

8. 使用示例与最佳实践

8.1 五个端到端使用示例

文档给出五个可运行的场景骨架，核心参数一览如下。

示例 1：复杂项目规划。目标描述含 objective（目标陈述）、constraints（约束，如"2 周截止、高安全、易用"）、resources（可用资源，如"3 名开发、1 名设计、1 万美元预算"），随后将目标拆为 UI 设计、后端认证实现、安全测试、生产部署、性能监控五个子目标，构造依赖矩阵后用 solve（method: "neumann"）优化执行顺序：

// Goal: Launch a new product feature
const productLaunchGoal = {
  objective: "Launch authentication system",
  constraints: ["2 week deadline", "high security", "user-friendly"],
  resources: ["3 developers", "1 designer", "$10k budget"]
};

// Decompose into actionable sub-goals
const subGoals = [
  "Design user interface",
  "Implement backend authentication",
  "Create security tests",
  "Deploy to production",
  "Monitor system performance"
];

// Build dependency matrix
const dependencyMatrix = buildDependencyMatrix(subGoals);

// Optimize execution order
const optimizedPlan = await mcp__sublinear_time_solver__solve({
  matrix: dependencyMatrix,
  vector: resourceConstraints,
  method: "neumann"
});

示例 2：资源分配多目标优化。三个竞争目标（降成本、提质量、增速）各有 weight 与 urgency；利用 PageRank 的 personalized 参数把急迫度作为个性化向量注入，使排序偏向当前更紧迫的目标：

// Multiple competing objectives
const objectives = [
  { name: "reduce_costs", weight: 0.3, urgency: 0.7 },
  { name: "improve_quality", weight: 0.4, urgency: 0.8 },
  { name: "increase_speed", weight: 0.3, urgency: 0.9 }
];

// Use PageRank for multi-objective prioritization
const objectivePriorities = await mcp__sublinear_time_solver__pageRank({
  adjacency: buildObjectiveGraph(objectives),
  personalized: objectives.map(o => o.urgency)
});

// Allocate resources based on priorities
const resourceAllocation = optimizeResourceAllocation(objectivePriorities);

示例 3：预测性行动规划。用 predictWithTemporalAdvantage 在市场条件变化前预测（distanceKm: 20000 模拟全球市场数据传播距离），再据预测生成战略行动、提前执行：

// Predict market conditions before they change
const marketPrediction = await mcp__sublinear_time_solver__predictWithTemporalAdvantage({
  matrix: marketTrendMatrix,
  vector: currentMarketState,
  distanceKm: 20000 // Global market data propagation
});

// Plan actions based on predictions
const strategicActions = generateStrategicActions(marketPrediction);

// Execute with temporal advantage
const results = await executeWithTemporalLead(strategicActions);

示例 4：多智能体目标协调。mesh 拓扑 + 12 个智能体 + specialized 策略组建群，并行 spawn 研究者（数据分析）、程序员（实现）、优化者（性能）三类角色，最终以 adaptive 策略编排"构建并优化推荐系统"任务：

// Initialize coordinated swarm
const coordinatedSwarm = await mcp__flow_nexus__swarm_init({
  topology: "mesh",
  maxAgents: 12,
  strategy: "specialized"
});

// Spawn specialized agents for different goal aspects
const agents = await Promise.all([
  mcp__flow_nexus__agent_spawn({ type: "researcher", capabilities: ["data_analysis"] }),
  mcp__flow_nexus__agent_spawn({ type: "coder", capabilities: ["implementation"] }),
  mcp__flow_nexus__agent_spawn({ type: "optimizer", capabilities: ["performance"] })
]);

// Coordinate goal achievement
const coordinatedExecution = await mcp__flow_nexus__task_orchestrate({
  task: "Build and optimize recommendation system",
  strategy: "adaptive",
  maxAgents: 3
});

示例 5：自适应重规划。用 task_status（detailed: true）监控执行进度，当偏差超过阈值时重建约束矩阵并以 method: "adaptive" 生成修订计划：

// Monitor execution progress
const executionStatus = await mcp__flow_nexus__task_status({
  taskId: currentExecutionId,
  detailed: true
});

// Detect deviations from plan
if (executionStatus.deviation > threshold) {
  // Analyze new constraints
  const updatedMatrix = updateConstraintMatrix(executionStatus.changes);

  // Generate new optimal plan
  const revisedPlan = await mcp__sublinear_time_solver__solve({
    matrix: updatedMatrix,
    vector: updatedObjectives,
    method: "adaptive"
  });

  // Implement revised plan
  await implementRevisedPlan(revisedPlan);
}

8.2 何时使用 GOAP

文档给出五条适用判据，可视为"取舍决策清单"：

• 复杂多步目标：目标由多个相互关联的行动构成；
• 存在资源约束：时间、成本或人力的优化至关重要；
• 动态环境：条件会变化、计划需要随变而变；
• 预测性场景：时间优势能带来可量化的竞争收益；
• 多智能体协作：多个智能体需朝共享目标协同推进。

反向理解即：若目标单步可达、无资源竞争、环境静态，直接执行即可，GOAP 属于过度设计。

8.3 目标定义的结构化模板

文档推荐用六字段结构定义目标，前 5 项（前置/后置/约束/度量/依赖）都能被 GOAP 的状态机与矩阵模型直接消费：

// Well-structured goal definition
const optimizedGoal = {
  objective: "Clear and measurable outcome",
  preconditions: ["List of required starting states"],
  postconditions: ["List of desired end states"],
  constraints: ["Time, resource, and quality constraints"],
  metrics: ["Quantifiable success measures"],
  dependencies: ["Relationships with other goals"]
};

8.4 性能优化四原则

• 矩阵稀疏化：大规模目标网络改用稀疏表示，避免稠密矩阵的内存爆炸；
• 增量更新：优先增量修订既有计划而非全量重建（与 ADR-123 的 delta-only 更新、"只计算变化足够大的部分"一脉相承）；
• 缓存：把成功的计划模式缓存起来供相似目标复用；
• 并行处理：相互独立的子目标并行执行（对应 §5.1 的 strategy: "parallel"）。

8.5 与其他智能体的协作矩阵

文档建议的协作方式：与 swarm 智能体协作做分布式执行；用 neural 智能体从历史规划成败中学习；与 workflow 智能体集成以固化可重复模式；借助 sandbox 智能体安全试跑计划。仓库中 flow-nexus 生态目录（plugin/agents/flow-nexus/、plugin/commands/flow-nexus/）与 sublinear 专职智能体目录（plugin/agents/sublinear/）正是这一矩阵在文件系统层面的落地。

9. 高级配置与容错设计

9.1 规划参数总览

文档给出的 plannerConfig 是全篇参数的最完整汇总，可作为自定义规划器时的默认值基线：

const plannerConfig = {
  searchAlgorithm: "a_star", // a_star, dijkstra, greedy
  heuristicFunction: "manhattan", // manhattan, euclidean, custom
  maxSearchDepth: 20,
  planningTimeout: 30000, // 30 seconds
  convergenceEpsilon: 1e-6,
  temporalAdvantageThreshold: 0.8,
  utilityWeights: {
    time: 0.3,
    cost: 0.3,
    risk: 0.2,
    quality: 0.2
  }
};

逐项说明与调参建议：

• searchAlgorithm：a_star（最优性 + 启发式加速）、dijkstra（无启发式时退化的 A*，保证最优但更慢）、greedy（最快但可能非最优，适合低风险快速逼近）；
• heuristicFunction：manhattan/euclidean 为经典几何启发；custom 可接入 §4.5 的求解器启发式；
• maxSearchDepth: 20：搜索深度上限，防状态空间爆炸；
• planningTimeout: 30000（30 秒）：单次规划的最长预算，超时进入降级分支；
• convergenceEpsilon: 1e-6：与 §4.3 的 epsilon 同源，控制迭代求解精度；
• temporalAdvantageThreshold: 0.8：与 §6.2 的置信度门槛一致，低于该值不采纳预测计划；
• utilityWeights：四类权重的默认分配，应与 §7.2 版本在语义上保持一致。

9.2 分级容错策略

RobustPlanner 将规划失败按类型分诊处理，是工程化落地的关键设计：

class RobustPlanner extends GOAPAgent {
  async handlePlanningFailure(error, context) {
    switch (error.type) {
      case 'MATRIX_SINGULAR':
        return await this.regularizeMatrix(context.matrix);
      case 'NO_CONVERGENCE':
        return await this.relaxConstraints(context.constraints);
      case 'TIMEOUT':
        return await this.useApproximateSolution(context);
      default:
        return await this.fallbackToSimplePlanning(context);
    }
  }
}

• MATRIX_SINGULAR（矩阵奇异，无法求解）：对矩阵做正则化（如加对角扰动、退化处理）后重试；
• NO_CONVERGENCE（迭代不收敛）：放宽约束（松弛可行性边界）后再求；
• TIMEOUT（超预算）：改用近似解，接受次优但可控；
• 未知错误：回退到"朴素简单规划"，保证系统不空转。

另配合 §6.2 的 try/catch 应急计划模式（规划执行异常时生成 contingency plan 并继续执行），整体形成"主计划—应急计划—降级规划"三级防线。

10. 从"目标"到"智能体可执行计划"的架构总结

综合文档全貌，sublinear-goal-planner 的架构可以归纳为一条流水线：

1. 表示层：用布尔命题状态 Map 表达世界状态与目标状态，用"前置条件/效果/成本"三元组定义行动（§4.1）；
2. 图模型层：行动迁移关系编码为带逆成本权重的邻接矩阵，analyzeMatrix 校验对角占优等可解性条件（§4.2）；
3. 优化层：solve 完成线性系统/共识求解，pageRank 完成行动与目标排序，predictWithTemporalAdvantage 在数据到达前给出预测解（§4.3–§4.5）；
4. 搜索层：A* 以"可用行动动态展开 + 求解器启发式"搜索最优行动序列（§4.5）；
5. 执行与学习层：OODA 循环 1 秒级监控偏差、超阈值自动重规划，成败经验沉淀到 goap-patterns 记忆空间供相似情境检索复用（§6.2–§6.3）；
6. 协作层：swarm 编排、按需 spawn 专职智能体、共识矩阵解决多智能体分歧（§5）。

最后需要指出的是，文档在 "Advanced Features" 中提到的三大前沿方向——时间计算优势（利用光速级延迟做预测性规划）、基于矩阵的目标建模（把目标表达为约束满足问题、用图论做依赖分析、用线性代数做优化、用反馈环持续改进）、创造性方案发现（通过矩阵操作探索超出直觉的方案空间并同时优化多成功准则）——在仓库中均有对应的技术基元记录，尤其是 ADR-123 以"复杂度感知的智能"为立场，将个性化 PageRank、稀疏传播、增量求解、预算门控与一致性校验沉淀为图智能引擎的标准能力。本文所述的 GOAP 规划器正是这套数学架构在单智能体目标规划上的收敛实例：规划不再只是"让模型推理步骤"，而是"把目标交给一套有复杂度预算的数学引擎去求解"。

若要进一步深入，建议继续阅读仓库中的以下资源：本智能体的精简提示词变体 .claude/agents/reasoning/goal-planner.md；镜像副本 plugin/agents/reasoning/agent.md；五个专职 sublinear 智能体定义 plugin/agents/sublinear/（矩阵优化、PageRank、共识、性能、预测交易各自成文）；以及描述整条求解链架构定位与算法谱系的 ADR-123。