a2a-result-merge

name	a2a-result-merge
description	A2A 多 bot 协作结果汇总指南。**仅在飞书群聊中使用，私聊时不适用。** **当以下情况时使用此 Skill**： (1) 多个 bot 分别完成子任务后需要汇总结果 (2) 用户问"最终结果是什么？" (3) 收到多个 bot 的回传结果，需要整合成统一交付物 (4) 不同 bot 给出了冲突的方案，需要决策
alwaysActive	true

A2A 结果汇总

汇总时机

当你作为协作发起者，收到所有子任务的回传结果后，需要汇总并回复用户。

判断标准：

• 所有你 @ 过的 bot 都已回传结果
• 或者部分 bot 超时未响应，需要先汇报已有结果

汇总报告模板

## 协作结果汇总

### 任务概述
{用户原始需求的一句话描述}

### 各方输出

**{bot1 名字}**：
{bot1 的核心输出，精简提炼}

**{bot2 名字}**：
{bot2 的核心输出，精简提炼}

### 综合结论
{整合各方输出的最终结论或方案}

### 后续建议
{如果有需要进一步跟进的事项}

不同场景的汇总策略

技术方案汇总

多个 bot 分别给出技术方案的不同部分：

• 按架构层次组织（前端 → 接口 → 后端 → 数据库）
• 检查接口是否对齐（前端调用的接口和后端设计的是否一致）
• 标注需要协调的地方

信息收集汇总

多个 bot 分别收集不同维度的信息：

• 去重：相同信息只保留一份
• 分类：按主题或维度组织
• 补充：标注信息缺口

审查意见汇总

多个 bot 分别审查同一份内容：

• 按严重程度排序（阻塞性问题 > 建议性问题）
• 合并相同意见
• 标注有分歧的地方

冲突处理

当两个 bot 给出不同甚至矛盾的结论时：

1. 列出分歧 — 明确说明哪些地方有不同意见
2. 分析原因 — 可能是前提假设不同、关注点不同
3. 给出建议 — 基于你的判断推荐一个方案，说明理由
4. 交给用户 — 如果无法判断，把两个方案都呈现给用户决策

### ⚠️ 分歧点

后端建议使用 Redis 缓存，前端建议使用本地 IndexedDB。

**分析**：后端关注数据一致性，前端关注离线体验。两者不冲突，可以同时采用——Redis 做服务端缓存，IndexedDB 做客户端离线存储。

**建议**：采用双层缓存方案。

注意事项

• 汇总时提炼核心信息，不要原样复制各 bot 的完整输出
• 如果某个 bot 未响应，在汇总中标注"未收到回复"
• 汇总完成后直接回复用户，不要再 @ 任何 bot