多个独立子代理方案分歧时，用交叉互评强化分析并综合决策

当多个独立子代理对同一争议决策给出分歧方案时，通过让作者互相结构化评价优缺点再做综合，得到比单独综合更全面的判断。

适用场景

解决思路

1. 在若干子代理已针对同一争议问题独立产出方案或意见后，执行第二轮交叉互评；不要直接只综合它们的第一轮报告。
2. 利用作者通常比综合者拥有更深上下文这一点：让作者互相挑出失败模式、隐藏假设和权衡，而不是只由你综合。
3. 在决策存在真实分歧时使用：例如独立代理产出了明显不同的方案，或问题足够主观、合理做法会互相冲突。
4. 适用场景包括架构与设计权衡、代码评审结论不一致、竞争的根因理论、代码结构或 API 形态等无单一正确答案的问题。
5. 只要存在值得解决的真实分歧，就可以自由使用，不必额外要求高风险场景才用。
6. 若第一轮方案高度一致，或问题有可直接验证的客观答案，不要启动交叉互评，因为会增加延迟和 token 消耗。
7. 前置条件：必须先拿到 N 份彼此独立的第一轮方案；第一轮中不要让作者看到彼此的工作，以保留多样性。
8. 若还没有独立方案：对偏判断类的决策，用 **council** 技能生成，即让模型多样化的子代理回答同一问题。
9. 若还没有独立方案：对偏调查类的问题，用 **research** 技能生成，即并行启动子代理调查。
10. 也可以直接使用任何已经收集到的、临时的独立子代理方案集合。
11. 组装方案：收集每位作者的方案，只保留核心建议及其理由，不要放完整对话记录。
12. 组装方案：尽量用中性标签，例如提案 A、B、C，并尽可能匿名作者身份，减少向最自信模型或声音产生从众偏差。
13. 复用第一轮同一批子代理，而不是新开子代理，以保留它们对问题的上下文理解。
14. 把其他作者的方案，不包含该作者自己的方案，发送给每位作者，要求结构化批评。
15. 要求作者对每个替代方案分别给出优点：它做对了什么、哪些地方比我的方案更强。
16. 要求作者对每个替代方案分别给出缺点：风险、边界情况、隐藏成本、错误假设。
17. 要求作者说明：看到替代方案后，是否会修改自己的建议，以及为什么修改或不修改。
18. 要求作者给出最终排序或推荐，并附上置信度。
19. 坚持每个替代方案都同时有优点和缺点；能承认对手优点的诚实批评比条件反射式自我辩护更有用。
20. 综合时由你自己完成，比较批评时依据证据质量，而不是票数多少。
21. 最终回答先给出推荐结论。
22. 指出作者在看到彼此工作后在哪里收敛；第二轮收敛是很强的信号。
23. 列出针对每个选项提出的最尖锐的反对意见。
24. 解释为什么推荐选项在决策标准下最能经受批评。
25. 说明剩余分歧、置信度和关键未知项。
26. 默认按以下结构输出最终答案，除非任务要求不同：`## Recommendation` 一到两句决策；`## How the critiques shifted things` 作者收敛或改变点、最强反对及是否决定性；`## Why this option wins` 基于批评的理由；`## Remaining risks and unknowns` 开放问题或注意事项。
27. 实践注意：交叉互评轮保持只读，除非底层任务明确涉及做修改。
28. 实践注意：除非用户要求，不要在面向用户的总结中暴露内部子代理 ID。
29. 实践注意：如果某条批评很薄或缺乏支持，向同一作者发针对性的追问，而不是丢弃它。

适用边界 · 注意事项

• 第一轮方案已经高度一致时。
• 问题有可直接验证的客观答案时。
• 尚未获得彼此独立的第一轮方案时，先补齐独立方案，再进入交叉互评。