RuView SPARC Coordinator：融合 SPARC 五阶段方法论的分层 MoE 路由与自学习多智能体协调模板

本文以 RuView 仓库中 .claude/agents/templates/sparc-coordinator.md 这份 SPARC 方法论编排者 Agent 模板为主体，完整拆解其 YAML 元数据、pre/post 钩子脚本、ReasoningBank 自学习协议、Queen-Worker 分层协调模型、MoE 专家路由与 SPARC 五阶段质量门禁。读完后你将理解该模板如何将"规格、伪代码、架构、精化、完成"这一开发方法论落地为可执行的多智能体工作流，以及它如何与仓库中的 sparc/ 阶段专家 Agent、V3 SPARC Orchestrator 和分层 Swarm 协调器协同工作。

一、模板定位与元数据设计

sparc-coordinator.md 是 RuView 仓库 .claude/agents/templates/ 目录下的一套 Agent 模板，其核心使命是编排完整的 SPARC（Specification, Pseudocode, Architecture, Refinement, Completion）方法论，并提供**分层协调（hierarchical coordination）、MoE 路由（mixture-of-experts routing）与自学习（self-learning）**三类能力，文档中声明其由 Agentic-Flow v3.0.0-alpha.1 驱动。

文件前半部分是 YAML frontmatter，定义了模板的身份与运行契约：

字段	取值	含义
name	sparc-coord	模板在 Agent 体系中的注册名
type	coordination	属于"协调类"Agent，而非执行类（coder/tester 等）
color	orange	UI/日志中的标识色
priority	high	高优先级调度
capabilities	见下	声明的能力清单，供上层编排器做能力匹配

capabilities 分成两组：基础能力（sparc_coordination、phase_management、quality_gate_enforcement、methodology_compliance、result_synthesis、progress_tracking）与 v3.0.0-alpha.1 新增的自学习/分层能力（self_learning、hierarchical_coordination、moe_routing、cross_phase_learning、smart_coordination）。这种"基础能力 + 版本标注新能力"的写法，使得上层路由逻辑可以按版本特征区分旧版协调器与具备自学习能力的协调器。

frontmatter 中 hooks.pre 与 hooks.post 是该模板的"运行骨架"——两个 Bash 钩子在 SPARC 周期开始前和结束后自动执行，下文将逐行剖析。

二、pre 钩子：会话初始化与历史经验回放

pre 钩子负责在 SPARC 周期启动前完成四件事：记录会话、检索历史、学习过往周期、落盘周期起点。脚本原文如下（摘自 sparc-coordinator.md frontmatter）：

echo "🎯 SPARC Coordinator initializing methodology workflow"
memory_store "sparc_session_start" "$(date +%s)"

# 1. Check for existing SPARC phase data
memory_search "sparc_phase" | tail -1

# 2. Learn from past SPARC cycles (ReasoningBank)
echo "🧠 Learning from past SPARC methodology cycles..."
PAST_CYCLES=$(npx claude-flow@alpha memory search-patterns "sparc-cycle: $TASK" --k=5 --min-reward=0.85 2>/dev/null || echo "")
if [ -n "$PAST_CYCLES" ]; then
  echo "📚 Found ${PAST_CYCLES} successful SPARC cycles - applying learned patterns"
  npx claude-flow@alpha memory get-pattern-stats "sparc-cycle: $TASK" --k=5 2>/dev/null || true
fi

# 3. Initialize hierarchical coordination tracking
echo "👑 Initializing hierarchical coordination (queen-worker model)"

# 4. Store SPARC cycle start
SPARC_SESSION_ID="sparc-coord-$(date +%s)-$$"
echo "SPARC_SESSION_ID=$SPARC_SESSION_ID" >> $GITHUB_ENV 2>/dev/null || export SPARC_SESSION_ID
npx claude-flow@alpha memory store-pattern \
  --session-id "$SPARC_SESSION_ID" \
  --task "sparc-coordination: $TASK" \
  --input "$TASK" \
  --status "started" 2>/dev/null || true

逐段解读其设计意图：

• 会话落盘：memory_store "sparc_session_start" 用当前时间戳写入记忆库，为 post 钩子做关联锚点；
• 断点感知：memory_search "sparc_phase" | tail -1 检查是否已有 SPARC 阶段数据，从而判断当前任务是全新周期还是中断后的续跑；
• 经验回放（ReasoningBank）：核心调用是 npx claude-flow@alpha memory search-patterns "sparc-cycle: $TASK" --k=5 --min-reward=0.85，即按任务描述做相似性检索，取相似度 Top-5 且奖励值（reward）不低于 0.85 的历史成功周期。若命中则打印提示并调用 get-pattern-stats 拉取统计画像。--min-reward=0.85 这一阈值表明模板只复用"高质量"历史经验，避免被平庸或失败案例污染；
• 会话 ID 生成：SPARC_SESSION_ID="sparc-coord-$(date +%s)-$$" 同时携带时间戳与进程号保证唯一性，并优先写入 $GITHUB_ENV（GitHub Actions 场景下可跨 step 传递），本地执行时回退为普通 export；
• 周期起点入档：store-pattern --status "started" 先以"started"状态写入模式库，保证即使后续阶段失败，post 钩子仍能基于同一 session-id 补写终态，形成完整的学习样本。

值得注意的细节是所有 npx claude-flow@alpha 调用都附带 2>/dev/null || true 或 || echo "" 兜底：记忆/学习系统是增强型依赖而非硬依赖，学习链路失败时协调工作流本身仍可继续。这与该模板"方法论合规优先"的定位一致。

三、post 钩子：成功率计算与完整学习样本落盘

post 钩子在协调阶段结束时执行，负责聚合各阶段成败、计算整体奖励（reward）、落盘完整周期样本，并在成功时触发神经模式训练。脚本关键逻辑：

# 1. Collect metrics from all SPARC phases
SPEC_SUCCESS=$(memory_search "spec_complete" | grep -q "learning" && echo "true" || echo "false")
PSEUDO_SUCCESS=$(memory_search "pseudo_complete" | grep -q "learning" && echo "true" || echo "false")
ARCH_SUCCESS=$(memory_search "arch_complete" | grep -q "learning" && echo "true" || echo "false")
REFINE_SUCCESS=$(memory_search "refine_complete" | grep -q "learning" && echo "true" || echo "false")

# 2. Calculate overall SPARC cycle success
PHASE_COUNT=0
SUCCESS_COUNT=0
[ "$SPEC_SUCCESS" = "true" ] && SUCCESS_COUNT=$((SUCCESS_COUNT + 1)) && PHASE_COUNT=$((PHASE_COUNT + 1))
# ...（pseudo/arch/refine 同理）

if [ $PHASE_COUNT -gt 0 ]; then
  OVERALL_REWARD=$(awk "BEGIN {print $SUCCESS_COUNT / $PHASE_COUNT}")
else
  OVERALL_REWARD=0.5
fi

OVERALL_SUCCESS=$([ $SUCCESS_COUNT -ge 3 ] && echo "true" || echo "false")

# 3. Store complete SPARC cycle learning pattern
npx claude-flow@alpha memory store-pattern \
  --session-id "${SPARC_SESSION_ID:-sparc-coord-$(date +%s)}" \
  --task "sparc-coordination: $TASK" \
  --input "$TASK" \
  --output "phases_completed=$PHASE_COUNT, phases_successful=$SUCCESS_COUNT" \
  --reward "$OVERALL_REWARD" \
  --success "$OVERALL_SUCCESS" \
  --critique "SPARC cycle completion: $SUCCESS_COUNT/$PHASE_COUNT phases successful" \
  --tokens-used "0" --latency-ms "0" 2>/dev/null || true

# 4. Train neural patterns on successful SPARC cycles
if [ "$OVERALL_SUCCESS" = "true" ]; then
  npx claude-flow@alpha neural train \
    --pattern-type "coordination" \
    --training-data "sparc-cycle-success" \
    --epochs 50 2>/dev/null || true
fi

memory_store "sparc_coord_complete_$(date +%s)" "SPARC methodology phases coordinated with learning ($SUCCESS_COUNT/$PHASE_COUNT successful)"

其中蕴含三个可复用的机制设计：

1. 跨阶段成败聚合：四个阶段专家 Agent（specification/pseudocode/architecture/refinement）各自在 post 钩子中写入 *_complete 标记，协调器通过 memory_search + grep -q "learning" 判定该阶段是否真正完成了"带学习记录"的收尾。从源码结构看，这一约定与 specification.md 等阶段专家模板 post 钩子中 memory_store "spec_complete_$(date +%s)" "Specification documented with learning" 的写入格式一一对应——协调器与阶段专家之间以记忆库为唯一总线通信；
2. 奖励与成功的双口径：OVERALL_REWARD 是成功率（0~1 连续值，无阶段数据时回退 0.5），而 OVERALL_SUCCESS 是硬阈值（至少 3/4 阶段成功才判成功）。连续奖励用于检索排序，布尔成功用于决定是否进入训练集，两者分工明确；
3. 条件触发训练：仅当 OVERALL_SUCCESS=true 才调用 neural train --pattern-type "coordination" --epochs 50，即只有"好经验"才参与神经模式训练，避免负样本污染。

四、自学习协议：循环前、循环中、循环后

模板正文以 TypeScript 风格的协议描述（对接 claude-flow v3.0.0-alpha.1 的概念 API 面，如 reasoningBank）给出自学习的完整闭环。

4.1 循环前：从历史成功与失败中学习

// 1. Search for similar SPARC cycles
const similarCycles = await reasoningBank.searchPatterns({
  task: 'sparc-cycle: ' + currentProject.description,
  k: 5,
  minReward: 0.85
});

if (similarCycles.length > 0) {
  similarCycles.forEach(pattern => {
    console.log(`- ${pattern.task}: ${pattern.reward} cycle success rate`);
    console.log(`  Key insights: ${pattern.critique}`);
    // Apply successful phase transitions
    // Reuse proven quality gate criteria
    // Adopt validated coordination patterns
  });
}

// 2. Learn from incomplete or failed SPARC cycles
const failedCycles = await reasoningBank.searchPatterns({
  task: 'sparc-cycle: ' + currentProject.description,
  onlyFailures: true,
  k: 3
});

if (failedCycles.length > 0) {
  failedCycles.forEach(pattern => {
    console.log(`- ${pattern.critique}`);
    // Prevent phase skipping
    // Ensure quality gate compliance
    // Maintain phase continuity
  });
}

这段协议的关键在于双向学习：minReward: 0.85 检索成功范式用于"复用已验证的相位转移、质量门禁判据与协调模式"；onlyFailures: true, k: 3 检索失败案例用于"防跳相、保门禁合规、维持相位连续性"。这与 pre 钩子中 search-patterns --min-reward=0.85 的 CLI 调用互为表里——TypeScript 描述的是语义契约，Bash 钩子是其在终端环境的具体实现。

4.2 循环后：以四维指标合成周期奖励

const cycleMetrics = {
  specificationQuality: getPhaseMetric('specification'),
  algorithmEfficiency: getPhaseMetric('pseudocode'),
  architectureScalability: getPhaseMetric('architecture'),
  refinementCoverage: getPhaseMetric('refinement'),
  phasesCompleted: countCompletedPhases(),
  totalDuration: measureCycleDuration()
};

// 四个维度等权合成 0-1 总奖励
const cycleReward = (
  cycleMetrics.specificationQuality * 0.25 +
  cycleMetrics.algorithmEfficiency * 0.25 +
  cycleMetrics.architectureScalability * 0.25 +
  cycleMetrics.refinementCoverage * 0.25
);

await reasoningBank.storePattern({
  sessionId: `sparc-cycle-${Date.now()}`,
  task: 'sparc-coordination: ' + projectDescription,
  input: initialRequirements,
  output: completedProject,
  reward: cycleReward,              // 0-1 based on all phase metrics
  success: cycleMetrics.phasesCompleted >= 4,
  critique: `Phases: ${cycleMetrics.phasesCompleted}/4, Avg Quality: ${cycleReward}`,
  tokensUsed: sumAllPhaseTokens(),
  latencyMs: cycleMetrics.totalDuration
});

对比 post 钩子的实现可以看到演进关系：钩子版以"阶段成功数/阶段总数"计算奖励，协议版则升级为"规格质量、算法效率、架构可扩展性、精化覆盖率"四项各 25% 加权的质量加权奖励，并额外记录 tokensUsed 与 latencyMs 供后续成本/时延分析。success 判据统一为 phasesCompleted >= 4，与钩子中"≥3 即成功"相比更严格，体现了从"数量达标"到"全量完成"的标准抬升。

五、分层协调：Queen-Worker 模型与双曲空间

模板将 SPARC 协调器定位为"Queen（女王）"，将四个阶段专家定位为"Worker（工人）"，并给出层级化协调调用：

// Use hierarchical coordination (queen-worker model)
const coordinator = new AttentionCoordinator(attentionService);

// SPARC Coordinator = Queen (strategic decisions)
// Phase Specialists = Workers (execution details)
const phaseCoordination = await coordinator.hierarchicalCoordination(
  [
    { phase: 'strategic_requirements', importance: 1.0 },
    { phase: 'overall_architecture', importance: 0.9 }
  ],  // Queen decisions
  [
    { agent: 'specification', output: specOutput },
    { agent: 'pseudocode', output: pseudoOutput },
    { agent: 'architecture', output: archOutput },
    { agent: 'refinement', output: refineOutput }
  ],  // Worker outputs
  -1.0  // Hyperbolic curvature for natural hierarchy
);

console.log(`Hierarchical coordination score: ${phaseCoordination.consensus}`);
console.log(`Queens have 1.5x influence on decisions`);

三层参数各有设计含义：

• Queen 决策项带 importance 权重：strategic_requirements 为 1.0、overall_architecture 为 0.9，即战略级决策项在共识计算中拥有不同权重；
• Worker 输出项是纯执行结果：四个阶段专家只贡献 output，不参与战略决策；
• 曲率 -1.0：模板注释说明使用负曲率（双曲空间）以"表达天然层级"，同时声明 Queen 对决策拥有 1.5 倍影响力。从模板描述看，这是一种用注意力几何结构模拟"少数战略节点主导、多数执行节点从属"的协调方案。

Queen 层的职责边界被明确列举：

const queenDecisions = [
  'overall_project_direction',   // 项目总方向
  'quality_gate_criteria',      // 质量门禁判据
  'phase_transition_approval', // 相位转移审批
  'methodology_compliance'      // 方法论合规
];

Worker 层则通过注意力机制达成内部共识，模板选用 'flash' 档作为 Worker 级协调（注释标注"Fast coordination for worker level"，即 Worker 层追求快速共识，战略复杂度上移到 Queen）：

const workers = [
  { agent: 'specification', role: 'requirements_analysis' },
  { agent: 'pseudocode',    role: 'algorithm_design' },
  { agent: 'architecture',  role: 'system_design' },
  { agent: 'refinement',    role: 'code_quality' }
];

const workerConsensus = await coordinator.coordinateAgents(
  workers.map(w => w.output),
  'flash'  // Fast coordination for worker level
);

这一 Queen-Worker 抽象在仓库中并非孤例：hierarchical-coordinator.md 定义了通用分层 Swarm 协调器（"Queen + Research/Code/Analyst/Test Workers"拓扑，swarm_init hierarchical --maxAgents=10 --strategy=adaptive），SPARC Coordinator 可视为该分层模型在"五阶段方法论"场景下的特化应用。

六、MoE 专家路由：按任务特征选择阶段专家

模板引入 MoE（Mixture of Experts）思路解决"当前任务应该交给哪个阶段专家"的问题：

// Route tasks to the best phase specialist using MoE attention
const taskRouting = await coordinator.routeToExperts(
  currentTask,
  [
    { agent: 'specification', expertise: ['requirements', 'constraints'] },
    { agent: 'pseudocode',    expertise: ['algorithms', 'complexity'] },
    { agent: 'architecture',  expertise: ['system-design', 'scalability'] },
    { agent: 'refinement',    expertise: ['testing', 'optimization'] }
  ],
  2  // Top 2 most relevant specialists
);

console.log(`Selected specialists: ${taskRouting.selectedExperts.map(e => e.agent)}`);
console.log(`Routing confidence: ${taskRouting.routingScores}`);

每个专家以 expertise 标签向量化自己的擅长域，路由器计算任务与各专家域的相关度后返回 Top-K 与 routingScores 置信度。模板还给出一个完整的路由器类示例，展示了专家成功率先验参与路由的设计：

class SPARCRouter {
  async routeTask(task: Task) {
    const experts = [
      {
        agent: 'specification',
        expertise: ['requirements', 'constraints', 'acceptance_criteria'],
        successRate: 0.92
      },
      {
        agent: 'pseudocode',
        expertise: ['algorithms', 'data_structures', 'complexity'],
        successRate: 0.88
      },
      {
        agent: 'architecture',
        expertise: ['system_design', 'scalability', 'components'],
        successRate: 0.90
      },
      {
        agent: 'refinement',
        expertise: ['testing', 'optimization', 'refactoring'],
        successRate: 0.91
      }
    ];

    const routing = await coordinator.routeToExperts(task, experts, 1); // 单选最优专家
    return routing.selectedExperts[0];
  }
}

对比两处用法可以看出模板对 Top-K 的策略选择：常规协调用 Top-2（双专家协作，覆盖任务的多面性），确定性单一职责任务用 Top-1（直接命中最优专家）。successRate 字段则把历史统计注入路由先验——这与第四节的学习闭环呼应：ReasoningBank 的 getPatternStats 产出的成功率，正是路由器的输入之一。

七、跨相位学习与周期改进追踪

7.1 跨相位注意力学习

// Learn patterns across SPARC phases using attention
const crossPhaseLearning = await coordinator.coordinateAgents(
  [
    { phase: 'spec',   patterns: specPatterns },
    { phase: 'pseudo', patterns: pseudoPatterns },
    { phase: 'arch',   patterns: archPatterns },
    { phase: 'refine', patterns: refinePatterns }
  ],
  'multi-head'  // Multi-perspective cross-phase analysis
);

console.log(`Cross-phase patterns identified: ${crossPhaseLearning.consensus}`);
const improvements = extractImprovements(crossPhaseLearning);

这里用 'multi-head' 档（对比 Worker 层的 'flash' 档）做"多视角跨相位分析"，目标是识别跨越多个阶段的共性模式（例如"规格阶段遗漏的边界条件总在精化阶段以缺陷形式复现"），再把提取出的 improvements 反哺后续周期。

7.2 周期统计与改进趋势

const cycleStats = await reasoningBank.getPatternStats({
  task: 'sparc-cycle',
  k: 20
});

console.log(`SPARC cycle success rate: ${cycleStats.successRate}%`);
console.log(`Average quality score: ${cycleStats.avgReward}`);
console.log(`Common optimization opportunities: ${cycleStats.commonCritiques}`);

// Weekly improvement trends
const weeklyImprovement = calculateCycleImprovement(cycleStats);

getPatternStats 取最近 20 个周期样本，输出成功率、平均奖励与"共性改进机会"（commonCritiques，即 critique 文本的高频聚类）。这对应 pre 钩子中 get-pattern-stats 命令的语义：每次新周期启动时看到的"历史画像"，正是历次 post 钩子落盘样本的统计结果。

关于性能收益，模板在 "Performance Benefits" 一节给出的对比属于文档声明的预期效果（传统串行协调"约 1 周/周期"，引入分层协调 + MoE 路由 + ReasoningBank + 跨相位注意力 + 有限并行后的 v3.0.0-alpha.1 版本"约 2-3 天/周期，质量 +40%"），并非仓库内可复测的实测基准，引用时应视为模板设计目标而非已验证数据。

八、SPARC 五阶段、质量门禁与相位转移流

模板正文给出五阶段职责划分，这是整个协调体系被管理的"对象"：

阶段	核心活动
1. Specification	需求细化收集、用户故事、验收标准定义、边界情况识别
2. Pseudocode	算法设计、逻辑流规划、数据结构选型、复杂度分析
3. Architecture	系统设计、组件定义、接口契约、集成规划
4. Refinement	TDD 实现、迭代改进、性能优化、代码质量增强
5. Completion	集成测试、文档定稿、部署准备、交接流程

相位转移以质量门禁（Quality Gate）为关卡，形成严格串行链路：

Specification → Quality Gate 1 → Pseudocode
     ↓
Pseudocode → Quality Gate 2 → Architecture
     ↓
Architecture → Quality Gate 3 → Refinement
     ↓
Refinement → Quality Gate 4 → Completion
     ↓
Completion → Final Review → Deployment

五道门禁的判据分别是：

1. Specification Complete：所有需求已文档化；
2. Algorithms Validated：逻辑已验证并优化；
3. Design Approved：架构已评审并获接受；
4. Code Quality Met：测试通过、覆盖率达标；
5. Ready for Production：全部标准满足。

仓库中更完整的编排文档 sparc-orchestrator.md（V3 SPARC Orchestrator）补充了每阶段对应的专家 Agent 与阻塞式门禁表：

Phase	Gate Criteria	Blocking
Specification	所有需求可测试	Yes
Pseudocode	算法完整、复杂度已分析	Yes
Architecture	通过安全评审	Yes
Refinement	测试通过、覆盖率 >80%	Yes
Completion	无关键问题	Yes

并把各阶段绑定到具体 Agent：specification、pseudocode、architecture 三个专家 Agent，Refinement 由 sparc-coder + tester 协作，Completion 由 reviewer + production-validator 把关。该文件还给出了可直接执行的 CLI 入口：

# 运行完整 SPARC 工作流
npx claude-flow@v3alpha sparc run full "$TASK"
# 单独运行某一阶段
npx claude-flow@v3alpha sparc run specification "$TASK"
npx claude-flow@v3alpha sparc run pseudocode "$TASK"
npx claude-flow@v3alpha sparc run architecture "$TASK"
npx claude-flow@v3alpha sparc run refinement "$TASK"
npx claude-flow@v3alpha sparc run completion "$TASK"
# TDD 工作流 / 状态查询
npx claude-flow@v3alpha sparc tdd "$FEATURE"
npx claude-flow@v3alpha sparc status

从源码结构看，sparc-coord 模板是"协调者视角"（如何调度、学习、路由），而 V3 orchestrator 文档是"执行入口视角"（如何跑、跑到哪一步、如何查状态），两者共同构成 SPARC 方法论在仓库内的完整落地。

九、Agent 协同、集成模式与用法示例

9.1 专业 SPARC Agent 与并行执行模式

模板定义了五个协同角色：SPARC Researcher（需求与可行性）、SPARC Designer（架构与接口）、SPARC Coder（实现与精化）、SPARC Tester（质量保障）、SPARC Documenter（文档与指南）。并行执行的四条规则是：

• 为独立组件派生多 Agent 并行开发；
• 组织跨职能评审；
• 测试与文档并行推进；
• 在相位边界处同步（即并行只发生在相位内部，跨相位仍走串行门禁）。

9.2 三类集成模式

集成对象	协调器行为
Task Orchestrator	接收高层目标 → 按 SPARC 相位分解 → 协调相位执行 → 回报进度
GitHub Agents	每相位创建分支 → 相位边界管理 PR → 门禁处协调评审 → 处理合并流程
Testing Agents	在精化阶段集成 TDD → 协调测试覆盖率 → 管理测试自动化 → 验证质量指标

9.3 典型用法示例

模板给出的三个提示词级用法可直接照抄：

# 完整 SPARC 周期
"Use SPARC methodology to develop a user authentication system"
# 聚焦特定阶段
"Execute SPARC architecture phase for microservices design"
# 并行组件开发
"Apply SPARC to develop API, frontend, and database layers simultaneously"

仓库中与之配套的执行入口还有 sparc.md（SPARC Orchestrator 命令，支持 mcp__claude-flow__sparc_mode MCP 工具、npx claude-flow sparc run sparc "task" CLI 与本地安装三种调用方式）以及 sparc-methodology/SKILL.md（SPARC 方法论 Skill，描述了 17 个专用模式、五种编排拓扑与红-绿-重构 TDD 工作流）。

十、最佳实践、记忆集成与成功指标

模板将方法论纪律浓缩为四条相位执行准则：

1. Never skip phases——每个阶段建立在前一阶段之上；
2. Enforce quality gates——门禁无捷径；
3. Document decisions——保持决策可追溯；
4. Iterate within phases——相位内部迭代是预期行为。

针对三类场景给出了差异化策略：功能开发走完整周期、侧重规格与充分测试；缺陷修复用轻量规格、聚焦精化并补回归测试；重构侧重架构、配套保持性测试（preservation testing）与文档更新。

记忆集成方面，模板声明的存储工件包括：相位输出与决策、质量门禁结果、架构决策、测试策略、经验教训；检索策略则对应四步——查历史相似项目、复用架构模式、应用已学优化、规避既往陷阱。这与 pre/post 钩子中 search-patterns / store-pattern / get-pattern-stats 三条 CLI 调用形成闭环。

成功指标分两层：阶段级（规格完整度、算法效率、架构清晰度、代码质量分、文档覆盖率）与周期级（每阶段耗时、门禁通过率、缺陷发现时点、方法论合规度）。周期级指标正是 post 钩子中 PHASE_COUNT/SUCCESS_COUNT/OVERALL_REWARD 的语义来源，可视为学习样本的特征字段。

十一、仓库内的支撑文件地图

围绕本模板，仓库中存在一组可直接对照阅读的文件：

• 阶段专家模板：specification.md、pseudocode.md、architecture.md、refinement.md——各自 frontmatter 的 post 钩子负责写入 *_complete 标记与阶段级学习样本，是协调器 post 钩子成败判定的数据来源；
• V3 编排器文档：sparc-orchestrator.md——含 ASCII 工作流图、每阶段 Agent 绑定、阻塞式门禁表与 npx claude-flow@v3alpha sparc CLI；
• 方法论 Skill：sparc-methodology/SKILL.md——17 个模式、MCP/CLI/本地三种激活方式、编排拓扑模式与常见工作流脚本；
• 分层 Swarm 协调器：hierarchical-coordinator.md——通用 Queen-Worker 模型，SPARC 模板中 AttentionCoordinator 抽象的通用版对应物；
• 学习器 Agent：reasoningbank-learner.md——ReasoningBank 学习机制的专职 Agent 定义；
• 执行命令：sparc.md 与 .claude/commands/sparc/ 目录下的模式命令（researcher、architect、tdd、reviewer、optimizer 等）。

适用前提与限制需要说明：本模板是 Agent 编排配置而非可独立运行的服务，其钩子依赖 npx claude-flow@alpha / @v3alpha CLI 与记忆库（memory_store/memory_search）在运行环境中可用；文中 TypeScript 片段是模板描述的概念 API 协议（对接 Agentic-Flow v3.0.0-alpha.1），仓库内未包含这些符号的可执行实现，实际执行面以钩子中的 Bash 命令为准；模板中的性能对比（周期时长、质量提升百分比）为文档声明的设计目标，使用时不应当作实测结论。

小结

sparc-coordinator.md 展示了将一套开发方法论工程化为多智能体系统的完整路径：用 YAML frontmatter 声明身份与能力，用 pre/post 钩子把"会话—检索—学习—训练"固化到生命周期两端，用 Queen-Worker 分层与 MoE 路由解决"谁来决策、谁来执行、先执行谁"，用 ReasoningBank 的五字段样本（task/input/output/reward/success/critique）让每个周期都成为下一次周期的训练数据。配合仓库中 sparc/ 阶段专家、V3 orchestrator 与分层 Swarm 协调器，这套模板构成了 RuView 仓库里"方法论即基础设施"的典型实现样本。