多个 agent 协同完成一件事。本页收 立党 与 onevcat 两方观点 + 综合判据。母概念见 Agents。
一句话判据
multi-agent 是否值得 = 「是否共改同一份产物 + 有没有干净的管理/汇总层」。 独立可拆分 + 层层汇总 → 值;共改一份代码 / 七嘴八舌无人管理 → 坑。
四种形态(别混为一谈)
| 形态 | 例子 | 评价 |
|---|---|---|
| 并行独立(map-reduce) | 搜索/爬虫、research、数据清洗、批量审核 | ✅ 最适合:足够并行、独立拆分、层层 reduce |
| 多模型交叉验证 | onevcat 的 argue | ✅ 防单模型盲区,"一个模型骗我,总不能全骗我" |
| 串行流水线 | MetaGPT(PM→架构→码→QA) | ⚠️ sequential,效率 < 单 agent 持续工作,只换来上下文隔离 |
| 组织/角色模拟 | Crew AI、agent agency、腾讯 WorkBody 类 | ❌ 没人管理 = 一团糟,过去几年公认大坑 |
适合 vs 不适合(来自 立党)
✅ 适合
- 大规模并行 map-reduce:任务先 map 给多个 agent,再 reduce 成汇总——架构干净
- 流程受控 + 可验证驱动的 multi-agent(立党称在 GitHub 开源,1000+ star)
❌ 不适合
- 共改代码的编程:七手八脚 merge 灾难;coding 更适合「单线程走到黑」。1000 个 agent 贡献代码 = 软件工程管理崩溃
- 串行 MetaGPT:效率反而低于单 agent
- 公司/团队架构模拟:七嘴八舌、无人决策,没产出
经济学前提(立党)
- 值不值看 ROI:用 1000 倍成本换 10-100 倍提升才划算(成本只是钱,效率提升不是钱能买的)
- 趋势支撑:token 越来越便宜/快、并发越来越高、模型越来越聪明 → multi-agent 是他眼中 agent scaling 唯一可信的方式
- 但前提始终是「能拆 + 能汇总 + 能验证」,否则成本打水漂
两方看似矛盾,其实不冲突
- 立党:编程不适合 multi-agent(共改代码会乱)
- onevcat:用 3 猫娘并行跑多 repo/多 worktree + argue 辩论
- 化解:onevcat 的并行是「独立任务并行 + 人居中调度 + 多模型交叉验证」,每个 agent 在自己的 worktree/repo 里干,不共改同一份代码;argue 也不是串行 MetaGPT。→ 落在立党认可的 ✅ 栏,而非他批的「七手八脚改一份代码」
- 可操作结论:想上 multi-agent 先问——任务能不能拆成互不共改产物的独立块?有没有一个干净的汇总/管理层(人或编排器)?两个都 yes 才上
与本 wiki 的连接
- 实践落地:个人多Agent工作流(onevcat 提炼)、需求驱动的自动化开发工作流(你自己的设计——注意:它更偏单 agent 在隔离环境干活,符合立党「编程单线程」的取向)
- 母概念:Agents
- 可验证环境是 multi-agent 的隐含前提之一,见 Agents 的「完美场景=封闭+可验证」
待补
- 立党下一期:用管理学方式做合理的 multi-agent 管理(出了再补)
- 立党开源的「流程受控 multi-agent + 可验证驱动」项目,找来读后补具体机制
- Anthropic/OpenAI 官方对 multi-agent / sub-agent 的工程建议(横向对照)