ln-310-multi-agent-validator

路径： 文件路径（references/、../ln-*）均相对于此技能目录。

类型： L2 协调器
类别： 3XX 规划

多 Agent 验证器

评估平台协调器，适用于：

• mode=story
• mode=plan_review

此技能使用评估平台进行：

• 必须开展官方文档、MCP Ref、Context7 和当前网络研究
• 并行只读证据通道
• 按顺序执行文档编写、修复、合并、优化和审批
• 基于运行时的工作者计划、工作者摘要、Agent 同步和清理验证

输入

输入	必填	来源	说明
storyId	mode=story	args、git 分支、kanban、用户	要验证的故事
plan {file}	mode=plan_review	args 或自动检测	要验证的计划文件

模式检测：

• plan 或 plan {file} -> mode=plan_review
• 否则 -> mode=story

必读

必须阅读： 加载 references/environment_state_contract.md、references/storage_mode_detection.md、references/input_resolution_pattern.md
必须阅读： 加载 references/evaluation_coordinator_runtime_contract.md、references/evaluation_summary_contract.md、references/evaluation_parallelism_policy.md、references/evaluation_research_contract.md
必须阅读： 加载 references/agent_delegation_pattern.md
必须阅读： 加载 references/penalty_points.md
必须阅读： 当 researchgraph 文件发生更改，或目标声称已具备假设、目标、基准或提案就绪条件时，加载 references/researchgraph_mcp_usage.md。
条件阅读：只有当协调器执行内联标准映射，而非使用 ln-312 的发现摘要时，才加载 references/phase2_research_audit.md。

Agent 审查策略：执行健康检查；无顾问可用时记录跳过原因；合并前验证每项顾问声明；将传输、身份验证或工具故障视为操作证据，而非领域发现。只有在评估运行时之外调试生命周期／存活状态详情时，才加载 references/agent_review_workflow.md。

工作者集合

协调器使用以下评估工作者：

• ln-311-review-research-worker
• ln-312-review-findings-worker
• ln-313-review-docs-worker
• ln-314-review-repair-worker
• ln-315-review-merge-worker
• ln-316-review-refinement-worker

工作者调用（必须）

宿主技能调用： 必须使用 Skill(skill: "...", args: "...") 进行委派。

• Claude：严格按所示调用 Skill 工具。
• Codex：如果没有 Skill 工具，则在可用技能中找到指定技能，读取其 SKILL.md，将 args 视为 $ARGUMENTS，执行该技能工作流，然后携带结果／产物返回此处。
• 不要内联工作者逻辑，也不要在未执行目标技能的情况下标记工作者已完成。

使用 Skill 工具委派工作者。不要在协调器中内联工作者逻辑。

TodoWrite 格式（必须）：

• Resolve target and build runtime manifest
• Load target artifacts and metadata
• Launch external agents and verify health
• Run research and findings workers in parallel
• Generate documentation updates
• Apply accepted low-risk repairs
• Sync agents and merge all evidence
• Run refinement (MANDATORY in ALL modes when advisor available — do NOT skip)
• Compute verdict and write review output
• Verify runtime cleanup and self-check

代表性调用：

Skill(skill: "ln-311-review-research-worker", args: "{identifier} research")
Skill(skill: "ln-312-review-findings-worker", args: "{identifier} findings")
Skill(skill: "ln-313-review-docs-worker", args: "{identifier} docs")
Skill(skill: "ln-314-review-repair-worker", args: "{identifier} repair")
Skill(skill: "ln-315-review-merge-worker", args: "{identifier} merge")
Skill(skill: "ln-316-review-refinement-worker", args: "{identifier} refinement")

运行时契约

**必须阅读：**加载 references/loop_health_contract.md

运行时系列：

• evaluation-runtime

标识符：

• 故事模式使用 story-{storyId}
• 计划评审使用 plan-{slug}

阶段顺序：

1. PHASE_0_CONFIG
2. PHASE_1_DISCOVERY
3. PHASE_2_AGENT_LAUNCH
4. PHASE_3_EVIDENCE_LANES
5. PHASE_4_DOCS
6. PHASE_5_REPAIR
7. PHASE_6_MERGE
8. PHASE_7_REFINEMENT
9. PHASE_8_APPROVAL
10. PHASE_9_SELF_CHECK

阶段策略：

• delegate_phases = [PHASE_3_EVIDENCE_LANES, PHASE_4_DOCS, PHASE_5_REPAIR, PHASE_6_MERGE, PHASE_7_REFINEMENT]
• aggregate_phase = PHASE_6_MERGE
• report_phase = PHASE_8_APPROVAL
• cleanup_phase = PHASE_9_SELF_CHECK
• self_check_phase = PHASE_9_SELF_CHECK
• agent_resolve_before = [PHASE_6_MERGE]
• required_phases_when_advisor_available = [PHASE_7_REFINEMENT]

并行规则

允许重叠执行：

• 外部 Agent
• ln-311
• ln-312
• 本地仓库检查和证据收集

仅可顺序执行：

• ln-313
• ln-314
• ln-315
• ln-316
• 审批和状态变更

工作流

阶段 0：配置

1. 确定 mode、标识符和存储模式。
2. 确定故事或计划目标。
3. 构建评估运行时清单，包含：
   • expected_agents
   • required_research=true
   • 精确的 phase_order
   • phase_policy
   • 报告路径
4. 启动运行时：

node references/scripts/evaluation-runtime/cli.mjs start \
  --skill ln-310 \
  --identifier {identifier} \
  --manifest-file .hex-skills/evaluation/{identifier}_manifest.json

5. 检查点记录阶段 0。

阶段 1：发现

1. 生成精确的目标产物。
2. 仅加载当前模式所需的元数据。
3. 在 mode=story 下，确定 Story 和子任务。
4. 在 mode=plan_review 下，确定计划文件。
5. 如果 researchgraph 文件有变更，或目标引用了 H##、G##、运行 ID、基准清单或就绪状态声明，则运行只读的 researchgraph 验证/审计，并将结果作为验证证据附加。
6. 检查点记录阶段 1，并附上已确定的引用。

阶段 2：启动 Agent

1. 运行 Agent 健康检查。
2. 从 .hex-skills/environment_state.json 中排除已禁用的 Agent。
3. 如果没有可用的 Agent：
   • 记录 agents_skipped_reason
   • 检查点记录阶段 2
   • 继续
4. 否则：
   • 构建各 Agent 的提示词
   • 启动每个可用的 Agent
   • 注册每个已启动的 Agent：

node references/scripts/evaluation-runtime/cli.mjs register-agent \
  --skill ln-310 \
  --identifier {identifier} \
  --agent {name} \
  --prompt-file {promptPath} \
  --result-file {resultPath} \
  --metadata-file {metadataPath}

5. 检查点记录阶段 2，并附上 health_check_done、agents_available、agents_required，以及可选的 agents_skipped_reason。
6. 在给出领域判定前，对每个外部 Agent 的结果进行分类：
   • rate_limited、tool_missing、auth_missing、permission_denial 和 asked_question 属于传输/操作状态。
   • 没有来自产物或发现项的领域证据时，不要将它们转为 NO-GO。
   • 记录重复的顾问/会话失败所反映的循环健康情况，并在重试不再有用时暂停。

阶段 3：证据通道

此阶段是强制性的并行证据屏障。

1. 构建 worker_plan，包含：
   • 通道为 research 的 ln-311（强制）
   • 通道为 findings 的 ln-312（强制）
2. 并行启动所有计划中的工作器。
3. 在这些工作器运行期间，继续检查本地仓库并收集其他证据。
4. 适时同步 Agent，但在合并前不要等待它们。
5. 按以下格式记录每个工作器的摘要：

node references/scripts/evaluation-runtime/cli.mjs record-worker-result \
  --skill ln-310 \
  --identifier {identifier} \
  --payload-file {childSummaryArtifactPath}

所有模式下都必须进行研究：

• 官方文档或标准
• MCP Ref
• 涉及库或框架时使用 Context7
• 当前网络最佳实践研究

对于 mode=story，发现项仍必须提供罚分证据和覆盖率分析。

阶段 4：文档

1. 在 mode=story 下，如果需要更改文档，则运行 ln-313-review-docs-worker。
2. 在 mode=plan_review 下，仅在没有需要创建的文档差异时才跳过。
3. 记录工作器摘要或明确的跳过理由。

阶段 5：修复

1. 通过 ln-314-review-repair-worker 应用已接受的低风险修复。
2. 不要将修复逻辑合并到研究或发现通道中。
3. 记录摘要和任何清理证据。

阶段 6：合并

前置条件：

• 所有计划中的证据工作者均已解决
• 所有必需的 Agent 均已解决或明确跳过

步骤：

1. 在合并屏障处同步一次 Agent：

node references/scripts/evaluation-runtime/cli.mjs sync-agent --skill ln-310 --identifier {identifier}

2. 运行 ln-315-review-merge-worker。
3. 对以下内容去重：
   • 本地发现
   • 工作线程发现
   • Agent 发现
   • 先前的审查历史
4. 拒绝缺乏依据的主张。
5. 仅应用已验证且接受的更改。
6. 使用 aggregation_summary 为阶段 6 创建检查点。

阶段 7：完善

绝 NEVER 跳过此阶段。 阶段 7 适用于所有模式：story、plan_review。 唯一有效的跳过理由是健康检查中没有可用的顾问。 模式不是跳过理由。复杂度不是跳过理由。时间不是跳过理由。 如果顾问可用，但你准备在未运行 ln-316 的情况下为阶段 7 创建检查点——请停止。你正在犯错。

模式	是否需要阶段 7？	是否允许跳过？
story	是	否（仅当没有可用顾问时允许）
plan_review	是	否（仅当没有可用顾问时允许）

顾问可用时，阶段 7 为强制阶段。协调器不得在没有 ln-316 记录的 review-refinement 工作线程摘要时为阶段 7 创建检查点。如果健康检查时有顾问可用，但不存在完善摘要，运行时 advance 命令将拒绝状态转换。

运行 ln-316-review-refinement-worker。完善使用两阶段状态机：

• 阶段 1：3 个并行顾问会话（dry_run_executor、new_dev_tester、adversarial_reviewer）
• 阶段 2：合并阶段 1 的结果后，运行 1 个顺序顾问会话（final_sweep）

规则：

• 必须涵盖全部 4 个视角
• 阶段 1 并行运行，阶段 2 在合并阶段 1 后运行
• 每个视角都必须通过 agent_runner.mjs 运行独立的顾问进程（不是主机原生子 Agent）
• 每个已启动的进程都必须提供清理证据
• 顾问会话失败时，使用 agent_runner.mjs 提供的 failure_class、progress_signals 和 session_usable；已分类的传输故障应暂停/延期，而不是转为领域发现
• 必须提供完善追踪记录
• 通过运行时 sync-agent 等待顾问结果；Claude 主机可使用 Monitor 进行可观测性检查

阶段 8：批准

故事模式：

1. 根据合并后和完善后的状态计算最终门禁结果。
2. 最终评估模型：

指标	之前	之后	含义
惩罚分	来自 ln-312	来自 ln-314	0 = 全部已修复
就绪度评分	clamp(1,10,10-floor(before/5))	clamp(1,10,10-floor(after/5))	质量（1-10）
反幻觉	—	来自 ln-311	VERIFIED/FLAGGED
AC 覆盖率	—	N/N	100% = 通过
门禁	—	GO/NO_GO	最终判定

3. 门禁规则：
   • GO = penalty_after=0，且没有 FLAGGED 项，且 ac_coverage=100%
   • NO_GO = 其他情况
   • 覆盖率：80-99% = +3 惩罚分，并强制设为 NO_GO
   • 覆盖率：<80% = +5 惩罚分，并强制设为 NO_GO
4. 若为 GO：将 Story 状态更改为 Todo；将 kanban_board.md 更新为 APPROVED。
5. 重试状态转换一次；如果失败 → NO_GO。
6. 编写面向用户的审查结果，按标准列出惩罚分的前后变化明细。

计划模式：

• 编写最终审查结果，不更改工作流状态

编写协调器摘要：

node references/scripts/evaluation-runtime/cli.mjs record-summary \
  --skill ln-310 \
  --identifier {identifier} \
  --payload '{...evaluation-coordinator summary...}'

阶段 9：自检

必需检查：

• 运行时已启动
• 存在发现检查点
• 已记录 Agent 健康状况
• 已完成强制研究
• 已记录所有必需的工作线程摘要
• 合并前已解决所有必需的 Agent
• 存在合并摘要
• 顾问可用时，存在完善追踪记录
• 已记录后台清理证据
• 已验证清理完成
• 已记录协调器摘要
• 已记录最终结果

然后：

node references/scripts/evaluation-runtime/cli.mjs complete --skill ln-310 --identifier {identifier}

摘要约定

协调器摘要类型：

• evaluation-coordinator

建议的负载字段：

• status
• final_result
• report_path
• worker_count
• agent_count
• issues_total
• severity_counts
• warnings
• cleanup_verified
• research_completed
• penalty_before
• penalty_after
• readiness_score
• ac_coverage
• gate (GO/NO_GO)
• flagged_items

完成定义

• 评估运行时已启动
• 强制研究已完成并记录
• 只读证据通道已并行执行
• 文档、修复、合并、优化和审批已按顺序执行
• 所有必需的工作者摘要均已记录
• 所有必需的 Agent 均已在合并前解决
• 顾问可用时已执行优化；仅当健康检查确认没有可用顾问时，才标记为 SKIPPED
• 清理证据已记录并验证
• 已写入 evaluation-coordinator 摘要
• 运行时已成功完成

元分析

可选参考：仅当用户要求运行后的元分析或按协议格式撰写运行反思时，才加载 references/meta_analysis_protocol.md。

在协调器运行结束后收到请求时，按照协议第 7 节分析会话，并在最终审查结果中包含按协议格式整理的输出。

参考资料

• 运行时：references/evaluation_coordinator_runtime_contract.md、references/evaluation_summary_contract.md
• 研究：references/evaluation_research_contract.md、references/research_tool_fallback.md、references/plan_review_pipeline.md
• 并行：references/evaluation_parallelism_policy.md
• 工作者：../ln-311-review-research-worker/SKILL.md、../ln-312-review-findings-worker/SKILL.md、../ln-313-review-docs-worker/SKILL.md、../ln-314-review-repair-worker/SKILL.md、../ln-315-review-merge-worker/SKILL.md、../ln-316-review-refinement-worker/SKILL.md
• 验证标准：references/phase2_research_audit.md、references/penalty_points.md
• 验证器支持资料：references/cross_reference_validation.md、references/dependency_validation.md、references/domain_patterns.md、references/templates/mcp_ref_findings_template.md、references/premortem_validation.md、references/quality_validation.md、references/risk_validation.md、references/solution_validation.md、references/standards_validation.md、references/structural_validation.md、references/traceability_validation.md、references/workflow_validation.md

---

版本： 8.0.0 最后更新： 2026-03-22