最近我看到了一个十分有趣的多 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那一刻。