OpenClaw 多 Agent 到底是利器还是噱头?系列三(终):90% 的人不需要多 Agent
这是「OpenClaw 多 Agent 到底是利器还是噱头？」系列第 3 集，共 3 集。
问题一：流水线式任务，到底需不需要多 Agent？
“早期我额外设了coding、architect、PM三个技术角色，结果发现这几个角色基本没什么实际产出——它们的能力和Zoe + ACP编码专家的组合高度重叠，反而增加了通信复杂度和调试成本。后来全砍了。”
“LLM是不可靠的路由器。用它们做创造性工作，用代码做管道。”
流水线式的任务，应该用代码/配置做编排，而不是用多个Agent互相传递。
以岚遥的 Macro → Trading 流水线为例：
Macro Agent 产出宏观因子↓ sessions_spawnTrading Agent 引用因子做评分
触发 trading 任务↓ 加载 macro-analysis Skill（按需）↓ 加载 stock-analysis Skill（按需）↓ 同一个 Agent 按顺序执行
-
-
且 Skill 按需加载（OpenClaw的 extraDirs 机制）
-
单 Agent + Skill 的质量差距，可以忽略不计
-
-
运维成本更高（两个独立workspace、两套记忆）
-
每加一个Agent，交互关系指数级增长（3个 = 3 对，6个 = 15 对）
问题二：多 Agent 到底解决什么问题？
抛开”并发效率”这个最显而易见的理由，逐一分析剩下的理由。
一个 Agent 的 SOUL.md + Skills 全加载，噪声会淹没关键规则。多 Agent 让每个 Agent 只看到自己需要的信息。
适用场景：技能集差异大（如量化交易 vs 生活管家）。
某些 Agent 有 exec 权限，某些没有。某些 Agent 能访问敏感数据，某些不能。
|
说法
|
为什么被夸大
|
|
“专业的事交给专业的Agent”
|
单Agent 通过Skill 按需加载也能实现”专业性”
|
|
“解耦复杂性”
|
流水线本身就是解耦，不需要多Agent
|
|
“减少幻觉”
|
幻觉主要来自prompt 质量和模型能力，不是Agent 数量
|
|
“Agent 间互相审核”
|
用同一个Agent 在不同阶段做不同检查，效果一样
|
多Agent不是架构升级，而是问题升级。不要为了解决不存在的问题引入复杂度。
问题三：你需不需要多 Agent？
1.你是不是在同时服务多个用户/群，且需要不同的身份和权限？
如果是，多 Agent 合理。不同群需要不同的人设和回复风格，单 Agent 的 SOUL.md 会膨胀到无法维护。
如果是，多 Agent 合理。某些 Agent 有 exec 权限，某些没有，这是最硬核的多 Agent 理由。
如果是，多 Agent 有价值。比如岚遥的 Trading Agent 运行半个月积累了大量交易经验，如果和生活管家共享记忆，会互相污染。
如果是，多 Agent 可以简化配置。每个 Agent 绑定一个默认模型，比在单 Agent 里来回切换更清晰。
判断标准
·0-1个”是”：单 Agent 足够，加 Skill 就行
对大多数人的建议
如果你和我一样，是个人用户，少量渠道（微信/QQ/飞书），技能集虽多但可以通过按需加载解决：
用 OpenClaw 的 extraDirs 机制，只在需要时注入相关Skill，避免上下文噪声。
3.用Cron + sessions_spawn做并行任务
临时子Agent，不是持久化的。需要并行时 spawn 一个，跑完自动归档。
4.等你真正遇到”一个Agent搞不定”的场景，再考虑拆分
什么算”搞不定”？上面 4 个自测问题，2个以上”是”的时候。
写在最后
回到系列开头的那个问题：多 Agent 到底是利器还是噱头？
答案是：对少数场景是利器，对大多数人来说是被包装出来的噱头。
真正的利器场景：安全隔离、多渠道身份、独立记忆体系。这些是单 Agent 确实搞不定的。
被包装出来的噱头：把流水线说成多Agent、把”并行搜索”说成多 Agent 优势、用”专业性”掩盖路由不可靠的问题。
岚遥砍掉了 3 个角色，Gustavo用 YAML 替代了 LLM 路由，HN用户说”同步两个心智的状态极其昂贵和缓慢”。
你最初的直觉是对的——模型擅长执行，不擅长探索。让LLM做路由和编排，恰恰是它目前不擅长的事。
多 Agent 不是未来，也不是过去。它是一个工具，用在对的地方就是利器，用错地方就是噱头。
这是「OpenClaw多 Agent 到底是利器还是噱头？」系列第 3 集（最终集），共 3 集。
夜雨聆风
