Menú
合并子代理结果技能，整合多个子代理的执行结果，处理冲突，生成最终输出
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
EnjoyHarness 唯一强制入口，初始化全局状态、文件体系、技能注册表
配置文件读取和验证技能，确保用户配置正确且完整
全流程自动执行超级组合技能，编排所有16个基础技能，从用户需求到完整交付的全自动化流程
头脑风暴技能，在实现前探索用户意图、需求和设计，防止返工
实施计划执行技能，逐任务执行实施计划，支持检查点、错误恢复和进度跟踪
10倍产能提效超级组合技能，通过并行执行、智能调度、优化策略实现10倍开发效率提升
| name | harness-merge-subharness-result |
| description | 合并子代理结果技能，整合多个子代理的执行结果，处理冲突，生成最终输出 |
| trigger_words | ["harness-merge-subharness-result","合并结果","merge-subagent","结果合并"] |
| priority | MEDIUM |
| dependencies | ["harness-monitor-subharness-agent"] |
| version | v3.0.0 |
使用 Read 工具读取：.EnjoyHarness/SKILL_REGISTRY.md
检查条件：
如果未完成：
❌ 错误: 子代理未监控
💡 请先运行: harness-monitor-subharness-agent
使用 Read 工具读取：.EnjoyHarness/SUBAGENT_MONITOR_REPORT.md
提取状态为 COMPLETED 的子代理列表。
如果没有已完成的子代理：
⚠️ 警告: 无已完成的子代理
💡 请等待子代理执行完成或检查失败原因
对于每个已完成的子代理 {task-id}：
使用 Read 工具读取：.subharness/{task-id}/SUBTASK_MANIFEST.md
提取：
使用 Read 工具读取：.subharness/{task-id}/EXECUTION_TRACE.md（如果存在）
提取：
使用 Bash 工具执行：
cd .subharness/{task-id}/WORK_TREE
# 查看修改的文件
git diff --name-only HEAD~{commit-count}
# 查看具体修改内容
git diff HEAD~{commit-count}
使用 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
策略 1: 自动合并（无冲突）
条件: 文件修改无重叠或修改不同区域
动作: 自动执行 git merge
策略 2: 优先级合并（有冲突）
条件: 文件修改冲突
动作: 按子代理优先级决定（先完成的优先）
输出: 记录冲突位置和选择理由
策略 3: 真实阻塞升级（严重冲突）
条件: 同一文件同一区域被多个子代理修改
动作: 标记为 NEEDS_MANUAL_RESOLUTION
输出: "⚠️ 严重冲突，先记录并进入失败处理；无法自动收敛时再人工升级"
使用 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
使用 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}
- 修改文件总数: {总数}
- 新增文件: {新增列表}
- 删除文件: {删除列表}
- 修改文件: {修改列表}
## 建议操作
- {具体建议，如"运行集成测试"或"人工解决冲突"}
使用 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
使用 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"或"继续优化"}
使用 Edit 工具更新：.EnjoyHarness/GLOBAL_STATE.md
current_task: none
active_subagents: []
last_completed_task: {task-id}
last_completed_at: {当前时间}
使用 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}
使用 Edit 工具更新：.EnjoyHarness/EVENT_LOG.md
old_string: total_events: N
new_string: total_events: N+3
使用 Edit 工具更新：.EnjoyHarness/SKILL_REGISTRY.md
old_string: - [ ] harness-merge-subharness-result - 合并结果技能
new_string: - [x] harness-merge-subharness-result - 合并结果技能 ✅
使用 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 ""
本技能执行预计迭代次数: 约 10 次（Read 4次 + Write 2次 + Edit 4次）
输入: 在子代理未监控时运行 期望输出: 错误提示"子代理未监控" 验证方式: 删除监控报告后运行
输入: 所有子代理状态为 IN_PROGRESS 期望输出: 警告"无已完成的子代理" 验证方式: 确保无子代理状态为 COMPLETED
输入: 两个子代理修改不同文件
期望输出: 成功合并，无冲突
验证方式: git log 检查合并提交
输入: 两个子代理修改同一文件 期望输出: 检测到冲突并记录 验证方式: 检查 MERGED_RESULTS.md 中的冲突列表
输入: 文件冲突但可自动解决 期望输出: 按优先级合并成功 验证方式: 检查最终代码内容
输入: 同一文件同一区域被修改 期望输出: 标记为 NEEDS_MANUAL_RESOLUTION 验证方式: 检查合并报告中的状态
输入: 合并后运行测试 期望输出: 测试通过，记录 TEST_PASS 验证方式: 检查 .EnjoyHarness/.test-result 文件
输入: 合并后测试失败 期望输出: 记录失败原因 验证方式: 检查事件日志中的 INTEGRATION_TEST 事件
输入: 执行合并技能
期望输出: 生成 FINAL_REPORT.md
验证方式: ls .EnjoyHarness/FINAL_REPORT.md
输入: 读取 GLOBAL_STATE.md
期望输出: current_task 为 none，active_subagents 为空
验证方式: grep "current_task" .EnjoyHarness/GLOBAL_STATE.md
适用场景:
- 不同文件被不同子代理修改
- 同一文件的不同区域被修改
- 新增文件不冲突
动作:
- 自动执行 git merge
- 无需额外交互，直接继续自治链路
- 记录合并日志
适用场景:
- 同一文件的不同函数被修改
- 同一文件的导入区域被修改
- 可以明确判断优先级的冲突
优先级规则:
1. 先完成的子代理优先
2. 核心功能优先于辅助功能
3. 修复Bug优先于功能开发
动作:
- 使用 git checkout --theirs 或 --ours
- 记录选择理由
- 标记为"自动解决冲突"
适用场景:
- 同一文件同一区域被多个子代理修改
- 逻辑冲突（如一个函数被删除，另一个修改了它）
- 无法自动判断优先级的冲突
动作:
- 标记为 NEEDS_MANUAL_RESOLUTION
- 记录冲突位置和原因
- 输出自动失败处理与人工升级步骤
- 不执行自动合并
人工解决步骤:
1. 查看冲突文件: git status
2. 打开冲突文件，搜索 <<<<<<< HEAD
3. 手动选择保留的代码
4. 提交解决: git add {file} && git commit
[开始合并]
↓
[读取子代理结果]
↓
[检测冲突]
↓
判断: 是否有冲突?
├─ 无冲突 → [自动合并] → [运行测试]
└─ 有冲突 → 判断: 冲突严重程度?
├─ 轻微 → [优先级合并] → [运行测试]
└─ 严重 → [标记真实阻塞] → [触发失败处理] → [仍阻塞再升级]
↓
判断: 测试是否通过?
├─ 通过 → [生成最终报告] → [完成]
└─ 失败 → [记录失败原因] → [触发 harness-handle-failure]
子代理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
子代理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子代理重新适配)
子代理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 → 校验最终输出是否符合架构规则
策略: 对于无依赖关系的子代理，可以并行合并
实现: 使用 Git worktree 创建临时合并分支
优势: 加快合并速度
策略: 只运行受影响文件的测试
实现: 分析修改文件，运行相关测试文件
优势: 减少测试时间
策略: 对于未修改的文件，跳过测试
实现: 使用测试框架的缓存机制
优势: 避免重复测试