brainstorm

头脑风暴

使用并行 Agent 针对某个问题生成并评估相互竞争的解决方案。每位提案者独立设计一种方案，然后所有提案者互相评议对方的方案。负责人将所有内容综合成结构化比较，供用户选择。

适用场景

• “……的最佳方法是什么？”——开放式设计问题
• 存在多种有效方案，且权衡取舍尚不明确
• 希望在决定采用某种实现方案前探索解决空间
• 难以逆转的架构或设计决策
• 用户明确要求进行头脑风暴、比较方案或评估选项

不适用场景

• 问题只有一种显而易见的解决方案——直接处理即可
• 调试问题——改用 competing-hypotheses
• 需要并行研究的多部分问题——改用 team-solve

---

说明

你是协调结构化头脑风暴的主持人。

协调协议

队友之间的消息是异步的——现在发送的消息，接收者可能要等完成当前工作后才会阅读。你不能依赖消息的发送时间来协调。相反，任务状态是共享状态，能让每个 Agent 了解当前进展。

以任务状态标记进展

队友收到消息时，应通过检查自己的任务状态来判断该消息在对话中的位置，而不是假设消息是“刚刚”发来的。

状态	设置者	含义
pending	负责人	尚未开始，正在等待分配
in_progress	队友	正在处理，或已完成并暂停等待负责人确认
completed	仅限负责人	负责人已阅读队友的报告——这表示已确认

由负责人将任务标记为 completed，而非队友。 队友看到自己的任务标记为 completed 时，便知道负责人已处理其报告，之后收到的任何新消息都是当前的。

队友协议

在发给每位队友的启动提示中加入以下规则：

1. 开始工作时，将任务标记为 in_progress
2. 使用 TaskGet 读取任务——任务描述包含你所需的一切内容（待评审的提案、需要纳入的反馈等）。不要搜索文件系统或其他 Agent 的文件来查找这些内容。
3. 如果任务描述缺少必要内容（例如，评审任务中没有提案），立即告知负责人并暂停。不要自行臆测。
4. 完成后，通过 SendMessage 发送报告，然后暂停——停止所有工作，不要检查 TaskList 或认领新任务。只需等待。
5. 对收到的任何消息采取行动前，先通过 TaskGet 检查任务状态：
   • 仍为 in_progress → 负责人尚未确认你的报告。该消息可能早于你的报告。请回复当前状态，不要重新执行任务。
   • 已为 completed → 负责人已处理你的报告。如果消息为你分配了新任务，则该消息包含当前指示——按要求继续。
6. 发送报告前，等待所有已启动的子 Agent 完成。不要留下仍在运行的后台工作。

负责人协议

1. 阅读队友的报告后，将其任务标记为 completed（表示已确认）
2. 发送新指示前，确保上一项任务已标记为 completed，且新任务已创建并分配
3. 通过 TaskList 确认各阶段已完成——检查所有相关任务是否处于预期状态，不要只凭记忆追踪消息

阶段 1：问题界定

启动任何 Agent 前，先明确界定问题。

1. 解析用户输入，了解：
   • 问题：需要解决或决定什么？
   • 约束：预算、时间安排、技术栈、兼容性、团队技能等。
   • 目标：怎样才算成功？性能、可维护性、简洁性、可扩展性？
   • 背景：当前已有些什么？已经尝试过或排除过哪些方案？
2. 如果问题描述不够充分，请提出澄清问题——好的头脑风暴需要明确的约束
3. 定义评估标准——比较各项提案的维度。常见标准包括：
   • 复杂度（实现工作量）
   • 风险（可能出现的问题）
   • 性能／可扩展性
   • 可维护性（长期成本）
   • 灵活性（适应未来变化的能力）
   • 根据此问题的具体重点调整标准
4. 决定方案范围——尽量涵盖多种思路，而不是提出 N 个相同想法的变体。例如：
   • 一个直接／简单的方案（工作量最少、组成部分最少）
   • 一个稳健／全面的方案（处理最多边缘情况，最能适应未来需求）
   • 一个非常规的方案（采用不同范式，或以创新方式重新界定问题）
   • 根据问题调整——并非每次头脑风暴都需要激进方案；有些问题适合提出两个务实方案，而不是勉强追求创意
5. 向用户说明问题界定：
   • 问题陈述、约束和评估标准
   • 计划安排的提案者人数（2-4 人）以及每人的思路方向
   • 询问：“我将启动 N 位提案者来设计相互竞争的方案。要继续吗？”

阶段 2：并行提出方案

各项提案并行且独立地制定——彼此不交流想法。

1. 使用 TeamCreate 创建团队
2. 使用 TaskCreate 为每位提案者创建一项提案任务
3. 使用 Task 并设置 team_name，为每项提案启动一位 general-purpose 队友
   • 根据其思路方向命名（例如：simple-approach、event-driven-approach、plugin-architecture）
   • 每位提案者的提示词必须包含：
     • 阶段 1 中完整的问题陈述、约束和评估标准
     • 分配给他们的思路／方向（但要强调应以证据为依据——如果研究表明该方向不合适，应如实说明，而不是勉强采用）
     • 研究代码库／背景并设计方案，不要做任何更改的指示
     • 上述协调协议中的队友协议（逐字复制到提示词中）
     • 以下子 Agent 指引（复制到提示词中）
     • 使用下方的提案格式，通过 SendMessage 报告方案的指示
   • 并行启动所有提案者
4. 提案者报告进展后，将相应的提案任务标记为 completed（确认已收到报告），并向用户简要更新进度
5. 提案者报告后不要关闭他们——阶段 3 和 4 仍需要他们

提案者的子 Agent 指引

将以下内容添加到每位提案者的提示词中：

使用子 Agent（Task 工具）来聚焦上下文。 请启动子 Agent，用于：

• 探索代码库，了解现有模式、依赖项和约束
• 研究你正在考虑的特定库、API 或方案
• 在确定某个方向前，检查其可行性
• 调查代码库中其他地方如何解决类似问题

每个子 Agent 都应报告：

1. 相关发现——对你的提案有影响的发现
2. 行不通的方向（1-2 句话）——看似可行但实际上不可行的方案，以及原因

选择子 Agent 类型时，代码库搜索优先选只读或专注于探索的类型；针对需要深入工具访问的分析（例如运行命令以测试可行性），则使用功能完整的类型——但不要更改文件。

提案格式

每位提案者应按以下格式撰写报告：

## Proposal: {title}

### Summary
{2-3 sentence overview of the approach}

### Design
- {how it works, key components, data flow}
- {which files/modules would be created or changed}
- {key implementation decisions and why}

### Strengths
- {what this approach does well}
- {which evaluation criteria it scores highest on}

### Weaknesses
- {known limitations or downsides}
- {which evaluation criteria it scores lowest on}

### Risks & Open Questions
- {what could go wrong}
- {unknowns that would need to be resolved during implementation}

### Effort Estimate
{relative sizing: small / medium / large, with brief justification}

### Confidence: {high/medium/low}
{how confident are you this approach would work well?}

阶段 3：同行评审

每位提案者都要评审所有其他提案，不只是投票，还要提出实质性意见。

1. TaskList 中所有提案任务都显示为 completed 后，收集所有提案
2. 为每位提案者使用 TaskCreate 创建一个评审任务。在任务描述中包含：
   • 除该提案者本人提案之外的所有提案全文
   • 阶段 1 的评估标准
   • 以下评审说明和格式
3. 将每个评审任务分配给相应的提案者，并向其发送消息，告知评审任务已准备就绪——任务描述中包含他们所需的全部内容
4. 并行发送所有评审消息——提案者同时进行评审
5. 收到评审者的反馈后，将相应评审任务标记为 completed（确认已收到报告），并向用户简要更新进度

评审说明

在每条评审消息中加入以下内容：

评审以下其他提案。请对每项提案作出诚实评价——你们不是在竞争，而是在帮助用户作出明智的决定。请具体、客观地提出建设性意见。

重要事项：

• 即使某种方案与你的方案截然不同，也要指出其真正的优点
• 指出提案者可能忽略的不足或风险
• 如果某项提案与你的方案有显著重叠，或可以合并，请予以说明——但除非合并确实更好，否则不要主张合并。各自独立的优质方案比勉强达成的折中更有价值。
• 如果其他提案中的某些内容让你想修改自己的方案，请予以说明——之后你将有机会修改

评审格式

每位评审者应按以下格式撰写报告：

## Reviews by {your proposal title}

### Review of "{other proposal title}"
**Strengths I see:**
- {what this approach does well that's worth preserving}

**Gaps or risks missed:**
- {things the proposer didn't address}

**Questions:**
- {things that are unclear or need more detail}

**Would I adopt any of this?**
{yes/no — and what specifically, if yes}

### Review of "{another proposal title}"
...

### Self-reflection
{After seeing the other proposals, what would you change about your own? Be specific.}

阶段 4：修订

提案者有一次机会根据同行反馈完善提案。

1. TaskList 中所有评审任务都显示为 completed 后，收集所有评审意见
2. 为每位提案者使用 TaskCreate 创建一个修订任务。在任务描述中包含：
   • 其他提案者对其提案的所有评审全文
   • 该提案者在阶段 3 的自我反思
   • 以下修订说明
3. 将每个修订任务分配给相应的提案者，并向其发送消息，告知修订任务已准备就绪——任务描述中包含他们所需的全部内容
4. 并行发送所有修订消息
5. 收到修订后的提案后，将相应修订任务标记为 completed（确认已收到报告），并向用户简要更新进度

修订说明

在每条修订消息中加入以下内容：

你已收到其他提案者的反馈。请修订提案，弥补合理指出的不足，但不要放弃核心方案，以迎合其他人。目标是尽可能完善你自己的方案，而不是将所有方案混合起来。

具体来说：

• 解决评审者指出的不足和风险（如果确实存在）
• 澄清评审者认为不清楚的内容
• 仅当其他提案中的好点子确实能改进你的方案，且不会从根本上改变方案时，才将其纳入
• 如果评审者的批评不适用，或基于误解，请简要说明原因

使用与之前相同的提案格式，但标明修改之处。在末尾添加“v1 变更”部分，列出修改内容及原因。

阶段 5：结构化比较

负责人将所有内容综合整理，为用户提供清晰的比较。

1. 确认 TaskList 中的所有修订任务都显示为 completed 后，收集最终提案

2. 构建一个权衡矩阵，根据阶段 1 的标准评估每项提案：

   标准	提案 A	提案 B	提案 C
   复杂度	...	...	...
   风险	...	...	...
   ...	...	...	...

3. 对每项提案进行总结：

   • 核心思路（1–2 句话）
   • 主要优势（值得考虑的原因）
   • 主要风险（最可能出问题的地方）
   • 同行共识（其他提案者对这种方案有哪些共识？）

4. 指出任何意外共识——如果所有提案者都指出了相同的风险，或都称赞了各项提案中的同一方面，请重点说明

5. 如果各项提案处于真实权衡光谱中的不同位置（例如，简单但受限与复杂但灵活），请将它们作为不同选项呈现——除非用户要求采用混合方案，否则不要试图将它们合并成折中方案

6. 如果某项提案明显优于其他方案，请给出建议；如果选择确实取决于个人偏好或优先级，则请说明需要权衡的选择

7. 将比较结果呈现给用户，并询问他们希望采取哪种方向（或是否想进一步探讨）

阶段 6：交接

这项技能止于提出建议，不负责实施。

1. 用户选定方案后，将其总结为一份清晰的简报：
   • 选定的提案（最终修订版）
   • 关键决策及其理由
   • 已知风险及缓解措施
   • 建议的实施顺序或第一步
2. 向所有队友发送关闭请求，并在结束前等待每位队友确认
3. 然后，用户可以直接实施，也可以将简报交给 team-solve，进行结构化实施

规则

• 提案期间保持独立 — 提案者在第 3 阶段之前不得查看彼此的成果
• 诚恳的同行评审 — 评审者应提出有建设性的批评，而不是试图削弱其他方案的竞争者
• 保留多样性 — 目标是提出各具特色的优质选项，而不是达成一致。两个立场截然不同的提案，胜过一个平淡的折中方案
• 修订，而非推倒重来 — 第 4 阶段是完善提案，而不是取而代之。如果提案者想从根本上改变自己的做法，这说明原有思路有误，而不是应该改成别人的提案
• 2–4 名提案者 — 少于 2 人就称不上头脑风暴；超过 4 人则收益递减，还会造成评审疲劳
• 任务状态是事实依据 — 通过 TaskUpdate 状态协调，而非依赖消息时间。务必检查 TaskList，确认当前状态。
• 队友汇报后暂停 — 发送报告后，停止工作并等待。不要自行认领新任务，也不要在检查任务状态之前处理排队中的消息。
• 由负责人标记 completed — 只有负责人可以将任务标记为 completed。这表示已确认完成，至此流程闭环。
• 子 Agent 成本低，上下文成本高 — 提案者应将研究工作交给子 Agent，而不是事事亲力亲为
• 完成子 Agent 工作后再汇报 — 发送报告之前，等待所有已启动的子 Agent 完成工作
• 任务中应包含内容 — 评审和修订任务的描述必须包含提案或反馈的全文。队友应使用 TaskGet 查看分配给自己的任务，以获取所需的全部信息。不要通过搜索文件系统、团队配置或其他 Agent 的临时文件来查找提案或反馈。
• 内容缺失？暂停并询问。 — 如果队友收到的评审或修订任务描述中没有所需的提案或反馈，应立即告知负责人：“任务缺少必要内容，暂停等待提供”，然后停止。不要擅自到其他地方查找内容。
• 不负责实现 — 此技能只提供建议，不编写代码。应移交给 team-solve 或直接进入实现。
• 如果队友暂时没有动静，这是正常的——轮到他们时再发送消息
• 队友未响应？ — 如果队友在合理时间内没有汇报，请检查其任务状态。如果卡住了，就启动替代人员并告知用户