# Harness Merge Subharness Result

> 合并子代理结果技能，整合多个子代理的执行结果，处理冲突，生成最终输出

- Skill: `konglong87/harness-merge-subharness-result` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add konglong87/harness-merge-subharness-result`
- Raw SKILL.md: https://api.skillmd.com/api/skills/konglong87/harness-merge-subharness-result/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: konglong87 (https://skillmd.com/u/konglong87)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/konglong87/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 工具执行：

```bash
cd .subharness/{task-id}/WORK_TREE

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

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

### Step 4: 检测结果冲突

#### 4.1 文件冲突检测

使用 Bash 工具执行：

```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: 自动合并（无冲突）**
```yaml
条件: 文件修改无重叠或修改不同区域
动作: 自动执行 git merge
```

**策略 2: 优先级合并（有冲突）**
```yaml
条件: 文件修改冲突
动作: 按子代理优先级决定（先完成的优先）
输出: 记录冲突位置和选择理由
```

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

### Step 5: 合并结果

#### 5.1 合并代码

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

```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`

内容：

```markdown
---
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 工具执行：

```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`

内容：

```markdown
---
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`

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

### Step 9: 更新事件日志

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

```markdown
{当前时间} | 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 工具输出：

```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: 自动合并（无冲突）
```yaml
适用场景:
- 不同文件被不同子代理修改
- 同一文件的不同区域被修改
- 新增文件不冲突

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

### 策略 2: 优先级合并（有冲突）
```yaml
适用场景:
- 同一文件的不同函数被修改
- 同一文件的导入区域被修改
- 可以明确判断优先级的冲突

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

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

### 策略 3: 真实阻塞升级（严重冲突）
```yaml
适用场景:
- 同一文件同一区域被多个子代理修改
- 逻辑冲突（如一个函数被删除，另一个修改了它）
- 无法自动判断优先级的冲突

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

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

## 合并流程图

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

## 使用示例

### 示例 1: 成功合并多个子代理
```yaml
子代理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: 冲突解决
```yaml
子代理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: 严重冲突
```yaml
子代理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（处理失败）
```

### 协作示例
```yaml
场景: 多个子代理并行执行功能开发

阶段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: 并行合并
```yaml
策略: 对于无依赖关系的子代理，可以并行合并
实现: 使用 Git worktree 创建临时合并分支
优势: 加快合并速度
```

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

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