| 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 给出不同甚至矛盾的结论时：
- 列出分歧 — 明确说明哪些地方有不同意见
- 分析原因 — 可能是前提假设不同、关注点不同
- 给出建议 — 基于你的判断推荐一个方案，说明理由
- 交给用户 — 如果无法判断，把两个方案都呈现给用户决策
### ⚠️ 分歧点
后端建议使用 Redis 缓存，前端建议使用本地 IndexedDB。
**分析**：后端关注数据一致性，前端关注离线体验。两者不冲突，可以同时采用——Redis 做服务端缓存，IndexedDB 做客户端离线存储。
**建议**：采用双层缓存方案。
注意事项
- 汇总时提炼核心信息，不要原样复制各 bot 的完整输出
- 如果某个 bot 未响应，在汇总中标注"未收到回复"
- 汇总完成后直接回复用户，不要再 @ 任何 bot
