为什么我放弃了 Multi-Agent，效果反而更好（以及你可能也不需要它)
- Source: https://x.com/xxx111god/status/2025394346191708297?s=46
- Mirror: https://x.com/xxx111god/status/2025394346191708297?s=46
- Published: 2026-02-22T02:16:56+00:00
- Saved: 2026-02-23
Content
这两天刷 X 全是 multi-agent
编排框架、通信协议、Agent 间消息传递... 大家都在聊，项目一个接一个
说实话，看得我有点 FOMO
我也试过。跑了一段时间真正的 multi-agent：多个 session 并行、Agent 之间传消息、共享状态... 技术上跑通了，但越用越觉得不顺手
问题在哪？
多个 session 要管理 — 哪个 Agent 在干嘛？
通信协议要设计 — 消息格式、超时、重试...
状态同步是个坑 — Agent A 改了数据，Agent B 怎么知道？
token 成本蹭蹭涨 — 每个 Agent 都要带完整 context
折腾了两个天，我问自己：我真正想要的是什么？
不是"多个独立运行的 Agent"，而是"多个视角帮我分析问题"。
这两个是不同的东西。
于是我换了个思路：单 Agent，让它在脑子里开圆桌会议。
不用真的 spawn 多个 Agent 互相发消息。就在同一个 context 里，让 AI 切换视角、自己跟自己辩论。
效果？比之前的 multi-agent 更好。成本？降了 10 倍。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
为什么要让 AI 吵架
刚开始用 AI 做决策的时候踩了个坑：它太听话了。
我问"这个交易能做吗"，它分析一通，给个看起来合理的答案。但它不会说"等等，你上次这么干亏了 $15"。它没那个视角。
单 Agent = 单视角 = Echo Chamber。
我问什么它顺着说，我漏掉的盲点它也看不见。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
我的圆桌会议怎么搞的
现在我 OpenClaw 里定义了 15 个"专家角色"：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
真实案例：交易亏了 $15，吵出一个系统 bug
上周天气交易单日亏了 $240.92。我让 AI 复盘，拉了三个角色进来：
风控官 🛡️ 上来就开炮："7 单全压 LAX 一个市场？47% 的亏损来自同一个 ticker。这是风控失败。"
激进派 🔥 不服："预测 64°F，实际 64.5°F，才差 0.5°F。这是方差，不是策略问题。"
质疑者 🔍 插了一刀："等等，settled_positions 数组是空的。我们根本没历史数据，怎么证明策略有效？"
三个人吵完，发现真正的问题：系统没有单市场仓位上限。 压 7 单在同一个 ticker 上，代码居然没拦。
当天晚上就加了 max 2 contracts per ticker 的硬限制。
如果只有一个 Agent，它会顺着我说"是的运气不好"。三个角色一吵，把系统漏洞吵出来了。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
另一个案例：从"今天亏了"升级到"整个策略有问题"
连续亏了几天，7 天胜率跌到 43.8%。我又开了个圆桌。
风控官：
"这不是单日波动，是系统性负期望。立刻暂停。"
激进派这次没杠，反而帮忙找 root cause：
"预测误差 σ=4°F，但 bracket 宽度只有 1°F。这不是交易，是赌博。"
质疑者翻旧账：
"Feb 10 的复盘报告说了 Open-Meteo 系统性低估 1-1.4°F，为什么没修？"
这次吵完，决定：
暂停交易 2 天
重建 30 天校准数据集
策略从 V2 升级到 V3
一个 Agent 会说"继续跑，明天可能就回来了"。圆桌把问题从"今天怎么亏了"升级到"整个策略架构是不是有问题"。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
技术问题也能用
还有个例子。我有个 AI 生图的工作流，固定 IP 角色叫 v17，但每次生成都长得不一样。
拉了 4 个技术角色进来：
TechEngineer 🔧："看了代码，v17 模板文件根本没被引用。contentgen.py 不知道它存在。"
QualityArchitect 🏛️："更深的问题——我们依赖人记得用 v17，而不是系统强制。SOP 写了没用，SOP 不会自动执行。"
SkepticalOperator 🤔："别过度工程。检测到 platform=xhs 时自动 prepend v17 prompt，3 行代码，今晚部署。"
当晚改完，成功率从 ~30% 拉到 >90%。
这次吵出来的金句："Rules must be in code, not in documentation."
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
两个最有用的角色
用下来，最值的两个：
🏆 MVP 角色
│
├─ 😈 DevilsAdvocate
│ └─ 专门唱反调，找漏洞，压力测试
│ 防 groupthink，防"这次不一样"
│
└─ 📚 HistorianAnalyst
└─ 专门翻旧账
"上次你这么干亏了 $179，忘了AI 是无状态的，但我 memory 文件里存了所有历史教训。HistorianAnalyst 就是在决策前把相关的坑调出来。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
为什么不每次 15 个角色全上
我定义了 15 个角色，但不代表每次都要全拉进来。
成本。时间。没必要。
大部分决策 3 个人 2 分钟能出结论，没必要开 15 人全体大会。
📊 我的分级
│
├─ <$100 ──────→ 3 人
├─ $100-500 ───→ 4-5 人
├─ >$500 ─────→ 6+ 人
└─ 不可逆的事 ──→ 6+ 人 + DevilsAdvocate 必须在场（Berman 的顾问委员会是固定 8 人每晚全跑，那是不同的设计思路——他追求全面覆盖，我追求按需精准。）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
和 Berman 的"顾问委员会"有什么区别
Matthew Berman 最近分享了他的 8 人 AI 顾问委员会。每晚自动跑，分析 14 个数据源，早上给建议。
我的不一样：
┌─────────────────┬─────────────────┐
│ Berman │ 我 │
├─────────────────┼─────────────────┤
│ 每晚定时跑 │ 要决策时才跑 │
│ 固定 8 人 │ 动态选 3-8 人 │
│ 主动发现机会 │ 防止决策翻车 │
└─────────────────┴─────────────────┘
proactive checkpoint
advisory
两种思路都行，看场景。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
实现比你想的简单
不用搭什么 multi-agent 框架。
就是一个 prompt 模板：
针对以下决策，开个圆桌会议：
[决策描述]
参与角色：
-
🛡️ RiskGuardian：找风险
-
🔥 GrowthStrategist：找机会
-
🤔 SkepticalOperator：质疑假设
每个角色发言 2-3 句，然后给 Consensu就这样。
不用 spawn 多个 session，不用设计通信协议，不用处理状态同步。
一个 Agent，多个视角，同一个 context 里完成。
成本跟普通对话差不多。效果比单视角强太多。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
为什么这个方案更适合日常使用
折腾了两个月，我越来越觉得这个"伪 multi-agent"比真 multi-agent 更适合个人用户。几个原因：
- 零基础设施
真 multi-agent 你得搞什么？
Agent 编排框架（LangGraph、AutoGen、CrewAI...）
消息队列或者 Agent 间通信协议
状态持久化（每个 Agent 的 memory 怎么存）
错误处理（一个 Agent 挂了怎么办）
圆桌会议需要什么？一个 prompt 模板。完了。
今天想加个新角色？改两行 prompt。不用重新部署，不用调 API。
- Context 天然统一
真 multi-agent 最头疼的是什么？状态同步。
Agent A 做了个决定，Agent B 怎么知道？你得设计消息传递、共享 memory、或者某种 pub-sub 机制。
圆桌会议？所有角色在同一个 context 里。风控官说完，激进派自然就看到了。不需要任何同步逻辑。
LLM 的 attention 机制本来就会让后面的角色"听到"前面的发言。这是免费的。
- 调试简单到离谱
真 multi-agent 出 bug 了：
是哪个 Agent 的问题？
消息传到了吗？
状态对不对？
要看好几个 session 的 log...
圆桌会议出问题了：就一个对话，从头看到尾。哪里不对一目了然。
- 成本差 10 倍不夸张
假设你要 5 个角色讨论一个问题。
真 multi-agent：
5 个独立 API 调用
每个都要带完整 system prompt
还要额外调用来汇总
保守估计 6-10x token
圆桌会议：
1 次调用
角色描述加起来可能就 200 token
输出长一点，但也就 2-3x 普通对话
每天跑几十次，一个月下来差别很大。
- 任何 LLM 都能用
这个方案不依赖任何框架、任何特定 API。
ChatGPT 能用。Claude 能用。Gemini 能用。本地跑的 Llama 也能用。
换模型？直接换，prompt 不用改。
真 multi-agent 框架呢？换个模型可能要改一堆适配代码。
- 迭代速度快
我的角色从最开始 5 个，迭代到现在 15 个。中间加过、删过、改过很多次。
每次改动就是编辑一个 markdown 文件。改完立刻生效。
如果是真 multi-agent，每加一个 Agent 就要：
写 Agent 代码
定义它的 tool
配置它和其他 Agent 的通信
测试集成
一个下午能加 5 个角色 vs 一周加一个 Agent。迭代速度差太远了。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
技术细节：我的 Skill 文件长什么样
在 OpenClaw 里，我把圆桌会议封装成一个 skill。核心就是个 YAML + markdown：
name: roundtable
description: 多视角决策分析
角色池定义
roles:
RiskGuardian:
emoji: 🛡️
focus: 风险、downside、防御
GrowthStrategist:
emoji: 🔥
focus: 增长、机会、ROI
SkepticalOperator:
emoji: 🤔
focus: 质疑假设、执行现实
DevilsAdvocate:
emoji: 😈
focus: 唱反调、压力测试
HistorianAnalyst:
emoji: 📚
focus: 历史类比、翻旧账
... 还有 10 个
选人规则
selection:
default: 3-4 人
high_risk: 6+ 人，必须含 RiskGuardian
financial: 必须含 FinanceAnalyst
irreversible: 必须含 DevilsAdvo调用的时候，AI 根据任务类型自动选角色，然后跑一轮讨论，最后给 Consensus。
整个 skill 文件不到 100 行。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
进阶玩法：和 Memory 系统联动
HistorianAnalyst 之所以能"翻旧账"，是因为我有个 memory 系统。
每次踩坑，我都会写进 memory/lessons/ 目录。格式大概这样：
{
"date": "2026-02-11",
"category": "trading",
"lesson": "7 单压同一个 ticker 导致 47% 亏损集中",
"action": "加 max 2 contracts per ticker 限制"
}
圆桌会议开始前，HistorianAnalyst 会先搜一遍相关的历史教训。
这样它说"上次你这么干亏了 $179"不是编的，是真的有记录。
AI 无状态没关系，文件系统有状态就行。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
什么时候我会升级到真 multi-agent
不是说圆桌会议能解决所有问题。有几个场景我确实在考虑上真 multi-agent：
- 需要真正并行的任务
比如同时监控 10 个数据源，每个数据源的处理逻辑不一样。
圆桌会议是串行的——一个角色说完下一个再说。真要并行跑，得上多 session。
- 超长运行时间
比如跑一整夜的监控，每小时检查一次。
单个 context 撑不了那么久，token 会爆。这种得用独立的 daemon agent。
- 需要独立工具权限
比如 CRM Agent 要连数据库，Trading Agent 要连交易所 API。
圆桌会议里的角色共享同一套工具。如果要隔离权限，得拆成真 Agent。
但这些都是进阶场景。日常决策分析，圆桌会议绰绰有余。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
什么时候才需要真的 multi-agent
🤔 需要真 multi-agent 的场景
│
├─ 任务要并行跑（同时爬 10 个网站）
├─ 需要持久化独立状态（CRM Agent 记住所有联系人）
└─ 超长时间运行（跑一整夜的监控）如果只是"想要多个视角帮我想问题"——圆桌会议够用。
简单方案能解决的，别上复杂架构。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
一句话
单 Agent 太顺从。让它们吵起来，才能吵出你没想到的问题。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
你怎么避免 AI 的 echo chamber？评论区聊聊。
cate
s。
？"
还有 8 个
Link: http://x.com/i/article/2025384356089389056