我们需要怎样的多 agent

最近我看到了一个十分有趣的多 agent 项目——三省六部制,首先用户是皇上,不论怎么讲,先过一把登基的瘾。它任命了一个太子,专门负责消息的分拣分发,平时和你闲聊,需要的时候就给下面派任务。下面有三省(中书·门下·尚书):负责需求规划,质量品控,任务调度。 最后还有执行六部(现在加了一个早朝官,变七部了),分别执行代码编写、bug 修复、数据处理,对任务进行了细致的划分,一个部门掌握一小摊。

先不管效果怎么样,如果早朝的时候,所有agent都先说一遍吾皇万岁万岁万万岁,那这个系统还是提供情绪价值的。相关的帖子下面,最有趣的评论莫过于,这套系统最大的问题就是容易导致token爆炸,国库空虚🤣。

在这个有趣的开源项目之外,我开始思考一个问题:人类的分工套用在agent上是不是合适的?


人类为什么进行分工

亚当·斯密在《国富论》开篇第一章便是论分工,他开宗明义地提到:劳动生产力最大的进步都是分工的结果。在亚当·斯密观察大头针工厂时,他发现当一个人试图完成所有工序,其效率远远低于一群各司其职的专人。当一个人专心完成一个工序时,经验的增长,判断力的提高,都进一步地提高生产力。

因此,当人类让 agent 深度参与自己的工作时,第一个想到的就是将全链条的工作进行切分。以市场调研为例,很多人设计的多 agent 工作流会包括:调研员(收集信息)、分析师(整理洞察)、策略师(给建议)、文案(写提案)——因为在正常人类社会中,这些本就由不同工种各自完成。

这个直觉很自然。但 AI 的"分工",真的和人类的分工是一回事吗?


AI 分工面临的独特问题

拆分越多,丢失越多

人类分工时,交接的是信息——一份文件、一个结论、一条指令。但 AI 在完成任务的过程中,积累的不只是信息,还有感知:在收集素材过程中形成的判断、在反复尝试中建立的路径感知。这些东西很难打包交接。

还是以市场调研为例。调研员 agent 在收集信息的过程中,会注意到某个数据的异常、某个用户反馈的微妙差异——这些构成了它对这个市场的"感知"。但当它把一份调研报告交给下一个分析师 agent 时,报告里有数据,没有这些感知。分析师拿到的是结论,不是过程;是表格,不是直觉。当一个多 agent 流水线把任务拆开,上一个节点往往只将最终产出交给下一个节点,而上下文信息在交接中被稀释掉了。拆得越细,丢失的越多。

上下文够大之后

多 agent 架构最初流行,有一个很实际的工程原因:早期模型的上下文窗口很小,一个 agent 根本装不下一条完整链路所需的信息,只能拆开来各管一段。

但现在的模型,上下文窗口已经足够大,能力也足够强,一个 agent 完全可以从头到尾完成整条链路上的工作。那些因为"装不下"而拆分的理由,正在逐渐失效。

不过,上下文边界并没有消失,只是变得更隐蔽。当 agent 发现自己接近上下文边界,它甚至会开始"恐慌"——着急把任务结束,以免撞上限制。OpenClaw 创始人 Peter Steinberger 在采访中提到,他会跟 agent 说"take it slow,慢慢来"。如果不这么说,agent 会在 thinking 里念叨"哦,我的上下文快接近上限了,所以我需要……“然后仓皇收尾。“慢慢来”,成了他工作流里神奇的提示词工程的一部分。

角色隔离是值得主动设计的

当然,有一种拆分是值得的:构建者与评估者的分离

agent 在完成自己的任务之后,往往会自信地说"我干得不错”。这时候,就需要另一个带有空白上下文的 agent 来审视它——由于没有过去构建时的路径依赖,它更容易发现问题,也更容易提出结构化的意见。

这不是模拟人类的"质检部门",而是利用了 AI 的一个特性:全新的上下文,意味着全新的眼光。


专家实践:Peter 的「轻管理」方案

我不想泛泛地讨论理论。Anthropic、LangChain 的博客里有很多类似的分析,最近关于 Harness Engineering 的讨论也受到了关注。让我们看看真正在用多 agent 工作流做出现象级应用的人是怎么做的。

Peter Steinberger 用多 agent 工作流开发了 OpenClaw。他在一个 3×3 的终端网格里并行运行 3 到 8 个 agent——但是,他没有一个主 agent 充当"太子"做大脑、做管理、做分配。他自己就是那个 main agent。

他对 background agents(后台自动跑的 agent)持明确的保留态度:因为他需要实时观察 agent 的走向,一旦发现偏离就立刻按 Escape 介入。这不是能力不够的问题——他每月花费上千美元订阅,拥有多个 ChatGPT 和 Claude 的最昂贵套餐,使用目前最聪明的模型,也从来没有做甩手掌柜,让它们无限制地自行运行。

他对分工的理解是:人作为质检者和方向控制器,agent 作为执行加速器。


我们需要怎样的多 agent

这让我想起强化学习奠基人 Rich Sutton 在 2019 年写下的《The Bitter Lesson》——计算领域最著名的文章之一,苦涩的教训。他的核心结论是:人类用领域知识和精巧工程来"指导"AI 的那些努力,最终都败给了算力的暴力碾压。那些看起来聪明的人工设计,一次次被更大的计算规模所淘汰。

这个教训放到多 agent 设计上同样成立:越是精心模拟人类组织架构的复杂层级,越会随着模型本身的进化而失去意义。随意堆砌 agent 的数量,迎来的不是分工带来的效率提升,而是患上了大公司病——分工变成了互相推诿,每个节点都在等上一个节点,没有人真正在推进执行。

那什么样的多 agent 是值得设计的?

串行认知隔离:提案者与评估者分开跑,各自拥有独立的上下文。不是因为模拟了人类的"复核机制",而是因为 AI 评价自己的工作时,往往都说"我做得不错"——一个空白上下文的审视者,比任何 prompt 技巧都更有效。

并行子任务:天然适合多 agent 的场景,用于提高速度。任务之间相互独立,并行不会带来上下文损耗,这才是真正的效率收益。

回到那个三省六部制的项目,正所谓登基易,治国难。当 agent 们忙成一锅粥,token 哗哗地烧,你是否还知道自己想要什么,看得出哪里跑偏,知道什么时候该伸手打断?

真正懂多agent的人,不是在享受登基的仪式感,而是知道什么时候该亲自出手——就像Peter按下Escape那一刻。