Harness Merge Subharness Result

harness-merge-subharness-result 合并子代理结果技能

核心能力

1. 检查前置条件（harness-monitor-subharness-agent）
2. 读取所有已完成子代理的结果
3. 检测并处理结果冲突
4. 合并代码修改（Git merge）
5. 运行集成测试
6. 生成最终输出报告

前置条件

• harness-monitor-subharness-agent 已完成
• 至少有一个子代理状态为 COMPLETED

执行步骤

Step 1: 检查前置条件

使用 Read 工具读取：.EnjoyHarness/SKILL_REGISTRY.md

检查条件：

• harness-monitor-subharness-agent 已标记为完成

如果未完成：

❌ 错误: 子代理未监控
💡 请先运行: harness-monitor-subharness-agent

Step 2: 获取已完成子代理列表

使用 Read 工具读取：.EnjoyHarness/SUBAGENT_MONITOR_REPORT.md

提取状态为 COMPLETED 的子代理列表。

如果没有已完成的子代理：

⚠️ 警告: 无已完成的子代理
💡 请等待子代理执行完成或检查失败原因

Step 3: 读取子代理结果

对于每个已完成的子代理 {task-id}：

3.1 读取子代理清单

使用 Read 工具读取：.subharness/{task-id}/SUBTASK_MANIFEST.md

提取：

• 任务描述
• 成功标准
• 输出文件列表

3.2 读取执行日志

使用 Read 工具读取：.subharness/{task-id}/EXECUTION_TRACE.md（如果存在）

提取：

• 执行节点列表
• 每个节点的输出
• 错误和警告

3.3 读取代码修改

使用 Bash 工具执行：

cd .subharness/{task-id}/WORK_TREE

# 查看修改的文件
git diff --name-only HEAD~{commit-count}

# 查看具体修改内容
git diff HEAD~{commit-count}

Step 4: 检测结果冲突

4.1 文件冲突检测

使用 Bash 工具执行：

# 收集所有子代理修改的文件
for dir in .subharness/*/WORK_TREE; do
  cd "$dir"
  git diff --name-only HEAD~{commit-count} >> /tmp/modified_files.txt
  cd - > /dev/null
done

# 检查是否有文件被多个子代理修改
sort /tmp/modified_files.txt | uniq -d > /tmp/conflict_files.txt

if [ -s /tmp/conflict_files.txt ]; then
  echo "⚠️ 检测到冲突文件:"
  cat /tmp/conflict_files.txt
fi

4.2 冲突处理策略

策略 1: 自动合并（无冲突）

条件: 文件修改无重叠或修改不同区域
动作: 自动执行 git merge

策略 2: 优先级合并（有冲突）

条件: 文件修改冲突
动作: 按子代理优先级决定（先完成的优先）
输出: 记录冲突位置和选择理由

策略 3: 真实阻塞升级（严重冲突）

条件: 同一文件同一区域被多个子代理修改
动作: 标记为 NEEDS_MANUAL_RESOLUTION
输出: "⚠️ 严重冲突，先记录并进入失败处理；无法自动收敛时再人工升级"

Step 5: 合并结果

5.1 合并代码

使用 Bash 工具执行（对于每个子代理）：

# 切换到主分支
git checkout main

# 合并子代理分支
git merge subtask/{task-id} --no-ff -m "Merge subagent {task-id} results"

# 如果有冲突，按策略处理
if [ $? -ne 0 ]; then
  # 自动解决冲突（优先级合并）
  git checkout --theirs {conflicted-files}
  git add {conflicted-files}
  git commit -m "Resolve conflicts from {task-id}"
fi

5.2 合并文档

使用 Write 工具创建文件：.EnjoyHarness/MERGED_RESULTS.md

内容：

---
merged_at: {当前时间}
total_subagents: {总数}
successful_merges: {成功数}
conflicts_resolved: {冲突解决数}
---

# Merged Results Report

## 合并概况
- 合并时间: {当前时间}
- 子代理总数: {总数}
- 成功合并: {成功数}
- 冲突解决: {冲突解决数}

## 合并详情

### 子代理: {task-id-1}
- 状态: ✅ 成功合并
- 修改文件: {文件列表}
- 提交哈希: {commit-hash}
- 冲突: 无

### 子代理: {task-id-2}
- 状态: ⚠️ 合并并解决冲突
- 修改文件: {文件列表}
- 提交哈希: {commit-hash}
- 冲突文件: {冲突文件列表}
- 解决策略: 优先级合并（先完成优先）

### 子代理: {task-id-3}
- 状态: ❌ 合并失败（严重冲突）
- 冲突文件: {冲突文件列表}
- 需要人工: 是

## 最终输出
- 合并提交: {merge-commit-hash}
- 修改文件总数: {总数}
- 新增文件: {新增列表}
- 删除文件: {删除列表}
- 修改文件: {修改列表}

## 建议操作
- {具体建议，如"运行集成测试"或"人工解决冲突"}

Step 6: 运行集成测试

使用 Bash 工具执行：

# 运行测试套件
npm test  # 或其他项目的测试命令

# 记录测试结果
TEST_RESULT=$?
if [ $TEST_RESULT -eq 0 ]; then
  echo "✅ 集成测试通过"
  echo "TEST_PASS" > .EnjoyHarness/.test-result
else
  echo "❌ 集成测试失败"
  echo "TEST_FAIL" > .EnjoyHarness/.test-result
fi

Step 7: 生成最终报告

使用 Write 工具创建文件：.EnjoyHarness/FINAL_REPORT.md

内容：

---
generated_at: {当前时间}
task_type: {任务类型}
status: {SUCCESS/PARTIAL/FAILED}
---

# Final Execution Report

## 任务概况
- 任务类型: {任务类型}
- 执行时间: {开始时间} - {结束时间}
- 总耗时: {总时长}
- 状态: {SUCCESS/PARTIAL/FAILED}

## 子代理执行情况

### 子代理1: {task-id-1}
- 任务: {任务描述}
- 状态: ✅ 完成
- 耗时: {时长}
- Token消耗: {tokens}
- 错误次数: {次数}
- 合并状态: ✅ 成功

### 子代理2: {task-id-2}
...

## 最终输出
- 合并提交: {commit-hash}
- 修改文件: {文件列表}
- 集成测试: ✅ 通过 / ❌ 失败

## Token消耗分析
- 总Token消耗: {总消耗}
- 子代理消耗: {详细列表}
- 优化建议: {建议}

## 错误分析
- 总错误次数: {总次数}
- 错误类型分布: {分布}
- 解决方案: {方案}

## 目标达成情况
- 原始目标: {目标描述}
- 达成情况: ✅ 完全达成 / ⚠️ 部分达成 / ❌ 未达成
- 验证结果: {验证详情}

## 后续建议
- {具体建议，如"提交PR"或"继续优化"}

Step 8: 更新全局状态

使用 Edit 工具更新：.EnjoyHarness/GLOBAL_STATE.md

current_task: none
active_subagents: []
last_completed_task: {task-id}
last_completed_at: {当前时间}

Step 9: 更新事件日志

使用 Edit 工具追加内容到：.EnjoyHarness/EVENT_LOG.md

{当前时间} | SUBAGENT_MERGE_START | harness-merge-subharness-result | 开始合并子代理结果 | SUCCESS
{当前时间} | SUBAGENT_MERGE_COMPLETE | harness-merge-subharness-result | 合并完成: {成功数}/{总数} | SUCCESS
{当前时间} | INTEGRATION_TEST | harness-merge-subharness-result | 集成测试: {PASS/FAIL} | {SUCCESS/FAILURE}

Step 10: 更新事件计数

使用 Edit 工具更新：.EnjoyHarness/EVENT_LOG.md

old_string: total_events: N new_string: total_events: N+3

Step 11: 更新技能注册表

使用 Edit 工具更新：.EnjoyHarness/SKILL_REGISTRY.md

old_string: - [ ] harness-merge-subharness-result - 合并结果技能 new_string: - [x] harness-merge-subharness-result - 合并结果技能 ✅

Step 12: 输出完成信息

使用 Bash 工具输出：

echo ""
echo "✅ harness-merge-subharness-result 完成!"
echo ""
echo "📊 合并统计:"
echo " - 子代理总数: {总数}"
echo " - 成功合并: {成功数}"
echo " - 冲突解决: {冲突解决数}"
echo " - 合并失败: {失败数}"
echo ""
echo "📋 详细报告:"
echo " - 合并报告: .EnjoyHarness/MERGED_RESULTS.md"
echo " - 最终报告: .EnjoyHarness/FINAL_REPORT.md"
echo ""
echo "🧪 集成测试:"
echo " - 状态: {PASS/FAIL}"
echo ""
echo "🎯 下一步:"
echo " - 成功: 运行 harness-validate-output 校验输出"
echo " - 失败: 运行 harness-handle-failure 处理失败"
echo ""

成功标准

• 读取所有已完成子代理的结果
• 检测并处理结果冲突
• 成功合并代码（或标记严重冲突）
• 运行集成测试
• 生成最终报告
• 更新全局状态
• 更新事件日志
• 技能注册表已更新

失败兜底

• harness-monitor-subharness-agent 未完成 → 终止执行，提示运行前置技能
• 无已完成子代理 → 输出警告，退出执行
• 合并冲突严重 → 标记为 NEEDS_MANUAL_RESOLUTION，输出人工解决步骤
• 集成测试失败 → 记录失败原因，触发 harness-handle-failure

联动关系

• 前置: harness-monitor-subharness-agent
• 正常触发: harness-validate-output（合并成功且测试通过）
• 异常触发: harness-handle-failure（合并失败或测试失败）

迭代计数

本技能执行预计迭代次数: 约 10 次（Read 4次 + Write 2次 + Edit 4次）

测试用例

测试 1: 前置条件检查

输入: 在子代理未监控时运行 期望输出: 错误提示"子代理未监控" 验证方式: 删除监控报告后运行

测试 2: 无已完成子代理

输入: 所有子代理状态为 IN_PROGRESS 期望输出: 警告"无已完成的子代理" 验证方式: 确保无子代理状态为 COMPLETED

测试 3: 成功合并（无冲突）

输入: 两个子代理修改不同文件 期望输出: 成功合并，无冲突 验证方式: git log 检查合并提交

测试 4: 冲突检测

输入: 两个子代理修改同一文件 期望输出: 检测到冲突并记录 验证方式: 检查 MERGED_RESULTS.md 中的冲突列表

测试 5: 冲突解决（优先级合并）

输入: 文件冲突但可自动解决 期望输出: 按优先级合并成功 验证方式: 检查最终代码内容

测试 6: 严重冲突标记

输入: 同一文件同一区域被修改 期望输出: 标记为 NEEDS_MANUAL_RESOLUTION 验证方式: 检查合并报告中的状态

测试 7: 集成测试通过

输入: 合并后运行测试 期望输出: 测试通过，记录 TEST_PASS 验证方式: 检查 .EnjoyHarness/.test-result 文件

测试 8: 集成测试失败

输入: 合并后测试失败 期望输出: 记录失败原因 验证方式: 检查事件日志中的 INTEGRATION_TEST 事件

测试 9: 最终报告生成

输入: 执行合并技能 期望输出: 生成 FINAL_REPORT.md 验证方式: ls .EnjoyHarness/FINAL_REPORT.md

测试 10: 全局状态更新

输入: 读取 GLOBAL_STATE.md 期望输出: current_task 为 none，active_subagents 为空 验证方式: grep "current_task" .EnjoyHarness/GLOBAL_STATE.md

冲突处理策略详解

策略 1: 自动合并（无冲突）

适用场景:
- 不同文件被不同子代理修改
- 同一文件的不同区域被修改
- 新增文件不冲突

动作:
- 自动执行 git merge
- 无需额外交互，直接继续自治链路
- 记录合并日志

策略 2: 优先级合并（有冲突）

适用场景:
- 同一文件的不同函数被修改
- 同一文件的导入区域被修改
- 可以明确判断优先级的冲突

优先级规则:
1. 先完成的子代理优先
2. 核心功能优先于辅助功能
3. 修复Bug优先于功能开发

动作:
- 使用 git checkout --theirs 或 --ours
- 记录选择理由
- 标记为"自动解决冲突"

策略 3: 真实阻塞升级（严重冲突）

适用场景:
- 同一文件同一区域被多个子代理修改
- 逻辑冲突（如一个函数被删除，另一个修改了它）
- 无法自动判断优先级的冲突

动作:
- 标记为 NEEDS_MANUAL_RESOLUTION
- 记录冲突位置和原因
- 输出自动失败处理与人工升级步骤
- 不执行自动合并

人工解决步骤:
1. 查看冲突文件: git status
2. 打开冲突文件，搜索 <<<<<<< HEAD
3. 手动选择保留的代码
4. 提交解决: git add {file} && git commit

合并流程图

[开始合并]
↓
[读取子代理结果]
↓
[检测冲突]
↓
判断: 是否有冲突?
├─ 无冲突 → [自动合并] → [运行测试]
└─ 有冲突 → 判断: 冲突严重程度?
    ├─ 轻微 → [优先级合并] → [运行测试]
    └─ 严重 → [标记真实阻塞] → [触发失败处理] → [仍阻塞再升级]
↓
判断: 测试是否通过?
├─ 通过 → [生成最终报告] → [完成]
└─ 失败 → [记录失败原因] → [触发 harness-handle-failure]

使用示例

示例 1: 成功合并多个子代理

子代理1: feature-20260328-110000 (用户登录功能)
修改文件: src/auth/login.js, tests/auth.test.js

子代理2: feature-20260328-110500 (用户注册功能)
修改文件: src/auth/register.js, tests/auth.test.js

合并过程:
1. 检测: 无文件冲突（不同文件）
2. 自动合并: git merge feature-20260328-110000
3. 自动合并: git merge feature-20260328-110500
4. 运行测试: npm test
5. 测试通过: ✅
6. 生成报告: FINAL_REPORT.md

状态: SUCCESS

示例 2: 冲突解决

子代理1: fix-20260328-120000 (修复登录Bug)
修改文件: src/auth/login.js (第10-20行)

子代理2: refactor-20260328-120500 (重构登录逻辑)
修改文件: src/auth/login.js (第15-30行)

冲突检测:
- 文件: src/auth/login.js
- 冲突区域: 第15-20行

冲突解决:
- 优先级判断: fix优先于refactor
- 策略: 优先级合并，保留子代理1的修改
- 记录: "保留fix-20260328-120000的修改，refactor需要重新适配"

状态: PARTIAL (需要refactor子代理重新适配)

示例 3: 严重冲突

子代理1: feature-20260328-130000 (添加用户头像功能)
修改文件: src/models/user.js (添加avatarUrl字段)

子代理2: refactor-20260328-130500 (重构User模型)
修改文件: src/models/user.js (删除User模型，迁移到UserEntity)

严重冲突:
- 同一文件完全重写
- 逻辑冲突（字段添加 vs 模型删除）

处理:
- 标记: TRUE_BLOCKER_ESCALATION_REQUIRED
- 输出: "严重冲突，自动恢复已无法安全决策，需要进入真实阻塞升级"
- 建议: "先运行 harness-handle-failure；若仍阻塞，再触发 harness-escalate-to-human"

状态: FAILED

与其他技能的协作

协作流程

harness-monitor-subharness-agent（监控子代理）
↓
判断: 子代理是否完成?
├─ 完成 → harness-merge-subharness-result（合并结果）
└─ 未完成 → 继续监控

harness-merge-subharness-result（合并结果）
↓
判断: 合并和测试是否成功?
├─ 成功 → harness-validate-output（校验输出）
└─ 失败 → harness-handle-failure（处理失败）

协作示例

场景: 多个子代理并行执行功能开发

阶段1: 监控
- harness-monitor-subharness-agent → 监控子代理A、B、C的执行状态
- 子代理A完成，子代理B完成，子代理C进行中

阶段2: 部分合并
- harness-merge-subharness-result → 合并子代理A和B的结果
- 检测冲突: 无冲突
- 运行测试: 通过
- 生成报告: MERGED_RESULTS.md

阶段3: 继续监控
- harness-monitor-subharness-agent → 继续监控子代理C
- 子代理C完成

阶段4: 最终合并
- harness-merge-subharness-result → 合并子代理C的结果
- 检测冲突: 有轻微冲突（导入顺序）
- 冲突解决: 优先级合并（C优先）
- 运行测试: 通过
- 生成最终报告: FINAL_REPORT.md

阶段5: 输出校验
- harness-validate-output → 校验最终输出是否符合架构规则

性能优化建议

优化 1: 并行合并

策略: 对于无依赖关系的子代理，可以并行合并
实现: 使用 Git worktree 创建临时合并分支
优势: 加快合并速度

优化 2: 增量测试

策略: 只运行受影响文件的测试
实现: 分析修改文件，运行相关测试文件
优势: 减少测试时间

优化 3: 缓存测试结果

策略: 对于未修改的文件，跳过测试
实现: 使用测试框架的缓存机制
优势: 避免重复测试