智能体聊天室
生成 N 个（默认 3 个）智能体，在一个模拟的共享对话中互动。每个智能体在回答前都会读取完整的聊天历史，以此为基础进行补充、质疑或完善。您（协调者）扮演项目经理的角色——主持各轮讨论、阅读辩论内容并提炼最终输出。
为什么这种方式有效： 顺序传递会丢失上下文——第二个模型不知道第一个模型做出决策的原因。共享对话保留了推理链条，并促成了真正的辩论。当智能体 A 说“这需要一个队列”，而智能体 B 说“一个简单的循环就足够了”时，这种分歧比任何一个智能体自信的单独回答都更有价值。智能体之间挑战假设、发现错误，并综合不同的推理路径。
执行步骤
1. 解析请求
从用户消息中提取：
- 问题/议题，需要辩论
- 智能体数量 N —— 默认为 3。用户可以覆盖（如“让5个智能体辩论”）。
- 辩论轮数 R —— 默认为 3 轮。用户可以覆盖（如“辩论5轮”）。
- 智能体角色（可选）—— 用户可以指定角色（如“让一个架构师、一个安全工程师和一个前端开发人员辩论这个问题”）。如果未指定，则分配不同的默认角色。
如果问题表述模糊，在生成智能体之前请先要求用户明确问题。
2. 分配智能体角色
每个智能体将获得一个独特的视角，以最大化富有成效的分歧。如果用户未指定角色，则根据问题领域从以下默认角色中选择：
软件工程：
- 架构师 —— 从系统、接口、可扩展性和长期可维护性的角度思考。
- 务实派 —— 专注于快速交付、最小复杂性、“足够好”的解决方案。
- 批评者 —— 寻找边界情况、故障模式、安全漏洞和未说明的假设。
产品/设计：
- 用户代言人 —— 专注于用户体验、简洁性和用户满意度。
- 商业策略师 —— 专注于收入、增长和竞争优势。
- 工程师 —— 将讨论扎根于技术可行性和成本。
战略/决策：
- 乐观者 —— 看到机会、潜在收益和行动的理由。
- 怀疑者 —— 看到风险、潜在损失和等待的理由。
- 综合者 —— 找到中间路线，整合双方的观点。
对于 N > 3 的情况，添加更多能够与现有角色产生有益张力的角色。
3. 初始化聊天文件
创建 active/chatroom/chat.json 文件，初始结构如下：
{
"problem": "{问题陈述}",
"context": "{任何相关上下文、代码、约束}",
"agents": [
{"name": "智能体 A", "role": "{角色}", "framing": "{角色描述}"},
{"name": "智能体 B", "role": "{角色}", "framing": "{角色描述}"},
{"name": "智能体 C", "role": "{角色}", "framing": "{角色描述}"}
],
"rounds": [],
"final_output": null
}
4. 运行辩论轮次
对于每一轮（第 1 轮到第 R 轮），并行生成所有 N 个智能体。每个智能体读取完整的聊天历史并进行贡献。
智能体生成配置：
subagent_type: "general-purpose"model: "sonnet"（默认 —— 用户可以覆盖为 opus 以进行更深入的推理）mode: "bypassPermissions"
轮次流程：
第 1 轮 —— 开场立场： 每个智能体陈述对问题的初步看法。
智能体提示：
你的角色是 {角色}：{角色描述}
问题：
{问题}
上下文：
{上下文}
这是多智能体辩论的第 1 轮。请陈述你对这个问题的初步立场。要具体且具体 —— 提出实际的解决方案，而不是模糊的原则。采取明确的立场。
其他智能体将在后续轮次中质疑你的立场，所以请明确你的推理。
按以下格式回答：
立场：[一句话概括你的立场]
推理：[你的详细论点 —— 3-5 个关键点]
提议：[你的具体建议]
顾虑：[你的方法可能出现什么问题]
直接写出你的回答 —— 不要写入任何文件。
第 2 轮及以后 —— 辩论： 每个智能体读取所有之前的回答并进行回应。
智能体提示：
你的角色是 {角色}：{角色描述}
问题：
{问题}
之前的讨论：
{所有之前的轮次记录，格式为“智能体 X (角色): 回答”}
这是多智能体辩论的第 {N} 轮。请仔细阅读之前的讨论。
你的任务：
1. 回应针对你立场的最强反驳。
2. 指出你与其他智能体 **同意** 的地方（承认对方的优点）。
3. 指出你仍然 **不同意** 的地方并说明理由。
4. 基于目前的讨论完善你的提议。
**不要** 只是重复你之前的立场。要与他人的观点进行互动。如果对方提出了更好的论点，就改变你的想法。
按以下格式回答：
同意之处：[其他智能体说得对的地方]
不同意之处：[你仍然不同意的点及理由]
完善后的提议：[你更新后的建议]
信心指数：[1-10，你对自己完善后的立场的信心程度]
直接写出你的回答 —— 不要写入任何文件。
每轮结束后：
- 收集所有智能体的回答。
- 将其追加到
chat.json的rounds数组中：
{
"round": 1,
"entries": [
{"agent": "智能体 A", "role": "架构师", "response": "..."},
{"agent": "智能体 B", "role": "务实派", "response": "..."},
{"agent": "智能体 C", "role": "批评者", "response": "..."}
]
}
- 检查是否趋同：如果所有智能体都同意（信心指数 8+，提议一致），则提前停止 —— 无需进行更多轮次。
5. 综合最终输出
在最后一轮结束后，您（协调者）阅读完整的辩论内容，并生成一份综合报告。不要 为这一步再生成智能体 —— 您自己来完成。
分析：
- 智能体在哪些方面达成了共识？ —— 这些是高信心的结论。
- 在哪些方面仍然存在分歧？ —— 这些是需要用户决策的真实权衡。
- 提出了哪些未解决的担忧？ —— 这些是需要监控的风险。
- 是否有智能体改变了想法？ —— 改变想法是强烈的信号。
6. 写入最终报告
更新 active/chatroom/chat.json 中的 final_output 字段，并将人类可读的摘要写入 active/chatroom/chatroom_report.md：
# 智能体聊天室报告
**问题**：{问题}
**智能体数量**：{N} | **辩论轮数**：{R}
**日期**：{日期}
## 参与者
| 智能体 | 角色 | 最终信心指数 |
|--------|------|----------------|
| 智能体 A | {角色} | {信心指数}/10 |
| 智能体 B | {角色} | {信心指数}/10 |
| 智能体 C | {角色} | {信心指数}/10 |
## 共识
{所有智能体在最后一轮达成一致的内容}
## 关键分歧
{智能体仍然存在分歧的地方 —— 公正地呈现双方观点}
## 建议行动
{您作为协调者的综合判断 —— 考虑所有观点后的最佳前进路径}
## 未解决的风险
{辩论中提出的但未完全解决的担忧}
## 辩论亮点
{最有趣的交锋 —— 想法发生改变或出现强有力反驳的地方}
## 完整记录
{链接到 chat.json 或将关键交锋内容嵌入此处}
7. 交付结果
向用户展示：
- 一段摘要 —— 辩论结果的概括
- 建议行动 —— 您作为协调者的判断，基于辩论内容
- 最尖锐的分歧 —— 需要用户判断的部分
- 报告和 chat.json 的文件路径
配置
| 参数 | 默认值 | 描述 |
|---|---|---|
| N | 3 | 聊天室中的智能体数量 |
| R | 3 | 辩论轮数 |
| model | sonnet | 每个智能体使用的模型 |
| roles | auto | 智能体角色（自动分配或用户指定） |
用户可以覆盖："让5个opus智能体辩论4轮" 或 "让一个架构师和一个初级开发人员辩论"。
成本考量
- 3 个 sonnet 智能体 x 3 轮 = 9 次智能体调用（约 $0.30-0.50）
- 3 个 opus 智能体 x 3 轮 = 9 次智能体调用（约 $3-5）
- 5 个智能体 x 5 轮 = 25 次调用 —— 使用 opus 会比较昂贵
- 默认使用 sonnet。仅在用户明确要求或问题需要深度技术推理时才使用 opus。
- 早期趋同可以节省成本 —— 如果智能体在所有轮次完成之前达成一致，则提前停止。
边界情况
- N < 2：警告用户 —— 聊天室至少需要 2 个智能体。最少为 2。
- 所有智能体立即达成一致：在第 1 轮后停止。报告一致同意。这是一个有效（且廉价）的结果。
- 智能体陷入僵局：经过 R 轮仍未达成共识，则如实报告僵局。结论是这是一个真正的判断问题，没有绝对的答案。
- 智能体偏离主题：在综合报告中排除该回答，并记下有效的智能体数量。
- 已存在聊天室文件：检查
active/chatroom/目录中是否存在文件。直接覆盖而不询问（这些是临时的辩论产物，不是持久性数据）。 - 用户指定了自定义角色：完全按照他们指定的角色使用。除非被要求，否则不要添加额外的角色。
输出文件
| 文件 | 描述 |
|---|---|
active/chatroom/chat.json | 完整的结构化辩论记录 |
active/chatroom/chatroom_report.md | 人类可读的综合报告 |
之前的报告会被覆盖 —— 这些是临时的辩论工具，并非存档。