roundtable

通过派遣并行子 Agent，从刻意对立的视角对决策、计划或提案进行压力测试，然后综合辩论结果，给出一项保留异议的裁决。

范围：仅限决策和设计。审查差异是 /code-review 的工作——不要让圆桌会议讨论代码变更。

流程

1. 确定议题

将用户的问题重述为一个可辩论的议题——一个圆桌会议可以支持或反对的主张（“我们应该将 X 拆分成独立服务”），而不是开放式问题（“我们该如何处理 X？”）。如果用户的要求太过含糊，无法确定议题，先请他们明确问题；如果仍然模糊不清，建议先运行 /grilling，再召集圆桌会议。

然后由你在主线程中整理证据包：相关文件路径和摘录、约束条件、已做出的决定，以及用户附上的任何内容。查找事实是主持人的工作，不是席位成员的工作——子 Agent 不会自行搜集信息，因此整个圆桌会议必须基于相同证据进行讨论。

派遣任何人之前，确认议题是一个句子，且证据包足以支持辩论。含糊不清的议题应在此处被拦下，而不是等四个并行子 Agent 都开始工作后才发现。

2. 安排席位

默认设置四个席位：

• 怀疑者——假设议题行不通，并阐述原因；坚持 YAGNI 原则；寻找隐藏假设。
• 架构师——从长远结构出发论证：模块深度、耦合度、演进成本。
• 用户代言人——从使用或调用结果的人的体验出发论证；关注真实工作流，而非假设情境。
• 务实派——从最短可行路径出发论证：维护负担、机会成本、本周能交付什么。

用户可以根据主题重新安排席位（例如“安排一桌安全专家”）——席位数量保持在 3–5 个。每个席位说明，无论默认还是自定义，都必须原样包含这一行：“你的任务是从这个视角提出最有力的论据，即使你综合权衡后的判断会落在别处。” 这句话是防止观点趋同的第一道防线。

3. 第一轮——独立陈述

并行派遣 N 个子 Agent，每个席位一个。除席位说明外，每个子 Agent 获得相同的输入包，其中包括：

• 议题，逐字照录。
• 完整的证据包——子 Agent 无法从其他地方获取这些信息。
• 席位说明，包括第 2 步中的最有力论据要求。
• 输出要求：“说明你的立场（支持／反对／有条件支持）、三条最有力的论据，以及你看到的最大风险。少于 300 词。”

隔离是关键：各席位都看不到其他席位的陈述，因此不会被第一个发表的观点锚定。

4. 第二轮——匿名交叉评审

仅当用户要求进行快速圆桌讨论时，才跳过这一轮。

从第一轮陈述中移除席位名称，打乱顺序，并标记为立场 A、B、C、D。再次并行派遣 N 个子 Agent——每个子 Agent 获得：

• 议题和证据包，与之前相同。
• 自己的席位说明，以及自己的匿名立场是哪一项。
• 所有匿名立场的完整内容。
• 以下要求：“反驳你最不同意的立场，并引用你要反驳的论点。承认自己立场中被其他立场确实削弱的任何观点。按说服力从高到低排列 A–D。少于 300 词。”

匿名化能让席位针对论据而非身份展开批评——针对“怀疑者”的反驳只是作秀；针对一条未注明出处的论点，则必须真正回应其内容。

5. 主持人综合

主线程还原匿名身份并作出判断。判断不是求平均：某个立场不会因为人数较少就被判错，未被任何反驳驳倒的异议应原样写入报告，并注明其所属席位。固定输出格式：

## Verdict — the recommendation, one paragraph
## Consensus — points every seat agreed on
## Dissent worth weighing — undefeated objections, attributed to their seats
## Vote table — seat × position × cross-review ranking
## What would change the verdict — facts that would flip it

不要根据裁决采取行动——圆桌会议提供建议，由用户作出决定。

成本护栏

一轮完整的圆桌讨论包含 2N 次子 Agent 运行（N 次陈述 + N 次交叉评审）；快速模式为 N 次。最多进行两轮，不进行无休止的辩论循环。如果交叉评审后仍无法得出结论，这本身就是调查结果：报告尚未解决的分歧，以及哪些证据可以解决分歧。